Rendered at 01:32:23 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
cbm-vic-20 6 hours ago [-]
Should have been titled "Is Parallel Programming What Can You Hard, And, If So, Do About It?"
2 hours ago [-]
crooked-v 4 hours ago [-]
Don't dead, open inside.
ozarkerD 6 hours ago [-]
world! hello
igsomething 5 hours ago [-]
I do agree with your comment.
not not
mlvljr 3 hours ago [-]
[dead]
criddell 6 hours ago [-]
This review seems to equate parallelism and concurrency as the same thing and they are not.
As I understand it, the parallelism is about task execution and concurrency is about task structure. Or, as Rob Pike said:
"Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."
He said that in his Concurrency is not Parallelism talk.
Jtsummers 6 hours ago [-]
That's a useful interpretation of the two terms, but it's far from universal and the two have often been used fairly interchangeably over the decades. It's been much more useful as a distinction when someone discussing it announces that that is how they're separating the two concepts, instead of trying to force other people to adopt that particular pair of definitions.
mkehrt 3 hours ago [-]
As other comments have pointed out, this is just not true in general usage.
When I was a grad student studying this stuff (~20 years ago), we used "parallelism" to mean running on different cores at the same time and "concurrency" to mean preemptive multithreading on a single processor.
wiml 2 hours ago [-]
That's the same distinction, made in the same way, isn't it?
mkehrt 1 hours ago [-]
Well, we were using it to talk about things like cache invalidation and lax memory models rather than properties of algorithms.
Jtsummers 2 hours ago [-]
Pretty much, yes.
2 hours ago [-]
ahelwer 6 hours ago [-]
That battle has unfortunately been lost and different sources give different definitions, often exactly swapped. This was discussed in one of the HN posts linked in the article: https://news.ycombinator.com/item?id=36318280
In the end I don't think it is too much of an issue. What confusion is really brought by conflating parallelism and concurrency? Sure, concurrent programs can be serialized onto a single core (that's how deterministic simulation testing implementations like Antithesis and record & replay implementations like Mozilla's rr operate). But there isn't some deep conceptual unlock you get by having a strict conceptual boundary between concurrency and parallelism.
Athas 5 hours ago [-]
I think there is a deep conceptual unlock: concurrency is about semantics, whilst parallelism is an operational property. I use this distinction a lot in my own work. Concurrent programming primitives are inherently non-deterministic (and usually about handling non-deterministic events), on top of which we must then establish some kind of properties (sometimes determinism to some extent). Many interesting parallel operations are however completely deterministic, and the fact that they are parallel is a property of their assigned cost model (and hopefully implementation, in practice).
I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.
convolvatron 32 minutes ago [-]
I don't like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don't have serializing operations, we have arbitrary execution order. but if we do then we can introduce the necessary determinism while still being (largely) concurrent in evaluation. and if those logically concurrent processes are physically concurrent then we have parallelism. so the first is necessary but not sufficient for the latter.
so I find saying that we have one or the other to pretty misleading.
jerf 5 hours ago [-]
Personally I think it's not a good idea to think too rigidly about and try to draw a huge distinction between the two. They're on a continuum and sometimes I'd say some things aren't even strictly speaking "between" them either. Sitting down and trying to classify code into "parallel" and "concurrent" is as likely to do harm as to do any good.
5 hours ago [-]
bolangi 4 hours ago [-]
The Raku language (formerly Perl 6) and its underlying VM has features to support parallel programming, concurrency and asynchrony, designed to make common cases relatively easy to code and avoid pitfalls.
Jonathan Worthington, the author of the VM and these features, has given an excellent presentation on the concepts and their implementation.
I would probably recommend the art of multiprocessor programming (herlihy and shavitz) as a good starting point for concurrent programming. There is also " A primer on memory consistency and cache coherence" (Nagarajan et al) if you want to get more into the interaction between memory consistency and coherence.
Mbarley 1 hours ago [-]
Debugging race conditions feels like chasing ghosts; often makes me just reach for a message queue.
theendisney 3 hours ago [-]
Give each dev their own core.
thomasahle 6 hours ago [-]
Parallel programming is a great application for LLM correctness proofs in Lean.
You can't unit test your way out, but if you care about the code's correctness, today there's a way.
vitalnodo 3 hours ago [-]
As I found out recently, there's a lighter option: model checkers like Spin. You describe your synchronization logic in a small modeling language (Promela), and Spin tries every possible interleaving of that model.
tintor 6 hours ago [-]
Mix of different types of tests helps.
Best examples are SQLite and Jepsen test suites for dbms engines.
My experience has been the opposite. If lean had linear types (or separation types), it would be, but as it is, Lean's just a little bit too focused on talking about results to tidily talk about how those results are computed.
raheemm 4 hours ago [-]
Even though I'm not a programmer I really enjoyed reading this book review.
kazinator 7 hours ago [-]
Nope! Parallel programming is all yahoo, wee, look at that go!
Then comes the parallel debugging.
Pretty soon it's 15 years later, different person, yahoo-wee bro having long moved on.
7 hours ago [-]
drnick1 5 hours ago [-]
What can you do about it?
Ask Claude, which has read all the existing literature on parallel programming, to make the program faster.
not not
As I understand it, the parallelism is about task execution and concurrency is about task structure. Or, as Rob Pike said:
"Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."
He said that in his Concurrency is not Parallelism talk.
When I was a grad student studying this stuff (~20 years ago), we used "parallelism" to mean running on different cores at the same time and "concurrency" to mean preemptive multithreading on a single processor.
In the end I don't think it is too much of an issue. What confusion is really brought by conflating parallelism and concurrency? Sure, concurrent programs can be serialized onto a single core (that's how deterministic simulation testing implementations like Antithesis and record & replay implementations like Mozilla's rr operate). But there isn't some deep conceptual unlock you get by having a strict conceptual boundary between concurrency and parallelism.
I agree that this distinction is hardly universal, but it seems to be growing increasingly established, and I think it is worth fighting for it.
so I find saying that we have one or the other to pretty misleading.
Jonathan Worthington, the author of the VM and these features, has given an excellent presentation on the concepts and their implementation.
https://www.youtube.com/watch?v=JpqnNCx7wVY
You can't unit test your way out, but if you care about the code's correctness, today there's a way.
Best examples are SQLite and Jepsen test suites for dbms engines.
https://jepsen.io/
Then comes the parallel debugging.
Pretty soon it's 15 years later, different person, yahoo-wee bro having long moved on.
Ask Claude, which has read all the existing literature on parallel programming, to make the program faster.