Amdahl's Law
Learn it → Apply it → Save as Skill
Speeding up one part of a system can only speed up the whole system by as much as that part actually matters. The portion you leave untouched sets a hard ceiling on your total gain, no matter how much faster you make everything else.
Learn it. Apply it. Save as Skill.
The Dr. Wallace’s Favorite Mental Models is designed to turn useful ways of thinking into reusable tools. Each model gives you a fast visual overview, deeper interactive learning, practical application exercises and an AI-ready Markdown skill you can save for future use.
Instead of merely reading about mental models, you can gradually build your own AI skills library: a collection of portable reasoning skills that can help ChatGPT, Claude, Grok and other AI assistants apply the mental models you value.
If a task takes 100 minutes and you can make 20 of those minutes infinitely fast, the other 80 minutes still happen. Your absolute best-case total is 80 minutes, not zero. The part you don't touch is the ceiling.
Same effort, very different payoff
Same 10× local speedup, applied to two different shares of the same job: optimizing the small 20% share only cuts total time by about 18% (a 1.22× overall speedup). Optimizing the large 80% share cuts total time by about 72% (a 3.57× overall speedup). The size of the share you touch, not the cleverness of the fix, decides the payoff.
Use it before you spend money or effort speeding anything up.
The model is most useful right before an optimization investment: buying more hardware, parallelizing a workflow, automating a step, or deciding which part of a slow process to fix first.
Measure → Target → Invest → Reassess.
Amdahl's Law is a prioritization discipline backed by a formula. It tells you where effort actually pays off.
Find out what share of total time or cost each part of the system actually consumes, not which part feels slowest.
Before investing, calculate the realistic ceiling on overall improvement given that part's share of the total.
Put money and effort toward the part with the largest time share, not the part that is easiest or most interesting to fix.
Once the biggest share shrinks, a different part is now the largest remaining share. Remeasure and repeat.
Try the actual formula on your own numbers.
Move the sliders to match your situation. The result updates live, using the same formula Gene Amdahl proposed in 1967: overall speedup = 1 ÷ ((1 − p) + p ÷ s).
Right now, speeding up that 50% share by 4× only gets you to 1.60× overall — because the untouched 50% still has to happen.
Six things worth understanding before you apply it.
Expand each to see the reasoning, the common objection, and where the pattern actually comes from.
The Law
The exact statement
If a fraction p of a task's time can be sped up by a factor of s, and the remaining (1 − p) cannot be sped up at all, then the overall speedup is 1 ÷ ((1 − p) + p ÷ s). As s grows toward infinity, the speedup approaches a ceiling of 1 ÷ (1 − p) — it never goes higher, no matter how fast the optimized part becomes.
Why it holds
The untouched part is a floor
Total time is the sum of the part you sped up and the part you didn't. You can shrink the first term toward zero, but the second term — the untouched (1 − p) share — stays exactly where it started. Total time can never fall below that floor.
The ceiling
Diminishing returns, made exact
Optimizing a 90%-share part can theoretically get you up to 10× overall, even at infinite local speedup. Optimizing a 50%-share part caps out at 2×. Optimizing a 10%-share part caps out at about 1.11×, regardless of how heroic the fix is. The ceiling is set entirely by the share, not by the quality of the optimization.
The counterexample
"But we just add more processors and it scales fine"
In 1988, computer scientist John Gustafson and his colleague Edwin Barsis published a paper showing that when the size of the problem grows along with the available resources — more data, not the same data faster — speedup can scale close to linearly with the number of processors, because the serial portion stays roughly fixed while the parallel portion simply does more work. This is Gustafson's Law. It isn't a refutation of Amdahl's Law; it answers a different question (a growing workload) than Amdahl's Law does (a fixed one).
The corollary
Order of attack matters
Fixing parts in order of time-share, biggest first, gives steadily shrinking gains at each step — a clean picture of diminishing returns. Fixing parts in a different order can make early gains look small and later gains look surprisingly large, purely because of sequencing, not because the later fixes were better.
Off the pattern
Where the clean formula breaks down
The formula assumes a clean split between a serial part and a parallel part, with zero cost to coordinate between them. Real systems pay for synchronization, communication, memory bandwidth and I/O contention — costs the formula ignores entirely. That omission usually makes Amdahl's Law optimistic: real-world speedups often fall short of what the formula predicts, not ahead of it.
An ML team wants to cut model training time.
This is an illustrative example designed to teach the method.
The same ceiling shows up well outside computing.
Amdahl's Law was written about processors, but the underlying arithmetic applies anywhere a job splits into a part you can speed up and a part you can't.
Faster replies, slower routing
Halving agent handling time (the 30% share) only cuts total resolution time by about 15% (a 1.18× speedup), since the 70% queue-wait share is untouched. Fixing the queue matters more.
One slow station on the line
Speeding up every other station by 2× barely helps if the 60%-share bottleneck station is untouched; the whole line still waits on it.
A faster commute, a fixed meeting load
Even eliminating a 15%-share commute entirely only frees up 15% of the day; the 85% spent in meetings and work is the share actually worth examining.
Faster builds, same manual QA
A 5× faster build pipeline (the 25% share) caps total release-cycle improvement at about 1.25×, because the 75%-share manual QA step still has to happen.
A 1967 conference argument that became a formula everyone still uses.
Expand for the origin of the model and its real limits.
Where did Amdahl's Law come from?
Gene Amdahl (1922–2015) was a computer architect who joined IBM in 1952 after completing his doctorate at the University of Wisconsin–Madison. He worked on the IBM 704, the IBM 709 and the Stretch project (which became the IBM 7030), became chief architect of the IBM System/360, and was named an IBM Fellow in 1965. At the 1967 AFIPS Spring Joint Computer Conference, Amdahl took part in a panel on future computer architecture alongside other architects, including Daniel Slotnick, a designer of the massively parallel ILLIAC IV. In a short, three-page written statement titled "Validity of the single processor approach to achieving large scale computing capabilities," Amdahl argued that physical and structural limits would constrain how much any special parallel feature could actually improve overall performance — the argument now known as Amdahl's Law. He left IBM in 1970 and founded Amdahl Corporation the same year with financing from Fujitsu, building mainframes that were "plug-compatible" with IBM's own systems.
Is this a proven formula or an informal heuristic?
Unlike many mental models on this list, Amdahl's Law is a provable mathematical identity once you accept its simplifying setup: a task cleanly split into one serial share and one parallel share, with no cost to coordinate between them. The arithmetic itself isn't in question. What's debatable is whether that clean split is a realistic description of your actual system — real workloads often have messier boundaries and extra overhead the formula doesn't count.
Is it really the same thing as "the law of diminishing returns"?
Not quite. Diminishing returns is a general observation that extra input to one factor eventually yields smaller extra output. Amdahl's Law is a specific, quantified case of that idea, built around a particular setup (a fixed task split into an untouched share and a sped-up share) with an exact formula and an exact ceiling — and, as the corollary above notes, it only produces the familiar "smoothly diminishing" pattern if you fix the biggest share first.
The formula is simple; applying it well is not.
Treating it as just "diminishing returns"
It's a specific, formula-driven claim about a fixed serial/parallel split, not a vague restatement of the general diminishing-returns idea.
Ignoring coordination overhead
The formula assumes zero cost to synchronize the parts. Real communication, locking and memory-bandwidth overhead usually makes actual speedup worse than predicted, not better.
Assuming the workload is fixed when it isn't
If more resources let you take on a bigger job rather than finishing the same job faster, Gustafson's framing fits better than Amdahl's.
Spending before measuring the share
Buying parallel capacity aimed at a part of the system without first measuring what fraction of total time that part actually consumes.
Optimizing the easy part, not the big part
A flashy fix on a small-time-share piece feels productive but barely moves total performance.
Expecting speedup to scale forever
Past the ceiling of 1 ÷ (1 − p), additional parallel resources on that same share buy nothing. More spending there is waste, not progress.
Some situations need a different lens.
Use Gustafson's Law when...
the total workload grows with the resources you add — processing more data with more machines, not the same data faster.
Use direct profiling or queueing analysis when...
the real bottleneck isn't compute at all, but network latency, disk I/O, or a human review step with its own queueing behavior.
Use an architecture change when...
the serial share itself can be redesigned away — removing a lock, changing an algorithm, eliminating a hand-off — rather than merely sped up in place.
One model rarely does the whole job.
Build an Amdahl's Law prioritization prompt.
This browser tool structures your thinking. It does not send your information anywhere or perform AI analysis.
Your AI-ready prompt
Turn this mental model into a reusable AI skill.
Save as Skill converts the model into portable Markdown instructions that teach an AI when and how to apply Amdahl's Law, what questions to ask, what evidence to seek, what mistakes to avoid and how to structure its analysis.
Build your own Mental Models Skills Library
Save the skills you find useful and organize them into your own reusable library. The Markdown is intentionally model-neutral, so it can be used wherever an AI system accepts uploaded files, project knowledge, custom instructions or reusable text context. Platform capabilities differ, so this is a portable skill file rather than a claim of one-click installation.
For readers who want the nuance.
Does Amdahl's Law mean parallel computing or automation is a bad investment?
No. It means the payoff from any investment is capped by how large a share of the total it actually targets. Parallel or automated capacity aimed at the biggest share is often an excellent investment; the same capacity aimed at a small share rarely is.
How is this different from "move fast and break things" or general efficiency advice?
Amdahl's Law isn't advice about speed or care — it's a measurement discipline. It tells you, with an exact ceiling, how much any given optimization can possibly be worth before you spend the effort to find out the hard way.
Is there a domain where this stops being useful advice?
Its clearest fit is anywhere a job splits cleanly into a part you can speed up and a part you can't — computing, manufacturing, logistics, operations. It gets less useful when the "parts" blur together, when the workload itself grows with your resources (Gustafson's territory), or when the real constraint is something the formula doesn't model at all, like morale, risk or trust.