# 共有メモリバンクコンフリクト ## 定義 共有メモリバンクコンフリクト(shared-memory bank conflict)とは、NVIDIA GPUのオンチップ共有メモリが32バンク(バンク幅4バイト、アドレスはmod 32でバンクに写像)で構成される中で、同一ウォープ内の複数スレッドが同じバンクの異なるアドレスへ同時にアクセスしようとすることで発生する直列化(serialization)である。バンク数(32)がウォープのスレッド数(32)と一致するため、行(row)を固定し列(column)を可変にするようなアクセスパターン(例: 素朴な行列転置における列読み出し)は32-wayの全面的なコンフリクトを引き起こし、本来並列であるべき32回のアクセスが1回ずつ直列実行される。全スレッドが同一アドレスにアクセスする特殊ケースはブロードキャストされコンフリクトを回避する。回避策として、共有メモリ配列に余分な列を加えるパディング(padding、例: `[32][33]`)と、インデックスをビット演算等で撹拌するスウィズリング(swizzling、メモリオーバーヘッドなし)がある。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 7 Profiling and Tuning GPU Memory Access Patterns]]) ## 横断的知見 - パディングはメモリオーバーヘッド(32要素タイルで約3%)と引き換えに実装が単純であるのに対し、スウィズリングはメモリオーバーヘッドゼロだがコンパイル時のインデックス変換が必要という異なるトレードオフを持つ。CUTLASS等の高性能ライブラリは後者(スウィズリング)をタイルイテレータ内部で採用している。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 7 Profiling and Tuning GPU Memory Access Patterns]]) - バンクコンフリクト回避(共有メモリのアクセスパターン設計)とウォープシャッフル命令(共有メモリ自体を迂回)は、同じ「スレッド間データ交換の高速化」という目的に対する異なる解法であり、シャッフルはウォープ内(32スレッド)に限定される一方、バンクコンフリクト回避技法は共有メモリを使う限り常に必要になる、という補完関係にある。(Source: [[@2025__OReilly__AI Systems Performance Engineering - Chapter 7 Profiling and Tuning GPU Memory Access Patterns]]) ## 未解決の問い - タイルサイズを32×32から64×64等に拡大した場合、パディング/スウィズリングのコストがレジスタ・共有メモリ予算の逼迫(第7章で言及される64×64タイルのオキュパンシ低下)とどう相互作用するか。 - 第10章(ウォープ特化・スレッドブロッククラスタ)で扱われるウォープ間(interwarp)通信技法が、バンクコンフリクト回避との関係でどう位置づけられるか。 - 本vaultの他のGPU/CUDA関連ソースで、実測のバンクコンフリクト発生率やNsight Computeでの検知手順の追加事例があるか。 ## 関連 - [[@2025__OReilly__AI Systems Performance Engineering - Chapter 7 Profiling and Tuning GPU Memory Access Patterns]] — 本概念の一次出典 - [[wiki/entities/AI Systems Performance Engineering|AI Systems Performance Engineering]] — 書籍本体 - [[メモリコアレッシング]] — 同章で扱う関連最適化技法 ## 出典 - Chris Fregly, *AI Systems Performance Engineering*, O'Reilly Media, 2025, Chapter 7 (§Avoid Shared-Memory Bank Conflicts, §Warp Shuffle Intrinsics).