我有一个用 F# 编写的科学程序，我想在一台具有多个处理器 (64) 的服务器上并行化并运行它，并且将来还要在云中运行（Windows Azure？）。该程序将在节点之间进行简单的 1-1 通信（无广播等）。
如果我使用 WCF，它会和 MPI 一样快吗？ WCF 没有的 MPI 有哪些？存在为 WCF 编写的 Pure MPI .NET，这让我更加困惑。我不知道是否使用 WCF 或 MPI.NET 或在 WCF 上运行的 Pure Mpi。
PS：我猜想 TPL 在 64 处理器或更多处理器上是不适用的，对吧？
【问题讨论】：
标签： wcf f# mpi task-parallel-library
您可能还想了解“mbrace”产品，它提供了一个云单子 (http://blogs.msdn.com/b/dsyme/archive/2011/08/23/m-brace-f- in-the-cloud.aspx)。不过，它仍处于相当早期的阶段。我不是专家，但您可能可以在 64 处理器设置上运行基于 mbrace 的解决方案作为有效的私有云。当您超越这一点时，迁移到 Azure 将是无缝的。
【讨论】：
WCF 和 MPI 是不同的概念。 WCF 就像一个人 A 要求一个人 B 做某事，而 MPI 就像一个人 A 创建自己的克隆（所有克隆都具有相同的能力/逻辑），然后这些克隆处理要解决的问题的特定部分，一次他们完成了他们的结果。
因此，选择哪一种适合您的特定应用取决于您的应用试图解决的问题。它甚至可能是 WCF 和 MPI 的组合。您的客户端应用程序要求 WCF 执行某些任务，并且 WCF 使用 MPI 创建“问题解决程序”的克隆，当克隆完成解决问题（并行）时，它们将聚合结果返回给 WCF，然后结果被发送到客户端应用程序。
【讨论】：
如果您在 1 台服务器上执行此操作，您可以只执行一个进程并并行执行代码。这样，您可以比通过 MPI 和 WCF 等消息更轻松、更快速地共享内存。尽管沟通的开销可能不会那么多，这取决于您的问题+解决方案。
此外，您对代码的更改也会少得多，F# 通常可以毫不费力地转换为并行代码。转到 MPI/WCF 将需要您重写大部分内容。
谷歌搜索 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# 的并行功能，它旨在轻松实现并行化。
稍后当您想使用云时，会将其变成客户端服务器。这是一个与并行化不同的问题。我会分别处理和解决它们。
关于 MPI 与 WCF。 WCF 被设计为一种 RPC 技术，即您调用远程过程并获得答案。如果您想将其用于具有单独进程的并行编程，则必须为此创建样板代码。 （跟踪订阅的客户等）
MPI 旨在运行这种架构并更轻松地处理它。 （第一个进程的编号为 0 并且是主进程，其他是从属进程的编号递增等）
但是我不认为 MPI 会很好地进入云，因为它涉及 http、协议、安全等。不确定 MPI 对这些事情的效果如何，WCF 确实可以很好地处理。
有一个用于 WCF 的 MPI.NET 的事实是因为 MPI 是关于许多人都熟悉的某种并行代码风格。因此，您可以使用编程概念并在利用 WCF 进行通信的 .NET 平台上使用它们。
如果您需要通过网络交换大量数据，您可能还想研究一下协议缓冲区（例如，请参阅protobuf-net）。这可以很容易地与 WCF 结合进行通信，并且在序列化结构化数据方面非常精简，因此您可以有效地通过网络发送。
格特-简
【讨论】：
很难给出具体的答案，因为这完全取决于你的应用程序的具体方面、它当前的架构（我想你已经有一些应用程序）等等。
当您提到 MPI 和 WCF 时，我假设应用程序被编写为多个相互通信的组件。构建此类应用程序的最佳方式是使用 F# 代理。 据我了解，您希望首先在单个服务器上运行该应用程序。如果您使用代理编写它，代理可以直接相互通信（因此您不需要 MPI 或 WCF）。
TPL 应该在单服务器（具有大量 CPU）上运行良好，但它不会扩展到分布式设置 - 您不能在另一台机器上运行 Task。但是，您可以在将要分发的单个组件（例如代理）中使用它。
关于 MPI 与 WCF - 我没有足够的经验来回答这个问题。但是，如果您使用基于代理的架构，那么尝试各种选项应该很容易。您还可以查看fracture 和相关项目，这些项目旨在为 F#（以及未来可能的分布式代理）实现高性能套接字。
【讨论】：