The Law of Diminishing Returns
This common frustration has a name, or at least, a governing principle. It’s called Amdahl’s Law, and it’s one of the most important and quietly influential concepts in computer science. First presented in 1967 by computer architect Gene Amdahl, the law
explains the very real limits of performance gains. In simple terms, it states that the speedup you get from adding more resources—like extra processor cores—is ultimately capped by the portion of the task that can’t be split up. Think of it like a team of chefs preparing a meal. You can hire ten chefs to chop vegetables simultaneously, which dramatically speeds up that part of the process. But if the recipe requires one person to spend 10 minutes slowly stirring the final sauce, it doesn't matter if you have ten chefs or a hundred; you can never finish the meal in less than ten minutes. That single, un-splittable task is the bottleneck, and Amdahl's Law is all about the bottleneck.
The Un-Splittable Task
At the heart of Amdahl's Law is the difference between “parallel” and “serial” work. A parallel task is like that vegetable chopping—it can be divided among multiple workers (or processor cores) to be completed faster. Modern software is filled with these, from rendering different parts of a video simultaneously to processing multiple streams of data. A serial task, however, is a single-file line. It’s a set of instructions that must be executed one after another, in a specific order. Think about launching an application: the software has to load configuration files first, then initialize its main window, then check for updates. You can’t do step three before step one. This sequential part of the code is the bottleneck that Amdahl warned us about. No matter how much parallel processing power you throw at a program, its overall speed will always be limited by the time it takes to complete its essential, serial steps.
In Your Apps and Games
This principle is constantly at play in the software you use every day. In a video game, the graphics engine might use dozens of cores on your GPU to render stunning, high-resolution landscapes in parallel. But often, the game’s core logic—the AI deciding what an enemy does next, or the physics engine calculating a collision—can only run on a single CPU core. The result? You can have the most powerful graphics card in the world, but if the game’s serial AI task is slow, your frame rate will still stutter. You see it in photo editing, too. Applying a complex filter to a high-resolution image can be broken down into parallel tasks, with different cores working on different parts of the picture. But loading the massive file from your hard drive and then saving the finished product are often serial tasks that put a hard limit on your total time savings.
Why More Cores Aren't a Magic Bullet
This is why your new 16-core processor doesn’t make Microsoft Word feel 16 times faster. Much of a word processor's job—like waiting for you to type the next character—is fundamentally serial. Amdahl's Law reveals that after a certain point, adding more cores provides diminishing returns. If 90% of a program can be parallelized, that sounds great. But the remaining 10% that’s serial means you can never make the program more than 10 times faster, even if you had a computer with a million cores. That 10% serial portion becomes the unbreakable speed limit. For developers, this isn’t a counsel of despair; it’s a guide. It tells them that to truly make software faster, they must be relentlessly creative in minimizing the serial parts of their code or find clever ways to restructure problems so more work can be done in parallel.
