Số đọc và ghi khác nhau sử dụng cachegrind và callgrind

Question

Tôi đang thực hiện một số thử nghiệm với Cachegrind, Callgrind và Gem5. Tôi nhận thấy rằng một số truy cập được tính là đã đọc cho cachegrind, như viết cho callgrind và cho cả đọc và viết bởi gem5.

Hãy lấy một ví dụ rất đơn giản:

int main() { 
    int i, l; 

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

tôi biên dịch với:

gcc ex.c --static -o cũ

Vì vậy, về cơ bản, theo tập tin asm, addl $1, -8(%rbp) được thực hiện 100.000 lần. Vì nó là cả đọc và viết, tôi đã mong đợi 100k đọc và viết 100k. Tuy nhiên, cachegrind chỉ đếm chúng như đã đọc và callgrind chỉ khi viết.

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

Có thể ai đó cho tôi một lời giải thích hợp lý? Tôi có chính xác để xem xét có trong thực tế ~ 100k lần đọc và ~ 100k viết (tức là 2 bộ nhớ cache truy cập cho một addl)?

Answer 1

callgrind không mô phỏng bộ nhớ cache đầy đủ theo mặc định. xem tại đây: http://valgrind.org/docs/manual/cl-manual.html#cl-manual.options.cachesimulation

Để bật truy cập đọc dữ liệu, bạn cần phải thêm --cache-sim = yes cho callgrind. Có nói điều này, tại sao thậm chí sử dụng callgrind trên mã này? Không có một cuộc gọi chức năng duy nhất (đó là những gì callgrind là cho)

Answer 2

From cachegrind manual: 5.7.1. Cache Simulation Specifics

• dẫn mà sửa đổi một vị trí bộ nhớ (ví dụ inc và tháng mười hai) được tính là làm chỉ là một đọc, tức là một tham chiếu dữ liệu duy nhất. Điều này có thể có vẻ lạ, nhưng kể từ khi viết không bao giờ có thể gây ra một miss (đọc đảm bảo khối là trong bộ nhớ cache) nó không phải là rất thú vị.

  Do đó, nó đo lường số lần truy cập bộ nhớ cache dữ liệu, nhưng số lần bỏ lỡ bộ nhớ cache dữ liệu có thể xảy ra.

Có vẻ như Logic mô phỏng bộ nhớ cache của callgrind đó là khác nhau từ cachegrind. Tôi sẽ nghĩ rằng callgrind sẽ tạo ra kết quả tương tự như cachegrind, vì vậy có lẽ đây là một lỗi?