X86 英特尔Nehalem微体系结构可以实现的最大IPC是什么？

是否对Intel Nehalem体系结构可实现的每个周期的最大指令数进行了估算？另外，影响每个周期的最大指令数的瓶颈是什么

TL:DR：

Intel Core、Nehalem和Sandybridge/IvyBridge：最多5个IPC，包括1个宏融合cmp+分支，将5条指令放入4个融合域uop，其余为单uop指令。（其中最多2个可以是微熔合存储或加载+ALU。）

Haswell高达第9代：使用两对指令和两条被解码为两个潜在微融合UOP的指令，每个周期最多可实现6条指令。根据，最大未使用域uop吞吐量为每个时钟7 uop

早期的P6系列：奔腾Pro/PII/PIII和奔腾M。还有奔腾4：使用3条被解码为3个UOP的指令，每个周期最多可以实现3条指令。（无宏融合，3宽解码和发布）

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

---

来源：。另请参见标记wiki

英特尔Core2及更高版本中出现故障的管道可以每个时钟发出/重命名4个融合域UOP。这是瓶颈。宏融合将把

cmp/jcc

组合成一个uop，但每个解码块只能发生一次。（直到哈斯韦尔）

此外，在SnB系列uop缓存之前，解码（最多4条指令到最多7个uop，采用4-1-1-1模式）也是另一个重要的瓶颈。多uop指令必须在第一个“插槽”中解码。有关Nehalem中潜在瓶颈的更多信息，请参阅Agner Fog的Microach指南

Nehalem指出，

nop

的吞吐量仅为0.33c，而不是0.25，但事实证明，这是因为

nop

在Sandybridge之前需要CPU中的ALU执行单元。Agner Fog说他没有发现Nehalem的退休瓶颈

即使您可以安排每4个uop有多个宏融合对在一个循环中，Nehalem的吞吐量也只有每个时钟（端口5）一个融合测试和分支uop。因此，即使不使用其中一些宏，它也无法在每个时钟上支持多个宏融合比较和分支。（Haswell无法在端口0或端口6上运行非执行分支）

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

请注意，pre-Haswell uarches只有三个ALU端口。但是

mov

加载或存储占用了管道带宽，因此拥有4个范围的问题/重命名有一个好处。前端的发布速度比无序内核的执行速度更快，这也很有用，因此调度程序中总是有一个工作缓冲区排队，这样它就可以找到指令级并行性，并尽早开始未来的加载，诸如此类

---

我认为除了加载/存储（包括

push

/

pop

由于堆栈引擎），

fxchg

可能是Nehalem中唯一不需要ALU端口的融合域uop。或者它实际上是这样的，比如

nop

。在SnB系列UARCHE上，有时还包括reg reg

mov

s（IvB和更高版本）<与Nehalem不同，code>nop也从不执行，因此SnB/IvB对

nop

的吞吐量为0.25c，即使它们只有3个ALU端口。

@Hadi:感谢您的编辑，但它引入了一个错误，除非我弄错了。Haswell（不是Skylake）添加了额外的not Take分支EU，并支持来自一个解码组的2个宏融合，正如我在后面的回答中所说的。此外，ROB始终位于融合域中。RS融合在P6家族而非SnB家族；也许你就是这么想的。Haswell确实有两个分支执行单元，但你确定它支持每个周期两个宏融合吗？我刚刚用一个循环运行了一个快速测试，该循环包含两条

add

指令序列和两条宏fusable

cmp/jcc

指令（一条总是不执行，一条总是执行循环控制）<代码>UOPS\u发布的任何显示每个迭代有4个UOPS（确认宏融合工作），但吞吐量是每个迭代1.7个周期。我认为这表明Haswell每个周期只能进行一次宏融合，除非我遗漏了什么。@HadiBrais:我没有可供测试的HSW:/除非你用NOP或其他东西溢出uop缓存，否则不会在每次迭代中重新解码紧密循环。因此，4个UOP确认您的循环解码时两个分支都融合了。如果在循环之前使用多uop insn，则确保循环作为一个组命中解码器。它不必每次迭代都重新融合它们，只需从LSD发出并执行UOP。将循环入口点对齐64（填充的最后一条指令是multi-uop）可能有助于排除前端的奇怪之处。@HadiBrais:但即使ROB是未使用的域，我认为前端吞吐量仍然是每个时钟4个融合域uop。因此，在任何给定的周期内，如果所有UOP都是微熔合加载+ALU或存储，则发布阶段能够写入8个ROB和RS条目。（可作为更大回路的一部分使用，或在4-uop回路中使用2个微熔合uop）。我还没有测试这个结论，看看我的理论是否符合现实，但我们确实知道SKL的未使用RS不是我的7 uop/时钟循环的瓶颈。这不像是不对齐。哦，是的，我忘了对齐。在64字节边界上对齐循环后，我得到了6的IPC。谢谢你指出这一点。是的，它不必支持每个周期两次宏融合，只要它可以从uop cach每周期馈送4个uop

;; 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