IPC 为什么到不了理论值：五级加宽点与真正的瓶颈

承总纲 pipelining-superscalar，超标量硬件结构见 superscalar-design。流水线和超标量给了"硬件上能多快"的潜力，但真实程序很少跑满。本篇回答两个互为镜像的问题：IPC 为什么能 > 1？反过来，为什么真实 IPC 又远达不到理论峰值（4~6）？ 答案藏在超标量架构的五个加宽点上——从取指到退休，每一级都被横向加宽，但每一级也都有各自的限制条件。

一、IPC > 1 的完整机制：哪里加宽了、各自有什么限制

答案藏在超标量架构的五个加宽点上——从取指到退休，每一级都被横向加宽，但每一级也都有各自的限制条件。下面从数据流的角度逐一拆解。

五级加宽全览

加宽点          并行度                     限制条件
────────────────────────────────────────────────────────────────────────────
① 取指          每拍 4~6 条 x86 指令       I-Cache miss、分支跳转打断连续取指、
                                            x86 变长指令预译码瓶颈
────────────────────────────────────────────────────────────────────────────
② 译码          4~6 个译码器并行            复杂指令需多 µop（如 rep movsb 几十条）
                                            一条复杂指令可能占满所有译码槽
────────────────────────────────────────────────────────────────────────────
③ 发射          保留站每拍可发射             操作数依赖（RAW 冒险）——源寄存器
                INT 4 条 + FP 4 条          被前面未完成指令占用则无法发射
                                            端口冲突——多条 µop 争同一执行单元
────────────────────────────────────────────────────────────────────────────
④ 执行          INT：8 ALU + 2 分支         端口专业化——整数加法只走 ALU 端口
                FP：4 FMA + 4 SIMD ALU      长延迟指令（除法 20+ 拍）占着端口
                共 18 个执行单元             访存只能走 LSU 的 AGU（×3~4）
────────────────────────────────────────────────────────────────────────────
⑤ 退休          ROB 每拍 4~8 条 µop         对头阻塞——头部未完成则后面全堵
                （与发射宽度对称匹配）        ROB 满（200~500 条目）则前端停发射
────────────────────────────────────────────────────────────────────────────

各加宽点的详细限制

① 取指宽度（4~6 条/拍）——"水源"瓶颈

现代 x86 前端每拍最多从 I-Cache 取出 16~32 字节（取决于微架构），对应 4~6 条普通指令。限制来自三个方面：

• I-Cache miss：取指地址不在 L1 I-Cache 中，需等 L2（~12 拍）或 L3（~40 拍），前端完全停摆。这是大代码段、虚函数-heavy 程序的常见瓶颈，perf 中表现为 stalled-cycles-frontend 高。
• 分支打断连续取指：遇到 taken branch 时，下一条指令地址不在当前 cache line 的连续位置，取指需要从新地址开始。即使分支预测正确，也有 1~2 拍的取指气泡。未预测到的间接跳转（如虚函数调用 call *%rax）会让取指完全中断。
• x86 变长指令：指令长度 1~15 字节不等，译码器必须先做预译码(pre-decode)标记每条指令的边界。如果指令流中有大量长指令（如带 REX 前缀 + ModRM + SIB + displacement），实际取指带宽可能只有 2~3 条/拍。

② 译码宽度（4~6 条/拍）——"复杂指令"陷阱

x86 的译码器数量就是前端吞吐的天花板。Intel 从 Core 2 开始用 4 个译码器（3 简单 + 1 复杂），AMD Zen 也是 4 个。限制：

• 简单指令 1:1 译码：add %rax, %rbx → 1 个 µop，占 1 个译码槽。
• 复杂指令 1:N 译码：rep movsb 可能生成几十个 µop，复杂译码器独占期间简单译码器也得等。div、idiv、cpuid 等也是 µop 炸弹。
• µop Cache 缓解：现代 CPU 用 µop Cache（Intel 的 DSB，AMD 的 OC）缓存已译码的 µop 序列，命中时完全跳过译码阶段——此时取指带宽可以 > 4 µop/拍。

③ 发射宽度（INT 4 + FP 4 = 8 µop/拍）——依赖链是头号杀手

这是超标量实际 IPC 的最常见瓶颈。保留站里可能有几十条 µop 在等待，但每拍能发射到执行单元的只有有限条，受两条规则约束：

• 操作数就绪（RAW 依赖）：µop 的源操作数如果不是"就绪"状态（被前面未完成指令的结果占用），就不能发射。一个三指令依赖链 A→B→C→D 中，A 发射后 B 等 1 拍才能发射，C 等 B、D 等 C……超标量再宽也只能一拍一条。
• 执行端口冲突：两条 µop 操作数都就绪，但如果它们都需要同一个执行端口（比如都是整数 ALU 运算），而该端口只有 4 个槽位，第 5 条就只能等下拍。编译器指令调度（-O2 以上）会尽量交错不同类型指令来缓解端口冲突。

