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 21 of 24 — ← Prev page 1 … 19 20 [21] 22 23 24 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-25 14:36 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <6GvtS.5$MR2.1@fx39.iad> |
| In reply to | #118199 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >David Brown <david.brown@hesbynett.no> writes: >>I have never spoken to the C standards committee or writers, either of >>current standard versions or the original C89 standard, or writers of >>pre-standard C specifications. So I cannot in any way claim to know >>their thoughts or motivations. I also have not seen any documentation >>that suggests what they might have thought about "optimisation on the >>assumption that undefined behaviour does not occur" - in either >>direction. > >When C89 was developed, the dominating C compiler in the Unix world >was PCC. GCC came on the scene late in the game (1988), without such >assumptions and produced a significant performance advantage. Well, yes. PCC at that point was 14 years old and showing its age. Motorola used PCC for the 88100 processor (I had to fix a bug in the register allocator when compiling the output of cfront, which extensively uses the comma operator in 1990); I had first used PCC in 1981.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-25 14:45 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <ZNvtS.8$MR2.1@fx39.iad> |
| In reply to | #118205 |
scott@slp53.sl.home (Scott Lurndal) writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>David Brown <david.brown@hesbynett.no> writes: > >>>I have never spoken to the C standards committee or writers, either of >>>current standard versions or the original C89 standard, or writers of >>>pre-standard C specifications. So I cannot in any way claim to know >>>their thoughts or motivations. I also have not seen any documentation >>>that suggests what they might have thought about "optimisation on the >>>assumption that undefined behaviour does not occur" - in either >>>direction. >> >>When C89 was developed, the dominating C compiler in the Unix world >>was PCC. GCC came on the scene late in the game (1988), without such >>assumptions and produced a significant performance advantage. > >Well, yes. PCC at that point was 14 years old and showing its age. > >Motorola used PCC for the 88100 processor (I had to fix a bug in the >register allocator when compiling the output of cfront, which >extensively uses the comma operator in 1990); I had first used PCC in >1981. I'll add that by 1989, AT&T/USL had a much more sophisticated C compiler for SVR4 and later Unixware. $ ls /usr/src/common/cmd/sgs acomp amigo ccsdemos cof2elf cpluspatch dis inc lex libsgs m4 optim strip yacc acpp ar cg cplusfe cpp dump intemu libelf lorder mcs sgs.install tsort alint as cmd cplusinc demangler fpemu ld libld lprof nm size unix_conv
[toc] | [prev] | [next] | [standalone]
| From | aph@littlepinkcloud.invalid |
|---|---|
| Date | 2026-10-04 08:15 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <IySdncOTp_Kpll_3nZ2dnZfqnPWdnZ2d@supernews.com> |
| In reply to | #118199 |
David Brown <david.brown@hesbynett.no> wrote:
> On 25/09/2026 07:39, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 21/09/2026 19:17, Anton Ertl wrote:
>>>> I referred to a specific paradoxical effect, not completely avoiding
>>>> all of them: The effect of programmers who, instead of working on
>>>> making the code faster through source-level changes, have to invest
>>>> time into avoiding getting it miscompiled.
>>>>
>>>
>>> By "miscompiled", do you mean incorrect object code, or object code that
>>> did not have the performance the programmer expected or hoped for?
>>
>> Code that behaves differently than intended, e.g., where a bounds check
>> is "optimized" away.
>>
>
> The trouble with that is determining precisely what was intended.
> Compilers are limited - the programmer has to express their intention in
> the restricted form of the programming language (C or whatever else).
> And the /only/ things that can be relied on to have a clear meaning are
> things that have clear defined behaviour as documented by the language
> standards or the compiler documentation.
>
> A program is a contract between the programmer and the compiler - the
> programmer promises to provide good code with a clearly defined meaning,
> and the compiler promises to give object code that implements that
> defined meaning. If the programmer breaks their side of the contract by
> writing code that does not have a clear meaning (at compile-time or
> run-time), the compiler /cannot/ fulfil its side of the contract. It is
> unable to generate "correct" object code from incorrect source code.
>
> If the programmer writes "a = b + c;" (all signed int), what is the
> intention? Does the programmer mean "generate an ADD assembly
> instruction"? Does he/she mean "I don't care how it happens, but 'a'
> should be the sum of 'b' and 'c'"? Do they mean "give me a two's
> complement wrapped addition"? Do they mean "I promise there will be no
> overflow" ? Do they mean "I /hope/ there will be no overflow" ? Or
> "While I am debugging, let me know if there is an overflow" ?
>
> The programmer might have intended lots of subtly different things from
> the same bit of code. But compilers cannot work by mind-reading. The
> only thing that the /code/ intends is "Add these two numbers. I promise
> there will be no overflow". Whatever the programmer imagines, that is
> the intention of the code. The compiler's job is to follow that - and
> if the programmer breaks his promise, it is garbage in, garbage out.
>
>
> I find the whole concept of optimising based on "what the programmer
> intended", rather than what the code they wrote means, somewhat
> hypocritical. The idea that "a = b + c;" should "obviously" wrap on a
> two's complement machine, while "a = b + 10 + c - 10;" should
> "obviously" optimise away the constants is clearly contradictory. It is
> an attitude that is denying responsibility - claiming "the compiler
> broke my code" rather than understanding "my code had mistakes but
> previously gave the right results by luck".
>
> I am not underestimating the difficulty of writing correct code here, or
> the frustration and costs involved when the behaviour of real-world code
> changes with different compilers or flags. But it is critical that
> programmers understand the origin of problems in order to deal with the
> issues instead of passing the blame around. Baring compiler bugs (even
> my favourite compiler has one or two outstanding bugs), what you term
> "miscompiling" here is actually errors in the programmers' source code.
>
> The way to improve the situation is not by blaming compiler writers, or
> inventing some kind of vague notion of what programmers "intended" or
> "do what some old compiler did", or limiting optimisations in compilers.
> Instead, it is by improving compilers, run-time checkers and static
> analysis tools to help identify the errors in the source code, improving
> teaching of programming to reduce the risk of such errors, improving
> languages to support lower-risk constructs, changing to programming
> languages with different characteristics, etc. Indeed, I find that
> better compilers with more powerful optimisations means fewer bugs in my
> code because I can write the code in clearer ways and still get
> efficient results in the end.
>
>
>> Performance regressions can be nasty for performance-sensitive code,
>> and consume time for finding a workaround (if one can be found), but
>> is a different thing.
>>
>
> Agreed. And correctness trumps speed every time.
>
>>>>> But as
>>>>> for the problems you mention w.r.t UB, I think it's just the result of
>>>>> poor semantics, for which I guess we (language semanticists) are partly
>>>>> to blame: we have developed fairly good tools to design sane language
>>>>> specs in general,
>>>>
>>>> I violently disagree. The C89 standard (just to name one) is a
>>>> partial specification not because the original C standards people were
>>>> poor at specifying semantics, but because given the differences
>>>> between the compilers out there and the hardware out there, the
>>>> easiest way to reach a consensus is to leave some parts unspecified.
>>>
>>> I have never spoken to the C standards committee or writers, either of
>>> current standard versions or the original C89 standard, or writers of
>>> pre-standard C specifications. So I cannot in any way claim to know
>>> their thoughts or motivations. I also have not seen any documentation
>>> that suggests what they might have thought about "optimisation on the
>>> assumption that undefined behaviour does not occur" - in either
>>> direction.
>>
>> When C89 was developed, the dominating C compiler in the Unix world
>> was PCC. GCC came on the scene late in the game (1988), without such
>> assumptions and produced a significant performance advantage. Only
>> after several years of heavy gcc development assumptions like
>> -fstrict-aliasing were introduced around gcc-2.7 (which was initially
>> disabled by default);
>
> ("-fstrict-aliasing" is still not enabled by default - you have to
> actively enable at least "-O2".)
>
>> I don't know when the assumption that signed
>> integer operations do not overflow was introduced, and initially it
>> could not be disabled (-fwrapv was added around gcc-3.4), so obviously
>> by that time people had taken over the gcc project who had a different
>> view about how undefined behaviour should be treated.
>
> I completely disagree that this is an "obvious" conclusion. While I
> cannot say anything for sure here, the explanation that comes first to
> my mind is that it was part of the natural progression of gcc towards
> more optimisations.
> "-fwrapv" would have been added as a result of complaints about
> problems with old code that made invalid assumptions that happened
> to "work" because older gcc did not have as many optimisations.
"-fwrapv" didn't exist when we started gcj, which used GCC to
implement Java. After some discussion with other GCC maintainers, it
was agreed to add wrapping signed integer semantics to GCC's IR.
"-fwrapv" provides that to C-derived languages too. Whether "-fwrapv"
would have happened without the pull from gcj I can't say. It's
impossible to rerun history.
In hindsight, though, it would have been easy enough to use unsigned
arithmetic within GCC to support gcj.
> I see absolutely no reason to assume that anyone at any time thought
> such optimisations were not valid - they simply had not yet been
> implemented.
I agree.
Andrew.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 12:15 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119t903$3pvpq$1@dont-email.me> |
| In reply to | #118456 |
On 04/10/2026 10:15, aph@littlepinkcloud.invalid wrote: > David Brown <david.brown@hesbynett.no> wrote: >> On 25/09/2026 07:39, Anton Ertl wrote: <snip> >>> I don't know when the assumption that signed >>> integer operations do not overflow was introduced, and initially it >>> could not be disabled (-fwrapv was added around gcc-3.4), so obviously >>> by that time people had taken over the gcc project who had a different >>> view about how undefined behaviour should be treated. >> >> I completely disagree that this is an "obvious" conclusion. While I >> cannot say anything for sure here, the explanation that comes first to >> my mind is that it was part of the natural progression of gcc towards >> more optimisations. > >> "-fwrapv" would have been added as a result of complaints about >> problems with old code that made invalid assumptions that happened >> to "work" because older gcc did not have as many optimisations. > > "-fwrapv" didn't exist when we started gcj, which used GCC to > implement Java. After some discussion with other GCC maintainers, it > was agreed to add wrapping signed integer semantics to GCC's IR. > "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv" > would have happened without the pull from gcj I can't say. It's > impossible to rerun history. > Thanks for that historical information - I had no idea that the implementation of Java was behind that feature of gcc. There are plenty of features (compiler flags, and extensions) of gcc that came about as the result of support of languages other than C and C++. But I did not know about this one. > In hindsight, though, it would have been easy enough to use unsigned > arithmetic within GCC to support gcj. > Yes - there's nothing that I can think of where the effect of "-fwrapv" could not be achieved with equal run-time efficiency by using unsigned types and some casts or other conversions. But if you need wrapping signed integer overflow semantics, then it is obviously neater in the source code to have it directly than to go via unsigned types. >> I see absolutely no reason to assume that anyone at any time thought >> such optimisations were not valid - they simply had not yet been >> implemented. > > I agree. > > Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-04 14:16 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119tn4n$3v9en$1@dont-email.me> |
| In reply to | #118456 |
aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb: > "-fwrapv" didn't exist when we started gcj, which used GCC to > implement Java. After some discussion with other GCC maintainers, it > was agreed to add wrapping signed integer semantics to GCC's IR. > "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv" > would have happened without the pull from gcj I can't say. It's > impossible to rerun history. Linear congruential random number generators, in common use when the dinosaurs roamed the computer centers, depend on wraparound semantics. In gfortran, they stopped working at one time because gcc assuming that this would not happen. -fwrap is a workaround (without changing the source), but of course using the RANDOM_NUMBER intrinsic is better - it also uses a reasonable algorithm. So, some people should probably be grateful to you :-) -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 16:36 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119to9d$3vcal$3@dont-email.me> |
| In reply to | #118460 |
On 04/10/2026 16:16, Thomas Koenig wrote: > aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb: > >> "-fwrapv" didn't exist when we started gcj, which used GCC to >> implement Java. After some discussion with other GCC maintainers, it >> was agreed to add wrapping signed integer semantics to GCC's IR. >> "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv" >> would have happened without the pull from gcj I can't say. It's >> impossible to rerun history. > > Linear congruential random number generators, in common use when > the dinosaurs roamed the computer centers, depend on wraparound > semantics. In gfortran, they stopped working at one time because > gcc assuming that this would not happen. -fwrap is a workaround > (without changing the source), but of course using the RANDOM_NUMBER > intrinsic is better - it also uses a reasonable algorithm. > > So, some people should probably be grateful to you :-) > Do unsigned types in Fortran not have wrapping semantics? Or are there no unsigned integer types in Fortran? I know not every language has the same distinction as C here.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-04 17:46 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119u3di$4edt$1@dont-email.me> |
| In reply to | #118461 |
David Brown <david.brown@hesbynett.no> schrieb: > On 04/10/2026 16:16, Thomas Koenig wrote: >> aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb: >> >>> "-fwrapv" didn't exist when we started gcj, which used GCC to >>> implement Java. After some discussion with other GCC maintainers, it >>> was agreed to add wrapping signed integer semantics to GCC's IR. >>> "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv" >>> would have happened without the pull from gcj I can't say. It's >>> impossible to rerun history. >> >> Linear congruential random number generators, in common use when >> the dinosaurs roamed the computer centers, depend on wraparound >> semantics. In gfortran, they stopped working at one time because >> gcc assuming that this would not happen. -fwrap is a workaround >> (without changing the source), but of course using the RANDOM_NUMBER >> intrinsic is better - it also uses a reasonable algorithm. >> >> So, some people should probably be grateful to you :-) >> > > Do unsigned types in Fortran not have wrapping semantics? Or are there > no unsigned integer types in Fortran? I know not every language has the > same distinction as C here. The Fortran language has no unsigned types. Two compilers, gfortran and flang, implement a suggestion that I made to J3 (much improved by some people on the committee) and was accepted, but not taken up by WG5. At the time, I had already started implementing it, so I went ahead and completed it anyway, see https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html (You can probably tell that this is still a sore point.) But what the pseudo-random number generators did was use *signed* overflow, which had been prohibited by the standard forever, but because people needed something and it worked, they went ahead and did it anyway. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-04 20:04 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119u4g1$5280$1@dont-email.me> |
| In reply to | #118464 |
On 04/10/2026 19:46, Thomas Koenig wrote: > David Brown <david.brown@hesbynett.no> schrieb: >> On 04/10/2026 16:16, Thomas Koenig wrote: >>> aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb: >>> >>>> "-fwrapv" didn't exist when we started gcj, which used GCC to >>>> implement Java. After some discussion with other GCC maintainers, it >>>> was agreed to add wrapping signed integer semantics to GCC's IR. >>>> "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv" >>>> would have happened without the pull from gcj I can't say. It's >>>> impossible to rerun history. >>> >>> Linear congruential random number generators, in common use when >>> the dinosaurs roamed the computer centers, depend on wraparound >>> semantics. In gfortran, they stopped working at one time because >>> gcc assuming that this would not happen. -fwrap is a workaround >>> (without changing the source), but of course using the RANDOM_NUMBER >>> intrinsic is better - it also uses a reasonable algorithm. >>> >>> So, some people should probably be grateful to you :-) >>> >> >> Do unsigned types in Fortran not have wrapping semantics? Or are there >> no unsigned integer types in Fortran? I know not every language has the >> same distinction as C here. > > The Fortran language has no unsigned types. Two compilers, gfortran > and flang, implement a suggestion that I made to J3 (much improved > by some people on the committee) and was accepted, but not taken > up by WG5. At the time, I had already started implementing it, > so I went ahead and completed it anyway, see > > https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html > > (You can probably tell that this is still a sore point.) > > But what the pseudo-random number generators did was use *signed* > overflow, which had been prohibited by the standard forever, but > because people needed something and it worked, they went ahead > and did it anyway. > I would guess you'd have trouble writing something that was efficient here, and avoided UB when you don't have language support for wrapping overflow (whether it be for signed or unsigned types). Thanks for the explanation. I can't imagine I'll ever work with Fortran, but it's nice to know more about it anyway.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-06 02:17 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a1loj$3u6ge$5@paganini.bofh.team> |
| In reply to | #118468 |
David Brown <david.brown@hesbynett.no> wrote:
> On 04/10/2026 19:46, Thomas Koenig wrote:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>> On 04/10/2026 16:16, Thomas Koenig wrote:
>>>> aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb:
>>>>
>>>>> "-fwrapv" didn't exist when we started gcj, which used GCC to
>>>>> implement Java. After some discussion with other GCC maintainers, it
>>>>> was agreed to add wrapping signed integer semantics to GCC's IR.
>>>>> "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv"
>>>>> would have happened without the pull from gcj I can't say. It's
>>>>> impossible to rerun history.
>>>>
>>>> Linear congruential random number generators, in common use when
>>>> the dinosaurs roamed the computer centers, depend on wraparound
>>>> semantics. In gfortran, they stopped working at one time because
>>>> gcc assuming that this would not happen. -fwrap is a workaround
>>>> (without changing the source), but of course using the RANDOM_NUMBER
>>>> intrinsic is better - it also uses a reasonable algorithm.
>>>>
>>>> So, some people should probably be grateful to you :-)
>>>>
>>>
>>> Do unsigned types in Fortran not have wrapping semantics? Or are there
>>> no unsigned integer types in Fortran? I know not every language has the
>>> same distinction as C here.
>>
>> The Fortran language has no unsigned types. Two compilers, gfortran
>> and flang, implement a suggestion that I made to J3 (much improved
>> by some people on the committee) and was accepted, but not taken
>> up by WG5. At the time, I had already started implementing it,
>> so I went ahead and completed it anyway, see
>>
>> https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html
>>
>> (You can probably tell that this is still a sore point.)
>>
>> But what the pseudo-random number generators did was use *signed*
>> overflow, which had been prohibited by the standard forever, but
>> because people needed something and it worked, they went ahead
>> and did it anyway.
>>
>
> I would guess you'd have trouble writing something that was efficient
> here, and avoided UB when you don't have language support for wrapping
> overflow (whether it be for signed or unsigned types).
If language supports large enough integers and with reasonable
optimizer code like:
bigint a = 123;
bigint b = 7;
bigint c = 17;
long f() {
a = 0xffffffffffffffff &(a*c + b);
return a;
}
will be compiled using wrapping 64-bit arithmetic. If additionaly
you make sure that a is local to random number module so compiler
knows that it has seen all updates to a, and updates stay within
64 bits than compiler can use 64-bit variables.
But having explicit wrapping types is more direct and easier to
implement, which mattered for dinosaurs.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-06 10:05 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a2a4t$1lqal$4@dont-email.me> |
| In reply to | #118484 |
On 06/10/2026 04:17, Waldek Hebisch wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 04/10/2026 19:46, Thomas Koenig wrote:
>>> David Brown <david.brown@hesbynett.no> schrieb:
>>>> On 04/10/2026 16:16, Thomas Koenig wrote:
>>>>> aph@littlepinkcloud.invalid <aph@littlepinkcloud.invalid> schrieb:
>>>>>
>>>>>> "-fwrapv" didn't exist when we started gcj, which used GCC to
>>>>>> implement Java. After some discussion with other GCC maintainers, it
>>>>>> was agreed to add wrapping signed integer semantics to GCC's IR.
>>>>>> "-fwrapv" provides that to C-derived languages too. Whether "-fwrapv"
>>>>>> would have happened without the pull from gcj I can't say. It's
>>>>>> impossible to rerun history.
>>>>>
>>>>> Linear congruential random number generators, in common use when
>>>>> the dinosaurs roamed the computer centers, depend on wraparound
>>>>> semantics. In gfortran, they stopped working at one time because
>>>>> gcc assuming that this would not happen. -fwrap is a workaround
>>>>> (without changing the source), but of course using the RANDOM_NUMBER
>>>>> intrinsic is better - it also uses a reasonable algorithm.
>>>>>
>>>>> So, some people should probably be grateful to you :-)
>>>>>
>>>>
>>>> Do unsigned types in Fortran not have wrapping semantics? Or are there
>>>> no unsigned integer types in Fortran? I know not every language has the
>>>> same distinction as C here.
>>>
>>> The Fortran language has no unsigned types. Two compilers, gfortran
>>> and flang, implement a suggestion that I made to J3 (much improved
>>> by some people on the committee) and was accepted, but not taken
>>> up by WG5. At the time, I had already started implementing it,
>>> so I went ahead and completed it anyway, see
>>>
>>> https://gcc.gnu.org/onlinedocs/gfortran/Unsigned-integers.html
>>>
>>> (You can probably tell that this is still a sore point.)
>>>
>>> But what the pseudo-random number generators did was use *signed*
>>> overflow, which had been prohibited by the standard forever, but
>>> because people needed something and it worked, they went ahead
>>> and did it anyway.
>>>
>>
>> I would guess you'd have trouble writing something that was efficient
>> here, and avoided UB when you don't have language support for wrapping
>> overflow (whether it be for signed or unsigned types).
>
> If language supports large enough integers and with reasonable
> optimizer code like:
>
> bigint a = 123;
> bigint b = 7;
> bigint c = 17;
> long f() {
> a = 0xffffffffffffffff &(a*c + b);
> return a;
> }
>
> will be compiled using wrapping 64-bit arithmetic. If additionaly
> you make sure that a is local to random number module so compiler
> knows that it has seen all updates to a, and updates stay within
> 64 bits than compiler can use 64-bit variables.
>
> But having explicit wrapping types is more direct and easier to
> implement, which mattered for dinosaurs.
>
Begin direct and easier to write matters to us non-dinosaurs too!
Yes, such "bigint" code should give you correct answers, but
optimisation is not going to be guaranteed. It is likely that you are
going to need a lot of mask operations in your code - its going to be
ugly, or have to use inline functions where infix operators would be
nicer. (Does Fortran have classes with overloaded operators, like C++?)
There are certainly good optimising Fortran compilers.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-19 12:06 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118ltsc$26ss6$1@dont-email.me> |
| In reply to | #118077 |
Paul Clayton <paaronclayton@gmail.com> schrieb: > I suspect algorithmic transformations are discouraged in > compilers under the assumption that the software developer used > appropriate algorithms as well as the compute cost to evaluate > options. Two points: A compiler is restricted by the transformations it can do by the language specification. For example, loop interchanges with floating point calculation can give different results. Unless directed otherwise, the compiler has to assume that this is what the user wants and needs. An exception is something like Fortran's FORALL constuct, where the loop ordering is not specified and the compiler can chose. Intrinsic functions like MATMUL also have no restriction on what they can do internally; they can (and often do) call a highly- optimized BLAS routine. >Usage and hardware information might theoretically be > made available, but I get the impression that most profiling > for compiler use is about path frequency. Compilers tend to focus on lower-level stuff. For example, there is a huge file of simplifying transformations for gcc at https://gcc.gnu.org/git/?p=gcc.git;a=blob_plain;f=gcc/match.pd This now also contains reverse-engineered bithacks. For example, the popcnt() method from Hacker's Delight are now recognized and translated into an internal function, which is then expanded into either an inlined function (much like the original) or a machine instruction, if the target has one. High-level transformation would transform Anton's beloved bubblesort benchmark into insertion sort, at least. But if you're willing to take the risk of AI, you can of course tell it "Find all O(N^2) algorithms in my code and replace them with O(N log N) where possible". It will happily do something, and the resulting code might even be correct after a few iterations. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-19 15:56 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep19.175649@mips.complang.tuwien.ac.at> |
| In reply to | #118097 |
Thomas Koenig <tkoenig@netcologne.de> writes: >Paul Clayton <paaronclayton@gmail.com> schrieb: >Two points: A compiler is restricted by the transformations >it can do by the language specification. For example, loop >interchanges with floating point calculation can give different >results. Interestingly, this is where gcc maintainers do the right thing and people who want to risk program breakage must use an extra flag (-ffast-math) to get "optimizations" (such as FP operation reassociation) that may change the results. >High-level transformation would transform Anton's beloved >bubblesort benchmark into insertion sort, at least. This bubble-sort benchmark comes from John Hennessey's collection of integer benchmarks, and Marty Fraeman has translated several of these benchmarks into Forth. This is the reason why I like to use it for comparing the performance of Forth systems to C compilers. Recognizing this bubble-sort and using a more efficient sort (e.g., insertion sort for small instances, quicksort for larger ones) would be a real optimization; it would ruin the comparability with the Forth translation (as long as we do not put this kind of effort into Forth compilers), but that's life. But for now gcc autovectorizes it in a way that produces a significant slowdown; clang avoids this pitfall. Note that this auto-vectorization of gcc does not just slow down bubble-sort, but also gforth: when you load two adjacent stack items in one VM instruction, gcc -O3 by default wants to auto-vectorize these accesses, and given that one or both of them usually have been written recently, this would result in a slowdown. What's worse, gcc seems to think that a lot of values are alive that are actually dead, and generates dozens or hundreds of copying instructions into the code of each VM instruction, increasing the slowdown even more. For that reason, we have disabled tree-slp-vectorization when building Gforth. >But if you're willing to take the risk of AI, you can of course >tell it "Find all O(N^2) algorithms in my code and replace them >with O(N log N) where possible". Most O(N^2) algorithms probably cannot be replaced in that way, e.g., the TSP algorithm used in "Writing Efficient Programs" by Jon Bentley. OTOH, as a human you can replace this TSP algorithm by one that runs faster (O(N log N) or so) and also usually produces a shorter tour, and IIRC Jon Bentley mentions this himself, but it will produce a different result, so a compiler cannot go there: It has to use the source code as specification. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-20 10:46 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118odha$31okp$1@dont-email.me> |
| In reply to | #118098 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > Thomas Koenig <tkoenig@netcologne.de> writes: >>Paul Clayton <paaronclayton@gmail.com> schrieb: >>Two points: A compiler is restricted by the transformations >>it can do by the language specification. For example, loop >>interchanges with floating point calculation can give different >>results. > > Interestingly, this is where gcc maintainers do the right thing and > people who want to risk program breakage must use an extra flag > (-ffast-math) to get "optimizations" (such as FP operation > reassociation) that may change the results. > >>High-level transformation would transform Anton's beloved >>bubblesort benchmark into insertion sort, at least. > > This bubble-sort benchmark comes from John Hennessey's collection of > integer benchmarks, and Marty Fraeman has translated several of these > benchmarks into Forth. This is the reason why I like to use it for > comparing the performance of Forth systems to C compilers. Bubblesort is the worst of non-joke sorting algorithms, see the quote from Numerical Recipes... > Recognizing this bubble-sort and using a more efficient sort (e.g., > insertion sort for small instances, quicksort for larger ones) would > be a real optimization; it would ruin the comparability with the Forth > translation (as long as we do not put this kind of effort into Forth > compilers), but that's life. But for now gcc autovectorizes it in a > way that produces a significant slowdown; clang avoids this pitfall. All such choices are the result of heuristics. Bubble sort has a very special memory access pattern. A straightforward patch would very likely pessimize a lot of existing code which profits from auto-vectorization. I have no doubt that the existing heuristics can be improved. > Note that this auto-vectorization of gcc does not just slow down > bubble-sort, but also gforth: when you load two adjacent stack items > in one VM instruction, gcc -O3 by default wants to auto-vectorize > these accesses, and given that one or both of them usually have been > written recently, this would result in a slowdown. What's worse, gcc > seems to think that a lot of values are alive that are actually dead, > and generates dozens or hundreds of copying instructions into the code > of each VM instruction, increasing the slowdown even more. For that > reason, we have disabled tree-slp-vectorization when building Gforth. There is no stopping you from developing a patch (or having it developed by a student as part of a thesis - can you act as supervisor for master's or bachelor's theses?) and then submitting it to gcc. But if you do so, you should make sure that it is does not slow down normal programs (as measured by SPEC). Regarding clang: There are numerous cases where gcc's more aggressive auto-vectorization generates a lot of profit vs. clang. These are cases that would very probably suffer when heuristics are not very carefully chosen. -- 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-20 14:24 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260920142421.00005c59@yahoo.com> |
| In reply to | #118100 |
On Sun, 20 Sep 2026 10:46:02 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb: > > Thomas Koenig <tkoenig@netcologne.de> writes: > >>Paul Clayton <paaronclayton@gmail.com> schrieb: > >>Two points: A compiler is restricted by the transformations > >>it can do by the language specification. For example, loop > >>interchanges with floating point calculation can give different > >>results. > > > > Interestingly, this is where gcc maintainers do the right thing and > > people who want to risk program breakage must use an extra flag > > (-ffast-math) to get "optimizations" (such as FP operation > > reassociation) that may change the results. > > > >>High-level transformation would transform Anton's beloved > >>bubblesort benchmark into insertion sort, at least. > > > > This bubble-sort benchmark comes from John Hennessey's collection of > > integer benchmarks, and Marty Fraeman has translated several of > > these benchmarks into Forth. This is the reason why I like to use > > it for comparing the performance of Forth systems to C compilers. > > Bubblesort is the worst of non-joke sorting algorithms, see > the quote from Numerical Recipes... > > > Recognizing this bubble-sort and using a more efficient sort (e.g., > > insertion sort for small instances, quicksort for larger ones) would > > be a real optimization; it would ruin the comparability with the > > Forth translation (as long as we do not put this kind of effort > > into Forth compilers), but that's life. But for now gcc > > autovectorizes it in a way that produces a significant slowdown; > > clang avoids this pitfall. > > All such choices are the result of heuristics. Bubble sort has a > very special memory access pattern. A straightforward patch would > very likely pessimize a lot of existing code which profits from > auto-vectorization. I have no doubt that the existing heuristics > can be improved. > > > Note that this auto-vectorization of gcc does not just slow down > > bubble-sort, but also gforth: when you load two adjacent stack items > > in one VM instruction, gcc -O3 by default wants to auto-vectorize > > these accesses, and given that one or both of them usually have been > > written recently, this would result in a slowdown. What's worse, > > gcc seems to think that a lot of values are alive that are actually > > dead, and generates dozens or hundreds of copying instructions into > > the code of each VM instruction, increasing the slowdown even more. > > For that reason, we have disabled tree-slp-vectorization when > > building Gforth. > > There is no stopping you from developing a patch (or having > it developed by a student as part of a thesis - can you act as > supervisor for master's or bachelor's theses?) and then submitting > it to gcc. But if you do so, you should make sure that it is does > not slow down normal programs (as measured by SPEC). > > Regarding clang: There are numerous cases where gcc's more > aggressive auto-vectorization generates a lot of profit vs. clang. > These are cases that would very probably suffer when heuristics > are not very carefully chosen. > I am not sure about vectorization in general. Personally, I had seen cases where clang autovectorization produced greater slowdowns than gcc's. But one particular pattern of gcc is certainly worse than clang's - merging narrow stores into wider ones. Nowadays gcc does not even consider it autovectorization. This pattern rarely leads to major slowdowns, more typically a little impacts in multiple places. But sometimes it gets measurable, esp. on Zen3. I don't believe that disabling this particular generic pessimization could impact Spec negatively, but I am not aware of simple way (i.e. normal -f flags, rather than semi-documented flags intended for gcc maintainers) to disable it.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-20 11:52 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118ohe6$32rm8$1@dont-email.me> |
| In reply to | #118101 |
Michael S <already5chosen@yahoo.com> schrieb: > On Sun, 20 Sep 2026 10:46:02 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > But one particular pattern of gcc is certainly worse than clang's - > merging narrow stores into wider ones. Nowadays gcc does not even > consider it autovectorization. This pattern rarely leads to major > slowdowns, more typically a little impacts in multiple places. But > sometimes it gets measurable, esp. on Zen3. > I don't believe that disabling this particular generic pessimization > could impact Spec negatively, but I am not aware of simple way (i.e. > normal -f flags, rather than semi-documented flags intended for gcc > maintainers) to disable it. If you have a test case (but please not bubble sort :-) where -fstore-merging pessimizes things (or -fno-store-merging makes a significant difference) please post it. I can then write a PR and hang it off https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094 where I don't see anything relevant at the moment. -- 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-20 15:09 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260920150918.000073e5@yahoo.com> |
| In reply to | #118102 |
On Sun, 20 Sep 2026 11:52:38 -0000 (UTC) Thomas Koenig <tkoenig@netcologne.de> wrote: > Michael S <already5chosen@yahoo.com> schrieb: > > On Sun, 20 Sep 2026 10:46:02 -0000 (UTC) > > Thomas Koenig <tkoenig@netcologne.de> wrote: > > > But one particular pattern of gcc is certainly worse than clang's - > > merging narrow stores into wider ones. Nowadays gcc does not even > > consider it autovectorization. This pattern rarely leads to major > > slowdowns, more typically a little impacts in multiple places. But > > sometimes it gets measurable, esp. on Zen3. > > I don't believe that disabling this particular generic pessimization > > could impact Spec negatively, but I am not aware of simple way (i.e. > > normal -f flags, rather than semi-documented flags intended for gcc > > maintainers) to disable it. > > If you have a test case (but please not bubble sort :-) where > -fstore-merging pessimizes things (or -fno-store-merging makes > a significant difference) please post it. I can then write a PR > and hang it off https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094 > where I don't see anything relevant at the moment. > IIRC, it already was in at least one of my PRs. May be, more than one.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-21 05:27 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118qf7r$3neji$1@dont-email.me> |
| In reply to | #118103 |
Michael S <already5chosen@yahoo.com> schrieb:
> On Sun, 20 Sep 2026 11:52:38 -0000 (UTC)
> Thomas Koenig <tkoenig@netcologne.de> wrote:
>
>> Michael S <already5chosen@yahoo.com> schrieb:
>> > On Sun, 20 Sep 2026 10:46:02 -0000 (UTC)
>> > Thomas Koenig <tkoenig@netcologne.de> wrote:
>>
>> > But one particular pattern of gcc is certainly worse than clang's -
>> > merging narrow stores into wider ones. Nowadays gcc does not even
>> > consider it autovectorization. This pattern rarely leads to major
>> > slowdowns, more typically a little impacts in multiple places. But
>> > sometimes it gets measurable, esp. on Zen3.
>> > I don't believe that disabling this particular generic pessimization
>> > could impact Spec negatively, but I am not aware of simple way (i.e.
>> > normal -f flags, rather than semi-documented flags intended for gcc
>> > maintainers) to disable it.
>>
>> If you have a test case (but please not bubble sort :-) where
>> -fstore-merging pessimizes things (or -fno-store-merging makes
>> a significant difference) please post it. I can then write a PR
>> and hang it off https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94094
>> where I don't see anything relevant at the moment.
>>
>
> IIRC, it already was in at least one of my PRs. May be, more than one.
The way I read it, it is the opposite - those are about missed
load/store merging. Here is the list.
94094: [meta-bug] store-merging and/or bswap load/store-merging missed optimizations [See dependency tree for bug 94094]
32605: Missing byte swap optimizations [See dependency tree for bug 32605]
65424: gcc does not recognize byte swaps implemented as loop. [See dependency tree for bug 65424]
88097: Missing optimization of endian conversion [See dependency tree for bug 88097]
89810: Suboptimal codegen: integer load/assemble from in-register array of uint8_t [See dependency tree for bug 89810]
89811: uint32_t load is not recognized if shifts are done in a fixed-size loop [See dependency tree for bug 89811]
92716: -Os doesn't inline byteswap function even though it's a single instruction [See dependency tree for bug 92716]
93328: missed optimization opportunity in deserialization code [See dependency tree for bug 93328]
93896: Store merging could merge 0 constructors into {} [See dependency tree for bug 93896]
94071: Missed optimization with endian and alignment independent memory access [See dependency tree for bug 94071]
94086: Missed optimization when converting a bitfield to an integer on x86-64 [See dependency tree for bug 94086]
94403: Missed optimization bswap [See dependency tree for bug 94403]
96135: [14/15/16/17 regression] bswap not detected by bswap pass, unexpected results between optimization levels [See dependency tree for bug 96135]
96167: fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy [See dependency tree for bug 96167]
98953: Failure to optimize two reads from adjacent addresses into one due to having an offset (index) [See dependency tree for bug 98953]
94071: Missed optimization with endian and alignment independent memory access [See dependency tree for bug 94071] (*)
98982: Optimizing loop variants of fixed-byte-order functions [See dependency tree for bug 98982]
102495: optimize some consecutive byte load pattern to word load [See dependency tree for bug 102495]
104344: Suboptimal -Os code for manually unrolled loop [See dependency tree for bug 104344]
104632: Missed optimization about reading backwards [See dependency tree for bug 104632]
123541: Load merging missing [See dependency tree for bug 123541]
So, if anybody is interested in aan actual fix, please post a
self-contained test case.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-20 12:13 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep20.141357@mips.complang.tuwien.ac.at> |
| In reply to | #118101 |
Michael S <already5chosen@yahoo.com> writes: >But one particular pattern of gcc is certainly worse than clang's - >merging narrow stores into wider ones. I have seen heavy slowdowns from merging narrow loads into wide loads <https://www.complang.tuwien.ac.at/anton/stwlf/>, but not for stores. Where can I read about this slowdown? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-20 15:35 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260920153543.00002baa@yahoo.com> |
| In reply to | #118105 |
On Sun, 20 Sep 2026 12:13:57 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Michael S <already5chosen@yahoo.com> writes: > >But one particular pattern of gcc is certainly worse than clang's - > >merging narrow stores into wider ones. > > I have seen heavy slowdowns from merging narrow loads into wide loads > <https://www.complang.tuwien.ac.at/anton/stwlf/>, but not for stores. > Where can I read about this slowdown? > > - anton Those are my measurements, mostly undocumented and dependent on situation. I never did a deep research. Typically cases of none-SIMD stores merged into SIMD. If store location is not used soon thereafter then impact is hard to detect. In this cases the only impact is code bloat and over-occupation of Ifetch and Decode stages. It seems to me, the most heavy impact on Zen3 is when such merged SIMD store is followed by GPR load to the same location within a dozen or so of CPU cycles.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-20 16:43 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep20.184354@mips.complang.tuwien.ac.at> |
| In reply to | #118106 |
Michael S <already5chosen@yahoo.com> writes: >It seems to me, the most heavy impact on Zen3 is when such merged >SIMD store is followed by GPR load to the same location within a dozen >or so of CPU cycles. This is a case I measured in <https://www.complang.tuwien.ac.at/anton/stwlf/>. Look for the wl>ws=_=>nl>ns line. In this case, on Zen3 merging (-O3) is faster than not merging (-O). But I see slowdowns from merging (-O3) in other cases where the partial store-to-load overlap does not occur, e.g., in the "wl>ws=>wl (recurrence), nl>ns (no recurrence)" case (and that's pretty widespread among microarchitectures), so there is probably another microarchitectural pitfall beyond the partal store-to-load forwarding. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 21 of 24 — ← Prev page 1 … 19 20 [21] 22 23 24 Next page →
Back to top | Article view | comp.arch
csiph-web