Optimising for Concurrency: Comparing and contrasting the BEAM and JVM virtual machines.

Highlights of the BEAM

Erlang and the BEAM VM were invented to be the right tool to solve a specific problem. They were developed by Ericsson to help implement telecom infrastructure handling both mobile and fixed networks. This infrastructure is highly concurrent and scalable in nature. It has to display soft real-time properties and may never fail. We don’t want our Hangouts calls on our mobile with our grandmothers dropped or our online gaming experience of Fortnite to be affected by system upgrades, high user load or software, hardware and network outages. The BEAM VM is optimised to solve many of these challenges by providing fine-tuned features which work on top of a predictable concurrent programming model.

Highlights of the JVM

The Java Virtual Machine (JVM) was developed by Sun Microsystem with the intent to provide a platform for ‘write once’ code that runs everywhere. They created an object oriented language similar to C++, but memory-safe because its runtime error detection checks array bounds and pointer dereferences. The JVM ecosystem became extremely popular with the Internet-era, making it the de-facto standard for enterprise server applications. The wide range of applicability was enabled by a virtual machine that caters for a wide range use cases, and an impressive set of libraries catering for enterprise development.

Concurrency and Parallelism

We talk about parallel code execution if parts of the code are run at the same time on multiple cores, processors or computers, while concurrent programming refers to handling events arriving to the system independently. Concurrent execution can be simulated on single threaded hardware, while parallel execution cannot. Although this distinction may seem pedantic, the difference results in some very different problems to solve. Think of many cooks making a plate of Carbonara pasta. In the parallel approach, the tasks are split across the number of cooks available, and a single portion would be completed as quickly as it took these cooks to complete their specific tasks. In a concurrent world, you would get a portion for every cook, where each cook does all of the tasks. You use parallelism for speed and concurrency for scale.

The BEAM and Concurrency

The BEAM provides light-weight processes to give context to the running code. These processes, also called actors, don’t share memory, but communicate through message passing, copying data from one process to another. Message passing is a feature that the virtual machine implements through mailboxes owned by individual processes. The message passing is a non-blocking operation, which means that sending a message to another process is almost instantaneous and the execution of the sender is not blocked. The messages sent are in the form of immutable data, copied from the stack of the sending process to the mailbox of the receiving one. This is achieved without the need for locks and mutexes among the processes, only a lock on the mailbox in case multiple processes send a message to the same recipient in parallel.

Scheduler

We mentioned that one of the strongest features of the BEAM is the ability to break a program into small, light-weight processes. Managing these processes is the task of the scheduler. Unlike the JVM, which maps its threads to OS threads and lets the operating system schedule them, the BEAM comes with its own scheduler.

Garbage Collector

Modern, high level programming languages today mostly use a garbage collector for memory management. The BEAM languages are no exception. Trusting the virtual machine to handle the resources and manage the memory is very handy when you want to write high level concurrent code, as it simplifies the task. The underlying implementation of the garbage collector is fairly straightforward and efficient, thanks to the memory model based on immutable state. Data is copied, not mutated and the fact that processes do not share memory removes any process interdependencies, which, as a result, do not need to be managed.

When not to use the BEAM

It is very much about the right tool for the job. You need a system to be extremely fast, but are not concerned about concurrency? Handling a few events in parallel, and having to handle them fast? Need to crunch numbers for Graphics, AI or analytics? Go down the C++, Python or Java route. Telecom infrastructure does not need fast operations on floats, so speed was never a priority. Aided with dynamic typing, which has to do all type checks at runtime means compiler time optimizations are not as trivial. So number crunching is best left to the JVM, Go or other languages which compile to native. It is no surprise that floating point operations on Erjang, the version of Erlang running on the JVM, was 5000% faster than the BEAM. But where we’ve seen the BEAM shine is using its concurrency to orchestrate number crunching, outsourcing the analytics to C, Julia, Python or Rust. You do the map outside the BEAM and the reduce within the BEAM.

Conclusion

Use the right tool for the job. If you are writing a soft real time system which has to scale out of the box and never fail, and do so without the hassle of having to reinvent the wheel, the BEAM is the battle proven technology you are looking for. For many, it works as a black box. Not knowing how it works would be analogous to driving a Ferrari and not being capable of achieving optimal performance or not understanding what part of the motor that strange sound is coming from. This is why you should learn more about the BEAM, understand its internals and be ready to finetune and fix it. For those who have used Erlang and Elixir in anger, we have launched a one day instructor-led course which will demystify and explain a lot of what you saw whilst preparing you to handle massive concurrency at scale. The course is available through our new instructor lead remote training, learn more here. We also recommend The BEAM book by Erik Stenman and the BEAM Wisdoms, a collection of articles by Dmytro Lytovchenko.

You may also like:

1.One of the authors also likes a similar looking dish not called carbonara but made with cream..

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Erlang Solutions

Erlang Solutions

World-class solutions for issues of scale, reliability & performance. Passionate about Erlang & Elixir. MongooseIM & WombatOAM creators. Also RabbitMQ experts!