百亿亿次级系统进程管理接口综述

张 昆，张 伟，卢 凯，董 勇，戴屹钦

(国防科技大学计算机学院，湖南 长沙 410073)

1 引言

目前，高性能计算HPC(High Performance Computing)系统性能已经进入百亿亿次时代，各国都向着实现百亿亿次计算性能目标不断行进，为提高经济竞争力、推进工业生产、改善人类社会生活创造更多切实效益。

进程管理是高性能计算的一个组成部分，在结点数量较少的计算系统中，进程管理的可扩展性对应用程序运行没有太大影响。但是，随着系统规模扩大，传统进程管理已经不能满足海量处理器核的需求，迫切需要一种可扩展的管理方式，且可以提供进程交换信息的机制。为了解决该问题，在进程管理中引入进程管理接口PMI(Process Management Interface)，用于在启动阶段部署进程的通信方法。引入后的进程管理包括3个部分[2]：并行编程库(例如MPI库)、PMI库和进程管理器。进程管理器是一个逻辑上的中心进程，用于管理进程启动与进程间信息传递。PMI库通过API接口提供进程交换信息机制。并行编程库可以通过PMI API来访问进程管理器提供的启动进程、初始化进程等各类功能。

IBM发布的报告[1]指出，实现百亿亿次级计算系统有5大瓶颈，其中一项就是通信瓶颈。为了突破这一瓶颈，在进程之间快速建立通信机制成为一项重要的研究课题。百亿亿次系统内包含数万结点与近千万处理器核，以往PMI建立通信的方法无法满足进程快速启动的要求，大规模并行应用的启动时间过长，成为限制系统运行效率、降低系统易用性的一个重要因素。

为了解决百亿亿次级系统的启动问题，进程管理接口发展出PMIx(Process Management Interface-Exascale)的版本，以实现在30 s内启动和连接大规模应用程序进程的总体目标[3]。PMIx定义了新的并行应用程序启动顺序，并针对大规模应用程序提出新的建立通信机制，力求缩短启动时间，提高系统性能。

本文主要探讨百亿亿次级计算性能目标下，进程管理接口启动大规模并行应用程序的有效性，对比PMI-1、PMI-2和PMIx的工作机制与特点，分析PMIx对于作业快速启动、系统高效运行的重要作用，以及在提升性能上做出的优化，并讨论未来的发展方向。

本文第2节介绍进程管理接口的发展过程和大规模并行应用程序启动过程，分析进程管理对于提高系统运行效率的重要意义；第3节分别介绍传统的并行应用程序启动顺序和PMIx模式下的并行应用程序启动顺序，对比分析PMIx在改进启动过程中所发挥的作用；第4节介绍为了提高系统性能，目前对PMIx所做的优化研究；第5节从启动并行应用程序期间和运行时控制2个方面对未来PMIx的发展方向进行了说明。

2 背景

2.1 进程管理接口介绍

在现代高性能计算系统中，一个并行计算任务包含多个并行作业，每一个并行作业又包含一个或多个并行应用程序，而每一个应用程序则是一组二进制可执行文件的实例化。在系统中启动一个并行应用程序主要包含以下几步[4]：

(1)部署运行时环境。

该阶段是在分配有作业的计算结点集上部署分布式的运行时环境RTE(Running Time Environment)。目前在大多数软件堆栈中，该阶段通常在分配的每一个计算结点上都创建一个RTE实例，用于后续生成和管理进程。

(2)启动应用程序进程。

在分配有作业的计算结点上，RTE实例生成相应进程，并执行进程启动。

(3)获取预定义环境信息。

在此阶段，RTE将自身已知的作业级信息提供给应用程序进程，如进程的rank信息、进程总数信息、共享同一计算结点的进程列表等。

(4)获取动态环境信息。

在该阶段，进程需要交换彼此特定于应用程序的数据信息。这些是不包含在阶段(3)中但进程必须知道的信息，例如通信寻址信息，通过定义的全局操作，进程获得此类信息。

