This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Breaking up the 'parse' time into 'parse/bison' and 'parse/other'
- From: Andi Kleen <ak at suse dot de>
- To: Tim Josling <tej at melbpc dot org dot au>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 26 Feb 2003 10:51:41 +0100
- Subject: Re: Breaking up the 'parse' time into 'parse/bison' and 'parse/other'
- References: <3E5BC2F7.E6A8F68@melbpc.org.au.suse.lists.egcs> <p73znok6svp.fsf@amdsimf.suse.de> <3E5C88C8.9F875B41@melbpc.org.au>
> The report you referred to about the parser - did it quantify the number of
> cache misses and the resulting %impact?
Yes, the access to the LALR tables of bison was in the top 5 for data cache
misses on an Athlon with 256K cache. My theory was that the optimization
passes in rest_of_compilation always need more than 256K scratch memory
and push out all the parser state, so when the next function is parsed
the parser has to fetch its state tables from memory again and eat the
cache miss latencies.
If you have a linux/x86 box around you can look at it yourself - just install
valgrind from http://developer.kde.org/~sewardj/ and run cc1 with some
bigger files in cachegrind. valgrind doesn't need any special kernel versions,
it is purely a software solution.
-Andi