当前信息技术的迅猛发展使得超级计算机系统架构日益复杂. 随着以GPU为代表的加速器技术的发展，加速器浮点性能越来越高，CPU与加速器的浮点性能差距越来越大. 异构系统架构通过整合不同类型的处理器（如CPU，GPU，FPGA等），实现了资源的共享和协同工作，从而提高了系统的整体性能，成为当前计算机系统发展的整体趋势. 根据2023年11月最新公布的TOP500排名，前10位中全部采用了异构系统架构，同时有74个上榜系统使用了加速器/协处理器技术，且呈现逐年增长的趋势. 这些充分表明超级计算已从传统CPU 集群向异构平台快速发展，随着硬件平台的类型转换，无论从各种类型软件(计算软件、管理软件)到服务模式都面临着重大挑战.

由于超级计算机系统研制的巨大成本以及科学家们希望通过高性能计算实现新研究成果的目标，在系统上执行的应用程序应该尽可能高效. 因而，为此类超级计算机系统开发应用程序的一个重要步骤就是性能分析和调优. 但因为此类机器的复杂架构，人们在设计阶段就对应用程序进行优化以获得最佳性能几乎是不可能的. 因此，有必要对超级计算机系统上运行的计算软件性能进行科学评测，并不断改进和优化程序，以此提升软件的真实性能.

为了真实反映计算软件在异构系统架构下发挥的实际性能，科研人员需要研究如何准确构建浮点性能特征指标，这也成为目前计算软件性能指标采集方法研究最为核心的问题之一. 浮点性能作为衡量计算软件性能的核心指标，直接影响到计算任务的执行效率、系统资源的利用率以及整体计算成本等.

当前一些国际主流并行程序性能分析工具及软件普遍存在与国产超算异构系统处理器产品兼容性低，往往需要进行插桩及重编译代码的方式，且单节点性能数据采集准确度不高等问题. 譬如，当前的程序性能分析工具主要面向异构系统设计和研发，普遍支持CPU，GPU，CPU+GPU等硬件环境，但对于国产超算异构系统的协处理器等还没有体系化的研究成果. 再譬如，用于评估GPU混合操作强度的基准测试工具mixbench^[1]，目前已经开发了CUDA，HIP，OpenCL，SYCL等多种实现，可以对系统性能数据进行准确采集，但在适用于GPGPU架构的计算密集型任务加速的协处理器上还没有开发实现；像Timemory^[2]，PAPI等并行程序需要进行插桩，同时需对被评测计算软件程序代码进行重编译，因而对于这类性能分析工具往往不具备通用及易用性；此外，像基准测试（Linpack Benchmark）的扩展版本HPL程序，主要用于解决大规模的线性方程组，由于它更多地专注于并行计算，因此在某些情况下可能无法准确评估单节点性能.

为了改进上述问题和不足，我们提出了一种异构系统下计算软件的性能数据采集方法，目前已实现单节点及多节点性能指标数据的有效采集，且对原程序无侵入性，无需修改需要被监控程序的代码进行插桩方式进行监控，通用性强，且在国产超算异构系统平台上得到了该方法的有效性实验验证.

本文工作的主要贡献包括3方面：

1）针对异构系统架构的复杂性，在国产超算系统上提出一种新的浮点性能数据采集方法，可为有效构建国产系统计算软件性能评测体系提供准确的分析依据；

2）开发了异构系统下浮点性能数据采集程序，实现了对并行计算软件浮点性能数据的收集和分析，且对原程序无侵入性，无需修改需要被监控程序的代码进行插桩方式进行监控，通用性强；

3）通过与rocHPL，Cannon，mixbench这3种典型基准测试程序的对比实验，验证了本文所提出方法的有效性和实用性，并针对人工智能（AI） 计算，在残差网络（residual network，ResNet）程序上开展了性能数据采集方面的监测研究，为科学计算软件应用生态的良性发展提供了数据支撑.

1.   相关工作

自20世纪70年代以来，研究人员相继开展了有关计算系统软件及工具性能测试和分析的研究工作，包括早期超算环境上的单一资源维度到多维度性能分析和测评工具的研发（如PerfExpert^[3]，Score-P^[4]，AutoTune^[5]，PAPI，Periscope^[6]等），以及近年来在超大规模和异构超算系统上的性能测评和分析（如Timemory^[2]，HPC-MixPBench^[7]，rocHPL^[8]等）. 以下是相关的研究工作详细介绍.

