コンパイラとアプリケーションのコデザイン
図40の右上の表にA64FXとSkylakeのO3リソースの量の比較を示す。この比較から分かるように、A64FXプロセサのO3リソースは軽めであり、浮動小数点演算パイプラインは9段と長めである。また、A64FXのコアのキャッシュメモリはL1キャッシュだけで、容量の大きなL2キャッシュは持っていない。つまり、A64FXはコア数が多く、スループットは高いがレーテンシは長いという設計で、複雑なボディーを持つループなどではパイプラインが詰まってしまって性能が出ないということが起こり易い。
また、A64FXは容量の大きなL2キャッシュを持っておらず、ワーキングセットが大きいプログラムではキャッシュミスが発生しやすい。L1キャッシュミスが発生すると、メインメモリであるHBM2から読んでくる必要があり、長いストールが発生する。これもL1キャッシュのミスが少ない性質の良いコードでは高いスレッド並列コアのスループットを利用して高い性能が得られるが、キャッシュミスの多い性質の良くない難しいコードの場合は、性能が下がってしまうことが考えられる。実行が難しいコードを使わないアプリケーションを作るというようなコデザインを研究すべきと筆者は考える。
富士通のコンパイラは、ループアンロールでループボディーを長くし、それにソフトウェアパイプライニングを行って、リバモアカーネルの性能を約20％引き上げている。図40の右下のグラフは、この様子を示すもので、青の棒グラフはアンロール後ソフトウェアパイプライン化を行った場合のMFlops/s性能で、赤はアンロールだけでソフトウェアパイプライン化を行っていないコードの性能を示すものである。
これもうまく実行されている場合はスループットが高くて良いのであるが、複雑なボディーを持つループはパイプラインのストールが発生しやすい。ここでもストールを発生させないプログラミングの研究が重要になりそうである。
-
図40 A64FXプロセサ向きのコンパイラ最適化
アプリケーションのコデザインであるが、NICAMの場合を例にとって説明する。NICAMは全球の雲解像モデルとして使用する。次にアクセスする要素までの距離がコンパイル時に分かっている場合は、性能を高めるためにstructure load/store命令を使用するコーディングを行う。structure load/store命令は間接load/store命令より効率が高い。また雲形成などの物理プロセスを記述する部分はループボディーが大きい。このような場合はコンパイラでは最適なコードが作れないことが多いので、複数の小さなボディーに分割するLoop fissionを行う。NICAMの場合、Loop fissionで30％効率を改善することができた。
そして、NICAMでは部分的に単精度計算を使う混合精度の計算についても評価を行ってきた。メモリアクセスが多い部分では、単精度浮動小数点計算を使うと必要なメモリバンド幅を減らすことができるため、60％の性能向上が得られた。
-
キャプションがここに入ります
(次回に続く)
