关于C++：为什么改变0.1F到0减慢性能10X？

Why does changing 0.1f to 0 slow down performance by 10x?

为什么这段代码，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

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倍以上(相同，除非另有说明)？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

使用Visual Studio 2010 SP1编译时。(我没有用其他编译器进行测试。)

相关讨论

欢迎来到非规范化浮点的世界！他们会破坏表演！！！！

非正态(或次正态)数是一种从浮点表示中得到一些非常接近零的额外值的方法。非规范化浮点上的操作比规范化浮点上的操作慢几十到数百倍。这是因为许多处理器不能直接处理它们，必须使用微码捕获和解析它们。

如果您在10000次迭代之后打印出这些数字，您将看到它们已经收敛到不同的值，这取决于使用的是0还是0.1。

以下是在x64上编译的测试代码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

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;
}

输出：

1
2
3
4
5
6
7

#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

请注意，在第二次运行中，数字非常接近于零。

非规范化的数字通常很少，因此大多数处理器不尝试有效地处理它们。

为了证明这与非规范化的数字有关，如果我们通过在代码开头添加此值将非规范化值刷新为零：

1	_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);

那么，带有0的版本不再慢10倍，实际上变得更快了。(这要求在启用SSE的情况下编译代码。)

这意味着，我们不使用这些奇怪的低精度几乎为零的值，而是将其舍入为零。

计时：核心I7 [email protected] GHz：

1
2
3
4
5
6
7

// 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被转换/存储到两个循环之外的寄存器中。所以这对性能没有影响。

相关讨论