美国 Argonne 国家实验室应用数学所主任 Pool^[9]在1974 年一系列非正式的讨论会中评估建立一套专门解线性系统问题之数学软件的可能性. 时至今日，Linpack已成为国际上最流行的用于测试高性能计算机系统浮点性能的benchmark. 利用高性能计算机，通过高斯消元法求解N元1次稠密线性代数方程组的测试，以此评价高性能计算机的浮点性能. 其中Linpack测试包括3类：Linpack100，Linpack1000，HPL. 前2种测试运行规模较小，已不适合现代计算机的发展，HPL评测程序报告的每秒浮点运算次数统计结果仍然成为如今国际TOP500组织排名的重要依据^[10]. Eustace等人^[11]开发了一种用于构建高性能程序分析工具的灵活接口ATOM（analysis tools for object modification）. 该接口将OM通用对象修改库与特定于工具的插装文件相链接，以产生定制插装工具. 通过读入用户应用程序，并通过添加对特定于工具的分析过程的调用来修改它，以此实现高性能程序的性能分析. 为了使用户能够轻松访问计数器，以帮助进行性能分析、建模和调优. Browne^[12]等人提出一种可扩展的跨平台硬件计数器应用性能调优架构PAPI. 这些功能为源代码级别性能分析软件提供了必要的基础. 慕尼黑工业大学Gerndt等人^[6]基于APART工作组开发的一套自动性能分析工具Periscope，可以完成从性能特性规范到与2个监视系统的集成，通过搜索过程以实现应用分布式自动在线分析，可扩展到数千个处理器. Miceli等人^[5]提出一种插件驱动的并行应用程序自动调优方法AutoTune. AutoTune可以扩展到Periscope，由此产生的Periscope调优框架可为多核和众核架构调优串行和并行代码，并返回可以集成到生产版本代码中的调优建议. 为了使应用程序开发人员和用户更容易进行性能优化，Martin等人^[3]开发了一个将简单的用户界面与复杂的分析引擎相结合的工具PerfExpert. 此外，对于每个瓶颈PerfExpert都提供了简明的性能评估，并建议程序员可以采取哪些步骤来提高性能. Dieter等人^[4]设计和实现了一个面向超级计算应用的联合测量基础设施Score-P. 该基础设施具有高可扩展性和易用性，且可作为一些性能工具（如Periscope，Scalasca，Vampir，TAU等）的通用基础，目标是增强可伸缩性、改进互操作性和降低维护成本. Madsen等人^[2]提出了一个名为Timemory的通用性能测量和分析框架. 该框架为现有的性能测量和分析工具提供了一个通用的接口，解决了用户级扩展的限制，使得现有的分析工具和库可以轻松地与Timemory框架集成. 同时支持多种并行模型、数据采集技术，可以满足多种应用场景下的性能测量和分析需求. 同年，Parasyris等人^[7]开发了一套用于混合精度分析的HPC基准套件HPC-MixPBench，由一组具有代表性的内核和基准测试组成，广泛应用于HPC领域. 该基准套件配有一个测试工具框架，可以在其中插入不同的工具，并在基准集上进行评估. Chalmers等人^[8]对AMD的高性能Linpack（HPL）基准测试的开源实现rocHPL进行了性能优化，通过高度优化的线性代数库利用节点上的高通量GPU加速器，以及整个CPU插槽来执行延迟敏感的因子分解阶段，并在橡树岭国家实验室的Frontier系统早期接入集群的单个节点上，以及扩展到多个节点上，展示了HPL基准测试的一些性能结果.

上述相关工作可以帮助人们更好地了解系统的运行情况和性能瓶颈，针对性地进行优化和改进，提高系统的整体性能和效率. 同时，也为本文的异构系统性能指标采集方法研究提供了重要的理论和实践基础.

2.   采集方法

本文提出了一种异构系统计算软件性能指标数据采集方法（如图1所示）. 该方法基于国产超算系统验证平台对浮点性能采集原型进行开发. 通过使用 AMD 基于异构系统架构实现的 rocm runtime 技术的API接口完成. 其中，2.1节主要介绍性能数据采集程序，2.2节主要介绍rocHPL，Cannon，mixbench这3类验证程序及算法的设计，以及ResNet 应用程序的原理分析.

图  1  性能数据采集方法框架

Figure  1.  Framework of performance data collection methods

下载: 全尺寸图片 幻灯片

2.1   性能指标数据采集程序介绍

本文提出了一种性能指标数据采集程序rocprofiler，可以实现单节点和多节点性能指标数据的有效采集. 我们自定义了一个浮点性能数据采集库（单位为FlOPS），并研发了一个采集接口rocprofiling lib API，用以采集以核函数（kernel function，KF）为单位的性能文件. 此外，我们还设计了一个单机版性能收集工具rpl，用以记录测试程序进程信息（如PID、开始和结束时间等），并对所收集的性能指标在时间维度上进行序列化，最终输出性能指标文件. 我们主要考虑到它是 AMD 提供的一个性能分析库接口，提供了一系列函数和数据结构，可用于收集和分析处理器在运行时的各种性能指标. 由于它是 AMD 官方提供的库，因此与 AMD 处理器的兼容性通常很好，能够确保数据的准确性和可靠性. 且对原程序无侵入性，无需修改需要被监控程序的代码进行插桩方式进行监控，该采集程序的通用性较强. 性能指标数据采集程序流程如图2所示.

图  2  性能指标数据采集程序流程图

Figure  2.  Flowchart for data collection program of performance metrics

下载: 全尺寸图片 幻灯片

rocprofiling lib API依赖AMD rocm生态的核心组成部分HSA Runtime. 在rocm中，HSA Runtime 负责在CPU，GPU等异构计算单元提供底层的硬件控制和调度（如内核函数的加载、执行）、内存管理和硬件抽象层. 同时HSA Runtime提供一个环境变量HSA_TOOLS_LIB，同过此环境变量，可以在执行基于HSA Runtime的rocm程序时动态加载特定的工具库实现对HSA Runtime的功能扩展，如监控或调试. 基于此，我们开发了rocprofiling lib API库，在程序启动前，通过设置HSA_TOOLS_LIB环境变量，实现在程序启动时对rocprofiling lib API库的动态加载，通过事件拦截和 API 来获取 GPU 任务的执行状态、内存使用、API 调用时序等，例如，当 HSA Runtime 提交一个 GPU 内核执行时，rocprofiling lib API库可以记录下该内核的提交时间、执行开始时间、结束时间，使用的GPU卡，以及在这段时间内的硬件性能数据. rocprofiling lib API库在加载后，会实时监控HSA Runtime核函数调度和执行的性能指标数据，在程序运行的整个生命周期内，会持续按特定的格式输出性能指标数据到指定文件中，基于这个特性，可以实现准实时的GPU性能分析，或在程序运行完毕后进行综合的性能分析. 我们选择采集以核函数为单位的性能文件，记录和分析核函数对算法性能影响的文件. 通过分析和比较性能文件中的数据，更好地理解核函数在算法中的作用，并优化核函数以提高算法的性能. 同时，这些性能文件也可以为后续研究提供有价值的参考数据.

在性能指标的选择上，我们选择了SQ_INSTS_VALU这个指标作为基准采集指标， SQ_INSTS_VALU代表在 GPU 内核中由矢量算术逻辑单元（vector arithmetic logic unit，VALU）执行的指令数，这个指标数据会侧面反应程序的浮点性能数据F（单位为GFlops）执行情况. 目前采用的计算公式如下：

