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 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-12 22:37 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1791844654-5857@newsgrouper.org> |
| In reply to | #118573 |
cross@spitfire.i.gajendra.net (Dan Cross) posted:
> In article <1791830400-5857@newsgrouper.org>,
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >quadibloc@invalid.com (John Savard) posted:
> >> On Mon, 12 Oct 2026 11:25:32 -0000 (UTC), Thomas Koenig
> >> <tkoenig@netcologne.de> wrote:
> >> >David Brown <david.brown@hesbynett.no> schrieb:
> >> >> But if you receive a "pointer to const" parameter to a function, you can
> >> >> still write via a cast version of the pointer if the original object was
> >> >> not defined as "const". (So objects defined as "const" may be placed in
> >> >> read-only memory of some kind, and trying to change them might cause a
> >> >> crash, signal, bus-error, etc.)
> >> >
> >> >In FORTRAN, it used to be possible on systems such as /360 to write
> >> >
> >> > CALL FOO(21)
> >> > WRITE (*,*) 21
> >> > END
> >> >
> >> > SUBROUTINE FOO(N)
> >> > N = 42
> >> > END
> >> >
> >> >and get a printout of 42 (21 is only half the truth,
> >> >remember!) because the compiler put the constants in read/write
> >> >storage and arguments were passed via address.
> >>
> >> And the proper way to correct this error is obvious. Not by putting
> >> constants in a segment marked read-only. But in properly implementing
> >> language semantics.
> >>
> >> So the values of constants are stored in memory.
> >>
> >> However, when a constant is passed to a function as an argument,
> >> clearly that constant should be treated as an *expression*, not as a
> >> variable. So you copy it to a temporary, and pass the address of the
> >> temporary to the function.
> >
> >And you think the language designers in 1956 could have figured that out ???
>
> I don't think that's the right framing.
>
> >> Not doing that was the bug.
> >
> >Some would disagree.
>
> That it's a bug? Clearly, changing the value of some constant
> is surprising, at best.
Allows one to have 1 {sin(), cos() ...} subroutine and change the value of pi
so one then has {sinpi(), cospi(), ...}
>
> - Dan C.
>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-10-13 00:35 +0000 |
| Subject | Re: smashing constants, sort of like Optimization by programmers |
| Message-ID | <11ajubp$s9b$1@gal.iecc.com> |
| In reply to | #118573 |
According to Dan Cross <cross@spitfire.i.gajendra.net>: >>> However, when a constant is passed to a function as an argument, >>> clearly that constant should be treated as an *expression*, not as a >>> variable. So you copy it to a temporary, and pass the address of the >>> temporary to the function. >> >>And you think the language designers in 1956 could have figured that out ??? > >I don't think that's the right framing. > >>> Not doing that was the bug. >> >>Some would disagree. > >That it's a bug? Clearly, changing the value of some constant >is surprising, at best. I wasn't writing programs in 1958, having had a prior committment in nursery school, but I was writing programs in the late 1960s. I think you would find the attitude was yes, you could do that, but it would be stupid, so don't. Remember that FORTRAN ran on a 70x with 32K words of memory, S/360 subset FORTRAN E ran on a 360/30 with 32K bytes and full FORTRAN G ran on a 360/40 with 128K bytes. Every word was precious, and wasting three or four words creating a temporary to defend against an obvious programmer error would have been silly. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-13 18:40 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11altui$q4p6$1@dont-email.me> |
| In reply to | #118561 |
John Savard <quadibloc@invalid.com> schrieb: > On Mon, 12 Oct 2026 11:25:32 -0000 (UTC), Thomas Koenig ><tkoenig@netcologne.de> wrote: > >>David Brown <david.brown@hesbynett.no> schrieb: >> >>> But if you receive a "pointer to const" parameter to a function, you can >>> still write via a cast version of the pointer if the original object was >>> not defined as "const". (So objects defined as "const" may be placed in >>> read-only memory of some kind, and trying to change them might cause a >>> crash, signal, bus-error, etc.) >> >>In FORTRAN, it used to be possible on systems such as /360 to write >> >> CALL FOO(21) >> WRITE (*,*) 21 >> END >> >> SUBROUTINE FOO(N) >> N = 42 >> END >> >>and get a printout of 42 (21 is only half the truth, >>remember!) because the compiler put the constants in read/write >>storage and arguments were passed via address. > > And the proper way to correct this error is obvious. Not by putting > constants in a segment marked read-only. But in properly implementing > language semantics. First, those semantics have to be defined... but I thought you were a great fan of all things /360, so I assumed you would like this :-) > So the values of constants are stored in memory. > > However, when a constant is passed to a function as an argument, > clearly that constant should be treated as an *expression*, not as a > variable. So you copy it to a temporary, and pass the address of the > temporary to the function. Not doing that was the bug. That would penalize correct code, which is a no-no. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 15:47 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aivfc$87l$1@reader2.panix.com> |
| In reply to | #118551 |
In article <11ahs8q$38ir0$4@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >[snip] >I think (and you will hopefully correct me if I am wrong!) in Rust if a >function receives a non-mutable reference as a parameter, it is not >allowed to cast it to a mutable reference. That is correct. There is no way to do that in safe Rust, and shenanigans that do it using unsafe are UB (UB in safe Rust is a compile-time error). As I mentioned in my other response, going the other direction is ok: it is possible to coerce a mutable reference to an immutable reference, so that you can e.g. invoke a method that takes `&self` on an object to which you have an `&mut` borrow. >> You can discuss if its a good idea to make non-mutability the default >> instead of the opposite. Personally I like that part. > >It certainly sounds good to me. It is! Being explicit about when things are mutable is very helpful. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 15:41 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aiv39$bpk$1@reader2.panix.com> |
| In reply to | #118540 |
In article <1791742457-5857@newsgrouper.org>,
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>
>Terje Mathisen <terje.mathisen@tmsw.no> posted:
>
>> Dan Cross wrote:
>---------
>>
>> My old asm/C brain _knows_ that a slice of something with a known
>> address and total length is effectively the same thing as an unmutable
>> array.
>
>Can I get a definition of what mutable in Rust means ??
First, it is important to note that this is a logical concept,
and has no bearing on the physical properties of the computer
that the program is running on.
>Intuition would imply the inverse of opposite of const from C.
Here's a detailed explanation.
By default, variables in Rust are immutable; that is, their
value may not change. For example, one cannot assign to them,
and to try and do so is a compile-time error:
? let foo = something();
? foo = something_else(); // Error: `foo` is immutable.
"Mutable", then, means the opposite: the value _can_ change.
Mutability is intorduced via the `mut` keyword:
let mut foo = something();
foo = something_else(); // Ok: `foo` is mutable.
In Rust, this extends to references, which have specific
properties: references are non-nullable, and can only refer to
valid, initialized objects; references are also prohibited from
outliving the object they refer to, and furthermore, they carry
a notion of mutability themselves: a mutable reference can be
used to change its referrent; immutable references cannot.
Immutable references are created using the `&` operator; mutable
references use the `&mut` operator.
Importantly, while immutable references can be created to
mutable objects, the inverse is not true: mutable references
cannot be created to immutable objects. So, for example this
does not compile:
? let foo = something();
? let foomut = &mut foo; // `foo` is immutable
But this is ok:
let mut foo = something();
let foomut = &mut foo;
As is this:
let mut foo = something();
let fooref = &foo; // Immutuable reference
let barref = &foo; // Ok; immutable reference
Having multiple immutable references to an object is fine, but
the language requires that _mutable_ references to an object
are mutually exclusive with any other reference to that object.
In Rust, we say that we "borrow" a reference to an object, and
the compiler has a thing called, "the borrow checker" that
checks that all of these properties hold.
So this will fail to compile:
? let mut foo = something();
? let foomut = &mut foo; // Ok: only mutable
? let barmut = &mut foo // Fail: a mut ref to foo exists
As will this:
? let mut foo = something();
? let foomut = &mut foo; // Ok; only reference.
? let fooref = &foo; // Fail: a mut ref to foo exists
And as will this:
? let mut foo = something();
? let fooref = &foo; // Ok: immutable reference.
? let barref = &foo; // Ok: multiple immut. refs ok
? let foomut = &mut foo; // Fail: exiting ref already
References also have a property called a "lifetime" that is tied
to the object they are borrowed from; the rule is that a
reference is not allowed to outlive its referrent. So this,
again, is a compile time error:
? let foo = {
? let bar = something();
? &bar // Error; bar going out of scope
? };
Here, I created a new scope (indicated by the curly braces) and
bound some object to the name `bar` in that scope, and attempted
to preserve a reference to that object outside of that scope.
However, that object only exists in that scope, so when the
scope ends, so too does the lifetime of the object; trying to
use a reference to it beyond that point violates the life time
rules enforced by the borrow checker.
But this serves to introduce another aspect of this, which is
that scopes and lifetimes matter with respect to how the
compiler treats these rules.
Take the following:
struct Obj(u32); // Tuple struct containing a u32
impl Obj {
fn print(&self) {
println!("Value in obj is: {}", self.0);
}
}
Here, I have defined a trivial struct (a "tuple struct"
specifically) that contains a simple datum; an unsigned 32-bit
integer. And I have written an "implementation" of that type
that provides a "print" method that takes `&self`; that is,
takes an immutable reference to an instance of that object and
prints the integer.
Now, consider this code:
let mut foo = Obj(42);
foo.print();
let foomut = &mut foo;
foomut.print();
What should happen here? The first three lines are fine; I
create the object, and I invoke its `.print()` method, which
takes an immutable reference to `foo`, and then I borrow a
*mutable* reference to foo, which is fine (the immutable
reference that `.print()` borrowed is gone at that point).
But in the 4th line I try to invoke `.print()` through through
the mutable borrow. However, as we have seen, `.print()` takes
an immutable reference, and I'm clearly holding a *mutable*
reference, which appears to violate the borrowing rules.
However, this code compiles just fine: what happened?
As it turns out, the compiler allows a mutable reference to be
_coerced_ into an immutable reference, which is what is
happening here. The compiler is allows this since it can infer
that nothing else can take an mut reference to the original
object while the mut ref exists, and since the mut ref is in
use, nothing can indirect through it and modify the underlying
object. So things like this are fine:
0 fn scopes() {
1 let mut foo = Obj(42);
2 foo.print();
3 let foomut = &mut foo;
4 foomut.print();
5 foo = Obj(32);
6 foo.print();
7 let barmut = &mut foo;
8 barmut.print();
9 barmut.0 = 22;
10 foo.print();
11 }
This also illustrates a couple of other aspects of the type
system: moves and non-lexical lifetimes.
Prior to 2018, the lifetimes of Rust objects followed the
lexical scopes of those objects, and this code would have failed
compilation on line 10, since the `&mut barmut` mutable borrow
from `foo` still existed in the lexical scope where we called
`foo.print()`. But since 2018, the borrow checker was changed
so that lifetimes reflect the flow graph of the program, not
just the lexical structure; in this case, the compiler can infer
that nothing in the program uses `barmut` after line 9, so
calling `foo.print()` on line 10 is fine; the borrow still
"exists" but is inactive by then.
On the other hand, if I rewrite the last few lines as:
? foo = Obj(32);
? let barmut = &mut foo;
? foo.print();
? barmut.0 = 22;
? barmut.print();
Then this fails to compile; the immutable borrow taken for
`foo.print()` conflicts with the mutable borrow taken on the
previous line.
By default, all assignments in Rust have _move_ semantics: after
the assignment, the source is considered destroyed, and any
references to it are no longer valid. That's why one can assign
to `foo` and on line 5 and then take a mut reference to it on
line 7; the assignment on 5 implicitly dropped the original
`foo` object created on line 1 and replaced it with a new
object, so the mut reference it created on line 3 is invalid;
an attempt to use it subsequently would fail to compile.
One can define a `copy` operator for types that should not have
move semantics; this is usually applied to trivial types (like
integers).
One may ask, "why bother with all of this stuff?" and the answer
is that Rust is designed for a multicore world. There is one
other wrinkle here that gives Rust a lot of power, and that's
how all of this stuff interacts with data races: safe Rust code
is data race free.
Rust does not mandate a particular shape or type of (software)
thread, but because of the "mut ref ^ immut ref" rule, enforced
by the borrow checker at compile-time, safe Rust programs cannot
race on access to data, even in the face of multithreading.
Rust handles this by exposing two "marker traits", `Sync` and
`Send`. To quote the _Rustinomicon_, "A type is `Send` if it is
safe to send it to another thread" and "A type is `Sync` if it
is safe to share between threads (T is `Sync` if and only if
`&T` is `Send`)." That is, a type can be _shared_ between
threads if it is safe to send an immutable reference to it from
one thread to another, and the compiler can check borrows
against the lifetimes of objects, hence, can detect data races
_statically, at compile time_.
(https://doc.rust-lang.org/nomicon/send-and-sync.html)
Those of us familiar with writing multithreaded programs will
recognize the power of these constructs: these rules, taken
together, statically eliminate entire categories of common
memory and concurrency problems.
Anyway, that what "mutable" means, in a nutshell, and why it is
important.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-12 18:37 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1791830267-5857@newsgrouper.org> |
| In reply to | #118559 |
cross@spitfire.i.gajendra.net (Dan Cross) posted: First off: thank you dan for a well done explanation. > In article <1791742457-5857@newsgrouper.org>, > MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > > > >Terje Mathisen <terje.mathisen@tmsw.no> posted: > > > >> Dan Cross wrote: > >--------- > >> > >> My old asm/C brain _knows_ that a slice of something with a known > >> address and total length is effectively the same thing as an unmutable > >> array. > > > >Can I get a definition of what mutable in Rust means ?? > --------snip of what I understand clearly------------ > > So this will fail to compile: > > ? let mut foo = something(); > ? let foomut = &mut foo; // Ok: only mutable > ? let barmut = &mut foo // Fail: a mut ref to foo exists Is this supposed to work across threads ?? so, only 1 thread has write access at any given point in time. If so, how does one thread hand-off mutability to another ?? --------------snip again-------- > > By default, all assignments in Rust have _move_ semantics: after > the assignment, the source is considered destroyed, and any > references to it are no longer valid. That's why one can assign > to `foo` and on line 5 and then take a mut reference to it on > line 7; the assignment on 5 implicitly dropped the original > `foo` object created on line 1 and replaced it with a new > object, so the mut reference it created on line 3 is invalid; > an attempt to use it subsequently would fail to compile. This is clever. > One can define a `copy` operator for types that should not have > move semantics; this is usually applied to trivial types (like > integers). > > One may ask, "why bother with all of this stuff?" and the answer > is that Rust is designed for a multicore world. There is one > other wrinkle here that gives Rust a lot of power, and that's > how all of this stuff interacts with data races: safe Rust code > is data race free. See question above. > Rust does not mandate a particular shape or type of (software) > thread, but because of the "mut ref ^ immut ref" rule, enforced > by the borrow checker at compile-time, safe Rust programs cannot > race on access to data, even in the face of multithreading. > > Rust handles this by exposing two "marker traits", `Sync` and > `Send`. To quote the _Rustinomicon_, "A type is `Send` if it is > safe to send it to another thread" and "A type is `Sync` if it > is safe to share between threads (T is `Sync` if and only if > `&T` is `Send`)." That is, a type can be _shared_ between > threads if it is safe to send an immutable reference to it from > one thread to another, and the compiler can check borrows > against the lifetimes of objects, hence, can detect data races > _statically, at compile time_. > (https://doc.rust-lang.org/nomicon/send-and-sync.html) > > Those of us familiar with writing multithreaded programs will > recognize the power of these constructs: these rules, taken > together, statically eliminate entire categories of common > memory and concurrency problems. > > Anyway, that what "mutable" means, in a nutshell, and why it is > important. Thanks again for a complete explanation. > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-12 21:07 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aji7b$2fh$1@reader2.panix.com> |
| In reply to | #118565 |
In article <1791830267-5857@newsgrouper.org>, MitchAlsup <user5857@newsgrouper.org.invalid> wrote: > >cross@spitfire.i.gajendra.net (Dan Cross) posted: > >First off: thank you dan for a well done explanation. > >> In article <1791742457-5857@newsgrouper.org>, >> MitchAlsup <user5857@newsgrouper.org.invalid> wrote: >> > >> >Terje Mathisen <terje.mathisen@tmsw.no> posted: >> > >> >> Dan Cross wrote: >> >--------- >> >> >> >> My old asm/C brain _knows_ that a slice of something with a known >> >> address and total length is effectively the same thing as an unmutable >> >> array. >> > >> >Can I get a definition of what mutable in Rust means ?? >> >--------snip of what I understand clearly------------ >> >> So this will fail to compile: >> >> ? let mut foo = something(); >> ? let foomut = &mut foo; // Ok: only mutable >> ? let barmut = &mut foo // Fail: a mut ref to foo exists > >Is this supposed to work across threads ?? so, only 1 thread has write >access at any given point in time. Yes, that's right. >If so, how does one thread hand-off mutability to another ?? Typically, you use a mutual exclusion primitive of one kind or another to serialize access to mutable state. For example, the standard library includes the usual complement of Mutex, reader/writer locks, condition variables, barriers, reference counters, thread-safe channels, and so on. For bare-metal programs we have to implement these ourselves, but there are some third-party implementations that can help (for example, the `spin` crate implements spinlocks, providing, an interface that looks close to `std::sync::Mutex`). Something I should have mentioned earlier is that Rust object has a single, well-defined owner, and that references to that object are borrowed _from the owner_. So, using `Mutex` as an example, we make the `Mutex` itself the owner of the object: the `.lock()` method lets threads borrow mutable references to the object, and the serialization inherent in the Mutex type and the locking protocol enforces the "mut ^ immut" semantics across threads. Similarly, a `RwLock` can hand out multiple immutable refs to the object, but keeps track of them, and only lets one borrower access a `mut ref` at a time, and only when there are no outstanding immutable refs to it. In fact, it's slightly more complex in that `mutex.lock()` actually returns a proxy object that holds onto the reference; its return type is actually, `LockResult<LockGuard<'_, T>>`, where `'_` is an anonymous lifetime, and `T` is the type of the thing protected by the `Mutex`. `LockResult` lets someone detect a lock that has been poisoned; the `LockGuard` is the thing that holds the ref. When it goes otu of scope, it automatically unlocks the mutex, and it implements a trait called `Deref` to forward uses on to the ref to the locked object. This all intersects with the `Send`/`Sync` stuff; `Mutex` is `Sync`, and `Mutex` objects themselves are treated as immutable. So to share access to a `Foo` between threads, I use something like a `Mutex<Foo>`. This is an example of "Interior Mutability", where something immutable (the `Mutex` object itself) can hold onto something that is mutable. This raises a question: if all this machinery is required for safe access to shared data across threads anyway, then why all the language-level rules? The answer is hinted at by the mutex object itself is immutable, we can hand out references to it easily. Since it owns the (mutable) object the lock protects, it can decide how to hand out references to the object. >--------------snip again-------- >> By default, all assignments in Rust have _move_ semantics: after >> the assignment, the source is considered destroyed, and any >> references to it are no longer valid. That's why one can assign >> to `foo` and on line 5 and then take a mut reference to it on >> line 7; the assignment on 5 implicitly dropped the original >> `foo` object created on line 1 and replaced it with a new >> object, so the mut reference it created on line 3 is invalid; >> an attempt to use it subsequently would fail to compile. > >This is clever. > >> One can define a `copy` operator for types that should not have >> move semantics; this is usually applied to trivial types (like >> integers). >> >> One may ask, "why bother with all of this stuff?" and the answer >> is that Rust is designed for a multicore world. There is one >> other wrinkle here that gives Rust a lot of power, and that's >> how all of this stuff interacts with data races: safe Rust code >> is data race free. > >See question above. See above; hopefully that helps? There's one other thing here that may be interesting: how does one implement any of this stuff _in Rust_? In particular, how does one implement interior mutability? The answer is using something called the `UnsafeCell`: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html `UnsafeCell` allows mutation of an object (the thing owned by the cell) through a shared (what up to now I've been calling an "immutable") reference to the cell. It's the one place that permits that behavior. The implementatin of a spinlock in the `spin` crate is an interesting read to understand the mechanics here: https://codeberg.org/zesterer/spin/src/branch/master/src/mutex/spin.rs >> Rust does not mandate a particular shape or type of (software) >> thread, but because of the "mut ref ^ immut ref" rule, enforced >> by the borrow checker at compile-time, safe Rust programs cannot >> race on access to data, even in the face of multithreading. >> >> Rust handles this by exposing two "marker traits", `Sync` and >> `Send`. To quote the _Rustinomicon_, "A type is `Send` if it is >> safe to send it to another thread" and "A type is `Sync` if it >> is safe to share between threads (T is `Sync` if and only if >> `&T` is `Send`)." That is, a type can be _shared_ between >> threads if it is safe to send an immutable reference to it from >> one thread to another, and the compiler can check borrows >> against the lifetimes of objects, hence, can detect data races >> _statically, at compile time_. >> (https://doc.rust-lang.org/nomicon/send-and-sync.html) >> >> Those of us familiar with writing multithreaded programs will >> recognize the power of these constructs: these rules, taken >> together, statically eliminate entire categories of common >> memory and concurrency problems. >> >> Anyway, that what "mutable" means, in a nutshell, and why it is >> important. > >Thanks again for a complete explanation. Happy to do it. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-10-12 22:35 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1791844557-5857@newsgrouper.org> |
| In reply to | #118572 |
cross@spitfire.i.gajendra.net (Dan Cross) posted:
> In article <1791830267-5857@newsgrouper.org>,
> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >
> >cross@spitfire.i.gajendra.net (Dan Cross) posted:
> >
> >First off: thank you dan for a well done explanation.
> >
> >> In article <1791742457-5857@newsgrouper.org>,
> >> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
> >> >
> >> >Terje Mathisen <terje.mathisen@tmsw.no> posted:
> >> >
> >> >> Dan Cross wrote:
> >> >---------
> >> >>
> >> >> My old asm/C brain _knows_ that a slice of something with a known
> >> >> address and total length is effectively the same thing as an unmutable
> >> >> array.
> >> >
> >> >Can I get a definition of what mutable in Rust means ??
> >>
> >--------snip of what I understand clearly------------
> >>
> >> So this will fail to compile:
> >>
> >> ? let mut foo = something();
> >> ? let foomut = &mut foo; // Ok: only mutable
> >> ? let barmut = &mut foo // Fail: a mut ref to foo exists
> >
> >Is this supposed to work across threads ?? so, only 1 thread has write
> >access at any given point in time.
>
> Yes, that's right.
>
> >If so, how does one thread hand-off mutability to another ??
>
> Typically, you use a mutual exclusion primitive of one kind or
> another to serialize access to mutable state. For example, the
> standard library includes the usual complement of Mutex,
> reader/writer locks, condition variables, barriers, reference
> counters, thread-safe channels, and so on. For bare-metal
> programs we have to implement these ourselves, but there are
> some third-party implementations that can help (for example, the
> `spin` crate implements spinlocks, providing, an interface that
> looks close to `std::sync::Mutex`).
>
> Something I should have mentioned earlier is that Rust object
> has a single, well-defined owner, and that references to that
> object are borrowed _from the owner_.
I was expecting one "thread" to hold (own?) the object in question
and was unsure how mutablility was handed out across other threads.
I had imagined that then current mut owner had its 'pointer' go
out of block and that somehow his no longer having a mutable ref
to the object somehow got propagated automagically by his leaving
of the block {which seems untenable}.
falling back on standard ways of passing this stuff around adds hope.
{{less Ada rendezvous like}}
> So, using `Mutex` as an example, we make the `Mutex` itself the
> owner of the object: the `.lock()` method lets threads borrow
> mutable references to the object, and the serialization inherent
> in the Mutex type and the locking protocol enforces the
> "mut ^ immut" semantics across threads.
Since I am a CPU guy, I would like to see the asm from any modern
architecture perform this handoff ! <please> ?
> Similarly, a `RwLock` can hand out multiple immutable refs to
> the object, but keeps track of them, and only lets one borrower
> access a `mut ref` at a time, and only when there are no
> outstanding immutable refs to it.
Sounds like reference counting...
> In fact, it's slightly more complex in that `mutex.lock()`
> actually returns a proxy object that holds onto the reference;
> its return type is actually, `LockResult<LockGuard<'_, T>>`,
> where `'_` is an anonymous lifetime, and `T` is the type of the
> thing protected by the `Mutex`. `LockResult` lets someone
> detect a lock that has been poisoned; the `LockGuard` is the
> thing that holds the ref. When it goes otu of scope, it
> automatically unlocks the mutex, and it implements a trait
> called `Deref` to forward uses on to the ref to the locked
> object.
Another level of indirection to handle a more complicated issue...
> This all intersects with the `Send`/`Sync` stuff; `Mutex` is
> `Sync`, and `Mutex` objects themselves are treated as immutable.
> So to share access to a `Foo` between threads, I use something
> like a `Mutex<Foo>`. This is an example of "Interior
> Mutability", where something immutable (the `Mutex` object
> itself) can hold onto something that is mutable.
>
> This raises a question: if all this machinery is required for
> safe access to shared data across threads anyway, then why all
> the language-level rules? The answer is hinted at by the mutex
> object itself is immutable, we can hand out references to it
> easily. Since it owns the (mutable) object the lock protects,
> it can decide how to hand out references to the object.
We have the same problems with coherent caches and there are 3
normal solutions {MESI, MOESI, and Directories}
> >--------------snip again--------
> >> By default, all assignments in Rust have _move_ semantics: after
> >> the assignment, the source is considered destroyed, and any
> >> references to it are no longer valid. That's why one can assign
> >> to `foo` and on line 5 and then take a mut reference to it on
> >> line 7; the assignment on 5 implicitly dropped the original
> >> `foo` object created on line 1 and replaced it with a new
> >> object, so the mut reference it created on line 3 is invalid;
> >> an attempt to use it subsequently would fail to compile.
> >
> >This is clever.
> >
> >> One can define a `copy` operator for types that should not have
> >> move semantics; this is usually applied to trivial types (like
> >> integers).
> >>
> >> One may ask, "why bother with all of this stuff?" and the answer
> >> is that Rust is designed for a multicore world. There is one
> >> other wrinkle here that gives Rust a lot of power, and that's
> >> how all of this stuff interacts with data races: safe Rust code
> >> is data race free.
> >
> >See question above.
>
> See above; hopefully that helps?
Yes, quite a lot. Thanks for taking the time.
I ask these detailed questions to see if there is some tweak to
my ISA that could allow a less costly solution with equivalent
semantics.
> There's one other thing here that may be interesting: how does
> one implement any of this stuff _in Rust_? In particular, how
> does one implement interior mutability?
I care about ISA semantics, where some small-moderate tweak might
shrink the code path significantly.
> The answer is using something called the `UnsafeCell`:
> https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html
>
> `UnsafeCell` allows mutation of an object (the thing owned by
> the cell) through a shared (what up to now I've been calling an
> "immutable") reference to the cell. It's the one place that
> permits that behavior.
>
> The implementatin of a spinlock in the `spin` crate is an
> interesting read to understand the mechanics here:
> https://codeberg.org/zesterer/spin/src/branch/master/src/mutex/spin.rs
I will read these later.
> >> Rust does not mandate a particular shape or type of (software)
> >> thread, but because of the "mut ref ^ immut ref" rule, enforced
> >> by the borrow checker at compile-time, safe Rust programs cannot
> >> race on access to data, even in the face of multithreading.
> >>
> >> Rust handles this by exposing two "marker traits", `Sync` and
> >> `Send`. To quote the _Rustinomicon_, "A type is `Send` if it is
> >> safe to send it to another thread" and "A type is `Sync` if it
> >> is safe to share between threads (T is `Sync` if and only if
> >> `&T` is `Send`)." That is, a type can be _shared_ between
> >> threads if it is safe to send an immutable reference to it from
> >> one thread to another, and the compiler can check borrows
> >> against the lifetimes of objects, hence, can detect data races
> >> _statically, at compile time_.
> >> (https://doc.rust-lang.org/nomicon/send-and-sync.html)
> >>
> >> Those of us familiar with writing multithreaded programs will
> >> recognize the power of these constructs: these rules, taken
> >> together, statically eliminate entire categories of common
> >> memory and concurrency problems.
> >>
> >> Anyway, that what "mutable" means, in a nutshell, and why it is
> >> important.
> >
> >Thanks again for a complete explanation.
>
> Happy to do it.
>
> - Dan C.
>
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-17 02:03 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aul0r$6f4$1@reader2.panix.com> |
| In reply to | #118575 |
In article <1791844557-5857@newsgrouper.org>,
MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) posted:
>> In article <1791830267-5857@newsgrouper.org>,
>> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>> >cross@spitfire.i.gajendra.net (Dan Cross) posted:
>> >First off: thank you dan for a well done explanation.
>> >
>> >> In article <1791742457-5857@newsgrouper.org>,
>> >> MitchAlsup <user5857@newsgrouper.org.invalid> wrote:
>> >> >
>> >> >Terje Mathisen <terje.mathisen@tmsw.no> posted:
>> >> >
>> >> >> Dan Cross wrote:
>> >> >---------
>> >> >>
>> >> >> My old asm/C brain _knows_ that a slice of something with a known
>> >> >> address and total length is effectively the same thing as an unmutable
>> >> >> array.
>> >> >
>> >> >Can I get a definition of what mutable in Rust means ??
>> >>
>> >--------snip of what I understand clearly------------
>> >>
>> >> So this will fail to compile:
>> >>
>> >> ? let mut foo = something();
>> >> ? let foomut = &mut foo; // Ok: only mutable
>> >> ? let barmut = &mut foo // Fail: a mut ref to foo exists
>> >
>> >Is this supposed to work across threads ?? so, only 1 thread has write
>> >access at any given point in time.
>>
>> Yes, that's right.
>>
>> >If so, how does one thread hand-off mutability to another ??
>>
>> Typically, you use a mutual exclusion primitive of one kind or
>> another to serialize access to mutable state. For example, the
>> standard library includes the usual complement of Mutex,
>> reader/writer locks, condition variables, barriers, reference
>> counters, thread-safe channels, and so on. For bare-metal
>> programs we have to implement these ourselves, but there are
>> some third-party implementations that can help (for example, the
>> `spin` crate implements spinlocks, providing, an interface that
>> looks close to `std::sync::Mutex`).
>>
>> Something I should have mentioned earlier is that Rust object
>> has a single, well-defined owner, and that references to that
>> object are borrowed _from the owner_.
>
>I was expecting one "thread" to hold (own?) the object in question
>and was unsure how mutablility was handed out across other threads.
I think it may be easier to think of software objects as the
owners, and threads as scopes. You can certainly have data that
"lives" within the context of a single thread and shared with
other threads, but the fundamental mechanism is the same: you
share some some kind of immutable reference to the (software)
object that actually owns the data and ask it to borrow the
actual data.
>I had imagined that then current mut owner had its 'pointer' go
>out of block and that somehow his no longer having a mutable ref
>to the object somehow got propagated automagically by his leaving
>of the block {which seems untenable}.
>
>falling back on standard ways of passing this stuff around adds hope.
>{{less Ada rendezvous like}}
Yeah. The thing that makes Rust interesting with respect to
these primitives is how you build them, using interior
mutability and the sharing rules of the language to make
guarantees about the correctness of the locking protocol.
In particular, if you take a resource you want to share, and you
hide it "inside" of some other object that logically "owns" the
resource, and then make it so that the only way you can access
it is via some interface provided by the owning object, then you
can enforce that nothing goes behind the back of the locking
protocol and accesses the shared resource independently.
Put another way, if the only way to get access to the resource
is through a proxy object returned by the owner's `.lock()`
method, and the owner makes sure that only one of those exists
at a time, then you've defacto serialized access to the
resource. Moreover, this is now enforced statically, by the
_compiler_, at build time. Your runtime cost on top of the
usual way is zero.
>> So, using `Mutex` as an example, we make the `Mutex` itself the
>> owner of the object: the `.lock()` method lets threads borrow
>> mutable references to the object, and the serialization inherent
>> in the Mutex type and the locking protocol enforces the
>> "mut ^ immut" semantics across threads.
>
>Since I am a CPU guy, I would like to see the asm from any modern
>architecture perform this handoff ! <please> ?
I mentioned this earlier but it bears repeating: all of this is
logical, at the level of the language.
Within the context of the Rust standard library, when targeting
an existing platform, the library primitives are usually
implemented in terms of familiar system interfaces: futexs on
Linux; pthreads and `pthread_mutex_t` where that's applicable;
whatever Windows does on Windows, and so on.
When you're writing bare metal code, you can roll your own, but
lots of folks just use the `spin` crate.
Once it's compiled, big chunks of it inline and it all lowers
down to more or less standard instruction sequences. The Rust
compiler generally does pretty well about optimizing the
abstractions away, meaning you're mostly left with "normal"
CAS instructions, barriers, and loads/stores.
See the end of the deep-dive into a spin-Mutex implementation,
with notes on how that maps to a real ISA.
>> Similarly, a `RwLock` can hand out multiple immutable refs to
>> the object, but keeps track of them, and only lets one borrower
>> access a `mut ref` at a time, and only when there are no
>> outstanding immutable refs to it.
>
>Sounds like reference counting...
Kinda. The property of a read/write lock is that multiple
readers can access the shared thing at one time, but only one
writer (sounds familiar with respect to the borrow checker rules
with respect to mutability, right?).
Building robust, scalable, production-quality RW locks is
surprisingly hard.
Of course, you have to keep track of the number of readers
actively holding the lock at any given time, but if we naively
admit more readers any time that number is >0, we run the risk
of starving writers; a writer may pend waiting on the lock while
readers just keep appearing. Similarly, if you've got a high
priority writer blocked behind a bunch of readers, you're open
to priority inversion; what if one of the readers blocks? The
point is, we also need to keep track of pending writers and the
priorities of whatever is contending for the lock.
>> In fact, it's slightly more complex in that `mutex.lock()`
>> actually returns a proxy object that holds onto the reference;
>> its return type is actually, `LockResult<LockGuard<'_, T>>`,
>> where `'_` is an anonymous lifetime, and `T` is the type of the
>> thing protected by the `Mutex`. `LockResult` lets someone
>> detect a lock that has been poisoned; the `LockGuard` is the
>> thing that holds the ref. When it goes otu of scope, it
>> automatically unlocks the mutex, and it implements a trait
>> called `Deref` to forward uses on to the ref to the locked
>> object.
>
>Another level of indirection to handle a more complicated issue...
Well, it's more about correctness than addressing a more complex
issue, per se. Forgive me if I've already posted this link, but
this is a good explanation of what's going on:
https://cliffle.com/blog/rust-mutexes/
>> This all intersects with the `Send`/`Sync` stuff; `Mutex` is
>> `Sync`, and `Mutex` objects themselves are treated as immutable.
>> So to share access to a `Foo` between threads, I use something
>> like a `Mutex<Foo>`. This is an example of "Interior
>> Mutability", where something immutable (the `Mutex` object
>> itself) can hold onto something that is mutable.
>>
>> This raises a question: if all this machinery is required for
>> safe access to shared data across threads anyway, then why all
>> the language-level rules? The answer is hinted at by the mutex
>> object itself is immutable, we can hand out references to it
>> easily. Since it owns the (mutable) object the lock protects,
>> it can decide how to hand out references to the object.
>
>We have the same problems with coherent caches and there are 3
>normal solutions {MESI, MOESI, and Directories}
Right. Interestingly, little of this solves those problems, but
the way we implement e.g., locking can influence how the
software interacts with those things. See below.
> [snip]
Acknowleding the mention you made about about how this all maps
to the ISA level, let's take a look at an actual program. Here
is an implementation of a simple spinlock:
```
//! Spin locks in Rust.
#![no_std]
use core::cell::UnsafeCell;
use core::marker::{Send, Sync};
use core::ops::{Deref, DerefMut};
use core::sync::atomic::{AtomicBool, Ordering};
pub struct Lock<T: ?Sized> {
held: AtomicBool,
data: UnsafeCell<T>,
}
impl<T> Lock<T> {
/// Creates a new `Lock` that owns an object of type T.
pub const fn new(value: T) -> Lock<T> {
Lock {
held: AtomicBool::new(false),
data: UnsafeCell::new(value),
}
}
/// Consumes the lock and returns the contained object.
pub fn into_inner(self) -> T {
self.data.into_inner()
}
}
impl<T: ?Sized> Lock<T> {
/// Acquires the lock. Returns a LockGuard that will
/// release the lock when dropped.
pub fn lock(&self) -> LockGuard<'_, T> {
while self.held.load(Ordering::Relaxed) || self.held.swap(true, Ordering::AcqRel) {
core::hint::spin_loop();
}
LockGuard {
data: unsafe { &mut *self.data.get() },
lock: self,
}
}
/// Releases the lock, assuming it is held. Private, so
/// that the only way to unlock is through the `drop` method
/// of a `LockGuard<T>` (that itself can only exist as the
/// result of a successful call to `lock`), or by calling
/// the unsafe `force_unlock` method.
fn unlock(&self) {
self.held.store(false, Ordering::Release);
}
/// Force-releases the lock.
///
/// Suppose that a lock guard holding the lock is leaked
/// (e.g., via `std::mem::forget()`); its `drop` method
/// can never be called to unlock. This function provides
/// an unsafe escape hatch to release the lock.
///
/// # Safety
///
/// Callers must ensure that the lock is currently locked,
/// that the underlying object is in a state that it is
/// safe to unlock, and that nothing else will try to unlock
/// the current lock-holder later; leaked LockGuards must
/// be forgotten: their `drop` methods must never be
/// invoked, and their borrows to the lock-owned data must
/// be gone.
pub unsafe fn force_unlock(&self) {
self.unlock();
}
}
unsafe impl<T: ?Sized + Send> Send for Lock<T> {}
unsafe impl<T: ?Sized + Send> Sync for Lock<T> {}
pub struct LockGuard<'a, T: ?Sized> {
lock: &'a Lock<T>,
data: &'a mut T,
}
impl<T: ?Sized> Deref for LockGuard<'_, T> {
type Target = T;
fn deref(&self) -> &T {
self.data
}
}
impl<T: ?Sized> DerefMut for LockGuard<'_, T> {
fn deref_mut(&mut self) -> &mut T {
self.data
}
}
impl<T: ?Sized> Drop for LockGuard<'_, T> {
fn drop(&mut self) {
self.lock.unlock();
}
}
```
What's going on here? A couple of notes. First, the lock
itself is pretty simple: it uses a single atomic boolean for
the lock bit, and holds the data protected by the lock in an
`UnsafeCell` (which it owns, meaning that it owns the data).
The first Rust-related thing that may be unfamiliar is that the
`Lock` type is "generic" over some type `T`; we say little about
what `T` is, but we use the `?Sized` construct to _remove_ the
constraint that the size of `T` must be a compile-time constant.
Rust has types where this is not the case, like slices (`[T]`),
which it describes as "dynamic views" into a "contiguous
sequence" of objects of some type; since the view is dynamic,
the number is not knowable at compile time (it is a runtime
property). But we want to be able to lock slices, so we use
`?Sized`. Because the size of `T` cannot be known at compile
time, the `UnsafeCell` that owns it comes last in the structure
definition.
Note the two `impl`s: these are where we define methods on
`Lock<T>`. The `.lock()` and `.unlock()` (and `force_unlock()`)
methods don't care what size the type is; they only operate on
the lock bit or references to `T` (via the interface of the
unsafe cell that owns the `T`), so we allow `?Sized` for `T`.
On the other hand, the `.new()` and `.into_inner()` methods _do_
care about the size of T: `.new` is a constructor that takes an
instance of T _by value_, which by default _moves_ the T object;
it moves it into the `UnsafeCell` (again, by value, so now the
`UnsafeCell` owns the T), creates a new `Lock<T>` that takes
ownership of the `UnsafeCell` (...and a new `AtomicBool`
initialized to `false` for the lock bit: false=="unlocked").
`.into_inner()` is a bit more interesting: this takes the `Lock`
by value, which moves it, thus consuming it; it then extracts
the T object from the `UnsafeCell` (via the cell's
`.into_inner()` method) and returns the value; we can do this
when we're done with the lock and want to discard it and
retrieve the value it had protected.
The `unsafe impl Send...` and `unsafe impl Sync...` tell the
language that we are implementing the `Send` and `Sync` traits
I mentioned the other day, for `Lock<T>`. These are `unsafe`
because we are taking the responsibility for ensuring that the
rules around send and sync are upheld, and not leaving that to
the compiler.
There's also `.force_unlock`, but let me talk about `LockGuard`
first.
Note that `.lock()` doesn't return e.g., a reference to the
locked object in the `UnsafeCell` owned by the lock. Instead,
it returns an onject of type `LockGuard<T>`, that has two data
members, both of which are references: one (a mutable borrow,
hence unique) to the object protected by the lock, and the
other, an immutable reference to the `Lock` that owns the
object.
A `LockGuard<'a, T>` is a proxy object through which we access
the T object protected by the lock. We've talked about the
generic "type" parameter, `T`, already, but what is this `'a`
thing? That is a _lifetime_ parameter: since `LockGuard`'s
data includes _references_, we need to tell the compiler how
long those can live, and what relationship they share (if any).
Here, we say, "these references share some lifetime, that we
call `'a`."
We then provide `impl`'s of three _traits_: a trait is basically
an interface, and describes methods and "associated types". We
"implement" it for types in order to expose the behavior the
trait describes, for those types. In this case, we impl
`Deref`, `DerefMut`, and `Drop`.
The first two allow us to use the `*` syntax to indirect through
the `LockGuard<T>` and access the object; hence, when we write,
`let guard = whatever.lock(); dosomething(*guard);`, we are
invoking the `.deref()` method we impl'ed from the `Deref` trait
on guard, and taking _its_ return value and passing that to
`dosomething`: here, that's an `&T`: an immutable borrow of the
T. `DerefMut` is similar, but used for mutable borrows; the
caveat with `DerefMut` is that the guard object must, itself, be
`mut` to invote `.deref_mut()` on it; the compiler will complain
if not.
The last trait, `Drop`, exposes the `.drop()` method that gets
automatically invoked when the `LockGuard<T>` object is
destroyed (either by going out of scope, or by passing it to the
`drop()` _function_, which takes its argument by value). In the
case of `LockGuard`, the `.drop` calls `self.lock.unlock();`,
unlocking the lock we've been holding, and giving another thread
a chance to grab the lock: note that `Lock<T>`'s `.unlock()`
method is _not_ marked `pub`: it is a private interface.
`LockGuard` can call it because it's defined in the same
_module_ as `Lock`, however; hence, the only way to invoke
`.unlock()` on the spinlock is via dropping the `LockGuard`.
I said I'd mention `.force_unlock()`, and now's the time:
everything I just said is a shameless lie. Well, not exactly,
but it is possible to "leak" a `LockGuard` so that it's
`.drop()` method is never called; the first is by passing it to,
`std::mem::forget`:
https://doc.rust-lang.org/std/mem/fn.forget.html
Using `std::mem::forget`, it's possible to "leak" a locked
object. So, the `.force_unlock` method is provided as an
escape hatch for situations where you know that the guard that
proxied a lock is gone and not coming back, but you still want
to be able unlock the lock. Thus, it is both _public_ and also
marked `unsafe`: this means that anyone who can get a reference
to the `lock` can call it, but they _must_ do so from inside an
`unsafe` block: the programmer takes on the responsibility of
ensuring that the invariants the lock requires are upheld if
they call it, and the compiler washes its hands of the
consequences.
Let's look at man example program that uses this:
```
fn main() {
let lock = spinlock::Lock::new(1);
let mut v = lock.lock();
*v -= 1;
std::mem::forget(v);
unsafe {
lock.force_unlock();
}
let val = lock.into_inner();
println!("val = {val}");
let v = threaded_add(16, 128);
println!("v = {v}");
}
#[inline(never)]
fn threaded_add(nthread: u16, niter: u16) -> u32 {
let lock = spinlock::Lock::new(0);
std::thread::scope(|scope| {
for _ in 0..nthread {
scope.spawn(|| count(&lock, niter));
}
});
lock.into_inner()
}
#[inline(never)]
fn count(lock: &spinlock::Lock<u32>, niter: u16) {
for _k in 0..niter {
let mut v = lock.lock();
*v += 1;
}
}
#[cfg(test)]
#[test]
fn threaded_add_works() {
assert_eq!(threaded_add(16, 1024), 16384);
}
```
Ok, so there are a couple of things going on here; first, I
create a new spinlock around an unsigned 32-bit integer
containing the value `1`, then I lock it and assign the result
to a mutable LockGuard, `v`; I use that to subtract 1 from the
value of the locked object, and then I `std::mem::forget` the
guard. I unlock the object via calling `.force_unlock()` in an
`unsafe { ... }` block, and then I consume the lock and get
the integer's counter from `.into_inner()` and print it out.
Next, I invoke this `threaded_add`, which creates a locked
counter, creates a few threads, and in each of those threads,
runs a loop that repeatedly locks the counter, adds one to it,
and drops the lock guard (implicitly, by letting it go out of
scope at the at the end of the loop body). Note that I broke
the counting loop out into a function annotated with the,
`[inline(never)]` _attribute_: this is just so I can find it
easily in assembly language output when I dump out the
instructions with `objdump` below.
All of the threads I create are "scoped", which means that they
are definitely reaped when the scope ends, and thus can't hold
references to the lock after they complete; this way, I can
safely consume the lock in with `.into_inner()` and return the
value of the counter from `threaded_add`.
Back in `main`, I capture the value returned from `threaded_add`
and _bind_ it to a variable I'm calling `v`; you may notice that
is the same name I had used for the `LockGuard` I created
earlier this was deliberate to demonstrate that `let` creates
lexical bindings, which can be replaced. Ordinarily, one would
not usually do this as a matter of good programming practice,
but it _can_ be useful (for example, when casting a value to
some compatible but different type).
There's also a `#[test]` function that runs automatically when
I build and run in test mode. It just invokes `threaded_add`
with a fixed number of threads and iterations for each, and
asserts the final output.
When run, this program prints:
val = 0
v = 2048
Which is what I expected.
So what does this look like at the machine code level? Let's
take a look at an excerpt from an optimized build, for x86_64.
This is the complete compiled output for `count`, shown above:
```
0000000000019aa0 <spinlock::count::hd8ea4fab4f0cabbe>:
19aa0: 66 85 f6 test %si,%si
19aa3: 74 2a je 19acf <spinlock::count::hd8ea4fab4f0cabbe+0x2f>
19aa5: 55 push %rbp
19aa6: 48 89 e5 mov %rsp,%rbp
19aa9: 31 c0 xor %eax,%eax
19aab: eb 05 jmp 19ab2 <spinlock::count::hd8ea4fab4f0cabbe+0x12>
19aad: cc int3
19aae: cc int3
19aaf: cc int3
19ab0: f3 90 pause
19ab2: 0f b6 0f movzbl (%rdi),%ecx
19ab5: 84 c9 test %cl,%cl
19ab7: 75 f7 jne 19ab0 <spinlock::count::hd8ea4fab4f0cabbe+0x10>
19ab9: b1 01 mov $0x1,%cl
19abb: 86 0f xchg %cl,(%rdi)
19abd: 84 c9 test %cl,%cl
19abf: 75 ef jne 19ab0 <spinlock::count::hd8ea4fab4f0cabbe+0x10>
19ac1: ff 47 04 incl 0x4(%rdi)
19ac4: ff c0 inc %eax
19ac6: c6 07 00 movb $0x0,(%rdi)
19ac9: 66 39 f0 cmp %si,%ax
19acc: 75 e4 jne 19ab2 <spinlock::count::hd8ea4fab4f0cabbe+0x12>
19ace: 5d pop %rbp
19acf: c3 retq
```
Here, `%rdi` is the reference to the `Lock<T>` and `%rsi` holds
`niter`. The first couple of instructions short-circuit an
argument of zero iterations, then do the usual function prologue
stuff and jump into the spin loop, (aligned on a 16 byte
boundary); there's the relaxed load at 0x19ab2, a test to see
if it's zero, and if not, jump back to the `PAUSE` (the
`std::hint::spin_loop()` call in the code). Otherwise, we
`xchg` the contents of the lock bit with a 1 (the
`self.lock.swap(true, Ordering::AcqRel)` in the code) and test
again; if we didn't win, it's a jump back to the pause and try
again. Otherwise, we increment the 32-bit word at offset 0x4
from the beginning of the lock (the shared counter), increment
the iteration count (in `%ax`), compare against the limit, and
either jump back to the locking loop, or do the usual epilogue
and return.
Note that all of the abstraction: the `.lock`, `LockGuard`, and
so on, is inlined and removed by the compiler. We're left with
pretty reasonable code.
The only other interesting bits of code are in `threaded_add`,
and there's not that much that's relevant there: the `Lock<T>`
holding a `u32` initialized to zero and the lock at is created
on the stack alongside some space for a few other temporary
registers, and the object itself is "created" with two
instructions:
```
196fd: 48 83 ec 78 sub $0x78,%rsp
...
19707: c6 45 b0 00 movb $0x0,0xffffffffffffffb0(%rbp)
1970b: c7 45 b4 00 00 00 00 movl $0x0,0xffffffffffffffb4(%rbp)
```
Plumbing that into the threads that get created is a little
tedious, but not terribly interesting; it's just a couple of
`mov`s and `jmp`/`callq`s. The ending `.into_inner()` call is
just:
```
19892: 8b 45 b4 mov 0xffffffffffffffb4(%rbp),%eax
```
Right before cleaning up the stack, popping callee saved
registers, and the `retq`.
The full code is at https://github.com/dancrossnyc/spinlock.
Hope this helps?
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-07 22:25 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20261007222539.000033d0@yahoo.com> |
| In reply to | #118474 |
On Mon, 5 Oct 2026 11:36:59 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <86h5j5pky9.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >Terje Mathisen <terje.mathisen@tmsw.no> writes: > > > >> Tim Rentsch wrote: > >> > >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: > >>> > >>>> Tim Rentsch wrote: > >[...] > >>>>> I favor a type equivalent to size_t for use as array index > >>>>> variables. > >>>> > >>>> In Rust, the only acceptable array index is of type "usize", > >>>> which is effectively the same as u64 on most platforms these > >>>> days, but does not need to be so: On a 32-bit target, it would > >>>> be the same as u32. > >>>> > >>>> So effectively very similar to size_t. > >>> > >>> Maybe that limitation works okay in Rust. In C sometimes it's > >>> important to allow a signed value for indexing. Probably 99% of > >>> the time size_t is good, but not always. > >> > >> The fact that array indices are unsigned is one of the more crucial > >> underpinnings of Rust safety. Even more importantly, all such > >> indices are verified against the actual array upper boundary. > >> [...] > > > >It's nice that array index values are checked against the array > >bounds. > > Terje was actually incorrect here; bounds checks are added in > debug mode, but are (usually) removed in optimized builds. > Are you sure? Methinks The Book states otherwise: https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-07 20:05 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a68mu$m4l$1@reader2.panix.com> |
| In reply to | #118515 |
In article <20261007222539.000033d0@yahoo.com>, Michael S <already5chosen@yahoo.com> wrote: >On Mon, 5 Oct 2026 11:36:59 -0000 (UTC) >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> In article <86h5j5pky9.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >Terje Mathisen <terje.mathisen@tmsw.no> writes: >> > >> >> Tim Rentsch wrote: >> >> >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >> >>> >> >>>> Tim Rentsch wrote: >> >[...] >> >>>>> I favor a type equivalent to size_t for use as array index >> >>>>> variables. >> >>>> >> >>>> In Rust, the only acceptable array index is of type "usize", >> >>>> which is effectively the same as u64 on most platforms these >> >>>> days, but does not need to be so: On a 32-bit target, it would >> >>>> be the same as u32. >> >>>> >> >>>> So effectively very similar to size_t. >> >>> >> >>> Maybe that limitation works okay in Rust. In C sometimes it's >> >>> important to allow a signed value for indexing. Probably 99% of >> >>> the time size_t is good, but not always. >> >> >> >> The fact that array indices are unsigned is one of the more crucial >> >> underpinnings of Rust safety. Even more importantly, all such >> >> indices are verified against the actual array upper boundary. >> >> [...] >> > >> >It's nice that array index values are checked against the array >> >bounds. >> >> Terje was actually incorrect here; bounds checks are added in >> debug mode, but are (usually) removed in optimized builds. >> > >Are you sure? >Methinks The Book states otherwise: >https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access If the array length and index are known ahead of time, or can be statically proven to be valid, then yes, the checks are (likely) removed in release mode as part of the ordinary optimization passes. In the case where one has already asserted that `p + n < arr.len()`, then I would expect any index `arr[p + k]` to omit the bounds check, for k < n. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-10-07 23:25 +0300 |
| Subject | Re: Optimization by programmers |
| Message-ID | <20261007232531.000012dd@yahoo.com> |
| In reply to | #118518 |
On Wed, 7 Oct 2026 20:05:50 -0000 (UTC) cross@spitfire.i.gajendra.net (Dan Cross) wrote: > In article <20261007222539.000033d0@yahoo.com>, > Michael S <already5chosen@yahoo.com> wrote: > >On Mon, 5 Oct 2026 11:36:59 -0000 (UTC) > >cross@spitfire.i.gajendra.net (Dan Cross) wrote: > > > >> In article <86h5j5pky9.fsf@linuxsc.com>, > >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> >Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> > > >> >> Tim Rentsch wrote: > >> >> > >> >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: > >> >>> > >> >>>> Tim Rentsch wrote: > >> >[...] > >> >>>>> I favor a type equivalent to size_t for use as array index > >> >>>>> variables. > >> >>>> > >> >>>> In Rust, the only acceptable array index is of type "usize", > >> >>>> which is effectively the same as u64 on most platforms these > >> >>>> days, but does not need to be so: On a 32-bit target, it > >> >>>> would be the same as u32. > >> >>>> > >> >>>> So effectively very similar to size_t. > >> >>> > >> >>> Maybe that limitation works okay in Rust. In C sometimes it's > >> >>> important to allow a signed value for indexing. Probably 99% > >> >>> of the time size_t is good, but not always. > >> >> > >> >> The fact that array indices are unsigned is one of the more > >> >> crucial underpinnings of Rust safety. Even more importantly, > >> >> all such indices are verified against the actual array upper > >> >> boundary. [...] > >> > > >> >It's nice that array index values are checked against the array > >> >bounds. > >> > >> Terje was actually incorrect here; bounds checks are added in > >> debug mode, but are (usually) removed in optimized builds. > >> > > > >Are you sure? > >Methinks The Book states otherwise: > >https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access > > > > If the array length and index are known ahead of time, or can be > statically proven to be valid, then yes, the checks are (likely) > removed in release mode as part of the ordinary optimization > passes. That is not different from any other bound-checked language that has optimizing compiler. > In the case where one has already asserted that > `p + n < arr.len()`, then I would expect any index `arr[p + k]` > to omit the bounds check, for k < n. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-07 22:36 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a6agf$37m70$1@dont-email.me> |
| In reply to | #118518 |
Dan Cross wrote: > In article <20261007222539.000033d0@yahoo.com>, > Michael S <already5chosen@yahoo.com> wrote: >> On Mon, 5 Oct 2026 11:36:59 -0000 (UTC) >> cross@spitfire.i.gajendra.net (Dan Cross) wrote: >> >>> In article <86h5j5pky9.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>> >>>>> Tim Rentsch wrote: >>>>> >>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>>>> >>>>>>> Tim Rentsch wrote: >>>> [...] >>>>>>>> I favor a type equivalent to size_t for use as array index >>>>>>>> variables. >>>>>>> >>>>>>> In Rust, the only acceptable array index is of type "usize", >>>>>>> which is effectively the same as u64 on most platforms these >>>>>>> days, but does not need to be so: On a 32-bit target, it would >>>>>>> be the same as u32. >>>>>>> >>>>>>> So effectively very similar to size_t. >>>>>> >>>>>> Maybe that limitation works okay in Rust. In C sometimes it's >>>>>> important to allow a signed value for indexing. Probably 99% of >>>>>> the time size_t is good, but not always. >>>>> >>>>> The fact that array indices are unsigned is one of the more crucial >>>>> underpinnings of Rust safety. Even more importantly, all such >>>>> indices are verified against the actual array upper boundary. >>>>> [...] >>>> >>>> It's nice that array index values are checked against the array >>>> bounds. >>> >>> Terje was actually incorrect here; bounds checks are added in >>> debug mode, but are (usually) removed in optimized builds. >>> >> >> Are you sure? >> Methinks The Book states otherwise: >> https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access > > If the array length and index are known ahead of time, or can be > statically proven to be valid, then yes, the checks are (likely) > removed in release mode as part of the ordinary optimization > passes. In the case where one has already asserted that > `p + n < arr.len()`, then I would expect any index `arr[p + k]` > to omit the bounds check, for k < n. That's exactly what I expected when I wrote my code the way I did. I know that Java specifically handles this situation, lifting any array bounds checking out of inner loops if possible. As that Godbolt link shows, my expectation was wrong. OTOH, for such a small program having 6 extra branches, none of them ever taken, is not likely to add any cycles to the program latency since current CPUs have more than enough issue ports to be able to handle these branches while processing the real code. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-08 22:05 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a943k$fqq$1@reader2.panix.com> |
| In reply to | #118521 |
In article <11a6agf$37m70$1@dont-email.me>,
Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>Dan Cross wrote:
>> [snip]
>> If the array length and index are known ahead of time, or can be
>> statically proven to be valid, then yes, the checks are (likely)
>> removed in release mode as part of the ordinary optimization
>> passes. In the case where one has already asserted that
>> `p + n < arr.len()`, then I would expect any index `arr[p + k]`
>> to omit the bounds check, for k < n.
>
>That's exactly what I expected when I wrote my code the way I did. I
>know that Java specifically handles this situation, lifting any array
>bounds checking out of inner loops if possible.
>
>As that Godbolt link shows, my expectation was wrong.
>
>OTOH, for such a small program having 6 extra branches, none of them
>ever taken, is not likely to add any cycles to the program latency since
>current CPUs have more than enough issue ports to be able to handle
>these branches while processing the real code.
I thought it was worth a small experiment; here's a silly pair
of functions:
```rust
#[inline(never)]
pub fn sum_sub_array(arr: [u32; 4], k: usize) -> u32 {
if k + 3 > arr.len() {
return 0;
}
arr[k] + arr[k + 1] + arr[k + 2]
}
#[inline(never)]
pub fn sum_sub_slice(sl: &[u32], k: usize) -> u32 {
if k + 3 > sl.len() {
return 0;
}
sl[k] + sl[k + 1] + sl[k + 2]
}
```
If I run these in such a way that they're not totally optimized
away and do a release build, they generate the exact same code:
```
0000000000015cb0 <rust_indices::sum_sub_array>:
15cb0: 31 c0 xor %eax,%eax
15cb2: 48 83 fe 01 cmp $0x1,%rsi
15cb6: 77 0b ja 15cc3 <rust_indices::sum_sub_array+0x13>
15cb8: 8b 44 b7 04 mov 0x4(%rdi,%rsi,4),%eax
15cbc: 03 04 b7 add (%rdi,%rsi,4),%eax
15cbf: 03 44 b7 08 add 0x8(%rdi,%rsi,4),%eax
15cc3: c3 ret
15cc4: cc int3
...
15ccf: cc int3
0000000000015cd0 <rust_indices::sum_sub_slice>:
15cd0: 31 c0 xor %eax,%eax
15cd2: 48 83 fe 01 cmp $0x1,%rsi
15cd6: 77 0b ja 15ce3 <rust_indices::sum_sub_slice+0x13>
15cd8: 8b 44 b7 04 mov 0x4(%rdi,%rsi,4),%eax
15cdc: 03 04 b7 add (%rdi,%rsi,4),%eax
15cdf: 03 44 b7 08 add 0x8(%rdi,%rsi,4),%eax
15ce3: c3 ret
15ce4: cc int3
...
15cef: cc int3
```
Perhaps it's something about the complexity of your function
that exceed some sort of threshold for the optimizer.
- Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-10-09 16:36 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11aau61$sbtb$2@dont-email.me> |
| In reply to | #118530 |
Dan Cross wrote:
> In article <11a6agf$37m70$1@dont-email.me>,
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>> Dan Cross wrote:
>>> [snip]
>>> If the array length and index are known ahead of time, or can be
>>> statically proven to be valid, then yes, the checks are (likely)
>>> removed in release mode as part of the ordinary optimization
>>> passes. In the case where one has already asserted that
>>> `p + n < arr.len()`, then I would expect any index `arr[p + k]`
>>> to omit the bounds check, for k < n.
>>
>> That's exactly what I expected when I wrote my code the way I did. I
>> know that Java specifically handles this situation, lifting any array
>> bounds checking out of inner loops if possible.
>>
>> As that Godbolt link shows, my expectation was wrong.
>>
>> OTOH, for such a small program having 6 extra branches, none of them
>> ever taken, is not likely to add any cycles to the program latency since
>> current CPUs have more than enough issue ports to be able to handle
>> these branches while processing the real code.
>
> I thought it was worth a small experiment; here's a silly pair
> of functions:
Thanks for testing!
>
> ```rust
> #[inline(never)]
> pub fn sum_sub_array(arr: [u32; 4], k: usize) -> u32 {
> if k + 3 > arr.len() {
> return 0;
> }
> arr[k] + arr[k + 1] + arr[k + 2]
> }
>
> #[inline(never)]
> pub fn sum_sub_slice(sl: &[u32], k: usize) -> u32 {
> if k + 3 > sl.len() {
> return 0;
> }
> sl[k] + sl[k + 1] + sl[k + 2]
> }
> ```
>
> If I run these in such a way that they're not totally optimized
> away and do a release build, they generate the exact same code:
That's actually what I would expect, re my post about a read-only array
and ditto slice being the same.
>
> ```
> 0000000000015cb0 <rust_indices::sum_sub_array>:
> 15cb0: 31 c0 xor %eax,%eax
> 15cb2: 48 83 fe 01 cmp $0x1,%rsi
> 15cb6: 77 0b ja 15cc3 <rust_indices::sum_sub_array+0x13>
> 15cb8: 8b 44 b7 04 mov 0x4(%rdi,%rsi,4),%eax
> 15cbc: 03 04 b7 add (%rdi,%rsi,4),%eax
> 15cbf: 03 44 b7 08 add 0x8(%rdi,%rsi,4),%eax
> 15cc3: c3 ret
> 15cc4: cc int3
> ...
> 15ccf: cc int3
>
> 0000000000015cd0 <rust_indices::sum_sub_slice>:
> 15cd0: 31 c0 xor %eax,%eax
> 15cd2: 48 83 fe 01 cmp $0x1,%rsi
> 15cd6: 77 0b ja 15ce3 <rust_indices::sum_sub_slice+0x13>
> 15cd8: 8b 44 b7 04 mov 0x4(%rdi,%rsi,4),%eax
> 15cdc: 03 04 b7 add (%rdi,%rsi,4),%eax
> 15cdf: 03 44 b7 08 add 0x8(%rdi,%rsi,4),%eax
> 15ce3: c3 ret
> 15ce4: cc int3
> ...
> 15cef: cc int3
> ```
>
> Perhaps it's something about the complexity of your function
> that exceed some sort of threshold for the optimizer.
>
Quite possibly so...
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-07 16:49 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <QfyxS.548$cMed.68@fx10.iad> |
| In reply to | #118515 |
On 2026-Oct-07 15:25, Michael S wrote: > https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access Does Rust allow zero length arrays, vectors, strings and slices? Ada calls these a null slice. In DEC Fortran 77 a zero length slice was a bounds check error, which was really irritating because in string manipulation they happen a lot. If so, how does one specify a null slice in Rust? I couldn't find any definition in that doc.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-07 22:13 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <A%CxS.2342$kpNb.464@fx16.iad> |
| In reply to | #118522 |
On 2026-Oct-07 16:49, EricP wrote: > On 2026-Oct-07 15:25, Michael S wrote: >> https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access > > Does Rust allow zero length arrays, vectors, strings and slices? > Ada calls these a null slice. > In DEC Fortran 77 a zero length slice was a bounds check error, > which was really irritating because in string manipulation they happen a lot. > If so, how does one specify a null slice in Rust? > I couldn't find any definition in that doc. > > I asked the Google AI "does programming language rust support zero length array slices" and it said: Yes, Rust fully supports zero-length (empty) array slices. A slice in Rust ([T]) represents a dynamically-sized view into a contiguous sequence of elements. Because the length is evaluated at runtime, a slice can safely have a length of 0. How to Create an Empty Slice You can create or obtain a zero-length slice in Rust in several ways: From an empty array or vector: let empty_array: [i32; 0] = []; let slice: &[i32] = &empty_array; // A zero-length slice Using a range that yields no elements: let numbers = [1, 2, 3, 4]; let empty_slice = &numbers[2..2]; // Length is 0 Directly via standard library constants: let empty_slice: &[i32] = &[]; Memory Layout of a Zero-Length Slice Under the hood, a slice reference (&[T]) is a fat pointer consisting of two components: 1. A pointer to the data. 2. The length of the slice (usize). For a zero-length slice, the length component is 0. To avoid using a null pointer (which Rust references cannot be), the data pointer component points to a well-aligned, non-null "dangling" pointer address (specifically NonNull::dangling()), making it completely safe and overhead-free.
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-10-08 05:46 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a7aoa$3hibk$1@dont-email.me> |
| In reply to | #118522 |
EricP <ThatWouldBeTelling@thevillage.com> schrieb: > On 2026-Oct-07 15:25, Michael S wrote: >> https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access > > Does Rust allow zero length arrays, vectors, strings and slices? > Ada calls these a null slice. > In DEC Fortran 77 a zero length slice was a bounds check error, Modern Fortran does allow it, and yes, it is very convenient. -- This USENET posting was made without artificial intelligence, artificial impertinence, artificial arrogance, artificial stupidity, artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2026-10-08 12:05 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jbPxS.600$MBQb.166@fx08.iad> |
| In reply to | #118515 |
On 2026-Oct-07 15:25, Michael S wrote: > On Mon, 5 Oct 2026 11:36:59 -0000 (UTC) > cross@spitfire.i.gajendra.net (Dan Cross) wrote: > >> In article <86h5j5pky9.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>> >>>> Tim Rentsch wrote: >>>> >>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes: >>>>> >>>>>> Tim Rentsch wrote: >>> [...] >>>>>>> I favor a type equivalent to size_t for use as array index >>>>>>> variables. >>>>>> >>>>>> In Rust, the only acceptable array index is of type "usize", >>>>>> which is effectively the same as u64 on most platforms these >>>>>> days, but does not need to be so: On a 32-bit target, it would >>>>>> be the same as u32. >>>>>> >>>>>> So effectively very similar to size_t. >>>>> >>>>> Maybe that limitation works okay in Rust. In C sometimes it's >>>>> important to allow a signed value for indexing. Probably 99% of >>>>> the time size_t is good, but not always. >>>> >>>> The fact that array indices are unsigned is one of the more crucial >>>> underpinnings of Rust safety. Even more importantly, all such >>>> indices are verified against the actual array upper boundary. >>>> [...] >>> >>> It's nice that array index values are checked against the array >>> bounds. >> >> Terje was actually incorrect here; bounds checks are added in >> debug mode, but are (usually) removed in optimized builds. >> > > Are you sure? > Methinks The Book states otherwise: > https://doc.rust-lang.org/book/ch03-02-data-types.html?highlight=array#invalid-array-element-access The reference is less see-spot-run https://doc.rust-lang.org/stable/reference/ Looking at the rules for type casting: https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html#numeric-cast Some initial thoughts: There are no value range checks between cast types, just bit-wise reinterpretation to the new type with possible sign/zero extension or truncation for size change. They don't define the order in which those two operations, type and size change, occur. If one casts an i8 into a u16 it doesn't say whether the value is sign extended to i16 first then type changed to u16, or type changed to u8 first then zero extended to u16. Since an array index is defined as type usize, if the index expression is signed then it will be bit-wise reinterpreted as unsigned, and possibly turn a negative value into a large positive usize value. If bounds checks are disabled for production builds then you get exactly the same array overflow as in C.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-10-08 22:55 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <11a9704$ruu$1@reader2.panix.com> |
| In reply to | #118526 |
In article <jbPxS.600$MBQb.166@fx08.iad>,
EricP <ThatWouldBeTelling@thevillage.com> wrote:
>[snip]
>The reference is less see-spot-run
>
>https://doc.rust-lang.org/stable/reference/
>
>Looking at the rules for type casting:
>
>https://doc.rust-lang.org/stable/reference/expressions/operator-expr.html#numeric-cast
>
>Some initial thoughts:
>
>There are no value range checks between cast types, just bit-wise reinterpretation
>to the new type with possible sign/zero extension or truncation for size change.
>
>They don't define the order in which those two operations, type and size change, occur.
>If one casts an i8 into a u16 it doesn't say whether the value is sign extended
>to i16 first then type changed to u16, or type changed to u8 first then zero
>extended to u16.
They do, but it requires looking at _two_ rules from that list.
The first,
|Casting between two integers of the same size (e.g. i32 -> u32)
|is a no-op (Rust uses 2’s complement for negative values of
|fixed integers)
and the third,
|Casting from a smaller integer to a larger integer (e.g. u8 ->
|u32) will
|
| * zero-extend if the source is unsigned
| * sign-extend if the source is signed
Note that the second of these, the third rule on the list,
mentions sign extension if the _source_ type is signed; the
signedness of the destination is not relevant.
Taken together, these imply that the source will be
sign-extended and then the conversion to unsigned will be
treated as a noop: rule #1 does not apply first because it is
specific to conversions between sign/unsigned integers of the
_same width_; so we start with rule #3, sign-extend, and _then_
we may apply rule #1.
For a negative value of a source type that is smaller than an
unsigned destination type, the result will be an unsigned value
in the upper half of the destination type's range.
term% cat cast.rs
fn main() {
let n: i8 = -2;
println!("-2 as u16 = {}", n as u16);
}
term% rustc cast.rs
term% ./cast
-2 as u16 = 65534
term%
If you wanted to force specific behavior, you could use multiple
casts (e.g., `n as u8 as u16`).
>Since an array index is defined as type usize, if the index expression
>is signed then it will be bit-wise reinterpreted as unsigned,
No, if the index expression is signed, it will be a compile-time
error since usize is, by definiton, unsigned, and usize is the
only permissible index type. Rust is statically typed, and
there are no implicit conversions that factor here.
>and possibly turn a negative value into a large positive usize
>value.
In order for this to happen, one would have to use an explicit
cast to make the negative value a `usize` first.
A fair followup question is, "suppose I do a comparison against
a signed type, but don't account for zero, and then convert it
to usize; could the optimizer remove the bounds checks?" For
example, this:
```rust
#[inline(never)]
pub fn get_a_number(k: i32) -> i32 {
const ARR: [i32; 10] = [500, 1, 200, 3, 410, 5, 37, 7, 8, -5];
if k < 10 { ARR[k as usize] } else { 0 }
}
```
When built with optimization enabled and linked with a simple
driver, panic's at runtime trying to use a negative value cast
to a (large) positive value as an index. On the other hand, if
I modify it to check the lower bound on the array, that is
optimized away. So this version,
```rust
#[inline(never)]
pub fn get_a_number(k: i32) -> i32 {
const ARR: [i32; 10] = [500, 1, 200, 3, 410, 5, 37, 7, 8, -5];
if 0 <= k && k < 10 { ARR[k as usize] } else { 0 }
}
```
yields this object code on x86_64:
```
0000000000014ad0 <rbounds::get_a_number>:
14ad0: 31 c0 xor %eax,%eax
14ad2: 83 ff 0a cmp $0xa,%edi
14ad5: 73 0c jae 14ae3 <rbounds::get_a_number+0x13>
14ad7: 89 f8 mov %edi,%eax
14ad9: 48 8d 0d 04 19 ff ff lea -0xe6fc(%rip),%rcx # 63e4 <__abi_tag+0x60e8>
14ae0: 8b 04 81 mov (%rcx,%rax,4),%eax
14ae3: c3 ret
14ae4: cc int3
...
14aef: cc int3
```
>If bounds checks are disabled for
>production builds then you get exactly the same array overflow as in C.
See above.
- Dan C.
[toc] | [prev] | [next] | [standalone]
Page 17 of 24 — ← Prev page 1 … 15 16 [17] 18 19 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web