Performance 具有普通可并行DO循环的MPI加速比（F90）

我有一个简单的DO循环（Fortran 90），其中各个迭代相互独立，只从硬盘驱动器输入/输出数据（进程之间不交换消息/MPI），我使用MPI并行化了该循环。 在顺序运行中，循环的一次迭代大约需要一天才能完成。如果我并行运行29个这样的迭代，大约需要2.5天。它位于超级计算机的一个节点上（即没有节点间通信）

我听人说过，对于可并行化的程序（循环中的独立步骤），总执行时间应该接近循环中仅运行一个步骤时的执行时间

问题：你觉得这种加速效果好吗

---

非常感谢。

因为您有独立的迭代，所以您在29个核心上进行29次迭代的运行时间不应该是在单个核心上进行单个迭代的运行时间。除非以下一个或多个条件适用，否则您应该接近一天：

• 计算节点上的内存不足，无法容纳所有进程及其数据
• 迭代之间的计算不平衡
• 有大量的磁盘输入/输出导致磁盘访问竞争
• 可能还有其他一些我没有想到的

---

那么，当您将代码的并行副本扩展到29个时，您的运行速度仅为希望的一半

内存带宽可能是一个问题，同一算法的29个副本同时读取/写入自己的内存。这就是为什么在这种情况下，在单个迭代中寻找并行性可能会更好（但更难）

让我们使用视频编码作为“一次迭代”的具体示例。例如，并行编码29个视频就像OP的建议。让x264使用32个内核对一个视频进行编码，然后在接下来的28个视频中重复编码，使用更少的总RAM，缓存更好

实际上，可能2或3个VID并行，每个VID使用10到16个线程，这将是好的，因为x264可以找到的并行度是有限的

这取决于算法，以及它在多线程中的扩展程度。如果根本没有，或者您没有时间编写代码，那么就一直使用暴力。一个超过10倍的加速系数基本上是不需要努力的。（例如，使用

make-j29

or在不同的数据集上运行单线程程序，或者在您的情况下，在一个程序中使用多线程。）

---

当代码运行时，您可以检查CPU利用率，以确保保持29个CPU内核像您尝试的那样忙碌。您还可以使用分析工具（如Linux

perf

）来调查缓存效果。如果并行运行的数据缓存未命中率是单线程运行的29倍以上，这就可以解释问题了。

计算节点上有多少内核？开始跑步时需要多少处理器？代码顺序部分的运行时间是多少？顺序部分的运行时间可以忽略不计，它只是一些简单的后处理。每个HPC节点有32个内核。我已经在29个内核上测试了29次迭代的循环，所以每个内核都有一次迭代。这种加速在我看来并不合适。您有多少I/O？如果进程不参与消息传递，为什么要使用MPI？我可以为初学者想出101种使用MPI使程序变慢的方法，但我不明白你为什么要使用MPI@博基：内存带宽可能是个问题，同一算法的29个副本同时读取/写入自己的内存。这就是为什么在这种情况下，在一次迭代中寻找并行性可能会更好（但更难）的原因。我把这变成了一个答案。谢谢你的回答。在这种情况下，29次迭代在节点上使用的256GB内存不足90GB。因此，有足够的内存。29个单独的进程执行相同的任务（出于测试目的），因此负载是平衡的。我对各个进程进行了计时，此外，我将对每个进程中的I/O进行计时，与数学部分分开。我会报告的。谢谢你的回复。在我的例子中，单个迭代是求解一个巨大矩阵的特征值/特征向量，然后将其中的一些写入HD上的文件。对于eigensolver，我使用了我无法并行化的经过良好开发和调优（屏蔽）的函数。@Boki:好的，所以可能是内存带宽/缓存大小限制。或者，如果您使用的内存太多，导致系统内存不足，并且必须分页到磁盘，那么您可以通过并行运行更少的内存来获得加速。除非您能找到一个很好的并行库来解决这个问题，否则只需暂停一天，然后计算您的10倍加速。或者，如果您可以安排您的程序将其工作扩展到多个计算节点，这应该会有所帮助。（只要集群中有空闲的节点，或者运行的某些其他作业不是内存密集型的。）但无论如何，即使MPI没有“做错任何事情”，也不能保证线性加速，因为内存/缓存是共享资源，所以你可以不用担心，继续你的研究：）@PeterCordes，很好你想到了内存带宽。这可能就是问题所在。我重复了模拟，但现在对代码中的每个核心任务和单个任务进行计时。HD i/o对整个延迟的贡献微乎其微。所有的延迟都在数学中（创建gignantic矩阵，然后找到特征向量/特征向量）。30个内核的延迟分布相对均匀。所以，很可能是RAM访问速度，正如你所指出的，Peter。谢谢你的建议。