面向E级高性能计算的软件栈（一）

最新推荐文章于 2024-04-24 10:36:50 发布

h_m_l

最新推荐文章于 2024-04-24 10:36:50 发布

阅读量1.2k

点赞数 2

分类专栏： HPC&AI 文章标签： Slurm PMIx UCX Exascale

原文链接：https://www.sciencedirect.com/science/article/pii/S0167819118302424?via%3Dihub

版权

HPC&AI 专栏收录该内容

6 篇文章 2 订阅

订阅专栏

1. 介绍

尽管处理器频率停滞不前，但维持可控的功率预算的需求，对生产更强大超级计算机的动力构成了挑战。高性能计算(HPC)系统随后采用了基于稳定增长的计算单元的多级、大规模并行计算。因此，在可靠性和功率约束下实现百亿亿次性能所需要的十亿个并行方式有望在50-100k节点中实现，这将推动未来的节点架构朝着多核和基于加速器的设计方向发展，从而按agnitude的顺序增加每个节点的复杂性。同时，成本方面的考虑也会导致每核可用内存的相应减少。

与硬件领域的发展类似，编程模型也正在经历重大的变化，因为它们努力实现百亿亿次的性能。新模型继续以快速的速度出现，经常在系统管理堆栈(SMS)上添加独特的需求。在其核心,模型都采用通信库表达必要的数据移动和应用程序进程之间的同步(典型如MPI,也有PGAS语言和库如UPC , OpenSHMEM和其他),需要在初始化期间wireup支持。此外，共存的编程模型越来越需要与SMS协调它们的操作，以实现最佳性能和期望的行为。

大规模HPC应用程序的部署和管理在历史上一直被各种可以部署和监视并行应用程序执行的竞争系统和方法所破坏。供应商和MPI实现者各自开发了一个复杂的解决方案生态系统来提供这些服务，这些服务包括各种SMS组件和编程库运行时。这些解决方案各有优点(性能、可移植性、独特的特性)，但它们接口的不兼容性增加了相关软件设计的开销，并使应用程序和工作流编制工具难以直接使用SMS。

进程管理接口(Process Management Interface，PMI)最初作为MPICH的一部分开发和分发，历史上一直被用作交换进程间通信和部署进程所需的有线信息的手段。到目前为止，已经发布了两个版本(PMI-1和PMI-2)，其中PMI-2的缩放性能明显优于其前身PMI-1。然而，要应对exascale系统提出的重大编排挑战，需要发展process-to-SMS接口，以允许并行应用程序的不同组件与现有和未来的SMS解决方案之间更紧密的集成。

PMI Exascale(PMIx)通过提供专门为支持exascale和超越环境而设计的PMI定义的扩展版本来满足这些需求:

为现有应用程序编程接口(API)中表示的功能添加灵活性。社区选择要求每个标准API的定义都包括传递键值“属性”对的数组。这些提供了一种在未来需求出现时定制API行为的方法，而不必更改或创建新的变体。此外，属性提供了一种机制，通过该机制，研究人员可以轻松地探索给定操作的新方法，而不必修改API本身;
使用提供扩展功能的新API来增强接口。该社区确定了几个关键领域，包括异步事件通知以及动态资源分配和管理。特别关注为研究人员提供适当的“hooks”，允许研究领域中的替代方法，例如应用程序和存储系统之间的交互；
在SMS子系统提供商之间建立协作，包括资源管理器、fabric、文件系统和编程库开发人员。PMIx可伸缩性的基础在于聚合来自这些源的信息，以集成启动过程并启用工作流编排。这需要定义各个子系统之间的集成点，以及就相关API、属性名称和数据类型的定义达成一致。成功的关键是采用了“right to not support”政策，授予所有实施者(PMIx库和主机环境)决定不支持给定特性的权利；
建立一个类似标准的机构来维护定义。他们仔细考虑了将PMIx置于各种现有标准机构的支持下，同时要求PMIx本身不受编程模型的限制，不直接隶属于任何特定的编程组或软件包。最终,委员会决定成立一个独立的PMIx标准程序，以满足社区的需要;并且提供PMIx标准的参考实现，该实现演示了所需的可伸缩性级别，同时保持它与标准本身的严格分离。

PMIx的工作并不针对特定的编程模型或实现，而是侧重于提供定义良好的接口，以不依赖于编程模型的方式抽象管理大规模应用程序部署和监控所需的公共特性。这是通过一个涉及多方社区的过程完成的，该社区包括供应商、编程库实现者和性能、监视和调试工具的提供者。