生成代码的唯一区别是快速版本的fld qword ptr [__real@3fb99999a0000000 (11820E8h)]和循环开始时的fldz，至少对于我在VS2010中构建的代码是这样的。
@德瓦尔，没错。代码几乎没有区别。它是一个影响数字是否非正规化的值。
它特别有趣，因为改变事物的顺序基本上是x += 0.1; x -= 0.1，也可以写成(x + 0.1) - 0.1。有人注意到缺乏关联性。(当然，这样的改写可能会改变结果，这是因为C++允许将中间结果保持在扩展精度。)
我仍然觉得有点奇怪，默认情况下编译器没有完全优化"+0"。如果他把"+0.0f"，会发生这种情况吗？
@这是一个很好的问题。现在我看了一下这个组件，就连+ 0.0f都没有得到优化。如果我不得不猜测的话，可能是+ 0.0f会产生副作用，如果y[i]恰好是NaN或其他什么信号……但我可能错了。
如果去掉加法/减法，性能如何？如果它仍然昂贵，我不会感到惊讶，因为乘法/除法对于子规范来说更昂贵。
@codeinchao是的，它仍然很昂贵，但是与26.7669相比，只有13.3208秒。这些数字仍然不正常。但我想，因为只有一半的手术量，手术速度是原来的两倍。我有点惊讶的是，非正规除法的运行速度似乎和非正规加减法一样慢。
所以…当涉及零值浮点时，注重性能的程序员应该做什么？
@Chriszuma，问题不是这里的零值，而是接近零的非正规化。如果您不需要对极小的数字进行算术运算，那么将非规范化值刷新为零。如果您确实需要处理这么小的数字，那么在大多数平台上使用双打可能会更快。
在许多情况下，double仍会遇到相同的问题，只是数值大小不同。对于音频应用程序(以及其他可以承受在这里或那里丢失1E-38的应用程序)，刷新到零是很好的，但我认为不适用于X87。如果没有ftz，音频应用程序通常的解决方法是将非常低的振幅(不可听)的直流或方波信号注入到远离非规范性的抖动数字中。
@RussellBorogove：我想知道是否有硬件设计包括一种强制LSB截断接近零的值的模式，以避免奇怪地处理非规范化值的要求？
大约在1998/1999年，我曾为JeskolaBuzz玩过插件。为此，我从奔腾166mmx升级到了奔腾3 500mhz。当时的一个传说是，当值衰减非常接近零时，"下溢异常"会导致严重的减速——即使中断/陷阱/任何禁用的东西，它仍然会导致严重的减速。解决方法是强制接近零值为零。这个传说是错的吗？这实际上是一个非规范化的浮动问题吗？
抛开性能不谈，为什么y[i] = (y[i] + 0.1f) - 0.1f甚至会导致与y[i] = (y[i] + 0) - 0不同的价值？
@Isaac是因为当y[i]显著小于0.1时，加上它会导致精度损失，因为数字中最重要的数字会变高。
这带来了一个奇怪的问题：您是否有硬件供应商进行有效非正规计算的例子？
@supercat，如果我理解的对，那就是flush to zero的本质。
@史蒂文314，传说是，比方说，不精确。IEEE754为非规格化的数字定义了一个"下溢异常"；如果硬件不能准确处理非规格化，则应该引发一个异常，但X87会缓慢地处理非规格化，而不会引发异常。
@根据Agner Fog的说法，英特尔新推出的Sandy Bridge微体系结构nraynaud可以非常有效地处理非正常情况。agner.org/optimize/blog/read.php？i＝142
@Russellborogove：在一个齐平到零的系统中，我理解这个术语，最小的和第二个最小的正数之间的差是最小数的量级的一个很小的分数。向系统中添加非正规化会减少最小数字的大小，以匹配数字之间最小的可测量数据引用。我的建议是增加数字之间的最小差异以匹配最小的标准化数字。这将确保如果x！=y，x+(y-x)和y之间的差值小于x和y之间的差值。
@RussellBorogove：虽然处理非规范化需要增加处理浮动的所有方面的复杂性，但是限制较低位的精度(实际上应该通过舍入而不是截断来完成)只需要在一个地方额外的逻辑。不是总是四舍五入到一个尾数LSB，有时会四舍五入到一个更粗的水平。
这与OBJ-C有什么关系吗？我想答案应该是，"可能，你自己来做基准测试吧？"或者，由于某种原因，这在目标C中不适用吗…？
@雅尔：它更像是一个CPU而不是一个语言问题，所以它可能与x86上的obj-c有关。(iPhone的ARMV7似乎不支持非规范化的浮动，至少在默认的运行时/构建设置下是如此)
@Russellborogove我这里有一个Sandy Bridge CPU(i7-2620m)，我不能观察到效率-我看到GCC 4.6.1和g++ -O3 -march=corei7-avx 9314534.cpp的速度下降了22倍。我尝试过的所有编译器选项都有类似的结果。
@我在2600公里的时候也注意到了。它确实与阿格涅·雾所说的相反。我最初怀疑这个部门对非正规化仍然很敏感。但是去掉除法(并乘以EDOCX1的倒数(1))会导致96x的速度减慢到非正规化！！！！
@神秘的所有我的搜索结果的SNB和非规范化的FP导致回到一个Agner雾文章。我还尝试了各种编译器选项(例如-mfpmath=…，-mfast math)，从上一条注释开始，我找不到任何位置1-d浮动不能使它更快，2)没有-d浮动的结果是正确的。因此，阿法克斯的说法是假的。
有趣。您在X87、SSE或两者上看到这个吗？
@Russellborogove i在32位模式下测试了x87，在64位模式下测试了sse。同样的结果。无论有无除法，都会出现严重的非正规化。约25倍(带分区)和100倍(不带分区)。
不知道那是怎么回事。如果你想解决的话，你可能会碰到雾。
@Russellborogove我只做了64位，我看到387(50倍)和SSE(14.5倍)的速度都有所放缓，两倍的浮点数相似。
@MVDS只是为了确认这不是一个单一的编译器的事情，我可以看到Delphi同样的减速。
投反对票的人愿意发表评论吗？
@S73V3R:0.f不能被优化掉，因为浮点值为负0，加+0.f到-.0f的结果是+0.f，所以加0.f不是一个标识操作，不能被优化掉。
FOG声称，由于Sandy Bridge似乎是错误的，非规范化不会增加延迟。也许因为天湖是对的，但哈斯韦尔肯定不是。
@HDL Fog最初声称Sandy Bridge没有异常减速。但在这个问题流行之后，我相信有人通知他，他重新测试了一下。判决是，加减不减速。但乘法运算仍然是一个巨大的减速。
@神秘井，他仍然声称"非正规数字，Nan’s和Infinity不会增加延迟。"2014年12月，Sandy Bridge、Ivy Bridge和Haswell的"说明表"pdf。
@EricPostischil优化甚至不是问题。即使完全删除了添加项，问题也会出现。正是由于除法，这些数字才被非正规化。
@pi：您要回复的注释没有解决这里发布的原始问题，在这个问题中，低于正常值的数字会导致性能下降。这是关于S73V3R提出的一个问题，即为什么在优化过程中不删除添加0。

