并行计算性能优化：Amdahl定律、CPU/GPU协同与工程实践-平芜编程栈

简介：《Parallel and High Performance Computing》是Manning出版社2021年推出的高性能计算实战读物，面向具备一定C/C++与科学计算基础、希望把串行代码改造为并行程序的开发者与理工科研究生。全书先讲并行计算的动机与并行化规划，再讨论性能上限、性能分析工具、数据设计与性能模型、并行算法与模式，随后落到CPU侧的向量化、OpenMP多线程、MPI分布式通信，并延伸至GPU加速与异构编程，方法论与可实践代码并重，对标签所提的parallel与GPU方向都有对应章节。资源包内为1个PDF文件，约35.83MB，保留原书版式与完整章节目录，便于按主题检索和跳读。目前已有692人学习下载，适合用来系统梳理并行思维、对照开展性能调优与瓶颈排查的中高级读者。

1. 为什么并行计算成了必修课：0.8% 与 99.2% 的反差

一本 2021 年出版的并行计算专著，扉页上放了两个饼图：串行部分 0.8%，并行部分 99.2%。意思是今天机器里真正"一次只干一件事"的算力只剩零头，剩下的全是要靠并行才吃得下的部分。你写一段纯串行循环，等于把整台机器百分之一不到的力气用上了，其余都在旁边看着。

打个比方，搬家公司开了一辆能装一百箱的货车过来，你却坚持用行李箱一趟一趟拖。并行计算与高性能计算讲的不是让你换门语言，而是货该怎么码、路该怎么走、哪一段会堵。

不懂这套规则，代码照样能跑，但慢得莫名其妙，而且你根本不知道慢在哪。这就是值得花时间搞懂的理由。

2. 并行的天花板在哪：Amdahl 定律与三条性能红线

2.1 加人不等于线性提速：那盆叫 Amdahl 的冷水

装修刷墙是个好模型。十面墙，一个人刷十小时；十个人一起来，理论上一个小时搞定。但前提是墙够多、滚筒够用、没人挡着谁。如果有一面墙必须先晾干才能刷第二遍，那十个人也得排队等那一段——这段等待就是串行部分，它不随人数增加而缩短。

Amdahl 定律把这个直觉写成了公式：

加速比 S(n) = 1 / ((1 - p) + p / n)

p是可以并行的那部分占比，n是并行单元数。代入几组数字就明白残酷在哪：p = 0.9、n = 8时加速比约 4.7 倍；p = 0.9、n趋近无穷大时，加速比卡死在 10 倍；只有当p = 0.99，理论上限才抬到 100 倍。换句话说，串行那 10% 决定了你花多少钱堆机器都摸不到的天花板。

这里有个关键参数：p不是拍脑袋估的，得靠性能分析工具测出来。一个程序里到底有多少时间花在可以并行的循环上、多少花在文件读取和初始化上，量一遍才知道。凭感觉估p = 0.95，实测往往是 0.8，投入产出比立刻翻车。

Gustafson-Barsis 定律给了另一半答案：如果问题规模可以随机器一起变大，加速比的天花板是可以往上抬的。公式是S = n - (1 - p)(n - 1)。翻译成人话：固定一个问题看能快多少，和固定时间看能算多大，是两个不同的问题。前者受 Amdahl 约束，后者受规模红利照顾。做科学计算的人更关心后者——机器变强了，就把网格划得更细、把时间步缩得更小，而不是死守原来那个规模。

两条定律的实用价值在于：先量出串行占比，再决定这活儿值不值得并行化。如果串行部分占 30%，那再怎么优化并行部分，最多也就 3 倍出头，不如先去优化那段串行代码。

2.2 三条尺子：峰值算力、内存带宽、机器平衡点

判断一个程序"该往哪个方向优化"，靠三个数字。

峰值浮点性能，单位是 GFlops/s，粗估方式是核数乘以每周期能做的浮点操作数再乘以频率。这是理论上限，实际代码很难摸到，能到六七成就已经很漂亮。峰值内存带宽，单位是 GB/s，是把数据从内存搬到处理器的高速通道有多宽。两者一除，得到机器平衡点，单位是"每字节多少次浮点运算"。

