c++ - g++ 4.7 中的 OpenMP(并行)不是很有效吗？ 2.5 倍于 5 倍 CPU

Question

我已经尝试将 OpenMP 与单个 #pragma omp parallel for 结合使用，这导致我的程序运行时间从 35 秒(99.6% CPU) 变为14 秒(500% CPU)，在 Intel(R) Xeon(R) CPU E3-1240 v3 @ 3.40GHz 上运行.这就是使用 g++ -O3 和 g++ -O3 -fopenmp 编译之间的区别，两者都使用 gcc (Debian 4.7.2-5) 4.7.2 在 Debian 7 上(喘不过气来)。

• 既然 CPU 是 4 核/8 线程，为什么最多只使用 500% 的 CPU，而理论上的最大值应该是 800%？它不应该至少达到 700s 的低点吗？

• 为什么我的总时间只提高了 2.5 倍，而 CPU 使用却增加了 5 倍？缓存抖动？

整个程序基于 C++ string 操作，递归处理(使用大量 .substr(1) 和一些连接)，其中所述字符串是连续的插入到 set 的 vector 中。

换句话说，基本上，在对 vector 进行操作的单个并行 for 循环中完成了大约 2k 次循环迭代，并且它们中的每一个都可能对自身进行两次递归调用 w/some string .substr(1) 和+ char 连接，然后递归终止于set .insert 单个字符串或两个字符串的串联，并且所述 set .insert 还处理大量可能的重复项。

一切都在规范范围内正确且良好地运行，但我正在尝试查看它是否可以运行得更快。 :-)

Answer 1

根据您的描述，您可以得出以下结论:

^{我假设 OpenMP 确实使用了 8 个线程(通过 export OMP_NUM_THREADS=8 验证)}

1. 500% CPU 意味着在障碍上花费了大量时间。这是由于负载平衡不好:不同的迭代花费不同的时间。因此默认(静态)循环调度效率低下，尝试不同的 kinds of loop scheduling ，例如动态。

2. 如果运行时时间与线程数不成比例地减少(例如，总 CPU 时间增加)，则可能是共享资源成为瓶颈，或者线程之间存在影响。请注意，这也可能是短屏障(来自负载不平衡)的结果，它执行忙等待而不是阻塞。

   • 最常见的共享资源是内存带宽。这是否会影响您，取决于您的工作集是否适合本地缓存。考虑到现代系统中的许多内存层次结构和 NUMA 属性，这可能变得非常难以理解。如果不重组数据访问以更有效地使用缓存(阻塞)，您无能为力。

   • 错误共享:如果多个线程写入和读取相同的内存位置(缓存行)，则相应的内存访问会变得更慢。尝试将并行循环内的写入限制为私有(private)变量。

   • 超线程 - 核心是两个硬件线程之间的共享资源。

     using 5x resources

     这是一个根本性的误解。额外的硬件线程为每个内核提供的额外资源很少。如果两个线程运行在同一个内核上，它们将共享计算资源和内存带宽，基本上唯一的优势就是隐藏的 I/O 延迟。尽管 2 倍的 CPU 时间，您永远不会看到 2 倍的加速。有时它会给你 10% 的加速，有时它会更慢。

     现在考虑在 4 个内核上运行 5 个事件线程。 2 个线程，共享一个核心，只会以大约 50% 的速度运行，这会减慢一切。尝试将线程数减少到内核数(export OMP_NUM_THREADS=4)。