gpi为实验测得的经验值，针对本实验平台(AMD Vega20)，取值为 125.038 8，针对不同的平台，gpi值可能需要进行相应的调整；t为计算时长，在SQ_INSTS_VALU按秒进行归一化后，t取1.

此外，对所收集的性能指标在时间维度上进行序列化，主要涉及将性能指标数据按照时间顺序进行编码和转换，以便于存储、传输和后续的分析处理. 序列化是将数据结构或对象状态转换为可以存储或传输的格式的过程. 通过对性能指标在时间维度上进行序列化，我们可以方便地存储、传输和分析大量的性能数据，从而更好地了解系统的性能状况，发现潜在的性能问题，并进行优化和改进.

该采集程序的伪代码如算法1所示.

算法1. 采集程序.

① /*注册核函数运行态数据采集*/

② OnLoadToolProp (rocprofiler_settings_t* settings)；

③　/* 加载配置文件及环境变量 */

④ LoadEnv()；

⑤　/*向rocm内核注册监视指标信息*/

⑥ registerMonitorMetrics()；

⑦ /*获取profiling队列*/

⑧ getProfilingVec()；

⑨ /*获取可用GPU agents信息*/

⑩ HsaRsrcFactory::Instance(). GetGpuAgent Info()；

⑪ /* 打开GPU profiling池接口*/

⑫ for i = 0 to n do

⑬　rocprofiler_pool_open()；

⑭ end for

⑮ /* 向GPU注册dispatch回调接口*/

⑯ rocprofiler_set_queue_callbacks()；

⑰ /* 回调接口处理*/

⑱ dispatch_callback_opt()；

⑲ /* 获取核函数运行GPU agent信息*/

⑳ GetAgentInfo()；

㉑ /* 获取profiling上下文信息*/

㉒ rocprofiler_pool_fetch()；

㉓ /* 通过上下文获取指标计数*/

㉔ rocprofiler_get_group.

基于2.1节性能指标数据采集程序的设计与描述，我们将在2.2节中设计4类程序及算法，对上述采集程序的准确性及可行性进行验证分析.

2.2   验证程序及算法设计

在应用程序运行设计环节，我们主要在国产超算平台上进行采集方法的验证. 具体配置参数包括：Linux操作系统，ROC Kernel Driver，rocm库，Tool-lib Interface以及基于HSA架构实现的 rocm runtime技术的API接口完成，并同时选择使用rocHPL，Cannon，mixbench，ResNet这4类程序对采集方法的有效性进行测试验证.

以下是这4类程序及算法原理的相关介绍：

2.2.1   rocHPL程序

我们使用rocHPL验证采集程序的准确性和可行性. rocHPL^[8]是基于HPL基准应用程序的基准测试工具，在AMD的Radeon开放计算ROCm平台、运行时和工具链之上进行实现. 其根据HIP编程语言创建，并针对AMD最新的独立GPU进行优化，能充分利用AMD ROCm平台计算卡性能. rocHPL采用精细的并行化策略，充分利用AMD GPU的并行计算能力，优化数据布局和内存访问模式，最大程度地减少内存访问延迟和提高内存带宽利用率.

此外，ROCBLAS作为AMD Radeon开放计算平台（ROCm）中的基本线性代数子程序（BLAS）库，提供了一组高效的基本线性代数操作函数，如矩阵乘法、矩阵向量乘法等. rocHPL可以利用ROCBLAS中优化的BLAS函数来执行一些基本的线性代数操作，从而加速LU分解过程和其他计算操作，获得更好的性能和效率. rocHPL程序的伪代码如算法2所示.

算法2. rocHPL程序.

① generate_random_matrix (A, n)；

② allocate_and_initialize_memory (A, n)；

③ /* 执行 LU 分解*/

④ for k = 1 to n do

⑤　synchronize_threads()；

⑥　/* 发送数据到计算设备 */

⑦　send_to_device()；

⑧　/* 找到主元素并行广播 */

⑨　find_and_broadcast_pivot (A, k, n)；

⑩　/* 执行部分选主消元 */

⑪　partial_pivot_elimination (A, k, n)；

⑫　/* 对于每个列，计算乘法因子并更新下一列， 　基于 ROCBLAS 进行求解 */

⑬　for j = k+1 to n do

⑭　　A[j][k] = A[j][k]/A[k][k]；

⑮　　for i = k+1 to n do

⑯　　　A[j][i] = A[j][i] − A[j][k] × A[k][i]；

⑰　　end for

⑱　end for

⑲　/* 同步数据 */

⑳　device_synchronize；

㉑ end for

㉒ free_memory (A).

为了保证数据的可靠，我们对 rocHPL 程序特别编译了双精度和单精度版本，分别进行测试，通过对比 rocHPL 自身的输出和采集程序输出来验证采集程序的准确性和可行性. 在2.2.2节中，我们将展示异构系统下的国产超算系统在单个节点及多个节点上的rocHPL基准测试的性能采集分析结果.

2.2.2   Cannon算法

我们在异构系统架构下实现了一个高性能的Cannon算法来验证采集程序的准确性和可行性. Cannon算法专为分布式计算环境中的矩阵乘法任务设计，优化了多处理器系统中大规模矩阵的计算，因此在通信效率上具有显著优势. 该算法采用分块矩阵乘法策略，将矩阵细分成更小的子矩阵或块，并按网格状布局分配到各个处理器上. 通过对数据块执行有序轮换操作，Cannon算法确保每个处理器能有效减少跨处理器通信，同时获取完成其计算任务所需的准确数据.

关于Cannon算法的原理介绍具体如下：

