英特尔 Nehalem 微架构可以实现的最大 IPC 是多少？答案

【问题标题】：What is the maximum possible IPC can be achieved by Intel Nehalem Microarchitecture?英特尔 Nehalem 微架构可以实现的最大 IPC 是多少？
【发布时间】：2016-08-30 16:12:34
【问题描述】：

英特尔 Nehalem 架构可实现的每周期最大指令数是否有估计值？此外，影响每个周期最大指令的瓶颈是什么？

【问题讨论】：

标签： x86 intel cpu-architecture nehalem

【解决方案1】：

TL:DR：

Intel Core、Nehalem 和 Sandybridge / IvyBridge：最多 5 个 IPC， 包括 1 个宏融合 cmp+branch 将 5 个指令放入 4 个融合域微指令，其余的是单微指令。（其中最多 2 个可以是 micro-fused store 或 load+ALU。）

Haswell 高达第 9 代：使用两对 macro-fusable ALU+branch 指令和两条解码成两个潜在微融合微指令的指令可以实现每个周期最多 6 条指令。根据my testing on Skylake.，最大 unfused-domain uop 吞吐量为每时钟 7 uop。

早期的 P6 系列：Pentium Pro/PII/PIII 和 Pentium M。还有 Pentium 4：使用 3 条指令解码为 3 条微指令，每个周期最多可以实现 3 条指令。（无宏融合，3-wide decode and issue）。

Sunny Cove 上的最大 IPC 可能为 7，这要归功于每时钟 5 uop 的前端带宽增加。

来源：Agner Fog's microarch pdf and instruction tables。另请参阅x86 标签 wiki。

Intel Core2 及更高版本中的乱序流水线可以在每个时钟发出/重命名 4 个融合域微指令。这就是瓶颈。 宏融合会将cmp / jcc 组合成一个微指令，但每个解码块只能发生一次。（直到 Haswell）。

另外，解码（最多 4 条指令以 4-1-1-1 模式最多 7 条指令）是 SnB 系列中的 uop-cache 之前的另一个重要瓶颈。多指令必须在第一个“槽”中解码。有关 Nehalem 潜在瓶颈的更多信息，请参阅 Agner Fog 的微架构指南。

Nehalem InstLatx64 表明 nop 令人惊讶地只有 0.33c 吞吐量，而不是 0.25，但根据 https://www.uops.info/table.html 的结果，这是因为 nop 在 Sandybridge 之前的 CPU 中需要一个 ALU 执行单元。 Agner Fog 说他没有发现 Nehalem 的退休瓶颈。

即使您可以安排每 4 个微指令中不止一个宏融合对在一个循环中，Nehalem 的吞吐量也仅为每个时钟（端口 5）一个融合的测试和分支微指令。因此，即使其中一些没有被采用，它也不能在每个时钟维持一个以上的宏融合比较和分支。（Haswell 可以在端口 0 或端口 6 上运行未采用的分支）。

;; Should run at one iteration per clock
.l:
    mov   edx, [rsi]    ; doesn't need an ALU uop.  A store would work here, too, but a NOP need an ALU port on Nehalem.
    add   eax, edx
    inc   rsi
    cmp   rsi, rdi          ; macro-fuses
    jb   .l                 ; with this, into 1 cmp+branch uop

为了便于测试并消除缓存/内存瓶颈，您可以将其更改为每次都从同一位置加载，而不是在寻址模式下使用循环计数器。（只要您避免因过多冷寄存器而导致寄存器读取停顿。）

请注意，Haswell 之前的 uarches 只有三个 ALU 端口。但是mov 加载或存储占用了管道带宽，因此拥有 4 宽的问题/重命名是有好处的。前端能够比乱序内核执行得更快也很有用，因此在调度程序中总是有一个工作缓冲区排队等待，因此它可以找到指令级并行性并尽早开始未来的负载，诸如此类。

我认为除了加载/存储（包括push/pop，感谢堆栈引擎）之外，fxchg 可能是 Nehalem 中唯一不需要 ALU 端口的融合域微指令。或者它实际上确实如此，比如nop。在 SnB 系列 uarches 上，xor same,same is handled in the rename/issue stage，有时还有 reg-reg movs（IvB 和更高版本）。 nop 也永远不会执行，这与 Nehalem 不同，因此 SnB/IvB 对 nop 的吞吐量为 0.25c，即使它们只有 3 个 ALU 端口。

【讨论】：

@Hadi：感谢您的编辑，但除非我弄错了，否则它会引入错误。 Haswell（不是 Skylake）添加了额外的未采用分支 EU，并支持来自一个解码组的 2 个宏融合，就像我稍后在这个答案中所说的那样。此外，ROB总是在融合域中。 RS融合在P6家族而不是SnB家族上；也许这就是你的想法。
Haswell 确实有两个分支执行单元，但你确定它每个周期支持两个宏融合吗？我刚刚使用包含两个add 指令序列和两个宏可熔cmp/jcc 指令序列的循环进行了快速测试（始终不采用一个，始终采用一个用于循环控制）。 UOPS_ISSUED_ANY 显示每次迭代有 4 个微指令（确认宏融合有效），但吞吐量为每次迭代 1.7 个周期。我认为这表明 Haswell 每个周期只能进行一次宏融合，除非我遗漏了什么。
@HadiBrais：我没有可用于测试的 HSW：/ 除非您使用 NOP 或其他内容溢出 uop 缓存，否则每次迭代都不会重新解码紧密循环。所以 4 uops 确认你的循环解码时融合了两个分支。如果您在循环之前使用多微指令 insn，则可以确保循环将解码器作为一个组命中。它不必每次迭代都重新融合它们，只需从 LSD 发出并执行 uops。将循环入口点对齐 64（最后一条填充指令是多指令）可能有助于排除前端的怪异。
@HadiBrais：但即使 ROB 是非融合域，我认为前端吞吐量仍然是每个时钟 4 个融合域 uops。因此，在任何给定的周期中，如果所有的微指令都是微融合加载+ALU 或存储，则发布阶段能够写入每个 ROB 和 RS 条目 8 个。（可作为更大循环的一部分，或在 4-uop 循环中使用 2 个微融合 uop）。我还没有测试这个结论来看看我的理论是否符合现实，但我们知道 SKL 的未融合 RS 不是我的 7 uop/clock 循环的瓶颈。这不像脱层。
哦，是的，我忘了对齐。在 64 字节边界上对齐循环后，我得到的 IPC 为 6。感谢您指出这一点。是的，它不必每个周期支持两个宏融合，只要它可以从 uop 缓存或 LSD 每个周期提供 4 个 uops。 Agner 的指南在第 10.6 节中确实说过 HSW 和 BDW 在一个循环中支持两个宏融合。