What We Think Amdahl's Law Is About
If you’ve been around software engineering long enough, you’ve heard of Amdahl's Law. It’s usually brought up in conversations about making things faster. You have a big, slow task, and you realize parts of it can be run simultaneously. So, you throw
more processors, cores, or threads at it. The law, created by computer architect Gene Amdahl in 1967, provides a formula to calculate the maximum theoretical speedup you can get from parallelizing a task. The common takeaway sounds like a simple, beautiful promise: the more of your program you can run in parallel, the faster it will go when you add more resources. On the surface, the lesson seems to be: find the parallelizable bits and go wild. This interpretation makes engineers focus obsessively on splitting up work—distributing data processing, handling web requests concurrently, or rendering scenes on multiple GPU cores. We get excited by the idea of infinite scalability, thinking that if we just get the parallel part right, a 16-core machine will be 16 times faster. This, right here, is the first part of the trap.
The Seductive Focus on Parallelization
The part of the code that can be parallelized gets all the glory. It’s the ‘P’ in the formulas you see online. For many ambitious self-taught developers, optimizing ‘P’ becomes a crusade. We learn about mutexes, semaphores, and async/await. We design elaborate systems to break down a giant job into a thousand tiny ones, all running at the same time. We feel like we're mastering the art of modern computing.
And when the performance gains don't match our expectations? We blame our implementation. We assume we didn't parallelize *enough*. We think, 'If I could just get that last 10% of the workload to run concurrently, we’d see the hockey-stick growth on the performance chart.' We add more workers to the pool, increase the thread count, and stare at CPU utilization graphs, convinced the solution is more parallelism. But we’re looking in the wrong place.
The Hidden Detail: The Tyranny of the Serial Part
Here's the detail that gets missed, and it’s not just a detail—it's the entire point of the law. Amdahl's Law isn't a celebration of parallel processing; it's a sobering warning about its limits. The most important part of the equation isn't the parallelizable portion. It's the small, stubborn, unglamorous part that *must* run sequentially.
Let’s say 90% of your application can be run in parallel, but 10% is strictly serial—things like reading a config file, initializing a database connection, or combining the final results. You might think, 'Great, 90% is a huge win!' But Amdahl's Law shows us this is a disaster in disguise. That 10% serial portion puts a hard cap on your total speedup. No matter if you have 16 cores, 128 cores, or a million cores, your program will never be more than 10 times faster. The theoretical maximum speedup is 1 divided by the serial fraction (1 / 0.10 = 10).
If that serial portion is just 1% of the task? Your maximum speedup is 100x. If it’s 0.1%? Your max is 1000x. The 'hidden detail' is that the serial fraction doesn’t just contribute to the total time; it *dominates* the potential for improvement at scale. The bottleneck isn't the work you parallelized; it's the tiny piece you couldn't.
A Pizza Party Analogy
Imagine you're throwing a pizza party for a thousand guests. You've brilliantly solved the parallel problem: instead of one person eating all the pizza, you have a thousand people who can eat their slice simultaneously. The eating part will be incredibly fast.
But there’s a serial problem: all the pizzas have to be delivered by one driver in one car. The driver has to make multiple trips. While the driver is on the road, your thousand guests are just waiting. You can hire a million guests (processors), but the party can’t truly start until all the pizzas are on the table. The delivery driver (the serial part) is the ultimate bottleneck.
Amdahl’s Law teaches us that if you want to make the pizza party faster, hiring more guests is a fool's errand after a certain point. The only way to get a significant speedup is to find a way to make the pizza delivery itself faster—maybe by using multiple cars or opening a pizzeria next door. You have to attack the serial component.
