我为有限体积求解器编写了一个C ++代码，用于模拟非结构化网格上的2D可压缩流，并使用MPI（openMPI 1.8.1）并行化我的代码。我使用gmsh-Metis将初始网格划分为N个部分（等于正在使用的处理器数量）。在求解器中，有一个函数可以计算各个分区中每个局部面的数值通量。此函数将左/右值和重建状态（在函数调用之前计算）作为输入，并返回相应的通量。在此函数调用期间，没有处理器间通信，因为所有输入数据都在本地可用。我使用MPI_Wtime来查找每个这样的函数调用所花费的时间。有6个处理器（英特尔®酷睿™i7（3770）），我得到以下结果：

处理器1： 140656732分钟内拨打140657932

处理器2： 1478383662在18.5758分钟内拨打电话

处理器3： 1422943146在65.3507分钟内拨打电话

处理器4： 1439105772在40.379分钟内拨打电话

处理器5： 1451746932在23.9294分钟内调用

处理器6： 1467187206在32.5326分钟内拨打电话

我对时间感到非常惊讶，尤其是来自处理器1和2的时序。处理器2比处理器1多出近8000万次调用但占用处理器1所用时间的1/7。我重新认为没有处理器1在此功能中发生处理器间通信。以下会导致这么大的时间变化吗？

函数内的条件if循环
输入变量值的大小。例如，如果处理器的大多数值接近于0。

如果不是这些，这种差异背后是否还有其他原因？

通常，您所描述的现象称为 负载不平衡 。根据问题，数值方法，并行化方案，输入数据，操作系统/运行时/应用程序配置甚至硬件，这种不平衡有许多潜在的来源！

硬件

您声明的处理器支持Intel TurboBoost，Intel RAPL以及动态电压和频率调整。任何这些都可能导致在某些内核上运行的线程/进程最终比其他内核更快地完成。为了清楚起见，在尝试解决这些问题时，我建议您配置系统以禁用这些功能，以及BIOS可能提供的任何空闲/睡眠状态省电选项。然后重新运行您的基准。

配置

您希望将并行执行的程度和分配与可用于在系统上运行程序的实际资源相匹配。这意味着一些事情

关闭同时运行的严重干扰进程
过程计数的最佳选择可能是硬件核心数量，硬件线程数量，或者少于每个允许操作系统安排其他过程而不会干扰的硬件线程数量
确保每个进程与不同处理器核心/线程之间的调度关联。这可以确保操作系统调度程序不会持久地尝试将您的进程移动到没有任何好处，并且当它们应该独立运行时，它们最终不会争用相同的执行单元。

特定应用程序问题

您是否在整个流程中对网格划分相对均匀？他们是否有相似数量的元素，以及相似的边界和内部份额？边界条件通常与内部元素具有非常不同的计算成本。您可能需要告诉分区器每个元素的权重不等，这样它就可以尝试生成大约均匀的分区而不是元素数。
您的问题域的某些部分的计算成本是否高于其他部分？您的问题提到了相关函数中的if语句。评估条件本身可能会导致变化，如果某些进程得到一个集合全部采用单向，而另一个进程混合，由于分支错误预测。更严重的是，如果这两个分支代表了大量不同的工作量。如果某些流程比其他流程更多地占用一个分支，则它们的工作负载会相应地不同。
此功能是否使用每个网格元素的任何迭代/收敛数值方法，其中不同的元素可能需要不同的迭代次数才能达到解决方案。不同的流程可能会有不同的元素计算成本分布。

MPI并行运行期间的变化时间

1 个答案:

硬件

配置

特定应用程序问题