Speedup with N workers is S(N) = 1 / (s + (1−s)/N), where s is the fraction of work that cannot be done in parallel. As N → ∞ the limit is 1/s: 5% serial code means a ×20 ceiling, no matter how many cores, nodes or workers you add.
| Serial fraction s | 8 workers | 64 workers | 1,024 workers | Ceiling 1/s |
|---|---|---|---|---|
| 1 % | ×7.5 | ×39.3 | ×91.2 | ×100 |
| 5 % | ×5.9 | ×15.4 | ×19.6 | ×20 |
| 10 % | ×4.7 | ×8.8 | ×9.9 | ×10 |
| 25 % | ×2.9 | ×3.8 | ×4.0 | ×4 |
The argument is Gene Amdahl’s, “Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities” (AFIPS Spring Joint Computer Conference, 1967). The paper itself contains no equation; it argues in prose that the sequential overhead of data management bounds what parallel machines can deliver, and the formula above is the later, standard reading of that argument. Read the table by columns: going from 64 to 1,024 workers buys almost nothing once s is 5 % or more.
The practical value is not the formula but that it forces you to name s. In services the serial fraction almost never looks like a “single-threaded section of code”: it is the single writer, a global lock, an auto-increment key, transaction coordination, the leader in a quorum, a shared rate limiter, the one partition a hot key converges on. Until that fraction is found and measured, horizontal scaling is buying cores under a ceiling someone else calculated.
The law is derived for a fixed problem size, and that is its limit. Gustafson’s counterpoint: if the amount of work grows along with resources (more data, higher resolution, a wider window), the serial fraction shrinks, and the practical gain behaves better than the formula promises. Both statements are true and answer different questions: “how many times faster is the same problem” and “how much bigger a problem can be handled in the same time.” What Amdahl’s law does not describe at all is the performance drop caused by coordination itself; USL (38) adds that.
A data-pipeline example. A Spark job runs 20 minutes on 16 executors; 2 minutes of it is the driver collecting results and writing one output file. Even with unlimited executors the job cannot finish in under 2 minutes, and doubling the cluster saves at most 9. The money is in the serial part: write in parallel, partitioned output, or drop the collect.