目前，大多数的高性能计算软件堆栈都采用进程管理接口来完成阶段(3)与阶段(4)的工作。并行应用程序进程通过PMI定义的API与RTE通信。PMI将信息组织成键值数据库的形式，通过Put、Get和同步原语访问数据库。

在并行应用程序启动过程中，最耗时的阶段为阶段(4)。当面对百亿亿次级系统时，进程数目庞大，所有进程彼此之间交换信息会花费大量时间，这对于实现快速启动应用程序的目标十分不利。而PMIx则集中解决此阶段问题，力求寻找获取动态信息的新方法，尽可能将阶段(4)中所需信息转移到阶段(3)中。通过减少进程交换信息操作的时间消耗，即使进程规模庞大，PMIx也可以达到快速启动应用程序的目标，促进系统高效运行。

2.2 进程管理接口发展过程

随着“异构MPI”项目的研究，各国致力于开发可应用于多台不同类型计算机上的MPI，这就需要MPI程序能够处理异构的通信协议、安全性机制和调度程序等[5]，这激发工作人员研究一类定义在MPI中使用的通用API，用来执行各类进程管理系统中的启动、监视和控制进程的功能[6]。

第1代PMI(PMI-1)被广泛应用在MPICH2[7]及其派生的MPI实现中[8]，其最初设计目标是利用一个接口减少进程管理器与MPI实现之间的耦合。PMI-1主要包含2个部分，一部分旨在协助MPI初始化过程中的引导活动，另一部分旨在支持MPI中的动态进程管理功能。PMI-1设计人员使进程管理器只提供MPI进程交换信息的通用机制。该机制由一个键值存储KVS(Key-Value Store)组成。经过适当的同步操作，一个进程放入KVS的内容可以由另一个进程读出。在PMI-1中，一个简单的集体屏障功能保证了该类同步。一旦所有进程经过屏障操作，则认为所有数据都已写入；并且一旦经过屏障操作释放进程，进程就可以读取所有数据。

但是，将PMI-1应用于现代高性能计算系统上时，却暴露出PMI-1的局限性。虽然在PMI-1中有一个键值数据库用于存取，但进程管理器无法向数据库中添加系统信息，导致MPI进程不能从进程管理器中查询此类信息。另外，PMI-1不能保证线程安全，在给定的PMI连接上，同时只能执行一个请求。并且，PMI-1中缺乏故障处理机制，无法在进程发生故障时重新生成进程。为了解决以上问题，开发人员设计出第2代进程管理接口(PMI-2)。

在PMI-2中，针对PMI-1的以下几个方面进行了改进[2]：

(1)增加查询功能。

PMI-2中加入了进程管理系统预定义的键。通过该类键，进程管理器将系统信息直接添加到键值库中，MPI程序可以获取与MPI进程相关的布局信息。

(2)扩大数据库信息范围。

PMI-1采用的是扁平化的数据库，一个MPI进程不能限制它添加到数据库中的键值的范围。在此情况下，加入的信息都归纳为全局信息，进程无法单独获取仅与本地计算结点相关的子集信息。为了解决这个问题，PMI-2中引入了结点级别与全局级别的数据库信息范围，进程管理器可以更高效率地提取信息。

(3)增加线程安全。

PMI-1面临多线程情况时，MPI实现调用PMI-1需使用适当锁机制保护。但是，PMI-1中的锁机制是粗粒度的，当PMI库的一个查询请求得到了进程管理器的响应后，其他线程就无法在该套接字上通信。PMI-2则对PMI-1中线程安全的限制进行了修改，MPI实现不需要确保一次仅有一个线程调用PMI。

(4)改善容错机制。

当故障发生时，PMI-1没有提供任何的进程重生机制进行处理。PMI-2提供了故障处理方法，利用重生的新进程取代同一进程组中的故障进程。

随着超级计算机的发展，高性能计算系统面临多层次的大规模并行处理，为了满足百亿亿次级系统的要求，PMI社区开发出PMIx接口[3,9]。PMIx是专门设计用于支持百亿亿次级系统的进程管理接口，该接口以编程模型不可知的方式抽象出管理大规模应用程序和监视进程所必需的功能。

