使用Intel编译器获得一致的浮点数值计算结果

使用Intel编译器获得一致的浮点数值计算结果


大多数十进制的浮点数, 用二进制表示时不是完全一致的; 与此同时, 大多数与浮点数值相关的计算结果, 存在着固有的不确定性.

通常, 编写浮点计算应用软件希望达到如下的目标:
- 准确性:
意味着该产品产生的计算结果,应当”接近”于实际计算的结果; 评判的标准是误差值, 有时候也采用最后几位(“units in the last place”, ulp)
- 可复制性:
意味着该产品始终产生一致的结果, 无论运行的先后, 采用不同的编译选项, 使用不同的编译器, 还是在不同的处理器或者操作系统平台
- 性能:
计算应用当然运行得越快越好

但是, 这些目标往往是互相矛盾的. 而良好的编程习惯和合理地使用编译器选项, 能够帮助你很好地取得平衡. 正确的编译器选项, 可以得到一致的, 近乎可重现的结果, 也能保证足够快的性能(当然不是最佳的).


浮点运算规则

Intel编译器实现了一整套Microsoft引入的浮点运算规则模型, 具体内容可参考 Microsoft* Visual C++* Floating-Point Optimization: http://msdn2.microsoft.com/en-us/library/aa289157(vs.71).aspx

这个编译器开关选项 (Windows中使用/fp:, Linux 或 Mac OS X 使用-fp-model, 下同) 可以让你自由地选择最合适的编译器规则, 基于如下的条件:
- 数值安全 (value safety)
- 浮点表达式赋值 (FP expression evaluation)
- 浮点精度溢出 (precise FP exceptions)
- 浮点计算合并(FP contractions)
- 访问浮点运算单元(FPU)

如下列出了使用/fp: (-fp-model) 时的全部可选参数:
precise 只允许数值安全的优化
source | double | extended 指定浮点表达式赋值时使用的精度
except 激活严格的浮点溢出模式
strict 激活访问FPU; 不允许浮点计算合并, 比如乘加(fused multiply-add, fma); 默认使用 ‘prcise’ 和 ‘except’
fast[=1] (缺省选项) 允许数值不安全的优化, 编译器自行决定表达式赋值的精度; 不允许访问FPU; 允许浮点计算合并
fast[=2] 允许一些额外的近似值计算

这个编译器开关取代了一系列在旧版本的Intel编译器中使用的选项, 例如/Op, /QIPF-fltacc, /flt-consistency (-mp, -IPF-fltacc, -flt-consistency).

其中, 当浮点运算结果需要满足符合ANSI / IEEE C++ 和 Fortran 语言标准时, 推荐使用如下的编译器选项组合:
/fp:precise /fp:source (Windows)
-fp-model precise -fp-model source (Linux, Mac OS X)


一个Fortran应用的例子

与不使用优化编译选项相比, 该应用程序优化编译后产生了不同的结果, 并且这种差异以一种特定的形式不断扩大. 产生问题的根源被定位在代码中如下形式的表达式:
A(I) + B + TOL
相对于TOL是一个非常小的正数, A(I) 和 B 的值比较大. 当编译器生成优化代码时, 愿意采用如下的赋值形式:
A(I) + (B + TOL)
这样的话, 常数表达式 (B+TOL) 进入循环 I 之前就可以只需要赋值一次. 可是原来代码的目的是为了保证表达式的结果为正, 当 A(I) 约等于 –B. 一旦 TOL 直接与 B 相加, 由于浮点精度限制, 它往往会被就会直接被取整, 因此也就无法发挥它使得表达式的结果保持正数的作用.

最简单的解决办法就是, 使用编译器开关 –fp-model precise 重新编译受影响的代码文件. 这样就能防止表达式重新组合, 而是按照代码书写时的次序进行赋值.

当然, 更直接的解决方案, 不会带来过多的性能下降, 就是改写原始的代码为:
(A(I) + B) + TOL
这样就可以清楚地表达出编程者的意图, 同时别忘了编译时使用选项 –assume protect_parents


另一个WRF的例子 (Weather Research and Forecasting model)

我们观察到同一个应用运行在不同数量的处理器下的MPI(Messenge Passing Interface)环境中, 结果会出现细微的不同. 这是因为随着不同数量的MPI进程, 原始问题的分解方式会发生变化, 进而导致循环边界和数据对齐也相应变化. 结果导致循环向量化代码中的循环次数, 以及前后的处理代码都发生了变化, 最终导致同样的数据, 却产生了略微不同的计算结果.

解决的方法就是编译时使用 –fp-model precise. 这样会让编译器生成前后一致的代码和数学库调用, 无论在循环体中和循环前后.

有时候(并不是一定), 这样做会阻止循环被向量优化, 特别是由于可能会改变计算的顺序导致结果发生结果不同, /fp:precise (-fp-model precise) 选项禁止归约(reduction)计算的向量化或者自动并行化. 注意, OpenMP中的并行归约操作无法因此被自动禁止, 程序员应当知道它们是数值不安全的操作, 必须自行处理.


可能的性能影响

/fp:precise /fp:source (-fp-model precise –fp-model source) 禁止使用某些特定的优化, 因此会在一定程度上降低应用程序的执行速度. 不同类型的应用受到的影响可能会非常不同.

从SPECCPU2000fp 测试集的试验数据来看, 对原有 -O3 选项的性能影响比较大, 大约为15%-20%, 主要是其中许多高级别的循环优化往往需要重新排列操作顺序. 而对 –O2 的影响很小, 基本在 1% 左右.


额外注意事项

编译选项 /fp:precise /fp:source (-fp-model precise –fp-model source) 也应当在调试模式 /Od (-O0) 时使用. Intel 编译器11.1以前的版本中, /Od (-O0) 会默认使用 /Op (-mp), 因此即使在 Intel 64 架构中也同样会生成 x87 指令, 除非使用 /fp:source (-fp-model source).

从11.0编译器版本开始, 使用/fp:precise (-fp-model precise)后, 循环中包含数学函数例如: log(), sin(), 也不会自动被向量化. 因为它可能会导致一个函数调用不同的数学函数库, 从而返回与标准数学函数库不同的, 略有差别的结果. 编译器选项开关 /Qfast-transcendentals (-fast-transcendentals) 能够恢复原来 10.1 版本中的缺省行为, 重新激活向量化优化.


结束语

Intel编译器选项能够让你控制并在浮点数值计算的准确性, 可复制性和性能目标中自行取舍.

使用 /fp:precise /fp:source (Windows) 或者 –fp-model precise –fp-model source (Linux, Mac OS X) 能够显著提高浮点运算结果的准确性和可复制性, 同时降低对运算性能的影响.



进一步阅读信息

1) Dr. Martyn J. Corden, David Kreitzer: “Consistency of Floating-Point Results using the Intel? Compiler or Why doesn’t my application always give the same answer?” http://software.intel.com/en-us/articles/consistency-of-floating-point-results-using-the-intel-compiler/
2) Microsoft Visual C++* Floating-Point Optimization: http://msdn2.microsoft.com/en-us/library/aa289157(vs.71).aspx
3) The Intel? C++ and Fortran Compiler User and Reference Guides, “Floating Point Operations” section.
4) “Floating Point Calculations and the ANSI C, C++ and Fortran Standard” http://www.intel.com/cd/software/products/asmo-na/eng/330130.htm
or see the list at http://www.intel.com/cd/software/products/asmo-na/eng/330130.htm