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