FPC壓縮論文解讀

寫在前面

最近看着方面的工作，爭取每天讀一篇論文做一個合輯。
本篇論文的題目是
Frequent Pattern Compression: A Significance-Based Compression Scheme for L2 Caches

背景知識

隨着處理器和內存速度之間的差距越來越大，內存系統設計者可能會發現緩存壓縮有利於增加緩存容量和減少片外帶寬。大多數硬件壓縮算法都屬於基於字典的類別，這取決於構建字典並使用其條目對重複的數據值進行編碼。這種算法在壓縮大型數據塊和文件方面是有效的。然而，緩存線通常很短（32-256字節），每行字典會帶來顯著的開銷，限制壓縮性並增加此類算法的解壓縮延遲。
關於各種壓縮算法的分類和解釋可以參考之前寫的筆記。

數據壓縮的前提
基於顯著性的壓縮是基於這樣的觀察：大多數數據類型（如32位整數）可以存儲在比最大允許位數少的位數中。例如，符號位擴展是一種常用的技術，用於將小整數（例如，8位）存儲到32位字中，而字中的所有信息存儲在最不重要的幾位中。

題外話

爲什麼要cache數據壓縮

將片內Cache 中的數據進行壓縮，可以顯著增加Cache的有效容量，降低 Cache失效率和傳送帶寬需求，從而能夠提高處理器的性能。但是，由於壓縮Cache發生命中時需要首先對壓縮數據進行解壓縮，壓縮Cache技術會增加Cache的命中延遲。 當後一效應占主導地位時，系統性能反而可能下降。因此，
壓縮Cache技術對於某些應用能夠提高性能，而對另外一些應用可能降低性能。這也是面向性能提升的壓縮存儲技術通常只應用於主存或l2 Cache的壓縮，而不能應 用於l1數據Cache的原因。因爲主存與l2 Cache的訪問頻率相對較少，較能容忍解壓縮延遲，而L1 Cache的頻繁訪問對訪問延遲的約束要求更爲嚴格．

這裏給出一些中文論文連接有興趣可以看一看
基於簡單常見模式編碼(S-FPC)的壓縮Cache層次設計

SFPC好像還蠻有意思的，這裏稍微提及一下。
SFPC是FPC（也就是本文）的變種，具體的可以參考我這篇博客

一種簡單的數據Cache壓縮方法及其在同時多線程處理器上的應用

FPC壓縮方案的核心特點

1. 此方案中，頻繁模式壓縮（FPC）通過以壓縮格式存儲常見的字模式並附帶適當的前綴，逐字壓縮單個緩存線。
2. 對於64字節緩存線，假設每個週期12 FO4門延遲，壓縮可在三個週期內完成，解壓縮可在五個週期內完成。
3. 我們提出一種壓縮緩存設計，其中數據以壓縮形式存儲在二級緩存中，但在一級緩存中不壓縮。二級緩存線被壓縮到預定的大小，永遠不會超過其原始大小，以減少反編譯開銷。
4. 這個簡單的方案提供了與具有更高緩存命中延遲的更復雜方案相當的壓縮比。

FPC壓縮方案

壓縮前綴編碼特點

緩存線 = Cache line

頻繁模式壓縮（FPC）基於緩存線壓縮/解壓縮。每個高速緩存線被劃分爲32位字（例如，64字節線爲16個字）。
每個32位的字被編碼爲3位pre-fix（前綴）加上數據。表1顯示了與每個pre-fix對應的不同模式。

壓縮層次特點

我們提出了一種壓縮緩存設計，其中數據未壓縮存儲在一級緩存中，壓縮存儲在二級緩存中。
優點
這有助於減少許多阻礙性能的代價高昂的二級緩存未命中，同時又不會影響一級命中的常見情況。
缺點
但是，這樣的設計增加了在兩個級別之間移動時壓縮或解壓縮緩存線的開銷。

壓縮

當數據從一級緩存寫入二級緩存時，會發生緩存線壓縮。使用一個簡單的電路（並行地）檢查每個字的模式匹配，可以很容易地壓縮緩存線。如果一個字與七種可壓縮模式中的任何一種匹配，則使用一個簡單的編碼器電路將該字編碼爲其最緊湊的形式。如果未找到匹配項，則整個字將與pre fix“111”一起存儲。
對於zero-run模式，我們需要檢測連續的0的個數，並增加數據值來表示它們的計數。由於在我們的設計中，零運行被限制爲8個零（多了的前綴就不是000了），因此可以使用簡單的多路複用/加法器電路在一個週期內實現。

緩存線壓縮可以在內存管道中實現，方法是在L1到L2寫入路徑上分配三個管道階段（一個用於模式匹配，一個用於零運行編碼，一個用於收集壓縮線）。一個包含壓縮和未壓縮形式的幾個條目的小型“受害者”我一般把這種cache叫老倒黴蛋緩存緩存可用於隱藏一級寫回的壓縮延遲。

解壓縮

當數據從二級緩存讀取到一級緩存時，會發生緩存線解壓縮。對於工作集不在一級緩存中的大多數基準測試來說，這是一個經常發生的事件。
解壓縮延遲非常關鍵，因爲它直接添加到二級命中延遲中。
解壓是一個比壓縮慢的過程，因爲行中所有單詞的前綴都必須串聯訪問，因爲每個pre-fix用於確定其對應的編碼單詞的長度，從而確定所有後續壓縮單詞的起始位置。

 舉個例子，現在L2CACHE裏面裝的數據是


001010001000011111

第一步讀001，前綴，則後面4bit是數據位
 所以L1CACHE中的數據是
 0000，0000，0000，0000
 0000，0000，0000，0100

此時確定了應該從010繼續讀L2CACHE，前綴010，則後面8位是數據位
 所以L1CACHE中的數據是
 0000，0000，0000，0000
 0000，0000，0001，1111

解壓原理圖（壓縮原理圖暫無）

在此之前我們先好好明確一個計算
一個CACHE LINE被分爲若干個32位的字
例如一個64B的CACHE LINE被分爲16個字
計算過程：64 * 1B = 16*32bit
這是一個64字節（16字）緩存線的緩存線解壓縮管道。
1個字3bit的前綴，16個字就是48bits
這是用於解壓縮壓縮緩存線的五級管道，其中每個級包含12個或更少的FO4門延遲。
第零步：確定zero-run的個數

1. 第一流水線級（包含零運行檢測器、移位寄存器和並行前置解碼器）對前置陣列進行解碼，以確定每個字的位長度。
2. 第二級和第三級（並行前置加法器陣列）通過以分層方式添加前面單詞的長度字段來計算每個數據單詞的起始位地址。
3. 第四級（並行移位寄存器）包含16個寄存器，每個寄存器都由其字的起始地址移位。
4. 第五級和最後一級包含模式解碼器，該模式解碼器根據其對應的pre fix將每個32位寄存器的內容解碼爲未壓縮字。

壓縮結果

結果當然是很好的，我就不贅述了，有幾個點可以注意一下

寫在最後

感覺還有很多可以改進的空間