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:
> > On Sat, 17 Jan 2004, Jan Hubicka wrote:
> >
> > 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.
I'm not counting the leafify inlining at all, so leafifying shouldn't make
an effect here.
Richard.