为什么这个循环每次迭代需要 1.32 个周期

Question

考虑这个简单的 C++ 函数来计算数组的prefix sum：

void prefix_sum(const uint32_t* input, uint32_t* output, size_t size) {
    uint32_t total = 0;
    for (size_t i = 0; i < size; i++) {
        total += input[i];
        output[i] = total;
    }
}

循环 compiles 到 gcc 5.5 上的以下程序集：

.L5:
        add     ecx, DWORD PTR [rdi+rax*4]
        mov     DWORD PTR [rsi+rax*4], ecx
        add     rax, 1
        cmp     rdx, rax
        jne     .L5

我没有看到任何可以阻止它在每次迭代中运行 1 个周期的东西，但我始终在 Skylake i7-6700HQ 上以 1.32 (+/- 0.01) 周期/迭代来测量它，当它针对 8 KiB 运行时输入/输出数组。

循环在 uop 缓存之外提供服务，不会跨越任何 uop 缓存边界，性能计数器也不会指示任何前端瓶颈。

它是 4 fused uops¹，这个 CPU 可以维持 4 fused ops/cycle。

有通过ecx和rax的依赖链，每个1个周期，但是这些add uop可以去4个ALU端口中的任何一个，所以看起来不太可能发生冲突。融合的cmp 需要转到 p6，这更令人担忧，但我只测量到 p6 的 1.1 uops/迭代。这可以解释每次迭代 1.1 个周期，但不是 1.4 个。如果我以 2 倍端口压力展开循环，则要低得多：所有 p0156 小于 0.7 微秒，但每次迭代 1.3 个周期时性能仍然出乎意料地慢。

每次迭代有一个存储，但我们可以每个周期进行一个存储。

每次迭代有一个负载，但我们每个周期可以做两个。

每个周期有两个复杂的 AGU，但我们每个周期可以做两个。

这里的瓶颈是什么？

有趣的是，我尝试了 Ithermal performance predictor，它几乎完全正确：估计 1.314 个周期与我测量的 1.32 个周期。

---

¹ 我通过 uops_issued.any 计数器确认了宏和微融合融合，该计数器在融合域中计数，并在此循环中每次迭代读取 4.0 个融合微指令。

Answer 1

我刚刚使用了有关 Ithermal 性能预测器的说明，我可能已经发现了问题。 试试看

add     ecx, DWORD PTR [rdi]
mov     DWORD PTR [rsi], ecx
add     rax, 1
cmp     rdx, rax

每次迭代提供惊人的 1.131 个周期。在每次迭代中添加 0 进行交叉检查（再次给出 1.3 个周期）消除了存储/加载瓶颈的可能性。 这最终表明寻址模式存在问题。

（编者注：这是一个有趣的实验数据，与我在 Agner Fog 博客上的帖子中发布的内容相匹配，下面的猜测被误解了。更简单的寻址模式可以加快速度，即使没有分层。）

---

（编者注：这部分是错误的：我们从问题中知道没有未分层，因为uops_issued.any = 4 每次迭代。）

我认为在索引寻址的情况下，您的 CPU 会取消您的 add/mov 分层。这种行为在几个架构（SnB、SKL、HWL）中都有很好的记录，有人在描述整个事情的 stackoverflow 上做得很好：https://stackoverflow.com/a/31027695/1925289 简而言之：如果涉及的寄存器和标志过多，则融合的操作 (DSB) 会变得未分层 (IDQ)，从而有效地再次取消融合。

其他资源：

• 广告融合限制：https://www.agner.org/optimize/blog/read.php?i=415#852

• 不层压：https://easyperf.net/blog/2018/02/15/MicroFusion-in-Intel-CPUs#unlamination-example-1