c - 是否仍然值得尝试在 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) 还是一个不透明的内联程序集和表 block ？

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

但是，在极少数情况下，可以做得更好。

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

编辑:我稍微重新安排了文本，以强调 Jonathan Leffler 在评论中建议的分析和算法。谢谢，乔纳森。

Edit2:修复了 kmm 发现的二次示例中的优先级拼写错误锐利的眼睛。