Haswell架构IMUL指令端口调度异常及超线程资源共享问题咨询

测试环境 #

Intel Xeon E5-1620 v3（Haswell架构，超线程开启）

测试结果 #

• 单IMUL r64, r64循环：符合预期，µOPs仅调度至Port1
• 双/三独立IMUL循环：所有µOPs仍仅分配到Port1，未按预期分散至Port0/5
• 同物理核超线程双线程均运行IMUL：Port1可处理3600M µOPs/秒，无性能损失
• 替换为ADD指令测试：µOPs均匀分配至Port0/1/5；但当超线程中一线程跑IMUL、另一跑ADD时，ADD循环性能下降，Port1被IMUL独占

疑问与核心问题 #

小疑问：dec+jnz宏融合为单µOP，为何在PCM中未观测到其调度至Port0/5？

核心问题：为何双线程均跑IMUL时Port1可共享，而IMUL与ADD共存时Port1不共享？需解释该端口调度与资源竞争机制。

解答 #

核心问题解析 #

1. IMUL的端口绑定特性

IMUL r64, r64是单操作数64位整数乘法指令，在Haswell架构中，这类指令的执行单元仅绑定在Port1——Port0/5虽支持整数加减、逻辑运算，但不具备64位整数乘法的硬件执行资源。因此无论多少个独立IMUL循环，所有µOP都只能排队等待Port1处理，无法分流到其他端口。

2. 超线程下Port1的共享逻辑

Haswell超线程采用资源分时复用机制：当两个线程均执行IMUL时，Port1的执行单元会被两个线程交替占用，每个线程获得约50%的端口带宽。由于IMUL的吞吐量（Haswell Port1支持每周期1个64位乘法µOP）与分时模式匹配，总吞吐量能达到单线程的2倍，因此无性能损失。

3. IMUL与ADD共存时的资源竞争

当超线程中一个线程跑IMUL、另一个跑ADD时，ADD的µOP本可分配到Port0/1/5，但Port1被IMUL独占的原因在于：

• IMUL的µOP属于端口绑定型，只能在Port1执行，调度器会优先为这类指令分配Port1资源，避免其因等待出现严重延迟；
• ADD的µOP属于多端口兼容型，调度器会自动将其分流到Port0/5，而非抢占Port1。若Port0/5被其他操作（如循环分支）占用，ADD的µOP只能等待，最终导致ADD循环性能下降。

小疑问解析 #

dec+jnz的宏融合µOP属于分支类微操作，在Haswell架构中，这类融合分支操作的执行单元绑定在Port6（分支预测单元），而非Port0/5。PCM统计的Port0/5流量为整数运算类µOP，因此无法观测到该融合µOP出现在这两个端口上。

内容的提问来源于stack exchange，提问作者Andrey Dmitriev