Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #111589 > unrolled thread
| Started by | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| First post | 2025-05-10 11:38 +0000 |
| Last post | 2025-05-20 18:31 -0700 |
| Articles | 20 on this page of 219 — 27 participants |
Back to article view | Back to comp.arch
Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-10 11:38 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-11 00:04 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-11 13:59 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Al Kossow <aek@bitsavers.org> - 2025-05-11 07:47 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-11 23:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-12 00:30 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 01:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-12 02:03 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Terje Mathisen <terje.mathisen@tmsw.no> - 2025-05-12 08:05 +0200
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-12 08:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-12 17:14 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-12 22:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-12 21:50 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-13 03:03 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-12 23:25 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 08:39 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-13 12:55 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-13 07:40 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-13 08:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 08:33 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-14 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-13 17:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-18 01:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-18 14:10 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-18 18:41 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Vir Campestris <vir.campestris@invalid.invalid> - 2025-05-19 21:46 +0100
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-19 14:58 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Vir Campestris <vir.campestris@invalid.invalid> - 2025-05-20 11:22 +0100
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-20 16:38 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-19 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-19 01:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-19 23:33 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 00:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 00:16 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-20 10:49 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 12:42 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 11:35 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:29 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 20:08 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:58 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 12:25 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 12:47 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-21 17:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-21 15:06 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-21 22:19 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 01:51 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Torbjorn Lindgren <tl@none.invalid> - 2025-05-22 12:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 12:39 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-22 18:36 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 13:20 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 14:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? jseigh <jseigh_es00@xemaps.com> - 2025-05-23 12:34 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 11:39 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-23 14:21 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 15:17 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-23 09:57 -0700
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 17:43 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 19:26 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-24 15:25 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 12:32 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-24 20:36 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Michael S <already5chosen@yahoo.com> - 2025-05-25 00:45 +0300
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 16:54 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Terje Mathisen <terje.mathisen@tmsw.no> - 2025-05-26 22:09 +0200
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-24 21:07 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 17:26 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-25 20:24 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-25 20:47 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-25 15:51 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-25 23:23 +0000
Re: recycling "Brian G. Lucas" <bagel99@gmail.com> - 2025-05-24 17:17 -0500
Re: recycling George Neuner <gneuner2@comcast.net> - 2025-05-25 02:24 -0400
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 10:53 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 17:03 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 12:34 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 00:38 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-24 16:57 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 14:24 -0500
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-30 09:20 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-24 20:38 +0000
Re: the power of junk, Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-24 16:45 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? cross@spitfire.i.gajendra.net (Dan Cross) - 2025-05-22 11:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 20:54 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 05:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-20 23:42 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-21 02:08 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 13:39 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:57 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-14 13:31 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-14 18:01 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-14 18:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Thomas Koenig <tkoenig@netcologne.de> - 2025-05-14 18:45 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-23 00:18 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 05:35 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 01:09 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 12:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-23 11:29 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-24 03:17 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-23 08:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-23 17:03 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-24 09:23 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-25 18:05 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-25 12:13 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-25 19:36 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-25 21:23 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-26 17:42 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 11:16 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-26 14:58 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-26 19:19 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 21:52 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-27 08:34 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-27 07:34 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-27 16:19 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-27 20:57 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-28 07:47 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-28 14:50 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 08:48 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 08:46 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:08 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 09:20 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:52 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 10:15 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 14:16 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 13:37 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-28 22:28 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-28 16:00 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 14:23 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-29 09:56 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-05-29 01:54 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-28 12:32 -0400
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 13:36 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:26 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 20:31 +0000
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 13:45 -0700
Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:24 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-25 19:16 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-25 16:27 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-26 03:01 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-25 23:58 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-26 15:36 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-26 20:14 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-26 07:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 07:31 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? antispam@fricas.org (Waldek Hebisch) - 2025-05-26 19:20 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 14:12 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 01:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-29 20:25 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 05:53 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-31 12:53 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? John Levine <johnl@taugh.com> - 2025-06-02 18:04 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-03 07:14 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-25 15:21 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 06:46 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Michael S <already5chosen@yahoo.com> - 2025-05-26 16:06 +0300
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 16:30 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 13:00 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 13:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 14:15 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 15:20 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 15:40 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 16:02 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-26 16:07 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-27 18:40 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:42 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-29 05:10 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 15:31 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Brett <ggtgp@yahoo.com> - 2025-05-30 01:17 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 15:33 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-27 12:28 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-26 23:12 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-26 23:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2025-05-26 19:00 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? David Brown <david.brown@hesbynett.no> - 2025-05-27 09:43 +0200
Drive Caches (Re: Is Parallel Programming Hard, ...) Lars Poulsen <lars@cleo.beagle-ears.com> - 2025-05-25 20:55 +0000
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-26 00:07 -0400
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) BGB <cr88192@gmail.com> - 2025-05-26 00:59 -0500
Re: Drive Caches (Re: Is Parallel Programming Hard, ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-26 07:13 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 22:19 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? EricP <ThatWouldBeTelling@thevillage.com> - 2025-05-23 20:51 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-17 23:57 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? quadibloc <quadibloc@gmail.com> - 2025-05-19 21:33 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 00:43 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 13:53 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? BGB <cr88192@gmail.com> - 2025-05-20 13:19 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-20 16:06 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-20 22:11 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? David Schultz <david.schultz@earthlink.net> - 2025-05-20 19:34 -0500
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:00 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-20 21:30 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:39 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:41 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-21 12:09 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-21 15:30 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:45 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lynn Wheeler <lynn@garlic.com> - 2025-05-21 07:06 -1000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? jseigh <jseigh_es00@xemaps.com> - 2025-05-21 17:32 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2025-05-21 07:05 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:48 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Stefan Monnier <monnier@iro.umontreal.ca> - 2025-05-21 08:23 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-21 14:08 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:49 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-22 17:34 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? scott@slp53.sl.home (Scott Lurndal) - 2025-05-22 17:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? mitchalsup@aol.com (MitchAlsup1) - 2025-05-23 01:54 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:42 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? George Neuner <gneuner2@comcast.net> - 2025-05-22 23:47 -0400
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:32 +0000
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:29 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-22 16:49 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-22 18:04 -0700
Re: Is Parallel Programming Hard, And, If So, What Can You Do About It? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-20 18:31 -0700
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-13 08:12 +0000 |
| Message-ID | <vvuuua$1mt7m$1@dont-email.me> |
| In reply to | #111606 |
On Tue, 13 May 2025 07:40:35 GMT, Anton Ertl wrote: > In this case the drive knows things that the OS does not: Consider that > the OS asked for sector N what happens when the arm finally has settled > enough to read from the track, and the first sector it sees is sector > N+10. The OS isn’t likely to ask for one sector at a time. It will use time- tested algorithms like scatter-read/gather-write and elevator seeking. This is why we have filesystem caches.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-13 08:33 -0700 |
| Message-ID | <vvvons$3uvs3$2@dont-email.me> |
| In reply to | #111607 |
On 5/13/2025 1:12 AM, Lawrence D'Oliveiro wrote: > On Tue, 13 May 2025 07:40:35 GMT, Anton Ertl wrote: > >> In this case the drive knows things that the OS does not: Consider that >> the OS asked for sector N what happens when the arm finally has settled >> enough to read from the track, and the first sector it sees is sector >> N+10. > > The OS isn’t likely to ask for one sector at a time. Frequently true, so consider this related scenario. The host requests a read of 10 sectors starting at sector N. When the head settles, the next sector is N+6. Without any in drive buffering, it would wait almost a full revolution till record N comes under the head. With buffering, but no cache, the drive reads record N+5 to N+9 into the buffer, then waits until the drive rotates to record N and begins the host transfer. This is an improvement because the transfer to the host is faster than the transfer from the disk, and the last 3 sectors can be transferred out of the buffer without waiting for the disk, so the transfer is completed faster. Now consider with caching. Similar, but after record N+9, the drive continues reading into the cache. Lets say there are 30 records on this track. If it reads all of the data into the cache, then proceeds as above once the disk rotates to record N, it has cost zero time, and if the host then issues another 10 sector read sequential to the initial one (or actually any sectors from N+10 to N+29). This can be satisfied out of the cache without any drive delay, so much faster than without the cache, and the heads can be moved away to start satisfying another unrelated request. There is minimal cost and substantial benefit. Now you have argued that the file system cache should take care of that, presumably issuing prefetch reads for the next sectors. This will work, of course, but has some disadvantages relative to using the drive cache. Specifically,since it is unlikely the prefetch request will be received by the drive before record N+10 has passed the heads, it will incur additional most of a rotational delay, which will tie up the drive, preventing it from responding to some other request. No one is arguing that host based file caches are bad. It is simply the fact that there are situations where drive caches are a useful addition, and since the drive has to have some DRAM anyway for other reasons, the cost is minimal. You can think of the drive cache as the "next level" cache behind the host based cache. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-14 00:18 +0000 |
| Message-ID | <1000nfp$2440u$1@dont-email.me> |
| In reply to | #111608 |
On Tue, 13 May 2025 08:33:15 -0700, Stephen Fuld wrote: > No one is arguing that host based file caches are bad. It is simply the > fact that there are situations where drive caches are a useful > addition ... You can tell that’s wrong because the drive cache is slower than the OS filesystem cache. Putting a slower cache in series with a faster one is a waste of time ... unless the slower cache is much larger. This is why, for example, we typically have 3 levels of RAM cache between the CPU and main memory these days. There is a factor of about 100:1 in relative speeds, so to bridge the gap we need multiple caches of various intermediate speeds, and you will notice their sizes are inversely related to their speeds. A drive cache can never be as big as main RAM on a modern PC. That’s why the drive cache is useless.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-13 17:49 -0700 |
| Message-ID | <1000pae$3uvs3$3@dont-email.me> |
| In reply to | #111612 |
On 5/13/2025 5:18 PM, Lawrence D'Oliveiro wrote: > On Tue, 13 May 2025 08:33:15 -0700, Stephen Fuld wrote: > >> No one is arguing that host based file caches are bad. It is simply the >> fact that there are situations where drive caches are a useful >> addition ... > > You can tell that’s wrong because the drive cache is slower than the OS > filesystem cache. I don't think that proves anything. I gave you an example of where the drive cache speeded up the sequence of two reads to where it was faster than two reads into the file cache. Putting a slower cache in series with a faster one is a > waste of time ... unless the slower cache is much larger. See my counter example posted earlier. > This is why, for example, we typically have 3 levels of RAM cache between > the CPU and main memory these days. There is a factor of about 100:1 in > relative speeds, so to bridge the gap we need multiple caches of various > intermediate speeds, and you will notice their sizes are inversely related > to their speeds. > > A drive cache can never be as big as main RAM on a modern PC. That’s why > the drive cache is useless. You haven't refuted my example, and besides the comparison you give here is not meaningful because you can't use all the main ram as a file cache. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-18 01:35 +0000 |
| Message-ID | <100bdhq$lhdb$3@dont-email.me> |
| In reply to | #111613 |
On Tue, 13 May 2025 17:49:17 -0700, Stephen Fuld wrote: > On 5/13/2025 5:18 PM, Lawrence D'Oliveiro wrote: > >> You can tell that’s wrong because the drive cache is slower than the OS >> filesystem cache. > > I don't think that proves anything. I gave you an example of where the > drive cache speeded up the sequence of two reads to where it was faster > than two reads into the file cache. Think of what a cache is for in the first place. The only reason they work is because of the “principle of locality”. This can also be expressed as saying that typical patterns of data access by application programs follow a Pareto distribution, less formally known by monikers like the “80/20 rule” or the “90/10 rule”. Let’s use the “90/10 rule” name just to put some concrete numbers on the whole idea: this says that 90% of (recent) data accesses will be to just 10% of the data. For “recent”, let’s say “within the last 10 seconds”. So the OS cache should be big enough to hold that 10% of the data that the app accessed in about the last 10 seconds. Of course the precise set of frequently- accessed data (the “working set”) will drift over time. So anything beyond this last-10-seconds’ worth will require hitting the actual disk device, which will happen eventually. At that point, the cache on the disk device is going to come into play. Trouble is it’s nowhere near this kind of size: it can only hold enough data for, say, about the last 1 second’s worth of accesses. So by the time the OS cache experiences a miss like this, the disk cache isn’t going to be able to help much, since it is more likely than not going to miss as well. To be useful, it needs to be about 10 times the size of the OS cache, so it can hold more of the 90% of the data that the app wants to access less frequently. But you can’t get drives like that.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-05-18 14:10 -1000 |
| Message-ID | <87sel1jw9z.fsf@localhost> |
| In reply to | #111623 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: > Think of what a cache is for in the first place. The only reason they work > is because of the “principle of locality”. This can also be expressed as > saying that typical patterns of data access by application programs follow > a Pareto distribution, less formally known by monikers like the “80/20 > rule” or the “90/10 rule”. IBM "added" full-track "-13" cache to 3880 dasd control for 3380 disk (ten records/track) ... claiming 90% "hit rate". Issue was that there was a lot of sequential file reading ... the 1st record read for track would be a "miss" but bring in the whole track, resulting in the next nine reads being "hits". system services offered option for application doing sequential i/o to specify full-track i/o (into processor memory) ... which would result in the zero hit rate for the controller cache (IBM standard batch operating system did contiguous allocation on file creation). About the same time, we did system mod. that did highly efficient trace/capture of every record operation which was deployed on numerous production systems. Then traces were fed to sophisticated simulator that could vary algorithms, caches, kinds of caches, sizes of caches, distribution of caches, etc. Given a fixed amount of cache storage, it was always better to have a global system cache ... than partitioned/distributed; except a few edge cases. Example, if device track cache could be used to immediately start transfering data, rather having to rotate to start of track before starting transfer. -- virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-18 18:41 -0700 |
| Message-ID | <100e28i$11n5t$1@dont-email.me> |
| In reply to | #111630 |
On 5/18/2025 5:10 PM, Lynn Wheeler wrote: > Lawrence D'Oliveiro <ldo@nz.invalid> writes: >> Think of what a cache is for in the first place. The only reason they work >> is because of the “principle of locality”. This can also be expressed as >> saying that typical patterns of data access by application programs follow >> a Pareto distribution, less formally known by monikers like the “80/20 >> rule” or the “90/10 rule”. > > IBM "added" full-track "-13" cache to 3880 dasd control for 3380 disk > (ten records/track) ... claiming 90% "hit rate". Issue was that there > was a lot of sequential file reading ... the 1st record read for track > would be a "miss" but bring in the whole track, resulting in the next > nine reads being "hits". > > system services offered option for application doing sequential i/o to > specify full-track i/o (into processor memory) ... which would result > in the zero hit rate for the controller cache (IBM standard batch > operating system did contiguous allocation on file creation). > > About the same time, we did system mod. that did highly efficient > trace/capture of every record operation which was deployed on numerous > production systems. Then traces were fed to sophisticated simulator that > could vary algorithms, caches, kinds of caches, sizes of caches, > distribution of caches, etc. > > Given a fixed amount of cache storage, it was always better to have a > global system cache ... than partitioned/distributed; except a few edge > cases. Example, if device track cache could be used to immediately > start transfering data, rather having to rotate to start of track before > starting transfer. It didn't make sense to, after executing the full track read, since the disk was positioned at the end of the track, and you had a good indication that it was a sequential file read, to start caching the next track in anticipation of the next full track read? -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2025-05-19 21:46 +0100 |
| Message-ID | <100g5an$1q32t$1@dont-email.me> |
| In reply to | #111634 |
On 19/05/2025 02:41, Stephen Fuld wrote: > > It didn't make sense to, after executing the full track read, since the > disk was positioned at the end of the track, and you had a good > indication that it was a sequential file read, to start caching the next > track in anticipation of the next full track read? It might if the disk was idle. But if there is a queue from another process it probably will be better to do that instead. Andy -- Do not listen to rumour, but, if you do, do not believe it. Ghandi.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-19 14:58 -0700 |
| Message-ID | <100g9ip$1otvf$1@dont-email.me> |
| In reply to | #111655 |
On 5/19/2025 1:46 PM, Vir Campestris wrote: > On 19/05/2025 02:41, Stephen Fuld wrote: >> >> It didn't make sense to, after executing the full track read, since >> the disk was positioned at the end of the track, and you had a good >> indication that it was a sequential file read, to start caching the >> next track in anticipation of the next full track read? > > It might if the disk was idle. But if there is a queue from another > process it probably will be better to do that instead. I presume you know that the 3880 controller did not do what today we call command queuing, so I think you were referring to a potential queue in the host. That being the case, the controller doesn't know if there is a queue or not. So given that, why not start reading record 1 on the next track. If a request comes in, you can abandon the read to service the request - no harm, no foul. If there isn't, and you subsequently get a request for that track, it's a big win. The only potential loss is if you get a request for the track that was LRU and got pushed out of the cache. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Vir Campestris <vir.campestris@invalid.invalid> |
|---|---|
| Date | 2025-05-20 11:22 +0100 |
| Message-ID | <100hl52$26e2p$1@dont-email.me> |
| In reply to | #111658 |
On 19/05/2025 22:58, Stephen Fuld wrote: > On 5/19/2025 1:46 PM, Vir Campestris wrote: >> On 19/05/2025 02:41, Stephen Fuld wrote: >>> >>> It didn't make sense to, after executing the full track read, since >>> the disk was positioned at the end of the track, and you had a good >>> indication that it was a sequential file read, to start caching the >>> next track in anticipation of the next full track read? >> >> It might if the disk was idle. But if there is a queue from another >> process it probably will be better to do that instead. > > I presume you know that the 3880 controller did not do what today we > call command queuing, so I think you were referring to a potential queue > in the host. That being the case, the controller doesn't know if there > is a queue or not. So given that, why not start reading record 1 on the > next track. If a request comes in, you can abandon the read to service > the request - no harm, no foul. If there isn't, and you subsequently > get a request for that track, it's a big win. The only potential loss > is if you get a request for the track that was LRU and got pushed out of > the cache. > > The only IBM machine I've ever even touch was a PC/XT - so no, I didn't know. That makes sense. My mainframe background goes back to the ICL 2900 at the beginning of the '80s. There were two families of disc controllers, one of which did clever stuff like retries for the host (I don't remember if it cached) and the other one was dumb and cheap. The dumb one was becoming more popular at the time when I discovered the realities of working in tech and had practice in CV writing... Andy -- Do not listen to rumour, but, if you do, do not believe it. Ghandi.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-05-20 16:38 -1000 |
| Message-ID | <877c2awuvs.fsf@localhost> |
| In reply to | #111658 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
> I presume you know that the 3880 controller did not do what today we
> call command queuing, so I think you were referring to a potential
> queue in the host. That being the case, the controller doesn't know
> if there is a queue or not. So given that, why not start reading
> record 1 on the next track. If a request comes in, you can abandon
> the read to service the request - no harm, no foul. If there isn't,
> and you subsequently get a request for that track, it's a big win.
> The only potential loss is if you get a request for the track that was
> LRU and got pushed out of the cache.
over optimizing full track read ahead could lock out other tasks that
had competing requirements for other parts of the disk.
trivia: early 70s, IBM decided to add virtual memory to all 370s. Early
last decade I was asked to tract down the decsion. I found staff member
to executive making the decision. Basically MVT (IBM's high end, major
batch system) storage management was so bad that (multiprogramming)
region sizes had to be specified four times larger than used, as a
result typical (high-end) 1mbyte 370/165 only ran four regions
concurrently, insufficient to keep system busy and justified. Running
MVT in a 16mbyte virtual address space (sort of like running MVT in CP67
16mbyte virtual machine) would allow concurrent regions to be increased
by factor of four times (caped at 15 because of 4bit storage protect
key) with little or no paging. Later as high-end systems got larger,
they needed more than 15 concurrent running regions ... and so switched
from VS2/SVS (single 16mbyte virtual address space) to VS2/MVS (a
separate 16mbyte virtual address space for each "region", went through
MVT->VS2/SVS->VS2/MVS)
along the way, I had been pontificating that DASD (disks) relative
system throughput has been decreasing ... in 1st part of 80s, I turned
out analysis that in the 15yr period since the IBM 360 1st ships,
DASD/disk relative system throughput had declined by an order of
magnitude (i.e. DASD got 4-5 times faster while systems got 40-50 times
faster). Some DASD division executive took exception and assigned the
division performance group to refute the claim ... after a few weeks,
they came back and bascially said I had slightly understated the
issue. The performance group then respun the analysis for user group
presenation on how to configure disks and filesystem to improve system
throughput (SHARE63, B874, 16Aug1984).
1970 IBM 2305 fixed-head disk controller supported 8 separate psuedo
device addresses ("multiple exposure") for each 2305 disk ... each
having channel program that the controller could optimize. In 1975, I
was asked to help enhance low-end 370 that had integrated channels and
integrated device controllers ... and I wanted to upgrade microcode so I
just update a queue of channel programs that the (integrated microcode)
controller could optimize (wasn't allowed to ship the product).
Later I wanted to add "multiple exposure" support to 3830 (precursor to
the 3880) for 3350 (moveable arm) disks (IBM east coast group was
working on emulated electronic memory disks, considered it might compete
and got it vetoed. sometime later they got shutdown, they were told IBM
was selling all electronic memory it could make as higher markup
processor memory).
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-20 20:49 -0700 |
| Message-ID | <100jig5$2fpju$1@dont-email.me> |
| In reply to | #111697 |
On 5/20/2025 7:38 PM, Lynn Wheeler wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> I presume you know that the 3880 controller did not do what today we >> call command queuing, so I think you were referring to a potential >> queue in the host. That being the case, the controller doesn't know >> if there is a queue or not. So given that, why not start reading >> record 1 on the next track. If a request comes in, you can abandon >> the read to service the request - no harm, no foul. If there isn't, >> and you subsequently get a request for that track, it's a big win. >> The only potential loss is if you get a request for the track that was >> LRU and got pushed out of the cache. > > over optimizing full track read ahead could lock out other tasks that > had competing requirements for other parts of the disk. Sure. That is why I asked if, with all the traces you had collected, you determined whether it was worthwhile to do it. snipped some stories. I just want to add that I, for one, enjoy your stories of your time with IBM, and all the internal struggles, both technological and "political" the company went through. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-19 00:18 +0000 |
| Message-ID | <91c8a31fc5d04a1fadf210b2dd6d4875@www.novabbs.org> |
| In reply to | #111623 |
On Sun, 18 May 2025 1:35:54 +0000, Lawrence D'Oliveiro wrote: > On Tue, 13 May 2025 17:49:17 -0700, Stephen Fuld wrote: > >> On 5/13/2025 5:18 PM, Lawrence D'Oliveiro wrote: >> >>> You can tell that’s wrong because the drive cache is slower than the OS >>> filesystem cache. >> >> I don't think that proves anything. I gave you an example of where the >> drive cache speeded up the sequence of two reads to where it was faster >> than two reads into the file cache. > > Think of what a cache is for in the first place. The only reason they > work > is because of the “principle of locality”. This can also be expressed as > saying that typical patterns of data access by application programs > follow > a Pareto distribution, less formally known by monikers like the “80/20 > rule” or the “90/10 rule”. > > Let’s use the “90/10 rule” name just to put some concrete numbers on the > whole idea: this says that 90% of (recent) data accesses will be to just > 10% of the data. > > For “recent”, let’s say “within the last 10 seconds”. Principle is reasonable, specified time is not. A 4MB cache can be filled in 1ms when memory performs at (only) 4GB/s (and the memory systems are up in the 40GB/s peak territory while caches remain rather small (several GB at most).) > So the OS cache > should be big enough to hold that 10% of the data that the app accessed > in > about the last 10 seconds. Of course the precise set of frequently- > accessed data (the “working set”) will drift over time. So anything > beyond > this last-10-seconds’ worth will require hitting the actual disk device, > which will happen eventually. Just change 10 seconds to 10 milliseconds and I have nothing to complain about. > At that point, the cache on the disk device is going to come into play. > Trouble is it’s nowhere near this kind of size: it can only hold enough > data for, say, about the last 1 second’s worth of accesses. So by the > time > the OS cache experiences a miss like this, the disk cache isn’t going to > be able to help much, since it is more likely than not going to miss as > well. To be useful, it needs to be about 10 times the size of the OS > cache, so it can hold more of the 90% of the data that the app wants to > access less frequently. > > But you can’t get drives like that.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-19 01:13 +0000 |
| Message-ID | <100e0it$19264$1@dont-email.me> |
| In reply to | #111631 |
On Mon, 19 May 2025 00:18:23 +0000, MitchAlsup1 wrote: > On Sun, 18 May 2025 1:35:54 +0000, Lawrence D'Oliveiro wrote: > >> For “recent”, let’s say “within the last 10 seconds”. > > Principle is reasonable, specified time is not. > > A 4MB cache can be filled in 1ms when memory performs at (only) 4GB/s > (and the memory systems are up in the 40GB/s peak territory while caches > remain rather small (several GB at most).) Filesystem cache turnover happens in times on the order of seconds, not milliseconds.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-19 23:33 +0000 |
| Message-ID | <fa7e33d953bc6f545387d862e19c2bd2@www.novabbs.org> |
| In reply to | #111633 |
On Mon, 19 May 2025 1:13:01 +0000, Lawrence D'Oliveiro wrote: > On Mon, 19 May 2025 00:18:23 +0000, MitchAlsup1 wrote: > >> On Sun, 18 May 2025 1:35:54 +0000, Lawrence D'Oliveiro wrote: >> >>> For “recent”, let’s say “within the last 10 seconds”. >> >> Principle is reasonable, specified time is not. >> >> A 4MB cache can be filled in 1ms when memory performs at (only) 4GB/s >> (and the memory systems are up in the 40GB/s peak territory while caches >> remain rather small (several GB at most).) > > Filesystem cache turnover happens in times on the order of seconds, not > milliseconds. Yes, running at the latency and bandwidth of the disk/SSD subsystem not of the DRAM system.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-20 00:36 +0000 |
| Message-ID | <100gipr$1sbnn$10@dont-email.me> |
| In reply to | #111659 |
On Mon, 19 May 2025 23:33:42 +0000, MitchAlsup1 wrote: > On Mon, 19 May 2025 1:13:01 +0000, Lawrence D'Oliveiro wrote: > >> Filesystem cache turnover happens in times on the order of seconds, not >> milliseconds. > > Yes, running at the latency and bandwidth of the disk/SSD subsystem not > of the DRAM system. It’s not really about latency, it’s just about the way the filesystem caches are used. They quite typically take up a big chunk of the RAM on a server, and stuff does tend to hang around in them for several seconds, to get good cache hits. (Though on Linux that’s considered a low-priority use, so if a regular application needs more RAM and there isn’t enough free, then the filesystem cache will be quickly flushed as necessary to make more available.) And consider that modern high-performance servers are available with terabytes of RAM. Fill a few tens of % of that with filesystem cache, and you see why disk caches don’t stand a chance.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-20 00:16 -0500 |
| Message-ID | <100h3jm$23ehu$1@dont-email.me> |
| In reply to | #111664 |
On 5/19/2025 7:36 PM, Lawrence D'Oliveiro wrote:
> On Mon, 19 May 2025 23:33:42 +0000, MitchAlsup1 wrote:
>
>> On Mon, 19 May 2025 1:13:01 +0000, Lawrence D'Oliveiro wrote:
>>
>>> Filesystem cache turnover happens in times on the order of seconds, not
>>> milliseconds.
>>
>> Yes, running at the latency and bandwidth of the disk/SSD subsystem not
>> of the DRAM system.
>
> It’s not really about latency, it’s just about the way the filesystem
> caches are used. They quite typically take up a big chunk of the RAM on a
> server, and stuff does tend to hang around in them for several seconds, to
> get good cache hits. (Though on Linux that’s considered a low-priority
> use, so if a regular application needs more RAM and there isn’t enough
> free, then the filesystem cache will be quickly flushed as necessary to
> make more available.)
>
> And consider that modern high-performance servers are available with
> terabytes of RAM. Fill a few tens of % of that with filesystem cache, and
> you see why disk caches don’t stand a chance.
The caches serve different purposes.
The OS side cache is to serve local IO requests.
The HDD cache is AFAIK more to consolidate IO requests and to prefetch
stuff, in a way where the HDD knows its geometry but the PC does not,
and to keep up the abstraction of 512 byte sectors on physical media
that is typically no longer using 512 byte sectors.
Across multiple media types, the abstractions have converged:
Linearly addressed array of 512 byte sectors.
Vs, say:
Cylinder/Head/Sector geometry;
Variable sector sizes and variable numbers of sectors per track;
Ability for the PC to not care if it is an HDD or SSD;
...
You need RAM to make this work, and a few MB of HDD side cache isn't a
huge cost if one would have already needed the same stuff to make the
HDD work.
At this point in time, would have a 512K RAM chip be cheaper than an 8
or 16MB RAM chip?... Not really.
Also the SATA interface is technically faster and has a higher bandwidth
than it can actually read stuff from the HDD itself, so if the HDD's
cache can do *anything* (in terms of prefetch and allowing IO requests
to be completed more quickly) it is still a win.
And, then, the filesystem can continue on operating in terms of an
abstract device without needing to be overly concerned with the physical
geometry of the underlying HDD.
Well, or sometimes, the filesystems try to be too clever and actually
make things worse.
Say, for example, if the FS tries to allocate files such that each
starts on a multiple of 32K (with a 4K cluster size), but then C source
files are often not so effective when spaced on multiples of 32K, and if
it goes back later and reclaims these intermediate clusters, then the
original files are not particularly densely packed, and a bunch of other
random files are shoved between, ... Leading to worse performance than
have the files simply been densely packed end-to-end in the first place.
Well, say, because the FS designers seem to casually assume smaller
numbers of multi-MB files, rather than people filling the drive with
millions of files most of which being kB sized.
Well, and if one has lots of files of this sort, often a 1K cluster size
makes sense as less space will be wasted on partial blocks (in the
absence of end-packing). But, then one also wants to have moderately
compact directory entries and inodes.
Say:
256 byte inode is good;
1024 byte inode (cough, "MFT Entry") is waste;
64 byte directory entry is good;
Like, ~ 95..99% of filenames do not exceed 48 characters.
Can special-case those that need more.
256 to 512 bytes is waste;
More so with the pointlessness of UTF-16 filenames.
Better to optimize for the 99% case here, IMO.
Vs, always provisioning for the worst case.
...
Though, does depend some on the relative cost though between constant
overhead data, and file payload.
...
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-20 10:49 -0400 |
| Message-ID | <jwv7c2bjqcx.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111666 |
> You need RAM to make this work, and a few MB of HDD side cache isn't a huge
> cost if one would have already needed the same stuff to make the HDD work.
Indeed, AFAIK, what we call "HDD cache" is actually just the RAM used
by the embedded CPU inside the drive for its operation.
I expect this is used to store the information about in-flight requests
(e.g. most importantly the data about the write requests received but
that haven't yet reached the platters), but I also expects it holds data
that happened to fly recently by the read-head, just in case.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-20 12:42 -0500 |
| Message-ID | <100ifa6$2b7vi$1@dont-email.me> |
| In reply to | #111673 |
On 5/20/2025 9:49 AM, Stefan Monnier wrote: >> You need RAM to make this work, and a few MB of HDD side cache isn't a huge >> cost if one would have already needed the same stuff to make the HDD work. > > Indeed, AFAIK, what we call "HDD cache" is actually just the RAM used > by the embedded CPU inside the drive for its operation. > I expect this is used to store the information about in-flight requests > (e.g. most importantly the data about the write requests received but > that haven't yet reached the platters), but I also expects it holds data > that happened to fly recently by the read-head, just in case. > Probably. As I understand it, it is this, along with a certain amount of "read prefetch", which is granted, typically the data for the rest of the track as the drive spins around; And, keeping some copies of previously read content around, which can be read again from this cache if they happen to be requested. As I understand it, also more modern HDDs tend to be "density per area" rather than angular slices (as it was on much older HDDs and floppies, *), so there would be more sectors on outer tracks vs on inner tracks. *: Though, IIRC, there were some oddball floppy drives / variants that did something similar, and could get significant improvements in capacity while still using the same (or similar) physical media (although, incompatible with more normal floppy drives). Eg: apparently things like LS-120 drives with 32MB on a 3.5" floppy sort of things, vs more on its specialized disks. Well, vs the 2.88MB format, which simply shoved more sectors onto the disk... Most everything else reached 1.44MB and died on this hill. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-20 11:35 -0700 |
| Message-ID | <100ii13$2b6j8$1@dont-email.me> |
| In reply to | #111676 |
On 5/20/2025 10:42 AM, BGB wrote: > On 5/20/2025 9:49 AM, Stefan Monnier wrote: >>> You need RAM to make this work, and a few MB of HDD side cache isn't >>> a huge >>> cost if one would have already needed the same stuff to make the HDD >>> work. >> >> Indeed, AFAIK, what we call "HDD cache" is actually just the RAM used >> by the embedded CPU inside the drive for its operation. >> I expect this is used to store the information about in-flight requests >> (e.g. most importantly the data about the write requests received but >> that haven't yet reached the platters), but I also expects it holds data >> that happened to fly recently by the read-head, just in case. >> > > Probably. Again, a caveat that my knowledge is pretty old, and may have been superseded. The drive certainly needs some DRAM for its internal operations, but as has been pointed out, the cost of making this larger and using that extra for cache is pretty small. I just checked and a current Seagate drive has 512 MB of cache. That cache is used on both reads and writes. For reads, the vendor can specify the max amount to prefetch, which then determines the number of segments the cache is divided into. i.e. you might not want to cache the rest of the track since that might force not keeping the data from a previous read. You can also specify the minimum to prefetch, which can be zero, which determines how soon the drive can move the heads for another request. For writes, even if no write caching is allowed, the DRAM is used to accept the write data before the heads have arrived at the requested track and the disk has spun to the required sector. This allows for a faster response in the case that the heads arrive on track in the "middle" of the requested write area so the drive can write the last part of the transfer to the disk before the first part. (i.e. you overlap the time to transfer the last part of the request to the disk with the rotation.) Of course, if write caching is enabled, the DRAM is used to hold the write data until it can be written to the disk. > As I understand it, it is this, along with a certain amount of "read > prefetch", which is granted, typically the data for the rest of the > track as the drive spins around; Perhaps. See above. > And, keeping some copies of previously read content around, which can be > read again from this cache if they happen to be requested. > > As I understand it, also more modern HDDs tend to be "density per area" > rather than angular slices (as it was on much older HDDs and floppies, > *), so there would be more sectors on outer tracks vs on inner tracks. This has been done for well over 30 years. It allows the disk capacity to be increased by about 1/3 without any increased cost of the disk, hence lowers cost per gigabyte of the disk. Of course it requires an interface, such as, originally SCSI, but now also SATA that is block oriented not cyl/head/record oriented. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web