In it, he points out that developers will no longer be able to count on the fact that CPUs are getting faster to cover their performance issues. In the past, it was ok to have slow algorithms or bloated code in your application because CPUs got exponentially faster – if you app was sluggish on a 2GHz PIII, you didn’t have to worry, the 3GHz machines would be out soon, and they’d be able to run your code just fine.
Unfortunately, this is no longer the case – the CPU manufacturers have hit a wall, and are (for the foreseeable future) unable to make faster processors.
What does this mean? It means that (as Herb says) the free lunch is over. Intel (and AMD) isn’t going to be able to fix your app’s performance problems, you’ve got to fall back on solid engineering – smart and efficient design, extensive performance analysis and tuning.
It means that using STL or other large template libraries in your code may no longer be acceptable, because they hide complexity.
It means that you’ve got to understand what every line of code is doing in your application, at the assembly language level.
It means that you need to investigate to discover if there is inherent parallelism in your application that you can exploit. As Herb points out, CPU manufacturers are responding to the CPU performance wall by adding more CPU cores – this increases overall processor power, but if your application isn’t designed to take advantage of it, it won’t get any faster.
Much as the financial world enjoyed a 20 year bull market that recently ended (ok, it ended in 1999), the software engineering world enjoyed a 20 year long holiday that is about to end.
The good news is that some things are still improving – memory bandwidth continues to improve, hard disks are continuing to get larger (but not faster). CPU manufacturers are going to continue to add more L1 cache to their CPUs, and they’re likely to continue to improve.
Compiler writers are also getting smarter – they’re building better and better optimizers, which can do some really quite clever analysis of your code to detect parallelisms that you didn’t realize were there. Extensions like OpenMP (in VS 2005) also help to improve this.
But the bottom line is that the bubble has popped and now it’s time to pay the piper (I’m REALLY mixing metaphors today). CPU’s aren’t going to be getting any faster anytime soon, and we’re all going to have to deal with it.
This posting is provided “AS IS” with no warranties, and confers no rights.