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 9 of 24 — ← Prev page 1 … 7 8 [9] 10 11 … 24 Next page →
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2026-09-14 16:24 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118902c$1jllu$1@dont-email.me> |
| In reply to | #117969 |
George Neuner wrote: > On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > >> George Neuner <gneuner2@comcast.net> writes: >> >> >>> Witness the proliferation of languages offering "managed environments" >>> offering such niceties as automatic storage management, automatic lock >>> handling (serialized object access), "comprehensions", etc., and large >>> standard libraries >> >> I don't see any problem with that. These features help to implement >> functionality in less programming time (and with less maintenance >> time) than without using these features, and that's true for >> programmers at any competence level. >> >>> without which the average programmer largely >>> would be incapable of producing a working program. >> >> That's pure elitism. > > Really? That's not my conclusion ... it was the result found by a > number of university studies and developer surveys. > > > Most studies involving GC have shown that programmers working on short > timelines are less likely to produce a correct [or sometimes even just > complete] program using manual memory management vs using GC. I have written multi-threaded programs since at least 1992 or so, preferably using LOCK XADD as the only synch mechanism, and I still get it wrong so often that for my latest effort in this area, I decided to go all the way to the file system: Every thread works on a completely separate set of input and output files, can optionally send progress reports back via UDP packets. This model is so very, very simple that I feel confident I'm not messing it up. :-) Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-15 06:34 -0700 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <867bkmwsd5.fsf@linuxsc.com> |
| In reply to | #117969 |
George Neuner <gneuner2@comcast.net> writes: > On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at > (Anton Ertl) wrote: > >> George Neuner <gneuner2@comcast.net> writes: >> >> >>> Witness the proliferation of languages offering "managed environments" >>> offering such niceties as automatic storage management, automatic lock >>> handling (serialized object access), "comprehensions", etc., and large >>> standard libraries >> >> I don't see any problem with that. These features help to implement >> functionality in less programming time (and with less maintenance >> time) than without using these features, and that's true for >> programmers at any competence level. >> >>> without which the average programmer largely >>> would be incapable of producing a working program. >> >> That's pure elitism. > > Really? That's not my conclusion ... it was the result found by a > number of university studies and developer surveys. > > > Most studies involving GC have shown that programmers working on short > timelines are less likely to produce a correct [or sometimes even just > complete] program using manual memory management vs using GC. Yeah. The studies I'm aware of that try to measure such things show not having to do manual memory management gives a productivity improvement of somewhere between 50 and 100 percent.
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-09-12 17:15 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <6aa5876f.783937@news.eternal-september.org> |
| In reply to | #117947 |
On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >George Neuner <gneuner2@comcast.net> writes: >>On Thu, 10 Sep 2026 17:22:37 GMT, anton@mips.complang.tuwien.ac.at >>(Anton Ertl) wrote: >>>However, I have seem many cases where people made a claim that >>>compilers generate better code than programmers. >>"compilers generate better code than MOST programmers." >>The qualification is important. >The statements I have read did not make such a qualification, >certainly not in capital letters. >>There is no doubt that a good >>programmer can beat the compiler, >And especially this statement is usually not made. On the contrary, >the perpetrator of such statements seem convinced of compiler >supremacy. I have no doubt that a good programmer can beat the original FORTRAN compiler for the IBM 704 computer, despite the fact that its optimization was very nearly as good as that of most optimizing compilers until at least the late 1970s. I would not, however, be willing to assert that one could easily find human programmers who could beat an optimizing compiler... which had the Itanium as its target. I don't believe that there are any other current architectures out there which are as nightmarish to program in assembler as the Itanium, but given the improvements in optimizing compilers, and the advances in modern computer architectures, I would still be hesitant to be categorical in asserting the human can always beat the optimizing compiler. Particularly given recent advances in AI. John Savard
[toc] | [prev] | [next] | [standalone]
| From | jgd@cix.co.uk (John Dallman) |
|---|---|
| Date | 2026-09-12 19:13 +0100 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <memo.20260912191341.8752C@jgd.cix.co.uk> |
| In reply to | #117981 |
In article <6aa5876f.783937@news.eternal-september.org>, quadibloc@invalid.com (John Savard) wrote: > I would not, however, be willing to assert that one could easily > find human programmers who could beat an optimizing compiler... > which had the Itanium as its target. It was claimed at the time that Itanium assembler was quite nice to write, once you had wrapped your head around some of its weird idioms. Of course, that was a lot easier if you were writing something that had been considered during the ISA design. Intel in the late 1990s had a period of transplanting supercomputer idioms into their ISAs, without fully understanding that those idioms were only useful for particular kinds of code. The Pentium 4, like the Itanium, wasn't very good at general-purpose code. The main gain I got from it was reduced dependency between floating-point operations once FP registers weren't organised as a stack. That allowed OoO to work better. John
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-12 18:14 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <2026Sep12.201446@mips.complang.tuwien.ac.at> |
| In reply to | #117981 |
quadibloc@invalid.com (John Savard) writes: >On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at >(Anton Ertl) wrote: >I would not, however, be willing to assert that one could easily find >human programmers who could beat an optimizing compiler... which had >the Itanium as its target. On the contrary: The IA-64 architects sold their architecture to Intel and HP management with hand-written examples that made good use of the hardware resources, and the promise that they would write compilers that could produce just as good code across the board. Those compilers failed to appear, and that's a big part of why IA-64 failed. So compilers are obviously not as good as humans on IA-64 code. >but given the improvements in optimizing compilers, and the advances >in modern computer architectures, I would still be hesitant to be >categorical in asserting the human can always beat the optimizing >compiler. I have used the traveling salesman program from Jon Bentley's 1982 book "Writing efficient programs" in my "Efficient programs" course since the late 1990s, including most of the optimizations that Jon Bentley has made to the source code, always with a relatively recent compiler. If the compilers would perform the optimizations that Jon Bentley performed in 1982, one would not see any change from his source-level optimizations. But actually the only one of Jon Bentley's source-level optimizations that did not result in a change, even with the latest gcc or clang I tried is function inlining. All 6 or 7 other source-level optimization steps by Jon Bentley resulted in a change in the resulting code and performance, more than 40 years after the book appeared. Or, consider the Racket 8.6 integer addition example in <2026Sep11.125438@mips.complang.tuwien.ac.at>, where I got the common case from 10 instructions down to 4 with a source-level optimization. If compilers were as great as you believe, the compiler would manage to perform this optimization by itself. >Particularly given recent advances in AI. What about them? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | quadibloc@invalid.com (John Savard) |
|---|---|
| Date | 2026-09-13 03:28 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <6aa6172e.15711625@news.eternal-september.org> |
| In reply to | #117986 |
On Sat, 12 Sep 2026 18:14:46 GMT, anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote: >quadibloc@invalid.com (John Savard) writes: >>On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at >>(Anton Ertl) wrote: >>I would not, however, be willing to assert that one could easily find >>human programmers who could beat an optimizing compiler... which had >>the Itanium as its target. >On the contrary: The IA-64 architects sold their architecture to Intel >and HP management with hand-written examples that made good use of the >hardware resources, and the promise that they would write compilers >that could produce just as good code across the board. Those >compilers failed to appear, and that's a big part of why IA-64 failed. >So compilers are obviously not as good as humans on IA-64 code. While this suggests that I was wrong about this, I must admit, I don't think that it proves the case. The compilers could have failed to appear for any number of reasons. And later on, Open64 appeared. John Savard
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-13 14:27 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <2026Sep13.162747@mips.complang.tuwien.ac.at> |
| In reply to | #117989 |
quadibloc@invalid.com (John Savard) writes: >On Sat, 12 Sep 2026 18:14:46 GMT, anton@mips.complang.tuwien.ac.at >(Anton Ertl) wrote: > >>quadibloc@invalid.com (John Savard) writes: >>>On Fri, 11 Sep 2026 06:33:21 GMT, anton@mips.complang.tuwien.ac.at >>>(Anton Ertl) wrote: > >>>I would not, however, be willing to assert that one could easily find >>>human programmers who could beat an optimizing compiler... which had >>>the Itanium as its target. > >>On the contrary: The IA-64 architects sold their architecture to Intel >>and HP management with hand-written examples that made good use of the >>hardware resources, and the promise that they would write compilers >>that could produce just as good code across the board. Those >>compilers failed to appear, and that's a big part of why IA-64 failed. >>So compilers are obviously not as good as humans on IA-64 code. > >While this suggests that I was wrong about this, I must admit, I don't >think that it proves the case. The compilers could have failed to >appear for any number of reasons. Such as what? It's not as if they did not try. >And later on, Open64 appeared. Later on? Open64 was first released in 2002, and its final release was on November 10, 2011 (couldn't they make it 2011-11-11?-). The compilers that were intended to make IA-64 competetive have never appeared, and Open64 has not changed that. However, concerning my statement above, I think the IA-64 architects used examples for which the architecture (and its in-order implementation) was particularly well-suited (software-pipelinable inner loops), and that compilers eventually usually worked ok for such examples, too. It's just that these compilers don't work so well on general-purpose code. But in any case, the fact that the architects sold their architecture with hand-written, not compiler-generated code shows that humans can write such code, and that it is not so easy to make a compiler do so. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2026-09-13 14:58 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <1186dm7$1idi$2@gal.iecc.com> |
| In reply to | #117990 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >However, concerning my statement above, I think the IA-64 architects >used examples for which the architecture (and its in-order >implementation) was particularly well-suited (software-pipelinable >inner loops), and that compilers eventually usually worked ok for such >examples, too. It's just that these compilers don't work so well on >general-purpose code. That's one of the problems that Multiflow also had, works great if you can predict the access patterns, a lot less great if the access patterns are data dependent. They also underestimated how fast out-of-order implementations would advance which handle data dependent access patterns just fine. -- 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 | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-13 16:09 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <2026Sep13.180951@mips.complang.tuwien.ac.at> |
| In reply to | #117991 |
John Levine <johnl@taugh.com> writes:
>They also underestimated how fast out-of-order implementations would advance
>which handle data dependent access patterns just fine.
OoO has a number of benefits over the EPIC (explicitly parallel
instruction computing) approach of IA-64. I have the impression that
this is not well known even among high-profile computer architects.
In particular, in Hennessy and Patterson's computer architecture book,
they 1) explain the advantage of OoO only with supporting more
in-flight cache misses; and 2) only give a very superficial
description of OoO microarchitectures. My impression is that they
lost interest in processor cores after the RISC revolution, and now
prefer to write more about multiprocessor interconnects and such.
As for the advance of OoO, hardware branch prediction (essential for
general-purpose code) had advanced beyond the capabilities of compiler
branch prediction (which compiler-based speculation supported by EPIC
was planned to rely on) in 1991 or so, so EPIC was at a disadvantage
there. Intel also knew that they designed the Pentium 4 (released
2000) with a 128-entry reorder buffer. And looking at SPEC CINT 2000,
despite their huge caches, IA-64 implementations never outdid
contemporaneous IA-32 or AMD64 implementations:
System Cint CFP
res base res base CPU Tested Published
Intel D850GB 656 640 714 704 Pentium 4 2000MHz Aug-2001 Sep-2001
hp rx4610 --- 379 715 715 Intel Itanium 800MHz Aug-2001 Sep-2001
Dell Precision WS 340 922 893 901 878 Pentium 4 2533MHz May-2002 Jun-2002
hp workstation zx6000 --- 807 1356 1356 Itanium 2 1000Mhz Jul-2002 Jul-2002
IA-64 implementations were good at CFP, at least initially, though.
Intel should have been aware of the Pentium 4's capabilities early on.
- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-13 17:38 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <1789321090-5857@newsgrouper.org> |
| In reply to | #117992 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > John Levine <johnl@taugh.com> writes: > >They also underestimated how fast out-of-order implementations would advance > >which handle data dependent access patterns just fine. > > OoO has a number of benefits over the EPIC (explicitly parallel > instruction computing) approach of IA-64. I have the impression that > this is not well known even among high-profile computer architects. > > In particular, in Hennessy and Patterson's computer architecture book, > they 1) explain the advantage of OoO only with supporting more > in-flight cache misses; and 2) only give a very superficial > description of OoO microarchitectures. My impression is that they > lost interest in processor cores after the RISC revolution, and now > prefer to write more about multiprocessor interconnects and such. > > As for the advance of OoO, hardware branch prediction (essential for > general-purpose code) had advanced beyond the capabilities of compiler > branch prediction (which compiler-based speculation supported by EPIC > was planned to rely on) in 1991 or so, so EPIC was at a disadvantage > there. Intel also knew that they designed the Pentium 4 (released > 2000) with a 128-entry reorder buffer. And looking at SPEC CINT 2000, > despite their huge caches, IA-64 implementations never outdid > contemporaneous IA-32 or AMD64 implementations: > > System Cint CFP > res base res base CPU Tested Published > Intel D850GB 656 640 714 704 Pentium 4 2000MHz Aug-2001 Sep-2001 > hp rx4610 --- 379 715 715 Intel Itanium 800MHz Aug-2001 Sep-2001 > Dell Precision WS 340 922 893 901 878 Pentium 4 2533MHz May-2002 Jun-2002 > hp workstation zx6000 --- 807 1356 1356 Itanium 2 1000Mhz Jul-2002 Jul-2002 > > IA-64 implementations were good at CFP, at least initially, though. It had 2× the number of pins for DRAM than P4. That goes a long way in SpecFP (way back when on-die cache was constrained...) > Intel should have been aware of the Pentium 4's capabilities early on. > > - anton
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-13 17:34 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <1789320867-5857@newsgrouper.org> |
| In reply to | #117991 |
John Levine <johnl@taugh.com> posted: > According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: > >However, concerning my statement above, I think the IA-64 architects > >used examples for which the architecture (and its in-order > >implementation) was particularly well-suited (software-pipelinable > >inner loops), and that compilers eventually usually worked ok for such > >examples, too. It's just that these compilers don't work so well on > >general-purpose code. > > That's one of the problems that Multiflow also had, works great if you > can predict the access patterns, a lot less great if the access patterns > are data dependent. I believe that this will always be the case for memory references. When striding through memory accessing doublewords 1 cache miss serves 8 LDDs 7 get hits 1 takes a miss. How does one software schedule for that pattern ?? On the other hand this is the planned pattern making Reservation Stations (dispatch stacks, and scoreboards) near optimal. SW has to do nothing to get the most out of the core !! > They also underestimated how fast out-of-order implementations would advance > which handle data dependent access patterns just fine. Pentium Pro should have given them a good clue.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-14 14:43 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <kKTpS.4356$Pwy8.3327@fx36.iad> |
| In reply to | #117995 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >John Levine <johnl@taugh.com> posted: > >> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >> >However, concerning my statement above, I think the IA-64 architects >> >used examples for which the architecture (and its in-order >> >implementation) was particularly well-suited (software-pipelinable >> >inner loops), and that compilers eventually usually worked ok for such >> >examples, too. It's just that these compilers don't work so well on >> >general-purpose code. >> >> That's one of the problems that Multiflow also had, works great if you >> can predict the access patterns, a lot less great if the access patterns >> are data dependent. > >I believe that this will always be the case for memory references. >When striding through memory accessing doublewords 1 cache miss >serves 8 LDDs 7 get hits 1 takes a miss. How does one software >schedule for that pattern ?? Don't use cache :-) There are several startups working on dense (10x or more) SRAM implementations with 1ns access times as an HBM replacement. With 1ns latency, who needs cache?
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-14 15:44 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <2026Sep14.174457@mips.complang.tuwien.ac.at> |
| In reply to | #118006 |
scott@slp53.sl.home (Scott Lurndal) writes: >There are several startups working on dense (10x or more) SRAM >implementations with 1ns access times as an HBM replacement. > >With 1ns latency, who needs cache? Only L1 caches have 1ns access latency, not even per-core L2 caches. There is no way a large memory will provide 1ns latency, not to one core, and certainly not to multiple cores. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-14 18:01 +0000 |
| Subject | Re: Optimization by programmers (was: Styles of addressing) |
| Message-ID | <1789408912-5857@newsgrouper.org> |
| In reply to | #118006 |
scott@slp53.sl.home (Scott Lurndal) posted:
> MitchAlsup <user5857@newsgrouper.org.invalid> writes:
> >
> >John Levine <johnl@taugh.com> posted:
> >
> >> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
> >> >However, concerning my statement above, I think the IA-64 architects
> >> >used examples for which the architecture (and its in-order
> >> >implementation) was particularly well-suited (software-pipelinable
> >> >inner loops), and that compilers eventually usually worked ok for such
> >> >examples, too. It's just that these compilers don't work so well on
> >> >general-purpose code.
> >>
> >> That's one of the problems that Multiflow also had, works great if you
> >> can predict the access patterns, a lot less great if the access patterns
> >> are data dependent.
> >
> >I believe that this will always be the case for memory references.
> >When striding through memory accessing doublewords 1 cache miss
> >serves 8 LDDs 7 get hits 1 takes a miss. How does one software
> >schedule for that pattern ??
>
> Don't use cache :-)
{derisively::} Riigghhtt
> There are several startups working on dense (10x or more) SRAM
> implementations with 1ns access times as an HBM replacement.
Pin to pin--that is address/command in makes setup time to pin on
HBC, and 1 ns later, data makes set up time of requesting chip ??
{{Oh, BTW, this gives the SRAM only 300ps to be accessed.......}}
> With 1ns latency, who needs cache
1ns is 5 clocks, which is about what the GBOoO chips at 5GHz are
running WITH L1 caches.
The issue with this thinking--is that it will take more than 1s
to get from a core's AGEN unit to the pins of the die, and more
than another 1ns for the incoming data to traverse the path in
the opposite direction. Here, you have already tripled perceived
latency; and have taken no account of other core's interfering
with this access.
I am sensitive to this because of the 68010 loop buffer, and the
68020 cache--both were just big enough to let the fetch side and
the data side of the processors to minimize interference to each
other.
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-16 13:14 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118h4cj$fi2a$1@dont-email.me> |
| In reply to | #117990 |
On 9/13/26 10:27 AM, Anton Ertl wrote: [snip] > However, concerning my statement above, I think the IA-64 architects > used examples for which the architecture (and its in-order > implementation) was particularly well-suited (software-pipelinable > inner loops), and that compilers eventually usually worked ok for such > examples, too. It's just that these compilers don't work so well on > general-purpose code. > > But in any case, the fact that the architects sold their architecture > with hand-written, not compiler-generated code shows that humans can > write such code, and that it is not so easy to make a compiler do so. It is not obvious to me that a human being able to generate good Itanium assembly from "30 lines of code" (quoting the Colwell oral history) is an indication that a compiler being able to do the same is nearly inconceivable. I generally agree that a compiler will not surpass the best performance of a supreme expert human programmer (for now). Even with the ability to perform algorithmic transformations and with knowledge of typical usage and hardware, the time/effort resources allocated to a compiler will be different. (I got the impression that C made structure arrangement difficult.) I suspect algorithmic transformations are discouraged in compilers under the assumption that the software developer used appropriate algorithms as well as the compute cost to evaluate options. Usage and hardware information might theoretically be made available, but I get the impression that most profiling for compiler use is about path frequency. I am guessing that effort (both compiler development and compilation computer resources) is a significant constraint. Dedicating three racks of servers to compile a module for a week seems unlikely to be attractive. Having half of the world's programmers working on compiler development also seems unlikely to be judged worthwhile. Human beings also seem to have a better information caching system. For a compiler modifying one variable name for clarity would (I think) typical force a recompilation, possibly of the whole program if whole program optimization is used, but a human would probably recognize the change as non-semantic. Some of the difficulties in developing a compiler superior to a human being in quality of generated code are quite substantial, but it seems that a well-engineered specialized machine should be able to outperform a human being even in an "intellectual" task. Expressing intent and not just mechanism in a programming language might facilitate some optimization as well as help with software maintenance. However, forcing programmers to write "compiler-friendly" programs seems unlikely to be attractive. Even maintenance-friendly software seems to have upfront costs that are too high to be considered worthwhile.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-17 16:47 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep17.184707@mips.complang.tuwien.ac.at> |
| In reply to | #118077 |
Paul Clayton <paaronclayton@gmail.com> writes: >I generally agree that a compiler will not surpass the best >performance of a supreme expert human programmer (for now). Take a look at Figure 1 of https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf There you see the performance from a compiler from 1997 (gcc-2.7.2.3, and gcc-2.7.0 actually appeared in 1995), from 1999 (egcs-1.1.2), and from 2015 (gcc-5.2.0, clang-3.5). You also see different compiler optimization levels (-O0, -O3 with various -f... options for defining behaviour that the 2015 compilers treat as undefined, and -O3 with as little language definition as the 2015 compilers use by default). And you see a sequence of manual optimizations, from tsp1 to tsp9, published by Jon Bentley in his 1982 book writing efficient programs; you can see the source code for these programs by following the links on <https://www.complang.tuwien.ac.at/anton/lvas/effizienz/tsp.html>. There you can see that the difference between the 1997 compiler and the 2015 compilers at -O3 is usually small. Has there been much progress since 2015? I doubt it. You can also see that the manual optimization steps bring vast improvements, far more than what the compilers have managed in these 18 years. One interesting case is the step from tsp4 to tsp5 (inlining of a function), which is flat for all the compilers, so all the compilers (from 1997 to 2015) do it by themselves; it is a prerequisite to following manual optimizations, so it cannot be left away in the manual optimization sequence. In the meantime I know that this program can be vectorized (and we have discussed manual vectorization at the assembly/intrinsic level here in 2016). I have tried getting recent gcc and clangs to vectorize it, and they certainly do not do it in an effective way for tsp1...tsp9. I have played around with transforming the program in a way that let's the auto-vectorization work, and have had some successes, but something else intervened when I was writing that up, so I do not have it in a form for public consumption. In any case, there is another factor of 3 or so in this program from manual changes that get "auto"-vectorization to work, but the "auto"-vectorization does not manage to do it automatically. And this is a simple program whose optimizations have been published in 1982. Admittedly, one of the steps changes what this program outputs, but that's one of the advantages human programmers have over compilers: They know the requirements, and can optimize to them, while the compiler only knows the source code, and has to treat it as a specification. >I am guessing that effort (both compiler development and >compilation computer resources) is a significant constraint. >Dedicating three racks of servers to compile a module for a week >seems unlikely to be attractive. The week would be a problem, throwing a lot of hardware at development has become pretty common in the last decade (e.g., continuous integration tests). >Having half of the world's >programmers working on compiler development also seems unlikely >to be judged worthwhile. Certainly not by me. My impression is that gcc and clang development has more developers thrown at it than is helpful for programmers. The devil finds work for idle hands to do, and in this case, it's elaborate "optimizations" based on the assumption that programs do not exercise undefined behaviour. There are other parts of development of these compilers that is beneficial, such as better error messages. >Human beings also seem to have a better information caching >system. For a compiler modifying one variable name for clarity >would (I think) typical force a recompilation, possibly of the >whole program if whole program optimization is used, but a human >would probably recognize the change as non-semantic. That case is actually easy to catch and deal with, it's just that it's not done. Other things in that vein, like ccache, seem to have fallen out of usage, at least I have not read about it for decades. >Some of the difficulties in developing a compiler superior to a >human being in quality of generated code are quite substantial, >but it seems that a well-engineered specialized machine should >be able to outperform a human being even in an "intellectual" >task. What makes you think so? And what do you mean with "specialized machine"? And what does this have to do with compilers? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | MitchAlsup <user5857@newsgrouper.org.invalid> |
|---|---|
| Date | 2026-09-17 19:38 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1789673881-5857@newsgrouper.org> |
| In reply to | #118080 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: > Paul Clayton <paaronclayton@gmail.com> writes: > >I generally agree that a compiler will not surpass the best > >performance of a supreme expert human programmer (for now). > > Take a look at Figure 1 of > > https://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf A good read... > There you see the performance from a compiler from 1997 (gcc-2.7.2.3, > and gcc-2.7.0 actually appeared in 1995), from 1999 (egcs-1.1.2), and > from 2015 (gcc-5.2.0, clang-3.5). You also see different compiler > optimization levels (-O0, -O3 with various -f... options for defining > behaviour that the 2015 compilers treat as undefined, and -O3 with as > little language definition as the 2015 compilers use by default). And > you see a sequence of manual optimizations, from tsp1 to tsp9, > published by Jon Bentley in his 1982 book writing efficient programs; > you can see the source code for these programs by following the links > on <https://www.complang.tuwien.ac.at/anton/lvas/effizienz/tsp.html>. > > There you can see that the difference between the 1997 compiler and > the 2015 compilers at -O3 is usually small. Has there been much > progress since 2015? I doubt it. > > You can also see that the manual optimization steps bring vast > improvements, far more than what the compilers have managed in these > 18 years. This is the "find a better algorithm" step of making programs fast. If one dives into LINPACK and LAPACK one finds FORTRAN code written in such a way that array-access-order is cache friendly. No compiler is ever going to do that automagically for general array code where the program specifies the indexing. However modern FORTRAN can use array-notation to free the compiler to create cache friendly algo- rythms. > One interesting case is the step from tsp4 to tsp5 > (inlining of a function), which is flat for all the compilers, so all > the compilers (from 1997 to 2015) do it by themselves; it is a > prerequisite to following manual optimizations, so it cannot be left > away in the manual optimization sequence. > > In the meantime I know that this program can be vectorized (and we > have discussed manual vectorization at the assembly/intrinsic level > here in 2016). I can't seem to find the source code ... I would like to try vectorizing with My 66000 ISA. ----------- > - anton
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-17 21:25 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep17.232554@mips.complang.tuwien.ac.at> |
| In reply to | #118081 |
MitchAlsup <user5857@newsgrouper.org.invalid> writes: > >anton@mips.complang.tuwien.ac.at (Anton Ertl) posted: >> And >> you see a sequence of manual optimizations, from tsp1 to tsp9, >> published by Jon Bentley in his 1982 book writing efficient programs; >> you can see the source code for these programs by following the links >> on <https://www.complang.tuwien.ac.at/anton/lvas/effizienz/tsp.html>. >> >> There you can see that the difference between the 1997 compiler and >> the 2015 compilers at -O3 is usually small. Has there been much >> progress since 2015? I doubt it. >> >> You can also see that the manual optimization steps bring vast >> improvements, far more than what the compilers have managed in these >> 18 years. > >This is the "find a better algorithm" step of making programs fast. tsp1..tsp9 all use the same algorithm: In the inner loop, look for a closest city to the one where the salesman currently is, and go there; yes, that's not a particularly good TSP algorithmand produces results that are not close to optimal, but it's the algorithm Bentley chose as running example for his book. >If one dives into LINPACK and LAPACK one finds FORTRAN code written >in such a way that array-access-order is cache friendly. No compiler >is ever going to do that automagically for general array code where >the program specifies the indexing. Matrix300 was eliminated from SPEC because all the computer companies started to use automatic cache blocking. IIRC this was for the step from SPEC89 to SPEC92. Later Sun managed to optimize IIRC the ear benchmark to perform array-of-structures to structure-of-arrays transformation, achieved a speedup by a factor of IIRC 2, and a significant increase in the aggregate SPEC score. If tsp1.c was a SPEC program, I am sure that the C compiler writers would find ways to optimize it to similar performance as tsp9, and further vectorize the code for even better performance. >> In the meantime I know that this program can be vectorized (and we >> have discussed manual vectorization at the assembly/intrinsic level >> here in 2016). > >I can't seem to find the source code ... I would like to try vectorizing >with My 66000 ISA. For the 2016 stuff, you can find versions from tspa.c to tspk.c on <https://www.complang.tuwien.ac.at/anton/lvas/effizienz/>. Note that these are not always derived from the version that is alhpabetically right before it, and some of the early ones are not vectorized at all, just attempts to get the compiler to vectorize it, which failed at the time. The first actually vectorized example is <https://www.complang.tuwien.ac.at/anton/lvas/effizienz/tspe.c> - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Paul Clayton <paaronclayton@gmail.com> |
|---|---|
| Date | 2026-09-21 22:10 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118ume7$15n8d$1@dont-email.me> |
| In reply to | #118084 |
On 9/17/26 5:25 PM, Anton Ertl wrote:
[snip]
> Matrix300 was eliminated from SPEC because all the computer companies
> started to use automatic cache blocking. IIRC this was for the step
> from SPEC89 to SPEC92.
I think I read that cache sizes were also a factor.
> Later Sun managed to optimize IIRC the ear
> benchmark to perform array-of-structures to structure-of-arrays
> transformation, achieved a speedup by a factor of IIRC 2, and a
> significant increase in the aggregate SPEC score.
I seem to recall that the (sub)benchmark was art. I got the
impression (possibly false) that the optimization was fragile
and strongly targeted to that specific benchmark. This is not
as extreme as GPU drivers changing optimizations for specific
game binaries. (Some such optimizations might be valid. If a
game uses a more general interface — for broader compatibility,
faster development, or easier extension — but a more specialized
(and faster) interface meets all requirements the GPU driver/
compiler could reasonably make that substitution. If the more
specialized interface is not published (e.g., to provide greater
future flexibility), the game developers could not use it even
if they were willing to sacrifice generality but having the
compiler/driver perform this optimization may be reasonable.
Yet using the program name to perform optimizations seems
sketchy.)
Side comment: One of the minor benefits proposed for Transmeta's
Code Morphing Software (converting x86 binaries to internal
VLIW) was the ability to work around timing limitations ("bugs")
in hardware. E.g., if a particular code sequence would fail
timing at peak frequency, binary translation could avoid that
case rather than force the hardware to be underclocked to
generally avoid that issue.
(I do not know how much of this would apply to a design with
dynamic scheduling. I also suspect that the advantage of
"fixing" hardware bugs in the binary translator was not that
great.)
Trusted binary translation and the fixed addressing of the
cached translations also allowed the removal of the instruction
TLB. If the translations had been persistently cached (like
AS/400 and the Mill proposal) and dynamic paging used, it
_might_ have been possible for relocation to be supported for
code and maintained the ability to avoid an instruction TLB.
(Azul Systems use huge pages for translation to facilitate
debugging even though, in theory, running JAVA applications
could be safe; compacting garbage collection might also have
reduced issues associated with huge pages. Such software-
hardware codesign does seem to have optimization potential.)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2026-09-18 16:38 -0400 |
| Subject | Re: Optimization by programmers |
| Message-ID | <jwva4peqp52.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #118077 |
Paul Clayton [2026-09-16 13:14:22] wrote: > I suspect algorithmic transformations are discouraged in > compilers under the assumption that the software developer used > appropriate algorithms as well as the compute cost to evaluate > options. Also because compilers generally can't (or at least shouldn't) take the chance of generating significantly slower code. The purpose of "language + compiler" is not to figure out magically how to implement the most efficient code that solves the same problem, instead it's to allow the programmer to write that most efficient code conveniently. Of course, there is a lot of commercial interest in doing the magic thing so as to save the work of understanding and rewriting the code to improve performance (hence all the work on auto-parallelization), but experience shows that it's an extremely difficult problem. Luckily, a lot of that work on trying to do the magic thing can also be used to solve the real problem: what the years of work on compiler-optimization has brought (instead of magically speeding up old code) is to improve the convenience to write efficient code. === Stefan
[toc] | [prev] | [next] | [standalone]
Page 9 of 24 — ← Prev page 1 … 7 8 [9] 10 11 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web