The Amdahl's law calculator above answers a question that decides whether a parallelisation project is worth doing: given the fraction of your program that can actually run concurrently, how much faster does it get on N processors, and what is the best it could ever get on any number of processors at all? The second answer is usually the surprising one, and it is fixed entirely by the part that stays serial.
Arb Digital publishes this as one of a set of free developer tools. It exists because the intuition most people carry — twice the cores, roughly twice the speed — is wrong in a specific and expensive way. A program that is 95 percent parallel does not get 8× faster on 8 cores; it gets 5.93× faster. And it never gets more than 20× faster, no matter what hardware you buy, because the 5 percent that cannot be parallelised does not care how many processors are standing idle waiting for it.
What This Amdahl's Law Calculator Does
It computes the classic speedup for a processor count you choose, then puts that number in context three ways. It shows the asymptotic ceiling with unlimited processors. It shows parallel efficiency, which is what share of the hardware you actually paid for is doing useful work. And it shows the same workload under Gustafson's law, which asks a different and often more realistic question about scaling.
The bar chart is the part worth staring at. It plots speedup at 2, 4, 16, 64 and 1,024 processors against the ceiling on a common scale, so the flattening is visible rather than described. Change the parallel fraction from 95 to 99 percent and watch every bar move; change it from 95 to 90 and watch the ceiling halve. That sensitivity — a small change in the serial fraction producing a large change in the achievable outcome — is the practical lesson.
How to Use It
- Estimate the parallel fraction honestly. Profile it rather than guessing; measured serial time divided by total time is the number you want, and it is almost always worse than the guess.
- Set the processor count you are actually considering, not an aspirational one.
- Optionally set a real parallel speedup instead of assuming perfect linear scaling of the parallel portion — this models communication overhead and contention.
- Enter a baseline runtime so the result comes back as a wall-clock time rather than a ratio.
- Compare the speedup against the ceiling. If you are already close to the ceiling, more processors will not help and the serial portion is the only thing left to work on.
The Formula and How It's Calculated
Split total runtime into a serial fraction and a parallel fraction p, so the serial part is (1 − p). Running on N processors, the parallel part takes p ÷ N of the original time while the serial part is unchanged. Speedup is therefore S = 1 ÷ ((1 − p) + p ÷ N). Let N go to infinity and the second term vanishes, leaving the ceiling: Smax = 1 ÷ (1 − p). Parallel efficiency is S ÷ N.
A worked example: at p = 0.95 and N = 8, speedup is 1 ÷ (0.05 + 0.95 ÷ 8) = 1 ÷ 0.16875 = 5.93×. Efficiency is 5.93 ÷ 8 = 74.1 percent, so a quarter of the hardware is effectively idle. The ceiling is 1 ÷ 0.05 = 20×, which you would approach only with an unbounded number of processors. A 100 second run becomes 16.9 seconds — and it could never become faster than 5 seconds.
The law is Gene Amdahl's, from a 1967 paper delivered at the AFIPS Spring Joint Computer Conference titled Validity of the single processor approach to achieving large scale computing capabilities, which argued against the then-current claim that multiprocessing alone would deliver order-of-magnitude gains. It remains standard material in performance engineering courses — MIT's 6.172 Performance Engineering of Software Systems is one openly published example covering parallel programming and scalability.
The Serial Part Sets the Limit, and Nothing Else Does
This is the whole point of the law and it deserves stating plainly. The ceiling depends only on the serial fraction. Not on the hardware, not on the language, not on how clever the parallel code is. If 5 percent of your runtime is serial, 20× is the maximum speedup that exists for that program, full stop. If 1 percent is serial, the maximum is 100×. If 10 percent is serial, it is 10×.
The asymmetry of that relationship is what catches people out. Going from 90 percent to 95 percent parallel — which sounds like a modest improvement — doubles the ceiling from 10× to 20×. Going from 99 to 99.9 percent takes it from 100× to 1,000×. Meanwhile going from 8 processors to 800 at a fixed 95 percent parallel fraction moves you from 5.93× to 19.53×, and no further, ever. The lesson for anyone allocating engineering time is uncomfortable but clear: past a certain point, attacking the serial section is worth vastly more than adding hardware.
Parallel Efficiency Is Where the Money Goes
Speedup tells you how much faster. Efficiency tells you how much of the machine you are wasting. At 95 percent parallel, 8 processors give 74 percent efficiency, 64 processors give 24 percent, and 1,024 processors give about 1.9 percent — you would be paying for 1,024 cores to get the work of roughly 20.
On owned hardware that inefficiency is invisible; on metered cloud compute it is a line item. The cost comparison in this tool exists for that reason: if a run costs the same total core-hours regardless of parallelism but finishes sooner, that is a straightforward win, but the moment efficiency drops you are paying strictly more for the same work in exchange for latency. Sometimes that trade is right — a nightly batch that must finish before the business opens has a hard deadline. Often it is not. Knowing the efficiency figure turns that into a decision rather than a habit. If you are sizing infrastructure around such runs, the uptime SLA calculator and the RAID calculator cover the availability and storage sides of the same planning exercise.
Gustafson's Law Asks a Different Question
Amdahl's law fixes the problem size and asks how much faster it runs. That is the right question for a fixed workload — the same simulation, the same nightly report. It is the wrong question for the many real workloads where more compute means people simply solve a bigger problem: a finer mesh, a longer horizon, more documents indexed.
Gustafson's reformulation fixes the runtime instead and asks how much more work you get done, giving S = N − α(N − 1) where α is the serial fraction. At 95 percent parallel on 8 processors that is 8 − 0.05 × 7 = 7.65×, against Amdahl's 5.93×. Neither number is wrong; they answer different questions. The rule of thumb: if your problem size is fixed by the requirement, use Amdahl. If the problem grows to fill the machine you give it, Gustafson is closer to what you will observe. The tool shows both so you can see how far apart they are for your fraction.
Where the Model Breaks Down
Amdahl's law is a bound, not a prediction, and it is optimistic in several ways. It assumes the parallel portion scales perfectly, ignoring communication cost, synchronisation, lock contention, false sharing and load imbalance — all of which grow with processor count and can make real speedup fall as you add cores past some point. The optional parallel-speedup field lets you substitute a measured figure for that idealised assumption.
It also ignores memory hierarchy in both directions. Against you: more cores contending for the same memory bandwidth can throttle everything. In your favour: splitting a dataset across more machines can put each piece in cache, occasionally producing superlinear speedup that appears to violate the law but is really a different program running on different hardware characteristics. And it says nothing about latency-bound work, where the constraint is waiting rather than computing — for those, the AI latency estimator and the bandwidth requirement calculator model the relevant bottlenecks instead.
Arb Digital builds and optimises web applications where performance is a business number, not a benchmark. See what we do, or tell us where your stack is slow.
See Web Design Services Talk to Arb DigitalCommon Mistakes to Avoid
- Guessing the parallel fraction — profile it. The serial share is reliably larger than developers estimate, and the ceiling is exquisitely sensitive to it.
- Reading speedup without efficiency — a 19× speedup on 1,024 cores is a headline and a disaster at the same time.
- Forgetting that the ceiling is fixed — once you are near 1 ÷ (1 − p), buying hardware achieves nothing measurable.
- Applying Amdahl to a growing problem — if the workload expands to fill the machine, Gustafson describes what you will actually see.
- Treating the number as a prediction — it is an upper bound that ignores communication, contention and memory pressure entirely.
Related Free Tools From Arb Digital
Pair this with the bandwidth requirement calculator for network capacity, the RAID calculator for storage layout, the uptime SLA calculator for availability budgets, the AI latency estimator for inference timing and the percentage calculator for quick ratio work. The full free online tools hub lists every calculator we publish.
Frequently Asked Questions
It states that the speedup of a program from parallelisation is limited by the portion that must run serially. With a parallel fraction p on N processors, speedup is 1 ÷ ((1 − p) + p ÷ N), and the maximum possible speedup on any number of processors is 1 ÷ (1 − p).
5.93×, not 8×. The calculation is 1 ÷ (0.05 + 0.95 ÷ 8) = 1 ÷ 0.16875. Parallel efficiency is 74.1 percent, meaning roughly a quarter of the hardware you paid for is waiting on the serial section.
One divided by the serial fraction. At 95 percent parallel the ceiling is 20×, at 99 percent it is 100×, and at 90 percent it is 10×. No amount of hardware moves that ceiling, because the serial portion takes the same time whatever else is running.
Amdahl fixes the problem size and asks how much faster it runs. Gustafson fixes the runtime and asks how much more work gets done, giving N − α(N − 1). Use Amdahl for a fixed workload and Gustafson where the problem grows to fill the available compute.
Speedup divided by processor count, expressed as a percentage. It measures how much of the hardware is doing useful work. Efficiency always falls as processors are added, and on metered compute it is the figure that determines whether extra cores are worth paying for.
Occasionally, through cache effects — splitting a dataset across machines can fit each piece in faster memory, producing superlinear speedup. That is a change in the hardware behaviour rather than a refutation of the law, which assumes identical execution characteristics throughout.
Because Amdahl's law is an optimistic upper bound. It ignores communication cost, synchronisation, lock contention, false sharing and memory bandwidth limits, all of which grow with thread count. Set the parallel-speedup field to a measured value to model that instead of perfect scaling.
This tool models an idealised bound on parallel speedup. Real performance depends on communication, contention, memory behaviour and workload characteristics, and should be confirmed by measurement.