假设矩阵A，B，C可以分成m×m块矩阵，即A = ($\boldsymbol A_{i,j}$)_m×m，B = ($\boldsymbol B_{i,j}$)_m×m，C = ($\boldsymbol C_{i,j}$)_m×m. 其中$\boldsymbol A_{i,j}$，$\boldsymbol B_{i,j}$，$\boldsymbol C_{i,j}$是n×n矩阵，进一步假定有p = m×m个处理机. 为了研究Cannon算法，我们引入块置换矩阵Q = ($\boldsymbol Q_{i,j}$)，使

其中I_n和O_n分别是n阶单位矩阵和零矩阵. 定义对角块矩阵${\boldsymbol{D}}_{\boldsymbol{A}}^{\left(l\right)}$ = $\mathrm{d}\mathrm{i}\mathrm{a}\mathrm{g}({\boldsymbol{D}}_{\boldsymbol{A}}^{\left(l\right)}$) = diag(A_i,i+1 mod m)，容易推导出：

因此，

其中${\boldsymbol{B}}^{\left(l\right)}$ = ${\boldsymbol{Q}}^{l}\times \boldsymbol{B}=$ ${\boldsymbol{Q}}^{l}\times {\boldsymbol{B}}^{(l-1)}$，利用这个递推关系式，并把处理器编号从1维映射到2维，即有P_myid = P_myrow,mycol，数据$\boldsymbol A_{i,j}$，$\boldsymbol B_{i,j}$，$\boldsymbol C_{i,j}$存放在$\boldsymbol P_{i,j}$中，得到在处理器P_myid上的算法，如图3所示.

图  3  处理器P_myid上的算法示意图

Figure  3.  Illustration of the algorithm on processor P_myid

下载: 全尺寸图片 幻灯片

基于上述有关Cannon算法的原理介绍，我们设计了一种Cannon算法的并行策略程序，用以与本文提出的采集程序rocprofiler进行验证分析.

Cannon算法的并行策略如图4所示.

图  4  Cannon算法的并行策略设计示意图

Figure  4.  Illustration for the design of parallel strategies in the Cannon algorithm

下载: 全尺寸图片 幻灯片

将该算法的并行策略设计主要分为以下部分：

1）使用MPI实现节点间并行Cannon算法在节点间并行方面，通过MPI实现矩阵的分块处理. 计算整个矩阵$N\times N$被分割成$m\times m$个小块，每个节点负责计算矩阵的一个子块，子块的大小为$\dfrac{N}{m}\times \dfrac{N}{m}$，共计使用$m\times m$个节点. 算法初始阶段，每个节点会预加载所需的数据块. 然后，随着计算的进行，每个节点在处理完当前的数据块后，会将其沿着特定的方向传送到相邻的节点,每个节点的通信代价为$O\left(\dfrac{2{N}^{2}}{{m}^{2}}\right)$，计算复杂度为$O\left(\dfrac{{N}^{3}}{{m}^{2}}\right)$. 这种方式有效减少了节点间的通信需求，并允许每个节点同时进行计算和数据传输，最大限度地利用了网络带宽.

2） 充分考虑并行策略在加速卡并行方面的扩展性考虑到每个节点配备了$n$个加速卡，这些加速卡将共同承担每个节点内的矩阵计算任务. 在这种设置下，每个加速卡将负责计算其分配到的子矩阵块的一部分. 每个节点上的矩阵子块被进一步划分为$n$个更小的部分，每个加速卡负责处理其中的一个部分. 在进行加速卡计算时，每个加速卡需要处理的数据量是整个矩阵的$\dfrac{1}{{nm}^{2}}$. 以一个$N\times N$的矩阵为例，每个加速卡处理的通信代价为$O\left(\dfrac{{N}^{2}}{{nm}^{2}}\right)$，计算复杂度为$O\left(\dfrac{{N}^{3}}{{nm}^{2}}\right)$.

在每个加速卡完成自己部分的计算后，我们需要将计算结果传输回其所属节点的主内存中. 这一步骤涉及的通信代价也是$O\left(\dfrac{{N}^{2}}{{nm}^{2}}\right)$.

该Cannon 算法程序伪代码如算法3所示.

算法3. 基于Cannon算法的分布式和加速卡矩阵.

① procedure CannonMatrixMultiply (A, B, C, m, n) ；

②　N ← 矩阵的总维度；

③　每个节点负责的子矩阵大小block_size ← 　N/m；

④　每个加速卡负责的子矩阵大小sub_block_ 　size ← block_size/n；

⑤　分配内存和显存资源；

⑥　初始化本地矩阵 A_local，B_local，C_local；

⑦　将A， B分块广播到各个节点；

⑧　for node_id = 0 to m² − 1 do

⑨　　for gpu_id = 0 to n − 1 do

⑩　　　在GPU上分配A_gpu，B_gpu，C_gpu及双缓冲 　　　区；

⑪　　end for

⑫　end for

⑬　对A_local，B_local进行初始行列对齐；

⑭　for step = 0 to m−1 do

⑮　　并行对每个节点的每个GPU执行：

⑯　　　双缓冲异步复制A_local，B_local的1/2到A_gpu， 　　　B_gpu；

⑰　　　使用矩阵乘法核心计算C_gpu ← C_gpu + 　　　A_gpu × B_gpu；

⑱　　　计算出的C_gpu是C_local的1/4；

⑲　　对A_local，B_local进行环形移位，与下一个节 　　点的数据交换同时进行；

⑳　　同步所有GPU处理器；

㉑　end for

㉒　收集所有点上的C_local到C；

㉓ end procedure

2.2.3   mixbench程序

我们使用mixbench程序验证采集程序rocprofiler的准确性和可行性. mixbench^[1]是一个GPU基准测试工具，旨在评估混合操作强度内核上GPU的性能范围. 它允许用户在一系列不同的操作强度值上对执行的内核进行自定义，以深入了解GPU在不同工作负载下的性能表现.

