PMI：可擴(kuò)展并行進(jìn)程管理AScalableParallelProcess-Management

PMI：AScalableParallelProcess-ManagemenIT擴(kuò)展并行進(jìn)程管理摘要。大規(guī)模系統(tǒng)的并行編程模型要求一種可擴(kuò)展的系統(tǒng)來管理組成了執(zhí)行并行程序的進(jìn)程。processmanagement必須能夠很快地啟動擁有數(shù)以百萬計進(jìn)程的并行程序，并且必須提供進(jìn)程交換信息的機(jī)制以使它們彼此連通。MPICH2及其衍生版本通過一個精心定義的接口來實現(xiàn)這個功能，叫PMI,它允許不同的processmanager用標(biāo)準(zhǔn)化的方式和MPI庫交互。在本文中，我們描述了PMI的功能。我們描述了PMI-1（目前的為MPICH2及其所有衍生版本通用的），也描述了PMI-2.,第二代的PMI（消除了PMI-1的各種缺陷）。除了接口本身，我們還分別描述了在新的MPICH2processmanagement架構(gòu)（叫Hydra）中PMI-1和PMI-2的參考實現(xiàn)，并比較它們在運(yùn)行千個MPI作業(yè)時的性能。1引言雖然processmanagement是高性能計算（HP。的一個組成部分系統(tǒng)，但是它沒得到同水平其他方面并行系統(tǒng)軟件的關(guān)注，卻是由來已久了。在百個節(jié)點(diǎn)的系統(tǒng)中，processmanagement的可擴(kuò)展性并不令人關(guān)注。隨著HPC系統(tǒng)變得越來越大，系統(tǒng)上千個節(jié)點(diǎn)和數(shù)萬的處理內(nèi)核越來越普遍；事實上，世界上最大的系統(tǒng)已經(jīng)使用幾十萬處理內(nèi)核。對于這樣的系統(tǒng)，processmanagement基礎(chǔ)架構(gòu)的可擴(kuò)展設(shè)計成為了各個方面的關(guān)鍵，這些方面包括啟動和管理并行應(yīng)用程序，可調(diào)試和管理工具。processmanagement系統(tǒng)必須，也理所當(dāng)然的，以可擴(kuò)展的方式的啟動和停止進(jìn)程。此外，它必須提供機(jī)制讓并行的進(jìn)程交換信息，以建立它們之間的通信。雖然HPC系統(tǒng)規(guī)模的日益擴(kuò)大需要并行編程庫（如MPI）和過程管理器（processmanager）之間的密切交互，但這兩個部件之間的適當(dāng)?shù)姆蛛x是必要的。這種分離不僅使得他們可以獨(dú)立開發(fā)和改進(jìn)，也保持并行編程庫足以通用于任何processmanagement框架。同時，這兩個組件必須共享足夠的信息，以便允許并行編程庫利用其所運(yùn)行系統(tǒng)的具體特點(diǎn)的優(yōu)勢?？紤]到這些要求，我們最初設(shè)計了PMI,一個為并行應(yīng)用程序的通用processmanagement接口。在本文中，我們首先描述第一代的PMI（PMI-1）。PMI-1被廣泛用于MPICH2[1]和從它派生的其他MPI實現(xiàn)，如MVAPICH2[4],英特爾MPI[6],SiCortexMPI[12],以及微軟的MPI[7]（編程庫部分），以及許多process-management框架，包括MPICH2的內(nèi)部process-management（Hydra,MPD,SMPD,Gforker,Remshell）,外部process-management,如SLURM[15],OSCmpiexec[9],OSUmpirun[13]（process-management部分）。雖然非常成功，PMI-1有一些局限性，特別是當(dāng)應(yīng)用于現(xiàn)代HPC系統(tǒng)。這些限制包括涉及到的問題有大量核心在單個節(jié)點(diǎn)上的可擴(kuò)展性，MPI和線程混合編程模型的高效交互，其他。基于我們PMI-1的經(jīng)驗，我們最近設(shè)計了一個二代接口（PMI-2）,克服PMI-1的缺點(diǎn)。該本文的第二部分介紹了描述了在新的MPICH2processmanagement架構(gòu)（叫Hydra）中PMI-1和PMI-2的參考實現(xiàn)。我們也通過闡述大約6000進(jìn)程規(guī)模上的性能測試結(jié)果，比較PMI-2同PMI-1以及其他processmanagement接口的能力。2process-management接口需求process在這個部分，我們提供了一個簡要概述來描述在大規(guī)模系統(tǒng)中可擴(kuò)展的并行程序管理的

