The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

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.

Obligatory Picture

[The future's so bright, I gotta wear shades]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site: https://boston.conman.org/, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

https://boston.conman.org/2000/08/01

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2024 by Sean Conner. All Rights Reserved.