Re: [問題] Cache size量測小程式數據解釋

看板C_and_CPP作者時間4年前 (2019/08/10 22:19), 4年前編輯推噓1(102)
留言3則, 1人參與, 4年前最新討論串2/3 (看更多)
上面有推文說這篇做 GPU 黑箱測試的方法 可以測試出 cache 大小、way 數等等的資訊 (Figure 1) https://mc.stanford.edu/cgi-bin/images/6/65/SC08_Volkov_GPU.pdf 因為這篇有點久之前看的了,有點印象模糊 重新讀了一遍,想說自己來回一下好了 -- 從原 po 的系統中可以看到 L1 = 32KB, 64B line, 8-way L2 = 256KB, 64B line, 8-way 因為你說最大只有測試 256KB,所以不用考慮 L3 首先「為什麼從64到512時間幾乎都沒有改變」 我猜,這個可能是因為 CPU 可以同時偷跑很多指令 可能偷跑到後面的時候就會先幫你抓進來到 L1,也就是你查到的 prefetch 導致根本是 CPU 的指令速度決定最終速度 (CPU bound) 我貼的那 paper 中 GPU 也是有一段上升的區間 (1K~4K) 這段代表 CPU bound -> memory bound 的過程 但是沒有前面水平 (64-512) 那段 或許是 GPU 天性設計,可以偷跑的指令數量很少的緣故 -- 可是到了 4096 之後又速度會下來,這是怎麼回事呢 來看一下 4096, 8192 在 L1 32K, 8-way cache 的行為 也就是說 cache index 是 4KB 一個循環 0, 4096, 8192, ... (64 個一循環) 0, 8192, 16384, ... (32 個一循環) 這些其實都是放在 index 0 的那個 set 所以在 stride 4096 的時候打架最嚴重 有 64 個人想要搶八個位子 現代 cache 很多都是用某些隨機機制踢掉的 所以如果打架的人變少了,速度就會在統計上變快 到了最後那個 array size/stride = 256KB/32768 = 8,因為 8-way cache 的關係 資料基本上全部命中 L1 所以速度又回到一開始的等級了 以上,希望有回答到你的問題 ※ 引述《hsnuer1171 (humanforestQQ)》之銘言: : 開發平台(Platform): (Ex: Win10, Linux, ...) : Linux : 編譯器(Ex: GCC, clang, VC++...)+目標環境(跟開發平台不同的話需列出) : GCC : 額外使用到的函數庫(Library Used): (Ex: OpenGL, ...) : STL only : 問題(Question): : Stackoverflow 詳細內容: : https://stackoverflow.com/questions/57343855/program-to-measure-cache-size-please-explain-results/57344177#57344177 : 我寫了一個簡單的程式來量測Cache Line Size : 就是每次跳一個step (offset)去存取array, 透過加大offset來觀察執行時間 : 預計當offset超過cache line size時 : 會導致每次都要從下層(L2)抓一條新的cache line : Code: : void access_array(char* arr, int steps) : { : const int loop_cnt = 1024 * 1024 * 32; // arbitary loop count : int idx = 0; : for (int i = 0; i < loop_cnt; i++) : { : arr[idx] += 10; : idx = (idx + steps) & (ARRAY_SIZE - 1); : } : } : Result: : step , time(us) : 1 , 29929 : 2 , 30003 : 4 , 30410 : 8 , 30046 : 16 , 31987 : 32 , 36796 : 64 , 72008 : 128 , 72300 : 256 , 71439 : 512 , 71460 : 1024 , 126504 : 2048 , 156086 : 4096 , 212619 : 8192 , 188025 : 16384 , 155549 : 32768 , 46295 : 在64的時候執行時間增加兩倍, 因為我的cache line size = 64, 符合預期 : 我的問題是: : 為什麼從64到512時間幾乎都沒有改變, 而從1K開始到4K又遞增上去? : Array size是256KB, 我試過128KB / 64 / 32 都是一樣結果 : Stackoverflow上面的回應是覺得跟prefetch / TLB miss有關, : 我覺得解釋聽起來還算合理但是好像沒有辦法証明 : 我試著查過不少資料, 大多數是講理論沒有講到太詳細spec : 所以想請各位幫忙解惑... : 感謝 : CPU: Intel Xeon(R) CPU E5-2667 0 @ 2.90GHz : Cache size: : LEVEL1_ICACHE_SIZE 32768 : LEVEL1_ICACHE_ASSOC 8 : LEVEL1_ICACHE_LINESIZE 64 : LEVEL1_DCACHE_SIZE 32768 : LEVEL1_DCACHE_ASSOC 8 : LEVEL1_DCACHE_LINESIZE 64 : LEVEL2_CACHE_SIZE 262144 : LEVEL2_CACHE_ASSOC 8 : LEVEL2_CACHE_LINESIZE 64 : LEVEL3_CACHE_SIZE 15728640 : LEVEL3_CACHE_ASSOC 20 : LEVEL3_CACHE_LINESIZE 64 : LEVEL4_CACHE_SIZE 0 : LEVEL4_CACHE_ASSOC 0 : LEVEL4_CACHE_LINESIZE 0 -- Time waits for no one. ↑ (。A。)ハァ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.87.161 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1565446778.A.0D9.html ※ 編輯: johnjohnlin (118.160.87.161 臺灣), 08/10/2019 22:25:04

08/10 23:59, 4年前 , 1F
感謝!!!! 我一開始也是認為是通通都撞在stride 0導致
08/10 23:59, 1F

08/10 23:59, 4年前 , 2F
的 但是我有把array size調成16KB發現也是在stride=4K
08/10 23:59, 2F

08/10 23:59, 4年前 , 3F
的時候最慢 L1應該是裝的下的 請問你的看法是?
08/10 23:59, 3F
文章代碼(AID): #1TJj9w3P (C_and_CPP)
文章代碼(AID): #1TJj9w3P (C_and_CPP)