我正在一个松散耦合的集群上进行某些数据处理。网络代码和处理代码已经到位，但是我们正在评估我们方法中的不同方法。目前，正如我们应该做的那样，我们在性能问题上受I / O约束，并且我们正努力减少这一瓶颈。显然，像Infiniband这样的更快的交换机将是很棒的，但是我们付不起仅仅扔掉已有的设备并购买新设备的奢侈。

我的问题是这样的。在群集上完成的所有传统且严格的HPC应用程序通常都是通过消息传递而不是直接通过套接字发送来实现的。这对性能有什么好处？如果从套接字切换，是否应该看到提速？

解决方案

MPI在下面使用套接字，因此实际上唯一的区别应该是代码与之接口的API。如果直接使用套接字，则可以微调协议，仅此而已。我们究竟在处理数据？

MPI使用套接字，并且如果我们知道自己在做什么，则可能会从套接字获得更多的带宽，因为我们不需要发送太多的元数据。

但是我们必须知道自己在做什么，而且很容易出错。本质上，我们将用自己的消息传递协议替换mpi。

我建议我们使用MPI而不是自己动手，除非我们非常擅长这种事情。使用我自己的协议编写了​​一些分布式计算式应用程序后，我总是发现自己正在重现(并且很难重现)MPI中的功能。

在性能方面，我不希望MPI像我们一样使用套接字来提供任何明显的网络加速。但是，MPI将为我们提供许多节点管理所需的功能，即节点之间的同步。

对于高容量，低开销的业务消息传递，我们可能需要签出

OAMQ有几种产品。开源变体OpenAMQ应该在JP Morgan进行交易，所以应该可靠，不是吗？

MPI可能使用插座。但是，也可以将MPI实现与使用直接分布式共享内存的SAN(系统区域网络)一起使用。如果我们拥有相应的硬件，那当然可以。因此，MPI允许我们将来使用此类资源。在这种情况下，我们可以获得巨大的性能提升(根据我上大学时对集群的经验，可以达到几个数量级的提升)。因此，如果我们要编写可移植到高端集群的代码，那么使用MPI是一个很好的主意。

即使丢弃性能问题，使用MPI也可以节省大量时间，我们可以将其用于提高系统其他部分的性能，或者只是节省理智。

我没有使用MPI，但是我已经使用了很多套接字。高性能套接字上需要考虑一些事项。我们是在做很多小数据包还是大数据包？如果我们正在处理许多小数据包，请考虑关闭Nagle算法以获得更快的响应：

setsockopt(m_socket，IPPROTO_TCP，TCP_NODELAY ...);

同样，在尝试通过大量数据传输时，使用信号实际上可能会慢很多。很久以前，我编写了一个测试程序，其中读取器将等待信号，并读取一个数据包，它将获得约100个数据包/秒的回响。然后我只是阻止了读取，并获得了10000次读取/秒。

关键是要查看所有这些选项，并进行实际测试。不同的条件将使不同的技术更快/更慢。重要的是，不仅要获取意见，还要对它们进行检验。史蒂夫·马奎尔(Steve Maguire)在"编写可靠代码"中对此进行了讨论。他使用了许多违反直觉的示例，并对其进行了测试，以找出使代码更好/更快的原因。

我必须同意OldMan和freespace。除非我们知道对MPI的特定有用度量(性能，可维护性等)的特定和改进，否则为何要重新发明轮子。 MPI代表了大量有关我们要解决的问题的共享知识。

我们不仅需要发送数据，还需要解决很多问题。连接的建立和维护将全部由我们负责。如果MPI是我们需要的确切抽象(听起来像是)，请使用它。

至少，使用MPI并在以后使用我们自己的系统对其进行重构是一种很好的方法，它会花费MPI的安装和依赖性。

我特别喜欢OldMan的观点，即MPI为我们提供的不仅仅是简单的套接字通信。我们将获得大量具有透明抽象的并行和分布式计算实现。

消息传递不是一种技术，而是一种范式。在最常规的安装中，MPI将使用套接字进行通信。切换到MPI可能会加快速度，但仅限于尚未优化套接字通信的情况。

应用程序I / O如何绑定？是在将数据块传输到工作节点时绑定的，还是由于计算过程中的通信而绑定的？

如果答案是"由于通信"，那么问题是我们正在编写一个紧密耦合的应用程序，并试图在为松散耦合的任务而设计的集群上运行它。获得性能的唯一方法是获得更好的硬件(更快的开关，infiniband等)……也许我们可以借用别人的HPC时间？

如果答案是"数据块"传输，则考虑为工作人员分配多个数据块(这样他们就可以保持更长时间的忙碌)并在传输之前压缩这些数据块。这是一种可以在松散耦合的应用程序中提供帮助的策略。

在这种情况下，性能并不是唯一的考虑因素，即使在高性能群集上也是如此。 MPI提供了一个标准的API，并且是"便携式的"。在不同版本的MPI之间切换应用程序比较简单。

大多数MPI实现使用套接字进行基于TCP的通信。与直接使用套接字的本地应用程序相比，任何给定的MPI实现都将得到更好的优化并提供更快的消息传递的可能性是件好事。

此外，如果我们有机会在具有InfiniBand的群集上运行代码，则MPI层将抽象出所有这些代码更改。这不是编码应用程序以直接使用OFED(或者另一个IB动词)实现的重要优势，这非常困难。

大多数MPI应用程序都包括小型测试应用程序，可用于独立于应用程序来验证网络设置的正确性。这是调试应用程序的主要优势。 MPI标准包括用于分析MPI调用的" pMPI"接口。该接口还使我们可以轻松地向所有消息传递例程添加校验和或者其他数据验证。

段落数量不匹配