management接口。process解耦ProcessManager和Process-Managementinterface在我們的模型中，過程管理包括三個主要部分：（1）并行編程庫（例如MPI）,（2）PMI庫，和（3）processmanager。這些組件就是在圖1中舉例示，不同的MPI庫，PMI庫和processmanagerso-PWUli*Pntrcdfin邛-PWUli*Pntrcdfin邛1卡加門11甫onSpwific)JJ111.::r?卡丁■?Fig.1.InteractionofMPT;mdtheprocessmanagerthroughPKflPlh班HaiugHK進(jìn)程管理器（processmanager）是一個邏輯上中心進(jìn)程（但往往實際上是分布式的一組進(jìn)程），用于管理（1）進(jìn)程啟動（包括啟動/停止進(jìn)程中，為每個進(jìn)程提供的環(huán)境信息,標(biāo)準(zhǔn)輸入/輸出/ERR轉(zhuǎn)發(fā)，傳播信號）和（2）信息在并行應(yīng)用程序之間傳遞（例如，建立交流信道）。幾個可用的processmanagers（例如，PBS[8],SUNGridEngine[14],andSSH,已經(jīng)提供這樣的能力。PMI庫提供了PMIAPI。然，PMI庫的實現(xiàn)，可能依賴于系統(tǒng)本身。某些情況下，諸如用于IBMBlueGene/L（BG/L）[3],PMI庫沒準(zhǔn)使用的系統(tǒng)特定功能來PMI提供服務(wù)。還有，比方說用在典型的商品集群中，PMI庫和processmanager通信用的是滴滴專車（例如，TCP。PMI庫可以任性的被實現(xiàn)，只要特定的實現(xiàn)樂意，在PMI-1和PMI-2有一個商量好的“連線協(xié)議（wireprotocol）”，是數(shù)據(jù)交換socket接口。使用這種協(xié)議的優(yōu)點(diǎn)是，任何應(yīng)用使用PMIAPI并遵守預(yù)定義PMI"連線協(xié)議”的程序能兼容任何P接受了PMI“連線協(xié)議”的PMIprocessmanager。我們注意到，PMIAPI和PMI“連線協(xié)議”是獨(dú)立的實體。一個實現(xiàn)可以選擇實現(xiàn)兩者，或它們中的一個。例如，在BG/L的PMI庫提供PMIAPI,但不使用基于socket的連線協(xié)議。因此，該庫兼容任何這個PMIAPI庫的程序，但是它不兼容接受了基于socket的PMI連線協(xié)議的processmanagers。概述第一代PMI（PMI-1）并行應(yīng)用程序的進(jìn)程需要相互進(jìn)行通信。建立這種交流通常需要發(fā)布一個聯(lián)系地址，沒準(zhǔn)是個IP地址，一個遠(yuǎn)程訪問存儲器段，其它互連的特定標(biāo)識符啥的。由于processmanager知道所有的進(jìn)程在哪里，也沒準(zhǔn)它管理一些掌握的標(biāo)準(zhǔn)I/O（標(biāo)準(zhǔn)輸入，標(biāo)準(zhǔn)輸出和stderr）進(jìn)程的通信，所以自然，它擁有processmanagement系統(tǒng)還提供了用于信息交換的基本設(shè)施。這就是我們processmanagement的關(guān)鍵功能，PMI一種認(rèn)同，即這兩個功能是緊密相關(guān)的，并且可以通過一個單一的服務(wù)被有效地提供。雖然PMI本身是通用的任何并行編程模型，而不僅僅是MPI,為了便于討論，我們只考慮在MPI編程這里模型。在MPI的情況下，PMI處理各種亂七八糟的，例如提供給每個MPI進(jìn)程它自己的信息（如它的rank）,以及程序中有關(guān)其他進(jìn)程的信息（如MPI_COMM_WORLDsize）。此外，每個啟動并行應(yīng)用程序的PMIprocessmanager被期望維護(hù)一個包含所有這些信息的數(shù)據(jù)庫。PMI定義了一個可移植的接口，使得MPI程序通過將信息添加到數(shù)據(jù)庫（put操作）和查詢程序中其他進(jìn)程增添的信息（"get"操作）與processmanager交互。PMI的功能被轉(zhuǎn)化成由PMI供應(yīng)商庫中相應(yīng)的連線協(xié)議，然后和processmanager交流。大部分?jǐn)?shù)據(jù)庫是通過使用鍵值對交換數(shù)據(jù)的。除了“put”與“get”的操作，PMI還提供了集體的“fence”操作可以讓有效地進(jìn)行集體的數(shù)據(jù)交換（如何使用fence更詳細(xì)的在第2.3節(jié)）。一個MPI庫和PMI庫和之間的交互示例，這時候processmanager管理著并行應(yīng)用程序有兩個進(jìn)程，P0和P1,其中P0要數(shù)據(jù)發(fā)送到P1。是介樣嬸滴，MPI初始化的過程中，每個MPI程序都添加自己的信息到PMI數(shù)據(jù)庫，這樣其他進(jìn)程可以聯(lián)系到它。當(dāng)P0調(diào)用MPI_Send至ijP1時，MPI庫可以從PMI數(shù)據(jù)庫查I有關(guān)P1,通過使用該信息連接到P1（如果需要的話），并發(fā)送數(shù)據(jù)。PMIRequirements之于ProcessManager的PMI需求在processmanagemen的設(shè)計過程中，對于processmanager有兩個主要的需求。首先，需要仔細(xì)功能劃分，以便于盡可能低開銷的耗費(fèi)在自身processmanager分層上。這種要求的出現(xiàn)是因為許多系統(tǒng)已經(jīng)有某種形式的一個緊密綁定到系統(tǒng)的processmanager（通常與資源管理器集成）?？梢浦驳腜MI必須有效地利用這些現(xiàn)有的而不需要額外開銷的系統(tǒng)（例如，無需原系統(tǒng)之外的額外進(jìn)程）。例如，接口需要數(shù)據(jù)異步處理或中斷來管理數(shù)據(jù)可能導(dǎo)致額外的開銷，就算是它們不與PMI服務(wù)交互；這可能是在大規(guī)模系統(tǒng)的一個主要問題。其次，一個可擴(kuò)展的鍵值系統(tǒng)的數(shù)據(jù)交換方式是必須的。這第二個要求具有若干方面。要弄一種系統(tǒng)，其中每一個進(jìn)程在并行作業(yè)開始的過程中，產(chǎn)生一個“聯(lián)絡(luò)id”，并希望使它對并行作業(yè)中的其他進(jìn)程可用。一個簡單的方法來做到這一點(diǎn)，進(jìn)程以向中央服務(wù)器提供數(shù)據(jù)，例如，將數(shù)據(jù)表示為（鍵，值）對存到一個簡單的數(shù)據(jù)庫中。如果P進(jìn)程都存放到中央服務(wù)器，時間復(fù)雜性為O（p）;當(dāng)時所有進(jìn)程都只提取一個單一的值也是O（P）。這種做法顯然是不可擴(kuò)展的。這時使用多臺服務(wù)器就行，但引入了另個問題。我們以PMI的解決方案是提供一個集體抽象，允許使用高效率的集體算法，以提供更具可擴(kuò)展性的行為。在此模型中，進(jìn)程將數(shù)據(jù)放入一個鍵值空間（KVS。然后，他們共同執(zhí)行一個fence操作。繼fence完成后，所有的進(jìn)程對KVS可以執(zhí)行g(shù)et操作。這樣的設(shè)計允許多種實現(xiàn)。最重要的，fence步驟，這是對所有進(jìn)程的集體操作，提供一個極好的機(jī)會來實現(xiàn)分發(fā)數(shù)據(jù)，這些數(shù)據(jù)通過一個可伸縮的方式put操作來提供。第二代PMI（PMI-2）雖然PMI-1的基本設(shè)計被廣泛采用了大量的PMI庫和processmanagmers，但因為我們弄到更高級功能的MPI以及較大的系統(tǒng)上，PMI-1的若干限制浮出水面。第二代的PMI（PMI-2）解決了這些限制。PMI-2接口的完整信息（包括函數(shù)名），和連線協(xié)議都放在網(wǎng)上了[10,11]。為了避免啰嗦，我們在本文中就不提了。我們還是說說PMI-2比PMI-1改進(jìn)了啥。缺乏查詢功能：PMI-1提供了一個簡單的key-value數(shù)據(jù)庫用于存取。雖然processmanager最有能力了解各種系統(tǒng)的具體細(xì)節(jié)，然PMI-1并不允許它與MPI進(jìn)程來分享這些信息。換句話說，processmanager本身無法把系統(tǒng)具體信息的鍵值添加到數(shù)據(jù)庫中；從而MPI進(jìn)程不能從processmanager查詢這些信息。一個這個限制的例子就是，在多核和多處理器的系統(tǒng)，MPI實現(xiàn)必須確定哪些進(jìn)程駐留在同一SM印點(diǎn)上（例如，創(chuàng)建共享存儲器段或用于分層聚集）。每個進(jìn)程通過獲取所有其他MPI進(jìn)程的聯(lián)系信息，收集這一信息，，并確定哪里是自己的安身之地。雖然這種方法很行得通，它是非常低效的，因為PMI獲取每個MPI進(jìn)程的操作是O（P）（整個操作O（PM））。PMI-2引入了作業(yè)的屬性的概念，它是Processmanager提供的預(yù)定義的鍵。使用這樣的密鑰，processmanager可以傳遞系統(tǒng)的具體資料給MPI進(jìn)程；也就是說，這些鍵是processmanager直接添加到鍵值庫的，允許每個MPI程序用一個操作就能以獲取有關(guān)的所有MPI進(jìn)程中的布局信息。另外，由于processmanager知道這樣的屬性是只讀的，它可以通過緩存在本地代理副本優(yōu)化其存儲，因此把PMI查詢請求從O（P^2）（在PMI-1里）降到接近零（在PMI-2里）。數(shù)據(jù)庫信息范圍（scope）:PMI-1采用了扁平的key-value數(shù)據(jù)庫。也就是說，一個MPI進(jìn)程不能限制它添加到數(shù)據(jù)庫中的一個鍵的范圍（scope）,所有的信息是全局的。因此，如果某些信息只想給本地進(jìn)程的一個子集，PMI-1就提供不了任何機(jī)制讓MPI進(jìn)程告訴processmanager這么干。例如，僅和本節(jié)點(diǎn)上進(jìn)程有關(guān)的shared-memorykeys的信息，但processmanager不知道往哪兒存放或者復(fù)制這樣的信息更好。為了解決這個問題，PMI-2引入了節(jié)點(diǎn)級別和全局級別的“scope”的鍵（PMI-2更嚴(yán)格的scope限制不支持，這雖失一般性卻有利于簡潔）。例如，對于共享內(nèi)存段的鍵可以被限制為節(jié)點(diǎn)級范圍，從而使processmanager來更好地提取。MPI+線程的程序：PMI-1不是線程安全的。因此，在多線程MPI程序情況下，MPI實現(xiàn)調(diào)用PMI-1時必須使用適當(dāng)?shù)逆i定機(jī)制保護(hù)。這種鎖往往是粗粒度，并且PMI庫和processmanager之間是序列化通信。也就是說，PMI庫發(fā)送一個查詢給processmanager一直到得到了它的響應(yīng)（一個往返通信），沒有其他的線程可以在同一socket上通信。PMI-2允許線程安全的PMI功能。因此，多個線程可以更細(xì)粒度的方式與服務(wù)器通信，從而管道請求更好，提高了性能。動態(tài)進(jìn)程：在PMI-1的每個進(jìn)程組維護(hù)一個單獨(dú)的數(shù)據(jù)庫和進(jìn)程不允許查詢整個數(shù)據(jù)庫的信息。對于動態(tài)產(chǎn)生的進(jìn)程，這是一個嚴(yán)重的限制，因為它需要這些進(jìn)程自己去交換他們的數(shù)據(jù)庫信息，并加載它們到單獨(dú)的數(shù)據(jù)庫中。此過程是繁瑣和高消耗（性能和內(nèi)存使用）。PMI-2理念中的job,可以是互相關(guān)聯(lián)的多個應(yīng)用程序或者是一個從另一個spawn出來的。這使得這樣job分享數(shù)據(jù)庫中的信息，而無需明確地復(fù)制。容錯：PMI-1當(dāng)故障發(fā)生時，不指定任何重生進(jìn)程機(jī)制。請注意，這是和生產(chǎn)MPI-2動態(tài)進(jìn)程說的是兩回事，因為spawn進(jìn)程將形成其自身的進(jìn)程組（MPI_COMM_WORL而不僅僅是取代現(xiàn)有的進(jìn)程組中的進(jìn)程。PMI-2提供重生理念，其中一個新的進(jìn)程本質(zhì)上取代同一進(jìn)程組內(nèi)的原進(jìn)程。在MPICH2中，PMI-2已實現(xiàn)新的processmanagement框架的一部分，稱為Hydra[5]。ExperimentalEvaluationandAnalysis4實驗評價與分析

