This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: cache misses in gcc 3.3
- From: Andi Kleen <ak at muc dot de>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: ak at muc dot de, gcc at gcc dot gnu dot org, mszick at goquest dot com
- Date: Mon, 10 Feb 2003 17:12:33 +0100
- Subject: Re: cache misses in gcc 3.3
- References: <20030210145645.9E371F290D@nile.gnat.com>
> One thing that is really important in going after speed improvements is
> to have really accurate profiling information that shows where the time
> is being spent. Otherwise you will chase phantoms.
My -O2 test case was spending 10% in the parser, according to the standard timing
output. This was in the top three, with only CSE being slower. This was on an
Athlon.
The explanation offered by cachegrind - excessive data cache misses when accessing
the bison parser state tables - didn't look too unreasonable.
Interestingly I tried it on a P4 too and there the parser took upto 15%.
Perhaps it suffers from poor branch predicton or similar.
As far as I can see Neil is doing a good thing by attacking the C parser.
Hopefully CSE can be fixed too - I assume tree-ssa will do that eventually?
-Andi