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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-23 12:36 +0000 |
| Message-ID | <26cdffcc235c3fc38a8b43834e912fac@www.novabbs.org> |
| In reply to | #111750 |
On Fri, 23 May 2025 6:09:37 +0000, BGB wrote: > On 5/23/2025 12:35 AM, Lawrence D'Oliveiro wrote: >> On Fri, 23 May 2025 00:18:53 -0000 (UTC), Waldek Hebisch wrote: >> >>> It is pretty clear that due to drive mechanics track cache/buffer is >>> useful. >> >> Only if you don’t take the statistics of real-world cache behaviour into >> account. >> >>> However, the real question is about size: how big should it be. >> >> It can never be big enough to make a difference. > > Sometimes, it is not the size of the cache that matters. > > > Say, for example, a typical cache configuration in my core: > L1 D$: 32K, direct mapped > L1 I$: 16K, direct mapped > L2: 256K, direct mapped. > > OK, so say I stick a 4K cache between the L1 and L2 caches. > Seems kinda useless just based on sizes. It is called a "victim buffer" > Except: This small cache is 4-way set associative and so can absorb a > bunch of conflict misses, and notably reducing the number of cache > misses in the L2 cache. It can bring a performance benefit, despite > being small. And generally fully associative > Why? Because it helps.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-23 11:29 -0500 |
| Message-ID | <100q848$5fc7$2@dont-email.me> |
| In reply to | #111751 |
On 5/23/2025 7:36 AM, MitchAlsup1 wrote: > On Fri, 23 May 2025 6:09:37 +0000, BGB wrote: > >> On 5/23/2025 12:35 AM, Lawrence D'Oliveiro wrote: >>> On Fri, 23 May 2025 00:18:53 -0000 (UTC), Waldek Hebisch wrote: >>> >>>> It is pretty clear that due to drive mechanics track cache/buffer is >>>> useful. >>> >>> Only if you don’t take the statistics of real-world cache behaviour into >>> account. >>> >>>> However, the real question is about size: how big should it be. >>> >>> It can never be big enough to make a difference. >> >> Sometimes, it is not the size of the cache that matters. >> >> >> Say, for example, a typical cache configuration in my core: >> L1 D$: 32K, direct mapped >> L1 I$: 16K, direct mapped >> L2: 256K, direct mapped. >> >> OK, so say I stick a 4K cache between the L1 and L2 caches. >> Seems kinda useless just based on sizes. > > It is called a "victim buffer" > I had usually understood it that a "victim buffer" was typically glued directly to the L1 cache. This was outside the L1 cache, and after the main TLB. So, the L1 ring consisted of: Join/VC -> L1D$ -> L1I$ -> TLB -> Join/VC The Join/VC stage was either a joiner between the L1 ring and L2 ring, or the 4K victim cache (optional, but does help). The L2 ring generally had the L2 cache, ROMs, a bridge to the MMIO bus, and the display and rasterizer modules (which had native interfaces on the ringbus). >> Except: This small cache is 4-way set associative and so can absorb a >> bunch of conflict misses, and notably reducing the number of cache >> misses in the L2 cache. It can bring a performance benefit, despite >> being small. > > And generally fully associative > On the FPGA, the cost difference between a 4-way 4K cache and 4-entry (full assoc) cache was small, but the using LUTRAMs gave a better hit-rate. The cost difference between 4-way and 8-way was a lot more steep (and seemingly doesn't improve hit rate enough to compensate for the fairly significant cost increase). I suspect it might be different tradeoffs on an ASIC though. >> Why? > > Because it helps. Yes.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-24 03:17 +0000 |
| Message-ID | <100rdnc$gk4l$1@dont-email.me> |
| In reply to | #111762 |
On Fri, 23 May 2025 11:29:03 -0500, BGB wrote: > On 5/23/2025 7:36 AM, MitchAlsup1 wrote: >> >> On Fri, 23 May 2025 6:09:37 +0000, BGB wrote: >> >>> OK, so say I stick a 4K cache between the L1 and L2 caches. >>> Seems kinda useless just based on sizes. >> >> It is called a "victim buffer" >> > I had usually understood it that a "victim buffer" was typically glued > directly to the L1 cache. So let me understand this: the analogous concept to a “victim buffer” in the disk drive case (assuming the analogy makes sense at all), would be something “glued directly” to the OS filesystem cache? That is, it would be on the main RAM side, not on the drive side? In order for the analogy to be truly analogous? Just trying to get things clear here. Because, you know, some people like to muddy the waters to distract from the fact that they don’t actually understand what’s going on.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-23 08:28 -0700 |
| Message-ID | <100q47d$3k7s2$1@dont-email.me> |
| In reply to | #111745 |
On 5/22/2025 5:18 PM, Waldek Hebisch wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote: >> On 5/13/2025 1:12 AM, Lawrence D'Oliveiro wrote: >>> On Tue, 13 May 2025 07:40:35 GMT, Anton Ertl wrote: >>> >>>> In this case the drive knows things that the OS does not: Consider that >>>> the OS asked for sector N what happens when the arm finally has settled >>>> enough to read from the track, and the first sector it sees is sector >>>> N+10. >>> >>> The OS isn’t likely to ask for one sector at a time. >> >> Frequently true, so consider this related scenario. The host requests a >> read of 10 sectors starting at sector N. When the head settles, the >> next sector is N+6. Without any in drive buffering, it would wait >> almost a full revolution till record N comes under the head. >> >> With buffering, but no cache, the drive reads record N+5 to N+9 into the >> buffer, then waits until the drive rotates to record N and begins the >> host transfer. This is an improvement because the transfer to the host >> is faster than the transfer from the disk, and the last 3 sectors can be >> transferred out of the buffer without waiting for the disk, so the >> transfer is completed faster. >> >> Now consider with caching. Similar, but after record N+9, the drive >> continues reading into the cache. Lets say there are 30 records on this >> track. If it reads all of the data into the cache, then proceeds as >> above once the disk rotates to record N, it has cost zero time, and if >> the host then issues another 10 sector read sequential to the initial >> one (or actually any sectors from N+10 to N+29). This can be satisfied >> out of the cache without any drive delay, so much faster than without >> the cache, and the heads can be moved away to start satisfying another >> unrelated request. There is minimal cost and substantial benefit. >> >> Now you have argued that the file system cache should take care of that, >> presumably issuing prefetch reads for the next sectors. This will work, >> of course, but has some disadvantages relative to using the drive cache. >> Specifically,since it is unlikely the prefetch request will be >> received by the drive before record N+10 has passed the heads, it will >> incur additional most of a rotational delay, which will tie up the >> drive, preventing it from responding to some other request. >> >> No one is arguing that host based file caches are bad. It is simply the >> fact that there are situations where drive caches are a useful addition, >> and since the drive has to have some DRAM anyway for other reasons, the >> cost is minimal. You can think of the drive cache as the "next level" >> cache behind the host based cache. > > It is pretty clear that due to drive mechanics track cache/buffer > is useful. Pretty clear to everyone except one person. :-) > However, the real question is about size: how big > should it be. For "consumer" drives I see claims of 256 MB > cache. Given rather optimistic 200 MB/s transfer rate it is > about 1.25s of drive data, that is 80-150 rotations. I would > expect that say 4 tracks should be enough for reading. For > writing one could use few more tracks. Still, advertised cache > sizes seem to be much bigger than necessary. It's not just the rotations, but the seek time. So your example is fewer "operations" than the 80-150 you get when just including rotations. And if you are caching writes, more cache gives you more blocks to choose from when optimizing the write back order, which reduces the time to write them all back. The larger DRAM is a small component of drive cost, so the manufacturers think it is worth including more. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-23 17:03 -0400 |
| Message-ID | <jwv8qmncayc.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111759 |
Stephen Fuld [2025-05-23 08:28:44] wrote:
> On 5/22/2025 5:18 PM, Waldek Hebisch wrote:
>> It is pretty clear that due to drive mechanics track cache/buffer
>> is useful.
> Pretty clear to everyone except one person. :-)
🙂
>> However, the real question is about size: how big
>> should it be. For "consumer" drives I see claims of 256 MB
>> cache. Given rather optimistic 200 MB/s transfer rate it is
>> about 1.25s of drive data, that is 80-150 rotations. I would
>> expect that say 4 tracks should be enough for reading. For
>> writing one could use few more tracks. Still, advertised cache
>> sizes seem to be much bigger than necessary.
> It's not just the rotations, but the seek time. So your example is fewer
> "operations" than the 80-150 you get when just including rotations.
I don't understand what you're getting at, here.
I think Waldek's argument is that 256MB corresponds approximately
to the amount of data stored in 80-150 tracks, and seek time doesn't
change that fact.
> And if you are caching writes, more cache gives you more blocks to choose
> from when optimizing the write back order, which reduces the time to write
> them all back.
IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so
unless the drive is allowed to do write-back caching it seems the amount
of space used for write-buffering is likely small (compared to 256MB).
[ Unless it is common for individual write commands to cover multi-MB
chunks of data? ]
> The larger DRAM is a small component of drive cost, so the
> manufacturers think it is worth including more.
In some markets (e.g. home routers), the size of DRAM seems to be enough
of a cost factor that it took many years until reaching 256MBs, even
though those boxes *need* that RAM for all kinds of purposes (the 128MB
of my current home-router seems to be its main source of instability).
but HDDs are pretty damn expensive beasts nowadays (because prices have
not gone down for the last 10 years or so), so I guess that makes
the relative cost of 512MB of DRAM "negligible"?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-24 09:23 -0700 |
| Message-ID | <100srqk$pos5$1@dont-email.me> |
| In reply to | #111768 |
On 5/23/2025 2:03 PM, Stefan Monnier wrote: > Stephen Fuld [2025-05-23 08:28:44] wrote: >> On 5/22/2025 5:18 PM, Waldek Hebisch wrote: >>> It is pretty clear that due to drive mechanics track cache/buffer >>> is useful. >> Pretty clear to everyone except one person. :-) > > 🙂 > >>> However, the real question is about size: how big >>> should it be. For "consumer" drives I see claims of 256 MB >>> cache. Given rather optimistic 200 MB/s transfer rate it is >>> about 1.25s of drive data, that is 80-150 rotations. I would >>> expect that say 4 tracks should be enough for reading. For >>> writing one could use few more tracks. Still, advertised cache >>> sizes seem to be much bigger than necessary. >> It's not just the rotations, but the seek time. So your example is fewer >> "operations" than the 80-150 you get when just including rotations. > > I don't understand what you're getting at, here. > I think Waldek's argument is that 256MB corresponds approximately > to the amount of data stored in 80-150 tracks, and seek time doesn't > change that fact. Yes, I didn't express myself well. :-( And once again, I have to say that my information may be obsolete. I think it is useful to separate talking about read data from write data. For read data, as with any cache, more is always better than less, though with diminishing returns. Why pick 1.25 sec as the "cut off point"? If the host re-references data that it hasn't read for say 3 seconds, having it in cache still saves, probably a seek time and on average 1/2 rotation time. Plus, it means the heads will be free to handle other requests. All of this is standard cache benefits. I see no reason to limit the cache size and reduce this benefit. >> And if you are caching writes, more cache gives you more blocks to choose >> from when optimizing the write back order, which reduces the time to write >> them all back. > > IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so > unless the drive is allowed to do write-back caching it seems the amount > of space used for write-buffering is likely small (compared to 256MB). > [ Unless it is common for individual write commands to cover multi-MB > chunks of data? ] For write data, I was unaware of the 32 operation limit. I was used to SCSI, which, IIRC was larger, and for server type applications, where some sort of UPS is more common, the site may choose to enable write caching in the disk. For a disk vendor, given the small cost of the DRAM, it is an easy choice. >> The larger DRAM is a small component of drive cost, so the >> manufacturers think it is worth including more. > > In some markets (e.g. home routers), the size of DRAM seems to be enough > of a cost factor that it took many years until reaching 256MBs, even > though those boxes *need* that RAM for all kinds of purposes (the 128MB > of my current home-router seems to be its main source of instability). > but HDDs are pretty damn expensive beasts nowadays (because prices have > not gone down for the last 10 years or so), so I guess that makes > the relative cost of 512MB of DRAM "negligible"? I can't comment on routers, but for disks, while the cost of the disk may not have come down, increasing capacity allows reduced cost per gigabyte. A substantial portion of the cost is not subject to Moore's law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity increasing technologies cost more (but not enough more to overwhelm the capacity advantage). -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-05-25 18:05 +0000 |
| Message-ID | <100vm4s$16av3$1@paganini.bofh.team> |
| In reply to | #111775 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
> On 5/23/2025 2:03 PM, Stefan Monnier wrote:
>> Stephen Fuld [2025-05-23 08:28:44] wrote:
>>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote:
>>>> It is pretty clear that due to drive mechanics track cache/buffer
>>>> is useful.
>>> Pretty clear to everyone except one person. :-)
>>
>> 🙂
>>
>>>> However, the real question is about size: how big
>>>> should it be. For "consumer" drives I see claims of 256 MB
>>>> cache. Given rather optimistic 200 MB/s transfer rate it is
>>>> about 1.25s of drive data, that is 80-150 rotations. I would
>>>> expect that say 4 tracks should be enough for reading. For
>>>> writing one could use few more tracks. Still, advertised cache
>>>> sizes seem to be much bigger than necessary.
>>> It's not just the rotations, but the seek time. So your example is fewer
>>> "operations" than the 80-150 you get when just including rotations.
>>
>> I don't understand what you're getting at, here.
>> I think Waldek's argument is that 256MB corresponds approximately
>> to the amount of data stored in 80-150 tracks, and seek time doesn't
>> change that fact.
>
> Yes, I didn't express myself well. :-( And once again, I have to say
> that my information may be obsolete.
>
> I think it is useful to separate talking about read data from write
> data. For read data, as with any cache, more is always better than
> less, though with diminishing returns. Why pick 1.25 sec as the "cut
> off point"? If the host re-references data that it hasn't read for say
> 3 seconds, having it in cache still saves, probably a seek time and on
> average 1/2 rotation time. Plus, it means the heads will be free to
> handle other requests. All of this is standard cache benefits. I see
> no reason to limit the cache size and reduce this benefit.
We are talking here about common case, that is when disc is accessed
via OS cache. OS cache is significantly larger than disc cache, so
hit ratio for data sent to host is going to be quite low. Disc
cache has an advantage: it gets "for free" some data that host did
not request. But it is rather unlikely that keeping such data
for long time has significant advantage.
>>> And if you are caching writes, more cache gives you more blocks to choose
>>> from when optimizing the write back order, which reduces the time to write
>>> them all back.
>>
>> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so
>> unless the drive is allowed to do write-back caching it seems the amount
>> of space used for write-buffering is likely small (compared to 256MB).
>> [ Unless it is common for individual write commands to cover multi-MB
>> chunks of data? ]
>
>
> For write data, I was unaware of the 32 operation limit. I was used to
> SCSI, which, IIRC was larger, and for server type applications, where
> some sort of UPS is more common, the site may choose to enable write
> caching in the disk. For a disk vendor, given the small cost of the
> DRAM, it is an easy choice.
I do not look at details of disc protocol. But with protocal done
right host would first transfer commands and then deliver data
in order requested by the drive. So most buffering would be in
the host and disc would need just enough buffering to ensure
smooth transmission and low interrupt rate. 4 track looks like
plenty for this purpose.
>>> The larger DRAM is a small component of drive cost, so the
>>> manufacturers think it is worth including more.
>>
>> In some markets (e.g. home routers), the size of DRAM seems to be enough
>> of a cost factor that it took many years until reaching 256MBs, even
>> though those boxes *need* that RAM for all kinds of purposes (the 128MB
>> of my current home-router seems to be its main source of instability).
>> but HDDs are pretty damn expensive beasts nowadays (because prices have
>> not gone down for the last 10 years or so), so I guess that makes
>> the relative cost of 512MB of DRAM "negligible"?
>
> I can't comment on routers, but for disks, while the cost of the disk
> may not have come down, increasing capacity allows reduced cost per
> gigabyte. A substantial portion of the cost is not subject to Moore's
> law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity
> increasing technologies cost more (but not enough more to overwhelm the
> capacity advantage).
In nineties I read that for motherboard manufactures 1 cent was
"negligible", but 10 cents was significant: In volume transactions
margins were low and no party were willing to absorb 10 cents
per piece "loss". Discs probably are less competitive than
motherboards, but I would expect adding 256 MB to lead to 1
dollar or more increase of cost.
So IMO it is highly unclear why manufacturers use large caches.
One possible explanation could be benchmarketing and using
obsolete benchmarks. Another could be inertia with customers
thinking that "larger cache is better".
Another things is fragmenting market into different "kinds" of
drives. Rationally, high performance drives should get
better mechanical parts. But in given performance area there
seem to be no reason for different mechanics, so I suspect
that they use the same. They may get different firmware.
"Green" consumer parts seem to be quite aggressive powering
down (IIUC on recent WD parts it is impossible to permanently
disable this), but beyond this it is not clear to me if there
are rational reasons for significantly different firmware.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-25 12:13 -0700 |
| Message-ID | <100vq44$1h5c4$1@dont-email.me> |
| In reply to | #111788 |
On 5/25/2025 11:05 AM, Waldek Hebisch wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote: >> On 5/23/2025 2:03 PM, Stefan Monnier wrote: >>> Stephen Fuld [2025-05-23 08:28:44] wrote: >>>> On 5/22/2025 5:18 PM, Waldek Hebisch wrote: >>>>> It is pretty clear that due to drive mechanics track cache/buffer >>>>> is useful. >>>> Pretty clear to everyone except one person. :-) >>> >>> 🙂 >>> >>>>> However, the real question is about size: how big >>>>> should it be. For "consumer" drives I see claims of 256 MB >>>>> cache. Given rather optimistic 200 MB/s transfer rate it is >>>>> about 1.25s of drive data, that is 80-150 rotations. I would >>>>> expect that say 4 tracks should be enough for reading. For >>>>> writing one could use few more tracks. Still, advertised cache >>>>> sizes seem to be much bigger than necessary. >>>> It's not just the rotations, but the seek time. So your example is fewer >>>> "operations" than the 80-150 you get when just including rotations. >>> >>> I don't understand what you're getting at, here. >>> I think Waldek's argument is that 256MB corresponds approximately >>> to the amount of data stored in 80-150 tracks, and seek time doesn't >>> change that fact. >> >> Yes, I didn't express myself well. :-( And once again, I have to say >> that my information may be obsolete. >> >> I think it is useful to separate talking about read data from write >> data. For read data, as with any cache, more is always better than >> less, though with diminishing returns. Why pick 1.25 sec as the "cut >> off point"? If the host re-references data that it hasn't read for say >> 3 seconds, having it in cache still saves, probably a seek time and on >> average 1/2 rotation time. Plus, it means the heads will be free to >> handle other requests. All of this is standard cache benefits. I see >> no reason to limit the cache size and reduce this benefit. > > We are talking here about common case, that is when disc is accessed > via OS cache. OS cache is significantly larger than disc cache, so > hit ratio for data sent to host is going to be quite low. Disc > cache has an advantage: it gets "for free" some data that host did > not request. But it is rather unlikely that keeping such data > for long time has significant advantage. > >>>> And if you are caching writes, more cache gives you more blocks to choose >>>> from when optimizing the write back order, which reduces the time to write >>>> them all back. >>> >>> IIUC, for SATA drives, NCQ is still limited to 32 in-flight commands, so >>> unless the drive is allowed to do write-back caching it seems the amount >>> of space used for write-buffering is likely small (compared to 256MB). >>> [ Unless it is common for individual write commands to cover multi-MB >>> chunks of data? ] >> >> >> For write data, I was unaware of the 32 operation limit. I was used to >> SCSI, which, IIRC was larger, and for server type applications, where >> some sort of UPS is more common, the site may choose to enable write >> caching in the disk. For a disk vendor, given the small cost of the >> DRAM, it is an easy choice. > > I do not look at details of disc protocol. But with protocal done > right host would first transfer commands and then deliver data > in order requested by the drive. So most buffering would be in > the host and disc would need just enough buffering to ensure > smooth transmission and low interrupt rate. 4 track looks like > plenty for this purpose. No, when the disk receives a write command, it accepts the write data immediately (up to some large limit). That way, when the heads settle on the track, if the disk happens to be positioned in the middle of the transfer, it can write the last part of the data to the disk immediately, then wait for the disk to spin to where the transfer starts to finish the transferring the first part of the write data. This reduces average latency, i.e. improves performance. >>>> The larger DRAM is a small component of drive cost, so the >>>> manufacturers think it is worth including more. >>> >>> In some markets (e.g. home routers), the size of DRAM seems to be enough >>> of a cost factor that it took many years until reaching 256MBs, even >>> though those boxes *need* that RAM for all kinds of purposes (the 128MB >>> of my current home-router seems to be its main source of instability). >>> but HDDs are pretty damn expensive beasts nowadays (because prices have >>> not gone down for the last 10 years or so), so I guess that makes >>> the relative cost of 512MB of DRAM "negligible"? >> >> I can't comment on routers, but for disks, while the cost of the disk >> may not have come down, increasing capacity allows reduced cost per >> gigabyte. A substantial portion of the cost is not subject to Moore's >> law (e.g. drive motor, magnets and arm assembly, etc.) and some capacity >> increasing technologies cost more (but not enough more to overwhelm the >> capacity advantage). > > In nineties I read that for motherboard manufactures 1 cent was > "negligible", but 10 cents was significant: In volume transactions > margins were low and no party were willing to absorb 10 cents > per piece "loss". Discs probably are less competitive than > motherboards, but I would expect adding 256 MB to lead to 1 > dollar or more increase of cost. I can't comment on your specific numbers, but assuming you are right, adding $1 to the cost is is small, at least in the part of the market I was familiar with. And remember, you are not "adding" 256MB, as some of that is needed for various internal operations. > So IMO it is highly unclear why manufacturers use large caches. > One possible explanation could be benchmarketing and using > obsolete benchmarks. Perhaps, but disk manufacturers are very sensitive to whatever benchmarks their customers use. > Another could be inertia with customers > thinking that "larger cache is better". Sure. > > Another things is fragmenting market into different "kinds" of > drives. Rationally, high performance drives should get > better mechanical parts. But in given performance area there > seem to be no reason for different mechanics, so I suspect > that they use the same. They may get different firmware. > "Green" consumer parts seem to be quite aggressive powering > down (IIUC on recent WD parts it is impossible to permanently > disable this), but beyond this it is not clear to me if there > are rational reasons for significantly different firmware. My knowledge is too obsolete to know about any of these, but another possibility is more extensive burn in for more expensive drives. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-25 19:36 +0000 |
| Message-ID | <1eb319f0e23c588dc4c6294fed84b2d1@www.novabbs.org> |
| In reply to | #111789 |
$1 added to a $200 drive is invisible
$1 added to a $20 drive is massive.
{at my current rate of space consumption, 1TB lasts a bit over 8 years}
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-25 21:23 -0700 |
| Message-ID | <1010qco$1r9ao$2@dont-email.me> |
| In reply to | #111790 |
On 5/25/2025 12:36 PM, MitchAlsup1 wrote:
> $1 added to a $200 drive is invisible
> $1 added to a $20 drive is massive.
>
> {at my current rate of space consumption, 1TB lasts a bit over 8 years}
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. ;^)
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-05-26 17:42 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1012965$1u7m$1@gal.iecc.com> |
| In reply to | #111805 |
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. None of them could do more than one transfer at a time but I think that was a limit of the electronics of the era, not a fundamental issue. -- 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 | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 11:16 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1012b5p$23l9s$1@dont-email.me> |
| In reply to | #111817 |
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. > None of them could do more than one transfer at a time but I > think that was a limit of the electronics of the era, not a fundamental > issue. Depends on what you mean by more than one transfer at a time. If you mean two simultaneous independent data streams to the host, that would require a second host connection. 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/ However, I think that, except for streaming applications, the bigger payoff is two simultaneous seeks. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-26 14:58 -0400 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <jwvtt575hsb.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111819 |
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?
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.
Maybe part of the gain of having two actuators is that each actuator is
a bit lighter?
Stefan
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2025-05-26 19:19 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1012esr$4ne$1@gal.iecc.com> |
| In reply to | #111820 |
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/ > >Hmmm, hard to believe it makes commercial sense: if you need higher >performance, when would this be price-competitive with 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. The data sheet says it is in effect two 7TB disks in a single enclosure. 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. -- 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 | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2025-05-26 21:52 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1013get$23l9t$5@dont-email.me> |
| In reply to | #111821 |
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/ >> >> Hmmm, hard to believe it makes commercial sense: if you need higher >> performance, when would this be price-competitive with 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. > > The data sheet says it is in effect two 7TB disks in a single enclosure. > > 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. I thought it would. I believe you about its current state, but I wonder why it wasn't more successful. It seems like a big improvement in throughput for very little extra cost. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-27 08:34 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <2025May27.103408@mips.complang.tuwien.ac.at> |
| In reply to | #111850 |
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/ [...] >I believe you about its current state, but I wonder >why it wasn't more successful. It seems like a big improvement in >throughput for very little extra cost. It seems that the technology is still on offer, e.g. https://geizhals.eu/seagate-exos-x-2x18-18tb-st18000nm0272-a2883003.html As for the price (and ignoring offers that are not in stock, or where the offers vary wildly vary): EUR Drive 427 Seagate Exos X - 2X18 18TB (2x9TB) 350 Exos X X18 18TB 440 2xToshiba N300 NAS Systems 10TB (total 20TB) 330 2xSeagate Exos E - 7E10 8TB (total 16TB) 385 10TB HDD + 8TB HDD (total 18TB) So you pay almost as much as for 2 10TB drives, but get only 2 9TB drives in one enclosure. The power consumption may be better for the 2X18 drive, though. - 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-27 07:34 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <1014ii3$23l9s$4@dont-email.me> |
| In reply to | #111853 |
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/ > [...] >> I believe you about its current state, but I wonder >> why it wasn't more successful. It seems like a big improvement in >> throughput for very little extra cost. > > It seems that the technology is still on offer, e.g. > > https://geizhals.eu/seagate-exos-x-2x18-18tb-st18000nm0272-a2883003.html > > As for the price (and ignoring offers that are not in stock, or where > the offers vary wildly vary): > > EUR Drive > 427 Seagate Exos X - 2X18 18TB (2x9TB) > 350 Exos X X18 18TB > 440 2xToshiba N300 NAS Systems 10TB (total 20TB) > 330 2xSeagate Exos E - 7E10 8TB (total 16TB) > 385 10TB HDD + 8TB HDD (total 18TB) > > So you pay almost as much as for 2 10TB drives, but get only 2 9TB > drives in one enclosure. The power consumption may be better for the > 2X18 drive, though. Thanks Anton. So cost per GB is close, but the single drive is still more expensive. :-( It should draw less power and require less cooling; one drive motor versus two, and except for the read channel, half the electronics. Slightly worse performance, as only one host transfer simultaneously. Overall, not a terrible deal, but not a great bargain. I'll bet the vendor gets better margins on it. Interesting! -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-27 16:19 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <2025May27.181954@mips.complang.tuwien.ac.at> |
| In reply to | #111855 |
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/ [...] >It should draw less power and require less cooling; >one drive motor versus two Probably not for that reason, but because with two drives there are 4 case housing walls parallel to rotating platters (resulting in more friction) rather than 2 walls for the 2x18 drive. > and except for the read channel, half the >electronics. The fact that this is presented as two drives to the system makes me suspect that the drive electronics is duplicated. - 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-27 20:57 -0700 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <10161je$23l9t$6@dont-email.me> |
| In reply to | #111857 |
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/ > [...] >> It should draw less power and require less cooling; >> one drive motor versus two > > Probably not for that reason, but because with two drives there are 4 > case housing walls parallel to rotating platters (resulting in more friction) rather than 2 walls for the 2x18 drive. > >> and except for the read channel, half the >> electronics. > > 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). It's not two separate drives because there is only one host interface. The two LUNS are like an old mainframe system where you might have a single controller with multiple drives behind it. Note the interface is SAS, which is derived from the old parallel SCSI, which supported LUNS. I may be wrong about this, but I don't believe SATA supports LUNS, but even if it does, that is still not two separate physical units. 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. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-28 07:47 +0000 |
| Subject | Re: fuzzy disks, Is Parallel Programming Hard, And, If So, What Can You Do About It? |
| Message-ID | <2025May28.094741@mips.complang.tuwien.ac.at> |
| In reply to | #111864 |
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'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. >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. 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. 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. 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. - 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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.arch
csiph-web