This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: povray: Revised numbers
> On Sat, 17 Jan 2004, Jan Hubicka wrote:
>
> > > Here are revised numbers for my povray test, based on comments both
> > > public and private:
> > >
> > > compile benchmark
> > > time time
> > > -------- ---------
> > > gcc mainline 1:43 7:59
> > > w/ -mfpmath=sse 1:46 6:30
> > >
> > > gcc tree-ssa 1:46 7:35
> > > w/ -mfpmath=sse ** SEG fault **
> > >
> > > icc 8.0 1:53 5:50
> > >
> > Thanks for testing.
> > If you have code where -mfpmath=sse lose considerably on mainline
> > (3.3 branch had very fresh SSA implementation and lacked P4 tunning), I
> > would be interested in seeing it.
>
> As can Scott, so can I ;) Here are some benchmarks for my favorite POOMA
> based application. For current 3.3, 3.4 and Intel 8.0 (tree-ssa ICEs).
> For a fair comparison, I dropped __attribute__((leafify)) in one round of
> testing, as I cannot hack Intel 8.0 for my needs.
>
> Compiler flags are -O2 -funroll-loops -ffast-math -march=athlon for gcc
> and -O2 -ip for icc. Tests are done on an Athlon 1GHz with 1GB ram.
> gcc 3.3 is 3.3.3 20040112, gcc 3.4 is 3.4.0 20040114, icc 8.0 is build
> 20031231Z.
>
> compile time run time binary size (static, stripped)
> gcc3.3 6m57s 1m24s 2877232
> 8m23s 0m34s 2963408 __attribute__((leafify))
> gcc3.4 3m41s 1m10s 2584088
> 5m04s 0m39s 2682520 __attribute__((leafify))
> icc8.0 12m41s 0m42s 5046476
>
> So what one can clearly see, Intel 8.0 looses all the way down in compilation
> speed and binary size, but is a lot better in runtime than plain gcc. And
> it should be clear, why I'm still maintaining the leafify attribute
> patch... :)
>
> The leafify test also shows that mainline/3.4 has somewhat regressed in
> speed compared to 3.3 - performance I expect to get back after rtlopt
> been merged. Together with the new parser and improved ISO compliance I'm
I think this can be actually interference with the leafify code. If you
leafify a really huge function, you easilly reach the inline-unit-growth
limits and supress all other inlining in effect.
I was thinking that perhaps it may sense to apply inline limits only to
the growth caused by non-always_inline/leafify/extern inline functions.
Honza
> quite happy with 3.4.
>
> I'd love to test tree-ssa, but that doesn't build my application at the
> moment (and I don't have the leafify attribute fixed wrt the latest
> cgraph changes yet).
>
> Richard.