At the forefront of virtual machine design

While the first article is being prepared in a training series about the Erlang language, I decided to translate one interesting blog post. A post about the development of the Erlang virtual machine and the goals that its authors are trying to achieve.



The Java virtual machine is now considered the benchmark, crammed with all sorts of optimizations and tricks so that you can break your head. Because of this, many programming languages ​​use it as an executable medium, instead of writing their own virtual machine (although someone still considers this an interesting occupation). I believe that the path chosen by the JVM will eventually become unpopular, since programmers in the very near future will face the problem of utilizing the power of systems with dozens or hundreds of processors.
')
Architects of virtual machines will face the same problem as the creators of processors today - do not do one thing quickly, do several things at the same time. Therefore, I do not believe that the benchmark of the virtual machine is the path chosen by the JVM. Java is not created for such a future:

We look at the image from the blog of Toby Archiani, who stole it from Ulf Wiger, who took it from Joe Armstrong, who borrowed it from Eric Chagershtern. On the graph - the part of the processor, which can be reached in one clock.

At first glance, it is difficult to assess the benefits of using the Erlang virtual machine. The garbage collector operates in soft real time, while the JVM garbage collector operates in hard real time. On-the-fly compilation is slow enough for methods from computational mathematics and cannot “inline” (tell me the correct word?) Between modules as HotSpot does. For inexperienced Erlang administrators in general - horror. For no apparent reason, it starts eating processor time and memory, and the only way to find out what is happening is to get into the shell and type commands in some esoteric language!

But all these problems are very minor if you look at the plans and goals of the Erlang virtual machine. At the beginning of the book Programming to Erlang, one of the creators of the language, Joe Armstrong, talks about the dream of a competitive programming model: your program runs N times faster on N processors. Erlang achieved this goal to some extent using a distributed programming model. But distributed programming is difficult: the moment will come when you will have to take into account the cost of sending messages on the network, deal with latency, lack of a network, server crashes. And although Erlang / OTP provides a powerful platform for developing distributed services, many distribution factors turn out to be insignificant when it comes to one server with a large number of cores in the processor.

VM Erlang supports SMP scheduler running in the normal thread for each processor core. This allows VMs to distribute processes to several processors at the same time avoiding the negative sides of distributed programming. A simple rule of Erlang: create as many processes as you want - the scheduler will load the processor evenly.

And although all this is beautiful and interesting, the SMP scheduler has many bottlenecks. Everything works fine with two or four cores, but as soon as you start to increase this number, the performance will not only not improve, but may fall. The same situation is in the JVM, but based on the fact that this behavior is the result of the fundamental principles and design of this virtual machine, the Erlang competitiveness model gives creators much more optimization options.

A recent presentation of the super-famous Erlanger Ulf Wiger tells us about a very near future for the Erlang virtual machine. The presentation clarified several weak points of scalability and how the authors plan to get rid of them. You can read the presentation yourself, or if you are lazy enough - read on, I will try to do everything for you.

So, here's the tv thing: (sorry for cutting out the drawings from the presentation of Ulf! They rule!)

In this picture was the large logo of Errikson. If anyone complains, I'll make my version.

This is the Erlang virtual machine scheduler. There are many schedulers, each of which works in a separate thread, and executes code from the general command flow. See a weak spot? Look at this bunch of arrows pointing to one place! How to solve this problem? Divide and conquer:



Separating each scheduler with its own execution queue, we will get rid of one weak point, but we will have to correctly distribute the processes between the schedulers. This is already starting to look like the core of the operating system, right? Well, let's see how it affects the scalability of the system:



The red line is today's SMP scheduler with a single execution queue. The blue line is the next generation SMP scheduler, which will be in the next versions of Erlang. As we can see, the separation of a single queue really helped, but after reaching a certain number of cores, the performance starts to fall again. What is the matter?

Again a bunch of arrows pointing to one place! :(

Memory allocation in Erlang is another blocking point and, accordingly, a weak link in the scalability of the system. I suppose that Ulf put it in his presentation because it is another task that the Erlang creators will solve when developing a new SMP planner.

It may seem that these minor improvements in the performance of the scheduler are not so exciting, but step by step the creators of Erlang go through all the bottlenecks of the scalability of the system, increasing the performance of the virtual machine. Based on the basic distribution of Erlang - the potential is huge. And with the increase in the number of cores on the processor (these tests were run on a 64-core processor), all these optimization steps will be more and more needed to utilize all the power of the computing system.

Systems like JVM will certainly not disappear with the advent of a multi-core future. An approach like software transactional memory can be successfully used in the JVM, especially with a language like Clojure for achieving results, in certain parallelization problems, better than the “nothing in common between processes” model in Erlang.

But in general, I find the Erlang approach to competitiveness more understandable and making programmers' lives easier, hiding the entire complexity of distribution to the lowest level of the virtual machine. This approach may be more logical than PTP, especially if it acquires a “human face”, which I am trying to achieve with my project a programming language based on the Erlang virtual machine - Reia. But the main thing is the presence of a huge potential for improving the performance of a virtual machine for multi-core systems, and I hope that one day we will see Joe Armstrong's dream in action - to run programs N times faster on N processors.

PS Russian is not my native language, so any corrections or suggestions for improving readability are welcome. Thank you for reading to the end;)