MPI还是套接字?

MPI可能使用套接字。但也有MPI实现可用于使用直接分布式共享内存的SAN(系统局域网)。当然,如果你有硬件的话。因此,MPI允许您在将来使用这些资源。在这种情况下,您可以获得巨大的性能改进(根据我在大学时使用集群的经验,您可以获得几个数量级的改进)。因此,如果您正在编写可以移植到高端集群的代码,那么使用MPI是一个非常好的主意。

即使放弃性能问题,使用MPI也可以节省大量时间,您可以使用这些时间来提高系统其他部分的性能,或者简单地保存您的理智。

我建议使用MPI而不是自己滚动,除非你非常擅长这类事情。使用我自己的协议编写了一些分布式计算风格的应用程序后,我发现自己总是在复制(而且复制得很糟糕)MPI中的功能。

在这种情况下,性能不是唯一的考虑因素,即使在高性能集群上也是如此。MPI提供了一个标准API,并且是“可移植的”。在不同版本的MPI之间切换应用程序相对简单。

此外,如果您有机会在具有InfiniBand的集群上运行代码,MPI层将抽象任何这些代码更改。这并不是一个微不足道的优势——将应用程序编码为直接使用ED(或其他IB动词)实现是非常困难的。

大多数MPI应用程序包括小型测试应用程序,可用于独立于应用程序验证网络设置的正确性。这是调试应用程序时的一个主要优势。MPI标准包括用于分析MPI调用的“pMPI”接口。此接口还允许您轻松地向所有消息传递例程添加校验和或其他数据验证。

消息传递是一种范例,而不是一种技术。在最一般的安装中,MPI将使用套接字进行通信。通过切换到MPI,您可以看到速度有所提高,但前提是您尚未优化套接字通信。

如果答案是“数据块”传输,那么考虑分配工人多个数据块(这样他们就忙得更长)。在传输之前压缩数据块。这是一种有助于松散耦合应用程序的策略。

MPI的好处是您可以进行集体通信。广播/减少O(log p)/*p是处理器的数量*/而不是O(p)是一个很大的优势。

我必须同意OldMan和freespace的观点。除非您知道MPI对某些有用指标(性能、可维护性等)的具体改进,否则为什么要重新发明轮子呢。MPI代表关于您试图解决的问题的大量共享知识。

除了发送数据,您还需要解决大量问题。连接设置和维护将由您负责。如果MPI是您所需要的确切抽象(听起来像是),请使用它。

至少,使用MPI并在以后使用您自己的系统进行重构是一种很好的方法,它可以降低MPI的安装成本和依赖性。

我没有使用MPI,但我使用了很多套接字。在高性能套接字上有一些需要考虑的事情。你是在做很多小包,还是大包?如果你正在做许多小数据包考虑关闭Nagle算法更快的响应:

此外,当试图通过网络获取大量数据时,使用信号的速度实际上要慢得多。很久以前,我做了一个测试程序,在这个程序中,阅读器会等待一个信号,然后读取一个数据包——它将得到大约100个数据包/秒。然后我只进行了阻塞读取,每秒读取10000次。

MPI在下面使用套接字,所以实际上唯一的区别应该是代码与之接口的API。如果直接使用套接字,可以对协议进行微调,但仅此而已。你到底在用这些数据做什么?

但是你必须知道你在做什么,而且很可能更容易出错。基本上,您将用自己的消息传递协议替换mpi。

商业 OAMQ 有几种产品。开源变体 OpenAMQ