在技​​术上，为什么Erlang的进程比OS线程更有效率？ [英] Technically, why are processes in Erlang more efficient than OS threads?

问题描述

从 Erlang Programming （2009）：

Erlang并发性快速可扩展。它的进程是轻量级的，因为Erlang虚拟机不会为每个创建的进程创建一个OS线程。它们在VM中创建，计划和处理，与底层操作系统无关。因此，流程创建时间大约为微秒，并且与并发现有流程的数量无关。与Java和C＃进行比较，每个进程都创建一个基础的操作系统线程：您将获得一些非常有竞争力的比较，Erlang的性能优于两种语言。

Erlang concurrency is fast and scalable. Its processes are lightweight in that the Erlang virtual machine does not create an OS thread for every created process. They are created, scheduled, and handled in the VM, independent of underlying operating system. As a result, process creation time is of the order of microseconds and independent of the number of concurrently existing processes. Compare this with Java and C#, where for every process an underlying OS thread is created: you will get some very competitive comparisons, with Erlang greatly outperforming both languages.

从 Erlang中的并发导向编程（pdf） （幻灯片）（2003）：

我们观察到，创建Erlang进程所花费的时间是1μs最多2500个进程;此后，它可以增加到大约3μs，最多可达30,000个进程。 Java和C＃的性能显示在图的顶部。对于少量进程，创建一个进程大约需要300μs。创建两千多个进程是不可能的。

We observe that the time taken to create an Erlang process is constant 1µs up to 2,500 processes; thereafter it increases to about 3µs for up to 30,000 processes. The performance of Java and C# is shown at the top of the figure. For a small number of processes it takes about 300µs to create a process. Creating more than two thousand processes is impossible.

我们看到，对于多达30,000个进程，在两个Erlang进程之间发送消息的时间约为0.8μs。对于C＃，每个消息大约需要50μs，最多可以达到最大进程数（约为1800个进程）。 Java更糟糕的是，对于多达100个进程，每个消息大约需要50μs，当它们有大约1000个Java进程时，它迅速增加到每个消息10ms。

We see that for up to 30,000 processes the time to send a message between two Erlang processes is about 0.8µs. For C# it takes about 50µs per message, up to the maximum number of processes (which was about 1800 processes). Java was even worse, for up to 100 process it took about 50µs per message thereafter it increased rapidly to 10ms per message when there were about 1000 Java processes.

我的想法

我不完全明白为什么Erlang进程在产生新进程时效率更高，每个进程的内存占用空间要小得多。操作系统和Erlang VM都必须执行调度，上下文切换，并跟踪寄存器中的值等等...

My thoughts

I don't fully understand technically why Erlang processes are so much more efficient in spawning new processes and have much smaller memory footprints per process. Both the OS and Erlang VM have to do scheduling, context switches, and keep track of the values in the registers and so on...

只是为什么不是操作系统线程以与Erlang中的进程相同的方式执行？他们是否必须支持更多的东西？为什么他们需要更大的内存占用？为什么它们的产卵和沟通较慢？

Simply why aren't OS threads implemented in the same way as processes in Erlang? Do they have to support something more? And why do they need a bigger memory footprint? And why do they have slower spawning and communication?

技术上，为什么Erlang中的进程在产卵和沟通方面比操作系统线程更有效率？为什么操作系统中的线程不能以同样有效的方式实现和管理？为什么操作系统线程有更大的内存占用，加上较慢的产生和通信？

Technically, why are processes in Erlang more efficient than OS threads when it comes to spawning and communication? And why can't threads in the OS be implemented and managed in the same efficient way? And why do OS threads have a bigger memory footprint, plus slower spawning and communication?

• 重点放在SMP上的Erlang VM内部 （2008）


• Java和Erlang中的并发（pdf）（2004）


• Erlang中Java和进程中线程的性能测量（1998）

• Inside the Erlang VM with focus on SMP (2008)
• Concurrency in Java and in Erlang (pdf) (2004)
• Performance Measurements of Threads in Java and Processes in Erlang (1998)

推荐答案

有几个因素：

1. Erlang进程不OS进程。它们由Erlang VM使用轻量级协作线程模型（在Erlang级别抢占，但在协作调度运行时的控制下）实现。这意味着切换上下文便宜得多，因为它们只切换已知的受控点，因此不必保存整个CPU状态（正常，SSE和FPU寄存器，地址空间映射等）。 li>
   
2. Erlang进程使用动态分配的堆栈，这些堆栈开始非常小，并根据需要增长。这样可以产生数千甚至数百万的Erlang进程，而不会吸收所有可用的RAM。


3. Erlang曾经是单线程的，这意味着没有必要确保线程 - 过程之间的安全。它现在支持SMP，但同一个调度器/核心上的Erlang进程之间的交互仍然非常轻量级（每个核心都有单独的运行队列）。

这篇关于在技​​术上，为什么Erlang的进程比OS线程更有效率？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！