* * * * *
                                        
                                   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 (Central Processing
> Unit) 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 (gigaHertz)? 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
[1]”

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 [2] programming [3] over the
coming years.

[1] http://www.gotw.ca/publications/concurrency-ddj.htm
[2] http://www.cs.nott.ac.uk/Department/Staff/gmh/faq.html
[3] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

Email author at sean@conman.org