在完成簡單的OpenMP測試後，接下來使用專門用來測試浮點運算能量的程式碼來測試單一伺服器的運算能量，主要測試Netlib提供的HPL，以及NASA提供的NPB，透過這兩個大型的測試程式碼，可以讓讀者更加了解此款伺服器的運算效能。

Part3 進階平行效能測試
1000d測試

1000d的測試程式碼可以從Netlib的網站上下載(http://www.netlib.org/benchmark/1000d)， 這個程式主要是求解線性聯立方程式的數值解，係數矩陣為1000X1000，求解方式是使用高斯消去法(Gaussian elimination with partial pivoting)，藉由測量程式執行的時間反算處理器的浮點運算效能，效能單位同樣為Mflops，每秒執行一百萬次浮點運算，本測試使用Intel Fortran 9.1編譯器，編譯選項為-fast，測出來的結果為738Mflops，發揮不到處理器十分之一的計算能量。

如果讀者有興趣可以試著將1000d.f程式碼修改成呼叫Lapack的函式並且連結到Intel Math Kernel Library(MKL)，會發現測出來的結果會大幅的成長，這是因為MKL已經針對處理器的快取記憶體與硬體架構做過最佳化，因此可以發揮七到八成的處 理器浮點運算效能，修改的方式並不困難，只要將程式碼裡的矩陣分解dgefa改成呼叫dgetrf，未知數求解從dgesl改成呼叫dgetrs就可以， 程式碼如下。

原始程式碼:

call dgefa(a,lda,n,ipvt,info)
call dgesl(a,lda,n,ipvt,b,0)

修改程式碼:

call dgetrf(n,n,a,lda,ipvt,info)
call dgetrs(’N',n,1,a,lda,ipvt,b,lda,info)

之後編譯出執行檔，執行前先指定只要使用一個執行緒來計算，因為MKL也是使用到OpenMP的方式來進行平行計算，所以可以用下面的指令來設定環境變數控制執行緒的數目。
export OMP_NUM_THREADS=1
然後執行程式，可以跑出6.9Gflops(1Gflops = 1000MFlops)的結果，效能成長9倍多，如果將矩陣大小調整到12000X12000，以及增加執行緒的數目，可以測出更高的成績，如下表。

執行緒數目 GFlops Speedup Efficiency(%)
1 8.88 1 100
2 17.02 1.92 96
4 28.65 3.23 80.7
8 35.74 4.02 50.3

由測試的數據可以看出來，這款四核心伺服器在兩個執行緒的情況下速度成長接近兩倍，不過隨著執行緒成長到4或8個時，平行效益降到80%和50%，主要原因還是在於這台機器的記憶體存取並不是最佳的設定，因此當執行緒增加，主記憶體的頻寬就不足，造成效能提升的瓶頸。
如果讀者進行的數值計算裡有使用到Lapack的函式， 在搭配MKL以及這款四核心伺服器，可以在不用撰寫平行計算程式下，大幅提升計算的速度，而這顆四核心處理器和以往Xeon處理器相比較，一項很大的優勢 為每個核心都具有獨立執行SSE指令的功能，不會發生以往使用Hyper-Threading時兩個執行緒輪流使用SSE指令的盲點。

HPL測試
HPL是一套測試分散式記憶體環境的浮點運算效能工具，透過這組程式碼可以測量出叢集系統(Cluster)的平行計算能量，Top500的效能數據測試也是以HPL為基準，簡單來講HPL可以視為1000d的MPI版本，HPL同樣可以從Netlib上下載http://www.netlib.org/benchmark/hpl/，解開後需要編輯Makefile(Make.Clovertown)設定編譯參數，這次的測試有使用到MKL的函式庫，編譯出執行檔(xhpl)後，可以透過編輯輸入檔案(HPL.dat) 來控制係數矩陣大小以及相關平行計算設定，因為MKL本身可以設定執行緒的平行計算，因此在測試時需要特別指定OMP_NUM_THREADS的環境變 數，如果沒有指定，MKL預設會使用到系統的所有處理器資源，會造成和MPI搶佔處理器的狀況，實際搭配MPI的測試組合就很多種，測試數據如下表，單位 為GFlops，每秒執行十億次浮點運算。

Np Thread=1 Thread=2 Thread=4 Thread=8
1 8.89 17.01 29.04 31.3
2 16.73 8.63 30.8  
4 26.82 29.3    
8 28.95      

上表的數據中Np代表Number of Process，如果使用到八個核心來計算，就會有四種組合方式，效能最佳的是Np=1,Thread=8這組，最差的是Np=8,Thread=1，原 因在於Np數目越多需要切割的矩陣就越分散，資料交換需要的時間更多，因此會影響到計算的效能。如果分析Thread=1情況下的Speed和 Effiency，如下表所示，會發現最有效率的組合是Np=4這組數據，速度可以提升3.02倍，達到75.5%的平行化效益。

Np Thread=1 Speedup Thread=1 Effiency(%)
1 1 100
2 1.88 94
4 3.02 75.5
8 3.26 40.75

NPB測試
NPB是由NASA所推出的計算流體力學(CFD)效能測試程式碼，NPB全名為NAS Parallel Benchmarks，NAS則是NASA Advanced Supercomputing的縮寫，NPB包含五組數值計算程式和三組CFD應用程式，藉由這些程式可以測試出計算叢集的浮點運算效能，本次測試用的是 NPB 3.0版本，此版本除了針對原有的循序程式進行最佳化調整外，還支援OpenMP的功能，因此可以用來測試多核心的伺服器，程式碼的下載請參考網頁上的指 示(http://www.nas.nasa.gov/Resources/Software/npb.html)如果讀者沒有NAS的帳號需要線上註冊後才能下載程式碼。

NPB測試可以指定矩陣的大小，共分成S、W、A、B、C和D六種等級，本次測試主要以A和C為主，網格大小分別為64*64*64和162*162*162，數據的整理以bt、lu、sp和cg這四種測試程式碼為主，以下節錄NPB的程式碼介紹。

    BT is a simulated CFD application that uses an implicit algorithm to solve 3-dimensional (3-D) compressible Navier-Stokes equations. The finite differences solution to the problem isbased on an Alternating Direction Implicit (ADI) approximate factorization that decouplesthe x, y and z dimensions. The resulting systems are Block-Tridiagonal of 5×5 blocks and are solved sequentially along each dimension.

    SP     is a simulated CFD application that has a similar structure to BT. The finite differences solution to the problem is based on a Beam-Warming approximate factorization that decouples the x, y and z dimensions. The resulting system has Scalar Pentadiagonal bands of linear equations that are solved sequentially along each dimension.LU

    is a simulated CFD application that uses symmetric successive over-relaxation (SSOR) method to solve a seven-block-diagonal system resulting from finite-difference discretization of the Navier-Stokes equations in 3-D by splitting it into block Lower and Upper triangular systems.CG uses a Conjugate Gradient method to compute an approximation to the smallest eigenvalue of a large, sparse, unstructured matrix. This kernel tests unstructured grid computations and communications by using a matrix with randomly generated locations of entries.

NPB的浮點運算測試結果如下圖所示，由圖上來看以bt的浮點運算數值最高，其次是lu和sp，cg測試出來的結果最差。

如果將數據轉成用Effiency來看，如下圖所示，以bt.A的情況來看，可以發現當執行緒為2個時還可以維持在94.5%的平行化效益，當執行 緒為4 個時降到76.9%，增加到8個執行緒時降到56.1%，另外可以看出bt、lu和sp這三個CFD計算程式以sp的演算法最不適合進行平行計算，lu則 是當網格成長到C等級時，平行效益降為一半，bt的演算法則在A和C等級都維持一樣的平行化效益，原因可以在於lu和sp這兩種演算法對於網格的存取比重 比較高，所以對於記憶體的頻寬要求相對比bt還高，因此浮點運算效能在平行化的情況下提升有限。

結論
在現今處理器朝向多核心的架構發展的趨勢下，如果想要在這樣的環境下加快計算的速度，就必須了解多核心架構下的效能瓶頸為何，在本次測試中，可以 大略分成兩類的計算程式，第一類是單純大量的數值計算，如Molecular dynamics simulation測試，用到8個核心同時計算，速度可以快約7.6倍，達到96%的平行化效益，第二類是計算過程中會存取大量記憶體的程式，如HPL 和NPB等，此時就會遇到主記憶體存取的瓶頸，導致核心數越多，速度成長幅度降低，平行化效益也跟著降低，因此當移植計算程式到這種的多核心平台下，最好 能夠評估一下平行化的效益如何，才能決定改善程式計算速度的方式，如果屬於第一類的情況就很適合用多台伺服器組成叢集來加快計算，如果屬於第二類，應該先 從記憶體存取的瓶頸著手，才不會浪費了處理器的效能。

至於這台伺服器的硬體性能則是相當的具有競爭優勢，單台伺服器就可安裝到64GB的主記憶體，搭配上64位元的作業系統，計算程式可以輕易的突破 以往4GB的限制，再加上兩顆四核心Xeon處理器的加持，搭配OpenMP或是MPI都可以進行平行計算，剩下的問題就是使用者的程式是否支援平行處 理，如果使用者有用到線性代數則可以考慮使用Intel MKL的數值計算函式，就可以順利的使用到多個核心來加快計算，否則可能得透過OpenMP或MPI的方式來改寫原有的循序程式碼。

本次測試用到的程式碼都是網路上公開的資源，因此如果讀者有類似的計算環境也可以下載測試一下，比較一下Intel最新款的四核心處理器是否速度有比較快(下載測試數據)。