在PMI-2的基础上，PMIx在功能上进行了进一步完善。相对于PMI-2中的数据库信息范围，PMIx将信息作用域增加到进程本地范围、结点本地范围、远程范围和全局范围。另外，在PMI-1与PMI-2中，键值的数据类型仅定义为字符串，PMIx则扩展了数据表示，可对更多类型数据进行存储。PMIx针对同步原语Fence和Get原语都加入了非阻塞版本，以降低操作延迟。同时，PMIx针对稀疏通信情况进行优化，提供按需数据交换模式，缩短通信时间。更为关键的是，针对启动大规模并行应用程序，PMIx定义了新的启动顺序，力求降低传统应用程序启动过程时间成本，加快程序启动。

3 大规模并行应用程序启动过程优化

随着高性能计算处理问题规模不断增大，传统并行程序启动过程显露出弊端。大规模应用程序的启动时间成为一个不可忽视的问题，PMIx为了满足百亿亿次级系统的要求，对传统启动顺序进行调整，力求快速启动应用程序。表1对比分析了传统应用程序启动顺序与PMIx模式下的启动顺序。下面将对PMIx优化并行应用程序的启动过程进行详细介绍。

Table 1 Analysis of start sequence of parallel application表1 并行应用程序启动顺序分析

3.1 传统并行应用程序启动顺序

传统并行应用程序的启动顺序大致分为以下6个不同的阶段，如图1[10]所示。

第1阶段：用户将作业组织成脚本或交互会话请求的形式，其中包含完成作业所需的资源类型与数量描述。而后，用户将作业提交给工作负载管理器WLM(WorkLoad Manager)，等待作业执行。

Figure 1 Traditional start sequence图1 传统启动顺序

第2阶段： WLM根据作业优先级、可支配资源数目和资源调度算法，将资源分配给作业，并将分配结果通知控制资源分配的资源管理器RM(Resource Manager)守护进程[11,12]。RM守护进程接收通知后，一方面在文件系统FS(File System)里获取应用进程二进制可执行文件，实例化作业进程，图1中“Spawn Procs”代表生成进程过程；另一方面从文件系统中加载实例化进程所需的动态依赖库。

可是，在进程数目庞大的情况下，由于大量结点的多个进程会同时进行请求库操作，极易引发“库检索风暴”问题，导致文件系统压力过大。

第3阶段：进程实例化完成后，需要构建进程之间的通信机制。每个进程都要提供交互所需的本地通信信息，例如进程rank和通信端点地址。当进程获取自身通信信息后，需要将该类信息发布到计算结点的本地代理上。

第4阶段：结点的本地代理发现所有进程信息后，利用网络上定义的全局操作[13]，完成结点与结点之间进程通信信息的全局交换过程，这一过程通常称为名片交换或BCX(Business Card Exchange),图1中“Global Xchg”代表该阶段。这个阶段是整个并行应用程序启动阶段中最耗时的部分。大部分的研究都关注如何开发更高效方法，以减少此过程的时间开销。

第5阶段：结点完成信息全局交换后，需要根据所获得的通信信息构建通信通道。在这一阶段，程序库会基于本地代理上的信息进行基础结构的组装，例如将通信通道映射到其他进程。这个阶段的时间花费是从本地结点的代理服务器上检索连接和其他所需信息所花的时间，以及每个进程配置其本地网络接口卡NIC(Network Interface Cards)所需的时间。

第6阶段：执行全局的屏障操作，用来确认结点上的所有进程都已经构建完成通信结构，可以进行通信。虽然这一过程并没有对数据进行处理操作，但此阶段是除全局交换外，另一个耗时最多的阶段。在该阶段，需要观察计算结点上的每一个进程是否都成功完成通信设置，另外还需要确认本地高速网络也处于接收信息的状态。只有经过该阶段的屏障，才可以认为所有进程能够进行交互。

