Home/Labs/Concurrency, Parallelism & Amdahl
All 280 Labs
INTERACTIVE LAB🤹

Concurrency vs Parallelism Lab (Interactive)

Slide parallel fraction and core count to find Amdahl’s speedup ceiling. Separate structure from execution: how many tasks are in flight versus truly simultaneous, and why serial fractions cap multi-core scaling.

Concurrency vs Parallelism & Amdahl's Law Simulator

“Dealing with lots of things at once” vs “doing lots of things at once” — and the serial-fraction ceiling on scaling.

90%

Serial part (locks, consensus, WAL): 10%

8
1,000
Amdahl speedup
4.71×
Hard speedup ceiling
10.0×
Core efficiency
59%
Wall-clock runtime
4250 ms

Speedup vs Core Count — S = 1 / ((1−p) + p/s)

1 cores
1.00×
2 cores
1.82×
4 cores
3.08×
8 cores
4.71×
16 cores
6.40×
32 cores
7.80×
64 cores
8.77×
128 cores
9.34×

Concurrency (structure): 1,000 tasks are “in flight” at once — an event loop interleaves them during I/O waits, even on 1 core.

Parallelism (execution): exactly 8 instruction streams run at the same physical instant (min(tasks, cores)).

Single-core baseline 20000 ms → 8-core wall time 4250 ms. Even with 128 cores, 10% serial work caps you at 10.0×.

How It Works Under the Hood

Rob Pike’s distinction: concurrency is dealing with lots of things at once (structure, works on one core via time-slicing), parallelism is doing lots of things at once (execution, needs physical cores). I/O-bound APIs spend 95% waiting and profit from concurrency; CPU-bound transcoding only speeds up with cores. Amdahl’s Law S = 1/((1-p) + p/s) proves the serial fraction — locks, consensus, WAL writes — hard-caps speedup no matter how many servers you buy.

Core Architectural Principles

  • Speedup ceiling equals 1/(1-p): 5% serial code caps even a 1,000-core machine at 20x.
  • Tasks in flight (concurrency) can exceed cores; simultaneously executing streams cannot.
  • I/O-bound workloads scale with event loops; CPU-bound workloads scale only with cores.
Interview Round Script

Use Amdahl when a interviewer proposes "add more servers": "if coordination through a single database lock is 10% of the path, no cluster size gives more than 10x — remove the serial bottleneck first." Quote Rob Pike verbatim, then contrast Node’s single-threaded concurrency with Go’s M:N parallel scheduler.

Key Trade-Offs

Concurrency handles vast numbers of waiting tasks cheaply, but true parallel speedups are permanently bounded by the serial fraction of the system.

Related Curriculum Chapter

Concurrency vs Parallelism

Read Full Chapter Blueprint

Explore More Interactive Labs

View All 280 Labs