How this instrument works
Any task splits into two pieces: a portion that can be parallelized and a portion that must run serially, one step after another, no matter how much hardware is available. Amdahl's Law describes what happens to the whole task's runtime when you speed up only the parallel piece — the serial piece keeps taking exactly as long as it always did, and it's that stubborn remainder that ultimately limits how much faster the overall task can get.
The formula takes two inputs: p, the fraction of the original runtime that can be parallelized, and s, the speedup achieved on just that fraction. As s grows toward infinity — an infinitely fast parallel portion — overall speedup doesn't grow without bound; it approaches a hard ceiling of 1/(1-p), set entirely by the serial fraction that was never sped up at all. A task that's 90% parallelizable can never exceed a 10x overall speedup, however many cores you add.
Gene Amdahl proposed this relationship in 1967 to argue against the era's push toward massively parallel computer designs, pointing out that most real workloads have an unavoidable serial component. It remains the standard first-pass tool for reasoning about whether adding cores, GPUs, or parallel workers is actually worth it for a given piece of software.
- Enter the parallelizable portion of the task, as a fraction between 0 and 1 — 0.9 means 90% of the runtime can be parallelized.
- Enter the speedup factor achieved on that parallel portion, such as 10 for a tenfold speedup on just the parallel part.
- Read Overall theoretical speedup — the best possible multiplier for the entire task once the unsped-up serial remainder is accounted for.
- Raise the speedup factor while holding the parallelizable portion fixed to see how quickly the overall number plateaus and stops improving.
Worked example — 90% parallel, sped up 10x
Enter 0.9 into Parallelizable portion and 10 into Speedup of the parallel portion — a task that's 90% parallelizable, run 10x faster on that portion alone. Overall theoretical speedup reads 5.2632: 1 ÷ ((1 − 0.9) + 0.9 ÷ 10) = 1 ÷ (0.1 + 0.09) = 1 ÷ 0.19.
Notice the ceiling this implies: even an infinitely fast parallel portion could only push this same 90%-parallel task to 1 ÷ (1 − 0.9) = 10x overall, because the remaining 10% of the work still runs serially and takes its full, unaccelerated share of the time no matter how much parallel hardware is available.
Questions
Why can't a 90%-parallel task get a 90% speedup?
Because the other 10% of the task still runs serially, taking exactly the time it always took, regardless of how fast the parallel 90% becomes. As the parallel portion's speedup grows very large, the overall speedup stops climbing and settles at a ceiling set purely by the serial fraction — for a 90%-parallelizable task, that ceiling is 10x, never higher, however much parallel hardware you add.
What's the maximum possible speedup for a given parallelizable portion?
It's 1 ÷ (1 − p), the value the formula approaches as the speedup factor s grows toward infinity. A task that's 50% parallelizable tops out at 2x overall speedup; one that's 95% parallelizable tops out at 20x; one that's 99% parallelizable tops out at 100x. This ceiling is why chasing more parallel hardware has rapidly diminishing returns once the serial fraction is small but nonzero.
Who came up with Amdahl's Law?
Computer architect Gene Amdahl, in a 1967 paper presented at the AFIPS Spring Joint Computer Conference titled 'Validity of the Single Processor Approach to Achieving Large Scale Computing Capabilities.' He used the relationship to argue that adding processors alone couldn't overcome a program's inherent serial bottlenecks, a point still central to parallel computing design today.
How is Amdahl's Law different from Gustafson's Law?
Amdahl's Law assumes the total amount of work stays fixed while you add processors, so the serial fraction's share of the runtime becomes proportionally more limiting as you parallelize further. Gustafson's Law instead assumes the problem size grows to fill the available processors, which paints a more optimistic picture of scalability for workloads that genuinely get bigger, not just faster, as hardware is added.
What does the 'speedup factor' input actually represent?
It's the speedup achieved specifically on the parallelizable portion of the task, not the whole task — for example, running that portion on 8 cores might give roughly an 8x speedup on just that piece, or offloading it to a GPU might give a much larger factor. The overall speedup this calculator returns is always smaller, because it also accounts for the serial portion that the speedup factor never touches.
Does Amdahl's Law only apply to computer parallelization?
No — the same reasoning applies to any process where only part of the total time is affected by an improvement, whether that's optimizing one stage of a manufacturing line, speeding up one leg of a commute, or upgrading one component of a larger system. Whatever fraction of the total time remains untouched by the improvement caps how much the overall improvement can ever help.