合并访存（Coalesced Memory Access）：小白也能懂的GPU访存优化核心
核心结论：合并访存是GPU全局内存访问的"黄金优化法则"------让同一个线程束（32个线程）访问连续、对齐的内存地址，使GPU的内存控制器把32个分散的访存请求"合并"成1次批量请求，就像32个工人按顺序排队搬砖，卡车1趟就能拉完，而非乱抢砖导致卡车跑32趟，大幅提升访存效率。
下面用"工厂搬砖"的比喻，从"为什么需要合并访存"到"底层原理"，全程小白友好，避开复杂术语。
一、先搞懂2个基础概念（小白必看）
要理解合并访存，先认清GPU访存的两个"底层规则"，否则所有原理都是空中楼阁：
| 概念 | 大白话解释 | 工厂比喻 |
|---|---|---|
| 线程束（Warp） | GPU调度的最小单位，固定32个线程为一组------GPU不会单独调度1个线程，要么调度整组32个，要么都不调度 | 工厂的"搬砖班组"，固定32个工人为一组，班长只派整组干活，不派单个工人 |
| 内存段（Memory Segment） | GPU内存控制器处理访存请求的最小单位（通常128字节，不同架构略有差异）------不管你要1字节还是128字节，GPU都会一次性读取/写入1个内存段 | 搬砖的"卡车货厢"，固定装128块砖（每块4字节，对应float），哪怕只需要1块，也得拉一整厢 |
补充：我们常说的"GPU显存"（全局内存），访问速度远慢于共享内存/寄存器，访存延迟是GPU性能的最大瓶颈------合并访存就是解决这个瓶颈的核心手段。
二、为什么需要合并访存？（用比喻讲透核心痛点）
假设你是工厂老板，要让32个工人（1个线程束）搬32块砖（每个线程拿1个float数据，4字节/块），砖在仓库里排成一排（内存地址连续）：
场景1：非合并访存（乱序搬砖，效率极低）
工人乱抢砖：
- 工人0拿第1块，工人1拿第33块，工人2拿第65块...工人31拿第993块；
- 每块砖分散在不同的货厢里，卡车要跑32趟，每趟只拉1块砖；
- 仓库管理员（内存控制器）要处理32次请求，还要来回找砖，耗时极长。
对应GPU行为：32个线程访问分散的内存地址，内存控制器发32次访存请求，每次只拿4字节，128字节的货厢（内存段）只利用了3.125%，带宽严重浪费，访存效率只有1/32。
场景2：合并访存（顺序搬砖，效率拉满）
工人按顺序搬砖：
- 工人0拿第1块，工人1拿第2块...工人31拿第32块；
- 32块砖刚好装满1个货厢，卡车1趟就拉完；
- 仓库管理员只处理1次请求，直接拉走整厢砖，效率100%。
对应GPU行为：32个线程访问连续的128字节地址（32×4=128），内存控制器只发1次请求，拿到整段内存后分给32个线程，带宽利用率100%。
三、合并访存的底层原理（3个核心要点）
合并访存的本质是让线程束的访存请求匹配GPU内存控制器的"批量处理规则"，核心原理可拆解为3步：
1. 批量请求：内存控制器只认"整段内存"
GPU的内存控制器（处理全局内存读写的硬件）不处理"单个字节"的请求，只处理"固定大小的内存段"（比如128字节）------这是硬件设计的硬规则。
- 合并访存：线程束的32个线程请求的地址刚好凑成1个完整的内存段，控制器1次请求就能满足所有线程；
- 非合并访存：线程请求的地址分散在多个内存段，控制器要发多次请求，每次只取少量数据，剩下的内存段空间全浪费。
2. 地址连续：线程索引和内存地址一一对应
合并访存的核心条件是：同一个线程束内，线程tid（0~31）访问的地址 = 基地址 + tid × 数据类型大小 。
举个具体例子（float类型，4字节）：
cuda
// 合并访存：线程tid访问连续地址
float* g_data; // 全局内存数组
float value = g_data[base + tid];
// tid=0 → base+0 → 地址X
// tid=1 → base+1 → 地址X+4
// ...
// tid=31 → base+31 → 地址X+124
// 总地址范围：X ~ X+124（128字节），刚好1个内存段如果改成g_data[base + tid × 32]（步长32），地址就会变成X、X+128、X+256...分散在不同内存段，变成非合并访存。
3. 地址对齐：起始地址要"卡准格子"
即使地址连续，若起始地址不是内存段大小的整数倍（比如128字节对齐），也会变成"半合并"访存，效率打折扣。
例子：未对齐的连续访问
内存段大小128字节，地址段为：0127、128255、256~383...
- 线程束访问地址：10 ~ 137（32个float，128字节）；
- 起始地址10不是128的倍数，这个地址范围跨了"0127"和"128255"两个内存段；
- 内存控制器需要发2次请求，读取两个内存段，再从中提取10~137的部分，效率只剩50%。
对齐的连续访问
- 线程束访问地址：128 ~ 255（起始地址128是128的倍数）；
- 控制器只发1次请求，效率100%。
小白技巧：CUDA中用
cudaMalloc分配的全局内存，默认是128字节对齐的，只要按顺序访问，就能满足对齐要求。
四、合并访存的判断标准（小白一眼就能懂）
不用记复杂参数，只需检查2点，就能判断是否是合并访存：
- 同一线程束内：线程0~31访问的内存地址是否连续（比如tid=0对应地址A，tid=1对应A+4，...tid=31对应A+124）；
- 起始地址：连续地址的起始值是否是内存段大小（128字节）的整数倍。
不同数据类型的合并访存要求（小白速查表）
| 数据类型 | 单个大小（字节） | 32线程总大小（字节） | 合并访存地址范围（示例） |
|---|---|---|---|
| char（int8） | 1 | 32 | 0~31（32字节，半合并）/ 0~127（128字节，全合并） |
| short（int16） | 2 | 64 | 0~63（64字节，半合并）/ 0~127（全合并） |
| float（int32） | 4 | 128 | 0~127（刚好1个内存段，全合并） |
| double（int64） | 8 | 256 | 0~255（2个内存段，需要2次请求，但仍是合并访存） |
补充：double类型的合并访存需要2次请求，但仍是最优解------因为32个线程访问256字节连续地址，比分散访问效率高16倍。
五、小白踩坑点（避坑指南）
- 跨步访问是最大坑 ：线程访问地址的步长≠数据类型大小（比如
g_data[tid×8]，步长8＞float的4字节），必成非合并访存； - 二维数组的行优先/列优先 ：访问
g_data[row*COLS + col]（行优先）是合并访存，访问g_data[col*ROWS + row]（列优先）是跨步访问，非合并； - 奇数长度数组：数组长度不是32的倍数，最后一个线程束会有"无效线程"，但只要有效线程访问连续地址，仍算合并访存；
- 现代GPU的"自动合并"：新架构（Ampere、Ada）对非合并访存有一定的自动优化，但手动做合并访存仍能提升3~10倍效率。
总结
关键点回顾
- 合并访存的核心：让同一个线程束的32个线程访问连续、对齐的全局内存地址，将32次分散请求合并成1~2次批量请求；
- 底层原理：匹配GPU内存控制器的"批量处理规则"，充分利用内存带宽，减少访存请求次数；
- 优化要点：线程索引和内存地址一一对应（步长=数据类型大小），保证起始地址对齐，避免跨步访问。
对小白来说，合并访存是GPU编程中"投入最少、收益最大"的优化手段------只需调整线程访问地址的方式，就能让全局内存访存效率提升10倍以上，是写CUDA代码必须掌握的核心知识点。