这可能更像是一个讨论问题，但我认为 stackoverflow 可能是提出这个问题的正确地方。我正在研究指令流水线的概念。我被告知，一旦流水线级数增加，流水线的指令吞吐量就会增加，但在某些情况下，吞吐量可能不会改变。在什么条件下，会发生这种情况？我认为停滞和分支可能是问题的答案，但我想知道我是否遗漏了一些重要的东西。
问问题
5430 次
5 回答
4
在等待结果或缓存未命中时，整个过程可能会被其他指令停止。流水线本身并不能保证操作是完全独立的。这是一个关于 x86 Intel/AMD 架构错综复杂的精彩演示：http: //www.infoq.com/presentations/click-crash-course-modern-hardware
它非常详细地解释了此类内容，并涵盖了一些有关如何进一步提高吞吐量和隐藏延迟的解决方案。JustJeff 提到了其中之一的乱序执行，并且您有程序员模型未公开的影子寄存器（x86 上超过 8 个寄存器），并且您还有分支预测。
于 2010-04-14T21:58:54.420 回答
3
同意。最大的问题是停顿（等待先前指令的结果）和不正确的分支预测。如果您的管道有 20 个阶段深，并且您等待条件或操作的结果，您将等待比您的管道只有 5 个阶段更长的时间。如果您预测错误的分支，则必须从管道中清除 20 条指令，而不是 5 条。
我想大概你可能有一个深度管道，其中多个阶段试图访问相同的硬件（ALU 等），这会导致性能下降，但希望你投入足够的额外单元来支持每个阶段。
于 2010-04-08T03:30:10.263 回答
1
指令级并行性的收益递减。特别是，指令之间的数据依赖关系决定了可能的并行性。
考虑写后读的情况（在教科书中称为 RAW）。
在第一个操作数得到结果的语法中，考虑这个例子。
10: add r1, r2, r3
20: add r1, r1, r1
第 10 行的结果必须在第 10 行的计算开始时才知道。数据转发缓解了这个问题，但……只是到了数据被知道的程度。
于 2010-04-14T22:49:42.593 回答
0
我还认为，将流水线增加超过系列中最长指令执行所需的时间不会导致性能提高。我确实认为停滞和分支是基本问题。
于 2010-04-08T02:30:20.263 回答
0
长管道中的停顿/气泡肯定会导致吞吐量的巨大损失。当然，流水线越长，浪费的时钟周期就越多。
我尝试了很长时间来考虑更长的管道可能会导致性能损失的其他场景，但这一切都回到了停滞状态。（以及执行单元的数量和发布方案，但这些与管道长度没有太大关系。）
于 2010-04-08T02:54:19.830 回答