Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #117702 > unrolled thread
| Started by | jgd@cix.co.uk (John Dallman) |
|---|---|
| First post | 2026-08-31 17:35 +0100 |
| Last post | 2026-09-07 17:15 -0700 |
| Articles | 20 on this page of 475 — 30 participants |
Back to article view | Back to comp.arch
Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-08-31 17:35 +0100
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:35 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:48 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-08-31 17:43 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-08-31 22:20 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:10 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 18:01 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 11:55 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 19:58 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 17:07 -0700
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:28 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-08 13:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:19 +0000
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-09 18:21 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 18:41 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:42 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 21:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:49 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:28 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:57 +0000
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-23 22:08 -0400
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:24 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-02 01:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:44 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 07:45 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 22:32 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 00:12 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 05:24 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:05 +0000
Re: 370 address sizes, Styles of addressing Andy Valencia <vandys@vsta.org> - 2026-09-01 10:07 -0700
Re: 370 address sizes, Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-01 21:17 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-02 18:59 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 01:50 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 16:30 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:50 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:25 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:53 +0000
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:36 +0000
Re: 370 address sizes, Styles of addressing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 08:46 -0700
Re: 370 address sizes, Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-16 17:21 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 10:58 -0700
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 10:00 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-17 20:37 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:15 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-16 18:59 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 19:16 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:19 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 12:24 -0700
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:20 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:12 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:26 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 18:27 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 20:29 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 18:03 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 02:46 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-05 04:26 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 14:40 +0000
Re: 370 address sizes, Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-09-03 20:53 +0100
Re: 370 address sizes, Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-03 15:48 +0000
Re: 370 address sizes, Styles of addressing David Schultz <david.schultz@earthlink.net> - 2026-09-03 12:07 -0500
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:33 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:23 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 16:44 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:32 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 14:43 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:32 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 21:08 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-04 01:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-05 01:08 +0000
Re: Styles of addressing mas@a4.home - 2026-09-06 03:56 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-06 13:51 +0000
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-10 04:11 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:59 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 15:16 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 16:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:55 +0000
Re: Styles of addressing Robert Finch <robfi680@gmail.com> - 2026-09-10 21:43 -0400
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-13 17:50 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 00:42 +0000
CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:02 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 18:58 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 19:01 +0000
Re: CHERI Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:45 +0200
Re: CHERI Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-11 16:49 -0400
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:00 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:50 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 18:14 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 21:59 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 22:34 +0000
Data-independent timing (was: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:22 +0000
Re: Data-independent timing (was: CHERI Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-14 10:04 -0700
Re: Data-independent timing (was: CHERI scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:08 +0000
Re: Data-independent timing (was: CHERI anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 21:35 +0000
Re: CHERI (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 11:31 +0100
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 16:42 +0000
Re: CHERI (was: Styles of addressing) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-11 07:01 +0000
Re: CHERI (was: Styles of addressing) kegs@provalid.com (Kent Dickey) - 2026-09-13 17:21 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 18:00 +0000
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:35 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 10:44 -0400
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 14:56 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 12:58 -0400
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-06 12:04 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:59 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 04:29 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 10:40 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:25 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 23:10 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 21:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 05:30 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-08 11:20 +0200
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 12:23 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:47 +0000
Re: Styles of addressing Josh Vanderhoof <x@y.z> - 2026-09-07 18:22 -0400
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-07 13:28 -0400
Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:33 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 15:48 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 20:05 +0000
Re: Addressing Shared Stuff Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 12:05 -0400
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-16 23:11 +0100
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:26 +0000
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 09:32 +0000
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-17 13:32 +0100
Re: Addressing Shared Stuff Michael S <already5chosen@yahoo.com> - 2026-09-18 01:08 +0300
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 06:10 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 16:06 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 17:26 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:40 +0000
Re: Addressing Shared Stuff Andy Valencia <vandys@vsta.org> - 2026-09-14 12:52 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 20:25 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:02 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:09 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-07 06:17 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:46 +0000
Re: Styles of addressing Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-06 20:21 +0300
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-08 15:08 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 20:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 00:35 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:19 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-09 10:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-10 06:16 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:22 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:42 +0200
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:32 +0000
Re: Styles of addressing George Neuner <gneuner2@comcast.net> - 2026-09-10 17:02 -0400
Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:33 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:55 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:54 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-11 23:19 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 22:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:30 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:23 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:18 +0200
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:09 +0000
Re: Optimization by programmers (was: Styles of addressing) George Neuner <gneuner2@comcast.net> - 2026-09-11 23:25 -0400
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:38 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:09 +0000
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 09:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:24 +0200
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:34 -0700
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:15 +0000
Re: Optimization by programmers (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 19:13 +0100
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 18:14 +0000
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-13 03:28 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 14:27 +0000
Re: Optimization by programmers (was: Styles of addressing) John Levine <johnl@taugh.com> - 2026-09-13 14:58 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 16:09 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:38 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:34 +0000
Re: Optimization by programmers (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 14:43 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 15:44 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 18:01 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 13:14 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 16:47 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:38 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 21:25 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-21 22:10 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 16:38 -0400
Re: Optimization by programmers David LaRue <huey.dll@tampabay.rr.com> - 2026-09-19 06:01 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 06:25 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 02:56 -0400
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-09-20 20:12 +0000
Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 06:55 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 17:04 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:39 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-23 18:34 +0000
Re: Microarchitectural effects on performance Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-23 13:53 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:48 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 17:17 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 20:06 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 23:48 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 05:25 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-22 14:13 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-26 07:44 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-22 14:48 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 19:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 05:19 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 08:29 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:40 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 06:45 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-22 14:32 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-22 15:21 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:23 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-23 14:01 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 16:52 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 08:01 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:38 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 07:54 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 18:24 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 11:20 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 21:24 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 04:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-02 10:05 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 22:04 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 13:13 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-24 11:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-24 16:35 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 07:47 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 07:59 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-24 09:29 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-25 07:27 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 17:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 11:51 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-25 11:16 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 19:00 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 18:12 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-26 10:25 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 13:42 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 18:18 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 18:04 +0200
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 19:43 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 10:55 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-27 22:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-28 02:59 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-28 14:43 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:14 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:36 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-05 16:48 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-06 23:16 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 13:28 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 16:43 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 19:57 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:31 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 21:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-11 08:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-11 18:14 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-11 20:56 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 07:47 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-12 11:25 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 16:20 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-12 17:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 21:05 +0200
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 12:03 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 10:27 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:00 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:02 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:50 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-14 23:39 +0200
Re: Optimization by programmers Andy Valencia <vandys@vsta.org> - 2026-10-13 09:09 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 16:31 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-13 18:12 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:02 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-13 19:50 +0200
Comment delimiters (was: Optimization by programmers) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-13 23:24 -0400
Re: Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-14 09:56 +0200
Re: Comment delimiters (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-14 12:14 -0400
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-14 18:07 +0000
Re: Comment delimiters (was: Optimization by programmers) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-14 18:50 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-14 15:45 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-15 06:17 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 06:35 +0000
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:10 +0000
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-16 18:55 +0000
Re: Comment delimiters George Neuner <gneuner2@comcast.net> - 2026-10-16 18:57 -0400
Re: Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 04:01 +0000
Re: Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-15 15:42 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-16 12:46 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:56 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:56 +0000
Re: FORTRAN, was Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-17 11:09 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-17 14:58 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-18 10:55 -0400
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-18 17:56 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-19 18:09 +0000
Re: more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-20 03:50 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-20 20:53 +0100
Re: more Fortran, Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-20 20:15 +0000
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-20 20:44 +0000
Re: more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-20 22:49 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-21 23:06 +0100
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-22 00:02 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-22 23:43 +0100
Re: more Fortran, Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-23 00:27 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-23 03:46 +0100
Re: more Fortran, Comment delimiters Michael S <already5chosen@yahoo.com> - 2026-10-23 11:21 +0300
Re: more Fortran, Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-23 12:49 +0200
Re: Algol, was more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-21 03:28 +0000
Re: Algol, was more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-21 14:10 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:11 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:38 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 20:35 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:49 +0000
Re: FORTRAN, was Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-17 17:16 +0000
Re: FORTRAN, was Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-18 02:03 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-17 08:51 +0000
Re: Comment delimiters Robert Finch <robfi680@gmail.com> - 2026-10-18 22:54 -0400
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:39 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:42 +0000
Re: Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:43 +0000
Re: Comment delimiters (was: Optimization by programmers) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-14 22:43 +0000
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-15 18:15 +0000
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-10-12 16:12 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:40 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:21 +0000
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-12 19:54 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:10 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:37 +0000
Re: smashing constants, sort of like Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-13 00:35 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-13 18:40 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:47 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:37 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:07 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:35 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 02:03 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 22:25 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 20:05 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 23:25 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:36 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:05 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-09 16:36 +0200
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 16:49 -0400
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 22:13 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-08 05:46 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-08 12:05 -0400
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:55 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-28 19:58 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 15:44 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:57 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-30 17:50 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:47 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-30 18:03 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-30 17:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 06:58 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-02 20:38 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 21:23 -0700
Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 11:12 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:45 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 08:29 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 18:29 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-10 14:18 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 17:31 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 15:40 +0000
Re: Rust Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-11 14:26 -0400
Re: Rust cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:14 +0000
Re: Rust Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 21:15 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:13 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-10 22:28 +0300
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 09:27 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-11 22:43 +0300
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 05:01 -0700
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 15:21 +0000
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-07 05:41 -0700
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 14:23 +0000
Re: Rust (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-06 21:18 -0400
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 22:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 14:25 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 21:08 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 01:49 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 13:05 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:34 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 12:42 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 10:54 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 17:39 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 21:23 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-29 16:53 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-27 11:46 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-27 14:42 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 06:12 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-28 07:57 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 08:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 11:06 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 14:32 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 16:40 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 01:58 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-29 10:16 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 05:31 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 19:52 +0000
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 13:52 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 11:06 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-25 05:43 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:49 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:45 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-25 05:39 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:36 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:45 +0000
Re: Optimization by programmers aph@littlepinkcloud.invalid - 2026-10-04 08:15 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 12:15 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 14:16 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 16:36 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 17:46 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 20:04 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-06 02:17 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-06 10:05 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-19 12:06 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 15:56 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 10:46 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 14:24 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 11:52 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:09 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-21 05:27 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 12:13 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:35 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 16:43 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 20:23 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 11:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-20 07:31 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 20:01 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 20:52 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 13:17 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-22 16:50 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 05:28 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 04:38 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 13:55 +0000
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-05 22:54 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 06:35 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 02:53 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 14:55 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 15:16 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 06:15 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-24 17:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-26 09:18 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 19:57 +0200
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:31 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-14 16:58 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:45 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:53 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 17:21 +0200
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-09-15 16:00 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 19:40 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 15:58 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-11 10:15 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:54 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 10:54 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 15:56 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 21:46 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 12:07 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 20:04 +0000
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:15 +0000
Re: PDP-10 Styles of addressing Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 13:55 -0300
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 17:32 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:42 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-02 11:19 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 20:39 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-02 21:09 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 22:01 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:34 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 01:37 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:25 +0200
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 08:13 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 08:43 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 05:41 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:16 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-12 02:29 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 07:49 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-11 23:30 -0700
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:23 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-12 18:34 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 17:15 -0700
Page 22 of 24 — ← Prev page 1 … 20 21 [22] 23 24 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-21 20:23 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260921202316.000051c8@yahoo.com> |
| In reply to | #118110 |
On Sun, 20 Sep 2026 16:43:54 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Michael S <already5chosen@yahoo.com> writes: > >It seems to me, the most heavy impact on Zen3 is when such merged > >SIMD store is followed by GPR load to the same location within a > >dozen or so of CPU cycles. > > This is a case I measured in > <https://www.complang.tuwien.ac.at/anton/stwlf/>. Look for the > wl>ws=_=>nl>ns line. In this case, on Zen3 merging (-O3) is faster > than not merging (-O). > > But I see slowdowns from merging (-O3) in other cases where the > partial store-to-load overlap does not occur, e.g., in the "wl>ws=>wl > (recurrence), nl>ns (no recurrence)" case (and that's pretty > widespread among microarchitectures), so there is probably another > microarchitectural pitfall beyond the partal store-to-load forwarding. > > - anton The truth is that I don't know exact conditions. Probably can dig test cases out of old projects if there is a real interest from gcc maintainers. One example where I had seen it was emulation of binary128 floating point, either fmul or fadd, I can't recollect which of the two. Although the whole enterprise with my failed attempt to give away to gcc much faster binary128 arithmetic was rather depressing so I'd prefer to find example from another field, but right now can not recollect anything else.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-20 11:49 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep20.134914@mips.complang.tuwien.ac.at> |
| In reply to | #118100 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> Thomas Koenig <tkoenig@netcologne.de> writes: >>>Paul Clayton <paaronclayton@gmail.com> schrieb: >>>Two points: A compiler is restricted by the transformations >>>it can do by the language specification. For example, loop >>>interchanges with floating point calculation can give different >>>results. >> >> Interestingly, this is where gcc maintainers do the right thing and >> people who want to risk program breakage must use an extra flag >> (-ffast-math) to get "optimizations" (such as FP operation >> reassociation) that may change the results. >> >>>High-level transformation would transform Anton's beloved >>>bubblesort benchmark into insertion sort, at least. >> >> This bubble-sort benchmark comes from John Hennessey's collection of >> integer benchmarks, and Marty Fraeman has translated several of these >> benchmarks into Forth. This is the reason why I like to use it for >> comparing the performance of Forth systems to C compilers. > >Bubblesort is the worst of non-joke sorting algorithms, see >the quote from Numerical Recipes... So what? >> Recognizing this bubble-sort and using a more efficient sort (e.g., >> insertion sort for small instances, quicksort for larger ones) would >> be a real optimization; it would ruin the comparability with the Forth >> translation (as long as we do not put this kind of effort into Forth >> compilers), but that's life. But for now gcc autovectorizes it in a >> way that produces a significant slowdown; clang avoids this pitfall. > >All such choices are the result of heuristics. Bubble sort has a >very special memory access pattern. A straightforward patch would >very likely pessimize a lot of existing code which profits from >auto-vectorization. I have no doubt that the existing heuristics >can be improved. Oh really? Loading two adjacent memory locations in a way that the compiler can see and (if the maintainer is sufficiently clueless) merge after storing to one of these locations, with some optimization barrier in between (control flow in the case of bubble-sort) is very special? How come it also occurs in Gforth? >> Note that this auto-vectorization of gcc does not just slow down >> bubble-sort, but also gforth: when you load two adjacent stack items >> in one VM instruction, gcc -O3 by default wants to auto-vectorize >> these accesses, and given that one or both of them usually have been >> written recently, this would result in a slowdown. What's worse, gcc >> seems to think that a lot of values are alive that are actually dead, >> and generates dozens or hundreds of copying instructions into the code >> of each VM instruction, increasing the slowdown even more. For that >> reason, we have disabled tree-slp-vectorization when building Gforth. > >There is no stopping you from developing a patch (or having >it developed by a student as part of a thesis - can you act as >supervisor for master's or bachelor's theses?) and then submitting >it to gcc. Sure, but nobody is paying me or the student to do it, either. So I leave it to those people who are paid to do it. Also, I don't think that flipping the default for tree-slp-vectorization off is a worthwhile thesis topic. Admittedly, there may be cases where tree-slp-vectorization would vectorize even if the vectorization for loads is turned off, but I expect it to be rare. >But if you do so, you should make sure that it is does >not slow down normal programs (as measured by SPEC). The parenthetical remark is revealing. While SPEC CPU may intend to be representative of a wide range of programs, it's still just a bunch of programs with a bunch of performance-critical hot spots (typically inner loops), and if these happen to avoid a performance pitfall like store-to-wide-load forwarding, it is doubtful that they are representative in this respect. >Regarding clang: There are numerous cases where gcc's more >aggressive auto-vectorization generates a lot of profit vs. clang. >These are cases that would very probably suffer when heuristics >are not very carefully chosen. My experiments with auto-vectorization over the last year with both gcc and clang contradict your claim that gcc is more aggressive in auto-vectorization in general. E.g., I tested when either compilers would stop auto-vectorizing loops due to potential aliases, and I have not found a limit for clang, while I have for gcc (I stopped when I ran out of registers for the arrays); i.e., clang is more aggressive here, at the cost of needing more checking for overlapping arrays before entering the loop. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-20 07:31 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86a4pct2oj.fsf@linuxsc.com> |
| In reply to | #118100 |
Thomas Koenig <tkoenig@netcologne.de> writes:
> Bubblesort is the worst of non-joke sorting algorithms, see
> the quote from Numerical Recipes...
For people who don't like bubble sort, or for inclusion in a set
of benchmarks, I suggest the following recently discovered
sorting algorithm (written in C-ish pseudocode):
void
baffle_sort( unsigned n, int *elements ){
for( unsigned i = 0; i < n; i++ ){
for( unsigned j = 0; j < n; j++ ){
if( elements[i] < elements[j] ){
/* exchange elements[i] and elements[j] */
}
}
}
}
(Disclaimer: not original.)
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-22 20:01 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118ufqa$131ts$2@dont-email.me> |
| In reply to | #118108 |
Tim Rentsch wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Bubblesort is the worst of non-joke sorting algorithms, see
>> the quote from Numerical Recipes...
>
> For people who don't like bubble sort, or for inclusion in a set
> of benchmarks, I suggest the following recently discovered
> sorting algorithm (written in C-ish pseudocode):
>
> void
> baffle_sort( unsigned n, int *elements ){
> for( unsigned i = 0; i < n; i++ ){
> for( unsigned j = 0; j < n; j++ ){
> if( elements[i] < elements[j] ){
> /* exchange elements[i] and elements[j] */
> }
> }
> }
> }
>
> (Disclaimer: not original.)
Did you watch one of my favorite Youtube channels?
:-)
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-22 20:52 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <iUBsS.67508$k62.22375@fx14.iad> |
| In reply to | #118129 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
>Tim Rentsch wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>> the quote from Numerical Recipes...
>>
>> For people who don't like bubble sort, or for inclusion in a set
>> of benchmarks, I suggest the following recently discovered
>> sorting algorithm (written in C-ish pseudocode):
>>
>> void
>> baffle_sort( unsigned n, int *elements ){
>> for( unsigned i = 0; i < n; i++ ){
>> for( unsigned j = 0; j < n; j++ ){
>> if( elements[i] < elements[j] ){
>> /* exchange elements[i] and elements[j] */
>> }
>> }
>> }
>> }
>>
>> (Disclaimer: not original.)
>
>Did you watch one of my favorite Youtube channels?
>:-)
As the google AI sez:
Complexity Matrix
Metric Complexity Description
Worst-Case Time O(n²) Always runs exactly n × n iterations.
Best-Case Time O(n²) Unlike optimized Bubble Sort, it has no early exit and runs fully even if pre-sorted.
Space Complexity O(1) Sorts in-place with a single temporary variable.
AI>Are you analyzing this specific function for a computer science
assignment / code review, or would you like me to help you rewrite
it into a working standard algorithm like Bubble Sort or Quick Sort?
me>If a student can't rewrite it themselves, they shouldn't be programming.
AI>That is a fair and candid perspective. Rewriting or fixing this specific
function is a foundational exercise in control flow, loops, and basic logic. If someone
cannot spot why a double-nested loop from 0 to n breaks standard sorting
conventions - or how to implement a basic three-line variable swap - they
will struggle immensely with more complex programming concepts.
AI>It highlights the difference between memorizing syntax and truly understanding
code execution.
AI>Are you grading student submissions that included this specific code, or are you
analyzing a textbook/exam problem designed to trip them up?
me>I saw the code snippet in comp.arch
AI>Ah, comp.arch - that explains it perfectly. USENET groups like comp.arch and comp.lang.c
are notorious for regulars posting bizarre, intentionally "baffling" code fragments to
spark academic debates, analyze compiler optimization side-effects, or illustrate
architectural edge cases.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-23 13:17 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1190jh9$1odpi$1@dont-email.me> |
| In reply to | #118134 |
Scott Lurndal <scott@slp53.sl.home> schrieb: > AI>Ah, comp.arch - that explains it perfectly. USENET groups like comp.arch and comp.lang.c > are notorious for regulars posting bizarre, intentionally "baffling" code fragments to > spark academic debates, analyze compiler optimization side-effects, or illustrate > architectural edge cases. ROTFLBTC :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-22 16:50 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <865wzwu9qj.fsf@linuxsc.com> |
| In reply to | #118129 |
Terje Mathisen <terje.mathisen@tmsw.no> writes:
> Tim Rentsch wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>> the quote from Numerical Recipes...
>>
>> For people who don't like bubble sort, or for inclusion in a set
>> of benchmarks, I suggest the following recently discovered
>> sorting algorithm (written in C-ish pseudocode):
>>
>> void
>> baffle_sort( unsigned n, int *elements ){
>> for( unsigned i = 0; i < n; i++ ){
>> for( unsigned j = 0; j < n; j++ ){
>> if( elements[i] < elements[j] ){
>> /* exchange elements[i] and elements[j] */
>> }
>> }
>> }
>> }
>>
>> (Disclaimer: not original.)
>
> Did you watch one of my favorite Youtube channels?
Certainly there is a chance that I did. I found out about
this sorting algorithm from a YouTube video.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-03 05:28 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119q3q8$36790$2@paganini.bofh.team> |
| In reply to | #118108 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>> Bubblesort is the worst of non-joke sorting algorithms, see
>> the quote from Numerical Recipes...
>
> For people who don't like bubble sort, or for inclusion in a set
> of benchmarks, I suggest the following recently discovered
> sorting algorithm (written in C-ish pseudocode):
>
> void
> baffle_sort( unsigned n, int *elements ){
> for( unsigned i = 0; i < n; i++ ){
> for( unsigned j = 0; j < n; j++ ){
> if( elements[i] < elements[j] ){
> /* exchange elements[i] and elements[j] */
> }
> }
> }
> }
>
> (Disclaimer: not original.)
AFAICS this is very old "sorting by choice" algortim, just written
in inefficient way (using swaps and keeping running max in the
array instead of using extra variable).
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-03 04:38 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <8633unnhed.fsf@linuxsc.com> |
| In reply to | #118416 |
antispam@fricas.org (Waldek Hebisch) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>> the quote from Numerical Recipes...
>>
>> For people who don't like bubble sort, or for inclusion in a set
>> of benchmarks, I suggest the following recently discovered
>> sorting algorithm (written in C-ish pseudocode):
>>
>> void
>> baffle_sort( unsigned n, int *elements ){
>> for( unsigned i = 0; i < n; i++ ){
>> for( unsigned j = 0; j < n; j++ ){
>> if( elements[i] < elements[j] ){
>> /* exchange elements[i] and elements[j] */
>> }
>> }
>> }
>> }
>>
>> (Disclaimer: not original.)
>
> AFAICS this is very old "sorting by choice" algortim,
I suggest you look again. It is not a selection sort.
> just written
> in inefficient way (using swaps and keeping running max in the
> array instead of using extra variable).
I am making no claim that this sort would be a good choice if
one wanted an efficient algorithm. Surely no one would choose
it on that basis. That's not what makes it interesting.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 13:55 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a0a7r$oau$1@reader2.panix.com> |
| In reply to | #118422 |
In article <8633unnhed.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>antispam@fricas.org (Waldek Hebisch) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>
>>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>>> the quote from Numerical Recipes...
>>>
>>> For people who don't like bubble sort, or for inclusion in a set
>>> of benchmarks, I suggest the following recently discovered
>>> sorting algorithm (written in C-ish pseudocode):
>>>
>>> void
>>> baffle_sort( unsigned n, int *elements ){
>>> for( unsigned i = 0; i < n; i++ ){
>>> for( unsigned j = 0; j < n; j++ ){
>>> if( elements[i] < elements[j] ){
>>> /* exchange elements[i] and elements[j] */
>>> }
>>> }
>>> }
>>> }
>>>
>>> (Disclaimer: not original.)
>>
>> AFAICS this is very old "sorting by choice" algortim,
>
>I suggest you look again. It is not a selection sort.
>
>> just written
>> in inefficient way (using swaps and keeping running max in the
>> array instead of using extra variable).
>
>I am making no claim that this sort would be a good choice if
>one wanted an efficient algorithm. Surely no one would choose
>it on that basis. That's not what makes it interesting.
This whole thread is probably better in something like
comp.programming.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-05 22:54 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a19rf$3u6ge$1@paganini.bofh.team> |
| In reply to | #118422 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>
>>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>>> the quote from Numerical Recipes...
>>>
>>> For people who don't like bubble sort, or for inclusion in a set
>>> of benchmarks, I suggest the following recently discovered
>>> sorting algorithm (written in C-ish pseudocode):
>>>
>>> void
>>> baffle_sort( unsigned n, int *elements ){
>>> for( unsigned i = 0; i < n; i++ ){
>>> for( unsigned j = 0; j < n; j++ ){
>>> if( elements[i] < elements[j] ){
>>> /* exchange elements[i] and elements[j] */
>>> }
>>> }
>>> }
>>> }
>>>
>>> (Disclaimer: not original.)
>>
>> AFAICS this is very old "sorting by choice" algortim,
>
> I suggest you look again. It is not a selection sort.
Yes, you are right. First pass seclecting maximal element is
like selection sort, the other passes work as insertion sort.
>> just written
>> in inefficient way (using swaps and keeping running max in the
>> array instead of using extra variable).
>
> I am making no claim that this sort would be a good choice if
> one wanted an efficient algorithm. Surely no one would choose
> it on that basis. That's not what makes it interesting.
Probably the most interestiong thing about it is that it actually
sorts. As a benchmork it could be useful to assess quality of
compiler removal of useless code. I suspect that currently no
compiler is able to remove useless half of this code, also
probably can not optimize sequence of swaps to array shift. But
those are not far from what is alreade done.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-06 06:35 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct6.083505@mips.complang.tuwien.ac.at> |
| In reply to | #118481 |
antispam@fricas.org (Waldek Hebisch) writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> antispam@fricas.org (Waldek Hebisch) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> void
>>>> baffle_sort( unsigned n, int *elements ){
>>>> for( unsigned i = 0; i < n; i++ ){
>>>> for( unsigned j = 0; j < n; j++ ){
>>>> if( elements[i] < elements[j] ){
>>>> /* exchange elements[i] and elements[j] */
>>>> }
>>>> }
>>>> }
>>>> }
...
>Probably the most interestiong thing about it is that it actually
>sorts. As a benchmork it could be useful to assess quality of
>compiler removal of useless code. I suspect that currently no
>compiler is able to remove useless half of this code, also
>probably can not optimize sequence of swaps to array shift. But
>those are not far from what is alreade done.
Given that gcc and clang do not optimize the sequence of swaps in the
bubble sort component of John Hennesseys stan.c benchmark collection
from the early 1980s into array rotation, I would not expect it to
happen for the above, especially given that elements[i] and
elements[j] can and regularly will alias. Ok, the compiler can infer
that no swap happens in this case, and split the inner loop into a
0..i-1 one and an i+1..n-1 one, but doing that is more involved than I
expect and have experienced from compiler optimizations for
"irrelevant" code.
For comparison, the inner loop of the bubble-sort benchmark in stan.c
is:
i=1;
while ( i<top ) {
if ( sortlist[i] > sortlist[i+1] ) {
j = sortlist[i];
sortlist[i] = sortlist[i+1];
sortlist[i+1] = j;
};
i=i+1;
};
I see fewer hurdles in optimizing that than the inner loop of
baffle_sort(), but it does not happen.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-06 02:53 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86a4orm9yh.fsf@linuxsc.com> |
| In reply to | #118481 |
antispam@fricas.org (Waldek Hebisch) writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> antispam@fricas.org (Waldek Hebisch) writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>
>>>>> Bubblesort is the worst of non-joke sorting algorithms, see
>>>>> the quote from Numerical Recipes...
>>>>
>>>> For people who don't like bubble sort, or for inclusion in a set
>>>> of benchmarks, I suggest the following recently discovered
>>>> sorting algorithm (written in C-ish pseudocode):
>>>>
>>>> void
>>>> baffle_sort( unsigned n, int *elements ){
>>>> for( unsigned i = 0; i < n; i++ ){
>>>> for( unsigned j = 0; j < n; j++ ){
>>>> if( elements[i] < elements[j] ){
>>>> /* exchange elements[i] and elements[j] */
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> (Disclaimer: not original.)
[...]
>> I am making no claim that this sort would be a good choice if
>> one wanted an efficient algorithm. Surely no one would choose
>> it on that basis. That's not what makes it interesting.
>
> Probably the most interestiong thing about it is that it actually
> sorts.
That it actually sorts is I think the most surprising thing.
What I found most interesting is how it sorts or why it sorts. It
took me a while to understand what makes it work. It is difficult,
for example, to write invariants for this code that can be used to
establish the conclusion that sorting actually takes place. A
better name than baffle_sort() might be least_transparent_sort().
But that would ruin the surprise. ;)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-10-06 14:55 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvfqyioea5.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118493 |
> What I found most interesting is how it sorts or why it sorts. It
> took me a while to understand what makes it work. It is difficult,
> for example, to write invariants for this code that can be used to
> establish the conclusion that sorting actually takes place.
Indeed, mostly because the first iteration (i=0) is completely different
from the other ones: the swaps that take place happen only when
i > j or i == 0
So only the first iteration of the outer loop really works on the whole
array. The subsequent ones do nothing once j > i.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-21 15:16 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep21.171615@mips.complang.tuwien.ac.at> |
| In reply to | #118100 |
Thomas Koenig <tkoenig@netcologne.de> writes:
>All such choices are the result of heuristics. Bubble sort has a
>very special memory access pattern.
Ok, what would a memory pattern look like that this vectorization was
designed for? The big slowdown comes from the fact that in the
reordering case the vectorized version performs a wide store, and in
the next iteration it performs a wide load that partially overlaps the
store. I buy it that the analysis will have trouble seeing that (not
that it's impossible in this case, but it requires effort).
>A straightforward patch would
>very likely pessimize a lot of existing code which profits from
>auto-vectorization.
How can we test this claim? What would such code look like that would
suffer from disabling the combining of loads that tree-slp-vectorize
performs?
I decided to test the claim by continuing to use bubble-sort, but
avoiding the stores and thus the big slowdown: Bubble-sort a
pre-sorted array. Apart from changing the array size, initializing
the array with pre-sorted values, changing the indentation and
condensing the code to one benchmark only (stan.c has a number of
benchmarks in one file, probably due to Pascal origins), the code is
unchanged; the original code already performs N iterations of the
outer loop (rather than doing an early-out on an already-sorted
array), so one does not need to change that aspect.
The inner loop is compiled by gcc-14.2 to:
novect (-O3 -fno-tree-slp-vectorize) vect (-O3)
70: mov (%rax),%ecx 90: movq (%rax),%xmm0
mov 0x4(%rax),%esi pshufd $0xe5,%xmm0,%xmm1
movd %xmm0,%esi
movd %xmm1,%ecx
cmp %esi,%ecx cmp %ecx,%esi
jle 7e jle ae #always taken
mov %esi,(%rax) pshufd $0xe1,%xmm0,%xmm0 #x
mov %ecx,0x4(%rax) movq %xmm0,(%rax) #x
7e: add $0x4,%rax ae: add $0x4,%rax
cmp %rax,%rdi cmp %rdi,%rax
jne 70 jne 90
In the presorted benchmark, the jle branch is always taken, and the
store instructions marked #x are never executed, so the
microarchitectural pitfall never occurs.
The novect code executes 7 instructions per iteration, the vect code
9, but maybe the vectorization manages to make the code execute faster
for some reason. Let's see (on a Xeon E-2388G (Rocket Lake):
cycles instructions
1,867,053,886 12,602,009,442 novect
3,603,774,972 16,202,621,392 vect
So the novect variant is twice as fast as the vect variant even
without the slowdown from the store-to-partially-overlapping loads.
If there is a speedup to be had from combining loads with
tree-slp-vectorize, it hides itself well.
The performance of the Rocket Lake for the novect variant is
remarkable. It manages 6.75 IPC on average, which is very close to
the speed of light for this microarchitecture, with 5 renamer slots,
with compare-and-branch macro-instructions occupying only one renamer
slot (so the speed of light for a loop with 5 non-branches and 2
branches is 7 IPC). Top-down microarchitectural analysis reports:
TopdownL1 # 2.7 % tma_backend_bound
# 1.6 % tma_bad_speculation
# -0.0 % tma_frontend_bound
# 95.7 % tma_retiring
The ideal is that 100% of the rename slots are consumed by retiring,
but the normal case is that many of the slots are lost due to the
other three reasons, and retiring numbers >50% are already pretty
good.
The Rocket Lake manages two taken branches per cycle here, while I had
thought it was only capable of doing one non-taken and one taken
branch per cycle.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-22 06:15 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118t6es$k2u5$1@dont-email.me> |
| In reply to | #118115 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>All such choices are the result of heuristics. Bubble sort has a >>very special memory access pattern. > > Ok, what would a memory pattern look like that this vectorization was > designed for? The big slowdown comes from the fact that in the > reordering case the vectorized version performs a wide store, and in > the next iteration it performs a wide load that partially overlaps the > store. I buy it that the analysis will have trouble seeing that (not > that it's impossible in this case, but it requires effort). > >>A straightforward patch would >>very likely pessimize a lot of existing code which profits from >>auto-vectorization. > > How can we test this claim? I do not believe that I have to explain the scientific method to you. As a first step, you would find an option that enables/disables what you don't like. -fstore-merging looks like a candidate, but there may be others. You can look at https://dl.acm.org/doi/10.1109/ASE56229.2023.00209 or https://link.springer.com/article/10.1007/s10515-024-00437-w if you want the full package. Then try this combination of options on other benchmarks as well as your pet one. I have my reservations about SPEC, but as you work at a university, you can get it for a discount. You can also use freely available benchmarks: Coremark, embench, Fortran Polyhedron - there are a lot. If there are benchmark which regress significantly with that set of options, you have your test case where it hurts. Like I wrote previously - you could have a bachelor or master student do this, it could be (part of a) nice thesis. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-24 17:05 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep24.190531@mips.complang.tuwien.ac.at> |
| In reply to | #118122 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >> Thomas Koenig <tkoenig@netcologne.de> writes: >>>A straightforward patch would >>>very likely pessimize a lot of existing code which profits from >>>auto-vectorization. >> >> How can we test this claim? > >I do not believe that I have to explain the scientific method >to you. > >As a first step, you would find an option that enables/disables >what you don't like. -fstore-merging looks like a >candidate, but there may be others. You can look at >https://dl.acm.org/doi/10.1109/ASE56229.2023.00209 or >https://link.springer.com/article/10.1007/s10515-024-00437-w >if you want the full package. > >Then try this combination of options on other benchmarks >as well as your pet one. I have my reservations about SPEC, >but as you work at a university, you can get it for a discount. >You can also use freely available benchmarks: Coremark, embench, >Fortran Polyhedron - there are a lot. > >If there are benchmark which regress significantly with that >set of options, you have your test case where it hurts. > >Like I wrote previously - you could have a bachelor or master >student do this, it could be (part of a) nice thesis. That's a lot of words to express that you have no evidence for your claim. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-26 09:18 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11982m1$avl4$1@dont-email.me> |
| In reply to | #118175 |
On 2026-09-24, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>> Thomas Koenig <tkoenig@netcologne.de> writes: >>>>A straightforward patch would >>>>very likely pessimize a lot of existing code which profits from >>>>auto-vectorization. >>> >>> How can we test this claim? >> >>I do not believe that I have to explain the scientific method >>to you. >> >>As a first step, you would find an option that enables/disables >>what you don't like. -fstore-merging looks like a >>candidate, but there may be others. You can look at >>https://dl.acm.org/doi/10.1109/ASE56229.2023.00209 or >>https://link.springer.com/article/10.1007/s10515-024-00437-w >>if you want the full package. >> >>Then try this combination of options on other benchmarks >>as well as your pet one. I have my reservations about SPEC, >>but as you work at a university, you can get it for a discount. >>You can also use freely available benchmarks: Coremark, embench, >>Fortran Polyhedron - there are a lot. >> >>If there are benchmark which regress significantly with that >>set of options, you have your test case where it hurts. >> >>Like I wrote previously - you could have a bachelor or master >>student do this, it could be (part of a) nice thesis. > > That's a lot of words to express that you have no evidence for your > claim. I was just trying to get you to do something useful. Wasted effort, I know, but I keep trying. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-22 19:57 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118ufhf$131ts$1@dont-email.me> |
| In reply to | #118097 |
Thomas Koenig wrote: > Paul Clayton <paaronclayton@gmail.com> schrieb: > >> I suspect algorithmic transformations are discouraged in >> compilers under the assumption that the software developer used >> appropriate algorithms as well as the compute cost to evaluate >> options. > > Two points: A compiler is restricted by the transformations > it can do by the language specification. For example, loop > interchanges with floating point calculation can give different > results. Unless directed otherwise, the compiler has to assume > that this is what the user wants and needs. > > An exception is something like Fortran's FORALL constuct, where > the loop ordering is not specified and the compiler can chose. > Intrinsic functions like MATMUL also have no restriction on what > they can do internally; they can (and often do) call a highly- > optimized BLAS routine. > >> Usage and hardware information might theoretically be >> made available, but I get the impression that most profiling >> for compiler use is about path frequency. > > Compilers tend to focus on lower-level stuff. For example, > there is a huge file of simplifying transformations for gcc at > https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/match.pd > > This now also contains reverse-engineered bithacks. For example, > the popcnt() method from Hacker's Delight are now recognized and > translated into an internal function, which is then expanded > into either an inlined function (much like the original) or > a machine instruction, if the target has one. clang recognizes both the bit per iteration and the n &= n-1 Hacker's method, bot turn into POPCNT on x86. Much more impressive (to me) was to see that same compiler (working as the Rust backend) also recognized at least two different naive implementations of a non-square bitmap transpose, converting it into a SIMD blob with no need for me to break out the SSE/AVX intrinsics! > > High-level transformation would transform Anton's beloved > bubblesort benchmark into insertion sort, at least. > > But if you're willing to take the risk of AI, you can of course > tell it "Find all O(N^2) algorithms in my code and replace them > with O(N log N) where possible". It will happily do something, > and the resulting code might even be correct after a few > iterations. "might" is important here... Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-14 16:31 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11890f6$1jr26$1@dont-email.me> |
| In reply to | #117981 |
John Savard wrote: > On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: >> George Neuner <gneuner2@comcast.net> writes: >>> On Thu, 10 Sep 2026 17:22:37 GMT, anton@mips.complang.tuwien.ac.at >>> (Anton Ertl) wrote: > >>>> However, I have seem many cases where people made a claim that >>>> compilers generate better code than programmers. > >>> "compilers generate better code than MOST programmers." > >>> The qualification is important. > >> The statements I have read did not make such a qualification, >> certainly not in capital letters. > >>> There is no doubt that a good >>> programmer can beat the compiler, > >> And especially this statement is usually not made. On the contrary, >> the perpetrator of such statements seem convinced of compiler >> supremacy. > > I have no doubt that a good programmer can beat the original FORTRAN > compiler for the IBM 704 computer, despite the fact that its > optimization was very nearly as good as that of most optimizing > compilers until at least the late 1970s. > > I would not, however, be willing to assert that one could easily find > human programmers who could beat an optimizing compiler... which had > the Itanium as its target. > > I don't believe that there are any other current architectures out > there which are as nightmarish to program in assembler as the Itanium, Huh??? I studied the Itanium architecture manuals and amused myself by writing asm kernels that took good advantage of the large register set, including the rotating ones. Not at all a nightmare! In fact, writing x87 asm by hand, trying to keep every working variable live on the 8-element stack, is significantly harder IMHO. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 22 of 24 — ← Prev page 1 … 20 21 [22] 23 24 Next page →
Back to top | Article view | comp.arch
csiph-web