📚 课程目录第2章并行计算性能模型

并行计算性能模型：别被理论数字忽悠了

性能模型，说白了就是一把尺子。用来衡量你的并行优化到底值不值得做。我刚开始搞并行计算的时候，总觉得代码跑得比单核快就行。后来被领导问了一句：「你花了三周改的代码，加速比多少？效率呢？」我才意识到，没有模型，优化就像闭着眼开车。

这一章我们就聊聊四个核心概念：Amdahl定律、Gustafson定律、加速比与效率、并行开销。嗯，听起来像理论课，但其实每个概念背后都有血泪教训。

Amdahl定律：串行部分才是真正的天花板

Amdahl定律告诉你一个很残酷的事实：加速比的上限由串行部分决定。公式非常简单：

加速比 S = 1 / ( (1 - P) + P / N )

其中：
  P = 可并行部分的比例
  N = 处理器核心数
  (1-P) = 必须串行执行的部分

举个例子。你有一个任务，95%的代码可以并行，但还有5%必须串行。用10个核跑：

S = 1 / (0.05 + 0.95/10) = 1 / (0.05 + 0.095) = 1 / 0.145 ≈ 6.9

10个核只换来不到7倍的加速。为什么会这样？因为那5%的串行部分在拖后腿。你加再多的核也没用。

核心结论：Amdahl定律适用于固定问题规模的场景。问题大小不变，你只能靠加核来提速。串行比例哪怕只有1%，理论上也永远打不过1000个核。

我记得有一次优化一个图像处理管线。觉得每步都可以并行，结果发现有一个全局归一化操作必须串行执行。Amdahl算了一下，发现就算用100个核，加速比也超不过20。果断改了算法设计，把归一化改成了分块统计。改完之后，加速比直接翻倍。

我曾经犯过一个低级错误：把所有初始化代码也计入了并行部分。结果理论加速比很好看，实际跑出来一塌糊涂。记住：IO、同步、内存分配，这些统统算串行开销，别自欺欺人。

Gustafson定律：换个角度看问题

Gustafson定律是Amdahl的「对偶版本」。它假设问题规模可以随着核数增长。公式变成了这样：

加速比 S = 1 - P + P * N

其中：
  P = 可并行部分的比例（在扩展后）
  N = 处理器核心数

为什么这个公式更乐观？因为它允许你「用更多核解决更大问题」。比如你用10个核，90%的代码可并行，加速比就是：

S = 1 - 0.9 + 0.9 * 10 = 0.1 + 9 = 9.1

几乎接近线性。Gustafson告诉我们：别只想着用更多核跑同样的问题，想想用更多核跑更大的问题。这也是为什么很多科学计算任务——比如天气预报、分子动力学模拟——能几乎线性扩展的原因。

我个人习惯：做性能预估时两个定律都算一遍。Amdahl给下限（最差情况），Gustafson给上限（理想情况）。真实加速比通常落在两者之间。

对比维度	Amdahl定律	Gustafson定律
问题规模	固定不变	随核数增长
视角	资源受限视角	时间受限视角
典型场景	嵌入式、实时系统	HPC、科学计算
加速比上限	1/(1-P)	无严格上限
关键假设	串行比例恒定	并行工作负载可扩展

加速比与效率：不只关心快不快

加速比是并行程序最重要的指标之一。它衡量的是「比单核快了多少倍」：

加速比 S = T_serial / T_parallel

其中：
  T_serial = 最优串行执行时间
  T_parallel = 并行程序在 N 个核上的执行时间

效率则用来衡量「资源用得好不好」：

效率 E = S / N

理想情况下：S = N，E = 1（线性加速）
实际情况：S < N，E < 1

举个例子。你用32个核跑任务，加速比是24。那么效率就是：

E = 24 / 32 = 0.75

意味着每个核只贡献了75%的「有效算力」，剩下的25%被通信、同步和负载不均衡吃掉了。你可以接受这个效率吗？取决于场景。工业界通常认为E > 0.7就算合格，E > 0.9就非常优秀。

我在项目中遇到过一个大坑：加速比看起来不错（24/32），但效率只有60%。为什么？因为代码中有一个全局锁，虽然争抢不频繁，但每次同步都导致大量空闲等待。改成了无锁数据结构后，效率升到了85%。你看，光看加速比会骗人的，必须盯着效率。

加速比分类：
线性加速：S = N（完美情况，很少见）
次线性加速：S < N（最常见，有并行开销）
超线性加速：S > N（因为缓存效应，但不稳定）

避开「内存墙」：超线性加速通常只出现在数据量特别小、刚好能塞进L2/L3缓存的场景。一旦数据规模增长，超线性就会消失。

并行开销分析：为什么加核不总是更快

并行不是免费的午餐。加核会引入额外的开销：

通信开销：数据在核之间传递需要时间
同步开销：等待其他核完成操作
负载不均衡：有的核忙死，有的核闲着
冗余计算：为了并行而重复执行某些操作
调度开销：系统管理线程/进程

我之前调试过一个并行渲染器，4核时加速比3.8，效率0.95。加到了16核后，加速比只有8，效率掉到0.5。排查后发现，通信开销随核数超线性增长。每一个新加入的核，都要跟所有其他核同步一次，通信复杂度是O(N²)。换了分治模式后，才把效率拉回来。

# 一个典型的并行开销分析日志（伪日志）
[17:42:01] Launch 8 workers...
[17:42:02] Worker 0: compute 12ms
[17:42:02] Worker 1: compute 14ms
[17:42:02] Worker 2: compute 18ms  ← 负载不均衡
[17:42:03] Barrier: wait 6ms       ← 同步开销
[17:42:03] Data transfer: 4ms      ← 通信开销
[17:42:03] Total: 28ms, overhead: 8ms

分析并行开销时，我一般会问三个问题：

加核后，通信量怎么变化？（是线性、平方还是指数增长？）
同步点是否太多或太频繁？
每个核的工作量是否均匀？

我曾经见过一个团队，优化时疯狂加核，结果加速比曲线在某个点后开始「倒挂」——加核反而变慢了。根本原因就是通信饱和，网络带宽被打满。一定要做小规模试验，画出加速比随核数的变化曲线，千万别直接上大规模集群。

总结一下：性能模型不是挂在嘴上的公式，而是你手上最实用的工具。Amdahl教你敬畏串行部分，Gustafson带你看到扩展的可能性，加速比和效率帮你定量衡量好坏，并行开销分析则告诉你——瓶颈到底在哪里。

下次加核之前，先算一算。别让理论成为事后诸葛。