2025-11-21T09:31:15.798794

Comparing Cross-Platform Performance via Node-to-Node Scaling Studies

Weiss, Stitt, Hawkins et al.
Due to the increasing diversity of high-performance computing architectures, researchers and practitioners are increasingly interested in comparing a code's performance and scalability across different platforms. However, there is a lack of available guidance on how to actually set up and analyze such cross-platform studies. In this paper, we contend that the natural base unit of computing for such studies is a single compute node on each platform and offer guidance in setting up, running, and analyzing node-to-node scaling studies. We propose templates for presenting scaling results of these studies and provide several case studies highlighting the benefits of this approach.
academic

Comparing Cross-Platform Performance via Node-to-Node Scaling Studies

基本信息

  • 论文ID: 2510.12166
  • 标题: Comparing Cross-Platform Performance via Node-to-Node Scaling Studies
  • 作者: Kenneth Weiss, Thomas M. Stitt, Daryl Hawkins, Olga Pearce, Stephanie Brink, Robert N. Rieben
  • 分类: cs.DC (Distributed, Parallel, and Cluster Computing)
  • 发表时间: October 15, 2025 (预印本)
  • 论文链接: https://arxiv.org/abs/2510.12166

摘要

随着高性能计算架构多样性的增加,研究人员和从业者越来越关注代码在不同平台上的性能和可扩展性比较。然而,缺乏关于如何实际设置和分析此类跨平台研究的可用指导。本文认为,此类研究的自然基本计算单位是每个平台上的单个计算节点,并为设置、运行和分析节点到节点扩展研究提供指导。我们提出了展示这些研究扩展结果的模板,并提供了几个案例研究来突出这种方法的优势。

研究背景与动机

问题背景

  1. 架构多样性增长:随着Exascale Computing Project (ECP)的完成和首批千万亿次级机器的成功部署(如Lawrence Livermore National Laboratory的El Capitan系统达到1.7 exaflops),超级计算机的节点架构出现了相当大的多样性。
  2. 平台选择挑战:在2024年11月的Top500榜单中,29.2%的系统同时具有GPU和CPU,占总性能份额的41.3%。面对众多计算平台选择,研究人员在实际约束条件下(如集群可用性和项目预算)选择合适平台求解问题并不总是明确的。
  3. 性能可移植性需求:大型代码库必须同时支持各种现有和即将推出的架构以及新功能,开发、管理、测试和维护特定平台的代码库版本是不可行的。许多团队通过使用RAJA、Kokkos、SYCL和OpenMP等抽象库进行单源性能可移植移植来应对这一挑战。

现有方法局限性

  1. 缺乏指导:文献中缺乏关于如何实际比较异构系统性能的指导
  2. 基准单位不统一:传统的单处理器基准在异构计算类型间比较时存在困难
  3. 分析工具分散:现有性能分析工具通常专注于单一架构或性能的单一方面

研究动机

本文旨在为跨平台性能比较提供系统性指导,特别是在云计算环境中,用户必须从一系列计算节点架构中选择并相应付费的场景下。

核心贡献

  1. 提出节点到节点比较范式:将单个计算节点确立为跨平台研究的相关计算单位
  2. 系统化扩展研究方法:详细描述了四种类型的节点到节点扩展研究方法
  3. 标准化可视化模板:提出了用于分析和比较跨平台性能的图表模板
  4. 实际工作流程指导:提供了设置、运行和分析节点到节点扩展研究的完整工作流程
  5. 真实案例验证:通过MARBL代码的多个案例研究验证了方法的有效性

方法详解

任务定义

本文研究的任务是建立一套标准化的跨平台性能比较方法,输入为不同平台上的计算任务,输出为可比较的性能分析结果和可视化图表。

节点到节点扩展研究类型

1. 强扩展研究(Strong Scaling)

  • 定义:保持总问题规模固定,变化计算资源数量
  • 度量:强扩展加速比 = t_P(1)/t_P(N),其中t_P(1)为单节点运行时间,t_P(N)为N个节点运行时间
  • 理想情况:运行时间随节点数量线性减少(log₂-log₂坐标系中斜率为-1)

2. 弱扩展研究(Weak Scaling)

  • 定义:保持每个计算节点的局部问题规模固定,随节点数量增加而增加总问题规模
  • 度量:弱扩展效率 = t_P(1)/t_P(N)
  • 理想情况:运行时间保持不变(log₂-log₂坐标系中斜率为0)

3. 强-弱扩展研究(Strong-Weak Scaling)

  • 定义:在单一图表中同时展示强扩展和弱扩展结果
  • 用途:帮助确定运行计算的"最佳点"
  • 可视化:实线连接强扩展数据点,虚线连接弱扩展数据点

4. 吞吐量扩展研究(Throughput Scaling)

  • 定义:在固定资源上比较每节点吞吐量,变化问题中的自由度数量
  • 度量:吞吐量 = ⟨DOFs-processed⟩/compute_node × cycles/second
  • 目标:找到资源饱和点并识别性能瓶颈

技术创新点

  1. 统一基准单位:以计算节点为基本比较单位,有效规范化不同节点架构的差异
  2. 标准化可视化:采用log₂-log₂坐标系,使理想扩展表现为特定斜率的直线
  3. 跨平台分析:通过垂直线比较相同节点数下的相对性能,通过水平线比较达到相似性能所需的节点数
  4. 综合评估框架:结合多种扩展类型提供全面的性能画像

实验设置

