Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On Wed, 21 May 2025 03:41:45 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:

On Tue, 20 May 2025 18:39:54 -0700, Chris M. Thomasson wrote:
>

Processes on the same core are concurrent - processes on different
cores are parallel.

 
Only if the cores and/or "hardware threads" do not interfere with one
another?

>
That’s why I think the distinction is meaningless.
>
Yes, there is a valid distinction to be made between truly concurrent/
parallel processes/threads, and ones which are made to appear so by
preemptive scheduling on shared hardware.
>
Not sure if there is a good term for the latter: “timesliced”?
“timeshared”? “pseudoconcurrent”? “pseudoparallel”?

Yeah ... but recall that the terminology is passed down from the days
of single core, single thread CPUs.  The meanings have been bent,
spindled, and mutilated by time, and conflated in general awareness.


Multi-programming meant running multiple programs on a single CPU.
[i.e. "concurrent" programming]  Preemptive timeslicing generally was
implied, but the term itself did not distinguish how programs were
separated: e.g., programmatically (purely by software), segmented by
partition, interleaved (with or without VMM protection), etc.

Multi-processing [from multi-processor] meant running multiple
processes in parallel on separate CPUs (remember, single core, single
thread).

Multi-threading meant being able to (pseudo)simultaneously execute
along multiple "paths" within a /single/ process.  The term itself did
not distinguish whether this was done concurrently (single CPU) or in
parallel, and also did not distinguish whether scheduling was
preemtive or cooperative.

Multi-tasking was a catch-all term that could mean any combination of
the others.


Nobody cares anymore.