使用gcc并对生成的程序集应用diff只会产生这种差异：

1
2
3
4
5
6
7

73c68,69
< movss LCPI1_0(%rip), %xmm1
---
> movabsq $0, %rcx
> cvtsi2ssq %rcx, %xmm1
81d76
< subss %xmm1, %xmm0

cvtsi2ssq一号确实慢了10倍。

显然，float版本使用从内存加载的xmm寄存器，而int版本使用cvtsi2ssq指令将实际的int值0转换为float，这需要很多时间。把-O3交给GCC没有帮助。(GCC第4.2.1版)

(使用double而不是float并不重要，只是它将cvtsi2ssq改为cvtsi2sdq。)

更新

一些额外的测试表明它不一定是cvtsi2ssq指令。一旦消除(使用int ai=0;float a=ai;和使用a而不是0时，速度差仍然存在。所以@mysticial是对的，非规范化的浮点数起作用。这可以通过测试0和0.1f之间的值来看出。上面代码中的转折点大约在0.00000000000000000000000000000001处，这时循环的长度突然增加了10倍。

更新<＜1

这一有趣现象的一个小形象化：

第1列：一个浮点，每次迭代除以2
第2列：这个浮点的二进制表示法
第3列：将此浮点数相加所用的时间为1e7次

当非规范化设置时，您可以清楚地看到指数(最后9位)更改为其最低值。在这一点上，简单的添加会慢20倍。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

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的等效讨论可以在堆栈溢出问题中找到，目标C中的非规范化浮点？.

相关讨论

这是由于非规范化的浮点使用。如何摆脱它和绩效惩罚？在互联网上搜寻杀死非正常数字的方法之后，似乎还没有"最好"的方法来做到这一点。我发现这三种方法在不同的环境中效果最好：

可能无法在某些GCC环境中工作：

1
2
// Requires #include <fenv.h>
fesetenv(FE_DFL_DISABLE_SSE_DENORMS_ENV);

可能无法在某些Visual Studio环境中工作：1

1
2
3
4

// 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中都有效：

1
2
3
4
// 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);
在现代Intel CPU上，"英特尔编译器"有默认禁用非规范化的选项。此处提供更多详细信息
编译器开关。-ffast-math、-msse或-mfpmath=sse将禁用非规范化并使其他一些事情更快，但不幸的是，也会进行许多其他可能破坏代码的近似。仔细测试！与Visual Studio编译器的快速数学等价的是/fp:fast，但我还无法确认这是否也会禁用非规范化。1

相关讨论

在GCC中，您可以通过以下方式启用FTZ和DAZ：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#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

(对应于卡尔·赫瑟林顿的学分[1])

[1]http://carlh.net/plugins/denormals.php

相关讨论

丹·尼利的评论应该扩大到一个答案：

它不是非正规化的零常数0.0f，也不是导致速度减慢的，而是每次循环迭代接近零的值。随着它们越来越接近于零，它们需要更精确的表示，并变得非规范化。这些是y[i]值。(它们接近于零，因为所有i的x[i]/z[i]小于1.0。)

代码的慢速版本和快速版本之间的关键区别是语句y[i] = y[i] + 0.1f;。一旦该行执行循环的每次迭代，浮点中的额外精度就会丢失，不再需要表示该精度所需的非规范化。之后，y[i]上的浮点操作仍然很快，因为它们没有非规范化。

为什么添加0.1f时会失去额外的精度？因为浮点数只有这么多有效数字。假设您有足够的存储空间来存储三个有效数字，那么至少对于本例的float格式，0.00001 = 1e-5和0.00001 + 0.1 = 0.1，因为它没有空间来存储0.10001中的最低有效位。

简言之，你可能会认为，江户记(14)不是不允许的。

神秘主义者也这么说：浮动的内容很重要，而不仅仅是汇编代码。