What Is Amdahl's Law? Parallel Speedup Explained

Amdahl’s Law is a formula that puts a hard ceiling on how much faster a program can run when you parallelize it: speedup is limited by the portion of the work that can’t be parallelized at all. If 10% of a program’s runtime is inherently sequential, no number of additional cores can ever make the whole program more than 10x faster — even with infinite parallel processing power.

The formula

Amdahl’s Law is usually written as:

Speedup = 1 / ((1 - P) + P / N)

Where P is the fraction of the program that can be parallelized, and N is the number of processors applied to that parallel portion. The (1 - P) term — the sequential fraction — never shrinks no matter how large N gets.

Push N toward infinity and the formula reduces to a hard limit: Speedup → 1 / (1 - P). If 90% of a workload is parallelizable (P = 0.9), the absolute best-case speedup is 10x, regardless of core count. If only 50% is parallelizable, the ceiling is 2x — you could have a thousand cores and never do better.

Why the sequential fraction dominates

This is the counterintuitive part: small sequential fractions have an outsized effect on the ceiling. Going from 90% to 95% parallelizable doesn’t just modestly raise the ceiling — it doubles it, from 10x to 20x. Going from 95% to 99% doubles it again, to 100x. The last few percentage points of “the part that can’t be parallelized” matter far more than the headline percentage suggests, because that fraction is the one thing more processors can never touch.

This is why real-world engineering effort on parallel systems is disproportionately spent hunting down sequential bottlenecks — a lock that serializes access, a setup step that has to run before workers can start, a single-threaded aggregation step at the end — rather than simply adding more workers. A race condition fix that adds a broad lock, for instance, can quietly shrink the parallel fraction and cap speedup far below what the hardware could otherwise deliver.

Where this shows up in practice

Amdahl’s Law was originally framed around CPU cores, but the same math applies to any system where some work must happen serially before or after parallel work can proceed:

• Multi-core CPU design. It’s part of why CPU vendors don’t just keep adding cores indefinitely — for many real workloads, the sequential portion of typical code caps the benefit long before the core count does. This is one reason chip design has also invested heavily in techniques like out-of-order execution and branch prediction, which speed up the sequential portions rather than relying purely on adding more parallel units.
• Distributed data processing. A MapReduce-style job’s “reduce” step, or any final aggregation that must wait for every parallel task to finish, is the sequential fraction. Adding more machines speeds up the “map” phase but does nothing for that final merge.
• Database and web workloads. Horizontally scaling read replicas parallelizes reads well, but a workload with heavy writes to a single primary key constrained table has a sequential bottleneck that more replicas won’t fix. See horizontal vs. vertical scaling for the broader scaling trade-off.
• SIMD and vector processing. Techniques like SIMD vectorization parallelize the arithmetic-heavy inner loop of a computation, but the code around that loop — setup, branching, I/O — still runs on the same sequential-execution ceiling Amdahl’s Law describes.

Amdahl’s Law vs Gustafson’s Law

Amdahl’s Law assumes the total amount of work is fixed and asks how much faster you can finish it. A related idea, Gustafson’s Law, flips the question: if you have more processors, you can often afford to do more work in the same amount of time, rather than the same work faster. Both are correct descriptions of different situations — Amdahl’s Law is the right lens when the problem size is fixed (finish this one job faster), and Gustafson’s is the right lens when the problem can grow to use the available hardware (process a bigger dataset in the same wall-clock time). Neither invalidates the other; they answer different questions.

Why it still matters for software engineers

You don’t need to compute the formula by hand to get value from Amdahl’s Law — the practical takeaway is a diagnostic habit. Before assuming “just add more workers” will fix a slow pipeline, ask what fraction of the critical path is genuinely parallel and what fraction is an unavoidable serial dependency: a single-threaded setup step, a shared lock, a final merge. If the sequential fraction is large, more parallelism buys little, and the higher-leverage fix is shrinking that fraction — not scaling the parallel part further.

The takeaway

Amdahl’s Law shows that a program’s maximum possible speedup from parallelization is capped by its sequential fraction, not by how much parallel hardware you throw at it. A workload that’s 90% parallelizable tops out at 10x speedup no matter how many cores you add — which is why finding and shrinking the serial bottleneck usually matters more than adding parallelism.