在這部分，我們闡述了一些PMI-1和PMI-2的性能對比實驗結(jié)果。系統(tǒng)信息查詢功能正如上面第三部分描述的，PMI-1僅提供了簡單的鍵值數(shù)據(jù)庫用于存取，所以processmanager不能為MPI進(jìn)程提供系統(tǒng)信息的查詢。因此為了確定哪些進(jìn)程處在同一SM叩點(diǎn)上，需要O（p2）PMI操作。使用PMI-2's作業(yè)屬性，這個性能降低到幾乎為零。Fig.2.Pioct^Idiincliintoua5760-coreSiCortexsystem:（loft'lamiclitimeand（right.）nuinlterofPMIrequests,Fig.2.Pioct^Idiincliintoua5760-coreSiCortexsystem:（loft'lamiclitimeand（right.）nuinlterofPMIrequests,這個是MPI程序啟動時間的反饋。圖示2（左）展示的是簡單MPI應(yīng)用（只調(diào)用MPI_Init和MPI_Finalize）,在PMI-1和PMI-2分別在5670核SiCortex系統(tǒng)的表現(xiàn)。如圖所示，在PMI-1里，總的啟動時間隨著系統(tǒng)規(guī)模增大而迅速增長。而PMI-2,明顯少了很多。圖2顯示了從processmanager收到PMI請求數(shù)目的視角，對于兩個PMI實現(xiàn)更多的分析。此圖說明了兩者之間性能區(qū)別的原因：PMI-1比PMI-2的PMI請求多了幾個數(shù)量級。新增功能對本地processmanager的影響如3.2部分所述，一些系統(tǒng)擁有一個processmanager（往往和resourcemanager合體），和系統(tǒng)緊密綁定。而有的processmanager自身就提供了PMI的功能，有的則沒有。高效執(zhí)行的PMI接口須有效的利用這些本地processmanager,不再需額外的開銷（例如，通過要求喚醒其他進(jìn)程心跳操作，而干擾核心計算）。在這節(jié)中，我們以1600核的SiCortex系統(tǒng)和NAS并行C類標(biāo)準(zhǔn)在兩種模式下評估這種“噪音影響”：（1）利用系統(tǒng)本地processmanager,SLURM--已經(jīng)提供了PMI-1的服務(wù)，（2）使用Hydraprocessmanager,內(nèi)部使用SLURMS程啟動和管理，但在額外的守護(hù)進(jìn)程之上提供PMI服務(wù)。如圖3所示，附加的PMI（傳說中的Hydra）在本地processmanager（傳說中的SLURM之上，對系統(tǒng)的影響并沒有太多的開銷。圖3（左）顯示對運(yùn)行時間的影響，對開銷毫無趕腳。圖3（右）示出了大量的應(yīng)用程序運(yùn)行時，最高和最低的執(zhí)行時間差異（百分比表示）。還是，在多數(shù)情況下，毫無差別（0%~~,最大也不過EP應(yīng)用有0.5%的差異。如此低開銷的一個最大的原因就是PMI的設(shè)計完全靠同步動作，所以呢沒有不同步的PMI的服務(wù)deamon進(jìn)程。也就是說，一旦初始化結(jié)束，只要MPI進(jìn)程不發(fā)PMI請求，就沒有額外的開銷

