Различные числа чтения и записи с использованием cachegrind и callgrind

Question

Я делаю несколько экспериментов с 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) 
    } 
} 

Я компилировать с:

НКА ex --static -o экс

Так в основном, в соответствии с asm file, 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)?

Answer 1

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

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

Answer 2

From cachegrind manual: 5.7.1. Cache Simulation Specifics

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

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

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