導入: なぜ「キャッシュライン・バウンス」を意識する必要があるのか
現代のCPUにおいて、メモリの読み書き速度はプロセッサの処理速度と比較して非常に低速です。そのため、CPUはキャッシュメモリを活用して性能を補っています。しかし、マルチスレッド環境で「ある変数の更新」が「無関係な別の変数の更新」に干渉し、性能を劇的に低下させる現象があります。これが「キャッシュライン・バウンス（擬似共有）」です。この問題を解決することで、並列処理のオーバーヘッドを抑え、プログラムの実行速度を向上させることができます。
基礎知識: キャッシュラインとMESIプロトコル
CPUはメモリからデータを読み込む際、数バイト単位ではなく「キャッシュライン」と呼ばれる単位（通常64バイト）で一度に読み込みます。
CPU間でのキャッシュ整合性を保つための「MESIプロトコル」という仕組みがあり、あるコアがデータを書き換えると、他のコアが持つ同じキャッシュラインは「無効（Invalid）」とみなされます。
もし、異なるスレッドが管理する変数が「たまたま同じ64バイトの範囲内」に存在すると、一方が書き込むたびに、もう一方がキャッシュを再取得し直すという「無駄な通信」がバス上で発生します。これが性能を著しく低下させる原因です。
実装/解決策: パディングによる境界線の分離
この現象を回避する最も確実な方法は、データ構造をキャッシュライン境界（64バイト）に強制的に配置（アライメント）することです。C++11以降で導入された「alignas」指定子を使うことで、コンパイラに対して特定の変数を独立したキャッシュラインに配置するように指示できます。
サンプルプログラム
以下のコードは、キャッシュラインの干渉を避けるための構造体の定義例です。
include <iostream>
include <atomic>
include <vector>
include <thread>
// alignas(64) を指定することで、この構造体は必ず64バイト境界から始まります。
// これにより、隣接するデータとキャッシュラインを共有しなくなります。
struct alignas(64) CacheAlignedCounter {
std::atomic<int> value{0};
};
int main() {
// 2つのカウンターを定義。
// パディングなしだと隣り合う可能性がありますが、alignasにより別々のラインに配置されます。
CacheAlignedCounter counterA;
CacheAlignedCounter counterB;
auto work = [](CacheAlignedCounter& c) {
for(int i = 0; i < 1000000; ++i) {
c.value.fetch_add(1, std::memory_order_relaxed);
}
};
// 別々のスレッドで同時に書き込みを行う
std::thread t1(work, std::ref(counterA));
std::thread t2(work, std::ref(counterB));
t1.join();
t2.join();
std::cout < "完了: counterA=" << counterA.value << ", counterB=" << counterB.value << std::endl;
return 0;
}
応用・注意点: 現場で役立つ補足情報
1. std::hardware_destructive_interference_size: C++17から導入されたこの定数を使用すると、環境ごとのキャッシュラインサイズを動的に取得できます。定数64と書くよりも移植性が高まります。
2. 過度なパディングの罠: パディングはメモリ消費量を増加させます。大量のオブジェクトを生成する場合、メモリ使用量とキャッシュ効率のトレードオフを考慮してください。
3. データ読み込みのみの場合: 頻繁に書き込まれない（読み取り専用の）データについては、キャッシュラインを分ける必要はありません。逆に共有することでキャッシュ効率が高まる場合もあります。あくまで「高頻度で書き込まれるデータ」に対してこの手法を適用するのが鉄則です。
コメント