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: Loop unrolling-related SPEC regressions?



On Wednesday, February 6, 2002, at 02:08 PM, Laurent Guerby wrote:
>                 GCC   S   G/S   SP  G/SP
>    164.gzip     461 472 0.976  563 0.818
>    175.vpr      259 255 1.015  285 0.908
>    176.gcc      323 248 1.302  355 0.909
>    181.mcf      180 194 0.927  196 0.918
>    186.crafty   524 632 0.829  678 0.772
>    197.parser   325 372 0.873  373 0.871
>    252.eon      642 692 0.927 1056 0.607
>    253.perlbmk  495 668 0.741  720 0.687
>    254.gap      366 441 0.829  441 0.829
>    255.vortex   410 702 0.584  731 0.560
>    256.bzip2    305 335 0.910  343 0.889
>    300.twolf    284 340 0.835  360 0.788
>
> Apparent weaknesses on base are vortex and perlbmk, has
> anyone looked at them? perl might be interesting, 25%
> base performance hit on such a complex piece of free software,
> there must be some critical interpreter piece of code
> completely miscompiled by CVS GCC (performance-wise).

I looked at Spec quite a bit for my last job and I can
suggest some things that are important.

Intelligent use of profiling info from the first pass is
important.  You'll see the published numbers do this.
Last time I looked gcc used this only for branch
straightening; it can also be used effectively to
drive inlining and register allocation.

crafty is heavily dependent on efficiency of "long long".
It's a chess program, full of 64-bit bitmasks.

eon is the only one in C++.  If there are any problems
in exception handling they will show up here.  The program
does not actually throw any exceptions, so turning off
the handling for peak may help (SPEC won't let you turn
it off for base).  Good inlining decisions are also important.

the two most heavily executed functions in perl are big;
IME register allocation & scheduling don't always work
well for big functions.  They also both call setjmp; if
this disables any substantial amount of optimization it
will hurt.

vortex accesses a huge amount of virtual memory.  Good
malloc/free performance is critical.


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