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 12 of 24 — ← Prev page 1 … 10 11 [12] 13 14 … 24 Next page →
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-24 07:59 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1193dsi$2pbdi$1@dont-email.me> |
| In reply to | #118148 |
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". -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-24 09:29 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <868q4qsjdy.fsf@linuxsc.com> |
| In reply to | #118172 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > 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". Let's call the new behavior type "implementation dependent". Suppose an implementation gives documentation that says "If a program execution would encounter implementation-dependent behavior, then program execution may be affected in ways that are unpredictable, unknown, and/or unreliable." Question: are you okay with that? If not, how would you write a requirement in the C standard to limit the meaning of "you can do whatever you want, but you must document what you do" that gives only as much freedom as you think should be allowed? I think we will find that different people have very different ideas about how much freedom should be allowed in saying what happens. It's a very hard problem.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-25 07:27 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11960cd$3lggg$1@dont-email.me> |
| In reply to | #118173 |
On 9/24/2026 9:29 AM, Tim Rentsch wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > >> 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". > > Let's call the new behavior type "implementation dependent". I am not hung up on the name, so at least for purposes of discussion, OK. > > Suppose an implementation gives documentation that says "If a program > execution would encounter implementation-dependent behavior, then > program execution may be affected in ways that are unpredictable, > unknown, and/or unreliable." > > Question: are you okay with that? If that is the implementation's general response, then, while it might be "legal", then no, I am not happy with it. > If not, how would you write a > requirement in the C standard to limit the meaning of "you can do > whatever you want, but you must document what you do" that gives only > as much freedom as you think should be allowed? I have minimal experience with standards writing, and none with language writing, so I may be off base here. I think that there are many situations where the standard, correctly, doesn't specify anything about what the compiler should do. These are currently called undefined behavior, and the standard essentially lets it go at that - no further documentation required. But in many, but not all, of such cases, the compiler implementer knows what it is going to do. What I am after is that in such cases, the implementer "supplement" the bare words with information that he has that knowledge and he should communicate it to the user. > I think we will find that different people have very different ideas > about how much freedom should be allowed in saying what happens. It's > a very hard problem. Note that I am not trying to restrict "what happens" in any way. What happens is anything that could/would happen under today's definition of undefined behavior. I am just trying to ask the implementer, whenever possible (and I realize that it is not always possible) to elaborate on the bare words "undefined behavior". -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-25 17:12 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119630a$3lmsq$3@dont-email.me> |
| In reply to | #118204 |
On 25/09/2026 16:27, Stephen Fuld wrote: > On 9/24/2026 9:29 AM, Tim Rentsch wrote: >> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> >>> 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". >> >> Let's call the new behavior type "implementation dependent". > > I am not hung up on the name, so at least for purposes of discussion, OK. > >> >> Suppose an implementation gives documentation that says "If a program >> execution would encounter implementation-dependent behavior, then >> program execution may be affected in ways that are unpredictable, >> unknown, and/or unreliable." >> >> Question: are you okay with that? > > If that is the implementation's general response, then, while it might > be "legal", then no, I am not happy with it. > > >> If not, how would you write a >> requirement in the C standard to limit the meaning of "you can do >> whatever you want, but you must document what you do" that gives only >> as much freedom as you think should be allowed? > > I have minimal experience with standards writing, and none with language > writing, so I may be off base here. > > I think that there are many situations where the standard, correctly, > doesn't specify anything about what the compiler should do. These are > currently called undefined behavior, and the standard essentially lets > it go at that - no further documentation required. > > But in many, but not all, of such cases, the compiler implementer knows > what it is going to do. What I am after is that in such cases, the > implementer "supplement" the bare words with information that he has > that knowledge and he should communicate it to the user. > > >> I think we will find that different people have very different ideas >> about how much freedom should be allowed in saying what happens. It's >> a very hard problem. > > Note that I am not trying to restrict "what happens" in any way. What > happens is anything that could/would happen under today's definition of > undefined behavior. I am just trying to ask the implementer, whenever > possible (and I realize that it is not always possible) to elaborate on > the bare words "undefined behavior". > > There is nothing - except time, resources and motivation - preventing C implementations documenting what they do in cases where the C standards say something is UB. Usually the do that as part of specific flags that affect the behaviour - gcc documents what it does on signed integer overflow if you have the "-fwrapv" flag enabled, for example. There are a few other situations where gcc has flags that give specific semantics to classes of UB. But I don't see any point in trying to give a description of "what happens in UB" in cases where you are not picking specific semantics. If you want wrapping signed overflow semantics, the documentation is under "-fwrapv". If you want to halt with a run-time diagnostic, the documentation is there in "-fsantize=signed-integer-overflow". If you want "do whatever you like, such as optimise" semantics, there is obviously no need for documentation. Remember also that once you document something as particular behaviour, it is fixed - there needs to be very strong justification for changing it later. Documentation /does/ restrict what happens. (You could file a bugzilla report asking for a specific page in the manual that covers this sort of thing, rather than having it scattered around the option pages. That would be handy.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-27 11:51 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86ik3qr0ih.fsf@linuxsc.com> |
| In reply to | #118204 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > On 9/24/2026 9:29 AM, Tim Rentsch wrote: [...] >> [...] how would you write a >> requirement in the C standard to limit the meaning of "you can do >> whatever you want, but you must document what you do" that gives only >> as much freedom as you think should be allowed? > > I have minimal experience with standards writing, and none with > language writing, so I may be off base here. > > I think that there are many situations where the standard, correctly, > doesn't specify anything about what the compiler should do. These are > currently called undefined behavior, and the standard essentially lets > it go at that - no further documentation required. > > But in many, but not all, of such cases, the compiler implementer > knows what it is going to do. What I am after is that in such cases, > the implementer "supplement" the bare words with information that he > has that knowledge and he should communicate it to the user. > > >> I think we will find that different people have very different ideas >> about how much freedom should be allowed in saying what happens. It's >> a very hard problem. > > Note that I am not trying to restrict "what happens" in any way. What > happens is anything that could/would happen under today's definition > of undefined behavior. I am just trying to ask the implementer, > whenever possible (and I realize that it is not always possible) to > elaborate on the bare words "undefined behavior". I want to write a short answer here. I trimmed away anything that looked incidental to my reply. The problem you want to solve is not a problem for the C standard; rather it is a problem with compilers and/or compiler writers. Because of that the C standard is not the right place to address it. The job of the C standard is to define the C language, and not to address questions of "how good" C implementations are. This property is a conscious and explicit decision made by the authors of the C standard. Any matters of "quality of implementation" are deliberately not addressed in the standard. I understand that you want to address what you see as a shortcoming in how compilers behave. Unfortunately the C standard is not the right venue to accomplish that, because how individual compilers behave is a quality of implementation concern, and not a question about what is the definition of the C language.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-25 11:16 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvwls9mljt.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118173 |
Tim Rentsch [2026-09-24 09:29:13] wrote:
> Suppose an implementation gives documentation that says "If a program
> execution would encounter implementation-dependent behavior, then
> program execution may be affected in ways that are unpredictable,
> unknown, and/or unreliable."
> Question: are you okay with that?
I'm not. It's not clear what it is that I want, but I know that I want
my undefined behaviors to be more constrained in what they can do.
I'll call "SMUB" my desired version of undefined behavior. It would go
somewhere along the lines of:
In case of a SMUB operation whose result type is T, then the
operation is allowed to return any bit pattern compatible with the
type T, or it can stop the execution of the program with an error.
In case it stops the execution with an the error, that it is
acceptable if the error doesn't occur exactly at the time the
operation would have taken place (i.e it can occur at any later
time, but also at an earlier time provided we already know that the
SMUB operation would take place anyway).
A SMUB operation that is normally pure is not allowed to mutate
anything. And a SMUB operation that normally mutates one memory
cell of type T is allowed to mutate any *one* memory cell of same
size as type T by putting into it a bit pattern compatible with the
type T.
In the case of `unreachable()`, that means the only thing it would be
allowed to do is to signal an error (at any point of the execution once
we know that `unreachable()` would be executed) or do nothing. IOW, if
it's executed and does not signal an error, the rest of the code may not
be optimized under the assumption that it was not (nor will not
be) executed.
=== Stefan
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-25 19:00 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11969ba$3lmsq$5@dont-email.me> |
| In reply to | #118213 |
On 25/09/2026 17:16, Stefan Monnier wrote:
> Tim Rentsch [2026-09-24 09:29:13] wrote:
>> Suppose an implementation gives documentation that says "If a program
>> execution would encounter implementation-dependent behavior, then
>> program execution may be affected in ways that are unpredictable,
>> unknown, and/or unreliable."
>> Question: are you okay with that?
>
> I'm not. It's not clear what it is that I want, but I know that I want
> my undefined behaviors to be more constrained in what they can do.
>
> I'll call "SMUB" my desired version of undefined behavior. It would go
> somewhere along the lines of:
>
> In case of a SMUB operation whose result type is T, then the
> operation is allowed to return any bit pattern compatible with the
> type T, or it can stop the execution of the program with an error.
> In case it stops the execution with an the error, that it is
> acceptable if the error doesn't occur exactly at the time the
> operation would have taken place (i.e it can occur at any later
> time, but also at an earlier time provided we already know that the
> SMUB operation would take place anyway).
>
> A SMUB operation that is normally pure is not allowed to mutate
> anything. And a SMUB operation that normally mutates one memory
> cell of type T is allowed to mutate any *one* memory cell of same
> size as type T by putting into it a bit pattern compatible with the
> type T.
That sounds somewhat like "erroneous behaviour" in C++.
<https://cppreference.com/cpp/language/ub>
It also sounds like what C has for conversion of an out-of-range value
to a signed integer type - "either the result is implementation-defined
or an implementation-defined signal is raised."
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. I have no issues with you wanting that, but I
don't want /my/ compilations to be limited by it.
And in fits what you have today in some cases, such as signed integer
overflow in gcc - you can choose "-fwrapv", or you can choose
"-fsanitize=signed-integer-overflow", or you can choose optimisation on
the assumption that the code is correct. That's the best of all worlds
as I see it, and forcing choices in the standards would limit that.
>
> In the case of `unreachable()`, that means the only thing it would be
> allowed to do is to signal an error (at any point of the execution once
> we know that `unreachable()` would be executed) or do nothing. IOW, if
> it's executed and does not signal an error, the rest of the code may not
> be optimized under the assumption that it was not (nor will not
> be) executed.
You would only put "unreachable()" in your code at a spot where you do
not expect execution to reach. So if it has got there, your code is
broken - you have no control of what it is doing.
If I write :
// classify must only be called with x between 0 and 100
int classify(int x) {
if (x < 10) return 0;
if (x < 30) return 1;
if (x <= 100) return 2;
unreachable();
}
and then use it as:
int vs[3];
// do_something must only be called with x between 0 and 100
void do_something(int x, int y) {
vs[classify(x)] = y;
}
what is the compiler supposed to do with the "unreachable()" if you are
not halting with an error? Is it supposed to guess that it must return
a value between 0 and 2 inclusive? Should it return an unspecified
value? There's a good chance that with a "do nothing" optimisation, it
would return an unchanged "x" - leading to a stomp of some random place
in memory.
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. You either have
to be very limiting (like "evaluate to an unspecified value") and add
extra manual checks in your code for validity, or accept UB. Other
options are too vague, and there is always scope for the bad behaviour
to amplify out of any hope of control.
If I wanted to terminate immediately, I'd write :
fprintf(stderr, "The programmer has screwed up\n");
exit(1);
We can do that already. I don't want "unreachable()" to duplicate that,
I want it to mean something else.
By all means make a macro that lets you choose between such actions
depending on whether you are doing fault-finding or want highly
optimised code.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-25 18:12 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <5QytS.300$s_2.139@fx24.iad> |
| In reply to | #118214 |
David Brown <david.brown@hesbynett.no> writes:
>On 25/09/2026 17:16, Stefan Monnier wrote:
>> Tim Rentsch [2026-09-24 09:29:13] wrote:
>>> Suppose an implementation gives documentation that says "If a program
>>> execution would encounter implementation-dependent behavior, then
>>> program execution may be affected in ways that are unpredictable,
>>> unknown, and/or unreliable."
>>> Question: are you okay with that?
>>
>> I'm not. It's not clear what it is that I want, but I know that I want
>> my undefined behaviors to be more constrained in what they can do.
>>
>> I'll call "SMUB" my desired version of undefined behavior. It would go
>> somewhere along the lines of:
>>
>> In case of a SMUB operation whose result type is T, then the
>> operation is allowed to return any bit pattern compatible with the
>> type T, or it can stop the execution of the program with an error.
>> In case it stops the execution with an the error, that it is
>> acceptable if the error doesn't occur exactly at the time the
>> operation would have taken place (i.e it can occur at any later
>> time, but also at an earlier time provided we already know that the
>> SMUB operation would take place anyway).
>>
>> A SMUB operation that is normally pure is not allowed to mutate
>> anything. And a SMUB operation that normally mutates one memory
>> cell of type T is allowed to mutate any *one* memory cell of same
>> size as type T by putting into it a bit pattern compatible with the
>> type T.
>
>That sounds somewhat like "erroneous behaviour" in C++.
>
><https://cppreference.com/cpp/language/ub>
>
>It also sounds like what C has for conversion of an out-of-range value
>to a signed integer type - "either the result is implementation-defined
>or an implementation-defined signal is raised."
>
>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. I have no issues with you wanting that, but I
>don't want /my/ compilations to be limited by it.
>
>And in fits what you have today in some cases, such as signed integer
>overflow in gcc - you can choose "-fwrapv", or you can choose
>"-fsanitize=signed-integer-overflow", or you can choose optimisation on
>the assumption that the code is correct. That's the best of all worlds
>as I see it, and forcing choices in the standards would limit that.
>
>>
>> In the case of `unreachable()`, that means the only thing it would be
>> allowed to do is to signal an error (at any point of the execution once
>> we know that `unreachable()` would be executed) or do nothing. IOW, if
>> it's executed and does not signal an error, the rest of the code may not
>> be optimized under the assumption that it was not (nor will not
>> be) executed.
>
>You would only put "unreachable()" in your code at a spot where you do
>not expect execution to reach. So if it has got there, your code is
>broken - you have no control of what it is doing.
>
>If I write :
>
> // classify must only be called with x between 0 and 100
> int classify(int x) {
> if (x < 10) return 0;
> if (x < 30) return 1;
> if (x <= 100) return 2;
> unreachable();
While I dislike 'assert' immensely (it is rude IMO),
it seems far better to just assert(x <= 100) upon function entry
rather than relying on whatever the compiler might do with
an 'unreachable' declaration.
C++26 style contracts may find their way into C someday....
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-26 10:25 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwvjyo8yv7k.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118214 |
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! Remember, we're starting from the problem that UB is used by compilers in ways which catch programmers off-guard. My SMUB proposal is an attempt to define something which I hope is closer to what programmers expect. 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`. > 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. > 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. 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. > 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. A halfway point might be for the compiler to emit a warning when it can't show that `unreachable()` is indeed unreachable. [ 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. ] === Stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-27 13:42 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119b6fd$1buj2$1@dont-email.me> |
| In reply to | #118232 |
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:
Date & Time : 27 Sep 2026 12:13:00
Test Name : gfortran-Ofast
Compile Command : gfortran -march=native -mtune=native -Ofast %n.f90 -o %n
Benchmarks : ac aermod air capacita channel2 doduc fatigue2 gas_dyn2 induct2 linpk mdbx mp_prop_design nf protein -rnflow test_fpu2 tfft2
Maximum Times : 10000.0
Target Error % : 0.200
Minimum Repeats : 10
Maximum Repeats : 100
Benchmark Compile Executable Ave Run Number Estim
Name (secs) (bytes) (secs) Repeats Err %
--------- ------- ---------- ------- ------- ------
ac 0.65 38616 4.54 13 0.1876
aermod 24.66 1074024 3.26 15 0.1773
air 2.96 94920 0.89 19 0.1560
capacita 3.97 127104 5.99 18 0.1858
channel2 0.40 26584 40.47 10 0.1494
doduc 4.61 164768 4.43 13 0.1230
fatigue2 1.50 69200 30.37 11 0.1968
gas_dyn2 1.59 74456 38.17 19 0.1610
induct2 4.63 220280 12.26 10 0.1702
linpk 0.53 30328 1.88 14 0.1842
mdbx 1.87 82200 3.02 10 0.1662
mp_prop_desi 0.75 39568 33.30 19 0.1536
nf 0.75 34848 3.03 18 0.1680
protein 2.32 94640 10.60 15 0.1572
-rnflow 0.00 0 -1.00 15 0.1572
test_fpu2 2.45 76648 16.08 16 0.1926
tfft2 0.97 43000 13.08 16 0.1436
Geometric Mean Execution Time = 10.57 seconds
Date & Time : 27 Sep 2026 13:45:57
Test Name : wrapv
Compile Command : gfortran -fwrapv -march=native -mtune=native -Ofast %n.f90 -o %n
Benchmarks : ac aermod air capacita channel2 doduc fatigue2 gas_dyn2 induct2 linpk mdbx mp_prop_design nf protein -rnflow test_fpu2 tfft2
Maximum Times : 10000.0
Target Error % : 0.200
Minimum Repeats : 10
Maximum Repeats : 100
Benchmark Compile Executable Ave Run Number Estim
Name (secs) (bytes) (secs) Repeats Err %
--------- ------- ---------- ------- ------- ------
ac 0.64 38616 4.50 10 0.1097
aermod 27.17 1118976 3.20 10 0.1696
air 3.40 111024 1.33 22 0.1867
capacita 2.98 102528 6.87 16 0.1163
channel2 0.37 26584 42.15 10 0.1187
doduc 4.34 152376 4.58 16 0.1956
fatigue2 1.53 69200 30.29 10 0.1952
gas_dyn2 1.59 74456 38.47 14 0.1602
induct2 4.13 199800 12.35 12 0.1728
linpk 0.50 30328 2.65 12 0.1263
mdbx 2.11 90352 3.25 10 0.0611
mp_prop_desi 0.72 35248 33.36 10 0.0438
nf 0.72 34848 4.19 10 0.1412
protein 2.30 90544 10.94 10 0.1665
-rnflow 0.00 0 -1.00 10 0.1665
test_fpu2 2.36 76648 15.57 10 0.1457
tfft2 0.52 26616 20.11 13 0.1603
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.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-27 18:18 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260927181805.0000132e@yahoo.com> |
| In reply to | #118247 |
On Sun, 27 Sep 2026 13:42:05 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> 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: > > Date & Time : 27 Sep 2026 12:13:00 > Test Name : gfortran-Ofast > Compile Command : gfortran -march=native -mtune=native -Ofast %n.f90 > -o %n Benchmarks : ac aermod air capacita channel2 doduc > fatigue2 gas_dyn2 induct2 linpk mdbx mp_prop_design nf protein > -rnflow test_fpu2 tfft2 Maximum Times : 10000.0 Target Error % > : 0.200 Minimum Repeats : 10 > Maximum Repeats : 100 > > Benchmark Compile Executable Ave Run Number Estim > Name (secs) (bytes) (secs) Repeats Err % > --------- ------- ---------- ------- ------- ------ > ac 0.65 38616 4.54 13 0.1876 > aermod 24.66 1074024 3.26 15 0.1773 > air 2.96 94920 0.89 19 0.1560 > capacita 3.97 127104 5.99 18 0.1858 > channel2 0.40 26584 40.47 10 0.1494 > doduc 4.61 164768 4.43 13 0.1230 > fatigue2 1.50 69200 30.37 11 0.1968 > gas_dyn2 1.59 74456 38.17 19 0.1610 > induct2 4.63 220280 12.26 10 0.1702 > linpk 0.53 30328 1.88 14 0.1842 > mdbx 1.87 82200 3.02 10 0.1662 > mp_prop_desi 0.75 39568 33.30 19 0.1536 > nf 0.75 34848 3.03 18 0.1680 > protein 2.32 94640 10.60 15 0.1572 > -rnflow 0.00 0 -1.00 15 0.1572 > test_fpu2 2.45 76648 16.08 16 0.1926 > tfft2 0.97 43000 13.08 16 0.1436 > > Geometric Mean Execution Time = 10.57 seconds > > Date & Time : 27 Sep 2026 13:45:57 > Test Name : wrapv > Compile Command : gfortran -fwrapv -march=native -mtune=native -Ofast > %n.f90 -o %n Benchmarks : ac aermod air capacita channel2 doduc > fatigue2 gas_dyn2 induct2 linpk mdbx mp_prop_design nf protein > -rnflow test_fpu2 tfft2 Maximum Times : 10000.0 Target Error % > : 0.200 Minimum Repeats : 10 > Maximum Repeats : 100 > > Benchmark Compile Executable Ave Run Number Estim > Name (secs) (bytes) (secs) Repeats Err % > --------- ------- ---------- ------- ------- ------ > ac 0.64 38616 4.50 10 0.1097 > aermod 27.17 1118976 3.20 10 0.1696 > air 3.40 111024 1.33 22 0.1867 > capacita 2.98 102528 6.87 16 0.1163 > channel2 0.37 26584 42.15 10 0.1187 > doduc 4.34 152376 4.58 16 0.1956 > fatigue2 1.53 69200 30.29 10 0.1952 > gas_dyn2 1.59 74456 38.47 14 0.1602 > induct2 4.13 199800 12.35 12 0.1728 > linpk 0.50 30328 2.65 12 0.1263 > mdbx 2.11 90352 3.25 10 0.0611 > mp_prop_desi 0.72 35248 33.36 10 0.0438 > nf 0.72 34848 4.19 10 0.1412 > protein 2.30 90544 10.94 10 0.1665 > -rnflow 0.00 0 -1.00 10 0.1665 > test_fpu2 2.36 76648 15.57 10 0.1457 > tfft2 0.52 26616 20.11 13 0.1603 > > 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. My understanding is that in Fortran array indexes are by default 32-bit. That couses real cost under wrapv. In C there is no such thing as default size of array index. 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-27 18:04 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119bepl$1fl0g$1@dont-email.me> |
| In reply to | #118251 |
On 27/09/2026 17:18, Michael S wrote: > > Fortran is not the same as C. > My understanding is that in Fortran array indexes are by default 32-bit. > That couses real cost under wrapv. > In C there is no such thing as default size of array index. 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. > You certainly /can/ do that. But a lot of C code uses "int" for array indexing. The "ideal" type in many cases would be "int_fast32_t" to say it should be of a big enough size (32-bit is enough range for a great many purposes) but can bigger if that's faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. The thing you want is that your loops with "a[i++]" operations are implemented as "*p++" rather than "*(a + i); i = (i + 1) & 0xffff'ffff)". The later is what you end up with if you use an unsigned 32-bit type or a signed 32-bit type with forced wrapping semantics. So you can either use a 64-bit type (signed or unsigned), or use normal 32-bit "int" as usual, but without forcing wrapping semantics on it.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-27 19:43 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260927194301.0000194f@yahoo.com> |
| In reply to | #118255 |
On Sun, 27 Sep 2026 18:04:05 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 27/09/2026 17:18, Michael S wrote: > > > > > Fortran is not the same as C. > > My understanding is that in Fortran array indexes are by default > > 32-bit. That couses real cost under wrapv. > > In C there is no such thing as default size of array index. 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. > > > > You certainly /can/ do that. But a lot of C code uses "int" for > array indexing. The "ideal" type in many cases would be > "int_fast32_t" to say it should be of a big enough size (32-bit is > enough range for a great many purposes) but can bigger if that's > faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. > That's not universal. For example, on both alive 64-bit Windows targets int_fast32_t is 32-bit. Godbolt shows the same for clang for MIPS64. I have no idea what OS it targets. Besides, int_fast32_t is both above my threshold of acceptable ugliness and acceptable geekery. > The thing you want is that your loops with "a[i++]" operations are > implemented as "*p++" rather than "*(a + i); i = (i + 1) & > 0xffff'ffff)". The later is what you end up with if you use an > unsigned 32-bit type or a signed 32-bit type with forced wrapping > semantics. > > So you can either use a 64-bit type (signed or unsigned), or use > normal 32-bit "int" as usual, but without forcing wrapping semantics > on it. > >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-27 10:55 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86mrt2r33i.fsf@linuxsc.com> |
| In reply to | #118256 |
Michael S <already5chosen@yahoo.com> writes: > On Sun, 27 Sep 2026 18:04:05 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 27/09/2026 17:18, Michael S wrote: >> >>> Fortran is not the same as C. >>> My understanding is that in Fortran array indexes are by default >>> 32-bit. That couses real cost under wrapv. >>> In C there is no such thing as default size of array index. 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. >> >> You certainly /can/ do that. But a lot of C code uses "int" for >> array indexing. The "ideal" type in many cases would be >> "int_fast32_t" to say it should be of a big enough size (32-bit is >> enough range for a great many purposes) but can bigger if that's >> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. > > That's not universal. > For example, on both alive 64-bit Windows targets int_fast32_t is > 32-bit. > Godbolt shows the same for clang for MIPS64. I have no idea what OS it > targets. > > Besides, int_fast32_t is both above my threshold of acceptable ugliness > and acceptable geekery. I favor a type equivalent to size_t for use as array index variables.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-27 22:12 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119btc7$1n32h$1@dont-email.me> |
| In reply to | #118261 |
Tim Rentsch wrote: > Michael S <already5chosen@yahoo.com> writes: > >> On Sun, 27 Sep 2026 18:04:05 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> On 27/09/2026 17:18, Michael S wrote: >>> >>>> Fortran is not the same as C. >>>> My understanding is that in Fortran array indexes are by default >>>> 32-bit. That couses real cost under wrapv. >>>> In C there is no such thing as default size of array index. 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. >>> >>> You certainly /can/ do that. But a lot of C code uses "int" for >>> array indexing. The "ideal" type in many cases would be >>> "int_fast32_t" to say it should be of a big enough size (32-bit is >>> enough range for a great many purposes) but can bigger if that's >>> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. >> >> That's not universal. >> For example, on both alive 64-bit Windows targets int_fast32_t is >> 32-bit. >> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >> targets. >> >> Besides, int_fast32_t is both above my threshold of acceptable ugliness >> and acceptable geekery. > > I favor a type equivalent to size_t for use as array index variables. > In Rust, the only acceptable array index is of type "usize", which is effectively the same as u64 on most platforms these days, but does not need to be so: On a 32-bit target, it would be the same as u32. So effectively very similar to size_t. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-28 02:59 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86bj9hr91x.fsf@linuxsc.com> |
| In reply to | #118263 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > Tim Rentsch wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sun, 27 Sep 2026 18:04:05 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> On 27/09/2026 17:18, Michael S wrote: >>>> >>>>> Fortran is not the same as C. >>>>> My understanding is that in Fortran array indexes are by default >>>>> 32-bit. That couses real cost under wrapv. >>>>> In C there is no such thing as default size of array index. 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. >>>> >>>> You certainly /can/ do that. But a lot of C code uses "int" for >>>> array indexing. The "ideal" type in many cases would be >>>> "int_fast32_t" to say it should be of a big enough size (32-bit is >>>> enough range for a great many purposes) but can bigger if that's >>>> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. >>> >>> That's not universal. >>> For example, on both alive 64-bit Windows targets int_fast32_t is >>> 32-bit. >>> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >>> targets. >>> >>> Besides, int_fast32_t is both above my threshold of acceptable ugliness >>> and acceptable geekery. >> >> I favor a type equivalent to size_t for use as array index variables. > > In Rust, the only acceptable array index is of type "usize", which is > effectively the same as u64 on most platforms these days, but does not > need to be so: On a 32-bit target, it would be the same as u32. > > So effectively very similar to size_t. Maybe that limitation works okay in Rust. In C sometimes it's important to allow a signed value for indexing. Probably 99% of the time size_t is good, but not always.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-28 14:43 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119dne7$2baig$1@dont-email.me> |
| In reply to | #118285 |
Tim Rentsch wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> Tim Rentsch wrote: >> >>> Michael S <already5chosen@yahoo.com> writes: >>> >>>> On Sun, 27 Sep 2026 18:04:05 +0200 >>>> David Brown <david.brown@hesbynett.no> wrote: >>>> >>>>> On 27/09/2026 17:18, Michael S wrote: >>>>> >>>>>> Fortran is not the same as C. >>>>>> My understanding is that in Fortran array indexes are by default >>>>>> 32-bit. That couses real cost under wrapv. >>>>>> In C there is no such thing as default size of array index. 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. >>>>> >>>>> You certainly /can/ do that. But a lot of C code uses "int" for >>>>> array indexing. The "ideal" type in many cases would be >>>>> "int_fast32_t" to say it should be of a big enough size (32-bit is >>>>> enough range for a great many purposes) but can bigger if that's >>>>> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. >>>> >>>> That's not universal. >>>> For example, on both alive 64-bit Windows targets int_fast32_t is >>>> 32-bit. >>>> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >>>> targets. >>>> >>>> Besides, int_fast32_t is both above my threshold of acceptable ugliness >>>> and acceptable geekery. >>> >>> I favor a type equivalent to size_t for use as array index variables. >> >> In Rust, the only acceptable array index is of type "usize", which is >> effectively the same as u64 on most platforms these days, but does not >> need to be so: On a 32-bit target, it would be the same as u32. >> >> So effectively very similar to size_t. > > Maybe that limitation works okay in Rust. In C sometimes it's > important to allow a signed value for indexing. Probably 99% of > the time size_t is good, but not always. > The fact that array indices are unsigned is one of the more crucial underpinnings of Rust safety. Even more importantly, all such indices are verified against the actual array upper boundary. When the compiler can prove to itself that such accesses are always safe, then the coded check can be omitted. Just like Java, a single test outside of a for loop can replace testing in every iteration. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 07:14 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86h5j5pky9.fsf@linuxsc.com> |
| In reply to | #118288 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > Tim Rentsch wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>> Tim Rentsch wrote: [...] >>>> I favor a type equivalent to size_t for use as array index variables. >>> >>> In Rust, the only acceptable array index is of type "usize", which is >>> effectively the same as u64 on most platforms these days, but does not >>> need to be so: On a 32-bit target, it would be the same as u32. >>> >>> So effectively very similar to size_t. >> >> Maybe that limitation works okay in Rust. In C sometimes it's >> important to allow a signed value for indexing. Probably 99% of >> the time size_t is good, but not always. > > The fact that array indices are unsigned is one of the more crucial > underpinnings of Rust safety. Even more importantly, all such indices > are verified against the actual array upper boundary. [...] It's nice that array index values are checked against the array bounds. But given that the checks are put in by the compiler, it seems rather silly to insist that index expressions have type usize, especially when a common remedy is just to add a cast. It's like saying the car won't start unless you take off your seatbelt.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 11:36 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a024r$f52$1@reader2.panix.com> |
| In reply to | #118352 |
In article <86h5j5pky9.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> Tim Rentsch wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>>> Tim Rentsch wrote: >[...] >>>>> I favor a type equivalent to size_t for use as array index variables. >>>> >>>> In Rust, the only acceptable array index is of type "usize", which is >>>> effectively the same as u64 on most platforms these days, but does not >>>> need to be so: On a 32-bit target, it would be the same as u32. >>>> >>>> So effectively very similar to size_t. >>> >>> Maybe that limitation works okay in Rust. In C sometimes it's >>> important to allow a signed value for indexing. Probably 99% of >>> the time size_t is good, but not always. >> >> The fact that array indices are unsigned is one of the more crucial >> underpinnings of Rust safety. Even more importantly, all such indices >> are verified against the actual array upper boundary. [...] > >It's nice that array index values are checked against the array >bounds. Terje was actually incorrect here; bounds checks are added in debug mode, but are (usually) removed in optimized builds. >But given that the checks are put in by the compiler, it seems >rather silly to insist that index expressions have type usize, >especially when a common remedy is just to add a cast. It's like >saying the car won't start unless you take off your seatbelt. I don't know why you would say that. The point is that Rust is strongly, statically typed and the type of an arrray index is well-defined as `usize`. Being intentional in what one writes is an important aspect of being a proficient Rust programmer. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-10-05 16:48 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <niho4rFdtsnU1@mid.individual.net> |
| In reply to | #118474 |
On 2026-10-05 14:36, Dan Cross wrote: > In article <86h5j5pky9.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>> Tim Rentsch wrote: >>> >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>> >>>>> Tim Rentsch wrote: >> [...] >>>>>> I favor a type equivalent to size_t for use as array index variables. >>>>> >>>>> In Rust, the only acceptable array index is of type "usize", which is >>>>> effectively the same as u64 on most platforms these days, but does not >>>>> need to be so: On a 32-bit target, it would be the same as u32. >>>>> >>>>> So effectively very similar to size_t. >>>> >>>> Maybe that limitation works okay in Rust. In C sometimes it's >>>> important to allow a signed value for indexing. Probably 99% of >>>> the time size_t is good, but not always. >>> >>> The fact that array indices are unsigned is one of the more crucial >>> underpinnings of Rust safety. Even more importantly, all such indices >>> are verified against the actual array upper boundary. [...] >> >> It's nice that array index values are checked against the array >> bounds. > > Terje was actually incorrect here; bounds checks are added in > debug mode, but are (usually) removed in optimized builds. > >> But given that the checks are put in by the compiler, it seems >> rather silly to insist that index expressions have type usize, >> especially when a common remedy is just to add a cast. It's like >> saying the car won't start unless you take off your seatbelt. > > I don't know why you would say that. The point is that Rust is > strongly, statically typed and the type of an arrray index is > well-defined as `usize`. Being intentional in what one writes > is an important aspect of being a proficient Rust programmer. The Ada language and its relatives are, arguably, even more strongly typed in the array-indexing area, because different array types can have different index types, and the declaration of an array type also specifies the type of the index. When combined with range-constrained types and subtypes, this means that the bounds check can often be done statically, at compile time, and the remaining run-time checks (if any) are usually not significant for performance.
[toc] | [prev] | [next] | [standalone]
Page 12 of 24 — ← Prev page 1 … 10 11 [12] 13 14 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web