从技术上讲，为什么 Erlang 中的进程比 OS 线程更高效? [英] Technically, why are processes in Erlang more efficient than OS threads?

问题描述

来自 Erlang 编程(2009 年):

From Erlang Programming (2009):

Erlang 并发速度快且可扩展.它的进程是轻量级的，因为 Erlang 虚拟机不会为每个创建的进程创建一个操作系统线程.它们在 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 年):

From Concurrency oriented programming in Erlang (pdf) (slides) (2003):

我们观察到创建一个 Erlang 进程所花费的时间是恒定的 1µs，最多可达 2,500 个进程；此后，对于多达 30,000 个过程，它增加到大约 3μs.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 微秒.对于 C#，每条消息大约需要 50 微秒，达到最大进程数(大约 1800 个进程).Java 甚至更糟，对于多达 100 个进程，每条消息需要大约 50 微秒，此后当有大约 1000 个 Java 进程时，它迅速增加到每条消息 10 毫秒.

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 进程在生成新进程方面效率如此之高，并且每个进程的内存占用要小得多.OS 和 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 中的进程在生成和通信方面比 OS 线程更有效?为什么不能以同样有效的方式实现和管理操作系统中的线程?为什么操作系统线程有更大的内存占用，加上更慢的生成和通信?

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?

• Erlang VM 内部专注于 SMP (2008)
• Java 中的并发性和在 Erlang (pdf) (2004)
• Java 线程和 Erlang 进程的性能测量(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 进程不是操作系统进程.它们由 Erlang VM 使用轻量级协作线程模型(在 Erlang 级别抢占，但在协作调度运行时的控制下)实现.这意味着切换上下文的成本要低得多，因为它们只在已知的受控点切换，因此不必保存整个 CPU 状态(正常、SSE 和 FPU 寄存器、地址空间映射等).
2. Erlang 进程使用动态分配的堆栈，这些堆栈开始时很小，并根据需要增长.这允许在不占用所有可用 RAM 的情况下生成数千甚至数百万个 Erlang 进程.
3. Erlang 曾经是单线程的，这意味着不需要确保进程之间的线程安全.它现在支持 SMP，但同一调度程序/内核上的 Erlang 进程之间的交互仍然非常轻量级(每个内核有单独的运行队列).

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