Различное количество операций чтения и записи с использованием cachegrind и callgrind

Я провожу эксперименты с Cachegrind, Callgrind и Gem5. Я заметил, что число обращений считалось чтением для cachegrind, записью для callgrind, а также чтением и записью для gem5.

Возьмем очень простой пример:

int main() {
    int i, l;

    for (i = 0; i < 1000; i++) {
        l++;
        l++;
        l++;
        l++;
        l++;
        l++;
        l++;
        l++;
        l++;
        l++;
        ... (100 times)
     }
 }

Я компилирую с:

gcc ex.c --static -o ex

Таким образом, в соответствии с файлом asm, addl $1, -8(%rbp) выполняется 100 000 раз. Поскольку это и чтение, и запись, я ожидал 100 КБ чтения и 100 КБ записи. Однако cachegrind считает их только прочитанными, а callgrind — только записывающими.

 % valgrind --tool=cachegrind --I1=512,8,64 --D1=512,8,64
--L2=16384,8,64 ./ex
==15356== Cachegrind, a cache and branch-prediction profiler
==15356== Copyright (C) 2002-2012, and GNU GPL'd, by Nicholas Nethercote et al.
==15356== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==15356== Command: ./ex
==15356== 
--15356-- warning: L3 cache found, using its data for the LL simulation.
==15356== 
==15356== I   refs:      111,535
==15356== I1  misses:        475
==15356== LLi misses:        280
==15356== I1  miss rate:    0.42%
==15356== LLi miss rate:    0.25%
==15356== 
==15356== D   refs:      104,894  (103,791 rd   + 1,103 wr)
==15356== D1  misses:        557  (    414 rd   +   143 wr)
==15356== LLd misses:        172  (     89 rd   +    83 wr)
==15356== D1  miss rate:     0.5% (    0.3%     +  12.9%  )
==15356== LLd miss rate:     0.1% (    0.0%     +   7.5%  )
==15356== 
==15356== LL refs:         1,032  (    889 rd   +   143 wr)
==15356== LL misses:         452  (    369 rd   +    83 wr)
==15356== LL miss rate:      0.2% (    0.1%     +   7.5%  )

-

 % valgrind --tool=callgrind --I1=512,8,64 --D1=512,8,64
--L2=16384,8,64 ./ex
==15376== Callgrind, a call-graph generating cache profiler
==15376== Copyright (C) 2002-2012, and GNU GPL'd, by Josef Weidendorfer et al.
==15376== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==15376== Command: ./ex
==15376== 
--15376-- warning: L3 cache found, using its data for the LL simulation.
==15376== For interactive control, run 'callgrind_control -h'.
==15376== 
==15376== Events    : Ir Dr Dw I1mr D1mr D1mw ILmr DLmr DLmw
==15376== Collected : 111532 2777 102117 474 406 151 279 87 85
==15376== 
==15376== I   refs:      111,532
==15376== I1  misses:        474
==15376== LLi misses:        279
==15376== I1  miss rate:    0.42%
==15376== LLi miss rate:    0.25%
==15376== 
==15376== D   refs:      104,894  (2,777 rd + 102,117 wr)
==15376== D1  misses:        557  (  406 rd +     151 wr)
==15376== LLd misses:        172  (   87 rd +      85 wr)
==15376== D1  miss rate:     0.5% ( 14.6%   +     0.1%  )
==15376== LLd miss rate:     0.1% (  3.1%   +     0.0%  )
==15376== 
==15376== LL refs:         1,031  (  880 rd +     151 wr)
==15376== LL misses:         451  (  366 rd +      85 wr)
==15376== LL miss rate:      0.2% (  0.3%   +     0.0%  )

Может ли кто-нибудь дать мне разумное объяснение? Правильно ли я считаю, что на самом деле ~ 100 тыс. операций чтения и ~ 100 тыс. операций записи (т.е. 2 доступа к кешу для надстройки)?


c assembly gem5 callgrind cachegrind
person Maxime Chéramy    schedule 03.04.2013    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Из руководства по cachegrind: 5.7.1. Особенности моделирования кэша

  • Инструкции, изменяющие ячейку памяти (например, inc и dec), считаются выполнением только чтения, то есть одной ссылки на данные. Это может показаться странным, но поскольку запись никогда не может привести к промаху (чтение гарантирует, что блок находится в кеше), это не очень интересно.

    Таким образом, он измеряет не количество обращений к кэшу данных, а количество возможных промахов кэша данных.

Может показаться, что логика имитации кеша callgrind отличается от cachegrind. Я думаю, что callgrind должен давать те же результаты, что и cachegrind, так что, может быть, это ошибка?

person Neopallium    schedule 21.05.2013
comment
Это точно мои мысли. Возможно баг, но это удивительно. Они дважды писали симуляцию кеша? - person Maxime Chéramy; 24.05.2013
comment
Из того, что я вижу, кажется, что они реализовали по крайней мере часть симуляции кеша дважды. Я не до конца понимаю логику преобразования и инструментов VEX IR. - person Neopallium; 25.05.2013

arrow_upward
-1
arrow_downward

callgrind по умолчанию не выполняет полную симуляцию кеша. см. здесь: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.cachesimulation

Чтобы включить доступ для чтения данных, вам нужно добавить --cache-sim=yes для callgrind. Сказав это, зачем вообще использовать callgrind в этом коде? Нет ни одного вызова функции (для чего и нужен callgrind)

person andrjas    schedule 22.04.2013
comment
Добавление cache-sim=yes ничего не меняет: указание размеров кеша автоматически активирует симуляцию кеша. - person Maxime Chéramy; 24.04.2013