4、CPU与GPU任务划分：Amdahl定律与Gustafson定律、任务分解策略、数据并行与任务并行、负载均衡原则

4.1 两个定律：别被理论框住，但也不能无视

做异构计算，第一个绕不开的就是Amdahl定律。说白了，它告诉我们一个扎心的事实：你的程序能加速多少，取决于那部分必须串行的代码占比。

公式很简单：加速比 = 1 / (串行比例 + 并行比例 / 核心数)。我刚开始做GPU优化时，总想着堆更多核心就能解决一切。结果呢？有一次优化一个图像处理管线，串行部分占了5%，我上了256个GPU核心，理论加速比也就20倍。嗯，现实更残酷，因为还有通信开销。

这时候Gustafson定律就登场了。它说：别盯着串行比例不放，你想想看，随着核心数增加，我们可以处理更大的数据量。公式是：加速比 = 串行比例 + 并行比例 × 核心数。这个视角更符合我们做GPU优化的日常——不是把原来跑1秒的程序压到0.01秒，而是让原来跑不了的大模型、大数据集变得可行。

我个人习惯这样用：如果任务是固定大小的（比如嵌入式设备），多想想Amdahl；如果是数据中心、超算场景，Gustafson更实用。我在项目中遇到过一位同事，死磕一个串行瓶颈优化了两个月，结果换个思路，把输入数据翻四倍，整体吞吐反而上去了。这就是两个定律的实战差异。

4.2 任务分解策略：怎么切，决定了性能上限

任务分解，说白了就是「怎么把活分给CPU和GPU」。我一般分三步走：

1. 识别计算密集区——用profiler跑一遍，看哪里耗时最多。我习惯用NVIDIA Nsight Systems先扫一轮。
2. 判断并行潜力——这段代码能不能拆成几千个独立线程？数据有没有依赖？
3. 决定归属——计算密集、数据独立、控制流简单的，扔给GPU；逻辑复杂、分支多、需要频繁同步的，留给CPU。

分解时要注意粒度。太粗了，GPU吃不饱；太细了，调度开销吃掉收益。我一般让每个GPU线程处理至少256个元素，这样能掩盖访存延迟。

4.3 数据并行与任务并行：两种思维，一个目标

数据并行，就是「同样的操作，不同的数据」。这是GPU的强项。比如矩阵乘法、图像滤波、神经网络卷积——每个输出像素的计算逻辑完全一样，只是输入数据不同。

任务并行，则是「不同的操作，不同的数据」。比如一个视频编码管线：读取帧、运动估计、熵编码、写文件。这些阶段可以流水线执行，CPU和GPU各管一段。

维度	数据并行	任务并行
典型场景	矩阵运算、图像处理	流水线、多阶段处理
硬件偏好	GPU（大量核心）	CPU（复杂调度）
同步开销	低（SIMT模型）	高（需要协调）
负载均衡难度	容易（数据均匀）	较难（任务耗时不一）

我实际做项目时，往往混合使用。比如一个深度学习推理管线：前向传播用数据并行跑在GPU上，数据预处理和后处理用任务并行跑在CPU上。这样CPU和GPU各司其职，谁也不闲着。

4.4 负载均衡原则：别让一个核心累死，其他核心闲死

负载均衡，是异构计算里最容易被忽视的坑。你想想看，如果GPU算得飞快，CPU却在慢吞吞地准备数据，那整体性能就被CPU拖死了。反过来也一样。

我总结了几条原则：

• 静态均衡：如果任务量可预估，提前分好。比如图像处理，每张图大小一样，可以平均分给GPU线程块。
• 动态均衡：任务量不确定时，用工作窃取（work stealing）。GPU这边用原子操作维护一个任务队列，哪个线程块空闲了就取下一个任务。
• 流水线均衡：CPU和GPU之间用双缓冲或环形缓冲区。CPU准备下一批数据的同时，GPU处理当前批。这样能隐藏数据传输延迟。

还有一个容易被忽略的点：CPU和GPU之间的数据传输。每次PCIe传输都有微秒级的延迟，如果频繁传输小数据，性能会惨不忍睹。我建议把多次小传输合并成一次大传输，或者用异步传输（cudaMemcpyAsync）配合流（stream）来重叠计算和传输。

嗯，最后说一句：没有银弹。每个应用都有自己的特性，你需要用profiler反复测量，找到瓶颈，再针对性地调整任务划分。我一般会准备三套方案：纯CPU、纯GPU、异构混合。然后对比性能，选最优的。有时候异构方案反而比纯GPU慢，因为通信开销太大。这时候别死磕，该放弃就放弃。