Verschiedene Lese- und Schreibzähler mit Cachegrind und Callgrind

Question

Ich mache einige Experimente mit Cachegrind, Callgrind und Gem5. Ich habe bemerkt, dass eine Anzahl von Zugriffen als gelesen für Cachegrind gezählt wurde, als Schreiben für Callgrind und für sowohl Lesen als auch Schreiben von Gem5.

Lassen Sie uns ein sehr einfaches Beispiel:

int main() { 
    int i, l; 

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

ich kompilieren mit:

gcc Ex.C --static -o ex

Also im Grunde, nach der asm-Datei, addl $1, -8(%rbp) wird 100.000 mal ausgeführt. Da es sowohl ein Lese- als auch ein Schreibvorgang ist, erwartete ich 100k Lesen und 100k Schreiben. Cachegrind zählt sie jedoch nur als Lese- und Aufrufgrind nur als Schreibvorgang.

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

Könnte mir jemand eine vernünftige Erklärung geben? Würde ich richtigerweise in Betracht ziehen, dass tatsächlich ~ 100k Lesevorgänge und ~ 100k Schreibvorgänge (d. H. 2 Cache-Zugriffe für ein add1) vorhanden sind?

Answer 1

callgrind führt standardmäßig keine vollständige Cache-Simulation durch. siehe hier: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.cachesimulation

Um den Datenlesezugriff zu aktivieren, müssen Sie --cache-sim = yes für Callgrind hinzufügen. Nachdem dies gesagt wurde, warum verwenden Sie sogar Callgrind für diesen Code? Es gibt nicht einen einzigen Funktionsaufruf (was Callgrind für ist)

Answer 2

From cachegrind manual: 5.7.1. Cache Simulation Specifics

• Anweisungen, die einen Speicherplatz (zB inc und Dezember) modifizieren als gerade dabei eine Lese gezählt, dh eine einzelne Datenreferenz. Dies mag seltsam erscheinen, aber da der Schreibvorgang nie einen Fehler verursachen kann (der Wert garantiert, dass der Block im Cache ist), ist es nicht sehr interessant.

  So misst es nicht die Anzahl der Male, die der Datencache zugegriffen wird, , aber die Anzahl der Male ein Datencache Miss konnte auftreten.

Es wäre das Callgrind die scheinen Logik Cache Simulation von cachegrind unterscheidet. Ich würde denken, dass Callgrind die gleichen Ergebnisse wie Cachegrind produzieren sollte, also ist das vielleicht ein Fehler?