为什么将0.1f改为0会使性能下降10倍？
为什么这一点代码，
const float x[16] = { 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6}; const float z[16] = {1.123, 1.234, 1.345, 156.467, 1.578, 1.689, 1.790, 1.812, 1.923, 2.034, 2.145, 2.256, 2.367, 2.478, 2.589, 2.690}; float y[16]; for (int i = 0; i < 16; i++) { y[i] = x[i]; } for (int j = 0; j < 9000000; j++) { for (int i = 0; i < 16; i++) { y[i] *= x[i]; y[i] /= z[i]; y[i] = y[i] + 0.1f; // <-- y[i] = y[i] - 0.1f; // <-- } } 运行速度比以下速度快10倍以上（除非另有说明，相同）？
const float x[16] = { 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6}; const float z[16] = {1.123, 1.234, 1.345, 156.467, 1.578, 1.689, 1.790, 1.812, 1.923, 2.034, 2.145, 2.256, 2.367, 2.478, 2.589, 2.690}; float y[16]; for (int i = 0; i < 16; i++) { y[i] = x[i]; } for (int j = 0; j < 9000000; j++) { for (int i = 0; i < 16; i++) { y[i] *= x[i]; y[i] /= z[i]; y[i] = y[i] + 0; // <-- y[i] = y[i] - 0; // <-- } }
当使用Visual Studio 2010 SP1编译时。 （我还没有用其他编译器testing过。）
欢迎来到非规范化的浮点世界！ 他们可以肆虐性能！
非正规（或低于正常）的数字是一种诡计，可以从浮点数表示中获得非常接近零的额外值。 非规格化浮点运算可能比标准化浮点运算速度慢几十到几百倍 。 这是因为许多处理器不能直接处理它们，必须使用微码来捕获和解决它们。
如果您在10,000次迭代后打印出数字，您将看到它们已经收敛到不同的值，具体取决于是使用0还是0.1 。
以下是在x64上编译的testing代码：
int main() { double start = omp_get_wtime(); const float x[16]={1.1,1.2,1.3,1.4,1.5,1.6,1.7,1.8,1.9,2.0,2.1,2.2,2.3,2.4,2.5,2.6}; const float z[16]={1.123,1.234,1.345,156.467,1.578,1.689,1.790,1.812,1.923,2.034,2.145,2.256,2.367,2.478,2.589,2.690}; float y[16]; for(int i=0;i<16;i++) { y[i]=x[i]; } for(int j=0;j<9000000;j++) { for(int i=0;i<16;i++) { y[i]*=x[i]; y[i]/=z[i]; #ifdef FLOATING y[i]=y[i]+0.1f; y[i]=y[i]-0.1f; #else y[i]=y[i]+0; y[i]=y[i]-0; #endif if (j > 10000) cout << y[i] << " "; } if (j > 10000) cout << endl; } double end = omp_get_wtime(); cout << end - start << endl; system("pause"); return 0; }
输出：
#define FLOATING 1.78814e-007 1.3411e-007 1.04308e-007 0 7.45058e-008 6.70552e-008 6.70552e-008 5.58794e-007 3.05474e-007 2.16067e-007 1.71363e-007 1.49012e-007 1.2666e-007 1.11759e-007 1.04308e-007 1.04308e-007 1.78814e-007 1.3411e-007 1.04308e-007 0 7.45058e-008 6.70552e-008 6.70552e-008 5.58794e-007 3.05474e-007 2.16067e-007 1.71363e-007 1.49012e-007 1.2666e-007 1.11759e-007 1.04308e-007 1.04308e-007 //#define FLOATING 6.30584e-044 3.92364e-044 3.08286e-044 0 1.82169e-044 1.54143e-044 2.10195e-044 2.46842e-029 7.56701e-044 4.06377e-044 3.92364e-044 3.22299e-044 3.08286e-044 2.66247e-044 2.66247e-044 2.24208e-044 6.30584e-044 3.92364e-044 3.08286e-044 0 1.82169e-044 1.54143e-044 2.10195e-044 2.45208e-029 7.56701e-044 4.06377e-044 3.92364e-044 3.22299e-044 3.08286e-044 2.66247e-044 2.66247e-044 2.24208e-044
注意第二次运行的数字非常接近零。
非规范化的数字通常很less，因此大多数处理器不会尝试有效地处理它们。
为了certificate这与非规格化的数字有关，如果我们通过将代码添加到代码的开始来将非规范化为零 ：
_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
然后， 0的版本不再慢10倍，实际上变得更快。 （这要求在启用SSE的情况下编译代码。）
这意味着，而不是使用这些奇怪的低精度几乎为零的值，我们只是舍入到零。
时间：Core i7 920 @ 3.5 GHz：
// Don't flush denormals to zero. 0.1f: 0.564067 0 : 26.7669 // Flush denormals to zero. 0.1f: 0.587117 0 : 0.341406
最后，这与整数或浮点数无关。 0或0.1f被转换/存储到两个循环之外的寄存器中。 所以这对性能没有影响。
使用gcc并将diff应用于生成的程序集只会产生以下差异：
73c68,69 < movss LCPI1_0(%rip), %xmm1 --- > movabsq $0, %rcx > cvtsi2ssq %rcx, %xmm1 81d76 < subss %xmm1, %xmm0
cvtsi2ssq速度确实慢了10倍。
显然， float版本使用从内存加载的XMM寄存器，而int版本使用cvtsi2ssq指令将实际的int值转换为float ，花费了大量的时间。 把-O3传给gcc并没有帮助。 （gcc版本4.2.1。）
（使用double float并不重要，只不过它将cvtsi2ssq变成了cvtsi2sdq 。）
更新
一些额外的testing表明它不一定是cvtsi2ssq指令。 一旦消除（使用int ai=0;float a=ai;并使用a而不是0 ），速度差异保持不变。 所以@Mysticial是正确的，非规范化的花车有所作为。 这可以通过testing0到0.1f之间的值来看到。 上述代码中的转折点大约为0.00000000000000000000000000000001 ，当循环突然花费10倍的时间。
更新<< 1
这个有趣的现象的一个小的可视化：
- 第1列：浮动，每次迭代除以2
- 第2列：这个浮点数的二进制表示
- 第3列：将这个浮点数加1e7次所花费的时间
您可以清楚地看到指数（最后9位）改变到最低值，当非规范化设置英寸此时，简单的加法变得慢了20倍。
0.000000000000000000000000000000000100000004670110: 10111100001101110010000011100000 45 ms 0.000000000000000000000000000000000050000002335055: 10111100001101110010000101100000 43 ms 0.000000000000000000000000000000000025000001167528: 10111100001101110010000001100000 43 ms 0.000000000000000000000000000000000012500000583764: 10111100001101110010000110100000 42 ms 0.000000000000000000000000000000000006250000291882: 10111100001101110010000010100000 48 ms 0.000000000000000000000000000000000003125000145941: 10111100001101110010000100100000 43 ms 0.000000000000000000000000000000000001562500072970: 10111100001101110010000000100000 42 ms 0.000000000000000000000000000000000000781250036485: 10111100001101110010000111000000 42 ms 0.000000000000000000000000000000000000390625018243: 10111100001101110010000011000000 42 ms 0.000000000000000000000000000000000000195312509121: 10111100001101110010000101000000 43 ms 0.000000000000000000000000000000000000097656254561: 10111100001101110010000001000000 42 ms 0.000000000000000000000000000000000000048828127280: 10111100001101110010000110000000 44 ms 0.000000000000000000000000000000000000024414063640: 10111100001101110010000010000000 42 ms 0.000000000000000000000000000000000000012207031820: 10111100001101110010000100000000 42 ms 0.000000000000000000000000000000000000006103515209: 01111000011011100100001000000000 789 ms 0.000000000000000000000000000000000000003051757605: 11110000110111001000010000000000 788 ms 0.000000000000000000000000000000000000001525879503: 00010001101110010000100000000000 788 ms 0.000000000000000000000000000000000000000762939751: 00100011011100100001000000000000 795 ms 0.000000000000000000000000000000000000000381469876: 01000110111001000010000000000000 896 ms 0.000000000000000000000000000000000000000190734938: 10001101110010000100000000000000 813 ms 0.000000000000000000000000000000000000000095366768: 00011011100100001000000000000000 798 ms 0.000000000000000000000000000000000000000047683384: 00110111001000010000000000000000 791 ms 0.000000000000000000000000000000000000000023841692: 01101110010000100000000000000000 802 ms 0.000000000000000000000000000000000000000011920846: 11011100100001000000000000000000 809 ms 0.000000000000000000000000000000000000000005961124: 01111001000010000000000000000000 795 ms 0.000000000000000000000000000000000000000002980562: 11110010000100000000000000000000 835 ms 0.000000000000000000000000000000000000000001490982: 00010100001000000000000000000000 864 ms 0.000000000000000000000000000000000000000000745491: 00101000010000000000000000000000 915 ms 0.000000000000000000000000000000000000000000372745: 01010000100000000000000000000000 918 ms 0.000000000000000000000000000000000000000000186373: 10100001000000000000000000000000 881 ms 0.000000000000000000000000000000000000000000092486: 01000010000000000000000000000000 857 ms 0.000000000000000000000000000000000000000000046243: 10000100000000000000000000000000 861 ms 0.000000000000000000000000000000000000000000022421: 00001000000000000000000000000000 855 ms 0.000000000000000000000000000000000000000000011210: 00010000000000000000000000000000 887 ms 0.000000000000000000000000000000000000000000005605: 00100000000000000000000000000000 799 ms 0.000000000000000000000000000000000000000000002803: 01000000000000000000000000000000 828 ms 0.000000000000000000000000000000000000000000001401: 10000000000000000000000000000000 815 ms 0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 42 ms 0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 42 ms 0.000000000000000000000000000000000000000000000000: 00000000000000000000000000000000 44 ms
关于ARM的等价讨论可以在Stack Overflow问题中findObjective-C中的非规范化浮点？ 。
这是由于非规范化的浮点使用。 如何摆脱它和性能的损失？ 在互联网寻找杀死非正规数字的方法之后，似乎还没有“最好”的方法来做到这一点。 我发现了这三种方法可能在不同的环境下效果最好：
-
在一些GCC环境中可能不起作用：
// Requires #include <fenv.h> fesetenv(FE_DFL_DISABLE_SSE_DENORMS_ENV); -
可能无法在一些Visual Studio环境中工作： 1
// Requires #include <xmmintrin.h> _mm_setcsr( _mm_getcsr() | (1<<15) | (1<<6) ); // Does both FTZ and DAZ bits. You can also use just hex value 0x8040 to do both. // You might also want to use the underflow mask (1<<11) -
似乎在GCC和Visual Studio中工作：
// Requires #include <xmmintrin.h> // Requires #include <pmmintrin.h> _MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON); _MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON); -
英特尔编译器可以select在现代英特尔CPU上默认禁用非正常模式。 更多细节在这里
-
编译器开关。
-ffast-math，-msse或者-mfpmath=sse将会禁用非-mfpmath=sse则-mfpmath=sse并且使其他一些事情更快，但不幸的是还会做很多其他的可能会破坏你的代码的近似值。 仔细testing！ Visual Studio编译器的快速math的等价物是/fp:fast但是我还没有能够确认这是否也禁用非规范化。 1
在海湾合作委员会，您可以启用FTZ和DAZ：
#include <xmmintrin.h> #define FTZ 1 #define DAZ 1 void enableFtzDaz() { int mxcsr = _mm_getcsr (); if (FTZ) { mxcsr |= (1<<15) | (1<<11); } if (DAZ) { mxcsr |= (1<<6); } _mm_setcsr (mxcsr); }
也使用gcc开关：-msse -mfpmath = sse
（相当于Carl Hetherington [1]）
