GPU共享内存优化：避免Bank Conflict提升性能

1. 理解Shared Memory与Bank Conflict的本质

在GPU编程领域，Shared Memory（共享内存）是位于每个SM（流式多处理器）上的高速可编程缓存，其访问延迟仅为全局内存的1/100。但它的性能优势有个重要前提——必须避免Bank Conflict（存储体冲突）。我第一次在CUDA内核中遭遇Bank Conflict时，性能直接从理论峰值的80%暴跌到15%，这个教训让我深刻认识到理解存储体架构的重要性。

现代GPU的Shared Memory通常被划分为32个物理Bank（对应warp中的32个线程），每个Bank的位宽是4字节。当同一个warp内的多个线程同时访问同一个Bank的不同地址时，就会触发Bank Conflict。此时硬件会将这些访问序列化，导致有效带宽急剧下降。举个例子：如果线程0访问Bank0的地址0x00，线程1访问Bank0的地址0x04，虽然访问的是不同地址，但因为落在同一个Bank上，就会产生2-way冲突。

关键认知误区：很多开发者以为只要访问不同地址就不会冲突，实际上决定因素是Bank编号而非绝对地址。Bank编号的计算公式为：(字节地址 / 4字节) % 32

2. Bank Conflict的典型场景与检测方法

2.1 冲突模式全解析

在我的项目经验中，Bank Conflict主要有三种典型模式：

1. 步长冲突：当线程访问地址呈固定步长时，如矩阵转置中的对角线访问。例如32x32矩阵按行存储时，列访问的步长为32*4=128字节，128/4%32=0，导致所有线程访问同一Bank。

2. 随机冲突：使用哈希表等数据结构时，不可预测的访问模式可能引发随机冲突。曾有个粒子碰撞检测项目因此性能下降40%。

3. 广播冲突：所有线程读取同一地址时（如常量参数），在Maxwell之前架构会产生32-way冲突，Pascal+架构通过广播机制优化了这种情况。

2.2 实战检测技巧

用NSight Compute工具检测冲突时，我总结出三个关键指标：

• shared_ld_bank_conflict：加载操作冲突次数
• shared_st_bank_conflict：存储操作冲突次数
• `shared_efficienc