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 20 of 24 — ← Prev page 1 … 18 19 [20] 21 22 … 24 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-27 21:23 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260927212334.000065fc@yahoo.com> |
| In reply to | #118258 |
On Sun, 27 Sep 2026 17:39:38 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Michael S <already5chosen@yahoo.com> schrieb: > > On Sun, 27 Sep 2026 13:42:05 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > > [Polyhedron benchmark, which is Fortran] > > >> Geometric Mean Execution Time = 11.73 seconds > >> > >> The geometric mean increased by around 11%. Some tests were > >> within shouting each other. Others (air, linpk, nf, tfft2) show > >> significant differences. > >> > >> So at least for that particular codebase, taking away the > >> freedom of the compiler to optimize based on the assumption > >> that integers will never overflow, and replacing it with > >> something defined, leads to a significant slowdown. > >> > > > > > > Fortran is not the same as C. > > C and Fortran share the same rules about integer overflow. > > But if you run any program through the NAG compiler, it is > translated to a C program. > > > My understanding is that in Fortran array indexes are by default > > 32-bit. > > That understanding turns out to be wrong. > > In Fortran, an array index is an integer expression, and that > can be of any KIND that the compiler supports. You can write > > use iso_fortran_env, only :: int64 > integer(int64) :: i > integer :: j > > This will declare a 64-bit integer variable i and a default integer > variable j. You can then access an array A either way, for > exmaple > > real, dimension(whatever) :: a > > a(i) = something > a(j) = something_else > > > > That couses real cost under wrapv. > > In C there is no such thing as default size of array index. > > Neither is there in Fortran. There is a default integer, > which is typically 32 bit. > > > The > > programmer can define it as 32-bit and suffer the same performance > > degradatioon under wrapv as Fortran does. Or he can define index as > > either ptrdiff_t or size_t and suffere no degradation. > > A Fortran programmer can do exactly the same; he could even import > C_PTRDIFF_T from the ISO_C_BINDING module. > > In that respect, there is not difference between C and Fortran. > So, what happens when you edit source code of Polyhedron benchmark to use of C_PTRDIFF_T for aray indices? Is there still an impact for -fwrapv ? of
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-29 16:53 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119gqet$3faea$1@dont-email.me> |
| In reply to | #118260 |
Michael S <already5chosen@yahoo.com> schrieb:
> So, what happens when you edit source code of Polyhedron benchmark to
> use of C_PTRDIFF_T for aray indices?
I (would, and did) get a ton of syntax errors.
Fortran does not do argument promotion, so (assuming the
right intrinsic module has been imported
subroutine foo(i)
integer(kind=c_ptrdiff_t), intent(in) :: i
...
and somewhere where foo is visible.
call foo(1)
is invalid when c_ptrdiff_t is not equal to the default integer
kind, and compilers catch that in a module. The calling side
should then read
call foo(1_c_ptrdiff_t)
so presumebly an abbreviation would be used.
Rewriting a Fortran program for larger integers is, unfortunately,
a major undertaking, best done with automated tools.
I can use the option of ill repute, -fdefault-integer-8, which
causes standard violations. Interestingly, that also makes one
benchmark fail.
> Is there still an impact for -fwrapv ?
From the numbers I've looked at with -fdefault-integer-8, not
a big one. But like I wrote above, this is an option of ill
repute.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-09-27 11:46 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <sTauS.1021$213.100@fx04.iad> |
| In reply to | #118247 |
On 2026-Sep-27 09:42, Thomas Koenig wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>
>> Given that UB has been shown to provide only fairly minor performance
>> gains,
>
> This I found hard to believe, so I ran a
> few benchmarks myself. I used the well-known
> Polyhedron suite, which can now be downloaded from
> https://fortran.uk/fortran-compiler-comparisons/the-polyhedron-solutions-benchmark-suite/
> ,
>
> This is Fortran, so integer overflow is an error. I ran the
> testsuite on gfortran with and without -fwrapv, otherwise letting
> the compiler go wild (-Ofast). Because gfortran puts arrays on the
> stack with -Ofast, I had to increase the stacksize for one particular
> code. I had to disable one test, rnflow, because of a bug.
>
> Here are the results:
>
> <snip>
>
> Geometric Mean Execution Time = 10.57 seconds
>
> Geometric Mean Execution Time = 11.73 seconds
>
> The geometric mean increased by around 11%. Some tests were
> within shouting each other. Others (air, linpk, nf, tfft2) show
> significant differences.
>
> So at least for that particular codebase, taking away the
> freedom of the compiler to optimize based on the assumption
> that integers will never overflow, and replacing it with
> something defined, leads to a significant slowdown.
>
One of the papers I looked at gave an example that can
explain some of this:
"for (int i = 0; i <= N; ++i) { ... }
Because of the undefined behavior caused by signed overflow
[8, UB #36], a compiler can often assume that such a loop will iterate
exactly N + 1 times. If i were instead declared as unsigned int,
making overflow defined, the compiler would now need to consider
the possibility that the loop will never terminate
(e.g., were N to be UINT_MAX)."
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-27 14:42 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwva4p2wnej.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118247 |
Thomas Koenig [2026-09-27 13:42:05] wrote: > Stefan Monnier <monnier@iro.umontreal.ca> schrieb: >> Given that UB has been shown to provide only fairly minor performance >> gains, > The geometric mean increased by around 11%. Some tests were > within shouting each other. Others (air, linpk, nf, tfft2) show > significant differences. FWIW, I consider a 10% performance difference to be fairly minor. Notice also that my SMUB proposal does allow some of the optimizations that UB allows w.r.t overflow (e.g. it allows the compiler to consider integer addition as associative) so it would not cost as much as `-fwrapv`. === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-28 06:12 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119d0g5$22r0a$1@dont-email.me> |
| In reply to | #118271 |
Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
> Thomas Koenig [2026-09-27 13:42:05] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>> Given that UB has been shown to provide only fairly minor performance
>>> gains,
>> The geometric mean increased by around 11%. Some tests were
>> within shouting each other. Others (air, linpk, nf, tfft2) show
>> significant differences.
>
> FWIW, I consider a 10% performance difference to be fairly minor.
That was the geometric mean, the worst one was a factor of 1.54.
And people fix speed regressions of an individual test case of
2-5%, so your opinion differs a lot from that of people who write
compilers, at least.
> Notice also that my SMUB proposal does allow some of the optimizations
> that UB allows w.r.t overflow (e.g. it allows the compiler to consider
> integer addition as associative) so it would not cost as much as
> `-fwrapv`.
Do you mean associative as in a + b = b + a (which is trivially
true) or associative as in (a + b) + c = (c + b) + a, even when
c + b overflows?
But your proposal, as I understand it, would destroy a lot of
range-based optimization, so that, for example, the second if
statement in
if (a > 5) {
if (a + 1 > 3) {
}
}
would be executed. You may wonder who writes such code, but
it can be created as the result of template initiation,
constant propagation, function specialization aka cloning,
devirtualization, link-time optimization (which allows a lot
of the previous stuff) or any combination of the above, plus
other optimization.
--
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-28 07:57 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep28.095712@mips.complang.tuwien.ac.at> |
| In reply to | #118272 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Stefan Monnier <monnier@iro.umontreal.ca> schrieb: >> FWIW, I consider a 10% performance difference to be fairly minor. > >That was the geometric mean, the worst one was a factor of 1.54. It would be interesting to know what kind of code that was, and what code was generated with either option. Wang et al. only saw a ~10% hit from -fwrapv on one of the SPEC CINT benchmarks (and no difference on the others), from a sign extension inserted in an inner loop. I find it hard to believe that additional sign extensions result in a factor 1.54 slowdown in an inner loop, much less across the whole benchmark. Did gfortran auto-vectorize some hot loop without -fwrapv, and but not with -fwrapv? >> Notice also that my SMUB proposal does allow some of the optimizations >> that UB allows w.r.t overflow (e.g. it allows the compiler to consider >> integer addition as associative) so it would not cost as much as >> `-fwrapv`. > >Do you mean associative as in a + b = b + a (which is trivially >true) or associative as in (a + b) + c = (c + b) + a, even when >c + b overflows? a+b = b+a is not the associative law. (a + b) + c = (c + b) + a is not the associative law, either. (a + b) + c = a + (b + c) is the associative law. The first is the commutative law (which also holds for addition), the second has no name, but if the commutative and associative laws hold for an operation, it holds, too. Concerning -fwrapv: The associative law holds for + and * in modulo arithmetics, so the compiler can perform optimizations that rely on the associative law when the programmer asks for modulo arithmetics with -fwrapv. That's not the case if overflow is trapped (-ftrapv, or its long-winded -fsanitize= cousin). >You may wonder who writes such code, but >it can be created as the result of template initiation, I.e., C programmers don't write such code. >devirtualization, I.e., C programmers don't write such code. I think that Fortran programmers don't write such code, either, - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-28 08:56 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119da3i$2647e$1@dont-email.me> |
| In reply to | #118276 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: >>You may wonder who writes such code, but >>it can be created as the result of template initiation, > > I.e., C programmers don't write such code. Compilers share middle and back ends. Do you propose to turn off specific optimizations for C only? > >>devirtualization, > > I.e., C programmers don't write such code. > > I think that Fortran programmers don't write such code, either, You mean Fortran programmers do not use features that have been in the language since Fortran 2003? Fortran has had type extension, type-bound procedures and CLASS since then. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 11:06 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119danj$23bo0$6@dont-email.me> |
| In reply to | #118276 |
On 28/09/2026 09:57, Anton Ertl wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>> FWIW, I consider a 10% performance difference to be fairly minor.
For some code, 10% may be considered a major improvement. Lots of code
is not performance-critical, but some of it is.
>>
>
> Concerning -fwrapv: The associative law holds for + and * in modulo
> arithmetics, so the compiler can perform optimizations that rely on
> the associative law when the programmer asks for modulo arithmetics
> with -fwrapv. That's not the case if overflow is trapped (-ftrapv, or
> its long-winded -fsanitize= cousin).
Yes, -fwrapv allows a lot more optimisation than -ftrapv.
>
>> You may wonder who writes such code, but
>> it can be created as the result of template initiation,
>
> I.e., C programmers don't write such code.
>
>> devirtualization,
>
> I.e., C programmers don't write such code.
>
C programmers use macros, which can result in such code. (Some C
programmers use a /lot/ of very convoluted macros.)
Code like this can also easily turn up as the result of inlining,
function cloning, constant propagation, and other such transformations:
int foo(int a) {
if (a + 1 > 3) {
...
}
}
int bar(int a) {
if (a > 5) {
return foo(a);
}
}
C++ gives more ways to write code than C, but I don't think it changes
the principles here.
(I suspect that another type of optimisation that people disagree about,
type-based alias analysis or "-fstrict-aliasing", is more relevant for
C++ than C, because you typically use more different types in C++.)
> I think that Fortran programmers don't write such code, either,
>
> - anton
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-28 14:32 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvpkxxfe32.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118272 |
Thomas Koenig [2026-09-28 06:12:21] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>> Notice also that my SMUB proposal does allow some of the optimizations
>> that UB allows w.r.t overflow (e.g. it allows the compiler to consider
>> integer addition as associative) so it would not cost as much as
>> `-fwrapv`.
>
> Do you mean associative as in a + b = b + a (which is trivially
> true) or associative as in (a + b) + c = (c + b) + a, even when
> c + b overflows?
[ Anton replied to this part. ]
> But your proposal, as I understand it, would destroy a lot of
> range-based optimization, so that, for example, the second if
> statement in
>
> if (a > 5) {
> if (a + 1 > 3) {
> }
> }
>
> would be executed.
I think there would be related cases where SMUB would disallow "similar"
optimizations (e.g. the `a + b > INTMAX` case), but not for the above
one: SMUB would say that the compiler is free to make `a+1` return any
integer it likes when the computation overflows, so the inner test can
be skipped.
> You may wonder who writes such code, but
I don't: it's common to see weird/useless code after macro-expansion.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-27 16:40 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119b9sf$1d7bm$1@dont-email.me> |
| In reply to | #118232 |
On 26/09/2026 16:25, Stefan Monnier wrote:
> David Brown [2026-09-25 19:00:26] wrote:
>> That seems fine for certain things, as a possible choice by an
>> implementation - it keeps the diagnostic option for the behaviour. But it
>> limits optimisation.
>
> Limiting optimization is the whole purpose of the exercise!
>
Limiting optimisations should /never/ be an aim in itself. An
optimisation is a transformation of the code (source code, internal
representations, object code) that results in faster and/or smaller
object code without affecting the semantics. Baring code whose
correctness depends on size or speed (which is certainly a valid
possibility in real world programming) since that is outside the scope
of definition for C and most other programming languages, an
optimisation cannot make a correct program incorrect, or change its
behaviour in any meaningful way - if a compiler pass or flag does make a
meaningful change, it is not an optimisation.
The critical thing to understanding optimisation is to understand the
semantics of the code - what the code actually means, according to the
specification of the language plus any additional semantics provided by
the implementation documentation. Where people usually get in trouble
is when they /think/ their code has defined semantics that it does not.
An optimisation does not "break" correct code. Code that is correct
before the optimisation pass will remain correct afterwards - code that
is incorrect after optimisation was incorrect before the optimisation.
But while optimisations do not introduce problems in correct code, they
certainly can amplify the /consequences/ of incorrect code. Sometimes,
by luck, the pre-optimisation consequences of a particular piece of
incorrect code - a particular case of UB at run-time - are negligible or
non-existent. Sometimes, by luck, that same UB has serious consequences
after optimisation.
And since people write incorrect code by mistake, or perhaps knowingly
but without appropriate precautions (like pre-processor checks for
particular compiler versions, or documented specific flags in the build
files), this can all lead to unpleasant surprises.
> Remember, we're starting from the problem that UB is used by
> compilers in ways which catch programmers off-guard.
If that is truly the way you think, then you should maybe give up
programming and start a conspiracy-theory pod-cast. (You'll probably
make more money!) Seriously - if you start from the suggestion that
compiler writers are aiming to catch programmers off-guard, or that they
disregard the needs of real programmers so that they can get better
benchmark results, you will always be fighting with your tools and tool
vendors, instead of cooperating. Toolchain writers are fallible humans,
like the rest of us, and they can make mistakes, make poor decisions,
have different priorities that don't match ours, and have bosses and
employers that have different ideas about what is important. But don't
imagine that anyone is in the toolchain business (or language
specification business) with an aim of making things difficult for
others, or of showing off how great their tools are in some test that
does not match real usage.
> My SMUB proposal
> is an attempt to define something which I hope is closer to what
> programmers expect.
There are a million C programmers. There are a million and one
different things that they expect, or want, or hope for. People who
think they know what programmers expect are, statistically speaking, wrong.
Of course you are entirely entitled to your own opinions about what
/you/ expect. And if you make proposals like this and there enough
people who think along the same lines, maybe it will lead to changes or
new features in the language and toolchains. The big challenge is
getting a workable definition of what this "SMUB" should be - that would
be a long and hard process.
>
> Given that UB has been shown to provide only fairly minor performance
> gains, I'm hopeful that "downgrading" UB to SMUB would be good enough in
> the vast majority of cases. You could still add a `--SMUB-is-UB` flag
> if you're so inclined, of course, just like the `--fast-math`.
First, you already have much of this as a flag in gcc - it's called
"enabling optimisation". If you blind "literal" code generation, that's
what you get by default in gcc. You still don't get guarantees - there
is no black-or-white choices here between "optimised" and "not optimised".
Secondly, you are not going to get anywhere when you try to talk about
"optimisation from UB" - that's too vague to be of any use. You can
talk about very specific classes of operation that has some UB today,
but not UB in general. As it stands, your suggestion would mean that
unless the "--SMUB-is-UB" flag is used, the compiler would need to
implement this :
int get(int * p) { return *p; }
as
int get(int * p) {
if (is_valid_pointer_to_an_int_object(p)) {
return *p;
} else {
return some_int;
// or
exit_with_error_message();
}
}
Clearly, that is not going to happen. If that's what you want, use a
managed language (or compile with a good memory sanitizer).
Thirdly, don't assume that other programmers want any of this. Some
will, others will not.
Fourthly, don't rely on an old benchmark paper of some particular
programs on one or two particular machines as though it "proves"
anything. It is perhaps an interesting study, and can be a guide to
where compiler writers should be concentrating their efforts, but it is
not "proof" that "optimising from UB has only minor gains". Performance
gains in compiled code is the combination of large numbers of
transformations whose average improvement is tiny, as well as some
passes that occasionally make a large difference. If assuming signed
integer overflow does not happen saves two instructions from a 100
instruction loop, it makes no practical difference - if it saves two
instructions from a four instruction loop, then that code benefits
greatly. And while code on an x86 might not see a difference from an
optimisation since the bottleneck is memory speed and caching patterns,
the same optimisation on a microcontroller might make a huge difference.
>
>> what is the compiler supposed to do with the "unreachable()" if you are not
>> halting with an error?
>
> At runtime, I think a self-respecting compiler would halt with an error,
> yes. That's the only behavior that won't catch programmers by surprise.
That would be a huge surprise to /me/ if it happened. Again, you are
extrapolating your own ideas to those of other programmers.
"unreachable()" says, very clearly IMHO (and I'm aware that opinions are
subjective) that this code will not be reached. I most certainly do not
want the compiler to inject code that will stop the program here.
That's simply not what the word means.
C already has ways to say "stop the program with a message". It has a
way to say "unless we have picked no-debugging mode, check that this
expression is true, or else stop with an error" - the "assert" macro has
been standard forever. (And some of us are against the use of that
macro, as it stands, in their code - others can use it if they like, but
it is too blunt an instrument for my needs.) gcc has had a
"__builtin_unreachable()" feature for decades - any programmer familiar
with that would likely be very surprised if C23's standardised
unreachable() macro acted differently.
There is /no/ choice of definition - or lack of definition - that is not
going to surprise at least some programmers. There is no choice that
will make everyone happy. The C standard committee picked the
definition that was most likely to be useful, and least likely to be
surprising, and compilers (like gcc) implement it as it is intended.
>
>> There's no way to get sensible semantics here - you either say terminate
>> immediately to limit damage, or accept what UB means. Trying to say you
>> things can go a bit bad, but not too bad, never works.
>
> Note that in your example, even if `unreachable()` turns into a nop, the
> potential damage still corresponds to executing the code which the users
> wrote, in the order they wrote it, performing the tests they wrote.
No, it does not. Turning "unreachable()" into a "nop" would just be an
extra opcode in the object code, one that should never be executed. If
control flow ever reaches the "unreachable()", then the programmer has
made a critical bug in their code somewhere. /Everything/ is then a
surprise - and most likely, the problem is long before the unreachable()
part, as are the consequences of the mistake. "unreachable()" is not an
assertion, or a checkpoint in the code - hitting it would mean you have
screwed up royally, and nothing can be relied upon. It is no different
in semantics from a comment saying "// Code flow should never get here"
- it is just that now you have a way of saying that to the compiler and
not just to human programmers.
And any imagined semantics of "unreachable()" just mean that you now
have a line in your code that does something, but it will never be
tested and cannot ever be tested. That's a big no-no for many developers.
Either the line with "unreachable()" can be executed, in which case you
should not use that macro but should do something else, or it is never
executed - in which case it should not have any semantics.
> So it still matches better the naive semantics most programmers have in
> their head than some of the very counter-intuitive runtime behaviors
> you may get with UB's current optimizations.
Nope.
>
>> We can do that already. I don't want "unreachable()" to duplicate
>> that, I want it to mean something else.
>
> I know. You like to take advantage of UB to try and gain the last few
> percents of optimizations. I put less emphasis on that.
>
I have already explained that I like UB for multiple reasons.
Optimisation is just one of them.
> A halfway point might be for the compiler to emit a warning when it
> can't show that `unreachable()` is indeed unreachable.
I can certainly agree that the compiler could give a warning if the
unreachable() is definitely reached. And if compiler writers can figure
out some decent heuristics about "unreachable()" being inevitably
reached after some useful code path, then a warning would be nice.
(That can't be given specifications in the standards, because you could
not define clear semantics here - but it's fine to have optional
compiler warnings on things that appear to be wrong according to some
kind of pattern recognition.)
But it would be virtually useless to have a warning any time the
compiler cannot prove that the "unreachable()" is indeed unreachable.
The whole point of its use is when the programmer knows more than the
compiler, and is giving the compiler additional information. If the
compiler knows that point in the code cannot be reached, then it already
knows it is unreachable, and will already optimise on the assumption
that the point is not reached!
>
> [ I generally like the idea of programmers being able to request
> specific optimizations and to be warned by the compiler when those
> requests can't be satisfied. So we don't have to go dig in the
> assembly output to confirm whether the compiler did the right thing or
> not. ]
>
I agree on that principle - I'm a big fan of warnings when my code
appears to be wrong. But this is not a situation where warnings would
be appropriate.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-28 01:58 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvpkxyue3t.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118248 |
David Brown [2026-09-27 16:40:15] wrote: > On 26/09/2026 16:25, Stefan Monnier wrote: >> Remember, we're starting from the problem that UB is used by >> compilers in ways which catch programmers off-guard. > If that is truly the way you think, then you should maybe give up > programming and start a conspiracy-theory pod-cast. (You'll probably make > more money!) Seriously - if you start from the suggestion that compiler > writers are aiming to catch programmers off-guard, or that they disregard I never claimed it is their aim. The fact that programmers are surprised by the behavior of the generated code (e.g. cases described as "nasal demons") just reflects the fact that their understanding of undefined behavior doesn't match the reality and my SMUB is an attempt to specify another flavor of undefined behavior which is hoped to: - Align more closely with what the average programmers expect when they hear "undefined behavior". - Still allow enough flexibility for the implementation that the impact on performance is usually small. I'm not blaming anyone. My finger is pointed only at the discrepancy between what UB is understood to mean by the C spec and what it is understood to mean by average programmers. [ And I don't see much hope to fix the programmers' understanding, so I think the only way to reduce this discrepancy is to change the C spec. ] === Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-29 10:16 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119fs5q$31nv1$3@dont-email.me> |
| In reply to | #118298 |
On 28/09/2026 07:58, Stefan Monnier wrote: > David Brown [2026-09-27 16:40:15] wrote: >> On 26/09/2026 16:25, Stefan Monnier wrote: >>> Remember, we're starting from the problem that UB is used by >>> compilers in ways which catch programmers off-guard. >> If that is truly the way you think, then you should maybe give up >> programming and start a conspiracy-theory pod-cast. (You'll probably make >> more money!) Seriously - if you start from the suggestion that compiler >> writers are aiming to catch programmers off-guard, or that they disregard > > I never claimed it is their aim. Okay - I apologise for reading too much into your wording there. > > The fact that programmers are surprised by the behavior of the generated > code (e.g. cases described as "nasal demons") just reflects the fact > that their understanding of undefined behavior doesn't match the reality True. But the root issue is that some programmers don't understand what UB is, or do not know that a particular construct is, or may have, UB. Undefined behaviour itself is not the problem, nor is compiler handling of it. This is why I am not convinced that some new types of sort-of UB will be helpful. They could only be useful in a few specific cases, and could easily add to the confusion. The focus, as I see it, should be on helping programmers understand UB, and helping them avoid it in their code. The part to be played by toolchains here is to be better at spotting potential UB and warning about it. (And toolchains are, on the whole, getting better at this.) There are also at least some particular cases where the C standards could be changed to give at least some definition to undefined behaviours, but not in many cases. > and my SMUB is an attempt to specify another flavor of undefined > behavior which is hoped to: > > - Align more closely with what the average programmers expect when > they hear "undefined behavior". I don't believe in the "average" programmer, or that there is any consensus about what they might expect. And I don't think a language like C, or its tools, should be aiming to cater for programmers who want a more managed or friendly language. Any solution which reduces the efficiency of generated code should be rejected. And any solution which says it is okay for C programmers to be lax should be rejected. Today, we tell C programmers "Do not let your signed integer arithmetic overflow - it will cause daemons to fly out of your nose! This is a rule of C, and you must obey it". It is simple and clear, and for the most part, not difficult to achieve. It is an unfortunate truth that not all C programmers know that rule, and that even experts occasionally make mistakes, but we live in an imperfect world. Changing this to "You should probably not let your signed integer arithmetic overflow. It's unlikely to have very bad consequences, but it will sometimes give the wrong answer, or perhaps stop your program. However, dereferencing an invalid pointer will still launch nasal daemons" is /not/ helpful. > - Still allow enough flexibility for the implementation that the impact > on performance is usually small. > > I'm not blaming anyone. My finger is pointed only at the discrepancy > between what UB is understood to mean by the C spec and what it is > understood to mean by average programmers. > > [ And I don't see much hope to fix the programmers' understanding, so > I think the only way to reduce this discrepancy is to change the > C spec. ] > > > === Stefan
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-02 05:31 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119nfk2$2rqdj$2@paganini.bofh.team> |
| In reply to | #118248 |
David Brown <david.brown@hesbynett.no> wrote:
> On 26/09/2026 16:25, Stefan Monnier wrote:
>> David Brown [2026-09-25 19:00:26] wrote:
>
>> A halfway point might be for the compiler to emit a warning when it
>> can't show that `unreachable()` is indeed unreachable.
>
> I can certainly agree that the compiler could give a warning if the
> unreachable() is definitely reached. And if compiler writers can figure
> out some decent heuristics about "unreachable()" being inevitably
> reached after some useful code path, then a warning would be nice.
> (That can't be given specifications in the standards, because you could
> not define clear semantics here - but it's fine to have optional
> compiler warnings on things that appear to be wrong according to some
> kind of pattern recognition.)
>
> But it would be virtually useless to have a warning any time the
> compiler cannot prove that the "unreachable()" is indeed unreachable.
> The whole point of its use is when the programmer knows more than the
> compiler, and is giving the compiler additional information. If the
> compiler knows that point in the code cannot be reached, then it already
> knows it is unreachable, and will already optimise on the assumption
> that the point is not reached!
I do not think that such warning would be useful to Stefan. But
that does not make it useless. Namely, difficultly of proof
decrease sharply if you have enough knowledge. Namely, for
seqential code current gcc is reasonably adept at propagating
conditions. It can recognize _some_ looping patterns. But
in general for loops and recursion one needs appropriate
invariants and variants. It is hard to automatically
infer them. But with enough programmer supplied information
compiler in principle could verify its correctness by
simple sequential-like reasoning. Failure to verify
information provided by programmer indicates that this
info is either wrong or incomplete. Both are reasons to
change it, either by removing info that failed to verify
or adding more info in hope that this will lead to
successful proof.
>> [ I generally like the idea of programmers being able to request
>> specific optimizations and to be warned by the compiler when those
>> requests can't be satisfied. So we don't have to go dig in the
>> assembly output to confirm whether the compiler did the right thing or
>> not. ]
>>
>
> I agree on that principle - I'm a big fan of warnings when my code
> appears to be wrong. But this is not a situation where warnings would
> be appropriate.
Lisp compiler 'sbcl' at high optimization level emits a lot of
warnings about constructs that it can not optimize, giving
information that is needed to enable optimization. In C similar
warnings are less needed, because basic C construct already have low
level ("optimized") form. But C programmers may expect some
optimizations and it would be good for compiler to report if
optimizations did not apply.
Of course, most people using '-Werror' does not want optimization
warning to halt the build. So clearly they should go in different
category than normal warnings.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-24 19:52 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1790279542-5857@newsgrouper.org> |
| In reply to | #118172 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted: > On 9/23/2026 7:47 AM, Tim Rentsch wrote: > > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > > > >> On 9/22/2026 5:32 AM, David Brown wrote: > > > > [...] > > > >>> And note that in C23 the macro "unreachable()" was added with the > >>> sole semantics being "If a macro invocation unreachable() is > >>> reached during execution, the behavior is undefined" and "The > >>> program execution shall not reach such an invocation". > >> > >> I don't have a problem with the inclusion of "unreachable()", but > >> can you give a possible rationale for making its behavior > >> "undefined" as opposed to say "implementation defined"? Yes, it > >> would make the compiler implementers do some work to document > >> whatever they decided to do, but are there any other reasons? > > > > The short answer is that being implementation-defined is too > > limiting. A construct having implementation-defined behavior > > cannot do "just anything"; the C standard must specify what > > behavior choices are possible. Any fixed set of choices might > > rule out what an implementation would like to do. So the only > > way to allow implementations to do whatever they choose is to > > have the behavior be undefined. > > As I responded to David, you are right, given the way those terms are > defined in the standard. But I submit there should be some way to > express essentially "you can do whatever you want, but must document > what you do". That would allow the compiler to fork "/bin/games/chess -play_both_sides"; It is unlikely that the programmer would desire or expect that. I think you want closer to "Do something reasonable here" for a broad definition of reasonable. > >
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-24 13:52 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11942ii$31l5g$1@dont-email.me> |
| In reply to | #118181 |
On 9/24/2026 12:52 PM, MitchAlsup wrote: > > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted: > >> On 9/23/2026 7:47 AM, Tim Rentsch wrote: >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>> >>>> On 9/22/2026 5:32 AM, David Brown wrote: >>> >>> [...] >>> >>>>> And note that in C23 the macro "unreachable()" was added with the >>>>> sole semantics being "If a macro invocation unreachable() is >>>>> reached during execution, the behavior is undefined" and "The >>>>> program execution shall not reach such an invocation". >>>> >>>> I don't have a problem with the inclusion of "unreachable()", but >>>> can you give a possible rationale for making its behavior >>>> "undefined" as opposed to say "implementation defined"? Yes, it >>>> would make the compiler implementers do some work to document >>>> whatever they decided to do, but are there any other reasons? >>> >>> The short answer is that being implementation-defined is too >>> limiting. A construct having implementation-defined behavior >>> cannot do "just anything"; the C standard must specify what >>> behavior choices are possible. Any fixed set of choices might >>> rule out what an implementation would like to do. So the only >>> way to allow implementations to do whatever they choose is to >>> have the behavior be undefined. >> >> As I responded to David, you are right, given the way those terms are >> defined in the standard. But I submit there should be some way to >> express essentially "you can do whatever you want, but must document >> what you do". > > That would allow the compiler to fork "/bin/games/chess -play_both_sides"; > It is unlikely that the programmer would desire or expect that. > > I think you want closer to "Do something reasonable here" for a broad > definition of reasonable. Ahhh, but that is the problem. Different people have different definitions of reasonable. While forking off a chess game wouldn't pass my (or, I suspect many people's) definition of reasonable, if it was documented, as I would require, you can't say it was unexpected. And, of course, I suspect that if it did that a lot, few people would use that compiler. :-) -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-25 11:06 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1195dj9$3bbk8$3@dont-email.me> |
| In reply to | #118184 |
On 24/09/2026 22:52, Stephen Fuld wrote: > On 9/24/2026 12:52 PM, MitchAlsup wrote: >> >> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted: >> >>> On 9/23/2026 7:47 AM, Tim Rentsch wrote: >>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>> >>>>> On 9/22/2026 5:32 AM, David Brown wrote: >>>> >>>> [...] >>>> >>>>>> And note that in C23 the macro "unreachable()" was added with the >>>>>> sole semantics being "If a macro invocation unreachable() is >>>>>> reached during execution, the behavior is undefined" and "The >>>>>> program execution shall not reach such an invocation". >>>>> >>>>> I don't have a problem with the inclusion of "unreachable()", but >>>>> can you give a possible rationale for making its behavior >>>>> "undefined" as opposed to say "implementation defined"? Yes, it >>>>> would make the compiler implementers do some work to document >>>>> whatever they decided to do, but are there any other reasons? >>>> >>>> The short answer is that being implementation-defined is too >>>> limiting. A construct having implementation-defined behavior >>>> cannot do "just anything"; the C standard must specify what >>>> behavior choices are possible. Any fixed set of choices might >>>> rule out what an implementation would like to do. So the only >>>> way to allow implementations to do whatever they choose is to >>>> have the behavior be undefined. >>> >>> As I responded to David, you are right, given the way those terms are >>> defined in the standard. But I submit there should be some way to >>> express essentially "you can do whatever you want, but must document >>> what you do". >> >> That would allow the compiler to fork "/bin/games/chess - >> play_both_sides"; >> It is unlikely that the programmer would desire or expect that. >> >> I think you want closer to "Do something reasonable here" for a broad >> definition of reasonable. > > Ahhh, but that is the problem. Different people have different > definitions of reasonable. > And there you have it - the crux of the issue, and the key reason why no programming language can have Tim's hypothetical "implementation dependent" behaviour. (That would be an extraordinarily confusing choice of name, but I am sure Tim is aware of that.) You can't have a specification that says "do something reasonable" - or "the compiler can do anything reasonable as long as it is documented". So the specification says "this document does not say anything about what will happen - it does not need to be defined, consistent, or something that any given programmer finds reasonable". Then it is up to compiler writers to decide what /they/ consider reasonable - possibly with different variations with different flags. And then the programmer can decide what /they/ consider reasonable - choosing a compiler and/or flags that suit their own preferences. Or they can write code that does not have the such constructs in the first place, and avoid the issue entirely.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-25 05:43 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11951l7$3a8v3$1@dont-email.me> |
| In reply to | #118181 |
MitchAlsup <user5857@newsgrouper.org.invalid> schrieb:
>
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> posted:
>
>> On 9/23/2026 7:47 AM, Tim Rentsch wrote:
>> > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>> >
>> >> On 9/22/2026 5:32 AM, David Brown wrote:
>> >
>> > [...]
>> >
>> >>> And note that in C23 the macro "unreachable()" was added with the
>> >>> sole semantics being "If a macro invocation unreachable() is
>> >>> reached during execution, the behavior is undefined" and "The
>> >>> program execution shall not reach such an invocation".
>> >>
>> >> I don't have a problem with the inclusion of "unreachable()", but
>> >> can you give a possible rationale for making its behavior
>> >> "undefined" as opposed to say "implementation defined"? Yes, it
>> >> would make the compiler implementers do some work to document
>> >> whatever they decided to do, but are there any other reasons?
>> >
>> > The short answer is that being implementation-defined is too
>> > limiting. A construct having implementation-defined behavior
>> > cannot do "just anything"; the C standard must specify what
>> > behavior choices are possible. Any fixed set of choices might
>> > rule out what an implementation would like to do. So the only
>> > way to allow implementations to do whatever they choose is to
>> > have the behavior be undefined.
>>
>> As I responded to David, you are right, given the way those terms are
>> defined in the standard. But I submit there should be some way to
>> express essentially "you can do whatever you want, but must document
>> what you do".
>
> That would allow the compiler to fork "/bin/games/chess -play_both_sides";
> It is unlikely that the programmer would desire or expect that.
Early versions of gcc did a game of hack when encountering a
pragma. The code looked like
do_pragma ()
{
close (0);
if (open ("/dev/tty", O_RDONLY, 0666) != 0)
goto nope;
close (1);
if (open ("/dev/tty", O_WRONLY, 0666) != 1)
goto nope;
execl ("/usr/games/hack", "#pragma", 0);
execl ("/usr/games/rogue", "#pragma", 0);
execl ("/usr/new/emacs", "-f", "hanoi", "9", "-kill", 0);
execl ("/usr/local/emacs", "-f", "hanoi", "9", "-kill", 0);
nope:
fatal ("You are in a maze of twisty compiler features, all different");
}
So there is precedent.
--
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-23 05:49 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118vp92$1ff81$2@dont-email.me> |
| In reply to | #118126 |
David Brown <david.brown@hesbynett.no> schrieb: > In microcontroller work, -Os is often used to put a stronger emphasis on > size optimisations. I have noticed there are sometimes "blips" - cases > where "-O2" leads to smaller code than "-Os", or where "-Os" leads to > faster code than "-O2". And there can sometimes be cases where the > speed/size tradeoffs are unreasonable - significantly slower code for > very minor size improvements, or vice versa. Just to muddle the waters a little more: I once submitted a PR where -O3 led to smaller code than -Os. The reason? -O3 ran a pass which led to significant simplification and subsequent dead code elimination. > I think one thing that is sometimes forgotten in all this, and could > usefully be mentioned on the gcc manual page for optimisation, is that > cpu architecture flags can make a significant difference. The step from > "-O2" to "-O2 -march=native" is likely to be a lot bigger than the step > from "-O2" to "-O3" in performance, with much lower risks of slowdowns. Additionally, -mtune=native can also help. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-23 10:45 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11903ip$1il2u$2@dont-email.me> |
| In reply to | #118141 |
On 23/09/2026 07:49, Thomas Koenig wrote: > David Brown <david.brown@hesbynett.no> schrieb: > >> In microcontroller work, -Os is often used to put a stronger emphasis on >> size optimisations. I have noticed there are sometimes "blips" - cases >> where "-O2" leads to smaller code than "-Os", or where "-Os" leads to >> faster code than "-O2". And there can sometimes be cases where the >> speed/size tradeoffs are unreasonable - significantly slower code for >> very minor size improvements, or vice versa. > > Just to muddle the waters a little more: I once submitted a PR > where -O3 led to smaller code than -Os. The reason? -O3 ran a > pass which led to significant simplification and subsequent dead > code elimination. Yes. It is not always easy to predict. I generally use -O2 in my embedded work. While -Os generally gives slightly smaller code for smaller test cases and functions, I find -O2 often gives smaller total code in practice because you get better inter-procedural optimisations. It can seem counter-intuitive, but even adding a flag like "-fipa-cp-clone" (from -O3) to clone functions can end up with smaller object code in the end. > >> I think one thing that is sometimes forgotten in all this, and could >> usefully be mentioned on the gcc manual page for optimisation, is that >> cpu architecture flags can make a significant difference. The step from >> "-O2" to "-O2 -march=native" is likely to be a lot bigger than the step >> from "-O2" to "-O3" in performance, with much lower risks of slowdowns. > > Additionally, -mtune=native can also help. > Sure, although that is already active as part of "-march=native". If you want to distribute a binary that can run on a wide range of systems but is optimised for newer processors, "-mtune" is the way to go.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-25 05:39 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep25.073928@mips.complang.tuwien.ac.at> |
| In reply to | #118126 |
David Brown <david.brown@hesbynett.no> writes: >On 21/09/2026 19:17, Anton Ertl wrote: >> 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. >> > >By "miscompiled", do you mean incorrect object code, or object code that >did not have the performance the programmer expected or hoped for? Code that behaves differently than intended, e.g., where a bounds check is "optimized" away. Performance regressions can be nasty for performance-sensitive code, and consume time for finding a workaround (if one can be found), but is a different thing. >>> 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 have never spoken to the C standards committee or writers, either of >current standard versions or the original C89 standard, or writers of >pre-standard C specifications. So I cannot in any way claim to know >their thoughts or motivations. I also have not seen any documentation >that suggests what they might have thought about "optimisation on the >assumption that undefined behaviour does not occur" - in either >direction. When C89 was developed, the dominating C compiler in the Unix world was PCC. GCC came on the scene late in the game (1988), without such assumptions and produced a significant performance advantage. Only after several years of heavy gcc development assumptions like -fstrict-aliasing were introduced around gcc-2.7 (which was initially disabled by default); I don't know when the assumption that signed integer operations do not overflow was introduced, and initially it could not be disabled (-fwrapv was added around gcc-3.4), so obviously by that time people had taken over the gcc project who had a different view about how undefined behaviour should be treated. Maybe the change can be pinpointed to the version when -fstrict-aliasing became the default, or maybe the attitude change was more gradual. Anyway, given the state of C compilers during C89 development, no, I don't think they ever thought that undefined behaviour would be used to justify "optimizing" away bounds checks, such as the second one below: char *buf = ...; char *buf_end = ...; unsigned int len = ...; if (buf + len >= buf_end) return; /* len too large */ if (buf + len < buf) return; /* overflow, buf+len wrapped around */ /* write to buf[0..len-1] */ [This example is given in <https://people.csail.mit.edu/nickolai/papers/wang-stack.pdf>, which cites <https://www.kb.cert.org/vuls/id/162289>] >(It has been mentioned that, for example, a two's complement >implementation could use wrapping signed arithmetic - but I have never >seen a suggestion that this behaviour should be encouraged or expected >just because a machine uses two's complement.) The C99 rationale (which obviously contains text written for C89) includes the following: |C code can be non-portable. Although it strove to give |programmers the opportunity to write truly portable programs, the C89 |Committee did not want to force programmers into writing portably, to |preclude the use of C as a "high-level assembler": the ability to |write machine-specific code is one of the strengths of C. It is this |principle which largely motivates drawing the distinction between |strictly conforming program and conforming program (Section 4). | |Keep the spirit of C. The C89 Committee kept as a major goal |to preserve the traditional spirit of C. There are many facets of the |spirit of C, but the essence is a community sentiment of the |underlying principles upon which the C language is based. Some of the |facets of the spirit of C can be summarized in phrases like: | | * Trust the programmer. | * Don't prevent the programmer from doing what needs to be done. | * Keep the language small and simple. | * Provide only one way to do an operation. | * Make it fast, even if it is not guaranteed to be portable. | |The last proverb needs a little explanation. The potential for |efficient code generation is one of the most important strengths of |C. To help ensure that no code explosion occurs for what appears to be |a very simple operation, many operations are defined to be how the |target machine's hardware does it rather than by a general abstract rule. So no, it does not say what a compiler should do, but I understand it as saying that it is in the spirit of C if a programmer relies on 2s-complement wraparound arithmetic for signed integers on an architecture where C compilers implement signed integer arithmetic in that way. That was certainly the case for many architectures in 1989, where no C compilers on MIPS produced the add or addi instructions (which trap on signed overflow) for signed arithmetic even though it was available. It was also the case for 68000, IA-32, HPPA, SPARC, Alpha, and others. And whenever I looked at the code produced for MIPS and Alpha, I have never seen the trapping addition/subtraction/multiplication instructions generated. Maybe if you ask for it with -ftrapv, but IIRC I looked at generated code once and found that the trapping instructions were ignored even then, instead generating more long-winded overflow checks. >You do not ask "what happens >if my signed integer arithmetic overflows?" or "what happens when I >access an array out of bounds?" - rather, it is your responsibility as a >C programmer to make sure that never happens. That's not at all what I read in the rationale. >The prime reason C does >not define behaviour here is not that different hardware or compilers >handle things differently, but that there is no sensible definition that >could be made. Java had no problem producing a sensible definition for what happens on signed overflow. Likewise, for the bounds check above, there is a sensible definition that can be made, and gcc actually still (or again) uses it if you tell it to, with -fwrapv-pointer. >Remember, C has a perfectly good way to say "this is determined by the >hardware or the implementation" - it is "implementation-defined >behaviour". It has a perfectly good way to say that "this operation >could result in any value" - it is "unspecified behaviour" or >"unspecified value". > >When the C standards writers say something is "undefined behaviour", >rather than "implementation defined" or "unspecified", it is my belief >that they did so intentionally and knowingly. The question is what the intention was. My impression is a decisive reason for declaring something undefined has been if straightforwardly generated code could trap on some architecture. This becomes most apparent when it comes to shifts, where some cases are implementation-defined and some are undefined, and the undefined cases correspond to cases that trap on some architecture. I do not care that much about the language-lawyering about the different names for the incomplete definitions in the C standards, but if an instruction traps, that does not look like nasal demons to me (Ariane 501 customers may disagree, but one can blame the inappropriate handling of the trap, based on the proof that the trap cannot happen). Maybe one of the C language lawyers can explain why they never chose to use "imlementation-defined" or any of the other incompleteness variants when a trap is possible. >And note that in C23 the macro "unreachable()" was added with the sole >semantics being "If a macro invocation unreachable() is reached during >execution, the behavior is undefined" and "The program execution shall >not reach such an invocation". The justification is for better >diagnostics and optimisations. How can "undefined behaviour" lead to better diagnostics given the attitude that "it is your responsibility as a C programmer to make sure that never happens"? Whoever wrote this justfication apparently has a different idea of the meaning of undefined behaviour than you do. Anyway, undefined behaviour in connection with "unreachable()" or "restrict" is not a problem as far as I am concerned. A programmer can just choose to never use "unreachable()" or "restrict", and avoid any undefined behaviours coming from these language features. And when he introduces them, my recommendation is to do it sparingly, only in those places that are relevant to performance. This is in contrast to taking the assumption that undefined behaviour does not happen anywhere, which means that programmers have to check everywhere for the >200 explicitly stated (and who knows how many implied) undefined behaviours in the current C standard. >I don't know whether or not the "founding fathers" of C intended or >expected compilers to optimise on the assumption that UB did not occur. One can look at the code written by Ritchie, Thompson and the other people at Bell Labs. Does it contain undefined behaviour? Very likely. >But I am confident that they considered a program to be broken if >execution reached a point where the behaviour was not defined in an >implementation (something may be UB in the C standards yet defined by an >implementation). If you mean "documented as defined", I doubt it. I expect that they did write programs that rely on the actual code generated by the compiler(s) the used for the program, on the target(s) they used for the program. And of course the C compilers before C89 did not document behaviours as defined that would be undefined by the standard only later. >It is, of course, possible that they did not foresee quite how this >would pan out in modern compilers. In particular, they may not have >predicted "time-travel" optimisations. However, authors of more modern >C standards - say, C11 onwards - know about them and have could have >explicitly outlawed them if they were considered to be invalid. There is no need to outlaw time travel in C standards, because it was never allowed. At least that's what I read here some years ago. Time traveling is a C++, not C property. >For >heavily used compilers, there is a strong (but not overpowering) push >towards backwards compatibility. This is why they have heavy regression >tests, and pre-release versions are tested with large samples of >important existing code. If this gives unexpected results, these must >be dealt with - was it a bug in the new compiler (in which case the fix >is obvious), or was it a bug in the old source code? Those cases are >more complicated - sometimes the old code must be fixed, but sometimes >the incorrect source code is too common, idomatic or important and the >compiler must, in effect, support additional semantics to retain the old >accidental semantics. Yes, my impression is that the pushback after miscompiling "relevant code" has been strong enough that the regression tests now avoid miscompiling that code, and a lot of the "irrelevant" code such as Gforth rides in the slipstream of that. Of course, relevant code like the Linux kernel uses a collection of flags (e.g, -fno-strict-overflow) that define otherwise undefined behaviour, so anybody who wants to ride in the slipstream of that code should use these flags as well, and leave the benchmarking settings (i.e., without these flags) to the benchmarks. >> 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>. > >There are two key problems with UB that stand in the way of this kind of >initiative. One is that many compilers provide consistent (and >sometimes even documented) behaviour for some things that are UB in the >C standards. Code relying on these behaviours is valid and safe, but >non-portable. But different compilers (or the same compiler but >different targets) could easily have different semantics, making it very >difficult to agree on any one choice. Secondly, many programmers write >code on the assumption that certain UB has certain consistent and >reliable behaviour - even though it is not documented anywhere. It is >code like that which could benefit from a "friendly C" (a poor choice of >name, IMHO, but that's entirely subjective) variant. But it is also >such code that makes a "friendly C" variant hard to define - such code >is hard to identify, and the expected behaviour can be even harder to >find, specify, and consistently describe. Such efforts try to achieve more than what is discussed in the part of the C99 rationale cited above, and more than I argue for in <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>; it also tries to solve portability between architectures and compilers. And given that such efforts have not come to fruition, one can conclude that they try to achieve too much. Alternatively, one can see the various flags provided by gcc, such as -fno-strict-aliasing as achieving at least a part of such efforts (not the portability between compilers, in general, but at least between architectures). There is at least one case (-fwrapv vs. -ftrapv) where one can ask gcc for one of several definined behaviours, though. >> 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>. >> > >I think it is entirely reasonable to keep old compiler versions around >and use them for old code. Unfortunately, the various Linux distributions do not agree with you, and do not distribute gcc versions back to 1.0. So, for software distributed as source code, asking for a known-good compiler for IA-32, such as gcc-2.95, is impractical. >I think it is entirely unreasonable to try to specify that new compilers >should have defined specifications to implement the "semantics" that >older compilers used for particular types of undefined behaviour. These >semantics will, for the most part, be poorly defined and can often be >inconsistent - many programs with UB work by luck, not design. On the contrary, the most common cases of undefined behaviour become well-defined. E.g., before gcc ever generated code based on the assumption that signed overflow never happens, it generated addu or equivalent (e.g., addiu or the implied addition in the address computation of a load) for an addition in the C source code; and optimizations preserved this behaviour, e.g., a+(-b) was compiled to subu, not sub. Continuing to generate code that behaves like that is well-defined, and it now even has flags in gcc (-fwrapv and -fwrapv-pointer, which can be combined into -fno-strict-overflow). >> 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. >> > >Linux commits to preserving the /defined/ behaviour of user-space APIs. If you mean that it takes the same work-to-rule approach that the gcc people do when it comes to "irrelevant" code, that's not the case. It commits to preserving the actual behaviour. That is well publicised, e.g. <https://linuxreviews.org/WE_DO_NOT_BREAK_USERSPACE>. Linus Torvalds wrote: |If a change results in user programs breaking, it's a bug in the |kernel. We never EVER blame the user programs. >But if a >particular invalid value of the parameter lets you gain access to >root-owned files, due to a bug in the kernel, you can be very sure that >this user-space behaviour will /not/ be preserved. I don't know if the maintainers of a user program ever reported a bug for closing such a security hole and insisted on preserving the behaviour; I doubt it. If they would, one way to deal with that would be to have a kernel option (compile-time, startup-time, or run-time) for opening the hole, which the default being that the hole is closed. There has been at least one well-known case where the kernel people went to great lengths to preserve a behaviour for a certain userspace program where the other behaviour already also had users (and in this case the kernel-option variant was not satisfactory, so they used something far uglier). This has all been well publicised, which makes me wonder why you are spreading the claims above; either you do not know what you are writing about, or you knowingly spread an untruth. - 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 20 of 24 — ← Prev page 1 … 18 19 [20] 21 22 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web