随着最近有关并行计算的大肆宣传，我一直在思考并行性、数字运算、集群等问题......
我开始阅读Learn You Some Erlang 。随着越来越多的人(包括我自己)学习，Erlang 以一种非常令人印象深刻、优雅的方式处理并发。
然后作者断言Erlang是not ideal for number crunching 。我可以理解像 Erlang 这样的语言会比 C 慢，但是并发模型似乎非常适合图像处理或矩阵乘法之类的事情，尽管作者明确表示不适合。
事情真的有那么糟糕吗？ Erlang 的优势是否存在克服其局部速度劣势的临界点？正在采取什么措施来解决速度问题？
需要明确的是:我并不是想发起一场辩论；我只是想发起一场辩论。我只是想知道。
最佳答案
将并行性仅仅视为原始数字处理能力是错误的。 Erlang 比 GPU 或经典 super 计算机更接近集群计算机的工作方式。
在现代 GPU 和老式 super 计算机中，性能主要取决于矢量化算术、专用计算硬件以及处理单元之间的低延迟通信。由于通信延迟很低并且每个单独的计算单元都非常快，因此理想的使用模式是将数据加载到机器的 RAM 中并让它立即处理所有数据。此处理可能涉及节点之间传递的大量数据，如图像处理或 3D 中所发生的情况，其中需要执行大量 CPU 密集型任务来将数据从输入形式转换为输出形式。当您经常需要访问磁盘、网络或其他一些慢速 I/O channel 来获取数据时，这种类型的机器并不是一个好的选择。这会闲置至少一个昂贵的专用处理器，并且可能还会阻塞数据处理管道，因此其他任何事情也无法完成。
如果您的程序需要大量使用慢速 I/O channel ，更好的机器类型是具有许多廉价独立处理器的机器，例如集群。你可以在一台机器上运行 Erlang，在这种情况下，你会在该机器中得到类似于集群的东西，或者你可以轻松地在实际的硬件集群上运行它，在这种情况下，你有一个集群的集群。在这里，通信开销仍然使处理单元闲置，但由于每个计算硬件上都有许多处理单元运行，Erlang 可以立即切换到其他进程之一。如果碰巧有一整台机器坐在那里等待 I/O，硬件集群中的其他节点仍然可以独立运行。仅当通信开销如此之高以至于每个节点都在等待其他节点或一般 I/O 时，此模型才会崩溃，在这种情况下，您要么需要更快的 I/O 要么需要更多节点，而 Erlang 自然地利用了这两者的。
通信和控制系统是 Erlang 的理想应用，因为每个单独的处理任务只需要很少的 CPU，并且只是偶尔需要与其他处理节点通信。大多数时候，每个进程都是独立运行的，每个进程只占用一小部分 CPU 资源。这里最重要的是能够有效地处理数千个此类问题。
绝对需要经典 super 计算机的经典案例是天气预报。在这里，您将大气分成多个立方体，并进行物理模拟以了解每个立方体中发生的情况，但您不能使用集群，因为空气在每个立方体之间移动，因此每个立方体不断与其 6 个相邻的邻居进行通信。 (空气不会穿过立方体的边缘或角落，是无限细的，因此它不会与其他 20 个相邻的立方体通信。)在集群上运行它，无论是在其上运行 Erlang 还是其他系统，并且它立即变成 I/O 绑定(bind)。
关于performance - Erlang 的并行性何时克服了其在数值计算方面的弱点？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1308527/