分布存储并行数值计算通信库界面设计

193分布存储并行数值计算通信库界面设计熊玉庆中科院计算所摘要指出了应用程序界面是分布存储并行数值计算通信库设计中的一个主要方面。分析了从进程抽象命名，基于源的消息选择和非阻塞点到点通信三个方面提高通信库的应用程序界面。关键词：并行数值计算通信库应用程序界面分布存储并行计算系统是目前高性能计算机的主流。通信库是分布存储并行计算系统的关键部分之一。目前，较常见的通信库有MPI[1]，PVM[2]等。它们是面向一般应用的，通用的消息传递界面。对于面向某一特殊领域的大型数值计算，这些库的界面较低，不适合大型数值程序的开发[3][4]。为快速方便地开发高性能，高可靠的大型数值软件，研制直接面向某一计算领域的通信库是十分必要和有价值的。这样，通信库界面设计就成为通信库设计的一个重要方面。这样的通信库界面应该是自然，简洁，方便，使程序编写更方便，编制的程序易于维护。本文从进程抽象命名，基于源的消息选择和非阻塞点到点通信三个方面讨论如何提高通信库的界面。并举例说明它们的实现方法。1.进程抽象命名在MPI，PVM等通信库中，一个进程组中的进程标记（在MPI中进程标记的英文为rank）是线性的。但在许多数值计算中线性的进程标记不能充分反映进程的逻辑通信模式。如在线性代数和油藏模拟计算中，二维的进程网格常常是方便的。而在有的FFT计算中蝶型的进程拓扑结构则更方便。由于进程的拓扑结构反映了进程的逻辑关系，因而，它对程序的编写及阅读带来极大方便。这里举例说明进程抽象命名的实现。一般地，设进程的拓扑结构为。假设所要设计的数值计算通信库是建立在MPI上。由于一个进程组中的通信总是在一定的通信上下文中进行，因此，必须将嵌入通信上下文中。在MPI中可实现如下：MPI_COMM_GROUP(comm,grp);/*找出初始进程组，进程的拓扑结构为线性*/MPI_GROUP_INCL(grp,Ng,,tgrp)/*形成新的进程组，进程的拓扑结构为*/MPI_COMM_CREATE(comm,tgrp,&tcomm);/*建立新的通信上下文*/2.基于源的消息选择[5]在通信过程中，接受进程对消息的选择一般是根据消息源和消息标志。但使用标志会带来一些问题。例如，在一个循环体中，通信使用一个固定的消息标志，那么，如果一个进程花比其他进程更多的时间完成一次循环，则该进程可能接受下一个循环的数据作为本次循环的数据。此外，并行程序往往很大，要多个人或多个小组共同完成。这就要求在所有子程序和所有程序员之间进行协调，使得各子程序中的通信消息标志不发生冲突。当以后要加入一个子程序时，必须保证新的子程序中的通信消息标志与其他子程序不发生冲突。这使得程序设计变得困难而复杂。下面举例说明基于源的消息选择的实现。再次假设所设计的数值计算通信库建立在194MPI上。为了实现基于源的消息选择，在通信上下文中，对每个通信上下文，定义一个一一映射nnf),(表示自该通信上下文建立以来，在该通信上下文中所进行的群通信次数，n的初值为1。为此，须另外定义通信上下文数据结构如下：StructCoNtExT{MPI_Commcomm;intmsgid,maxid,minid;…}comm是MPI的通信域，maxid,minid表示消息标志的范围，Context是指向该数据结构的一个指针。在Context建立时maxid和minid被赋初值。msgid是当前消息标志，初值为minid。f定义如下：0)minmod(max,maxminmax)minmod(max1,1)1()(ididnidididididnnfnf显然，f在区间[1+(k-1)(maxid-minid),k(maxid-minid)]上是个一一映射，其中，k=1,2,…。maxid和minid的值相差足够大，使得在任意时刻在同一通信域中未完成的群通信操作数不超过maxid-minid个。因而，在任意时刻不同群通信所传递的消息的消息标志不同，而同一次群通信中，各进程发送或接收的消息标志相同。对于中的点到点通信子程序，它们调用MPI的MPI_SEND和MPI_RECV来实现的。MPI_SEND和MPI_RECV在通信时，所传递的消息都带有消息标志，内部把这些消息标志都置为某个常量。该常量的值在maxid和minid之外。在同一通信域中，当MPI的两个进程之间通信所传递消息的消息标志相同，而且接收操作是MPI_RECV时，点到点通信操作的顺序与程序执行的顺序是一致，因而，接收进程只需知道发送进程标记，就可对接收的消息进行区别。这样，在中就实现了点到点无消息标志通信，从而通信对消息的选择是基于源的。对于中的群通信(collectivecommunications)，如果它们直接调用MPI的群通信子程序，则由于MPI的群通信子程序自身是无消息标志通信，因而，自然实现了通信对消息的选择是基于源的。假设它们是由MPI的MPI_SEND和MPI_RECV来实现的。MPI_SEND和MPI_RECV都以消息标志及接收进程或发送进程标记作为参数来区别消息。通信路经是由逻辑拓扑TOPO来决定的。现以广播通信为例来说明。设该通信子程序为_BCAST设某一进程调用广播通信子程序，如果它是消息源进程，则根据TOPO，_BCAST调用MPI_SEND将消息发给其他进程。这里把消息发给哪个进程是由TOPO来决定的。MPI_SEND所需消息标志是)(nf如果调用广播通信子程序的进程不是消息源进程，则_BCAST首先调用MPI_RECV，MPI_RECV的消息标志也为)(nf，因而，在同一次广播通信中的各进程发送或接收的消息的标志相同。由于同一次广播通信中各进程的TOPO参数一致，因此，MPI_RECV接到的消息与发给它的消息一致。MPI_RECV是全局阻塞的，在未接到消息之前，不会前进到下一步。MPI_RECV接到消息后，_BCAST根据TOPO决定是否将消息发给其他进程及发给哪个进程，如果要发送，消息的标志仍然为)(nf。3.非阻塞点到点发送操作[1]为了提高并行计算的性能，让通信与计算重叠是一种有效途径，多线程是达到这种根的一个方法。当一个线程阻塞等待通信时，同一个处理器上的另一个线程可被调用执行。在单线程环境中，非阻塞通信方式是达到通信与计算重叠的一个重要方法。195非阻塞点到点通信由两部分组成，一部分是启动操作，它启动非阻塞通信。另一部分是完成操作，它完成一次非阻塞通信。在MPI中，非阻塞点到点发送操作子程序可描述如下：MPI_ISEND（buff,count,datatype,dest,tag,comm,request），它返回一个值id。buff是一个缓冲区，含有要发送的消息。destination是消息要到达的进程号。MPI_ISEND启动一个通信，但不完成它。这个调用在消息从buff拷贝出来之前返回。MPI_WAIT（request,status），当request标识的操作完成时，也就是当消息从发送缓冲区拷贝出来时，MPI_WAIT返回，否则，它阻塞。MPI_TEST（request,flag,status），如果request标识的操作完成，它返回，并置flag=true，否则，flag=false。对于完成操作，MPI还提供几个子程序，它们是MPI_WAIT和MPI_TEST的延伸。在非阻塞点到点发送操作中，操作未完成前，发送缓冲区不能被使用。非阻塞通信可获得相当大的性能改善。然而，非阻塞通信的使用容易带来错误，导致代码过于复杂，这与并行数值计算通信库易于使用的目的不符。为了利用非阻塞通信带来的益处，同时避免它产生的缺陷。在并行数值计算通信库设计时，在其内部使用非阻塞通信，将非阻塞通信的复杂性对用户屏蔽。设在并行数值计算通信库中满足上述要求的点到点发送子程序是_SEND。为实现这两个子程序，首先在中设置一个公共缓冲池。_SEND的实现算法如下：_SEND（BUFF，DEST，…）{从系统中申请一块内存buff；buffBUFF；将buff放到公共缓冲池中；MPI_ISEND(buff,count,datatype,dest,tag,comm,request);MPI_TESTALL(count,array_of_request,flag,array_of_status);将可重用的缓冲区从公共缓冲池中释放；}在MPI_TESTALL的参数表中，count是公共缓冲池中缓冲区的个数，array_of_request表示与公共缓冲池中所有缓冲区相关的非阻塞通信的request对象队列。为及时释放公共缓冲池中的可重用的缓冲区，在的所有通信操作结束前，都执行如下程序段：⑴MPI_ISEND(buff,count,datatype,dest,tag,comm,request);⑵将可重用的缓冲区从公共缓冲池中释放；从上面算法，可知_SEND内部执行了非阻塞发送，但从用户角度，避免了使用启动与完成两个操作。从而实现了上述目标。4.总结提高应用程序界面是分布存储并行数值计算通信库设计中的一个重要方面。本文分析了从进程抽象命名，基于源的消息选择和非阻塞点到点发送操作三个方面提高通信库的应用界面。但提高通信库界面并不仅限于这几方面。有关的工作还有待于进一步研究。致谢本文工作完成于中科院软件所并行软件研究开发中心，并得到该中心孙家昶研究员，李玉成高工和中科院计算所张祥研究员的悉心指导。在此，向他们表示诚挚的谢意。196参考文献[1]M.P.I.Forum,MPI:Amessagepassinginterfacestandard,InternationalJournalofSupercomputerapplicationsandHighPerformanceComputing,8(3/4),1994.SpecialissueonMPI.[2]A.Geist,A.Beguelin,J.Dongarra,W.C.Jiang,R.Manchek,andV.Sunderam,PVM:ParallelVirtualMachine,TheMITPress,1994.[3]AboutmpCParallelProgrammingEnvironment,AvailableviaworldwidewebfromURL=~mpc.[4]J.J.Dongarra,R.C.Whaley,“AUser’sGuidetotheBLACSv1.0”,TechnicalReportUTCS-95-281,LAPACKWorkingNotes#94,UniversityofTennessee.June1995.[5]A.Skjellum,S.G.Smith,etc,ThedesignandevolutionofZipcode,ParallelComputing20(1994)565-596.