徐海坤,匡鄧暉,劉 杰,2,龔春葉,2

(1.國防科技大學(xué)并行與分布處理國家重點實驗室，湖南 長沙 410073;2.國防科技大學(xué)復(fù)雜系統(tǒng)軟件工程湖南省重點實驗室，湖南 長沙 410073)

1 引言

在核反應(yīng)堆設(shè)計、臨界安全分析及屏蔽計算中，中子輸運問題是數(shù)值計算核心。通常采用確定論方法和蒙特卡羅MC(Monte Carlo)方法(又稱為隨機模擬法)[1,2]進行數(shù)值模擬。其中基于組合幾何的蒙特卡羅MC方法具有幾何仿真能力強、物理建模完善、模擬近似程度小、對問題維度不敏感等優(yōu)點。但是，利用蒙特卡羅方法進行數(shù)值模擬時也有明顯缺點，例如，收斂速度慢，模擬時間長[3 - 5]。隨著現(xiàn)代超級計算機技術(shù)的飛速發(fā)展，蒙特卡羅方法天然的粒子并行性使得這些缺點得以明顯改善，但在超大規(guī)模的核反應(yīng)堆數(shù)值模擬計算中，模擬時間長的問題依然比較突出。

堆用蒙特卡羅分析程序RMC(Reactor Monte Carlo Code)[6,7]是由清華大學(xué)工程物理系核能科學(xué)與工程管理研究所反應(yīng)堆工程計算分析實驗室(REAL團隊)自主研發(fā)的,用于反應(yīng)堆堆芯計算分析的三維輸運蒙特卡羅程序。RMC程序針對反應(yīng)堆計算分析中的基本需求，同時結(jié)合新概念反應(yīng)堆系統(tǒng)設(shè)計時幾何結(jié)構(gòu)靈活、中子能譜復(fù)雜及材料組分多樣、各向異性及泄露強(某些特定情況)等特點進行研發(fā)，是多物理多尺度耦合核能系統(tǒng)數(shù)值分析平臺的物理計算核心。

RMC程序有以下幾大特點：

(1)MPI+OpenMP 2層并行。RMC程序?qū)崿F(xiàn)了MPI+OpenMP 2層并行計算模式，上層使用MPI實現(xiàn)對等模式下的并行計算，下層采用OpenMP實現(xiàn)多線程并行計算，用任務(wù)分解方法實現(xiàn)粒子并行。同時，MPI也分成2級并行，第1級采用區(qū)域分解方法劃分幾何區(qū)域，以減少內(nèi)存占用量，第2級實現(xiàn)對粒子的并行計算。

(2) 大量采用vector作為基本數(shù)據(jù)類型。RMC程序使用C++作為開發(fā)語言，程序中大量使用容器vector代替數(shù)組作為基本數(shù)據(jù)類型。vector可變?nèi)萘刻匦允沟镁幊虡O為方便，但容量變化的同時需要不停地從內(nèi)存中申請和釋放空間，尤其是在多線程的環(huán)境中，內(nèi)存申請和釋放會引起線程之間的資源競爭，從而導(dǎo)致程序性能下降。

(3) 文件I/O量大。RMC程序?qū)崿F(xiàn)了斷點續(xù)算功能，續(xù)算功能由主進程控制，每隔一段時間主進程負(fù)責(zé)收集各個進程中粒子的相關(guān)信息，然后由主進程輸出到相關(guān)文件中。當(dāng)計算規(guī)模比較大時，續(xù)算文件的大小往往能達到幾十GB甚至上百GB，文件讀寫均需要較長的時間。

RMC程序在實際進行反應(yīng)堆數(shù)值分析計算時，對于千萬網(wǎng)格的計算規(guī)模，在數(shù)千核的計算機上完成單個燃耗步的計算需要數(shù)小時之久，完成一次大規(guī)模的數(shù)值分析需要幾天甚至一周時間。在有限的計算資源上如何提高計算的效率是本文研究的主要目的。

2 采用的優(yōu)化方法

根據(jù)RMC程序的特點，本文先后開展了以下工作。

2.1 基于TCMalloc的動態(tài)內(nèi)存分配優(yōu)化方法

RMC程序在內(nèi)存管理上有以下幾個特點：

(1) 內(nèi)存分配量大，在進行千萬網(wǎng)格數(shù)值模擬時，單個進程所占內(nèi)存在70 GB以上。

