Work out real speedup from a parallel fraction, the cores a target needs, and the core count a request rate demands — with Amdahl's ceiling shown.
Enter how much of the work runs in parallel and how many cores you have. You get the speedup, the efficiency per core, and the ceiling no core count can pass.
Speedup at each core count and parallel fraction, computed from the law. The column headings match the table published in LLNL's Introduction to Parallel Computing Tutorial.
| Cores | P = 50% | P = 90% | P = 95% | P = 99% |
|---|---|---|---|---|
| 10 | 1.81 | 5.26 | 6.89 | 9.17 |
| 100 | 1.98 | 9.17 | 16.80 | 50.25 |
| 1,000 | 1.99 | 9.91 | 19.62 | 90.99 |
| 10,000 | 1.99 | 9.99 | 19.96 | 99.01 |
| 100,000 | 1.99 | 9.99 | 19.99 | 99.90 |
You might also find these calculators useful
More cores stop helping long before you run out of budget, and Amdahl's Law says exactly where. Enter the share of your work that runs in parallel and this calculator gives the real speedup at any core count, the ceiling no machine can pass, and the cores a target needs — or tells you plainly that the target is unreachable. Two sizing modes turn a measured load into a core count using the utilization law, with the cost of every headroom choice shown beside it.
Split a program into the part that can run on many cores at once (the parallel fraction P) and the part that cannot (the serial fraction, 1 − P). Adding cores shortens only the first part; the second takes the same time on one core as on a thousand. So the speedup is bounded by 1 ÷ (1 − P) however much hardware you buy. At P = 0.95 that bound is 20×, and reaching even 19× of it takes hundreds of cores. This is why a core count chosen from a workload label rather than from a measured parallel fraction tends to be wrong in both directions.
Amdahl's Law
An engineer with a 95%-parallel job checks the ceiling, sees 20×, and finds that 64 cores already reach 15.4× — 77% of everything unlimited hardware could ever give.
A team is asked to make a 60%-parallel service twice as fast. The ceiling is 2.5× and they already sit at 2.1×, so the answer is to raise P, not to buy hardware.
A platform engineer turns 500 requests per second at 40 ms of CPU each into a core count at a chosen utilization, with the queueing cost of that choice shown.
A database sitting at 92% is converted into CPU demand and re-sized to a target, which is the same arithmetic run in reverse.
The same answer is given in millicores, which is the unit a container request actually takes.
A target above 1 ÷ (1 − P) cannot be bought at any price. Knowing the ceiling before you shop is worth more than any recommended core count.
Speedup per core drops steadily as N rises. The table shows where each extra core stops paying for itself, in your own numbers.
“Database” and “web server” do not have parallel fractions; programs do. Both sizing modes take what you can actually measure.
Target utilization is not a standard anybody publishes. The page takes it as an input and shows the cores and the queueing each choice costs.
SMT exposes two hardware threads per physical core. The page reports both and never presents the thread count as extra throughput.
Physical cores for a machine, hardware threads for a scheduler, and millicores for a Kubernetes request — the same answer in all three.
It depends on two things you can measure: how much CPU your work consumes, and how much of it can run in parallel. For a service, multiply the request rate by the CPU time one request costs — 500 requests per second at 40 ms each is 20 cores of demand — then divide by the utilization you want to sit at. For a single program, the parallel fraction decides it: past a certain core count the extra cores return almost nothing, and this calculator shows exactly where that point is for your P.
It states that the speedup from parallelising a program is limited by the part that stays serial. With P as the parallel fraction and N cores, speedup = 1 ÷ ((1 − P) + P ÷ N). As N grows the second term vanishes and the speedup approaches 1 ÷ (1 − P) — a hard ceiling set entirely by the serial share.
Because only the parallel part gets faster. At P = 0.90, eight cores give 4.71× and sixteen give 6.40× — double the hardware for 36% more speed. The serial tenth of the work takes the same time in both cases, and it grows as a share of the total runtime as everything around it shrinks.
1 ÷ (1 − P). At P = 0.50 it is 2×, at 0.90 it is 10×, at 0.95 it is 20× and at 0.99 it is 100×. LLNL's parallel computing tutorial puts it memorably: you can spend a lifetime getting 95% of your code parallel and never beat 20× no matter how many processors you use.
Run it on one core and on N cores and record both times. The measured speedup S gives P = (1 − 1 ÷ S) ÷ (1 − 1 ÷ N), which is the Karp–Flatt approach in reverse. A profiler works too: anything running while only one thread is busy belongs to the serial fraction.
Two, on every mainstream implementation of simultaneous multithreading — Intel Hyper-Threading and AMD SMT both expose two hardware threads per physical core. Those are scheduling slots, not two cores' worth of throughput; the real gain varies by workload and can be negative for some. This calculator reports the thread count as a count, and never as a performance multiplier.
Usually not. Kubernetes documents its own unit precisely: one CPU unit is one physical core or one virtual core, depending on the node. On most public clouds a vCPU is one hardware thread, so two vCPUs share one physical core. If you size in physical cores and deploy in vCPUs, check which one your provider means before halving or doubling anything.
Divide by 1,000. Kubernetes writes 0.1 CPU as 100m, read as one hundred millicpu or millicores, and the two spellings mean the same thing. The finest value it accepts is 1m, which is 0.001 CPU — 0.5m is not a valid request. This calculator gives every sizing answer in millicores as well as cores.
No standards body publishes a number, which is why this page takes it as an input rather than asserting one. The trade-off is concrete: for a single queue, mean response time is service time ÷ (1 − utilization), so 70% costs about 3.3× the service time and 90% about 10×. Burst traffic, failover capacity and background work all come out of the same headroom.