指标	单位	估算方式	实际预期
峰值浮点性能	GFlops/s	核数 × 每周期操作数 × 频率	实测算力常为峰值的 50%～70%
峰值内存带宽	GB/s	厂商规格，另用基准实测	实测常为标称值的 50%～80%
机器平衡点	Flops/Byte	峰值算力 ÷ 峰值带宽	数值越大，越容易卡在带宽上

还是厨房的比喻：灶眼数量是算力，从冰箱到灶台的通道宽度是带宽。灶眼加到二十个，通道还是单人侧身过，那也只能干等着。机器平衡点就是在问：每搬一公斤食材进来，你能炒几个菜？搬一次只炒一个菜，那你就是带宽受限，加灶眼没用。

衡量应用侧的对应指标叫算术强度：每读一个字节的数据，做了多少次浮点运算。算术强度低于机器平衡点，说明程序是内存受限，优化方向是改数据布局、提高缓存命中、减少无谓搬运；高于平衡点，才是计算受限，这时候向量化和更强的算力才有意义。

测带宽有个经典小基准，叫 Stream Triad：

// a[i] = b[i] + scalar * c[i] // 每次迭代读两个数组、写一个数组，共 24 字节，做 2 次浮点运算 // 用它测出来的带宽，比看规格表靠谱得多 for (int i = 0; i < n; i++) { a[i] = b[i] + scalar * c[i]; }

这段循环访存连续、没有分支、没有依赖，是最理想的带宽测量样本。跑一遍，用总字节数除以耗时，就得到这块机器在真实代码下的带宽。很多人第一次测完会发现，标称和实测能差一倍，这个差距就是后面所有优化的现实起点。

2.3 数据怎么摆，比你写什么循环更关键

很多人优化并行程序的第一反应是改循环，其实真正决定性能的往往是数据结构的摆放方式。举个粒子模拟的例子，每个粒子有位置三分量和质量：

// 写法一：结构体数组（AoS），一个粒子的所有字段挨在一起 struct Particle { float x, y, z, mass; }; struct Particle particles[N]; // 写法二：数组结构体（SoA），同一字段的所有粒子挨在一起 float x[N], y[N], z[N], mass[N];

如果循环里只用到x，第一种写法会把y、z、mass一起拖进缓存行，等于每读一个有用的数，顺带浪费三个位置。第二种写法里x是连续存放的，读起来干净利落。在带宽受限的程序里，这个差别能到两三倍。折中方案叫 AoSoA，把粒子分成固定大小的块，块内用 SoA、块间用 AoS，兼顾连续访存和缓存局部性。

缓存未命中有三种来源，业内叫三个 C。强制性未命中（compulsory）是第一次访问某块数据，躲不掉；容量未命中（capacity）是缓存装不下工作集，旧数据被挤出去；冲突未命中（conflict）是不同地址映射到同一缓存组，互相顶掉。区分它们的方法很朴素：把数据规模缩小到能塞进缓存，如果性能突然变好，那多半是容量问题；如果换个数组大小性能就抖一下，那是冲突问题。

稀疏矩阵更能说明问题。同样的数学问题，用稠密二维数组存会浪费大量零元素，用压缩稀疏行格式只存非零值和列索引，内存占用能降一个数量级，但访存变随机了。选哪种表示，取决于矩阵稀疏程度和你更怕内存还是更怕带宽——这本身就是一道性能取舍题。

3. CPU 这条主线：向量化、OpenMP、MPI 各管哪一段

3.1 向量化：一条指令干四份活

现代 CPU 里有一类指令叫 SIMD，单指令多数据。一条加法指令可以同时对四个或八个浮点数生效，等于免费捡了几倍算力，前提是编译器看得出这几份数据互不干扰。

