Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #118058 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2023-12-10 10:46 +0100 |
| Last post | 2024-02-14 15:57 +0100 |
| Articles | 20 on this page of 213 — 14 participants |
Back to article view | Back to comp.lang.c++
Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-10 10:46 +0100
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-10 21:48 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-11 04:15 +0100
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-11 17:12 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-11 18:19 +0100
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-13 15:16 +0000
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-13 15:25 +0000
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-14 15:06 +0000
Re: Sieve of Erastosthenes optimized to the max red floyd <no.spam.here@its.invalid> - 2023-12-14 08:20 -0800
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-23 10:30 -0800
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-23 21:20 +0000
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-24 00:36 -0800
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-29 18:03 +0000
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-13 21:31 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-20 13:44 +0100
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-21 15:30 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-21 17:07 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-21 17:13 +0100
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-23 10:21 -0800
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2023-12-23 21:21 +0000
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-24 10:49 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-21 14:23 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-22 04:28 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-21 20:02 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-22 17:55 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-23 12:52 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-24 11:03 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-24 13:24 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-26 06:00 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-25 21:39 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-26 10:27 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-26 12:24 -0800
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-26 23:35 +0000
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-26 15:37 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-26 21:59 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-27 10:23 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-27 20:49 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-28 12:00 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-28 15:38 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-29 04:17 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-28 20:58 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-29 10:58 +0100
Re: Sieve of Erastosthenes optimized to the max David Brown <david.brown@hesbynett.no> - 2023-12-29 13:56 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-29 17:04 +0100
Re: Sieve of Erastosthenes optimized to the max David Brown <david.brown@hesbynett.no> - 2023-12-30 19:27 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-31 11:22 +0100
Re: Sieve of Erastosthenes optimized to the max scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:49 +0000
Re: Sieve of Erastosthenes optimized to the max David Brown <david.brown@hesbynett.no> - 2024-01-01 12:46 +0100
Re: Sieve of Erastosthenes optimized to the max scott@slp53.sl.home (Scott Lurndal) - 2023-12-29 16:01 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-29 17:06 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-29 13:45 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-29 14:09 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-29 14:12 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-30 05:42 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-29 20:45 -0800
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-30 04:56 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-30 06:09 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-30 05:51 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-30 10:15 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-30 20:35 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-31 06:54 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 07:01 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-31 11:20 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-31 17:30 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-01 06:21 +0100
Re: Sieve of Erastosthenes optimized to the max scott@slp53.sl.home (Scott Lurndal) - 2023-12-31 18:44 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-01 06:22 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-01 08:28 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-01 14:11 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:36 -0800
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-30 04:51 +0000
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-30 12:00 -0800
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2023-12-29 17:29 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-30 05:45 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-30 11:58 -0800
Re: Sieve of Erastosthenes optimized to the max red floyd <no.spam.here@its.invalid> - 2023-12-30 14:58 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 11:49 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-31 06:51 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 11:36 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-01 07:28 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 22:53 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-01 14:11 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-01 15:34 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-02 11:55 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-02 10:38 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-03 06:48 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-03 13:32 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-04 04:37 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-05 19:21 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-06 08:18 +0100
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-06 08:31 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-06 10:30 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-06 13:15 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-06 13:19 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-07 10:14 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-07 10:10 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-07 12:46 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-08 06:48 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-08 12:18 -0800
Re: Sieve of Erastosthenes optimized to the max red floyd <no.spam.here@its.invalid> - 2024-01-08 17:14 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-09 07:19 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-09 23:33 -0800
Re: Sieve of Erastosthenes optimized to the max Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-09 02:02 +0000
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-01-09 15:12 +0100
OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Vir Campestris <vir.campestris@invalid.invalid> - 2024-01-29 21:31 +0000
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-16 08:06 -0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-16 18:30 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-23 05:51 -0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-24 10:45 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-25 00:48 -0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-25 15:51 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-03-11 10:10 -0700
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-12 10:15 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-14 12:44 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 07:25 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-14 17:20 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-14 17:35 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-14 17:41 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 19:20 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-15 16:30 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-15 11:21 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) wij <wyniijj5@gmail.com> - 2024-03-15 19:07 +0800
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-15 12:56 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-14 19:20 +0100
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-20 08:35 -0700
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-20 18:34 +0200
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-20 18:35 +0200
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-24 12:28 -0700
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Bonita Montero <Bonita.Montero@gmail.com> - 2024-04-25 06:19 +0200
Re: OT: A better sieve (was Re: Sieve of Erastosthenes optimized to the max) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-04-25 14:14 -0700
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-31 11:39 -0800
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-12-29 13:52 -0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2023-12-27 06:06 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-22 19:34 -0700
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-23 17:54 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-23 14:04 -0700
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-24 07:30 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 12:52 -0700
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-03-24 21:00 +0100
Re: Sieve of Erastosthenes optimized to the max "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-24 13:05 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-05-16 17:28 +0100
Re: Sieve of Erastosthenes optimized to the max Ben Bacarisse <ben@bsb.me.uk> - 2024-05-16 21:40 +0100
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-21 19:06 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-05-30 12:32 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-30 14:17 +0200
Re: Sieve of Erastosthenes optimized to the max Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-30 19:55 +0300
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-31 10:17 +0200
Re: Sieve of Erastosthenes optimized to the max Paavo Helde <eesnimi@osa.pri.ee> - 2024-05-31 20:52 +0300
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-05-30 22:17 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-01 21:07 +0100
Re: Sieve of Erastosthenes optimized to the max Richard Damon <richard@damon-family.org> - 2024-06-01 20:43 -0400
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-02 03:23 -0700
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-02 19:50 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-18 20:56 +0100
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 17:34 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-30 21:47 +0100
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-01 23:20 -0700
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-07-02 21:24 +0100
Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-07-03 11:25 +0100
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-15 06:15 -0700
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-20 07:41 -0700
OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-07-25 12:46 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-10 07:07 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-12 15:32 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-16 07:48 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-15 17:52 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-16 08:40 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-16 19:35 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-16 19:55 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-19 21:23 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 17:21 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 17:24 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 17:43 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-20 17:55 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 18:59 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 12:08 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-27 06:09 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-09-01 21:23 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-01 20:40 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-02 07:08 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-09-03 17:45 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 03:46 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-09-28 13:49 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-02 11:44 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-02 13:10 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-07 08:41 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-10-20 12:44 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-04 03:56 -0800
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-19 21:34 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max red floyd <no.spam.here@its.invalid> - 2024-08-19 21:08 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-20 21:14 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 09:35 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 08:31 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 19:20 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 19:36 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 19:39 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-20 20:13 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max scott@slp53.sl.home (Scott Lurndal) - 2024-08-20 20:50 +0000
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-22 17:30 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-08-22 18:38 +0200
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-22 21:47 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max Vir Campestris <vir.campestris@invalid.invalid> - 2024-08-22 21:56 +0100
Re: OT: Re: Sieve of Erastosthenes optimized to the max red floyd <no.spam.here@its.invalid> - 2024-08-22 17:00 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 10:59 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-28 15:21 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-26 12:47 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-18 19:52 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-10 17:24 -0700
Re: OT: Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 00:00 -0700
Re: Sieve of Erastosthenes optimized to the max Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-23 07:34 -0700
Re: Sieve of Erastosthenes optimized to the max wij <wyniijj5@gmail.com> - 2024-02-14 00:15 +0800
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-13 19:08 +0100
Re: Sieve of Erastosthenes optimized to the max Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-14 15:57 +0100
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-12-24 10:49 -0800 |
| Message-ID | <865y0nv3jk.fsf@linuxsc.com> |
| In reply to | #118122 |
Vir Campestris <vir.campestris@invalid.invalid> writes: > On 23/12/2023 18:21, Tim Rentsch wrote: > >> Vir Campestris <vir.campestris@invalid.invalid> writes: >> >>> On my system my code takes about 20 seconds to produce 1e9 >>> primes. [...] >> >> Do you mean 1e9 primes or just the primes less than 1e9? To >> do the first 1e9 primes a sieve would need to go up to about >> 23.9e9 (so half that many bits if only odd numbers were >> represented). > > Primes up to 1e9. > > I have another idea though, watch this space... Does your have enough memory to compute all the primes up to 24e9? If it does I suggest that for your next milestone.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-21 14:23 -0800 |
| Message-ID | <um2dsb$17vgg$2@dont-email.me> |
| In reply to | #118058 |
On 12/10/2023 1:46 AM, Bonita Montero wrote:
> union alignas(CL_SIZE) ndi_words_cl { word_t words[CL_SIZE /
> sizeof(word_t)]; ndi_words_cl() {} };
alignas is pretty damn convenient. Iirc, it pads and aligns? Iirc, it
even works with std::vector.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-22 04:28 +0100 |
| Message-ID | <um2vpr$1e7pn$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118106 |
Am 21.12.2023 um 23:23 schrieb Chris M. Thomasson: > alignas is pretty damn convenient. Iirc, it pads and aligns? Iirc, it > even works with std::vector. The problem with that is that I can't have an alignas on a word_t since the rest of the cacheline would be padded. So I join as much word_t's as possible in a single ndi_word_s_cl and have a span later on it to have full iterator debugging.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-21 20:02 -0800 |
| Message-ID | <um31o0$1edq3$1@dont-email.me> |
| In reply to | #118108 |
On 12/21/2023 7:28 PM, Bonita Montero wrote:
> Am 21.12.2023 um 23:23 schrieb Chris M. Thomasson:
>
>> alignas is pretty damn convenient. Iirc, it pads and aligns? Iirc, it
>> even works with std::vector.
>
> The problem with that is that I can't have an alignas on a word_t since
> the rest of the cacheline would be padded. So I join as much word_t's as
> possible in a single ndi_word_s_cl and have a span later on it to have
> full iterator debugging.
>
Yup. This is a good practice indeed as long as they are related
logically, it will be beneficial to do this. Say a cache line is say 64
bytes and a word of 8 bytes, can be packed 8 fulls words indeed. No
cache line straddling allowed, damn it!
aligned on a l2 cache line boundary:
struct l2_cache_line
{
word m_words[8];
};
Fine. I think alignas auto packs. I need to to bust out the most recent
C++ mode on my compilers to revisit it. Actually, I need to do it
anyway. The fun part is that I have old code that is interesting, well
before alignas:
https://pastebin.com/raw/f37a23918
Fun times! :^)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-22 17:55 +0100 |
| Message-ID | <um4f1l$1l1c2$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118109 |
Am 22.12.2023 um 05:02 schrieb Chris M. Thomasson: > Fine. I think alignas auto packs. I need to to bust out the most recent > C++ mode on my compilers to revisit it. Actually, I need to do it > anyway. The fun part is that I have old code that is interesting, well > before alignas: False-sharing woudln't hurt my algorithm much since only the beginning and the end of the thread-local segment overlaps with other thread; but I do it anyway to have maximum performance.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-23 12:52 -0800 |
| Message-ID | <um7haa$274oh$3@dont-email.me> |
| In reply to | #118113 |
On 12/22/2023 8:55 AM, Bonita Montero wrote: > Am 22.12.2023 um 05:02 schrieb Chris M. Thomasson: > >> Fine. I think alignas auto packs. I need to to bust out the most >> recent C++ mode on my compilers to revisit it. Actually, I need to do >> it anyway. The fun part is that I have old code that is interesting, >> well before alignas: > > False-sharing woudln't hurt my algorithm much since only the beginning > and the end of the thread-local segment overlaps with other thread; but > I do it anyway to have maximum performance. That's is a good habit to get into. :^)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-24 11:03 +0100 |
| Message-ID | <um8vlp$2h8oc$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118120 |
Am 23.12.2023 um 21:52 schrieb Chris M. Thomasson: > On 12/22/2023 8:55 AM, Bonita Montero wrote: >> False-sharing woudln't hurt my algorithm much since only the beginning >> and the end of the thread-local segment overlaps with other thread; but >> I do it anyway to have maximum performance. > That's is a good habit to get into. :^) I experimentally removed the masking of the lower bits of the partition bounds according to the cacheline size and there was no measurable performance-loss.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-24 13:24 -0800 |
| Message-ID | <uma7i4$2nagg$1@dont-email.me> |
| In reply to | #118125 |
On 12/24/2023 2:03 AM, Bonita Montero wrote: > Am 23.12.2023 um 21:52 schrieb Chris M. Thomasson: > >> On 12/22/2023 8:55 AM, Bonita Montero wrote: > >>> False-sharing woudln't hurt my algorithm much since only the beginning >>> and the end of the thread-local segment overlaps with other thread; but >>> I do it anyway to have maximum performance. > >> That's is a good habit to get into. :^) > > I experimentally removed the masking of the lower bits of the > partition bounds according to the cacheline size and there was > no measurable performance-loss. > Still, imvvho, it _is_ a good practice to get into wrt padding and aligning...
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-26 06:00 +0100 |
| Message-ID | <umdmkf$3clht$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118128 |
Am 24.12.2023 um 22:24 schrieb Chris M. Thomasson: > Still, imvvho, it _is_ a good practice to get into wrt padding and > aligning... With an upper bound of 2 ^ 32 I've got 131070 cachleines per thread. If I have false sharing at the beginning and end of the range that doesn't hurt much.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-25 21:39 -0800 |
| Message-ID | <umdovb$3cmi3$2@dont-email.me> |
| In reply to | #118131 |
On 12/25/2023 9:00 PM, Bonita Montero wrote: > Am 24.12.2023 um 22:24 schrieb Chris M. Thomasson: > >> Still, imvvho, it _is_ a good practice to get into wrt padding and >> aligning... > > With an upper bound of 2 ^ 32 I've got 131070 cachleines per thread. > If I have false sharing at the beginning and end of the range that > doesn't hurt much. > Remember when Intel first started hyperthreading and god damn threads could false share with each other (on the stacks!) the low and high 64 byte parts of the 128 byte cache lines? A workaround was to artificially offset the threads stacks via alloca.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-26 10:27 +0100 |
| Message-ID | <ume6ap$3ecjk$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118132 |
Am 26.12.2023 um 06:39 schrieb Chris M. Thomasson: > Remember when Intel first started hyperthreading and god damn threads > could false share with each other (on the stacks!) the low and high 64 > byte parts of the 128 byte cache lines? A workaround was to artificially > offset the threads stacks via alloca. If you have one core and two threads there's no false sharing. It doesn't matter if the "conflicting" accesses come from either thread of from one thread with that. False sharing is only pos- sible with two cores or more.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-26 12:24 -0800 |
| Message-ID | <umfcqi$3jktj$2@dont-email.me> |
| In reply to | #118133 |
On 12/26/2023 1:27 AM, Bonita Montero wrote: > Am 26.12.2023 um 06:39 schrieb Chris M. Thomasson: > >> Remember when Intel first started hyperthreading and god damn threads >> could false share with each other (on the stacks!) the low and high 64 >> byte parts of the 128 byte cache lines? A workaround was to >> artificially offset the threads stacks via alloca. > > If you have one core and two threads there's no false sharing. So, are you familiar with Intel's early hyper threading problem? There was false sharing between the hyperhtreads. The workaround did improve performance by quite a bit. IIRC, my older appcore project had this workaround incorporated into it logic. I wrote that sucker back in very early 2000's. Humm... I will try to find the exact line. > It doesn't matter if the "conflicting" accesses come from either > thread of from one thread with that. False sharing is only pos- > sible with two cores or more.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-26 23:35 +0000 |
| Message-ID | <20231226152712.582@kylheku.com> |
| In reply to | #118134 |
On 2023-12-26, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: > On 12/26/2023 1:27 AM, Bonita Montero wrote: >> Am 26.12.2023 um 06:39 schrieb Chris M. Thomasson: >> >>> Remember when Intel first started hyperthreading and god damn threads >>> could false share with each other (on the stacks!) the low and high 64 >>> byte parts of the 128 byte cache lines? A workaround was to >>> artificially offset the threads stacks via alloca. >> >> If you have one core and two threads there's no false sharing. > > So, are you familiar with Intel's early hyper threading problem? There > was false sharing between the hyperhtreads. The workaround did improve > performance by quite a bit. IIRC, my older appcore project had this > workaround incorporated into it logic. I wrote that sucker back in very > early 2000's. Humm... I will try to find the exact line. Could you be both right? The performance problem was real, but maybe it wasn't "false sharing"? The hyper-thread are the same core; they share the same caches. Might you be describing a cache collision rather than false sharing? A single processor can trigger degenerate cache uses (at any level of a cache hierarchy). For instance, if pages of virtual memory are accessed in certain patterns, they can trash the same TLB entry. Was it perhaps the case that these thread stacks were allocated at such a stride, that their addresses clashed on the same cache line set? That could be a problem even on one processor, but it's obvious that hyperthreading could exacerbate it because switches between hyperthreads happen on a fine granularity. They don't get to run a full scheduler-driven time quantum. A low-level processor event like a pipeline stall (or other resource issue) can drive a hyper thread switch. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-26 15:37 -0800 |
| Message-ID | <umfo3c$3l1oh$1@dont-email.me> |
| In reply to | #118135 |
On 12/26/2023 3:35 PM, Kaz Kylheku wrote: > On 2023-12-26, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >> On 12/26/2023 1:27 AM, Bonita Montero wrote: >>> Am 26.12.2023 um 06:39 schrieb Chris M. Thomasson: >>> >>>> Remember when Intel first started hyperthreading and god damn threads >>>> could false share with each other (on the stacks!) the low and high 64 >>>> byte parts of the 128 byte cache lines? A workaround was to >>>> artificially offset the threads stacks via alloca. >>> >>> If you have one core and two threads there's no false sharing. >> >> So, are you familiar with Intel's early hyper threading problem? There >> was false sharing between the hyperhtreads. The workaround did improve >> performance by quite a bit. IIRC, my older appcore project had this >> workaround incorporated into it logic. I wrote that sucker back in very >> early 2000's. Humm... I will try to find the exact line. > > Could you be both right? The performance problem was real, but maybe > it wasn't "false sharing"? The hyper-thread are the same core; they > share the same caches. > > Might you be describing a cache collision rather than false sharing? Iirc, when I read the docs from Intel, it was the low 64 bytes being falsely shared with the high 64 bytes of a 128 byte l2 cache line? > > A single processor can trigger degenerate cache uses (at any level > of a cache hierarchy). For instance, if pages of virtual memory > are accessed in certain patterns, they can trash the same TLB entry. > > Was it perhaps the case that these thread stacks were allocated at such > a stride, that their addresses clashed on the same cache line set? > > That could be a problem even on one processor, but it's obvious that > hyperthreading could exacerbate it because switches between hyperthreads > happen on a fine granularity. They don't get to run a full > scheduler-driven time quantum. A low-level processor event like a > pipeline stall (or other resource issue) can drive a hyper thread > switch. >
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-26 21:59 -0800 |
| Message-ID | <umgego$3r29p$1@dont-email.me> |
| In reply to | #118136 |
On 12/26/2023 3:37 PM, Chris M. Thomasson wrote: > On 12/26/2023 3:35 PM, Kaz Kylheku wrote: >> On 2023-12-26, Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote: >>> On 12/26/2023 1:27 AM, Bonita Montero wrote: >>>> Am 26.12.2023 um 06:39 schrieb Chris M. Thomasson: >>>> >>>>> Remember when Intel first started hyperthreading and god damn threads >>>>> could false share with each other (on the stacks!) the low and high 64 >>>>> byte parts of the 128 byte cache lines? A workaround was to >>>>> artificially offset the threads stacks via alloca. >>>> >>>> If you have one core and two threads there's no false sharing. >>> >>> So, are you familiar with Intel's early hyper threading problem? There >>> was false sharing between the hyperhtreads. The workaround did improve >>> performance by quite a bit. IIRC, my older appcore project had this >>> workaround incorporated into it logic. I wrote that sucker back in very >>> early 2000's. Humm... I will try to find the exact line. >> >> Could you be both right? The performance problem was real, but maybe >> it wasn't "false sharing"? The hyper-thread are the same core; they >> share the same caches. >> >> Might you be describing a cache collision rather than false sharing? > > Iirc, when I read the docs from Intel, it was the low 64 bytes being > falsely shared with the high 64 bytes of a 128 byte l2 cache line? Something about false interference between threads that should not even be interacting with one another to begin with. It was a problem. The fix was based on alloca, so that is something to ponder on. > > > >> >> A single processor can trigger degenerate cache uses (at any level >> of a cache hierarchy). For instance, if pages of virtual memory >> are accessed in certain patterns, they can trash the same TLB entry. >> >> Was it perhaps the case that these thread stacks were allocated at such >> a stride, that their addresses clashed on the same cache line set? >> >> That could be a problem even on one processor, but it's obvious that >> hyperthreading could exacerbate it because switches between hyperthreads >> happen on a fine granularity. They don't get to run a full >> scheduler-driven time quantum. A low-level processor event like a >> pipeline stall (or other resource issue) can drive a hyper thread >> switch. >> >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-27 10:23 +0100 |
| Message-ID | <umgqe5$3sc4h$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118138 |
Am 27.12.2023 um 06:59 schrieb Chris M. Thomasson: > Something about false interference between threads that should not even > be interacting with one another to begin with. It was a problem. The fix > was based on alloca, so that is something to ponder on.; Like with any SMT-core there could be cache-thrashing between the cores. The L1 data cache was only 8kB, maybe only two was associative that could be thrashing between the cores. But I've no clue what this would have to to with alloca().
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2023-12-27 20:49 +0000 |
| Message-ID | <20231227124453.126@kylheku.com> |
| In reply to | #118139 |
On 2023-12-27, Bonita Montero <Bonita.Montero@gmail.com> wrote: > Am 27.12.2023 um 06:59 schrieb Chris M. Thomasson: > >> Something about false interference between threads that should not even >> be interacting with one another to begin with. It was a problem. The fix >> was based on alloca, so that is something to ponder on.; > > Like with any SMT-core there could be cache-thrashing between the > cores. The L1 data cache was only 8kB, maybe only two was associative > that could be thrashing between the cores. But I've no clue what this > would have to to with alloca(). Say you have thread stacks that are offset by some power of two amount, like a megabyte. Stack addresses at the same depth (like the local variables of threads executing the same function) are likely to collide on the same cache set (at different levels of the caching hierachy: L1, L2, translation caches). With alloca, since it moves the stack pointer, we can carve variable amounts of stack space to randomize the stack offsets (before calling the work functions). In different threads, we use differently-sized alloca allocations. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-28 12:00 +0100 |
| Message-ID | <umjkg8$bqmr$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118140 |
Am 27.12.2023 um 21:49 schrieb Kaz Kylheku: > Say you have thread stacks that are offset by some power of two amount, > like a megabyte. Stack addresses at the same depth (like the local > variables of threads executing the same function) are likely to collide > on the same cache set (at different levels of the caching hierachy: L1, > L2, translation caches). >> With alloca, since it moves the stack pointer, we can carve variable > amounts of stack space to randomize the stack offsets (before calling > the work functions). In different threads, we use differently-sized > alloca allocations. That's not sth. alloca() could alleviate. The startup-code inside the userspace-part of the thread should randomize the starting address of the stack within the size of a set. Most resources on the net say that the Pentium 4's L1 data cache asso- ciativity is eight, so there's not much chance of aliasing inside the L1D cache.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2023-12-28 15:38 -0800 |
| Message-ID | <uml0sp$i3j7$1@dont-email.me> |
| In reply to | #118141 |
On 12/28/2023 3:00 AM, Bonita Montero wrote: > Am 27.12.2023 um 21:49 schrieb Kaz Kylheku: > >> Say you have thread stacks that are offset by some power of two amount, >> like a megabyte. Stack addresses at the same depth (like the local >> variables of threads executing the same function) are likely to collide >> on the same cache set (at different levels of the caching hierachy: L1, >> L2, translation caches). > >> With alloca, since it moves the stack pointer, we can carve variable >> amounts of stack space to randomize the stack offsets (before calling >> the work functions). In different threads, we use differently-sized >> alloca allocations. > > That's not sth. alloca() could alleviate. The startup-code inside the > userspace-part of the thread should randomize the starting address of > the stack within the size of a set. > Most resources on the net say that the Pentium 4's L1 data cache asso- > ciativity is eight, so there's not much chance of aliasing inside the > L1D cache. > The use of alloca to try to get around the problem in their (Intel's) early hyperthreaded processors was real, and actually helped. It was in the Intel docs.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-12-29 04:17 +0100 |
| Message-ID | <umldni$n9ob$1@raubtier-asyl.eternal-september.org> |
| In reply to | #118142 |
Am 29.12.2023 um 00:38 schrieb Chris M. Thomasson: > The use of alloca to try to get around the problem in their (Intel's) > early hyperthreaded processors was real, and actually helped. It was in > the Intel docs. I don't believe it.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web