Conteggi di lettura e scrittura diversi utilizzando cachegrind e callgrind

Question

Sto facendo alcuni esperimenti con Cachegrind, Callgrind e Gem5. Ho notato che un certo numero di accessi sono stati contati come letti per cachegrind, come write per callgrind e sia per leggere che scrivere da gem5.

Facciamo un esempio molto semplice:

int main() { 
    int i, l; 

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

compilo con:

gcc ex.c --static -o ex

Quindi, fondamentalmente, secondo il il file asm, addl $1, -8(%rbp) viene eseguito 100.000 volte. Poiché è sia una lettura che una scrittura, mi aspettavo 100k di lettura e 100k di scrittura. Tuttavia, cachegrind conta solo come letti e callgrind solo come scrittura.

% 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% ) 

Qualcuno potrebbe darmi una spiegazione ragionevole? Sarei corretto considerare che ci sono in effetti ~ 100k read e ~ 100k write (cioè 2 accessi alla cache per un addl)?

Answer 1

callgrind non simula la cache completa per impostazione predefinita. vedere qui: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.cachesimulation

Per abilitare l'accesso alla lettura dei dati è necessario aggiungere --cache-sim = yes per callgrind. Detto questo, perché persino usare callgrind su questo codice? Non c'è una sola chiamata di funzione (che è ciò che callgrind è per)

Answer 2

From cachegrind manual: 5.7.1. Cache Simulation Specifics

• istruzioni che modificano una posizione di memoria (ad esempio, INC e DEC) sono contato come fare proprio una lettura, vale a dire un singolo riferimento di dati. Questo potrebbe sembrare strano, ma dato che la scrittura non può mai causare una mancanza (la lettura di garantisce che il blocco si trovi nella cache) non è molto interessante.

  Pertanto misura non il numero di accessi alla cache di dati, ma il numero di volte in cui si può verificare una perdita della cache di dati.

Sembrerebbe logica di simulazione di cache che callgrind è diverso da Cachegrind. Penserei che callgrind dovrebbe produrre gli stessi risultati di cachegrind, quindi forse questo è un bug?