HPL ベンチマークを用いた性能確認

3.4 GPUPC GEMM Libraryの評価 70

3.4 GPUPC GEMM Libraryの評価 71

第2の実験として，問題サイズを11000に固定しブロックサイズを2ずつ変更し ながらHPLを実行したところ，72の倍数のときに良い性能が得られることが確認 できた (図33)．

以上から，実験環境1においては，問題サイズ11000，ブロックサイズ72におい て，最大性能FLOPS値4.04GFLOPSを得ることができた．

− 問 題 サ イ ズ ( 2 9 , 3 0 , 3 4 , 3 5 )

− ブ ロ ッ ク サ イ ズ ( 1 , 2 , 3 , 4 )

− プ ロ セ ス グ リ ッ ド の サ イ ズ ( 2 x2 , 1 x4 , 4 x1 )

− 解 の チ ェ ッ ク に お け る 残 差 の 境 界 線 ( 1 6 . 0 )

− P a n e l F a c t o r i z a t i o n の ア ル ゴ リ ズ ム ( l e f t , Crout , R i g h t )

− 再 帰 的 P a n e l F a c t o r i z a t i o n の ア ル ゴ リ ズ ム ( l e f t , Crout , R i g h t )

− 再 帰 的 F a c t o r i z a t i o n に お け る s u b p a n e l 数 ( 2 )

− 再 帰 的 F a c t o r i z a t i o n に お け る s u b p a n e l 幅 の 最 小 値 ( 2 )

− P a n e l B r o a d c a s t の ト ポ ロ ジ ( 1 r g )

− Look−ahead の 深 さ ( 1 )

− Update に お け る 通 信 ト ポ ロ ジ ( mix )

− long に お け る U の 平 衡 化 処 理 の 有 無 (有)

− mix に お け る 行 数 の 境 界 値 ( 6 4 )

− L1 パ ネ ル の 保 持 の 仕 方 ( t r a n s p o s e d )

− U パ ネ ル の 保 持 の 仕 方 ( t r a n s p o s e d )

− メ モ リ の a l i g n m e n t ( 8 )

図 31: HPLの性能パラメタ(括弧内は初期値)

GPUPC GEMM Libraryを用いたHPLベンチマーク

GPUPC GEMM Libraryを用いてHPLベンチマークを実行する前に，CPU向け のHPLベンチマーク結果を参考にしてGPUPC GEMM Libraryを用いたHPLベン チマークの問題設定を検討する．

GPUPC GEMM LibraryではCPUからGPUへのデータ転送において一定のメイ ンメモリが必要となることから，HPLの問題サイズをCPUによるHPLベンチマー クで高い性能が得られる範囲における最大の問題サイズではなく，ある程度小さい 値で行う必要がある．

3.4 GPUPC GEMM Libraryの評価 72

図 32: CPUによるHPLの性能調査：問題サイズと性能(環境1)

図 33: CPUによるHPLの性能調査：ブロックサイズと性能(環境1)

3.4 GPUPC GEMM Libraryの評価 73

また第1の評価の結果から，問題分割・並列実行によって高い性能を発揮するには

DGEMMの問題サイズがある程度大きい必要があることが判明している．そのため，

仮にHPL内で実行されるDGEMMの問題サイズが全て小さい場合は，分割実行に より良い性能を得ることが困難であると言える．そこで，HPLにおけるDGEMM の実行について確認した．その結果，次のようなパターンとなっていることが確認 できた．なお，文中の問題サイズMNKは図21に対応している．

1. HPL内ではDGEMMを繰り返し実行している．

2. DGEMMの問題サイズMは，HPLの問題サイズから次第に小さくなっていく．

3. DGEMMの問題サイズNとKは，次項 (4) の場合を除いてブロックサイズ未 満の小さな値である．

4. “一定の周期”で，問題サイズNが問題サイズM+1，問題サイズKがブロック サイズ，という“比較的大きなDGEMM”が実行される．

5. ブロックサイズが大きいほど，“一定の周期”は長い周期になり，HPL全体に

おいて“比較的大きなDGEMM”が実行される回数も減少する．

実行パターンから，GPUPC GEMM Libraryは“比較的大きなDGEMM”のみを適 切に問題分割・並列実行することで高い性能が得られることが期待できる．

既に述べたように，CPU単体でのHPLベンチマークにおいてはブロックサイズ が72の倍数の時に良い性能が得られる．並列実行では問題サイズが大きなときに良 い性能が得られることから，これらの数の倍数の中から適当な値を選択することで 高い性能が得られると考えられる．

以上の検討結果から，問題サイズは8000に固定し，ブロックサイズは72の倍数 をいくつか試すことで良いベンチマーク結果が得られると考えられる．なお，問題 サイズ8000，ブロックサイズ72におけるCPUのみを用いたHPLベンチマークの 性能は3.90GFLOPSであった．

検討結果に基づき環境1にてHPLベンチマークを行った結果を図34に示す．横 軸にはブロックサイズ，縦軸には性能FLOPS値をとっている．

グラフからわかるように，本環境ではブロックサイズが576のときに最も高い性 能が得られており，その性能FLOPS値は5.86GFLOPSであった．CPUによるHPL

3.4 GPUPC GEMM Libraryの評価 74

図 34: GPUPC GEMM Libraryを用いたHPLの実行結果(環境1)

の最大性能FLOPS値が4.04GFLOPSであったことから，提案方式による速度向上 率は45.0%となる．

以上の結果から，GPUPC GEMM Libraryを用いることで高い性能を得られるこ とが示された．

ただし，演算精度には問題が残った．HPLは演算の途中と終了時に演算精度の確 認を行う機能を備えている．GPUPC GEMM Libraryを用いてHPLを実行した場 合，終了時の演算精度確認をパスすることができなかった．GPUによる演算が単精 度であるために計算誤差が大きくなってしまったことが理由であると考えられる．既 に述べたように本アプローチでは演算精度の改善を行わない方針であり，性能評価 の結果から本アプローチにより高い演算性能を得られることが確認できたと見なす．

なお，HPL内のDGEMM演算を全てGPUのみで実行することも可能である．し かしながら，問題サイズが小さいときに高い性能が得られないため，全体として低

いFLOPS値が得られることが明らかである．実際に測定を行った結果，1GFLOPS

にも満たない低い性能が得られた．

3.4 GPUPC GEMM Libraryの評価 75