(2) 多線程中使用vector容器，內(nèi)存申請釋放比較頻繁，線程之間內(nèi)存鎖操作開銷較大，且容易產(chǎn)生內(nèi)存碎片。

在多線程計算環(huán)境中，要保證內(nèi)存數(shù)據(jù)的訪問效率和穩(wěn)定性，首先要考慮多線程內(nèi)存管理的有效性，即內(nèi)存分配釋放的快速性、碎片率、利用率和擴展性問題。RMC程序使用vector容器作為基本數(shù)據(jù)類型，在多線程的計算過程中需要不斷地申請和釋放內(nèi)存資源，需要選擇高效的內(nèi)存管理算法來減少多線程環(huán)境中的鎖競爭問題。

多線程內(nèi)存管理方式主要采用多堆的組織方式，內(nèi)存管理算法用于處理堆、處理器和線程之間的對應(yīng)關(guān)系。目前PTMalloc是Linux的主流內(nèi)存管理算法，該算法為一種基于線程隨機挑選內(nèi)存堆的算法。該算法每次分配內(nèi)存首先隨機查找未被使用的內(nèi)存堆，然后在該內(nèi)存堆中分配內(nèi)存。 釋放內(nèi)存時需將分配的內(nèi)存堆收回該內(nèi)存堆。在多線程的環(huán)境中，該內(nèi)存管理算法可能存在多個線程共享一個內(nèi)存分配區(qū)，使各個線程在申請釋放內(nèi)存時都需要加鎖、解鎖操作，且PTMalloc采用的是比較耗時的互斥鎖，這在一定程度上使得PTMalloc在多線程競爭時的性能受到影響。

TCMalloc是Google開發(fā)的面向多線程的內(nèi)存管理庫。與PTMalloc相比，TCMalloc具有更高的內(nèi)存分配效率和內(nèi)存利用率，提高了多線程并發(fā)環(huán)境中內(nèi)存管理的效率。TCMalloc的內(nèi)存結(jié)構(gòu)為三級緩存模型，分為線程局部緩存區(qū)(ThreadCache)、中央緩存區(qū)(CentralCache)和全局的頁面堆(PageHeap)。線程局部緩存區(qū)負(fù)責(zé)線程內(nèi)的內(nèi)存管理，當(dāng)局部緩存區(qū)能滿足線程分配內(nèi)存需求時，線程內(nèi)無需鎖操作即可進行內(nèi)存分配；當(dāng)局部緩存區(qū)無法滿足線程內(nèi)存分配需求時，則采用鎖機制從中央緩存區(qū)和全局頁面堆分配內(nèi)存。頻繁地內(nèi)存操作時，線程局部緩存區(qū)和中心緩存區(qū)之間可能存在周期性的抖動現(xiàn)象。

本文基于TCMalloc的內(nèi)存管理算法，結(jié)合RMC程序的特點，對TCMalloc大內(nèi)存的管理算法進行了以下幾點改進。

2.1.1 預(yù)先分配大量內(nèi)存塊

在內(nèi)存結(jié)構(gòu)上，本文沿用TCMalloc的三級緩存結(jié)構(gòu)，以保證內(nèi)存分配效率。由于RMC程序占用內(nèi)存量比較大，因此在初始化管理時，本文根據(jù)RMC程序的內(nèi)存需求，提前設(shè)置好中央緩存區(qū)中的內(nèi)存數(shù)量、運行時線程數(shù)以及每個線程局部內(nèi)存區(qū)的內(nèi)存數(shù)量，預(yù)先分配大量內(nèi)存塊到線程局部緩存區(qū)和中央緩存區(qū)，以減少線程在分配內(nèi)存時向中央內(nèi)存區(qū)申請內(nèi)存和釋放內(nèi)存所帶來的鎖開銷。

Figure 1 Loop iteration task queue of openMP schedule strategy圖1 OpenMP調(diào)度策略下循環(huán)迭代的任務(wù)隊列

2.1.2 一次申請多個大內(nèi)存塊

TCMalloc算法將大小在32 KB以內(nèi)的內(nèi)存塊稱為small內(nèi)存，將32～128 KB的內(nèi)存塊稱為large內(nèi)存，將超過128 KB的內(nèi)存塊稱為huge內(nèi)存。對于huge內(nèi)存TCMalloc直接使用mmap映射內(nèi)存的方法來進行內(nèi)存申請操作。當(dāng)線程局部緩存區(qū)的內(nèi)存無法滿足huge內(nèi)存的申請操作時，TCMalloc采用鎖機制一次性從全局頁面堆申請多個內(nèi)存堆用于huge內(nèi)存的分配操作，這樣避免了在大內(nèi)存分配時的多次鎖操作。預(yù)計一次性需要申請的內(nèi)存堆大小按式(1)計算：

