1. 先理解GPU为什么长这样：吞吐优先的硬件设计哲学
1.1 两种完全不同的“快”逻辑
很多人第一次接触GPU并行计算时，习惯性地把GPU理解成“很多个CPU 拼在一起”，这个直觉不算全错，但会严重误导后续的性能优化方向。CPU的核心设计目标是让单条指令尽可能快地执行完，它把大量晶体管用在分支预测、乱序执行、超大缓存上，换来的是极低的响应延迟。而GPU的核心设计目标是让海量指令在单位时间内尽可能多地完成，它不在乎某一条指令多花几个周期，在乎的是整个系统每秒钟能处理多少个计算任务。这两种目标决定了硬件资源的分配方式完全不同。
我常拿“小饭店”和“大食堂”来做类比：CPU就像小饭店，几个厨师手艺精湛，每个菜都精心烹制，但同一时间只能接待有限的客人；GPU就像大食堂，几十个窗口同时出餐，每个窗口的师傅只重复做几样固定的菜，单个窗口的效率未必高，但整体吞吐量碾压小饭店。GPU并行计算架构的所有设计，都是围绕“大食堂”这个思路展开的。
1.2 延迟隐藏是GPU的生命线
既然单个计算单元的执行效率不高，GPU靠什么弥补？答案是延迟隐藏。简单说，当一组计算任务正在等待数据从显存返回时，GPU不会让计算单元闲着，而是立刻切换到另一组已经准备好数据的任务继续执行。这种切换开销极低，因为硬件的寄存器资源是按“组”预先分配好的，切换线程组只需要改变一组指针，几拍之内就能完成。
这就是为什么GPU编程模型 要求你把问题拆成“成千上万个细小子任务”。如果子任务数量太少，切换的余地就小，数据等待期间计算单元只能空转，GPU的优势完全发挥不出来。我见过不少第一次写GPU程序的开发者，把一个循环拆成几百个线程就觉得已经“并行”了，结果跑出来比CPU还慢，原因就是子任务数量远不够填满硬件的调度流水线。理解“延迟隐藏”这四个字，是读懂后面所有硬件细节的前提。
1.3 软件线程与硬件执行单元的比例
另一个容易误解的概念是“软件线程”和“硬件执行单元”的关系。你在编程接口里创建一万个逻辑线程，并不代表硬件里有一万个物理执行单元，实际执行单元是有限的，这一万个线程会被分批、分时地调度到物理单元上执行。所以GPU编程的终极目标是：把足够多的逻辑线程组织成合理的形状，让有限的物理单元始终处于饱和状态。
这里有一个关键经验：逻辑线程的数量最好是“物理执行单元的整数倍以上”，一般建议至少达到几倍的冗余，因为不同子任务的访存节奏、计算复杂度都不一样，只有留下足够的调度余量，才能让硬件一直在切换中找到可以立即执行的线程组。实际项目 中，这个倍数通常用“占用率”来衡量，后面我会细讲怎么算。
2. 硬件骨架拆解：计算单元、线程束与指令发射
2.1 流处理器簇：真正的大食堂窗口
GPU的物理计算核心被组织成若干“流处理器簇”，每个簇内部包含一整组整齐划一的执行单元、共享的寄存器堆和一块容量不大但速度很快的共享内存。你可以把一个簇想象成一个独立的小食堂，里面有几十个窗口、一块公用的配菜台和一个订单调度员。不同的簇之间相对独立，有各自的资源边界，无法随意借用彼此的寄存器和共享内存。
同一个簇内部，所有执行单元共享同一套指令流：调度器每次选择一个“线程束”——通常由32个逻辑线程组成——然后让这32个线程的指令在多个执行单元上同步执行。也就是说，GPU本质上是一个“单指令多线程”的机器，一个簇在某一个时钟周期内，所有活跃线程都在执行同一条指令，只不过作用在不同的数据上。
2.2 为什么要设计成32个线程一束
线程束的粒度选择是硬件设计的一个核心权衡。32这个数字不是拍脑袋定的，它对应了执行单元的宽度和寄存器堆的带宽。当32个线程同时访问寄存器时，寄存器文件可以一次完成32份数据的读取，这种批量操作能最大化利用芯片内的布线资源。如果线程束太窄，指令发射的带宽利用率就会下降；如果太宽，分支分歧带来的浪费会更大，调度粒度也会变粗。经过多年平衡，32成了主流约定。
对写程序的人来说，线程束最重要的含义是：你的分支语句最好以线程束为单位保持一致。假如一个线程束里部分线程走if分支、部分走else分支，硬件只能分别执行两个分支，另一半执行单元在等待时是空闲的。这种“分支发散”是性能杀手，我在优化项目时优先检查的就是有没有线程束级别的分支分歧。
2.3 指令发射与寄存器压力的矛盾
每个流处理器簇内部，指令发射是一个周期性的流水过程：取指、译码、发射、执行、写回。为了保证32个线程的数据都在寄存器里躺好，每个线程能用的寄存器数量是有上限的。寄存器总量固定，如果每个线程占用越多寄存器，那么同一时刻能容纳的线程数就越少，调度器可切换的备选线程组就越少，延迟隐藏能力就越弱。
很多人不知道的是，编译器有时会把数组索引访问塞进一个叫“本地内存”的地方，表面看这仍然是“内存操作”，实际上本地内存的访问延迟比寄存器高一个数量级，而且它还会挤占全局显存的带宽。这属于“寄存器溢出”——程序里的寄存器需求量超过了硬件限制，编译器只好把多余的变量存到慢速空间里。遇到这种情况，降低单个线程的寄存器用量（比如砍掉过大的局部数组）往往比优化算法 本身更有效。
3. 内存体系是性能命脉：合并 访问、共享内存与Bank冲突
3.1 全局内存的合并访问规则
GPU并行计算里，绝大多数性能问题最终都会归因到访存。显存带宽虽然大，但它是一个共享的稀缺资源，所有线程都在抢。为了让有限的带宽发挥最大价值，硬件的内存控制器要求：同一线程束的32个线程，在访问全局内存时最好访问一段连续地址。
如果32个线程恰好访问连续地址，硬件可以把这32份数据合并成几次大块传输，一次完成。如果线程之间的地址跳来跳去，硬件就不得不拆分成多次小传输，带宽利用率直线下降。这就像搬家时，如果你把所有箱子按顺序堆在门口，一辆大货车就能拉走；如果每层楼都放几箱，就得来回跑很多趟。
实际编码时要注意：线程束内相邻线程的访问地址要相邻。最常见的问题是数据排列不当，比如线程束访问一个二维数组的某一列而不是某一行，地址就不连续，性能可以差出数倍。优化这类代码的第一步往往不是改写算法，而是把存储布局从“列优先”改成“行优先”，或者引入转置和分块。
3.2 共享内存：用户可控的高铁通道
共享内存是GPU架构里最值得花时间研究的存储层次。它位于流处理器簇内部，访问延迟比全局内存低得多，带宽极高，而且完全由程序员控制。你可以把共享内存理解为食堂里的配菜台：厨师（执行单元）做菜时不用每次跑去仓库（全局内存）取菜，而是提前把常用材料堆在配菜台上，随手可取。
共享内存最有价值的用途是“数据复用”。在很多算法里，相邻线程会访问大量重叠的数据，如果每个线程都直接去全局内存读取，带宽很快被耗尽。更好的做法是：先把数据块从全局内存加载到共享内存，然后所有线程只从共享内存里反复读取。这种做法在矩阵乘法、卷积、图像处理中都是核心优化手段。
3.3 Bank冲突：共享内存里最大的坑
共享内存虽然在硬件层面很快，但它有一个结构限制：整块共享内存被划分成若干个“Bank”，每个Bank在同一个时钟周期内只能被访问一次。当线程束内的多个线程同时访问同一个Bank的不同地址时，硬体会把这些访问强制拆成多次执行，这个过程叫Bank冲突。极端情况下，32个线程访问同一个Bank，性能会退化到原本的几十分之一。
避免Bank冲突的常用思路是“错位访问”：给数组加上一小段填充，让原本对齐的地址错开。比如共享内存数组的第0行有32个float，你在分配时每一行额外加一个float的padding，线程访问第0行第0列时落在一个Bank，访问第1行第0列时落在另一个Bank，冲突就自然缓解了。这个技巧很简单，但如果不了解Bank机制，新手往往遇到共享内存变慢却完全不知道原因。
4. 让硬件吃饱：并行度、占用率与性能估算模型
4.1 为什么“线程多”不等于“并行度高”
每个程序员都知道GPU需要大量线程，但“大量”到底是多少，很多人没有概念。假设一个流处理器簇最多能同时容纳2048个活动线程，你的程序却只排了1024个线程，那么有一半的调度席位空着，硬件在等待数据时连切换的候选都没有。反过来，如果你的寄存器使用率偏高，导致每个线程占的资源太多，也会压缩活动线程的容量。这两个因素都属于“占用率”的范畴。
占用率 = 实际活动线程数 / 硬件最大支持线程数，它是一个百分比。我见过一个常见的误区：为了提高单线程性能，把大数组全部存在寄存器里，结果寄存器爆掉，编译器开始溢出到本地内存，占用率暴跌，整体性能比朴素版本还慢两倍。优化GPU程序时，单线程效率是第二位的，让硬件满负荷运转才是第一位。
4.2 一个简单模型：算清楚你的任务要跑多久
我在做性能预估时喜欢用一个简化的模型，把每次执行看作两个阶段的循环：读数据、算结果。假设访问一次全局内存的延迟是400个周期，而一次计算操作只需要4个周期。如果程序是纯粹的计算密集型任务，那么每个线程几乎不需要等待数据，计算单元的利用率可以接近100%；如果是访存密集型任务，大量时间花在等待数据上，此时必须依靠高占用率来切换线程，掩盖等待。
更直观的估算方式是：先统计程序里每条核心指令的占比，再乘以对应的延迟，加起来得到一个平均延迟。然后用“总指令延迟”和“可并行任务数”算理论吞吐量，再对比实际测试结果，偏差通常能定位到瓶颈是计算单元、访存带宽还是等待延迟。这个模型不需要多精确，能帮你判断优化方向就足够了。
4.3 调节三个旋钮：线程块大小、寄存器上限、共享内存分配
现代GPU编程接口允许你在启动计算时指定线程块的大小，一般取256或512是比较稳妥的选择。线程块太小会让调度器频繁切换，增加开销；线程块太大又可能超出硬件资源限制，导致启动失败。共享内存的分配也是一个旋钮：分配越多共享内存，每个簇能同时容纳的线程块就越少，占用率就会下降。所以共享内存并非越多越好，而是要用在能明显减少全局访问的地方。
我见过有人为了追求极高的占用率，把所有共享内存需求都降到零，结果程序性能反而变差。因为全局访问次数增加了好几倍，让有限的显存带宽成了新的瓶颈。占用率只是一个中间指标，最终目标是最小化总执行时间——这需要你在占用率和数据复用率之间找平衡。
5. 真实项目中的优化链路：从瓶颈定位到代码改造
5.1 先用性能分析工具，不要靠猜
每次接手一个新的GPU并行计算项目，我的第一步永远是运行性能分析工具，把内核执行时间、访存指令占比、分支效率、占用率这些指标拉出来看。原因很简单：GPU的性能瓶颈往往藏在你看不见的硬件行为里，靠肉眼读代码很难判断是寄存器溢出、Bank冲突还是全局内存访问次数过多。
性能分析工具的报告会直接告诉你哪些地方有“卡点”：比如某个内核的访存等待时间占比高达70%，那就优先在访存布局上做文章；如果报告显示有严重的分支发散，那就去检查线程束内部的数据分布条件；如果显示活动线程数低于理论值，那就去调寄存器上限或共享内存分配策略。数据驱动比经验驱动靠谱得多。
5.2 案例：矩阵乘法的分块优化
矩阵乘法是最经典的教学案例，也是我实际调优时最常拿来练手的问题。朴素做法是每个线程算输出矩阵的一个元素，每个元素需要整行和整列的反复访问，对全局内存的访问次数非常夸张。优化做法是分块：把大矩阵切成小块，每个线程块负责一小块输出区域，先把所需的两个“小方块”加载到共享内存，再在共享内存里完成累加。这个策略把全局内存访问次数降了数量级，是共享内存数据复用的教科书级应用。
我在一个模拟项目X里实践过从朴素版到分块版的优化：矩阵规模约4096乘4096，经过分块和线程束合并访问调整后，执行时间从80多毫秒降到了不到10毫秒，核心变化就是把每次累加都要读全局内存改成了共享内存反复读写。这个案例里还带着一个隐藏问题：分块大小不能盲目取大，因为共享内存有限，块太大反而降低占用率。最后我试出来的最优分块是16乘16的块，配合16乘16的线程块，整体效果最稳。
5.3 案例：从瓶颈出发改造访存模式
另一个真实项目是图像滤波的并行实现，需求是对一张大图做一个5乘5的卷积。初始实现直接让每个像素的线程去全局内存读取邻域像素，编译运行后速度只比CPU版本快了一点点。用性能分析工具一看，问题一目了然：全局内存读请求次数极高，带宽几乎被压满，而计算单元利用率却很低。
改造方案分两步。第一步做成行缓存：每个线程块先把一行数据加载到共享内存，处理时纵向复用；第二步处理边界像素，避免线程分支发散。改造之后带宽占用下降了约一半，整体加速比接近理论上的可用带宽上限。从这段经历里我最深刻的体会是：GPU并行计算优化的本质，不是把代码写得“更并行”，而是把数据的访问路径理顺。
5.4 几个绕不开的细节与常见误区
最后整理几条项目里反复踩过的细节，供后来者参考。
第一，整数除法和浮点特殊函数尽量少用。核函数里一个看起来不起眼的整数除法，在32个线程同步执行时会重复占用执行单元很多个周期，如果循环里还反复调用，性能损失会被放大。第二，尽量避免在核函数里写动态分配和递归，这类操作会让局部线程的控制流不一致，严重影响调度器的效率。第三，内核启动是有固定开销的，如果计算量太小（比如只处理几千个数据），启动开销可能比计算本身还大，这种场景用GPU反而得不偿失，适合CPU侧处理。
还有一个经常被忽视的地方是编译选项。不同编译选项对寄存器分配策略影响很大，有的优化选项会为了减少指令数而增加寄存器占用，有的则是反过来压缩寄存器数量、增加指令数。我在几个项目里的经验是：不要默认编译选项，要实际试两三种组合，对比性能后再定。开发时用调试方便的选项，发布时再用激进一点的优化选项，这是一种很实用的工作流。
从我这些年接触GPU并行计算的经验看，最值得反复读的永远是架构手册里关于内存和调度的部分。很多所谓“玄学性能问题”，本质上都是某条硬件规则没摸透。先把线程束的调度方式、内存合并访问、共享内存的Bank结构这几件事刻在脑子里，再去看各种高级优化技巧，就会顺畅得多。如果你正卡在某个性能瓶颈上，不妨先把代码放下，开一份性能分析报告，对着这篇内容逐条核对，通常很快就能找到那个被忽略的硬件限制。
版权声明：本文为CSDN博主「凯萨薇」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_29191669/article/details/168812565
