5 ms·

Yet another blog post about how parallelism is not concurrency

38 points by dbaupp 11y ago

_nato_ 11y ago
For me, these drawings made it quite clear what the differences were: http://joearms.github.io/2013/04/05/concurrent-and-parallel-programming.html http://joearms.github.io/2013/04/05/concurrent-and-parallel-...
- sean-duffy 11y ago
  That example is not correct, a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy.
  - simoncion 11y ago
    > ...a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy. How do you figure? From TFA: > A lot of software systems are useful to reason about as having multiple threads of control — for instance, separate clients connecting to a server, or separate UI widgets. Programs that are organized this way exhibit concurrency. The fact that multiple threads of control are a good way of organizing and reasoning about certain programs is orthogonal to whether those programs are running on one processor core or four or 1000. One queue of people executing the "get espresso from the coffee machine" routine and another queue executing the "get drip coffee from the coffee machine" routine seems like concurrency to me. Two different routines are competing for the use of a single resource, but neither routine needs to know about the other -if we presume that there's a work scheduling system in place-. What's more, this trivially gives way to parallelism: add another coffee machine (which is analogous to another CPU core) and assign one of the queues to that machine. BAM! Instant parallelism. What am I misunderstanding here?
- Sanddancer 11y ago
  It's more complicated than that, but the pic could be a decent starting point. Concurrency is the person waiting in the line pulling out their cell phone and checking their email while they're waiting for their turn at the coffee machine. The get_coffee thread is scheduled, but blocked, so the person waiting is handling the check_email thread. They can only do one thing at a time, but that one thing can swap in and out as situations change.
pcwalton 11y ago
I like this article especially because it doesn't take sides, unlike many others. Concurrency is not "better" than parallelism, and parallelism is not "better" than concurrency. Sometimes you want concurrency because you want to interleave operations, and sometimes you want parallelism because you want stuff to go faster, and sometimes you want both.
tbrownaw 11y ago
concurrency: pretending to do multiple things at the same time parallelism: actually doing multiple things at the same time Mostly, the distinction is useful if you want to paper over slow I/O without making sure your algorithms can actually run efficiently spread over multiple cores.
- adrusi 11y ago
  Concurrency isn't pretending to do multiple things at the same time, it's the concept of multiple things happening at once. Concurrency doesn't necessarily involve parallel computation. Concurrency is just when you think about something as multiple things happening at once. This includes parallel computation, as well as premptive multitasking on a single CPU, as well as cooperative multitasking (including in green threads). It also includes coroutines, and the notion of an "iterator". Arguably dealing with time is also concurrency because it weave your program's thread of execution with the thread of time.

38 points by dbaupp 11y ago

For me, these drawings made it quite clear what the differences were: http://joearms.github.io/2013/04/05/concurrent-and-parallel-programming.html http://joearms.github.io/2013/04/05/concurrent-and-parallel-...

sean-duffy 11y ago
That example is not correct, a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy.
- simoncion 11y ago
  > ...a key concept in concurrency is that it gives way to potential parallelism, but this does not follow from the queues and coffee machines analogy. How do you figure? From TFA: > A lot of software systems are useful to reason about as having multiple threads of control — for instance, separate clients connecting to a server, or separate UI widgets. Programs that are organized this way exhibit concurrency. The fact that multiple threads of control are a good way of organizing and reasoning about certain programs is orthogonal to whether those programs are running on one processor core or four or 1000. One queue of people executing the "get espresso from the coffee machine" routine and another queue executing the "get drip coffee from the coffee machine" routine seems like concurrency to me. Two different routines are competing for the use of a single resource, but neither routine needs to know about the other -if we presume that there's a work scheduling system in place-. What's more, this trivially gives way to parallelism: add another coffee machine (which is analogous to another CPU core) and assign one of the queues to that machine. BAM! Instant parallelism. What am I misunderstanding here?
Sanddancer 11y ago
It's more complicated than that, but the pic could be a decent starting point. Concurrency is the person waiting in the line pulling out their cell phone and checking their email while they're waiting for their turn at the coffee machine. The get_coffee thread is scheduled, but blocked, so the person waiting is handling the check_email thread. They can only do one thing at a time, but that one thing can swap in and out as situations change.

pcwalton 11y ago

I like this article especially because it doesn't take sides, unlike many others. Concurrency is not "better" than parallelism, and parallelism is not "better" than concurrency. Sometimes you want concurrency because you want to interleave operations, and sometimes you want parallelism because you want stuff to go faster, and sometimes you want both.

tbrownaw 11y ago

concurrency: pretending to do multiple things at the same time parallelism: actually doing multiple things at the same time Mostly, the distinction is useful if you want to paper over slow I/O without making sure your algorithms can actually run efficiently spread over multiple cores.

adrusi 11y ago
Concurrency isn't pretending to do multiple things at the same time, it's the concept of multiple things happening at once. Concurrency doesn't necessarily involve parallel computation. Concurrency is just when you think about something as multiple things happening at once. This includes parallel computation, as well as premptive multitasking on a single CPU, as well as cooperative multitasking (including in green threads). It also includes coroutines, and the notion of an "iterator". Arguably dealing with time is also concurrency because it weave your program's thread of execution with the thread of time.