仍然值得尝试在C中为sqrt()创建优化吗？

Question

用于创建sqrt()的更快实现的旧技巧(查找表,近似函数)是否仍然有用,或者是现代编译器和硬件的默认实现？

Answer 1

规则1:优化前的配置文件

在投入任何努力以确保您可以击败优化器之前,您必须分析所有内容并发现瓶颈所在的位置.一般来说,它sqrt()本身不太可能是你的瓶颈.

规则2:在替换标准函数之前替换算法

即使sqrt()是瓶颈,那么仍然有可能存在算法方法(例如通过长度平方排序距离,这可以在不调用任何数学函数的情况下轻松计算),这可以消除sqrt()首先调用的需要.

如果你什么都不做,编译器会为你做什么

许多现代C编译器都愿意以更高的优化级别内联CRT函数,使得包括调用在内的自然表达能够sqrt()达到所需的速度.

特别是,我检查了MinGW gcc v3.4.5,并用一个sqrt()内联代码替换了一个调用,该内联代码改组了FPU状态,并且核心使用了该FSQRT指令.由于C标准与IEEE 754浮点交互的方式,它必须遵循FSQRT一些代码来检查异常情况并sqrt()从运行时库调用实际函数,以便浮点异常可以由根据标准要求的库.

使用sqrt()内联并在更大的所有double表达式的上下文中使用,结果尽可能高效,因为符合标准并保持完全精度.

对于编译器和目标平台的这种(非常常见的)组合,并且不了解用例,这个结果非常好,并且代码清晰且可维护.

在实践中,任何技巧都会使代码不那么清晰,而且可能的维护性也会降低.毕竟,您宁愿维护(-b + sqrt(b*b - 4.*a*c)) / (2*a)内联汇编和表格的不透明块吗？

此外,在实践中,您通常可以指望编译器和库作者充分利用您的平台的功能,并且通常比您对优化的微妙之处了解更多.

但是,在极少数情况下,可能会做得更好.

一个这样的场合是在计算中你知道你真正需要多少精度,并且知道你不依赖于C标准的浮点异常处理,并且可以与硬件平台提供的东西相提并论.

编辑:我重新安排了一些文本,以强调分析和算法,如Jonathan Leffler在评论中所建议的那样.谢谢,乔纳森.

编辑2:修正了kmm锐利眼睛发现的二次例子中的优先错误.