Thread

Book review: Is parallel programming hard, and, if so, what can you do about it?

149 points · 66 comments · ahelwer

criddell · 1790278663 · focus · HN ↗
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.
1. ahelwer · 1790279929 · focus · HN ↗
  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: <a href="https://news.ycombinator.com/item?id=36318280">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.
  1. Dylan16807 · 1790333666 · focus · HN ↗
    It's really important to get people to recognize that concurrency can happen on a single core or a single task-switching thread. You don't necessarily need to split off parallelism to explain that, but it helps.
    And it's worth talking about how you can have a single task run in a parallel way, for varying strictness of 'single'.
    Coroutines and SIMD are far enough apart that their execution models should have different words.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.