Amdahl's Law Calculator
How much faster will more cores really make your program? Enter the parallel fraction and core count to get the theoretical speedup — then solve backwards for the cores you need or the parallel fraction your code actually achieved. Compare against Gustafson's law, visualize the diminishing-returns curve, model parallel overhead, and find the cost-optimal core count.
Two-way Amdahl solver
What is Amdahl's law?
In 1967, IBM computer architect Gene Amdahl presented a short argument at the AFIPS Spring Joint Computer Conference that became one of the most quoted formulas in parallel computing. His point was simple: every program has a part that cannot be parallelized — startup, file I/O, synchronization, inherently sequential logic — and that serial part caps the speedup no matter how many processors you throw at the problem.
If a fraction P of a program's execution time can be parallelized across N processors, the parallel part finishes N times faster while the serial part (1 − P) takes just as long as before. Total time becomes (1 − P) + P/N of the original, so the theoretical speedup is:
The killer corollary: as N → ∞, speedup approaches 1 / (1 − P). A program that is 5% serial can never exceed 20× speedup — even on a million cores. Optimizing the serial fraction is usually worth more than buying hardware: raising P from 90% to 95% doubles the ceiling from 10× to 20×.
Worked example 1: video rendering farm
A 4K video render takes 4 hours on one machine. Profiling shows 90% of the time is frame rendering (embarrassingly parallel) and 10% is scene setup and final encoding (serial). You rent 16 cores:
Step 1. P = 0.90, N = 16.
Step 2. S = 1 / ((1 − 0.90) + 0.90/16) = 1 / (0.10 + 0.05625) = 1 / 0.15625 = 6.4×.
Step 3. New render time = 4 h / 6.4 = 0.625 h = 37.5 minutes.
Step 4. Sanity check: the ceiling is 1/0.10 = 10×, so 6.4× is plausible; efficiency is
6.4/16 = 40% — the serial 10% is already biting.
Worked example 2: ML data pipeline
One training epoch takes 3 hours; the data-loading and augmentation stage is 75% of the time and scales with workers, while gradient sync and checkpointing stay serial. You run 8 data-loader workers:
Step 1. P = 0.75, N = 8.
Step 2. S = 1 / ((1 − 0.75) + 0.75/8) = 1 / (0.25 + 0.09375) = 1 / 0.34375 ≈ 2.91×.
Step 3. Epoch time = 3 / 2.91 ≈ 1.03 hours (about 62 minutes).
Step 4. The ceiling here is only 4× — if epochs are still too slow, the win is in
parallelizing the sync/checkpoint code (raising P), not in adding a 9th worker.
Worked example 3: how many cores do I need? (inverse)
You need a 4× speedup and your profiler says 85% of the workload parallelizes. Solving S = 1/((1−P) + P/N) for N gives N = P / (1/S − (1−P)):
Step 1. N = 0.85 / (1/4 − 0.15) = 0.85 / 0.10 = 8.5.
Step 2. Round up to whole cores: 9 cores.
Step 3. Verify: S = 1 / (0.15 + 0.85/9) = 1 / 0.2444 ≈ 4.09× ✓.
Step 4. Had you asked for 10× with the same P, the solver would refuse — the ceiling is
1/0.15 ≈ 6.67×, so no core count can deliver it. That refusal is a feature: it tells you to
fix the serial fraction first.
Amdahl vs Gustafson: which one do you need?
Amdahl (1967) fixes the problem size — the same video, the same dataset — and asks how fast it finishes. Gustafson (1988) fixes the run time and asks how much bigger a problem you can solve: scaled speedup S = N − (1−P)(N−1), which grows almost linearly with cores. Neither is "more correct"; they answer different questions. A useful habit: compute both. When the two agree (small N, high P), your scaling story is robust. When they diverge wildly, say so explicitly — your conclusion depends on whether the workload grows with the machine.
Speedup reference table
Theoretical speedup S for common parallel fractions and core counts. The ∞ row is the Amdahl ceiling 1/(1−P) — the value no core count can pass.
| Cores \ P | 50% | 75% | 90% | 95% | 99% |
|---|---|---|---|---|---|
| 1 | 1.00× | 1.00× | 1.00× | 1.00× | 1.00× |
| 2 | 1.33× | 1.60× | 1.82× | 1.90× | 1.98× |
| 4 | 1.60× | 2.29× | 3.08× | 3.48× | 3.88× |
| 8 | 1.78× | 2.91× | 4.71× | 5.93× | 7.48× |
| 16 | 1.88× | 3.37× | 6.40× | 9.14× | 13.91× |
| 32 | 1.94× | 3.66× | 7.80× | 12.55× | 24.43× |
| 64 | 1.97× | 3.82× | 8.77× | 15.42× | 39.26× |
| 128 | 1.98× | 3.91× | 9.34× | 17.41× | 56.39× |
| ∞ | 2.00× | 4.00× | 10.00× | 20.00× | 100.00× |
Read a row to feel diminishing returns: at P = 90%, 16 cores give 6.40× but doubling to 32 buys only 7.80×, and even 128 cores reach just 9.34× against a 10× ceiling.
Practical tips
- Measure P, don't guess it. Profile the serial run: P ≈ 1 − (serial-only time / total time). Or measure speedup on N cores and use the inverse solver — the honest P is the one your code actually achieves.
- Attack the serial fraction first. Raising P from 0.90 to 0.95 doubles your ceiling; doubling cores from 16 to 32 at P = 0.90 only moves 6.40× → 7.80×.
- Budget for overhead. Thread pools, locks, and NUMA effects add a real overhead term; re-measure speedup after parallelizing, because the textbook curve is an upper bound.
- Watch memory bandwidth. Amdahl assumes compute-bound work. If 64 cores starve on the same memory bus, your limit is bandwidth, not the serial fraction — profile before scaling.
- Report strong vs weak scaling separately. A 95%-efficient weak-scaling benchmark (Gustafson regime) says nothing about fixed-problem speedup. State which one you measured.
Frequently asked questions
What is Amdahl's law?
Amdahl's law is a formula for the theoretical speedup of a task when only part of it can be parallelized. Presented by computer architect Gene Amdahl at the 1967 AFIPS Spring Joint Computer Conference, it states that the overall speedup is limited by the fraction of the work that stays serial: S = 1 / ((1 − P) + P / N), where P is the parallelizable fraction and N is the number of processors. Even with infinite processors, speedup can never exceed 1 / (1 − P) — so a program that is 5% serial tops out at 20×.
What do P and N mean in Amdahl's law?
P is the fraction of the execution time that can be parallelized (0 to 1, or 0–100%), measured on the original single-processor run. N is the number of processors or cores — more generally, the speedup factor applied to the parallelizable portion. The remaining (1 − P) is the serial fraction: setup, synchronization, and inherently sequential logic that no number of cores can accelerate.
How do I calculate speedup with Amdahl's law?
Plug the parallel fraction P and core count N into S = 1 / ((1 − P) + P / N). Example: 80% of a program parallelizes (P = 0.8) on 8 cores: S = 1 / (0.2 + 0.8/8) = 1 / 0.3 ≈ 3.33×. The calculator above does this instantly, and also solves the inverse problems: cores needed for a target speedup, or the implied P from a measured speedup.
What is the maximum possible speedup?
Let N go to infinity and the formula collapses to S_max = 1 / (1 − P), the Amdahl ceiling. With P = 0.5 the ceiling is 2×, with P = 0.9 it is 10×, and with P = 0.99 it is 100×. This is the hard lesson of the law: doubling cores forever buys you at most the ceiling, so shrinking the serial fraction usually beats buying more cores.
What is the difference between Amdahl's law and Gustafson's law?
Amdahl's law assumes a FIXED problem size: speedup is bounded by 1/(1−P). Gustafson's law (Gustafson, 1988, CACM) assumes the problem GROWS with the machine — scaled speedup S = N − (1−P)(N−1), which rises almost linearly with cores. Use Amdahl when the workload is fixed (rendering one video file); use Gustafson when bigger machines solve bigger problems (finer simulations, larger training batches). With P = 0.9 and 10 cores, Amdahl gives 5.26× while Gustafson gives 9.1× — same math, different assumption about what scales.
Why is my speedup much lower than my core count?
Because of diminishing returns. Parallel efficiency is S / N, and it falls as N grows. With P = 0.9 on 64 cores, speedup is only 8.77× — about 14% efficiency — even though the ceiling is 10×. Every new core adds less usable power than the last, since the serial fraction becomes a larger share of the shrinking total time. The scaling-curve tab above shows this bend visually.
When does Amdahl's law not apply?
It is an idealized model: it ignores parallel overhead (thread management, synchronization, communication), memory-bandwidth walls, and load imbalance, so real speedups come in below the curve. It also assumes a fixed workload — for scaled workloads, Gustafson's law is the honest model. With heterogeneous cores (big.LITTLE, CPU+GPU), the simple N needs weighting; Hill and Marty (2008, "Amdahl's Law in the Multicore Era") extended the analysis to asymmetric multicore designs.
How do I model parallel overhead?
Add an overhead fraction to the denominator: S = 1 / ((1 − P) + P/N + overhead), where overhead is the extra serial-equivalent cost of parallelization (e.g. 0.05 for 5%). Example: P = 0.9, N = 16, overhead 5% gives S = 1 / (0.1 + 0.05625 + 0.05) ≈ 4.85× instead of the ideal 6.4× — overhead alone eats about 24% of the speedup. The overhead tab models this and shows how the loss grows with core count.
How many cores should I actually use or buy?
Not the maximum — the cost-optimal count. Each added core costs money while saving less and less wall time, so total cost (compute spend + the value of your waiting time) has a minimum. The optimizer tab scans core counts 1.. N and finds it. Rule of thumb: stop adding cores when the next doubling buys under ~10% more speedup; beyond that you are mostly paying for idle silicon.
Can I use Amdahl's law for GPUs or distributed clusters?
Yes, with care. Treat N as the number of effective parallel execution units (GPU streaming multiprocessors, cluster nodes) and keep P honest — communication between nodes counts as overhead or serial time, not free parallelism. Distributed systems usually have much larger overhead fractions than a single multicore chip, so model overhead explicitly instead of trusting the ideal curve.
What is parallel efficiency and strong vs weak scaling?
Parallel efficiency is S / N: the fraction of ideal linear speedup you actually get. Strong scaling fixes the problem size and adds cores — exactly what Amdahl's law describes, with efficiency falling toward zero. Weak scaling grows the problem with the core count — the Gustafson regime — where efficiency can stay near 100%. Report which one you measured; a 90% efficient weak-scaling result says nothing about strong scaling.
Who was Gene Amdahl?
Gene Myron Amdahl (1922–2015) was an American computer architect, chief designer of several IBM mainframes including the System/360, and founder of Amdahl Corporation. He presented the argument that became Amdahl's law at the 1967 AFIPS conference as a rebuttal to the era's enthusiasm for massive parallelism: his point was that the serial portion of a workload ultimately dictates performance, a warning that still shapes multicore design today.
Sources
Formulas verified against primary sources before publication:
• Amdahl, G. M. (1967). "Validity of the single processor approach to achieving large scale
computing capabilities." Proc. AFIPS Spring Joint Computer Conference, pp. 483–485.
doi:10.1145/1465482.1465560 — S = 1 / ((1−p) + p/s).
• Gustafson, J. L. (1988). "Reevaluating Amdahl's Law." Communications of the ACM,
31(5), 532–533. doi:10.1145/42411.42415 — S = N − (N−1)·s.
• Hill, M. D. & Marty, M. R. (2008). "Amdahl's Law in the Multicore Era."
Computer, 41(7), 33–38. doi:10.1109/MC.2008.209.
Free client-side tool — every calculation runs in your browser; nothing is uploaded.
Free tool by NRTechStudio