令人尴尬的并行执行，没有加速（MEEP，openMPI）答案

【问题标题】：Embarrasingly parallel execution, no speedup (MEEP, openMPI)令人尴尬的并行执行，没有加速（MEEP，openMPI）
【发布时间】：2017-02-22 14:59:27
【问题描述】：

我一直在尝试利用并行化来使用 MEEP 模拟软件更快地运行一些模拟。默认情况下，该软件仅使用一个 CPU，并且 FDTD 仿真很容易通过并行化加速。最后我发现运行1核或4核没有区别，模拟时间是一样的。

然后我想我会改为在每个内核上运行单独的模拟以增加我的总模拟吞吐量（例如同时运行 4 个不同的模拟）。

令我惊讶的是，每当我开始新的模拟时，已经开始的模拟会变慢，即使它们在不同的内核上运行。例如，如果我只在 1 个内核上运行 1 个模拟，则 FDTD 模拟的每个时间步长大约需要 0.01 秒。如果我在另一个内核上启动另一个进程，每个模拟现在每个时间步花费 0.02 秒，依此类推，这意味着即使我在不同的内核上运行彼此无关的不同模拟，它们都会减慢速度，让我没有速度净增加。

我不一定要寻求帮助来解决这个问题，就像我寻求帮助来理解它一样，因为它激发了我的好奇心。每个模拟实例需要的内存不到我总内存的 1%，所以这不是内存问题。我唯一能想到的就是共享缓存内存的内核，或者内存带宽饱和，有没有办法检查是否是这种情况？

模拟相当简单，我运行的程序比这个更需要内存，并且在并行化方面有很大的加速。

有什么提示可以帮助我理解这种现象吗？

【问题讨论】：

您应该使用适当的工具来读取可以将共享资源指示为瓶颈的硬件性能计数器。有很多parallel tools。但如果你只是单独运行应用程序，你可以使用像perf 这样简单的东西。
您的分析是一个好的开始，但还有其他可能的问题：降低涡轮频率、超线程/AMD 推土机“模块”，但如果没有更具体的系统和应用程序信息，则无法判断
数据长度是多少？ 100 MB？尝试使所有内核仅在 1MB 部分上工作，然后在完成后继续在另一部分上工作。这样，当一个核心访问一个单元时，另一个核心可以将其作为另一个单元的邻居来访问。
您可以使用perf Linux 事件分析器快速检查那里可能发生的情况。你知道模拟是否依赖文件访问？如果多个进程竞争独占文件访问，它也可能在进程间级别产生序列化。

标签： parallel-processing mpi meep

【解决方案1】：

我认为应该更好地查看更大的模拟，因为众所周知的涡轮增压技术问题（单核性能随线程数而变化）无法解释您的结果。它会解释是否有一个单核处理器。

所以，我认为这可以用内存缓存级别来解释。也许如果您尝试比 L3 缓存大得多的模拟（i7 为 > 8MB）。

【讨论】：

【解决方案2】：

我在 Intel(R) Core(TM) i7-3517U CPU @ 1.90GHz 双核（4 线程）上进行的测试。 1 mpi 线程的所有模拟 (-np 1)

10mb 模拟：

四次模拟 0.0255 s/step
两次模拟 0.0145 s/步
一次模拟 0.0129 秒/步

100mb 模拟：
四次模拟 1.13 s/步
两次模拟 0.61 s/步
一次模拟 0.53 秒/步

奇怪的是，两个具有 2 个线程的模拟的运行速度几乎与两个具有 1 个线程的模拟的运行速度相同。

【讨论】：