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 10 of 24 — ← Prev page 1 … 8 9 [10] 11 12 … 24 Next page →
| From | David LaRue <huey.dll@tampabay.rr.com> |
|---|---|
| Date | 2026-09-19 06:01 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <XnsB4CC147A2B814hueydlltampabayrrcom@157.180.91.226> |
| In reply to | #118094 |
Stefan Monnier <monnier@iro.umontreal.ca> wrote in news:jwva4peqp52.fsf- monnier+comp.arch@gnu.org: > Paul Clayton [2026-09-16 13:14:22] wrote: >> 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. > > Also because compilers generally can't (or at least shouldn't) take the > chance of generating significantly slower code. > > The purpose of "language + compiler" is not to figure out magically how > to implement the most efficient code that solves the same problem, > instead it's to allow the programmer to write that most efficient > code conveniently. > > Of course, there is a lot of commercial interest in doing the magic > thing so as to save the work of understanding and rewriting the code to > improve performance (hence all the work on auto-parallelization), but > experience shows that it's an extremely difficult problem. > > Luckily, a lot of that work on trying to do the magic thing can also be > used to solve the real problem: what the years of work on > compiler-optimization has brought (instead of magically speeding up old > code) is to improve the convenience to write efficient code. > > > === Stefan > Remember too, that some lower languages and especially older computers actually had code meant to take a certain amount of time. We depended on knowing time constraints. That knowledge isn't always honored by a well meaning compiler writer and can have disasterous results if the optimized for time code is put into place and not discovered in time. Even modern computers depend on knowing how the code will really run. Anyone who has had the joy of figuring out why tinkering with code or hardware suddenly had unextpected results can attest to. Knowing how to properly interface with hardware is one of the joys of low level programming. Everything mattered, even time, to that developer. David -- still enjoying peering inside things and fixing them
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-19 06:25 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep19.082513@mips.complang.tuwien.ac.at> |
| In reply to | #118094 |
Stefan Monnier <monnier@iro.umontreal.ca> writes: >Paul Clayton [2026-09-16 13:14:22] wrote: >Also because compilers generally can't (or at least shouldn't) take the >chance of generating significantly slower code. One would hope so, but: |In the case of the bubble-sort benchmark (c-manual/bubble-sort.c in |bench.zip), on a Rocket Lake (Xeon E-2388G) the auto-vectorization |leads to a slowdown by a factor of 5.7 of gcc-14.2 -O3 over gcc-14.2 |-O3 -fno-tree-vectorize, by a factor of 5.6 over clang-19.1 -O3 (where |clang does not vectorize anything in this benchmark), by a factor of |5.3 over gcc-14.2 -O, and by a factor of 2.1 over gcc-14.2 -O0. Read more about the reasons on <http://www.complang.tuwien.ac.at/anton/stwlf/>. >The purpose of "language + compiler" is not to figure out magically how >to implement the most efficient code that solves the same problem, >instead it's to allow the programmer to write that most efficient >code conveniently. I agree. >Of course, there is a lot of commercial interest in doing the magic >thing so as to save the work of understanding and rewriting the code to >improve performance (hence all the work on auto-parallelization), but >experience shows that it's an extremely difficult problem. Experience shows that it is an easy problem to get people to put money into your project by promising them that the compiler will magically solve it (and thus they can save on expensive programmer time); earlier successful ways to convert wishful thinking into money are the philosopher's stone, and a contemporary way is AI. In the case of optimizing compilers it helps that one can present showpieces where it works as promised. I guess the alchemists had similar tricks (maybe they sold chemical reactions as first steps to the desired end result), and we can see in daily news how the AI companies do it. >Luckily, a lot of that work on trying to do the magic thing can also be >used to solve the real problem: what the years of work on >compiler-optimization has brought (instead of magically speeding up old >code) is to improve the convenience to write efficient code. It depends. When the optimizer writers, in their mission to achieve good benchmark results, put the assumption in their optimizers that programs do not exercise undefined behaviour (except the cases that occur in the benchmarks, e.g., the SATD function in 464.h264ref) and "optimize" programs with that assumption. They tell programmers who are hit by this that their previously working programs are buggy and have always been broken, and that one must not write such code. This does not improve the convenience of writing efficient code, on the contrary: In Section 4.3 of <https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf> I estimate that Gforth would slow down by a factor >3 compared to Gforth 0.7.0 from a set of changes for avoiding undefined behaviour where I could make an estimate of the performance effects; we would have to introduce other changes as well, which would also affect performance negatively. And not just for Gforth, also for other programs, it has a chilling effect on programmer optimizations if the programmers always have to be on the lookout for undefined behaviour instead of concentrating on optimizing the program. But if optimizer writers strove to "improve the convenience to write efficient code" instead of just improving benchmark results, maybe such paradoxical effects can be avoided. - 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 | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-20 02:56 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvse34pgvh.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118096 |
Anton Ertl [2026-09-19 06:25:13] wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >>Paul Clayton [2026-09-16 13:14:22] wrote: >>Also because compilers generally can't (or at least shouldn't) take the >>chance of generating significantly slower code. > One would hope so, but: Indeed, in practice virtually all compiler "optimizations" are valid only statistically: in most cases they either have no measurable effect or they improve some characteristic, but there are almost always corner cases where they make things worse. The traditional "-O<N>" flags are a way to state how much you're willing to get worse performance in exchange for the opportunity to maybe get better performance. > Experience shows that it is an easy problem to get people to put money > into your project by promising them that the compiler will magically > solve it (and thus they can save on expensive programmer time); > earlier successful ways to convert wishful thinking into money are the > philosopher's stone, and a contemporary way is AI. In the case of > optimizing compilers it helps that one can present showpieces where it > works as promised. I guess the alchemists had similar tricks (maybe > they sold chemical reactions as first steps to the desired end > result), and we can see in daily news how the AI companies do it. +1 >>Luckily, a lot of that work on trying to do the magic thing can also be >>used to solve the real problem: what the years of work on >>compiler-optimization has brought (instead of magically speeding up old >>code) is to improve the convenience to write efficient code. > It depends. "Can be used" doesn't mean it's necessarily used that way, indeed. > But if optimizer writers strove to "improve the convenience to write > efficient code" instead of just improving benchmark results, maybe > such paradoxical effects can be avoided. In general it's hard to completely avoid paradoxical effects. But as for the problems you mention w.r.t UB, I think it's just the result of poor semantics, for which I guess we (language semanticists) are partly to blame: we have developed fairly good tools to design sane language specs in general, but not to specify anything vaguely related to "undefined behavior", so we end up with this bogus notion that "UB implies anything you want" (including "Minority Report" absurdities where we're allowed to do anything as soon as we know that UB *would* happen anyway). === Stefan
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-09-20 20:12 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118penq$241o$2@gal.iecc.com> |
| In reply to | #118109 |
According to Stefan Monnier <monnier@iro.umontreal.ca>: >Anton Ertl [2026-09-19 06:25:13] wrote: >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>>Paul Clayton [2026-09-16 13:14:22] wrote: >>>Also because compilers generally can't (or at least shouldn't) take the >>>chance of generating significantly slower code. >> One would hope so, but: > >Indeed, in practice virtually all compiler "optimizations" are valid >only statistically: in most cases they either have no measurable effect >or they improve some characteristic, but there are almost always corner >cases where they make things worse. There are plenty of optimizations that always make things better, e.g., removing dead code, or reusing values in registers. But these days those are so obvious we sometimes forget about them. I agree that the more sophisticated the optiomization, the more likely it is to have perverse cases. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-21 06:55 +0000 |
| Subject | Microarchitectural effects on performance (was: Optimization ...) |
| Message-ID | <2026Sep21.085556@mips.complang.tuwien.ac.at> |
| In reply to | #118111 |
John Levine <johnl@taugh.com> writes:
>According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>Indeed, in practice virtually all compiler "optimizations" are valid
>>only statistically: in most cases they either have no measurable effect
>>or they improve some characteristic, but there are almost always corner
>>cases where they make things worse.
>
>There are plenty of optimizations that always make things better, e.g.,
>removing dead code, or reusing values in registers.
For certain values of "better", such as code size. Unfortunately, for
optimizing execution time, there are microarchitectural effects in
play that can result in paradoxical effects even for code that pretty
much everybody woul consider better without information to the
contrary. E.g., on a DecStation I saw a 20% slowdown by removing a
piece of code that had become unnecessary earlier, in a benchmark that
actually did not exercise this code. My explanation for that was
I-cache conflicts.
Many of these effects (such as I-cache conflicts) are not directly
connected to the transformation at hand. Some may be fixable by
further transformations; e.g., if branch targets shortly before a
cache-line boundary are bad for performance, one can insert padding
before the branch target.
OTOH, the store-to-wide-load forwarding issue that I have discussed in
this thread is directly connected to the auto-vectorization of several
narrow loads into a wide load. So in this case the transformation has
direct connection to the microarchitectural pitfall.
>I agree that the more sophisticated the optiomization, the more likely it
>is to have perverse cases.
In the case of auto-vectorizing loads, I have seen the compiler
generate code that results in a significantly increased number of
executed instructions (but reduced executed loads); I wonder how that
code performs in those cases where the microarchitectural pitfall does
not strike; maybe I will measure it later. But the more serious issue
is the microarchitectural pitfall, which does not always strike, so
the people who enabled this transformation by default may be
blissfully unaware of it.
Microarchitectural pitfalls can be unrelated to the sophistication of
the compiler. E.g., I discuss [ertl24] a number of microarchitectural
pitfalls that many Forth systems fall into, not because of
sophistication, but because the Forth systems use techniques that
worked fine in the microprocessors of the 1970s and 1980s, and
actually still work fine on threaded-code systems on modern CPUs, but
fall into these pitfalls in native-code systems. Ok, in a way it
affects more sophisticated systems more, but not because of the
sophistication of their optimizations; systems with more sophisticated
optimizations see the same issues as less sophisticated ones, that are
still native-code systems.
@InProceedings{ertl24,
author = {M. Anton Ertl},
title = {How to Implement Words (Efficiently)},
crossref = {euroforth24},
pages = {43--52},
url = {http://www.euroforth.org/ef24/papers/ertl.pdf},
url-slides = {http://www.euroforth.org/ef24/papers/ertl-slides.pdf},
video = {https://www.youtube.com/watch?v=bAq4760h5ZQ},
OPTnote = {not refereed},
abstract = {The implementation of Forth words has to satisfy the
following requirements: 1) A word must be
represented by a single cell (for
\code{execute}). 2) A word may represent a
combination of code and data (for, e.g.,
\code{does>}). In addition, on some hardware,
keeping executed native code and (written) data
close together results in slowness and therefore
should be avoided; moreover, failing to pair up
calls with returns results in (slow) branch
mispredictions. The present work describes how
various Forth systems over the decades have
satisfied the requirements, and how many systems run
into performance pitfalls in various situations.
This paper also discusses how to avoid this
slowness, including in native-code systems.}
}
@Proceedings{euroforth24,
title = {40th EuroForth Conference},
booktitle = {40th EuroForth Conference},
year = {2024},
key = {EuroForth'24},
url = {http://www.euroforth.org/ef24/papers/proceedings.pdf}
}
- 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-21 17:04 +0000 |
| Subject | Re: Microarchitectural effects on performance (was: Optimization ...) |
| Message-ID | <1790010267-5857@newsgrouper.org> |
| In reply to | #118113 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:
> John Levine <johnl@taugh.com> writes:
-------------------
>
> OTOH, the store-to-wide-load forwarding issue that I have discussed in
> this thread is directly connected to the auto-vectorization of several
> narrow loads into a wide load. So in this case the transformation has
> direct connection to the microarchitectural pitfall.
I think we need to make a distinction between vectorization and
SIMDization. Vectors are like CRAY (and RISC-v) while SIMD is
most everyone else.
In modern machines LDs are well pipelined, often multi-lane; so,
when a compiler auto-SIMDs a gaggle of LDs into a LDSIMD, one
then needs a similar means to extract the gaggle from the SIMD.
This extract is less likely to have the same properties of the
LD pipeline.
> >I agree that the more sophisticated the optiomization, the more likely it
> >is to have perverse cases.
>
> In the case of auto-vectorizing loads, I have seen the compiler
> generate code that results in a significantly increased number of
> executed instructions (but reduced executed loads); I wonder how that
> code performs in those cases where the microarchitectural pitfall does
> not strike; maybe I will measure it later. But the more serious issue
> is the microarchitectural pitfall, which does not always strike, so
> the people who enabled this transformation by default may be
> blissfully unaware of it.
>
> Microarchitectural pitfalls can be unrelated to the sophistication of
> the compiler.
In 1992 I was working on a machine with a packet-cache organization
of instructions. The compiler we had was unrolling, loop inducing
and loop strength reducing generated code. This often-added instructions
into the loop body and the loop no longer fit in n packets (now n+1)
packets--resulting in a slowdown of n/(n+1). The fix was to turn those
kinds of optimizations back off. {{A packet was a trace with pre-routed
instructions}} SPECint gains about 10% on this µArchitecture by turning
those optimizations off.
> E.g., I discuss [ertl24] a number of microarchitectural
> pitfalls that many Forth systems fall into, not because of
> sophistication, but because the Forth systems use techniques that
> worked fine in the microprocessors of the 1970s and 1980s, and
> actually still work fine on threaded-code systems on modern CPUs, but
> fall into these pitfalls in native-code systems.
Is this related to the over aggressive branch predictors of modern ?
Either branches themselves or indirect calls.
Read the paper--yes a nasty wicket when the container containing
a return address is used for something other than a return. Safe-
Stack would prevent that use (RA is neither LD-able nor ST-able.)
> Ok, in a way it
> affects more sophisticated systems more, but not because of the
> sophistication of their optimizations; systems with more sophisticated
> optimizations see the same issues as less sophisticated ones, that are
> still native-code systems.
>
> @InProceedings{ertl24,
> author = {M. Anton Ertl},
> title = {How to Implement Words (Efficiently)},
> crossref = {euroforth24},
> pages = {43--52},
> url = {http://www.euroforth.org/ef24/papers/ertl.pdf},
> url-slides = {http://www.euroforth.org/ef24/papers/ertl-slides.pdf},
> video = {https://www.youtube.com/watch?v=bAq4760h5ZQ},
> OPTnote = {not refereed},
> abstract = {The implementation of Forth words has to satisfy the
> following requirements: 1) A word must be
> represented by a single cell (for
> \code{execute}). 2) A word may represent a
> combination of code and data (for, e.g.,
> \code{does>}). In addition, on some hardware,
> keeping executed native code and (written) data
> close together results in slowness and therefore
> should be avoided; moreover, failing to pair up
> calls with returns results in (slow) branch
> mispredictions. The present work describes how
> various Forth systems over the decades have
> satisfied the requirements, and how many systems run
> into performance pitfalls in various situations.
> This paper also discusses how to avoid this
> slowness, including in native-code systems.}
> }
> @Proceedings{euroforth24,
> title = {40th EuroForth Conference},
> booktitle = {40th EuroForth Conference},
> year = {2024},
> key = {EuroForth'24},
> url = {http://www.euroforth.org/ef24/papers/proceedings.pdf}
> }
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-23 05:39 +0000 |
| Subject | Re: Microarchitectural effects on performance (was: Optimization ...) |
| Message-ID | <2026Sep23.073956@mips.complang.tuwien.ac.at> |
| In reply to | #118114 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> John Levine <johnl@taugh.com> writes: >------------------- >> >> OTOH, the store-to-wide-load forwarding issue that I have discussed in >> this thread is directly connected to the auto-vectorization of several >> narrow loads into a wide load. So in this case the transformation has >> direct connection to the microarchitectural pitfall. > >I think we need to make a distinction between vectorization and >SIMDization. Vectors are like CRAY (and RISC-v) while SIMD is >most everyone else. Architecturally, vectors are an instance of SIMD. Is there any other instance? In a compiler, the conversion of scalar code to code that uses SIMD instructions is called vectorization. What you are thinking about is microarchitecture. Does the SIMD instruction work on every scalar separately, or does it work on several scalars in parallel. One interesting aspect is that early SSE2 implementations worked 8 bytes at a time, so if the scalars were binary64 floats, you would classify these implementations as "vectors", while if the scalars were binary32, you would classify them as "SIMD". The bubble-sort benchmark sorts 4-byte integers. With auto-vectorization, the program loads two adjacent integers with one 8-byte load; if they are reordered, it stores two integers with an 8-byte store. The microarchitectural pitfall occurs on a load after such a store, and it slows the program down, but the program behaves correctly, so the compiler works correctly and the architecture is implemented correctly. Maybe some future microarchitectures will include a way to avoid this pitfall: E.g., it could notice that a given load sees relatively many overlaps, and have a mechanism that splits it into sub-loads and merge the results, basically undoing the vectorization. Would you classify such a microarchitecture as vector or as SIMD? One architectural difference between the Cray-1 and modern architectures is that the Cray-1 only has 8-byte data, whether shorts, ints, or floats (not sure about doubles); and I think that's even the case for chars in C. So the issue of dealing with 4-byte or 1-byte lanes does not pose itself in microarchitectures for this architecture. It does pose itself for RISC-V. I have not looked at RISC-V vectors and their implementations, but somehow I doubt that all of them will perform string loads one byte at a time. Reading up about the NEC SX-Aurora <https://en.wikipedia.org/wiki/SX-Aurora_TSUBASA>, the spiritual successor of the Cray-1, it has 64 logical vector registers with 256x64 bits length. It's implementation uses "32-fold parallel SIMD units" (obviously using SIMD in your sense, not the architectural sense; I would rather call it "32x64-bit-wide functional units"), and with three FMA units this results in up to 192 DP FP ops per cycle. I expect that it has a similar performance problem if a load partially overlaps a store, especially if the distance is not a multiple of the FU width. What would a 2018-vintag Cray-1 successor look like. Probably much like the NEC SX-Aurora, i.e., it would also have this problem. Given that we have not seen an SX-Aurora successor in 8 years, despite new types of HBM appearing and the demand for SIMD (with small to very small components) being huge, it seems like NEC has finished their SX line with the Aurora. >In modern machines LDs are well pipelined, often multi-lane; so, >when a compiler auto-SIMDs a gaggle of LDs into a LDSIMD, one >then needs a similar means to extract the gaggle from the SIMD. >This extract is less likely to have the same properties of the >LD pipeline. Cartainly even the load-only version of bubble-sort performs slower on Rocket Lake <2026Sep21.171615@mips.complang.tuwien.ac.at>. OTOH, microarchitectures tend to have fewer load units than ALU units, so even if the scalar values are needed, one probably can construct a cases where a wide load followed by extraction and processing is faster than two narrow loads followed by processing. In general, though, it probably is only beneficial if the data then does not need to be extracted, but the further processing can also happen in a SIMD way. >> E.g., I discuss [ertl24] a number of microarchitectural >> pitfalls that many Forth systems fall into, not because of >> sophistication, but because the Forth systems use techniques that >> worked fine in the microprocessors of the 1970s and 1980s, and >> actually still work fine on threaded-code systems on modern CPUs, but >> fall into these pitfalls in native-code systems. > >Is this related to the over aggressive branch predictors of modern ? >Either branches themselves or indirect calls. One of the pitfalls is related to branch prediction: Using a call instruction and then not returning, but popping the return address off the stack to get the position of the call instruction as data; this results in the hardware return stack getting out-of-sync and results in all returns at the current level and further out to be mispredicted. What do you mean by "over aggressive branch prediction"? Either a branch predictor predicts correctly or it mispredicts. In what case would it be "over aggressive"? - 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-23 18:34 +0000 |
| Subject | Re: Microarchitectural effects on performance (was: Optimization ...) |
| Message-ID | <1790188471-5857@newsgrouper.org> |
| In reply to | #118142 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: > > > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > > > >> John Levine <johnl@taugh.com> writes: > >------------------- > >> > >> OTOH, the store-to-wide-load forwarding issue that I have discussed in > >> this thread is directly connected to the auto-vectorization of several > >> narrow loads into a wide load. So in this case the transformation has > >> direct connection to the microarchitectural pitfall. > > > >I think we need to make a distinction between vectorization and > >SIMDization. Vectors are like CRAY (and RISC-v) while SIMD is > >most everyone else. > > Architecturally, vectors are an instance of SIMD. Is there any other > instance? One might consider vVM somewhere between CRAY and SIMD. > In a compiler, the conversion of scalar code to code that uses SIMD > instructions is called vectorization. Compilers have to prove various things in order to (your term) vectorize. These profs work for CRAY and SIMD. These proofs are NOT NEEDED for vVM. > What you are thinking about is microarchitecture. Does the SIMD > instruction work on every scalar separately, or does it work on > several scalars in parallel. Later CRAY (and NEC) build multiple lanes of calculations, so that, every clock one could perform 2^(small n) calculations of memory references. Thus SIMD is the second dimension of executing lots of instruction instances per cycle. > One interesting aspect is that early SSE2 implementations worked 8 > bytes at a time, so if the scalars were binary64 floats, you would > classify these implementations as "vectors", while if the scalars were > binary32, you would classify them as "SIMD". > > The bubble-sort benchmark sorts 4-byte integers. With > auto-vectorization, the program loads two adjacent integers with one > 8-byte load; if they are reordered, it stores two integers with an > 8-byte store. The microarchitectural pitfall occurs on a load after > such a store, and it slows the program down, but the program behaves > correctly, so the compiler works correctly and the architecture is > implemented correctly. > > Maybe some future microarchitectures will include a way to avoid this > pitfall: E.g., it could notice that a given load sees relatively many > overlaps, and have a mechanism that splits it into sub-loads and merge > the results, basically undoing the vectorization. Would you classify > such a microarchitecture as vector or as SIMD? deSIMD since you are taking what is in SIMD form and decomposing it to perform better on "this implementation". > One architectural difference between the Cray-1 and modern > architectures is that the Cray-1 only has 8-byte data, Yes to CRAY-1 and CRAY-1S, no to CRAY-XMP/YMP--at least at the ports to memory. CRAY-1 had 24-bit base/bounds memory space. > whether shorts, > ints, or floats (not sure about doubles); and I think that's even the > case for chars in C. So the issue of dealing with 4-byte or 1-byte > lanes does not pose itself in microarchitectures for this > architecture. Lee Higbe told me (1982) that CRAY-1 vectorized symbol table lookup. > It does pose itself for RISC-V. I have not looked at RISC-V vectors > and their implementations, but somehow I doubt that all of them will > perform string loads one byte at a time. My 66000 vVM accesses memory at cache-width, and then parcels out data to calculations from a high ported set of buffers. So, a GBOoO would access 2 cache lines per cycle and then parcel out the data at whatever width is useful to the calculations needed done. > Reading up about the NEC SX-Aurora > <https://en.wikipedia.org/wiki/SX-Aurora_TSUBASA>, the spiritual > successor of the Cray-1, it has 64 logical vector registers with > 256x64 bits length. It's implementation uses "32-fold parallel SIMD > units" (obviously using SIMD in your sense, not the architectural > sense; I would rather call it "32x64-bit-wide functional units"), and > with three FMA units this results in up to 192 DP FP ops per cycle. I > expect that it has a similar performance problem if a load partially > overlaps a store, especially if the distance is not a multiple of the > FU width. > > What would a 2018-vintag Cray-1 successor look like. Probably much > like the NEC SX-Aurora, i.e., it would also have this problem. Vectors died as a concept because one could build way more on-die calculation performance than one could feed with the number of memory pins one could surround that die with. > Given that we have not seen an SX-Aurora successor in 8 years, despite > new types of HBM appearing and the demand for SIMD (with small to very > small components) being huge, it seems like NEC has finished their SX > line with the Aurora. HBM does not solve the pin problem (above) but it does ameliorate a factor of 4× of it. > >In modern machines LDs are well pipelined, often multi-lane; so, > >when a compiler auto-SIMDs a gaggle of LDs into a LDSIMD, one > >then needs a similar means to extract the gaggle from the SIMD. > >This extract is less likely to have the same properties of the > >LD pipeline. > > Cartainly even the load-only version of bubble-sort performs slower on > Rocket Lake <2026Sep21.171615@mips.complang.tuwien.ac.at>. OTOH, > microarchitectures tend to have fewer load units than ALU units, so > even if the scalar values are needed, one probably can construct a > cases where a wide load followed by extraction and processing is > faster than two narrow loads followed by processing. In general, > though, it probably is only beneficial if the data then does not need > to be extracted, but the further processing can also happen in a SIMD > way. > > >> E.g., I discuss [ertl24] a number of microarchitectural > >> pitfalls that many Forth systems fall into, not because of > >> sophistication, but because the Forth systems use techniques that > >> worked fine in the microprocessors of the 1970s and 1980s, and > >> actually still work fine on threaded-code systems on modern CPUs, but > >> fall into these pitfalls in native-code systems. > > > >Is this related to the over aggressive branch predictors of modern ? > >Either branches themselves or indirect calls. > > One of the pitfalls is related to branch prediction: Using a call > instruction and then not returning, but popping the return address off > the stack to get the position of the call instruction as data; this > results in the hardware return stack getting out-of-sync and results > in all returns at the current level and further out to be > mispredicted. > > What do you mean by "over aggressive branch prediction"? Either a > branch predictor predicts correctly or it mispredicts. In what case > would it be "over aggressive"? There are cases where not predicting is faster than prediction with low success rate. The dispatch point of an interpreter/simulator is one. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-23 13:53 -0400 |
| Subject | Re: Microarchitectural effects on performance |
| Message-ID | <jwvjyobj1va.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118142 |
>>I think we need to make a distinction between vectorization and >>SIMDization. Vectors are like CRAY (and RISC-v) while SIMD is >>most everyone else. > Architecturally, vectors are an instance of SIMD. Is there any other > instance? My understanding is that "SIMD" can be used to refer to the family of techniques that includes Cray-style vectors, AVX-style small vectors, Connection Machines, and GPU warps. But recently, I've heard the term used "SIMD" used to refer specifically to AVX-style small vectors, and "SIMT" for GPU warps. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-21 12:48 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvbj9qpo44.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118111 |
John Levine [2026-09-20 20:12:42] wrote: > According to Stefan Monnier <monnier@iro.umontreal.ca>: >>Indeed, in practice virtually all compiler "optimizations" are valid >>only statistically: in most cases they either have no measurable effect >>or they improve some characteristic, but there are almost always corner >>cases where they make things worse. > There are plenty of optimizations that always make things better, e.g., > removing dead code, or reusing values in registers. But these days those > are so obvious we sometimes forget about them. "Always" is a very strong statement. In practice, it's hard to be 100% sure that there can't be some weird corner case. Dead code removal looks safe enough, but it tends to change code layout, which in turn can affect cache conflicts, it can also enable new optimizations (which can in turn have detrimental effects), ... I'm not saying compilers should not do dead code removal, tho. Just that weird performance effects of optimizations are part of life, and every optimization comes with a degree of uncertainty over whether or not it'll be harmless. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-21 17:17 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep21.191719@mips.complang.tuwien.ac.at> |
| In reply to | #118109 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>Anton Ertl [2026-09-19 06:25:13] wrote:
[...]
>The traditional "-O<N>" flags are a way to state how much you're willing
>to get worse performance in exchange for the opportunity to maybe get
>better performance.
The gcc manual states:
With '-O', the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal
of compilation time.
[...]
[about -O2] As
compared to '-O', this option increases both compilation time and
the performance of the generated code.
[...]
[about -O3] Optimize yet more.
In earlier gcc versions, it made statements along the lines that -O3
may be a mixed bag, but that's gone.
>> But if optimizer writers strove to "improve the convenience to write
>> efficient code" instead of just improving benchmark results, maybe
>> such paradoxical effects can be avoided.
>
>In general it's hard to completely avoid paradoxical effects.
I referred to a specific paradoxical effect, not completely avoiding
all of them: The effect of programmers who, instead of working on
making the code faster through source-level changes, have to invest
time into avoiding getting it miscompiled.
>But as
>for the problems you mention w.r.t UB, I think it's just the result of
>poor semantics, for which I guess we (language semanticists) are partly
>to blame: we have developed fairly good tools to design sane language
>specs in general,
I violently disagree. The C89 standard (just to name one) is a
partial specification not because the original C standards people were
poor at specifying semantics, but because given the differences
between the compilers out there and the hardware out there, the
easiest way to reach a consensus is to leave some parts unspecified.
I don't think that they expected that compiler writers on a
twos-complement machine that does not trap on signed overflow would
say: Hey, signed overflow is undefined behaviour, let's assume it
never happens, and silently miscompile some (not all) programs that
actually perform signed overflows. It gives a speedup in some SPEC
program (How much? Don't know, but I am sure it exists); ok, it
breaks this other SPEC program, let's special-case the optimization to
avoid this breakage.
My impression is that the C compiler maintainers and some others have
fallen in love with the idea of optimizing based on assuming that
undefined behaviour does not happen; e.g., I have read the claim that
this is the only thing that gives C an edge over other programming
languages (or somesuch). So I think that while the C89 committee may
not have thought of such things, recent C standardization committees
probably have.
Still, even if they did not, there are still differences between
hardware and between existing compilers to reconcile (although a lot
of the old hardware variations have died out), and getting consensus
on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew
Flatt, and John Regehr tried to create a more completely specified
"friendly C", and did not find consensus:
<https://blog.regehr.org/archives/1287>.
But fortunately a completely specified C is not necessary, a
willingness to preserve the behaviour of existing working programs
compiled with an earlier version of the same compiler is. Read more
about it in <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>.
Linux commits to preserving user-space behaviour (whether standard or
not), everything I have heard from people claiming to speak for gcc
and clang maintainers has been in the opposite direction. So I blame
the gcc and clang maintainers for the undefined-behaviour shenanigans
they perform.
- 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 | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-21 20:06 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1790021183-5857@newsgrouper.org> |
| In reply to | #118117 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >Anton Ertl [2026-09-19 06:25:13] wrote: ------------- > >But as > >for the problems you mention w.r.t UB, I think it's just the result of > >poor semantics, for which I guess we (language semanticists) are partly > >to blame: we have developed fairly good tools to design sane language > >specs in general, > > I violently disagree. The C89 standard (just to name one) is a > partial specification not because the original C standards people were > poor at specifying semantics, but because given the differences > between the compilers out there and the hardware out there, the > easiest way to reach a consensus is to leave some parts unspecified. Does anyone know if Ada was successful about not leaving parts unspecified ?? > I don't think that they expected that compiler writers on a > twos-complement machine that does not trap on signed overflow would > say: Hey, signed overflow is undefined behaviour, let's assume it > never happens, and silently miscompile some (not all) programs that > actually perform signed overflows. It gives a speedup in some SPEC > program (How much? Don't know, but I am sure it exists); ok, it > breaks this other SPEC program, let's special-case the optimization to > avoid this breakage. This is a problem with SPEC not the compilers for various machines. A broad spectrum benchmark should not contain code that relies on unspecified or undefined behaviors. I remember Whetstone on the S.E.L. machines had a call to EXP( float ) with a constant value and expected IBM quality result, whereas on the S.E.L. machine the operand constant was such that (hex alignment) could NEVER produce the expected result to the accuracy the benchmark was expecting. In all other regards S.E.L. FP was equivalent to IBM 360 FP arithmetic. One would hope that IEEE 754 put an end to it, but BFP8 and FP8 raises this spectré again. > My impression is that the C compiler maintainers and some others have > fallen in love with the idea of optimizing based on assuming that > undefined behaviour does not happen; e.g., I have read the claim that > this is the only thing that gives C an edge over other programming > languages (or somesuch). So I think that while the C89 committee may > not have thought of such things, recent C standardization committees > probably have. How much more optimizations can compilers deliver to the bottom line (not just benchmarks). Last week we saw an episode where the compilers only got 1.x% speedup over years (sub-decade). Is there ever going to be a time to stop ?? > Still, even if they did not, there are still differences between > hardware and between existing compilers to reconcile (although a lot > of the old hardware variations have died out), and getting consensus > on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew > Flatt, and John Regehr tried to create a more completely specified > "friendly C", and did not find consensus: > <https://blog.regehr.org/archives/1287>. > > But fortunately a completely specified C is not necessary, a > willingness to preserve the behaviour of existing working programs > compiled with an earlier version of the same compiler is. Read more > about it in <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>. > > Linux commits to preserving user-space behaviour (whether standard or > not), everything I have heard from people claiming to speak for gcc > and clang maintainers has been in the opposite direction. So I blame > the gcc and clang maintainers for the undefined-behaviour shenanigans > they perform. Some of the machines have egregious behaviors in tiny little corners of the architecture(s) and implementation(s). Not being able to run the same binary with and without integer overflow detection as an example. And even when they can, they cannot perform Ada ADD Byte and take a signed overflow trap on 8-bit results easily. So, much of the blame is cast back on architects of those machines. > - anton
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-21 23:48 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260921234813.00003eda@yahoo.com> |
| In reply to | #118118 |
On Mon, 21 Sep 2026 20:06:23 GMT MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > > > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > >Anton Ertl [2026-09-19 06:25:13] wrote: > ------------- > > >But as > > >for the problems you mention w.r.t UB, I think it's just the > > >result of poor semantics, for which I guess we (language > > >semanticists) are partly to blame: we have developed fairly good > > >tools to design sane language specs in general, > > > > I violently disagree. The C89 standard (just to name one) is a > > partial specification not because the original C standards people > > were poor at specifying semantics, but because given the differences > > between the compilers out there and the hardware out there, the > > easiest way to reach a consensus is to leave some parts > > unspecified. > > Does anyone know if Ada was successful about not leaving parts > unspecified ?? > I think that Ada never had such goal. It specified more than contemporaries (at least those that pretended to be "system" level languges) and than nearly all successors and considered that it is good enough. Some corner cases were considered impractical to specify precisely. E.g x := a + b + c, where x, a, b and c are 32-bit integers, a = 0x7fff_ffff, b = 1, c = -2. It may raise exception or silintly produce correct answer. Both behaviors are acceptable by Ada spec.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-22 05:25 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep22.072554@mips.complang.tuwien.ac.at> |
| In reply to | #118118 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >> >Anton Ertl [2026-09-19 06:25:13] wrote: >------------- >> >But as >> >for the problems you mention w.r.t UB, I think it's just the result of >> >poor semantics, for which I guess we (language semanticists) are partly >> >to blame: we have developed fairly good tools to design sane language >> >specs in general, >> >> I violently disagree. The C89 standard (just to name one) is a >> partial specification not because the original C standards people were >> poor at specifying semantics, but because given the differences >> between the compilers out there and the hardware out there, the >> easiest way to reach a consensus is to leave some parts unspecified. > >Does anyone know if Ada was successful about not leaving parts >unspecified ?? Does Ada have this goal? Java does have this goal, and AFAIK it is far better in this respect than C. There are some difficulties where hardware differences (handling of denormals on the 80387, thankfully phased out with the advent of SSE2) and lack of specification in hardware (weak memory models) are concerned. >> I don't think that they expected that compiler writers on a >> twos-complement machine that does not trap on signed overflow would >> say: Hey, signed overflow is undefined behaviour, let's assume it >> never happens, and silently miscompile some (not all) programs that >> actually perform signed overflows. It gives a speedup in some SPEC >> program (How much? Don't know, but I am sure it exists); ok, it >> breaks this other SPEC program, let's special-case the optimization to >> avoid this breakage. > >This is a problem with SPEC not the compilers for various machines. How should it be a problem of SPEC if a compiler wilfully break non-SPEC programs, but spares SPEC programs? >A broad spectrum benchmark should not contain code that relies on >unspecified or undefined behaviors. A benchmark that is supposed to contain representative of real-world application programs written in C must exercise undefined behaviour in those C programs. If SPEC rejects benchmark submissions because of undefined behaviour, or edits the undefined behaviour out, the result is no longer representative. (The focus of SPEC CPU on long-running programs that use lots of memory also hurts.) >> My impression is that the C compiler maintainers and some others have >> fallen in love with the idea of optimizing based on assuming that >> undefined behaviour does not happen; e.g., I have read the claim that >> this is the only thing that gives C an edge over other programming >> languages (or somesuch). So I think that while the C89 committee may >> not have thought of such things, recent C standardization committees >> probably have. > >How much more optimizations can compilers deliver to the bottom line >(not just benchmarks). Number of optimizations? There have been a number of cases where I have noticed that gcc misses a real optimization. The tsp example also shows that a lot of the optimizations that Jon Bentley performed in 1982 are not performed by compilers. Effect of new optimizations or "optimizations" based on assuming that undefined behaviour never happens on performance? They never say. That's the cool thing. They do not have numbers (they certainly never present any, certainly not for their own compilers), but are convinced that their "optimizations" do wonders for performance, and their fanboys are even more convinced. Why are they convinced? My guess is me that they see that their transformation actually is applied, and assume that it gives a speedup. The speedup is usually not measurable, because the transformation is not applied in hot code, but the assumption is that the combination of hundreds of transformations has a beneficial effect. Which might be the case if they hit more often than they miss, but they defend every questionable transformation (or worse, "optimization") with the argument that it helps, without presenting evidence, certainly not in any case where I have seen this claim, and I have seen it several times, most recently in this discussion <118odha$31okp$1@dont-email.me>. I have tested several of these claims, e.g., just yesterday <2026Sep21.171615@mips.complang.tuwien.ac.at> the claim that auto-vectorizing several narrow loads into a wide load is a optimization unless the "very special memory access pattern" happens. Of course Thomas Koenig did not specify what's so "very special" about the memory access pattern, which allows him to claim that every case where no speedup is shown, such as the one in <2026Sep21.171615@mips.complang.tuwien.ac.at>, is also "very special". OTOH, he has not shown a single instance where this autovectorization helps, i.e., a case that he does not consider to be "very special". My guess is that the majority of cases are "very special". For the "optimization" that broke SATD in 464.h264ref, the gcc people defanged it for the release of gcc-4.8 in a way that spared 464.h264ref. When I talked to a gcc developer about it, he said something like "it did not speed up relevant programs". Which makes it interesting to know what "relevant programs" are; my guess is that it is a corpus of programs consisting of well-known benchmarks plus a collection of programs from paying customers who would not like to see their programs to regress in performance; it seems to me that they now also have a collection of programs where functionality is tested, but apparently that did not include the SPEC CPU benchmarks before gcc-4.8 (or the functionality testing was not performed before creating the prerelease that broke 464.h264ref). >Last week we saw an episode where the compilers >only got 1.x% speedup over years (sub-decade). Is there ever going to >be a time to stop ?? When the money stops flowing. As mentioned, there are a lot of transformations possible. Turning them into reliable automatic optimizations is a lot of work; I have my doubts that it is worth it. >> Linux commits to preserving user-space behaviour (whether standard or >> not), everything I have heard from people claiming to speak for gcc >> and clang maintainers has been in the opposite direction. So I blame >> the gcc and clang maintainers for the undefined-behaviour shenanigans >> they perform. > >Some of the machines have egregious behaviors in tiny little corners >of the architecture(s) and implementation(s). Not being able to run >the same binary with and without integer overflow detection as an example. None of the mainstream architectures have hardware support for this feature, and I have never missed it. >And even when they can, they cannot perform Ada ADD Byte and take a signed >overflow trap on 8-bit results easily. It's not that hard: Sign-extend the byte, compare the result to the original, and jump to the trap if it they are different. Three inline instructions on AMD64 and RISC-V. And checking the result is far better than checking every operation, because the result may be in range even if some intermediate result is not. - 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 | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-22 14:13 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <XyzsS.183583$KV1.64738@fx09.iad> |
| In reply to | #118123 |
On 2026-Sep-22 01:25, Anton Ertl wrote: > MitchAlsup <user5857@newsgrouper.org.invalid> writes: >> >> How much more optimizations can compilers deliver to the bottom line >> (not just benchmarks). > > Number of optimizations? There have been a number of cases where I > have noticed that gcc misses a real optimization. The tsp example > also shows that a lot of the optimizations that Jon Bentley performed > in 1982 are not performed by compilers. > > Effect of new optimizations or "optimizations" based on assuming that > undefined behaviour never happens on performance? They never say. > That's the cool thing. They do not have numbers (they certainly never > present any, certainly not for their own compilers), but are convinced > that their "optimizations" do wonders for performance, and their > fanboys are even more convinced. It seems someone measured UB optimization performance impact in LLVM: Exploiting Undefined Behavior in C C++ Programs for Optimization A Study on the Performance Impact, 2025 https://dl.acm.org/doi/abs/10.1145/3729260 https://dl.acm.org/doi/pdf/10.1145/3729260 "Using LLVM, a compiler known for its extensive use of UB for optimizations, we demonstrate that, for the benchmarks and UB categories that we evaluated, the end-to-end performance gains are minimal."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-26 07:44 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep26.094458@mips.complang.tuwien.ac.at> |
| In reply to | #118130 |
EricP <ThatWouldBeTelling@thevillage.com> writes:
>On 2026-Sep-22 01:25, Anton Ertl wrote:
>> Effect of new optimizations or "optimizations" based on assuming that
>> undefined behaviour never happens on performance? They never say.
>> That's the cool thing. They do not have numbers (they certainly never
>> present any, certainly not for their own compilers), but are convinced
>> that their "optimizations" do wonders for performance, and their
>> fanboys are even more convinced.
>
>It seems someone measured UB optimization performance impact in LLVM:
>
>Exploiting Undefined Behavior in C C++ Programs for Optimization
>A Study on the Performance Impact, 2025
>https://dl.acm.org/doi/abs/10.1145/3729260
>https://dl.acm.org/doi/pdf/10.1145/3729260
They did it by using 6 pre-existing flags in clang, and adding 12
additional ones that defined behaviour that C and C++ do not define.
>"Using LLVM, a compiler known for its extensive use of UB for optimizations,
>we demonstrate that, for the benchmarks and UB categories that we evaluated,
>the end-to-end performance gains are minimal."
An earlier work with a similar result is:
@InProceedings{wang+12,
author = {Xi Wang and Haogang Chen and Alvin Cheung and Zhihao Jia and Nickolai Zeldovich and M. Frans Kaashoek},
title = {Undefined Behavior: What Happened to My Code?},
booktitle = {Asia-Pacific Workshop on Systems (APSYS'12)},
OPTpages = {},
year = {2012},
url1 = {http://homes.cs.washington.edu/~akcheung/getFile.php?file=apsys12.pdf},
url2 = {http://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf},
OPTannote = {}
}
In particular, Wang et al. found that in all of the SPEC 2006 (IIRC)
CPU benchmarks written in C, there are only two locations where the
"optimizations" they looked at made a difference that's beyond the
noise level. These performance benefits could also be had by two
small changes in the source code (which does not happen for
benchmarks, but it happens for production code), which is much cheaper
than "sanitizing" all of the code (which does not happen for
benchmarks, either; instead, the compiler is tuned to avoid
miscompiling the benchmark; but for production code the fans of
"optimization" want us to do it).
- 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 | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-09-22 14:48 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <nhf88cF3gbbU1@mid.individual.net> |
| In reply to | #118118 |
On 2026-09-21 23:06, MitchAlsup wrote: > > anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Anton Ertl [2026-09-19 06:25:13] wrote: > ------------- >>> But as >>> for the problems you mention w.r.t UB, I think it's just the result of >>> poor semantics, for which I guess we (language semanticists) are partly >>> to blame: we have developed fairly good tools to design sane language >>> specs in general, >> >> I violently disagree. The C89 standard (just to name one) is a >> partial specification not because the original C standards people were >> poor at specifying semantics, but because given the differences >> between the compilers out there and the hardware out there, the >> easiest way to reach a consensus is to leave some parts unspecified. > > Does anyone know if Ada was successful about not leaving parts > unspecified ?? Not entirely, because there are still some cases where the Ada standard says that "erroneous execution" follows, which means essentially unpredictable effects, and also cases of "bounded error", which means that one of a few, specific and defined things can happen, but it is unpredictable or implementation-dependent which of those things happen. Perhaps the most easily triggered erroneous execution is accessing an object via a pointer, but that object has been discarded (a dangling reference). Most erroneous-execution cases come from similar "behind the scenes" changes of program state that make some other parts of that state no longer valid or correct. A typical case of bounded error is when a subprogram call has two formal parameters, but the call supplies the same object as an argument to both those parameters, so that the subprogram can access the same object through two paths. If the parameter-passing method is left to the compiler's choice (by copy or by reference), it is a bounded error to assign the object a value via one path, and then read the object via the other path, where the possible consequences are that Program_Error is raised, or the newly assigned value is read, or some old value of the object is read. The Ada language manintainers certainly consider it an important goal to minimize the cases of both types of unspecified behaviour. And to identify those cases in the Ada reference manual, of course. Also, if some behaviour is defined in the reference manual as implementation dependent, the standard requires an implementor to document what the implementation does in such cases. The SPARK subset/variant of Ada has the stronger goal of either preventing such problems by design, or proving that they cannot happen in execution.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-23 19:28 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119198l$22s12$1@dont-email.me> |
| In reply to | #118118 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb: > How much more optimizations can compilers deliver to the bottom line > (not just benchmarks). Last week we saw an episode where the compilers > only got 1.x% speedup over years (sub-decade). Is there ever going to > be a time to stop ?? As of a hours minutes ago, there were 4547 bugs in GCC with the missed-optimization keyword. There are 229 open bugs blocking the "missed optimization in SPEC" bug, PR 26163 (but some of these are also ICEs). You will be amused to learn that there are 415 open bugs regarding vectorization. There are regular regressions in SPEC where somebody observes a slowdown of 5% or 15% on some architecture or other. There is still quite a few optimizations to be done. Which ones have which effect on any particular piece of software is of course not clear. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-22 05:19 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118t35m$j2ih$1@dont-email.me> |
| In reply to | #118117 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > I don't think that they expected that compiler writers on a > twos-complement machine that does not trap on signed overflow would > say: Hey, signed overflow is undefined behaviour, let's assume it > never happens, and silently miscompile some (not all) programs that > actually perform signed overflows. Define "miscompile". According to which specification? [...] > My impression is that the C compiler maintainers and some others have > fallen in love with the idea of optimizing based on assuming that > undefined behaviour does not happen; e.g., I have read the claim that > this is the only thing that gives C an edge over other programming > languages (or somesuch). Other languages handle this better. In Fortran, for example, signed integer overflow is just an error, so a compiler that would not optimize on the assumption of absence of integer overflow would be doing a poor jobs. >So I think that while the C89 committee may > not have thought of such things, recent C standardization committees > probably have. > > Still, even if they did not, there are still differences between > hardware and between existing compilers to reconcile (although a lot > of the old hardware variations have died out), and getting consensus > on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew > Flatt, and John Regehr tried to create a more completely specified > "friendly C", and did not find consensus: ><https://blog.regehr.org/archives/1287>. People who want that kind of language know where to find it, they can always chose Ada. -- 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-22 08:29 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep22.102909@mips.complang.tuwien.ac.at> |
| In reply to | #118121 |
Thomas Koenig <tkoenig@netcologne.de> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>
>> I don't think that they expected that compiler writers on a
>> twos-complement machine that does not trap on signed overflow would
>> say: Hey, signed overflow is undefined behaviour, let's assume it
>> never happens, and silently miscompile some (not all) programs that
>> actually perform signed overflows.
>
>Define "miscompile".
If a compiler produces an unintended behaviour for an existing, tested
program that works as intended with an earlier version of the compiler.
@InProceedings{ertl17kps,
author = {M. Anton Ertl},
title = {The Intended Meaning of \emph{Undefined Behaviour}
in {C} Programs},
crossref = {kps17},
pages = {20--28},
url = {https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf},
url2 = {http://www.kps2017.uni-jena.de/proceedings/kps2017_submission_5.pdf},
abstract = {All significant C programs contain undefined
behaviour. There are conflicting positions about how
to deal with that: One position is that all these
programs are broken and may be compiled to arbitrary
code. Another position is that tested and working
programs should continue to work as intended by the
programmer with future versions of the same C
compiler. In that context the advocates of the first
position often claim that they do not know the
intended meaning of a program with undefined
behaviour. This paper explores this topic in greater
depth. The goal is to preserve the behaviour of
existing, tested programs. It is achieved by letting
the compiler define a consistent mapping of C
operations to machine code; and the compiler then
has to stick to this behaviour during optimizations
and in future releases.}
}
@Proceedings{kps17,
title = {19. Kolloquium Programmiersprachen und Grundlagen der Programmierung (KPS'17)},
booktitle = {19. Kolloquium Programmiersprachen und Grundlagen der Programmierung (KPS'17)},
year = {2017},
key = {KPS '17},
editor = {Wolfram Amme and Thomas Heinze},
url = {http://www.kps2017.uni-jena.de/kps2017_proceedings.html},
url-pdf = {http://www.kps2017.uni-jena.de/proceedings/kps2017.pdf}
}
>According to which specification?
If you want that, go for the specification of a conforming program in
the C standard. Compiling a conforming program compiled with a
different compiler or on a different architecture to different
behaviour is ok with me, compiling it on the same architecture with a
new version of the same compiler into different behaviour is
miscompilation.
>In Fortran, for example, signed
>integer overflow is just an error, so a compiler that would not
>optimize on the assumption of absence of integer overflow would
>be doing a poor jobs.
What does "just an error" mean? Does it trap?
>> Still, even if they did not, there are still differences between
>> hardware and between existing compilers to reconcile (although a lot
>> of the old hardware variations have died out), and getting consensus
>> on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew
>> Flatt, and John Regehr tried to create a more completely specified
>> "friendly C", and did not find consensus:
>><https://blog.regehr.org/archives/1287>.
>
>People who want that kind of language know where to find it,
I think these efforts are the result of C compiler maintainers and
their fanboys trying to deflect the blame from the real culprits (the
C compiler maintainers) to the C standardization committee: If the
specification is to blame, people try to work on a better
specification.
These attempts were not successful with me, howewer. I think that the
compiler maintainers are to blame. I don't think that the C standard
is to blame, just as the rules are not to blame for malicious
compliance. <https://en.wikipedia.org/wiki/Malicious_compliance>
describes the behaviour of gcc and clang in the last decades:
"strictly following orders, laws, and rules to the letter, ignoring
expectations that go without saying and the spirit of the
requirement." At least that's the way they behave when some breakage
actually comes up in public.
But given that you mention a different language, I also have the
impression that the unhappyness about this behaviour by the compiler
maintainers is among C programmers, not (to my knowledge) among C++
programmers.
A number of projects that use C use compiler options to make the
language more defined, among them the Linux, PostgresSQL, and Gforth.
In Gforth we try, and if present, use the options
-fno-gcse
-fcaller-saves
-fno-defer-pop
-fno-inline
-fwrapv
-fchar-unsigned
-fno-strict-aliasing
-fno-cse-follow-jumps
-fno-reorder-blocks
-fno-reorder-blocks-and-partition
-fno-toplevel-reorder
-fno-trigraphs
-falign-labels=1
-falign-loops=1
-falign-jumps=1
-fno-delete-null-pointer-checks
-fcf-protection=none
-fno-tree-slp-vectorize
some of which tighten the language definition. I expect that other
projects have similar lists. With new compiler versions we
occasionally have to scan the options to see if there is something new
that may be "optimized" by the new version and where there exists an
option for tightening the language to prevent that "optimization" from
miscompiling the program.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 10 of 24 — ← Prev page 1 … 8 9 [10] 11 12 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web