博士

ロボ子、今日はCPUキャッシュについて話すのじゃ！

ロボ子

CPUキャッシュ、ですか。L1、L2、L3とRAMがあるんですよね。それぞれの速度と容量が違うと。

博士

そうじゃ！L1キャッシュは4サイクル（約1ナノ秒）で32KB、L2キャッシュは12サイクル（約3ナノ秒）で256KB、L3キャッシュは40サイクル（約10ナノ秒）で8MBじゃ。RAMは200サイクル以上（約60ナノ秒）で32GBもあるぞ。

ロボ子

RAMからの読み込みはL1キャッシュの約60倍も遅いんですね！キャッシュミスは60キャッシュヒットに相当する、と。

博士

その通り！だからキャッシュを意識したプログラミングが大切なのじゃ。例えば、フォルスシェアリングって知ってるか？

ロボ子

フォルスシェアリング…複数のCPUコアが同じキャッシュラインを共有する異なる変数を変更すると発生する、パフォーマンス低下の原因になるものですね。

博士

よく知ってるの！高並行処理時に10倍もパフォーマンスが低下することもあるから、要注意じゃぞ！

ロボ子

それを防ぐために、データ指向設計が重要になるんですね。構造体配列(AoS)と配列構造体(SoA)の使い分けとか。

博士

そうじゃ！ホット/コールドデータの分離や、NUMA対応アロケーションも有効じゃ。CPU IDに基づいてメモリを割り当てるのじゃ。

ロボ子

キャッシュを意識したハッシュテーブルには、Robin Hoodハッシュテーブルを使うと良いんですね。

博士

さすがロボ子、よく勉強しておる！実際のプロダクション例としては、分析パイプラインでのイベントバッチ処理が挙げられるのじゃ。

ロボ子

SIMDフレンドリーなレイアウトも重要ですね。Vec3構造体を使うとか。

博士

`perf` ツールを使ってキャッシュミスを測定し、キャッシュパフォーマンスをベンチマークするのも大事じゃぞ。

ロボ子

Goでキャッシュフレンドリーなコードを書くためのルールもあるんですね。頻繁にアクセスされるフィールドを同じキャッシュラインに配置したり、ゴルーチンのデータをキャッシュラインで分離したり…。

博士

そうそう！ランダムアクセスよりもシーケンシャルアクセスを優先したり、範囲が許容される場合はint64ではなくint32を使ったりするのも効果的なのじゃ。

ロボ子

予測可能な分岐とアクセスパターンも重要ですね。メモリの再利用はホットキャッシュにつながる、と。

博士

最適化のレシピとしては、まず`perf`でキャッシュミスを特定し、ホットパスのためにAoSからSoAへ再構築、フォルスシェアリングを排除するためにパディング…という流れじゃな。

ロボ子

セキュリティに関する考慮事項もあるんですね。タイミングサイドチャネルを悪用する可能性のあるメモリアライメントトリックに注意したり、キャッシュベースの攻撃（Spectre、Meltdown）は予測可能なメモリアクセスパターンを悪用したり…。

博士

ロボ子、悲しい顔をするでない。テスト戦略も重要じゃぞ！マイクロベンチマークを使って特定の最適化を測定したり、異なるCPUアーキテクチャでテストしたりするのじゃ。

ロボ子

現実的なデータサイズとアクセスパターンで測定し、パフォーマンスカウンタを使用してキャッシュヒット率を検証するんですね。異なるコア数でテストを実行して、フォルスシェアリングを検出すると。

博士

言語比較で言うと、Goのガベージコレクションはメモリアクセスパターンにオーバーヘッドを追加するけど、キャッシュフレンドリーなコードは局所性を改善することによりGC圧力を軽減できるのじゃ。

ロボ子

最適化手法の改善例として、分析パイプラインではバッチ処理で最大14倍高速化、ゲーム物理エンジンでは衝突検出で8倍高速化、データベースインデックス作成ではシーケンシャルスキャンで11倍高速化されたんですね。

博士

そう！キャッシュを意識するだけで、こんなにもパフォーマンスが向上するのじゃ！ところでロボ子、キャッシュって何でできてるか知ってるか？

ロボ子

えっと…半導体ですか？

博士

ブー！正解は…お金じゃ！キャッシュだけに！