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 18 of 24 — ← Prev page 1 … 16 17 [18] 19 20 … 24 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-28 19:58 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260928195833.00001d42@yahoo.com> |
| In reply to | #118285 |
On Mon, 28 Sep 2026 02:59:06 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: > > > Tim Rentsch wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> On Sun, 27 Sep 2026 18:04:05 +0200 > >>> David Brown <david.brown@hesbynett.no> wrote: > >>> > >>>> On 27/09/2026 17:18, Michael S wrote: > >>>> > >>>>> Fortran is not the same as C. > >>>>> My understanding is that in Fortran array indexes are by default > >>>>> 32-bit. That couses real cost under wrapv. > >>>>> In C there is no such thing as default size of array index. The > >>>>> programmer can define it as 32-bit and suffer the same > >>>>> performance degradatioon under wrapv as Fortran does. Or he > >>>>> can define index as either ptrdiff_t or size_t and suffere no > >>>>> degradation. > >>>> > >>>> You certainly /can/ do that. But a lot of C code uses "int" for > >>>> array indexing. The "ideal" type in many cases would be > >>>> "int_fast32_t" to say it should be of a big enough size (32-bit > >>>> is enough range for a great many purposes) but can bigger if > >>>> that's faster. On most 64-bit targets, "int_fast32_t" will be > >>>> 64-bit. > >>> > >>> That's not universal. > >>> For example, on both alive 64-bit Windows targets int_fast32_t is > >>> 32-bit. > >>> Godbolt shows the same for clang for MIPS64. I have no idea what > >>> OS it targets. > >>> > >>> Besides, int_fast32_t is both above my threshold of acceptable > >>> ugliness and acceptable geekery. > >> > >> I favor a type equivalent to size_t for use as array index > >> variables. > > > > In Rust, the only acceptable array index is of type "usize", which > > is effectively the same as u64 on most platforms these days, but > > does not need to be so: On a 32-bit target, it would be the same > > as u32. > > > > So effectively very similar to size_t. > > Maybe that limitation works okay in Rust. In C sometimes it's > important to allow a signed value for indexing. Probably 99% of > the time size_t is good, but not always. My only Rust program was full of casts of various integer types to usize. Exactly for the purpose of array indexing.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-29 15:44 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86y0cjpthz.fsf@linuxsc.com> |
| In reply to | #118299 |
Michael S <already5chosen@yahoo.com> writes: > On Mon, 28 Sep 2026 02:59:06 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>> Tim Rentsch wrote: [...] >>>> I favor a type equivalent to size_t for use as array index >>>> variables. >>> >>> In Rust, the only acceptable array index is of type "usize", which >>> is effectively the same as u64 on most platforms these days, but >>> does not need to be so: On a 32-bit target, it would be the same >>> as u32. >>> >>> So effectively very similar to size_t. >> >> Maybe that limitation works okay in Rust. In C sometimes it's >> important to allow a signed value for indexing. Probably 99% of >> the time size_t is good, but not always. > > My only Rust program was full of casts of various integer types to > usize. Exactly for the purpose of array indexing. That tells me a lot. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-09-30 13:57 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119j4g4$4kn$1@reader1.panix.com> |
| In reply to | #118299 |
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'd be curious to know more about your program. I've written several hundred kloc of Rust at this point, and while what I write may be terribly specialized, I rarely find myself indexing an array; often, I'm using iterators or some other abstraction for that kind of thing. If that was the one program you have written in Rust, my _guess_ is that you were using paradigms appropriate to a different language, which is why you felt you needed to reach for casts to index an array so frequently. Again, that's not a comment on your program, so much as suggesting an impedence mismatch between what you wrote and how one would generally expect to use the language. In general, I think a person's experience writing a single program tells us very little. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-09-30 17:50 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20260930175006.000031dd@yahoo.com> |
| In reply to | #118336 |
On Wed, 30 Sep 2026 13:57:24 -0000 (UTC) cross@spitfire.i.gajendra.net (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. > I didn't reach the second stage. Not sure about first. > 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." > IMHO, he is correct. Rust is certainly the hardest to learn out of computer languges that I ever tried that I would not call idiotic. > 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'd be curious to know more about your program. The program was an implementation scalable flood fill algorithm (i.e. one with much better than typical worst case BigO properties, both for speed and for space) together with test benches for correctness and speed. As you could guess, I didn't really wrote it in Rust. It was a non-literal port from C. The purpose of translation was two-fold: improvement of my knowledge of Rust and getting better feel for cost of mandatory bound checking for one particular sort of data structures. Before doing Rust port I did port to Golang. Unlike for Rust, where I only read The Book and went trough part of tutorial, I had small previous practical experience in Go, but it was not very recent. Still, the difference in my productivity was huge. In favor of Go, of course. > I've written > several hundred kloc of Rust at this point, and while what I > write may be terribly specialized, I rarely find myself indexing > an array; often, I'm using iterators or some other abstraction > for that kind of thing. If that was the one program you have > written in Rust, my _guess_ is that you were using paradigms > appropriate to a different language, which is why you felt you > needed to reach for casts to index an array so frequently. > > Again, that's not a comment on your program, so much as > suggesting an impedence mismatch between what you wrote and how > one would generally expect to use the language. > > In general, I think a person's experience writing a single > program tells us very little. > I never pretended otherwise. Although I don't see how one can avoid cast if one wants to use indices that originate in signed domain. Or, as was often a case in this particular program, in domain of narrower unsigned integers. > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 11:47 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a02pc$eql$1@reader2.panix.com> |
| In reply to | #118337 |
In article <20260930175006.000031dd@yahoo.com>, Michael S <already5chosen@yahoo.com> wrote: >On Wed, 30 Sep 2026 13:57:24 -0000 (UTC) >cross@spitfire.i.gajendra.net (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. > >I didn't reach the second stage. Not sure about first. > >> 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." > >IMHO, he is correct. >Rust is certainly the hardest to learn out of computer languges that I >ever tried that I would not call idiotic. She, actually, but yes. I guess it depends on one's background, but in general if you are coming from many years of experience in languages like C or C++, Rust can be a real slog. I've seen some anecdotal reports that teaching it to programming neophytes as a first language is actually quite productive. >> 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'd be curious to know more about your program. > >The program was an implementation scalable flood fill algorithm (i.e. >one with much better than typical worst case BigO properties, both for >speed and for space) together with test benches for correctness and >speed. As you could guess, I didn't really wrote it in Rust. It was a >non-literal port from C. The purpose of translation was two-fold: >improvement of my knowledge of Rust and getting better feel for cost of >mandatory bound checking for one particular sort of data structures. So mandatory bounds checking will usually be compiled out in optimized builds; you can choose to keep it in, but most don't. >Before doing Rust port I did port to Golang. Unlike for Rust, where I >only read The Book and went trough part of tutorial, I had small >previous practical experience in Go, but it was not very recent. Still, >the difference in my productivity was huge. In favor of Go, of course. Indeed. Sometimes I find Go far more productive, and other times Rust. It really depends on the category of problem I am working on. >> I've written >> several hundred kloc of Rust at this point, and while what I >> write may be terribly specialized, I rarely find myself indexing >> an array; often, I'm using iterators or some other abstraction >> for that kind of thing. If that was the one program you have >> written in Rust, my _guess_ is that you were using paradigms >> appropriate to a different language, which is why you felt you >> needed to reach for casts to index an array so frequently. >> >> Again, that's not a comment on your program, so much as >> suggesting an impedence mismatch between what you wrote and how >> one would generally expect to use the language. >> >> In general, I think a person's experience writing a single >> program tells us very little. > >I never pretended otherwise. No I know, but at least one other reader appeared to. >Although I don't see how one can avoid >cast if one wants to use indices that originate in signed domain. Or, >as was often a case in this particular program, in domain of narrower >unsigned integers. Well, for narrower to wider unsigned types, there is `into()`. Depending on what you were using for the underlying collection, there is also the `std::ops::Index` trait that you could `impl` for index types other than `usize`, and container types other than primitive arrays and slices. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-30 18:03 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119jbt5$cn3a$1@dont-email.me> |
| In reply to | #118336 |
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. 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. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-30 17:49 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1790790574-5857@newsgrouper.org> |
| In reply to | #118338 |
Terje Mathisen <terje.mathisen@tmsw.no> posted: > 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. Wouldn't that be FRustrating ?!? > 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. > > Terje >
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-01 06:58 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86pkxtplou.fsf@linuxsc.com> |
| In reply to | #118338 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-02 20:38 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119otm8$2c89q$2@dont-email.me> |
| In reply to | #118350 |
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. 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-02 21:23 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86ik3jo1js.fsf@linuxsc.com> |
| In reply to | #118398 |
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.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-03 11:12 +0000 |
| Subject | Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct3.131214@mips.complang.tuwien.ac.at> |
| In reply to | #118413 |
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). At some point I thought that one would have to use the more heavy-weight reference-counting stuff to get through the borrow checker. 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. 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). 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. - 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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-05 12:45 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <11a0662$gic$1@reader2.panix.com> |
| In reply to | #118421 |
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. But that is separate from whether it can be done or not. In fact, in Rust you can use the approximately the same techniques you would use in Pascal, C, or (probably) Forth: raw pointers are a part of the language, and you can simply use them with `unsafe` code, and it would be no more "unsafe" than in C or Pascal. One might argue that that defeats the purpose of the language, and you'd be right to a point. The difference is that in C or Pascal, the entire program is what Rust would call "unsafe", whereas generally this can be restricted to just a few lines of carefully audited code in Rust. FWIW, for things like containers of various kinds (trees, hash tables, linked-lists, growable arrays, etc), production programs usually use an existing library or crate instead of rolling their own. >At some point I thought that one would have to use the more >heavy-weight reference-counting stuff to get through the borrow >checker. > >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. 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). > >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. Sounds like you're in what we'd call the, "fighting the borrow checker" stage. It may be that you end up really not liking Rust or feeling that other languages are better, but I wager that just about anyone who has seriously used the language has gone through similar things. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-06 08:29 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct6.102919@mips.complang.tuwien.ac.at> |
| In reply to | #118478 |
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, 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.
I also knew Java solutions to the problem:
1) Special-case the root (which you typically have to do in Java
anyway, and otherwise always keep a pointer to the last tree node
around, and also keep the knowledge about the last left-or-right
decision around (or take it again). This all leads to quite a bit of
code that is duplicated relative to the code above.
2) Recurse into the tree and rewrite all the links to the subtrees
along the spine of the search. This is not quite as duplicative as 1)
(but the root still has to be handled separately), but it performs
several writes instead of just one, and the recursion is not a tail
recursion, so is relatively expensive.
I wanted something with the benefits of the Pascal/C/Forth variant,
not something like the Java variants. I don't know if that counts as
"manner you were accustomed to thinking about the problem".
And I learned this technique in Pascal or Modula-2 (probably from one
of Wirth's books), and had no problem transferring the knowledge into
C or Forth, on the contrary: In C and Forth I could turn search into a
loop (in Pascal it has to be a tail-recursive function, because you
can only produce references to variables and fields through reference
parameters).
For a language that aspires to take over from C for systems
programming, I expect that one can use this technique, too.
>But that is separate from whether it can be done or not.
Sure, and as I found out later, it can be done.
>In fact, in Rust you can use the approximately the same
>techniques you would use in Pascal, C, or (probably) Forth: raw
>pointers are a part of the language, and you can simply use them
>with `unsafe` code, and it would be no more "unsafe" than in C
>or Pascal. One might argue that that defeats the purpose of the
>language, and you'd be right to a point. The difference is that
>in C or Pascal, the entire program is what Rust would call
>"unsafe", whereas generally this can be restricted to just a few
>lines of carefully audited code in Rust.
Given that I do not understand the automagic stuff done by the Rust
compiler enough to get this kind of tree insertion past the borrow
checker, even though it is possible, I don't trust my capabilities to
audit unsafe Rust.
>FWIW, for things like containers of various kinds (trees, hash
>tables, linked-lists, growable arrays, etc), production programs
>usually use an existing library or crate instead of rolling
>their own.
When I saw that this technique cannot be implemented in Java, I
wondered why Java was not having references to fields (answer:
probably because that would make garbage collection more costly and/or
less precise), that this technique is needed for relatively few
things, mostly stuff that's in libraries. And I wondered how these
library methos are implemented (at one point I guessed that they
implemented these parts of their libraries in C, but when I actually
look, the implementation of what I looked at was in Java, IIRC along
the lines of 1)).
For a language that aspires to replace C for systems programming,
giving the Java answer is not good enough, though.
>>At some point I thought that one would have to use the more
>>heavy-weight reference-counting stuff to get through the borrow
>>checker.
>>
>>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. 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).
>>
>>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.
>
>Sounds like you're in what we'd call the, "fighting the borrow
>checker" stage. It may be that you end up really not liking
>Rust or feeling that other languages are better, but I wager
>that just about anyone who has seriously used the language has
>gone through similar things.
I wonder about that. From the books I read, I get the impression that
Rust used to have less automagic stuff, and much of the automagic was
added later, as a convenience for the programmers who already knew the
language. So the Rust programmers of the early days formed a mental
model based on "Pedestrian Rust" (i.e., with less automagic), and when
they see a program with more automagic, and need to understand some
conveniently short piece of Rust code in detail, they form a mental
model of the code in Pedestrian Rust. But how can a Rust programmer
who starts now learn Pedestrian Rust and how it relates to the modern
language. There are hints in the books I read, but not enough to get
a firm foundation.
- 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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-07 18:29 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <11a6326$qkk$1@reader2.panix.com> |
| In reply to | #118492 |
[Crossposted and and Followup-To: comp.programming]
In article <2026Oct6.102919@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> 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, 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;
>}
An intersting way to write it; I understand you're trying to
reuse `search` in `insert`, below, and thus why you want to
return `rootp`.
>void insert(struct tree **rootp, int key, int val)
>{
> struct tree **nodep = **search(rootp, key);
I know you said this was untested; clearly you should not
indirect the result of `search` here.
> 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.
>
>I also knew Java solutions to the problem:
>
>1) Special-case the root (which you typically have to do in Java
>anyway, and otherwise always keep a pointer to the last tree node
>around, and also keep the knowledge about the last left-or-right
>decision around (or take it again). This all leads to quite a bit of
>code that is duplicated relative to the code above.
>
>2) Recurse into the tree and rewrite all the links to the subtrees
>along the spine of the search. This is not quite as duplicative as 1)
>(but the root still has to be handled separately), but it performs
>several writes instead of just one, and the recursion is not a tail
>recursion, so is relatively expensive.
Or, 3) Simply reimplement the comparison in `insert`; it's a
trivial amount of code.
I chose a variant of (1) for my implementation, but only because
it was easy, not because it was required. No unsafe code or
fancy reference counting here.
--->BEGIN `tree.rs`<---
//! Simple binary search tree.
use std::cmp::Ordering;
use std::fmt::Debug;
/// A binary search tree over any key type that implements a
/// total ordering.
pub struct Tree<K: Debug + Ord, V: Debug> {
root: Option<Box<Node<K, V>>>,
}
impl<K: Debug + Ord, V: Debug> Tree<K, V> {
/// Creates a new, empty tree.
pub fn new() -> Tree<K, V> {
Tree { root: None }
}
/// Searches the tree for the given key, and returns
/// `Some(&value)` if it's here, otherwise returns None.
///
/// # Example
///
/// ```
/// let mut tree = tree::Tree::<i32, i32>::new();
/// tree.insert(2, 200);
/// tree.insert(1, 100);
/// assert_eq!(tree.search(&0), None);
/// assert_eq!(tree.search(&1), Some(&100));
/// assert_eq!(tree.search(&2), Some(&200));
/// ```
pub fn search(&self, key: &K) -> Option<&V> {
let mut root = &self.root;
while let Some(node) = root {
match key.cmp(&node.key) {
Ordering::Less => root = &node.left,
Ordering::Equal => return Some(&node.value),
Ordering::Greater => root = &node.right,
}
}
None
}
/// Inserts the given `value` into the tree with the given
/// `key`. Returns true if the node was inserted, or false
/// if the key was already in the tree.
///
/// # Example
///
/// ```
/// let mut tree = tree::Tree::<i32, i32>::new();
/// assert_eq!(tree.insert(1, 100), true);
/// assert_eq!(tree.insert(1, 200), false);
/// assert_eq!(tree.insert(2, 100), true);
/// ```
pub fn insert(&mut self, key: K, value: V) -> bool {
let mut root = &mut self.root;
loop {
let Some(node) = root else {
root.replace(Node::new(key, value));
return true;
};
match key.cmp(&node.key) {
Ordering::Less => root = &mut node.left,
Ordering::Equal => return false,
Ordering::Greater => root = &mut node.right,
}
}
}
/// Print the tree, if it is not empty.
pub fn print(&self) {
if let Some(node) = &self.root {
node.print();
}
}
}
// A node in the tree owns its key, value, and left and right
// children.
struct Node<K: Debug + Ord, V: Debug> {
key: K,
value: V,
left: Option<Box<Node<K, V>>>,
right: Option<Box<Node<K, V>>>,
}
impl<K: Debug + Ord, V: Debug> Node<K, V> {
/// Creates a new boxed node owning the given key and value.
pub fn new(key: K, value: V) -> Box<Node<K, V>> {
Box::new(Node {
key,
value,
left: None,
right: None,
})
}
/// Pre-order print of this node and its children.
pub fn print(&self) {
if let Some(left) = &self.left {
left.print();
}
println!("key = {:?}, value = {:?}", self.key, self.value);
if let Some(right) = &self.right {
right.print();
}
}
}
--->END `tree.rs`<---
Note that there's more code here than in your C code, but this
also does a lot more; this is generic over any key and value
types where the key type implements a total ordering, and where
both types implement the `Debug` trait (so they can be printed).
Just to be fancy I added some comments, and note that the
examples in thosee comments are actually unit tests that are run
with `cargo test`.
There is also a pre-order `print` routine. With a trivial
driver program, this prints:
term% cat src/main.rs
use tree::Tree;
pub fn main() {
let mut tree = Tree::<i32, i32>::new();
tree.insert(2, 200);
tree.insert(1, 100);
tree.insert(3, 300);
tree.print();
println!("tree.search(0) = {:?}", tree.search(&0));
println!("tree.search(1) = {:?}", tree.search(&1));
}
term% cargo run
Compiling tree v0.1.0 (/Users/cross/xfer/tree)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s
Running `target/debug/tree`
key = 1, value = 100
key = 2, value = 200
key = 3, value = 300
tree.search(0) = None
tree.search(1) = Some(100)
term%
>I wanted something with the benefits of the Pascal/C/Forth variant,
>not something like the Java variants. I don't know if that counts as
>"manner you were accustomed to thinking about the problem".
I would say that it does. You wanted to do something that is
familiar from Pascal or Modula-2, but that is annoying to
express in Rust. However, that doesn't mean that there is not a
similar way to effect the same thing in Rust.
>And I learned this technique in Pascal or Modula-2 (probably from one
>of Wirth's books), and had no problem transferring the knowledge into
>C or Forth, on the contrary: In C and Forth I could turn search into a
>loop (in Pascal it has to be a tail-recursive function, because you
>can only produce references to variables and fields through reference
>parameters).
>
>For a language that aspires to take over from C for systems
>programming, I expect that one can use this technique, too.
See above. The core of the `search` and `insert` algorithms are
similar to the ones you sketched, though the pointer-to-pointer
to a node is not returned by `search`. If that is what you mean
by "technique" then you're right; doing that in Rust is
inconvenient because it violates the borrow checker's rules
about the existence of multiple simultaneous mutable references
to an object. But I claim that is just a detail, and not a
terribly interesting one at that; certainly not an impediment to
substituting Rust for C in systems programming.
Even so, as I said, one _can_ use the same technique using a
smallish-bit of `unsafe` code. This version is more faithful to
your original:
--->BEGIN `unsafe_tree.rs`<---
//! Simple binary search tree.
use std::cmp::Ordering;
use std::fmt::Debug;
/// A binary search tree over any key type that implements a
/// total ordering.
pub struct Tree<K: Debug + Ord, V: Debug> {
root: *mut Node<K, V>,
}
impl<K: Debug + Ord, V: Debug> Tree<K, V> {
/// Creates a new, empty tree.
pub fn new() -> Tree<K, V> {
Tree {
root: std::ptr::null_mut(),
}
}
fn search(&mut self, key: &K) -> &mut *mut Node<K, V> {
let mut nodep = &mut self.root;
while let Some(node) = unsafe { nodep.as_mut() } {
match key.cmp(&node.key) {
Ordering::Less => nodep = &mut node.left,
Ordering::Equal => break,
Ordering::Greater => nodep = &mut node.right,
}
}
nodep
}
pub fn insert(&mut self, key: K, value: V) {
let inodep = self.search(&key);
if let Some(node) = unsafe { inodep.as_mut() } {
node.value = value;
} else {
let node = Node::new(key, value);
*inodep = std::boxed::Box::leak(node);
}
}
pub fn print(&self) {
unsafe { self.root.as_ref() }.map(|root| root.print());
}
}
impl<K: Debug + Ord, V: Debug> Drop for Tree<K, V> {
fn drop(&mut self) {
let _root = unsafe { std::boxed::Box::from_raw(self.root) };
}
}
// A node in the tree owns its key, value, and left and right
// children.
struct Node<K: Debug + Ord, V: Debug> {
key: K,
value: V,
left: *mut Node<K, V>,
right: *mut Node<K, V>,
}
impl<K: Debug + Ord, V: Debug> Node<K, V> {
/// Creates a new boxed node owning the given key and value.
pub fn new(key: K, value: V) -> Box<Node<K, V>> {
Box::new(Node {
key,
value,
left: std::ptr::null_mut(),
right: std::ptr::null_mut(),
})
}
/// Pre-order print of this node and its children.
pub fn print(&self) {
unsafe { self.left.as_ref() }.map(|left| left.print());
println!("key = {:?}, value = {:?}", self.key, self.value);
unsafe { self.right.as_ref() }.map(|right| right.print());
}
}
impl<K: Debug + Ord, V: Debug> Drop for Node<K, V> {
fn drop(&mut self) {
if !self.left.is_null() {
let _left = unsafe { std::boxed::Box::from_raw(self.left) };
}
if !self.right.is_null() {
let _right = unsafe { std::boxed::Box::from_raw(self.right) };
}
}
}
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn raw_insert_works() {
let mut tree = Tree::new();
tree.insert(1, 100);
tree.insert(3, 300);
tree.insert(2, 200);
drop(tree);
}
}
--->END `unsafe_tree.rs`<---
I stripped comments for brevity, but added explicit `Drop` impls
to avoid leaking memory. The seemingly useless test here allows
me to exercise this under `miri` to check for memory safety
violations manipulating raw pointers with `unsafe`:
term% cargo +nightly miri test
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.00s
Running unittests src/lib.rs (target/miri/aarch64-apple-darwin/debug/build/tree/6797a5ad52527de9/out/tree-6797a5ad52527de9)
running 1 test
test otree::tests::raw_insert_works ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.16s
Running unittests src/main.rs (target/miri/aarch64-apple-darwin/debug/build/tree/6121d361cfb78277/out/tree-6121d361cfb78277)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.03s
Doc-tests tree
running 2 tests
test src/lib.rs - Tree<K,V>::insert (line 51) ... ok
test src/lib.rs - Tree<K,V>::search (line 25) ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.11s
all doctests ran in 0.14s; merged doctests compilation took 0.03s
term%
So, we can see that it is possible to use the same technique you
are familiar with.
The difference is that, with Rust, you usually don't _want_ to
do it this way, since there's a completely safe alternative that
leverages the type system to prohibit memory leaks, dangling
pointers, and so on, by construction.
Frankly, unless I was doing something very odd, I wouldn't write
my own binary search tree at all; the standard library's
collections implementations are pretty good, and then there are
third-party libraries like Hashbrown and Crossbeam that are
best-in-class across the industry.
>>But that is separate from whether it can be done or not.
>
>Sure, and as I found out later, it can be done.
Indeed; see above.
>>In fact, in Rust you can use approximately the same
>>techniques you would use in Pascal, C, or (probably) Forth: raw
>>pointers are a part of the language, and you can simply use them
>>with `unsafe` code, and it would be no more "unsafe" than in C
>>or Pascal. One might argue that that defeats the purpose of the
>>language, and you'd be right to a point. The difference is that
>>in C or Pascal, the entire program is what Rust would call
>>"unsafe", whereas generally this can be restricted to just a few
>>lines of carefully audited code in Rust.
>
>Given that I do not understand the automagic stuff done by the Rust
>compiler enough to get this kind of tree insertion past the borrow
>checker, even though it is possible, I don't trust my capabilities to
>audit unsafe Rust.
Is it significantly different than doing so in C, Pascal, or
Forth? See the second program, above; the use of `unsafe` in
the bits that correspond to your sketch in C is constrained to
two places that indirect raw pointers.
It is true that I think it is more difficult to write _correct_
`unsafe` code in Rust than in, say, C, because the language is
more demanding of the programmer. But in return for that
investment in effort, you get substantally more type and memory
safety.
>>FWIW, for things like containers of various kinds (trees, hash
>>tables, linked-lists, growable arrays, etc), production programs
>>usually use an existing library or crate instead of rolling
>>their own.
>
>When I saw that this technique cannot be implemented in Java, I
>wondered why Java was not having references to fields (answer:
>probably because that would make garbage collection more costly and/or
>less precise), that this technique is needed for relatively few
>things, mostly stuff that's in libraries. And I wondered how these
>library methos are implemented (at one point I guessed that they
>implemented these parts of their libraries in C, but when I actually
>look, the implementation of what I looked at was in Java, IIRC along
>the lines of 1)).
>
>For a language that aspires to replace C for systems programming,
>giving the Java answer is not good enough, though.
Fortunately for Rust, that's not what it does.
>>>At some point I thought that one would have to use the more
>>>heavy-weight reference-counting stuff to get through the borrow
>>>checker.
>>>
>>>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. 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).
>>>
>>>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.
>>
>>Sounds like you're in what we'd call the, "fighting the borrow
>>checker" stage. It may be that you end up really not liking
>>Rust or feeling that other languages are better, but I wager
>>that just about anyone who has seriously used the language has
>>gone through similar things.
>
>I wonder about that.
It's so common that "fighting the borrow checker" is the
community's slogan to describe it. Another common phenomenon
for those who put in the work and come out the other side of
that is that one finds the discipline it imposes on how one
thinks of one's programs makes one a better programmers in
unsafe languages, like C.
>From the books I read, I get the impression that
>Rust used to have less automagic stuff, and much of the automagic was
>added later, as a convenience for the programmers who already knew the
>language. So the Rust programmers of the early days formed a mental
>model based on "Pedestrian Rust" (i.e., with less automagic), and when
>they see a program with more automagic, and need to understand some
>conveniently short piece of Rust code in detail, they form a mental
>model of the code in Pedestrian Rust. But how can a Rust programmer
>who starts now learn Pedestrian Rust and how it relates to the modern
>language. There are hints in the books I read, but not enough to get
>a firm foundation.
Early Rust was very different, and much closer to a managed
language with garbage collection, green threads, a heavy-weight
runtime, etc. Put another way, the trend has been less and less
"automagic" (as you put it) and making things more explicit over
time.
You keep conflating things you are not familiar with in a
language you are not familiar with, with the idea that those
things are "automagic." But really there is no magic here, and
I suspect the answer to your question about how one learns to
adapt their mental model of Rust is to first stop thinking of it
as magical.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-10 14:18 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct10.161800@mips.complang.tuwien.ac.at> |
| In reply to | #118514 |
cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[Crossposted and and Followup-To: comp.programming]
Given that I don't subscribe to c.p, I kept comp.arch in the
Newsgroups.
>In article <2026Oct6.102919@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>My goal was to implement search tree insertion as efficiently and
>>compactly as in Pascal, 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;
>>}
>
>An intersting way to write it; I understand you're trying to
>reuse `search` in `insert`, below, and thus why you want to
>return `rootp`.
>
>>void insert(struct tree **rootp, int key, int val)
>>{
>> struct tree **nodep = **search(rootp, key);
>
>I know you said this was untested; clearly you should not
>indirect the result of `search` here.
>
>> 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.
>>
>>I also knew Java solutions to the problem:
>>
>>1) Special-case the root (which you typically have to do in Java
>>anyway, and otherwise always keep a pointer to the last tree node
>>around, and also keep the knowledge about the last left-or-right
>>decision around (or take it again). This all leads to quite a bit of
>>code that is duplicated relative to the code above.
>>
>>2) Recurse into the tree and rewrite all the links to the subtrees
>>along the spine of the search. This is not quite as duplicative as 1)
>>(but the root still has to be handled separately), but it performs
>>several writes instead of just one, and the recursion is not a tail
>>recursion, so is relatively expensive.
>
>Or, 3) Simply reimplement the comparison in `insert`
That goes along with 1), but I forgot to mention it.
>it's a trivial amount of code.
There's the rub. I don't consider a factor of ~2 trivial, even if it
is only 20 lines of code. And in particular, "simply reimplement"
means that the same thing occurs several times in the code, and in
maintainance one must remember to change all of the occurences.
Fortunately, that's not necessary in Rust. But the fact that you did
not find it tells me that Rust is hard even for experienced Rust
programmers.
>I chose a variant of (1) for my implementation, but only because
>it was easy, not because it was required. No unsafe code or
>fancy reference counting here.
>
>--->BEGIN `tree.rs`<---
>//! Simple binary search tree.
>
>use std::cmp::Ordering;
>use std::fmt::Debug;
>
>/// A binary search tree over any key type that implements a
>/// total ordering.
>pub struct Tree<K: Debug + Ord, V: Debug> {
> root: Option<Box<Node<K, V>>>,
>}
>
>impl<K: Debug + Ord, V: Debug> Tree<K, V> {
> /// Creates a new, empty tree.
> pub fn new() -> Tree<K, V> {
> Tree { root: None }
> }
>
> /// Searches the tree for the given key, and returns
> /// `Some(&value)` if it's here, otherwise returns None.
> ///
> /// # Example
> ///
> /// ```
> /// let mut tree = tree::Tree::<i32, i32>::new();
> /// tree.insert(2, 200);
> /// tree.insert(1, 100);
> /// assert_eq!(tree.search(&0), None);
> /// assert_eq!(tree.search(&1), Some(&100));
> /// assert_eq!(tree.search(&2), Some(&200));
> /// ```
> pub fn search(&self, key: &K) -> Option<&V> {
> let mut root = &self.root;
> while let Some(node) = root {
> match key.cmp(&node.key) {
> Ordering::Less => root = &node.left,
> Ordering::Equal => return Some(&node.value),
> Ordering::Greater => root = &node.right,
> }
> }
> None
> }
>
> /// Inserts the given `value` into the tree with the given
> /// `key`. Returns true if the node was inserted, or false
> /// if the key was already in the tree.
> ///
> /// # Example
> ///
> /// ```
> /// let mut tree = tree::Tree::<i32, i32>::new();
> /// assert_eq!(tree.insert(1, 100), true);
> /// assert_eq!(tree.insert(1, 200), false);
> /// assert_eq!(tree.insert(2, 100), true);
> /// ```
> pub fn insert(&mut self, key: K, value: V) -> bool {
> let mut root = &mut self.root;
> loop {
> let Some(node) = root else {
> root.replace(Node::new(key, value));
> return true;
> };
> match key.cmp(&node.key) {
> Ordering::Less => root = &mut node.left,
> Ordering::Equal => return false,
> Ordering::Greater => root = &mut node.right,
> }
> }
> }
>
> /// Print the tree, if it is not empty.
> pub fn print(&self) {
> if let Some(node) = &self.root {
> node.print();
> }
> }
>}
>
>// A node in the tree owns its key, value, and left and right
>// children.
>struct Node<K: Debug + Ord, V: Debug> {
> key: K,
> value: V,
> left: Option<Box<Node<K, V>>>,
> right: Option<Box<Node<K, V>>>,
>}
>
>impl<K: Debug + Ord, V: Debug> Node<K, V> {
> /// Creates a new boxed node owning the given key and value.
> pub fn new(key: K, value: V) -> Box<Node<K, V>> {
> Box::new(Node {
> key,
> value,
> left: None,
> right: None,
> })
> }
>
> /// Pre-order print of this node and its children.
> pub fn print(&self) {
> if let Some(left) = &self.left {
> left.print();
> }
> println!("key = {:?}, value = {:?}", self.key, self.value);
> if let Some(right) = &self.right {
> right.print();
> }
> }
>}
>--->END `tree.rs`<---
>
>Note that there's more code here than in your C code, but this
>also does a lot more; this is generic over any key and value
>types where the key type implements a total ordering, and where
>both types implement the `Debug` trait (so they can be printed).
If I don't need any of that, does it get smaller? I don't think so.
Here's my attempt, and I expect that experienced Rust programmers will
find ways to improve on it. It includes a lookup function:
-------------------
use std::cmp::Ordering;
pub struct Tree<K: Ord, V> {
root: Subtree<K, V>,
}
type Subtree<K,V> = Option<Box<Node<K,V>>>;
struct Node<K: Ord, V> {
key: K,
val: V,
left: Subtree<K, V>,
right: Subtree<K, V>,
}
impl<K: Ord,V> Tree<K,V> {
pub fn new() -> Self {
Tree { root: None }
}
pub fn insert(&mut self, key: K, val: V) {
let mut t = &mut self.root;
while let Some(node)=t {
match key.cmp(&node.key) {
Ordering::Equal => {node.val = val; return;},
Ordering::Less => t = &mut node.left,
Ordering::Greater => t = &mut node.right,
};
};
*t = Some(Box::new(Node {key, val, left: None, right: None}))
}
pub fn lookup(&self, key: K) -> Option<&V> {
let mut t = &self.root;
while let Some(node)=t {
match key.cmp(&node.key) {
Ordering::Equal => return Some(&node.val),
Ordering::Less => t = &node.left,
Ordering::Greater => t = &node.right,
};
};
None
}
}
fn main() {
let mut q1 = Tree::new();
q1.insert(2,"abc".to_string());
q1.insert(3,"def".to_string());
q1.insert(1,"ghi".to_string());
q1.insert(3,"jkl".to_string());
println!("{:?}",q1.lookup(1));
println!("{:?}",q1.lookup(2));
println!("{:?}",q1.lookup(3));
}
----------------------------
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?
insert now integrates search, because I could not satisfy the compiler
with a separate search; maybe a more experience Rust programmer can
separate it out again. The advantage is that there is no need to
combine the found and notfound cases in one return value in search,
only to handle them as separate cases in insert. But at least there
is no duplication of the comparison code.
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.
Of course, if search is factored out, both clients have to explicitly
check for both outcomes and have code for both. But that's probably
preferable to duplicating the search.
>though the pointer-to-pointer
>to a node is not returned by `search`. If that is what you mean
>by "technique" then you're right; doing that in Rust is
>inconvenient because it violates the borrow checker's rules
>about the existence of multiple simultaneous mutable references
>to an object.
Yes, that's what I meant by "technique". And it's possible in safe
Rust, but I had a very hard time finding it (and for a while thought
that it is not possible). The fact that you thought it is not
possible in safe Rust means that it is not just my inexperience at
fault here.
>But I claim that is just a detail, and not a
>terribly interesting one at that; certainly not an impediment to
>substituting Rust for C in systems programming.
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. 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,
>Even so, as I said, one _can_ use the same technique using a
>smallish-bit of `unsafe` code.
That's cool, but given that I have difficulty understanding why the
compiler complained about my version with separate search, I feel very
uncomfortable in asserting to the compiler that my use of unsafe
features is safe once we leave the unsafe block.
>Frankly, unless I was doing something very odd, I wouldn't write
>my own binary search tree at all; the standard library's
>collections implementations are pretty good
And I actually don't use binary search trees anyway, neither
self-written nor from libraries, because hash tables tend to be the
better alternative, except when I want to know the next-higher element
or somesuch. But being able to have a reference to a field is also
useful when implementing hash tables.
But anyway, the libraries have to be written in some language, and
given that Rust fans tell us to rewrite all C code in Rust, I would
expect that the library should be written in Rust, and, in particular
in safe Rust (otherwise, why rewrite it in Rust?).
And actually, we teach our students how to write this stuff (even in
Java), because we think it teaches them something useful. And at
least one Rust fan thinks so, too, and wrote "Learn Rust With Entirely
Too Many Linked Lists", where I found out how to implement the
mentioned technique in safe Rust.
>>Given that I do not understand the automagic stuff done by the Rust
>>compiler enough to get this kind of tree insertion past the borrow
>>checker, even though it is possible, I don't trust my capabilities to
>>audit unsafe Rust.
>
>Is it significantly different than doing so in C, Pascal, or
>Forth? See the second program, above; the use of `unsafe` in
>the bits that correspond to your sketch in C is constrained to
>two places that indirect raw pointers.
I may be able to shut up the compiler and get an executable with
"unsafe", but will the resulting program work? And I can have the
same assurance in C or Forth, so why should I switch to Rust to get
that?
>It's so common that "fighting the borrow checker" is the
>community's slogan to describe it.
Sounds to me like "the community" has found a convenient cliche to
avoid thinking about why people have difficulties with Rust, and why
these difficulties may increase as Rust advances.
>>From the books I read, I get the impression that
>>Rust used to have less automagic stuff, and much of the automagic was
>>added later, as a convenience for the programmers who already knew the
>>language. So the Rust programmers of the early days formed a mental
>>model based on "Pedestrian Rust" (i.e., with less automagic), and when
>>they see a program with more automagic, and need to understand some
>>conveniently short piece of Rust code in detail, they form a mental
>>model of the code in Pedestrian Rust. But how can a Rust programmer
>>who starts now learn Pedestrian Rust and how it relates to the modern
>>language. There are hints in the books I read, but not enough to get
>>a firm foundation.
>
>Early Rust was very different, and much closer to a managed
>language with garbage collection, green threads, a heavy-weight
>runtime, etc. Put another way, the trend has been less and less
>"automagic" (as you put it) and making things more explicit over
>time.
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).
>You keep conflating things you are not familiar with in a
>language you are not familiar with, with the idea that those
>things are "automagic." But really there is no magic here, and
>I suspect the answer to your question about how one learns to
>adapt their mental model of Rust is to first stop thinking of it
>as magical.
The language hides a number of things with automation, and given that
I have no good mental model for that, following Clarke's third law
("Any sufficiently advanced technology is indistinguishable from
magic."), I refer to that automatic stuff as "automagic stuff". I
don't think it's magic, it just tries to be indistinguishable. It
shouldn't.
- 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 | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-10 17:31 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <11adson$sir$1@reader2.panix.com> |
| In reply to | #118533 |
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:
>>[Crossposted and and Followup-To: comp.programming]
>
>Given that I don't subscribe to c.p, I kept comp.arch in the
>Newsgroups.
Ok. If it doesn't bother the regulars, then I guess that's
fine. It seems off-topic, but sure.
>>In article <2026Oct6.102919@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>My goal was to implement search tree insertion as efficiently and
>>>compactly as in Pascal, 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;
>>>}
>>
>>An intersting way to write it; I understand you're trying to
>>reuse `search` in `insert`, below, and thus why you want to
>>return `rootp`.
>>
>>>void insert(struct tree **rootp, int key, int val)
>>>{
>>> struct tree **nodep = **search(rootp, key);
>>
>>I know you said this was untested; clearly you should not
>>indirect the result of `search` here.
>>
>>> 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.
>>>
>>>I also knew Java solutions to the problem:
>>>
>>>1) Special-case the root (which you typically have to do in Java
>>>anyway, and otherwise always keep a pointer to the last tree node
>>>around, and also keep the knowledge about the last left-or-right
>>>decision around (or take it again). This all leads to quite a bit of
>>>code that is duplicated relative to the code above.
>>>
>>>2) Recurse into the tree and rewrite all the links to the subtrees
>>>along the spine of the search. This is not quite as duplicative as 1)
>>>(but the root still has to be handled separately), but it performs
>>>several writes instead of just one, and the recursion is not a tail
>>>recursion, so is relatively expensive.
>>
>>Or, 3) Simply reimplement the comparison in `insert`
>
>That goes along with 1), but I forgot to mention it.
It is an important distinction.
>>it's a trivial amount of code.
>
>There's the rub. I don't consider a factor of ~2 trivial, even if it
>is only 20 lines of code.
Repeating the conditional is 5 lines, including the closing
brace on a ine by itself. The `while` surrounding it is another
2, again including the closing brace.
>And in particular, "simply reimplement"
>means that the same thing occurs several times in the code, and in
>maintainance one must remember to change all of the occurences.
It's a loop around a match over a conditional expression:
while let Some(node) = root {
root = match key.cmp(&node.key) {
Ordering::Less => &mut node.left,
Ordering::Equal => return false,
Ordering::Greater => &mut node.right,
};
}
And in fact it _has_ to be different in a way, because the
reference must be mutable, whereas for searching as a lookup,
that is not necessary.
You could wrap that in a macro if you really wanted to.
>Fortunately, that's not necessary in Rust. But the fact that you did
>not find it tells me that Rust is hard even for experienced Rust
>programmers.
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 chose a variant of (1) for my implementation, but only because
>>it was easy, not because it was required. No unsafe code or
>>fancy reference counting here.
>>
>>--->BEGIN `tree.rs`<---
>>//! Simple binary search tree.
>>
>>use std::cmp::Ordering;
>>use std::fmt::Debug;
>>
>>/// A binary search tree over any key type that implements a
>>/// total ordering.
>>pub struct Tree<K: Debug + Ord, V: Debug> {
>> root: Option<Box<Node<K, V>>>,
>>}
>>
>>impl<K: Debug + Ord, V: Debug> Tree<K, V> {
>> /// Creates a new, empty tree.
>> pub fn new() -> Tree<K, V> {
>> Tree { root: None }
>> }
>>
>> /// Searches the tree for the given key, and returns
>> /// `Some(&value)` if it's here, otherwise returns None.
>> ///
>> /// # Example
>> ///
>> /// ```
>> /// let mut tree = tree::Tree::<i32, i32>::new();
>> /// tree.insert(2, 200);
>> /// tree.insert(1, 100);
>> /// assert_eq!(tree.search(&0), None);
>> /// assert_eq!(tree.search(&1), Some(&100));
>> /// assert_eq!(tree.search(&2), Some(&200));
>> /// ```
>> pub fn search(&self, key: &K) -> Option<&V> {
>> let mut root = &self.root;
>> while let Some(node) = root {
>> match key.cmp(&node.key) {
>> Ordering::Less => root = &node.left,
>> Ordering::Equal => return Some(&node.value),
>> Ordering::Greater => root = &node.right,
>> }
>> }
>> None
>> }
>>
>> /// Inserts the given `value` into the tree with the given
>> /// `key`. Returns true if the node was inserted, or false
>> /// if the key was already in the tree.
>> ///
>> /// # Example
>> ///
>> /// ```
>> /// let mut tree = tree::Tree::<i32, i32>::new();
>> /// assert_eq!(tree.insert(1, 100), true);
>> /// assert_eq!(tree.insert(1, 200), false);
>> /// assert_eq!(tree.insert(2, 100), true);
>> /// ```
>> pub fn insert(&mut self, key: K, value: V) -> bool {
>> let mut root = &mut self.root;
>> loop {
>> let Some(node) = root else {
>> root.replace(Node::new(key, value));
>> return true;
>> };
>> match key.cmp(&node.key) {
>> Ordering::Less => root = &mut node.left,
>> Ordering::Equal => return false,
>> Ordering::Greater => root = &mut node.right,
>> }
>> }
>> }
>>
>> /// Print the tree, if it is not empty.
>> pub fn print(&self) {
>> if let Some(node) = &self.root {
>> node.print();
>> }
>> }
>>}
>>
>>// A node in the tree owns its key, value, and left and right
>>// children.
>>struct Node<K: Debug + Ord, V: Debug> {
>> key: K,
>> value: V,
>> left: Option<Box<Node<K, V>>>,
>> right: Option<Box<Node<K, V>>>,
>>}
>>
>>impl<K: Debug + Ord, V: Debug> Node<K, V> {
>> /// Creates a new boxed node owning the given key and value.
>> pub fn new(key: K, value: V) -> Box<Node<K, V>> {
>> Box::new(Node {
>> key,
>> value,
>> left: None,
>> right: None,
>> })
>> }
>>
>> /// Pre-order print of this node and its children.
>> pub fn print(&self) {
>> if let Some(left) = &self.left {
>> left.print();
>> }
>> println!("key = {:?}, value = {:?}", self.key, self.value);
>> if let Some(right) = &self.right {
>> right.print();
>> }
>> }
>>}
>>--->END `tree.rs`<---
>>
>>Note that there's more code here than in your C code, but this
>>also does a lot more; this is generic over any key and value
>>types where the key type implements a total ordering, and where
>>both types implement the `Debug` trait (so they can be printed).
>
>If I don't need any of that, does it get smaller? I don't think so.
>
>Here's my attempt, and I expect that experienced Rust programmers will
>find ways to improve on it. It includes a lookup function:
>
>-------------------
>use std::cmp::Ordering;
>
>pub struct Tree<K: Ord, V> {
> root: Subtree<K, V>,
>}
>
>type Subtree<K,V> = Option<Box<Node<K,V>>>;
>
>struct Node<K: Ord, V> {
> key: K,
> val: V,
> left: Subtree<K, V>,
> right: Subtree<K, V>,
>}
>
>impl<K: Ord,V> Tree<K,V> {
> pub fn new() -> Self {
> Tree { root: None }
> }
>
> pub fn insert(&mut self, key: K, val: V) {
> let mut t = &mut self.root;
> while let Some(node)=t {
> match key.cmp(&node.key) {
> Ordering::Equal => {node.val = val; return;},
> Ordering::Less => t = &mut node.left,
> Ordering::Greater => t = &mut node.right,
> };
> };
> *t = Some(Box::new(Node {key, val, left: None, right: None}))
> }
>
> pub fn lookup(&self, key: K) -> Option<&V> {
> let mut t = &self.root;
> while let Some(node)=t {
> match key.cmp(&node.key) {
> Ordering::Equal => return Some(&node.val),
> Ordering::Less => t = &node.left,
> Ordering::Greater => t = &node.right,
> };
> };
> None
> }
>}
This is essentially the same program I just presented to you;
you added a type alias, changed `insert` to set the value, and
used `*t` instead of `.replace` for inserting a new node, used
ersatz formatting (ie, not `rustfmt`), and omitted the comments.
I find it strange that you claim this as different from what I
presented to you, except in trivial details, while also telling
me that I "did not find" something.
Are you sure you actually ready my post, and the programs in it?
>fn main() {
> let mut q1 = Tree::new();
> q1.insert(2,"abc".to_string());
> q1.insert(3,"def".to_string());
> q1.insert(1,"ghi".to_string());
> q1.insert(3,"jkl".to_string());
> println!("{:?}",q1.lookup(1));
> println!("{:?}",q1.lookup(2));
> println!("{:?}",q1.lookup(3));
>}
>----------------------------
>
>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.
>insert now integrates search, because I could not satisfy the compiler
>with a separate search; maybe a more experience Rust programmer can
>separate it out again. The advantage is that there is no need to
>combine the found and notfound cases in one return value in search,
>only to handle them as separate cases in insert. But at least there
>is no duplication of the comparison code.
I fail to see how your program is very different from mine,
aside from using the type alias for `Subtree`. The comparison
is clearly duplicated in your code. Perhaps you are commenting
on a hypothetical where that does not happen, as in my second
example?
>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.
By analogy, in your C, how would it affect things if you wanted
to `const` qualify the tree pointer for lookups?
>Of course, if search is factored out, both clients have to explicitly
>check for both outcomes and have code for both. But that's probably
>preferable to duplicating the search.
See my second program in the post you responded to.
>>though the pointer-to-pointer
>>to a node is not returned by `search`. If that is what you mean
>>by "technique" then you're right; doing that in Rust is
>>inconvenient because it violates the borrow checker's rules
>>about the existence of multiple simultaneous mutable references
>>to an object.
>
>Yes, that's what I meant by "technique". And it's possible in safe
>Rust, but I had a very hard time finding it (and for a while thought
>that it is not possible). The fact that you thought it is not
>possible in safe Rust means that it is not just my inexperience at
>fault here.
I did not say that it was "not possible"; indeed, I can think of
any number of ways to do it, using interior mutability, arcs,
etc. I said it was inconvenient, and I would argue not very
interesting.
You seem to be claiming you have a solution to this, but have
yet to present that code; your program above was basically a
copy of my program, and your commentary suggests you couldn't
figure out a different way to write it yourself.
>>But I claim that is just a detail, and not a
>>terribly interesting one at that; certainly not an impediment to
>>substituting Rust for C in systems programming.
>
>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, and then defined your criteria so that it
excludes the most obvious translation.
>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; that is exactly
the same as every line in a C program.
>>Even so, as I said, one _can_ use the same technique using a
>>smallish-bit of `unsafe` code.
>
>That's cool, but given that I have difficulty understanding why the
>compiler complained about my version with separate search, I feel very
>uncomfortable in asserting to the compiler that my use of unsafe
>features is safe once we leave the unsafe block.
I'm afraid that sounds like a problem for you to deal with, not
a problem with Rust.
>>Frankly, unless I was doing something very odd, I wouldn't write
>>my own binary search tree at all; the standard library's
>>collections implementations are pretty good
>
>And I actually don't use binary search trees anyway, neither
>self-written nor from libraries, because hash tables tend to be the
>better alternative, except when I want to know the next-higher element
>or somesuch. But being able to have a reference to a field is also
>useful when implementing hash tables.
>
>But anyway, the libraries have to be written in some language, and
>given that Rust fans tell us to rewrite all C code in Rust, I would
>expect that the library should be written in Rust, and, in particular
>in safe Rust (otherwise, why rewrite it in Rust?).
I'm not sure how useful it is to try to explain this, since your
thoughts on the matter appear to have already calcified.
But the reason is that locality of reasoning is a powerful tool
when building reuseable components. Does the Rust standard
library use `unsafe` code? Yes, it does. However, it wraps
that in a safe facade, and competent Rust programmers seek to
minimize it. The `unsafe` code is then heavily audited; this
does not guarantee bug freedom, but no one serious ever claimed
that it did. However, it _does_ make debugging dramatically
easier: if a program dumps core at some point down the road,
it's likely that the crash originated in `unsafe` code in a
library, and that becomes the focus for looking for the bug.
>And actually, we teach our students how to write this stuff (even in
>Java), because we think it teaches them something useful. And at
>least one Rust fan thinks so, too, and wrote "Learn Rust With Entirely
>Too Many Linked Lists", where I found out how to implement the
>mentioned technique in safe Rust.
Yes. Gankra was also the driving force behind the strict
pointer provenance work. You may enjoy her writing on, "the
tower of weakenings."
>>>Given that I do not understand the automagic stuff done by the Rust
>>>compiler enough to get this kind of tree insertion past the borrow
>>>checker, even though it is possible, I don't trust my capabilities to
>>>audit unsafe Rust.
>>
>>Is it significantly different than doing so in C, Pascal, or
>>Forth? See the second program, above; the use of `unsafe` in
>>the bits that correspond to your sketch in C is constrained to
>>two places that indirect raw pointers.
>
>I may be able to shut up the compiler and get an executable with
>"unsafe", but will the resulting program work? And I can have the
>same assurance in C or Forth, so why should I switch to Rust to get
>that?
Because with C and Forth you can't just wrap the unsafe bits
behind a safe interface that consumers can rely on, placing the
burden on all users to ensure safety, whereas in Rust, you can.
Consider the arguments in in your Tree example; the tree itself
is a pointer to a pointer to the root. What if that pointer is
garbage? What if it's dangling? In Rust, `&self` is guaranteed
to be a valid, non-nil reference to a live object, and moreover
you are guaranteed that no other thread is trying to mutate that
object while you're holding that ref. Neither C nor Forth can
give you any such guarantee. Similarly, `&mut self` guarantees
that no other reference to the object exists. Visibility
similarly gives you control; by wrapping, say, a raw pointer
inside of an `struct` as a non-public member, you can guarantee
that the same pointer is the one used in multiple, subsequent
function calls: as written, your C code has two functions that
share no relationship save that one calls the other. I could
cal `insert`, and then go and muck with the tree myself, so that
its ordering constraints are violated, and then call `insert`
again and have a tree that didn't respect the BST properties. I
could pass a random garbage `root` pointer and cause the program
to crash. And so on.
Do I really need to go on, here?
>>It's so common that "fighting the borrow checker" is the
>>community's slogan to describe it.
>
>Sounds to me like "the community" has found a convenient cliche to
>avoid thinking about why people have difficulties with Rust, and why
>these difficulties may increase as Rust advances.
Bluntly, I think you are not really in a position to make that
claim, and are inventing excuses to justify your preconceptions
and biases.
>>>From the books I read, I get the impression that
>>>Rust used to have less automagic stuff, and much of the automagic was
>>>added later, as a convenience for the programmers who already knew the
>>>language. So the Rust programmers of the early days formed a mental
>>>model based on "Pedestrian Rust" (i.e., with less automagic), and when
>>>they see a program with more automagic, and need to understand some
>>>conveniently short piece of Rust code in detail, they form a mental
>>>model of the code in Pedestrian Rust. But how can a Rust programmer
>>>who starts now learn Pedestrian Rust and how it relates to the modern
>>>language. There are hints in the books I read, but not enough to get
>>>a firm foundation.
>>
>>Early Rust was very different, and much closer to a managed
>>language with garbage collection, green threads, a heavy-weight
>>runtime, etc. Put another way, the trend has been less and less
>>"automagic" (as you put it) and making things more explicit over
>>time.
>
>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.
>>You keep conflating things you are not familiar with in a
>>language you are not familiar with, with the idea that those
>>things are "automagic." But really there is no magic here, and
>>I suspect the answer to your question about how one learns to
>>adapt their mental model of Rust is to first stop thinking of it
>>as magical.
>
>The language hides a number of things with automation, and given that
No, it really doesn't.
>I have no good mental model for that, following Clarke's third law
>("Any sufficiently advanced technology is indistinguishable from
>magic."), I refer to that automatic stuff as "automagic stuff". I
>don't think it's magic, it just tries to be indistinguishable. It
>shouldn't.
Sorry, but I see no evidence that you have taken the time to
actually understand that the things you attribute to automation
are actually rather explicit; you're a smart guy, and I'm quite
sure you could do it if you wanted; it's really all rather
obvious once you dig into it a little bit. Given that, and that
you continue to assert that it's "automagic" I can tell that you
simply don't want to, perhaps because it is different from what
you are used to.
Hint: when an object goes out of scope, it is "dropped." A type
can register a "drop handler" by implementing the `Drop` trait.
For a smart pointer like `Box`, that simply frees the thing it
points to. Same with a Mutex: the `lock()` operation returns a
`MutexGuard` object that holds the lock. When it goes out of
scope, its `drop()` method unlocks the mutex. Cf,
https://cliffle.com/blog/rust-mutexes/
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-10-11 15:40 +0000 |
| Subject | Re: Rust (was: Optimization by programmers) |
| Message-ID | <2026Oct11.174012@mips.complang.tuwien.ac.at> |
| In reply to | #118534 |
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. 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. 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? >>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. >>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? 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. >>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. >>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. >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. >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. >>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? - 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 | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-10-11 14:26 -0400 |
| Subject | Re: Rust |
| Message-ID | <jwvcxtg9jxl.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118539 |
> 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? IIUC it can but at the cost of making `search` take a `&mut` reference. I get the impression that you'd otherwise need "mutability polymorphism", i.e. a single piece of code that can be instantiated either for `&` or for `&mut`. You can probably avoid writing the code twice, tho, by abusing macros (aka "template polymorphism"). === Stefan
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 19:14 +0000 |
| Subject | Re: Rust |
| Message-ID | <11ajbi6$j2c$1@reader2.panix.com> |
| In reply to | #118552 |
In article <jwvcxtg9jxl.fsf-monnier+comp.arch@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> 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? > >IIUC it can but at the cost of making `search` take a `&mut` reference. >I get the impression that you'd otherwise need "mutability >polymorphism", i.e. a single piece of code that can be instantiated >either for `&` or for `&mut`. You can probably avoid writing the code >twice, tho, by abusing macros (aka "template polymorphism"). ...or using interior mutability with e.g., a `Cell`. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-10-12 21:15 +0000 |
| Subject | Re: Rust |
| Message-ID | <11ajild$3vq17$5@dont-email.me> |
| In reply to | #118552 |
On Sun, 11 Oct 2026 14:26:48 -0400, Stefan Monnier wrote: > You can probably avoid writing the code twice, tho, by abusing > macros (aka "template polymorphism"). Why would that be “abusing”? Aren’t macros designed for just such a purpose?
[toc] | [prev] | [next] | [standalone]
Page 18 of 24 — ← Prev page 1 … 16 17 [18] 19 20 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web