这个question展示了一个非常有趣的现象：denormalized浮动使代码减慢超过一个数量级。
这种行为在accepted answer中得到了很好的解释。但是，有一条评论，目前有153条评论，我找不到满意的答案：
为什么编译器在这种情况下不会降低+/- 0？ - 迈克尔多根
旁注：我的印象是0f是/必须是完全可表示的（此外 - 它的二进制表示必须全为零），但在c11标准中找不到这样的声明。证明这一点的引用，或反驳这一主张的论点，将是最受欢迎的。无论如何，迈克尔的问题是这里的主要问题。
实现可以给零和不是浮点数（例如无穷大和NaN）的值作为符号或者可以使它们保持未签名。
编译器无法消除浮点正零的添加，因为它不是标识操作。按IEEE 754规则，加+0的结果。到-0。不是-0。;它是+0。
编译器可以消除+0的减法。或者添加-0。因为那些是身份操作。
例如，当我编译它时：
double foo(double x) { return x + 0.; }
使用Apple GNU C 4.2.1在Intel Mac上使用-O3，生成的汇编代码包含addsd LC0(%rip), %xmm0。当我编译这个：
double foo(double x) { return x - 0.; }
没有添加指令;程序集只返回其输入。
因此，原始问题中的代码可能包含此语句的添加指令：
y[i] = y[i] + 0;
但不包含此声明的说明：
y[i] = y[i] - 0;
但是，第一个语句涉及y[i]中具有次正规值的算术，因此足以减慢程序的速度。
不是正常化的零常数0.0f，它是循环的每次迭代接近零的值。随着它们越来越接近零，它们需要更高的精度来表示，因此非规范化。在original question，这些是y[i]值。
代码的慢速和快速版本之间的关键区别是语句y[i] = y[i] + 0.1f;。执行此行后，浮点数中的额外精度将丢失，并且不再需要表示该精度所需的非规范化。之后，y[i]上的浮点运算仍然很快，因为它们没有非规范化。
添加0.1f时，为什么额外的精度会丢失？因为浮点数只有这么多有效数字。假设您有三个有效数字的足够存储空间，然后是0.00001 = 1e-5和0.00001 + 0.1 = 0.1，至少对于此示例浮点格式，因为它没有空间存储0.10001中的最低有效位。