GPU 访存性能优化：Coalesced Access 合并访问

可视化演示

动态展示warp线程合并访问、非合并访问、矩阵布局影响与带宽对比四个视角，直观理解GPU内存事务合并机制。

访存带宽瓶颈

图书馆里，读者翻一页书只要一秒钟，但送书员从地下书库取一趟书要三分钟。GPU 的算力就是“翻书”的速度，全局内存（Global Memory）就是那座遥远的三分钟书库。每个线程想要数据，都必须先经历一次漫长的“取书等待”，而等待期间计算单元只能空转。

你可能听说过 GPU 的显存带宽很高，动辄每秒几百 GB，但那是“大量数据连续搬运”时的理想值。当每个线程零散地要 4 个字节时，带宽再高也发挥不出来。GPU 中衡量这个矛盾的关键叫计算访存比（Arithmetic Intensity），也叫算术强度——它描述每拿一块数据能做多少次计算。

$$\text{算术强度} = \frac{\text{浮点运算次数}}{\text{全局内存读写的字节数}}$$

1. 浮点运算次数：程序里实际完成的乘法和加法等计算总量，它构成公式的分子，代表读者翻书的动作量。

$$\text{浮点运算次数}$$

2. 全局内存读写的字节数：内核从显存读入或写出的数据总量，它构成分母，代表送书员搬运的书本量。

$$\text{全局内存读写的字节数}$$

3. 比值与硬件平衡点：当算术强度高于 GPU 的平衡点，程序是计算密集型；低于平衡点，则是访存密集型，受带宽限制。

$$\frac{\text{浮点运算次数}}{\text{全局内存读写的字节数}} \ge \text{平衡点}$$

当“取书”时间占比太高时，翻书再快也是白搭。所以想让 GPU 满负荷运转，就必须让每一趟取书都“满载而归”——这正是合并访问要解决的第一个问题。

合并访问原理

读者们并不是单独行动的，而是 32 个人坐成一桌，同时举手向管理员要书。在 GPU 中，这 32 个线程组成的团队叫做一个 Warp（线程束），它是线程调度和访存处理的最小单位。管理员不会分别处理 32 张索书单，而是把 32 个地址放在一起，统一决策怎么取。

这时有个决定性的细节：这 32 个地址是否连续。如果线程 0 要地址 100、线程 1 要地址 104、线程 2 要地址 108……就像 32 本书在书架上紧紧挨着，管理员推一趟车就能全部带回来。这种“同一 warp 的 32 个线程访问连续内存地址”的现象，就是 Coalesced Access（合并访问）。

$$A_{\text{max}} - A_{\text{min}} + s \le L_{\text{line}}$$

1. 线程组地址跨度：找出同 warp 内最大地址与最小地址之差，再加上元素大小 s，得到请求覆盖的总范围。

$$A_{\text{max}} - A_{\text{min}} + s$$

2. 缓存线长度：一次内存事务最多搬运的字节数 L_line，常见的硬件值是 128B。

$$L_{\text{line}} = 128\text{B}$$

3. 条件判断：如果覆盖范围不超过 128B，说明 32 个请求挤在一条“传送带”上，一次事务即可满足全部。

$$A_{\text{max}} - A_{\text{min}} + s \le 128\text{B}$$

所以，要给“读者”安排座位，就得让“书”按座位顺序排在书架上。数组的内存布局，直接决定管理员推一趟车能带回多少有用的书。

硬件执行机制

管理员的小推车容量是固定的，不能只装一本书就跑一趟——GPU 的内存系统也是如此。全局内存以固定大小的“块”为单位搬运，这个块叫缓存线（Cache Line），典型大小为 128 字节。即便程序只想要其中的 4 个字节，硬件也会把所在的整个块搬回来。

更细致的划分是 32 字节的扇区（Sector）。一条 128B 缓存线被切成 4 个扇区，实际传输时按扇区粒度组织。如果一个 warp 的请求恰好落在半个扇区上，另一半的字节也会被无差别搬回——这都是带宽开销。理解这一点后，你就能算出一笔账：一个 warp 读 32 个 float（每个 4 字节），理想情况下正好凑满 128 字节。

