本節書摘來自異步社區《現代體系結構上的UNIX系統：內核程序員的對稱多處理和緩存技術（修訂版）》一書中的第2章，第2.11節，作者：【美】Curt Schimmel著，更多章節內容可以訪問云棲社區“異步社區”公眾號查看

2.11 高速緩存的性能

雖然全面討論高速緩存的性能超出了本書的范圍，但還是可以做以下一些觀察。首先，高速緩存的性能不僅取決于高速緩存的設計，而且取決于應用程序的引用模式。因此，必須謹慎地通過測試基準程序來判定高速緩存的性能以及一般化測試結果。雖然很容易編寫一個獲得100%命中率的基準程序，但是把它們運用到實際應用中的時候，這樣的結果是毫無意義的。例如，下面的程序會獲得100%的高速緩存命中率：

while (1);

循環執行一次之后，所有的指令引用都會在高速緩存中命中。相反，下面的代碼片段給一個數組中的每個元素都乘以常數c，因而會得到相當低的高速緩存命中率（假定數組要比高速緩存大）。

for ( j=0; j < YMAX; j++)for ( i=0; i < XMAX; i++)matrix[i][j] *= c;

因為在C語言中，數組是按行來保存的，在使用高速緩存的時候，如果數組中一行的大小超過了高速緩存行的長度（假定一開始數組沒有被高速緩存），那么每次執行最里面的語句就會出現一次缺失。這樣的情形尤其糟糕，因為行很長的高速緩存會讀取大量從來都不會用到的數據。互換兩層for循環會因為空間局部性而提高性能。即使每個元素只讀取一次，高速緩存每次都要讀取整整一行的事實也意味著引用連續的元素可能會產生一次命中。例外的情況是那些行很小的高速緩存，像MIPS R2000/R3000，它們的每個高速緩存行只有4字節。如果數組matrix的每個元素也是4字節，那么就沒有空間局部性的好處了。

即使高速緩存的性能是依賴于應用的，在直覺上還是可以有下面的結論（雖然對于所有應用來說，它們并不一定都對，但是對于包括典型UNIX命令在內的許多應用來說，它們都是正確的）。首先，寫回策略比寫直通策略更可取，因為程序一般會因為時間局部性而多次修改變量。即使它們沒有多次修改變量，寫回高速緩存機制也往往不會增加任何性能開銷，因為寫直通一行或者在以后替換行的時候再寫回都要花費一個存儲器周期。為每一行維護一個修改位并處理寫回雖然增加了復雜性，但這樣做是值得的。在最差的情況下，沒有時間或者空間局部性可言，有寫分配能力的寫回策略只會多讀一次高速緩存行。完全沒有局部性的情形是非常少見的，所以它們不會對性能造成明顯的影響。

接下來，增加組的大小一般也會有幫助。對于小規模的高速緩存（1 KB或者更小）來說這樣的做法特別有用，因為即便多個地址產生了相同的索引，它也能利用更多的高速緩存。對于非常大的高速緩存（1 MB或者更多）來說，增加組的大小就沒那么重要了，因為隨著行數的增加，出現一段數據替換現有的高速緩存數據的可能性也逐漸減小。

由于空間局部性，增加高速緩存行的大小一般也會對高速緩存性能有幫助。高速緩存行太長的缺點是在缺失處理期間讀取數據需要開銷。在小規模高速緩存的組織結構中找不到很長的高速緩存行，因為這就意味著高速緩存中的行數會更少。因此出現替換的頻率就更高了。

高速緩存的性能也會受到操作系統的影響。不同的高速緩存組織結構需要不同情況的沖洗機制。有若干種技術可以用來減少必須發生的沖洗量。這很重要，因為頻繁的沖洗很花時間，并且減少了有用的數據被高速緩存的時間。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的《现代体系结构上的UNIX系统：内核程序员的对称多处理和缓存技术（修订版）》——2.11 高速缓存的性能...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。