(1)

其中,n為線程數(shù)，α為內(nèi)存堆中的空間系數(shù)，M為全局內(nèi)存堆的大小，Li為局部緩存區(qū)內(nèi)存塊總大小。

2.2 OpenMP線程調(diào)度策略

RMC程序中最主要的計算部分為粒子輸運計算，即對所有粒子進行追蹤(track)、采樣(sample)和碰撞(collide)計算。如在使用32進程、每進程創(chuàng)建10個線程計算共50萬粒子的算例中，粒子輸運計算部分占據(jù)了RMC程序約80%計算時間。

在RMC代碼中粒子輸運部分體現(xiàn)為對粒子循環(huán)的for循環(huán)結(jié)構(gòu)，由于各粒子模擬之間不存在數(shù)據(jù)依賴，RMC使用OpenMP對該循環(huán)體進行了線程級并行，這同MPI并行一樣，是對粒子并行的粗粒度并行結(jié)構(gòu)。由于輸運計算內(nèi)部有眾多判斷分支，每個粒子輸運時間必然都不盡相同，且無法預(yù)測，因此需要對該粗粒度的omp for循環(huán)體采用合適的并行調(diào)度策略，以盡量減少線程級并行計算時間。

OpenMP對循環(huán)體有3種調(diào)度策略：靜態(tài)調(diào)度(static)、動態(tài)調(diào)度(dynamic)和指導(dǎo)調(diào)度(guided)，并通過子句schedule(type,chunksize)來控制所采取的調(diào)度策略。循環(huán)體可以看成是各循環(huán)迭代塊組成的任務(wù)隊列，循環(huán)塊大小由chunksize設(shè)置。

圖1演示了當(dāng)循環(huán)結(jié)構(gòu)迭代900次、由3個線程并行、chunksize=100時，3種調(diào)度策略的循環(huán)迭代塊劃分方式，以及迭代塊任務(wù)隊列分配方式。其中的方塊代表迭代塊，塊中數(shù)字表示迭代塊大小。

值得注意的是，guided調(diào)度策略中，隊列第k個迭代塊大小由式(2) 確定，依次減小，直至減小到chunksize。

(2)

其中，LCk為第k個迭代塊之后剩余的迭代次數(shù)，NP為線程數(shù)，p為比例因子，編譯器中通常設(shè)置為1。

對于無法預(yù)測每個粒子輸運時間的隨機循環(huán)結(jié)構(gòu)，應(yīng)該采用dynamic或guided動態(tài)調(diào)度策略，并讓迭代塊chunksize盡量小，這將使得各線程的計算負(fù)載更加平衡。不過static調(diào)度迭代塊分配方式固定，而dynamic和guided調(diào)度是由運行時系統(tǒng)動態(tài)決定的，相較static方法，dynamic、guided方法和較小的chunksize會增加系統(tǒng)調(diào)度開銷。但是，考慮到大規(guī)模問題中粒子抽樣、追蹤花費的計算時間較長，可以忽略增加的調(diào)度開銷。總而言之，針對蒙特卡羅類粒子輸運程序，采用chunksize小的動態(tài)調(diào)度策略，理論上能得到更短的整體計算時間。

2.3 vector內(nèi)存對齊優(yōu)化方法

許多計算機系統(tǒng)對基本類型的數(shù)據(jù)在內(nèi)存中存放的位置有限制，它們會要求這些數(shù)據(jù)的首地址是某個數(shù)的倍數(shù)，通常是4或者8的倍數(shù)，這就是所謂的內(nèi)存對齊。在多數(shù)情況下，經(jīng)過內(nèi)存對齊后，CPU的內(nèi)存訪問速度會大大提升，也更容易對數(shù)據(jù)做向量化之類的數(shù)據(jù)并行調(diào)優(yōu)。因此，如果要提升應(yīng)用程序的性能，所有的程序數(shù)據(jù)都應(yīng)盡可能地對齊?，F(xiàn)在大多數(shù)的編譯器都已經(jīng)實現(xiàn)了自動對齊策略，但手動的數(shù)據(jù)對齊仍然是常用的應(yīng)用程序性能優(yōu)化手段。

