Различные количества чтения и записи с использованием cachegrind и callgrind - программирование
Подтвердить что ты не робот

Различные количества чтения и записи с использованием 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 учитывает их только как read и 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 ​​кэша доступа для addl)?

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

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