Thread

1. 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:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36318280">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=36318280

      In the end I don&#x27;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&#x27;s how deterministic simulation testing implementations like Antithesis and record &amp; replay implementations like Mozilla&#x27;s rr operate). But there isn&#x27;t some deep conceptual unlock you get by having a strict conceptual boundary between concurrency and parallelism.

      1. Athas · 1790281604 · focus · HN ↗

         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.

         1. convolvatron · 1790298005 · focus · HN ↗

            I don&#x27;t like the essential characteristic of concurrency being nondeterminism. its really that multiple processes are running concurrently. if we don&#x27;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.

            1. gpderetta · 1790326078 · focus · HN ↗

               deterministic scheduling is possible, but most theoretical concurrency models assume non-determinism.

               And even with deterministic scheduling, concurrency might be dictated by external stimuli (for example request arrival) that are not deterministic.

               1. convolvatron · 1790356915 · focus · HN ↗

                  Im not saying arrival order isn&#x27;t a key consequence of concurrency in many cases, it&#x27;s just not the same as concurrency itself. I guess the point for me is that when we&#x27;re programming or when we&#x27;re using models, we define the partial ordering. so if an event arrives from outside and causes a message to be put in the queue, the read of that event by another thread is still after the external event.

                  so our job is really to kind of look at all the possible topological sorts of that &#x27;after&#x27; ordering, and ensure that they are all correct, and if not, add additional edges by using locks or whatever mechanism.

                  kind of more interested are techniques like mvcc and crdt, which make _any_ causal ordering of events (topo sort) result in a meaningful answer.

                  but if you look at classical simd for example, we have concurrency (and parallelism) without additional constraints, because the threads are strongly synchronized at the hardware level.

                  1. gpderetta · 1790679611 · focus · HN ↗

                     I would say that classical simd with explicit vector registers is plain parallelism, not concurrency. You can build concurrent abstractions on top of it (ISPC, any of the high level GPU languages), but when you move beyond simple simd hardware and have multiple hardware threads executing simd groups on multiple cpus, possibly with the ability to migrate threads between groups, the strong synchronization is a bit lost. But I&#x27;ll admit I&#x27;m not an expert.

Unofficial Hacker News client; not affiliated with Y Combinator.