一条指令优化引发的血案，性能狂掉50%，clang使用-ffast-math选项后变傻了
//www.cnblogs.com/bbqzsl/p/15510377.html
近期在做优化时，对一些函数分别在不同编译平台上进行bench测试。发现了不少问题。
现在拿其中一个问题来分享。
1 typedef float MAFloat; 2 3 MAFloat sma(const MAFloat* seq, const int cnt, const int N, const int M) 4 { 5 const MAFloat C1 = (MAFloat)M/N; 6 const MAFloat C2 = (MAFloat)(N-M)/N; 7 MAFloat result = 0.f; 8 int total = cnt; 9 10 #pragma nounroll 11 for (int i = 0; i < total; ++i) 12 { 13 result = result * C2 + seq[i] * C1; 14 } 15 16 return result; 17 }
测试代码很简单，只一个循环，循环内只做了算术运算，汇编代码也很容易。
测试平台包括：
win10：平台，vc120，gcc10，clang11
centos8：平台，gcc8，gcc10，clang11
vc：使用选项 /arch:sse2 /O2，并且win32
gcc：使用选项 -ffast-math -O2 -m32
clang：使用选项 -ffast-math -O2 -m32
数组长度为 28884 = 7221 * 4；
cpu 是 core i5，3.5Ghz
测试结果：
win10：平台，vc120 (0.06x ms)，gcc10 (0.06x ms)，clang11 (0.09x ms)
centos8：平台，gcc8 (0.06x ms)，gcc10 (0.06x ms)，clang11 (0.09x ms)
不论在win10还是centos8平台上，clang编译的代码的性能居然比vc或gcc编译的代码性能差了50%。
现在我们来对比gcc10与clang11产出汇编代码
## gcc .L149: movss (%edx,%eax,4), %xmm1 # xmm1 = seq[i] mulss %xmm3, %xmm0 # xmm0 = result * C2 addl $1, %eax # mulss %xmm2, %xmm1 # xmm1 = seq[i] * C1 addss %xmm1, %xmm0 # result = xmm0 + xmm1 cmpl %ecx, %eax jl .L149 # next loop ## clang LBB7_3: # =>This Inner Loop Header: Depth=1 movss (%eax,%edx,4), %xmm4 # xmm4 = mem[0],zero,zero,zero mulss %xmm1, %xmm3 # incl %edx cmpl %ecx, %edx mulss %xmm0, %xmm4 addss %xmm4, %xmm3 mulss %xmm2, %xmm3 # xmm2 = 1/N; jl LBB7_3
gcc生成的汇编代码一共7条指令，clang生成的汇编代码一共8条指令多出了一条mulss。
clang不知什么原因自作聪明将
result * C2 + seq[i] * C1;
优化成
(1/N) * (result * (N-M) + seq[i] * M);
即使多出一条mulss指令，性能也不至于差了50%，就像7条指令与10.5条指令的差距。
现在来分析
我的机器使用i5 3.5Ghz， 1ns可以运行3.5指令周期。
数组长度为28884，即执行循环代码28884次
运行时间为 28884 * (循环体指令周期）/ 3.5
我现在粗略地将每条指令周期看作是1，gcc生成的代码运行时间粗略地为 28884 * 7 / 3.5 = 57768ns，与测试结果在0.06ms基本相当。用同样的方法估算，clang生成的代码运行时间粗略地为 28884 * 8 / 3.5 = 66020ns。
但是不同的指令，执行不同数量的微指令(uop)，也就是延迟，mulss为4或5，addss为3，上面汇编代码的其它指令各为1。
mulss %xmm2, %xmm1 # xmm1 = seq[i] * C1
addss %xmm1, %xmm0 # result = xmm0 + xmm1
在上面两条指令，addss 依赖 mulss 的结果于 %xmm1，也就是说addss 必须在mulss开始执行后延迟4或5个周期才能执行。由于cpu的乱序机制，这时候延迟的周期数内可以在其他ALU执行其它指令。所以gcc生成的汇编代码的情况可以看作没有指令周期的损失。
再来看clang生成的汇编代码
mulss %xmm0, %xmm4 addss %xmm4, %xmm3 mulss %xmm2, %xmm3 # xmm2 = 1/N;
addss 依赖 mulss 的结果于 %xmm4，然后mulss 依赖 addss 的结果于 %xmm3，这里我们将第一个依赖等同于gcc汇编中的那个依赖，那么下一个依赖的3个周期就必须等待，一次循环一共才8条指令，两个依赖的延迟合计就8个指令周期，乱序也就没有指令可以执行，所以就硬生生多出3或4个指令周期等待。
运行时间一下子就变成了 28884 * (8+3) / 3.5 = 90778ns。
估算的结果与测试的结果基本上吻合。
有兴趣的朋友可以到godblot上测试汇编，一旦让clang使用-ffast-math选项，编译发生这一出傻事。
