「京」スパコンシステムの詳細が明らかに

京スパコンのような大規模システムでは信頼性が非常に重要である。各ノードの故障率が100年に1回であれば、1ノードだけを使っている場合には全く問題ないが、8万ノードあると、ほぼ10時間に1回故障することになってしまう。

このため、CPUの命令実行やICCの通信はエラーを検出すると、同じ命令や通信を再実行して一過性のノイズによる誤動作を回避している。また、システム的にも1カ所が故障してもシステム全体は止まらないという思想で作られている。前に説明したようにTofuはローカルグループ内の別のノードまでルーティングしてXYZ軸の故障個所を回避することができ、IOへのパスの2重化、サービスプロセサの2重化などにより、片方が故障してもシステムとしての動作は回復できるようになっている。

もう1つ大きいのが、SPARC64 VIIIfxプロセサやICCの水冷である。

プロセサやICCなどのLSIの故障率には、その寿命はジャンクション温度の指数関数で低下するというアレニウスの法則がある。この法則に従えば温度を10度下げると寿命は約2倍になるという。このため、通常は85℃程度で使用するLSIを、京システムでは30℃に水冷して使用している。これにより、部品寿命は60倍～100倍に伸び、その分、故障頻度が減少する。実際の京スパコンの故障率は実運用でデータを取らなければ分からないが、LINPACKの測定では28時間の連続稼働が実現されており、1つのノードでは100年に1回よりも低い故障率になっていると考えられる。

同社のSPARCベースのシステムは、OSとしてSolarisを使っているが、京スパコンではPCクラスタとの実行環境の統一性とLusterファイルシステムやOpenMPIなどのオープンソースのソフトウェアの移植性の点からLinuxを採用している。しかし、大規模スパコンの運用管理系は、これまでの富士通のノウハウを生かして自主開発となっている。

スパコンでは多数のコアに仕事を分散する。そして全てのコアでの処理が終わったことを確認して次のステップに進む。この終了の確認を同期と呼ぶ。一番上の図のように全てのノードの処理時間が同じであればムダは生じないが、OSのデーモン処理などの実行(本来の計算以外の処理なのでノイズと呼んでいる)が入ったコアは処理の終了が遅れ、それに伴って他のコアとの同期タイミングも遅くなる。

このようなノイズの入り方は計算とは非同期であるので、まったく同じ計算をやらせても、実行時間がばらついてくる。このばらつきをジッタ(Jitter)という。京のLinuxでは、ジッタを減らすために2つの対策を取っている。1つはノイズとなる処理を洗い出し、ノイズ間隔が短い、あるいは継続時間が長いものはOSのソースコードを改良して間隔は200ms以上、継続時間は50us以下になるように改善した。もう1つはTofuインタコネクトのハードバリア機能を使って、下側の図に示すように、全てのコアでノイズの発生タイミングをそろえるという改善を行っている。

説明を端折ったが、京スパコンでは、プロセサ内の8コアの同期を行うハードバリア機能だけではなく、トーラスインタコネクトについても、プロセサ機能を使用せずにICCの中にツリー上に各ノードの処理の完了をまとめて同期時間を短縮するハードバリア機能が実装されている。

京システムは8万ノードを超える巨大なシステムであり、全体を1つのジョブで占有する場合もあるが、多くの場合は分割して使用される。そうすると、大きな箱の中にサイズが異なる小さな箱を効率よく詰め込むということが必要になる。このため、3次元形状を意識したスケジューラを開発し、隙間にジョブを詰め込むバックフィルや、その時にジョブのXYZ軸を回転して詰め込むなどの手法を組み込んで、効率的にジョブを詰め込んでいる。

京スパコンでは、プログラミング言語としてはFortran 2003、C、C++が利用できる。そしてノード内並列処理にはOpenMP 3.0をサポートしている。そして、ノード間並列処理を行うにはXPFortranを使用するか、MPI 2.1を使って明にノード間のデータ通信を記述することになる。 米国では、Co-Array Fortran(CAF)やUnified Parallel C(UPC)などのPGAS(Partitioned Global Address Space)言語を使ってノード間並列プログラムの作成を容易にする方向に向かっている現状で、ノード間並列プログラムの記述に前世代からのXPFortranしかないのは淋しい感じがする。

プログラミングツールでは多数ノードの中での負荷バランスを解析したり、Tofuの性能モニタ機能を使った通信状況のプロファイルの表示、トーラス上でのランクマッピングを自動的に最適化したりするツールなどを加えて、超並列の京システムへの対応を行っている。

国内のスパコンでも1000コア程度のシステムは相当数あり、このレベルの並列アプリケーションの開発はすでに行われているが、それを超えて10万コアに達する超並列のアプリケーションは未知の領域である。京スパコンのシングルコアでのアプリケーション実行性能やノードペアでの通信性能などは予定した性能が出ているが、本当の超並列でのアプリケーションの性能発揮はこれからのチューニングにかかっている。

講演で示された次のグラフでは1,024コアから65,536コアとノード数を64倍に増やした時、フラットMPIでは6倍強で性能が飽和し、ハイブリッドMPIでは11倍弱である。これにTofuのハードウェアバリア機構を組み合わせると16倍強まで性能が向上している。その点では京システムで導入したハイブリッドMPIやTofuのハードウェアバリア機構は4,096ノード以上では効果を発揮していると言える。しかし、最良の条件でも64倍のノード数で性能は16倍程度にしか上がっておらず、超並列システムで高性能を実現するには大きな挑戦が残っているという感じである。