结合全局内存访问执行单精度浮点乘加运算、双精度浮点乘加运算、半精度浮点乘加运算（仅适用于GPU）和整数乘加运算这4种类型进行实验. 当前的 GPU 能够通过将执行切换到能够执行计算操作的线程来隐藏内存延迟. 使用该工具可以评估计算设备在这2种类型的操作中的实际最优平衡.

本文使用mixbench程序对国产超算系统单个节点上的mixbench程序开展性能指标采集，通过测试程序进行实验验证.

该采集程序的部分关键代码如算法4所示 .

算法4. mixbench 程序.

① /* 设置计算矩阵大小*/

② const long reduced_grid_size = size/(ELEMENTS_ PER_THREAD)/128；

③ const int BLOCK_SIZE = 256；

④ const int TOTAL_REDUCED_BLOCKS = reduced_ grid_size / BLOCK_SIZE；

⑤ /* 拆分矩阵计算网格*/

⑥ dim3 dimReducedGrid()；

⑦ /* 定义计算函数*/

⑧ benchmark_func()；

⑨ /* 加载到加速卡进行计算*/

⑩ hipExtLaunchKernelGGL().

2.2.4   ResNet程序

我们选择对一种深度卷积神经网络模型ResNet进行监控测试，尝试针对AI 计算包括训练和推理做一些性能数据采集方面的研究. ResNet由He等人^[13]在2015年提出，是一种深度神经网络架构. 通过引入残差连接解决了深度神经网络在训练过程中遇到的梯度消失或梯度爆炸问题，从而允许网络层数显著增加，性能也随之提升. 经典神经网络ResNet作为一种重要的深度学习模型，成为许多深度学习模型的基础架构，在人工智能领域有着较广泛的应用^[1].

下面是有关ResNet程序算法的原理，主要分为5个方面：

1）残差学习

传统的神经网络直接学习输入到输出的映射函数H(x). 而ResNet程序通过引入残差学习这一方法原理，使得网络学习的是输入x与输出H(x)之间的残差F(x) = H(x) − x. 这样，网络的实际输出是H(x) = F(x) + x. 这种设计使得网络在训练时更容易优化，因为残差映射通常比原始映射更容易学习，如图5所示.

图  5  残差学习构建块模型示意图^[13]

Figure  5.  Iluustration of the residual learning for building block model

下载: 全尺寸图片 幻灯片

2）残差块

ResNet的基本组成单元是残差块^[14]. 残差块内部通常包含多个卷积层（通常为2到3个），每个卷积层后面跟着批量规范化和非线性激活函数. 重要的是，残差块的输入会通过跨层连接直接加到输出上，形成残差连接. 这种连接是恒等映射，不会增加额外的参数和计算量.

3）网络结构

ResNet的网络结构基于VGG网络，但去除了全连接层，改用全局平均池化层来减少参数数量并提高模型的泛化能力. ResNet的网络深度可以从几十层到几百层不等，如ResNet-18，ResNet-34，ResNet-50，ResNet-101等. 不同深度的ResNet在网络结构和参数数量上有所不同，但都遵循了残差连接的基本原则.

4）瓶颈设计.

在较深的ResNet版本中（如ResNet-50及以上），为了降低计算复杂度，残差块采用了瓶颈设计. 瓶颈设计首先通过一个1×1的卷积层来降低特征图的维度（称为降维），然后通过一个3×3的卷积层进行特征提取，最后再通过一个1×1的卷积层将特征图的维度恢复（称为升维）. 这种设计减少了参数量和计算量，同时保持了模型的性能.

5）训练与性能.

ResNet在训练过程中利用残差连接的优势，有效缓解了梯度消失问题，使得深层网络也能够被有效训练. ResNet通过引入残差连接和残差块设计，解决了深度神经网络在训练过程中遇到的梯度消失问题，使得网络层数可以显著增加，性能也随之提升.

本文选择ResNet程序对性能数据进行监控，尝试针对AI 计算包括训练和推理做一些性能数据采集方面的研究.

3.   实验与分析

3.1   实验环境介绍

本实验的测试环境是部署在国产超算异构系统上，由6400个计算节点组成，每个节点配备一个AMD CPU （32核AMD EPYC 7551P CPU，128 GB主内存）和4个最新的AMD GPUs（Vega20）. 系统中使用的GPU是AMD定制的固定低频（1.4 GHz）的特殊型号.

一个CPU有32个核心，提供384 GFlOPS，而一个GPU提供5.9 TFLOPS. 在每个节点中，CPU侧有128 GB的DDR4内存，GPU侧有64 GB的HBM2内存. HBM2内存的带宽高达1TBps. 所有节点通过具有200 Gbps高速网络接口的高带宽FatTree互连网络连接. 在1个节点内，2个计算组件通过PCle总线（Gen 3.0）连接. 总共有25600个GPU，它们一起提供了152 PFlOPS的峰值性能. 在2020年之前，它是世界上最大的基于PCle的GPU异构系统. 实验的操作系统基于 CentOS 7.6，GNU编译器套件版本为7.3.1，OpenMPI版本为 4.1.4，ROCm 版本为 4.0.1.

3.2   实验结果分析

在实验环节，我们分别使用rocHPL，Cannon，mixbench这3种测试程序对本文提出的性能指标数据采集方法进行实验验证和对比分析. 同时，针对AI 计算，在ResNet程序上开展了性能数据采集方面的监测分析.

实验与分析结果具体如下：

1）rocHPL.

① 单节点双精度采集分析. 在这个实验中，我们首先进行了单节点4卡双精度的测试，我们在同一节点上对 rocHPL 双精度版根据不同的运算规模进行测试，在运行 rocHPL 的同时运行采集程序rocprofiler，输出结果如表1和图6所示.

表  1  不同规模下rocHPL程序（双精度）和rocprofiler程序的输出结果

Table  1.  Output Results of rocHPL (Double Precision) and rocprofiler Programs at Different Scales

