为什么 gcc 数学库如此低效?

本文介绍了为什么 gcc 数学库如此低效?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

当我将一些 fortran 代码移植到 c 时，令我惊讶的是，使用 ifort(intel fortran 编译器)编译的 fortran 程序和使用 gcc 编译的 c 程序之间的大部分执行时间差异来自三角函数的计算函数(sin、cos).这让我感到惊讶，因为我曾经相信这个答案所解释的，像正弦和余弦这样的函数是在微处理器内部的微代码中实现的.

When I was porting some fortran code to c, it surprised me that the most of the execution time discrepancy between the fortran program compiled with ifort (intel fortran compiler) and the c program compiled with gcc, comes from the evaluations of trigonometric functions (sin, cos). It surprised me because I used to believe what this answer explains, that functions like sine and cosine are implemented in microcode inside microprocessors.

为了更明确地发现问题，我在 fortran 中做了一个小测试程序

In order to spot the problem more explicitly I made a small test program in fortran

program ftest
  implicit none
  real(8) :: x
  integer :: i
  x = 0d0
  do i = 1, 10000000
    x = cos (2d0 * x)
  end do
  write (*,*) x
end program ftest

在 intel Q6600 处理器和 3.6.9-1-ARCH x86_64 Linux我得到 ifort 12.1.0 版

On intel Q6600 processor and 3.6.9-1-ARCH x86_64 LinuxI get with ifort version 12.1.0

$ ifort -o ftest ftest.f90
$ time ./ftest
  -0.211417093282753

real    0m0.280s
user    0m0.273s
sys     0m0.003s

虽然使用 gcc version 4.7.2 我得到

$ gfortran -o ftest ftest.f90
$ time ./ftest
  0.16184945593939115

real    0m2.148s
user    0m2.090s
sys     0m0.003s

这几乎是 10 倍的差异！我是否仍然可以相信 cos 的 gcc 实现是微处理器实现的包装器，其方式与英特尔实现中可能完成的方式类似?如果这是真的，瓶颈在哪里?

This is almost a factor of 10 difference! Can I still believe that the gcc implementation of cos is a wrapper around the microprocessor implementation in a similar way as this is probably done in the intel implementation? If this is true, where is the bottle neck?

编辑

根据评论，启用的优化应该可以提高性能.我的观点是优化不会影响库函数……这并不意味着我不在重要的程序中使用它们.但是，这里有两个额外的基准测试(现在在我的家用电脑上intel core2)

According to comments, enabled optimizations should improve the performance. My opinion was that optimizations do not affect the library functions ... which does not mean that I don't use them in nontrivial programs. However, here are two additional benchmarks (now on my home computer intel core2)

$ gfortran -o ftest ftest.f90
$ time ./ftest
  0.16184945593939115

real    0m2.993s
user    0m2.986s
sys     0m0.000s

和

$ gfortran -Ofast -march=native -o ftest ftest.f90
$ time ./ftest
  0.16184945593939115

real    0m2.967s
user    0m2.960s
sys     0m0.003s

您(评论员)想到了哪些特定优化?在这个特定的例子中，编译器如何利用多核处理器，其中每次迭代取决于前一次的结果?

Which particular optimizations did you (commentators) have in mind? And how can compiler exploit a multi-core processor in this particular example, where each iteration depends on the result of the previous one?

编辑 2

Daniel Fisher 和 Ilmari Karonen 的基准测试让我认为问题可能与特定版本的 gcc (4.7.2) 以及我正在使用的特定版本 (Arch x86_64 Linux) 有关我的电脑.所以我用 debian x86_64 Linux、gcc version 4.4.5 和 ifort version 12.1 在 intel core i7 盒子上重复了测试.0

The benchmark tests of Daniel Fisher and Ilmari Karonen made me think that the problem might be related to the particular version of gcc (4.7.2) and maybe to a particular build of it (Arch x86_64 Linux) that I am using on my computers. So I repeated the test on the intel core i7 box with debian x86_64 Linux, gcc version 4.4.5 and ifort version 12.1.0

$ gfortran -O3 -o ftest ftest.f90
$ time ./ftest
  0.16184945593939115

real    0m0.272s
user    0m0.268s
sys     0m0.004s

和

$ ifort -O3 -o ftest ftest.f90
$ time ./ftest
  -0.211417093282753

real    0m0.178s
user    0m0.176s
sys     0m0.004s

对我来说，这是一个非常可接受的性能差异，这永远不会让我问这个问题.看来我得去 Arch Linux 论坛问这个问题了.

For me this is a very much acceptable performance difference, which would never make me ask this question. It seems that I will have to ask on Arch Linux forums about this issue.

不过，对整个故事的解释还是很受欢迎的.

However, the explanation of the whole story is still very welcome.

x87

为什么 gcc 数学库如此低效?

问题描述

推荐答案