// 没有分支、访存连续、没有指针别名，最容易被自动向量化 void add(float *a, float *b, float *c, int n) { for (int i = 0; i < n; i++) { c[i] = a[i] + b[i]; } }

配合编译选项开启：-O3 -march=native让编译器针对本机指令集生成代码，-fopt-info-vec一类开关可以打印哪些循环被向量化了、哪些没有、原因是什么。这一步最容易被忽略——很多人以为自己开了优化就向量化了，实际编译器早就默默放弃了，只是没告诉你。

阻碍向量化的常见写法有几种：循环体里有if分支、调用了无法内联的函数、指针之间存在别名（编译器不敢确定a和c不重叠）。解决办法分别是改写成分支无关的形式、加内联、给指针加restrict限定。实在不行可以上 OpenMP 的#pragma omp simd明确告诉编译器"这个循环放心向量化"，或者用编译器内置的向量类型手写，代价是可读性下降、换平台要重写。

向量化属于"改动小、收益稳"的一档。一个访存密集的循环，向量化之后常见能快两三倍，而且不涉及线程调度、不用改程序结构。它的天花板也明显：受限于指令宽度，通常就是四倍或八倍。

3.2 OpenMP：共享内存里的分工牌

一台机器多个核，共享同一块内存，这时候用 OpenMP 最省事。它靠编译指令（pragma）工作，不改代码逻辑，只在循环或代码块前面加一行。

#include <omp.h> double sum = 0.0; // 把循环拆给多个线程，每个线程算一部分，最后自动合并 // reduction(+:sum) 让每个线程持有自己的局部和，结束时再相加 #pragma omp parallel for reduction(+:sum) for (int i = 0; i < n; i++) { sum += a[i]; }

关键在于变量作用域。循环下标默认是每个线程私有的，循环外声明的变量默认是共享的。这个默认值坑过很多人：一个临时累加变量忘了声明成私有，多个线程同时往上加，结果每次运行都不一样，还查不出原因。这种问题叫竞态条件，属于并行编程里的玄学，靠打印调试基本没戏，得用专门的线程检查工具跑一遍。

OpenMP 有三档用法。最浅的一档是循环级并行，加一行 pragma 就完事，适合快速试水。中间一档是函数级并行，把整段逻辑包进并行区域，靠显式的同步点协调。最深一档是和 MPI 混用，每个节点开若干线程，节点之间靠消息通信。

用的时候要注意几个默认陷阱：默认线程数往往等于逻辑核数而不是物理核数，超线程在计算密集场景反而拖慢；线程绑定（affinity）没设好，线程会在核之间来回迁移，缓存全废；并行区域开得太小，线程创建销毁的开销比计算本身还大。这三点合起来，就是"加了并行反而更慢"的常见原因。

3.3 MPI：跨机器的消息骨架

一台机器装不下的问题，得靠多台机器一起算。这时候内存不共享了，每个进程有自己独立的地址空间，只能靠发消息交换数据。MPI 就是这套消息机制的标准接口。

#include <mpi.h> MPI_Init(&argc, &argv); // 启动并行环境 MPI_Comm_rank(MPI_COMM_WORLD, &rank); // 我是第几号进程 MPI_Comm_size(MPI_COMM_WORLD, &size); // 一共多少个进程 double local = compute_my_part(rank, size); double global = 0.0; // 把所有进程的局部结果求和，结果广播给每个进程 MPI_Allreduce(&local, &global, 1, MPI_DOUBLE, MPI_SUM, MPI_COMM_WORLD); MPI_Finalize(); // 收尾

最基本的通信是点对点发送和接收：一个进程MPI_Send，另一个MPI_Recv。实际写代码时用得更多的是集合通信——广播把一份数据发给所有进程，归约把所有进程的值合成一个，分发把数据切开分给各进程，收集把各进程的结果拼回来。这四类操作覆盖了绝大多数场景，比自己手写循环发送可靠得多。

两个进阶技巧值得知道。一是自定义数据类型：如果每个进程要发一个结构体，逐个字段发会有多次通信开销，把结构体的内存布局描述成一个 MPI 类型，一次就能发完。二是笛卡尔拓扑：给进程网格编上二维或三维坐标，邻居是谁一目了然，写边界交换时代码清晰很多。

