今年度からポスト富岳FSも始まって、牧野もシステム調査研究に採択された2つ
の提案のうち1つの代表として関わることになりました。
まあその、「京」の時にも富岳の時にもアクセラレータ提案して却下になってるので
2度あることは3度あるとは思いますが、とはいえ対抗提案をすることで本命のもの
がよくなるかもしれないですし、また3度目の正直ということもあるかもしれないので、
というところです。
とはいえ、世界の情勢をみると、ホモジニアスな CPU コアの並列システムで
世界一の性能をだしたのは2010年以降 「京」、 BG/Q、富岳の3システムだけ
で、それ以外は Tianhe-2A(Xeon Phi ですが)、Sunway TaihuLight、Summit、
Frontiers と全てヘテロジニアス、また現在 1EF 以上を達成しているとみら
れる中国の 2 システムもヘテロジニアスです。なので、日本だけが
ガラパゴス的な古いシステムにしがみついているようにもみえます。
中国についてみると、
その一つは Sunway OceanLite
で、ヘテロジニアスといってもプロセッサコア自体は同一で、普通にキャッシュ
をもつ MPE (management processing element) とキャッシュのかわりにロー
カルメモリを持ち、主記憶と DMA 転送ができてまたコア間のレジスタ-レジス
タ転送や放送や総和をサポートする CPE (compting processing element) か
らできています。これはキャッシュコヒーレンシを排除してローカルメモリア
クセスに限ることで電力性能とアプリケーション実行効率をあげています。ま
あそのぶんプログラムは修正は必要ですが、主記憶は一応共有されてるのが使
う側からみるとメリットです。データ転送書く必要ないしそこで性能が制約される
こともないからです。プログラムも、低レベル環境でもスレッドベースなので、
比較的ハードルは低いかもしれません。
他の Tianhe-2A、Summit、Frontiers はCPUとアクセラレータでメモリ空間が別で、
使うのはそれなりに大変です。
さて、我々はなんとなく
-
CPU オンリーのホモジニアスシステムは使いやすいが性能は低い(価格あたり、電力あたり共に)
-
アクセラレータがあるヘテロジニアスなシステムは使いにくいが性能は高い(価格あたり、電力あたり共に)
と思っているわけですが、これは、マーケットにある製品の観測としては概ね
正しいとして、「我々が開発するものはどうあるべきか」ということを考える
には十分ではありません。設計空間の中には少なくともCPU オンリーのホモジ
ニアスシステムだけれど使いにくい、というものは確実に存在しているし、原
理的にはアクセラレータがあるヘテロジニアスなシステムだけど使いやすい、とか
CPU オンリーのホモジニアスシステムだけれど性能が高いとかいったものも存
在しているかもしれなくて、我々はその可能な設計空間の中から「ベスト」
(という言葉が何を意味しているかも問題ですが)なものを選択するべきだから
です。
従って、ここでは、我々が CPU、アクセラレータ、といっている時にそれは実際には
何をいっているのか、という概念整理を試みます。
さて、CPUベースのシステムについては、我々のイメージは明確です。システ
ムとしては、Xeon、あるいは ARM、SPARC のような、その上のOSが動くマルチ
タスクなCPU の対称型(これはそうでなくてもいいですが)マルチプロセッサで、
1ノードはコヒーレンシがある階層キャッシュによる物理的共有メモリである
ものです。
ノード内の並列化には、プロセス並列の MPI とスレッド並列の OpenMP (OS的
には pthread)がどちらも、通常はハイブリッドの形で使えることになります。
これが「使いやすい」というのは、要するに OpenMP で並列化できるので
並列化してないプログラムの並列化をインクリメンタルにできるとか、
プラグマによるもので並列化しない動作も可能であるとかだと思います。
そうすると、システム側からみた「CPUベース」の条件は
-
OS が動く対称型マルチプロセッシング CPUコア
-
コヒーレントな階層キャッシュによる物理共有メモリ
ですが、アプリケーション側からみて「CPUベース」であることの意味は単に
OpenMP が動くこと、ということになるでしょう。システム側の条件とアプリ
ケーション側の条件は似てはいますが同じではありません。例えば、OpenMP
が実行できるためには共有メモリである必要はありますが、原理的にはキャッ
シュコヒーレンシは必須ではありません。というか、少なくとも常時維持して
いる必要はありません。これはそもそも OpenMP がrelaxed-consistency モデ
ルによっているからではあります。
例えば、何か並列に実行できるループを OpenMP で並列実行したとしま
す、並列実行できる、ということは、そのループを実行中にあるプロセッ
サが更新したデータを他のプロセッサが使うことはない、ということで
す。なので、少なくともループの実行中は、キャッシュが更新された、
という情報を他に伝える必要はありません。ループが終わって、他のプ
ロセッサが自分の更新したところをアクセスする可能性がでる直前に、
ライトバックして書換え情報を共有するか、そもそも書いたあとでロー
カルキャッシュを全部クリアすればよいわけです。もちろん、OpenMP の
ループ毎にプライベートキャッシュを全部捨てるのは必ずしも賢い方法
ではありませんが、コヒーレンシだけが解ではありません。プライベー
トキャッシュを捨てる、という方法は賢くなさそうですが、コヒーレン
シプロトコルと違ってコアが数増えてもトラフィックが増えない、スケー
ラブルな方法であるというメリットもあります。
細かいところまでちゃんと理解していないのでここは嘘を書いているか
もしれませんが、PEZY-SC では実際にコヒーレントがないキャッシュが
採用されていて、あるPEが更新したデータを他のPEがアクセスする前に
実際に2つが属するキャッシュレベルまでのフラッシュが必要で、上に書
いたのに近い仕掛けになってるのではないかと思います。なお、PEZY-SC
の階層キャッシュの特徴は、L2, L3 と下にいくと非常にラインサイズが
大きくなることで、これは(近くのPEが近くのアドレスをアクセスするよ
うになっていれば)アドレストラフィックを減らし、非常にバンド幅が高
い L2, L3 の実現を可能にしています。
とはいえ、ここで書いていることは要するに、 OpenMP は
-
共有メモリ並列プロセッサでの fork-join 型の複数スレッド実行
-
複数スレッド間の relaxed-consistency
を前提にしている、ということで、これらを完全にサポートする
ためにはハードウェアとして共通メモリ並列の MIMD プロセッサが必要
です。
逆にいうと、完全でないサポートであれば SIMD でも問題ありません。例えば、
元々ベクトルプロセッサでベクトル化されていたようなループを OpenMP
(+SIMD) で並列化しています、というものは、ベクトルプロセッサ自体が
SIMD プロセッサとみなせるわけでもちろん SIMD プロセッサで(主記憶が共有
されていれば)実行できます。
ループではなくて配列表記ですが、 HPF の元になったともいえるCM-Fortran
はもちろん 完全 SIMD で流体とかQCDに普通に使われてたわけでそれなりに広
い範囲のアプリケーションを記述するだけの表現力もあります。
つまり、並列実行が非常に複雑な、コア毎に全然違うことをするようなもの
でなければ、「OpenMPが動けばいい」というアプリケーション側の要請に
答えるのに原理的には CPU である必要は全くないことになります。
もちろん、データセンターとかで仮想マシンにインスタンスを多数動かすとか
ウェブサーバーとかだと本当にCPUの並列性が必要(ただそうすると共有メモリ
である必要が全くない気がしますが、、、)ですが、少なくとも我々がHPCアプ
リケーションを動かす、という時に求めることは「pragma omp parallel for
を並列実行してくれる」ということでしょう。深層学習だと話はもっと簡単で、
PyTorch とか JAX とか(まあこれらがHPFみたいなものですが)が動けばよい。
それなら別に parallel for を動かすところはCPU でなくても 大規模 SIMD
ユニットでも GPU でもあるいはMN-Core でもいいじゃないかという気もする
わけですが、それには、「起動とデータ転送オーバーヘッドが十分小さいなら」
という条件があります。例えばカーネル起動に数十マイクロ秒もかかっていては、
ものすごくがんばってカーネルの数を減らしても性能をだすことは
難しいですし、また、ホストメモリとデバイスメモリの間のデータ転送や
その起動にさらに時間がかかっていては話になりません。
これは、
-
ホストがデバイスメモリに低レイテンシ、高バンド幅でアクセスできる
-
アクセラレータ側のコードを低レイテンシで起動できる
必要がある、ということです。1 は、Sunway とかのようにCPU とアクセラレー
タを統合すればよいわけで、これはその気になればできる話だし、2も、ハー
ドウェアレベルで「注意深く」設計すればすむ話ではあります。とはいえ、ど
ちらにしてもキャッシュコヒーレンシとかいっているとそのレイテンシが既に
大きいので無理、という問題はあります。例えば、外部DRAM が主記憶で、そ
れをキャッシュコヒーレンシがある形で共有していると、実際のホストとアク
セラレータの通信レイテンシはすぐにマイクロ秒オーダーになってしまうわけ
で、つまり、外部DRAM レベルで共有するものでは十分ではありません。CPUベー
スのメニーコアでなかなか性能がスケールしない(MPI並列では別)のは結局こ
れが理由で、通信・同期のレイテンシがとてつもなく大きいために折角同じパッ
ケージにはいっていて物理的にはナノ秒で通信できるのに、採用された通信メ
カニズムのために 100-1000倍遅くなっているからです。
まあその、1 には、どういうコアを使うか問題がもちろんあり、 64 bit ARM
コアは高いとか、そういう問題はあります。とはいえ最近だと RISC-V が
かなり使えるようになってきています。
そうすると、なんとなく形がみえてくるかな、というところです。