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

Question

考虑这个简单的C++函数来计算数组的前缀和：

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

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

它是4个融合的UOP¹，这个CPU可以支持4个融合的OPs/周期。

有通过ECX和RAX携带的依赖链，每个都是一个循环，但是这些AddUOP可以到4个ALU端口中的任何一个，所以似乎不太可能冲突。融合的CMP需要转到p6，这是一个更令人担忧的问题，但我只测量到p6的1.1 UOPS/迭代。这将解释每次迭代1.1个循环，但不是1.4个循环。如果我将循环展开2倍，端口压力会低得多：对所有p0156来说不到0.7uops，但性能仍然出乎意料地慢，每次迭代1.3个循环。

每个迭代有一个存储，但我们可以每个循环做一个存储。

有趣的是，我尝试了Ithermal性能预测器，它几乎完全正确：估计了1.314个循环，而我的测量值是1.32个。

¹我通过uops_subsced.任何计数器确认了宏和微融合融合，该计数器在融合域中计数，并在此循环的每次迭代中读取4.0个融合的uops。

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博客上发布的帖子相匹配，下面的猜测误解了这一点。更简单的寻址模式可以加快它的速度，即使没有解层。）

>

AD融合限制:https://www.agner.org/optimize/blog/read.php?i=415852

解层:https://easyperf.net/blog/2018/02/15/MicroFusion-in-Intel-CPUs#解层-示例-1