是什么让Erlang不适合计算成本高昂的工作？

Question

在Erlang编程的开头,有以下内容:

是什么让Erlang成为您项目的最佳选择？这取决于你想要建立什么.如果您正在考虑编写一个数字运算应用程序,图形密集型系统或在手机上运行的客户端软件,那么抱歉,您买错了书.

隐含的信息是Erlang不适合计算上昂贵的工作.是什么让Erlang如此不合适,或者我误解了？

Answer 1

Erlang为I/O绑定应用程序提供了亮点,即问题的限制因素是I/O操作的延迟和吞吐量,而不是指令可以通过CPU管道推送的速率.Web服务器和数据库是I/O绑定应用程序的良好示例:限制因素可能是磁盘和网络而不是CPU.传统上"计算量大"的应用程序包括加密工具和科学模拟.

至于为什么Erlang在遇到计算密集型问题时无法匹配像C和Fortran这样的语言,我们必须考虑代码生成和缓存友好等问题......我会试一试:

• 代码生成:通常在启动Erlang程序时,它将在BEAM中运行,BEAM是一个基于线程代码的虚拟机.尽管BEAM在大多数情况下表现良好,但每个逻辑"指令"的开销要比现代优化C编译器生成的代码要大得多.HiPE项目为Erlang提供了一个本机代码编译器,几年前就已经集成到主OTP源代码树中了*.虽然它确实提高了Erlang的数字运算能力,但仍然很难匹配编写良好的C或Fortran程序.
• 缓存友好性:内存系统是现代计算机的主要瓶颈:从主内存读取可能需要数百个处理器周期!为了解决这个问题,CPU设计人员引入了几个级别的缓存来隐藏内存延迟.缓存利用计算机程序的两个关键属性:时间和空间局部性 - 即,最近引用的内存区域(和附近区域)可能再次被引用.像C和Fortran这样的语言提供了对内存分配位置和方式的大量控制,使程序员能够调整算法以便与缓存很好地协作.对于像Erlang这样的动态语言,通常也不会这样,其中内存分配对程序员是隐藏的,并由虚拟机自动处理.
• 代码大小:关于空间局部性的论证也适用于代码; Erlang代码,无论是本机代码还是字节代码形式,通常都会大于相应的编译C代码.这导致指令高速缓存中更频繁的未命中.

请记住,这只是冰山一角,我绝不是Erlang或语言实现方面的专家.不要让Erlang可能永远不会进行科学模拟的事实吓到你了; 对于许多应用程序来说,它是一种绝对出色的语言.

*HiPE可通过Debian中的erlang-base-hipe包或./configure --enable-hipe源tarball获得.

Answer 2

只是C代码在大多数情况下可能会相当快.Erlang非常擅长容错,分布式计算和并发.程序员往往同样精通编写erlang或其他语言,但如果你想要速度,可以使用C或C++,也许来自erlang端口,因此这段代码可以在你自己的erlang应用程序中使用.

Answer 3

Erlang是一种并发函数编程语言,专为编写大型工业实时系统而设计.没有什么能够特别阻止您开发"数字运算应用程序或图形密集型系统",但该语言在实时事件处理中闪耀.