优化数学库（libm）答案

【问题标题】：Optimize mathematical library (libm)优化数学库（libm）
【发布时间】：2014-03-10 03:45:17
【问题描述】：

有没有人尝试用-march=corei7 编译glibc，看看是否有任何Linux x68_64 发行版默认提供的版本的性能改进？ GCC 使用-march=i686 编译。我认为（不确定）数学库也以相同的方式编译。有人可以确认吗？

【问题讨论】：

我要指出，任何 x86-64 构建不能根据定义使用-march=i686。至少，任何 x86-64 构建都可以采用 SSE、SSE2 和 16 个 SSE 寄存器。我的直觉是，进一步指定微架构的收益将很小；特别是对于标量而非 SIMD 数学函数。

标签： math gcc optimization libm

【解决方案1】：

大多数用于 x86 的 Linux 发行版仅使用 i686 指令进行编译，但要求为以后的处理器安排它们。我并没有真正关注后来的发展。

很久以前，根据处理器线的不同版本的系统库很常见，但很快就认为性能差异对于成本来说太小了。与此同时，机器的性能也变得更加统一。

必须始终记住的一件事是，今天的机器内存受限。即，今天的内存访问比一条指令花费的时间要长几百倍，而且差距还在扩大。更不用说这台机器（一台旧的笔记本电脑，大约 2 年前是顶级的）有 4 个内核（8 个线程），所有这些都在努力从内存中获取数据/指令。让代码运行得稍微快一点，让 CPU 等待 RAM 的时间更长，但效率并不高。

【讨论】：

我使用的是一个真正计算机密集型的数值气象模型。大多数使用它的人说，使用 ifort 编译的代码比使用 gfortran 编译的代码运行速度快 3 到 5 倍。根据英特尔网站，gfortran 能够生成真正高效的代码。所以我认为性能差异可能与数学函数的实现有关。你怎么看？
这取决于确切的用法。仅仅调用简单的函数不会有太大的不同，如果不是太频繁的话，更是如此。分析代码，看看时间花在了哪里。如果您可以访问例如intel 的编译器，在主代码上试试那个（编译系统库是麻烦，三次；只能在可怕的情况下完成
在数学（尤其是超越）函数的上下文中，情况并非如此。它们几乎总是完全受 CPU 限制，使用范围缩减、多项式评估等，除了偶尔查找魔术常量的表。
@BrettHale，调用到库中将主要执行操作，因此尝试削减库中的设置几乎没有（如果有的话）效果。