Why Do I Need to Know This? What’s in It for Me?
I’m tempted to be a tad flippant and tell you that there’s no way to avoid this topic; multicore
processors are here now and here to stay, and if you want to remain a vital and employable
programmer, you have no choice but to learn and master this material. Of course, I’d be waving
my hands around manically for emphasis and trying to put you into a frightened state of mind.
While all that is true to some degree, a kinder and gentler approach is more likely to gain your
trust and get you on board with the concurrent programming revolution.
Whether you’re a faceless corporate drone for a large software conglomerate, writing code for
a small in-house programming shop, doing open source development, or just dabbling with
writing software as a hobby, you are going to be touched by multicore processors to one degree
or another. In the past, to get a burst of increased performance out of your applications, you
simply needed to wait for the next generation of processor that had a faster clock speed than
the previous model. A colleague of mine once postulated that you could take nine months off
to play the drums or surf, come back after the new chips had been released, run some
benchmarks, and declare success. In his seminal (and by now, legendary) article, “The Free
Lunch Is Over: A Fundamental Turn Toward Concurrency in Software” (
Dr. Dobb’s Journal
,
March 2005), Herb Sutter explains that this situation is no longer viable. Programmers will
need to start writing concurrent code in order to take full advantage of multicore processors
and achieve future performance improvements.
What kinds of performance improvements can you expect with concurrent programming on
multicore processors? As an upper bound, you could expect applications to run in half the time
using two cores, one quarter of the time running on four cores, one eighth of the time running
on eight cores, and so on. This sounds much better than the 20–30% decrease in runtime when
using a new, faster processor. Unfortunately, it takes some work to get code whipped into shape
and capable of taking advantage of multiple cores. Plus, in general, very few codes will be able
to achieve these upper bound levels of increased performance. In fact, as the number of cores
increases, you may find that the relative performance actually decreases. However, if you can
write good concurrent and multithreaded applications, you will be able to achieve respectable
performance increases (or be able to explain why you can’t). Better yet, if you can develop
your concurrent algorithms in such a way that the same relative performance increases seen
on two and four cores remains when executing on 8, 16, or more cores, you may be able to
devote some time to your drumming and surfing. A major focus of this book will be pointing
out when and how to develop such
scalable
algorithms.
Isn’t Concurrent Programming Hard?
Concurrent programming is no walk in the park, that’s for sure. However, I don’t think it is as
scary or as difficult as others may have led you to think. If approached in a logical and informed
fashion, learning and practicing concurrent programming is no more difficult than learning
another programming language.
4 C HA PT ER 1 : W AN T TO G O FA ST ER ? RA IS E YO UR H AN DS I F YO U WA NT T O GO F AS TE R!
