Skylake能否突破4IPC？其理论最大IPC及示例代码探讨

为什么你的代码IPC能超过4？ #

你提到的Skylake前端4指令/周期的解码速度，是指传统解码器的上限——当代码无法命中μop缓存时，前端只能通过解码器以每周期4条x86指令的速度解码。但Skylake还配备了μop缓存（Micro-op Cache）：如果代码能命中该缓存，前端可以直接从缓存中取出预解码后的微操作（uop），供给后端的速度可达每周期6个uop。

你的LLVM-MCA数据显示Dispatch Width: 6，说明前端确实在以最大分发宽度向后端输送uop；uOps Per Cycle: 5.71也接近6的上限。只要后端能及时处理这些uop（无数据依赖、端口资源充足），IPC就会突破传统解码器的4指令/周期限制——你的4.91就是这种情况的体现。

Skylake的理论最大IPC是多少？ #

Skylake后端拥有6个独立的执行端口，每个周期最多可以完成6个单uop指令（无数据依赖、端口分配无冲突），因此理论最大IPC为6。但实际场景中很难完全达到，因为需要满足严格的条件：

• 所有指令都是单uop，且无任何数据/控制依赖
• 指令能完美分配到不同的执行端口，无资源竞争
• 前端持续以每周期6个uop的速度供给（μop缓存命中）

达到理论极限的小型代码示例 #

以下是一段能接近Skylake理论IPC上限的汇编代码示例：

; 假设esi中存储循环次数，初始值足够大
loop_top:
    add     eax, ebx    ; 单uop，可分配到端口0/1/5
    add     ecx, edx    ; 单uop，可分配到端口0/1/5
    add     r8d, r9d    ; 单uop，可分配到端口0/1/5
    add     r10d, r11d  ; 单uop，可分配到端口0/1/5
    add     r12d, r13d  ; 单uop，可分配到端口0/1/5
    add     r14d, r15d  ; 单uop，可分配到端口0/1/5
    dec     esi         ; 与jnz宏融合为1个uop
    jnz     loop_top

这段代码的核心是：

1. 6条完全独立的add指令（无数据依赖），均为单uop，可并行分配到不同执行端口
2. dec esi与jnz loop_top会被宏融合成1个uop，不占用额外的执行端口资源
3. 循环体足够简单，能稳定命中μop缓存，前端持续以最大速度供给uop

当循环次数足够多时，这段代码的IPC可以接近6的理论极限。

内容的提问来源于stack exchange，提问作者Elliot Gorokhovsky