📚 课程目录第3章并行编程模型与工具链

3. 并行编程模型与工具链

并行算法最终要落到具体的编程模型上。模型决定了线程或进程如何创建、数据如何共享、同步如何表达，也决定了性能瓶颈会以什么形式暴露出来。本节围绕三类主流模型展开：共享内存模型（OpenMP、Pthreads）、消息传递模型（MPI）以及异构模型（CUDA/HIP），并给出编译与性能分析工具链的基本用法。理解它们的差异，比记住某个 API 更重要。

共享内存模型：同一地址空间内的协作

共享内存模型的前提是多个执行单元（线程）访问同一块虚拟地址空间。OpenMP 以编译制导指令的形式表达并行，适合循环级和数据级并行。以数组求和为例，最典型的写法是用 parallel for 配合归约子句：

double sum = 0.0;
#pragma omp parallel for reduction(+:sum) schedule(static)
for (int i = 0; i < n; ++i)
    sum += a[i];

这里 reduction(+:sum) 让每个线程持有私有副本，循环结束后再合并，避免了写冲突；schedule(static) 表示按块静态划分迭代空间，适合每次迭代计算量均匀的情形。若迭代耗时差异大，可改用 schedule(dynamic, 64) 以 64 次迭代为粒度动态领取任务，代价是额外的调度开销。需要强调的是，OpenMP 的并行区域默认存在隐式栅栏，循环结束即同步，这一点在嵌套并行或流水线场景中要特别留意。

Pthreads 提供更底层的线程控制，需要显式创建线程、划分任务、加锁或使用条件变量。它适合任务结构不规则、需要精细控制线程生命周期的场合，但同步错误（数据竞争、死锁）也更难排查。实践中常见做法是：能用 OpenMP 表达的规则并行优先用 OpenMP，只有在任务划分或线程间协作逻辑复杂时才下沉到 Pthreads。

消息传递模型：MPI 的显式通信

MPI 面向分布式内存，每个进程拥有独立地址空间，数据交换必须通过显式消息。其基本骨架是初始化、确定进程编号与总数、通信、收尾：

MPI_Init(&argc, &argv);
MPI_Comm_rank(MPI_COMM_WORLD, &rank);
MPI_Comm_size(MPI_COMM_WORLD, &size);
// 各进程计算本地部分，然后汇总
MPI_Reduce(local, global, count, MPI_DOUBLE, MPI_SUM, 0, MPI_COMM_WORLD);
MPI_Finalize();

点对点通信用 MPI_Send/MPI_Recv，集合通信用 MPI_Bcast、MPI_Scatter、MPI_Gather、MPI_Allreduce 等。设计并行算法时要先想清楚数据分布：是按行块划分矩阵，还是按二维块划分？划分方式直接决定通信量和通信模式。一个常见判断依据是通信计算比——若每次迭代只需交换边界数据而内部计算量大，扩展性通常较好；若每步都要全局归约，则归约的延迟会成为瓶颈。此外，非阻塞通信 MPI_Isend/MPI_Irecv 配合 MPI_Wait 可以把通信与计算重叠，是提升效率的常用手段。

异构模型：CUDA 与 HIP 的执行层次

异构模型面向 CPU 主机加加速器的结构。CUDA 中，主机代码负责数据搬运与内核启动，设备端由网格（grid）、线程块（block）、线程（thread）三级组织。一个向量加法的内核示意如下：

__global__ void vecAdd(const float* a, const float* b, float* c, int n) {
    int i = blockIdx.x * blockDim.x + threadIdx.x;
    if (i < n) c[i] = a[i] + b[i];
}
// 主机端：vecAdd<<<(n+255)/256, 256>>>(d_a, d_b, d_c, n);

块大小 256 是常见起点，网格大小按 (n+255)/256 向上取整，内核内用边界判断防止越界。性能上要关注合并访存（相邻线程访问相邻地址）、共享内存的合理使用以及占用率。HIP 的编程接口与 CUDA 高度相似，主要差异在运行时 API 前缀与编译工具，便于代码在 NVIDIA 与 AMD 平台间迁移。

编译与性能分析工具链

三类模型对应不同的编译入口。OpenMP 程序用 gcc -fopenmp -O2 编译；MPI 程序用 mpicc 或 mpicxx 包装器，运行用 mpirun -np 4 ./app；CUDA 用 nvcc -O3 -arch=sm_80，HIP 用 hipcc。编译选项直接影响性能，例如 -O2/-O3 的向量化、-march=native 的指令集选择，都会改变实测结果。

性能分析要分层进行。先用 perf stat 看整体指标，如指令数、缓存未命中率、上下文切换；再用 perf record/report 或 gprof 定位热点函数；对 OpenMP 可借助 OMP_NUM_THREADS 控制线程数做扩展性对比；对 MPI 关注通信时间占比；对 GPU 则用 Nsight Systems 看内核时间线与数据传输开销。一个实用的判断方法是做强扩展性测试：固定问题规模，线程或进程数从 1 增到 8，记录运行时间，若加速比明显低于线性，就要检查负载不均、同步等待或通信瓶颈。

教学示例：对规模 n=10^7 的浮点数组求和，单线程耗时设为基准，4 线程理想加速比接近 4；若实测只有 2.5 左右，优先排查伪共享（多个线程写同一缓存行的不同变量）与归约实现方式，而不是先怀疑编译器。

总体而言，模型选择应服从算法结构与硬件形态：数据天然共享且并行规则，选 OpenMP；需要跨节点扩展，选 MPI；计算密集且可规则映射到大量轻量线程，考虑 CUDA/HIP。工具链的作用是把“看起来并行”变成“确实高效”，编译选项、线程/进程规模、性能计数器三者结合，才能形成可复现的调优闭环。