ムーアの法則の先にあるコンピューティングはどうなるのか？(2) ムーアの法則後の性能向上方法を考える

大きな性能向上にはアルゴリズムの再設計が必要

エクサスケール以降のスケーリングを達成するためには、ハードウェアからドライブされるアルゴリズムの開発、アルゴリズムからドライブされるハードウェアの開発、ハードウェアとアルゴリズムの共同開発の3股のアプローチが必要である。

ハードからアルゴリズムの設計をドライブし、アルゴリズムからハードの設計をドライブし、ハードとアルゴリズムのコデザインを行うという三股の開発が必要

SuperLUの最適化を例にとると、基本の最適化はリコンパイルであるが、XeonからXeon Phi(KNL)に替えると性能は0.6倍に下がってしまう。また、リコンパイルだけではGPUを付けることもできない。

ベクトル化やCUDAへの書き換えなどのコードのリファクタリングによる性能向上は、KNLのスピードアップで1.6倍の性能向上が得られる。GPUオフロードの効果は0.9～3倍の性能向上である。

そして、2次元の計算を3次元に変更するとか、通信の必要回数やバンド幅を少なくするとかのアルゴリズムの再設計による最適化では、CPU側では0.6～27倍の性能となり、GPU側では2.5～27倍の性能となった。

このようにリファクタリングだけでは大きな性能改善は望めず、大きな性能向上にはアルゴリズムの再設計が不可欠である。

ベースラインのリコンパイルではほとんど性能は上がらない。ベクトル化やCUDAの使用などのリファクタリングでも大きな改善は得られない。大きな性能改善にはアルゴリズムの再設計が必要になる

アクセラレータハードウェアの開発

Chiselのようなハードウェア設計言語は、プロトタイプを早く作れるという点で便利である。また、RISC-Vはオープンソースで拡張性があるので便利である。そして、OpenSoCはオープンソースのファブリックで各社のアクセラレータを接続することができる。これらをうまく使えば少ない手間で専用アクセラレータが作れる。

Chiselのようなハードウェア設計言語の使用、RISC-Vのようなオープンなプラットフォームの使用、OpenSoCで各種のアクセラレータの接続などを行えば、少ない手間でハードウェアアクセラレータが作れる

良く使われる数値アルゴリズムを加速するハードウェアを作るのは良い考えである。次の左の図はコア間を結合するオーバヘッドの小さいメッセージキューのブロック図である。このようなキューをハードウェアで作ると、通信レーテンシ―はリモート通信の場合では5.7倍に短縮され、ローカル通信の場合は12倍に短縮されるという結果が報告されている。

メッセージキューをハードウェアで作り、リモート通信のレーテンシを1/5.7に、ローカル通信のレーテンシを1/12に短縮することができた

シンボリックな行列ソルバーであるTrisolveでは、左下の図のようなLマトリクスを解くために依存関係の追跡が必要となる。そのため中央の図のように依存関係をグラフで表し、右側の図のようにレベル化したグラフを作る。現在、この依存関係はOMPアトミックを使って追跡されている。

シンボリックに行列を解くTrisolveでは依存関係のグラフを作る。これの依存関係を追跡するためにOMPアトミックを使っている

このグラフの追跡をOMPアトミックを使って行う場合の処理時間は左の棒グラフのようになり、コア数が増えるにつれて処理時間が長くなっていく。これに対してOMPのTaskloopを使うと、中央の図の棒グラフのようになり、ほとんどコア数に依存せず高速の処理ができる。

右側の棒グラフは、依存性の追跡だけでなく、行列を解くDGEMVやTRSMVの処理時間も含んだ処理時間を表していると思われるが、4コアでは91%、16コアでは77%、64コアでは49%と並列処理の効果が出ている。

OMPアトミックで依存関係を追跡した場合の処理時間(左)とOMPTaskloopを使った場合(中央)の処理時間の比較。右の大きなグラフはDGEMVやTRSMVを含んだ処理時間の比較

次の図は横軸がコア数で、縦軸は処理時間であり、OpenMPの場合とメッセージキューを使った場合を比較している。上側の線がOMPを使ったTrisolveの処理時間、下側の線はメッセージキューを使うようにSuperLUのアルゴリズムを変更したTrisolveの処理時間である。

この比較に見られるように、メッセージ当たりのオーバヘッドは1/12となり、 64コアでは性能が2倍、512コアでは8倍となっている。さらにコア数が多くなると最大20倍くらいの性能アップが期待される。

OMPアトミックを使うTrisolveではコア数を増やしてもOMPのリミットより早くならない。これに対してメッセージキューを使えば最大では20倍くらい早くできる

次の図は、HPC Challengeベンチマークに出てくる単精度複素数のFFT計算を行うネットワークである。このロジックをSPIRALで記述して合成した。14nmプロセスを使って作れば、1GHzのクロックで動作する。

オフチップのメモリのバンド幅が100GB/sの場合はFP性能のリミットは約1.5TFlopsで、計算ロジックのチップ面積は4.5mm2となった。メモリバンド幅が1TB/sの場合はFP性能のリミットは15TFlopsでチップ面積は36mm²となった。

FFTのネットワークを作ると、メモリバンド幅が100GB/sの場合は約1.5TFlops、メモリバンド幅が1TB/sの場合は約15TFlopsの性能が得られる

このFFTアクセラレータをFFT命令を追加したRISC-V CPUに繋いで性能の測定を行った。その結果は3.5GHzクロックのCore i7 5930K CPUでのソフトウェア処理では265ms掛かったが、FFTアクセラレータでは2.1msと126倍の速度が得られた。

FFTアクセラレータをFFT命令を追加したRISC-V CPUにつなぐと、汎用CPUによるソフトウェア処理の126倍の性能が得られた

次の円グラフは、米国のエネルギー省のスパコン(SummitやSierraなど国立研究所にある大型スパコンはほとんどがエネルギー省のスパコンである)ワークロードを示すもので、25%余りを占める一番大きいパイスライスがDFT(Density Functional Theory)の計算である。したがってDFT計算の性能を改善すれば大きな効果が得られる。

米国のエネルギー省のスパコンのワークロード。全体の25%以上がDFT計算に使われている

オフチップの通信を最小化したLS3DFではO(N)でスケールするDFT計算方式が確立している。

DFT計算のカーネルは3Dの並列FFTと複素数の行列演算である。複素行列演算の部分はコンピュートバウンドで、専用ハードウェアで性能を向上させられる可能性がある。

DFTのカーネルは、オフチップの通信を最小化したLS3DFではO(N)でスケールする。3D並列FFTとZGEMMなどの複素数の行列演算が計算の中心

科学計算に特化したアーキテクチャとしては、物性関係ではDFTの高性能化で、FFTの計算が多くを占めており、この部分をFPGAやASICで高性能化することが考えられる。CryoEMのアクセラレータは、現在、ローレンスバークレイ国立研究所に設置されているものは750GB/sの性能であるが、カスタムASICを検出器の近くに置くことで性能を上げられる可能性がある。遺伝子関係では、ストリングのマッチングやハッシングの高速化が有効である。遺伝子関係は2bitから8bitの精度のデータが扱えれば良いので、FPGAの適用が有効そうである。ディジタルの流体計算のアクセラレータでは3D集積でペタスケールのチップを作れる可能性がある。

このように、計算に特化したアクセラレータで大幅に性能を上げられる可能性のある分野が多く存在している。

(次回は7月31日に掲載します)