MPI与Microsoft WCF对比Microsoft TPL

Question

我有一个用F＃编写的科学程序，我希望在一台服务器上并行运行多个处理器（64），以及将来也在云端运行（Windows Azure？）。该程序将在节点之间进行简单的1-1通信（无广播等）。

如果我使用WCF，它会和MPI一样快吗？ WCF没有的MPI是什么？存在为WCF编写的Pure MPI .NET，这让我更加困惑。我不知道是否要在WCF上运行WCF或MPI.NET或Pure Mpi。

PS：我猜TPL在64位以上的游戏中已经超出游戏规则，对吧？

Answer 1

很难给出具体的答案，因为这完全取决于应用程序的特定方面，当前的架构（我想你已经有了一些应用程序）等。

• 当你提到MPI和WCF时，我假设应用程序被编写为几个相互通信的组件。构建此类应用程序的最佳方法是使用 F＃代理。 据我所知，您希望首先在单个服务器上运行该应用程序。如果使用代理编写代理，代理可以直接相互通信（因此您不需要MPI或WCF）。

• TPL 应该在单个服务器（具有大量CPU）上运行良好，但不能扩展到分布式设置 - 您无法在另一台计算机上运行Task 。但是，您可以在将要分发的单个组件（例如代理）中使用它。

关于MPI与WCF - 我没有足够的经验来回答这个问题。但是，如果您使用基于代理的体系结构，则应该很容易尝试各种选项。您还可以查看fracture和相关项目，这些项目旨在为F＃（以及将来可能的分布式代理）实现高性能套接字。

Answer 2

如果您在1台服务器上执行此操作，则只需执行一个进程并并行执行代码即可。这样，您可以比通过MPI和WCF等消息更轻松，更快地共享内存。虽然通信的开销可能不是那么多，取决于您的问题+解决方案。

此外，对代码的更改也会少得多，F＃通常可以很轻松地转换为并行代码。转到MPI / WCF会要求您重写大部分内容。

Google搜索F＃+ parallel提供了大量有用的信息，您应该首先阅读，这样才能获得良好的开端： http://blogs.msdn.com/b/dsyme/archive/2010/01/09/async-and-parallel-design-patterns-in-f-parallelizing-cpu-and-i-o-computations.aspx

所以在1台服务器上，我会使用F＃的并行功能，它的设计很容易并行化。

稍后当你想要使用云时，那将把它变成cleint-server。那是一个与平行化不同的问题。我会分开对待和解决它们。

关于MPI与WCF。 WCF被设计为RPC技术，即您调用远程过程并获得答案。如果要将其用于使用单独进程的并行编程，则必须为其创建样板代码。 （跟踪受影响的客户等）。

MPI旨在运行这种架构并更容易处理它。 （第一个进程得到数字0并且是主数据库，另一个进程是奴隶数逐步编号等。）

我怎么认为MPI不会很好地去云，因为它会调用http，协议，安全性等等。不确定MPI对这类事情的效果如何，WCF确实可以很好地处理它。

WCF有一个MPI.NET的事实是因为MPI是一种很多人都熟悉的某种平行代码风格。因此，您可以使用编程概念并在.NET平台上使用它们，利用WCF进行通信。

如果需要通过线路交换大量数据，可能需要查看的其他内容是协议缓冲区（例如，请参阅protobuf-net）。这可以很容易地与WCF结合进行通信，并且非常依赖于序列化结构化数据，因此您可以有效地通过网络发送。

格特 - 扬

Answer 3

WCF和MPI是不同的概念。 WCF就像一个人A要求B做某事，因为MPI就像一个人A创建自己的克隆（所有克隆具有相同的能力/逻辑）然后这些克隆工作在要解决的问题的特定部分上他们完成了他们的结果。

因此，选择哪一个适合您的特定应用程序取决于您的应用程序试图解决的问题。它甚至可能是WCF和MPI的组合。您的客户端应用程序要求WCF执行某项任务，并且WCF使用MPI创建“问题解决器”的克隆，并且当克隆完成解决问题（并行）时，它们将聚合结果返回给WCF，然后结果发送到客户端应用程序。

Answer 4

您可能还想采用提供云monad的'mbrace'产品（http://blogs.msdn.com/b/dsyme/archive/2011/08/23/m-brace-f-在最cloud.aspx）。尽管如此，它还处于相当早的阶段。我不是专家，但可能是您可以在64处理器设置上有效地运行基于mbrace的解决方案作为私有云。当你长大之后，转向Azure将是无缝的。