c – OpenMP：不要使用超线程核心(一半`num_threads()`w /超线程)

2023年5月2日 345次阅读

在
Is OpenMP (parallel for) in g++ 4.7 not very efficient? 2.5x at 5x CPU,我确定我的程序的性能在11s和13s之间变化(大多数总是在12s以上,有时慢到13.4s),在使用默认的#pragma omp parallel for,并且OpenMP加速时,在500％CPU左右在4核8线程Xeon上,5x CPU w / g -4.7 -O3 -fopenmp仅为2.5倍.

我尝试使用schedule(静态)num_threads(4),并注意到我的程序总是在11.5s到11.7s(总是低于12s)完成,大约320％CPU,例如,运行更一致,并且使用更少的资源(即使最佳运行速度比超线程的稀有异常值慢半秒.

是否有任何简单的OpenMP方法来检测超线程,并将num_threads()减少到实际的CPU内核数量？

(有一个类似的问题,Poor performance due to hyper-threading with OpenMP: how to bind threads to cores,但是在我的测试中,我发现仅仅从8到4线程的减少已经在Debian 7 wheezy和Xeon E3-1240v3上完成了这项工作,因此,这个问题仅仅是将num_threads()减少到核心数.)

最佳答案 如果您在Linux下运行[也假设是x86 arch],您可以查看/ proc / cpuinfo. cpu核心和兄弟姐妹有两个字段.第一个是[真实]核心的数量,后者是超线程的数量. (例如,在我的系统中,我的四核超线程机器分别为4和8).

因为Linux可以检测到[并且来自Zulan注释中的链接],所以也可以从x86 cpuid指令获得该信息.

无论哪种方式,还有一个环境变量：OMP_NUM_THREADS,它可能更容易与启动器/包装器脚本一起使用

您可能希望考虑的一件事是,除了一定数量的线程之外,您可以使内存总线饱和,并且线程[或内核]的增加不会提高性能,并且实际上可能会降低性能.

从这个问题：Atomically increment two integers with CAS有一个链接到CppCon 2015的视频讲座,分为两部分：https://www.youtube.com/watch?v=lVBvHbJsg5Y和https://www.youtube.com/watch?v=1obZeHnAwz4

他们每人约1.5小时,但IMO非常值得.

在演讲中,发言者[做过大量的多线程/多核优化]说,根据他的经验,内存总线/系统在大约四个线程后趋于饱和.

点赞