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

Question

在Erlang编程的开头，有以下内容：

  

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

隐含的信息是Erlang不适合计算成本高昂的工作。是什么让Erlang如此不合适，或者我误解了？

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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