运算规模/ 阶数	运行时间/ s	rocHPL浮点运算 速度/GFLOPS	rocprofiler浮点运算 速度/FLOPS	误差/%
80000	126	2741.4	2712.73	−1.05
81000	129	2763.7	2749.63	−0.51
82000	131	2811.9	2810.80	−0.04
83000	126	2838.4	2806.07	−1.14
84000	128	2881.4	2866.74	−0.51
85000	142	2912.7	2888.28	−0.84
86000	145	2952.6	2927.42	−0.85
87000	148	2977.9	2970.92	−0.23
88000	152	3017.6	2994.61	−0.76

下载: 导出CSV 

| 显示表格

图  6  使用单节点4 GPUs的双精度rocHPL和rocprofiler程序在不同规模下的输出结果

Figure  6.  Output results of double precision rocHPL and rocprofiler programs using a single node with 4 GPUs at different scales

下载: 全尺寸图片 幻灯片

rocHPL的实际性能随着运算规模的增大而逐渐升高，基本呈线性关系；采集程序的输出比 rocHPL输出稍低，并随着 rocHPL的性能升高而进行相应的升高，两者的整体变化趋势趋于一致. 经过对输出数据的运算，采集程序rocprofiler的整体误差在−0.66%左右. 针对以上有关双精度浮点数计算准确性验证实验我们可以看出，在不同规模下采集程序输出的浮点性能与目标程序输出浮点性能的误差没有明显变化，采集准确性与计算规模变化无关.

② 单节点单精度采集分析. 由于单精度在运算中的内存占用比双精度小，在实际测试中，我们使用更高的规模进行了4卡单节点单精度的测试（如表2和图7所示）. rocHPL单精度版的浮点性能随着规模的增加而增高，基本呈线性关系，采集程序rocprofiler的输出比rocHPL稍低，并随着 rocHPL 的性能升高而进行相应的升高，两者的整体变化趋势趋于一致. 经计算，整体误差为−1.65%.

表  2  不同规模下rocHPL程序（单精度）和rocprofiler程序的输出结果

Table  2.  Output Results of rocHPL Programs (Single Precision) and rocprofiler Programs at Different Scales

运算规模/ 阶数	运行时间/ s	rocHPL浮点运算 速度/GFLOPS	rocprofiler浮点运算 速度/GFLOPS	误差/%
80000	72	4775.2	4720.77	−1.14
90000	91	5415.0	5319.97	−1.75
100000	112	6041.6	5923.38	−1.96
110000	135	6663.6	6535.68	−1.92
120000	160	7271.1	7158.06	−1.55
127000	179	7708.7	7586.57	−1.58

下载: 导出CSV 

| 显示表格

图  7  使用单节点4 GPUs的单精度rocHPL和rocprofiler程序在不同规模下的输出结果

Figure  7.  Output results of single precision rocHPL and rocprofiler program using a single node with 4 GPUs at different scales

下载: 全尺寸图片 幻灯片

经实验分析，在不同规模下采集程序输出的浮点性能与目标程序输出浮点性能的误差没有明显变化，采集准确性与浮点数精度变化无关.

③ 多节点双精度采集分析. 为了验证采集程序在多节点上的扩展性，我们也对rocHPL在多节点上的采集进行了测试，鉴于整体内存资源的增加，进行了更大规模的测试.

表3给出了rocHPL双精度版和采集程序在不同规模下的输出结果. 从图8中可以看出，rocHPL的浮点性能随着规模的增加而增高，基本呈线性关系，采集程序rocprofiler的浮点运算值输出比rocHPL稍高，并随着rocHPL的性能升高而进行相应的升高，两者的整体变化趋势趋于一致. 经计算，整体的误差为0.1%.

表  3  不同规模下rocHPL程序（单精度）和rocprofiler程序的输出结果

Table  3.  Output Results of rocHPL (Single Precision) and rocprofiler Programs at Different Scales

运算规模/ 阶数	运行时间/ s	rocHPL浮点运算 速度/GFLOPS	rocprofiler浮点运算 速度/GFLOPS	误差/%
80000	122	2802.8	2802.89	0.00
90000	154	3159.5	3161.84	0.07
100000	189	3531.8	3539.41	0.22
110000	231	3865.9	3857.63	−0.21
120000	272	4252.3	4255.47	0.07
130000	319	4602.7	4614.90	0.27
140000	369	4973.6	4981.31	0.16
150000	423	5330.3	5342.72	0.23
160000	483	5673.7	5681.24	0.13

下载: 导出CSV 

| 显示表格

图  8  使用4节点16 GPUs的单精度rocHPL和rocprofiler程序在不同规模下的输出结果

Figure  8.  Output results of single precision rocHPL and rocprofiler program using 4 nodes with 16 GPUs at different scales

下载: 全尺寸图片 幻灯片

2）Cannon

本实验的主要目标是评估并优化Cannon并行矩阵乘法算法在异构系统上的执行效率. 异构系统广泛使用各种串行算法库，但为了实现高效的并行计算，特别是在处理矩阵乘法这类计算密集型任务时，理解并优化并行算法如Cannon是非常必要的. Cannon算法通过优化任务分配和负载平衡，有助于提高并行处理的效率.

因此，除了使用标准的rocHPL程序外，我们还实现了一个Cannon程序并且进行了深入测试，以验证其在实际应用中的表现，并通过采集程序监控其性能表现，以确保结果的可靠性和准确性. 这种测试不仅帮助我们评估算法的性能，还为进一步的优化提供了实验数据支持.

如表4所示，展示了Cannon程序和采集程序在单节点相同规模但不同参数配置下的输出结果. 其中−g代表每个节点的卡数，−p代表每个方向的分块数，在Cannon算法中固定为节点数的平方根. 经测算，整体误差为−4.55%.

表  4  单节点相同规模不同参数下Cannon程序和采集程序rocprofiler的输出结果

Table  4.  Output Results of Cannon and rocprofiler Programs with the Same Scales but Different Parameters for a Single Node

