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 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-28 14:50 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <2025May28.165035@mips.complang.tuwien.ac.at> |
| In reply to | #111865 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>On 5/27/2025 9:19 AM, Anton Ertl wrote: >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>> On 5/27/2025 1:34 AM, Anton Ertl wrote: >>>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>>>> On 5/26/2025 12:19 PM, John Levine wrote: >>>>>>> According to Stefan Monnier <monnier@iro.umontreal.ca>: >>>>>>>> Stephen Fuld [2025-05-26 11:16:25] wrote: >>>>>>>>> https://www.seagate.com/innovation/multi-actuator-hard-drives/ [...] >to get the project done quickly, they started out by >duplicating the drive electronics (only one motor controller is >connected, and (wild guess) spindown on idle is disabled; otherwise >they would need to synchronize that; or maybe they do, at least in >order to implement staggered spin-up); they added a front end that >provides a common host interface with the two LUNs (probably available >as off-the-shelf component), and the only new development necessary >for the project was the split actuator. That's how it came out for >the 2X14 drive; and my guess is that the sales numbers were good >enough to respin it as 2X18 when the density per platter had increased >enough for that, but not good enough to perform the development of the >original plan. > >While the minimal-duplication approach would be cheaper if enough >units are sold, my guess is that the number of 2X drives sold is not >high enough for that, and so it's cheaper to use two mass-produced >drive electronics and one mass-produced LUN-splitter instead. > >The fact that the idle power consumption of the 2X14 (7W) is higher >than the idle power consumption of the X14 (5W) >(<https://www.storagereview.com/news/seagate-exos-2x14-hdd-delivers-524mb-s> >is another hint that there probably is more rather than less >duplication. Counterevidence for my theory: The Exos X drives are all listed as having 256MB of cache, including the 2X drives. If the electronics were fully duplicated, they could list 512MB. - 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 | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 08:48 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1017b7t$334ga$2@dont-email.me> |
| In reply to | #111866 |
On 5/28/2025 7:50 AM, Anton Ertl wrote: snip > Counterevidence for my theory: The Exos X drives are all listed as > having 256MB of cache, including the 2X drives. If the electronics > were fully duplicated, they could list 512MB. Our posts mentioning this "crossed in the mail" :-) -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 08:46 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1017b4j$334ga$1@dont-email.me> |
| In reply to | #111865 |
On 5/28/2025 12:47 AM, Anton Ertl wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> On 5/27/2025 9:19 AM, Anton Ertl wrote: >>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>> On 5/27/2025 1:34 AM, Anton Ertl wrote: >>>>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>>>>> On 5/26/2025 12:19 PM, John Levine wrote: >>>>>>> According to Stefan Monnier <monnier@iro.umontreal.ca>: >>>>>>>> Stephen Fuld [2025-05-26 11:16:25] wrote: >>>>>>>>> https://www.seagate.com/innovation/multi-actuator-hard-drives/ > [...] >>> The fact that this is presented as two drives to the system makes me >>> suspect that the drive electronics is duplicated. >> >> Not two drives, but two Logical Units (LUNS). > > <https://www.techopedia.com/definition/321/logical-unit-number-lun> says: > |The term LUN was initiated from the SCSI protocol and provided a > |methodology for identifying specific disc drives within a regular > |component such as a disc array. > > In the present context: If the drive electronics has the minimum > amount of duplication, why present the thing as two LUNs? It allows there to be two commands outstanding (one per LUN) to be active at the same time without the added complexity of command queuing. This allows overlapping the seeks and rotations of the two LUNs, thus improving performance. > >> It's not two separate >> drives because there is only one host interface. > > In the scenario described above, disk arrays have only one host > interface but still contain separate drives, each drive identified by > a LUN. Yes. > >> So, without knowing for sure, I think the disk has one set of host >> interface electronics, one main CPU, one DRAM buffer, one motor control, >> etc. It says that it can transfer from both disks (presumably at least >> one to/from the buffer) simultaneously, so it has two disk read channels >> and two disk write channels. But I don't think anything else is duplicated. > > In that case, why have two LUNs? It seems to me that in this > scenario, it would be easier to use the drive as one 18TB LUN, no need > for the user to arrange the two LUNs into a RAID0 or JBOD. But then, unless you used command queuing, you can't have seek overlap between the two "halfs" of the drive. > In this > scenario the drive electronics could arrange the sectors of logically > consecutive tracks to come from alternating actuators, which allows to > double the sequential speed, and also to double the IOPS of random > accesses given enough concurrent requests. You only get double the IOPS if the host supports command queuing. As to whether to interleave the addresses, that is an independent question. There are advantages and disadvantages, mainly revolving around (pun intended) how long the average user request is versus what is the unit of interleave. > My guess is that the eventual intent of Seagate was to provide that > scenario, but to get the project done quickly, they started out by > duplicating the drive electronics (only one motor controller is > connected, and (wild guess) spindown on idle is disabled; otherwise > they would need to synchronize that; or maybe they do, at least in > order to implement staggered spin-up); they added a front end that > provides a common host interface with the two LUNs (probably available > as off-the-shelf component), and the only new development necessary > for the project was the split actuator. That's how it came out for > the 2X14 drive; and my guess is that the sales numbers were good > enough to respin it as 2X18 when the density per platter had increased > enough for that, but not good enough to perform the development of the > original plan. Well, neither of us knows for sure. But they already had eight platter drive hardware, so no new development for incorporating that, versus having to find some mechanism to anchor the "upper" drive motor to the casing that doesn't exist now. And no need to add the "front end" you mention. Plus if you were going to duplicate essentially all the electronics, (plus the added front end) you need space for the second circuit board, so you would probably have to sacrifice a platter to fit it within the form factor. So it seems doubtful to me. One other hint - no mention of separate caches for each actuator. But again, I have no direct knowledge. BTW, more information at https://www.seagate.com/content/dam/seagate/migrated-assets/www-content/solutions/mach-2-multi-actuator-hard-drive/files/sc702.2-2101us-mach-2-faq.pdf -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-28 12:08 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwvldqglo5z.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111867 |
Stephen Fuld [2025-05-28 08:46:26] wrote:
> You only get double the IOPS if the host supports command queuing.
I'd expect that command queuing is the only case that really matters in
practice.
> As to whether to interleave the addresses, that is an independent
> question. There are advantages and disadvantages, mainly revolving
> around (pun intended) how long the average user request is versus what
> is the unit of interleave.
That seems like a more important benefit: the users get to choose how to
spread their data depending on their specific use case.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 09:20 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1017d4b$334ga$3@dont-email.me> |
| In reply to | #111869 |
On 5/28/2025 9:08 AM, Stefan Monnier wrote: > Stephen Fuld [2025-05-28 08:46:26] wrote: >> You only get double the IOPS if the host supports command queuing. > > I'd expect that command queuing is the only case that really matters in > practice. You may be right. And I expect most applications will use that. But the cost of presenting as two LUNs is essentially zero, why not support it for those "legacy" systems not supporting command queuing? >> As to whether to interleave the addresses, that is an independent >> question. There are advantages and disadvantages, mainly revolving >> around (pun intended) how long the average user request is versus what >> is the unit of interleave. > > That seems like a more important benefit: the users get to choose how to > spread their data depending on their specific use case. I don't disagree, though I didn't see any mechanism for the user to specify the unit of interleave. Of course you could do this in the host file system. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-28 12:52 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwv4ix4lltt.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111870 |
Stephen Fuld [2025-05-28 09:20:27] wrote:
> On 5/28/2025 9:08 AM, Stefan Monnier wrote:
>> That seems like a more important benefit: the users get to choose how to
>> spread their data depending on their specific use case.
> I don't disagree, though I didn't see any mechanism for the user to specify
> the unit of interleave. Of course you could do this in the host
> file system.
If they appear as two LUNs, then the drive can't do the interleaving,
only the host can.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 10:15 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1017gb2$3b6lq$1@dont-email.me> |
| In reply to | #111872 |
On 5/28/2025 9:52 AM, Stefan Monnier wrote: > Stephen Fuld [2025-05-28 09:20:27] wrote: >> On 5/28/2025 9:08 AM, Stefan Monnier wrote: >>> That seems like a more important benefit: the users get to choose how to >>> spread their data depending on their specific use case. >> I don't disagree, though I didn't see any mechanism for the user to specify >> the unit of interleave. Of course you could do this in the host >> file system. > > If they appear as two LUNs, then the drive can't do the interleaving, > only the host can. Of course the drive can. In general, you have no idea of the mapping between what the host calls a LUN/LBA (logical block address), and the physical cylinder and head on the drive. You might notice a performance difference depending upon workload, but that is the point of allowing the user to specify the interleave factor. For example, say the drive chooses to interleave between the two actuators every 64K bytes. If a long (say 1MB) request comes in on one LUN, it will intermittently tie up both actuators, so if another 1 MB request comes in on the other LUN, it will have to wait, but on the other hand, when that second request gets its turn, it will complete faster. And, of course, if you use command queuing, you may not even notice. YMMV. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-28 14:16 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwvmsawk3kr.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111873 |
Stephen Fuld [2025-05-28 10:15:14] wrote:
> On 5/28/2025 9:52 AM, Stefan Monnier wrote:
>> If they appear as two LUNs, then the drive can't do the interleaving,
>> only the host can.
> Of course the drive can. In general, you have no idea of the mapping
> between what the host calls a LUN/LBA (logical block address), and the
> physical cylinder and head on the drive.
Right, but what would be the point of exposing two LUNs if the drive
does the interleaving? Wouldn't it be "all cost, no benefit"?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 13:37 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1017s6o$3b6lq$2@dont-email.me> |
| In reply to | #111874 |
On 5/28/2025 11:16 AM, Stefan Monnier wrote: > Stephen Fuld [2025-05-28 10:15:14] wrote: >> On 5/28/2025 9:52 AM, Stefan Monnier wrote: >>> If they appear as two LUNs, then the drive can't do the interleaving, >>> only the host can. >> Of course the drive can. In general, you have no idea of the mapping >> between what the host calls a LUN/LBA (logical block address), and the >> physical cylinder and head on the drive. > > Right, but what would be the point of exposing two LUNs if the drive > does the interleaving? Wouldn't it be "all cost, no benefit"? The benefit of LUNs is to allow the host issue more than one command at a time when the host doesn't support command queuing. It is independent of the interleaving decision. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-28 22:28 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <b44852e57a4e97e430bd9078ec3022e7@www.novabbs.org> |
| In reply to | #111875 |
On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote: > On 5/28/2025 11:16 AM, Stefan Monnier wrote: >> Stephen Fuld [2025-05-28 10:15:14] wrote: >>> On 5/28/2025 9:52 AM, Stefan Monnier wrote: >>>> If they appear as two LUNs, then the drive can't do the interleaving, >>>> only the host can. >>> Of course the drive can. In general, you have no idea of the mapping >>> between what the host calls a LUN/LBA (logical block address), and the >>> physical cylinder and head on the drive. >> >> Right, but what would be the point of exposing two LUNs if the drive >> does the interleaving? Wouldn't it be "all cost, no benefit"? > > The benefit of LUNs is to allow the host issue more than one command at > a time when the host doesn't support command queuing. It is independent > of the interleaving decision. Seems to me that SR-IOV provides the mechanism to have almost any number of in-order queues, each; give GuestOS[5] k virtual FUs to device[19]. Want overlap and don't care about order, spread the workload around. Don't want overlap or do care about order, use a single V device.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-28 16:00 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <10184id$3b6lq$3@dont-email.me> |
| In reply to | #111876 |
On 5/28/2025 3:28 PM, MitchAlsup1 wrote: > On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote: > >> On 5/28/2025 11:16 AM, Stefan Monnier wrote: >>> Stephen Fuld [2025-05-28 10:15:14] wrote: >>>> On 5/28/2025 9:52 AM, Stefan Monnier wrote: >>>>> If they appear as two LUNs, then the drive can't do the interleaving, >>>>> only the host can. >>>> Of course the drive can. In general, you have no idea of the mapping >>>> between what the host calls a LUN/LBA (logical block address), and the >>>> physical cylinder and head on the drive. >>> >>> Right, but what would be the point of exposing two LUNs if the drive >>> does the interleaving? Wouldn't it be "all cost, no benefit"? >> >> The benefit of LUNs is to allow the host issue more than one command at >> a time when the host doesn't support command queuing. It is independent >> of the interleaving decision. > > Seems to me that SR-IOV provides the mechanism to have almost any number > of in-order queues, each; give GuestOS[5] k virtual FUs to device[19]. I confess to no knowledge of SR-IOV. But absent command queuing, the device will only accept one command per LUN. If there were more than one, neither the SAS nor the SATA protocol has a way to indicate for which command the read data returned is for. The primary thing that command queuing provides is that mechanism. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-29 14:23 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <o5_ZP.5253$9Zy4.3292@fx42.iad> |
| In reply to | #111876 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Wed, 28 May 2025 20:37:44 +0000, Stephen Fuld wrote: > >> On 5/28/2025 11:16 AM, Stefan Monnier wrote: >>> Stephen Fuld [2025-05-28 10:15:14] wrote: >>>> On 5/28/2025 9:52 AM, Stefan Monnier wrote: >>>>> If they appear as two LUNs, then the drive can't do the interleaving, >>>>> only the host can. >>>> Of course the drive can. In general, you have no idea of the mapping >>>> between what the host calls a LUN/LBA (logical block address), and the >>>> physical cylinder and head on the drive. >>> >>> Right, but what would be the point of exposing two LUNs if the drive >>> does the interleaving? Wouldn't it be "all cost, no benefit"? >> >> The benefit of LUNs is to allow the host issue more than one command at >> a time when the host doesn't support command queuing. It is independent >> of the interleaving decision. > >Seems to me that SR-IOV provides the mechanism to have almost any number >of in-order queues, each; give GuestOS[5] k virtual FUs to device[19]. While true, the AHCI specification for the SATA PCI controller doesn't include SRIOV. nVME on ther other hand, includes SRIOV support specifically for that reason.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-29 09:56 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwvldqfmsl7.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111875 |
Stephen Fuld [2025-05-28 13:37:44] wrote:
> On 5/28/2025 11:16 AM, Stefan Monnier wrote:
>> Stephen Fuld [2025-05-28 10:15:14] wrote:
>>> On 5/28/2025 9:52 AM, Stefan Monnier wrote:
>>>> If they appear as two LUNs, then the drive can't do the interleaving,
>>>> only the host can.
>>> Of course the drive can. In general, you have no idea of the mapping
>>> between what the host calls a LUN/LBA (logical block address), and the
>>> physical cylinder and head on the drive.
>> Right, but what would be the point of exposing two LUNs if the drive
>> does the interleaving? Wouldn't it be "all cost, no benefit"?
> The benefit of LUNs is to allow the host issue more than one command at
> a time when the host doesn't support command queuing. It is independent of
> the interleaving decision.
I don't think it's independent: tying the LUNs to the interleaving
brings the benefit of letting the users choose the interleaving and
basically exposing the hardware reality so the host can make best use
of it. If the interleaving is independent from the LUNs it means the
sole purpose of the LUNs would be a poor man's command queuing.
If you want multiple commands in flight, command queuing is the standard
solution and it's not like it's rocket science, so why would you use
LUNs for it instead, given how much more clunky it is to use for
that purpose?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-05-29 01:54 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1018eor$2d8m$1@gal.iecc.com> |
| In reply to | #111865 |
According to Anton Ertl <anton@mips.complang.tuwien.ac.at>: >In the present context: If the drive electronics has the minimum >amount of duplication, why present the thing as two LUNs? From the Seagate FAQ: Q: Is the development of a single volume drive expected in the future (i.e., the drive itself will load balance/optimize by striping workloads evenly across both actuators)? A: Maybe. It is possible, but there are tail-latency issues with a configuration like this, yet it is the simplest way to get plug-and-play performance. There needs to be enough market to justify the firmware development/complexity And as for what it's intended for: Q: What workloads show the best performance benefits over a single actuator? A: Exos 2X was designed for hyperscale workloads that focus on low queue-depth random read operations (low queue-depths keep command latencies low) and large transfer size sequential operations. The highest performance gains over a single actuator will be found during high transfer size sequential reads/writes (128KB transfers and larger), random reads (all transfer sizes), and random writes (128KB transfers and larger) -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-28 12:32 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwvfrgolngc.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111821 |
John Levine [2025-05-26 19:19:55] wrote:
> According to Stefan Monnier <monnier@iro.umontreal.ca>:
>>Hmmm, hard to believe it makes commercial sense: if you need higher
>>performance, when would this be price-competitive with an SSD?
[...]
> It seems to have come and gone. Nobody has them new, refurbished are
> $150 - $200 on eBay. An SSD of similar size is in the $2000 range so
> it would have made sense for a data warehouse.
The prices I see currently are about CAD$16/TB for 3½" (~20TB) HDDs vs
CAD$80/TB for M.2 (~4TB) SSDs.
I guess if you need many TBs and you're content with a 2x speedup,
a dual-actuator drive can make sense, but I suspect that the market for
those whose performance falls between HDDs and SSDs is shrinking.
I wonder how power consumption compares for 20TB-range HDDs-vs-SSDs.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 13:36 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1012jce$23l9t$1@dont-email.me> |
| In reply to | #111820 |
On 5/26/2025 11:58 AM, Stefan Monnier wrote: > Stephen Fuld [2025-05-26 11:16:25] wrote: >> https://www.seagate.com/innovation/multi-actuator-hard-drives/ > > Hmmm, hard to believe it makes commercial sense: if you need higher > performance, when would this be price-competitive with an SSD? It should be not much more costly than a single disk of the same capacity. It has the same number of heads, platters, and of course the same enclosure, etc. A little more work to separate the two arm magnetic actuators. The same electronics, except for, and this is probably the most expensive part, an additional read channel. So still a lot cheaper than an SSD. > Also, that page is very light on details, but the image they include > suggests the two actuators are used on separate platters, so it's akin > to cramming a 2-disk-RAID0 into a single HDD enclosure. Yeah, sort of. But a single drive motor, a single host interface, microprocessor, etc. So quite a bit less costly than two separate disks. > Maybe part of the gain of having two actuators is that each actuator is > a bit lighter? I suspect that is insignificant. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-26 23:26 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <2N6ZP.39064$wdi3.10961@fx45.iad> |
| In reply to | #111829 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 5/26/2025 11:58 AM, Stefan Monnier wrote: >> Stephen Fuld [2025-05-26 11:16:25] wrote: >>> https://www.seagate.com/innovation/multi-actuator-hard-drives/ >> >> Hmmm, hard to believe it makes commercial sense: if you need higher >> performance, when would this be price-competitive with an SSD? > >It should be not much more costly than a single disk of the same >capacity. It has the same number of heads, platters, and of course the >same enclosure, etc. A little more work to separate the two arm >magnetic actuators. The same electronics, except for, and this is >probably the most expensive part, an additional read channel. So still >a lot cheaper than an SSD. Burroughs systems did have SSD's (DRAM-based) which were used for the MCP disk (which held the run/spo/maintenance logs) which had frequent accesses from the late 70's. They weren't cheap.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-26 20:31 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <Vc4ZP.3004$Yx54.41@fx40.iad> |
| In reply to | #111819 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 5/26/2025 10:42 AM, John Levine wrote: >> According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>: >>> For some damn reason I thought of a fractal disk arm, an arm that had a >>> fractal structure, the disk rotates, but the fractal arm can read from >>> many places at once? Try not to flame me too much. ;^) >> >> Dunno about fractal, but I have used head per track disks with a fixed arm >> with many heads, and a disk with a crooked Y-shaped arm with two heads over >> two tracks. > >Yup. And IIRC the IBM 3380 had a linear actuator with two heads per >arm, one covering the outer cylinders, the other the inner cylinders. >The tradeoff was shorter seeks, thus smaller seek time but higher cost >due to more heads. Burroughs had some memorex-built drives that had multiple actuators which allowed it to sustain two simultaneous independent transfers from the media. This was circa 1988. The drives were often shared between two to four systems in loosely coupled multiprocessor configurations. Required a forklift to deliver to the machine room. 1GB capacity. > But if you mean two simultaneous >transfers into a buffer in order to get higher host transfer rate, that >is apparently now available. > >https://www.seagate.com/innovation/multi-actuator-hard-drives/ Ah, what's old is new again.... I can't imagine why Seagate calls that "The world's first multiactuator technology", given we had it four decades ago.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 13:45 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1012jsc$23l9s$2@dont-email.me> |
| In reply to | #111828 |
On 5/26/2025 1:31 PM, Scott Lurndal wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> On 5/26/2025 10:42 AM, John Levine wrote: >>> According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>: >>>> For some damn reason I thought of a fractal disk arm, an arm that had a >>>> fractal structure, the disk rotates, but the fractal arm can read from >>>> many places at once? Try not to flame me too much. ;^) >>> >>> Dunno about fractal, but I have used head per track disks with a fixed arm >>> with many heads, and a disk with a crooked Y-shaped arm with two heads over >>> two tracks. >> >> Yup. And IIRC the IBM 3380 had a linear actuator with two heads per >> arm, one covering the outer cylinders, the other the inner cylinders. >> The tradeoff was shorter seeks, thus smaller seek time but higher cost >> due to more heads. > > Burroughs had some memorex-built drives that had multiple actuators which > allowed it to sustain two simultaneous independent transfers from the > media. Interesting. I presume that the two transfers had to be to two different head of string/controllers. > This was circa 1988. The drives were often shared between two > to four systems in loosely coupled multiprocessor configurations. That makes sense. No need to mess with the OS to allow two transfers to/from the same drive. > Ah, what's old is new again.... > > I can't imagine why Seagate calls that "The world's first multiactuator technology", > given we had it four decades ago. Come on, Scott! Both of us old codgers learned long ago to separate Marketing from reality! :-) I'll bet 1988 was before many of Seagate's people were born, much less involved in the industry. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-26 23:24 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <6L6ZP.39039$wdi3.25477@fx45.iad> |
| In reply to | #111831 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 5/26/2025 1:31 PM, Scott Lurndal wrote: >> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >>> On 5/26/2025 10:42 AM, John Levine wrote: >>>> According to Chris M. Thomasson <chris.m.thomasson.1@gmail.com>: >>>>> For some damn reason I thought of a fractal disk arm, an arm that had a >>>>> fractal structure, the disk rotates, but the fractal arm can read from >>>>> many places at once? Try not to flame me too much. ;^) >>>> >>>> Dunno about fractal, but I have used head per track disks with a fixed arm >>>> with many heads, and a disk with a crooked Y-shaped arm with two heads over >>>> two tracks. >>> >>> Yup. And IIRC the IBM 3380 had a linear actuator with two heads per >>> arm, one covering the outer cylinders, the other the inner cylinders. >>> The tradeoff was shorter seeks, thus smaller seek time but higher cost >>> due to more heads. >> >> Burroughs had some memorex-built drives that had multiple actuators which >> allowed it to sustain two simultaneous independent transfers from the >> media. > >Interesting. I presume that the two transfers had to be to two >different head of string/controllers. Each actuator appeared to the disk controller as a disk unit, so both could be transfering data simultaneously to one or more hosts. A single controller could control up to 16 units; a box called an 'exchange' could sit upstream of a controller and allow the controller to be accessed by multiple host channels (up to 16 host channels connected to eight exchange boxes servicing multiple disk controllers to which the drive units were connected). Those cables were all 1.25-1.50" in diameter and could really crowd the subfloor spaces. > > >> This was circa 1988. The drives were often shared between two >> to four systems in loosely coupled multiprocessor configurations. > >That makes sense. No need to mess with the OS to allow two transfers >to/from the same drive. The hosts were connected to a separate I/O device called a shared systems processor which basically supported block-level locking between the loosely coupled hosts. Before accessing a shared file block, a block lock on the unit needed to be acquired by the host by communicating with the SSP. > > >> Ah, what's old is new again.... >> >> I can't imagine why Seagate calls that "The world's first multiactuator technology", >> given we had it four decades ago. > >Come on, Scott! Both of us old codgers learned long ago to separate >Marketing from reality! :-) I'll bet 1988 was before many of Seagate's >people were born, much less involved in the industry. :-)
[toc] | [prev] | [next] | [standalone]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web