📚 课程目录第2章性能指标

2. 性能指标：吞吐量、延迟与加速比

做流水线设计，说白了就是在跟三个数字打交道：吞吐量、延迟和加速比。这三个指标就像流水线的三围，哪个差了都不行。我见过不少新手一上来就猛怼吞吐量，结果延迟爆炸，最后整个系统反而跑不起来。

咱们一个一个拆开讲。

吞吐量，衡量的是系统在单位时间内能处理多少任务。对于流水线来说，就是每秒钟能吐出多少个结果。

核心公式：

Throughput = 任务数 / 总时间

或者更常用的：

Throughput = 1 / 时钟周期 × 每周期完成的任务数

举个例子。一条 5 级流水线，时钟频率 1GHz，每周期能完成 1 条指令。那它的吞吐量就是 1 GIPS（Giga Instructions Per Second）。

但这里有个坑——流水线停顿。我在项目中遇到过，理论算出来吞吐量 1 GIPS，实际跑起来只有 0.7 GIPS。为什么？因为数据冒险、控制冒险、结构冒险都会让流水线停下来。你想想看，流水线一停，吞吐量就往下掉。

实战小技巧：

我个人习惯在评估吞吐量时，先算理论峰值，再乘一个 0.7~0.8 的折损系数。这个系数来自经验，但比直接拿理论值去忽悠老板靠谱得多。

延迟，指的是单个任务从进入流水线到完成所花的时间。注意，是单个任务，不是一批任务。

对于流水线来说，延迟 = 流水线级数 × 时钟周期。

Latency = N × T_clk

其中 N 是流水线级数，T_clk 是时钟周期。

举个例子：5 级流水线，时钟周期 1ns，那一条指令的延迟就是 5ns。

这里有个容易混淆的地方——吞吐量和延迟不是一回事。我见过有人把这两个混着用，结果设计评审时被怼得哑口无言。

指标	关注点	典型单位	流水线影响
吞吐量	系统整体处理能力	任务/秒	增加级数通常提升吞吐量
延迟	单个任务完成时间	秒、时钟周期	增加级数会增大延迟

注意：

我曾经在一个项目中，为了提升吞吐量，把流水线从 5 级加到了 12 级。吞吐量确实上去了，但延迟从 5ns 变成了 12ns。结果下游模块受不了这个延迟，整个系统反而要加额外的缓冲。嗯，这就是典型的「顾头不顾腚」。

加速比，衡量的是用了流水线之后，性能提升了多少倍。

定义公式：

Speedup = 非流水线执行时间 / 流水线执行时间

理想情况下，N 级流水线的加速比就是 N。但现实很骨感——因为流水线有开销，还有各种冒险。

实际加速比的计算要考虑流水线停顿：

Speedup_actual = N / (1 + 停顿周期数 / 总指令数)

举个例子：5 级流水线，每 10 条指令中有 2 个停顿周期。那实际加速比就是：

Speedup = 5 / (1 + 2/10) = 5 / 1.2 ≈ 4.17

你看，离理想的 5 倍还差一截。

这三个指标不是孤立的。我习惯用一个三角形来理解它们的关系：

从图上能看出来：

我的经验：

做流水线设计时，我一般先定延迟上限——因为下游模块往往有固定的时序要求。然后在这个约束下，尽量提升吞吐量。加速比嘛，更多是用来跟老板汇报的，证明你的设计比上一版强了多少倍。

假设我们要设计一个 4 级流水线加法器。非流水线版本执行一次加法需要 4ns。流水线版本时钟周期 1ns，每周期能完成 1 次加法。

非流水线：

延迟 = 4ns
吞吐量 = 1 / 4ns = 250 M次/秒

流水线（理想）：

延迟 = 4ns × 4级 = 4ns（注意：延迟没变！因为每级1ns，4级还是4ns）
吞吐量 = 1 / 1ns = 1000 M次/秒
加速比 = 1000 / 250 = 4

等等，这里有个细节——流水线的延迟其实没变。为什么？因为非流水线执行一次加法要 4ns，流水线也要 4ns（4级 × 1ns）。但吞吐量翻了 4 倍。

这就是流水线的精髓：用相同的延迟，换更高的吞吐量。

避坑指南：

我曾经在面试时问过一个候选人：「流水线能降低延迟吗？」他想了半天说「能」。嗯，这是个经典误区。流水线不能降低单个任务的延迟，它只是让多个任务能同时处理，从而提升吞吐量。除非你优化了关键路径，否则延迟只会增加或保持不变。

这三个指标是流水线设计的基石。记住：

它们之间互相制约，没有完美的设计。你只能根据实际需求做取舍。我个人习惯先把延迟定死，再优化吞吐量，最后用加速比来验证设计是否合理。