单节点无法运行时如何评估强扩展并行效率

背景说明 #

我实现了OpenMP/MPI混合并行算法，希望测量其强扩展并行效率，需计算加速比 S=t(1)/t(N) 及效率 E=S/N。经分析，算法峰值效率对应的问题规模超出基准集群单节点的数据容纳能力。可行方案有两种：

• 以能容纳数据的最小节点数（如4节点）为基准，计算加速比 S=t(4)/t(N)；
• 通过外推得到理论单节点求解时间 t(1) 作为基准。

问题解答 #

1. 哪种方案更优？原因是什么？ #

优先选择方案1（以能容纳数据的最小节点数为基准），核心原因如下：

• 外推得到的t(1)是纯理论值，完全无视单节点无法承载该规模数据时的内存瓶颈、IO限制等实际运行障碍，计算出的加速比和效率和真实运行场景脱节，参考价值极低；
• 方案1的所有测试都基于能实际完成计算的真实场景，得到的性能数据能准确反映算法在目标问题规模下的并行表现，对实际集群部署和性能优化的指导意义更强。

2. 若采用第一种方案，严格来说能否称其为强扩展并行效率？ #

严格意义上不属于标准的强扩展并行效率。
传统强扩展的定义是：固定问题规模，通过增加计算核心/节点数来衡量性能提升，且基准必须是单节点（或单核心）能够独立完成该问题规模计算的场景。
当问题规模超出单节点承载能力时，用多节点做基准的测试属于“实用强扩展”或“受限强扩展”，不符合强扩展的严格定义，但在工程实践中，这种测试的价值远高于强行追求标准定义的测试——因为它完全贴合真实业务的运行场景。

附加问题：测量t(1)时，应使用带模拟通信的mpirun -n 1 ./my_benchmark_program，还是无通信的OpenMP版本./my_openmp_only_benchmark_program？ #

必须选择**mpirun -n 1 ./my_benchmark_program**，理由如下：

• 要保证基准测试的代码路径和多节点混合并行版本完全一致，带模拟通信的版本保留了算法中所有MPI通信逻辑（哪怕单进程时通信是空操作），测出的时间能真实反映算法在单进程模式下的实际开销；
• 无通信的OpenMP版本相当于修改了算法核心逻辑，去掉了通信相关的代码分支，和混合并行版本的运行路径差异极大，测出的时间不具备可比性，不能作为有效基准。

内容的提问来源于stack exchange，提问作者Nitin Malapally