1. 先想清楚并行计算到底在解决什么问题我见过太多人一上手就往代码里塞#pragma omp parallel for跑起来发现比串行还慢然后就得出一个结论说并行计算没什么用。问题从来不在并行本身而在于没搞清楚自己在优化什么。计算机系统里的并行计算本质是一套用更多硬件资源换时间的方法论而方法论的前提是先认清瓶颈在哪一层。如果你连程序是卡在计算、内存带宽还是锁竞争上都不知道那并行只会把你原本隐藏的问题放大。1.1 频率墙之后性能增量从哪来单核主频的故事在 2005 年前后基本就讲完了。那之前每一代新 CPU 靠提频率就能白送 30% 到 50% 的性能程序员什么都不用做。后来功耗密度撞墙了频率从 4GHz 往上走变得越来越贵芯片厂商转而把晶体管用来堆核心数双核、四核、十六核、几十核。这意味着什么意味着从那一刻起你的程序快不快这件事第一次变成了程序员的责任。硬件厂商把并行能力摆在你面前但你不用它就闲置。这里有个特别容易被忽略的现实多核带来的不是线性收益。我把一台 32 核机器上的串行程序改成 32 线程实测加速比能到 20 倍就算相当漂亮了。剩下的损耗来自同步开销、内存带宽争抢、缓存一致性流量、调度抖动。理解这些损耗从哪来比背下来几个 API 有用得多。1.2 并行的四个层次与选型地图在计算机系统里并行不是一个东西而是四个不同层次的技术的统称它们的作用范围、实现代价、可控程度完全不同层次典型技术谁来控制粒度程序员可见性指令级并行 ILP流水线、超标量、乱序执行、分支预测CPU 硬件单条指令流内基本不可见只能迎合数据级并行 DLPSIMD、SSE/AVX/NEON、GPU 向量单元编译器 手写 intrinsic向量宽度 4~16 元素半可见编译报告可查线程级并行 TLP多核、SMT、pthread、OpenMP操作系统 程序员函数/循环体完全可见需自己设计请求级并行 RLP多进程、分布式、流水线服务架构师任务/请求完全可见需设计架构选型的基本判断逻辑很朴素如果你的热点是个纯计算的大循环先看编译器有没有自动向量化如果循环体里没有依赖再考虑上多线程如果连多线程都吃不满机器那才去考虑跨节点。反过来做先上分布式再优化单机是典型的浪费。1.3 Amdahl 与 Gustafson两个定律决定优化上限Amdahl 定律说的是设程序中可并行部分占比为 p并行度为 N理论加速比 S 1 / ((1-p) p/N)。这个公式最反直觉的地方在于——当 N 趋于无穷S 也只能趋近于 1/(1-p)。也就是说如果你的程序有 10% 是串行的无论你堆多少核加速比上限就是 10 倍。我拿一个真实例子算一下某图像处理程序能做到 90% 并行理论加速比 10 倍。我跑到 8 线程时实测 4.9 倍跑到 16 线程时 6.2 倍。为什么因为那 10% 的串行部分里包含了每帧的读取和写回这部分还随着线程数增加变得更慢——多个线程同时争抢内存带宽。Gustafson 定律则给了另一个视角它假设问题规模随机器规模一起扩大S N - α(N-1)其中 α 是串行比例。这在工程上更贴近现实——我们通常不是拿固定数据集去跑更快的机器而是用更大的机器去跑更大的数据。所以当有人拿着 Amdahl 说并行没前途时你要想清楚你的问题规模是固定的还是可扩展的。这两个定律不是让你背的是让你在做优化前先估算这活值不值得干天花板在哪。2. 硬件视角并行发生在计算机系统的哪些角落写并行代码之前脑子里要有一张硬件地图。我见过有人写了 64 线程的程序结果所有线程都在抢同一个缓存行硬件层面变成了串行——这种问题光看代码是看不出来的得知道底下的机制。2.1 指令级并行流水线、超标量与乱序执行CPU 内部其实一直在偷偷并行。一条指令的执行被拆成取指、译码、执行、访存、写回五个阶段流水线让不同指令的不同阶段重叠起来理论上能把吞吐提升 5 倍。超标量再进一步一个周期发射多条指令。到了乱序执行CPU 会在窗口内重排指令顺序只要不影响最终结果它就想尽办法把等待时间填满。这些机制对程序员的意义在于CPU 在替你填延迟但它填得动的前提是你的指令流有足够的并行空间。一段满是数据依赖的循环比如a[i] a[i-1] * 2 b[i]乱序引擎也无能为力。我调过一个数组前缀和改成两遍扫描的分块写法后IPC 从 0.8 提到 2.1什么都没并行化速度就上去了。这就是迎合硬件的价值。需要注意的是分支预测。分支预测失败一次代价是十几到二十几个周期。在并行场景下如果多个线程的分支行为不一致预测器会被污染命中率下降。这类问题没有银弹只能通过减少热路径上的分支、把数据布局改得更一致来缓解。2.2 数据级并行从 MMX 到 AVX-512 的向量化SIMD 的原理特别直白一条指令处理一整排数据。一个 256 位的 AVX 寄存器能塞下 8 个 float加法指令一次算 8 个。理论上 8 倍加速实际通常能拿到 4 到 6 倍。能不能向量化主要看三条循环边界是否已知、有没有跨迭代依赖、访存是否连续。我拿一段高斯模糊的卷积举例原始写法是内层循环沿 x 方向滑动窗口编译器给出的报告是missed: not vectorized: control flow in loop。把滑动窗口改成每轮处理 8 个像素、用寄存器搬运边界的写法后-fopt-info-vec-optimized立刻报了向量化成功单线程就快了 3.7 倍。提示GCC 用-O3 -marchnative -fopt-info-vec-allvec.logClang 用-Rpassloop-vectorize -Rpass-missedloop-vectorize这两个开关是排查向量化的第一手段比盲猜高效得多。2.3 线程级并行多核、SMT 与存储层次物理核之间共享 L3每个核有私有 L1/L2。SMT同步多线程让一个物理核以两套寄存器上下文交替执行把流水线气泡填上通常能再压榨出 15% 到 30% 的吞吐。但它不是白给的两个逻辑核共享 L1/L2缓存压力翻倍对缓存敏感的程序开 SMT 反而变慢。这里有一条我反复验证过的经验计算密集型程序线程数取物理核数访存密集型程序线程数往往要小于物理核数。我测过的矩阵转置在 16 物理核上用 8 线程跑出的成绩比 16 线程快 12%因为每个线程的内存带宽需求已经足够填满内存控制器了。存储层次是并行的天然敌人。CPU 访问 L1 大约 4 个周期访问主存要 200 多个周期差 50 倍。并行化会把原本能塞进 L1 的工作集打散成多个线程各自的工作集总占用变大缓存命中率下降。这就是为什么很多程序越并行越慢。2.4 缓存一致性协议与伪共享多核之间靠一致性协议保持缓存同步MESI 是最常见的一种缓存行有 Modified、Exclusive、Shared、Invalid 四个状态。当一个核要写某行它得先让其他核上的副本失效。这个过程以 64 字节缓存行为单位而不是以你写的那个变量为单位。伪共享由此而来两个线程分别写两个不同的变量但这两个变量恰好落在同一个缓存行里于是每次写都触发对方缓存行失效缓存行在两个核之间来回弹跳。这个问题极其隐蔽因为源代码上两个变量毫无关系。我在一个统计程序里遇到过8 个线程各写各的计数器代码看着完全无竞争实测却比单线程慢 3 倍。修复方法就是填充把每个热变量撑到独立的缓存行struct padded_counter { long long value; char pad[64 - sizeof(long long)]; } __attribute__((aligned(64)));我用perf c2c record定位过一次报告里HITM命中被修改的缓存行计数高得离谱那就是伪共享的铁证。这个工具在排查可疑的多线程性能问题时属于必开项。3. 编程模型选型pthread、OpenMP 还是任务库选并行框架这件事很多人凭喜好我看的是三件事代码改动量、可维护性、以及团队里最不熟练的那个人能不能看懂。技术选型的失败八成不是技术本身不行而是后来没人维护得动。3.1 三类并行范式的适用边界pthread或 Windows 线程是最底层的控制力最强代价是样板代码多、错误处理繁琐、容易漏掉 join 和锁释放。适合的场景是长期运行的服务模块线程生命周期需要精细管理。OpenMP是编译制导的一行 pragma 就能把一个 for 循环并行化改动量最小适合数值计算、科学计算、快速原型。缺点是抽象层厚遇到复杂依赖或需要深层调优时能操作的旋钮有限。任务库C 的std::async、TBB、folly、以及各种线程池提供的是任务粒度而不是线程粒度天然支持动态负载均衡和嵌套并行适合树形递归、不规则任务。代价是调度开销和调优难度都更高。我个人的默认顺序是能 OpenMP 解决的用 OpenMP因为它出错概率最低需要长时间运行、线程数稳定、要做资源隔离的用显式线程池递归分解类的问题用任务库。3.2 选型对照表与决策路径维度pthreadOpenMP任务库/线程池代码改动量大极小中负载均衡手写schedule(dynamic)自动嵌套并行手写支持但需谨慎天然支持调试难度高中中高线程数精细控制完全可控环境变量控制池大小控制典型场景服务常驻模块数值循环递归/不规则任务决策路径可以简化成一句话先问并行单元是循环还是任务再问负载是否均匀最后问这个模块要不要活很久。循环均匀短生命周期OpenMP不规则递归任务库长期常驻需要资源隔离显式线程。3.3 同步原语的代价与选择同步是并行程序的主要开销来源。我按代价从低到高排一下原子操作与无锁结构、自旋锁、互斥锁、条件变量、屏障。这个排序不是绝对的取决于竞争程度。低竞争下自旋锁很快高竞争下自旋锁会烧掉大量周期此时互斥锁让出 CPU 反而更好。有个具体数字供参考无竞争的互斥锁加解锁大约 20 到 30 纳秒有竞争、需要进内核挂起的时候能到几微秒。也就是说一次锁竞争的代价相当于几千次浮点运算。如果你的临界区只有几条赋值语句用锁就是灾难这时候应该考虑原子操作或者改成每个线程私有变量再归约。原子操作也不是免费的。在高竞争下原子加会因为缓存行争抢而退化实测 32 线程同时自增一个计数器比单线程慢 20 倍以上。正确做法是每个线程维护本地计数最后统一汇总把 32 次全局竞争变成 32 次本地写加 1 次归约。4. 动手实操把一段串行代码改成并行接下来我把一个完整的改造过程走一遍从测量到上线。这段流程我用了很多年基本每次都能复用。4.1 建立可信基线测量比优化重要第一步永远是关闭所有优化干扰拿到可信的串行基线。我的做法是固定 CPU 频率、关闭睿频、绑定单核运行反复跑 5 次取中位数而不是平均值——平均值会被偶发的调度抖动拉偏。cpupower frequency-set -g performance taskset -c 2 ./app --repeat 5 perf stat -e cycles,instructions,cache-misses,L1-dcache-load-misses ./appperf stat的输出能告诉你几件关键的事IPC 是否偏低说明线程在等、cache-misses 是否异常高说明工作集超过缓存、指令数是否与预期一致说明没被优化掉。我见过有人优化了半天结果发现目标循环被编译器直接常量折叠掉了测出来的成绩毫无意义。注意测性能时一定要确认被测代码真的执行了。加一个基于结果的校验和、或者打印一个副作用能避免这类低级错误。4.2 用 OpenMP 做第一版并行化我用一段分块矩阵乘作为样例串行版本长这样void matmul_serial(const double *A, const double *B, double *C, int N) { for (int i 0; i N; i) for (int k 0; k N; k) { double a A[i * N k]; for (int j 0; j N; j) C[i * N j] a * B[k * N j]; } }注意这个 i-k-j 的循环顺序不是随便写的。相比 i-j-k它把内层循环变成了对 B 的行连续访问同时 C 的写入也被连续化了缓存友好度完全不同。我测过同样规模下 i-j-k 版本要慢 4 倍以上。第一版并行化只改一行#pragma omp parallel for schedule(runtime) for (int i 0; i N; i) for (int k 0; k N; k) { double a A[i * N k]; for (int j 0; j N; j) C[i * N j] a * B[k * N j]; }编译时加-O3 -marchnative -fopenmp。这里有个细节外层的 i 循环是天然无依赖的因为每个 i 对应 C 的不同行各线程之间没有写冲突符合 OpenMP 的并行条件。如果换成并行 k 循环就会有多个线程同时写 C 的同一元素产生数据竞争结果错误。4.3 线程数与调度策略的实测选择调度策略用schedule(runtime)是个技巧它把策略的选择推迟到运行时通过环境变量OMP_SCHEDULE切换不用重新编译就能对比 static、dynamic、guided 三种策略。我拿 N2048 的矩阵实测了一轮线程数staticdynamic,1guided加速比static11.82 s1.85 s1.83 s1.0020.95 s0.98 s0.96 s1.9240.51 s0.52 s0.51 s3.5780.29 s0.30 s0.29 s6.28160.21 s0.23 s0.21 s8.67320.24 s0.27 s0.24 s7.58几个结论外层循环迭代次数只有 2048粒度已经够大dynamic 的调度开销纯属浪费所以 static 反超16 线程是最好的点到 32 线程反而下降因为此时内存带宽已经饱和多出来的线程只是增加了缓存争抢。关于线程数我一般会先跑一个扫描从 1 到 2 倍物理核数画出曲线取拐点。环境变量是OMP_NUM_THREADS也可以用omp_set_num_threads()。别用omp_get_num_procs()硬编码那个值在容器环境下经常不准——容器里拿到的是宿主机核数会导致超额订阅。4.4 伪共享的复现与修复我特意构造过一个伪共享的案例用一个统计直方图程序每个线程负责一段区间但把各线程的计数写进了连续数组// 有问题的版本8 个 long long 挤在一起占 64 字节 long long local_count[8]; #pragma omp parallel { int tid omp_get_thread_num(); for (...) local_count[tid]; }8 个 long long 正好 64 字节全在一个缓存行里8 个核互相弹缓存行。实测 8 线程比单线程慢 2.8 倍。改成填充后struct alignas(64) padded { long long v; char pad[56]; }; padded local_count[8];实测 8 线程加速比 6.4 倍从负优化直接变成接近线性的正优化。这个对比我每次给团队做分享都会放因为它直观得吓人代码逻辑一个字没改只是数据布局变了性能差 18 倍。用perf c2c record ./app perf c2c report能直接在报告里看到Shared Data Cache Line Table哪一行被多个核反复抢一目了然。这是排查这类问题最省时间的路径比逐段注释代码去二分定位快得多。4.5 实测数据与加速比复盘把矩阵乘那一版最终数据整理一下用 Amdahl 定律反推串行比例。16 线程实测加速比 8.67代入公式解 1/((1-p)p/16)8.67得到 1-p≈0.046也就是串行部分约占 4.6%。这个 4.6% 来自哪里大部分是初始化的内存分配和最后的校验以及线程创建销毁的固定开销。想继续往上提路径就明确了把初始化也拆进去并行、检查是否触发了 NUMA 远程访问、把schedule改回 static 减少调度抖动、以及注意内存对齐让向量化在这些代码里也能生效。做完这几项我在同一台机器上把 16 线程的成绩从 8.67 提到了 11.3。当然继续往上边际收益就很小了这时候该考虑的是换算法——比如引入分块使其对缓存更友好而不是继续折腾线程数。5. 常见问题与排查技巧实录并行程序出错有个特点大部分错误不会每次都出现这让排查变得格外磨人。下面这些是我实际踩过的坑和对应的定位思路。5.1 加速比上不去的排查顺序按这个顺序查基本能覆盖九成情况确认真的并行执行了。OMP_NUM_THREADS8 ./app同时在另一个终端top -H看线程数。如果只有一个线程在跑说明 pragma 没生效可能没加-fopenmp或者循环条件不满足并行要求。看是不是访存瓶颈。如果每个线程都大量读写堆上随机位置的数据加线程只会加剧争抢。此时正确做法是改数据布局而不是加线程。查伪共享。用perf c2c。这一步我强烈建议在怀疑锁竞争之前做因为伪共享的表现和锁竞争几乎一样但修复成本低得多。看同步点的密度。统计一下每轮循环里的 barrier 和锁次数。如果同步非常频繁调大并行粒度。确认没有线程饥饿。NUMA 机器上线程和内存跨节点访问的延迟差 1.5 到 2 倍用numactl --hardware看拓扑再用numactl --cpunodebind0 --membind0做本地绑定测试。5.2 数据竞争与死锁的定位手法数据竞争最典型的症状是同一份输入跑十次有两次结果不对。定位它的第一手段是 ThreadSanitizerg -fsanitizethread -g -O1 -fopenmp app.cpp -o app_tsan ./app_tsan它会直接指出哪两个位置发生了竞争、分别在哪一行、涉及哪个变量。代价是执行慢 5 到 15 倍所以只能在小数据集上跑。我一般在写完之后就用小规模数据过一遍 TSan作为提交前的固定动作。死锁的定位相对简单用gdb -p pidattach 上去thread apply all bt打出所有线程的栈看谁在等谁。经验上死锁绝大多数来自加锁顺序不一致比如线程 A 先锁 x 再锁 y线程 B 先锁 y 再锁 x。修复就是给所有锁定一个全局顺序所有代码严格遵守。我见过一个更隐蔽的版本同一个函数在不同调用路径下加锁顺序相反这种只能靠代码审查或者把加锁逻辑收敛到一个地方解决。还有一个容易被忽略的问题OpenMP 的omp for默认结束处有隐式 barrier如果你在一个循环里嵌套了并行区域可能多出很多不必要的同步。这时候用nowait子句去掉它但前提是后续代码确实不依赖这个同步点。去掉之后如果结果错了说明你误判了依赖关系——这类错误不会崩只会悄悄算错最危险。5.3 常见问题速查表现象可能原因首选排查手段加了线程反而变慢伪共享 / 内存带宽饱和perf c2c、逐步增减线程数结果时对时错数据竞争ThreadSanitizer 小数据复现程序卡住不返回死锁attach gdb查看全部线程栈只有一两个核在忙并行区域没生效 / 负载不均检查编译参数尝试 dynamic加速比远低于核数串行部分占比高 / NUMA 远程访问反推 Amdahl做本地绑核多线程下比预期慢很多缓存容量被稀释缩小工作集或做分块线程数超过核数后骤降上下文切换与超额订阅限制线程数检测容器核数6. 工程细节这些坑我替你踩过了最后聊几个不那么技术但特别影响结果的经验都是被坑出来的。6.1 并行粒度的经验取值粒度太细调度和同步开销吃掉收益粒度太粗负载不均导致部分线程闲着。我的经验数值是每次并行迭代的工作量至少要能跑满几微秒。粗算一下一次 OpenMP 静态调度的迭代开销大概几百纳秒到一微秒如果迭代本身只要 100 纳秒那开销比工作还大。判断方法很粗暴把迭代次数缩小十倍如果性能和缩小前差不多说明开销占比过高如果性能也降了十倍说明是计算主导。这个实验我做过很多次结论很一致。另外一个技巧是合并迭代把若干个连续的小迭代打包成一个并行单元用collapse(2)子句把两层循环合并并行也是一种标准做法。6.2 NUMA、绑核与内存带宽在双路服务器上CPU0 访问自己挂的内存大概 80 纳秒访问 CPU1 挂的内存要 140 纳秒。如果线程跑在 CPU0 上但数据在 CPU1 的节点性能会明显下降而且这个损失在并行下被放大。处理方式有两种。一是先用numactl --cpunodebind0 --membind0把进程限制在单节点看性能是否改善如果改善明显再考虑在代码里做线程亲和性绑定和数据本地化分配。二是用first-touch原则内存分配不立即落页哪个线程先写哪页页就落在那个节点上。所以并行初始化的顺序会影响数据分布这一点在写#pragma omp parallel for初始化数组时要特别注意——初始化循环的并行划分方式决定了后续访问的内存局部性。绑核用OMP_PROC_BINDclose OMP_PLACEScores是最省事的组合比手写sched_setaffinity简单。但要注意如果机器上还有别的任务在跑绑核可能让你抢不到时间片这时候反而要放开绑定。6.3 可复现的性能测试怎么做性能数字不可复现所有优化结论都没有意义。我的固定做法是固定频率策略为 performance关闭睿频波动每组配置跑 5 次以上报告中位数和最大值不报平均值用同一份数据、同一种内存分配方式每次只改一个变量其余保持完全一致记录编译参数、编译器版本、CPU 型号、内存频率有一次我们团队为一个 8% 的提升争论了三天最后发现两次测试的机器一台开了 SMT 一台没开。这类问题不靠流程规范是防不住的。测试记录表格不需要花哨把上面这几项写清楚就够。我还建议保留一个最慢版本的基准数据每次优化后都跑一遍对比。见过太多项目随着功能累加性能悄悄劣化回溯时才发现但已经无从下手。我个人的体会是并行计算真正难的部分从来不是那几个 API而是判断这个瓶颈到底在哪一层的能力。我刚开始做的时候也犯过上来就加线程的毛病后来慢慢养成习惯先测量再算理论上限然后从最低代价的手段开始试——向量化、数据布局、减少同步最后才是加线程。顺序反过来往往就是白忙一场。另外一点多线程代码里所有看起来不可能出错的地方都要用工具验证一遍尤其是用 ThreadSanitizer 过一遍小数据这个习惯帮我省下的调试时间比我学过的任何优化技巧都值钱。