Porting and Parallel Optimization of Common Operators Based on Heterogeneous Programming Models
-
摘要:
GPU作为构造大规模超算系统的核心计算部件，向着体系结构多样化和异构化的方向发展. 来自不同芯片厂商的GPU加速器具有差异较大的体系结构设计. 加速器类型和编程模型多样化是构建大规模超算系统的重要技术趋势. 多样化加速器要求开发者为多种硬件平台提供高性能共性算法库软件，然而这也导致了算法库软件重复开发问题. 为降低重复开发成本，统一编程模型SYCL（system-wide compute language）应运而生，并适配了多种硬件平台. 尽管如此，在不同硬件上，SYCL的性能仍不及各自原生编程模型. 因此，需要进一步优化SYCL的性能以将目前成熟完备的CUDA（compute unified device architecture）编程思路和高性能程序应用到SYCL中. 基于软硬件协同设计，提出了paraTRANS方法，该方法是面向跨异构编程模型SYCL代码移植过程中共性算子优化工具，并在不同场景下给出了对移植得到的SYCL的GEMM（general matrix multiplication）进行优化的方法. 评测了paraTRANS优化后基于SYCL的GEMM算子在NVIDIA RTX 3090和AMD MI100上的性能情况. 结果显示，在NVIDIA RTX 3090上，paraTRANS达到了96.95% CUDA原生算子的性能水平；在AMD MI100上，则接近CUDA在NVIDIA RTX 3090上硬件峰值百分比100.47%所表现出来的性能水平. 这些结果表明成功地将原生高性能CUDA算子代码移植并进一步优化至SYCL环境中，并为未来类似工作提供新颖且有效的优化思路.
Abstract:As the fundamental computing component in constructing large-scale supercomputing systems, GPUs are undergoing architectural diversity and heterogeneity. GPU accelerators from various chip manufacturers exhibit significant variations in their architectural designs. Accelerator diversity and programming model diversity are important technical trends for building large-scale supercomputing systems. Diverse accelerators require developers to provide high-performance software for multiple hardware platforms, resulting in software duplication. To reduce the cost of duplication, the unified programming model SYCL (system-wide compute language) adapts to multiple hardware platforms, but SYCL’s performance on different hardware is not as good as the native programming model of the platform, and SYCL’s performance needs to be further optimized. In order to be able to apply the mature and complete CUDA (compute unified device architecture) programming ideas and high-performance programs to SYCL, it is necessary to discuss the performance of high-performance CUDA programs ported to SYCL on multiple platforms and the ideas for further optimization. Based on software-hardware co-design, we propose paraTRANS: a common operator optimization system for the code migration process of cross-heterogeneous programming model SYCL, and give the optimization methods for the migrated SYCL GEMM (general matrix multiplication) in different scenarios. We evaluate the performance of SYCL GEMM optimized by paraTRANS, which can achieve 96.95% of CUDA’s FLOPS on the original NVIDIA RTX 3090, and 100.47% of CUDA’s hardware peak performance percentage on AMD MI100, both close to the level before migration. This paper provides ideas for porting high-performance CUDA code to SYCL and further optimization.
-
Keywords:
- SYCL /
- cross heterogeneous architecture /
- code migration /
- GEMM /
- parallel optimization
-
近年来，在高性能计算领域，加速器的异构性正在成为显著的发展趋势. 各类CPU，GPU，FPGA，TPU都成为高性能计算领域可用的选择[1-2]. 伴随着硬件加速器类型的多样化，编程模型也存在着多样化的趋势.
OpenCL（open computing language） 是一个有望于实现跨异构平台的编程模型. OpenCL的存在促进了使用CPU，GPU以及其他加速器进行并行编程的发展，但其易用性成为了它再进一步的阻碍. 相比于CUDA（compute unified device architecture）编程，使用OpenCL进行编程更加的繁琐易错，开发效率不如使用CUDA. 并且OpenCL对于NVIDIA GPU，不能够像CUDA一样发挥硬件的性能，使用OpenCL也意味着会带来一定的性能损失[3].
SYCL（system-wide compute language）的设计初衷可以看作是为OpenCL提供了更高层次的抽象. SYCL覆盖了OpenCL现有的许多特性，并且因为引入更新的C++ 特性，为开发过程降低了难度和复杂度. 在美国能源部E级计算机研制计划ECP（exascale computing project）中，SYCL 被认为是实现可扩展、高性能计算的重要技术之一，被广泛使用于ECP的各个项目中. 如PROTEAS-TUNE-SYCL，STRUMPACK-SuperLU，SUNDIALS，hypre，ALExa 项目的Tasmanian库和Sake的子项目Kokkos Kernels 等，SYCL在其中都发挥着作用[4]. 目前有多种实现支持SYCL标准，如Intel DPC++，hipSYCL等. 其中Intel DPC++ 是目前对SYCL支持良好的编译器. 它支持了最新的SYCL 2020标准，并且开放源代码于 GitHub的Intel/LLVM仓库[5]. 本文使用了Intel DPC++作为SYCL的编译器实现来进行研究.
当前使用CUDA编写的高性能程序的体量十分庞大，生态相对完备. 在开发SYCL代码时，能够将已有的CUDA代码移植到SYCL提高开发效率、降低开发成本. 为了将CUDA程序高效地转换为其他程序，一些工具被专门用作CUDA到其他编程模型的移植. 例如，HIPIFY是用来将CUDA源代码自动化移植为HIP（heterogeneous-compute interface for portability）C++源代码的工具集[6]，DPCT（Intel DPC++ compatibility tool）是用来将CUDA源代码自动化移植SYCL源代码的辅助工具[7].
现有移植工具的存在，提高了将已有的、成熟的 CUDA 代码移植到SYCL过程的效率，降低了移植过程中的难度. 但是，本文观察到优化过的程序在移植之后会出现显著的性能下降的问题. 这些因为移植造成的性能问题存在一定的普遍性，文中将其分为2类：一类是当CUDA程序移植为SYCL程序之后，依然运行在原硬件时存在的性能下降问题；另一类是当CUDA程序移植为SYCL程序之后运行在其他异构硬件上存在的性能下降问题. 本文以一个高度优化的CUDA GEMM（general matrix multiplication）为例[8]，详细描述了CUDA GEMM移植后性能问题的发现与优化，提出一个面向跨异构编程模型SYCL代码移植过程的共性算子优化工具paraTRANS.
图1给出了paraTRANS的原理图. 如图1所示，paraTRANS将DPCT移植得到的在不同硬件上性能不佳的SYCL GEMM做进一步分析、辅助优化，从而得到适应硬件平台的SYCL GEMM. paraTRANS主要解决了DPCT移植来的SYCL GEMM的2个关键问题：1）解决了在相同体系结构GPU上因为寄存器占用增加造成的计算资源利用率低的问题；2）解决了在不同体系结构GPU（AMD MI100）上因为scratch memory访存开销造成的访存阻塞问题. 该工具通过分析和解决如上2个问题，使得进一步优化后的SYCL GEMM达到了移植前的性能水平.
1. 背景与研究动机
本节首先介绍了要移植的高度优化的GEMM实现，然后分析了DPCT移植前后的代码情况，最终总结了用DPCT移植后造成的性能下降情况.
1.1 基于CUDA编程模型的GEMM算子
本文研究高性能的CUDA代码在移植前后的性能差异，因此选择一个高度优化的CUDA GEMM实现作为移植对象. 该CUDA GEMM通过多层的矩阵分块、共享内存、预取、循环展开、解决访存冲突等方法进行了优化. 图2给出了CUDA GEMM的基本逻辑与访存情况，该实现将会先后把输入矩阵A，B的部分数据从全局内存写入共享内存，然后再从共享内存写入寄存器进行计算. 共享内存和寄存器的写入都使用了预取策略，将本轮计算与下一轮数据读取重叠，提升计算单元利用率.
![]()
图 2 基于CUDA编程模型的原生GEMM算子实例代码Figure 2. Native GEMM operator example code based on CUDA programming model1.2 针对CUDA GEMM的DPCT移植案例分析
Intel oneAPI toolkit提供了DPCT用来辅助进行CUDA到 SYCL的代码移植过程. 通常来说，90%~95%的CUDA代码能够通过DPCT工具转换为SYCL 代码. 不能够通过工具进行自动转换的部分，DPCT 会以“WARNING”的形式给出提示，然后由人工进行调整[7].
使用DPCT能够实现CUDA GEMM到SYCL GEMM的自动化移植. 如图3所示，移植后的SYCL GEMM在编程模型相关的关键字上出现了改变，但是算法并没有发生改变. 移植前后的CUDA GEMM与SYCL GEMM按照同样的逻辑执行计算.
![]()
图 3 经DPCT移植的朴素未优化的SYCL GEMM代码Figure 3. Naive unoptimized SYCL GEMM code ported by DPCT1.3 针对移植造成性能下降的评价
本文对同样逻辑、算法的CUDA GEMM与SYCL GEMM的性能进行了测试. 首先分析了CUDA GEMM与SYCL GEMM计算、访存的瓶颈. 如图4所示，本文首先选取了大小为M=N=K=4 864下的GEMM测试了其Roofline情况. 由图4可知，该GEMM的性能瓶颈为硬件计算能力. 在图4（a）中，用DPCT移植得到的SYCL GEMM表现与CUDA GEMM相似，但出现了性能下降，存在进一步优化的空间. 而图4（b）中的SYCL GEMM则远离硬件计算能力的上限，有显著的优化空间.
![]()
图 4 经DPCT移植的朴素未优化GEMM算子的Roofline模型Figure 4. Roofline model of naive unoptimized GEMM operator ported by DPCT本文进一步测量了移植带来的性能下降情况. 图5给出了DPCT移植的SYCL GEMM在NVIDIA RTX 3090与AMD MI100上峰值性能百分比的下降. 在NVIDIA RTX 3090上进行测试时，发现移植后的SYCL GEMM的硬件峰值性能百分比是移植前CUDA GEMM的78.7%；而在AMD MI100上进行测试时，发现移植后的SYCL GEMM能够达到的硬件峰值性能百分比是移植前CUDA GEMM的25.4%. 这说明代码移植后，同样的算法与逻辑以及编程模型与硬件的改变带来了明显的性能问题，高性能的代码从CUDA到SYCL不能保证性能的可移植性.
![]()
图 5 DPCT移植的SYCL GEMM在NVIDIA RTX 3090和AMD MI100上峰值性能百分比的下降Figure 5. Degradation of peak performance percentage of DPCT transplanted SYCL GEMM on NVIDIA RTX 3090 and AMD MI1002. 整体系统设计
当移植得到的程序运行在NVIDIA与AMD的GPU上时，关于如何取得最佳性能存在不同的挑战. 为了解决移植后不同硬件的性能下降问题，本文提出了面向跨异构编程模型SYCL代码移植过程的共性算子优化工具paraTRANS. 其实现思路如图6所示，该工具分别针对移植后SYCL GEMM运行在相同与不同体系结构GPU下的性能瓶颈定位与进一步优化.
第3节针对相同体系结构GPU的SYCL移植后的GEMM算子进行了优化. 第3节定位了SYCL编程模型缺乏对各种优化方法的寄存器占用与程序的SM（streaming multiprocessors）占用率之间的策略平衡. 首先分析了性能瓶颈，然后采取基于变量占用分析的代码化简算法，减少少量寄存器以恢复SM占用率，最终在NVIDIA RTX 3090上取得接近移植前的CUDA GEMM水平.
第4节针对不同体系结构GPU的SYCL移植后GEMM算子进行了优化，并定位了SYCL GEMM在GPU体系结构改变时所引发的高额的访存开销问题. 该节分析了访存开销由scratch memory的大量访问造成，然后通过面向分块参数调优的搜索算法，缩小了线程分块，最终在AMD MI100上取得移植前CUDA GEMM的水平.
3. 针对相同体系结构GPU的SYCL移植后的GEMM算子优化
本节介绍了在相同体系结构GPU下DPCT产生代码的性能瓶颈，以及paraTRANS如何对SYCL GEMM进行优化，最终达到接近移植前的水平.
3.1 移植后SYCL代码对计算资源利用率降低的性能分析
实验测试发现，在同体系结构GPU上，移植后的SYCL GEMM若要获取与移植前同样水平的性能，存在如下挑战：SYCL编程模型缺乏对优化算法的寄存器占用数与warp 占用率的策略平衡. 移植后的SYCL GEMM会因为相比于CUDA的少量寄存器的额外开销，而造成SYCL GEMM的warp 占用率的显著下降. warp占用率下降将会影响程序的SM利用率，从而降低计算资源利用率.
从图4（a）和图5可知，在NVIDIA RTX 3090 上，DPCT移植的SYCL GEMM浮点运算速度相比CUDA GEMM出现下降. 本文测量了一组输入大小不同的GEMM移植前后的性能情况，移植后的浮点运算速度约是移植前的78.7%. 可见直接移植得到的SYCL GEMM性能不佳，存在一定的优化空间.
本节进一步测量了移植前后GEMM在NVIDIA RTX 3090上的SM占用情况. 数据项SM busy表示在一个SM上实际达到的指令吞吐占理论上能够达到的指令吞吐的百分比，因此该项数据越高，在计算任务相同时，SM利用率越高，计算效率越高. 图7给出了移植前的CUDA GEMM与DPCT移植得到的SYCL GEMM的SM busy情况. 从图7中可知，SYCL GEMM能够达到的SM busy平均是CUDA GEMM的74.97%，移植造成了SM利用率的下降.
![]()
图 7 从CUDA到SYCL移植前后GEMM在NVIDIA RTX 3090上SM busy的差异Figure 7. Difference in SM busy of GEMM on NVIDIA RTX 3090 before and after transplantating from CUDA to SYCLSM上能够发射的指令数量受到理论上一个SM能够驻存的线程块数量的影响，该指标通常用warp占用率描述. warp占用率表示一个SM上能够驻留的warp数量占理论最多能够启动warp数量的百分比. 而占用率受到核函数启动配置，如寄存器、共享内存等的影响，SM上有限的资源将会限制线程块启动数量. 本节测量了移植前后GEMM的启动配置，计算了各自的warp占用率. 实验发现：CUDA GEMM每个线程占用128个寄存器，理论warp占用率达到33.3%；SYCL GEMM每个线程占用129个寄存器，理论warp占用率只有16.7%；在移植后因为寄存器占用增加，warp占用率降低了一半.
下面以GEMM大小为M=N=K=5 120时为例，说明寄存器占用增加情况与造成warp占用率降低情况. 在1.2节中已经得知DPCT移植前后GEMM算法不变，但是编程模型对应的关键字改变. 在图8中能够看到SYCL与CUDA代码的后续编译流也存在差异. NVCC（nvidia CUDA compiler）中的CICC部件负责处理CUDA 核函数代码，而DPC++中的不同的LLVM（low level virtual machine） Pass负责处理SYCL 核函数代码. 不同关键字对应的不同函数调用与后续不同的编译流程使得相同算法下的SYCL GEMM与CUDA GEMM生成了不同的PTX指令，从而导致在NVIDIA GPU上最终执行需要的寄存器数目不同. 因此在图8中的①与②尽管源自相同的算法实现，但是最终的寄存器占用数不同. NVCC生成了占用寄存器数目更少的最终指令.
![]()
图 8 SYCL与CUDA的编译差异导致寄存器分配差异与资源空闲Figure 8. Register allocation and resource idle due to SYCL and CUDA compilation differences寄存器是所有驻留在SM的线程共享的有限资源. 当一个线程块驻留在SM上，需要为线程块中的每个线程分配寄存器，因为寄存器有限，所以某一时刻能够驻留在SM上的线程块数量会受到限制. 在图8中，移植得到的SYCL GEMM的每个线程多占用1个寄存器，在1个SM上为1个block分配资源时将会多占用8个寄存器页. 此时1个SM上的寄存器资源允许同时启动的block从2个变为1个，活跃的warp的数量从16个下降到8个，所以warp占用率下降到原来的一半，程序并行性下降进而导致计算资源利用率下降.
3.2 基于变量占用分析的代码简化算法
3.1节分析了寄存器占用增加以及warp占用率下降，进而带来SM利用率下降，导致程序性能下降的问题. 本节针对此问题，给出解决方法. 算法1给出在面临寄存器占用增加造成warp占用率下降时的解决方案.
算法1的行②~⑪给出了算法适用的条件，即满足移植后寄存器数量增加且warp占用率下降时，此算法须进行代码的简化. 行⑫scanVariables函数将会扫描整个核函数中的变量开销，记录变量名与大小到variableMap中. 行⑬将会根据当前的变量开销，选择可能的代码化简方案存储到list变量中. 行⑭~⑯对于生成代码化简方案将会依次进行测试，并将测试的结果记录到res变量中. 在完成测试之后，选择最佳的代码简化方案作为最终的简化算法.
算法1的关键是选择合适的方式简化DPCT移植得到的SYCL代码，从而达到减少寄存器占用的目的，进而提升程序warp占用率，使得程序能够实现更高的SM利用率，以达到更高的性能.
算法1. 基于变量占用分析的代码简化算法.
输入：CUDA源程序src_cu，SYCL源程序src_sycl；
输出：最佳的简化方案result.
① Procedure codeSimplification
② occupancyCuda ← testOccupancy(src_cu)；
③ occupancySycl ← testOccupancy(src_sycl)；
④ if occupancyCuda ≤ occupancySycl then
⑤ break；
⑥ end if
⑦ regCuda ← getRegNum(src_cu)；
⑧ regSycl ← getRegNum(src_sycl)；
⑨ if regCuda ≥ regSycl then
⑩ break；
⑪ end if
⑫ variableMap ← scanVariables(src_sycl)；
⑬ list ← simplificationStrategy(variableMap)；
⑭ for strategy in list do
⑮ res.append(strategy.test())；
⑯ end for
⑰ result ← res.findBest()；
⑱ end procedure
3.3 预取策略与资源利用率的权衡案例分析
3.2节给出了分析变量占用来简化代码以降低寄存器占用的算法，本节给出一个可行的通过放弃预取操作简化代码的案例. 首先，根据算法1首先判断寄存器与warp占用率是否满足适用条件. 图9给出了移植前后CUDA，SYCL的代码寄存器占用与warp占用率，可见满足适用条件：在移植之后，寄存器从128提升到129，warp占用率从33.3%下降到16.7%. 然后算法1会扫描分析DPCT移植后SYCL程序的变量占用情况.
算法最终确定的简化算法是去掉移植后SYCL GEMM的预取. 如图10可见，在去掉预取之后，原本所需要的Av1，Bv1将不再需要即去掉预取之后无需双倍的变量开销从共享内存中预取下一轮计算的数据.
最终图9给出去掉预取之后的SYCL GEMM（图9中paraTRANS寄存器优化）的寄存器占用回落到每线程124个，warp占用率此时已恢复到移植前的CUDA GEMM水平. 需要强调的是，该问题的解决关键是减少寄存器的占用，而非预取对GEMM性能有害. 这里选择去掉预取的方式来减少寄存器占用，是因为更高的warp占用率带来的性能提升超过预取带来的性能提升.
4. 针对不同体系结构GPU的SYCL移植后GEMM算子优化
本节介绍DPCT移植得到的SYCL GEMM在体系结构不同的AMD MI100上的性能瓶颈，以及 paraTRANS 如何减小scratch memory的访存开销，提升移植后SYCL GEMM的性能水平.
4.1 scratch操作导致访存开销的成因分析
我们发现，在不同体系结构GPU上（如AMD GPU），移植后的SYCL GEMM若要获取与移植前同样水平的性能，存在如下挑战：SYCL代码移植过程中，由GPU体系结构改变（由NVIDIA到AMD GPU）所引发的高访存开销. SYCL GEMM运行在AMD MI100上时，源自CUDA GEMM的分块策略会造成严重的scratch memory开销. 这是因为DPC++在AMD MI100上产生了warp占用率更高的代码，但寄存器资源不足，从而占用额外的慢速的scratch memory. 因此体系结构改变之后，原先一个线程的计算负载将不适用新的硬件.
在将 GEMM 移植到 AMD MI100 上之后，因为运行硬件性能不同，无法直接比较移植前后的浮点运算速度以说明运行前后的性能损失. 所以通过式（1）计算GEMM能够达到的硬件峰值性能百分比来衡量移植后的核函数对于硬件的利用率情况.
Ratio=程序达到的FP32性能硬件的FP32峰值性能. (1) CUDA GEMM与SYCL GEMM分别在NVIDIA Geforce RTX 3090和AMD Instinct MI100上进行测试. 移植后程序的最大峰值性能从64.4%下降到16.37%，说明高度优化的CUDA GEMM移植到SYCL GEMM之后运行在其他硬件上的运行性能不佳，存在显著的优化空间.
对于移植之后运行在 AMD MI100 上的 SYCL GEMM，本节通过ROC Profiler来做进一步分析. 首先观察访存计算的时间占比情况. 如图11所示，移植后的SYCL GEMM访存单元时间占比总是最长，而VALU时间占比很短. 因访存而阻塞的时间平均值达到21.32%，在大多数矩阵大小下均长于计算时间.
![]()
图 11 AMD MI100上移植后未优化的SYCL GEMM算子的访存计算的时间占比Figure 11. SYCL GEMM’s time proportion of units on AMD MI100因为CUDA GEMM通过使用共享内存，每个线程块首先读矩阵A，B到快速共享内存，后续对A，B的频繁访问在共享内存中进行. 极大降低了访问A，B的开销. 然后反复读取共享内存，极大降低了访问A，B的开销. 但是移植后却出现了高昂的访存开销，因此考虑移植后核函数是否有其他反常的访存现象. 本节通过ROC Profiler对SYCL GEMM在AMD MI100上进行了测试，发现移植后SYCL GEMM出现了大量的scratch memory的占用.
下面以在MI100上的CUDA GEMM与在3090上的SYCL GEMM为例，介绍scratch memory开销如何造成了严重的访存延迟.
如图12所示，scratch memory 和 global memory 均位于AMD GPU的HBM2上. 对于访问同一规模数据，访问片下HBM2（high bandwidth memory 2）的延迟远高于访问片上的寄存器速度.
![]()
图 12 GPU访存体系结构改变所导致的访存瓶颈Figure 12. The memory bottleneck caused by the change of GPU’s memory architecture在移植前的NVIDIA GPU上，一个线程需要32 b寄存器128个（512 B），CUDA GEMM即需要100%的寄存器文件访问. 而在移植后的AMD GPU上，一个线程需要32 b向量寄存器64个（256 B）、一个scratch memory（180 B）. 在不考虑其他因素时，SYCL GEMM将会进行58.71%的寄存器文件访问和41.28%的scratch memory访问. 由此可见，移植的SYCL GEMM在AMD GPU上增加了大量慢速的scratch访问，进而造成了严重的访存阻塞.
造成该问题的根本原因是硬件体系结构改变之后，DPC++倾向在AMD上启动warp占用率更高的核函数，需要启动更多线程. 移植后SYCL GEMM的warp占用率在AMD GPU上达到40%，而移植前的CUDA GEMM只有33.3%. 更高的warp占用率，需要更多的寄存器资源. 而在AMD Instinct MI100与NVIDA RTX 3090上FP32单元能够访问的寄存器文件均为65 536个32 b寄存器. 此时寄存器资源不变、单个线程计算负载不变时，寄存器资源出现不足，数据需要写入到scratch memory来维持高warp占用率. 因此在不改变编译器的情况下，解决此问题需要大幅度减少单个线程寄存器的占用量.
4.2 面向分块参数调优的搜索算法
4.1节分析了额外的scratch memory开销造成访存阻塞，访存时间占比远高于计算时间，最终导致程序性能下降. 本节针对此问题给出解决方法，算法2为面临此问题时的算法流程描述.
算法2的行②~⑥给出算法适用的条件，即需要满足移植后CUDA程序访问scratch memory的量高于移植前CUDA程序访问local memory的量. 算法2的行⑦对DPCT移植得到的SYCL程序进行模板化，该过程将GEMM的3层分块抽取到模板参数以生成模板文件. 算法2行⑧将根据用户的配置生成期望的参数搜索空间，以确定最佳分块的取值范围. 行⑨将结合生成的参数空间与模板文件搜索性能最佳的分块结果.
算法2的关键是通过调整分块的大小来调整单个线程需要计算的任务，从而避免单个线程计算过多元素而编译器生成高warp占用率程序造成的寄存器资源紧张，需要交换到访问速度更慢的scratch memory的问题.
算法2. 面向分块参数调优的搜索算法.
输入：CUDA程序src_cu，SYCL程序src_sycl；
输出：最佳分块策略result.
① Procedure searchTileSize
② localCuda ← getLocal(src_cuda)；
③ localSycl ← getScratch(src_sycl)；
④ if localCuda ≥ scratchSycl then
⑤ break；
⑥ end if
⑦ templateFile ← genTemplate(dpctSyclFile)；
⑧ searchsSpace ← genSpace(configurations)；
⑨ result←searchBestTileSize(templateFile, searchSpace)；
⑩ end procedure
4.3 通过缩小分块降低scratch操作引发的访存开销案例分析
4.2节给出了针对分块参数进行搜索的算法，本节给出基于对分块参数进行搜索来确定移植后SYCL GEMM新分块的研究案例. 首先，根据算法2判断移植前后scratch memory访问情况. 由图12可知，移植前GEMM不存在local memory的开销，移植后每个线程存在180 B的开销，因此适用于此算法. 为了减少scratch memory的使用，我们选择了更小的分块参数搜索范围，最终确定的分块情况如表1所示.
表 1 减少线程分块大小优化SYCL GEMM代码Table 1. SYCL GEMM Code Optimized by Reducing Thread Tile Size分块配置 Mb Nb Kb Mw Nw Mt Nt 原分块 128 128 8 32 64 8 8 新分块 128 128 16 16 64 4 8 在分块情况改变之后，图13给出了缩小分块后代码层面的改变. 由图13可知，调整分块之后，SYCL GEMM算法未改变，单个线程的计算量减半，启动线程数量加倍. 图14进一步展示与图13对应的更改分块前后的变量开销情况. 当不考虑后续编译优化时，理论上，计算该分块需要从共享内存中的矩阵A块读取Mt×1的子块到寄存器，从共享内存中的矩阵B块读取Nt×1的子块到寄存器. 读取矩阵C对应的Mt×Nt的子块到寄存器，计算的结果需要Mt×Nt的寄存器存储. 最终需要的寄存器数量为Mt+Nt+2×Mt×Nt. 代入前后的Mt与Nt大小，可得到理论上优化后节省了每线程272 B. 因此，优化后因采用更小的线程分块，scratch memory的占用降低到了每线程16 B，并且访存阻塞时间下降显著，从平均 21.32% 下降到了平均 0.39% .
![]()
图 13 减少线程分块大小优化SYCL GEMM代码Figure 13. SYCL GEMM code optimized by reducing thread tile size![]()
图 14 经过优化后的Mt，Nt分块尺寸变化Figure 14. Changes in block size for Mt and Nt after optimization算法2自动优化移植后的分块策略，降低了对硬件寄存器的使用. 因为优化后分块变小，所以变量占用与寄存器开销降低. 最终，scratch memory开销降低，解决了访存阻塞的问题.
5. 实验结果与分析
本节评测了paraTRANS优化后的SYCL GEMM性能. 主要对4个GEMM对象进行评价，分别是：1）CUDA GEMM，即被移植的CUDA GEMM； 2） SYCL GEMM（DPCT），即DPCT移植得到的SYCL GEMM； 3）paraTRANS（寄存器优化），即paraTRANS在相同体系结构GPU（NVIDIA RTX 3090）下对SYCL GEMM进一步优化得到的一种SYCL GEMM实现； 4）paraTRANS（分块参数调优），即paraTRANS在不同体系结构GPU（AMD MI100）下对SYCL GEMM进一步优化得到的一种SYCL GEMM实现.
实验过程中的硬件软件环境如表2所示.
表 2 实验环境Table 2. Experimental Environment软硬件 版本/型号 Ubuntu 20.04.5 LTS Python 3.8 CUDA 11.7 ROCm 5.4.3 Intel/LLVM sycl分支（commit id：ec064e） DPCT 2023.0.0 TVM sycl分支（commit id：6842ca） CPU Intel® Xeon® Silver 4110 CPU @ 2.10 GHz NV GPU NVIDIA Geforce RTX 3090 AMD GPU AMD Instinct MI100 5.1 针对基于SYCL的GEMM算子性能测试
本节分别从不同大小的GEMM移植和不同实现的GEMM移植2个角度来说明GEMM移植前后的性能问题，并且给出了paraTRANS的性能提升情况.
5.1.1 CUDA到SYCL移植后对不同矩阵大小的测试
本实验测试了移植前、移植后以及针对移植得到的程序进一步优化后的GEMM在不同矩阵输入大小下的性能情况. 实验选择的GEMM大小参考了百度的DeepBench[9]基准程序，然后为矩阵分块进行了针对输入大小的手动补齐.
本实验旨在直观给出不同输入下，移植后存在的性能下降情况以及优化后的性能提升情况. 移植后的GEMM分别在NVIDIA与AMD的显卡上进行了测试.
如图15所示，在NVIDIA的GPU测试有2个现象：1）移植后的GEMM普遍出现性能下降；2）通过放弃预取的方式减少寄存器开销和换取warp占用率的方式在54.67%的输入样例中能够发挥作用，而在剩余的输入大小时不能发挥作用. 图16给出了AMD的GPU测试情况，表明优化后的程序相比于移植得到的程序的性能提升. 在AMD Instinct MI100上的加速效果平均能够达到4.49倍.
![]()
图 15 在NVIDIA RTX 3090上移植前后、paraTRANS优化后的GEMM在不同输入大小下的性能情况Figure 15. Performance of DPCT-ported and paraTRANS-optimized GEMM on NVIDIA RTX 3090 for different input sizes![]()
图 16 在AMD Instinct MI100上DPCT移植的与paraTRANS优化的SYCL GEMM在不同输入大小下的性能Figure 16. Performance of DPCT-ported and paraTRANS-optimized SYCL GEMM on AMD Instinct MI100 for different input sizes当移植后的程序运行在NVIDIA RTX 3090上时，因为移植后的程序寄存器的占用增加，导致warp占用率下降，程序性能下降. 而通过简化算法放弃预取，减少寄存器的数量的方法来提高程序warp占用率的方法能够在半数以上的矩阵大小下发挥作用. 当移植的程序运行在AMD MI100上时，移植后的程序在AMD MI100上运行时会带来大量的scratch memory的访问，导致访存延迟时间占比高，程序性能下降. 而通过减小矩阵分块大小，单个线程的计算量减少，能够减少scratch memory的访问，所以优化后的SYCL程序性能得到进一步提升.
移植后的程序在不同硬件下、不同的输入矩阵大小下普遍会存在移植后性能下降的问题. 性能下降的问题能够通过一定的算法、代码的改变进行缓解，达到接近移植前的水平.
5.1.2 对基于不同编译schedule调优策略的算子测试
本实验旨在验证针对相同矩阵大小的GEMM算子，由TVM编译器生成的SYCL代码通过不同编译schedule调优策略后，是否也会出现4.1节和5.1节中所出现的不良寄存器分配和访存拥塞问题. 同时验证paraTRANS对这些问题的优化效果.
本实验基于NVIDIA RTX 3090平台，分别利用TVM的CUDA和SYCL两种编译后端，来生成具有相同GEMM 尺寸（M=N=K=4 096），但具有不同调度实现的核函数代码. 同时通过与paraTRANS的寄存器和分块参数调优优化后的SYCL代码性能进行比较. 实验对大小为M=N=K=4 096的矩阵乘法利用TVM auto-scheduler分别对SYCL和CUDA进行代码调优，且经过2000轮调优后达到性能收敛为止. 实验选取了调优过程中的50个最好的调度配置，记为图17~19的50组GEMM 核函数.
![]()
图 17 TVM生成的CUDA和SYCL算子的整体性能差异Figure 17. Overall performance disparities of CUDA and SYCL operators generated by TVM![]()
图 18 TVM生成的CUDA和SYCL算子的单个线程寄存器占用差异Figure 18. Disparities in register utilization per thread between CUDA and SYCL operators generated by TVM![]()
图 19 TVM生成的CUDA和SYCL算子对local memory访问指令数的差异Figure 19. Disparities in the count of local memory access instructions for CUDA and SYCL operators generated by TVM为进一步追踪基于TVM所生成的SYCL算子的性能下降以及paraTRANS性能提升的原因，本节实验将通过图18和图19分别对各核函数占用的寄存器数量和local load/store指令数进行了进一步测试和分析.
整体实验结果如图17所示，TVM生成的代码中，基于SYCL的GEMM算子性能要低于基于CUDA的GEMM算子. 其中，核函数 ID大于10之后的算子实现性能下降尤其明显. 此外，本实验也验证了本文所提出paraTRANS系统，能够有效提高GEMM算子的计算峰值性能，超过TVM通过自动调优所得到的SYCL算子性能.
虽然TVM所生成的CUDA与SYCL核函数代码两者在算法、共享内存使用、循环结构与计算元素的顺序等多个方面都是相同的. 但是，由图17可知，基于SYCL生成的GEMM 核函数性能要低于基于CUDA的算子实现. 在前10组中，SYCL的性能平均是CUDA的80.74%. 在剩余40组中，SYCL的性能平均只有CUDA的3.41%. 总体性能方面，50组核函数性能均无法超过本文所提出的paraTRANS系统对寄存器和分块参数优化后的GEMM算子性能.
图18和图19给出了不同GEMM 核函数在寄存器和NVIDIA local memory访问上的情况. 其中，在访存层次结构上，NVIDIA local memory与AMD的scratch memory是同等级别的访存资源. 首先，由图19可知，前10组TVM所生成的CUDA代码与SYCL代码均不存在local memory访问. 但是，根据图18可知，前10组中2种编程模型所对应的算子对寄存器的占用量明显上升. 在后40组中，图18显示TVM基于SYCL所产生的核函数代码的寄存器占用量出现了显著的减少. 图19显示SYCL核函数对local memory有了大量的访问操作.
通过对50个TVM生成的核函数实现的分析可知，在不同的核函数实现中，SYCL性能均低于CUDA性能. 而性能下降的原因总结如下：
1）在前10组核函数实验中，SYCL性能小幅度下降是由寄存器占用量增加引起的，导致warp占用率下降和性能下降原理如3.1节所述.
2）在后40组实验中，SYCL性能大幅度下降是因为寄存器占用量降低，导致出现更多次对local memory访存操后出现访存阻塞情况，性能下降原理如4.1节所述.
综上，基于3.2节所提出的基于寄存器分配优化和4.2节所提出的分块参数调优优化， paraTRANS系统能够有效解决以上2点问题，能够有效控制寄存器数量进而提高warp占用率，同时降低local memory访存操作次数，缓解访存阻塞问题.
5.2 对不同大小GEMM的roofline性能测试
本实验直观地给出DPCT移植后SYCL GEMM的优化潜力以及优化后的SYCL GEMM与理论性能上限的距离.
由图4可知，GEMM的理论最大性能受到硬件的计算能力限制. 在本实验中，为了清楚对比图20中计算强度的变化，缩放了坐标轴，图20中未画出硬件的访存瓶颈线.
![]()
图 20 基于Roofline模型对不同大小的GEMM的优化效果Figure 20. Optimization effect of roofline model for multiple GEMM sizes在图20（a）中，DPCT移植后的SYCL GEMM总是在CUDA GEMM的下方，距离硬件的计算能力上限更远. 去掉预取的SYCL GEMM则在低计算强度下处于CUDA GEMM上方，随计算强度不断上升，其浮点运算速度基本与CUDA GEMM重合或略微低于CUDA GEMM.
在图20（b）中，DPCT移植得到的SYCL GEMM距离硬件计算能力上限很远. 而缩小分块后的SYCL GEMM在相同计算强度下取得更高的浮点运算速度，更接近硬件的计算能力上限.
在NVIDIA RTX 3090上时，DPCT移植得到的SYCL GEMM性能下降，远离硬件计算能力上限，优化空间更大. 而去掉预取后达到了与移植前相同的优化水平. 在AMD MI100上时，DPCT移植得到的SYCL GEMM远离硬件计算能力上限，优化空间大. 缩小分块后，SYCL GEMM更加逼近硬件的峰值计算能力.
DPCT移植得到的SYCL GEMM在原NVIDIA RTX 3090上和其他AMD MI100上性能不佳，优化潜力大. 而在各自平台下进行优化后都更加逼近硬件峰值计算能力，达到移植前水平.
5.3 对SM利用率与warp占用率的测试
本实验以输入矩阵大小满足M=N=K时为例，测试GEMM移植后运行在NVIDIA RTX 3090上因为寄存器占用增加而造成warp占用率下降的情况. 具体测试了修改移植后GEMM算法后，程序的warp占用率的提升以及SM利用率的提升. 旨在说明移植后，进一步优化后的GEMM的寄存器、warp占用率、SM利用率的改变.
图21中的3条曲线给出了移植前、移植后、对移植的SYCL GEMM进一步优化后的情况. 移植后的SYCL GEMM性能出现了明显下降，对移植后的SYCL GEMM简化算法之后，SYCL GEMM能够达到移植之前的96.95%. 表3给出了相应的寄存器、warp占用率的变化情况. 可见移植后的SYCL GEMM寄存器数目从128提升到了129，warp占用率相应从33.3%下降到16.7%. 而简化算法后的SYCL GEMM的寄存器从129回落到124，warp占用率相应从16.7%回升到33.3%. 图22则给出了去掉预取后SM busy指标从移植后平均56.58%提升到65.68%.
![]()
图 21 移植后与paraTRANS优化后的GEMM在NVIDIA RTX 3090上一组输入下的性能Figure 21. Performance of ported and paraTRANS-optimized GEMM on NVIDIA RTX 3090 for a set of inputs表 3 寄存器占用和warp占用率Table 3. Register Usage and warp OccupancyGEMM核函数类别 寄存器数/线程 warp 占用率 /% CUDA GEMM 128 33.3 SYCL GEMM（DPCT） 129 16.7 SYCL GEMM（寄存器优化） 124 33.3 ![]()
图 22 GEMM 在 NVIDIA RTX 3090 上 SM busy测试Figure 22. SM busy test of GEMM on NVIDIA RTX 3090移植后，寄存器数目的增加是DPC++与NVCC的不同实现导致的. 而寄存器影响程序warp占用率，进而影响程序的并行执行效率. 所以能够观察到在完成移植之后寄存器数目上升、warp占用率下降、整体的浮点运算速度下降. 使用更少变量和更加简单的算法，会减少寄存器的占用情况. 相应的在对移植后的SYCL GEMM去掉预取之后，寄存器占用下降，warp占用率回到移植前水平，SM busy提升，整体的浮点运算速度也回到接近移植前的水平.
移植后的SYCL程序运行在NVIDIA RTX 3090上时，会因为编译器不同导致移植后程序寄存器占用数目不同，进而影响程序的warp占用率与程序的并行度，最终影响SM利用率. 如果此问题是性能瓶颈，可以考虑简化算法，减少寄存器占用以换取更高的warp占用率与程序的并行度，提高SM利用率.
5.4 对访存、计算时间占比的测试
本实验以输入矩阵大小满足M=N=K时为例，测试GEMM移植后运行在 AMD MI100 上存在的显著的访存问题，以及通过减小分块的方式来提升移植后SYCL GEMM的性能.
图23比较了移植前、移植后、对移植后GEMM更改分块后这3组GEMM在不同输入大小下能够达到的硬件峰值性能情况. 可以观察到，移植后的SYCL GEMM能够达到的峰值性能下降到16.76%，调整分块后的SYCL GEMM峰值性能达到65.11%，与移植前同一水平. 图24给出了优化前后的计算、访存的时间占比情况，在减小分块之后，访存阻塞的时间占比下降，且访存总时间占比下降，计算时间成为主要部分. 进一步分析程序的scratch memory访问量，在减小分块后访问量从每线程180 B下降到每线程16 B.
![]()
图 23 GEMM在NVIDIA RTX 3090和AMD MI100上达到的峰值性能百分比Figure 23. The percentage of peak performance achieved by GEMM on NVIDIA RTX 3090 and AMD MI100![]()
图 24 减少分块后SYCL GEMM 在 AMD MI100的各处理流程的时间占比Figure 24. Time proportion of SYCL GEMM on AMD MI100 in each processing flows after reducing the tiles移植后运行在AMD MI100上的SYCL GEMM访问scratch memory的开销大，而移植前的GEMM则不存在此开销. 原因是DPC++在AMD MI100上编译的程序warp占用率更高，但因为AMD Instinct MI100的寄存器资源有限，所以导致额外的scratch memory开销. 而scratch memory位于off-chip的device memory（HBM2）上，访问速度慢，从而造成了严重的访存等待，移植后的SYCL GEMM性能不高. 在减小分块之后，单个线程量任务减少，寄存器占用减少，scratch memory访问大幅降低，程序性能得到显著提升.
移植后的SYCL程序运行在AMD MI100上时，因为编译器的优化策略不同，引入大量的scratch memory访问，从而影响程序的性能. 若此问题是移植后程序的性能瓶颈，可以考虑减少单个线程的计算量以及减少寄存器占用，从而减少scratch memory的访问.
6. 相关工作
SYCL 相比于 CUDA 来说，是更新的编程模型，许多特性依然值得探讨，性能表现依然需要验证. 最近几年，伴随着 Intel DPC++ 版本的发布更新，许多文章分析了 SYCL 的性能表现. 在文献[10]中，研究了Rodinia benchmark 从CUDA移植到SYCL的过程. 该文发现 DPCT 能够将 87% 的 CUDA 代码自动翻译. 然后研究了NVIDIA GPU和Intel CPU的性能情况，发现访存操作与原生代码相近，但是存在一些算子出现了指令、访存、硬件利用率等方面的性能问题. 文献[11]研究了将 epistasis detection 算法从 CUDA移植到 SYCL 的过程，通过移植后的手动调优，实现了在 NVIDIA GPU 上能够取得与 CUDA性能相近的表现. 文献[12]将一份针对 NVIDIA GPU 编写的stencil代码，从CUDA 移植到了SYCL，达到了 75% 的性能移植表现. 文献[13]研究了分子动力学模拟软件 LAMMPS 在不同的 GPU 平台上的性能移植情况，提供了通过roofline模型来研究软件在不同架构下的 GPU 平台下的加速情况. 文献[14]将Bioinformatics应用从CUDA 移植到SYCL 上，从软件的调用接口和PTX代码生成的角度分析了移植后的SYCL代码，解释了在NVIDIA GPU上存在性能问题的原因. 文献[15-18]也介绍了SYCL应用在不同的GPU上的性能情况. 文献[19-20]也介绍了SYCL代码的可移植性问题，并且在调研过程中发现，编译器的优化欠佳导致移植的程序性能不佳不是孤例. 文献[21]发现GTC-P程序在移植到OpenACC时，会因为编译器带来性能瓶颈，需要额外的优化. 总结来说，伴随 SYCL的逐渐发展，评测分析SYCL的性能情况以及研究SYCL的编译器实现是SYCL被更多人接受的关键.
以上工作研究了不同的应用从CUDA到SYCL的移植，分析其在NVIDIA GPU上的运行效果. 而本文讨论了CUDA GEMM的移植，并且从移植后的程序的寄存器、访存的角度分析了在NVIDIA GPU和AMD GPU上不同的性能表现. 研究了典型应用在跨编程模型和跨硬件平台上的性能变化情况.
7. 总 结
本文介绍了一个面向跨异构编程模型SYCL代码移植过程的共性算子优化工具paraTRANS以及将一个高性能的CUDA GEMM移植到SYCL的过程，并评价了移植后的性能表现. 而paraTRANS定位了体系结构在相同与不同的GPU上性能下降的原因，进行了针对不同平台的优化.
移植得到的SYCL GEMM运行在体系结构相同的NVIDIA RTX 3090上时，paraTRANS 分析了性能瓶颈，解决了SYCL GEMM各优化方法对寄存器资源的占用与SM占用率之间的策略平衡，提出了基于变量占用分析的代码简化算法，选择通过预取换取warp占用率的方式，最终在NVIDIA RTX 3090上得到接近移植前性能水平的SYCL GEMM.
移植得到的SYCL GEMM运行在体系结构不同的AMD MI100上时，paraTRANS 定位了性能瓶颈，解决了SYCL GEMM在体系结构改变时（NVIDIA到AMD）存在的显著访存阻塞的挑战，并通过面向参数调优的搜索算法，选择通过缩小线程分块的方式，最终在AMD MI100上得到达到移植前性能水平的SYCL GEMM.
而本文的研究对象相对单一，paraTRANS当前也局限在GEMM移植优化的问题上. 在未来的工作中，我们将会尝试对更多的对象做移植，检查它们移植前后的性能情况，提供更加普适的问题解决算法. 并且本文涉及的硬件也只覆盖了NVIDIA与AMD这2款GPU，而在Intel的GPU、海光DCU、FPGA等硬件上的性能如何依然未知. 在未来的工作中会在更多的实验平台上讨论其性能可移植的问题.
作者贡献声明：马兆佳与邵恩共同提出了算法思路实验方案并撰写论文；马兆佳完成实验；狄战元、马立贤提出建议与技术指导并修改论文.
-
![]()
图 2 基于CUDA编程模型的原生GEMM算子实例代码
Figure 2. Native GEMM operator example code based on CUDA programming model
![]()
图 3 经DPCT移植的朴素未优化的SYCL GEMM代码
Figure 3. Naive unoptimized SYCL GEMM code ported by DPCT
![]()
图 4 经DPCT移植的朴素未优化GEMM算子的Roofline模型
Figure 4. Roofline model of naive unoptimized GEMM operator ported by DPCT
![]()
图 5 DPCT移植的SYCL GEMM在NVIDIA RTX 3090和AMD MI100上峰值性能百分比的下降
Figure 5. Degradation of peak performance percentage of DPCT transplanted SYCL GEMM on NVIDIA RTX 3090 and AMD MI100
![]()
图 7 从CUDA到SYCL移植前后GEMM在NVIDIA RTX 3090上SM busy的差异
Figure 7. Difference in SM busy of GEMM on NVIDIA RTX 3090 before and after transplantating from CUDA to SYCL
![]()
图 8 SYCL与CUDA的编译差异导致寄存器分配差异与资源空闲
Figure 8. Register allocation and resource idle due to SYCL and CUDA compilation differences
![]()
图 11 AMD MI100上移植后未优化的SYCL GEMM算子的访存计算的时间占比
Figure 11. SYCL GEMM’s time proportion of units on AMD MI100
![]()
图 12 GPU访存体系结构改变所导致的访存瓶颈
Figure 12. The memory bottleneck caused by the change of GPU’s memory architecture
![]()
图 13 减少线程分块大小优化SYCL GEMM代码
Figure 13. SYCL GEMM code optimized by reducing thread tile size
![]()
图 14 经过优化后的Mt，Nt分块尺寸变化
Figure 14. Changes in block size for Mt and Nt after optimization
![]()
图 15 在NVIDIA RTX 3090上移植前后、paraTRANS优化后的GEMM在不同输入大小下的性能情况
Figure 15. Performance of DPCT-ported and paraTRANS-optimized GEMM on NVIDIA RTX 3090 for different input sizes
![]()
图 16 在AMD Instinct MI100上DPCT移植的与paraTRANS优化的SYCL GEMM在不同输入大小下的性能
Figure 16. Performance of DPCT-ported and paraTRANS-optimized SYCL GEMM on AMD Instinct MI100 for different input sizes
![]()
图 17 TVM生成的CUDA和SYCL算子的整体性能差异
Figure 17. Overall performance disparities of CUDA and SYCL operators generated by TVM
![]()
图 18 TVM生成的CUDA和SYCL算子的单个线程寄存器占用差异
Figure 18. Disparities in register utilization per thread between CUDA and SYCL operators generated by TVM
![]()
图 19 TVM生成的CUDA和SYCL算子对local memory访问指令数的差异
Figure 19. Disparities in the count of local memory access instructions for CUDA and SYCL operators generated by TVM
![]()
图 20 基于Roofline模型对不同大小的GEMM的优化效果
Figure 20. Optimization effect of roofline model for multiple GEMM sizes
![]()
图 21 移植后与paraTRANS优化后的GEMM在NVIDIA RTX 3090上一组输入下的性能
Figure 21. Performance of ported and paraTRANS-optimized GEMM on NVIDIA RTX 3090 for a set of inputs
![]()
图 22 GEMM 在 NVIDIA RTX 3090 上 SM busy测试
Figure 22. SM busy test of GEMM on NVIDIA RTX 3090
![]()
图 23 GEMM在NVIDIA RTX 3090和AMD MI100上达到的峰值性能百分比
Figure 23. The percentage of peak performance achieved by GEMM on NVIDIA RTX 3090 and AMD MI100
![]()
图 24 减少分块后SYCL GEMM 在 AMD MI100的各处理流程的时间占比
Figure 24. Time proportion of SYCL GEMM on AMD MI100 in each processing flows after reducing the tiles
表 1 减少线程分块大小优化SYCL GEMM代码
Table 1 SYCL GEMM Code Optimized by Reducing Thread Tile Size
分块配置 Mb Nb Kb Mw Nw Mt Nt 原分块 128 128 8 32 64 8 8 新分块 128 128 16 16 64 4 8 
下载: 导出CSV
表 2 实验环境
Table 2 Experimental Environment
软硬件 版本/型号 Ubuntu 20.04.5 LTS Python 3.8 CUDA 11.7 ROCm 5.4.3 Intel/LLVM sycl分支（commit id：ec064e） DPCT 2023.0.0 TVM sycl分支（commit id：6842ca） CPU Intel® Xeon® Silver 4110 CPU @ 2.10 GHz NV GPU NVIDIA Geforce RTX 3090 AMD GPU AMD Instinct MI100
下载: 导出CSV
表 3 寄存器占用和warp占用率
Table 3 Register Usage and warp Occupancy
GEMM核函数类别 寄存器数/线程 warp 占用率 /% CUDA GEMM 128 33.3 SYCL GEMM（DPCT） 129 16.7 SYCL GEMM（寄存器优化） 124 33.3
下载: 导出CSV
-
[1] Schneider D. The exascale era is upon us: The frontier supercomputer may be the first to reach 1, 000, 000, 000, 000, 000, 000 operations per second[J]. IEEE Spectrum, 2022, 59(1): 34−35 doi: 10.1109/MSPEC.2022.9676353
[2] Brodtkorb A R, Dyken C, Hagen T R, et al. State-of-the-art in heterogeneous computing[J]. Scientific Programming, 2010, 18(1): 1−33 doi: 10.1155/2010/540159
[3] Munshi A. The openCL specification[C/OL]//Proc of the 21st IEEE Hot Chips Symp (HCS). Piscataway, NJ: IEEE, 2009[2023-04-19]. http://ieeexplore.ieee.org/document/7478342
[4] Heroux M A, McInnes L C, Thakur R, et al. ECP software technology capability assessment report[R/OL]. 2020[2023-04-23]. https://doi.org/10.2172/1760096
[5] Intel. Intel/LLVM: Intel staging area for llvm. org contribution[CP/OL]. (2023-04-19)[2023-04-19]. https://github.com/intel/llvm
[6] AMD ROCm Software. HIPIFY[CP/OL]. (2023-06-26)[2023-06-27]. https://github. com/ROCm-Developer-Tools/HIPIFY
[7] Intel. Migrate CUDA* to DPC++ code: Intel DPC++ compatibility tool [EB/OL]. [2023-07-07]. https://www.intel.com/content/www/us/en/developer/tools/oneapi/dpc-compatibility-tool.html
[8] Zhai Yujia. How to optimize SGEMM on NVIDIA GPUs[CP/OL]. (2023-04-19)[2023-04-21]. https://github.com/yzhaiustc/Optimizing-SGEMM-on-NVIDIA-Turing-GPUs
[9] Baidu Research. DeepBench[CP/OL]. (2023-06-28)[2023-07-04]. https: //github. com/baidu-research/DeepBench
[10] Castaño G, Faqir-Rhazoui Y, García C, et al. Evaluation of Intel’s DPC++ compatibility tool in heterogeneous computing[J]. Journal of Parallel and Distributed Computing, 2022, 165: 120−129 doi: 10.1016/j.jpdc.2022.03.017
[11] Jin Zheming, Vetter J S. Performance portability study of epistasis detection using SYCL on NVIDIA GPU[C/OL]//Proc of the 13th ACM Int Conf on Bioinformatics, Computational Biology and Health Informatics. New York: ACM, 2022[2023-04-23]. https://dl.acm.org/doi/10.1145/3535508.3545591
[12] Christgau S, Steinke T. Porting a legacy cuda stencil code to oneapi[C]//Proc of the 34th IEEE Int Parallel and Distributed Processing Symp Workshops (IPDPSW). Piscataway, NJ: IEEE, 2020: 359−367
[13] Hagerty N, Vergara V G M, Tharrington A. Studying performance portability of lammps across diverse gpu-based platforms[R/OL]. 2022[2023-04-23]. https://doi.org/10.1002/cpe.7895
[14] Jin Zheming, Vetter J S. Understanding performance portability of Bioinformatics applications in SYCL on an NVIDIA GPU[C]//Proc of the 16th IEEE Int Conf on Bioinformatics and Biomedicine (BIBM). Piscataway, NJ: IEEE, 2022: 2190−2195
[15] Deakin T, McIntosh-Smith S. Evaluating the performance of HPC-style SYCL applications[C/OL]//Proc of the 8th Int Workshop on OpenCL. New York: ACM, 2020[2023-04-19]. https://dl.acm.org/doi/10.1145/3388333.3388643
[16] Jin Zheming, Vetter J S. Evaluating nonuniform reduction in HIP and SYCL on GPUs[C]//Proc of the 8th Int Workshop on Data Analysis and Reduction for Big Scientific Data (DRBSD). Piscataway, NJ: IEEE, 2022: 37−43
[17] Volokitin V, Bashinov A, Efimenko E, et al. High performance implementation of Boris particle pusher on DPC++. A first look at oneAPI[C]//Proc of the 14th Int Conf on Parallel Computing Technologies. Berlin: Springer, 2021: 288−300
[18] Costanzo M, Rucci E, Sánchez C G, et al. Assessing opportunities of SYCL and Intel oneAPI for biological sequence alignment[J]. arXiv preprint, arXiv: 2211.10769, 2022
[19] Da Silva H C, Pisani F, Borin E. A comparative study of SYCL, OpenCL, and OpenMP[C]//Proc of the 2016 Int Symp on Computer Architecture and High Performance Computing Workshops (SBAC-PADW). Piscataway, NJ: IEEE, 2016: 61−66
[20] Tsai Y M, Cojean T, Anzt H. Porting sparse linear algebra to Intel GPUs[C]//Proc of the 27th European Conf on Parallel Processing. Berlin: Springer, 2021: 57−68
[21] 王一超,林新华,蔡林金,等. 太湖之光上利用OpenACC移植和优化GTC-P[J]. 计算机研究与发展,2018,55(4):875−884 doi: 10.7544/issn1000-1239.2018.20160871 Wang Yichao, Lin Xinhua, Cai Linjin, et al. Porting and optimizing GTC-P on TaihuLight supercomputer with OpenACC[J]. Journal of Computer Research and Development, 2018, 55(4): 875−884 (in Chinese) doi: 10.7544/issn1000-1239.2018.20160871
计量
- 文章访问数: 97
- HTML全文浏览量: 16
- PDF下载量: 33
