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

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

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

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

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

许多现代C编译器都愿意以更高的优化级别内联CRT函数,使得自然表达包括对sqrt()的调用尽可能快.

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

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

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

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

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

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

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

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

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