In his famous The Free Lunch Is Over article from 2005, Herb Sutter predicted a Concurrent Programming Revolution as big as Object-Oriented Revolution. Has this revolution really happend in years 2005 – 2013?
Key points in the article:
-
Processor manufacturers have run out of room with most of their traditional approaches to boosting CPU performance. Instead of driving clock speeds ever higher, they are instead turning to hyperthreading and multicore architectures.
-
Applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains.
-
“Oh, performance doesn’t matter so much, computers just keep getting faster” statement will be wrong.
-
Efficiency and performance optimization will get more, not less, important. Those languages that already lend themselves to heavy optimization will find new life; those that don’t will need to find ways to compete and become more efficient and optimizable. Expect long-term increased demand for performance-oriented languages and systems.
-
Programming languages and systems will increasingly be forced to deal well with concurrency. We desperately need a higher-level programming model for concurrency than languages offer today.
7
Yes, but it depends.
You can’t expect to write nontrivial, high-performance software without both taking advantage of parallel hardware and using concurrency as a program structuring technique. But most software is both trivial and non–performance-critical. A web app isn’t doing much number crunching, and CRUD apps have nothing like the hard timing limits of some simulation and medical software.
Game developers in particular need to care about this, because games are the most common type of application with soft realtime requirements. The problem is salient on a mobile phone, where you want to squeeze as much computing and rendering power as possible out of an integrated chip with two CPU cores and a low-power GPU. That’s another reason that so many developers are looking at Haskell and waiting for languages like Rust to mature—we want safety and performance on modern hardware.
Since 2005 we have gained new and improved tools such as OpenCL, CUDA, OpenMP, and vector instruction sets for working with concurrency and data parallelism in established languages. However, the relative newcomers are designed from early on to do many more interesting things with concurrency.
Haskell’s concurrent runtime allows the language to provide rich support for lightweight parallelism (sparks) and concurrency abstractions (threads, channels, and shared mutable references). Go and Rust also offer lightweight tasks, Go using channels and Rust using message passing.
These systems offer memory safety, performant runtimes, and static protection against certain kinds of races. The by-default immutability of Haskell and Rust make concurrency much easier for humans to manage. Erlang was doing this already in the 80s, but the needs of software and our knowledge about how to design programming systems have also improved since—thank goodness.
Finally, many existing languages—I won’t name names—are ready to decline as credible choices for writing new software. Their burdens of complexity and poor concurrency abstractions make them unsuitable for the considerations of modern applications. We are simply waiting for mature alternatives.
2
Here are few data points; decide for yourself if it counts as a revolution.
Parallelized Hardware
Around 2005, both Intel and AMD start mass-producing 2-core desktop x86 CPUs (Pentium D and Athlon 64), with clock speeds around 3 GHz.
In 2006, PlayStation 3 is released, featuring the Cell processor with 8+1 cores at 3.2 GHz.
In 2006, GeForce 8 series is released. It consists of large numbers (~100) of general-purpose ‘stream processors’, as opposed to graphics-specific units. Around 2007, CUDA 1.0 spec is released, allowing some general-purpose computation run on massively-parallel NVidia hardware.
Since then, the tendencies continued.
Say, now, in 2013, both Intel and AMD offer 4, 8, and 16-core CPUs, with clock speeds slightly above mere 4 GHz. Dual-core and quad-core designs are common for lower-power devices, such as laptops and smartphones.
All this is mass-produced, consumer-grade everyday computer hardware.
Software
CUDA is released in 2007, then OpenCL in 2008, allowing to use massively-parallel GPUs in general (non-graphical) computation. The model becomes popular; many hosting companies (e.g. Amazon) offer GPUs for general computing tasks.
Go is released in 2009, featuring very cheap preemptive threads (“goroutines”) and allowing to efficiently express highly concurrent algorithms.
Akka toolkit is released for Java and Scala in 2009, allowing for actor-based concurrency.
Erlang (a highly concurrent language) sees some increase in usage.
Concurrency vs Parallelism
Note that to utilize parallel hardware, one does not necessarily need software concurrency, that is, juggling with threads of execution within a computation. Many problems are solved by parallel, non-interacting processes, where each process is a traditional sequential program.
Parallel processing may utilize more traditional languages and parallel frameworks, like map-reduce or MPC or OpenMP. For such frameworks, presence of multiple cores on the same CPU crystal is not conceptually very different from just having more CPUs in the cluster; the difference is mainly speed.
No free lunch so far
CPU speeds still linger at around 5 GHz at the high end. With better technologies in sight, like graphene transistors, frequencies may again rise in the future, but not very soon probably.