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 doesnt 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 dont 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.
Is The Free Lunch Over?
concurrency
Yes, but it depends.You cant 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 nonperformance-critical. A web app isnt 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. Thats another reason that so many developers are looking at Haskell and waiting for languages like Rust to maturewe 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.Haskells 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 sincethank goodness.Finally, many existing languagesI wont name namesare 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.