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 13 of 24 — ← Prev page 1 … 11 12 [13] 14 15 … 24 Next page →
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-06 23:16 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a3ofn$2ak3s$1@dont-email.me> |
| In reply to | #118474 |
Dan Cross wrote:
> In article <86h5j5pky9.fsf@linuxsc.com>,
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>> [...]
>>>>>> I favor a type equivalent to size_t for use as array index variables.
>>>>>
>>>>> In Rust, the only acceptable array index is of type "usize", which is
>>>>> effectively the same as u64 on most platforms these days, but does not
>>>>> need to be so: On a 32-bit target, it would be the same as u32.
>>>>>
>>>>> So effectively very similar to size_t.
>>>>
>>>> Maybe that limitation works okay in Rust. In C sometimes it's
>>>> important to allow a signed value for indexing. Probably 99% of
>>>> the time size_t is good, but not always.
>>>
>>> The fact that array indices are unsigned is one of the more crucial
>>> underpinnings of Rust safety. Even more importantly, all such indices
>>> are verified against the actual array upper boundary. [...]
>>
>> It's nice that array index values are checked against the array
>> bounds.
>
> Terje was actually incorrect here; bounds checks are added in
> debug mode, but are (usually) removed in optimized builds.
That's what I assumed, except I check my assumptions by godbolt'ing my
code, using -O -C "target_cpu=native" to get a bleeding edge optimized
build, and that's where I saw a loop which started with
while pos+7 < input.len() {
... here a bunch of accesses to input[p], input[p+1]...input[p+6]
}
Every one of those secodnary accesses were very obviously tested against
the input length (stored in a register for the duration)
I considered reporting this as a very clear performance bug!
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-07 13:28 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a5hd5$4qb$1@reader2.panix.com> |
| In reply to | #118501 |
In article <11a3ofn$2ak3s$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Dan Cross wrote:
>> In article <86h5j5pky9.fsf@linuxsc.com>,
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>
>>>> Tim Rentsch wrote:
>>>>
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> Tim Rentsch wrote:
>>> [...]
>>>>>>> I favor a type equivalent to size_t for use as array index variables.
>>>>>>
>>>>>> In Rust, the only acceptable array index is of type "usize", which is
>>>>>> effectively the same as u64 on most platforms these days, but does not
>>>>>> need to be so: On a 32-bit target, it would be the same as u32.
>>>>>>
>>>>>> So effectively very similar to size_t.
>>>>>
>>>>> Maybe that limitation works okay in Rust. In C sometimes it's
>>>>> important to allow a signed value for indexing. Probably 99% of
>>>>> the time size_t is good, but not always.
>>>>
>>>> The fact that array indices are unsigned is one of the more crucial
>>>> underpinnings of Rust safety. Even more importantly, all such indices
>>>> are verified against the actual array upper boundary. [...]
>>>
>>> It's nice that array index values are checked against the array
>>> bounds.
>>
>> Terje was actually incorrect here; bounds checks are added in
>> debug mode, but are (usually) removed in optimized builds.
>
>That's what I assumed, except I check my assumptions by godbolt'ing my
>code, using -O -C "target_cpu=native" to get a bleeding edge optimized
>build, and that's where I saw a loop which started with
>
> while pos+7 < input.len() {
> ... here a bunch of accesses to input[p], input[p+1]...input[p+6]
> }
>
>Every one of those secodnary accesses were very obviously tested against
>the input length (stored in a register for the duration)
>
>I considered reporting this as a very clear performance bug!
I wonder if what you saw was actually loop unrolling. I just
tried something similar, albeit with a very simple sum in the
loop body, and don't see a bunch of extraneous bounds checks.
I do wonder, though, whether you'd get better object code using
`input.iter().chunks(n)` or `.windows(n)`.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-07 16:43 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a5lqo$2v5bq$1@dont-email.me> |
| In reply to | #118510 |
Dan Cross wrote:
> In article <11a3ofn$2ak3s$1@dont-email.me>,
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>> Dan Cross wrote:
>>> In article <86h5j5pky9.fsf@linuxsc.com>,
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> Tim Rentsch wrote:
>>>>>
>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>
>>>>>>> Tim Rentsch wrote:
>>>> [...]
>>>>>>>> I favor a type equivalent to size_t for use as array index variables.
>>>>>>>
>>>>>>> In Rust, the only acceptable array index is of type "usize", which is
>>>>>>> effectively the same as u64 on most platforms these days, but does not
>>>>>>> need to be so: On a 32-bit target, it would be the same as u32.
>>>>>>>
>>>>>>> So effectively very similar to size_t.
>>>>>>
>>>>>> Maybe that limitation works okay in Rust. In C sometimes it's
>>>>>> important to allow a signed value for indexing. Probably 99% of
>>>>>> the time size_t is good, but not always.
>>>>>
>>>>> The fact that array indices are unsigned is one of the more crucial
>>>>> underpinnings of Rust safety. Even more importantly, all such indices
>>>>> are verified against the actual array upper boundary. [...]
>>>>
>>>> It's nice that array index values are checked against the array
>>>> bounds.
>>>
>>> Terje was actually incorrect here; bounds checks are added in
>>> debug mode, but are (usually) removed in optimized builds.
>>
>> That's what I assumed, except I check my assumptions by godbolt'ing my
>> code, using -O -C "target_cpu=native" to get a bleeding edge optimized
>> build, and that's where I saw a loop which started with
>>
>> while pos+7 < input.len() {
>> ... here a bunch of accesses to input[p], input[p+1]...input[p+6]
>> }
>>
>> Every one of those secodnary accesses were very obviously tested against
>> the input length (stored in a register for the duration)
>>
>> I considered reporting this as a very clear performance bug!
>
> I wonder if what you saw was actually loop unrolling. I just
> tried something similar, albeit with a very simple sum in the
> loop body, and don't see a bunch of extraneous bounds checks.
Not unrolling, the code is here:
https://godbolt.org/z/YnY5G1K49
The interesting part starts at line 28/29 .LBB0_02 in the asm window
where you can see (starting at line 37) a bunch of cmp r8,rsi / jae
<panic> sequences.
> I do wonder, though, whether you'd get better object code using
> `input.iter().chunks(n)` or `.windows(n)`.
I guess I can try this, I'm guessing chunks(7) will error out if less
than 7 elements are available?
The code is from Advent of Code 2024 day 3,
https://github.com/TerjeWiigMathisen/aoc/tree/master/2024/day03
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-07 19:57 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a6870$41j$1@reader2.panix.com> |
| In reply to | #118512 |
In article <11a5lqo$2v5bq$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Dan Cross wrote:
>> In article <11a3ofn$2ak3s$1@dont-email.me>,
>> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>>> Dan Cross wrote:
>>>> In article <86h5j5pky9.fsf@linuxsc.com>,
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>
>>>>>> Tim Rentsch wrote:
>>>>>>
>>>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>>>
>>>>>>>> Tim Rentsch wrote:
>>>>> [...]
>>>>>>>>> I favor a type equivalent to size_t for use as array index variables.
>>>>>>>>
>>>>>>>> In Rust, the only acceptable array index is of type "usize", which is
>>>>>>>> effectively the same as u64 on most platforms these days, but does not
>>>>>>>> need to be so: On a 32-bit target, it would be the same as u32.
>>>>>>>>
>>>>>>>> So effectively very similar to size_t.
>>>>>>>
>>>>>>> Maybe that limitation works okay in Rust. In C sometimes it's
>>>>>>> important to allow a signed value for indexing. Probably 99% of
>>>>>>> the time size_t is good, but not always.
>>>>>>
>>>>>> The fact that array indices are unsigned is one of the more crucial
>>>>>> underpinnings of Rust safety. Even more importantly, all such indices
>>>>>> are verified against the actual array upper boundary. [...]
>>>>>
>>>>> It's nice that array index values are checked against the array
>>>>> bounds.
>>>>
>>>> Terje was actually incorrect here; bounds checks are added in
>>>> debug mode, but are (usually) removed in optimized builds.
>>>
>>> That's what I assumed, except I check my assumptions by godbolt'ing my
>>> code, using -O -C "target_cpu=native" to get a bleeding edge optimized
>>> build, and that's where I saw a loop which started with
>>>
>>> while pos+7 < input.len() {
>>> ... here a bunch of accesses to input[p], input[p+1]...input[p+6]
>>> }
>>>
>>> Every one of those secodnary accesses were very obviously tested against
>>> the input length (stored in a register for the duration)
>>>
>>> I considered reporting this as a very clear performance bug!
>>
>> I wonder if what you saw was actually loop unrolling. I just
>> tried something similar, albeit with a very simple sum in the
>> loop body, and don't see a bunch of extraneous bounds checks.
>
>Not unrolling, the code is here:
>
>https://godbolt.org/z/YnY5G1K49
>
>The interesting part starts at line 28/29 .LBB0_02 in the asm window
>where you can see (starting at line 37) a bunch of cmp r8,rsi / jae
><panic> sequences.
So you're not actually indexing into an _array_ here, but rather
into a _slice_, which is always bounds-checked in safe Rust
code.
>> I do wonder, though, whether you'd get better object code using
>> `input.iter().chunks(n)` or `.windows(n)`.
>
>I guess I can try this, I'm guessing chunks(7) will error out if less
>than 7 elements are available?
But really what you want is to find all subsequences matching
the regular expression , `mul([0-9]+,[0-9]+)`, and then extract
the two numeric fields, multiple them, and sum the results.
That's a reduction over a sequence of products, which is itself
a reduction over a sequence of patches that yield pairs of
integers.
I understand you want raw speed; a way to get that is to
implement the DFA corresponding to that regexp by hand, and use
something like Boyer Moore to handle the fixed part.
>The code is from Advent of Code 2024 day 3,
>https://github.com/TerjeWiigMathisen/aoc/tree/master/2024/day03
Oh, I don't do Advent of Code, but looking briefly at the
problem description I don't see why you couldn't use `&str` to
represent the input data. Nothing says it's not UTF-8, and from
what I understand, the guy who runs it usually isn't a jerk
about that kind of thing. I haven't tried to benchmark your
code against, e.g., this:
-->BEGIN<---
pub fn next(mut s: &str) -> Option<(i32, &str)> {
while !s.is_empty() {
let pos = s.find("mul(")?;
let (_, rest) = s.split_at(pos + 4);
s = rest;
let comma = s.find(|c: char| !c.is_ascii_digit())?;
let (adigits, rest) = s.split_at(comma);
let Some(rest) = rest.strip_prefix(",") else {
s = rest;
continue;
};
let a = adigits.parse::<i32>().ok()?;
let rparen = rest.find(|c: char| !c.is_ascii_digit())?;
let (bdigits, rest) = rest.split_at(rparen);
let Some(rest) = rest.strip_prefix(")") else {
s = rest;
continue;
};
let b = bdigits.parse::<i32>().ok()?;
return Some((a * b, rest));
}
None
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn invalids() {
assert_eq!(next("aaa"), None);
assert_eq!(next(""), None);
assert_eq!(next("mul(3,5"), None);
assert_eq!(next("mul(3, 5"), None);
assert_eq!(next("mul(3,"), None);
assert_eq!(next("mul(3"), None);
assert_eq!(next("mul("), None);
}
#[test]
fn aproduct() {
let s = "abmul[1,2]mul(3,5)a";
assert_eq!(next(s), Some((15, "a")));
}
#[test]
fn mproducts() {
let s = "mul(1,2)mul(3,4)";
let aopt = next(s);
assert_eq!(aopt, Some((2, "mul(3,4)")));
let (a, s) = aopt.unwrap();
let bopt = next(s);
assert_eq!(bopt, Some((12, "")));
let (b, s) = bopt.unwrap();
assert_eq!(next(s), None);
assert_eq!(a * b, 24);
}
}
--->END<---
I suspect yours may be somewhat faster, though this likely does
more error checking. YMMV.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-07 22:31 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a6a6h$37i1n$1@dont-email.me> |
| In reply to | #118517 |
Dan Cross wrote:
> In article <11a5lqo$2v5bq$1@dont-email.me>,
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>> Not unrolling, the code is here:
>>
>> https://godbolt.org/z/YnY5G1K49
>>
>> The interesting part starts at line 28/29 .LBB0_02 in the asm window
>> where you can see (starting at line 37) a bunch of cmp r8,rsi / jae
>> <panic> sequences.
>
> So you're not actually indexing into an _array_ here, but rather
> into a _slice_, which is always bounds-checked in safe Rust
> code.
My old asm/C brain _knows_ that a slice of something with a known
address and total length is effectively the same thing as an unmutable
array.
Even if it isn't, the fact that I start by verifying that the slice
extends at least 7 bytes past the p index means that all of p,
p+1,p+2...p+6 must be valid, right?
>
>>> I do wonder, though, whether you'd get better object code using
>>> `input.iter().chunks(n)` or `.windows(n)`.
>>
>> I guess I can try this, I'm guessing chunks(7) will error out if less
>> than 7 elements are available?
>
> But really what you want is to find all subsequences matching
> the regular expression , `mul([0-9]+,[0-9]+)`, and then extract
> the two numeric fields, multiple them, and sum the results.
> That's a reduction over a sequence of products, which is itself
> a reduction over a sequence of patches that yield pairs of
> integers.
Yes, doing it that way is easy!
>
> I understand you want raw speed; a way to get that is to
> implement the DFA corresponding to that regexp by hand, and use
> something like Boyer Moore to handle the fixed part.
Collectively we've tried all sorts of stuff in order to come up with the
absolute fastest solution, without having to use unsafe code.
>
>> The code is from Advent of Code 2024 day 3,
>> https://github.com/TerjeWiigMathisen/aoc/tree/master/2024/day03
>
> Oh, I don't do Advent of Code, but looking briefly at the
> problem description I don't see why you couldn't use `&str` to
I typically pass the input to my process(inp:&str) function that way,
but by turning it into a naked byte array (slice?), indexing is better
defined with no need to iterate over a potential UTF8 sequence (even
though we know there won't be any).
> represent the input data. Nothing says it's not UTF-8, and from
> what I understand, the guy who runs it usually isn't a jerk
> about that kind of thing. I haven't tried to benchmark your
> code against, e.g., this:
What you implement here is just Part1: After solving that you get to
read Part2 where you have to also detect "do()" and "don't()" sequences,
so that the multiplication result only adds to the part2 result if we're
not following a don't().
>
> -->BEGIN<---
> pub fn next(mut s: &str) -> Option<(i32, &str)> {
> while !s.is_empty() {
> let pos = s.find("mul(")?;
> let (_, rest) = s.split_at(pos + 4);
> s = rest;
> let comma = s.find(|c: char| !c.is_ascii_digit())?;
> let (adigits, rest) = s.split_at(comma);
> let Some(rest) = rest.strip_prefix(",") else {
> s = rest;
> continue;
> };
> let a = adigits.parse::<i32>().ok()?;
> let rparen = rest.find(|c: char| !c.is_ascii_digit())?;
> let (bdigits, rest) = rest.split_at(rparen);
> let Some(rest) = rest.strip_prefix(")") else {
> s = rest;
> continue;
> };
> let b = bdigits.parse::<i32>().ok()?;
> return Some((a * b, rest));
> }
> None
> }
>
> #[cfg(test)]
> mod tests {
> use super::*;
>
> #[test]
> fn invalids() {
> assert_eq!(next("aaa"), None);
> assert_eq!(next(""), None);
> assert_eq!(next("mul(3,5"), None);
> assert_eq!(next("mul(3, 5"), None);
> assert_eq!(next("mul(3,"), None);
> assert_eq!(next("mul(3"), None);
> assert_eq!(next("mul("), None);
> }
>
> #[test]
> fn aproduct() {
> let s = "abmul[1,2]mul(3,5)a";
> assert_eq!(next(s), Some((15, "a")));
> }
>
> #[test]
> fn mproducts() {
> let s = "mul(1,2)mul(3,4)";
> let aopt = next(s);
> assert_eq!(aopt, Some((2, "mul(3,4)")));
> let (a, s) = aopt.unwrap();
> let bopt = next(s);
> assert_eq!(bopt, Some((12, "")));
> let (b, s) = bopt.unwrap();
> assert_eq!(next(s), None);
> assert_eq!(a * b, 24);
> }
> }
> --->END<---
>
> I suspect yours may be somewhat faster, though this likely does
> more error checking. YMMV.
>
My guess is that your code (after adding the simultaneous scans for the
do/don't markers) will take about twice as long (or more?) as the 7 us
both my own and u/maneatingape (reddit handle of the guy with the
fastest Rust solutions to all the 500+ puzzles) needs to deliver the result.
He is famous for solving every one of them in less than half a second:
His current total is 462 milliseconds for 524 stars.
I've managed to improve slightly on his code a few times, but more often
he is ahead of the best I've been able to come up with.
Collectively, the group discussing this on reddit have tried many
different search approaches, including unaligned load of 4 bytes as a
u32, then compare that directly against "mul(", "do()" and "don'" in a
match statement. For me, this was slower in Rust, but a C programmer
gained a us or two this way.
Setting up a combined Boyer-Moore would be doable:
If the fourth byte is '(', ')' or "'", check the preceeding bytes, if
not a match use a pre-computed skip table (maybe even one for each
initial match?) to increment the pointer. Hmmm... maybe I'll try this!
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-08 21:28 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a91un$a7p$1@reader2.panix.com> |
| In reply to | #118520 |
[Cross-post to comp.programming, Followup-To: comp.programming]
In article <11a6a6h$37i1n$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Dan Cross wrote:
>> In article <11a5lqo$2v5bq$1@dont-email.me>,
>> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>>> Not unrolling, the code is here:
>>>
>>> https://godbolt.org/z/YnY5G1K49
>>>
>>> The interesting part starts at line 28/29 .LBB0_02 in the asm window
>>> where you can see (starting at line 37) a bunch of cmp r8,rsi / jae
>>> <panic> sequences.
>>
>> So you're not actually indexing into an _array_ here, but rather
>> into a _slice_, which is always bounds-checked in safe Rust
>> code.
>
>My old asm/C brain _knows_ that a slice of something with a known
>address and total length is effectively the same thing as an unmutable
>array.
Sadly, though, it's not. :-/
>Even if it isn't, the fact that I start by verifying that the slice
>extends at least 7 bytes past the p index means that all of p,
>p+1,p+2...p+6 must be valid, right?
One would think!
>>>> I do wonder, though, whether you'd get better object code using
>>>> `input.iter().chunks(n)` or `.windows(n)`.
>>>
>>> I guess I can try this, I'm guessing chunks(7) will error out if less
>>> than 7 elements are available?
>>
>> But really what you want is to find all subsequences matching
>> the regular expression , `mul([0-9]+,[0-9]+)`, and then extract
>> the two numeric fields, multiple them, and sum the results.
>> That's a reduction over a sequence of products, which is itself
>> a reduction over a sequence of patches that yield pairs of
>> integers.
>
>Yes, doing it that way is easy!
Well, I mean as a conceptual thing; not necessary using a regex
library. That is, mentally write the patterns down as a DFA and
then write that out as code+state tables.
>> [snip]
>> represent the input data. Nothing says it's not UTF-8, and from
>> what I understand, the guy who runs it usually isn't a jerk
>> about that kind of thing. I haven't tried to benchmark your
>> code against, e.g., this:
>
>What you implement here is just Part1: After solving that you get to
>read Part2 where you have to also detect "do()" and "don't()" sequences,
>so that the multiplication result only adds to the part2 result if we're
>not following a don't().
Ah. Yeah, I'm going to refrain; it's cool that folks are excited
about that, but it's not my favorite biscuit.
>> [snip]
>> I suspect yours may be somewhat faster, though this likely does
>> more error checking. YMMV.
>
>My guess is that your code (after adding the simultaneous scans for the
>do/don't markers) will take about twice as long (or more?) as the 7 us
>both my own and u/maneatingape (reddit handle of the guy with the
>fastest Rust solutions to all the 500+ puzzles) needs to deliver the result.
Maybe? I dunno; the library is probably optimized to use pretty
efficient algorithms, and/or simd and all that jazz.
>[snip]
>Setting up a combined Boyer-Moore would be doable:
>
>If the fourth byte is '(', ')' or "'", check the preceeding bytes, if
>not a match use a pre-computed skip table (maybe even one for each
>initial match?) to increment the pointer. Hmmm... maybe I'll try this!
Right. This lets you potentially go sub-linear looking for the
tokens you care about. I wonder how it would stack up against
using something like `memchr::memmem`, though, since that'll get
you hardware acceleration using SIMD instructions and goofy
stuff like that.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-11 08:41 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11afi48$2ev5k$1@dont-email.me> |
| In reply to | #118520 |
Terje Mathisen <terje.mathisen@tmsw.no> schrieb: > My old asm/C brain _knows_ that a slice of something with a known > address and total length is effectively the same thing as an unmutable > array. > > Even if it isn't, the fact that I start by verifying that the slice > extends at least 7 bytes past the p index means that all of p, > p+1,p+2...p+6 must be valid, right? Range checking is very difficult for a compiler, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=VRP . -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-11 18:14 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1791742457-5857@newsgrouper.org> |
| In reply to | #118520 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > Dan Cross wrote: --------- > > My old asm/C brain _knows_ that a slice of something with a known > address and total length is effectively the same thing as an unmutable > array. Can I get a definition of what mutable in Rust means ?? Intuition would imply the inverse of opposite of const from C. > Even if it isn't, the fact that I start by verifying that the slice > extends at least 7 bytes past the p index means that all of p, > p+1,p+2...p+6 must be valid, right? ---------- > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-11 20:56 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11agm4p$2tfut$1@dont-email.me> |
| In reply to | #118540 |
MitchAlsup wrote: > > Terje Mathisen <terje.mathisen@tmsw.no> posted: > >> Dan Cross wrote: > --------- >> >> My old asm/C brain _knows_ that a slice of something with a known >> address and total length is effectively the same thing as an unmutable >> array. > > Can I get a definition of what mutable in Rust means ?? It does mean that the function which receives a non-mut parameter, or itself declares som non-mut local variables, cannot modify any of them. So yes, very similar to "not const". You can discuss if its a good idea to make non-mutability the default instead of the opposite. Personally I like that part. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 07:47 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11ahs8q$38ir0$4@dont-email.me> |
| In reply to | #118541 |
On 11/10/2026 20:56, Terje Mathisen wrote:
> MitchAlsup wrote:
>>
>> Terje Mathisen <terje.mathisen@tmsw.no> posted:
>>
>>> Dan Cross wrote:
>> ---------
>>>
>>> My old asm/C brain _knows_ that a slice of something with a known
>>> address and total length is effectively the same thing as an unmutable
>>> array.
>>
>> Can I get a definition of what mutable in Rust means ??
>
> It does mean that the function which receives a non-mut parameter, or
> itself declares som non-mut local variables, cannot modify any of them.
>
> So yes, very similar to "not const".
It sounds more powerful than "not const" in C.
This is perfectly reasonable C code :
void change(const int * p, int x) {
int * q = (int *) p;
*q = x;
}
Calling "change" with a pointer to data that was defined with a
const-qualified type is undefined behaviour. Other than that, the
behaviour is fully defined.
So you may not change the value of a variable /defined/ as "const" in C
- any attempt to do so is UB, and unless you go out of your way (such as
with pointer casts), accidental attempts will usually be flagged as
compile-time errors.
But if you receive a "pointer to const" parameter to a function, you can
still write via a cast version of the pointer if the original object was
not defined as "const". (So objects defined as "const" may be placed in
read-only memory of some kind, and trying to change them might cause a
crash, signal, bus-error, etc.)
(In C++, members of a class can be marked "mutable" so that they can be
changed without even needing any pointer cast shenanigans. This means
you can have classes where instances are "logically constant" in a
function call - their user-visible value does not change - but with
aspects that do change, such as caching the results of a calculation, or
re-ordering elements in the underlying data structure for a set.)
The weaker promise of "const" in C and C++ blocks some possible compiler
optimisations of code, but allows some additional user flexibility.
I think (and you will hopefully correct me if I am wrong!) in Rust if a
function receives a non-mutable reference as a parameter, it is not
allowed to cast it to a mutable reference.
>
> You can discuss if its a good idea to make non-mutability the default
> instead of the opposite. Personally I like that part.
>
It certainly sounds good to me.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-12 11:25 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aig3c$3hdcn$1@dont-email.me> |
| In reply to | #118551 |
David Brown <david.brown@hesbynett.no> schrieb:
> But if you receive a "pointer to const" parameter to a function, you can
> still write via a cast version of the pointer if the original object was
> not defined as "const". (So objects defined as "const" may be placed in
> read-only memory of some kind, and trying to change them might cause a
> crash, signal, bus-error, etc.)
In FORTRAN, it used to be possible on systems such as /360 to write
CALL FOO(21)
WRITE (*,*) 21
END
SUBROUTINE FOO(N)
N = 42
END
and get a printout of 42 (21 is only half the truth,
remember!) because the compiler put the constants in read/write
storage and arguments were passed via address. (We used to call
this "Variation der Konstanten", which translates to "variation
of parameters", from ODE theory.
On modern systems, you get a bus error:
$ ./a.out
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
Backtrace for this error:
#0 0x72b109a23e59 in ???
#1 0x72b109a22e75 in ???
#2 0x72b10964532f in ???
at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#3 0x401172 in foo_
at /tmp/crash.f90:6
#4 0x40118f in MAIN__
at /tmp/crash.f90:1
#5 0x401226 in main
at /tmp/crash.f90:3
But it would be interesting to be able to put arguments into
storage which can be changed by the caller, but not the callee,
sort of a read-only stack, but I am not sure how one would
efficiently implement that.
(Modern Fortran offers INTENT for that, so
CALL FOO(21)
WRITE (*,*) 21
END
SUBROUTINE FOO(N)
INTEGER, INTENT(IN) :: N
N = 42
END
gets you
error.f90:7:7:
7 | N = 42
| 1~
Error: Dummy argument 'n' with INTENT(IN) in variable definition context (assignment) at (1)
--
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-12 16:20 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aiqc0$3kr94$3@dont-email.me> |
| In reply to | #118556 |
On 12/10/2026 13:25, Thomas Koenig wrote: > David Brown <david.brown@hesbynett.no> schrieb: > >> But if you receive a "pointer to const" parameter to a function, you can >> still write via a cast version of the pointer if the original object was >> not defined as "const". (So objects defined as "const" may be placed in >> read-only memory of some kind, and trying to change them might cause a >> crash, signal, bus-error, etc.) > > In FORTRAN, it used to be possible on systems such as /360 to write > > CALL FOO(21) > WRITE (*,*) 21 > END > > SUBROUTINE FOO(N) > N = 42 > END > > and get a printout of 42 (21 is only half the truth, > remember!) because the compiler put the constants in read/write > storage and arguments were passed via address. (We used to call > this "Variation der Konstanten", which translates to "variation > of parameters", from ODE theory. > Yes, that "feature" of old FORTRAN is rather famous. Forth is arguably even better for this : : 21 42 ; 21 . 42 ok That is - you can redefine the word "21" to put the value 42 on the stack. Then if you ask for the number "21", you get the value 42. It is not an oddity of the implementation, but the way the language works. > On modern systems, you get a bus error: > > $ ./a.out > > Program received signal SIGSEGV: Segmentation fault - invalid memory reference. > > Backtrace for this error: > #0 0x72b109a23e59 in ??? > #1 0x72b109a22e75 in ??? > #2 0x72b10964532f in ??? > at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0 > #3 0x401172 in foo_ > at /tmp/crash.f90:6 > #4 0x40118f in MAIN__ > at /tmp/crash.f90:1 > #5 0x401226 in main > at /tmp/crash.f90:3 > > > But it would be interesting to be able to put arguments into > storage which can be changed by the caller, but not the callee, > sort of a read-only stack, but I am not sure how one would > efficiently implement that. > > (Modern Fortran offers INTENT for that, so > > CALL FOO(21) > WRITE (*,*) 21 > END > > SUBROUTINE FOO(N) > INTEGER, INTENT(IN) :: N > N = 42 > END > > gets you > > error.f90:7:7: > > 7 | N = 42 > | 1~ > Error: Dummy argument 'n' with INTENT(IN) in variable definition context (assignment) at (1) >
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-12 17:10 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct12.191033@mips.complang.tuwien.ac.at> |
| In reply to | #118558 |
David Brown <david.brown@hesbynett.no> writes: >Forth is arguably even better for this : > >: 21 42 ; >21 . >42 ok > >That is - you can redefine the word "21" to put the value 42 on the >stack. Then if you ask for the number "21", you get the value 42. It >is not an oddity of the implementation, but the way the language works. Yes, but used like this, it's only a curiosity; nobody does this except to show that it can be done. However, there are cases where this is practically relevant: hex \ change to base #16 add \ is this a dictionary word, or a number? The classic ways to avoid this has been to 1) prefix hex numbers with 0 if they would otherwise start with a letter. Dictionary words rarely start with digits, and when they do, they don't conflict with hex numbers. 2) Use "," at the end of assembly language mnemonics, e.g. "add,": Benefits: 1) Avoids conflicts with hex numbers. 2) For postfix assemblers (e.g. "r0 r1 r2 add,", the "," nicely separates the instruction from the next. But a significant number of Forth assemblers do not follow this convention. In modern Forth another way is to avoid changing BASE, and just prefix hex numbers with "$", e.g., "$add". When you do, e.g., hex : add ; in Gforth, Gforth tells you: "warning: defined literal add as word". It does not tell you that when you define "add" when the base is decimal, however. - 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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-12 21:05 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11ajb1e$3ssgg$1@dont-email.me> |
| In reply to | #118562 |
On 12/10/2026 19:10, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> Forth is arguably even better for this : >> >> : 21 42 ; >> 21 . >> 42 ok >> >> That is - you can redefine the word "21" to put the value 42 on the >> stack. Then if you ask for the number "21", you get the value 42. It >> is not an oddity of the implementation, but the way the language works. > > Yes, but used like this, it's only a curiosity; nobody does this > except to show that it can be done. > Of course :-) But it /is/ a cool curiosity! It is a natural consequence of having substantial freedom to define and redefine almost anything as a "word". And I can imagine it having a variety of uses, even for things like words that are all digits or otherwise mean something. However, my experience of Forth is quite minimal - just playing around a little - and I have no knowledge of using it for real code. > However, there are cases where this is practically relevant: > > hex \ change to base #16 > add \ is this a dictionary word, or a number? > I did not know about the "hex" word, so this is a new detail for me. Yes, I can see that having potential for confusion. > The classic ways to avoid this has been to > > 1) prefix hex numbers with 0 if they would otherwise start with a > letter. Dictionary words rarely start with digits, and when they > do, they don't conflict with hex numbers. > > 2) Use "," at the end of assembly language mnemonics, e.g. "add,": > Benefits: 1) Avoids conflicts with hex numbers. 2) For postfix > assemblers (e.g. "r0 r1 r2 add,", the "," nicely separates the > instruction from the next. But a significant number of Forth > assemblers do not follow this convention. > > In modern Forth another way is to avoid changing BASE, and just prefix > hex numbers with "$", e.g., "$add". > That looks clearer to me. Using $ for hex numbers is, I think, the first convention I learned (it was used in BBC Basic, and by its 6502 assembler). > When you do, e.g., > > hex > : add ; > > in Gforth, Gforth tells you: "warning: defined literal add as word". > It does not tell you that when you define "add" when the base is > decimal, however. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-10-13 12:03 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <nj6aehFiusqU1@mid.individual.net> |
| In reply to | #118562 |
On 2026-10-12 20:10, Anton Ertl wrote: > David Brown <david.brown@hesbynett.no> writes: >> Forth is arguably even better for this : >> >> : 21 42 ; >> 21 . >> 42 ok >> >> That is - you can redefine the word "21" to put the value 42 on the >> stack. Then if you ask for the number "21", you get the value 42. It >> is not an oddity of the implementation, but the way the language works. > > Yes, but used like this, it's only a curiosity; nobody does this > except to show that it can be done. Forth originated in astronomy, if I remember correctly. I do remember that in an astronomy-domain Forth program, where it was often necessary to transform the celestial coordinates of stars from the standard catalog epoch (the start of the year 1950) to the current time, the word 1950.0 was defined to perform that transformation. That Forth system did not have floating-point support, so 1950.0 could not be understood as a floating-point literal. But if the program had been ported to a Forth system with floating-point support, confusion could have resulted.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-13 10:27 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct13.122712@mips.complang.tuwien.ac.at> |
| In reply to | #118580 |
Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >Forth originated in astronomy, if I remember correctly. I do remember >that in an astronomy-domain Forth program, where it was often necessary >to transform the celestial coordinates of stars from the standard >catalog epoch (the start of the year 1950) to the current time, the word >1950.0 was defined to perform that transformation. That is unlikely, as explained below. >That Forth system did not have floating-point support, so 1950.0 could >not be understood as a floating-point literal. But if the program had >been ported to a Forth system with floating-point support, confusion >could have resulted. Most Forth systems recognize strings like 1950.0 as double-cell numbers. That's expecially true in early systems, where 16-bit cells were too small for the arithmetic needs of many applications (including in astronomy). In early systems fixed-point was used a lot, and 1950.0 is interpreted as 19500 with a scale factor of 1/10. Only in recent times with 32-bit and 64-bit cells roll-your-own system implementors have chosen to abandon double-cell numbers, but mainstream systems (even with 64-bit cells) still recognize 1950.0 as double-cell number. Just on 2026-10-05 someone complained on comp.lang.forth <6ac33315@news.ausics.net>: |Maybe there's a mechanism in Gforth that stops annoying nags when |printing numbers? | |Gforth 0.7.9_20200709 | |1. d. |*terminal*:1:1: warning: '1.' is a double-cell integer; type `help' for more info1 ok The warning is not about printing the double-cell number, but about the "1.". But anyway, it shows that double-cell numbers are still being used. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2026-10-13 20:00 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <nj76d2FnesuU1@mid.individual.net> |
| In reply to | #118581 |
On 2026-10-13 13:27, Anton Ertl wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >> Forth originated in astronomy, if I remember correctly. I do remember >> that in an astronomy-domain Forth program, where it was often necessary >> to transform the celestial coordinates of stars from the standard >> catalog epoch (the start of the year 1950) to the current time, the word >> 1950.0 was defined to perform that transformation. > > That is unlikely, as explained below. I am rather sure that my memory is correct. This was quite a long time ago -- some time in the 1980s, IIRC. >> That Forth system did not have floating-point support, so 1950.0 could >> not be understood as a floating-point literal. But if the program had >> been ported to a Forth system with floating-point support, confusion >> could have resulted. > > Most Forth systems recognize strings like 1950.0 as double-cell > numbers. That's expecially true in early systems, where 16-bit cells > were too small for the arithmetic needs of many applications > (including in astronomy). OK, I did not know about that double-cell interpretation, so my comments about floating point are mistaken. > In early systems fixed-point was used a lot, and 1950.0 is > interpreted as 19500 with a scale factor of 1/10. The Forth program in question represented angles as fixed-point fractions (0 <= x < 1) of a full circle. I don't remember the number of bits used. Even if that Forth system by default interpreted 1950.0 as a double-cell number, apparently it was still possible to override that interpretation by defining a word called 1950.0. But I trust we agree that such word names are not to be recommended.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-14 08:02 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct14.100238@mips.complang.tuwien.ac.at> |
| In reply to | #118586 |
Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >On 2026-10-13 13:27, Anton Ertl wrote: >> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >>> Forth originated in astronomy, if I remember correctly. I do remember >>> that in an astronomy-domain Forth program, where it was often necessary >>> to transform the celestial coordinates of stars from the standard >>> catalog epoch (the start of the year 1950) to the current time, the word >>> 1950.0 was defined to perform that transformation. >> >> That is unlikely, as explained below. > >I am rather sure that my memory is correct. > >> In early systems fixed-point was used a lot, and 1950.0 is >> interpreted as 19500 with a scale factor of 1/10. >The Forth program in question represented angles as fixed-point >fractions (0 <= x < 1) of a full circle. I don't remember the number of >bits used. Yes, that was customary for angles, as mentioned in the HOPL-II paper "The Evolution of Forth" <https://www.forth.com/resources/forth-programming-language/>: |Moore expressed angles internally as 14-bit, 15-bit or 30-bit |fixed-point binary fractions. >Even if that Forth system by default interpreted 1950.0 as a double-cell >number, apparently it was still possible to override that interpretation >by defining a word called 1950.0. Sure it's possible, but there is no reason why one would call a conversion word 1950.0. What would have been more in line with practice is to define a word 1950.0 which does what writing 1950.0 without such a word does (if the BASE is right): to push a double-cell number 19500. The benefit of defining such a word in an indirect-threaded code implementation (usual for Forth in those times) is that invoking the word costs only one cell, whereas a double-cell constant costs 4 cells. The word amortizes its memory once more than three occurences are in play. The disadvantage of doing that for numbers with more than one digit is that the BASE no longer influences the number that is pushed by writing 1950.0. But it can easily be that, for this application, this was acceptable. EPOCH still might have been a better name, though. - 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-14 08:50 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Oct14.105043@mips.complang.tuwien.ac.at> |
| In reply to | #118607 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >What would have been more in line with >practice is to define a word 1950.0 which does what writing 1950.0 >without such a word does (if the BASE is right): to push a double-cell >number 19500. ... >EPOCH still might have been a better name, though. One possible reason for not calling it EPOCH would be that the programmer noticed that there were many uses of 1950.0 around the source code and then decided to save memory by defining a named word 1950.0. Calling that word EPOCH would have required to search and replace all occurences of 1950.0, and who knows what editing tools the programmers had at their disposal (probably the classic Forth block editor, which I have never used); in any case, calling the word 1950.0 avoided the need for this step. - 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 | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-14 23:39 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aosq9$1sccf$1@dont-email.me> |
| In reply to | #118607 |
Anton Ertl wrote: > Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >> On 2026-10-13 13:27, Anton Ertl wrote: >>> Niklas Holsti <niklas.holsti@tidorum.invalid> writes: >>>> Forth originated in astronomy, if I remember correctly. I do remember >>>> that in an astronomy-domain Forth program, where it was often necessary >>>> to transform the celestial coordinates of stars from the standard >>>> catalog epoch (the start of the year 1950) to the current time, the word >>>> 1950.0 was defined to perform that transformation. >>> >>> That is unlikely, as explained below. >> >> I am rather sure that my memory is correct. >> >>> In early systems fixed-point was used a lot, and 1950.0 is >>> interpreted as 19500 with a scale factor of 1/10. >> The Forth program in question represented angles as fixed-point >> fractions (0 <= x < 1) of a full circle. I don't remember the number of >> bits used. > > Yes, that was customary for angles, as mentioned in the HOPL-II paper > "The Evolution of Forth" > <https://www.forth.com/resources/forth-programming-language/>: Garmin uses (used?) fixed-point only in their GPSs, with circles stored as a scaled 0:32 value with an implied period in front. Since the Earth is 40 000 km around (over the poles, about 1/300 more along equator), this corresponds to about 9mm precision which they probably thought was more than good enough for a consumer handheld device. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
Page 13 of 24 — ← Prev page 1 … 11 12 [13] 14 15 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web