超线程...让我的渲染器慢了 10 倍

Question

执行摘要： 如何在代码中指定 OpenMP 应该只对 REAL 核心使用线程，即不计算超线程核心？

详细分析：多年来，我在空闲时间编写了一个纯软件的开源渲染器（光栅器/光线跟踪器）。 GPL 代码和 Windows 二进制文件可从此处获取： https://www.thanassis.space/renderer.html 它在 Windows、Linux、OS/X 和 BSD 下编译和运行良好。

上个月我引入了光线追踪模式 - 生成的图片质量飞速提升。不幸的是，光线追踪比光栅化慢几个数量级。为了提高速度，就像我对光栅器所做的那样，我向光线追踪器添加了 OpenMP（和 TBB）支持 - 以轻松利用额外的 CPU 核心。光栅化和光线追踪都很容易进行线程化（每个三角形的工作 - 每个像素的工作）。

在家里，使用我的 Core2Duo，第二个核心可以帮助所有模式 - 光栅化和光线追踪模式都获得了 1.85 倍到 1.9 倍的加速。

问题：自然，我很好奇看到顶级CPU性能（我也“玩”GPU，初步 CUDA 端口），所以我想要一个坚实的比较基础。我把代码给了我的一个好朋友，他可以使用一台“野兽”机器，配备 16 核、1500 美元的英特尔超级处理器。

他以“最重”模式（光线追踪器模式）运行它

……他的速度是我的 Core2Duo 的五分之一（！）

喘息 - 恐怖。刚刚发生了什么？

我们开始尝试不同的修改、补丁……最终我们找到了答案。

通过使用 OMP_NUM_THREADS 环境变量，可以控制生成多少个 OpenMP 线程。 随着线程数量从 1 个增加到 8 个，速度也在增加（接近线性增加）。 当我们超过 8 的那一刻，速度开始下降，直到它急剧下降到我的 Core2Duo 速度的五分之一，此时所有 16 个核心都被使用了！

为什么是8？

因为 8 是真实核心的数量。其他 8 个是……超线程！

理论： 现在，这对我来说是个新闻 - 我已经看到超线程在其他算法中提供了很多帮助（高达 25%），所以这是出乎意料的。显然，即使每个超线程核心都有自己的寄存器（和 SSE 单元？），光线追踪器也无法利用额外的处理能力。这让我想到......

可能不是处理能力匮乏——而是内存带宽。

光线追踪器使用包围体层次结构数据结构来加速光线-三角形相交。如果使用超线程核心，则一对中的每个“逻辑核心”都会尝试从该数据结构中的不同位置（即内存中）读取数据，并且CPU缓存（每对本地）将被完全破坏。至少，这是我的理论 - 非常欢迎任何建议。

问题是：OpenMP 检测“核心”数量并生成与之匹配的线程 - 也就是说，它在计算中包含超线程“核心”。就我而言，这显然会导致速度方面的灾难性结果。有谁知道如何使用 OpenMP API（如果可能的话，可移植的）仅为真实核心生成线程，而不是超线程核心？

PS 代码是开放的（GPL）并且可以在上面的链接中获取，请随意在您自己的机器上重现 - 我猜这会在所有超线程 CPU 中发生。

PPS 请原谅这篇文章的长度，我认为这是一次教育经历并想分享。

Answer 1

基本上，您需要一些相当可移植的方式来查询环境以获取相当低级的硬件详细信息 - 通常，您不能仅通过系统调用来做到这一点（操作系统通常甚至不知道硬件线程和内核之间的差异）。

hwloc 是一个支持多种平台的库 - 支持 Linux 和 Linux。 windows（和其他）、intel 和AMD芯片。 Hwloc 将使您了解有关硬件拓扑的所有信息，并了解内核和硬件线程（在 hwloc 术语中称为 PU - 处理单元）之间的区别。因此，您可以在开始时调用这个库，找到实际核心的数量，然后调用 omp_set_num_threads() （或者只是在并行部分的开头添加该变量作为指令）。

Answer 2

不幸的是，您关于为什么会发生这种情况的假设很可能是正确的。可以肯定的是，您必须使用配置文件工具 - 但我之前在光线追踪中见过这种情况，所以这并不奇怪。无论如何，目前无法从 OpenMP 中确定某些处理器是“真实的”，而某些处理器是超线程的。您可以编写一些代码来确定这一点，然后自己设置数字。然而，仍然存在 OpenMP 不会在处理器本身上调度线程的问题 - 它允许操作系统执行此操作。

OpenMP ARB 语言委员会一直致力于尝试定义一种标准方法，让用户确定其环境并说明如何运行。目前，这一讨论仍在激烈进行。许多实现允许您通过使用实现定义的环境变量将线程“绑定”到处理器。但是，用户必须知道处理器编号以及哪些处理器是“真实的”处理器，哪些是超线程的。

Answer 3

问题是OMP如何使用HT。
这不是内存带宽！
我在 2.6GHz HT PIV 上尝试了简单的循环。
结果是惊人的...

使用 OMP：

    $ time ./a.out 
    4500000000
    real    0m28.360s
    user    0m52.727s
    sys 0m0.064s

不使用 OMP：
$ 时间 ./a.out
4500000000

    real0   m25.417s
    user    0m25.398s
    sys 0m0.000s

代码：

    #include <stdio.h>
    #define U64 unsigned long long
    int main() {
      U64 i;
      U64 N = 1000000000ULL; 
      U64 k = 0;
      #pragma omp parallel for reduction(+:k)
      for (i = 0; i < N; i++) 
      {
        k += i%10; // last digit
      }
      printf ("%llu\n", k);
      return 0;
    }