# 次世代スパコン「京(けい)」のコアテクノロジ > [!abstract] 概要 > 次世代スパコン「京」は世界最先端の 100 万コアクラスの超並列計算を実現するスーパコンピュータである。100 万並列の実効性能を得るには、過去のハードウェア、ソフトウェアを根本的に見直す必要がある。 > 「京」システムでは、米国動向も考慮し、並列計算モデルからノード間同期、データ転送、OS、並列ファイルシステム、ソフトウェア開発ツールに至るまで一新した。「京」システムはハードウェアの開発を完了し、2012 年の完成に向けて現在建造中である。本稿では、「京」システムのさまざまな超並列技術の中でも特にスケーラビリティを高める技術を解説する。 ## 論文情報 - タイトル: 次世代スパコン「京(けい)」のコアテクノロジ(英題 Core technologies developed for "K computer") - 著者・所属: 追永 勇次、富士通株式会社 次世代テクニカルコンピューティング開発本部 - 媒体: 応用物理 第 80 巻 第 7 号(2011)pp. 590-593。「最近の展望」欄の解説記事。2011 年 3 月 7 日受理、J-STAGE 公開 2011 年 7 月 10 日 - DOI: 10.11470/oubutsu.80.7_590。キーワードは supercomputer、massively parallel computer、K computer - 4 ページの解説であり、参考文献は 6 件。著者は 1974 年に富士通へ入社し、大型汎用計算機とスーパーコンピュータのアーキテクチャ・ハードウェア開発に従事してきた ## 概要 「京」は、100 万コア級の超並列で 10 ペタフロップスの実行性能を目指す国家プロジェクトのスーパーコンピュータである。本稿は、コア数に比例した性能の伸び(スケーラビリティ)を妨げる通信時間・IO 時間・処理の不均衡を、インターコネクト、マルチコアの自動並列化、ハードウェアバリア、OS ジッタ対策、ファイルシステム、チューニングツールの 6 要素でどう抑えるかを解説する。 ## 問題設定 - 背景: 2007 年に開発を始めた時点で、Top500 の第 1 位はリンパック実行性能 280 テラフロップスだった。このころ、ハイエンドの高性能計算機はコモディティ部品ベースの PC クラスタから、専用ハードウェアのプロセッサとインターコネクトを用いた超並列システムへ変わり始めていた - 米国では、1 ペタフロップスの実アプリケーション性能を目標とする次世代機の開発が複数進んでいた。これらは 100 万コア級を前提に、対象の並列アプリケーションのメモリ・ネットワーク・IO 性能を調べ、システム設計へ提言して反映していた。当時の日本は、対象アプリケーションを戦略的・包括的に分析して次世代の要件を提言するところまで至っていなかったと著者は述べる - 目標: 10 ペタフロップスの実行性能には 100 万コア級を想定する必要があり、システム設計は対象アプリケーションで大きく変わる。そこで米国のペタスケールアプリケーションの分析結果(文献 1)を参考に、メモリ、インターコネクト、IO 性能で世界トップクラスの低遅延と高バンド幅を目標に置いた - 課題: 並列アプリケーションのスケーラビリティは演算時間に対する通信時間の比で決まる。並列規模が増えると通信時間の分だけ性能が得られなくなり、コア単位の演算の不均衡も性能を落とす。IO も並列処理で高い性能を出すため同じ問題が起きる。維持するには処理遅延を抑え、通信を局所化する必要がある。著者は課題を次の 3 つに整理する 1. 規模に応じて通信時間と IO 時間をどう下げるか(Tofu、VISIMPACT、ファイルシステム) 2. ハードウェアとソフトウェアの処理遅延をどう小さくし、処理の不均衡を最小化するか(Tofu、高機能バリアインタフェース、OS ジッタ対策) 3. 性能を妨げる原因をどう提示し、最適化を支援するか(チューニングツール) ## 提案手法 - **全体構成**: 演算性能 128 ギガフロップスの 8 コアプロセッサ(SPARC64 VIIIfx)を、耐故障性のある Tofu インターコネクトで 8 万個以上結合する。128 ギガフロップス×8 万個は約 10 ペタフロップスで、目標値と整合する(算術による確認)。 **図 1: システム構成** ![[_attachments/oubutsu-2011-80-7-590/fig01-system-config.png]] (図 1. 計算ノード群が Tofu インターコネクト(計算用)と IO 用に接続され、IO ノードの下にローカルディスクとローカルファイルシステム、高性能クラスタネットワーク経由でファイルサーバとグローバルディスク・グローバルファイルシステムが並ぶ。右上は計算ノード構成で、8 コアプロセッサ、コア間バリア、共有キャッシュメモリ、メモリ帯域 64GB/s、インターコネクト総帯域 100GB/s、高機能バリアインタフェースを示す。) - **Tofu インターコネクト(3.1 節)**: 既存クラスタの 10 倍以上となるプロセッサ数万台規模で、通信時間・処理遅延・不均衡を下げるために独自開発した。Tofu は Torus fusion の略。従来の 3 次元トーラスに対し、ノード間リンク数を 6 から 10 に増やした 6 次元メッシュ/トーラスとし、通信ホップ数の短縮とランダム通信性能の向上を得る。ジョブごとに独立なトーラストポロジを見せることもでき、アプリケーションの隣接通信アルゴリズムが効果的に対応づく - 計算ノードと IO ノードの間は、ジョブ間の IO 干渉を最小にするため、計算用通信と IO 用通信を分ける。Z 軸=0 のノードを IO ノードとし、Z 軸=0 を IO 専用ネットワークとする。IO 通信は計算ノードから直下の IO 専用ネットワークを通る - リンク帯域は片側 5GB/s、ノード当たり 10 リンクで合計 100GB/s(双方向計)。これにより、ファイル入出力通信とノード間同期通信を、ばらつきの影響を抑えながら共有できるようになったと述べる。各ノードは最大 4 方向へ同時にデータ転送でき、複数経路による同一ノード間の多重転送も可能である。実測は 1 多重で 4.7GB/s、4 多重で 3 倍以上の 15GB/s だった - **VISIMPACT(3.2 節)**: Virtual Single Processor by Integrated Multicore Architecture の略。超高並列での通信時間の増大を抑える技術で、2008 年発表の 4 コアプロセッサ FX1 で初めて実現し、「京」で 8 コア向けに拡張した。高機能な自動並列化コンパイラと、マルチスレッド処理を助けるプロセッサ機構(コア間バリア、共有キャッシュ)から成る。全プロセス数を 1/8(8 コアの場合)に抑えて通信時間を減らし、従来の並列プログラムでも 1 プロセスを自動的に複数コアで処理する。プロセス並列度を上げずに最大 8 倍のコアを使える - コア間バリアの処理時間は 8 コアで約 0.1μs で、ソフトウェア実装の約 2μs の 1/20 である。このため粒度の小さい演算ループにも自動並列化を適用でき、性能が上がる **図 2: VISIMPACT の効果** ![[_attachments/oubutsu-2011-80-7-590/fig02-visimpact-effect.png]] (図 2. 実プログラムから特徴的な部分を抽出した 146 本を 1 ノード(8 コア)で実行したときの性能向上率の分布。6 倍以上が 10%、4〜6 倍が 25%、2〜4 倍が 28%、2 倍未満が 28%、性能向上せずが 10%。) - 図 2 では 146 本の 90% で性能が向上し、10% は 6 倍以上だった。向上率が低いプログラムの多くは、自動並列化されるループの粒度が小さい。その場合は自動並列化のコア数を設定し、適切なコア数とプロセス数のバランスで実行させる - **高機能バリアインタフェース(3.3 節)**: 計算ノード間の集合通信を速めるため、FX1 で汎用インターコネクトの拡張として実現した高機能スイッチの機能を Tofu 上に実装した。通信の高速化と、通信制御のオフロードによるプロセッサ負荷の低減という 2 つの効果がある **図 3: 高機能バリアインタフェースの実行時間** ![[_attachments/oubutsu-2011-80-7-590/fig03-barrier-interface-time.png]] (図 3. ノード数 0〜768 に対する縮約演算とバリア同期の経過時間(μs)。ソフトウェア実装は 768 ノードで 50μs を超えて増え続けるのに対し、高機能バリアは 10μs 未満にとどまる。) - 図 3 では 768 プロセスで、ソフトウェア実装に比べバリア同期が 6.7 倍、縮約演算が 7.5 倍に速くなった。非圧縮流体解析コードの姫野ベンチマーク(XL サイズ)では、図 4 に示すように、処理量が一定のため並列数を増やすとスケーラビリティが鈍るにもかかわらず、VISIMPACT と高機能バリアの効果で通信時間が減り、高並列まで維持された **図 4: 姫野ベンチマーク(XL サイズ)のスケーラビリティ** ![[_attachments/oubutsu-2011-80-7-590/fig04-himeno-scalability.png]] (図 4. コア数(軸は 1,000〜100,000)に対する性能比。図の読み取りでは最右点付近で、VISIMPACT なしは 5 前後で頭打ち、VISIMPACT ありは 11 前後、VISIMPACT あり+高機能バリアは 17 前後(いずれも概数)。) - **OS ジッタ対策(3.4 節)**: 計算ノードでは、使い勝手と汎用性を重視して汎用 OS の Linux を動かす。計算プロセス以外にもシステム監視やファイルシステムなどのプロセスが動き、計算プロセスから見ると処理の途中への割り込み(ノイズ)となって性能のばらつき(OS ジッタ)が起きる。逐次計算では平均値だけが問題になるが、並列計算ではプロセス間の同期が繰り返されるため遅延が蓄積し、実行時間が大きく延びる - 並列度と OS ジッタの関係は、Bertsimas-bound のモデル(文献 4)で実行時間の上限値を求めた。「一般 Linux」は一般の Linux サーバで観測された長いノイズを用い、計算粒度(同期間隔)を 1ms と 10ms とした。並列度が数千を超えると、ノイズによる実行時間の増加が大きくなる(図 5) - 「京」の OS では、長いノイズを 50μs 以下、平均ノイズ率を一般の Linux の 1/10〜1/100 の水準である 10^-4 にする。加えて、FX1 で実績のある協調スケジューリングを導入する。OS ノイズの発生源が協調して一斉に動くと、並列数 N への影響を効果的に減らせることが知られており、Hoefler らがシミュレーションで効果を確認している(文献 5)。この機能は高機能バリアインタフェースを使って実現した **図 5: OS ジッタの影響** ![[_attachments/oubutsu-2011-80-7-590/fig05-os-jitter-impact.png]] (図 5. 並列度に対する実行時間比。軸右端付近で、一般 Linux は同期間隔 1ms が約 8、10ms が約 3。「京」目標は 1ms が約 2、10ms が約 1.3(いずれも概数)。「京」目標は達成値でなく目標値の曲線である。) - **ファイルシステム(3.5 節)**: 必要な並列 IO 性能は現状の約 100 倍で、外部との相互接続性も重要なため、大規模・高性能に対応するオープンソースのクラスタファイルシステム Lustre をベースに開発した。各 IO ノードに独立した 1GB/s のファイル装置を結合し、これを 1000 台規模で並列動作させて 1TB/s 級のファイル IO 性能を狙う。1000 台規模での IO スケーラビリティを保つため、ジョブ用ファイルシステム(ローカル)と一般ユーザー用(グローバル)を分け、一般ユーザーの IO とジョブの IO を隔離する。各計算ノードの IO は直下の IO ノードへ出し、IO 処理時間を短縮する - **チューニング機能(3.6 節)**: 負荷の不均衡は巨大システムほど影響が深刻で、見つけること自体も難しい。そこで負荷バランス解析ツールを新たに開発した。従来のツールは同期待ち時間が通信時間に含まれて不均衡を測りにくかったが、本ツールは実行時間を演算時間・通信時間・通信同期待ち時間に分けて測り、演算の負荷バランスと同期待ちを区別して表示する。加えて、Tofu の各構成要素に混雑状況の統計カウンタを置いて常時読み出せるようにし、通信の混雑を避けるため、通信を多く行うプロセッサ群を近くへ置く RMATT(Rank Map Automatic Tuning Tool)を開発した。RMATT は、並列プログラム実行時に採取する通信ログを解析し、プロセッサ群の配置を自動で最適化する ## 新規性 - 本稿は「最近の展望」欄の解説であり、個々の技術の新規性を先行研究と比較して論じる論文ではない。読み取れる位置づけは次の 3 点である - 米国のペタスケールアプリケーション分析を設計要件へ反映するという開発方針(1 章、2 章) - スケーラビリティを、通信・IO の時間、処理遅延と不均衡、阻害要因の可視化という 3 課題へ分解し、要素技術を対応づける整理 - FX1 で実現済みの VISIMPACT と高機能スイッチ機能、協調スケジューリングを、8 コアと Tofu 向けに引き継いで拡張した点 - 先行 source との対応: 同じ富士通は 1990 年代に、単段クロスバー結合の分散メモリ型ベクトル並列機 VPP500 を作っていた([[@1999__Parallel Computing__Development of supercomputers in Japan - Hardware and software]])。集合演算・同期を点対点網から分ける発想は CM-5 の制御網([[@1992__SPAA__The Network Architecture of the Connection Machine CM-5]])や BG/L の専用網([[@2005__IBM JRD__Overview of the Blue Gene／L system architecture]])にも見える。ただし本稿は、高機能バリアが専用の同期網か Tofu の共有リンク上かを明記していない ## 評価の設定 - 本稿は実験の節を持たない。評価の記述は 4 つで、いずれもシステム完成前の 2011 年 3 月の受理時点のものである - 多重転送の転送性能(1 多重 4.7GB/s、4 多重 15GB/s)は実測と明記される - 146 本のプログラムを 1 ノード(8 コア)で動かした VISIMPACT の効果(図 2) - 高機能バリアの実行時間(図 3、768 プロセス)と姫野ベンチマーク XL(図 4)。実測かシミュレーションかは本文に明記がない - OS ジッタは Bertsimas-bound のモデルによる実行時間の上限値の計算(図 5)であり、「京」の曲線は目標値である ## 実験結果 - 転送: 4 多重で 1 多重の 3 倍以上(4.7GB/s から 15GB/s) - VISIMPACT: コア間バリア約 0.1μs でソフトウェアの 1/20。146 本の 90% で向上、10% は 6 倍以上(図 2) - 高機能バリア: 768 プロセスでバリア同期 6.7 倍、縮約演算 7.5 倍(図 3)。姫野ベンチマーク XL では、VISIMPACT なしが頭打ちになるのに対し、併用で高並列まで伸びる(図 4) - OS ジッタ: 並列度が数千を超えると一般 Linux では実行時間の増加が顕著になり、目標の「京」では抑えられる(図 5) ## 考察 - 著者は、OS ノイズの低減と OS 間の協調による時間軸上のノイズの隔離で、使い勝手(汎用 Linux)と性能を両立できると考える - 「京」で 100 万コア級の超並列計算の基盤技術が確立されると期待する。一方、2018〜2020 年に来ると言われるエクサスケール時代は 1 億コア級が想定されるため、さらなる技術革新が必要だと結ぶ ## 強み / 弱点・課題 - 強み: スケーラビリティの阻害要因(通信、IO、処理遅延、不均衡)を 3 課題に整理し、要素技術との対応を 4 ページで見渡せる。数値は 1/20、6.7 倍、7.5 倍、90% など具体的で、FX1 からの継承関係も分かる - 弱点・課題: ベンダー自身の解説であり、比較対象や条件(ノード数、ベンチマークの規模、測定か計算か)の記述が薄い。図 4 と図 5 は数値が本文に無く、図の読み取りに頼る。図 5 の「京」曲線は目標値で、達成は本稿では示されない。完成前の記述のため、実機での結果は別の資料が要る