This book is not about how to write correct and beautiful code, I am assuming that you already know how to do that. This book isn’t really about performance tuning either, although the final chapters cover things like tracing and profiling which can help you find bottlenecks and unnecessary usage of resources.
Leading up to those last chapters, the real goal with this book is to give you all the information, all the gory details of the BEAM VM, that you may need in order to really understand the performance of your Erlang application.
For anyone who:
-
Wants to tune an Erlang installation.
-
Wants to know how to debug VM crashes.
-
Wants to improve the performance of Erlang applications.
-
Wants to understand how Erlang really works.
-
Wants to learn how to build your own runtime environment.
If all you want to do is performance tweaking, then jump to the last part of the book … but to really understand those chapters in depth, you should read the rest of the book.
The Erlang BEAM VM is a great piece of engineering that can run on anything from a gum-stick computer to the largest multicore system with terabytes of memory. In order to be able to optimize the performance of such a system for your application, you need to not only know your application, but you also need to have a thorough understanding of the VM itself.
With this knowledge, you will be able to understand how your application behaves when running on the BEAM, and you will also be able to find and fix problems with the performance of your application.
You don’t need to be an Erlang programmer to read this book, but you will need some basic understanding of what Erlang is. This following section will give you some Erlang background.
In this section, we will look at some basic Erlang concepts that are vital to understanding the rest of the book.
Erlang has been called, especially by one of Erlang’s creators, Joe Armstrong, a concurrency oriented language. Concurrency is definitely at the heart of Erlang, and to be able to understand how an Erlang system works you need to understand the concurrency model of Erlang.
First of all, we need to make a distinction between concurrency and parallelism. In this book, concurrency is the concept of having two or more processes that can execute independently of each other, this can be done by first executing one process then the other or by interleaving the execution, or by executing the processes in parallel. With parallel executions, we mean that the processes actually execute at the exact same time by using several physical execution units. Parallelism can be achieved on different levels. Through multiple execution units in the execution pipeline in one core, in several cores on one CPU, by several CPUs in one machine, or through several machines, possibly in different locations.
Erlang uses processes to achieve concurrency. Conceptually, Erlang processes are similar to most OS processes: they are isolated memory spaces (hence, they are not threads), they execute in parallel, and can communicate through signals. In practice, there is a huge difference in that Erlang processes are much more lightweight than most OS processes. Many other concurrent programming languages call their equivalent to Erlang processes agents.
Erlang achieves concurrency by interleaving the execution of processes on the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM achieves true parallelism by running one scheduler per core and executing one Erlang process per scheduler. The designer of an Erlang system can achieve further parallelism by distributing the system over several computers.
A typical Erlang system (a server or service built in Erlang) consists
of a number of Erlang applications, which are independently versioned
units of software, such as a microservice or a library.
Each application is made up of several Erlang modules, which are the
fundamental unit of code encapsulation, each module in a separate file
with the extension .beam for compiled code that can be loaded, and
.erl for source code to be compiled.
Each module contains a number of functions, some of which are exported and can be called from other modules, while the rest are internal. A function takes a number of arguments and returns a value. The body of a function is made up of expressions. Since Erlang is a functional language, it has no statements, only expressions, which produce a result. In Erlang Code Examples we can see some examples of Erlang expressions and functions.
%% Some Erlang expressions:
true.
1+1.
if (X > Y) -> X; true -> Y end.
%% An Erlang function:
max(X, Y) ->
if (X > Y) -> X;
true -> Y
end.Erlang has a number of built in functions (or BIFs) which are
implemented by the VM. This is either for efficiency reasons, like the
implementation of lists:append() which could easily have been implemented
in Erlang itself. It could also be to
provide some low level functionality, which would be hard or impossible to
implement in Erlang itself, like list_to_atom().
As an end user you can provide your own functions implemented in C by using the Native Implemented Functions (NIF) interface (see [NIFs]).
First of all I want to thank the whole OTP team at Ericsson both for maintaining Erlang and the Erlang runtime system, and also for patiently answering all my questions. In particular I want to thank Kenneth Lundin, Björn Gustavsson, Lukas Larsson, Rickard Green and Raimo Niskanen.
I would also like to thank Yoshihiro Tanaka, Roberto Aloi and Dmytro Lytovchenko for major contributions to the book, and HappiHacking and TubiTV for sponsoring work on the book.
Finally, a big thank you to everyone who has contributed with edits and fixes: