This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Reasonable L1 cache miss rate for gcc
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: torvalds at transmeta dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 11 Aug 2002 01:12:39 -0400 (EDT)
- Subject: Reasonable L1 cache miss rate for gcc
- Reply-to: dberlin at dberlin dot org
What is a reasonable L1 cache miss rate (for memory loads
only not instructions) is for a P4 running GCC?
I have the exact figures, but without some idea of what reasonable would
be, i have no idea how *bad* it is.
Percentage wise, it's a 14-25% miss rate (depending on input).
Of course, I really want to know about L2's, but the file describing all
the available p4 pmcs says:
<!-- I have not been able to get counts that make sense from ld_miss_2L_retired yet. -->
<ld_miss_2L_retired>
<type>replay</type>
<tag_setup>
<pebs_enable>
<set>
<l1miss/>
<tag/>
</set>
</pebs_enable>
<pebs_matrix_vert>
<set>
<ld/>
</set>
</pebs_matrix_vert>
</tag_setup>
<count_setup>
<replay_event>
<set><nbogus/></set>
</replay_event>
</count_setup>
</ld_miss_2L_retired>
I agree with the conclusion of the comment, the l2 miss numbers it
gives don't make sense.
Sigh.
Someone with a PIII should be able to get oprofile to give us some l2
numbers.
On the other hand, those using cachegrind should be aware that it took a
*long* time for cachegrind cc1 run on the same input (preprocessed
version of expr.c at -O2), and the numbers it came up with are off by a
factor of 7 (on the low side. IE it claims 2 when it's really 14).
So i'm not too keen on using cachegrind numbers to model our cache
behavior.
--Dan