About

Amdahl's Law defines the theoretical upper bound on speedup when parallelizing a program. Given a task where a fraction P is perfectly parallelizable and the remainder 1 − P is strictly serial, adding processors yields diminishing returns that converge to 11 − P. Misjudging the serial fraction by even 5% can lead to procurement of hundreds of cores that deliver negligible gain. This calculator computes exact speedup S(n) and parallel efficiency E(n) for arbitrary processor counts and renders the full speedup curve so you can identify the point of diminishing returns before committing hardware budget.

The model assumes uniform parallelizable work with zero communication overhead. Real systems incur synchronization, cache coherence, and memory bandwidth penalties that further reduce observed speedup. Treat these results as a ceiling, not a prediction. For workloads with communication cost, consider Gustafson's Law or measured Karp-Flatt metrics as complementary analyses.

Formulas

Amdahl's Law expresses theoretical speedup as a function of the parallelizable fraction and processor count:

S(n) = 1(1 − P) + Pn

The maximum theoretical speedup as n → ∞:

S_max = 11 − P

Parallel efficiency measures how effectively each processor contributes:

E(n) = S(n)n × 100%

Where: P = fraction of the program that is parallelizable (0 ≤ P ≤ 1). n = number of processors. S(n) = theoretical speedup with n processors. E(n) = parallel efficiency as percentage.

Reference Data

Parallel Fraction (P)	Max Speedup S(∞)	S(2)	S(4)	S(8)	S(16)	S(64)	S(256)	S(1024)
50%	2.00	1.33	1.60	1.78	1.88	1.97	1.99	2.00
75%	4.00	1.60	2.29	2.91	3.37	3.76	3.94	3.98
80%	5.00	1.67	2.50	3.33	4.00	4.71	4.92	4.98
90%	10.00	1.82	3.08	4.71	6.40	8.77	9.63	9.91
95%	20.00	1.90	3.48	5.93	9.14	15.42	18.29	19.51
97%	33.33	1.94	3.64	6.60	10.96	21.92	28.83	32.36
99%	100.00	1.98	3.88	7.48	13.91	39.26	72.08	91.19
99.5%	200.00	1.99	3.94	7.73	14.88	47.41	105.32	163.93
99.9%	1000.00	2.00	3.99	7.94	15.76	56.47	172.74	506.33
100%	∞	2.00	4.00	8.00	16.00	64.00	256.00	1024.00

Frequently Asked Questions

Amdahl's Law shows that the serial portion (1 − P) creates a hard floor. If 10% of your code is serial, maximum speedup is 10× regardless of processor count. Each added processor only accelerates the parallel fraction P/n, so the serial part dominates at high core counts.

Profile your application using tools like gprof, perf, or Intel VTune. Measure wall-clock time of sections that can execute concurrently versus those that must run sequentially (I/O waits, lock contention, serial initialization). The ratio of parallelizable time to total time gives P. Run multiple measurements under representative workloads - P varies with input size and data distribution.

No. Amdahl's Law assumes zero overhead for synchronization, inter-process communication, cache coherence, and memory bandwidth contention. Real speedup is always lower than Amdahl's prediction. For systems where communication cost scales with processor count, the actual speedup curve bends downward and can even decrease beyond an optimal core count.

Use Gustafson's Law (scaled speedup) when the problem size grows proportionally with processor count. Amdahl's Law fixes the problem size, which is appropriate for latency-bound tasks. Gustafson's model applies to throughput-bound scenarios where more cores process more data in the same time - common in scientific simulations and batch processing pipelines.

Industry benchmarks vary, but efficiency E(n) above 70% is generally considered cost-effective for cluster procurement. Below 50%, the cost per unit of speedup increases sharply. Use this calculator to find the processor count where efficiency drops below your threshold - that is your economically optimal configuration. Procuring beyond that point yields diminishing returns per dollar spent.

Yes. Many algorithms have serial fractions that decrease with input size - Gustafson's insight. For example, a matrix multiplication with O(n³) parallel work and O(n²) serial setup has an effective P that approaches 1 as n grows. Always profile at your target input scale. The P value you enter should reflect your production workload, not a toy benchmark.