[Bug fortran/40766] this fortran program is too slow

[Bug fortran/40766] this fortran program is too slow

[dfranke at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766

--- Comment #21 from Daniel Franke <dfranke at gcc dot gnu.org> 2011-07-24 18:49:19 UTC ---
One year down. Did anything happen here?

[Bug fortran/40766] this fortran program is too slow

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu.org

--- Comment #22 from Janne Blomqvist <jb at gcc dot gnu.org> 2012-04-19 14:34:35 UTC ---
AFAIK the recently released Glibc 2.15 incorporates quite a lot of work in
libm. Whether it fixes any of these performance issues I don't know.

[Bug fortran/40766] this fortran program is too slow

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766

--- Comment #23 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-04-24 13:13:13 UTC ---
The glibc libm work has mainly been oriented at correctness rather than 
performance, and postdates the 2.15 release so will be new in 2.16 (the 
2.15 announcement came some time after the actual tag and branching).

[Bug tree-optimization/40766] this fortran program is too slow

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
          Component|fortran                     |tree-optimization

--- Comment #24 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
On a Intel(R) Xeon(R) CPU E5640 @ 2.67GHz under
Linux version 2.6.43.8-1.fc15.x86_64 (mockbuild@x86-02.phx2.fedoraproject.org)
(gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC) ) #1 SMP Mon Jun 4 20:33:44
UTC 2012, the timing for the test in comment #0 compiled with gfortran 4.6.3 is

[delta] test/fortran$ time a.out
  4.28173363E+09
1441.326u 0.035s 24:04.84 99.7%    0+0k 0+0io 0pf+0w

Note that a real(8) version gives

[delta] test/fortran$ time a.out
   696899672.37568963     
184.465u 0.067s 3:05.04 99.7%    0+0k 400+0io 3pf+0w

without optimization,

   696899672.37569129     
131.957u 0.104s 2:12.39 99.7%    0+0k 0+0io 0pf+0w

with -O3 and

   696899672.37550783     
136.051u 0.066s 2:16.43 99.7%    0+0k 0+0io 0pf+0w

with -O3 -ffast-math. I don't have access to more recent fedora and/or gcc
versions, so I don't know if the miserable performances of some linux
transcendental floats have been finally fixed or not (the accuracy argument is
ridiculous: what is the point to get the 23rd bit exact when you cat get more
than 50 for 10 time less?). On this count this PR should be fixed as INVALID.

However, I have found a strange behavior with optimization when repeating the
test on a 2.5Ghz Core2Duo under x86_64-apple-darwin10:

-O0             76.1s
-O0 -ftree-ter  62.5s
-O1            103.0s
-O2            112.9s
-O3            112.9s
-Ofast         115.2s

Can someone explain what's going on?