Friday, February 18, 2005
Free lunch
There's an interesting phenomenon thats known as “Andy giveth, and Bill taketh away.” No matter how fast processors get, software consistently finds new ways to eat up the extra speed. Make a CPU ten times as fast, and software will usually find ten times as much to do (or, in some cases, will feel at liberty to do it ten times less efficiently). Most classes of applications have enjoyed free and regular performance gains for several decades, even without releasing new versions or doing anything special, because the CPU manufacturers (primarily) and memory and disk manufacturers (secondarily) have reliably enabled ever- newer and ever-faster mainstream systems …
CPU performance growth as we have known it hit a wall two years ago. Most people have only recently started to notice …
Quick: Whats the clock speed on the CPU(s) in your current workstation? Are you running at 10GHz? On Intel chips, we reached 2GHz a long time ago (August 2001), and according to CPU trends before 2003, now in early 2005 we should have the first 10GHz Pentium-family chips. A quick look around shows that, well, actually, we dont. Whats more, such chips are not even on the horizonwe have no good idea at all about when we might see them appear.
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
Moore's Law never stated that CPU speed would double every year—no, it in fact stated that transistor densities would double every 18 months. It was a side effect that processors doubled in speed each time (and in recent times, about every 12 months or so). But this article stipulates that raw CPU speed has pretty much capped out so traditional software methodologies are ill- suited to the new reality of stagnating CPU speeds (Hah! looks like Microsoft is in trouble now) and that programmers now need to learn concurrent programming if they're going to take advantage of multiprocessor systems (which are becoming more prevelent; if CPUs won't get much faster, put in more CPUs).
Concurrent programming isn't easy. It's hard. Harder than you think.
And I expect because of that, just as most languages adapted some form of object-oriented programming over the past fifteen years, that programming languages will adapt some form of functional programming over the coming years.
