This is the mail archive of the gcc@gcc.gnu.org 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: remarks about g++ 4.3 and some comparison to msvc & icc on ia32


> On 1/28/07, Jan Hubicka <hubicka@ucw.cz> wrote:
> >Also having some testcases showing inlining deffects in GCC would be
> >very interesting for me.  Now after IPA-SSA has been merged, I plan to
> >do some retuning of inliner for 4.3 release since a lot has changes
> >about properties of it's input and it was originally designed to operate
> >well on IL used by early tree-ssa.
> Gcc, well g++ really, used to be so bad at the inlining game, ie
> single op functions/ctors suddendly left out, there was no other
> options than to explicitly direct inlining if one cared about
> performance. So i don't have much to show, for what i monitored wasn't

I am not quite sure what you mean by direct inlining here.  At -O2 G++
still don't inline any functions not marked as inline by user, at -O3 we
do.  I plan to propose to change this behaviour to make -O2 auto-inline
everything that is expected to reduce code size.

I am just about to leave for 5 days but I plan to run couple of
benchmarks after that and propose this.

I would be interested to know about obvious mistakes GCC do - GCC now
has logic to set cost of inlining "wrapper" functions (ie functions
doing just one extra call and casts) to at most 0. It might be
interesting to know if some common scenarios are missed.

> under g++ juridiction.
> Now i know it has improved (much) because obviously other parts are
> being stressed.

Well, we are working on it ;)
You can take a look at c++ benchmarks http://www.suse.de/~gcctest the
work is ongoing since cgraph was implemented in 2003, another retunning
happen at about 4.0 timeframe, 4.3 has the SSA based IPA that should be
another improvement.
> 
> >Considering information about stack frame size in the inlining costs is
> >one of things I believe we should do but it is also dificult to tune
> >without interesting testcases for it.
> I have no idea what would make such testcase interesting to you.
> But i can try.
> You'll find 2 preprocessed GPLed sources attached with
> 
> frontend.cc, app::frontend_loop()
> (i don't particularly care about that function, but on ia32 - x86-64
> is immune - g++ is quite creative about it (large frame, oodles of
> upfront zeroing, even if it's a bit better with the gcc-4.3-20070119
> snapshot))
> frame size, msvc 1152 bytes, icc 2108, g++ 2604
> 
> rt_render_packet.cc, horde::grunt_render_tiles_packet(...)
> (this one i care about, inlining is controlled)
> frame size, msvc 1688, icc 1804, gcc 1932
> Performance wise on that one msvc lags by 25% and gcc has a slight
> lead of a couple percent on icc.
> 
> note: take 2, http://ompf.org/vault/frontend.ii.bz2
> http://ompf.org/vault/rt_render_packet.ii.bz2

Thanks, what is definitly most interesting for me is self contained
testcase I can easilly compile and run, like we have tramp3d. I will
definitly take a lok at your testcases, but perhaps only after returning
from trip at next weekend since I am running out of time for all my
TODOs today ;)

Concerning the frame sizes, we really need some kind of analysis from
where it is comming - ie whether GCC simply inline too much together, or
fail to pack well the structures using existing algorithm or it is
register pressure problem.

Thanks,
Honza


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