超线程对编译器性能的影响？答案

【问题标题】：Impact of hyperthreading on compiler performance?超线程对编译器性能的影响？
【发布时间】：2010-01-06 18:07:14
【问题描述】：

假设我们想尽可能快地编译一个大型项目（比如 GCC 或 Linux 内核）。具有超线程功能的 CPU（比如 Intel Core i7）在启用或禁用超线程的情况下运行编译器的速度是否更快？是否有任何已发布的基准测试？

我对超线程的理解是，每个内核都可以从两个（或多个进程）中选择指令。这通常会使核心更高效，因为功能单元空闲的可能性较小。但是，由于在同一内核上运行的进程共享缓存等资源并且可能相互干扰，因此可能会降低性能。性能是否真正提高取决于工作负载。

那么对于编译器工作负载，性能会提高吗？如果有，多少？

【问题讨论】：

我最近没有这方面的经验，但编译不是受 I/O 限制的吗？
玩“make -j N”并测量不同N的系统资源？
@Nikolai，如果我有一个超线程 CPU 可以玩，我会的。我问这个是为了知道买一个是否值得。
@Ken，我的经验正好相反。由于我通常会进行小的更改并经常重新编译，因此所有源通常都在磁盘缓存中。编译时我经常看到 100% 的 CPU 使用率。

标签： performance compilation hyperthreading

【解决方案1】：

在 Ubuntu 8.04 x86 上编译 coreutils-8.4

启用了 HT 的 Intel Atom 1.6 GHz：

~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make > /dev/null

real    2m33.375s
user    2m22.873s
sys     0m10.541s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make -j2 > /dev/null

real    1m54.707s
user    3m26.121s
sys     0m13.821s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make > /dev/null

real    2m33.372s
user    2m22.753s
sys     0m10.657s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make -j2 > /dev/null

real    1m54.851s
user    3m26.145s
sys     0m13.685s
~/coreutils-8.4$

所以超线程将运行时间减少到 75%，这相当于 处理能力提高了 33%。（我运行了两次以确保所有内容都在内存缓存中。）

这是一个对照实验，表明单独使用make -j2 并不能提高在 Ubuntu 8.04 x86 上编译 coreutils-8.4 的速度

单核 Core 2 Quad 2.5 GHz VM（无 HT）：

~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make > /dev/null

real    0m44.453s
user    0m38.870s
sys     0m5.500s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make -j2 > /dev/null

real    0m45.131s
user    0m40.450s
sys     0m4.580s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make > /dev/null

real    0m44.621s
user    0m39.090s
sys     0m5.340s
~/coreutils-8.4$ make clean > /dev/null
~/coreutils-8.4$ time make -j2 > /dev/null

real    0m45.165s
user    0m40.390s
sys     0m4.610s
~/coreutils-8.4$

【讨论】：

这很棒。对照实验表明，这确实有所作为。谢谢。
我希望看到在禁用 HT 的情况下在 Atom 上重复测量，假设这是可能实现的。此外，关于内存使用的说明会很好，因为 Atom 可能会开始交换或删除缓存，尤其是在 -j2 情况下。
In-order Atom 在利用指令级并行性方面比 Nehalem 或 Sandybridge 系列 CPU 或 AMD Ryzen 更差。与主流 CPU 相比，HT 对 Atom 的帮助可能更大。或者它可能帮助更少，因为主流 CPU 具有更大的缓存和更多的执行资源（以及更高的分支错误预测惩罚，并且 HT 允许另一个线程在一个从错误推测中恢复时使用 CPU）。因此，HT 可能对主流 CPU 也有很大帮助，但比例可能大不相同。
我对这个实验持保留态度。通常，单个进程构建会像读取、进程、写入或 io/cpu/io 一样，只需通过 Make 使用两个线程，您就可以改进这一点。可以尝试从 bios 中禁用 HT 并进行测试。
@auselen 这是一个高度简化的实验，有很多限制，但对照实验专门解决了您的问题

【解决方案2】：

这完全取决于编译器是否被编写为多线程的。如果是这样，那么超线程肯定会加快速度，因为操作系统可以将编译器线程的不同部分调度到不同的内核上。我同意 Ken 的观点，即编译通常比处理密集型更受 I/O 限制，因此拥有高速硬盘驱动器比拥有 100 个内核的高速处理器更为必要。

【讨论】：

如果编译器是用 make -j N 调用的（N 是逻辑处理器的数量）呢？我担心由于不同的编译器进程不共享任何数据，它们实际上会大大降低性能。
1) 只要有足够的物理内存，编译（无论如何在 Linux 上）总是可以不受 io 限制。 2) 流行的构建系统可以并行调用许多编译器进程，使得多线程编译器不再是问题。（不过，对于链接器而言，情况则不然）