9

我正在为一些数据处理开发一个松散耦合的集群。网络代码和处理代码已经到位,但我们正在评估我们方法中的不同方法。现在,正如我们应该做的那样,我们在性能问题上受到 I/O 的限制,我们正在努力减少这个瓶颈。显然,像 Infiniband 这样更快的交换机会很棒,但我们不能承担仅仅扔掉我们拥有的东西并获得新设备的奢侈。

我提出的问题是这样的。在集群上完成的所有传统和严肃的 HPC 应用程序通常都是通过消息传递而不是直接通过套接字发送来实现的。这有什么性能优势?如果我们从套接字切换,我们应该看到加速吗?

4

10 回答 10

20

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

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

于 2008-09-30T16:18:58.330 回答
12

我建议使用 MPI 而不是自己滚动,除非你非常擅长那种事情。在使用我自己的协议编写了​​一些分布式计算类应用程序之后,我总是发现自己正在重现(并且重现不佳)在 MPI 中发现的特性。

性能方面,我不希望 MPI 给你任何切实的网络加速——它和你一样使用套接字。然而,MPI 将为您提供管理许多节点所需的许多功能,即节点之间的同步。

于 2008-09-30T16:02:03.410 回答
4

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

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

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

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

于 2009-04-17T20:14:03.817 回答
3

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

您的应用程序 I/O 是如何绑定的?是在将数据块传输到工作节点时绑定,还是因为计算过程中的通信而绑定?

如果答案是“因为通信”,那么问题是您正在编写一个紧密耦合的应用程序并试图在为松散耦合任务设计的集群上运行它。获得性能的唯一方法是获得更好的硬件(更快的交换机、infiniband 等)……也许您可以借用其他人的 HPC 的时间?

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

于 2008-09-30T17:46:43.610 回答
3

MPI 的好处是您可以进行集体通信。在 O(log p) /* p is your number of processor*/ 而不是 O(p) 中进行广播/减少是一个很大的优势。

于 2009-05-19T16:29:03.803 回答
2

我必须同意 OldMan 和自由空间。除非您知道对 MPI 的某些有用指标(性能、可维护性等)的特定和改进,否则为什么要重新发明轮子。MPI 代表了有关您尝试解决的问题的大量共享知识。

您需要解决大量问题,而不仅仅是发送数据。连接设置和维护都将成为您的责任。如果 MPI 是您需要的确切抽象(听起来确实如此),请使用它。

至少,使用 MPI 并随后用您自己的系统对其进行重构是一种减少 MPI 安装和依赖性的好方法。

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

于 2008-09-30T17:40:19.367 回答
1

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

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

此外,在尝试获取大量数据时,使用信号实际上会慢得多。很久以前我做了一个测试程序,阅读器会等待一个信号,然后读取一个数据包——它会得到大约 100 个数据包/秒。然后我只是做了阻塞读取,并获得了 10000 次读取/秒。

重点是查看所有这些选项,并实际测试它们。不同的条件将使不同的技术更快/更慢。重要的是不仅要获得意见,还要对它们进行测试。Steve Maguire 在“Writing Solid Code”中谈到了这一点。他使用了许多违反直觉的示例,并对其进行测试以找出使代码更好/更快的原因。

于 2008-09-30T16:29:18.057 回答
0

MPI 在下面使用套接字,因此真正唯一的区别应该是您的代码与之交互的 API。如果您直接使用套接字,您可以微调协议,但仅此而已。你到底在用这些数据做什么?

于 2008-09-30T15:52:55.973 回答
0

MPI 使用套接字,如果您知道自己在做什么,您可能可以从套接字中获得更多带宽,因为您不需要发送尽可能多的元数据。

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

于 2008-09-30T16:01:23.693 回答
0

对于大容量、低开销的业务消息传递,您可能需要查看 带有多个产品的OAMQ 。开源变体OpenAMQ应该在 JP Morgan 进行交易,所以它应该是可靠的,不是吗?

于 2008-09-30T16:09:57.040 回答