RMC程序以vector作為基本數(shù)據(jù)類型，vector是C++容器中最常用的基本數(shù)據(jù)類型之一。C++中的vector數(shù)據(jù)類型原型聲明如下所示：

template 〈typename _Tp,typename _alloc=std::allocator〈_Tp〉〉

class vector::protected _Vector_Vase〈_Tp,_Alloc〉;

vector底層默認(rèn)調(diào)用系統(tǒng)的std:allocator作為內(nèi)存分配器，而std::allocator分配器通過Linux系統(tǒng)默認(rèn)內(nèi)存分配函數(shù)malloc實現(xiàn)，分配后的內(nèi)存首地址是否對齊取決于編譯器。使用自定義的對齊內(nèi)存分配器(AlignedAllocator)替換vector默認(rèn)分配器std::allocator，便可強制實現(xiàn)vector內(nèi)存首地址對齊。不同于std::allocator利用malloc函數(shù)，AlignedAllocator利用C語言底層內(nèi)存分配函數(shù)posix_memalign實現(xiàn)對齊內(nèi)存分配。

其中AlignedAllocator部分定義如下所示：

template 〈typenameT,AlignmentAlign〉

classAlignedAllocator

{

public:

typedefT*pointer;

typedef constT*const_poster;

pointer allocate(size_tn,typenameAlignedAllocator〈void,Align〉::const_pointer=0)

{

const size_talignment=static_cast〈size_t〉(Align);

void *ptr=allocate_aligned_memory(alignment,n*sizeof(T));

if(ptr== nullptr) {

throw std::bad_alloc();

}

returnreinterpret_cast〈pointer〉(ptr);

}

void * allocate_aligned_memory(size_talign,size_tsize)

{

assert(align>=sizeof(void*));

if(size== 0) {

returnnullptr;

}

void*ptr=nullptr;

intrc=posix_memalign(&ptr,align,size);

if(rc!= 0) {

returnnullptr;

}

returnptr;

}

}

2.4 基于HDF5的并行I/O技術(shù)

HDF5(Hierarchical Data Format Version 5)是近年來流行的一種針對科學(xué)數(shù)據(jù)進行高效存儲和管理的新型數(shù)據(jù)存儲方案,RMC程序同樣采用HDF5作為其中間續(xù)算文件數(shù)據(jù)存儲方案。

HDF5使用類似UNIX文件系統(tǒng)的層次結(jié)構(gòu)來描述所存儲的數(shù)據(jù)集。如用/foo/zoo來表示一個名為foo的group之下名為zoo的dataset。dataset是HDF5數(shù)據(jù)的基本類型，主要包括數(shù)據(jù)本身和描述數(shù)據(jù)用的元數(shù)據(jù)。

如圖2a所示,HDF5的串行I/O方式通常是按照file→group→dataset→dataspace→data流程依次創(chuàng)建各對象，最終由單個進程將數(shù)據(jù)讀/寫進dataset中。HDF5也能夠進行并行I/O，它通過底層調(diào)用MPI-2并行I/O接口來實現(xiàn)并行I/O，可以由多個進程同時讀寫文件中同一個dataset的各部分。如圖2b所示，編寫并行代碼需要在串行流程上增加一些操作，首先需要給file和dataset賦予mpio屬性，將dataspace劃分成歸屬各子進程的slabspace，各子進程在slabspace基礎(chǔ)上，同時讀寫劃分成子數(shù)據(jù)的subdata。這樣便完成了并行I/O操作。

Figure 2 Programming process of HDF5圖2 HDF5編程流程

RMC的續(xù)算文件通常需要保存幾何、材料、粒子、計數(shù)器和燃耗等數(shù)據(jù)，這些數(shù)據(jù)主要與網(wǎng)格規(guī)模和粒子規(guī)模有關(guān)。在大規(guī)模算例中，續(xù)算文件通常達到幾十、上百GB。例如在320萬粒子的千萬級網(wǎng)格算例中，文件大小高達148 GB。由于RMC對粒子進行了數(shù)據(jù)分解、對網(wǎng)格進行了區(qū)域分解，從而續(xù)算文件所需數(shù)據(jù)分散在各進程中。而RMC程序通常采用HDF5串行I/O方式訪問續(xù)算文件，即主進程在進行數(shù)據(jù)讀寫之前，必須先從其他進程中收集完整信息，再將信息數(shù)據(jù)寫入/讀出文件。而采用HDF5并行I/O方式，主進程無需收集數(shù)據(jù)，各進程便可直接將子數(shù)據(jù)寫入/讀出文件，從而節(jié)省MPI通信時間。尤其對于RMC具有幾十、上百GB續(xù)算文件數(shù)據(jù)的大規(guī)模算例，并行I/O方式能夠節(jié)省的通信開銷非?？捎^。