这就是为什么 IPC 从 0.61（-O0）升到 1.68（-O2）后仍然远低于理论 4~6 的原因——不是执行单元不够（8 个 ALU 闲置 7 个），而是保留站里能发射的 µop 太少（依赖链捆住了绝大多数候选指令）。

④ 执行宽度（18 个执行单元）——跑不满的真正原因

执行单元数量远超前端带宽，理论上足够支撑高 IPC。但实际中执行单元利用率极低，原因有三：

• 端口专业化是双刃剑：Add 只走 INT ALU，FMA 只走 FP 端口，load 只走 AGU。一段连续整数加法的代码把 8 个 ALU 填得满满当当，4 个 FMA 和 4 个 SIMD ALU 完全空闲——这是"结构性空转"。
• 长延迟指令占着端口不出活：div 执行 20+ 拍，期间该端口不能再接收新指令。虽然现代 CPU 对除法做了流水化（多周期但可重叠），吞吐仍远低于加法。
• 执行结果需要旁路网络：运算结果要通过旁路网络(bypass network)转发给依赖指令，如果依赖链跨集群（INT 算完给 FP 用），旁路延迟多 1~2 拍，进一步拉长依赖链。

⑤ 退休宽度（4~8 µop/拍）——对头阻塞

这部分前文 superscalar-design §1.4 已详细分析。退休本身很少成为瓶颈（宽度与发射对称），但对头阻塞会让前面所有加宽的努力白费：一条 load miss 指令堵在 ROB 头部，后面 200 条已完成的指令全部出不来——此时 IPC 跌到接近 0，但问题不在退休宽度不够，而在那条慢指令本身。

三层并行抽象

将上述五级加宽浓缩为三个逻辑层：

层级        做了什么                                  该层并行度
─────────────────────────────────────────────────────────────────
执行层      8 ALU + 4 FMA + 4 SIMD ALU + 2 分支      同一拍最多 18 个执行单元同时运算
（根本）    各自独立、互不阻塞
─────────────────────────────────────────────────────────────────
发射层      保留站乱序发射，操作数就绪即分发            INT 集群同拍最多 4 条
（调度）    找无依赖 µop 填满空闲执行单元              FP 集群同拍最多 4 条
─────────────────────────────────────────────────────────────────
退休层      ROB 多端口并行提交                         每拍 4~8 条 µop 退休
（出口）    连续完成的头部条目批量退休
─────────────────────────────────────────────────────────────────
管线的瓶颈  取指/译码 4~6 条、LSU AGU 3~4 个          I-Cache miss、变长指令、复杂 µop

真实 IPC 公式：

IPC = min(
    前端带宽,                          ← 硬件上限
    保留站可发射数,                     ← ILP（依赖链长度）
    执行单元可用端口数,                 ← 端口冲突
    ROB 退休带宽,                      ← 对头阻塞
    1 / (每条指令平均访存延迟)          ← Cache miss
)

最小项决定最终 IPC，五个加宽点中任何一个卡住，其他四个加得再宽也没用。

三层之间的关系：

• 退休层不拖后腿：退休带宽（4~8 µop/拍）与发射带宽（4+4=8 µop/拍峰值）对称匹配。只要头部的多条指令都完成了，它们就同一拍退休，没有"逐条排队"的单入口瓶颈——ROB 是宽闸门，不是单车道。
• 真正的瓶颈在发射层：执行单元再多，如果保留站里所有 µop 都因为操作数未就绪而卡住（依赖链太长、cache miss 没回来），那执行单元就空转。这就是为什么超标量必须配乱序执行——去挖 ILP、填满空闲端口。
• 执行层是理论上限但很少真正达到：18 个执行单元并行运算，但端口专业化让大多数代码只能用到其中一小部分。纯整数代码只能用 8 个 ALU，浮点密集型代码只能用 4 个 FMA——全单元同时满载仅在"整数+浮点+SIMD 高度混合且无依赖"的理想情况下才有可能。

用一个时序片段来直观感受：假设程序有 6 条无依赖的整数加法：

拍1: 前端取指 I1~I6（6 条全部进入）
拍2: 译码完成，全部发射到 INT 保留站
拍3: 保留站乱序发射——I1→ALU1, I2→ALU2, I3→ALU3, I4→ALU4（4 条同拍开始执行）
     剩余 I5、I6 等下一拍（ALU 池有 8 个，但保留站发射宽度限制为 4）
拍4: I1~I4 完成（1 拍延迟），结果写入各自 ROB 槽位
     I5→ALU5, I6→ALU6 发射