随着并行应用程序进程数目的大幅度增加，传统的启动过程中第4阶段进程交换信息和第6阶段确认进程状态过程都会花费过多时间。为了实现在短时间内启动大规模应用程序，PMIx对传统应用程序启动顺序进行改进，力求消除全局交换的时间成本。

3.2 PMIx模式下并行应用程序启动顺序

传统启动过程中耗时最大的部分是全局交换信息与执行全局屏障阶段，PMIx通过提供新的接口，调整并行应用程序的启动顺序，力求去除以上2个阶段。修改后的并行应用程序理想启动顺序如下所示：

第0阶段：该阶段是针对系统资源进行的汇总过程，技术上来讲并不是启动过程的一部分，但资源目录(包括交换机、网络和结点拓扑等)对于应用程序调度以及有效完成启动过程至关重要。在该过程中，PMIx以动态方式处理资源，并对资源目录实时更新，从而保证启动过程的顺利完成。

第1阶段：用户将作业组织成脚本或交互会话请求的形式，其中包含完成作业所需要的资源类型与数量描述。而后，用户将作业提交给WLM，等待作业执行。在该阶段，WLM除了将请求记录到适当的队列中，还使用PMIx接口将请求传递到文件系统，以获取所有用户标识的可执行文件与支持库。

第2阶段：WLM根据作业优先级、可支配资源数目和资源调度算法，将资源分配给作业。分配通常发生在当前处理作业通知完成，启动末尾操作之前。因此，在新作业调度开始之前，有一定的时间对资源分配进行预处理。

PMIx利用这段时间完成2个重要步骤。首先，它提供一个接口，WLM可以通过该接口通知FS分配情况，并将在初始阶段确定的所需文件列表传递给FS。若此时存在可用缓存，文件系统将启动进程用到的文件缓存到与分配结点相关内存位置，通过定位所需文件，缓解文件系统检索压力。

其次，WLM利用另一个PMIx接口将分配情况和作业描述都传递给子系统，并接收一个“blob”，其中包含每个子系统对作业的支持信息(例如网络系统对进程通信的支持信息)。标记返回值来标识哪些值直接提供给结点上的本地资源，以及哪些作为环境变量传递给应用程序进程，环境变量在由特定进程初始化时会被资源识别。

第3阶段：缓存所需文件并获得网络配置后，WLM将“blob”以及分配信息和资源目录信息传递给已分配结点上的RM守护进程。在派生本地进程之前，每个RM守护进程都可以利用PMIx接口将配置信息传递给本地资源。RM守护进程向本地PMIx服务器注册应用程序和本地进程，从而为进程提供与应用程序和本地环境有关的信息。完成操作后，RM守护程序将派生应用程序进程。

第4阶段：在进程初始化期间，每个进程调用PMIx_Init函数连接到本地PMIx服务器。PMIx服务器通知RM进程连接，并返回本地RM守护进程在注册期间提供的所有信息。

至此，启动序列完成，进程已经获取网络系统的通信支持，可以自由通信。

但是，以上过程只是PMIx提出的一个理想启动顺序，目前还没有在进程管理系统中完全实现。要完全消除传统启动过程中全局交换和全局屏障阶段，需要对系统管理堆栈中的网络库与相应的事件处理机制做进一步改进[14,15]。

目前，PMIx提供了2个可用于提高启动性能的方法[3,9]。首先，在BCX操作中删除本地RM守护进程提供给每个进程的数据，从而大大减少BCX操作中包含的数据量，减少全局交换信息的时间。另外，PMIx提出一种直接名片交换DBCX(Direct Business Card Exchange)的替代连接方法，该方法根据需要获取所需进程的名片来代替BCX操作。每个进程发布的数据都缓存在本地PMIx服务器上，当进程向特定进程请求名片时，进程首先检查本地PMIx共享内存段，以查看数据是否已可用。如果不可用，则将请求传递到本地服务器，服务器随后请求主机RM守护进程从指定进程的PMIx服务器中检索数据。然后，本地PMIx服务器将数据提供给请求的客户端进程。虽然DBCX通过消除BCX操作允许更快的启动速度，但检索特定进程名片信息的效率较低。因而，DBCX更适合稀疏通信的环境，对于密集通信，还存在需要改进的地方。