此外，相比串行I/O，并行I/O具有更高的讀寫速度，不過并行I/O性能受到計算機系統(tǒng)存儲硬件配置的限制。一般來說，數(shù)據(jù)存儲服務(wù)器結(jié)點越多，I/O并行度越高，并行I/O的加速優(yōu)勢越能體現(xiàn)出來。

3 測試與分析

本節(jié)對以上優(yōu)化方法開展單項性能測試，測試在高性能計算系統(tǒng)上進行，該系統(tǒng)每個計算結(jié)點包括2個Intel Xeon E5-2660 處理器(主頻2.6 GHz、10個核，每核包括32 KB L1數(shù)據(jù)Cache和32 KB L1指令Cache，256 KB L2 Cache,10核共享25 MB L3 Cache)和256 MB內(nèi)存，結(jié)點間使用國防科技大學(xué)自主研發(fā)的Express高速互連網(wǎng)絡(luò)，通信帶寬25 Gbps。系統(tǒng)采用Lustre并行文件系統(tǒng)，共有16個存儲結(jié)點。編譯環(huán)境使用基于gcc 4.8.5的Intel C/C++Compiler 16.0.3，并行環(huán)境使用針對Express-2高速網(wǎng)絡(luò)優(yōu)化的mpich3。

3.1 動態(tài)內(nèi)存分配優(yōu)化測試

將優(yōu)化后的TCMalloc庫編譯成靜態(tài)庫，在RMC程序編譯階段鏈接靜態(tài)庫，程序運行期間會自動調(diào)用優(yōu)化后的內(nèi)存分配方法。對RMC程序進行實際性能測試，測試規(guī)模盡可能重現(xiàn)工業(yè)算例所需的運行模式，固定進程數(shù)為32，每個進程創(chuàng)建10個線程，改變粒子數(shù)，分別測試不同粒子數(shù)情況下程序的執(zhí)行時間，結(jié)果如圖3所示。

Figure 3 Test results using optimized dynamic memory allocation method圖3 動態(tài)內(nèi)存分配優(yōu)化測試結(jié)果

在1 200萬網(wǎng)格數(shù)量的實驗測試中，分別測試了200萬粒子數(shù)、150萬粒子數(shù)和100萬粒子數(shù)情況下程序總體的運行時間。在粒子數(shù)為200萬時，未使用內(nèi)存優(yōu)化管理方法、使用TCMalloc和使用優(yōu)化的TCMalloc 3種情況下程序的運行時間分別為783 s, 683.2 s和671.4 s，使用本文優(yōu)化的內(nèi)存管理方法，較使用系統(tǒng)默認(rèn)的內(nèi)存管理方法，程序總體性能提升了16.25%，較使用TCMalloc提升了1.7%。

3.2 OpenMP調(diào)度策略測試

通過在omp制導(dǎo)指令中調(diào)整schedule子句,便可指定OpenMP調(diào)度策略，如使用如下制導(dǎo)指令便可將調(diào)度策略修改為迭代塊大小為100的動態(tài)調(diào)度策略：

#pragma omp parallel for schedule (dyna- mic,100)

RMC程序中對粒子追蹤和隨機抽樣過程的循環(huán)結(jié)構(gòu)采用的原始調(diào)度策略是chunksize=nIter/nThread的guided調(diào)度，這種調(diào)度結(jié)果其實和缺省static調(diào)度一樣，沒有達到負(fù)載平衡效果。

為了改善這種不合理的調(diào)度策略，本文采用了(guided,1),(guided,100),(dynamic,1),(dyna- mic,100)4種較小迭代塊的動態(tài)調(diào)度策略，并同原始調(diào)度(guided,nIter/nThread)和缺省static調(diào)度進行了對比。表1展示了對于6百萬級網(wǎng)格算例，使用32個進程，每個進程創(chuàng)建10個線程，計算200萬個粒子，迭代200次時，采用6種不同OpenMP調(diào)度策略的RMC計算時間。原始調(diào)度策略耗時最長，約252.4 s，采用(guided，1),(guided，100),(dynamic，1)的計算時間最短，約為234.1～238.5 s，整體性能提升約5.82%～7.81%。這表明，對于由粒子模擬存在眾多條件語句分支的蒙特卡羅程序，采用chunksize小的OpenMP動態(tài)調(diào)度策略，能夠在一定程度上提升性能。