拍5: I1~I4 全部在 ROB 头部且都已完成 → 同一拍退休 4 条（IPC=4）
     I5、I6 完成，写入 ROB
拍6: I5、I6 退休（IPC=2）

这个例子中，IPC=4 受限于发射宽度（保留站每拍只能发 4 条到 INT 集群），而非执行单元（有 8 个 ALU 闲置）或退休宽度。如果这 6 条指令两两依赖（I1→I2, I3→I4, I5→I6），则 IPC 降到 2——依赖链长度直接吃掉一半宽度。

实际 CPU 不会完美到 IPC=4 持续不断——依赖链、cache miss、分支误预测随时会打断这个理想流。但架构设计的初衷就是：在 ILP 充足的瞬间，所有五级加宽点都能支撑 IPC > 1，没有哪一级是单入口串行瓶颈。真正限制 IPC 的是软件本身的 ILP 和访存延迟，不是硬件加宽不够。

二、流水线 vs 超标量 + 为什么必须乱序

流水线和超标量是正交的两个维度——流水线是纵向（时间重叠），超标量是横向（空间加宽），两者独立、叠加使用：

	流水线	超标量
方向	纵向（时间维度重叠）	横向（空间维度加宽）
做法	一条指令切成 N 级，级间重叠	每级放 M 份硬件
提升	吞吐 ≈ ×级数（IPC 上限≈1）	IPC 上限 ≈ 宽度 M
现代 CPU	二者都用：既深(15~20级)又宽(4~6路)

但超标量给了"一拍多条"的硬件能力，能不能真喂满，取决于程序里有多少指令级并行(ILP)——即"此刻有多少条互不依赖、能同时跑的指令"。如果按程序顺序取指，紧挨着的几条往往有依赖：

add rax, rbx      ; ①
mov rcx, rax      ; ② 依赖①的 rax → 必须等① → 不能同拍
sub rcx, 1        ; ③ 依赖② → 又得等

这三条是依赖链，超标量再宽也只能一条条来，端口大量空闲，IPC 掉回接近 1。

出路：乱序执行——不按程序顺序，从后面捞出与①②③无关的独立指令，填进空闲端口。这就是为什么超标量几乎必然配乱序执行：横向加宽的硬件，需要乱序调度才喂得饱（详见 cpu-out-of-order）。

关键因果链：流水线→吞吐到 IPC≈1 见顶 → 超标量加宽想突破 1 → 但顺序发射喂不满宽机器 → 必须乱序执行找 ILP → 但乱序遇到分支会卡 → 必须分支预测跨过分支继续找。这条链就是微架构演进的主线（见总纲 cpu-microarch-overview）。IPC > 1 能成立，不是因为某一个环节特别快，而是执行层多单元并行、发射层乱序填满、退休层多端口批量提交三层同时加宽——每一层都没有单入口串行瓶颈（详见上节）。

三、观测：IPC 就是超标量+流水线成效的总分

流水线和超标量的综合成效，直接体现在 IPC(每周期退休指令数)（见 perf）：

perf stat ./app
#   看 insn per cycle 那一行,就是 IPC
#   IPC = instructions / cycles

判读：

• IPC 接近核宽度(如 3~4) = 流水线满、超标量端口喂得饱，ILP 挖得好。
• IPC 远低于 1(如 0.3) = 流水线频繁停顿/清空。常见元凶：cache miss（等内存，cache-organization/tlb）、分支误预测（清空流水线，branch-prediction）、长依赖链（ILP 不足）。
• 配套事件：stalled-cycles-frontend（前端喂不上，多为 I-cache/分支）、stalled-cycles-backend（后端卡住，多为 load miss/端口争用）。

IPC 是"CPU 内部效率"的总分；它低，说明你的代码没喂饱这台又深又宽的机器——去查是内存(cache/TLB)、分支、还是依赖链。

四、一句话总结

超标量给了"一拍多条"的硬件能力（五级加宽点：取指 4~6 / 译码 4~6 / 发射 INT 4+FP 4 / 执行 18 单元 / 退休 4~8 µop 每拍），但真实 IPC = min(前端带宽、发射数、端口数、退休带宽、访存延迟)——最小项卡住，其他加得再宽也没用。最常见的瓶颈在发射层：依赖链捆住候选 µop、端口冲突互相抢槽位，而不是执行单元不够；所以超标量几乎必然配乱序执行去挖 ILP、配分支预测跨过控制冒险。流水线（纵向重叠）和超标量（横向加宽）是两个正交手段，现代大核既深又宽地叠加使用；综合成效直接看 perf stat 的 IPC，低了就去查 cache/TLB miss、分支误预测、依赖链。