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 19 of 24 — ← Prev page 1 … 17 18 [19] 20 21 … 24 Next page →
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 19:13 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <11ajbg5$mdk$1@reader2.panix.com> |
| In reply to | #118539 |
In article <2026Oct11.174012@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article <2026Oct10.161800@mips.complang.tuwien.ac.at>, >>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >>>cross@spitfire.i.gajendra.net (Dan Cross) writes: >[Anton Ertl:] >>I do not know what you are referring to when you write, the >>"fact that you did not find it"; did you not notice that I gave >>you _two_ programs, one of which was pretty much the same as the >>C program you gave? What, exactly, are you referring to? > >I was referring to your safe Rust solution. However, I did not look >at it closely enough, especially at your insert, to realize that what >you had done is to turn search into lookup, and that you do not call >search from insert, like the C version does. Clearly. Forgive my saying it, but bluntly, this calls into question your entire reading of my post. >I just saw that there is a similar match in your insert as in search >(and the non-recursive Java version would also have that) and set out >to refine an existing linked-list implementation with insertion at the >end into a tree insertion that does not repeat the match, and I used >your match code from search for the parts that the linked-list >implementation does not do. > >The list variant has the walk to the end separated from the actual >insertion, and the C tree variant also does it that way, and I wanted >the Rust version to do the same, but could not get it past the Rust >compiler. The insertion code did not look particularly nice, either, >checking for something that is alreadu known in the search code. so >to work around the compiler problem, I eventually decided to inline >the search code into insert, and I could get that to compile. > >For testing I then added a lookup, which was derived from the search >part of insert, without mut stuff, so it's full circle back at your >search. > >Anyway, yes, your insert does not work the Java version, but like the >C version with search() inlined into insert(), and like the insert I >finally arrived at. Yes. I take it that here, you are describing the process by which you arrived at the program you posted in your response to me. >Which leads to the question? Can an experienced Rust programmer do a >search that works like the C search(), and an insert that calls >search() and then uses the reference to either update a node or insert >a new one? Given that you did not read the first program in my post carefully, I wonder whether you read the _second_ program in my post carefully, or rather, closed over it like the first. I suggest having a look at that. >>>Like your code and Java code, this has a separate type Tree with a >>>field root and with its own new function, while in C a "struct tree *" >>>variable can serve as root pointer; and this leads to an additional >>>line each in insert and lookup. Can we do without most of that >>>(havibf a constructor is useful) and just use Subtree instead of Tree? >> >>Sure. I do not think it is an interesting exercise, though. > >I tried it for a while, and did not get anything but more and more >compiler errors. *shrug* Is it useful as anything other than an academic exercise? >>>The integration of search in insert led to a duplication of most of >>>the search code in lookup. However, requiring a mutable reference is >>>not necessary for the lookup code, so a search that takes a mutable >>>reference and returns a mutable reference is too restrictive for >>>lookup. But maybe a more experienced Rust programmer can write a >>>generic search that takes an &mut tree for insert, and a & for lookup. >> >>If it offends you that much, you could use a macro. > >Good to know that there is this option. > >>By analogy, in your C, how would it affect things if you wanted >>to `const` qualify the tree pointer for lookups? > >C works perfectly fine without "const", so why would I want to do that? Are you joking? What if you have a `const struct tree` and want to take a pointer to it? More generally this is the sort of thing I'm referring to; Rust is a different language than C, with different semantics, and it imposes different constraints on programs than C. One can, if motivated, find some program that one can express in C, but that cannot be expressed the exact same way in Rust. But why is that notable? One could well invert this: I can define some program that I express in Rust and ask why it cannot be expressed in the exact same way in C. But by itself, that's not terribly interesting; what matters more is whether there are problems, or perhaps more importantly categories of _problems_, that are expressible in one and not the other. I don't think there really are; the solutions might differ in some ways, but that's to be expected because the languages themselves are different. >By contrast, Rust is picky about "mut". If I add it everywhere where >the syntax allows it (which might be the analogon of leaving "const" >away), the borrow checker will complain about programs that it >accepted before adding all the "mut"s. That's right. The language imposes semantic constraints on mutability and references; see my other post about this. But surely this is not surprising? >>>I think that, in order to be the rightful heir, safe Rust should be >>>able to do everything one can do in the other language that's not >>>inherently unsafe, and do it without needing to duplicate code of >>>other nastyness. >> >>I think that criteria is both silly and arbitrary, and has no >>basis in actual practice. You are asserting that an arbitrary >>implementation detail of this one program is a useful yardstick >>by which to measure a language's applicability to an entire >>problem domain, > >Not one detail, the collection of all the details. This is one. All what details? Your statemtn was that, "safe Rust shoudl be able to do everything one can do in the other language that's not inherently unsafe". But missing here is your definition of what you mean by, "unsafe". I gave you Rust's definition: the safety of a program is determined by whether or not the compiler can infer that the program upholds the rules of the language vis borrows, mutability, lifetimes, and so on; that is, whether the borrow checker can do its job. But there are cases where the programmer has some insight into the context of the program that the borrow checker just can't see into; hence, `unsafe` as a part of the language. >>>You may wonder about "inherently unsafe": I have no >>>definition for that yet, but I would not kno why inserting a node into >>>a search tree would ever fall into that category, >> >>Actually, I think perhaps it's the other way around: you do not >>seem to know what "unsafe" means in a Rust context. It is >>merely a statement that the compiler cannot infer that the >>"unsafe" code meets the language's memory safety criteria, and >>that the programmer is asserting that it does; > >I understand that. Forgive me, but I'm not so sure. Under that definition, the entirety of a C program is `unsafe`; it's up to the programmer to uphold the invariants of the language, and there isn't much in the way of requirements on the _language itself_ to help you out. In this way, you seem to be putting a greater burden on Rust than you do on C. >>that is exactly >>the same as every line in a C program. > >The decisive difference is that in a C program there is no end to an >unsafe block, where I have to satisfy safety criteria that are beyond >my experience level. In seeming contradiction to what I wrote above, I think that it _is_ harder to write correct `unsafe` Rust code than to write correct C code, which is one reason Rust programmers try to isolate `unsafe` code as much as possible. The flip side is that, if you do, the language gives you hard guarantees that you can rely on to write correct programs; entire categories of errors are eliminated by construction. The thing that you wrote that does not follow is that `unsafe` Rust code is never allowed to _violate_ those safety criteria; it's just that the programmer takes on burden of upholding them, with less assistance from the language. It is not an escape hatch to YOLO your program. >>I'm afraid that sounds like a problem for you to deal with, not >>a problem with Rust. > >Sure, and the way I deal with that is to not use unsafe Rust. *shrug* That's on you, not on Rust. >>>What I mean is the automatic dropping, and the fact that the Box stuff >>>only occurs in the type declarations, but is automatically >>>dereferenced or otherwise automatically handled; "let x = ..." >>>produces a type automatically (but I guess you could put a type >>>declaration there, though). >> >>Drop and box as a smart pointer is simply "RAII", which has been >>in C++ since the 1980s. Hindley and Milner created the type >>inference rules you are referring to here in the 1970s. > >And? ...and so it's not "automagic". It's simply an application of well-known, pre-existing, techniques. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-10 22:28 +0300 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <20261010222854.0000591c@yahoo.com> |
| In reply to | #118492 |
On Tue, 06 Oct 2026 08:29:19 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> cross@spitfire.i.gajendra.net (Dan Cross) writes:
> >In article <2026Oct3.131214@mips.complang.tuwien.ac.at>,
> >Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> >>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> >>>That's good to know but what is a good resource to learn the Rust
> >>>language? I've looked at the Rust book several times and each
> >>>time come away rather frustrated.
> >>
> >>If you mean "The Rust Programming Language", I came away from it
> >>disillusioned.
> >>
> >>The reason was that I could not get a search-tree insertion
> >>technique to work that can be implemented in e.g., Pascal, C, and
> >>Forth, but not in Java (because in Java I cannot produce references
> >>to a field inside an object).
> >
> >I think what you mean to say is that you couldn't find a way to
> >implement that in the manner you were accustomed to thinking
> >about the problem, given your prior experience.
>
> My goal was to implement search tree insertion as efficiently and
> compactly as in Pascal,
I suppose, you mean some extended Pascal dialect here, because I can not
imagine how you code an example below in Standard Pascal.
Then again, I learned Pascal ~40 years ago and didn't use it in
practice since 1989 or 1990, so can easily miss something.
I would think that it is possible to code your example in Standard
Ada83, but not in "checked" subset of it.
> C or Forth (and in contrast to Java), ideally
> in safe Rust. Here it is in C (untested):
>
> struct tree {
> int key; /* or some other key type */
> int val; /* or some other value type */
> struct tree *left;
> struct tree *right;
> };
>
> struct tree **search(struct tree **rootp, int key)
> {
> while ((root=*rootp)!=NULL && key != root->key) {
> if (key < root->key)
> rootp = &(root->left);
> else
> rootp = &(root->right);
> }
> return rootp;
> }
>
> void insert(struct tree **rootp, int key, int val)
> {
> struct tree **nodep = **search(rootp, key);
> struct tree *node = *nodep;
> if (node == NULL) {
> node = malloc(sizeof(tree));
> node->key = key;
> node->left = NULL;
> node->right = NULL;
> *nodep = node;
> }
> node->val = val;
> }
>
> Passing a reference to a mutable field is what is done in these
> languages, and I don't know an efficient and similarly compact
> technique that does not pass a reference to a mutable field.
>
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-11 09:27 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct11.112704@mips.complang.tuwien.ac.at> |
| In reply to | #118535 |
Michael S <already5chosen@yahoo.com> writes:
>On Tue, 06 Oct 2026 08:29:19 GMT
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>> My goal was to implement search tree insertion as efficiently and
>> compactly as in Pascal,
>
>I suppose, you mean some extended Pascal dialect here, because I can not
>imagine how you code an example below in Standard Pascal.
>Then again, I learned Pascal ~40 years ago and didn't use it in
>practice since 1989 or 1990, so can easily miss something.
Page 75 and 76 of my copy of "Programming in Modula-2" (Second Edition)
contain this:
TreePtr = POINTER TO TreeNode;
TreeNode =
Record
key: CARDINAL;
data: ...
left, right: TreePtr;
END;
PROCEDURE search(VAR p: TreePtr; x: CARDINAL): TreePtr;
BEGIN
IF p # NIL THEN
IF p^.key < x THEN
RETURN search(p^.right,x)
ELSIF p^.key > x THEN
RETURN search(p^.left, x)
ELSE
RETURN p
END
ELSE (* not found, hence insert *)
NEW(p);
WITH p^ DO
key := x;
left := NIL;
right := NIL;
END;
RETURN p
END
END search
You would invoke this with
search(root,needle)^.data := ...;
in order to actually change the field "data", performing the insert
functionality.
One would not want to use this procedure for lookup, given that it
inserts a node with an uninitialized data field when the key is not
found. Wirth gives a loop implementation of lookup before the
PROCEDURE search.
Note that the "VAR" in front of the p makes p a reference parameter
rather than a value parameter (like x), which is key to making this
work for insertion. This language feature is also present in Pascal;
the Pascal syntax is different, but I don't think that prevents
implementing this approach.
Using recursion is necessary here because Modula-2 and Pascal support
references to variables or fields only for parameters. But the
recursive calls are tail-recursive (I don't think that Wirth's
Modula-2 or Parcal compilers optimized tail recursion, 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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-11 22:43 +0300 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <20261011224357.0000479d@yahoo.com> |
| In reply to | #118538 |
On Sun, 11 Oct 2026 09:27:04 GMT anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Tue, 06 Oct 2026 08:29:19 GMT > >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: > >> My goal was to implement search tree insertion as efficiently and > >> compactly as in Pascal, > > > >I suppose, you mean some extended Pascal dialect here, because I can > >not imagine how you code an example below in Standard Pascal. > >Then again, I learned Pascal ~40 years ago and didn't use it in > >practice since 1989 or 1990, so can easily miss something. > > Page 75 and 76 of my copy of "Programming in Modula-2" (Second > Edition) contain this: > > TreePtr = POINTER TO TreeNode; > TreeNode = > Record > key: CARDINAL; > data: ... > left, right: TreePtr; > END; > > PROCEDURE search(VAR p: TreePtr; x: CARDINAL): TreePtr; > BEGIN > IF p # NIL THEN > IF p^.key < x THEN > RETURN search(p^.right,x) > ELSIF p^.key > x THEN > RETURN search(p^.left, x) > ELSE > RETURN p > END > ELSE (* not found, hence insert *) > NEW(p); > WITH p^ DO > key := x; > left := NIL; > right := NIL; > END; > RETURN p > END > END search > > You would invoke this with > > search(root,needle)^.data := ...; > > in order to actually change the field "data", performing the insert > functionality. > > One would not want to use this procedure for lookup, given that it > inserts a node with an uninitialized data field when the key is not > found. Wirth gives a loop implementation of lookup before the > PROCEDURE search. > > Note that the "VAR" in front of the p makes p a reference parameter > rather than a value parameter (like x), which is key to making this > work for insertion. This language feature is also present in Pascal; > the Pascal syntax is different, but I don't think that prevents > implementing this approach. > > Using recursion is necessary here because Modula-2 and Pascal support > references to variables or fields only for parameters. But the > recursive calls are tail-recursive (I don't think that Wirth's > Modula-2 or Parcal compilers optimized tail recursion, though). > > - anton Thank you. I forgot about call by reference feature of Pascal. But even if I was not forgetting about it, using recursive function call to emulate & operator of C probably would not cross my mind.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-06 05:01 -0700 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <861pa3m40z.fsf@linuxsc.com> |
| In reply to | #118421 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> That's good to know but what is a good resource to learn the Rust >> language? I've looked at the Rust book several times and each >> time come away rather frustrated. > > If you mean "The Rust Programming Language", I came away from it > disillusioned. Yes, that's the book I meant. > The reason was that I could not get a search-tree insertion technique > to work that can be implemented in e.g., Pascal, C, and Forth, but not > in Java (because in Java I cannot produce references to a field inside > an object). > > At some point I thought that one would have to use the more > heavy-weight reference-counting stuff to get through the borrow > checker. [discovered later not to be necessary] I think this test case is a good one. Somewhat disappointing that Rust makes it non-obvious. Do you know if what you learned would carry over to, for example, AVL trees? > Then I found the book "Learn Rust With Entirely Too Many Linked > Lists", and I found that the problem could be solved without reference > counting after all. Thank you for this reference. I am just starting to look it over. Do you know if there is a PDF version somewhere rather than the endless-series-of-webpages format shown on its website? > However, the problem in this case is the usual > thing with type inference: There is so much going on that happens > automagically (in particular automatic dereferencing in Rust), and the > Rust compiler does not know where you went wrong, so the error message > is unhelpful (while for the simpler cases the compiler usually guesses > right and gives very helpful, to-the-point error messages). Hmm. That might be worth my while doing some web research for. > Even after reading the second book, I am still disillusioned with > Rust. The Rust fans tend to say: "If it compiles, it runs." The > problem is that it can be harder to get a Rust program to compile than > to debug a program in, say, Forth (which has barely any checking). > For debugging, I at least have a method on how to proceed. When I get > an unhelpful compiler error, I am left to trying various things, > blindly. Can I ask how much experience you have with ML-style languages (e.g., ML, OCaml, Haskell)? I'm wondering how the type inference in Rust compares to the type inference done in those languages.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-06 15:21 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct6.172109@mips.complang.tuwien.ac.at> |
| In reply to | #118495 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> The reason was that I could not get a search-tree insertion technique >> to work that can be implemented in e.g., Pascal, C, and Forth, but not >> in Java (because in Java I cannot produce references to a field inside >> an object). >> >> At some point I thought that one would have to use the more >> heavy-weight reference-counting stuff to get through the borrow >> checker. [discovered later not to be necessary] > >I think this test case is a good one. Somewhat disappointing that >Rust makes it non-obvious. Do you know if what you learned would >carry over to, for example, AVL trees? What I learned? No. I did not really learn it. I saw how I could modify an example from the book to achieve what I want, and understood the explanation of that example, but I do not know how to use this stuff to build code from scratch. Whether it is possible to do AVL trees in safe Rust without resorting to reference-counting and such? Maybe, but I guess there are too many mutable references around in AVL tree operations at the same time. >> Then I found the book "Learn Rust With Entirely Too Many Linked >> Lists", and I found that the problem could be solved without reference >> counting after all. ... >Do you know if there is a PDF version somewhere rather than the >endless-series-of-webpages format shown on its website? I don't know, but I would expect it. The way it looks, it seems to use some software for books in multiple formats. >> Even after reading the second book, I am still disillusioned with >> Rust. The Rust fans tend to say: "If it compiles, it runs." The >> problem is that it can be harder to get a Rust program to compile than >> to debug a program in, say, Forth (which has barely any checking). >> For debugging, I at least have a method on how to proceed. When I get >> an unhelpful compiler error, I am left to trying various things, >> blindly. > >Can I ask how much experience you have with ML-style languages >(e.g., ML, OCaml, Haskell)? I'm wondering how the type inference in >Rust compares to the type inference done in those languages. A little with Miranda and Haskell (Hugs), and the latter is the reason why I have this opinion of type inference: You get a long error message that tells you that there is some inconsistency in the inferred types; because the types are inferred from a significant stretch of code, the problem could be anywhere in this code. My impression is that in Rust you tend to nail down things more often than in Haskell, so the stretches are shorter, but there is more automagic going on in Rust, with automatic defererencing and referencing, automatic dropping, etc., and the borrow checker interacts with the automagic, which makes it at least as hard to deal with as th Haskell type inference. For Haskell I can at least make types explicit at various places to reduce the area where the error might hide, but in Rust I have no way to disable the automagic, and no way (or at least I don't know it) to tell the borrow checker what I think it should be seeing, such that it can tell me where my error is. I have investigated some tool that IIRC rewrite the Rust program to give more information about how it understands the program, but at least for my test case, it was not enlightening. As for the type system, a friend told me that he likes Rust because it gives him what he likes about Haskell's type system in an imperative language. - 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-07 05:41 -0700 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <86a4oplm30.fsf@linuxsc.com> |
| In reply to | #118496 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>> The reason was that I could not get a search-tree insertion technique >>> to work that can be implemented in e.g., Pascal, C, and Forth, but not >>> in Java (because in Java I cannot produce references to a field inside >>> an object). >>> >>> At some point I thought that one would have to use the more >>> heavy-weight reference-counting stuff to get through the borrow >>> checker. [discovered later not to be necessary] >> >> I think this test case is a good one. Somewhat disappointing that >> Rust makes it non-obvious. Do you know if what you learned would >> carry over to, for example, AVL trees? > > What I learned? No. I did not really learn it. I saw how I could > modify an example from the book to achieve what I want, and understood > the explanation of that example, but I do not know how to use this > stuff to build code from scratch. > > Whether it is possible to do AVL trees in safe Rust without resorting > to reference-counting and such? Maybe, but I guess there are too many > mutable references around in AVL tree operations at the same time. A simple search tree can do insertion only at the leaves. Other binary tree insertion methods typically modify interior nodes, and certainly AVL trees fall in this category. Except for the difference of leaf-node-only modification and interior-node modification, I don't see why they should be any different. Is there something about the Rust-safe code that you wrote that depends on modifying only leaf nodes? >>> Then I found the book "Learn Rust With Entirely Too Many Linked >>> Lists", and I found that the problem could be solved without reference >>> counting after all. >>> >>> Even after reading the second book, I am still disillusioned with >>> Rust. The Rust fans tend to say: "If it compiles, it runs." The >>> problem is that it can be harder to get a Rust program to compile than >>> to debug a program in, say, Forth (which has barely any checking). >>> For debugging, I at least have a method on how to proceed. When I get >>> an unhelpful compiler error, I am left to trying various things, >>> blindly. >> >> Can I ask how much experience you have with ML-style languages >> (e.g., ML, OCaml, Haskell)? I'm wondering how the type inference in >> Rust compares to the type inference done in those languages. > > A little with Miranda and Haskell (Hugs), and the latter is the reason > why I have this opinion of type inference: You get a long error > message that tells you that there is some inconsistency in the > inferred types; because the types are inferred from a significant > stretch of code, the problem could be anywhere in this code. > > My impression is that in Rust you tend to nail down things more often > than in Haskell, so the stretches are shorter, but there is more > automagic going on in Rust, with automatic defererencing and > referencing, automatic dropping, etc., and the borrow checker > interacts with the automagic, which makes it at least as hard to deal > with as th Haskell type inference. > > For Haskell I can at least make types explicit at various places to > reduce the area where the error might hide, but in Rust I have no way > to disable the automagic, and no way (or at least I don't know it) to > tell the borrow checker what I think it should be seeing, such that it > can tell me where my error is. > > I have investigated some tool that IIRC rewrite the Rust program to > give more information about how it understands the program, but at > least for my test case, it was not enlightening. > > As for the type system, a friend told me that he likes Rust because it > gives him what he likes about Haskell's type system in an imperative > language. Very interesting. Thank you for the long explanation. I am curious to know more but comp.arch is not the right place for that discussion so I will stop here (and perhaps continue in a better choice of forum).
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-07 14:23 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <11a5kkp$i58$1@reader2.panix.com> |
| In reply to | #118496 |
In article <2026Oct6.172109@mips.complang.tuwien.ac.at>, Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote: >[snip] >My impression is that in Rust you tend to nail down things more often >than in Haskell, so the stretches are shorter, but there is more >automagic going on in Rust, with automatic defererencing and >referencing, automatic dropping, etc., and the borrow checker >interacts with the automagic, which makes it at least as hard to deal >with as th Haskell type inference. The rules for when references are taken, when dereferences happen, and when things are dropped are well-defined; there's no magic there. To a first order approximation, a references is taken using the `&` and `&mut` operators, or when an object is the target of a method call that takes `&self` or `&mut self`. An object is dereferenced using `*` operator, the `.deref()` operator for something that impl's the `Deref` trait, or when using the `.` operator on product types. An object is dropped either when it goes out of scope, or when subject to the `Drop` operator. Rust objects and references have lifetimes, which are a first-class part of the type system. The borrow checker enforces rules relating the lifetimes of objects and their references. Specifically: * A reference to an object cannot outlive the object itself (no dangling references). * If a _mutable_ reference to an object exists at some point in time, then that reference is the only reference to that object. * Any number if _immutable_ references may exist to an object at any given time, mutually exclusive with a mutable reference to that object. Rust references are non-nullable, and the borrow checker rules enforce that they always point to a valid object; the language will not allow you to take a reference to an uninitialized object. There are a couple of fine points here; if you have a mutable reference to something, it's ok to call a method on it that takes `&self`, for example, but for the most part the above is a decent mental model. There are also so-called "raw" pointers in Rust that are similar to pointers in C or Pascal in that they are nullable, can dangle, and don't necessarily have to point to a valid, initialized object. One can create a raw pointer using the `&raw` or `&raw mut` operators, by assignment from a reference, or by an explicit function/cast. Creating a raw pointer is considered safe, since they do not have to be valid. However, dereferencing a raw pointer is `unsafe`, meaning that it is the programmer's responsibility to ensure that it points to a valid object before dereferencing. Raw pointers also have a notion of "provenance", which tracks their origin (think capabilities in the CHERI sense here; indeed CHERI was the motivation for the "strict provenance" APIs: https://doc.rust-lang.org/std/ptr/index.html#strict-provenance). >For Haskell I can at least make types explicit at various places to >reduce the area where the error might hide, but in Rust I have no way >to disable the automagic, and no way (or at least I don't know it) to >tell the borrow checker what I think it should be seeing, such that it >can tell me where my error is. This is classic, "fighting the borrow checker." The checker will tell you exactly where it thinks your error is, as far as saying, "you use a reference at this point, when the object it points to went out of scope at this other point..." or "you attempted to take a mutable reference to an object while another live reference to it already existed..." or "you tried to take *any* reference to an object while a live mutable reference exists". There's no magic here, and generally the error messages are pretty good. The `unsafe` keyword is the escape hatch that tells the compiler that I, the programmer, am doing something weird that it has no insight into, and so it cannot automatically enforce its checks, and that I am therefore taking on the responsibility of ensuring that the language's rules with respect to memory safety and concurrency are respected. Note that `unsafe` does not allow a programmer to _violate_ those rules, it merely tells the compiler that they've been checked manually. Once you get used to it, the borrow checker is unintrusive, and it really does catch errors that would lead to crashes or mangled data in other languages. But if you are trying to write a Rust program the same way you would in a language that is not type- and memory-safe, like C or (I gather) Forth, you will almost certainly find it very frustrating. >I have investigated some tool that IIRC rewrite the Rust program to >give more information about how it understands the program, but at >least for my test case, it was not enlightening. Perhaps you are referring to Miri? That is a simulator for the IR, that can be used to find bugs in raw pointer usage in `unsafe` code. >As for the type system, a friend told me that he likes Rust because it >gives him what he likes about Haskell's type system in an imperative >language. Yes. The type system allows you to make aggressive use of things like "typestates" and "newtypes" to eliminate entire categories of errors. The "Parse, don't validate" metaphor introduced by Alexis King on her blog post (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/) translates almost directly from Haskell to Rust; my colleague Cliff Biffle has written on typestates in Rust here: https://cliffle.com/blog/rust-typestate/ When I wrote the host OS boot loader for our machines (the thing we run from the reset vector) I used newtypes to describe page mappings so that virtaul page addresses of a certain size _had_ to be canonical and properly aligned and _had_ to point to a correctly sized and aligned physical page frame that was similarly valid. Once one has parsed a virtual page address or physical frame address into its representative type, there's no need to revalidate it at point of use. The existence of an instance of those types is a proof that the addresses are valid: https://github.com/oxidecomputer/phbl/blob/main/src/mmu.rs These techniques apply to all sorts of things. Making a erroneous combination unrepresentable at the type level is an incredibly powerful tool. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2026-10-06 21:18 -0400 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <9v6bcl1l61ou3602t1fqifa5jedr12nj6d@4ax.com> |
| In reply to | #118495 |
On Tue, 06 Oct 2026 05:01:32 -0700, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: > >> Then I found the book "Learn Rust With Entirely Too Many Linked >> Lists", and I found that the problem could be solved without reference >> counting after all. > >Thank you for this reference. I am just starting to look it over. >Do you know if there is a PDF version somewhere rather than the >endless-series-of-webpages format shown on its website? At the upper right are controls to go to the GIT repository or "print" the book as rendered. BUt it seems that if you print/save you'll lose the table of contents.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-06 22:17 -0700 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <86ld8aks1u.fsf@linuxsc.com> |
| In reply to | #118504 |
George Neuner <gneuner2@comcast.net> writes: > On Tue, 06 Oct 2026 05:01:32 -0700, Tim Rentsch > <tr.17687@z991.linuxsc.com> wrote: > >> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >> >>> Then I found the book "Learn Rust With Entirely Too Many Linked >>> Lists", and I found that the problem could be solved without reference >>> counting after all. >> >> Thank you for this reference. I am just starting to look it over. >> Do you know if there is a PDF version somewhere rather than the >> endless-series-of-webpages format shown on its website? > > At the upper right are controls to go to the GIT repository or "print" > the book as rendered. BUt it seems that if you print/save you'll lose > the table of contents. Okay great. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-03 14:25 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119qs71$308or$1@dont-email.me> |
| In reply to | #118413 |
Tim Rentsch wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> Tim Rentsch wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>> [on learning Rust] >>> >>>> Quite often, when "fighting the borrow checker", typically because >>>> I'm updating a complicated data structure in two locations at the >>>> same time, I'll fall back to "write Fortran in Rust", with every >>>> access indexed. >>>> >>>> This is BTW one of those problems the brand new upcoming borrow >>>> checker is supposed to be far better at figuring out: If I'm >>>> updating totally separate parts of the same larger structure, >>>> then it should be OK to mutate both at the same time. >>>> >>>> I do realize that there are far more Rusty ways to solve this >>>> type of issue, they just don't come naturally to me yet. >>> >>> (Please excuse my pursuing this non-arch topic...) >>> >>> Question for any Rusters in the group -- >>> >>> What is the best was to learn the Rust programming language? >>> Which books or other documents are the best introductory or >>> reference materials? >>> >>> Disclaimer: My experience with Rust is more than zero but >>> not a lot more than zero. >> >> My personal Rust journey has been driven by a desire to match or >> beat the fastest known times for the Advent of Code puzzles, from >> 2015 to 2025. > > That's good to know but what is a good resource to learn the Rust > language? I've looked at the Rust book several times and each > time come away rather frustrated. > I don't have any suggestions here, I tend to google any questions I have, then follow those links that point into the Rust std lib. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-03 21:08 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86mrsum7k3.fsf@linuxsc.com> |
| In reply to | #118424 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: > Tim Rentsch wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: [...] >>> My personal Rust journey has been driven by a desire to match or >>> beat the fastest known times for the Advent of Code puzzles, from >>> 2015 to 2025. >> >> That's good to know but what is a good resource to learn the Rust >> language? I've looked at the Rust book several times and each >> time come away rather frustrated. > > I don't have any suggestions here, I tend to google any questions I > have, then follow those links that point into the Rust std lib. Okay. Kind of disappointing but thank you for the followup.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 12:29 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a0580$gjj$1@reader2.panix.com> |
| In reply to | #118350 |
In article <86pkxtplou.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Terje Mathisen <terje.mathisen@tmsw.no> writes: > >[on learning Rust] > >> Quite often, when "fighting the borrow checker", typically because >> I'm updating a complicated data structure in two locations at the >> same time, I'll fall back to "write Fortran in Rust", with every >> access indexed. >> >> This is BTW one of those problems the brand new upcoming borrow >> checker is supposed to be far better at figuring out: If I'm >> updating totally separate parts of the same larger structure, >> then it should be OK to mutate both at the same time. >> >> I do realize that there are far more Rusty ways to solve this >> type of issue, they just don't come naturally to me yet. > >(Please excuse my pursuing this non-arch topic...) > >Question for any Rusters in the group -- > >What is the best was to learn the Rust programming language? >Which books or other documents are the best introductory or >reference materials? > >Disclaimer: My experience with Rust is more than zero but >not a lot more than zero. Without knowing what methods you have tried, what books you have already explored, what you found dissatisfying about them, and why, it is impossible to give you a good answer. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-12 01:49 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86mrsji9qt.fsf@linuxsc.com> |
| In reply to | #118477 |
cross@spitfire.i.gajendra.net (Dan Cross) writes: > In article <86pkxtplou.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >> [on learning Rust] >> >>> Quite often, when "fighting the borrow checker", typically because >>> I'm updating a complicated data structure in two locations at the >>> same time, I'll fall back to "write Fortran in Rust", with every >>> access indexed. >>> >>> This is BTW one of those problems the brand new upcoming borrow >>> checker is supposed to be far better at figuring out: If I'm >>> updating totally separate parts of the same larger structure, >>> then it should be OK to mutate both at the same time. >>> >>> I do realize that there are far more Rusty ways to solve this >>> type of issue, they just don't come naturally to me yet. >> >> (Please excuse my pursuing this non-arch topic...) >> >> Question for any Rusters in the group -- >> >> What is the best was to learn the Rust programming language? >> Which books or other documents are the best introductory or >> reference materials? >> >> Disclaimer: My experience with Rust is more than zero but >> not a lot more than zero. > > Without knowing what methods you have tried, what books you have > already explored, what you found dissatisfying about them, and > why, it is impossible to give you a good answer. Fortunately some other people found it possible to give helpful replies.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 13:05 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11ailv5$k3$1@reader2.panix.com> |
| In reply to | #118555 |
In article <86mrsji9qt.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: > >> In article <86pkxtplou.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>> [on learning Rust] >>> >>>> Quite often, when "fighting the borrow checker", typically because >>>> I'm updating a complicated data structure in two locations at the >>>> same time, I'll fall back to "write Fortran in Rust", with every >>>> access indexed. >>>> >>>> This is BTW one of those problems the brand new upcoming borrow >>>> checker is supposed to be far better at figuring out: If I'm >>>> updating totally separate parts of the same larger structure, >>>> then it should be OK to mutate both at the same time. >>>> >>>> I do realize that there are far more Rusty ways to solve this >>>> type of issue, they just don't come naturally to me yet. >>> >>> (Please excuse my pursuing this non-arch topic...) >>> >>> Question for any Rusters in the group -- >>> >>> What is the best was to learn the Rust programming language? >>> Which books or other documents are the best introductory or >>> reference materials? >>> >>> Disclaimer: My experience with Rust is more than zero but >>> not a lot more than zero. >> >> Without knowing what methods you have tried, what books you have >> already explored, what you found dissatisfying about them, and >> why, it is impossible to give you a good answer. > >Fortunately some other people found it possible to give >helpful replies. Oh? Which ones? I saw few responses to your question, and the only other references given were to the standard library source code or, "Learning Rust With Entirely Too Many Linked Lists" (https://rust-unofficial.github.io/too-many-lists/), by Aria Desires. What did you find useful about those, and how, for you, did they improve on the references you had already reviewed? - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 12:29 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a056c$7hp$1@reader2.panix.com> |
| In reply to | #118338 |
In article <119jbt5$cn3a$1@dont-email.me>, Terje Mathisen <terje.mathisen@tmsw.no> wrote: >Dan Cross wrote: >> In article <20260928195833.00001d42@yahoo.com>, >> Michael S <already5chosen@yahoo.com> wrote: >>> [snip] >>> My only Rust program was full of casts of various integer types to >>> usize. Exactly for the purpose of array indexing. >> >> Beginning Rust programmers tend to go through a few phases, >> particularly if coming from a language like C. "Fighting the >> Borrow Checker" is well-known; "traits are awesome; let's use >> them everywhere!" is another. >> >> When I started programming in Rust, most of my immediate >> colleagues and I had terribly little experience in the language. >> We were excited about the its potential benefits, but realized >> it would take a few months to build up a sufficient level of >> familiarity to use it skillfully. One quipped, "this language >> has a near-vertical learning curve." >> >> At one point a coworker (self-deprecatingly) said, "look, I'm >> writing crust! C in Rust syntax!" Everyone thought this was a >> great play on words, but he was correct: the programs we were >> writing were essentially C programs, just expressed in Rust. We >> quickly adopted that to describe our still naive code: it wasn't >> an insult, just an expression that we were still coming to terms >> with a new way of doing things. Some of the hallmarks of that >> included using the wrong paradigms (and types!) for lots of our >> code. > >I have definitely noted this in my own code, crust is a good name for it. > >Quite often, when "fighting the borrow checker", typically because I'm >updating a complicated data structure in two locations at the same time, >I'll fall back to "write Fortran in Rust", with every access indexed. I myself have done this on more than one occasion; it's a quick way to get going. When I wrote the rxv64 operating system, for instance, and got to the part where I was implementing a 6th Ed Unix-style buffer cache, and needed a doubly linked list, I ended up using an array as a proxy, with next and prev indices instead of pointers. The cache in simple systems is fixed sized anyway, so it wasn't a major imposition. >This is BTW one of those problems the brand new upcoming borrow checker >is supposed to be far better at figuring out: If I'm updating totally >separate parts of the same larger structure, then it should be OK to >mutate both at the same time. Yes, Polonius (named for the character from Hamlet). It is now in Alpha in nightly rustc builds. https://blog.rust-lang.org/2026/08/04/enabling-polonius-alpha-on-nightly/ >I do realize that there are far more Rusty ways to solve this type of >issue, they just don't come naturally to me yet. Things like Cell, RefCell, etc, supporting interior mutability are the usual solutions to things like that. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-28 15:34 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <kOvuS.16$MN2.7@fx45.iad> |
| In reply to | #118261 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >Michael S <already5chosen@yahoo.com> writes: > <int_fast_32_discussion> >> That's not universal. >> For example, on both alive 64-bit Windows targets int_fast32_t is >> 32-bit. >> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >> targets. >> >> Besides, int_fast32_t is both above my threshold of acceptable ugliness >> and acceptable geekery. > >I favor a type equivalent to size_t for use as array index variables. I -use- size_t for array index variables.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-29 12:42 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <8633urrgj1.fsf@linuxsc.com> |
| In reply to | #118296 |
scott@slp53.sl.home (Scott Lurndal) writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Michael S <already5chosen@yahoo.com> writes: > > <int_fast_32_discussion> > >>> That's not universal. >>> For example, on both alive 64-bit Windows targets int_fast32_t is >>> 32-bit. >>> Godbolt shows the same for clang for MIPS64. I have no idea what OS it >>> targets. >>> >>> Besides, int_fast32_t is both above my threshold of acceptable ugliness >>> and acceptable geekery. >> >> I favor a type equivalent to size_t for use as array index variables. > > I -use- size_t for array index variables. I generally do not use the type name size_t for indicating anything other than values meant to hold a size in bytes, such as would be produced by the sizeof operator. I do use the type size_t for all sorts of other different things, but normally with a different name given by using a typedef. An example is the type name Index for variables meant to hold array index values. I find using such more specific names, rather than using size_t everywhere, generally makes code easier to read and understand.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-28 10:54 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119da08$23bo0$5@dont-email.me> |
| In reply to | #118256 |
On 27/09/2026 18:43, Michael S wrote: > On Sun, 27 Sep 2026 18:04:05 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 27/09/2026 17:18, Michael S wrote: >> >>> >>> Fortran is not the same as C. >>> My understanding is that in Fortran array indexes are by default >>> 32-bit. That couses real cost under wrapv. >>> In C there is no such thing as default size of array index. The >>> programmer can define it as 32-bit and suffer the same performance >>> degradatioon under wrapv as Fortran does. Or he can define index as >>> either ptrdiff_t or size_t and suffere no degradation. >>> >> >> You certainly /can/ do that. But a lot of C code uses "int" for >> array indexing. The "ideal" type in many cases would be >> "int_fast32_t" to say it should be of a big enough size (32-bit is >> enough range for a great many purposes) but can bigger if that's >> faster. On most 64-bit targets, "int_fast32_t" will be 64-bit. >> > > That's not universal. Sure - it is implementation-dependent, usually defined by a platform ABI. > For example, on both alive 64-bit Windows targets int_fast32_t is > 32-bit. > Godbolt shows the same for clang for MIPS64. I have no idea what OS it > targets. > That's interesting - thanks for the correction. I will have to be more nuanced - on /many/ 64-bit targets, int_fast32_t is 64-bit. (I also see, from godbolt, that it is 64-bit on 64-bit ARM for Linux but again is 32-bit on 64-bit ARM for Windows.) > Besides, int_fast32_t is both above my threshold of acceptable ugliness > and acceptable geekery. It is not pretty, no. And I think that is the main hinder for the use of the "fast" and "least" integer types. I have very rarely used them myself - only on code that I know was to be used on 8-bit AVRs and 32-bit ARMs. > > >> The thing you want is that your loops with "a[i++]" operations are >> implemented as "*p++" rather than "*(a + i); i = (i + 1) & >> 0xffff'ffff)". The later is what you end up with if you use an >> unsigned 32-bit type or a signed 32-bit type with forced wrapping >> semantics. >> >> So you can either use a 64-bit type (signed or unsigned), or use >> normal 32-bit "int" as usual, but without forcing wrapping semantics >> on it. >> >> > >
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-27 17:39 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119bkcq$1gqec$1@dont-email.me> |
| In reply to | #118251 |
Michael S <already5chosen@yahoo.com> schrieb: > On Sun, 27 Sep 2026 13:42:05 -0000 (UTC) > Thomas Koenig <tkoenig@netcologne.de> wrote: > [Polyhedron benchmark, which is Fortran] >> Geometric Mean Execution Time = 11.73 seconds >> >> The geometric mean increased by around 11%. Some tests were >> within shouting each other. Others (air, linpk, nf, tfft2) show >> significant differences. >> >> So at least for that particular codebase, taking away the >> freedom of the compiler to optimize based on the assumption >> that integers will never overflow, and replacing it with >> something defined, leads to a significant slowdown. >> > > > Fortran is not the same as C. C and Fortran share the same rules about integer overflow. But if you run any program through the NAG compiler, it is translated to a C program. > My understanding is that in Fortran array indexes are by default 32-bit. That understanding turns out to be wrong. In Fortran, an array index is an integer expression, and that can be of any KIND that the compiler supports. You can write use iso_fortran_env, only :: int64 integer(int64) :: i integer :: j This will declare a 64-bit integer variable i and a default integer variable j. You can then access an array A either way, for exmaple real, dimension(whatever) :: a a(i) = something a(j) = something_else > That couses real cost under wrapv. > In C there is no such thing as default size of array index. Neither is there in Fortran. There is a default integer, which is typically 32 bit. > The > programmer can define it as 32-bit and suffer the same performance > degradatioon under wrapv as Fortran does. Or he can define index as > either ptrdiff_t or size_t and suffere no degradation. A Fortran programmer can do exactly the same; he could even import C_PTRDIFF_T from the ISO_C_BINDING module. In that respect, there is not difference between C and Fortran. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
Page 19 of 24 — ← Prev page 1 … 17 18 [19] 20 21 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web