作者：MS 转自：enet
C++ 优化编译器不仅能够将源代码转换为机器码，而且能够对机器指令进行适当的排列以便改善性 能和/或减小大小。遗憾的是，许多常用的优化在应用于浮点计算时未必安全。在下面的求和算法 [1] 中，可以看到这方面的一个恰当的示例：
float KahanSum( const float A[], int n )
{
float sum=0, C=0, Y, T;
for (int i=0; i {
Y = A[i] - C;
T = sum + Y;
C = T - sum - Y;
sum = T;
}
return sum;
}
该函数将数组向量 A 中的 n 个浮点值相加。在循环体中，算法计算 一个“修正”值，然后将其应用于求和的下一步。与简单的求和相比，该方法大大减小了累积性舍入 误差，同时保持了 O(n) 时间复杂性。
一个不完善的 C++ 编译器可能假设浮点算法遵循与实数算法相同的代数规则。这样的编译器可能 继而错误地断定
C = T - sum - Y ==> (sum+Y)-sum-Y ==> 0;
也就是说，C 得到的值总是常量零。如果随后将该常量值传播到后续表达式中，循环体将化简为简 单的求和。更准确地说，就是
Y = A[i] - C ==> Y = A[i]
T = sum + Y ==> T = sum + A[i]
sum = T ==> sum = sum + A[i]
因此，对于不完善的编译器而言，KahanSum 函数的逻辑转换将是：
float KahanSum( const float A[], int n )
{
float sum=0; // C, Y & T are now unused
for (int i=0; i sum = sum + A[i];
return sum;
}
尽管转换后的算法更快，但它根本没有准确表达程序员的意图。精心设计的误差修正已经 被完全消除，只剩下一个具有所有其关联误差的简单的直接求和算法。
当然，完善的 C++ 编译器知道实数算法的代数规则通常并不适用于浮点算法。然而，即使是完善 的 C++ 编译器，也可能错误地解释程序员的意图。
考虑一种常见的优化措施，它试图在寄存器中存放尽可能多的值（称为“登记”值）。在 KahanSum 示例中，这一优化可能试图登记变量 C、Y 和 T，因为这些变量仅在循环体内使用。如果寄存器精度为 52 位（双精度）而不是 23 位（单精度），这一优化可以有效地将 C、Y 和 T 的类 型提升为 double。如果没有以同样的方式登记 sum 变量，则它仍将编 码为单精度。这会将 KahanSum 的语义转换为下面的语义
float KahanSum( const float A[], int n )
{
float sum=0;
double C=0, Y, T; // now held in-register
for (int i=0; i {
Y = A[i] - C;
T = sum + Y;
C = T - sum - Y;
sum = (float) T;
}
return sum;
}
尽管现在 Y、T 和 C 以更高的精度进行计算，但新的编码可能产生精确性较低的结果，具体取决 于 A[] 中的值。因而，即使看起来无害的优化也可能具有消极的后果。
这些种类的优化问题并不局限于“棘手”的浮点代码。即使是简单的浮点算法，在经过错误的优化 后也可能失败。考虑一个简单的直接求和算法：
float Sum( const float A[], int n )
{
float sum=0;
for (int i=0; i sum = sum + A[i];
return sum;
}
因为一些浮点单元能够同时执行多个运算，所以编译器可能选择采用标量简化 优化。这一 优化有效地将简单的 Sum 函数从上述形式转换为以下形式：
float Sum( const float A[], int n )
{
int n4 = n-n%4; // or n4=n4&(~3)
int i;
float sum=0, sum1=0, sum2=0, sum3=0;
for (i=0; i {
sum = sum + A[i];
sum1 = sum1 + A[i+1];
sum2 = sum2 + A[i+2];
sum3 = sum3 + A[i+3];
}
sum = sum + sum1 + sum2 + sum3;
for (; i sum = sum + A[i];
return sum;
}
该函数现在保持了四个独立的求和运算，它们可以在每个步骤同时处理。尽管优化后的函数现在要 快得多，但优化结果可能与非优化结果完全不同。在进行这一变化时，编译器采用了具有结合律的浮 点加法；即以下两个表达式等效：(a+b)+c == a+(b+c)。然而，对于浮点数而言，结合律并不总是适 用。现在，转换后的函数不是按以下方法求和：
sum = A[0]+A[1]+A[2]+...+A[n-1]
而是按以下方法计算结果：
sum = (A[0]+A[4]+A[8]+...)
+(A[1]+A[5]+A[9]+...)
+(A[2]+A[6]+A[10]+...)
+(A[3]+A[7]+A[11]+...)
+...
对于 A[] 的某些值而言，不同的加法运算顺序可能产生意外的结果。更为复杂的是，某些程序员 可能选择预先针对此类优化做准备，并相应地对这些优化进行补偿。在此情况下，程序可以按不同的 顺序构建数组 A，以便优化的 sum 产生预期的结果。而且，在许多情况 下，优化结果的精确性可能“足够严密”。当优化提供了令人信服的速度优点时，尤其如此。例如， 视频游戏要求具有尽可能快的速度，但通常并不要求进行高度精确的浮点计算。因此，编译器制造商 必须为程序员提供一种机制，以便控制速度和精确性之间经常背离的目标。
某些编译器通过为每种类型的优化单独提供“开关”在速度和精确性之间进行折衷。这使开发人员 可以禁用可能为其特定应用程序的浮点精确性带来变化的优化。尽管该解决方案可能提供对编译器的 高度控制，但它也会带来其他一些问题：
• 通常很难搞清楚需要启用或禁用哪些开关。
• 禁用任一优化都可能对非浮点代码的性能带来不利影响。
• 每个附加的开关都会引起许多新的开关组合；组合数目将很快变得难以控制。
因此，尽管为每种优化提供单独的开关看起来似乎很有吸引力，但使用此类编译器可能非常麻烦并 且不可靠。
许多 C++ 编译器提供了“一致性”浮点模型（通过 /Op 或 /fltconsistency 开关），从而使开 发人员能够创建符合严格浮点语义的程序。采用该模型时，可以防止编译器对浮点计算使用大多数优 化，同时允许其对非浮点代码使用这些优化。但是，该一致性模型具有一个缺点。为了在不同的 FPU 体系结构中返回可预测的结果，几乎所有 /Op 实现都将中间表达式舍入到用户指定的精度；例如，考 虑下面的表达式：
float a, b, c, d, e;
. . .
a = b*c + d*e;
为了在使用 /Op 开关时产生一致的且可重复的结果，该表达式的计算方式按如下方式实现：
float x = b*c;
float y = d*e;
a = x+y;
现在，最终结果在计算该表达式的每一步 中都产生了单精度舍入误差。尽管这种解释在严 格意义上并未破坏任何 C++ 语义规则，但它几乎肯定不是计算浮点表达式的最佳方法。通常，以 尽可能高的可行精度计算中间结果 更为可取。例如，以如下所示的较高精度计算表达式 a=b*c+d*e 将会更好：
double x = b*c;
double y = d*e;
double z = x+y;
a = (float)z;
或者，采用以下方式会更好：
long double x = b*c;
long double y = d*e
long double z = x+y;
a = (float)z;
在以较高精度计算中间结果时，最终结果显然会更为精确。具有讽刺意味的是，如果采用一致性模 型，则当用户试图通过禁用不安全的优化来减少误差时，出现误差的可能性却恰恰增加了。因此，一 致性模型不仅严重降低了效率，同时还无法对精确性的提高提供任何保证。对于认真的数值程序员而 言，这看起来不像是一个很好的折衷，这也是该模型没有被广泛接受的主要原因。
从版本 8.0 (Visual C++?2005) 开始，Microsoft C++ 编译器提供了一种更好的选择。它使程序 员可以选择以下三种常规浮点模式之一：fp:precise、fp:fast 和 fp:strict。
• 在 fp:precise 模式下，仅对浮点代码执行安全优化，并且与 /Op 不同，以最 高可行 精度一致性地执行中间计算。
• fp:fast 模式放松了浮点规则，允许以牺牲精确性为代价进行更为积极的优化。
• fp:strict 模式提供了 fp:precise 的所有常规正确性，同时启用了 fp- exception 语义，并禁止在存在 FPU 环境更改（例如，对寄存器精度、舍入方向的更改等等）时进行 非法转换。
可以通过命令行开关或编译器杂注单独控制浮点异常语义；默认情况下，在 fp:precise 模式下禁 用浮点异常语义，而在 fp:strict 模式下启用该语义。编译器还提供了对 FPU 环境敏感性和某些特 定于浮点的优化（如化简）的控制。这一简单明了的模型为开发人员提供了大量针对浮点代码编译的 控制，并且无须使用太多的编译器开关，也不会带来令人讨厌的副作用。
