6.3 性能调优与并行效率

6.3 性能调优与并行效率

本节摘要：性能的单位是 ns/天——一天机时能买到多少纳秒的模拟。本节讲清 ns/天 由哪三块算力拼成（非键、PME、约束与整合）、域分解怎么切盒子、GPU 与 CPU 怎么分工，给出从单机到集群的调参流程与一份基准测试会话，并诊断三种"加核不加速"的典型瓶颈。调优的纪律先立在前面：一切以基准数据说话，改一个参数跑一次短基准，禁止凭感觉堆参数。

前两节的方案设计（窗口数、采样时长）都悬在一个数字上：你的模拟一天能跑多远。本节管这个数字。承上：1.3 说 GROMACS 的快来自算法、实现、并行三层，前两层出厂已定，第三层是使用者的旋钮；启下：7.1 与 7.2 的两个案例都要在预算约束下交卷，调优结论直接决定案例里"跑 200 ns 还是跑 2 μs"。

ns/天 的构成：钱花在哪三块

每一步的计算开销大致三块：非键实空间（邻居对 LJ 与静电实部，占比通常一半以上）、PME 倒易空间（FFT 与网格通信）、约束与整合（LINCS/SETTLE 加积分记账，占比一成上下）。mdrun 末尾的性能报告会给出各块的耗时分解与 ns/天 总账——调优就是让三块并行不互相等待。log 里的关键行：

               Core t (s)   Wall t (s)        (%)
                   7128.4        744.2       958.0
Performance:        412.36        0.412    ns/day
...
R.E.E.D.  PME mesh   load distribution ...
Force evaluation load %  PME mesh:  23.5   non-bonded: 68.1   update: 8.4
​

最后那行负载分布是诊断起点：PME 占比过高（如超过三成）说明倒易空间是短板，加 PME 专用进程或降网格密度；非键占比过高说明体系大、邻居对多，域分解扩进程有效；update 占比异常高则常见于约束参数被调得激进（lincs-iter 加倍之类的手滑）。

域分解与 GPU 分工

域分解把盒子切成若干小区，每个线程 MPI 进程认领一块，邻居表按小区管理，界面原子做 halo 通信。进程数由 -dd 显式指定或自动定；经验是每进程负责的原子数别低于几千，否则通信吃掉收益。PME 专用进程（-npme）把倒易空间的 FFT 单独圈给若干进程，让做实空间的进程不等 FFT——体系越大、PME 占比越高，这个参数越值钱。多核单机的推荐起手（接 4.1 的会话）：

# 先跑基准：20000 步的短任务，专门用来量产能
$ gmx grompp -f bench.mdp -c npt.gro -t npt.cpt -p topol.top -o bench.tpr
$ gmx mdrun -s bench.tpr -deffnm b_cpu -nt 32 -ntomp 2 -pin on
$ gmx mdrun -s bench.tpr -deffnm b_gpu -nt 16 -ntomp 2 -pin on -nb gpu -pme cpu -bond gpu
# 对比两个 b_*.log 的 Performance 行；再扫 -nt 8/16/24/32/48 画扩展曲线
​

GPU 分工原则一句话：非键批量规则、GPU 吃得香（-nb gpu）；PME 是全局通信型、CPU 团队更稳（-pme cpu）；单卡多节点时才考虑 -pme gpu 并实测。常见的手滑是把 -pme gpu 想当然地开着——多数配置下反而更慢，一切以基准为准。

图 6-3 并行扩展与负载：加核在哪儿开始白花钱

演算：预算反推方案

把 ns/天 变成方案约束是一次两行乘除。设基准测得 8 ns/天（单节点），6.1 的溶剂化循环要 11 个 λ 窗口、每窗采样 5 ns：

• 单窗口墙钟 = 5 ns ÷ 8 ns/天 ≈ 15 小时
• 11 窗串行 ≈ 7 天；若集群批处理 11 个作业并行排队，墙钟 ≈ 15 小时
• 若再加 BAR 精修（每窗加倍采样），预算翻倍——方案设计时就要知道这账

再演算一个反向问题：课题要 2 μs 总采样、机时预算一周，需要产能多少？2 μs ÷ 7 天 ≈ 286 ns/天——单节点给不出，要么扩节点（查扩展曲线到弯折点为止），要么回到 6.2 用增强采样把"需要的 ns"压下来。这段算术是"采样方法选型"与"机时预算"的换算器，值得写进开题报告。

三个易错点与速记

调优的三条红线：其一，把 -nt 神数抄来抄去——不同 CPU、不同体系的最优组合不同，抄参数不如跑基准；其二，dlb（动态负载均衡）在真空占比大的体系（脂膜边缘！）被关掉，界面进程等死；其三，基准跑太短——2000 步以内的基准含大量预热噪声，短基准至少 10000 步并丢弃前两成。

演算：阿姆达尔上限——优化前先算理论天花板

并行扩展的天花板可以用阿姆达尔定律先算出来：若程序里比例为 s 的部分只能串行（全局同步的 FFT 通信、约束迭代），则 p 个并行单元的加速比上限是 1 / (s + (1−s)/p)。代入 PME 体系典型值：

import numpy as np

def amdahl(s, p):
    return 1.0 / (s + (1 - s) / p)

for s in (0.05, 0.10, 0.20):
    row = [amdahl(s, p) for p in (8, 32, 128, 512)]
    print(f"串行比例 {s*100:4.0f}% -> 核数 8/32/128/512 的加速比: " +
          " / ".join(f"{v:5.1f}" for v in row))
​

典型输出：串行占一成时，512 核的理论加速比只有约 9.8 倍——这解释了为什么大集群上"几千核买几倍加速"，也解释了 6.2 的粗粒化为什么是产能杠杆（把体系做小，串行通信占比随之下降）。对照自己基准测出的加速比与这条理论线，差距悬殊处就是负载失衡或通信瓶颈，回到上文三型瓶颈诊断。

mdrun 调优旋钮总表

三个高频疑问

为什么我的 ns/天 和同事同款硬件差一半？ 按顺序查四件事：版本与编译选项（SIMD 指令集是否匹配 CPU）、nsteps 基准是否含预热、是否忘了绑核、mdp 里是否残留了别人的调试参数（如 nstlist 被改成 5、或开了不必要的能量输出）。四件都不是，再谈硬件差异。

多 GPU 节点怎么分工？ 单进程一卡是默认形态（线程 MPI 给每个 GPU 分一个 rank），两卡以上先确认体系大到喂得饱——卡与卡之间的通信开销让小体系多卡反而变慢。扩卡前先把单卡吃满（加原子数或加步长需求），这是产能优化的正确顺序。

什么参数动完必须重跑 EM？ 影响力场的参数：截断、tolerance、色散校正、couple 相关。它们改的不是"跑得快慢"而是"势能面形状"，EM 与平衡判据必须重新过一遍——这也是 6.3 与第3章的接缝：性能旋钮与物理旋钮分开管，性能旋钮随便拧，物理旋钮动一次回炉一次。

速记：ns/天 是唯一通用货币，构成三块——非键、PME、更新；负载分布行是诊断起点，PME 占比高三成即短板；域分解甜点在每进程几千原子；GPU 吃非键、CPU 守 PME，-pme gpu 要实测；预算反推公式——窗口数乘单窗时长除以产能；扩展曲线画到弯折点为止，剩下的核还给别的作业。工具与产能都齐了，第7章把全册串成两个完整案例。