为何简单循环中CPU FLOPs性能无法达到其标称GHz主频？

你对CPU“1周期完成1次运算”的理解混淆了指令延迟和指令吞吐两个完全不同的概念，再加上测试代码本身的设计问题，才会出现和预期偏差极大的测试结果，这一现象和译码瓶颈、SIMD强制要求没有直接关系。

1. 串行数据依赖是短循环测试的核心瓶颈 #

你的第一版测试代码如下：

float sum = 0;    
for (int i = 0; i < 1000000; i+=1) {
    sum = sum * 1 + 1;
}

所有迭代完全串在一条依赖链上：第N次迭代的输入sum必须等第N-1次迭代的计算结果完全写回寄存器才能开始执行，乱序执行、流水线并行根本没有发挥空间。

现代CPU不管是Intel x86架构还是苹果A系列的ARM架构，单精度a*b+c的运算基本都会被编译器优化为单条FMA（融合乘加）指令，两个核心参数的差异是你预期偏差的来源：

• 这类指令的峰值吞吐确实可以达到1条/周期——意思是如果指令之间没有依赖，流水线每个周期都能接收一条新的FMA指令，满负载下平均每周期完成1次乘加运算。
• 但这类指令的延迟普遍在3_{4个周期——意思是单条FMA从发射到拿到最终结果，需要3}4个时钟周期的流水线处理时间。

在完全串行依赖的场景下，你每3_{4个周期才能启动1次新的迭代，再叠加循环计数器自增、分支判断的固定开销（约2}3个周期/迭代），刚好6个左右周期完成1次迭代，和你在Intel、移动端设备上测到的约1/6主频性能完全吻合。

2. 手动展开去掉循环反而更慢的原因 #

你写的10万次重复直线代码性能暴跌，和运算本身无关，纯粹是代码设计不符合CPU缓存特性：

• 单条FMA指令的长度是4字节，10万条重复指令光机器码就占400KB，远大于CPU核心L1指令缓存的典型容量（32KB），CPU需要不断从L2甚至L3缓存取指令，取指带宽直接下降数倍。
• 固定跳转的短循环会被CPU的循环流检测器直接识别，指令会被缓存到译码后的微指令缓存里，根本不需要重复译码；而超长的直线代码没有循环分支，指令预取器的预取效率远低于循环场景，流水线会因为等待指令取指出现大量空泡，性能自然会暴跌。

3. 常见认知误区澄清 #

• 不存在“必须用SIMD才能跑满主频性能”的说法：CPU标称的4.2GHz是核心时钟周期频率，不是SIMD运算的专属频率。只要打破数据依赖，哪怕只用标量指令，也能摸到每周期1次乘加的峰值吞吐。
• 指令译码不是该测试场景的瓶颈：短循环的代码体积极小，会被常驻在微指令缓存中，现代CPU每周期4~6条指令的译码带宽完全可以覆盖循环里的少量指令开销，根本不会卡在译码阶段。

4. 性能验证方法 #

不需要使用SIMD，只要把串行依赖链拆成多个独立的累加变量，让CPU可以并行发射多条无依赖的FMA指令填满流水线，就能摸到标量运算的吞吐上限，参考代码：

float sum0 = 0, sum1 = 0, sum2 = 0, sum3 = 0;
for (int i = 0; i < 1000000; i += 4) {
    sum0 = sum0 * 1 + 1;
    sum1 = sum1 * 1 + 1;
    sum2 = sum2 * 1 + 1;
    sum3 = sum3 * 1 + 1;
}
float total = sum0 + sum1 + sum2 + sum3;

四个sum变量的计算完全独立，没有数据依赖，CPU可以同时在流水线上处理4条不同的FMA指令，刚好覆盖FMA的4周期延迟，做到平均每周期完成1次乘加运算，性能会直接提升到接近主频对应的预期水平。如果开编译器最高优化等级，编译器还会自动做循环展开、SIMD向量化，性能还能再提升数倍。

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