gcc - OpenMP GCC GOMP 浪费屏障

Question

我有以下程序。
nv 大约是 100，dgemm 大约是 20x100，所以还有很多工作要做:

#pragma omp parallel for schedule(dynamic,1)
        for (int c = 0; c < int(nv); ++c) {
            omp::thread thread;                                               
            matrix &t3_c = vv_.at(omp::num_threads()+thread);
            if (terms.first) {
                blas::gemm(1, t2_, vvvo_, 1, t3_c);
                blas::gemm(1, vvvo_, t2_, 1, t3_c);
            }

            matrix &t3_b = vv_[thread];
            if (terms.second) {
                matrix &t2_ci = vo_[thread];
                blas::gemm(-1, t2_ci, Vjk_, 1, t3_c);
                blas::gemm(-1, t2_ci, Vkj_, 0, t3_b);
            }
        }

但是对于 GCC 4.4、GOMP v1、 gomp_barrier_wait_end占运行时间的近 50%。更改 GOMP_SPINCOUNT减轻了开销，但只使用了 60% 的内核。 OMP_WAIT_POLICY=passive 相同.系统是Linux，8核。

如何在不旋转/等待重载的情况下获得充分利用

Answer 1

障碍是一种症状，而不是问题。在循环结束时有很多等待的原因是一些线程在其他线程之前完成得很好，并且它们都在 for 循环结束时等待了很长一段时间，直到每个人都完成了。

这是一个典型的负载不平衡问题，在这里很奇怪，因为它只是一堆矩阵乘法。它们的大小不同吗？就 NUMA 而言，它们是如何在内存中布局的——它们当前是否都位于一个内核的缓存中，还是存在其他共享问题？或者，更简单地说——是不是只有 9 个矩阵，所以剩下的 8 个就注定要等待谁得到最后一个？

当这种事情发生在更大的并行代码块中时，有时可以在某些循环迭代尚未完成时继续执行下一个代码块；在那里你可以添加nowait for which 的指令将覆盖默认行为并摆脱隐含的障碍。但是，在这里，由于并行 block 正好是 for 循环的大小，所以这并没有什么帮助。