OpenMP：“隐式屏障”中有 20% 的时间？

Posted 2023-03-06

【中文标题】OpenMP：“隐式屏障”中有 20% 的时间？

【英文标题】：OpenMP: 20% time in "implicit barrier"?

【发布时间】：2012-12-27 14:51:22

【问题描述】：

我正在研究一些使用 OpenMP 的代码，尽管我对它不太熟悉。 （代码也不是 OpenMP。）

当针对它运行分析器时，我发现该程序在“OMP 隐式屏障”函数中花费了大约 20% 的挂钟时间。

这是 OpenMP 的典型特征，还是（可能）意味着工作负载在线程之间分布不均？

谢谢

【问题讨论】：

这完全取决于应用程序在障碍之间的作用。即，如果它做的很少那么确定，它将把所有时间都花在 MP 上。

这很不寻常，正如您所建议的那样，这是负载不平衡的症状。如果您能找到特定的隐含障碍，我们可能会提供更多建议——例如，如果它位于 omp for 工作共享结构的末尾，您可以尝试使用 schedule(dynamic) 看看是否有帮助。

【参考方案1】：

在大多数 OpenMP 结构的末尾都有隐式障碍，例如 for（在 C/C++ 中）或 do（在 Fortran 中）、sections 和 single（但是，在末尾没有障碍master 构造）。 nowait 子句可用于禁用这些隐式屏障，如果算法允许不同的线程在工作共享指令之后不同步运行。另一个隐式屏障位于每个并行区域的末尾，作为 fork/join 执行模型的一部分。

您猜对了，隐式障碍等待时间的高百分比通常意味着工作共享远非最佳。可能存在（大量）大型 single 构造，也可能存在并行循环（for/do 构造），每次迭代的执行时间不同。如果不平衡来自每次迭代中计算时间不同的循环（典型示例是绘制 Mandelbrot 集），则可以使用schedule(dynamic,chunk) 子句将循环调度更改为dynamic，其中chunk 是块大小（ >= 1)。块大小越小，负载平衡越好，但动态循环调度程序的开销会更高。块大小越大，开销越低，但会出现更多的负载不平衡。最佳值通常取决于问题的类型和硬件，因此必须调整该值才能在执行代码的特定系统上获得最佳性能。