Concurrency vs Parallelism

Two words, two different things

CONCURRENCY                          PARALLELISM
-----------                          -----------
About STRUCTURE                      About EXECUTION
"How my program is organized"        "What's actually running right now"
Tasks can take turns on 1 core       Tasks really run at the same instant
                                     on different hardware

A program can be:

• Concurrent on one core (tasks take turns; asyncio, Python with the GIL).
• Parallel without much concurrency (a SIMD matrix multiply).
• Both at once (a multi-threaded web server on multiple cores).

A picture

In each picture below, read each vertical column top to bottom: that column shows what is running on every core at that wall-clock instant.

ONE CORE: Concurrency only

Wall clock -------------------------------------->

Task A:  ███ ░░░ ░░░ ███ ░░░ ░░░ ███ ░░░ ░░░
Task B:  ░░░ ███ ░░░ ░░░ ███ ░░░ ░░░ ███ ░░░
Task C:  ░░░ ░░░ ███ ░░░ ░░░ ███ ░░░ ░░░ ███

           ███ = running on the core
           ░░░ = waiting its turn

  At every column, exactly ONE task has ███. The OS rotates the
  three tasks through the single core. The user feels concurrency,
  but only 1 task is actually executing at any wall-clock instant.


FOUR CORES: Concurrency + Parallelism

Wall clock -------------------------------------->

Core 0:  ███ ███ ███ ███ ███ ███ ███ ███ ███   (Task A)
Core 1:  ███ ███ ███ ███ ███ ███ ███ ███ ███   (Task B)
Core 2:  ███ ███ ███ ███ ███ ███ ███ ███ ███   (Task C)
Core 3:  ███ ███ ███ ███ ███ ███ ███ ███ ███   (Task D)

  At every column, FOUR tasks have ███. They really do run at
  the same wall-clock instant on different physical cores.
  That's parallelism.

The kitchen analogy: one chef switching between three dishes is concurrent. Three chefs each cooking one dish is parallel. Three chefs each rotating across three dishes is both.

Why people confuse them and pay for it

Most "make this faster with threads" instincts are wrong because the developer mixed up the two. Adding threads to Python CPU code makes it slower (the GIL serializes execution; the result is concurrency overhead with no parallel speedup). Spinning up 10,000 goroutines for CPU-bound work doesn't help past the core count. async/await provides concurrency but zero parallel speedup.

The single test

Ask: "At any given instant, how many tasks are executing CPU instructions?"

• One = concurrency only.
• N = parallelism. (And if the code is structured for it, concurrency is present too.)

When to reach for what

How this changes the code

• Concurrency forces designs around coordination: shared state, channels, locks, cancellation.
• Parallelism forces designs around data dependencies: what must happen before what; can the work be split into independent shards.

The two design conversations are different. A good interviewer probes both, "how do these tasks share state?" (concurrency) and "what's the speedup with more cores?" (parallelism).