测试平台

  1. Sierra (ATS-2):125 petaflop系统,4,320个计算节点,每节点配备两个20核POWER9处理器、四个NVIDIA Volta V100 16GB GPU和256GB内存
  2. Astra:2.3 petaflop系统,2,592个计算节点,每节点配备两个28核Cavium ThunderX2 ARM处理器和128GB内存
  3. CTS-1:商用系统,1,302个计算节点,双18核Intel Xeon E5-2695处理器,128GB内存
  4. CTS-2:商用系统,1,496个计算节点,双56核Intel Xeon Platinum 8480+处理器,256GB内存
  5. EAS-3:El Capitan早期访问系统,36个计算节点,单64核AMD Trento处理器,四个AMD MI-250X 128GB GPU,512GB内存

测试代码

使用MARBL(Multiphysics on Advanced Platforms)代码,这是Lawrence Livermore National Laboratory开发的下一代性能可移植多物理仿真代码,专门用于模拟高能密度物理(HEDP)。

工作流程工具

  • Maestro:用于编排扩展研究的运行
  • Caliper和Adiak:用于代码注释和元数据收集
  • Thicket:用于读取和过滤Caliper数据,生成扩展图表

实验结果

案例研究1:FY20项目里程碑

在Triple-Pt 3D流体力学基准测试中:

  • 强扩展性能:GPU平台Sierra在单节点上相比CPU平台有约15倍加速比,但随着节点数增加,优势逐渐减小(8节点时约8倍,32节点时约4倍)
  • 弱扩展性能:Astra表现出优异的弱扩展性(2,048节点时仅1.49倍减速),Sierra也显示合理的弱扩展性(1.8倍减速)

案例研究2:高阶运行的节点到节点吞吐量研究

  • CPU平台限制:CTS-1和CTS-2快速饱和,吞吐量曲线相对平缓
  • GPU平台优势:ATS-2和EAS-3实现显著更高的吞吐量
  • 内存容量影响:EAS-3节点相比ATS-2可运行大一个数量级的问题
  • 多项式阶数效应:所有平台上,随着多项式阶数从线性增加到二次再到三次,代码都实现更高吞吐量

案例研究3:不同库特性的跨平台比较

在Shaped-Charge 3D问题中:

  • 内存池共享效益:在GPU平台上,主机代码MARBL和状态方程库LEOS共享预分配内存池相比各自使用独立内存分配,在所有规模下都观察到显著优势(2x-4x改进)

案例研究4:容器化MARBL性能对比

  • 性能损失最小:容器化MARBL (cMARBL)相比原生MARBL二进制文件的性能损失可忽略不计
  • 云端部署可行性:为利用云资源进行各种MARBL工作负载提供了机会

相关工作

传统扩展研究

传统强扩展和弱扩展研究通常以单处理器为基准,这种方法在异构计算类型间比较时存在困难。本文的节点到节点方法提供了更实用的跨平台比较基础。

性能分析工具

现有工具如PAPI counters、ARM forge、Intel VTune、NVIDIA Nsight等通常专注于单一架构。相比之下,Ubiquitous Performance Analysis范式和相关工具(Caliper、Adiak、Hatchet、Thicket)为跨平台性能分析提供了更好的支持。

工作流管理

Maestro、Merlin、Ramble等工具帮助管理仿真集合,但并非都内置支持在不同集群上运行仿真和比较结果的功能。

结论与讨论

主要结论

  1. 节点级比较的有效性:单个计算节点作为跨平台比较的基本单位是合理和实用的
  2. 标准化可视化的价值:提出的图表模板能够清晰展示不同类型的扩展性能
  3. 实际应用的成功:通过多个真实案例验证了方法的有效性和实用性

局限性

  1. 节点内通信成本:节点到节点扩展研究将一些节点内通信成本纳入初始单节点测量中
  2. 手动工作量大:实际设置这些研究和跨运行跟踪数据/元数据需要大量手动工作
  3. 数据点有限:使用均匀细化进行弱扩展导致数据点很少

未来方向

  1. 框架开发:开发更容易设置此类研究的框架
  2. 云计算探索:利用云计算集群的多样化计算节点探索更多"假设"问题
  3. 能耗分析:扩展到能耗/功耗使用的跨平台比较

深度评价

优点

  1. 实用性强:提出的方法直接解决了HPC社区面临的实际问题
  2. 系统性完整:从理论框架到实际工作流程都有完整覆盖
  3. 验证充分:通过多个真实的大规模案例研究验证了方法有效性
  4. 可视化清晰:提出的图表模板直观易懂,便于分析和比较
  5. 工具支持:提供了完整的工具链支持

不足

  1. 理论深度有限:主要是方法论和实践指导,缺乏深层理论分析
  2. 普适性待验证:主要基于MARBL代码的案例,其他类型应用的适用性需要进一步验证
  3. 自动化程度低:当前工作流程仍需要大量手动配置和管理

影响力

  1. 填补空白:为HPC社区缺乏的跨平台性能比较指导提供了系统性解决方案
  2. 标准化潜力:提出的方法和可视化模板有成为社区标准的潜力
  3. 实用价值高:对于系统采购、云计算资源选择等实际决策具有重要价值

适用场景

  1. 系统采购评估:帮助决策者比较不同架构系统的性能
  2. 云计算资源选择:指导用户在云环境中选择最适合的计算实例类型
  3. 代码移植评估:帮助开发者评估代码在不同平台上的移植效果
  4. 性能优化指导:为性能优化工作提供基准和目标设定

参考文献

本文引用了52篇相关文献,涵盖了HPC扩展研究、性能分析工具、工作流管理和相关应用等多个方面,为研究提供了坚实的理论基础和技术支撑。


这篇论文为HPC社区提供了急需的跨平台性能比较指导,具有很强的实用价值。虽然在理论创新方面相对有限,但其系统性的方法论和充分的实验验证使其成为该领域的重要贡献。