边界交换（ghost cell exchange）是科学计算的经典模式。把一个大网格切成若干块分给各进程，每块计算时需要邻居块边缘的一圈数据。于是每步迭代都要和上下左右四个邻居交换这一圈。通信量不大，但频率高，能不能和计算重叠起来，直接决定扩展性。当进程数从几十涨到几千，这部分的开销会逐渐吃掉并行收益，这也是强扩展性测试里最先暴露的瓶颈。

3.4 三层叠起来才完整

把上面三样串起来，一个现代 CPU 程序的并行层次是：最内层靠向量化榨干单核，中间层靠 OpenMP 用满一台机器的所有核，最外层靠 MPI 把多台机器连起来。三者不是替代关系，是叠加关系。

为什么最外层不直接用 OpenMP 覆盖所有核？因为跨机器的内存不共享，OpenMP 的共享变量模型出了单机就失效。为什么不用 MPI 覆盖单机内部？因为进程间通信要过操作系统，开销比线程间共享内存高一个量级，同一台机器上开几十个 MPI 进程纯属浪费。

混合模式（MPI + OpenMP）的典型配置是：每个物理节点起一个或两个 MPI 进程，每个进程内开与物理核数相当的线程。这样既控制了通信进程的数量，又用满了节点的算力。配置不对的典型症状是：进程数开太多，通信时间占比飙升，加机器反而变慢。

4. GPU 这条路：加速器为什么不是"更快的 CPU"

4.1 硬件模型：一千个小学生和几个博士生

CPU 和 GPU 的设计哲学完全不同。CPU 是几个博士生，什么活都能干，擅长处理分支、乱序执行、复杂的控制流。GPU 是一千个小学生，只会做同一道算术题，但同时做、做得飞快。它们不是替代关系，是分工关系。

GPU 内部的组织结构大致是三层：最外层是若干流式多处理器（不同厂商叫法不同，有的叫计算单元），每个里面有一批处理单元，处理单元再往下是寄存器和一小块高速共享内存。调度以固定大小的组为单位，组内所有单元锁步执行同一条指令——一个组里的三十二个单元，如果代码里出现分支，一部分走 if、一部分走 else，那两组要分别执行一遍，等于白白浪费一半时间。这就是为什么 GPU 最怕分支发散。

有个关键指标叫占用率：每个流式多处理器上同时驻留多少个工作组。占用率高，一组在等内存的时候，调度器可以切到另一组继续算，延迟就被掩盖了。占用率低，处理器就干等着。影响占用率的主要因素是每个线程用的寄存器数量和共享内存大小——内核写得太"奢侈"，占用率就上不去，再好的硬件也跑不满。

这也解释了一个反直觉现象：把内核里的临时变量精简一下、少用几个寄存器，性能可能提升百分之几十，比改算法还管用。

4.2 编程模型：每个工作项只知道自己的编号

GPU 编程模型的核心思想是"我编程"：你写的不是"整个数组怎么处理"，而是"第 i 个工作项该怎么处理我这一份数据"。工作项按网格组织，网格切成工作组，工作组内的项可以共享一小块高速内存并做同步，跨工作组就只能靠内核结束来间接同步。

索引映射是最容易出错的地方。一个工作项要算出自己在全局的第几号、在组内的第几号、属于第几组，三者组合起来才能定位到该处理哪个数据元素。写错一位，结果就是错位的——程序不崩，但算出来是垃圾，这种 bug 排查起来极其痛苦。

正因为跨工作组没有同步原语，经典的归约操作要分两阶段：组内先归约到一个值，写回全局内存，再启动第二个内核把各组的值归约成最终结果。想在 GPU 上写一个"全局求和"，比在 CPU 上复杂得多，这是很多人第一次上手时最不适应的地方。

