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 1 of 11 [1] 2 3 … 11 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2025-05-10 11:38 +0000 |
| Subject | Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <vvnds6$3gism$1@dont-email.me> |
For those who don't know it: This it the title of a book on, you guessed it, parallel programming (the "perfbook"), from the perspective of a Linux developer, Paul E. McKenney. https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html Much of it should be familiar to many contributors to comp.arch, but certainly not everything will be familiar to everyone (if I take myself as an example). It also contains a little appendix entitled "Advice to Hardware Designers", which is interesting.
[toc] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-11 00:04 +0000 |
| Message-ID | <edb59b7854474033c748f0fd668badaa@www.novabbs.org> |
| In reply to | #111589 |
Summary:: Devices need just as much cache coherence as cores--maybe more.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-11 13:59 +0000 |
| Message-ID | <w32UP.481123$C51b.217868@fx17.iad> |
| In reply to | #111590 |
mitchalsup@aol.com (MitchAlsup1) writes: >Summary:: Devices need just as much cache coherence as cores--maybe >more. Does a uart need cache coherence? How about a SPI or MMC controller?
[toc] | [prev] | [next] | [standalone]
| From | Al Kossow <aek@bitsavers.org> |
|---|---|
| Date | 2025-05-11 07:47 -0700 |
| Message-ID | <vvqdas$g9oh$1@dont-email.me> |
| In reply to | #111591 |
On 5/11/25 6:59 AM, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >> Summary:: Devices need just as much cache coherence as cores--maybe >> more. > > Does a uart need cache coherence? How about a SPI or MMC controller? > I had wondered about SOCs like the RPi Pico With the narrow memory interfaces, are cores starved for memory bandwidth?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-11 23:46 +0000 |
| Message-ID | <vvrcs9$msmc$2@dont-email.me> |
| In reply to | #111592 |
On Sun, 11 May 2025 07:47:53 -0700, Al Kossow wrote: > With the narrow memory interfaces, are cores starved for memory > bandwidth? Low memory bandwidth has been a chronic issue since the “wait states” of the 1980s. That’s why we have memory caches.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-12 00:30 +0000 |
| Message-ID | <0ec5d195f4732e6c92da77b7e2fa986d@www.novabbs.org> |
| In reply to | #111593 |
On Sun, 11 May 2025 23:46:17 +0000, Lawrence D'Oliveiro wrote: > On Sun, 11 May 2025 07:47:53 -0700, Al Kossow wrote: > >> With the narrow memory interfaces, are cores starved for memory >> bandwidth? > > Low memory bandwidth has been a chronic issue since the “wait states” of > the 1980s. > > That’s why we have memory caches. Which architects tend to only understand what happens when these caches are attached to CPUs and not "Joe Random Bus Master",
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-12 01:19 +0000 |
| Message-ID | <vvribg$npn4$1@dont-email.me> |
| In reply to | #111594 |
On Mon, 12 May 2025 00:30:37 +0000, MitchAlsup1 wrote: > On Sun, 11 May 2025 23:46:17 +0000, Lawrence D'Oliveiro wrote: > >> That’s why we have memory caches. > > Which architects tend to only understand what happens when these caches > are attached to CPUs and not "Joe Random Bus Master", One of my pet peeves is disk drives with memory caches in them. Why?
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-12 02:03 +0000 |
| Message-ID | <a4498684344066be615dbca13652c982@www.novabbs.org> |
| In reply to | #111595 |
On Mon, 12 May 2025 1:19:44 +0000, Lawrence D'Oliveiro wrote: > On Mon, 12 May 2025 00:30:37 +0000, MitchAlsup1 wrote: > >> On Sun, 11 May 2025 23:46:17 +0000, Lawrence D'Oliveiro wrote: >> >>> That’s why we have memory caches. >> >> Which architects tend to only understand what happens when these caches >> are attached to CPUs and not "Joe Random Bus Master", > > One of my pet peeves is disk drives with memory caches in them. Why? Makes the disk faster, decreasing pressure on the "Disk Cache" in DRAM.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-12 22:34 +0000 |
| Message-ID | <vvtt1r$1b8s7$3@dont-email.me> |
| In reply to | #111596 |
On Mon, 12 May 2025 02:03:44 +0000, MitchAlsup1 wrote: > On Mon, 12 May 2025 1:19:44 +0000, Lawrence D'Oliveiro wrote: > >> One of my pet peeves is disk drives with memory caches in them. Why? > > Makes the disk faster, decreasing pressure on the "Disk Cache" in DRAM. You realize that cache is on the wrong side of a drive interface which is not designed to run at RAM speeds?
[toc] | [prev] | [next] | [standalone]
| From | Terje Mathisen <terje.mathisen@tmsw.no> |
|---|---|
| Date | 2025-05-12 08:05 +0200 |
| Message-ID | <vvs343$ulkk$1@dont-email.me> |
| In reply to | #111595 |
Lawrence D'Oliveiro wrote: > On Mon, 12 May 2025 00:30:37 +0000, MitchAlsup1 wrote: > >> On Sun, 11 May 2025 23:46:17 +0000, Lawrence D'Oliveiro wrote: >> >>> That’s why we have memory caches. >> >> Which architects tend to only understand what happens when these caches >> are attached to CPUs and not "Joe Random Bus Master", > > One of my pet peeves is disk drives with memory caches in them. Why? > For reads it allows the disk to always read full sets of sectors, the following blocks are likely to be needed soon anyway. For writes, as long as the drive has enough energy (maybe in the form of spinning inertia, or a hefty cap?) the always be able to save the buffer cache to spinning rust, it can allow operations to complete immediately, or as soon as the data has been transferred into the disk cache. Since all disks are using linear sector (or 4K block?) addressing these days, instead of head/cylinder/sector, a little bit of cache can help hide the tiny time glitches when the disk has to reposition. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-12 08:41 +0000 |
| Message-ID | <2025May12.104157@mips.complang.tuwien.ac.at> |
| In reply to | #111597 |
Terje Mathisen <terje.mathisen@tmsw.no> writes: >Lawrence D'Oliveiro wrote: >> One of my pet peeves is disk drives with memory caches in them. Why? >>=20 > >For reads it allows the disk to always read full sets of sectors, the=20 >following blocks are likely to be needed soon anyway. Yes. >For writes, as long as the drive has enough energy (maybe in the form of = > >spinning inertia, or a hefty cap?) the always be able to save the buffer = > >cache to spinning rust, it can allow operations to complete immediately, = > >or as soon as the data has been transferred into the disk cache. I used to think so, but someone (who appeared knowledgable) corrected that view and told me that all that HDDs ever do on power loss is to complete the current sector. >Since all disks are using linear sector (or 4K block?) addressing these=20 >days, instead of head/cylinder/sector, a little bit of cache can help=20 >hide the tiny time glitches when the disk has to reposition. An alternative is to skew the start of the first sector on the next track to take the repositioning time into account, and from what I have read, that is what is done. It allows to complete a sequence of sectors in one go, and then move on to the next sequence of sectors elsewhere, without having to wait for another disk rotation to be able to write the sector that was missed in an unskewed drive. On SSDs DRAM cache is also used for storing the logical-to-physical sector mapping of the flash translation layer; accessing it on flash is apparently too slow. Some DRAM-less SSDs keep that cache in host DRAM (but AFAIK in an area that is then not accessed by the host). In all of these caches the disk drive cache is not addressable by the CPU and it's coherence with the CPU cache is therefore not an issue. It's coherence with the permanent state of the drive is an issue, though. SCSI and SATA drives (and, I guess, NVME drives, too, but I have read little about that) support command-queuing interfaces that allow the file systems to manage this coherence. File systems are not as good at that as I would like. - 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 | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-12 22:39 +0000 |
| Message-ID | <vvtta6$1b8s7$5@dont-email.me> |
| In reply to | #111598 |
On Mon, 12 May 2025 08:41:57 GMT, Anton Ertl wrote: > On SSDs DRAM cache is also used for storing the logical-to-physical > sector mapping of the flash translation layer; accessing it on flash is > apparently too slow. There is a lot of complicated firmware in SSDs to make them look as much like a traditional hard drive as possible, so that traditional hard drive filesystems can be used unchanged. This firmware has been known to have bugs in it. Whereas the Linux kernel includes a few filesystems purpose-designed for operation on raw flash devices, that integrate wear-levelling etc right into the block allocation algorithms. Wouldn’t it be much better (more efficient and more reliable) to get rid of most of that firmware layer, and use these sorts of filesystems directly?
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-12 17:14 -0700 |
| Message-ID | <vvu2sr$3uvs3$1@dont-email.me> |
| In reply to | #111598 |
On 5/12/2025 1:41 AM, Anton Ertl wrote: > Terje Mathisen <terje.mathisen@tmsw.no> writes: >> Lawrence D'Oliveiro wrote: >>> One of my pet peeves is disk drives with memory caches in them. Why? >>> =20 >> >> For reads it allows the disk to always read full sets of sectors, the=20 >> following blocks are likely to be needed soon anyway. > > Yes. > >> For writes, as long as the drive has enough energy (maybe in the form of = >> >> spinning inertia, or a hefty cap?) the always be able to save the buffer = >> >> cache to spinning rust, it can allow operations to complete immediately, = >> >> or as soon as the data has been transferred into the disk cache. > > I used to think so, but someone (who appeared knowledgable) corrected > that view and told me that all that HDDs ever do on power loss is to > complete the current sector. Caveat - my knowledge on this subject is old and may be obsolete. But it was correct. Close. They complete the current sector (so that a subsequent read doesn't cause a messy error due to partially written sector), then do an emergency retract of the heads. This is done so when the disk stops spinning and the heads land, they do so in the "landing zone" which is an area that is a little rougher than the rest of the disk. This prevents the heads from becoming stuck to the disk surface, a problem known as "stiction" without this, when power is restored and the disk starts spinning again, the heads would stick to the disk surface and be ripped off the arm, essentially destroying the drive. The rougher landing zone area of the disk prevents stiction. If you want the write operation to complete after a power outage, you need a battery backup. >> Since all disks are using linear sector (or 4K block?) addressing these=20 >> days, instead of head/cylinder/sector, a little bit of cache can help=20 >> hide the tiny time glitches when the disk has to reposition. > > An alternative is to skew the start of the first sector on the next > track to take the repositioning time into account, and from what I > have read, that is what is done. It allows to complete a sequence of > sectors in one go, and then move on to the next sequence of sectors > elsewhere, without having to wait for another disk rotation to be able > to write the sector that was missed in an unskewed drive. Actually, both a cache and skewing are done. There are two "levels" of skew. A small skew is used at the end of each track except the last on on the cylinder to allow for a small "microseek" to allow the drive to compensate for the small differences in track location in each surface. A larger skew is used after the last track on each cylinder to allow the heads to seek to the next cylinder without, as you say, incurring a full rotation delay. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-12 22:35 +0000 |
| Message-ID | <vvtt4d$1b8s7$4@dont-email.me> |
| In reply to | #111597 |
On Mon, 12 May 2025 08:05:56 +0200, Terje Mathisen wrote: > Lawrence D'Oliveiro wrote: >> >> One of my pet peeves is disk drives with memory caches in them. Why? >> > For reads it allows the disk to always read full sets of sectors, the > following blocks are likely to be needed soon anyway. Leave that up to the OS I/O optimization algorithms. Because they know things about the data that the drive doesn’t. > For writes, as long as the drive has enough energy (maybe in the form of > spinning inertia, or a hefty cap?) the always be able to save the buffer > cache to spinning rust, it can allow operations to complete immediately, > or as soon as the data has been transferred into the disk cache. In other words, telling lies to the OS that the write has completed when it hasn’t. This kind of thing can really stuff up filesystem integrity guarantees.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-12 21:50 -0400 |
| Message-ID | <jwvr00twbj5.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111600 |
Lawrence D'Oliveiro [2025-05-12 22:35:57] wrote:
> On Mon, 12 May 2025 08:05:56 +0200, Terje Mathisen wrote:
>> For reads it allows the disk to always read full sets of sectors, the
>> following blocks are likely to be needed soon anyway.
> Leave that up to the OS I/O optimization algorithms. Because they know
> things about the data that the drive doesn’t.
But the drive also knows things about the data that the OS can't know
(things that have to do with the physical location of the data on the
platters). Which is why it makes sense for both the OS and the drive to
make their own efforts.
Lawrence D'Oliveiro [2025-05-12 22:39:02] wrote:
> On Mon, 12 May 2025 08:41:57 GMT, Anton Ertl wrote:
>> On SSDs DRAM cache is also used for storing the logical-to-physical
>> sector mapping of the flash translation layer; accessing it on flash is
>> apparently too slow.
> There is a lot of complicated firmware in SSDs to make them look as
> much like a traditional hard drive as possible, so that traditional
> hard drive filesystems can be used unchanged. This firmware has been
> known to have bugs in it.
Bugs is largely attached to "complicated", yes. This said, I've been
lucky enough not to bump into any of them in my years of use of SSDs.
I admittedly don't push them very hard.
> Whereas the Linux kernel includes a few filesystems purpose-designed
> for operation on raw flash devices, that integrate wear-levelling etc
> right into the block allocation algorithms. Wouldn’t it be much
> better (more efficient and more reliable) to get rid of most of that
> firmware layer, and use these sorts of filesystems directly?
More reliable, I don't know: to get comparable performance, you'll need
comparable complexity, so probably comparable amount of bugs.
Tho I guess by being exposed to many more eyes (by virtue of being Free
Software), it could have a chance of being more reliable, maybe.
But in any case, your above argument has some problems:
- Those "few filesystems" aren't nearly good enough to compete with
a normal filesystem running on top of a typical SSD. Simply because
those filesystems have not been designed for those kinds of uses.
Last I checked, they don't scale very well to TB sizes, for example.
And they haven't seen nearly as much work put into avoiding stuttering
and poor performance when the drive is full. More generally, they
haven't received nearly as much attention as has been invested in
SSDs' "FTL".
- The experience with flash technology in the Linux kernel for smaller
devices like home routers and such suggests that doing wear leveling
in the filesystem is a bad idea because you want to do it over the
whole device: no big difference if you have a single filesystem on the
whole drive, but for the general case you want something like UBI,
i.e. a kind of volume-management system that takes care of spreading
the writes over the whole drive as well as remapping defective pages,
while still exposing some of the semantics of flash chips, so you need
non-standard filesystems on top of that
- For better of for worse, drive manufacturers simply have not given
access to the "raw" flash layer. I'm not completely sure why, but
I get the impression that manufacturers use it as a way to segment the
market, with different prices for the same flash chips combined with
different FTLs.
But maybe at some point, market conditions will change and we'll be
able to buy SSDs that can be accessed directly at the flash level?
I agree with you in theory, but in practice I think the potential gain is
rather small. Maybe the "block device abstraction" isn't such a bad
choice in the end.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-13 03:03 +0000 |
| Message-ID | <vvucqi$1i6m9$1@dont-email.me> |
| In reply to | #111603 |
On Mon, 12 May 2025 21:50:02 -0400, Stefan Monnier wrote: > But the drive also knows things about the data that the OS can't know > (things that have to do with the physical location of the data on the > platters). No it doesn’t. Consider a journalling filesystem, where the journal entry must be written first before the actual filesystem update. If the drive reorders the writes to do the latter first, there go your filesystem integrity guarantees. > More reliable, I don't know: to get comparable performance, you'll need > comparable complexity ... Fewer layers ⇒ less complexity. > - Those "few filesystems" aren't nearly good enough to compete with > a normal filesystem running on top of a typical SSD. Simply because > those filesystems have not been designed for those kinds of uses. Of course they are. You don’t think there are filesystem experts working on the Linux kernel?
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-12 23:25 -0400 |
| Message-ID | <jwvbjrxw6bs.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111604 |
>> But the drive also knows things about the data that the OS can't know
>> (things that have to do with the physical location of the data on the
>> platters).
> No it doesn’t.
I admire your nuanced understanding of the matter.
>> More reliable, I don't know: to get comparable performance, you'll
>> need comparable complexity ...
> Fewer layers ⇒ less complexity.
The relation between these two is not nearly that simple.
>> - Those "few filesystems" aren't nearly good enough to compete with
>> a normal filesystem running on top of a typical SSD. Simply because
>> those filesystems have not been designed for those kinds of uses.
> Of course they are.
Can you name some?
> You don’t think there are filesystem experts working on the
> Linux kernel?
Just because your design is optimized for ~100MB devices doesn't mean
you're an idiot who couldn't have made a design optimized for
~1TB devices.
Just like the fact that your design for ~1TB devices sucks rocks
when used on ~100MB devices doesn't make you an idiot.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-13 08:39 -0700 |
| Message-ID | <vvvp3n$3uvs4$1@dont-email.me> |
| In reply to | #111604 |
On 5/12/2025 8:03 PM, Lawrence D'Oliveiro wrote: > On Mon, 12 May 2025 21:50:02 -0400, Stefan Monnier wrote: > >> But the drive also knows things about the data that the OS can't know >> (things that have to do with the physical location of the data on the >> platters). > > No it doesn’t. Consider a journalling filesystem, where the journal entry > must be written first before the actual filesystem update. If the drive > reorders the writes to do the latter first, there go your filesystem > integrity guarantees. First of all, you said that there aren't things that the drive knows but the host doesn't. This isn't true (e.g. which disk sectors are defective and had to be relocated), and the rest of your response doesn't refute that, but talks about file system stuff. Secondly, if a particular write, in your example, the journal write has to be completed before the other write, the disk provides that capability. It has nothing to do with what the disk knows. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | EricP <ThatWouldBeTelling@thevillage.com> |
|---|---|
| Date | 2025-05-13 12:55 -0400 |
| Message-ID | <IQKUP.130057$rkV6.19858@fx46.iad> |
| In reply to | #111604 |
Lawrence D'Oliveiro wrote: > On Mon, 12 May 2025 21:50:02 -0400, Stefan Monnier wrote: > >> But the drive also knows things about the data that the OS can't know >> (things that have to do with the physical location of the data on the >> platters). > > No it doesn’t. Yes the HDD controller does know more. For 40 or so years HDD have done automatic bad sector and bad track replacement. Each track has a few spare sectors and each zone has a number of spare tracks. They also use zoned recording where the number of sectors per track changes as you move out from the center. So you won't know which sectors are on the same track. Also as Anton mentioned rotational optimization where you write logical sectors 1,2,3,4 but they are actually written 3,4,<wait>,1,2, or even 3,4,<wait>,2,<seek>,1. The HDD controller is responsible for mapping the logical sector numbers onto the real physical disk sectors using those internal maps and then optimizing the head seeks. > Consider a journalling filesystem, where the journal entry > must be written first before the actual filesystem update. If the drive > reorders the writes to do the latter first, there go your filesystem > integrity guarantees. For those drives that accept multiple queued commands, they are _defined_ as being reordered by the drive controller. If you don't want two commands reordered then submit them serially and wait for each completion status. File system integrity has to take many failure modes into account. E.g. sectors are 512B but a file system block is 4kB or 8 sectors. On power fail the drive finishes writing only its current sector with a valid checksum. Only part of the block was written but its sector checksums are all correct. File systems can add block checksums to their meta data blocks to catch this. To allow recovery from power fail or crash, which parts of the file system IO can be overlapped in parallel and which must be serialized is part of resilient file system and database design. >> More reliable, I don't know: to get comparable performance, you'll need >> comparable complexity ... > > Fewer layers ⇒ less complexity. Modularity => less complexity due to less interactions between components. Fewer layers => more interactions => more permutations and combinations. SSD's each have a different internal design. Your approach would require the OS to know about the internal details of every flash chip down to the chip rev level for every manufacturer. >> - Those "few filesystems" aren't nearly good enough to compete with >> a normal filesystem running on top of a typical SSD. Simply because >> those filesystems have not been designed for those kinds of uses. > > Of course they are. You don’t think there are filesystem experts working > on the Linux kernel? An area you may be thinking of, where having the file system directly control the low level SSD might benefit, is putting a log structured file system directly onto an SSD. Currently these have the SSD's Flash Translation Layer FTL doing work to make it appear as though physically discontiguous blocks look logically contiguous with FTL blocks storing all that mapping meta data, then the log structured file system works to map those logically contiguous blocks scatter back to their associated files. This would probably be simpler with just one software layer, but that would require either the file system know about flash details, or flash have a full file system.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-13 07:40 +0000 |
| Message-ID | <2025May13.094035@mips.complang.tuwien.ac.at> |
| In reply to | #111600 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes: >On Mon, 12 May 2025 08:05:56 +0200, Terje Mathisen wrote: > >> Lawrence D'Oliveiro wrote: >>> >>> One of my pet peeves is disk drives with memory caches in them. Why? >>> >> For reads it allows the disk to always read full sets of sectors, the >> following blocks are likely to be needed soon anyway. > >Leave that up to the OS I/O optimization algorithms. Because they know >things about the data that the drive doesn’t. 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. Now the drive could employ a work-to-rule attitude and ignore all sectors until it finds sector N, and then send that over to the OS. The OS takes a little time and asks for N+1. Unfortunately, your work-to-rule HDD has already rotated a little way into sector N+1, so it has to wait another rotation for N+1, and so on. By contrast, a read-caching HDD will read the whole track in one rotation, and then deliver sector N and all the other sectors from that track that the OS asks for out of the cache. >> For writes, as long as the drive has enough energy (maybe in the form of >> spinning inertia, or a hefty cap?) the always be able to save the buffer >> cache to spinning rust, it can allow operations to complete immediately, >> or as soon as the data has been transferred into the disk cache. > >In other words, telling lies to the OS that the write has completed when >it hasn’t. Not necessarily. When you do command queuing and report the writes as completed only when they actually have completed, you also need RAM on the drive for storing all the queued writes and their data. >This kind of thing can really stuff up filesystem integrity >guarantees. Which file system offers any useful integrity guarantees? When I last looked in the Linux docs, the only file system giving any integrity guarantees at all was NILFS2. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web