キャッシュコヒーレンシプロトコル(Cache Coherence, MESI)
1. 概要
A. 定義
キャッシュコヒーレンシ(Cache Coherence) とは、複数のプロセッサ(コア)がそれぞれのプライベート(private)キャッシュに同一メモリブロックの複製を保持していても、どのコアがそのブロックを読んでも最も新しく書き込まれた唯一の値を観測できることを保証する性質であり、これをハードウェア的に強制する状態機械(state machine)がキャッシュコヒーレンシプロトコル(cache coherence protocol) である。代表的実装が、各キャッシュラインをModified・Exclusive・Shared・Invalidの四状態で管理するMESIプロトコルである。
キャッシュコヒーレンシの本質は「性能のためにデータを複数箇所へ複製したときに生じる矛盾を隠す」ことにある。マルチコアシステムでは各コアがメモリアクセス遅延を減らすために自分専用のL1/L2キャッシュを持つ。ところが二つのコアが同じ変数 x を自分のキャッシュに載せた状態で一方のコアが x を更新すると、他方のコアのキャッシュには古い(stale)値が残る。プロトコルがなければ「コアBはコアAがすでに1に変えた x を依然として0と読む」という矛盾が生じる。キャッシュコヒーレンシプロトコルは書き込みが起きた瞬間に他の複製を無効化(invalidate)または更新(update)し、ソフトウェアには「キャッシュのない単一共有メモリ」という錯覚を維持させる。
なぜ四状態なのかも設計論理で説明される。あるキャッシュラインについて区別すべき核心属性は「有効か(valid)」「自分だけが持つか(exclusive)」「メモリと同じか(clean)」の三つである。有効でなければInvalid、有効かつ単独・cleanならExclusive、有効・単独だがdirtyならModified、有効だが他キャッシュと共有(clean)ならSharedと、自然に四通りの組合せが生じる。これより少ないMSIは「単独clean」を別に表現できず不要な無効化を招き、より多いMOESI/MESIFは追加属性(「共有中のdirtyの供給責任者」や「代表応答者」)を表現するために状態を増やしたものである。すなわち状態集合の大きさは「どの区別までハードウェアで追跡してトラフィックを節約するか」という費用対効果の判断の結果である。
ここで必ず区別すべき概念がコヒーレンシ(coherence) と整合性/メモリ整合性モデル(consistency) である。coherenceは「単一アドレス」への書き込みの順序と可視性を扱う局所的性質であり、consistencyは「互いに異なる複数アドレス」へのアクセスがどの順序で観測されるかを規定する大域的規則(例:Sequential Consistency, TSO)である。すなわちMESIはcoherenceを保証するが、異なる変数間の並べ替え(reordering)問題はメモリバリア(memory barrier)とconsistencyモデルの領域として残る。技術士の答案でこの二つを混同しないことが肝要である。
B. 登場背景と必要性
シングルコア時代はキャッシュが一つだけで「キャッシュの値とメモリの値が異なりうる」という問題(write-backによる不一致)だけ管理すれば十分だった。しかし2000年代半ば以降、クロック向上が電力・発熱の壁(Power Wall)に突き当たり、性能拡張の軸が「より速い一つのコア」から「複数のコア」へ移り、すべてのサーバ・PC・スマートフォンがマルチコアになった。コアごとにプライベートキャッシュを置く構造が一般化すると、同一データの複製が複数キャッシュに散らばることが常態化し、これを矛盾なく管理するハードウェア機構が必須となった。
キャッシュコヒーレンシはまたキャッシュの書き込み方式(write-back/write-through)とも噛み合う。大半の現代キャッシュは書き込みを即座にメモリへ反映せずキャッシュにのみ記録し後で書き戻すwrite-back 方式を使うが、この方式はメモリトラフィックを大きく減らす代わりに「キャッシュにのみ最新値がある」状態(MESIのM)を生む。したがってコヒーレンシプロトコルはあるコアがそのブロックを要求したとき、メモリではなく最新値を持つキャッシュが応答するよう調整せねばならない。write-throughならメモリが常に最新でこの調整は単純だがメモリ帯域を過消費するため、性能のためにwrite-backを選んだ代償としてコヒーレンシ管理が複雑になったのである。
この必要性は実務性能に直結する。例えばマルチスレッドプログラムでスレッドが共有カウンタを更新したりロック(lock)変数を奪い合うと、当該キャッシュラインがコア間を絶えず往復するキャッシュラインピンポン(ping-pong) が発生し、数十〜数百サイクルの遅延が繰り返される。コヒーレンシプロトコルは正確性を保証する安全装置であると同時に、そのトラフィック費用が並列拡張性の上限を決める性能要因でもある。したがって高性能サーバ、インメモリDBMS、ロックフリーデータ構造、HPCカーネルを設計する技術者はプロトコルの動作原理を理解し、偽共有(false sharing)を避けるようデータを配置せねばならない。
2. キャッシュコヒーレンシ問題の構造と要件
マルチコアのメモリ階層は以下のように「コア別プライベートキャッシュ + 共有LLC(Last-Level Cache) + メインメモリ」で構成され、コヒーレンシプロトコルはプライベートキャッシュ間の複製を調整する階層で動作する。
flowchart TB
subgraph Chip["マルチコアプロセッサ"]
C0["コア 0"] --> L10["L1/L2 プライベートキャッシュ"]
C1["コア 1"] --> L11["L1/L2 プライベートキャッシュ"]
C2["コア 2"] --> L12["L1/L2 プライベートキャッシュ"]
L10 --- BUS["コヒーレンシ相互接続<br/>(共有バス / リング / メッシュ)"]
L11 --- BUS
L12 --- BUS
BUS --- LLC["共有L3(LLC)<br/>+ スヌープフィルタ/ディレクトリ"]
end
LLC --- MEM[("メインメモリ(DRAM)")]
style Chip fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
style LLC fill:#fef7e0,stroke:#f9ab00,stroke-width:2px
上図で共有L3(LLC)とともに描かれたスヌープフィルタ/ディレクトリ の位置が重要である。多くの商用CPUはLLCを包含(inclusive)型に設計し、上位プライベートキャッシュにあるラインは必ずLLCにも存在するようにする。するとLLCの各ラインに「どのコアがこのラインをプライベートキャッシュに持つか」を示す存在ビット(presence bit)を付け、事実上LLCがオンチップのディレクトリ兼スヌープフィルタの役を担う。おかげで外部から入ったスヌープやコア間要求を全コアへばらまかず、当該ラインを持つコアにのみ伝達できる。ただし包含型はLLCからラインが追い出されると上位キャッシュの複製も併せて無効化せねばならない逆無効化(back-invalidation)の費用があり、近年は非包含(non-inclusive)型と別個のスヌープフィルタを組み合わせる設計も増えている。
コヒーレンシプロトコルが満たすべき条件は通常三つに整理される。第一は書き込み伝播(write propagation) で、あるコアの書き込み結果が結局は他コアの読みに反映されねばならないことである。第二は書き込み直列化(write serialization) で、同一アドレスへのすべての書き込みがすべてのコアに同じ順序で見えねばならないことである。もしコアAが x=1、x=2 を順に書いたなら、他のどのコアも2を見た後に1を見る逆転を経験してはならない。第三は最新値の返却で、読みは「最後に完了した書き込み」の値を返さねばならない。
具体例として二つのコアが共有変数 flag(初期値0)を扱う状況を見よう。コアAが flag=1 を書くには、まず自分がそのラインを書き込み可能な状態で所有せねばならない。コアBが同じラインを読み用に保持していたなら、Aの書き込み要求はBの複製を無効化し、以後Bが再び flag を読むとキャッシュミスが発生しA(またはメモリ)から1という最新値を取ってくる。こうして「書き込み → 他複製の無効化 → 再ロード」という三拍子が書き込み伝播と直列化を同時に達成する。重要なのはこの全過程がソフトウェアには見えず、プログラマは単にメモリを読み書きするだけという点である。ハードウェアが正確性を担うためマルチコアプログラミングが成立するが、その裏の無効化トラフィックが性能費用として転嫁されるという事実は性能技術者が必ず意識せねばならない。
coherenceとconsistencyの境界は具体的な並べ替え事例で見るとより明確になる。コアAが data=42 を書いた後 ready=1 を書き、コアBが ready==1 を確認した後 data を読む典型的な旗パターンを考えよう。MESIは data と ready それぞれに「唯一の最新値」を保証するが、二変数へのAの書き込みがBに同じ順序で見える保証はしない。弱いメモリモデル(ARM等)ではBが ready=1 を先に観測しても data の旧値を読みうるため、必ずメモリバリアやrelease/acquire意味の原子操作で順序を強制せねばならない。このようにcoherenceだけを信じてconsistencyを見落とすと「たまにだけ誤る」再現困難なバグが生じるため、二概念の役割分担を明確に認識することが並列プログラミングの出発点である。
これらの条件を達成する方針は大きく二系統である。無効化方式(write-invalidate) は書き込み直前に他のすべての複製を無効化し書くコアが唯一の所有者になる方式で、今日ほぼすべての商用プロセッサが採用する。更新方式(write-update) は書いた値を他の複製へブロードキャストして更新する方式だが、共有者が多いときバス帯域が過大で現代システムでは稀にしか使われない。例えば生産者-消費者のように片方のみ書き他方が即読むパターンではupdateが有利でありうるが、書くコアが頻繁に変わる一般的ワークロードではinvalidateがトラフィック面で圧倒的に効率的で事実上の標準となった。
3. プロトコルの分類:スヌーピング vs ディレクトリベース
コヒーレンシトラフィックを「誰がどう伝達するか」でプロトコルはスヌーピングとディレクトリベースに分かれる。この選択はコア数と相互接続構造に応じて性能・拡張性が大きく変わるため、設計トレードオフを理由とともに理解せねばならない。
スヌーピング(Snooping/Snoopy)方式 はすべてのキャッシュが共有バス(またはブロードキャスト可能な相互接続)を常時監視し、あるコアが特定アドレスへの読み/書き要求を上げると各キャッシュが自分がそのブロックを持つか自ら確認して状態を変える方式である。中央管理者がなく実装が単純で遅延が短いが、すべての要求を全キャッシュへブロードキャストせねばならないためコア数が増えるとバス帯域が飽和する。そこで小〜中規模(数〜数十コア)システムに適し、実際の商用チップは帯域の無駄を減らすためスヌープフィルタ(snoop filter) を置き、当該ブロックを持つ可能性のないキャッシュにはスヌープを送らない。
ディレクトリ(Directory)ベース方式 は各メモリブロックごとに「どのノード/キャッシュがそのブロックの複製を持つか」を記録するディレクトリを置き、書き込みが必要なコアがディレクトリに問い合わせて共有者にのみ選択的に無効化メッセージを送る方式である。ブロードキャストがないため数百〜数千コアの大規模NUMA・メニーコアシステムでも拡張するが、ディレクトリ照会という間接段階が加わり遅延が増え、ディレクトリ格納領域(ブロック数 × ノード数ビット)がオーバーヘッドとなる。今日の大型サーバCPUは二方式を混合し、ソケット内部はスヌーピング/リング・メッシュで、ソケット間はディレクトリ/スヌープフィルタで処理するハイブリッド構造をよく使う。
| 区分 | スヌーピング(Snooping) | ディレクトリ(Directory) |
|---|---|---|
| 伝達方式 | 全ブロードキャスト | 共有者にのみ選択送信 |
| 相互接続 | 共有バス・リング | 拡張型メッシュ・クロスバー |
| 拡張性 | 数〜数十コア | 数百〜数千コア |
| 遅延 | 短い(直接監視) | 相対的に長い(ディレクトリ経由) |
| オーバーヘッド | バス帯域の飽和 | ディレクトリ格納領域 |
| 適用例 | デスクトップ・小規模サーバ | 大型NUMA・HPC・メニーコア |
例えば2ソケットx86サーバはソケット内部のコアをリング/メッシュで束ねスヌープフィルタで調整し、ソケット間はUPI/Infinity Fabric上でディレクトリ的情報を活用して不要なクロスソケットスヌープを抑制する。一方、数千コア規模のHPCノードやGPUのマルチチップ構成はディレクトリベースが事実上必須である。
拡張性の数値感覚も重要である。純粋なブロードキャストスヌーピングではコアがN個のとき一つの書き込み要求が原理上N個のキャッシュすべてに伝達されねばならないため、コヒーレンシトラフィックがコア数に比例(あるいはそれ以上)して増える。コアが8個なら耐えられるが64個、128個になると相互接続が要求で飽和し「コアを増やすほどかえって遅くなる」逆説が生じる。ディレクトリ方式は共有者集合にのみメッセージを送るためこの問題を緩和するが、代わりにブロックごとに共有者ビットマップを格納せねばならずメモリオーバーヘッドが大きくなる。そこで大規模システムは全ブロックではなく実際にキャッシュに載ったブロックのみ追跡するスパースディレクトリ(sparse directory) や階層型ディレクトリで空間を節約する。このように「トラフィックを減らせば格納領域を多く使い、格納領域を節約すれば精度(追跡精度)が落ちる」という交換関係がコヒーレンシハードウェア設計の本質的緊張である。
4. MESIの状態と遷移
無効化方式スヌーピングの代表がMESIであり、各キャッシュラインは四状態のいずれかを持つ。以下の状態遷移図は、自コアの読み/書き(PrRd/PrWr)とバスで観測される他コアの要求(BusRd/BusRdX)に応じてラインがどう移り動くかを示す。
stateDiagram-v2
[*] --> Invalid
Invalid --> Exclusive: PrRd / 他の複製なし
Invalid --> Shared: PrRd / 他の複製あり
Invalid --> Modified: PrWr / BusRdX
Exclusive --> Modified: PrWr / バストラフィック不要
Exclusive --> Shared: 他コア BusRd を観測
Exclusive --> Invalid: 他コア BusRdX を観測
Shared --> Modified: PrWr / BusRdXで他複製を無効化
Shared --> Invalid: 他コア BusRdX を観測
Modified --> Shared: 他コア BusRd / 書き込み後共有
Modified --> Invalid: 他コア BusRdX / write-back実行
Modified(M, 変更済) はこのキャッシュだけが唯一複製を持ち、メインメモリより新しい(dirty)状態である。他のキャッシュにこのブロックはないため自由に読み書きできるが、このラインが置換されたり他コアが要求すると、必ずメモリへ書き戻し(write-back) するか要求者へ直接データを渡し(cache-to-cache transfer)コヒーレンシを維持せねばならない。
Exclusive(E, 排他的) はこのキャッシュだけが複製を持つがメモリと値が同じ(clean)状態である。E状態の価値は書き込み最適化にある。すでに唯一の所有者であることが確定しているため、このブロックへ書くとき他キャッシュを無効化する必要がなくバストラフィックなしで直ちにMへ遷移できる。もしE状態がなければ(MSIプロトコル)、単独で読んだデータに書くときすら不要な無効化ブロードキャストを出さねばならないが、「読んですぐ書く」よくあるパターンでEはこの無駄を除き性能を高める。
参考としてE状態はデータ共有が稀なワークロードで特に効果が大きい。単一スレッドが大半のデータを一人で扱う典型的アプリケーションではほぼすべてのラインがEで積載され書き込み時に無効化トラフィックが発生しないため、MSIに比べバス使用量が目立って減る。逆に共有が頻繁なワークロードではEの利点が小さくなり、この場合はMOESIのOやMESIFのFが共有状況のトラフィックを減らして補う。このように状態集合の効用はワークロードの共有特性によって変わるため、プロセッサ設計者は対象市場の代表ワークロードを基準にプロトコルを選ぶ。
Shared(S, 共有) は複数のキャッシュが同一のclean複製をともに持つ状態である。読みは自由だが、書くにはまずBusRdX(またはUpgrade)要求で他のすべての共有者を無効化し所有権を独占した後Mへ遷移せねばならない。Invalid(I, 無効) は複製がないか古くて使えない状態で、アクセスするにはメモリや他キャッシュから再び取ってこねばならない。
これらの状態が実際にどう動くか一つのシナリオで追ってみよう。初めに誰もあるラインを持たない状態(I)で、コア0がそのブロックを初めて読むと他の複製がないためE 状態で積載される。このときコア0が直ちに書くとバストラフィックなしでM へ上がる。続いてコア1が同じブロックを読むとBusRdが観測され、コア0は自分のMラインをコア1へ供給(cache-to-cache)しつつ両キャッシュともS へ下がる。再びコア1がそのブロックに書くとBusRdXでコア0のS複製を無効化(I)し自分はM になる。結局「所有権」がコア0 → コア1へ移ったわけで、もし二つのコアが交互に書き込みを繰り返すとラインがM状態で両側を果てしなく往復するピンポンが発生し深刻な遅延を招く。この流れを頭の中に描けてこそ、共有データ競合がなぜ並列性能を削るのかを定量的に説明できる。
一つ付け加えると、教科書の四つの安定状態(M/E/S/I)は概念モデルであり、実際のハードウェア実装には要求がバスを往復する間ラインが留まる過渡状態(transient state) が多数存在するという事実である。例えばSからMへ上がろうとUpgrade要求を送った後応答を待つ中間状態、Mラインを他コアへ渡す途中の状態などがそれである。これらの過渡状態は二つのコアが同時に同じラインの所有権を狙う競合(race)を矛盾なく直列化するために必要であり、このため商用コヒーレンシプロトコルの実際の状態数は数十に達し形式検証(formal verification)の対象となる。答案では「安定状態4つ + 多数の過渡状態」という構造に触れれば理解の深さを示せる。
MESIを拡張した変種はそれぞれの非効率を狙う。MOESI はOwned(O) 状態を追加し、dirtyなブロックをメモリへ即座に書き戻さずとも他キャッシュと共有できるようにする(所有者が最新値供給の責任を負う)。これはwrite-backトラフィックを減らしAMD系が採用する。MESIF はForward(F) 状態を置き、複数の共有者のうち「一つ」だけが要求に応答(データ供給)するよう指定して多重応答の衝突をなくす(Intel系)。このように追加状態はすべて「不要なメモリ書き戻し」または「重複応答」という特定トラフィックを減らす同じ動機から生じたもので、違いは「どの費用を優先して減らすか」の選択である。
| 状態 | 有効 | メモリと一致 | 他キャッシュ共有可 | 書き込み時の動作 |
|---|---|---|---|---|
| Modified | O | 不一致(dirty) | X(単独) | 直ちに可能 |
| Exclusive | O | 一致(clean) | X(単独) | トラフィックなしでM遷移 |
| Shared | O | 一致(clean) | O | 無効化後にM遷移 |
| Invalid | X | - | - | 再ロード必要 |
5. 深化:偽共有(False Sharing)と最新動向
コヒーレンシプロトコルを理解すべき最も実戦的な理由は偽共有(false sharing) という性能の罠のためである。キャッシュコヒーレンシはバイト単位ではなくキャッシュライン(通常64バイト) 単位で動作する。したがって互いに異なる二つのスレッドが論理的には全く異なる変数を扱っても、その変数がたまたま同じ64バイトラインに配置されると、一方のスレッドの書き込みが他方のスレッドのラインを無効化しピンポンが発生する。例えばコア別カウンタ配列 long cnt[N] を隣接配置したまま各コアが自分のインデックスだけ増やしても、複数のカウンタが一つのラインに束ねられ実際には共有がないのに激しいコヒーレンシトラフィックが生じる。実測ではこうしたコードは各カウンタをキャッシュラインサイズにパディング(alignas(64))すると数倍〜数十倍速くなる事例が多く、これは高性能並列コードの核心チューニングポイントである。
偽共有の費用をサイクル単位で見積もるとなぜ致命的かが明確になる。L1キャッシュヒットは通常数サイクルで終わるが、他コアがM状態で保持するラインを取ってくるリモートHITM(Hit-Modified)は数十〜数百サイクルを要する。ソケットが異なればクロスソケット相互接続まで経るため費用はさらに大きくなる。四つのスレッドが一つのラインに束ねられた互いに異なるカウンタをそれぞれ毎秒数億回増やすコードなら、増加ごとにライン所有権移転を誘発し事実上直列化されキャッシュヒットの数十倍の遅延を被る。逆にカウンタを互いに異なるラインへ分離すると各コアが自分のラインをM状態で独占したままバストラフィックなしで更新するため線形に近く拡張する。同一アルゴリズムがデータ配置一つで数十倍の差が出るこの現象は、マルチコア時代に「正確性はハードウェアが、性能はデータ配置が決める」という命題を最も劇的に示す。
この原理は実際の産業コードベースの随所に反映されている。Linuxカーネルはコアごとに独立複製を置くper-CPU変数 を広範に使い共有書き込みとそれに伴うコヒーレンシトラフィックを根本的に避け、統計・カウンタはコア別に集計した後読むときのみ合算する。Javaでは @Contended(JEP 142)アノテーションでホットフィールドをキャッシュライン境界に合わせパディングし偽共有を防ぎ、高性能メッセージングライブラリLMAX Disruptorのリングバッファもシーケンスカウンタをパディングし生産者-消費者間の偽共有を除いたことで有名である。このように「共有を減らし、不可避な共有はラインを分離する」という原則はOS・ランタイム・ライブラリの全階層で繰り返し現れる性能設計の定石である。
またロック(lock)と原子操作(atomic)の費用もコヒーレンシプロトコルで説明される。compare-and-swap やスピンロックの獲得は当該ロック変数ラインを書き込み可能な状態(M)で独占せねばならないため、多くのコアが一つのロックを奪い合うとそのラインがコア間を暴走するように移動する。これが伝統的スピンロックがコア数に応じて急激に遅くなる理由であり、MCSロック・チケットロックのようにコア別の局所変数でスピンするよう設計したキューベースロックが登場した背景でもある。すなわち「ロックが遅い」現象の底にはキャッシュコヒーレンシトラフィックがあると理解すれば、競合緩和(シャーディング・バックオフ・局所集計)のような処方を原理に基づいて選べる。
最新動向としては第一に、CXL(Compute Express Link) ベースのメモリ拡張・共有が注目される。CXL.cache/CXL.memプロトコルはCPUと加速器・外部メモリプールの間にハードウェアコヒーレンシを拡張し、デバイスがホストメモリをコヒーレントにキャッシュしたりメモリプールを複数ホストがコヒーレントにアクセスする構造を志向する。これは伝統的にソケット内部に閉じていたコヒーレンシドメインをパッケージ・ラックレベルへ広げる試みで、メモリ分離(memory disaggregation)とプーリングを通じサーバ間メモリを柔軟に再配分しようとするデータセンター要求と噛み合う。ただしコヒーレンシ範囲が広がるほどリモートアクセス遅延とコヒーレンシトラフィック管理の難度が併せて増すため、どのデータをコヒーレント共有対象に置くかについて慎重な階層設計が求められる。第二に、チップレット(chiplet)・メニーコア 化で単一パッケージ内のノード数が急増し、純粋なブロードキャストスヌーピングは限界に達しディレクトリ・スヌープフィルタとメッシュ相互接続が標準になりつつある。第三に、GPU・異種計算ではCPU-GPU統合メモリ(例:統合仮想アドレス空間)のコヒーレンシ範囲をどこまでハードウェアが保証しどこからソフトウェア同期に委ねるかが設計争点である。第四に、コヒーレンシトラフィックが性能・電力の相当部分を占めるにつれ、スケーラブルディレクトリ(sparse/hierarchical directory)とコヒーレンシドメイン分割の研究が続いている。第五に、ハードウェアトランザクショナルメモリ(HTM) はコヒーレンシプロトコルの追跡能力を活用し、トランザクション領域で読み書きしたキャッシュラインの衝突をハードウェアが検出し衝突時にロールバックする方式でロックなし同期を支援する。これはコヒーレンシ機構が単なる正確性保証を越え同時実行制御の基盤インフラへ拡張される流れを示す。
これらの動向の共通点は「コアとメモリが爆発的に増える時代に、全面的ハードウェアコヒーレンシをそのまま押し通すより範囲を知的に調節する」ことである。伝統的な単一サーバの緻密なコヒーレンシから、ソケット・パッケージ・ラックへ範囲を階層化し一部をソフトウェアへ委ねる「選択的コヒーレンシ」へ重心が移っており、設計者はワークロードの共有パターンを分析しどの階層までハードウェアコヒーレンシを置くか判断せねばならない。
6. 考慮事項および示唆点
総合すると、キャッシュコヒーレンシプロトコルは「見えないがマルチコア性能の底を支える契約」である。技術士の観点から導かれる示唆点は次のとおりである。
第一に、正確性のハードウェア保証と性能のソフトウェア責任を分離して考えねばならない。 MESIはcoherence(単一アドレスの最新値可視性)を保証するが、異なる変数間の順序はメモリconsistencyモデルとバリアの領域である。ロックフリーコードや二重検査ロック(double-checked locking)のような微妙な同期では「コヒーレンシが保証されるのでバリアは不要」という誤解が致命的バグにつながる。技術士の観点では二つの階層を区別して設計・レビューする力量が求められる。
第二に、データ配置が性能の決定変数であることを設計原則とせねばならない。 偽共有の回避(ホット変数の分離・パディング)、スレッドとデータの局所性整合(NUMA-aware配置)、共有書き込みの最小化(コア別局所集計後に併合)が並列拡張性を左右する。トレードオフとしてパディングはメモリ使用量を増やすため、競合が実際に激しいホットデータに選択的に適用する判断が必要である。
第三に、アーキテクチャ別特性(MESI/MESIF/MOESI、スヌーピング対ディレクトリ)に合わせチューニングを変えねばならない。 同一コードでもIntel(MESIF)とAMD(MOESI)、ソケット数、SNC設定に応じてコヒーレンシトラフィックの様相が変わる。性能プロファイリング時はキャッシュミスだけでなくコヒーレンシ関連カウンタ(例:リモートHITM、cross-socketトラフィック)も併せて観測し、ボトルネックの原因をクロス・共有トラフィックに探さねばならない。
第四に、拡張性の観点からコヒーレンシ範囲(coherence domain)を設計レベルで調節せねばならない。 コア・ソケット・加速器が増えるほど全面的ハードウェアコヒーレンシは費用が急増するため、CXL・分散共有メモリ・メッセージパッシング(MPI)のようにコヒーレンシ範囲を意図的に狭めたりソフトウェアで代替する選択が有効である。今後の異種・プールドメモリ環境では「どこまでハードウェアコヒーレンシで束ね、どこから明示的同期で分離するか」がシステムアーキテクチャの核心的意思決定になる見込みで、関連技術としてNUMA局所性最適化、メモリバリア/原子操作、トランザクショナルメモリを併せて考慮せねばならない。
第五に、セキュリティ・信頼性の面でもコヒーレンシ機構の副作用を認識せねばならない。 キャッシュ状態遷移とそれによるアクセス遅延差は測定可能な信号となり、他コアのメモリアクセスパターンを推論するキャッシュサイドチャネル攻撃(例:Flush+Reload、コヒーレンシトラフィックに基づく測定)の土台になりうる。またコヒーレンシプロトコルはマルチコア同時実行バグのデバッグを難しくするが、再現性の低い競合条件(race)が特定のコア配置・タイミングでのみ現れるためである。技術士の観点では性能最適化とセキュリティ・検証可能性の間の均衡を考慮し、機微演算の定数時間実装や体系的な同時実行テスト(モデル検査・ストレステスト)を設計に含めねばならない。
参考資料
- Hennessy & Patterson, "Computer Architecture: A Quantitative Approach" (Chapter on Multiprocessors and Cache Coherence)
- Sorin, Hill, Wood, "A Primer on Memory Consistency and Cache Coherence", Morgan & Claypool — https://doi.org/10.2200/S00346ED1V01Y201104CAC016
- Intel, "Intel 64 and IA-32 Architectures Software Developer's Manual, Vol. 3A" — https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html
- CXL Consortium, "Compute Express Link Specification" — https://computeexpresslink.org/
一言まとめ: キャッシュコヒーレンシプロトコル(MESI)は複数のキャッシュに散らばった同一ブロックの複製をModified・Exclusive・Shared・Invalidの状態機械で管理し「唯一の最新値」の可視性をハードウェアで保証し、スヌーピング・ディレクトリ方式の選択と偽共有の回避がマルチコア性能・拡張性を左右する。