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 | 19 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 11 of 11 — ← Prev page 1 … 9 10 [11]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-22 02:45 +0000 |
| Message-ID | <100m345$38sd4$1@dont-email.me> |
| In reply to | #111725 |
On Wed, 21 May 2025 15:30:43 -0400, Stefan Monnier wrote: > In the case of concurrency the core question is: Given a set of somewhat > independent tasks working on some chunks of data, make sure the computed > result is correct, e.g. design tools like mutexes, memory barriers, > transactional memory, static analysis, reasoning principles, etc... > whose core focus is on making sure there's no race conditions, dead > locks, ... > > In the case of parallelism, the core question instead is: given a > program/algorithm, restructure (or even completely replace) it so as to > divide it into somewhat independent tasks that can take advantage of > multiple CPUs to finish the work faster. All those issues of race conditions, deadlocks, livelocks etc apply equally whether the concurrency/parallelism is real (multiple physical CPUs) or virtual (process preemption on shared CPUs). The difference is that different bugs in the synchronization/locking show up in different situations. This is why it is helpful to test your concurrent code in a variety of situations.
[toc] | [prev] | [next] | [standalone]
| From | Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Date | 2025-05-21 07:06 -1000 |
| Message-ID | <87v7ptopv1.fsf@localhost> |
| In reply to | #111696 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> Only if the cores and/or "hardware threads" do not interfere with one
> another? Fwiw, an example of an embarrassingly parallel algorithm is
> computing the Mandelbrot set. Actually, this reminds me of the "alias"
> problem with Intel hyper threading in the past.
shortly after graduating and joining IBM, I got roped into helping with
hyperthreading the 370/195. It had pipelined, out-of-order execution,
but conditional branches drained the pipeline and most code only ran
system had half rated throughput. Two hardware i-streams ... each
running at half throughput would (might) keep system full throughput.
hardware hyperthreading mentioned in this about Amdahl winning the
battle to make ACS, 360 compatible (folklore it was shutdown because IBM
was concerned that it would advance the state-of-the-art too fast and
IBM would loose control of the market, and Amdahl leaves IBM).
https://people.computing.clemson.edu/~mark/acs_end.html
Then decision was made to add virtual memory to all 370s, and it was
decided it would be too difficult to add it to 370/195 and all new 195
activity was shutdown (note operating system for 195 was MVT and its
shared memory multiprocessor support on 360/65MP was only getting
1.2-1.5 throughput of single processor, so running 195 with simulated
multiprocessor with two i-streams ... would only be more like .6 times
fully rated throughput (all hardware might be running at 100%, but the
SMP overhead would limit productive throughput); trivia the
multiprocessor overhead continues up throught MVS.
also after joining IBM, one of my hobbies was enhanced production
operating systems for internal datacenters and the online
sales&marketing support HONE systems were early (& long time)
customer. Then with decision to add virtual memory to all 370s, there
was also decision to do VM370 and in the morph of CP67->VM370 a lot of
things were simplified and/or dropped (including multiprocessor
support). I then start adding stuff back into VM370 and initially do
multiprocessor support for the HONE 168s so they can add 2nd processor
to all their systems (and managed to get twice single processor
throughput with some cache affinity hacks and other stuff).
In the mid-70s, after Future Systems implodes,
http://www.jfsowa.com/computer/memo125.htm
https://en.wikipedia.org/wiki/IBM_Future_Systems_project
https://people.computing.clemson.edu/~mark/fs.html
I get roped into helping with a 370 16-CPU multiprocessor design. It was
going fine until somebody tells head of POK (high end 370 processors)
that it could be decades before POK's favorite son operating system (now
"MVS") had ("effective") 16-cpu support (POK doesn't ship a 16-CPU
system until after the turn of the century) ... and some of us are
invited to never visit POK again.
--
virtualization experience starting Jan1968, online at home since Mar1970
[toc] | [prev] | [next] | [standalone]
| From | jseigh <jseigh_es00@xemaps.com> |
|---|---|
| Date | 2025-05-21 17:32 -0400 |
| Message-ID | <100lgpk$31s5l$1@dont-email.me> |
| In reply to | #111719 |
On 5/21/25 13:06, Lynn Wheeler wrote:
...
>
> I get roped into helping with a 370 16-CPU multiprocessor design. It was
> going fine until somebody tells head of POK (high end 370 processors)
> that it could be decades before POK's favorite son operating system (now
> "MVS") had ("effective") 16-cpu support (POK doesn't ship a 16-CPU
> system until after the turn of the century) ... and some of us are
> invited to never visit POK again.
>
I got the impression that MVS's processor managment was really unweildy,
the vary processor online stuff, and wasn't expected to happen more than
once after os boot.
When they put in support for multiple TOD clocks, they had to be kept in
sync. If an out of sync condition was detected, checked when bit 31 of
the clock carried out (about once per second), an external interrupt
would be raised, and you synced them back up by putting the cpu's into
set clock spin loops. In VMXA we would just signal processor them into
the sync logic. In MVS, I think they had to vary the procssor back
offline before they could do something like that. Which meant every
time a processor came online from power off state, its TOD clock was
in an unset state, cause a TOD sync ext exception, all the online
processors would have varied offline, so the sync code could be run, and
then varied online again. Repeat for every processor being brought
online from powered off state. MVS couldn't deal with it so they had
the hardware folk put in a standalone clock chip to set the processor's
clock on power on (allegedly a Timex watch chip).
So without that chip, there would always be a TOD sync exeption at boot
time. There was a Japanese data center that had the hardware console
on the opposite side of the data center instead of side by side with the
system console. So when VMXA issued the operator message to press the
enable TOD set button on the hw console, the operator barely had time
to run over the side to press it. You had 30 secs but vmxa messages
were asynchronous (and probably on the wrong side of that spin loop).
Had to futz with order of issuing that operator message.
Oh, and 370 arch stated that STCK would always be unique and monotonic
but that might not have been really true. With enough clock drift, a
lot could happen in the 1 second between TOD sync checks.
Joe Seigh
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2025-05-21 07:05 +0000 |
| Message-ID | <2025May21.090538@mips.complang.tuwien.ac.at> |
| In reply to | #111682 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Tue, 20 May 2025 20:06:13 +0000, Stefan Monnier wrote: >> FWIW, I think these kinds of things usually fall in the scope of >> concurrency rather than parallelism. > >When I run 20-copies of a FEM CFD application, each uni-process:: >am I running concurrently ?? or in parallel ?? or both ?? That's an example of an embarrasingly parallel problem, and you can run it on a machine with 20 processors or 20 machines with 1 processor each without needing any communication between the processes. Concurrency is concerned with the coordination of simultaneous processes (or threads) that need to communicate, even if it is just to coordinate the access to a shared resource. The classical example is how to coordinate the simulteous access to a bank account. If the account contains EUR 100 (and allows no overdraft), and two people want to withdraw EUR 100 from it at the same time, what happens? Concurrency is an issue already when only a single core is involved (if the account is checked before the withdrawal happens, and there can be a task switch to the other withdrawal, the account can be overdrafted; this is a classic race condition), but becomes harder when parallel hardware is involved. I have not read the book, but it seems that a more appropriate title would be "Is Concurrent Programming Hard ...". Parallel computing, OTOH seems to be more concerned with building computers with many processors that execute HPC applications quickly, and programming the HPC applications such that they make good use of these computers. That leaves the question open what HPC applications are. It's somewhat cyclic: Those that can make good use of parallel (super-)computers. The non-cyclical part is that those are applications that are important enough to someone for financing such supercomputers. The example of CFP (computational fluid dynamics) is maybe _the_ original HPC application: the nuclear weapons laboratories in the USA were the first customers of supercomputers and parallel computers. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-22 02:48 +0000 |
| Message-ID | <100m39h$38sd4$2@dont-email.me> |
| In reply to | #111706 |
On Wed, 21 May 2025 07:05:38 GMT, Anton Ertl wrote: > That leaves the question open what HPC applications are. It's somewhat > cyclic: Those that can make good use of parallel (super-)computers. What makes a supercomputer? These days, it’s a massively parallel machine. But so is a renderfarm. The difference with the super is, it has a high- speed interconnect between the processor nodes. That’s what allows it to cope with problems beyond the merely “embarrassingly parallel”, like a renderfarm. And that’s what makes it more expensive than the renderfarm.
[toc] | [prev] | [next] | [standalone]
| From | Stefan Monnier <monnier@iro.umontreal.ca> |
|---|---|
| Date | 2025-05-21 08:23 -0400 |
| Message-ID | <jwvtt5ew3wl.fsf-monnier+comp.arch@gnu.org> |
| In reply to | #111682 |
>>> Personally, I rarely use multi-threading, and when I do, it is usually
>>> in
>>> the form of using mutex locks over shared buffers.
>>> You lock the mutex if needed to copy data from one thread to another; or
>>> when doing a task that depends on the data being consistent.
>>
>> FWIW, I think these kinds of things usually fall in the scope of
>> concurrency rather than parallelism.
>
> When I run 20-copies of a FEM CFD application, each uni-process::
> am I running concurrently ?? or in parallel ?? or both ??
Both: AFAIK the choice of how to divide&spread the data and the work is
in the parallelism camp, while the choice of how to synchronize them is
in the concurrency camp.
Stefan
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-21 14:08 +0000 |
| Message-ID | <bef78de0c7ac6e7150ed593f70e54221@www.novabbs.org> |
| In reply to | #111709 |
On Wed, 21 May 2025 12:23:49 +0000, Stefan Monnier wrote: >>>> Personally, I rarely use multi-threading, and when I do, it is usually >>>> in >>>> the form of using mutex locks over shared buffers. >>>> You lock the mutex if needed to copy data from one thread to another; or >>>> when doing a task that depends on the data being consistent. >>> >>> FWIW, I think these kinds of things usually fall in the scope of >>> concurrency rather than parallelism. >> >> When I run 20-copies of a FEM CFD application, each uni-process:: >> am I running concurrently ?? or in parallel ?? or both ?? > > Both: AFAIK the choice of how to divide&spread the data and the work is > in the parallelism camp, while the choice of how to synchronize them is > in the concurrency camp. I think of it as Both--especially when affinity is not used and the processes contend for CPUs randomly. Then process[a] and process[b] are running simultaneously (different cores) they are parallel, when running back-to-back on the same core they are concurrent. > > Stefan
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-22 02:49 +0000 |
| Message-ID | <100m3cg$38sd4$3@dont-email.me> |
| In reply to | #111712 |
On Wed, 21 May 2025 14:08:37 +0000, MitchAlsup1 wrote: > ... when running back-to-back on the same core they are concurrent. Consecutively, surely (on a time-slice basis). When a judge sentences you to serve different jail terms concurrently, they are not added together. When two processes run on the same CPU, their execution times are added together.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-22 17:34 +0000 |
| Message-ID | <8d64a7052e4957a49e3708ae6493b9f8@www.novabbs.org> |
| In reply to | #111731 |
On Thu, 22 May 2025 2:49:53 +0000, Lawrence D'Oliveiro wrote: > On Wed, 21 May 2025 14:08:37 +0000, MitchAlsup1 wrote: > >> ... when running back-to-back on the same core they are concurrent. > > Consecutively, surely (on a time-slice basis). > > When a judge sentences you to serve different jail terms concurrently, > they are not added together. > > When two processes run on the same CPU, their execution times are added > together. Wall clock time adds. process times do not.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-05-22 17:42 +0000 |
| Message-ID | <WlJXP.865264$ujgb.271614@fx15.iad> |
| In reply to | #111736 |
mitchalsup@aol.com (MitchAlsup1) writes: >On Thu, 22 May 2025 2:49:53 +0000, Lawrence D'Oliveiro wrote: > >> On Wed, 21 May 2025 14:08:37 +0000, MitchAlsup1 wrote: >> >>> ... when running back-to-back on the same core they are concurrent. >> >> Consecutively, surely (on a time-slice basis). >> >> When a judge sentences you to serve different jail terms concurrently, >> they are not added together. >> >> When two processes run on the same CPU, their execution times are added >> together. > >Wall clock time adds. >process times do not. Angels. Pins. Given that the two processes are effectively interleaved, the two problems solved by the individual processes are solved concurrently. If one ran to completion before the other started, then they'd be considered consecutive. Hyperthreading allows instruction level concurrency between independent processes assigned to the same core.
[toc] | [prev] | [next] | [standalone]
| From | mitchalsup@aol.com (MitchAlsup1) |
|---|---|
| Date | 2025-05-23 01:54 +0000 |
| Message-ID | <cfaaaeda3027719c1ce749b419c5008a@www.novabbs.org> |
| In reply to | #111737 |
On Thu, 22 May 2025 17:42:14 +0000, Scott Lurndal wrote: > mitchalsup@aol.com (MitchAlsup1) writes: >>On Thu, 22 May 2025 2:49:53 +0000, Lawrence D'Oliveiro wrote: >> >>> On Wed, 21 May 2025 14:08:37 +0000, MitchAlsup1 wrote: >>> >>>> ... when running back-to-back on the same core they are concurrent. >>> >>> Consecutively, surely (on a time-slice basis). >>> >>> When a judge sentences you to serve different jail terms concurrently, >>> they are not added together. >>> >>> When two processes run on the same CPU, their execution times are added >>> together. >> >>Wall clock time adds. >>process times do not. > > Angels. > Pins. > > Given that the two processes are effectively interleaved, the two > problems > solved by the individual processes are solved concurrently. > > If one ran to completion before the other started, then they'd be > considered > consecutive. > > Hyperthreading allows instruction level concurrency between independent > processes assigned to the same core. Same physical core, different virtual core.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-22 22:42 +0000 |
| Message-ID | <100o99a$3mk15$5@dont-email.me> |
| In reply to | #111736 |
On Thu, 22 May 2025 17:34:08 +0000, MitchAlsup1 wrote: >> When two processes run on the same CPU, their execution times are added >> together. > > Wall clock time adds. process times do not. While the process is current, execution time accumulates according to wall-clock time. Isn’t that the definition of execution time?
[toc] | [prev] | [next] | [standalone]
| From | George Neuner <gneuner2@comcast.net> |
|---|---|
| Date | 2025-05-22 23:47 -0400 |
| Message-ID | <kgrv2ktlq1k0a6beadhc85s7a8osgk9kdj@4ax.com> |
| In reply to | #111731 |
On Thu, 22 May 2025 02:49:53 -0000 (UTC), Lawrence D'Oliveiro <ldo@nz.invalid> wrote: >On Wed, 21 May 2025 14:08:37 +0000, MitchAlsup1 wrote: > >> ... when running back-to-back on the same core they are concurrent. > >Consecutively, surely (on a time-slice basis). "consecutively" implies serially and running to completion. Not sure of a better term ... maybe "adjacently"? >When a judge sentences you to serve different jail terms concurrently, >they are not added together. Different domain - terminology not relevant. >When two processes run on the same CPU, their execution times are added >together. Depends on the context: if you want to know how long until both are complete, then yes. If you want to know when the 1st completes - or alternatively when the 2nd one begins, then the answer depends on whether they are run serially (consecutively ;-) or concurrently (interleaved).
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-21 00:32 +0000 |
| Message-ID | <100j6vc$2fqhj$10@dont-email.me> |
| In reply to | #111680 |
On Tue, 20 May 2025 16:06:13 -0400, Stefan Monnier wrote: > FWIW, I think these kinds of things usually fall in the scope of > concurrency rather than parallelism. I have no idea what the difference is supposed to be; as far as I’m concerned, they’re synonyms.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-20 18:29 -0700 |
| Message-ID | <100jaa7$2g8o9$2@dont-email.me> |
| In reply to | #111686 |
On 5/20/2025 5:32 PM, Lawrence D'Oliveiro wrote: > On Tue, 20 May 2025 16:06:13 -0400, Stefan Monnier wrote: > >> FWIW, I think these kinds of things usually fall in the scope of >> concurrency rather than parallelism. > > I have no idea what the difference is supposed to be; as far as I’m > concerned, they’re synonyms. Think of a single lock-free algorithm, say a queue, that is servicing multiple threads. Well, that takes away from an embarrassingly parallel algorithm, vs one queue per thread. Even if after a thread obtains work from said queue and can operate in parallel on it independently, that single queue causes the overall operation to not be embarrassingly parallel anymore. Not sure if that helps with your question, but it's just my view...
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-20 18:04 -0700 |
| Message-ID | <100j8rm$2g8o9$1@dont-email.me> |
| In reply to | #111677 |
On 5/20/2025 11:19 AM, BGB wrote: > On 5/20/2025 8:53 AM, Scott Lurndal wrote: >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>> On Mon, 19 May 2025 21:33:11 +0000, quadibloc wrote: >>> >>>> Parallel programming isn't "hard" or "easy". >>> >>> Concurrent processes/threads, running either fully concurrently on >>> separate processors, or with asynchronous preemption on shared >>> processors, >>> are hard to program. >> >> Clearly you are someone who has never done it. > > In my case... > > Personally, I rarely use multi-threading, and when I do, it is usually > in the form of using mutex locks over shared buffers. > > You lock the mutex if needed to copy data from one thread to another; or > when doing a task that depends on the data being consistent. > > > Ironically, this is something that fairly easily maps onto a weak memory > model. > > And is easily adapted to networked shared memory approaches as well; > except that a shared-memory-system mutex is almost impractically > expensive, and it may make sense to have multiple types of mutex in this > case with more limited scope, say, to avoid needing to forcibly > synchronize "everything". > > > And, it almost seems like the solution to a lot of these "problems" > would be more "have everyone assume that weak consistency as the > default" rather than "make every CPU and every piece of hardware obey > cache coherence". > > Or, IOW, Unless you lock the mutex, you have no idea whether the shared > writable data is up-to-date. Only shared read-only data is "safe" to be > accessed freely, after any initial synchronization is done. Are you familiar with lock and/or wait free algorithms?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-22 16:49 -0700 |
| Message-ID | <100od5j$3nj0g$1@dont-email.me> |
| In reply to | #111691 |
On 5/20/2025 6:04 PM, Chris M. Thomasson wrote: > On 5/20/2025 11:19 AM, BGB wrote: >> On 5/20/2025 8:53 AM, Scott Lurndal wrote: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Mon, 19 May 2025 21:33:11 +0000, quadibloc wrote: >>>> >>>>> Parallel programming isn't "hard" or "easy". >>>> >>>> Concurrent processes/threads, running either fully concurrently on >>>> separate processors, or with asynchronous preemption on shared >>>> processors, >>>> are hard to program. >>> >>> Clearly you are someone who has never done it. >> >> In my case... >> >> Personally, I rarely use multi-threading, and when I do, it is usually >> in the form of using mutex locks over shared buffers. >> >> You lock the mutex if needed to copy data from one thread to another; >> or when doing a task that depends on the data being consistent. >> >> >> Ironically, this is something that fairly easily maps onto a weak >> memory model. >> >> And is easily adapted to networked shared memory approaches as well; >> except that a shared-memory-system mutex is almost impractically >> expensive, and it may make sense to have multiple types of mutex in >> this case with more limited scope, say, to avoid needing to forcibly >> synchronize "everything". >> >> >> And, it almost seems like the solution to a lot of these "problems" >> would be more "have everyone assume that weak consistency as the >> default" rather than "make every CPU and every piece of hardware obey >> cache coherence". >> >> Or, IOW, Unless you lock the mutex, you have no idea whether the >> shared writable data is up-to-date. Only shared read-only data is >> "safe" to be accessed freely, after any initial synchronization is done. > > Are you familiar with lock and/or wait free algorithms? > wrt lock/wait-free, a song: lol! https://youtu.be/lcOxhH8N3Bo?list=RDa7Tuta8aOhs
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-22 18:04 -0700 |
| Message-ID | <100ohid$3o8ct$1@dont-email.me> |
| In reply to | #111744 |
On 5/22/2025 4:49 PM, Chris M. Thomasson wrote: > On 5/20/2025 6:04 PM, Chris M. Thomasson wrote: >> On 5/20/2025 11:19 AM, BGB wrote: >>> On 5/20/2025 8:53 AM, Scott Lurndal wrote: >>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>>> On Mon, 19 May 2025 21:33:11 +0000, quadibloc wrote: >>>>> >>>>>> Parallel programming isn't "hard" or "easy". >>>>> >>>>> Concurrent processes/threads, running either fully concurrently on >>>>> separate processors, or with asynchronous preemption on shared >>>>> processors, >>>>> are hard to program. >>>> >>>> Clearly you are someone who has never done it. >>> >>> In my case... >>> >>> Personally, I rarely use multi-threading, and when I do, it is >>> usually in the form of using mutex locks over shared buffers. >>> >>> You lock the mutex if needed to copy data from one thread to another; >>> or when doing a task that depends on the data being consistent. >>> >>> >>> Ironically, this is something that fairly easily maps onto a weak >>> memory model. >>> >>> And is easily adapted to networked shared memory approaches as well; >>> except that a shared-memory-system mutex is almost impractically >>> expensive, and it may make sense to have multiple types of mutex in >>> this case with more limited scope, say, to avoid needing to forcibly >>> synchronize "everything". >>> >>> >>> And, it almost seems like the solution to a lot of these "problems" >>> would be more "have everyone assume that weak consistency as the >>> default" rather than "make every CPU and every piece of hardware obey >>> cache coherence". >>> >>> Or, IOW, Unless you lock the mutex, you have no idea whether the >>> shared writable data is up-to-date. Only shared read-only data is >>> "safe" to be accessed freely, after any initial synchronization is done. >> >> Are you familiar with lock and/or wait free algorithms? >> > > wrt lock/wait-free, a song: lol! > > https://youtu.be/lcOxhH8N3Bo?list=RDa7Tuta8aOhs > > After you get a working spicy complex algo, ready to go. (Charli XCX - Speed Drive (From Barbie The Album) [Official Audio]) https://youtu.be/TxZwCpgxttQ ;^D
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-05-20 18:31 -0700 |
| Message-ID | <100jaec$2ghvk$1@dont-email.me> |
| In reply to | #111589 |
On 5/10/2025 4:38 AM, Thomas Koenig wrote: > For those who don't know it: This it the title of a book on, > you guessed it, parallel programming (the "perfbook"), from the > perspective of a Linux developer, Paul E. McKenney. > > https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html > > Much of it should be familiar to many contributors to comp.arch, > but certainly not everything will be familiar to everyone (if I > take myself as an example). It also contains a little appendix > entitled "Advice to Hardware Designers", which is interesting. The fun part about RCU is that the readers do not have to be dependent on the writers and vise versa. The readers can go full steam ahead, without giving a crap about what the writers are doing. However, this is useful in certain types of scenarios. It's not a silver bullet.
[toc] | [prev] | [standalone]
Page 11 of 11 — ← Prev page 1 … 9 10 [11]
Back to top | Article view | comp.arch
csiph-web