为什么HT的并行编译性能比没有?

时间:2013-12-15 18:52:18

标签: performance hyperthreading

我在Linux 2.6.39 x86_64上的Core i7 930 @ 2.8GHz(四核)上的BIOS中启用并禁用了HyperThreading的葡萄酒编译时间。每次测量都是这样的:

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

其中N是从1到8的数字。

这是结果(“速度”是60 /实时(1)):

enter image description here

此处蓝线对应HT禁用,紫色对应HT启用。看来,当启用HT时,使用1-4线程比没有HT慢。我想这可能与内核没有将进程分配到不同的内核并重用已经忙碌的内核的第二个线程有关。

所以,我的问题是:如何强制内核为每个核心调度提供1个进程,而不是向同一个核心的不同线程添加更多进程?或者,如果我的推理是错误的,那么对于并行运行的1-4个进程,如果没有HT,我怎么能有HT的性能呢?

2 个答案:

答案 0 :(得分:2)

英特尔芯片上的超线程是作为一个pysical核心的一些元素的重复实现的,但没有足够的电子元件作为独立核心(例如,他们可能共享一个指令解码器,但我不记得英特尔实现的具体细节)。

使用HT作为1.5个物理内核构建一个物理内核,操作系统将其视为2个真实内核。这不等于1.5倍的速度(这可能因使用情况而异)

在您的示例中,非HT最多可以加速4个线程,因为没有任何内核与其HT管道共享工作。您会看到4个线程以上的平线,因为现在您只有4个执行线程,并且您可以在线程之间进行一些额外的开销上下文切换。

在HT示例中,您可能会慢到4个线程,因为其中一些线程被分配给一个真正的核心并且它是HT,因此这两个执行线程共享物理资源会导致性能下降。超过4个线程,您将看到额外执行线程的好处,但您会看到收益递减的开始。

您最多可以在两种情况下匹配最多4个线程的性能,但可能不会与编译作业匹配。我认为,为了设置处理器亲和性而产生的许多进程。如果你使用OpenMP或MPI运行一个真正的并行作业,其中X< = 4个线程绑定到特定的真实CPU核心,我认为你会看到HT-off和-on之间的性能相似。

答案 1 :(得分:1)

给定一些线程< =真实核心的数量,使用HT应该更慢,因为(粗略地认为)你可能会将核心的速度降低一半。 1

请记住,通常更多内核并不比更快的内核更好。事实上,开发多核系统这么多工作的唯一原因是变得越来越难以加快更快的。因此,如果您不能拥有20 Ghz处理器,则需要8 x 3 Ghz处理器。

我认为HT主要是在上下文中的优势,其中每个线程不一定会吞噬尽可能多的处理器;它正在做一些特定的任务,由与用户的互动来管理,比如CAD东西,视频游戏等;这些是从多任务中受益的应用程序。相比之下,服务器平台 - 其中主要应用程序倾向于线程独立的任务,这些任务不依赖于任何其他任务,因此尽可能快地运行 - 不会直接受益于多个-tasking;他们受益于速度make属于同一类别,尽管线程之间可能存在更大程度的相互依赖性,这就是为什么你会看到4-8线程的HT优势。


1。这是一种简化。 HT不会简单地将内核数量加倍并将其速度减半,但无论使用何种动态,系统的每秒处理器周期总数都不会得到改善。它是相同的 - 只有更多支离破碎