RuntimeImpact(AbsolutePerformance；Ruhtime(PertenlijeVjriancejiRuntimeImpact(AbsolutePerformance；Ruhtime(PertenlijeVjriancejiF運(yùn).工Runtimeimpacto:separatePMIserverdawui口10IleftJabsoluteruutiniei孔nd(right)jm巾干】由用「vari孔nccinruntime.多線程MPI應(yīng)用程序的性能wmMroMa5-43z,1-msrG.lrlP^rfornnaiice口口ThreadedA1Pp■litHtionmThF*adCount隨著每個節(jié)點(diǎn)上核數(shù)量的增長，人們開始研究把MPI和線程放在一起用，MPI可能被一個進(jìn)程的多個線程調(diào)用。由于PMI-1不是線程安全的，所以所有的PMI調(diào)用必須以粗粒度的附加鎖保護(hù)；所以在某時間內(nèi)只能有一個線程和processmanagerwmMroMa5-43z,1-msrG.lrlP^rfornnaiice口口ThreadedA1Pp■litHtionmThF*adCountFig.4.MultithreadingPerformance在該實驗中，我們使用基準(zhǔn)評價（不斷對processmanager的發(fā)布和撤銷服務(wù)）來測量PMI操作的并發(fā)性。PMI-1每個線程獲得一個鎖，發(fā)送發(fā)布服務(wù)的請求，然后就等著processmanager的響應(yīng)，然后釋放鎖。PMI-2,每個PMI的請求都有一個線程ID;故，PMI庫可以發(fā)完一個請求就釋放鎖（讓別的線程也能發(fā)請求）就算是沒收到響應(yīng)。當(dāng)processmanager響應(yīng)了發(fā)布請求時，它就把原來的線程ID發(fā)回來，傳遞給相應(yīng)的線程。圖4是這樣線程支持的示意，就像圖里看到的，PMI-1中，增加線程的數(shù)量并不能減少單次MPI請求的平均時間，因為全部的請求都是串行的（所有線程的總工作量是固定的）.在PMI-2中，多線程進(jìn)行PMI并行請求時，所有的請求都是細(xì)粒度的方式，能獲得更好的并發(fā)性。所以平均PMI每個線程延遲是較小的。我們注意單線程的例子，比起PMI-1,PMI-2有額外開銷。這不是期望的結(jié)果，我們正研究咋回事。4.4可選Processmanagement框架的比較在本節(jié)中，我們比較了實現(xiàn)了PMI-2接口的

可選processmanagement框架，OpenRTEOpenRTE[2]（ORTE是OpenMPI所使用的processmanagement系統(tǒng)。它為并行Processmanagement提供穩(wěn)健和透明的支持。和PMI一樣，它包括“鍵值對”系統(tǒng)用于MPI進(jìn)程和processmanagement系統(tǒng)之間溝通。圖5比較了MPI應(yīng)用程序的啟動時間，分別是PMI-2實現(xiàn)的Hydra和OpenRTE勺。如該圖所示，PMI-2性能比ORTE3這796-核心商品集群上略勝一籌。Fig-5.Joblaunchtimecomparisonwithalternativeprocessmanagers5相關(guān)工作Fig-5.Joblaunchtimecomparisonwithalternativeprocessmanagers改進(jìn)并行編程模型的process-management框架是老生常談了。然而，大多數(shù)努力都集中在改進(jìn)Processmanager本身如何啟動和管理進(jìn)程。OSCmpiexec[9],OSU勺mpirun（也稱為SceLA[13],和SLURM[15]就是這樣的例子。OSCmpiexec的是一個MPI應(yīng)用程序的processmanager其內(nèi)部用PBS[8]啟動和管理作業(yè)。這是一個集中式的processmanager使用多種processmanagement連線協(xié)議通信，包括PMI-1。俄勒岡州立大學(xué)（OSU的mpirun是基于SSH的；它采用分層的方法來啟動進(jìn)程，并與PMI-1交互。SLURM[15]不同于其他主流processmanager,因為它提供一個完整的基礎(chǔ)設(shè)施，啟動和管理進(jìn)程；它也提供了其自己的與進(jìn)程進(jìn)行交互的PMI-1實現(xiàn)。而所有這些實現(xiàn)尋求提高對大型系統(tǒng)的processmanagement,我們的工作的不同點(diǎn)在于不去學(xué)習(xí)這些實現(xiàn)接口（MPI庫和processmanager之間）的需求和限制，而是PMIAPI和連線協(xié)議。ORTE^I供了一種機(jī)制用于MPI進(jìn)程同集成processmanager交互。然而，它并沒有明確分離這些功能，就像PMI和其相關(guān)的連線協(xié)議。總之，我們的工作不同于其他process-management系6結(jié)束語本文中，我們闡述了通用的框架能夠和并行編程庫交互繼而我們描述了新的第二代上大量內(nèi)核的擴(kuò)展性問題，processmanagement接口，PMI,它使得不同的processmanagement（如MPI）6結(jié)束語本文中，我們闡述了通用的框架能夠和并行編程庫交互繼而我們描述了新的第二代上大量內(nèi)核的擴(kuò)展性問題，processmanagement接口，PMI,它使得不同的processmanagement（如MPI）。我們首先描述了目前MPICH2M其衍生產(chǎn)品使用的PMI-1。PMI,PMI2,它克服了現(xiàn)今HPC系統(tǒng)中MPI和多線程混合編程的有效交互。結(jié)合本文還描述了MPICH2±的一個新的processmanagement框架名叫我們的性能結(jié)果Ourperformanceresults證明了顯著的性能提升從PMI-1的缺點(diǎn)：包括單機(jī)器PMI-1和PMI-2設(shè)計細(xì)節(jié),Hydra的設(shè)計實現(xiàn)。PMI-1到PMI-2.參考文獻(xiàn)ArgonneNationalLaboratory:MPICH2./research/projects/mpich2Castain,R.,Woodall,T.,Daniel,D.,Squyres,J.,Barrett,B.,Fagg,G.:TheOpenRun-TimeEnvironment(OpenRTE):Atransparentmulti-clusterenvironmentforhigh-performancecomputing.In:RecentAdvancesinParallelVirtualMachineandMessagePassingInterface.pp.225-232.Springer(2005)Gara,A.,Blumrich,M.,Chen,D.,Chiu,G.,Coteus,P.,Giampapa,M.,Haring,R.,Heidelberger,P.,Hoenicke,D.,Kopcsay,G.,Liebsch,T.,Ohmacht,M.,SteinmacherBurow,B.,Takken,T.,Vranas,P.:OverviewoftheBlueGene/Lsystemarchitecture.IBMJournalofResearchandDevelopment49(2/3)(2005)Huang,W.,Santhanaraman,G.,Jin,H.,Gao,Q.,,Panda,D.:DesignofhighperformanceMVAPIC