public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug fortran/40766] this fortran program is too slow [not found] <bug-40766-4@http.gcc.gnu.org/bugzilla/> @ 2011-07-24 18:50 ` dfranke at gcc dot gnu.org 2012-04-19 14:37 ` jb at gcc dot gnu.org ` (2 subsequent siblings) 3 siblings, 0 replies; 4+ messages in thread From: dfranke at gcc dot gnu.org @ 2011-07-24 18:50 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/40766] this fortran program is too slow [not found] <bug-40766-4@http.gcc.gnu.org/bugzilla/> 2011-07-24 18:50 ` [Bug fortran/40766] this fortran program is too slow dfranke at gcc dot gnu.org @ 2012-04-19 14:37 ` jb at gcc dot gnu.org 2012-04-24 13:14 ` joseph at codesourcery dot com 2013-06-19 12:51 ` [Bug tree-optimization/40766] " dominiq at lps dot ens.fr 3 siblings, 0 replies; 4+ messages in thread From: jb at gcc dot gnu.org @ 2012-04-19 14:37 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug fortran/40766] this fortran program is too slow [not found] <bug-40766-4@http.gcc.gnu.org/bugzilla/> 2011-07-24 18:50 ` [Bug fortran/40766] this fortran program is too slow dfranke at gcc dot gnu.org 2012-04-19 14:37 ` jb at gcc dot gnu.org @ 2012-04-24 13:14 ` joseph at codesourcery dot com 2013-06-19 12:51 ` [Bug tree-optimization/40766] " dominiq at lps dot ens.fr 3 siblings, 0 replies; 4+ messages in thread From: joseph at codesourcery dot com @ 2012-04-24 13:14 UTC (permalink / raw) To: gcc-bugs 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). ^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug tree-optimization/40766] this fortran program is too slow [not found] <bug-40766-4@http.gcc.gnu.org/bugzilla/> ` (2 preceding siblings ...) 2012-04-24 13:14 ` joseph at codesourcery dot com @ 2013-06-19 12:51 ` dominiq at lps dot ens.fr 3 siblings, 0 replies; 4+ messages in thread From: dominiq at lps dot ens.fr @ 2013-06-19 12:51 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2013-06-19 12:51 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <bug-40766-4@http.gcc.gnu.org/bugzilla/> 2011-07-24 18:50 ` [Bug fortran/40766] this fortran program is too slow dfranke at gcc dot gnu.org 2012-04-19 14:37 ` jb at gcc dot gnu.org 2012-04-24 13:14 ` joseph at codesourcery dot com 2013-06-19 12:51 ` [Bug tree-optimization/40766] " dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).