This is the mail archive of the
mailing list for the GCC project.
Re: Optimization comparison: 3.3, 3.4, mainline, tree-ssa
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: coyote at coyotegulch dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 18 Apr 2004 18:56:35 -0400 (EDT)
- Subject: Re: Optimization comparison: 3.3, 3.4, mainline, tree-ssa
- References: <4082E5BE.email@example.com>
> Performance on the "alma" test is predicated on the speed of the
> sin(), cos(), and sqrt() functions. I've tried -D__NO_INLINE__,
> -fno-inline, and other suggestions, without finding anything that
> improved GCC's performance on this benchmark.
Strange. Using last night's mainline on i686-pc-linux-gnu, when I
supply either -D__NO_INLINE__ or -D__NO_MATH_INLINES I get a dramatic
30% speedup for alma. Still not as fast as ICC, but better than it
was. I suspect we'll do better when Uros finishes the x87
Anyway, please try compiling almabench.c with -save-temps and look at
the .i file. Search for inline versions of the trig functions. For
me, these go away and we're left with the regular function calls (and
thus the nifty new builtins) when I use either of those macros. I'm
very curious why you see no difference and I do.
> Whether it's a problem in glibc or a problem in gcc doesn't really
> matter to the user -- he or she just wants fast code.
Agreed completely. That's why I support adding a fixincl hack to
define __NO_MATH_INLINES at the top of math.h (ditto respectively for
__NO_STRING_INLINES and string.h.) I suppose that's maybe
controversial but too bad IMHO.
We (the gcc and glibc communities) need to stop writing the same
optimizations in two places and the compiler is where they belong
because ultimately it can do a better job.
Kaveh R. Ghazi firstname.lastname@example.org