$$32 \times 4\text{B} = 128\text{B} = L_{\text{line}}$$

1. 线程数乘以元素大小：一个 warp 有 32 个线程，每个线程读一个 4 字节的 float。

$$32 \times 4\text{B}$$

2. 与缓存线长度比较：计算结果恰好等于一条标准缓存线 128B，说明装载量与小车容量完全匹配。

$$32 \times 4\text{B} = 128\text{B}$$

3. 满载事务数：在这种完美匹配下，内存系统只需 1 次事务就能完成整个 warp 的请求。

$$N_{\text{trans}} = 1$$

小车一趟能装多少书，决定了“满载”的定义。设计任何 GPU 数据结构时，心里都要装着 128 字节这把尺子——它是硬件世界的“车厢容量”。

非合并访问代价

如果读者要的书散落在书库的八个不同角落，管理员就得推八趟车，每趟车厢里只装四本书，其余空间全部空置。在 GPU 里，这种场景叫非合并访问（Uncoalesced Access），是最常见的性能杀手。

举个例子：32 个线程以 stride=32B 的间隔读 float，也就是线程 i 读地址 i×32 处的 4 个字节。线程 0 读 0，线程 1 读 32，线程 2 读 64……直到线程 31 读 992。从地址 0 到 992，跨越了整整 8 条 128B 缓存线，而每条线上只用到 16 字节。硬件被迫做 8 次事务，搬回 1024 字节，真正用到的只有 128 字节。

$$N_{\text{trans}} = \left\lceil \frac{(N_{\text{thread}} - 1) \times \text{stride} + s}{L_{\text{line}}} \right\rceil$$

1. 首末线程覆盖宽度：首个线程与最后一个线程之间的地址距离，再加上一个元素大小 s，得到完整访问范围。

$$(N_{\text{thread}} - 1) \times \text{stride} + s$$

2. 除以缓存线长度：用覆盖宽度除以 128B，看它横跨了几条缓存线。

$$\frac{(N_{\text{thread}} - 1) \times \text{stride} + s}{L_{\text{line}}}$$

3. 向上取整：只要碰到某条线的边界，哪怕只越界 1 字节，也要多算一次事务。

$$\left\lceil \frac{(N_{\text{thread}} - 1) \times \text{stride} + s}{L_{\text{line}}} \right\rceil$$

4. 代入 stride=32B 的实例：31×32+4=996，除以 128 向上取整得到 8 次事务，带宽利用率仅 12.5%。

$$\left\lceil \frac{31 \times 32 + 4}{128} \right\rceil = 8$$

带宽浪费就像推车空驶——运输的趟数是最硬的成本，千万别让小车运空气。8 倍事务意味着访存时间可能膨胀 8 倍，原本几分钟跑完的内核，可能变成几十分钟。

优化策略实战

解决问题的思路，是重新组织“借书单”和“书架排布”，让同一位管理员的每一趟车都满载。在 CUDA 中，最常见的优化是矩阵布局调整：二维数组默认按行主序存储，如果让相邻线程访问同一行的相邻列，地址就是连续的；但若让它们访问同一列的相邻行，地址就隔着一整行的距离，立刻变成非合并访问。

第二个经典优化是 AoS 转 SoA。假设你有一个存储 3D 坐标的结构体数组 struct Vec3 { float x, y, z; }，数组中每个元素连续存放 x、y、z。如果 32 个线程分别读取 32 个元素的 x 字段，它们之间的间隔是 12 字节——没对齐也没连续。改进办法是把布局改成三个独立数组 float xs[N]、float ys[N]、float zs[N]，读 x 字段的线程就连续访问了。

$$\text{pos}(r, c) = r \times W + c$$

1. 行偏移：第 r 行起始于 r×W 的位置，因为前面已经存了 r 个完整行。