4 进程管理接口性能优化分析

PMIx启动过程中耗时最长的部分是全局交换信息、建立通信机制的过程。为了快速启动大规模并行应用程序，目前对于PMIx的研究，大部分都集中在改进全局交换、建立大规模进程通信通道方面，研究者们针对PMIx启动过程中的各个阶段做出不同方面的优化。本节从下列几个方面介绍目前对于PMIx所进行的优化研究：(1)优化PMIx数据库伸缩性；(2)优化数据表示形式；(3)优化PMIx运行时环境。

4.1 优化PMIx数据库伸缩性

在进程管理接口提供的交互方式里，资源管理器与应用程序的信息交换是通过键值数据库KVDb(Key-Value Database)来进行的。应用程序进程通过PMI提供的Put原语将数据提交到KVDb中，利用特定的同步原语使数据库接收所有进程Put的数据，而后进程调用Get原语从KVDb中获取所需信息。

结点内的KVDb访问是影响PMI性能的主要原因之一，主要体现在Get原语的延迟问题。Chakraborty等人[16]对资源管理器SLURM中PMI-2实现的可伸缩性进行分析，将客户进程与服务器的通信定义为影响通信效率的一个关键限制，并且他们也探讨了利用共享内存机制实现KVDb的优势，主要包含以下几点：

(1)内存消耗可伸缩：传统方式在应用程序的每一个进程上都复制一次KVDb的内容，导致占用过多内存。利用共享内存机制，只需要在计算结点上存储一次KVDb内容，可减少存储量。

(2)更优的并行性：共享内存允许客户端在不涉及服务器的情况下独立访问KVDb。

(3)延迟更低：操作被允许可以按照CPU速度进行处理。

通过对PMI数据库伸缩性进行优化，从而降低Get原语的延迟，加快进程数据访问，提升资源管理器性能。与PMI-1和PMI-2相比，PMIx提供了更优的数据访问能力，一方面对作业级信息进行扩展，资源管理器可以直接获得作业环境的信息；另一方面，PMIx允许按需获取信息，在PMIx_Get中可以从KVDb中获得指定进程的信息。

PMI中原有的锁机制是POSIX线程[17]中的Read/Write locks(RW-locks)锁机制，该类锁的可伸缩性十分有限。为了进一步减少PMIx_Get操作延迟，Polyakov等人[18]基于文献[19]中的静态算法在PMIx的2.1版本中提出2N-lock锁机制。通过引入信号锁解决静态算法中写入器易饿死的问题，信号锁不易被读取器获取，但可以被写入器获取。写入器需要首先获得所有信号锁，然后获取读取锁进行写入操作。

另外，Polyakov等人[18]发现PMIx_Get中的线程转换也是影响性能的另一个限制因素。由于在PMIx 2.1版本的参考实现里，共享内存组件无法访问PMIx实现的全局状态，作者提出了新的线程安全转换方案：在PMIx_Get获取所需数据后，再进行线程shift操作，从而避免读写数据过程中的线程shift操作带来的延迟。对比原有实现，新提出的PMIx主机通信的锁定与线程安全方案，在168 PPN(Processors Per Node)情况下，最高可减少PMIx_Get操作66倍的延迟。

4.2 优化数据表示形式

这一部分的优化是针对PMIx启动过程中全局交换信息阶段的数据量大小进行的，通过精简交换信息的数据量，去除不必要的重复信息，从而缓解数据交换的压力，加速信息交换过程。并且，更精简的数据表示形式也可以减少存储空间占用，这对于大规模并行程序来说效果更为明显。

表2针对PMIx启动过程中涉及到的在数据表示形式方面所做的不同优化方式的效果进行了总结，简要介绍了各类方法的优化对象和优化方式，对比优化前与优化后数据表示形式的字节大小，分析所提出方法的优化效果，本节后续将对各类优化方法的具体内容进行详细介绍。