运算规模/ 阶数	参数配置	次数	运行时 间/s	Cannon输出 浮点运算值/ GFLOPS	rocprofiler输出 浮点运算值/ GFLOPS	误差/%
16000	−g1，−p1	10	8.5	960.318	902.866	−5.89
16000	−g4，−p1	10	20.7	395.157	382.871	−3.11

下载: 导出CSV 

| 显示表格

除单节点相同规模不同参数下Cannon程序和采集程序rocprofiler的输出结果进行对比外，我们也针对多节点的情况对Cannon进行了较大规模的实验验证和测试，分别为4节点16 GPU和16节点64 GPU. 如表5和表6所示，Cannon是个弱扩展的程序，在规模相同的情况下，增加节点和GPU对性能几乎无影响，但更多节点使Cannon能够执行更大规模的算例. 如图9和图10所示，无论是4节点16 GPU，还是16 节点64 GPU，随着规模的增加，Cannon程序的性能也随之大幅提升，相应的，采集程序rocprofiler的输出也随之增大. 经实验测算，误差在−1.72%~−3.33%内波动,误差并没有随着程序性能的提升有较大的波动. 经过计算，在4节点16 GPU的情况下，采集程序的整体误差为−2.62%，在16节点64 GPU的情况下，整体误差为−2.56%.

表  5  4节点16 GPUs下不同规模相同参数下Cannon程序和rocprofiler程序的输出结果

Table  5.  Output Results of Cannon and rocprofiler Programs Using 4 Nodes with 16 GPUs Under the Same Parameters at Different Scales

运算规模/ 阶数	参数配置	运行时 间/s	Cannon浮点 运算速度/ GFLOPS	rocprofiler浮点 运算速度/ GFLOPS	误差/%
16000	−g4，–p2	24.62	332.70	321.70	−3.31
20000	−g4，–p2	24.53	652.23	640.60	−1.78
24000	−g4，–p2	24.83	1113.45	1077.30	−3.25
28000	−g4，–p2	25.25	1738.82	1680.89	−3.33
32000	−g4，–p2	30.81	2127.25	2072.69	−2.56
36000	−g4，–p2	31.13	2997.30	2908.19	−2.97
40000	−g4，–p2	32.16	3979.96	3909.19	−1.78
44000	−g4，–p2	33.95	5018.20	4893.30	−2.49
48000	−g4，–p2	34.52	6408.18	6209.09	−3.11
52000	−g4，–p2	35.46	7931.46	7758.24	−2.18
56000	−g4，–p2	37.75	9304.78	9053.28	−2.70
60000	−g4，–p2	39.44	10953.08	10742.57	−1.92

下载: 导出CSV 

| 显示表格

表  6  16节点64 GPUs下不同规模相同参数下Cannon程序和rocprofiler程序的输出结果

Table  6.  Output Results of Cannon and rocprofiler Programs Using 16 Nodes with 64 GPUs Under the Same Parameters at Different Scales

运算规 模/阶数	参数配置	运行时 间/s	Cannon浮点运算 速度/GFLOPS	rocprofiler浮点运 算速度/GFLOPS	误差/%
16000	–g4，–p4	24.73	331.22	324.15	−2.13
24000	–g4，–p4	24.85	1112.42	1084.48	−2.51
32000	–g4，–p4	25.45	2574.84	2491.57	−3.23
40000	–g4，–p4	25.15	5089.31	5001.53	−1.72
48000	–g4，–p4	35.12	6298.12	6141.64	−2.48
56000	–g4，–p4	30.83	11392.37	11076.96	−2.77
64000	–g4，–p4	32.50	16133.76	15662.66	−2.92
72000	–g4，–p4	33.67	22168.59	21527.30	−2.89
80000	–g4，–p4	34.38	29783.12	29280.91	−1.69
88000	–g4，–p4	37.47	36376.88	35481.71	−2.46
96000	–g4，–p4	37.34	47390.02	45946.58	−3.05
104000	–g4，–p4	40.19	55981.57	54788.45	−2.13
112000	–g4，–p4	43.33	64853.90	62756.47	−3.23

下载: 导出CSV 

| 显示表格

图  9  使用4节点16 GPUs 的单精度Cannon和rocprofiler程序在不同规模下的输出结果

Figure  9.  Output results of single precision Cannon and rocprofiler programs using 4 nodes with 16 GPUs at different scales

下载: 全尺寸图片 幻灯片

图  10  使用4节点64 GPUs 的Cannon程序和rocprofiler程序在不同规模下的输出结果

Figure  10.  Output results of Cannon and rocprofiler programs using 4 nodes with 64 GPUs at different scales

下载: 全尺寸图片 幻灯片

针对以上有关Cannon浮点数计算准确性验证实验我们可以看出，在单节点或多节点的各个规模下采集程序输出的浮点性能与目标程序输出浮点性能的误差没有明显变化，且采集程序对我们实现的的Cannon程序也有很好的监控效果.

3）mixbench

此外，我们还对mixbench程序进行了测试. mixbench是一个性能基准测试工具，专门用于评估在支持 HIP（异构接口移植性）编程模型的 GPU 平台上的混合计算和内存负载的工作性能. 在本次测试中，使用的mixbench为单进程版，且固定使用GPU0来进行计算，通过设计用例来模拟程序在合理场景(1节点1进程)和不合理场景（1节点多进程）的性能表现，验证采集程序在不同场景下的输出是否符合预期.

表7给出了在相同规模、相同测试次数和迭代次数等相同参数下，节点上启动一个进程和多个进程的mixbench程序和采集程序的输出结果.

表  7  相同规模和相同参数下不同场景mixbench程序和rocprofiler程序的输出结果

Table  7.  Output Results of mixbench and rocprofiler Programs in Different Scenarios with the Same Scales and Parameters

