The free lunch is over. Better yet, the free lunch was already over in 2005 and right now we’re starting to pay for it, even though we aren’t aware of it. Edit : there’s an interesting reddit thread for this piece on “Go” vs “GoLang”. As Nicolas Grilly pointed out, I’m just using GoLang for SEO purposes. “The free lunch is over” or “a fundamental turn toward concurrency in software” is a paper by published in Dr.Dobb’s Journal back in March 2005. In it, the author clearly describes the state of the art of hardware innovation in 2005: as did the total performance per clock and the overall power. Do you remember the days when the GHz specs were in front of every ad? Well, 3GHz CPUs were introduced in 2004 and today in 2016 my MacBookPro provides a staggering… 2.7GHz. This physical wall has many implications in the world of software with much of the theory already laid out by in his famous paper “Communicating Sequential Processes”, one of the main inspiration of GoLang. Herb Sutter the Moore Law applied to clock speed had stopped C.A.R. Hoare 35 Years of Microprocessor Trend Data Fast forward to 2016 and we can conclude that not only , but also that the . In other words, don’t let the above graph confuse you: . This is because at smaller scale some quantum properties starts to emerge ( ) and because it actually costs more to put more transistors. Again, . clock speeds have not increased in a decade number of transistors per dollar has started to fall adding more transistors is not the solution tunneling the free lunch is over More walls Back in 2005 the near-term future performance growth drivers were: hyperthreading multicore cache Caches have physical limits: the bigger the cache, the slower it gets. Modern CPUs have L1 and L2 caches directly inside the chip to reduce distances. As the speed of light is not going anywhere faster, — even if measured in — . Caches are much more fast than RAM, but again, they have limits. distance nm equals speed A modern CPU Over the last decade performance, especially on the server, has been dictated by . But multicore CPU comes at a cost too and cannot scale indefinitely: not every application can exploit multicore and the synchronization overhead between the operations hits performance very fast. Some compute-intensive operations that can be massively parallelised (like deep learning, analytics and engineering or simulation) can benefit from GPU-accelerated computing. adding more CPU cores Much of the improvement in performance in the last two decades has come from architectural improvements: out of order execution (super-scalar) speculative execution vector (SSE) instructions NVidia GPU Acceleration “Modern processors are a like nitro fueled funny cars, they excel at the quarter mile. Unfortunately modern programming languages are like Monte Carlo, they are full of twists and turns.” — David Ungar, OOPSLA (year unknown) The solution, part 1: better software All the above points lead toward one crucial point: if we cannot safely rely on the hardware to increase the performance, . And boy what a mess we have there. we need to turn to software Most of the traditional programming languages comes from the 90’s and uses traditional single-threaded processes. Multi-threading is of course available but it’s messy, complicated and way too expensive. Let’s look at a thread in Java: the creation of a thread start out at 1Mb, along with a region of memory called a guard page that acts as a guard between one thread’s memory and another. This means that, if creating a web server, creating one thread per request will eventually lead to an so some level of management is required. Moreover, a thread has significant setup and teardown costs because it has to request resources from the OS and return it once its done. OutOfMemoryError However, even though most programming languages have for multi-threading, the real problem comes with and the , and . For more on the difference between concurrency and parallelism, go see ’s excellent talk . Spoiler: parallelism is about doing the same thing at once, while concurrency can involve parallelism, but it’s more about doing different things at once. As one can quickly see, in the latter case, communication between the “tasks” — or processes — becomes crucial. support concurrent execution perils of threading-locking race conditions deadlocks Rob Pike concurrency is not parallelism Another separate chapter should be dedicated to Object-Oriented-Programming (OOP): in Java everything quickly becomes a pointer which puts lots of pressure on the heap thus running around the CPU, which is not very memory-effective. So what? Are we back to 's and ? Of course not. C allocs free For best performance on today’s hardware in today’s world, we need a programming language which: Is compiled, not interpreted. Permits efficient code to be written. Lets programmers talk about memory effectively, think structs vs java objects Has a compiler that produces efficient code, it has to be small code as well, because cache. The solution, part 2: better programming languages I think that the development community will be much more fragmented in the future than it is already today. However, if the fragmentation lines are now between programming languages (and further down to frameworks within a PL ), the fragmentation lines of the future could very well become over complexity and optimization. In this new world, the real confrontation can occur over the comparison between something like and . NodeJS GoLang NodeJS is relatively easy to write and run, even though On production you need to perform a series of pre-tasks to get your project ready that make the ritual to summon Satan look like a boiled eggs recipe. — Jose Aguinaga, How it feels to learn Javascript in 2016 However, besides all the Babel(s), Typescripts and ES6-ES2016(s) the adoption of JS — especially between corporate — is not slowing down. Most used PL in 2016 on Github This comes down to several reasons, but especially: the relative ease of the language the relative ease of finding devs (front-end devs are already familiar with the language) the vast ecosystem of libraries and tools Despite the awesomeness of the V8 engine and the tricks that can be done on the event loop by implementing promises, . As such, it cannot directly use multi-core CPUs even though it is possible to spawn different processes on several threads. NodeJS is single-threaded On the other side of the spectrum, is heavily targeted as a modern and especially as a replacement for . GoLang C C++ Go is mostly an imperative language (although it has structs and methods that can be used for OOP, and first-class and higher-order functions for FP), it is compiled and it’s garbage collected (like OCaml and Haskell). — (see further down in the comments) Nicolas Grilly , its runtime is incredibly clever and, most importantly, it . In fact, it has its own abstractions over threads (called ) that are automatically managed and can communicate with . However is designed from the ground-up to exploit multi-cores and modern hardware goroutines channels The creation of a goroutine is very cheap: it’s just 2kb (again, a thread requires 1Mb) and the runtime automagically manages them so that they are put on threads when running and removed when blocking. Several memory optimizations can be performed (but discouraged) and it’s somewhat predictable whether or not a variable will be allocated on the heap or on the stack. The solution, part 3: better developers A common belief seems to be that in the future, it will be easier to do programming. I disagree. I think that the contrary is actually true. And the reason is because if hardware isn’t getting any more faster, then . better performance is achieved with optimization, and that is hard Optimization requires not only the mastering of the tool (the software) but also an extensive knowledge of the matter (the hardware). Moreover, . Researchers and Universities are sometimes critical of programming languages like Go — and rightfully so — but the point is not to look at the past and converge on classic OO paradigms, but to improve on what is here to stay. the developer of the future needs to be even more open-minded than the one of the past sometimes Conclusion In conclusion and to wrap-up, . Even though we will not stop anytime soon to have faster CPUs due to incremental changes and innovation in the architecture, as developers we need to start to think more of optimization and best-coding and best-development practices. . too to be able to exploit the full range of multi-core architecture of the CPU with concurrent development. hardware limits are putting more pressure on the software GoLang is the programming language more suited for this kind of development, but that’s not enough Developers needs to understand more about the hardware . Optimized software can run on cheaper and slower hardware. This translates to less expensive cloud servers, higher margins for corporations and overall cost reduction for the end-user. Imagine to run a full-fledged OS with all the capabilities of a modern-day PC on a mobile phone. Think of your mobile phone as your primary and unique computer or to more powerful IoT devices and you can see where optimization can lead innovation in the future. Better developers will have a huge impact on the end user too Credits The inspiration for this piece comes from a workshop with that I have attended during dotGo in Paris. The slides of the workshop can be found . David Cheney here by Herb Sutter The Free Lunch Is Over by C.A.R. Hoare Communicating Sequential Processes by Krishna Sundarram How goroutines work by Jose Aguinaga How it feels to learn JavaScript in 2016
