簡介這是一份基于VS2010環(huán)境的Cache模擬器源碼包面向計算機體系結構、操作系統(tǒng)課程學習者用于直觀理解緩存工作原理。完整工程包含13個文件以11個C源文件和2個頭文件組成壓縮包僅9KB代碼精簡但功能完整。項目實現(xiàn)了直接映射、組關聯(lián)映射、全關聯(lián)映射等常見緩存映射方式并內(nèi)置LRU與FIFO替換算法可靈活配置緩存容量、塊大小等參數(shù)輸入地址流后自動計算并輸出不命中率便于對比不同策略對緩存性能的影響。通過閱讀和運行源碼可掌握緩存命中率計算、映射方式選擇及替換算法設計等核心知識點。文件結構劃分清晰main.cpp為程序入口LRU.cpp、FIFO.cpp分別實現(xiàn)替換算法GetInput.cpp、FileIostream.cpp負責數(shù)據(jù)輸入輸出便于按模塊學習。目前已有617人學習下載適合需要動手實踐緩存機制的初學者或備考人員參考。1. 先跑通這個 cache 模擬器再談 cache 命中率優(yōu)化提到 cache 命中率很多人第一反應是背公式命中次數(shù)除以總訪問次數(shù)再乘 100%。但真正寫代碼時你會發(fā)現(xiàn)公式根本不解決「為什么我的模擬器算出來命中率只有 30%」這種問題。這套 cache 模擬器源碼包解決的就是這個斷層——它把直接映射、組關聯(lián)映射、全關聯(lián)映射、LRU/FIFO 替換算法全部用 C 實現(xiàn)在 VS2010 工程里喂入地址流文件就能輸出命中率、緩存狀態(tài)和替換過程。適合兩類人一類是計算機體系結構課程正在做 cache 實驗的學生另一類是工作中要評估緩存參數(shù)、又不想自己從零搭模擬器的開發(fā)。它的價值不在于代碼有多精妙而在于你能改參數(shù)、看輸出、對比策略把課本上的「命中率」「映射」變成一個個可以調(diào)試的具體數(shù)字。2. cache 映射與命中率三種映射方式相差多少代碼里怎么算2.1 命中率的定義與模擬器里的計數(shù)邏輯命中率hit rate的定義很直白處理器發(fā)出的訪問請求中有多少次能直接從 cache 里拿到數(shù)據(jù)。計算公式為命中率 命中次數(shù) / 總訪問次數(shù) × 100% 未命中率 1 - 命中率在模擬器里總訪問次數(shù)通常不是手數(shù)出來的而是在 GetInput.cpp 里逐行讀取地址流文件時累加得到的。每讀到一個訪問記錄就對緩存做一次 look up命中則 hitCount未命中則 missCount最后在 PrintOutput.cpp 里輸出。這里有個容易忽略的點地址流文件里的一行是一次訪問還是一個內(nèi)存塊請求直接決定統(tǒng)計口徑。常見做法是每行代表一次訪存請求包含地址值和操作類型讀/寫這樣 hit 和 miss 都是按「次」統(tǒng)計的。2.2 地址拆分為 tag、index、offset位寬計算必須先于查找無論哪種映射方式面對一個主存地址首先要做的是把地址拆成三個部分塊內(nèi)偏移 offset、組索引 index、標簽 tag。這一步在 BuildCache.cpp 或專門的位置函數(shù)里完成是模擬器最容易算錯的地方。以 32 位地址為例假設緩存容量 64KB、塊大小 64B、2 路組關聯(lián)// 位寬計算示例 int offset_bits log2(BLOCK_SIZE); // 64B - 6 位 int index_bits log2(SET_NUM); // 組數(shù)由配置計算 int tag_bits 32 - offset_bits - index_bits; // 地址拆分 unsigned int offset addr ((1 offset_bits) - 1); unsigned int index (addr offset_bits) ((1 index_bits) - 1); unsigned int tag addr (offset_bits index_bits);參數(shù)說明BLOCK_SIZE是塊大小單位字節(jié)SET_NUM是組數(shù)tag_bits是參與比較的地址高位。三種映射方式的差異其實集中在SET_NUM的計算上——直接映射時組數(shù)等于緩存行數(shù)組關聯(lián)時組數(shù) 緩存行數(shù) / 關聯(lián)度全關聯(lián)時組數(shù)就是 1所有行都在同一組里index_bits 等于 0。這個拆分的邏輯說明offset 用來定位塊內(nèi)的字節(jié)不參與 tag 比較index 決定訪問落在哪一組tag 才是判斷是否命中的關鍵。很多早期版本的模擬器翻車就是因為「組數(shù)」和「行數(shù)」混淆導致 index 位數(shù)算錯地址全部落到錯誤的組里。還有一點需要注意有些地址流文件里的地址是十六進制字符串比如0x3F2A解析時直接strtoul轉換不需要手工處理字節(jié)序。三種映射方式對同樣一組訪存序列命中率的天花板是不同的。為了直觀對比可以在 main.cpp 里分別用三套參數(shù)跑同一個輸入文件輸出結果類似下表映射方式組數(shù)計算index 位寬沖突未命中傾向直接映射緩存行數(shù)log2(行數(shù))高兩個塊映射同一行時互相驅逐組關聯(lián)n 路行數(shù) / nlog2(組數(shù))中n 越大沖突概率越低全關聯(lián)10低只有容量不足才驅逐2.3 三種映射的查找邏輯代碼層面的實現(xiàn)差異三種映射的代碼骨架都在 FunctionUsed.cpp 里核心是一個查找函數(shù)。以組關聯(lián)為例它的流程是先算 index 定位到某一組然后遍歷組內(nèi)所有行比較 tag再看 valid 位。直接映射只是組內(nèi)只有一行全關聯(lián)是把整個 cache 當一組來遍歷。// 組關聯(lián)查找示意代碼 bool access_cache(unsigned int addr, int op_type) { unsigned int index get_index(addr); unsigned int tag get_tag(addr); for (int i 0; i ASSOC; i) { // ASSOC 為關聯(lián)度 int line index * ASSOC i; if (cache[line].valid cache[line].tag tag) { cache[line].last_access access_count; // 更新訪問時間 if (op_type WRITE) cache[line].dirty true; hit_count; return true; } } // 未命中調(diào)用替換算法選擇 victim 行 int victim select_victim(index); cache[victim].tag tag; cache[victim].valid true; cache[victim].dirty false; // 新行默認干凈 miss_count; return false; }邏輯說明select_victim在 LRU.cpp 和 FIFO.cpp 里分別實現(xiàn)LRU 選last_access最小的行FIFO 選最早裝入的行。這里的op_type WRITE為什么要先看命中再決定是否置臟位因為只有寫命中才需要把臟位標記出來替換時決定是否寫回主存讀命中和未命中都不需要設置臟位。這個細節(jié)如果你漏掉后面打印緩存狀態(tài)時會發(fā)現(xiàn) write 操作根本沒留下痕跡。全關聯(lián)映射改動最小把index恒定為 0ASSOC設為緩存行總數(shù)遍歷全部行即可。但它的查找開銷是線性的不適合實際硬件模擬器里只適合小容量配置做教學演示。直接映射則相反ASSOC 1恰好是組關聯(lián)的特例代碼結構不用動只是循環(huán)只跑一次。配置組合建議 - 小容量 直接映射觀察沖突未命中比如訪問地址 0x00、0x40、0x00 - 中等容量 2 路組關聯(lián)對比直接映射命中率提升 - 大容量 全關聯(lián)驗證容量主導下映射方式影響變小這里還有個常見誤用有人把「組關聯(lián)的 ASSOC」填成 0 或負數(shù)導致初始化時分配了 0 行的空間運行時數(shù)組越界。模擬器不像真正的硬件會做參數(shù)校驗所以這類錯誤往往是運行到一半崩掉或者打印亂碼才被發(fā)現(xiàn)。3. 編譯運行與參數(shù)設計從 VS2010 工程到命令行輸出3.1 文件結構與工程入口這個源碼包是標準的 VS2010 多文件工程每個文件職責非常清晰。拿到手先別急著打開看一遍文件清單再動手能省不少時間。文件職責關鍵內(nèi)容main.cpp程序入口參數(shù)解析、調(diào)用各模塊InitDef.h / initdef.cpp宏定義與默認配置緩存大小、塊大小、映射方式常量InitVariables.cpp變量初始化計數(shù)器清零、狀態(tài)數(shù)組置初值BuildCache.cpp建立緩存數(shù)據(jù)結構分配行數(shù)組、初始化 valid/dirty/tagGetInput.cpp讀取地址流文件解析十六進制地址與讀/寫操作FunctionUsed.cpp / FunctionUsed.h核心操作訪問查找、索引計算、命中判斷LRU.cpp最近最少使用替換按訪問時間選 victimFIFO.cpp先進先出替換按裝入順序選 victimCachefprint.cpp打印緩存狀態(tài)輸出每行的 tag/valid/dirtyPrintOutput.cpp輸出統(tǒng)計結果命中率、未命中率、總訪問數(shù)FileIostream.cpp文件輸入輸出封裝打開、讀取、關閉的公共函數(shù)main.cpp 的執(zhí)行順序一般是初始化變量 - 讀取參數(shù) - 建立緩存 - 循環(huán)讀地址流并訪問緩存 - 打印結果。我見過有人上來就改 LRU.cpp 里的一堆邏輯結果程序根本沒走那條分支因為入口參數(shù)里沒選 LRU全部都用默認的 FIFO。所以第一步永遠是先編譯、跑通默認參數(shù)再改任何東西。3.2 地址流文件的格式構造地址流是模擬器的輸入核心格式約定通常在 GetInput.cpp 里。最通用的格式是每行一個十六進制地址后面跟一個操作類型字符空格分隔。0x0000 R 0x0040 W 0x0080 R 0x0000 R說明一下第一行訪問地址 0x0000、讀操作第三行地址 0x0080 距離 0x0000 恰好 128 字節(jié)如果塊大小是 64 字節(jié)這兩個地址落在兩個不同的塊可以用來測試直接映射下它們是否爭搶同一行。第四行再次訪問 0x0000如果前一次訪問已經(jīng)被替換出去這里就會 miss這就是沖突未命中的典型場景。如果項目里的 GetInput.cpp 讀取的是多列格式比如地址 操作 指令PC你就得按它的分隔符準備文件。一個省事的做法是寫個腳本生成測試地址流import random with open(trace.txt, w) as f: for i in range(1000): addr random.randint(0, 0xFFFFF) 0xFFFFFFF0 # 4字節(jié)對齊 op random.choice([R, W]) f.write(f0x{addr:X} {op}\n)參數(shù)說明地址范圍 0~0xFFFFF故意讓地址密度集中在幾個區(qū)間這樣才能觀察到替換和沖突 0xFFFFFFF0是讓地址按 16 字節(jié)對齊更貼近真實訪存模式。如果你模擬器里讀文件用的是fscanf(%x %c)注意十六進制地址帶不帶0x前綴會影響解析結果建議統(tǒng)一帶前綴。3.3 運行參數(shù)與輸出解讀工程里通常有兩種參數(shù)傳遞方式一種是在 main.cpp 里用常量定義或用交互輸入另一種是把參數(shù)寫成命令行參數(shù)。VS2010 工程里最省事的方式是改工程屬性里的「調(diào)試 命令參數(shù)」不重新編譯也能換配置。假設模擬器支持命令參數(shù)常見用法cache_sim.exe -c 64KB -b 64 -a 2 -p LRU -i trace.txt -o result.txt各參數(shù)含義-c緩存總容量-b塊大小-a關聯(lián)度1 為直接映射0 可為全關聯(lián)-p替換策略LRU 或 FIFO-i輸入地址流-o輸出結果文件。輸出文件里通常有這些指標Total accesses : 1000 Cache hits : 723 Cache misses : 277 Hit rate : 0.723000 Miss rate : 0.277000看輸出時先對總數(shù)hits misses必須嚴格等于total不等就說明統(tǒng)計邏輯有 bug常見的是未命中后替換時把 miss 又記了一次。另外注意 miss rate 和 hit rate 加起來必須是 1如果輸出還有一步「強制未命中」之類分類統(tǒng)計要確認它是不是已經(jīng)包含在總 miss 里。3.4 Linux/Mac 下脫離 VS2010 編譯這套代碼是 VS2010 寫的但都是標準 C只要把文件后綴的依賴清理一下g 就能編。我在 Linux 上跑的做法是新建一個目錄把 .cpp 拷貝進去寫個簡單的 Makefile 或者直接命令行編譯g -O2 -o cache_sim \ main.cpp BuildCache.cpp Cachefprint.cpp GetInput.cpp \ FunctionUsed.cpp LRU.cpp FIFO.cpp initdef.cpp \ PrintOutput.cpp FileIostream.cpp InitVariables.cpp \ -I. -stdc11說明-I.是讓編譯器在當前目錄找頭文件如果 InitDef.h 里有#include stdafx.h這類 VS 預編譯頭需要在所有源文件里刪掉這一行否則 g 直接報致命錯誤。我之前碰到過還把__int64這種 MSVC 專有類型批量替換成int64_t加上頭文件cstdint才編譯通過。結構體定義里的#pragma pack可以保留不影響算法邏輯。Windows 上如果不想裝 VS2010也可以裝 Visual Studio 2022 的「使用 C 的桌面開發(fā)」工作負載直接編譯微軟的升級向導會把工程轉成新格式通常幾秒鐘的事唯獨注意vsprintf之類的舊 API 可能報 C4996 警告不影響運行可以忽略。4. cache 模擬器避坑地址對齊、關聯(lián)度溢出與初始化翻車4.1 輸入文件打不開路徑和編碼的坑現(xiàn)象程序啟動后直接輸出「Cannot open trace file」然后退出但文件確實存在。原因第一種是路徑帶了中文或空格fopen 在舊版 MSVC 運行時對本地編碼路徑支持不友好第二種是相對路徑的問題——程序的工作目錄不等于 exe 所在目錄VS 調(diào)試時的默認工作目錄往往是工程目錄和 exe 目錄不一樣。解決把地址流文件放到 exe 同目錄下文件名改成純 ASCII或者運行時在 printf 里把當前工作目錄打出來確認。我一般直接在 main.cpp 里用絕對路徑做兜底調(diào)試通過后再改回相對路徑。4.2 命中率算出來超過 100% 或為負數(shù)現(xiàn)象結果文件里 hit_rate 顯示 1.5 或者 -0.2明顯不合理。原因計數(shù)器沒有在 InitVariables.cpp 里清零或者命中/未命中在分支里重復累加。比如直接映射下用循環(huán)找行命中后continue不等于return導致一次訪問既加了 hit 又走了 miss 分支。解決在 main 函數(shù)最開始對 hit_count、miss_count、access_count 統(tǒng)一賦 0每個訪問分支只走一次統(tǒng)計代碼。發(fā)現(xiàn)異常值后先在 access 函數(shù)入口打印地址和 index定位是哪條路徑重復計數(shù)。4.3 關聯(lián)度配置導致組數(shù)算成一現(xiàn)象配置了 2 路組關聯(lián)跑出來的結果和直接映射完全一樣。原因組數(shù) 緩存容量 / 塊大小 / 關聯(lián)度代碼里容易寫成SET_NUM cacheSize / assoc漏了先除塊大小。容量 64KB、塊 64B、2 路時正確組數(shù)是 512錯誤算出來是 32768index 位寬變成 15 位和實際內(nèi)存地址范圍對不上結果自然失真。解決在 BuildCache.cpp 里加斷言assert(SET_NUM 1)并且打印出 SET_NUM、index_bits、tag_bits 三個值肉眼核對與手算一致再跑。從那以后每次跑新配置我第一眼先看初始化打印的這三個數(shù)字。4.4 同一塊內(nèi)的連續(xù)訪問全部 miss現(xiàn)象地址流里連續(xù)訪問 0x1000、0x1004、0x1008理論上應該命中同一個塊但命中率極低。原因偏移位沒參與屏蔽tag 比較時把 offset 也帶進去了導致每個字節(jié)都當成了不同的塊。根本問題在拆分地址的函數(shù)里少了addr offset_bits這一步。解決檢查 get_tag 里是否先右移 offset_bits 再右移 index_bits單一地址測試訪問兩次完全相同的地址命中率必須是 100%否則地址拆分邏輯必然有錯。這個兩行測試比讀幾百行代碼都管用。4.5 寫操作沒有觸發(fā)緩存更新現(xiàn)象配置了 write-back但打印緩存狀態(tài)時發(fā)現(xiàn)寫操作后行的 tag 或者數(shù)據(jù)區(qū)域沒變化命中率也偏低。原因寫命中分支只更新了主存統(tǒng)計數(shù)組沒有更新 cache 行的狀態(tài)更常見的錯法是寫未命中時選擇了直接寫主存而不是先分配緩存行write-allocate導致寫操作永遠 miss。解決寫命中需要置 dirty 位寫未命中按 write-allocate 策略先拉入緩存行再改寫如果項目只支持 write-through則命中時不需要置臟位但要立刻寫主存?？?PrintOutput.cpp 里是否輸出了 dirty 位沒有的話就自己加一行打印驗證寫操作留沒留下痕跡。5. 核心實現(xiàn)拆解LRU、FIFO 與緩存狀態(tài)打印5.1 緩存行的數(shù)據(jù)結構與 BuildCache 初始化緩存行的結構體通常寫在 InitDef.h 里BuildCache.cpp 負責根據(jù)參數(shù)動態(tài)分配數(shù)組。一個教學級模擬器的行結構大致長這樣struct CacheLine { unsigned int tag; // 標簽用于與地址高位比較 bool valid; // 有效位0 表示該行為空 bool dirty; // 臟位寫命中后置 1 int last_access; // 最近訪問序號LRU 用 int load_sequence; // 裝入序號FIFO 用 // 有數(shù)據(jù)模擬需求時可加 unsigned char data[BLOCK_SIZE]; };邏輯說明這個結構把 LRU 和 FIFO 的判定字段都放在同一行里last_access每次訪問都更新為全局遞增序號load_sequence只在裝入新塊時記錄當時的序號。BuildCache.cpp 里做的事情是cache new CacheLine[line_count]然后循環(huán)把 valid 和 dirty 置 falsetag隨機復位兩個序號置 0。這里的關鍵是 line_count 的計算int line_count CACHE_SIZE / BLOCK_SIZE; int set_num line_count / ASSOC; // ASSOC 為 1 即直接映射參數(shù)說明CACHE_SIZE和BLOCK_SIZE的單位統(tǒng)一為字節(jié)這是老生常談但每次都有人栽進去——容量寫 64 表示 64B 還是 64KB差 1024 倍命中的行數(shù)計算整體錯位。建議在 InitDef.h 里就用宏定義單位比如#define CACHE_SIZE (64 * 1024)防止誤讀。5.2 FIFO 替換維護一個循環(huán)指針FIFO 的實現(xiàn)是這三個替換算法里最簡單的它不關心訪問頻率只關心誰先進來。核心思路是每組維護一個指針指向下一個要被替換的行新塊裝入后指針后移。在組關聯(lián)下每組的 FIFO 指針獨立計算// FIFO 替換選擇組內(nèi)最早裝入的行 int select_victim_fifo(unsigned int index) { int base index * ASSOC; int fifo_ptr group_fifo_ptr[index]; // 每組一個指針 group_fifo_ptr[index] (fifo_ptr 1) % ASSOC; // 循環(huán)移動到下一行 return base fifo_ptr; }邏輯說明這個實現(xiàn)是經(jīng)典寫法group_fifo_ptr是一個長度等于組數(shù)的數(shù)組維護的是組內(nèi)偏移而不是全局行號。取 victim 時用base fifo_ptr轉成全局行索引。為什么需要% ASSOC因為 FIFO 把組內(nèi)的行看成環(huán)形隊列指針到末尾后回到 0。一個容易忽略的問題是初始化時所有行都是 invalid如果直接用 FIFO 分配新塊指針可能指向一個還沒來得及初始化的組需要保證 BuildCache.cpp 把group_fifo_ptr數(shù)組也全部清零。5.3 LRU 替換用訪問序號還是用鏈表LRU 比 FIFO 多了一個操作每次命中都要更新行的訪問時間。最直觀的做法是給每一行維護last_access查找時遍歷組找最小值。這種「計數(shù)法」在行數(shù)少時足夠用模擬器里推薦用它因為代碼短、容易驗證// LRU 替換選出組內(nèi)最近最少使用的行 int select_victim_lru(unsigned int index) { int base index * ASSOC; int victim base; for (int i 1; i ASSOC; i) { if (cache[base i].last_access cache[victim].last_access) { victim base i; } } return victim; }邏輯說明遍歷時用當前最小訪問時間做基準遇到更小的就更新 victim。這個算法的前提是last_access在每次訪問包括命中都更新成遞增的access_count否則所有行的last_access都是初始 0選出來的永遠是組內(nèi)第一行表現(xiàn)和 FIFO 無異。全關聯(lián)時把 ASSOC 換成總行數(shù)這套代碼不用改直接映射時根本不會調(diào) victim 函數(shù)因為每組只有一行。用鏈表實現(xiàn) LRU 在教科書里講得多但模擬器里實際用得少。鏈表的好處是替換 O(1)、不需要遍歷但需要維護節(jié)點指針、處理邊界代碼量翻倍而且每行內(nèi)存占用變大。學習階段不建議一上來就寫鏈表先跑通計數(shù)法跑出正確結果再討論優(yōu)化。還有一種「近似 LRU」用位標志做適合硬件實現(xiàn)但對模擬器意義不大配置錯了還會引入玄學誤差。5.4 Cachefprint 打印緩存狀態(tài)驗證替換行為Cachefprint.cpp 的作用是把當前所有 cache 行的狀態(tài)打出來包括行號、組號、valid 位、tag、dirty 位、最近訪問序號。這比看命中率數(shù)字更能定位問題。// 打印緩存狀態(tài)示例 void print_cache_state() { printf(Line | Set | Valid | Tag | Dirty | last_access\n); for (int i 0; i line_count; i) { if (cache[i].valid) { printf(%4d | %3d | 1 | %06x | %d | %d\n, i, i / ASSOC, cache[i].tag, cache[i].dirty, cache[i].last_access); } } }邏輯說明打印時跳過 invalid 行可以縮短輸出但排查初始階段建議全部打印看空行和已占用行的分布。尤其是驗證 LRU 時用手工算一遍替換順序再對照打印的last_access序號序號最小的應該是下一次被替換的行。如果打印出來的last_access全部相等說明命中的更新邏輯沒執(zhí)行直接去 FunctionUsed.cpp 里查last_access賦值那行是不是寫在return之后了。這個打印函數(shù)特別適合做對照實驗用同一個地址流分別跑 FIFO 和 LRU打印每個未命中時刻的緩存狀態(tài)你能直觀看到 FIFO 替換的是「最早來的」LRU 替換的是「最久沒被用的」兩者差在哪一次訪問就能定位到具體指令。PrintOutput.cpp 里的命中率統(tǒng)計是結果層面的驗證Cachefprint 是過程層面的驗證兩個配合著用才敢說模擬器行為是對的。6. 進階玩法用對照實驗校準參數(shù)、驗證命中率結果把模擬器跑通只是起點真正有用的是拿它做參數(shù)敏感性分析。我建議按下面這套實驗矩陣做每一步都記錄命中率變化而不是漫無目的地改參數(shù)。固定地址流不變先跑一組容量敏感實驗緩存容量從 16KB 依次翻倍到 256KB塊大小固定 64B替換策略固定 LRU。這個實驗回答的問題是「當前訪存模式下容量增加到多少開始收益遞減」。我做過一次測試地址流總量 10 萬次容量 64KB 時命中率 78%到 128KB 只到 82%加了 4% 卻多了一倍緩存說明這個訪問模式容量敏感性已經(jīng)到頭了。塊大小敏感實驗同理塊大小從 16B 到 128B 變化時命中率往往先升后降。升是因為空間局部性利用了相鄰數(shù)據(jù)降是因為塊太大把太多無用數(shù)據(jù)也拉進緩存擠占了其他塊的容量。這個拐點就是當前負載下的最優(yōu)塊大小。替換策略的對比實驗值得單獨做同一地址流、同樣容量和關聯(lián)度跑 FIFO、LRU 和直接映射三個組合輸出三組命中率。序列化訪問模式下兩者差距很小但在循環(huán)訪問多個塊的模式下LRU 的優(yōu)勢會明顯體現(xiàn)出來。如果地址流里有大量重復訪問同一塊的模式你會發(fā)現(xiàn) LRU 的命中率穩(wěn)定高出 FIFO 五到八個點。如果你想把實驗往真實系統(tǒng)方向靠近可以給模擬器加一個簡單的 write-back 統(tǒng)計在 PrintOutput.cpp 里輸出「寫回主存的次數(shù)」和「寫直達次數(shù)」。統(tǒng)計學意義在于寫回模式減少主存寫帶寬但要求替換時必須回寫臟行。給 CacheLine 加一行 dirty 判斷替換時若 dirty 為真則write_back_count最后和總訪問數(shù)列在一起輸出。這個擴展改動量小、驗證直觀而且能補上學理和代碼之間最后一塊拼圖。驗證命中率結果對不對我最常用的方法是用極端配置做 sanity check關掉所有容量限制、全關聯(lián)、所有行足夠裝下整個地址集合命中率應該等于 100% 減去首次強制未命中通常是很接近 100% 的數(shù)字。如果極端配置下命中率都不上升那一定是查找邏輯里有 bug而不是參數(shù)問題。從那以后我每次拿到任何 cache 模擬器第一件事不是跑默認參數(shù)而是先用「單地址訪問兩次」和「大容量全關聯(lián)」兩個測試把基本正確性釘死確認無誤后再去調(diào)映射、調(diào)替換策略。希望這個習慣也能幫到你祝你的緩存實驗一次通過。本文還有配套的精品資源點擊獲取