Ever notice that CPU speed has stalled?

I just read Herb Sutter’s blog for the first time in a while. For some reason I hadn’t subscribed before, but I remember reading it in the past. Perhaps I’d lost interest because he’s one of the architects of Visual C++, and I’m not interested in that variant of the C family. If given the choice, for low-level Win32 code, I’d use Delphi, and for .NET development I’d use C#.

Anyway, his latest post references an article he’s written for the March 2005 issue of Dr Dobbs that mentions a fact I’m sure we’ve all noticed in our subconscious: the speed of Intel CPUs in commodity PCs hasn’t changed all that much in the past year or more. It seems to be stuck at the 3GHz barrier (plus or minus a few tenths of a GHz).

There’s certainly a lot of chat around on how graphics cards are getting more and more powerful. In fact, some graphics cards now have more memory than the entry-level PCs from Dell. We’re hearing about the next WiFi after 802.11g. LCD screens are de rigueur. Fast disks? Pile ‘em on. But CPU speed? Ho hum, everything goes quiet.

Herb believes that the lease is expiring on Moore’s Law. Intel et al just can’t get more paths through that silicon.

What does that mean for software developers? Well, sorry and all that, but the CPU bullet train has reached the terminus: we can no longer count on faster chips hiding our software performance problems. We should be rigorous in measuring performance and optimizing. Don’t micro-optimize, but optimize at an algorithmic level (hey, my specialty!).

Herb has another solution, one that would strike terror in a lot of developers’ hearts: use concurrency. It’s likely that commodity PCs will start to appear with two CPUs, possibly with gaming machines first, and then it’ll spread into the mainstream. Writing multi-threaded applications to take advantage of two CPUs is harder than writing single-threaded ones. Nevertheless, one way to get more performance from our applications would be to off-load some processing onto another CPU. If I were you, I’d start researching and experimenting with how to write multi-threaded algorithms, with how to write thread-safe code, and with how to deal with deadlocks.

Also be on the lookout for extensions that would help make writing multi-threaded apps easier and less error-prone, for error-prone they are. For C# check out Microsoft Research’s Comega prototype. For Delphi? Well, that’s a topic for another day.