随着各地的并行计算所有的炒作最近，我一直在想了很多关于并行，数字运算，集群，等等...
我开始阅读了解你一些二郎 。 随着越来越多的人在学习（包括我自己），二郎处理在一个非常令人印象深刻，优雅的方式并行。
于是笔者断言，Erlang是不理想的数字运算 。 我可以理解，像二郎语言会比C慢一些，但对于并发的模式似乎非常适合喜欢的东西图像处理或矩阵乘法，即使专门撰文说，它不是。
难道真的那么糟糕吗？ 是否有一个地方Erlang的力量克服其本地速度的弱点一个临界点？ 是/正在采取什么措施来应对速度？
需要明确的是：我并不想开始辩论; 我只是想知道。
这是一个错误的认为并行的，因为只有大约原始的数字运算能力。 Erlang是接近集群计算机工作比，说的方式，GPU或经典的超级计算机。
在现代GPU和旧式的超级计算机，性能是所有关于矢量运算，专用计算硬件和处理单元之间的低延迟通信。 因为通信延迟低，并且每个单独的计算单元是非常快的，理想的使用模式是装载机器的RAM了数据，并将它立即紧缩这一切。 该处理可能涉及大量节点之间传送数据的，如在图像处理或三维发生，那里有大量CPU密集型任务做从输入表格数据转换，以输出的形式。 这种类型的机器是一个糟糕的选择，当你经常必须去一个磁盘，网络或数据的一些其它慢速I / O通道。 这空转至少一个昂贵，专用处理器，大概也扼流圈数据处理流水线所以不出意外的得到执行，无论是。
如果你的程序需要频繁使用慢速I / O通道，更好的机型是一个与许多廉价的独立的处理器，就像一个集群。 你可以在一台机器，在这种情况下，你的机器中得到的东西像一个集群上运行二郎，或者你可以很容易的实际硬件集群，在这种情况下，你有集群的集群上运行它。 在这里，通信开销仍然空闲处理单元，而是因为你对计算机硬件的每一位运行多个处理单元，二郎可以切换瞬时其他进程中的一个。 如果碰巧整个机器正坐在那里等待I / O，你仍然有可独立运行的硬件集群中的其他节点。 这种模式只发生故障时的通信开销是如此之高，每个节点正在等待其他一些节点上，或用于通用I / O，在这种情况下，您可能需要更快的I / O或多个节点，这两者二郎自然利用的。
通信和控制系统的Erlang的理想应用，因为每个人的处理任务需要很少的CPU和偶尔需要与其它处理节点进行通信。 大多数时候，每个过程独立地操作时，每次服用的CPU功率的一小部分。 这里最重要的是有效地处理成千上万的这些能力。
经典的情况下，你绝对需要一个经典的超级计算机是天气预报。 在这里，你把气氛成立方体，做物理模拟，找出每个立方体会发生什么，但你不能使用群集，因为每个立方体之间的空中动作，所以每个立方体不断与它的6楼相邻的邻居沟通。 （空气不经过一个立方体的边或角，被无限地精细，所以也没有跟其他20个邻近的立方体。）在集群上运行这一点，无论是在它或其他一些系统运行Erlang和它瞬间变得I / O瓶颈。
是否有一个地方Erlang的力量克服其本地速度的弱点一个临界点？
嗯，当然有。 例如，当试图找到一个兆个数字:)的位数：
http://matpalm.com/median/question.html
您发布之前，我碰巧注意到，这是1号岗上erlang.reddit.com。
几乎任何语言可以并行。 在某些语言很简单，在别人它在屁股痛，但它可以做到的。 如果你想跨越8000 CPU在网格上运行一个C ++程序，勇往直前！ 你可以做到这一点。 它已经做过的事情。
二郎不会做任何事情，在其他语言中是不可能的。 如果运行一个Erlang程序的单个CPU比运行C ++程序相同的CPU效率较低，然后200 CPU的运行的Erlang也将慢于200级CPU的运行的C ++。
什么二郎神确实做的是使这种并行的易于使用 。 它节省了开发时间和减少错误的机会。
所以我会说没有，有没有转折点，那Erlang的并行性使得它能够跑赢另一种语言的数值数字运算力。
其中二郎分数是使它更容易进行扩展，所以正确地做。 但它仍然可以，如果你愿意花额外的开发时间，其在数字运算更好的，其他语言来完成。
，当然，我们也不要忘记， 语言没有速度好老点。 足够好的二郎编译器会产生完全最佳代码。 足够糟糕的C编译器将产生运行比什么都慢的代码。
There is pressure to make Erlang execute numeric code faster. The HiPe compiler compiles to native code instead of the BEAM bytecode for example, and it probably has its most effective optimization on code on floating points where it can avoid boxing. This is very beneficial for floating point code, since it can store values directly in FPU registers.
For the majority of Erlang usage, Erlang is plenty fast as it is. They use Erlang to write always-up control systems where the most important speed measurement that matters is low latency responses. Performance under load tends to be IO-bound. These users tend to stay away from HiPe since it is not as flexible/malleable in debugging live systems.
Now that servers with 128Gb of RAM are not that uncommon, and there's no reason they'll get even more memory, some IO-bound problems might shift over to be somewhat CPU bound. That could be a driver.
You should follow HiPe for the development.
Your examples of image manipulations and matrix multiplications seem to me as very bad matches for Erlang though. Those are examples that benefit from vector/SIMD operations. Erlang is not good at parallellism (where one does the same thing to multiple values at once).
Erlang processes are MIMD, multiple instructions multiple data. Erlang does lots of branching behind pattern matching and recursive loops. That kills CPU instruction pipelining.
The best architecture for heavily parallellised problems are the GPUs. For programming GPUs in a functional language I see the best potential in using Haskell for creating programs targeting them. A GPU is basically a pure function from input data to output data. See the Lava project in Haskell for creating FPGA circuits, if it is possible to create circuits so cleanly in Haskell, it can't be harder to create program data for GPUs.
The Cell architecture is very nice for vectorizable problems as well.
我认为，大盘需要的是指出，并行不一定甚至一般左右的速度。
它是关于如何表达算法或程序中的活动顺序是局部有序。