内存层级也要心里有数：全局内存容量大但慢，共享内存快但小，寄存器最快但最少。数据在哪儿、访问模式是否连续、有没有被多个工作项同时读同一块，这三点决定了内核的实际速度。合并访存（相邻工作项访问相邻地址）是基本功，不满足这个条件，带宽能掉到理论值的几分之一。

4.3 两条上坡路：指令式和原生语言

往 GPU 上搬代码有两条路，坡度不同。

第一条是指令式。在原代码里加编译指令，让编译器负责把循环搬到 GPU 上执行、负责数据在主机和设备之间的搬运。OpenACC 的写法是一行#pragma acc parallel loop加在循环前面，OpenMP 则用#pragma omp target teams distribute parallel for。好处是改动小、一份代码能在不同厂商的硬件上编译，坏处是控制粒度粗，数据什么时候搬、搬多少，编译器说了算，性能调优空间有限。适合已有的大段代码快速试水。

第二条是原生语言。直接写 GPU 内核函数，显式管理内存分配、数据拷贝、内核启动配置。这一类里有几套体系：一套是某显卡厂商的私有语言，生态最成熟、资料最多；一套是与之高度相似、可以互相转换的移植版本；一套是开放标准的跨平台语言，写法更啰嗦但哪儿都能跑；还有一套是建立在 C++ 之上的单源方案，主机代码和设备代码写在同一个文件里，编译期分离。再往上还有性能可移植层，用一套高层抽象写一次，编译到不同后端，代价是失去一些底层控制。

怎么选？看三个条件：代码量有多大、要不要跨厂商、团队熟不熟。新项目、只跑一种硬件、追求极致性能，走原生语言；老代码、多平台交付、人力有限，走指令式。中间地带用性能可移植层过渡，但别指望它把所有硬件的性能都榨干。

4.4 数据搬运：那条收费公路

独立显卡和主机之间隔着一条总线。这条总线的带宽，比显卡自己显存的带宽低一个数量级。这意味着：数据搬一次过去，必须在那边算很多次，才划得来。

实测方法很直接：写一个只做数据拷贝、不做计算的小程序，测出实际传输带宽，再和你内核的计算量对比。一个经验法则是，如果一次传输对应的计算时间不到传输时间的几倍，那这次上 GPU 基本白干。

优化手段是把传输和计算重叠起来。异步队列（有的叫流）允许你在队列 A 里传输下一批数据的同时，在队列 B 里计算上一批。这样总线就不会闲着。用不用得上，取决于你的问题能不能切成互相独立的批次——能切，就能重叠；切不开，就只能干等。

集成显卡是另一条路。它和 CPU 共享内存，省掉了搬运这一步，虽然绝对算力不如独立显卡，但对于中等规模、数据搬运占比高的问题，实际表现可能更好。这一点经常被忽略，很多人一上来就盯着独立显卡的峰值算力，忽略了搬运成本。

5. 五个易混说法：核多就快、GPU 必胜、向量化等于多线程

5.1 误区一：核多就等于快

易混点在于把核数当成性能指标。为什么容易混？因为厂商宣传页上最显眼的就是核数，从四核到六十四核，数字一路涨，直觉上就该一路快。

怎么区分：核数只是峰值算力的一个因子，另外两个是每周期操作数和频率。更要命的是扩展性——核加一倍，性能不一定加一倍。Amdahl 定律管着上限，内存带宽管着下限，线程调度开销管着中间。一个带宽受限的程序，从八核换到三十二核，性能可能只涨两成。判断方法很简单：把线程数从一逐步加到最大值，画出加速曲线，看它在哪儿拐平。拐平之后再加核，纯属浪费电。

5.2 误区二：GPU 一定比 CPU 快

易混点在于拿峰值算力直接对比。为什么容易混？因为 GPU 的峰值浮点数字确实比 CPU 高一个数量级，宣传材料也爱这么比。

