C语言循环数组访问远慢于变量的性能差异底层原理问询

1. 核心瓶颈：循环携带依赖链长度差异 #

两组测试的性能差距本质是循环迭代的串行依赖链长度不同，这是CPU乱序执行也无法突破的硬件限制：

• Test1的迭代依赖链极短：每次迭代仅需等待上一轮的i计算完成，即可直接执行i += shift，shift为固定寄存器存储的变量，整条依赖链仅包含1个整数加法操作，在酷睿i9架构下 latency 为1周期。
• Test2的迭代依赖链是完全串行的长链路，每轮迭代必须按顺序执行三个无法重叠的操作：
  • 用上一轮计算完成的i值读取内存str[i]，即便L1缓存命中，酷睿i9的整数load操作latency为4~5周期
  • 用读取到的str[i]作为下标查询shifts数组，即便数组长度仅为2，该次load操作也需要1~2周期
  • 将查询到的步长值加到i上完成更新，加法操作1周期
    整条依赖链总 latency 达到6_{8周期，是Test1的6}8倍，和你实测的数倍性能差距完全吻合。

2. 其他排除项的验证 #

你预先排除的影响因素确实不会成为核心瓶颈：

• shifts数组长度仅为2/8，必然常驻L1缓存，不会出现缓存miss导致的额外延迟，你排除缓存影响的判断是正确的
• 两组测试的分支预测准确率、比较次数完全一致，循环跳转的开销两边均等，不会产生差异
• 即便关闭优化（-O0）或开启最高优化（-O3），循环携带的串行依赖逻辑不会被编译器修改，因此不同优化等级下性能差异始终存在

3. 可验证的指标 #

你可以通过Mac平台的Instruments性能计数器验证该结论：Test2的每指令周期数(CPI)会是Test1的数倍，该指标直接反映了CPU流水线因依赖等待产生的停顿占比。

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