Page 51 - 《软件学报》2021年第8期

孙乔 等:面向异构计算机平台的 HPL 方案 2333

身的尾子矩阵调用 dgemm(矩阵乘法)完成更新.
不论进程与 CPU 以怎样的方式对应,HPL 算法中占据绝大部分计算量的尾子矩阵更新操作都能完全利用
所有协处理器完成.在该过程通过协处理进行充分加速之后,其余的零散计算的资源使用率将成为性能瓶颈.其
中典型的有 Panel 分解操作及处于 Update 阶段的分布式行交换操作.从算法流程上,在 HPL 的每一次迭代步骤
中,只有特定 P-Fact 列进程完成本次迭代所需的 Panel 分解操作,同时也只有 U 行进程参与矩阵 U 的广播.因此
不同的进程与处理器的映射关系会导致不同的资源使用情况.图 3 展示了一个由 4 个实验节点(具体参数介绍
见第 5.1 节)组成的分布式环境.图 3 左侧展示了进程与 Socket 一一对应的情况.由于每一个 Socket 仅管理 8 个
CPU 核心和一个协处理设备.因此在 P-Fact 过程中只有共计 8×4=32 个 CPU 核心参与 Panel 分解运算,而在
Update 阶段的行交换过程中,仅有 4 个协处理器完成对 U 矩阵的打包并由对应的 4 道 PCI-e 总线进行传输.若
采用图 3 右侧进程与节点(node)一一对应的方式执行 HPL 程序,每个进程管控 4 个协处理器设备,则在 Panel 分
解部分将有 8×4×2=64 个 CPU 核心参与计算,而在 Update 阶段的行交换过程中会有 8 个协处理器及其 PCI-e
总线参与.随着协处理器运算能力的进一步增长,占绝大部分计算量的 BLAS 3 级函数能够很快完成,而诸如
Panel 分解,数据打包等必要步骤的运行时间比重将进一步加大,因此应在这些步骤中应尽可能地充分利用各种
硬件资源.

Fig.3 Different mappings between processes and nodes
图 3 进程与节点的不同对应关系

3 Hetero-HPL 总体结构

为了提高 HPL 各个阶段的资源利用率.本文提出 Hetero-HPL 方案.总体上,Hetero-HPL 中每一个进程能够
管理任意数量的协处理器,在大幅度提高上述关键计算步骤的资源利用率的前提下,以协处理器间高度负载均
衡的方式完成 HPL 计算.Hetero-HPL 对原始 HPL 算法做出的改动可归纳为数据映射及操作映射两个方面,分别
对应于如图 4 所示的 MD_Mapping 框架及 MD_Primitive 算法库.它们将在本节中分别予以介绍.