从技术上讲，为什么Erlang中的进程比OS线程更有效率？

Erlang的特征

来自Erlang编程（2009）：

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

摘自Erlang的面向并发编程（pdf） （幻灯片）（2003）：

我们观察到，创建一个Erlang进程所花费的时间在2,500个进程中恒定为1µs。此后，对于多达30,000个处理，它增加到大约3µs​​。图的顶部显示了Java和C＃的性能。对于少量的过程，创建一个过程大约需要300µs。创建两千多个流程是不可能的。

我们看到，对于多达30,000个进程，在两个Erlang进程之间发送消息的时间约为0.8µs。对于C＃，每条消息大约需要50µs的时间，最多不超过最大进程数（大约1800个进程）。Java甚至更糟，对于多达100个进程，每条消息花费大约50µs的时间，此后，当大约有1000个Java进程时，它迅速增加到每条消息的10ms。

我的想法

我从技术上不完全理解为什么Erlang进程在生成新进程时效率如此之高，而每个进程的内存占用却少得多。OS和Erlang VM都必须进行调度，上下文切换，并跟踪寄存器中的值等等。

就是为什么OS线程的实现方式与Erlang中的进程不同？他们还需要更多支持吗？为什么他们需要更大的内存空间？为什么它们的生成和通讯速度较慢？

从技术上讲，在生成和通信方面，为什么Erlang中的进程比OS线程更有效？为什么不能以同样有效的方式来实现和管理操作系统中的线程？为何OS线程占用的内存更大，并且生成和通讯速度较慢？

更多阅读

• 专注于SMP的Erlang VM内部（2008）
• Java和Erlang中的并发性（pdf）（2004）
• Java和进程中的线程的性能度量（Erlang，1998年）

有几个促成因素：

1. Erlang进程不是OS进程。它们由Erlang VM使用轻量级的协作线程模型（在Erlang级别上是抢占式，但在协作调度的运行时的控制下）实现。这意味着切换上下文要便宜得多，因为它们仅在已知的受控点进行切换，因此不必保存整个CPU状态（常规，SSE和FPU寄存器，地址空间映射等）。
2. Erlang进程使用动态分配的堆栈，该堆栈开始时很小，并根据需要增长。这样就可以产生数千甚至上百万个Erlang进程，而不会占用所有可用的RAM。
3. Erlang以前是单线程的，这意味着不需要确保进程之间的线程安全。它现在支持SMP，但是在同一调度程序/内核上的Erlang进程之间的交互仍然非常轻巧（每个内核有单独的运行队列）。

经过更多研究后，我找到了Joe Armstrong的演示文稿。

从Erlang-并发世界（演示）软件（13分钟）：

[Erlang]是一种并发语言–意思是说线程是编程语言的一部分，它们不属于操作系统。这确实是Java和C ++等编程语言的错误所在。它不是编程语言中的线程，而是操作系统中的线程-它们继承了操作系统中存在的所有问题。问题之一是内存管理系统的粒度。 操作系统中的内存管理保护整个内存页面，因此线程可以使用的最小大小是页面的最小大小。 那实际上太大了。

如果您在计算机上增加了更多的内存（保护内存的位数相同，因此页表的粒度会增加），那么最终您会说64kB的进程占用数百个字节。

我认为它至少回答了我的几个问题

我已经在汇编程序中实现了协程，并评估了性能。

在协处理器之间（也称为Erlang进程）之间的切换在现代处理器上大约需要16条指令和20纳秒。另外，您经常知道要切换到的进程（例如：可以将在队列中接收消息的进程实现为从调用进程到接收进程的直接交接），因此调度程序不会起作用，它是O（1）运算。

要切换OS线程，大约需要500-1000纳秒，因为您要调用内核。OS线程调度程序可能在O（log（n））或O（log（log（n（n））））时间中运行，如果您有成千上万甚至数百万个线程，这将开始引起注意。

因此，Erlang进程更快，扩展性更好，因为交换的基本操作都更快，并且调度程序的运行频率更低。

Erlang进程（大约）对应于绿色线程于其他语言的；进程之间没有操作系统强制的隔离。（可能存在语言强制的分隔，但这尽管Erlang比大多数人做得更好，但是保护程度较小。）由于它们的重量轻得多，因此可以广泛使用。

另一方面，OS线程可以简单地安排在不同的CPU内核上，并且（大多数）可以支持独立的CPU绑定处理。OS进程类似于OS线程，但是具有更强的OS强制分离。这些功能的代价是OS线程和（甚至更多）进程更加昂贵。

了解差异的另一种方法是这样。假设您要在JVM之上编写Erlang的实现（这不是一个特别疯狂的建议），那么您将使每个Erlang进程成为具有某种状态的对象。然后，您将拥有一个运行Erlang进程的Thread实例池（通常根据主机系统中的内核数量确定大小；这是真实的Erlang运行时BTW中的可调参数）。反过来，这将在可用的实际系统资源上分配要完成的工作。这是一种非常整齐的处理方式，但是完全依赖因为每个单独的Erlang进程做得并不多。当然可以；Erlang的结构使其不需要繁重的流程，因为执行该程序的是它们的整体集合。

在许多方面，真正的问题是术语之一。Erlang称为进程的事物（与CSP，CCS尤其是π演算中的相同概念高度对应）与具有C继承的语言（包括C ++，Java，C＃和许多其他）调用进程或线程。有一些相似之处（都涉及并发执行的概念），但是绝对没有对等的地方。因此，当有人对您说“处理”时要小心；他们可能会理解它的含义完全不同...

我认为Jonas需要一些数字来比较OS线程和Erlang进程。编程Erlang的作者Joe Armstrong不久前测试了将Erlang进程产生到OS线程的可伸缩性。他用Erlang编写了一个简单的Web服务器，并针对多线程Apache进行了测试（因为Apache使用OS线程）。有一个旧的网站，其数据可以追溯到1998年。我只找到了该网站一次。因此我无法提供链接。但是信息在那里。研究的重点表明，Apache最多可以使用8K进程，而他的手写Erlang服务器可以处理10K +进程。

因为Erlang解释器只需要担心自己，所以OS还有许多其他事情要担心。

原因之一是不是在操作系统中创建erlang进程，而是在evm（erlang虚拟机）中创建了erlang进程，因此成本更低。