Różne liczby odczytywania i zapisywania za pomocą cachegrind i callgrind

Question

Robię kilka eksperymentów z Cachegrind, Callgrind i Gem5. Zauważyłem, że liczba wejść była liczona jako odczyt dla cachegrind, jako zapis dla callgrind oraz dla odczytu i zapisu gem5.

Weźmy bardzo prosty przykład:

int main() { 
    int i, l; 

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

skompilować z:

gcc -o ex.c --static ex

Więc w zasadzie, zgodnie z plik ASM, addl $1, -8(%rbp) jest wykonywany 100 000 razy. Ponieważ jest to zarówno czytanie, jak i pisanie, spodziewałem się 100 000 odczytów i 100 000 wpisów. Jednak cachegrind liczy je tylko jako odczyt i wywołanie tylko w formie zapisu.

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

Może ktoś mi dać rozsądny wyjaśnienie? Czy mam rację biorąc pod uwagę fakt, że w rzeczywistości istnieje ~ 100 000 odczytów i ~ 100 000 zapisów (tj. 2 dostępy do pamięci podręcznej dla dodatku)?

Answer 1

callgrind nie domyślnie symuluje pełną pamięć podręczną. zobacz tutaj: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.cachesimulation

Aby włączyć dostęp do odczytu danych, musisz dodać --cache-sim = yes dla callgrind. Powiedziawszy to, dlaczego używasz callgrind na tym kodzie? Nie jest to pojedynczy wywołanie funkcji (co jest co callgrind jest)

Answer 2

From cachegrind manual: 5.7.1. Cache Simulation Specifics

• Instrukcje, które modyfikują lokalizację pamięci (np INC i DEC) są liczone jak robi tylko do odczytu, tj. pojedyncze odniesienie do danych. To może wydawać się dziwne, ale ponieważ zapis nie może nigdy spowodować błędu (czytamy, że blok jest w pamięci podręcznej), nie jest to zbyt interesujące.

  W ten sposób mierzona jest nie tyle liczba razy, ile jest dostępna pamięć podręczna danych, , ale liczba wystąpień pominięcia pamięci podręcznej danych.

Wydaje się logika symulacji cache tego callgrind różni się od cachegrind. Myślę, że callgrind powinien dawać takie same wyniki jak cachegrind, więc może to jest błąd?