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. Jtsummers · 1790279871 · focus · HN ↗

      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.

      1. packetlost · 1790306926 · focus · HN ↗

         Frankly the software industry suffers heavily from a lack in standardized terminology. The precise definition of parallelism vs concurrency is one that I think is incredibly important. You are doing your peers a disservice by using them interchangeably, they are not.
      2. miki123211 · 1790325938 · focus · HN ↗

         You can have parallelism without much concurrency. Think parsing a bunch of files, where you have a `fn parse(path) -> AST` which does not rely on global state. Parallelizing something like this is trivial, with no mutexes in sight, and can be great for performance in many situations.

         On the other hand, you can have concurrency without parallelism. Think a database where IO is the bottleneck, and you have multiple clients doing reading and writing at all once, potentially to the same table, in isolated transactions, on different db nodes which have to communicate. That's a lot of concurrency and nasty locks, even if you're running on a single core and wouldn't get much of a speedup from doing otherwise.

Unofficial Hacker News client; not affiliated with Y Combinator.