来自Erlang Programming(2009):
Erlang并发性快速且可扩展.它的进程是轻量级的,因为Erlang虚拟机不会为每个创建的进程创建一个OS线程.它们在VM中创建,调度和处理,与底层操作系统无关.结果,进程创建时间大约为微秒,并且与并发存在的进程的数量无关.将其与Java和C#进行比较,其中为每个进程创建底层OS线程:您将获得一些非常有竞争力的比较,Erlang大大优于两种语言.
来自Erlang的并发编程(pdf) (幻灯片)(2003):
我们观察到创建Erlang进程所需的时间是1μs到2,500个进程; 此后,对于多达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线程更有效？为什么操作系统中的线程不能以同样有效的方式实现和管理？为什么操作系统线程的内存占用量更大,产生和通信速度更慢？
BEA和M.的字母代表什么？我记得看到对首字母缩略词"BEAM"的解释,但我还没有找到它.
它出现在错误代码中:
? gentoo iex
Erlang/OTP 17 [erts-6.4.1] [source] [64-bit] [smp:8:8] [async-threads:10] [kernel-poll:false]
Interactive Elixir (1.0.4) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> import Math
08:05:02.839 [error] Loading of /var/opt/proj/elx/ubuntu/Elixir.Math.beam failed: :badfile
** (CompileError) iex:1: module Math is not loaded and could not be found
08:05:02.846 [error] beam/beam_load.c(1104): Error loading module 'Elixir.Math':
non-ascii garbage '78705400' instead of chunk type id
(elixir) src/elixir_exp.erl:123: :elixir_exp.expand/2
iex(1)>
因此,看起来.beam文件存在某种问题,可能是由于我使用了vi.(注意Elixir程序员:不要编辑.beam文件,这很痛苦.)
这个问题解释了BEAM虚拟机是什么,而不是字母代表什么.似乎很难在Erlang中心快速找到关于词源的更多信息.据说 BEAM是Erlang和Elixir的秘诀.
Erlang是一种众所周知的编程语言，因其轻量级线程而闻名（除其他外）。Erlang 通常是用BEAM 机器实现的。Erlang BEAM 机器的描述 (H'97) 说
为了保证公平调度，一个进程在经过固定数量的减少后被挂起，然后从队列中恢复第一个进程。
我对这种减少的概念很感兴趣。根据 (H'97)，只有以下 BEAM 命令算作减少：
所有这些都涉及函数调用。相比之下，调用 C 函数（例如TrC/TrCO）和调用内置函数（例如由Bif_0_ 调用）不算作减少。
问题。在这个序言之后，这是我想知道的。
(H'97) B. Hausman，Erlang BEAM 虚拟机规范。
concurrency erlang multithreading scheduling vm-implementation