Performance 为什么有HT的并行编译性能比没有HT的差？

我在Linux 2.6.39 x86_64上的i7 930@2.8GHz内核（四核）上的BIOS中启用和禁用了超线程，对wine的编译时间进行了多次测量。每次测量都是这样的：

git clean -xdf
./configure --prefix=/usr
time make -j$N

其中

N

是从1到8的数字

以下是结果（“速度”为60/实时（1））：

此处，蓝线对应HT禁用，紫色线对应HT启用。当启用HT时，使用1-4个线程似乎比不使用HT慢。我想这可能与内核没有将进程分发到不同的内核以及重用已经繁忙的内核的第二个线程有关

---

所以，我的问题是：我如何强制内核给每个内核一个进程调度更高的优先级，而不是给同一个内核的不同线程添加更多的进程？或者，如果我的推理是错误的，对于并行运行的1-4个进程，使用HT的性能如何不比不使用HT的性能差？

给定大量线程英特尔芯片上的超线程是作为pysical内核的某些元素的复制而实现的，但没有足够的电子设备作为独立内核（例如，他们可能共享一个指令解码器，但我想不起英特尔实施的具体细节）

将一个带有HT的pysical内核镜像为1.5个物理内核，而您的操作系统将其视为2个真实内核。但这并不等于1.5倍的速度（这可能因使用情况而异）

在您的示例中，非HT的速度更快，最多4个线程，因为没有一个内核与它们的HT管道共享工作。您可以看到4个线程上方的平面线，因为现在您只有4个执行线程，并且线程之间的上下文切换会有一点额外的开销

在HT示例中，最多4个线程的速度稍慢，这可能是因为其中一些线程被分配给了一个真正的内核，而该内核是HT，因此这两个执行线程共享物理资源时，性能正在下降。在4个线程以上，您看到了额外执行线程的好处，但您看到了减少r的开始埃图恩斯

---

对于最多4个线程，您可能可以在这两种情况下匹配性能，但可能不会与编译作业匹配。我认为，对于为设置处理器相关性而生成的许多进程，如果您使用OpenMP或MPI与XWell运行真正的并行作业，您似乎试图说HT不会加快任何速度。但这显然是不正确的根据这项技术的定义，这是正确的，也与观察结果相矛盾（参见图中的线程>4，比较两条曲线）.从我的测量结果来看，它有效地增加了一个核心，尽管物理上只有4个核心-在所有8个线程都在忙着工作的情况下。你是对的，我向后解释了图表，lol，我会编辑这个。但是：图表仍然显示了我的一般观点，即超线程不会--不能--增加处理器周期可用。它显然是动态扩展的，因此，如果您在四核上运行4个线程，理想情况下，这4个线程与不运行HT的4个线程大致相同。“理想情况下，或多或少”这就是区别所在——在这种情况下，理想的情况是4个快速内核。您有4个没有HT的快速内核，启用它不能使它变得更好，但可能使它变得更糟。图表显示，对于超线程和此任务，近似线性速度随着线程数增加到4而增加，然后再增加一个较小的速度（但仍在增加）。我没有想到会出现这种情况，但请查看数据。很抱歉，您根本不了解HT。将HT与另一个要添加的内容一起使用是，超线程允许每个核心有多个线程，可能会导致缓存争用问题。可能是其他线程（如果你吃掉了所有的内核，并且有很多后台进程，比如如果你让X服务器运行的话，可能会有很多）在同一个物理内核上进行调度，并逐出大量编译器的缓存线（否则这是一个很好的解释）。