Table 2 Summary of data representation optimization mechanisms表2 数据表示形式优化机制总结

4.2.1 优化通信地址信息

Polyakov等人[20]使用基于UCX(Unified Communication X)通信的PMIx高性能软件栈对数据布局进行优化。UCX是一个高级通信库，其地址信息中包含进程建立连接过程中用到的所有信息，如通信地址、地址长度、通道特征等。Polyakov等人[20]通过去除地址表示中的通道特征和地址长度等通用信息，将通信实体地址信息大小从51 B降低到21 B，优化了60%。

4.2.2 优化进程交换数据表示

在PMIx中，进程交换全局信息时，通过调用运行时环境的Fence函数确保KVDb的全局信息同步，这是整个并行应用程序启动过程中最耗时的部分[21]。Fence函数通过交换每个运行结点上的数据块来保证信息同步，数据块由头部信息与进程组件信息组成，进程组件信息按照进程rank排序，每一个进程组件由进程标识符与进程键值对组成。为了减少交换的数据量信息，Polyakov等人[20]对数据块中各部分进行了如下优化：

(1)优化进程标识符表示。

一直以来，进程标识符是由进程namespace与rank组成。namespace字段由运行时环境所分配，在不同的运行时环境中，该字段的长度是不同的。在Open RTE(Run Time Environment)环境中，namespace字段大小为10 B，而在SLURM中，该字段至少为21 B。Polyakov等人对PMIx_Fence进行分析发现，参与同步操作的进程必须是同一namespace中的，这就表示参与同步操作的进程可组成一个固定序列，只需用一个大小为4 B的序列号标识进程即可，减少了进程标识符的内存占用。

(2)优化键值对表示。

在2.1版本及以前的PMIx参考实现里，一个键值对中key的表示形式为(namespace,rank,key-name)，并且PMIx_Get原语可以识别请求key所在的进程的rank值，这导致相同的key可能在数据块中重复出现。本文通过建立关于key的索引表，并只用key在表中的整数索引(大小为4 B)标识key的位置，对键值对表示进行优化。对于每个结点上N个进程(PPN为N)的情况，若key字段大小为s个字节，另外需要4个字节来表示key的长度，则一个key共需占用N*(s+4)个字节；引入索引表后，上述情况只需占用(s+4)+4*N个字节，对比减少占用s*(N-1)-4个字节，对于高性能计算软件堆栈，优化效果明显。

(3)优化数值编码方式。

在2.1版本及以前的PMIx参考实现里的数值表示中，为了防止数据溢出，通常采用一个相比数值实际大小要大很多的数据类型来表示数据。例如对于键值对中的value字段，不论键值真实大小，统一采用uint64数据类型定义键值，在内存中占用[21;256] B。这种方法在一定程度上造成了空间浪费，当进程数目较多时，浪费更为明显。本文采用Little-Endian Base 128(LEB128)[22]编码方式，仅把所需要的字节打包到缓冲区中，避免了数据类型造成的多余空间浪费，优化了数据占用空间。

4.3 优化PMIx运行性时环境

针对分布式计算运行时环境的问题，目前已经有了一系列的研究，每一类方法都集中解决一类特定问题。MPICH提供了多种运行时环境[23]，例如Hydra[24]、MPD(MultiPrupose Daemon)[25]、Gforker等。Hydra可以很好地扩展单个结点上的大量进程，与混合编程模型可有效交互；虽然Hydra可以检测和报告MPI进程失败，但无法处理故障进程。MPD通过一个环形拓扑连接结点，然而MPD弹性差，如果2个结点故障会将所有结点分成2个单独的结点组，从而阻止故障结点的通信；另外，MPD也不具备可伸缩性。

