Concurrency - Java: The Good Parts - page 161

Chapter 10. Concurrency
There was a time, not all that long ago, when it was easy to improve the performance of your
programs. You could take a look at what a program was doing using a profiler and study the
inner loops of the code. You could write dozens of test cases, varying the load on the program,
to see which optimization was working under what set of circumstances. You could handcraft
clever data structures that would save cycles per call. If you were industrious and lucky, all of
this work would take about 18 months, at which time the new generation of processors would
become available and your program would suddenly run about twice as fast. Lather, rinse, re-
peat.
But this pattern has changed recently. Cranking up the clock (and therefore the speed) on a
processor has become harder and harder to do. People are now worried about energy effi-
ciency, which goes down as the clock goes up. The corollary to the energy problem is the heat
problem; chips are getting harder and harder to cool as they go faster and faster. It has been
some time since the raw speed of the CPU has seen a significant bump.
We are still seeing the effects of Moore's Law; CPU designers are still cramming more and
more transistors on each piece of silicon. But rather than using those transistors to make the
CPU faster, they have moved to producing multicore chips, in which multiple copies of the
CPU share a chip. The idea is that if you have multiple programs running on a machine, you
can run each program in its own core and get twice the overall performance. [ 37 ]
Now, instead of the chip being twice as fast every 18 months, the chips seem to be getting
twice as many cores every 18 months. The chip jockeys can still claim that they are doubling
performance every 18 months, but now they mean that they can run twice as many programs
concurrently.
These extra cores don't do anything to automatically speed up your program. Your program
will take just as long to run as it did on the previous generation of hardware. Unless, that is,
you have written your program to take advantage of these extra cores. If your program has a
high degree of concurrency, so that it can run on multiple cores at the same time, doubling
the number of cores available to your program could double the speed of that program. [ 38 ] But
you have to write the program differently than you would write a standard, sequential pro-
gram. You need to write your program to take advantage of concurrency.