怎么区分：峰值是理论值，实际能不能跑到，取决于三件事。数据搬运占比高不高——传输一次算不了几次，那点算力优势全被总线吃掉；分支发散严不严重——一个工作组里代码路径不统一，执行效率直接腰斩；问题规模够不够大——几千个元素的小数组，光启动内核的开销就超过计算本身。判断标准是算术强度：算得越多、搬得越少，GPU 越占便宜；逻辑复杂、分支多、数据量小，CPU 反而更合适。

5.3 误区三：向量化和多线程是一回事

易混点在于两者都叫"并行"。为什么容易混？因为效果都是变快，术语又都带"并行"两个字。

怎么区分：向量化是单指令多数据，一条指令处理四到八个数据，发生在单个核内部，不需要线程、不需要同步、不会出现竞态。多线程是多指令多数据，每个线程执行不同的指令流，需要调度、需要同步、需要考虑共享变量。两者是叠加关系，不是替代关系——一个程序可以既向量化又多线程，也可以只做其中一样。实践顺序上，先向量化再上线程更划算：向量化改动小、风险低，而且向量化之后每个线程干的活更少，线程数需求也随之下降。

5.4 误区四：缓存越大越好

易混点在于把缓存容量当成唯一指标。为什么容易混？因为规格表上缓存一栏的数字确实越大越好看。

怎么区分：缓存的效果取决于访问模式。顺序访问、工作集小，缓存命中率自然高；随机访问、工作集大，缓存再大也留不住数据。三个 C 里的容量未命中只是其中一种，冲突未命中靠的是调整数据布局和对齐，强制性未命中躲不掉只能靠预取。所以真正的优化动作不是"买缓存大的机器"，而是"把数据摆成缓存友好的样子"——结构体数组换数组结构体、循环分块、提高复用率。这些改动不花钱，效果常常比换硬件明显。

5.5 误区五：并行算法就是串行算法加几个线程

易混点在于以为并行只是执行方式的改变，算法本身不用动。为什么容易混？因为入门例子（数组相加、矩阵乘法）确实只要加个 pragma 就完事。

怎么区分：有些算法天生不适合并行，得换。最典型的是浮点求和——加法在数学上满足结合律，但在浮点运算里不满足，不同的相加顺序会得到略不同的结果。并行归约把求和顺序打乱了，结果就有微小差异，做结果比对时会发现对不上，这种问题很隐蔽。更彻底的是前缀和（扫描）：串行版本一遍循环就完事，并行版本需要先做上坡扫描再做下坡扫描，虽然总工作量增加了，但深度从 n 降到 log n，在核多的时候反而更快。算法复杂度和并行性能模型是两套评价体系，前者数操作次数，后者看关键路径长度和通信开销。以为"复杂度低就一定快"，在并行世界里经常不成立。

6. 什么时候该并行、什么时候别碰：一份判断清单

动手之前，有几个问题值得先问一遍。

程序跑得慢，慢在哪？没量过就没有发言权。用性能分析工具跑一遍，看时间花在哪个函数、哪个循环。如果八成时间花在读文件上，那并行计算一点忙都帮不上，该换的是存储格式。

串行部分占多少？估一个p值，代入 Amdahl 公式算上限。如果算出来最多快三倍，而改造成本要两周，那就得掂量。

算术强度够不够高？每读一个字节做多少次运算，和机器平衡点比一比。低于平衡点，先改数据布局，别急着上多线程。

下面这张表是按场景给的粗略建议：

场景特征	建议方向	理由
循环体简单、访存连续、无分支	先做向量化	改动最小，收益稳定在两三倍
单机多核、循环之间互相独立	OpenMP 循环级并行	一行 pragma 起步，注意变量作用域
单机装不下、需要多台机器	MPI 分块加边界交换	通信开销要能和计算重叠
计算密集、数据量大、分支少	考虑 GPU	算术强度高，搬运成本摊得薄
逻辑复杂、分支多、数据量小	留在 CPU	GPU 的锁步执行最怕分支发散
八成时间在 I/O	先改存储和读取方式	并行解决不了读写瓶颈
结果需要逐位可复现	谨慎并行归约	浮点求和顺序改变会带来微小差异