なにかの〆切が近い気もするのですがそれ用に考えの整理も兼ねて。
ここのところ演算器の数が多いプロセッサといえば GPU だったわけですが、PEZY-SC や Sunway 26010 のような、256 とか1024 とかのコアがMIMD 動作する(さらにPEZY-SC の場合は1コアが8スレッドSMTで合計8192スレッドが独立動作する)ものがでてきており、Top 500 や特に Green 500 で上位を占めるようになってきています。
以下では、これらのプロセッサにある原理的な困難と、それへの可能な対応について考えたいと思います。
細粒度 MIMD アーキテクチャで HPC 的な並列度の高いアプリケーションを動作させる時の大きな問題は3つあり、プロセッサ間通信のオーバーヘッドと、命令供給の問題、データ供給の問題となるように思います。
プロセッサ間通信の問題は、さらに2つのレベルの問題に分かれます。一つは、汎用的なMIMD アーキテクチャではコア間通信がキャッシュを経由するものになるため、特にレイテンシが非常に大きい並列化の障害になることです。もう一つは、本質的にMIMD であり、キャッシュ等の予測困難な振舞いをする部分もあるために同期には時間がかかることです。これらだけで結構致命的なのは Xeon Phi が示している通りです。
コア数がさらに増えると命令供給が大変になります。L1I をあまり大きくできないからです。PEZY-SC とSW26010 のどちらでも、L1I はコアあたり 1-2KB です。命令長が 64ビットだとすれば、128命令とか256命令しかないわけです。つまり、計算の最内側ループが100命令程度以下でないと、L1I のミスが発生してまともな性能がでることはおよそ期待できなくなります。
(2917/4/18 追記)
上の記述は間違いで、 SW26010 はコアあたりL1Iが16KBでした。ローカルメモ
リが 64KB ですからこれくらいが妥当でしょう。4way SIMD であることで
ローカルメモリ、L1I ともに大きくし、命令供給の問題をある程度緩和できて
いる一方、インオーダーのアーキテクチャでシングルスレッドであるためコン
パイラによる命令スケジューリングに頼らざるを得ないのですがそれに耐える
コンパイラにはなっていない、というなかなか難しい問題が発生していました。
演算器レイテンシを隠すのに十分なアーキテクチャレジスタもないので、なか
なか性能をだすのは簡単ではありません。また、コア内SIMD のため差分法で
は32バイト境界にアラインしないアクセスで性能が落ちる(ちょっとそれ以前
の問題もありましたがそれはさておき、、、)という問題も発生します。
(2917/4/18 追記終わり)
L2I を大きくし、ラインサイズを増やし、命令プリフェッチを掛ける、とかいったことも考えられますが、これは要するに L2I に L1I以上のバンド幅をもたせる、ということでかなり大変です。ちなみに SW26010 では命令キャッシュの階層構造は公開されていなくて、そもそもL2Iがあるのかどうかも明らかではありません。
粒子系シミュレーションでの相互作用カーネルくらいでも、なかなか 100命令には入りません。2粒子間でははいったとしても、アンロールやソフトウェアパイプライニングをしないと性能がでないという問題も別にあるわけで、このために命令数が増えるからです。
例えばもっとも単純な例ともいえるカットオフのない重力相互作用でも、逆数平方根計算の演算数によっては 30-40命令になり、これを4重にアンロールすれば既に160命令になるわけです。4重でたりるか、というと、演算器のレイテンシが4ということは最近の計算機ではまずないので、たりません。つまり、8重とかしたいわけでそうするとほぼ確実に不足になります。
ここでは、PEZY-SC の SMT 構成にはメリットがあります。8スレッドで同じループが実行されていれば、それは8重にアンロールされているのと同じ効果になり、ソフトウェアパイプライニングをしなくても演算器レイテンシが隠蔽でき高い性能がでるからです。とはいえ、これは「8スレッドで同じループが実行されていれば」という条件付きであり、最内側ループ1回実行時間より十分短い時間程度で複数スレッドが同期している必要がありま
す。同期がずれるとカタストロフィックに実行時間が延びることになりかねません。
重力相互作用程度であれば、それでも最内側ループで十分計算量が多く、またそのようなループがそれほど沢山はない(多くの場合1つしかない)ので頑張ればなんとかなることもあります。HPL では行列乗算カーネルはさらに単純なので命令キャッシュが問題になることはありません。
しかし、もうちょっと複雑なことをするプログラムになると、最内側ループは容易に複雑なものになります。例えば陽解法の少し複雑なスキームであれば、独立変数がメッシュ点あたり数個、CIP や IDO のような導関数を保持するスキームでも20程度であるのに対して、1ステップの演算数は数千に及びます。各メッシュに対して同じ演算をするので、そちら向きには3重ループがもちろんあるのですが、基本的にはその3重ループの最内側にこの
数千演算を実行する命令が並んでしまうわけです。これは命令キャッシュ的には最悪です。
そうなると普通はどうするかというと、最内側ループを非常に細かく分割するわけです。そうすると、各ループでは中間結果をロードして中間結果をストアすることになるので、データのためのメモリアクセスが非常に多くなります。また、性能をだすためには最内側ループの長さをある程度長く、となると、今度はそれが L1D からあふれるので大きく演算効率が下がることになります。
つまり、圧縮性流体スキームは、原理的には演算数が非常に多いため、データの再利用性は非常に高く、あまり主記憶バンド幅を必要としないのですが、実際には、L1I が小さいことによって命令列を十分にストア・再利用できず、そのため必要なデータ転送量が非常に大きくなってしまうわけです。もっとも、これは例えば 1KB を 8KB にすればなんとかなるような話ではなく、数千命令+アンロールが必要なので非現実的なサイズのL1I がな
ければこの問題は解消できません。
さて、ではどうすればいいか、というわけですが、もちろん、私の意見としては、ある程度大きな単位、例えば64コアとか256コアとか別に全チップでもいいのですが、で SIMD 動作させればよかろう、ということになります。この場合、命令を格納するべきストレージは MIMD の L1I に比べて64倍とか 256倍とかおそらくもっと使えるわけで、例えば数MB を使えば10万命令ほどがはいることになり、どんなに複雑なループでも実行可能です。
PEZY-SC のように(コヒーレントではないにしても、、、)データキャッシュありの構成だと、そうはいってもSIMDでは、、、とかいろいろな意見もでてくると思いますが、SW26010 のように各PEはローカルメモリにしかアクセスできなくてメインメモリには DMA で、とかになると SIMD で書けるようなことでないと性能はでないわけで、それなら、、、という気がしてきます。分岐ができるとかいっても分岐したら L1I からあふれるとか分岐の
ペナルティがとかそういうことになるからです。
まあそれでもなんでも SIMD はやだ、という人はいるわけで、そういう人には頑張って余計な苦労をして下さいというしかないわけですが、多少とも状況を改善しようと思うと、例えばコア内でSIMD幅を広げてコア数を減らして、(Xeon Phi 的アプローチですね)しかし電力性能や面積性能を犠牲にするくらいしかできることはないのではと思います。
一つありえるのは、古典的なベクトル命令、つまり長さ4とかではなく64くらいまでのベクトルに対する演算を命令でサポートするようにして、演算に対する命令の必要バンドを 1/16 とか 1/32 に落とすことです。そうすると、 L1I が不要、あるいは 64 コア程度で共有することが可能になり、大きくサイズを増やすことができます。これの問題は、ソフトウェア的に必要な並列度が増えてしまうことで、L1D のサイズとの間にまたミスマッチ
が起こる可能性が高くなります。
データ供給の問題は、上にみたように命令供給の問題と絡みあっているわけです。SW26010 では、ローカルメモリに DMA 可能なアーキテクチャと、演算コア間の低レイテンシな通信の実装によってある程度までこの問題を緩和していますが、命令供給の問題がより表面にでてくるように思います。
と、私が考えると演算器毎にローカルメモリをもつ SIMD に移行以外の解があるとは思えないのですが、さて、今後どうなっていくんでしょうね、、、
まあその、計算機作るほうの立場としては他の皆様が迷走していても別にかまわないというか知ったことではないのですが、使うほうの立場としては深刻です。データだけでなく命令キャッシュの具合も考慮した上で効率がでるようなやり方を考えろ、ということになるわけで、粒子間相互作用くらいならともかく、差分計算でよい方法があるのかどうかはまだ？な感じです。ある意味、制御構造というか数値スキームをプログラム側ではなくデータ側で表現するようなことも検討する必要があるのかもしれません。段々、それはプログラム可能な計算機を使ってることなのか？という疑問も湧いてくるのですが、、、