我想知道超线程 CPU 的理论加速是多少。假设 100% 并行化和 0 次通信 - 两个 CPU 的加速比为 2。超线程 CPU 怎么样?
Kon*_*lph 61
正如其他人所说,这完全取决于任务。
为了说明这一点,让我们看一个实际的基准测试:

这是摘自我的硕士论文(目前无法在线获得)。
这显示了字符串匹配算法的相对加速1(每种颜色都是不同的算法)。这些算法在两个具有超线程的 Intel Xeon X5550 四核处理器上执行。换句话说:总共有 8 个内核,每个内核可以执行两个硬件线程(=“超线程”)。因此,基准测试最多使用 16 个线程(这是此配置可以执行的最大并发线程数)来测试加速。
四种算法中的两种(蓝色和灰色)在整个范围内或多或少地线性缩放。也就是说,它受益于超线程。
其他两种算法(红色和绿色;色盲人士的不幸选择)线性扩展最多 8 个线程。在那之后,他们停滞不前。这清楚地表明这些算法没有从超线程中受益。
原因?在这种特殊情况下,它是内存负载;前两种算法需要更多的内存进行计算,并且受到主存总线性能的限制。这意味着当一个硬件线程在等待内存时,另一个可以继续执行;硬件线程的主要用例。
其他算法需要较少的内存,不需要等待总线。它们几乎完全是计算边界并且仅使用整数算术(实际上是位运算)。因此,没有并行执行的潜力,也没有从并行指令流水线中获益。
1即加速因子为 4 意味着该算法的运行速度是仅用一个线程执行的速度的四倍。根据定义,在一个线程上执行的每个算法的相对加速因子为 1。
geo*_*ffc 20
问题是,这取决于任务。
超线程背后的概念基本上是所有现代 CPU 都有不止一个执行问题。现在通常接近十几个。分为整数、浮点数、SSE/MMX/Streaming(不管现在叫什么)。
此外,每个单元具有不同的速度。即它可能需要一个整数数学单元 3 个周期来处理某些东西,但 64 位浮点除法可能需要 7 个周期。(这些是不基于任何东西的神话数字)。
乱序执行有助于保持各个单元尽可能满。
然而,任何单个任务不会每时每刻都使用每个单个执行单元。甚至拆分线程也无济于事。
因此,假设有第二个 CPU,另一个线程可以在其上运行,使用未使用的可用执行单元,例如您的音频转码,这是 98% SSE/MMX 的东西,并且 int 和 float 单元完全除了一些东西闲置。
对我来说,这在单个 CPU 世界中更有意义,伪造第二个 CPU 允许线程更轻松地跨越该阈值,只需很少(如果有)额外的编码来处理这个虚假的第二个 CPU。
在 3/4/6/8 核的世界中,拥有 6/8/12/16 个 CPU 有帮助吗?不知道。尽可能多?取决于手头的任务。
因此,要真正回答您的问题,这将取决于您的进程中的任务、它正在使用哪些执行单元,以及在您的 CPU 中,哪些执行单元空闲/未充分使用并可用于第二个假 CPU。
据说某些“类别”的计算内容会受益(笼统地说)。但是没有硬性规定,对于某些课程,它会减慢速度。
我有一些轶事证据可以添加到geoffc 的答案中,因为我实际上有一个带有超线程的 Core i7 CPU(4 核)并且玩了一些视频转码,这是一项需要大量通信和同步但有足够的任务并行性,您可以有效地完全加载系统。
我通常使用 4 个超线程“额外”内核来处理分配给任务的 CPU 数量,这相当于相当于大约 1 个额外 CPU 的处理能力。额外的 4 个“超线程”内核增加的可用处理能力与从 3 到 4 个“真实”内核的数量大致相同。
诚然,这并不是一个严格的公平测试,因为所有编码线程可能会在 CPU 中竞争相同的资源,但对我来说,它确实显示出整体处理能力的至少小幅提升。
显示它是否真的有帮助的唯一真正方法是在启用和禁用超线程的系统上同时运行几个不同的整数/浮点/SSE 类型测试,并查看受控系统中可用的处理能力环境。