Linus Torvalds <torvalds@transmeta.com> writes:
> >
[ under kernel 2.4.2 ]
> >
> >    CVS gcc 3.0:          Debian gcc 2.95.3:   RedHat gcc 2.96:
> > 
> >    real    16m8.423s     real    8m2.417s     real    12m24.939s
> >    user    15m23.710s    user    7m22.200s    user    10m14.420s
> >    sys     0m48.730s     sys     0m41.040s    sys     2m13.910s 
> >maps:    <250 lines           <250 lines          >3000 lines
> >
> >Obviously, the *real* problem is RedHat GCC 2.96.  If Linus bothers to
> >write this patch (he probably already has),
> 
> Check out 2.4.3-pre7, I'd be interested to hear what the system time is
> for that one.

Okay.  One note about the above results: as Zach pointed out, my
2.95.3 number for "maps" was wrong.  I must have forgotten to collect
the data but thought I had.  In fact, there are ~10 lines in "maps"
for the 2.95.3 "cc1plus" process.  The other "maps" numbers for 3.0
and 2.96 are correct, at least within an order of magnitude.

Under 2.4.3-pre7, I get the following disappointing numbers:

    CVS gcc 3.0:          Debian gcc 2.95.3:   RedHat gcc 2.96:

    real    16m10.660s    real    7m58.874s    real    10m36.368s
    user    15m27.900s    user    7m23.090s    user    10m0.290s 
    sys     0m48.400s     sys     0m40.350s    sys     0m40.790s 
maps:   <20 lines             ~10 lines            ~10 lines

A huge win for 2.96 and absolutely no benefit whatsoever for 3.0, even
though it obviously had a 10-fold effect on maps counts.  On the
positive side, there was no performance *hit* either.

As a blind "have not looked at relevant kernel source" guess, this
looks like a hash scaling problem to me: the hash size works great for
~300 maps and falls apart in a major way at ~3000 maps, presumably
when we get multiple hits per hash bin and start walking 10-member
lists.

How this translates into a course of action---some combination of
keeping your patch, enlarging the hash, and performance tweaking the
list-walking---I'm not sure.

Kevin <buhr@stat.wisc.edu>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/