http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #23 from 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 cam
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #22 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #21 from Daniel Franke 2011-07-24
18:49:19 UTC ---
One year down. Did anything happen here?
--- Comment #20 from mkuvyrkov at gcc dot gnu dot org 2010-05-10 10:46
---
Subject: Re: this fortran program is too slow
On 5/7/10 1:38 AM, steven at gcc dot gnu dot org wrote:
> --- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38
> ---
> One possibility is t
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38 ---
One possibility is to see if the glibc patches for this issue can be merged
into eglibc... Maxim what do you think?
--
steven at gcc dot gnu dot org changed:
What|Removed |Adde
--- Comment #18 from dfranke at gcc dot gnu dot org 2010-05-06 19:23
---
(In reply to comment #16)
> This is a glibc issue with software sin function.
Is there anything that we can do about this?
If not, this PR should be closed.
--
dfranke at gcc dot gnu dot org changed:
--- Comment #17 from burnus at gcc dot gnu dot org 2009-12-05 19:01 ---
(In reply to comment #16)
> This is a glibc issue with software sin function.
AMD has some patches for this, which are seemingly only used by (open)SUSE's
glibc. Try http://developer.amd.com/CPU/LIBRARIES/LIBM/Pages
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-12-05 06:29
---
This is a glibc issue with software sin function. It does not use the FPU.
Just try with -m32. Changing n=5
$ gfc -m64 untitled.f90
$ time ./a.out
-1781878.9
real0m3.060s
user0m3.050s
sys
--- Comment #15 from linuxl4 at sohu dot com 2009-07-25 07:40 ---
no , I wrote this source myself.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #14 from eres at il dot ibm dot com 2009-07-22 11:15 ---
(In reply to comment #0)
> program main
> implicit none
> integer :: i,j
> integer,parameter :: N=5000
> real :: x(N)=0.0
> do j=1,20
> do i=1,N
> x(i)=x(i)+sin(real(i))+cos(real(i))-tan(real(i))
>
--- Comment #13 from burnus at gcc dot gnu dot org 2009-07-16 09:43 ---
See PR 40770 for "Vectorization of complex types, vectorization of sincos
missing"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--
ubizjak at gmail dot com changed:
What|Removed |Added
BugsThisDependsOn||40770
Status|UNCONFIRMED |NEW
Ever Confirm
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-07-16 09:06
---
Actually the middle-end presents the vectorizer with a call to a complex
function and REAL/IMAGPART exprs. I don't remember exactly which part
confuses it, but certainly the mixed complex / real types do.
--
--- Comment #11 from ubizjak at gmail dot com 2009-07-16 07:16 ---
(In reply to comment #6)
> Thus the question is really: Why are neither vmlsSinCos4 nor vmlsTan4 - nor
> for
> ACML vrs4_sincosf/vrsa_sincosf (vrs*_tan* does not exist) called?
Because sincos returns _TWO_ values and t
--- Comment #10 from ubizjak at gmail dot com 2009-07-16 06:56 ---
(In reply to comment #6)
> Thus with the GLIBC (with AMD patches) or with the AMCL, one gets only a
> slowdown of 25%, which is still acceptable. Why the Intel routines are so slow
> on my AMD, I do not know.
See [1], s
--- Comment #9 from kargl at gcc dot gnu dot org 2009-07-16 05:06 ---
(In reply to comment #8)
> compilation is also very slow, isn't it?
>
It's due to the initialization expression.
How much memory do you have? You're most likely swapping.
Your code when compiled with 4.5.0 shows
--- Comment #8 from linuxl4 at sohu dot com 2009-07-16 04:37 ---
compilation is also very slow, isn't it?
can anybody confirm my results of only with or without -O3 option?
I think the difference of sse or x87 is 4 times at most.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4076
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-15 21:00 ---
icc can vectorize the function, gcc cannot. Use an operating system which
has sincos available and you'll get at least that bit.
You definitely want -O3 -ffast-math. That we can't vectorize sin/cos/tan
is RMS faul
--- Comment #6 from burnus at gcc dot gnu dot org 2009-07-15 20:27 ---
You should also add -march=native to the command line; it probably does not
help much, bit it should help a bit. I recall also the standard GLIBC misses
some optimized version for math on x86-64 while AMD provides pat
--- Comment #5 from dominiq at lps dot ens dot fr 2009-07-15 18:50 ---
> can anybody confirm?
On a 2.1Ghz core2duo, i686-apple-darwin, I get:
[ibook-dhum] bug/timing% gfc -m64 -O3 -ffast-math pr40766_db.f90
[ibook-dhum] bug/timing% time a.out
4.36921651E+09
157.568u 0.454s 2:38.39 99
--- Comment #4 from linuxl4 at sohu dot com 2009-07-15 18:35 ---
-O3 also very slow.
4.28173363E+09
real81m50.845s
user81m50.587s
sys 0m0.444s
can anybody confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40766
--- Comment #3 from ubizjak at gmail dot com 2009-07-15 17:58 ---
(In reply to comment #1)
> if I call the functions(sin,cos,tan) from intel's libimf.so, then
> gfortran 1.f90 -limf
> 4.31716608E+09
>
> real6m39.177s
> user6m38.289s
> sys 0m0.512s
This is probably libra
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-15 15:55 ---
What is the timing when adding -O3 to the command line. GCC defaults to no
optimizations turned on. This is unlike ifort which defaults to having
optimizations turned on.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #1 from linuxl4 at sohu dot com 2009-07-15 15:49 ---
My server is an atom330/gentoo
gfortran -v
GNU Fortran (GCC) 4.5.0 20090715 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.
gfortran 1.f90; time ./a.out
4.28173363E+09
real120m30.599s
user120m2
24 matches
Mail list logo
