This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Reasonable L1 cache miss rate for gcc


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]