All over the world only We Are (Erlang) right and the others are all wrong

The following views are a bit biased, but a good article

The world is the only one we are right, the others are all wrong. We (Erlang programmers) found the crux and solved the problem correctly, and all the others (non-Erlang) looked in the wrong direction and solved the wrong problem.

The question that other people around the world is trying to solve is how to make existing programs run in parallel. until 2004, Moore's Law worked. Every year our program executes faster, we don't need to be a good programmer, and we don't need to have a better algorithm to make the program faster than a year.

The chips are getting bigger, the clock speed is getting faster, the program is running faster and faster, and the performance is increased by 15% amplitude each year.

By the year 2004, these phenomena have ceased. The chip is already large enough, and the clock speed is fast to all parts of the chip that the clock pulse cannot reach in a clock cycle. The circuit design begins to change. Multi-core processor appears.

From 2004 onwards, the size of the chip is still increasing, but the clock rate starts to become smaller, and the number of CPUs on each chip begins to increase. We went from a time when every chip had only one super processor to a multi-core processor era with slower and weaker performance on each chip.

As a result, the sequential execution of the program appears to be slowing down, one year slower, and the parallel execution of the program is getting faster and quicker.

The problem is that there are very few programs that are executed in parallel.

Erlang is a programming language with concurrency features, so Erlang programs are inherently faster than other programs when they run on computers with parallel capabilities. And the only thing that can stop it from running faster is that there may be bottlenecks in the Erlang program that must be executed sequentially.

In parallel programs there are parts that need to be executed sequentially, which is the fulfillment of the Amdahl law.

Assuming that you have 10% of your programs that need to be executed sequentially (the remainder can be parallel), the execution time of the parallel parts can be compressed approximately 0--as long as there are enough processors that can be parallel. However, the time of the sequential execution portion cannot be reduced.

If your program contains 10% of the code that needs to be executed sequentially, your program will perform up to 10 times times faster. 1/10 of the programs are never up to speed, and the execution time of the other 9/10 programs can be reduced to close to 0.

So, for Erlang programmers, the trick to improve the speed of their programs is to find the parts of the code that need to be executed sequentially.

And for any programmer who writes sequential programs, the way to speed up their programs is to find the parts of their program that can be executed in parallel.

Let the serial program automatically parallelize the journey paved with thorns, unable to walk through. (not entirely, it can be achieved in some special circumstances, but it's not easy).

Today's data centers are full of cool new computers, with up to 24 cores in some top-level configurations. But what about their performance? Are these cool new machines up to 24 times times faster?

Yes for some programs, but not for most programs. For most programs, only one of the 24 CPUs is exploited. The low utilization of the CPU has become a serious problem. This is a testament to Alexander Gounares
Brilliant in Erlang factory talk about the problem.

Alexander's speech gave us a glimpse of the future. He pioneered Concurix and let us see the direction of the future. They are developing tools that automatically identify bottlenecks in the Erlang code that need to be executed sequentially.

Concurix uses these tools to discover bottlenecks in Erlang virtual machines, showing amazing results in their tests. They found a bottleneck in the image processing application, which is a program lock in the Zlib library, written in C. They rewrote it with Erlang and replaced the C code with Erlang.

This is incredible, C program should be faster, the fact is, but it has a sync lock. The Erlang program is slower, but does not have a state lock, which gives it an opportunity to ascend. With the C code removed, the image processing app written in Erlang is much faster than the original C program.

I was amazed at the appearance of such good things.

When Alexander in Erlang Factory's speech video, you're ready to be amazed when you watch. This is the future, and the future will be San Francisco next week.

All over the world only We Are (Erlang) right and the others are all wrong