Table 1 Computation time of particle transportation module under different scheduling strategies

3.3 vector內(nèi)存對齊優(yōu)化測試

在RMC程序中，把自定義的內(nèi)存對齊分配器(AlignAllocator)應(yīng)用到vector的數(shù)據(jù)類型定義中的方式如下所示：

vector〈int,AlignedAllocator〈int,64〉〉 Array;

本節(jié)對于1 200萬網(wǎng)格算例，使用32個進程，每進程創(chuàng)建10個線程，分別測試了100萬粒子數(shù)和50萬粒子數(shù)情況下程序的運行時間，表2為測試結(jié)果。

Table 2 Test results using vector memory alignment optimization表2 vector內(nèi)存對齊優(yōu)化測試結(jié)果

從表2中可以看出，使用內(nèi)存對齊優(yōu)化方法后，程序總體提升僅有1.8%，說明程序在編譯階段就已盡可能地實現(xiàn)了內(nèi)存對齊，但手動的內(nèi)存對齊仍然能使程序性能提高。

3.4 HDF5文件I/O測試

在RMC程序中，HDF5原本使用串行I/O技術(shù)，本文采用并行I/O技術(shù)后，程序性能得到極大提升。HDF5并行I/O實現(xiàn)方法主要在于，在串行I/O代碼的基礎(chǔ)上，添加mpio屬性，2.4節(jié)中闡述了具體方式。本文進行了2組測試：第1組使用16個進程，測試了400萬粒子數(shù)、600萬網(wǎng)格單元規(guī)模、72 GB續(xù)算文件的算例，測試結(jié)果如表3所示；第2組使用了64個進程，測試了320萬粒子數(shù)、1 200萬網(wǎng)格單元規(guī)模、146 GB續(xù)算文件的算例，測試結(jié)果如表4所示。

Table 3 HDF5 I/O test under 6 million grids

Table 4 HDF5 I/O test under 12 million grids

第1組測試中，讀寫時間分別縮短了90.12%和85.72%；第2組測試中，讀寫時間分別縮短了96.30%和95.18%。可見HDF5的并行I/O技術(shù)極為有效地提升了文件讀寫性能，而且網(wǎng)格規(guī)模越大，性能提升越明顯。

3.5 總體性能測試

將以上4種優(yōu)化方法全部應(yīng)用到RMC程序中，對RMC程序進行優(yōu)化后的整體性能測試。測試中同樣固定進程數(shù)為32，每個進程創(chuàng)建10個線程，分別計算在1 200萬網(wǎng)格情況下，200萬粒子規(guī)模和100萬粒子規(guī)模的程序總運行時間，測試結(jié)果如表5所示。從表5中可以看出，2種粒子規(guī)模下，程序的總體性能提升均達到了26.45%以上。

Table 5 Test results of overall performance

4 結(jié)束語

本文針對堆用蒙特卡羅分析程序(RMC)，先后開展了一系列的程序性能優(yōu)化研究，采取了基于TCMalloc動態(tài)內(nèi)存分配優(yōu)化、OpenMP線程并行調(diào)度策略優(yōu)化、vector內(nèi)存對齊優(yōu)化和基于HDF5的并行I/O優(yōu)化等優(yōu)化方法，并對優(yōu)化后的程序進行了實際性能測試。測試結(jié)果表明，每種優(yōu)化方法都使程序性能得到一定程度的提升，其中動態(tài)內(nèi)存分配優(yōu)化方法使程序性能整體提升了16.25%，表明在RMC程序中，頻繁的內(nèi)存分配是造成程序性能較低的主要原因之一，新的內(nèi)存管理方法有效提高了多線程環(huán)境中內(nèi)存管理的效率?；贖DF5的并行I/O優(yōu)化極大地縮減了程序續(xù)算文件讀寫時間。相較串行I/O方式，進程數(shù)越多，并行I/O時間越短。因此，使用HDF5的并行I/O非常有效。綜上所述，采用一系列的優(yōu)化方法優(yōu)化后，程序整體性能提高26.45%以上。