$$r \times W$$

2. 列偏移：在本行内部，第 c 个元素要再往右移动 c 个位置。

$$+ c$$

3. 行主序连续的含义：相邻列 c 和 c+1 的地址相差 1 个元素，这正是合并访问需要的连续模式。

$$\text{pos}(r, c) = r \times W + c$$

书要按“读者座位”重新上架，这是合并访问优化的灵魂——布局先行，代码在后。同样一套计算逻辑，仅仅改变数据存储方式，访存效率就能从 12.5% 变成 100%。

对齐与整数倍

书架上的隔板位置是固定的，如果管理员第一本书没有放在隔板起点，第二本书就会横跨两个隔板，取书时反而要多翻一个格子。GPU 内存同理：基地址的对齐决定了你的连续请求会不会跨过 128B 边界。

即使 32 个地址完全连续，如果基地址错开了 64B，那么这 128B 的数据会横跨两条缓存线，硬件仍然要做 2 次事务。解决办法有两个：一是让分配器返回按 128B 对齐的内存（如 CUDA 的 cudaMalloc 通常保证 256B 对齐）；二是让二维数组的每一条“行”长度恰好是缓存线大小的整数倍，这样下一行又从对齐位置开始。

$$W' = \left\lceil \frac{W \times s_{\text{elem}}}{L_{\text{line}}} \right\rceil \times \frac{L_{\text{line}}}{s_{\text{elem}}}$$

1. 行原始字节数：矩阵一行有 W 个元素，每个元素占 s_elem 字节，因此一行占 W×s_elem 字节。

$$W \times s_{\text{elem}}$$

2. 向上取整到缓存线倍数：除以 128B 后向上取整，得到这一行实际占用的缓存线条数。

$$\left\lceil \frac{W \times s_{\text{elem}}}{L_{\text{line}}} \right\rceil$$

3. 换算回元素个数：把缓存线条数乘回 L_line / s_elem，得到 padding 后的新行宽，让每行起点对齐到 128B 边界。

$$W' = \left\lceil \frac{W \times s_{\text{elem}}}{L_{\text{line}}} \right\rceil \times \frac{L_{\text{line}}}{s_{\text{elem}}}$$

对齐是“让每趟推车都从隔板起点出发”的纪律。配合布局调整，合并访问才能万无一失：连续性负责满载，对齐性负责不踩线。

AI 应用场景

Python 演示

import math def simulate_warp_access(addr_start, stride, num_threads=32, line_size=128, bytes_per_thread=4):    """模拟一个 warp 的 32 个线程访问全局内存，统计缓存线事务数与带宽利用率。"""    lines = set()    for i in range(num_threads):        addr = addr_start + i * stride        line = addr // line_size        lines.add(line)    num_trans = len(lines)    useful_bytes = num_threads * bytes_per_thread    moved_bytes = num_trans * line_size    efficiency = useful_bytes / moved_bytes    return num_trans, efficiency  def main():    print("=== 模拟 GPU Warp 访存模式 ===")    print(f"{'stride':>6} {'trans':>5} {'efficiency':>10}")    for stride in [4, 8, 16, 32, 64, 128]:        trans, eff = simulate_warp_access(0, stride)        print(f"{stride:>5}B {trans:>5} {eff:>10.1%}")  if __name__ == "__main__":    main()

1. lines = set()用集合去重，多个线程落在同一条缓存线上时，只计一次内存事务。
2. line = addr // line_size将地址整除 128，得到这条地址所属的缓存线编号。
3. moved_bytes = num_trans * line_size硬件实际搬运的总字节数是事务数乘以 128B，不管有没有用到。
4. efficiency = useful_bytes / moved_bytes有效带宽利用率：真正读到的数据除以被搬运的总数据。
5. for stride in [4, 8, 16, 32, 64, 128]从小到大遍历步长，直观看出 stride=4（连续 float）时效率 100%，stride 越大浪费越严重。

常见误区

面试题