为什么MPI被认为比共享内存更难,而Erlang在消息传递时更容易被认为更容易？

如今,Erlang作为一种在多核上编写并行程序的语言,现在引起了很多人的兴趣.我听说有人认为Erlang的消息传递模型比主流共享内存模型(如线程)更容易编程.

相反,在高性能计算社区中,主要的并行编程模型是MPI,它也实现了消息传递模型.但是在HPC领域,这种消息传递模型通常被认为很难编程,人们认为OpenMP或UPC等共享内存模型更容易编程.

有谁知道为什么在IT和HPC世界中对消息传递与共享内存的看法存在这样的差异？是否由于Erlang和MPI如何实现消息传递的一些根本区别,使得Erlang风格的消息传递比MPI更容易？还是有其他原因吗？

我同意之前的所有答案,但我认为一个未明确的关键点是,MPI可能被认为很难并且Erlang容易的一个原因是模型与域的匹配.

Erlang基于本地内存,异步消息传递和共享状态的概念,通过使用所有线程可以获得的某种形式的全局数据库来解决.它专为不会移动大量数据的应用程序而设计,并且不应该爆炸到需要协调的100k个单独节点.

MPI基于本地内存和消息传递,旨在解决移动数据是域的关键部分的问题.高性能计算非常关注数据集的问题,并将其分解为大量计算资源.这在消息传递系统中非常困难,因为数据必须在记住平衡的情况下明确分发.从本质上讲,MPI可以被视为一种勉强的准入,共享内存不会扩展.它的目标是跨越100k或更多处理器的高性能计算.

Erlang并没有尝试实现最高性能,而是将自然并行的问题分解为自然线程.与MPI相比,它的设计考虑了完全不同类型的编程任务.

因此,与pthreads和其他相当本地的异构线程解决方案相比,Erlang是最好的,而不是MPI,它实际上是针对一个非常不同(在某种程度上固有的更难)的问题集.

Erlang中的并行性仍然很难实现.我的意思是你仍然需要弄清楚如何分解你的问题,但是与C或C++中的一些MPI库相比,有一些小问题可以缓解这个难题.

首先,由于Erlang的消息传递是一流的语言特性,因此语法糖使其变得更容易.

此外,Erlang库都是围绕Erlang的消息传递构建的.这种支撑结构有助于提升并行处理的土地.看一下OTP的组件,比如gen_server,gen_fsm,gen_event.这些是非常易于使用的结构,可以帮助您的程序变得平行.

我认为可用标准库的稳健性更多地区分了erlang从其他MPI实现传递的消息,而不是语言本身的任何特定功能.

通常,HPC中的并发意味着处理大量数据.这种并行性称为数据并行性,并且使用像OpenMP这样的共享内存方法确实更容易实现,因为操作系统会处理诸如调度和任务放置之类的事情,如果使用消息传递范例,则必须自己实现这一点. .

相比之下,Erlang旨在应对电话系统中遇到的任务并行性,其中不同的代码片段必须同时执行,只有有限的通信量和对容错和恢复的强烈要求.

这个模型类似于大多数人使用PThreads的模型.它适用于Web服务器等应用程序,其中每个请求都可以由不同的线程处理,而HPC应用程序对大量数据执行大致相同的操作,这些数据也必须在工作者之间进行交换.

我认为当你使用MPI进行编程时以及使用Erlang进行编程时,它与思维方式有关.例如,MPI没有内置到语言中,而Erlang内置了对消息传递的支持.另一个可能的原因是仅发送/接收消息和将解决方案划分为并发执行单元之间的断开.

使用Erlang,您不得不在函数式编程框架中思考数据实际上从函数调用到函数调用 - 并且接收是一种看起来像语言中的正常构造的活动行为.这使您可以在实际执行的计算与发送/接收消息的行为之间建立更紧密的联系.

另一方面,使用MPI,您不得不仅考虑实际的消息传递,而不是真正的工作分解.这种思考框架需要在代码中编写解决方案和消息传递基础结构之间进行某种上下文切换.

讨论可以继续进行,但常见的观点是,如果消息传递的构造实际上构建在您正在使用的编程语言和范例中,那么通常这是表达解决方案的更好方法,而不是"其他方面". "或作为语言的附加物存在(以图书馆或扩展名的形式存在).