https://msyksphinz.hatenablog.com/entry/2025/07/21/040000

ISCA 2025で発表された "The XOR Cache A Catalyst for Compression" を読んでみることにした。

6. 評価

6.1 評価手法

シミュレータ: Gem5を用いて、XORキャッシュおよびコヒーレンス・プロトコルを実装・評価した。
キャッシュやタグ構造の面積・電力・レイテンシ評価: CACTI 7.0を使用
XOR圧縮ハードウェアの論理合成: Synopsys Design Compiler(32nmプロセス)を用いた。
ハードウェア構成(表3)
- 3レベルキャッシュ階層
- LLCは各バンク1MiB、計4バンク(4MiB)
- XOR圧縮にとって最も保守的(＝圧縮のチャンスが少ない)な構成

CPU	4-core, 3GHz x86-64
L1I	32KiB, 4-way, 4-cycle, 64B line, LRU, Private
L1D	32KiB, 4-way, 4-cycle, 64B line, LRU, Private
L2	256KiB, 8-way, 9-cycles, 64B line, LRU, Private
L3	1MiB per bank, 16-way, 40-cycle, 64B line, LRU, Shared, 4-banks
Memory	Dual Channel DDR4-2400

ベースライン(非圧縮)は各バンク1MiBのLLCであり、圧縮方式として以下を比較対象とする：

BΔI(Base-Delta-Immediate)(Intra-line 圧縮)
BPC(Bit-Plane Compression)(Intra-line 圧縮)
Thesaurus (Inter-line 圧縮)

本研究のXORキャッシュは、XOR圧縮とBΔIを併用し、より高い圧縮を実現する構成である。データ・アレイサイズは、プロファイル結果(図2のgeomean)に基づいて縮小している：

BΔI → 1.3倍縮小
Thesaurus, BPC → 1.5倍縮小
XOR+BΔI → 2.5倍縮小
マップテーブル: 128エントリ、ダイレクトマップ方式である。
- 加えて、同等の有効容量を持つExclusive LLC(非包含)およびExclusive+BΔIも評価対象に含めている。

レイテンシの仮定は以下の通りである：

LLC：一律40サイクル(圧縮方式に関わらず)
BΔI：1サイクル
Thesaurus：5サイクル
BPC：7サイクル
XOR圧縮：XORゲート遅延は0.12nsであり、1サイクル内に収まると仮定
ベンチマーク
- PERFECT(OpenMPマルチスレッド画像処理)
- PARSEC 3.0(simlargeデータセット)
- SPEC CPU2017(マルチプログラム評価。各ランでは4種類のSPECベンチマークをランダムに選んで混在実行。表5参照)

すべてgem5によるフルシステムシミュレーションで評価し、100B命令分をファストフォワードし、各コアで1B命令分の詳細統計を収集した。

6.2 XOR圧縮の相乗効果：マップ関数の比較

図12では、4種類のマップ関数(LSH-RP, LSH-BS, BL, SBL)の比較を示している。

(a) Inter-line 圧縮比：マップビット数が増えるとユニーク値が増加し、同じビンに似た候補が入りにくくなるため、圧縮率は低下する。
(b) Intra-line 圧縮比：マップビットが多いと、偽の類似候補(false match)が減り、真の類似候補が得られるため、圧縮率は向上する。
(c) 総合圧縮比：カバレッジと精度のトレードオフの結果として、BLおよびSBLは7ビット前後で最も高い圧縮比を示す。

本研究では、以降の評価でSBL(7ビット)を用い、XOR+BΔIの平均圧縮率≒2.5を採用する。

6.3 圧縮比の改善

図13は、各ベンチマークにおける圧縮比の実測値を示している。

XOR+BΔIは、BΔI単独、Thesaurus、BPCより一貫して高い圧縮比を示す。
Exclusive LLCはSラインを保持しないため一部圧縮されるが、効果は限定的(1.06倍程度)である。
XOR Cacheは包含による冗長性を活用できる点で、Exclusive LLCよりも優位である。

図13(c)(d)では、プライベートキャッシュのライン状態(M / S unique / S non-unique)の割合を可視化している。XOR圧縮できるラインはS uniqueの部分に依存する。Mラインが多すぎるとXOR候補が減り、圧縮率が低下する(例：dwt)。PARSECやPERFECTはマルチスレッドのためS non-uniqueが多く、S uniqueが減り、圧縮効果が相対的に小さい。

6.4 面積・電力の削減

6.4.1 面積

XOR Cacheは、タグ／データ・アレイの分離やマップテーブルの追加によりわずかにオーバーヘッドが生じるが、圧縮によるデータ・アレイ削減が支配的であり、結果として非圧縮に対して1.93倍のLLC面積削減を達成している。 BΔI、Thesaurus、BPCと比べても1.3〜1.5倍小さい(図14参照)。

6.4.2 電力

XOR復元による追加アクセス(リモートリカバリなど)は全体の約2%未満である。追加通信によるネットワークトラフィック増加は+23.4%であるが、Exclusive LLCでは+24.6%増であり、それより小さい。それでも全体としてLLC電力は1.92倍削減、階層全体で1.46倍削減となる。

6.5 性能オーバーヘッド

図15に示す通り、マルチスレッド(PERFECT, PARSEC)では1.45%の遅延増、マルチプログラム(SPEC)では2.95%のCPI増となった。差の理由は、SPECの方が圧縮効果が小さく、復元コストが相対的に大きくなるためである。リモートリカバリ経路をたどるLLCヒットが15%ほどあることも影響している。総じて、XOR Cacheの平均性能オーバーヘッドは2.06%にとどまる。