4. 并行编程基础与性能分析工具

全波电磁仿真（FDTD、FEM、MoM、BEM 等）的计算核心通常归结为三类操作：网格单元上的局部更新、稀疏矩阵与向量的乘加、以及稠密/稀疏线性方程组的迭代求解。这三类操作恰好对应三种主流并行编程模型：共享内存的 OpenMP、分布式内存的 MPI、以及异构加速的 CUDA/HIP/OpenACC。理解它们的核心机制与适用边界，是后续把仿真代码真正跑快的前提。

一、四种并行模型的核心机制

OpenMP 面向单节点多核 CPU，采用编译制导（pragma）方式，在串行代码中标注并行区。其核心是 fork-join 执行模型：主线程遇到 #pragma omp parallel 时派生线程组，退出并行区时汇合并等待。数据作用域（shared / private / reduction）决定变量是共享还是各线程私有，这是最容易出错的地方。FDTD 的电场更新是典型的 embarrassingly parallel 循环，只需在时间步循环内对空间三重循环加 #pragma omp parallel for collapse(3)，配合 schedule(static) 即可获得接近线性的加速。但要注意伪共享（false sharing）：相邻线程写同一 cache line 的不同元素会导致缓存行反复失效，通常用 padding 或分块（tiling）缓解。

MPI 面向多节点集群，采用显式消息传递。每个进程拥有独立地址空间，通过 MPI_Send/Recv、MPI_Allreduce、MPI_Isend/Irecv 交换数据。电磁仿真中常见的域分解（domain decomposition）把计算区域切成子域，每个进程负责一块，边界处交换 halo 层数据。关键性能点是通信与计算的重叠：用非阻塞通信先发起 halo 交换，再计算内部区域，最后等待边界数据。MPI 的扩展性受限于通信延迟和带宽，强扩展（固定问题规模增加进程数）通常在数百到数千核后效率下降，弱扩展（问题规模随进程数增长）表现更好。

CUDA/HIP 面向 GPU 异构计算。执行模型是 grid-block-thread 三级层次：一个 kernel 启动为若干 block，每个 block 含若干线程，线程以 32 个为一组构成 warp 并执行。性能关键包括：合并访存（相邻线程访问相邻地址）、足够的占用率（occupancy）以隐藏访存延迟、避免 warp 分支发散、合理使用共享内存减少全局访存。FDTD 的 Yee 网格更新天然适合 GPU：每个线程负责一个网格点的场分量更新，用 __syncthreads() 同步共享内存中的 halo 数据。HIP 与 CUDA 编程接口高度相似，便于跨厂商移植。

OpenACC 用制导指令把循环和数组卸载到加速器，代码改动量小，适合已有大型 CPU 代码的快速移植。核心指令是 #pragma acc parallel loop 与 #pragma acc data copyin/copyout。其性能通常略低于手写 CUDA，但开发成本低，适合原型验证。

二、性能剖析工具的使用要点

并行代码跑起来只是第一步，找到瓶颈才是关键。CPU 侧首选 Intel VTune：用 vtune -collect hotspots ./solver 采集热点，再用 vtune -report hotspots 查看函数级耗时；若怀疑访存瓶颈，改用 -collect memory-access 分析缓存命中率与 NUMA 效应。GPU 侧用 NVIDIA Nsight Compute 分析单个 kernel 的占用率、访存效率与 warp 停顿原因，用 Nsight Systems 看整体时间线，判断是 kernel 计算慢还是 H2D/D2H 拷贝拖累。

MPI 与 OpenMP 混合程序推荐 TAU 或 Score-P。TAU 通过 tau_exec 或编译期插桩自动记录 MPI 调用、OpenMP 区域和函数耗时，生成调用图与并行剖面；Score-P 侧重事件追踪，配合 Vampir 可视化时间线，能直观看到进程间的等待与通信空档。实践中常见的问题是：某进程在 MPI_Allreduce 上等待过久，说明负载不均或通信与计算未重叠。

三、加速比评估方法

加速比定义为 S = T₁ / Tₙ，其中 T₁ 为单进程/单线程基线时间，Tₙ 为 N 个并行单元的时间。并行效率 E = S / N，理想情况 E=1。实际评估需区分两种场景：强扩展固定问题规模，增加进程数，考察通信开销占比；弱扩展问题规模随进程数等比增长，考察算法是否可扩展。按 Amdahl 定律，若串行部分占比 f，则最大加速比 S_max = 1 / (f + (1-f)/N)，当 N→∞ 时 S_max = 1/f。例如 f=5%，即使无限核，加速比也不超过 20 倍。

一个可复用的评估流程如下：

# 1. 基线：单线程运行，记录 wall time
OMP_NUM_THREADS=1 ./fdtd_solver -n 512 -steps 2000
# 输出：T1 = 186.4 s

# 2. 强扩展：固定问题规模，逐步增加线程/进程
OMP_NUM_THREADS=8  ./fdtd_solver -n 512 -steps 2000   # T8  = 25.1 s
OMP_NUM_THREADS=16 ./fdtd_solver -n 512 -steps 2000   # T16 = 14.3 s
mpirun -np 32 ./fdtd_solver -n 512 -steps 2000        # T32 = 9.8 s

# 3. 计算加速比与效率
# S8  = 186.4 / 25.1  = 7.43   E8  = 7.43 / 8  = 92.9%
# S16 = 186.4 / 14.3  = 13.03  E16 = 13.03 / 16 = 81.4%
# S32 = 186.4 / 9.8   = 19.02  E32 = 19.02 / 32 = 59.4%

# 4. 用 VTune / Nsight 定位效率下降原因
vtune -collect hotspots -result-dir r1 ./fdtd_solver
nsys profile -o gpu_trace ./fdtd_solver_gpu

上例中 8 线程效率 92.9%，16 线程降到 81.4%，32 进程仅 59.4%，说明通信或内存带宽开始成为瓶颈。此时应结合剖析工具确认：若 VTune 显示内存带宽接近峰值，则需优化数据布局或分块；若 TAU 显示 MPI 等待时间占比高，则应调整域分解粒度或改用非阻塞通信。