Chris Sells created a blog entry that linked to an article by Herb Sutter called The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software.
The article is long, but definitely worth the read. It points out that for years we've seen an exponential growth in CPU clock speed. I can remember buying a PII 266MHz when it was the fastest you could get at the time (around 1997). In fact, I remember my boss telling me "when you plug that thing in the lights in the house are going to dim!" Some time in 2000, I built a dual 733Mhz system when the 800Mhz chip was top of the line in the market. Now I'm running a 3.2GHz system, but as the article points out, 2GHz was out back in Aug 2001. If the exponential trend were continuing, we should be at 10GHz by now. Today the max clock speed is 3.4GHz and Intel will be at 3.7Ghz in 2005, but we probably will not see 4GHz next year.
The article also points out some interesting facts about dual core CPUs and hyperthreading with respect to performance. I found one particular section to be quite humorous:
"So a dual-core CPU that combines two 3GHz cores practically offers 6GHz of processing power. Right? Wrong...Unless the two cores are running different processes, or different threads of a single process that are well-written to run independently and almost never wait for each other, they won’t be well utilized. (Despite this, I will speculate that today’s single-threaded applications as actually used in the field could actually see a performance boost for most users by going to a dual-core chip, not because the extra core is actually doing anything useful, but because it is running the adware and spyware that infest many users’ systems and are otherwise slowing down the single CPU that user has today. I leave it up to you to decide whether adding a CPU to run your spyware is the best solution to that problem.)"
So what does all of this mean to developers?
"If you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multithreaded) application. And that’s easier said than done, because not all problems are inherently parallelizable and because concurrent programming is hard."