OPEN RTE[26]是OPEN MPI[27]的运行时环境，用于启动、监视和杀死并行作业，通过各种拓扑连接守护进程，但是通信并不可靠。PRETE运行时环境是PMIx规范的参考实现，技术上属于OPEN RTE的一个分支，继承了OPEN RTE中启动和监视MPI作业的大部分功能，能够部署各种各样的并行应用程序和工具。

针对不同的运行时环境，在PMIx中可进行不同的优化措施，目前已有的针对运行时环境优化的研究有：

Polyakov等人[20]针对SLURM[28]运行时环境中PMIx_Fence操作进行优化，将PMIx_Fence与MPI Allgatherv[29]操作对比分析，采用调整后的Bruck级联算法作为Fence操作。作者在108个结点上进行实验，以SLURM 18.08作为运行时环境，利用提出的集体算法与原有的树形Fence操作、环形Fence操作进行实验对比。结果表明，在108个结点上，当消息的规模从20字节扩展到214字节时，相比树形算法和环形算法，集体算法有效降低了Fence操作延迟。

为了在系统上有效运行计算任务，处理系统故障具有重要意义[30]。Zhong等人[31]针对PMI-x的参考运行时环境(PRRTE)中的故障处理进行研究，实现一种高效运行时故障检测，每个参与者只在可恢复的环拓扑之后观察单个对等点，利用多个重叠的拓扑进行优化检测与传播，最小化故障检测开销并保证框架的可伸缩性，加快进程故障处理。作者提出的方法权衡了系统开销、检测效率和检测风险之间的复杂关系，既可以承受结点与故障检测的高频特性，同时具有较低程度的拓扑结构，为在大型系统上有效进行故障管理提供了新的思路。

4.4 进程管理接口优化机制效果对比

4.1～4.3节中介绍了目前PMIx在数据库伸缩性、数据表示形式、运行时环境3方面所做的优化研究，表3对这3类优化机制效果进行了综合分析，探讨每一类优化机制的侧重点方向，通过对比为未来优化方向提供研究思路。

Table 3 Comparison and analysis of different PMIx optimization mechanisms表3 不同PMIx优化机制效果对比分析

5 结束语

为了早日实现百亿亿次计算目标，PMIx社区与各国研究人员一直致力于改进PMIx，以实现在更短时间内启动大规模进程的启动目标。本节主要从PMIx对于并行应用程序启动期间和运行时控制2个方面对PMIx未来的发展方向进行介绍。

5.1 并行应用程序启动期间

并行应用程序启动期间，在所有计算结点上实例化可执行文件及其依赖库的时间是影响启动过程的重要因素，当大规模进程同时请求加载一个依赖库时，容易引发“库检索风暴”问题。

目前，PMIx正在定义新的API，优化可执行文件的实例化。为了缓解文件系统的检索压力，未来PMIx正致力于通过预先定义的接口对作业脚本进行分析，提前获得所执行作业的动态依赖库信息，调用脚本级的指令提前发现所需的依赖文件，预定位到存储管理器中，并利用二进制文件执行动态库的加载。

在进程建立通信阶段，探索新的进程通信方式，当前发布的PMIx 3.0版本提供了为进程分配静态端口的函数。在未来的资源管理器中，可以利用此类接口取消进程动态分配通信端口的过程，从而消除全局交换信息阶段带来的时间成本问题。

5.2 运行时控制

目前PMIx对于运行时控制的优化主要集中于对存储数据方面的控制能力，例如对于并行应用程序数据重定位或存储策略的能力，目前这方面的研究还处于起步阶段，在未来还有很大改进空间。当前，PMIx正致力于发展以下几个方面：

(1)增强并行应用程序进程向资源管理器汇报数据存储情况，并将当前系统可用的资源实时更新通知到资源管理器。

(2)加强并行应用程序的进程向资源管理器查询当前数据的存储情况，快速获取进程所需数据的位置以及当前资源管理器存储方式等信息。

(3)进一步加强PMIx对于事件的处理机制，利用触发器及时激发事件进行事务处理；提高故障处理能力，合理应对系统运行过程中可能出现的各类问题，加强对于数据库更新的管控能力。