multithreading - 4 插槽 NUMA 系统上的矩阵乘法效率低下

Question

我正在开发密集矩阵乘法代码(https://github.com/zboson/gemm)来学习并行编程。我使用 OpenMP 进行线程处理。我的系统有四个插槽，每个插槽都配备 Xeon E5-1620 处理器。每个处理器有 10 个内核/20 个超线程。所以总共是 40 个内核/80 个超线程。当我在一个线程上运行我的代码时，我得到了大约 70% 的峰值触发器(19.2 GFLOPS 中的 13 个)。然而，当我使用 40 个线程运行我的代码时，我只得到了大约 30% 的峰值触发器(682.56 GFLOPS 中的 185 个)。在一个只有一个插槽和 4 个内核的单独系统(Sandy Bridge)上，我可以通过四个线程获得大约 65% 的效率。

我将线程绑定(bind)到每个物理内核 using system calls .我尝试禁用此功能并改用 export OMP_PROC_BIND=true或 export GOMP_CPU_AFFINITY="0 4 8 12 16 20 24 28 32 36 1 5 9 13 17 21 25 29 33 37 2 6 10 14 18 22 26 30 34 38 3 7 11 15 19 23 27 31 35 39"但这些没有什么区别。我仍然可以获得大约 30% 的效率(尽管使用其他不良绑定(bind)设置可能会获得更差的效率)。

我还能做些什么来提高效率？ 我了解 first touch policy被使用，因此内存页面由第一个接触它们的线程分配。当我写出矩阵乘积时，也许我应该为每个套接字制作一个单独的输出，然后最后合并每个套接字的结果？

我正在使用带有 Linux 64 位内核 2.6.32 的 GCC 4.8.0

编辑:我使用以下绑定(bind)矩阵大小 = 2048x2048

export GOMP_CPU_AFFINITY="0 4 8 12 16 20 24 28 32 36 1 5 9 13 17 21 25 29 33 37 2 6 10 14 18 22 26 30 34 38 3 7 11 15 19 23 27 31 35 39"

这应该有线程 0-9 -> 节点 0、10-19 节点 1、20-29 节点 2、30-39 节点 3。

有了这个绑定(bind)，我得到:

 nthread    efficiency    node
 1          77%           0
 2          76%           0
 4          74%           0
 6          62%           0
 8          64%           0
10          52%           0
14          50%           0+1
16          30%           0+1

Answer 1

有理由怀疑效率下降也是因为过多的跨套接字通信。但是设置线程亲和性并不足以避免这些通信，它应该在算法级别上解决，例如以最小化跨numa节点交互的方式划分工作。最好的方法是在 cache-oblivious way 中实现它。 ，例如不是按行或列，而是按二维图 block 平行。

例如，您可以使用 tbb::parallel_for与 blocked_range2d为了更有效地使用缓存。

更高级别的并行性降低的效率也可能表明没有足够的工作来证明同步的开销是合理的。