作为一个框架，MadGraph旨在建立一个完整的标准模型和超越标准模型的现象学，包括横截面计算以及事件操作和分析等元素。
作为正在进行的极光早期科学计划 （ESP） 项目的一部分，该项目旨在为 CERN 的大型强子对撞机 （LHC） 为百万兆次级计算时代准备 ATLAS 实验——由沃尔特·霍普金斯 （Walter Hopkins） 领导的“百万兆次级 ATLAS 探测器中的模拟和学习”——研究人员正在移植和优化代码，使实验能够在一系列下一代架构上运行其模拟和数据分析任务。
其中包括即将推出的英特尔-HPE Aurora 系统，该系统位于阿贡国家实验室的美国能源部 （DOE） 科学办公室用户设施 Argonne Leadership Computer Facility （ALCF）。
MadGraph是一种用于大型强子对撞机实验的粒子相互作用模拟器，它执行粒子物理计算以生成预期的大型强子对撞机探测器粒子相互作用。作为一个框架，MadGraph旨在建立一个完整的标准模型和超越标准模型的现象学，包括横截面计算以及事件操作和分析等元素。
ALCF的博士后Nathan Nichols加入了ATLAS ESP项目，在MadGraph代码的背景下研究性能可移植性框架，使ATLAS等实验能够使用现代超级计算机来满足其大型计算需求。
定义 MadGraph 的性能可移植性
Nichols说：“对我而言，便携性和高性能意味着应用程序需要能够在尽可能多的设备上高效运行，无论供应商如何，无论是NVIDIA、Intel还是AMD。“如果一个应用程序在英特尔 GPU 上运行得非常好，但在 NVIDIA GPU 上运行时出现问题，那么它就不是真正的性能可移植性。作为开发人员，您还希望代码易于维护，因此您不希望将不同的代码块拼凑成代码库，而是希望编写一个代码并让该代码在所有不同的设备上都能正常运行。
由于MadGraph最初是在十多年前开发的，它有一个遗留的代码库，使用户能够在大型强子对撞机上模拟大多数感兴趣的物理过程，因此实现可移植性并不像传统的独立或科学应用所期望的那样简单。
“该应用程序包含 Python 脚本，这些脚本编写 Fortran 代码以生成当时在 CERN 运行的任何物理实验的模拟;它非常通用，可以即时编写代码 - 可能是每个物理过程的一组新源代码，具体取决于实验，“Nichols说。“高性能地移植应用程序，或者编写一个高性能的GPU内核可能具有挑战性，因为内核可以是任何类型的粒子配置，我们需要能够有效地生成和运行在设备上，无论物理学家可能想要探索什么物理过程。这有点令人生畏。
确定要采用的可移植性框架
当 Nichols 加入该项目时，该团队已经决定测试三个可移植性框架，即 SYCL、Kokkos 和 alpaka。他将带头开发 SYCL 版本。
选取了五个具有代表性的物理过程作为标准案例来测试代码性能。当需要认真研究 MadGraph 的 SYCL 移植时，Nichols 的第一步是检查原生 CUDA 代码，以确定可以提高性能的领域。
他解释说：“在编写完所有内容并且我们有了适用于不同可移植性框架的软件工作版本之后，我们需要缩小选择范围，以确定将来支持哪个版本最有意义。
Nichols 领导了 Argonne 的工作，以衡量和比较框架在多个架构中的性能。
Nichols 使用 GitLab 建立了持续集成软件管道，以便对阿贡系统评估联合实验室 （JLSE） 托管的各种设备进行定期性能测试。运行这些夜间性能测试的系统包括 Nvidia GPU（V100 和 A100）、Intel GPU（Aurora 的早期版本）、Intel CPU（Skylake）和 AMD GPU（MI50、MI100、MI250）。
JLSE系统提供的测试设置使得根据所评估的五个不同物理过程来判断性能的框架变得简单明了：Nichols将从计算简单的物理过程开始，然后逐步提高计算难度。在整个测试过程中，Nichols 会对软件堆栈进行细微的更改，以评估性能受到的影响。
他进行了性能扩展，以了解哪个可移植性框架在不同的 GPU 上提供了最佳性能。性能甚至超过了原生 CUDA 和 CPU 代码，最终确定 SYCL 移植在所有测试系统中性能最高，Kokkos 紧随其后。鉴于这些指标，ATLAS团队选择继续使用SYCL，并停止使用其他可移植性框架进行开发。
选择 SYCL 端口后，Nichols 更新了 MadGraph 框架中基于 Python 的代码生成器，以选择性地输出 SYCL 矩阵元素计算。最初，这只为用户指定的物理过程生成了基于 Fortran 的矩阵元素代码。
当Nichols在SYCL移植上工作时，CERN团队开发了一个代码混合桥，以促进Fortran代码调用正在测试的多个C++可移植性库中的函数。
“我们需要 SYCL 库和 Fortran 代码来相互通信，”Nichols 说。“但是，由于使用不同的编程语言，我们无法让 SYCL 库和 Fortran 代码正确链接，这是我们发现的众多错误中的第一个。幸运的是，我的团队一直在与英特尔的联系人密切合作，现在所有这些错误都得到了解决，我们应该能够消除它们。
处理高寄存器压力
其中一些错误源于 MadGraph 代码在寄存器压力下存在的问题。寄存器文件是可以存储不同对象的空间分配，对 GPU 性能有重大影响。粗略地说，寄存器压力是指寄存器文件接近其最大容量时的术语。
“一旦注册表已满，内部的对象必须转移到不同的内存位置，这需要时间，然后清空的注册表开始填充新项目，”Nichols说。“现在，我正在运行的应用程序不仅要从普通的寄存器文件中调用项目，还要从整个系统的全局内存中调用项目。
除了纠正寄存器压力触发的传输导致的性能下降外，MadGraph团队还必须调试代码，以便利用可用的性能分析工具，这些工具本身需要保留寄存器文件。
“由于我们遇到了这些寄存器溢出，性能工具无法自行保留该空间，因此我们无法真正深入地分析我们的代码正在做什么。这反过来意味着我们必须依靠先前编程经验提供的有根据的猜测，“Nichols说。
在 Aurora 上部署
与迄今为止其他版本的应用程序相比，MadGraph 的 SYCL 端口在 Intel GPU 上表现出卓越的性能。
在整个Aurora测试和开发系统Sunspot（有128个可用节点）上运行SYCL端口后，Nichols和ATLAS团队开始调整MadGraph生成的文件的I/O和通信，以确保在Aurora上大规模部署时具有高效的功能。
MadGraph 能够通过线性缩放将单个进程单独委托给每个 GPU，是一个令人尴尬的并行应用程序。
“由于MadGraph是令人尴尬的并行，因此就Aurora部署而言，扩展并不是一个问题，”Nichols指出。
另一方面，随着整个Aurora系统上线，ATLAS团队必须衡量当前为代码开发的工作流程在百万兆次级计算机的大量计算节点上是否有效。
Nichols 还开发了一个自定义数学函数库，允许在不破坏 MadGraph 代码的情况下将原始数据类型与 SYCL 向量类型交换。
“SYCL向量类型允许代码利用CPU上可用的向量指令集，从而在这些设备上提高性能，”他说。“以这种临时方式使用 SYCL 向量类型与推荐的方法形成鲜明对比，后者依赖于自动矢量化并使用函数扩展。然而，对于像 MadGraph 这样的大型遗留代码库，传统方法通常不足以获得所需的性能。他补充说，该库仍然需要进一步修订，因为虽然与 SYCL 矢量类型一起使用可以在 CPU 上提供强大的性能，但在 GPU 上，它的性能会大大降低，并且其编译时间会大大增加。
Nichols 打算通过对代码进行系统测试来改进库，并与其他开发人员协商以收集各种观点。
这种合作在将 MadGraph 引入百万兆次级和为未来用户调整 Aurora 方面发挥了重要作用;特别是与英特尔卓越中心员工的定期研讨会，帮助提出了提高 MadGraph 代码性能的想法，并指出了编译器的改进。一般来说，ESP 项目是解决复杂、大规模 HPC 系统推出所固有问题的重要工具。
SYCL可移植性框架允许开发者使用不同的方法启动并行内核（即在GPU上启动运行代码的方法），这导致了对涉及基础数据并行内核、工作组数据并行内核和分层数据并行内核的不同内核启动方法的实验和比较;分层数据并行内核被发现表现最好。
Nichols提到：“SYCL规范的相关部分最近一直在修订中，所以我一直有兴趣帮助完成这一过程，为此我开发了一些不同的测试应用程序。“仅仅测试 SYCL 规范下可用的各种选项是确定如何提高性能的最佳方式。”
Argonne ATLAS 团队探索将整个软件管道的不同部分卸载到 GPU，但 Nichols 发现几乎所有的性能瓶颈都可以归因于矩阵元素计算。通过 GPU 卸载，这些计算被加速到一定程度，以至于本地化为 CPU 操作的代码元素受到轻微的负面影响。（卸载受影响元素所需的工作量超过了这样做可以获得的任何性能提升。
Nichols 目前正在为 MadGraph 版本而努力，这需要完成文档、测试并确保所有物理过程正常运行，并磨练 SYCL 移植，以确保代码维护对用户来说尽可能简单明了。这些努力旨在通过最终部署SYCL端口，将ATLAS项目扩展到Aurora。
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
