Herb Sutter is arguing that current clockspeeds have hit a practical limit, and the only way to keep Moore's "Law" going is with multi-core CPUs:

http://www.gotw.ca/publications/concurrency-ddj.htm

Critique of the Article

I think some of his points are flawed. First, there are too few datapoints at the end of his chart to note a trend. However, the point that clock speeds are leveling off is probably correct, considering announcements of future processors from Intel and AMD.

What Sutter doesn't do is make the First Most Common CPU Mistake, which is assuming that clock speed is the only factor. Instead, he makes the Second Most Common CPU Mistake, which is acknowledging that clock speed isn't the only factor, but then ignoring this fact for the rest of the prose.

Notice in his chart that although clock speeds might be leveling off, transister counts keep going up. Further, note that other types of processors have much higher transister counts than Intel or AMD CPUs. An nVidia 6800 Ultra graphics card has a processor with 222mil transisters. The latest Pentium 4 processors have 149mil transisters, and much of that is cache. (Modern graphics cards are fully programmable and could be used as a general-purpose CPU if you're willing to put the effort into it).

He seems to assume throughout the article that because clock speeds are falling off, the only way to get future performace gains is through multi-threaded programms running on multi-core CPUs. However, he mistakes the reasons for not aiming for higher clock speeds:

We’ll probably see 4GHz CPUs in our mainstream desktop machines someday, but it won’t be in 2005. Sure, Intel has samples of their chips running at even higher speeds in the lab—but only by heroic efforts, such as attaching hideously impractical quantities of cooling equipment. You won’t have that kind of cooling hardware in your office any day soon, let alone on your lap while computing on the plane.

According to the recent CPU guide on Tom's Hardware, the current Pentium 4 processors are maxing at 115 watts of heat loss (note that the Athlon Thunderbirds were considered very high at around 70-80 watts). This would seem to go along with his point.

However, according to the same article above, the latest Athlon64 processors are maxing at an impressive 33 watts. So the heat problem isn't a problem (at least for the forseeable future), but is rather due to an inefficiency in Intel's processor lineup.

In short, his statement that the old ways of increasing CPU speeds are hitting practical limits is flawed. Transister counts are still rising, and designs can still be improved. Eventually, we will hit that limit, but we're not close yet. Just when we'll hit that limit is the matter of some debate, but we can safely leave it alone for now.

But he Still has a Point

With multi-core CPUs, we'll see a good reason for enhancing concurrency in software, even when targetted for low-end desktops and servers.

He compares this to the way OO finally caught on in the '90s. "In the 1990s, we learned to grok objects", he says. Many would say that in the '90s, we learned to grok objects poorly. We can all list off projects that had a flawed OO design that still passes user requirements. The only people directly affected by bad OO design are the people doing the coding on the project.

Concurrency is different because bad concurrency will have obvious (though often transient) bugs that can leak through in either testing or production. Bad concurrency will be noticed by users at some point. As such, I think programmers will have more incentive (compared to OO) for groking concurrency well.

I'm employed as a web programmer. Many are quick to say that web applications usually don't need threads, but this isn't entirely true. Most web servers for serious web sites use a threading model for handling requests that can take advantage of multi-processor/multi-core/hyperthreaded systems. Your own code may not use threads or fork off, but it is one thread/processes in a larger program tree. Even so, this has been the situation for a long time, and experianced web programmers know how to deal with it.

However, web programming isn't the only place Perl is located, and has been known to move into new areas whenever it wants to (once for sys admins, then for the web, and more recently for genetics). Wherever Perl is found, and wherever it may one day be, concurrency may not be as prevelent as it was for web sites, and Perl will have to deal with that.

So I leave this brain-dump with a question: what can we do to improve Perl's concurrency? The Lambda the Ultimate fourm has a posting that discusses the way many other languages are dealing with it, and may provide a source of inspiration for continuing the grand Perl tradition of stealing good ideas from other languages.

Update: Title correction per erix's suggestion.