Re: More on compile performance of Linux kernels in mainline gcc

[Zack Weinberg <zack at codesourcery dot com>]

Andi Kleen <ak@suse.de> writes:

> This is an addendum for the numbers for linux kernel compiling
> on x86-64 I posted some days ago. gcc tested is the same (041029)
> on the same machine with the same kernel tree/configuration.

I can't comment on most of this, but:

> Looks like the likely/unlikely split is not very effective,
> there are a lot of hot unlikely hits. 

That logic has known bugs.  You could try disabling it
(-fno-reorder-blocks-and-partition) or applying Caroline Tice's
patches which are supposed to make it better (posted in
mid-September).  I'd be interested to hear the results, especially if
you try the latter.

> 1.5% garbage collector accounting looks like a bug if that function
>      isn't misnamed.

ggc_alloc_stat performs the function of malloc.  The garbage collector
itself does not appear on this profile, which does not surprise me, as
the memory pressure heuristics basically shut it off for any input
that wouldn't otherwise push the machine into swap.

> Looks like that hot hash lookup is just a bad cache pig. Maybe
> the hash table is not too small, but too big? 

It is indeed far too big.  That's the identifier hash table, which has
all kinds of other junk in it as well as identifiers.  Geoffrey
Keating is or was working on this.

> yyparse is surprisinly cache intensive.

Big data table competing with the giant data structure that yyparse is
building.  Again, patches exist that might help: this time it's the
parser rewrite by Joseph Myers.

zw