Erlang以能够支持许多轻量级进程而闻名; 它可以这样做,因为它们不是传统意义上的进程,甚至不像P线程中的线程,而是完全在用户空间中线程化。 这是好的(实际上很棒)。 但是,在多核/多处理器环境中,Erlang线程如何并行执行呢? 当然,他们必须以某种方式映射到内核线程才能在不同的内核上执行? 假设情况如此,这是如何完成的? 很多轻量级进程是否映射到单个内核线程? 还是有另一种解决这个问题的方法?
我一直在阅读“真实世界Haskell”一书,关于并发性和并行性的一章。 我的问题如下: 由于Haskell线程真的只是一个“真正的”OS线程中的多个“虚拟”线程,这是否意味着创build很多(如1000)不会对性能产生严重影响? 也就是说,我们可以说用forkIO创build一个Haskell线程的开销(几乎)可以忽略不计? 如果可能,请带上切实的例子。 轻量级线程的概念不妨碍我们使用多核架构的好处吗? 据我所知,两个Haskell线程不可能同时在两个独立的内核上执行,因为从操作系统的angular度来看,它们确实是一个单一的线程。 还是Haskell运行时做了一些巧妙的技巧,以确保可以使用多个CPU?
Erlang的特点 来自Erlang编程 (2009): Erlang的并发性是快速和可扩展的。 其进程是轻量级的,因为Erlang虚拟机不会为每个创build的进程创build一个OS线程。 它们是在虚拟机中创build,调度和处理的,与底层操作系统无关。 因此,进程创build时间是微秒级的,并且与现有进程的数量无关。 将它与Java和C#进行比较,在每个进程中创build一个底层操作系统线程:您将得到一些非常有竞争力的比较结果,Erlang的性能大大超过了这两种语言。 来自Erlang的并发导向编程(pdf) (幻灯片) (2003): 我们观察到创build一个Erlang过程所花费的时间是恒定的1μs到2500个过程; 此后,对于多达30000个过程,其增加到约3μs。 Java和C#的性能显示在图的顶部。 对于less量的stream程来说,创build一个stream程大约需要300μs。 创build两千多个进程是不可能的。 我们看到,对于多达30,000个进程,在两个Erlang进程之间发送消息的时间大约是0.8μs。 对于C#,每个消息大约需要50μs,直到最大进程数(大约1800个进程)。 Java甚至更糟糕,对于高达100个进程,每个消息花费大约50μs,而当有大约1000个Java进程时,每个消息快速增加到10ms。 我的想法 我没有完全理解为什么Erlang进程在产生新进程方面更有效率,并且每个进程的内存占用更小。 操作系统和Erlang虚拟机都必须执行调度,上下文切换以及跟踪寄存器中的值等。 简单地说,为什么OS线程不像Erlang中的进程一样实现呢? 他们需要更多的支持吗? 为什么他们需要更大的内存空间? 为什么他们的产卵和交stream比较慢? 从技术上讲,为什么Erlang中的进程比OS线程在产卵和通信方面更有效率? 为什么操作系统中的线程不能以同样有效的方式实现和pipe理? 为什么操作系统线程有更大的内存占用,再加上较慢的产卵和通信? 更多的阅读 Erlang VM内部重点关注SMP (2008) Java和Erlang中的并发(pdf) (2004) Java和进程中的线程性能测量(Erlang ,1998)