This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]