Scatter/Gather thoughts

by Johan Petersson

The Concurrency Revolution

C++ guru Herb Sutter has written an article about processing performance growth and how he thinks concurrency will be the main driver behind future performance advances. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software will appear in Dr. Dobb's Journal, but the article is available on his website now.

Starting today, the performance lunch isn’t free any more. Sure, there will continue to be generally applicable performance gains that everyone can pick up, thanks mainly to cache size improvements. But if you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multithreaded) application. And that’s easier said than done, because not all problems are inherently parallelizable and because concurrent programming is hard.

I've seen this coming for a few years and I couldn't agree more. While there has been an increased interest for concurrency lately due to hyperthreading and multicore architectures, most developers still perceive multiprocessing and multithreading as difficult and actively avoid such techniques. That needs to change.

Concurrency is difficult, but that's an inevitable technological obstacle we will have to overcome. Better algorithms, tools and languages are needed: commonly used programming languages ignore concurrency issues (C and C++) or offer limited support that is hard to use safely and efficiently (Java and most other imperative languages). New ways to reason about and dealing with concurrency would also be helpful.

Gordon Moore is not God and his prediction is not a law of nature. Transistor counts won't keep increasing if our software is unable to make full use of the extra transistors, and from now on those will often be found in additional execution cores. In order to ensure continuing advance in computing power, software will need to cooperate with hardware by exploiting parallelism and getting rid of the concurrency bottlenecks.

29 December, 2004