This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc300 vs gcc295.3 benchmarking?
- To: pcarlini at unitus dot it
- Subject: Re: gcc300 vs gcc295.3 benchmarking?
- From: "RenE J.V. Bertin" <rjvbertin at hotmail dot com>
- Date: Tue, 17 Jul 2001 17:24:52 +0200
- Cc: gcc at gcc dot gnu dot org
>
>Did you really check this? Did you really thoroughly test the effect of
>-mpreferred-stack-boundary=X and of the other alignment switches? I'm
>asking
>this because, in my personal experience, they are still relevant,
>especially so
>when doubles are involved.
Thoroughly, no. I did try -malign-double (which is included in the "optimal
option list" I mentioned, and a few -mpreferred-stack-boundary=X values (the
default and the apparently theoretical optimal of X=8). I also tried the new
options like accumulate-args, etc. The effect was minimal. But I should
mention that I tried this always with the -mcpu and -march options set to
pentiumpro, and with a programme I wrote for benchmarking a callback
mechanism I use extensively (= not only floating point benchmarking).
OTOH, since you mention fl.pt. alignment, I tried the integer version of the
dhrystone test I have. No floating point operations, and yet I get the same
pattern. -mpreferred-stack-boundary=8 gives (almost) identical performance
(for pure integer benchmarking) between the 2 versions. I thus re-tried the
fl.pt. benchmark. At best (with my optimal list, and -mpref-stk-bndr=8),
gcc3 is some 7% slower than gcc 2.95.3 . It would seem that alignment is the
main but not only cause of the performance difference.
I am a bit reluctant to use -mpreferred-stack-boundary=8 as a default, given
the remarks about its use in libraries in the gcc manual...
Best,
RenE
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.