将乘法强度缩减为循环携带加法后代码执行速度反而变慢的原因探究

这真是个典型的“反直觉”优化案例！咱们来拆解一下为什么你按照Agner Fog的思路改完代码，性能反而掉了一半——核心问题出在现代CPU的指令级并行（ILP）和SIMD向量化能力上，而不是指令数量的多少。

1. 原版本的隐藏优势：并行性与SIMD #

你看到原版本有3次乘法+2次加法，但GCC在-O3下做了两件关键优化：

• 自动向量化：原代码里的A*i*i + B*i + C是典型的“数据并行”计算——每个data[i]的计算完全独立于其他元素。GCC会把这个循环转换成SIMD指令（比如你看到的mulpd，即打包双精度乘法），一次能处理2个甚至更多data元素。
• 乱序执行与多执行单元：现代CPU有多个浮点乘法器和加法器，而且支持乱序执行。原代码中每个迭代的计算没有数据依赖（data[i]不依赖data[i-1]），CPU可以同时启动多个迭代的乘法、加法操作，把指令延迟完全隐藏掉。哪怕乘法指令本身延迟高，但通过并行执行，吞吐量反而很高。

2. 手动优化版本的致命缺陷：串行依赖链 #

你的优化版本把计算改成了基于上一次结果的增量累加，看似减少了乘法，但却引入了强数据依赖：

data[i] = Y;
Y += Z;  // Y依赖上一次的Y和Z
Z += A2; // Z依赖上一次的Z

每一步的Y必须等上一步的Y和Z计算完，Z又必须等上一步的Z计算完。这形成了一条无法打断的串行依赖链，CPU的乱序执行能力完全没用武之地——它只能一步一步地执行，哪怕加法延迟只有3-4个周期，整个循环的速度被这条链死死卡住，吞吐量直接降到了“每个周期处理一个元素”的下限。

更糟的是，这种累加模式破坏了编译器的自动向量化机会——因为每个元素的计算依赖前一个，SIMD没法并行处理多个元素，所以你看到的汇编只有addsd（标量加法），一次只能处理一个data元素，吞吐量直接砍半。

3. 验证你的猜想：禁用SIMD试试 #

你可以做个小实验，用-fno-tree-vectorize参数编译两个版本，强制GCC关闭向量优化：

gcc -O3 -fno-tree-vectorize -o 1_novec ./code1.c
gcc -O3 -fno-tree-vectorize -o 2_novec ./code2.c

这时候原版本没法用SIMD并行处理，只能串行计算乘法，你会发现优化版本的速度反而会超过原版本——这就印证了之前的结论：原版本的性能优势来自SIMD和并行执行，而你的手动优化在没有SIMD的场景下才有用。

总结 #

Agner Fog的优化思路是针对更老的、缺乏SIMD和乱序执行能力的CPU设计的。现代CPU的自动优化（向量化、循环展开、乱序执行）已经能很好地处理这类独立元素的计算，你的手动优化反而引入了串行依赖，还破坏了编译器的向量化机会，最终导致性能下降。

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