场景	矩阵规模	测试 次数	迭代 次数	运行 时间/s	mixbench 浮点运算 速度/ GFLOPS	rocprofiler 浮点运算 速度/ GFLOPS	误差/ %
1n_1p	320×1024×1024	100	512	63	5381.88	5252.42	−2.41
1n_4p	320×1024×1024	100	512	286	4806.03	4742.65	−1.32
4n_4p	320×1024×1024	100	512	64	19866.15	20686.44	4.13
4n_16p	320×1024×1024	100	512	287	19145.15	18741.42	−2.11
16n_16p	320×1024×1024	100	512	64	80431.26	82745.77	2.88

下载: 导出CSV 

| 显示表格

场景中的1n_1p代表1节点运行1个进程，1n_4p代表节点运行4个进程，依此类推.

在合理场景下，如 1n_1p，4n_4p，16n_16p随着节点数的增加，整体性随之线性增长，这是由于mixbench本身为单进程版，各进程间没有依赖和通信，所以性能的增长情况是符合预期的，与之对应的采集程序rocprofiler的采集输出也随之线性增长，整体误差在5%以内.

另外，对比1n_1p和1n_4p以及4n_4p和4n_16p的结果可以看出，在不合理场景下，1n_4p和4n_16p由于单节点上出现多个进程竞争同一个GPU资源导致整体的性能不仅没有增加，反而出现降低，这时相对应的rocprofiler的输出也出现相应的降低，误差在3%以内.

4）ResNet

本文通过实验环节，判断采集程序在面对AI领域的计算任务能否正常提供支持. 由于ResNet本身不会输出自身的运算性能，暂时不能通过对比验证采集程序rocprofiler的准确性，所以增加本计算实验，用以证明本采集程序在AI领域的拓展性. 实验结果如表8所示.

表  8  rocprofiler程序在ResNet程序中多个参数下的输出结果

Table  8.  Output Results of rocprofiler Program Under the Multiple Parameters in ResNet Program

精度	模型	任务性质	参数大小	批量 大小	Class 数量	GPU 数量	rocprofiler浮 点运算速度/ GFLOPS
float	resnet34	训练	21797672	32	1000	1	87.52
float	resnet34	训练	21797672	32	1000	4	115.10
float	resnet34	测试	21797672	32	1000	1	39.96
float	resnet34	测试	21797672	32	1000	4	53.62
float	resnet50	训练	25557032	32	1000	1	100.31
float	resnet50	训练	25557032	32	1000	4	124.94
float	resnet50	测试	25557032	32	1000	1	72.64
float	resnet50	测试	25557032	32	1000	4	110.18
float	resnet101	训练	44549160	32	1000	1	162.12
float	resnet101	训练	44549160	32	1000	4	209.64
float	resnet101	测试	44549160	32	1000	1	117.02
float	resnet101	测试	44549160	32	1000	4	188.67
float	resnet152	训练	60192808	32	1000	1	233.12
float	resnet152	训练	60192808	32	1000	4	292.06
float	resnet152	测试	60192808	32	1000	1	183.30
float	resnet152	测试	60192808	32	1000	4	258.90
double	resnet34	训练	21797672	32	1000	1	306.95
double	resnet34	训练	21797672	32	1000	4	494.84
double	resnet34	测试	21797672	32	1000	1	194.79
double	resnet34	测试	21797672	32	1000	4	259.68
double	resnet50	训练	25557032	32	1000	1	370.14
double	resnet50	训练	25557032	32	1000	4	517.37
double	resnet50	测试	25557032	32	1000	1	163.06
double	resnet50	测试	25557032	32	1000	4	272.99
double	resnet101	训练	44549160	32	1000	1	417.67
double	resnet101	训练	44549160	32	1000	4	500.17
double	resnet101	测试	44549160	32	1000	1	218.62
double	resnet101	测试	44549160	32	1000	4	305.26
double	resnet152	训练	60192808	32	1000	1	455.73
double	resnet152	训练	60192808	32	1000	4	551.28
double	resnet152	测试	60192808	32	1000	1	323.48
double	resnet152	测试	60192808	32	1000	4	322.89

下载: 导出CSV 

| 显示表格

由上述4种实验测试结果可以看出，采集程序对 rocHPL 和mixbench的性能监控采集有较高的准确性，对于移植的 Cannon 的性能监控采集准确性稍差，但对于不同规模或不同参数的测试，采集程序的输出会表现出极高的趋同性. 此外，使用本文的采集方法，还可以针对AI 计算包括训练和推理做一些性能数据采集方面的研究，如使用ResNet进行监控测试，证明本采集程序在AI领域的拓展性. 由此可见，使用此种方法的软件性能指标采集具有准确性和实用性，具有较高的数据参考价值.

4.   总　　结

本文针对异构系统架构的复杂性，在国产超算系统上提出了一种新的浮点性能数据采集方法. 该方法基于国产超算系统验证平台对浮点性能采集原型进行开发及验证，并基于此方法开发了一种异构系统下浮点性能数据采集程序. 该程序实现了对并行计算软件浮点性能数据的收集和分析，且对原程序无侵入性，无需修改需要被监控程序的代码进行插桩方式进行监控，通用性强. 目前已实现单节点及多节点性能指标数据的采集，并在rocHPL，Cannon，mixbench，ResNet这4类程序中完成测试验证，采集程序准确度较高，采集效果达到实验预期，对程序调优具有较好的参考价值，由此可证明该方法的有效性和实用性，可为有效构建国产计算软件性能评测体系提供准确的分析依据.

下一步我们将继续在多个计算软件应用程序上对本文采集程序进行测试验证，同时进一步开展AI计算方向的测试程序实验验证，并对采集方法加以优化完善. 我们还将在HSA架构下的其他平台上进行实验分析和应用推广，希望可以为国产科学计算软件应用生态的良性发展提供数据和理论支持.

作者贡献声明：顾蓓蓓主要负责方法研究、实验设计、论文写作与格式校正等；邱霁岩、王宁、陈健主要负责实验分析和处理；迟学斌主要负责论文框架和实验指导.