３.システムソフトウェア 前節の通り、エクサスケールへ向けて起こるさまざまな制約を満たすためにアーキテクチ

ャが変化することが必然となる。ノードあたりの演算器の数の増加やメモリ階層・ネットワ

ーク階層の複雑化は不可避であり、コンポーネント数の増加によって平均故障間隔(MTBF)が無視できない程度に短くなると予想されている。また、計算機の性能の制約条件もトランジ

スタ数から電力へと移ってきており、計算機のコンポーネントごとの電力の把握と制御が必

要となってきている。 このように複雑化する環境下においてハードウェアとアプリケーションの橋渡しをするシ

ステムソフトウェアの果たすべき役割は重要であり、さまざまな方面での研究開発が望まれ

ている。研究開発の過程では、実装のメモリおよびオーバヘッドにおけるスケーラビリティ

の確保が強く要求されており、API における互換性の維持・標準化への貢献も必要となる。

本節ではこれらシステムソフトウェアにおける研究開発項目とロードマップについて記述す

る。 3.1 オペレーティングシステム

ヘテロジニアス 従来のスカラ型のプロセッサの性能/電力効率では ExaFlops を 20MW という電力で達成で

きない。そこで、電力あたりの性能の優れた GPGPU などのアクセラレータや演算特化型の

プロセッサを従来型スカラプロセッサと組み合わせるヘテロジニアスアーキテクチャが有望

である。組み合わせ方には PCI-express や Infiniband を用いてノード単位で結合する方法と、

チップ内または QPI, HyperTransport などノード内で結合する方法がありうる。 しかし、異種のプロセッサを組み合わせた場合ユーザへの見せ方を再考する必要がある。

プログラミングモデル、メモリ空間の共有・非共有、プロセッサ間通信レイテンシ、など使

い方と得られる性能を踏まえながら、OS の提供する機能を設計していく必要がある。プロセ

ススケジューリングにおいても、スカラプロセッサ上プロセスと演算プロセッサ上のプロセ

スを密に同期させる機構が必要であるなど、演算プロセッサを含めたプロセスモデル、プロ

セス管理モデル、ロードモジュール形式、プログラムロード方式などの検討が必要である。 OS 自身においてもヘテロジニアス対応が必要である。演算特化のプロセッサではファット

な OS の要求するスカラ性能を十分に発揮できない。そこで、汎用 OS 機能はスカラプロセッ

サで実行し、アプリケーション実行に特化した HPC 向け LightWeight OS を演算プロセッサ

で実行する。このように HPC 向けに OS を再設計する必要がある。アプリケーションは両者

間で分散もしくは演算プロセッサ上で実行する。I/O サービスや割り込み処理などもスカラ

プロセッサにオフロードする検討も必要である。この場合 I/O スループット志向のアプリケ

ーションは演算プロセッサ、数値演算主体のアプリケーションは演算プロセッサで実行する。 大規模並列 今後単体プロセッサコアの大きな性能向上は見込めず、チップ内およびシステム内のコア

数が激増していく。従来の OS は高々数 10 コアまでを意識して、かつ単体ノードに閉じた設

計がされており、ノード内並列性、ノード間並列性を向上していく必要がある。 ノード内においては、アプリケーションが数千～数万のプロセッサコアでスレッドを動作

させる。このときに各プロセッサコアに OS が割り込み等で介入すると性能外乱となる。こ

れらのジッタの削減が重要な技術となる。そのためにはヘテロジニアスで述べた演算プロセ

ッサ専用 LightweightOS 等により、I/O やデーモンなどの外乱要因をスカラプロセッサにオ

フロードする必要がある。 また、ノード内、システムワイドにおいて非常に多数のスレッドが動作するため、スレッ

ドの高速同期機構、切り替え機構をハードウェアの協力を得て実現する必要がある。ネット

ワークとの関係においても、従来のようにネットワークパケットが到着してプロトコル処理

をしてからターゲットのスレッドをスケジュールし wakeup するのではなく、ネットワーク

参考資料 2 ロードマップ未定稿 1

パケットが到着するとその足でブロックされていたスレッドが実行されるような機構が必要

とされる。 耐故障 数〜100 万ノード規模システムに対して、全システムのチェックポイント・リスタートな

ど、従来の隠蔽型耐故障で対応することは、そのデータ量や故障頻度（MTTF）を鑑みると

非現実的であり、アプリケーションと協調した Fault Resilience システムの実現が理想的であ

る。そのためにはノード内のハードウェアおよび OS 内部の障害情報を Fault Resilience フレ

ームワーク（ランタイム）に通知するための API を提供する必要がある。 一方で、アプリケーションの改変が不可能であったり、システムをパーティショニングし

て小規模なジョブを実行したりする場合には、システムソフトウェアレベルで故障を隠蔽す

ることも依然必要である。隠蔽型耐故障の大規模対応として、半導体ストレージや不揮発メ

モリを用いたチェックポイント・リスタートの高速化が挙げられる。また、仮想計算機技術

を用いることで、ノード間の移送が容易になり、障害回復や負荷分散に対する柔軟性の向上

が見込まれる。しかし、仮想化による性能低下が問題となるため、得失の評価や軽量な仮想

化技術の開発が求められる。 ノード内ヘテロ化に伴い CPU コアが OS 実行用と演算用に分離することを想定しており、

各コアへの OS 機能の割当てと耐故障に対するモデル化がまず必要である。耐故障の観点か

ら見ると、故障がどちらのコアで起こったかによってジョブ継続性への対応が異なる。演算

コア故障に対しては、チェックポイント・リスタート等による再実行が可能なので、ランタ

イムシステムと連携してジョブを継続実行する。一方、OS コア故障に対しては、ソフトウェ

ア対応のみならずハードウェアの冗長化が必要と考えるが、コスト増に見合う効果が得られ

るかは要検討である。実用化にあたっては、より低コストかつ軽量な冗長化技術の開発が必

要である。 メモリ 各種メモリウォールを打破するためのメモリアーキテクチャ、プログラミングモデルの実

現のために、API 定義を含めた OS サービスを最適化することを目指す。OS が関連する研究

項目としては、コアローカルメモリ、ヘテロジニアスアーキテクチャ対応、不揮発メモリ等

の新規メモリテクノロジの活用が挙げられる。 ローカルメモリについては、アプリケーションからの常に安定した性能を確保できる静的

な領域獲得を行うアプローチが有力である。これを実現するためのメモリの獲得、マッピン

グの API の定義をする他、コンテキストスイッチ時の動作等についての設計を進める。 ヘテロジニアスアーキテクチャについては、異なるアーキテクチャ間での共有メモリ領域

の獲得 API の他、一貫性保証の方式等の各種 API の定義を行うことに加え、ポータビリティ

を考慮した ELF 形式を拡張もしくは置換するような実行モジュールの形式の標準化提案も重

要となる。合わせてリンカやデバッガ等のツール類の実現方法の検討も重要な鍵となる。 また、今後 HPC システムでも実用レベルとなる新規のメモリテクノロジの活用方法につい

ての検討は非常に重要である。特に MRAM, FeRAM のような不揮発メモリについては、チェ

ックポイント・リスタートの高速化、消費電力削減、マイクロリブートの高速化等の有望な

用途が考えられ、積極的に活用研究を進めるべき分野だと考える。

線表 年次 取り組み項目 2011 OS アーキテクチャの基本設計

2012 2013

フルシステムシミュレーションによる資源管理のスケーラ

ビリティ評価。大まかな API の定義。シミュレーションに

よるメモリアーキテクチャの性能評価

2014 2015

ノード間通信、スレッド管理、メモリ階層管理の API の詳

細化。 ロードモジュール形式の策定。

参考資料 2 ロードマップ未定稿 2

2016 2017

電力管理、耐故障の API の詳細化。小規模プロトタイプシ

ステムでの実装、評価。 2018 2019 実システム上での評価、調整

3.2 ランタイム

大規模並列性への対応 大規模並列における課題としてノード間の通信の実装があげられる。通信可能性のあるノ

ード群がそれぞれ非同期通信用のバッファを確保していてはメモリ使用量が莫大となる。し

かし動的に確保していては性能が出ない。機能と性能バランスを考えて通信方式を設計する

必要がある。マルチコアアーキテクチャの普及に伴い、多数ある CPU コアのうちの一部を通

信専用コアとして確保し、通信処理をすべてそのコアで行う手法が現実的になってきている。

通信専用コアを用いることで、非同期集合通信のようなより複雑な通信処理を効率よく実行

することが可能になると考えられる。また、通信を割り込みによって制御することでデータ

を利用するコアに行わせて、コアレベルで細分化したメモリ階層上に効率的にデータを配置

する手法も考えられる。これらの通信プリミティブ実装技術の取捨選択および組み合わせに

ついて検討する必要がある。 従来のシステムでは、プログラムの性能チューニングに必要な程度の精度で事前にプログ

ラムの挙動を予測可能であったため、コンパイル時最適化や、ランタイムシステム導入時の

調整等、静的な最適化が主流であった。しかしエクサスケールシステムでは、並列度が数億

並列を超える上、ノード内及びノード間の階層構造の深化によってプロセスやスレッドの配

置による性能の変動が大きくなるため、現実的な時間での静的最適化が困難となる。また、

エクサスケールシステムではコスト面の制約により、特にインターコネクト上の通信衝突に

代表される資源の競合が頻発するようになる。この資源競合の発生頻度や性能への影響を事

前に見積もることは困難である。そこでエクサスケールのランタイムシステムでは、実行時

の状況を考慮した動的な最適化技術が重要になる。既に、集団通信のアルゴリズムを動的に

選択する STAR-MPI や、実行中に負荷の均等化を図る Adaptive MPI 等、様々な動的最適化技

術の研究が進められているが、それらの多くは実行時の情報のみに依存しており、大規模な

システムではオーバヘッドの影響が深刻になる。そのため、エクサスケールシステムに向け、

静的な情報と動的な情報を活用した、より高度な最適化技術の研究開発が求められる。静的

な情報としては、インターコネクトのトポロジ情報や割り当てられたノードの形状の他、プ

ログラムの通信パターンや通信と計算の比率等のコンパイル時に得られる情報が考えられる。

これらの情報と、実行時に得られる負荷バランスやインターコネクトの混雑状況等の情報か

ら、総合的な最適化の方針を決定することが出来る。具体的な最適化の対象としては、パタ

ーン通信やライブラリ関数のアルゴリズム選択、プロセスやスレッドの配置、負荷均等化、

各種性能パラメータの調整、等が考えられる。なお、これらの技術は、ハードウェアの構成

や言語処理系、数値計算ライブラリの技術動向に応じた開発が求められるため、これらのレ

イヤとの連携が必須である。

ヘテロジニアスアーキテクチャの活用 また、ヘテロジニアスアーキテクチャの普及に伴い、アクセラレータ間通信の効率化につ

いても検討する必要がある。GPU のように機能が限定されているアクセラレータでは、直接

他ノードへの通信を行うことができないため、一旦 CPU 側にデータを転送したうえで通信を

行う必要があるが、これをシームレスに行う機構が必要となってくる。また、Intel の MICに代表される比較的高機能なアクセラレータではアクセラレータ上のスレッドの一部を通信

専用にしてその上で通信を行うという方向性も考えられる。また、これらのアクセラレータ

では従来のプロセッサに較べてキャッシュサイズが小さいため、キャッシュを活用するため

にも同一のコアで計算と通信を行うことも検討する必要がある。 さらに、ヘテロジニアス化とともに実行コンテキストの数が増大した実行環境下では、ア

プリケーションのデバッグが従来のシングルスレッド環境やホモジニアス環境に比べて困難

になってきている。アクセラレータにおいても必要な粒度で実行を止めてメモリ情報を取得

でき、多量の実行コンテキストを無理なく追跡可能なデバッグ環境の構築が必要である。

参考資料 2 ロードマップ未定稿 3

電力管理 OS とランタイムシステムで連携しシステム全体の電力最適化を行うことを目指す。そのため

に利用可能な（細粒度）電力制御パラメータの取得と設定、および電力データを取得するた

めの API を定義する必要がある。制御例として、CPU の Dynamic speed scaling（DVFS な

ど）や Dynamic Resource Sleeping（パワーゲーティングなど）、未使用メモリへの電源供給

を止めるなどが考えられる。ランタイムシステムではこれらの API を用いて電力制御ポリシ

を定義し、電力バジェットの制約を満たしながらアプリケーションの実行を行う透過的フレ

ームワークの提供を行う必要がある。 生産性 性能や機能を計算に特化したプロセッサコア、またはアクセラレータ（以下、アクセラレ

ータ等）上で動くプログラムから通信や I/O を発行するための仕組みの確立に取り組む必要

がある。アクセラレータ等からの I/O の可否はハードウェアの仕様に依存するが、新たな

API を定義した上で、ハードウェアが I/O 機能を提供する場合はその機能を利用し、提供し

ない場合はソフトウェアエミュレーションを行う等、ハードウェア構成の差異を吸収するソ

フトウェアレイヤーを提供して統一的なアプリケーションプログラミング環境を提供する必

要がある。 アプリケーションの性能測定のためにハードウェアに依存しない性能データ収集のための

API を定義し、ハードウェアが取得する性能データをユーザーアプリケーションや性能解析

ツールに提供する必要がある。ただし、基本的には既存ツールである PAPI のアプローチで

不足はなく、新たなハードウェアに対応する実装を行う必要はあるものの、新たな研究課題

を含むものではない。 アクセラレータ等で動作するプログラムのデバッグ機構を提供する方法を確立する必要が

ある。デバック機能として一般的なブレークポイントの設定やステップ実行がアクセラレー

タ等でも提供されるか否かは不明であるが、少なくとも異常発生時にメモリの状態を保存し

て安全にプログラムを停止するコアダンプの機能はすべてのハードウェアで利用可能となる

よう、ハードウェア設計者と協調して研究開発を進める必要がある。 既存のプログラムとの互換性を確保するため、POSIX 互換インタフェースの提供も検討す

べきである。特にスクリプト言語を利用できるようにすることは、利用者の生産性を高める

ことにつながることが期待できる。完全な POSIX 互換インタフェースを提供してすべての既

存プログラムを動作可能とする方式と、スクリプト言語の処理系や言語のクラスライブラリ

を新たな API で再実装してスクリプト自体の互換性を確保する方式の利害得失を検討する必

要がある。

線表 時期 研究項目 -2012 数 Peta スケール計算機での基礎的な性能解析

非同期集合通信機構の実装 -2013 定型通信コードの動的最適化技術

非同期通信 GPU 間通信の最適化

-2014 数十 Peta スケール計算機での検証 並列・ヘテロジニアス環境向けデバッガの開発

-2015 定型コードでの通信及び計算の動的最適化技術 高機能アクセラレータによる通信の最適化

-2016 数百 Peta スケール計算機での検証 非定型コードの動的最適化技術

-2017 アクセラレータ内での計算と通信の同コア実行 -2018 Exa スケール計算機での検証

Exa スケール計算機のハードウェアに向けた動的最適化技術の改良

3.3 I/O

参考資料 2 ロードマップ未定稿 4

エクサスケールのスーパーコンピュータシステム上で高性能な I/O を実現するための技術

的課題としては、主に以下のようなものがあげられる。 新デバイスの有効活用 ストレージアーキテクチャ I/O ミドルウェア プログラミングモデル・ランタイムシステム 外部連携

ここでは、これらの研究課題に対するロードマップについて包括的に述べる。 3.3.1 ヘテロジニアスアーキテクチャ エクサスケールシステムでは、アクセラレータの利用により 10 億並列級のプロセス・ス

レッドからの I/O が発生しうると目されている。しかし、現在のファイルシステムは、この

ような膨大な数や量の I/O 数を処理することはできない。特に、既存の並列・分散ファイル

システムでは I/O スループット性能向上に特化したものが多い一方、将来はそれだけでなく

IOPS 性能が必要とされると予想される。これは、特に、大規模データ処理アプリケーション

で顕著であり、上位のプログラミングモデルとランタイムと連携した並列分散ファイルシス

テムが求められる。例えば、大規模データ処理のためのプログラミングモデル・ランタイム

システムにおいては、局所性を考慮した大規模データ処理ソフトウェアを簡便に記述できる

ことが求められる。これらのことは、既存の MapReduce やワークフローシステムでも一部

実現されているが、エクサスケールのシステムにむけては、演算アクセラレータなどの新し

いデバイスにおいては性能特性・挙動が異なるため、アクセラレータ間のデータ転送や局所

性の考慮したタスクのスケジューリングなどの実現が必要である。 3.3.2 メモリ

Solid State Drive(SSD)や Storage-Class Memory(SCM)といった新たなメモリデバイスをスト

レージ階層に持ち込む際の次のような課題の解決に向けては，データを配置するストレージ

階層や記憶デイバスを管理することが可能なファイルシステムやデータストアの研究を進め

ていくことが考えられる。データの配置を管理することでストレージシステムにおける電源

制御の柔軟性を高めるとともに，故障耐性を加味していくことができると考えられる。 新記憶デバイスを使用したストレージ階層の形成 新記憶デバイスの故障耐性に対する考慮 データの配置を管理するファイルシステムやデータストアの実現に向けては，エクサスケ

ールシステムに求められる I/O 性能や電力を想定した際に，計算クライアントも含めシステ

ムのどこに新記憶デバイスを持ち込み，新記憶デバイスを使用したストレージ階層において

データをどのように取り扱うかといったアーキテクチャの検討が必要になると考えられる。 3.3.3 大規模並列 現在のファイルシステムは、10 億並列級のプロセス・スレッドからの I/O を処理すること

はできない。また、これまでの POSIX 準拠の I/O API や MPI-IO のような I/O インタフェー

スだけでは、アプリケーションで扱いやすいデータレイアウトや I/O パターンを記述できな

いため最大限に I/O 性能を達成できない。このため、アプリケーションが発行する膨大な数

や量の I/O を最適化し、ファイルシステムとの性質の差異を吸収することで、ファイルシス

テムの性能を最大限に発揮できるようなミドルウェアの開発が必須となる。 3.3.4 電力 エクサスケールシステムでの I/O においても消費電力の削減が重要な課題である。例えば、

エクサスケールシステム上では、データ転送、特に、オンチップとオフシップ間のデータ転

送がシステム全体の消費電力の向上に大幅に寄与することが問題となるため、これまで以上

に、アプリケーション層での局所性の考慮が重要になると考えられる。また、ストレージを

参考資料 2 ロードマップ未定稿 5

構成するデバイスコンポーネント(例えば HDD)の数も多く複雑になるため、コンポーネント

単体の消費電力削減も重要な課題である。一方で、近年、SSD や SCM など不揮発性のデバイ

スも登場していることから、これらのデバイスの活用も重要ようである。特に、現在不揮発

性メモリを使用した現在不揮発メモリを使用したファイルシステムの研究等は進められてい

るが，エクサスケールシステムのストレージシステムに向けては電力消費等の側面も考慮し，

新記憶デバイスを使用したストレージ階層を形成する必要がある。

3.3.5 耐故障 エクサスケールマシンにおいては、計算ノードやストレージを構成するコンポーネント数

が多くなるので必然的に故障率も高くなる。従って、エクサスケールシステムミドルウェア

の研究開発においても，性能向上だけに特化するのではなく、故障への対応も含めて検討す

る必要がある。例えば、大規模データ処理のプログラミングモデルやランタイムシステムは、

大規模データ処理のためのソフトウェアコンポーネントを簡便に連携できつつも、計算環境

の故障に対処するために、エラー診断や耐故障性の実現が求められる。また、並列ファイル

システムにおいても、RAID などの冗長性を実現する手法だけでなく、ファイルの複製作成

なども検討が必要である。また、SSD や SCM などの新記憶デバイスにおいても、ディスクデ

イバスと比較して I/O 性能や電力消費の面で優れている反面，記憶素子の書き込み回数につ

いては劣っている。新記憶デバイスの寿命を延ばすウェアレベリング技術の研究は進められ

ているが，エクサスケールシステムのストレージシステムに向けては大量の I/O が発生する

ことを考慮し，故障耐性の検討が必要である。 3.3.6 線表

年次 取り組み項目 2011 新記憶デバイス階層を組み込んだ I/O アーキテクチャの検

討 2012 2013 新記憶デバイス階層を活用する I/O モデルやプログラミン

グモデル・ライブラリ・ランタイムシステムの開発 2014 2015 新記憶デバイス階層へ配置するデータを管理するファイル

システムやデータストアの開発 2016 2017 新記憶デバイス階層へ配置するデータの先行制御機能等の

開発 2018

3.4 システム管理・外部連携 エクサスケール HPC システムにおいてはネットワーク構成の制約により、複数のジョブを実行する

際にはジョブを構成するタスクを適切なノードに割り当てる必要がある。また、ジョブ実行中のノード故

障への対処機構も必要となる。このためにはノード状態の監視機構が求められるが、監視機構により

システムに負荷をかけることは極力避ける必要がある。本章ではエクサスケールシステムに求められ

るジョブやタスクのスケジューリング機構、資源監視機構についての研究課題をまとめる。また、エク

サスケールシステムへのデータ入出力、外部システムと連携した計算実行のための研究課題につい

てもまとめる。

ジョブ・タスク管理 ノードに対するジョブ/タスクの最適な割り当ては、本質的に困難な問題であるが、これまではノード数

/ジョブ数が十分小さかったため、総当りによるアドホックな手法が十分に機能していた。また、スケジ

ューラ本体がシングルスレッドで同期的なネットワーク通信を行う古典的なプログラムであることも珍し

くなかった。エクサスケールシステムでは、ノード数が膨大になるため、スケジューラ自体のスケーラビ

リティが問題になる。さらに、ノードにはネットワークやメモリ構成、特定のデータへの距離などのさまざ

参考資料 2 ロードマップ未定稿 6

まなヘテロ性が存在し、ジョブが個々のノードへ要求するプロパティにもヘテロ性が存在する。このヘ

テロ性によってスケジューリングはさらに困難になる。

スケーラビリティ エクサスケールシステムにおいては、スケジューラ自身のスケーラビリティを確保するこ

とが非常に重要になる。一体として動作する多数のタスクから構成される大規模ジョブだけ

でなく、大量の独立したタスクから構成されるいわゆるアレイジョブに関しても十分な配慮

を行う必要がある。 このために、ノード群、タスク群を類似性によってグループわけし、グループ単位でスケ

ジューリングを行うギャングスケジューリングやなんらかの経験的手法を導入し、効率的な

スケジューリング手法を確立する。また、スケジューラ自身のマルチスレッド化、通信の非

同期化、必要があれば複数ノードにまたがる並列化などの手法を用いて、スケーラビリティ

を確保する。 資源記述記法の導入

ヘテロな環境での割当を実現するためには、まずノードの機能やジョブの要請を明示的に記

述する記法を導入する必要がある。 ネットワークを意識したスケジューリング

利用者の要求に応じた IO、ネットワーク帯域制御、トポロジを意識した配置が必要である。 データアフィニティスケジューリング

データインテンシブな計算を行う場合、データと計算ノードの位置が近くなるように配置

（データアフィニティスケジューリング）するほど、ネットワーク帯域の消費量の削減と計

算効率の向上ができることが知られている。エクサスケールシステムでは分散ファイルシス

テムを利用し、計算ノード数は 100 万を超えるため、データアフィニティを考慮することが

重要となる。そのため、ファイルシステム側でジョブの利用するデータの所在を知るための

API を規定するとともに、それを利用したジョブの割り当て、またそれを上位ワークフロー

エンジンに伝えるための API が必要となる。 アレイジョブと密結合ジョブの共存

スケジューリングの対象となる並列ジョブは、アレイジョブと密結合ジョブに大別され、そ

れぞれに対する要請は全く異なる。スケジューラは、これら 2 つの違いを意識し、双方を効

率的にスケジューリングする必要がある。 モニタリングと連携したノードの死活管理と FT 機能と連携した対処

エクサスケールシステムにおけるジョブの実行では、ソフトウェアおよびハードウェアコン

ポーネントの数が爆発的に増大することから、ジョブの実行中にいずれかのノードもしくプ

ロセスが停止する可能性が非常に高い。ジョブスケジューラはモニタリング機能と連携して

停止したノード、プロセスを検出し、FT 機能と連携しジョブに指定された方針にしたがった

対処を行う必要がある。具体的には、新たなノードを自動的に追加割当てし、チェックポイ

ントからリスタートするなどである。 ワークフローエンジン

複数のジョブから構成されるワークフローを実行するワークフローエンジンが必要である。

ワークフローエンジンはスケジューラと連携し、各ジョブの出力ファイルの位置などを意識

したスケジューリングをスケジューラに依頼する。

線表 年次 取り組み項目 2011 スケジューリング手法の検討、スケーラブルな実装手法の

検討、ワークフローエンジンアーキテクチャの検討 2012 2013 データ、ネットワークに対するアフィニティスケジューリ

ングの検討。 2014 2015 スケジューラとワークフローエンジンプロトタイプの設計

と実装 2016 2017

スケジューラ及びワークフローエンジンの性能検証と改良 2018

参考資料 2 ロードマップ未定稿 7

モニタリング・ロギング モニタリング、ロギングにより収集される情報は、ハードウェアの故障やその予兆の検知、リソースの

利用状況に適応的に動作するジョブスケジューラあるいはアプリケーションで利用される。利用目的

によって収集される情報は異なっても、これらを統一的に扱うための機構が必要になる。以下にこの

分野での研究開発項目をまとめる。

● 収集すべき情報の決定

エクサスケールシステムにおいて、収集すべき情報およびその精度は、これまでの規模のシ

ステムとは異なってくるのかを検討する必要がある。アプリケーションの動作や性能に大きく

影響を与えるものとして例えば以下のようなものが考えられるが、他に、エクサスケールシス

テムに固有な情報も必要に応じて追加する。また、情報の追加や制度の変更を容易に行う

ことが可能なインタフェースを設計する。

● ハードウェアの故障やエラーの情報

● ネットワークの利用率や使用電力の情報

● 通信ログ、性能カウンタ等から得られる情報

● フィードバックのための機構

ジョブスケジューラやアプリケーションに対して、収集した情報を提供するための機構が必要

となる。このための、共通基盤となるインタフェースの設計・構築が必要である。

また、システムや性能の理解を助けるための情報可視化技術についての研究を進めることも

必要である。

● 低負荷な情報収集

モニタリング・ロギングではシステムへの負荷を最小限にすることが求められる。ノードごとに

かかる負荷についてはこれまでの研究の延長として考えることができるが、情報の集約は、ノ

ード数の増加に伴い、より効率的に行う必要がある。情報集約の最適化については、エクサ

スケールシステム向けの通信ライブラリとの協調が必要となる可能性がある。

ノードごとにかかる負荷の削減については、OS との協調が必要となる。

● 莫大なデータの扱い

エクサスケールシステムにおいては、収集されるデータの量も莫大になる。このため、重要な

情報を失うことなくデータ量を大幅に削減する技術を研究することが必要である。また、デー

タマイニング、あるいは検索についても研究を進める必要がある。

加えて、ストレージ資源の節約と対応の即時性の両方の観点から、継続的に生成されるデ

ータをリアルタイム的に処理する技術も必要とされる。

参考資料 2 ロードマップ未定稿 8

外部資源連携 外部資源連携では、HPC システムと外部の計算資源・ストレージ資源を連携して HPC システム利

用者の計算実行支援を行うシステムの研究開発項目をまとめる。具体的には HPC システムに対して

外部のデータアーカイブから高速かつセキュアにデータをステージインする機構や、HPC システムの

処理容量を超えた計算要求がある場合にクラウド等の外部計算資源を動的に確保し利用する機構な

どを実現するための研究開発を行う。外部資源連携は HPC システムに特化した研究項目ではない

が、計算資源やストレージ資源が少数のデータセンターや計算機センターに集約される傾向にある

ため、センター間の強固な連携が可能となり、その環境を活用した高効率かつ高信頼な資源連携を

実現するための研究開発が必要である。

● オンデマンドネットワーク経路・帯域予約技術

複数サイトの計算資源やストレージ資源のコアロケーションのために以前より研究開発され

ていたが、個別に開発されていたネットワーク資源管理システム間でのインターオペラビリテ

ィの実現が必要である。また HPC システムと外部資源間での経路・帯域確保のための共通

API を定義する必要がある。

● 外部計算資源連携

HPC システムをマルチテナントで運用する場合、全利用者のジョブ実行要求がシステム供

給計算量を超える場合がある。この際に一定条件を満たすジョブ（性能を求めない、ランタイ

ム制約の少ない等）を外部の計算機に実行させることで、全体のスケジューリング効率が上

がる可能性がある。また逆に、外部計算機資源の一部として HPC システムを使えるシステム

を実現する（例: Amazon Cluster Compute Instance としてエクサスケール HPC システムを

利用する）ことで、HPC システムの稼働率・課金収入向上につながる。このようなシステムを

実現するには、動的かつ透過的に外部計算資源を確保する技術が必要であり、また、異種

外部資源を統一的に操作する API も必要となる。この際、外部資源から HPC システムの情

報の一部を参照しなければならない場合もあるかもしれないが、必要最低限の情報のみに

する、専用セキュアチャネルによる通信を行う等のセキュリティ対応が必要である。

● 外部ストレージ連携

外部のクラウドや大規模データアーカイブと HPC システム間のデータ入出力については、イ

ンタフェース、効率、利便性の点での研究課題がある。現在多数あるクラウドストレージには

共通インタフェースが無いため、異種資源を統一扱うためのインタフェースが必要になる。イ

ンターネットの WAN 帯域の向上により、HPC システムや大規模データセンター間では Long

Fat Pipe(LFP)の活用がさらに重要になる。マルチストリーム転送や TCP/IP によらない転送

手法等 LFP 環境でも効率の良い転送手法が必要である。またデータの複製を複数の外部

ストレージに分散して管理することで、データへの到達性や転送性能の向上につながるが、

複製配置アルゴリズムやメタデータ管理の耐故障性機能向上のための研究開発が必要であ

る。HPC システムから外部ストレージに対してのアクセス方法についてもステージングだけで

なく、利用者の用途に応じて計算ノードから透過的・階層的にアクセスできる仕組みが必要

になる可能性がある。

● 広域ワークフローエンジン

ワークフローエンジンに求められる基本機能としては上記ジョブ・タスク管理で挙げた項目と

共通するが、広帯域高遅延環境を意識したタスク分配が必要となる。動的なネットワーク資

源確保技術、外部計算資源確保技術との協調も必要である。

線表

参考資料 2 ロードマップ未定稿 9

3.5 耐故障性 Fault Resilience フレームワーク １）アプリケーションレベル耐故障コーディング支援機構[rt] アプリケーション側で全耐故障機能を実装するのは実行コスト的には理想であるが、実

装コストが大きく、これを軽減するミドルウェアの提供が必要である。アプリケーショ

ン実装者が、アプリケーション内に限った耐故障機能実装ができるフレームワークの作

成、これを更におしすすめ、変数の用い方や、スレッド/プロセスの役割等を注釈として

記述をするだけで適切な耐故障機能を提供するようなミドルウェアが期待される。また、

自動並列化、PGAS 系のプログラミングツールに見られる注釈文もアプリケーション側

からの情報として積極的に利用する等、各種ミドルウェア内での協調も考慮し、アプリ

ケーション実装者のコストを削減していく。これらの注釈文からの情報は、耐故障機能

が必要なデータ範囲や、復旧する必要がある機能の絞り込み、並列プロセスの一貫性制

御等に利用される。本課題に関しては、プログラミング言語レイヤとの綿密な協調が必

要である。 4th 2011FY – 2nd 2012FY Fault Resilient 機能記述フレームワークとユースケースに合わせ

た利用法の提案 3rd 2012FY – 2015?? ミドルウェア復旧インタフェースの提案と実装 3rd 2012FY – 2015?? ユーザコードから耐故障アドバイスの抽出を行う手法の検討・実装 ２）効率的な情報伝播機構と Fault Resilient システムミドルウェア[os][io][rt] 耐故障機能を効率的に行うための肝は、システムを構成する各コンポーネントの状態

についてシステムレイヤを越えて横断的に開示することにより、適切な耐故障機能を構

成することである。これらの情報は莫大な量になる可能性が高く、計算リソースに影響

しないようなるべく効率的に伝播する必要がある。このため、伝播方法や必要な情報の

選別について検討する必要がある。さらに、やり取りされる情報の規格を統一する必要

もあり、情報の規格の統一には故障モデルを明確に定める必要がある。 さらに、効率の良いミドルウェア自身の耐故障性と共に、レイヤ外の他コンポーネン

トからの情報を受入、開示といったコンポーネント間連携が行えるよう、ミドルウェア

自身も改変していく必要がある。 4th 2011FY – 2nd 2012FY 故障モデルの策定と規格の検討 3rd 2012FY - 2015?? 耐故障機能に合わせた効率のよいイベント伝播基盤 2014?? – Fault Resilient ミドルウェアの開発

参考資料 2 ロードマップ未定稿 10

課題：隠蔽型耐故障の高効率化 ３）従来の耐故障機能の大規模対応[os][rt] アプリケーションユーザが耐故障機能の恩恵を得るためには自らアプリケーションを

改変するか、アプリケーション実装者の対応を待つ必要がある。前者の手段が提供され

ていないバイナリコード提供アプリケーション等の場合、ユーザが環境として導入する

事のできる、従来のシステムソフトウェアレベル耐故障が必要となる。このため、アプ

リケーション実行時の通信パターンや、メモリアクセスパターンを利用するなど、シス

テム側から能動的にアプリケーション（他コンポーネント）を解析することによりシス

テムソフトウェアレベルの耐故障機能も効率化する必要がある。どの要素がどのように

耐故障機能のアドバイスとして寄与するかの選定は１）の成果を利用する。 4th 2012FY – 2015?? システム情報から耐故障アドバイス作成を行う手法の検討・実装 課題：耐故障基礎技術および Fault-Aware なリソース管理技術 ４）故障を考慮したリソースマネージメント[mgmt.][rt] ジョブスケジューリングを始めとするリソースマネージメント機能について、故障を

考慮する必要があり、今日までにジョブワークフローの復旧といった研究が行われてき

た。これらを更に推し進めると共に、故障したリソースの代替リソースの確保や、冗長

化リソースの管理を行う必要がある。また、これらのリソース管理を元に、故障を加味

したより効率のいいリソース配分が実現可能となる。 4th 2011FY – 1st 2012FY 故障頻出環境において管理すべきリソースの検討 2nd 2012FY – 2014?? 必要なリソースに関する適切なマネージメント技術の開発

参考資料 2 ロードマップ未定稿 11

1.プログラミング研究開発ロードマップ エクサスケールにおけるプログラミング言語および環境は、前述した課題の解決を支援し、

かつ性能と生産性を両立することが必須である。現在においても異種プロセッサを内包した

ノードからなるヘテロジニアススーパーコンピュータ等のプログラミングでは、生産性の大

幅な低下が問題になっている。これは適切な抽象化を提供するプログラミングモデルの欠如

が原因である。また、電力効率を重視したアプリケーション開発を支援するために、消費電

力の計測および制御のための API が必要になるが高性能計算環境においてはそのような機能

を備えた標準 API は未だ未整備である。同様に耐故障性、10 億スレッド規模の大規模並列プ

ログラミング、より複雑かつ深い階層のメモリシステム等に起因する課題に対してアーキテ

クチャ、システムソフトウェアおよびアプリケーションとの協調のもと解決するプログラミ

ング環境について以下にその研究開発ロードマップを示す。

1.1 要素技術研究項目

1.1.1 ヘテロジニアスアーキテクチャ

担当： 滝沢 課題 ヘテロジニアスアーキテクチャ化したシステムには、従前の汎用プロセッサに加えて演算

に特化したアクセラレータが搭載されている。アクセラレータは汎用プロセッサとは全く異

なるアーキテクチャを持ち、そのプログラミングモデルはそれぞれのアクセラレータのハー

ドウェア構成を抽象化するために特化されたものとなっている。そのようなプログラミング

モデルにも基づくアプリケーション開発においてはアクセラレータのハードウェア構成を強

く意識したプログラミングが必須となり、アプリケーションの可搬性や性能可搬性が著しく

低下する。 さらに、汎用プロセッサとアクセラレータとでは処理の得手不得手が異なるため、それを

考慮して適材適所で処理を割り当てる必要がある。このため、従来より並列処理に求められ

てきた問題分割に加えて、それぞれのプロセッサの得手不得手を考えて処理の割り当てを考

える必要がある。このような状況においては、汎用プロセッサとアクセラレータの組合わせ

が変わるたびにプログラムを大きく修正する必要があり、アプリケーションの可搬性や性能

可搬性を損なうという大きな問題となる。また、プロセッサ間の役割分担の変更に伴ってデ

ータの配置方法も再検討が必要となる。 現在の対策・現状 現在、最も広く普及しているアクセラレータは GPU であり、そのプログラミング環境とし

ては CUDA[1]が事実上の標準である。CUDA で開発されたプログラムは、NVIDIA 社の GPUでしか実行することはできない。この可搬性の問題を解決するために、OpenCL[2]がアクセ

ラレータを利用するアプリケーション開発の標準 API として提唱されている。しかし、そこ

で想定されているハードウェアモデルは現在の GPU を強く意識しており、将来のアクセラレ

ータのハードウェアを適切に抽象化できるとは限らない。また、各種アクセラレータを利用

するための API は OpenCL によって統一されつつあるものの、その性能を引き出すために必

要な最適化技法はそれぞれ異なっている。このため、アクセラレータごとに異なる性能最適

化技法を適用する必要があり、アプリケーション開発の生産性が著しく低下する。さらに、

異種複数のプロセッサへの処理の割り当ては、システム構成ごとにアプリケーション開発者

によって経験的に決められている。CUDA や OpenCL の API を直接的には記述しないプログ

ラミング環境として、コンパイラ指示行に基づいて C/C++や Fortran のコードを CUDA や

OpenCL へと変換する環境も整備されつつあり、今後さらに普及することが予想される[3]。しかし、多くの場合、利用するアクセラレータを意識してコンパイラ指示行を挿入する必要

参考資料 2 ロードマップ未定稿 12

がある。すなわち、その重要性にも関わらず、可搬性や性能可搬性を向上させるための研究

の方向性は未だ確立されていない。 今後のアプローチ ポストスケールやエクサスケールの時代に利用可能な多種多様なアクセラレータを使いこ

なすためには、各種アクセラレータを統一的に利用可能なプログラミングインタフェースや、

自動最適化・自動チューニングに必要な情報を記述するためのインタフェースの開発が求め

られる。また、現在主流のアクセラレータである GPU における課題を考慮すると、異種複数

のプロセッサへの処理の割り当てを自動化する研究アプローチも期待される。また、FPGA等のプログラマブルロジックアクセラレータの利用が HPC 分野で一般化するためには、ハー

ドウェア構成を設計・記述することなく、アプリケーションから利用可能となることが強く

求められる。 2012～2017 年には、それぞれのアクセラレータに特化して設計されてきたプログラミン

グインタフェースが共通化される時期と予想され、現在の OpenCL 等やその拡張によって標

準的なプログラミング環境が確立されることが期待される。汎用プログラミング言語(C++など)を使ってアクセラレータを利用するための研究も盛んに行われ、その成果によって標準的

なアプリケーション開発者によるアクセラレータ利用が現在よりも容易になることが予想さ

れる。ただし、インタフェースを共通化してもアクセラレータごとに求められる性能最適化

技法を共通化することは困難であるため、その作業を支援するための研究も重要となる。ア

プリケーション開発者の指示に基づく半自動最適化や自動チューニングの技術を研究し、性

能最適化作業の労力を軽減するといった研究のアプローチ等が考えられる。 システム構成ごとに汎用プロセッサとアクセラレータの役割分担が変化することを考える

と、その役割分担の自動化や半自動化を前提とし、システム構成を極力意識させないプログ

ラミングモデルの設計・開発が強く求められる。 さらには、アクセラレータが独自のメモリ空間を持っている場合には、汎用プロセッサと

アクセラレータとの間のデータ転送の自動化や高効率化も重要な研究課題である。 2018～2020 年には、現在とは全く異なるアーキテクチャに基づくアクセラレータが利用

可能となっている可能性がある。例えば、HPC 分野におけるプログラマブルロジックアクセ

ラレータの利用の可能性も模索され、OpenCL 等、他のアクセラレータと同様のプログラミ

ングインタフェースでプログラマブルロジックアクセラレータを利用するための研究開発が

予想される。この時期には、消費電力などの制約から、汎用プロセッサに加えてアクセラレ

ータを搭載するシステム構成が現在よりもさらに一般的になると予想される。このため、ア

クセラレータの機能や性能が発展し、現在とは異なるアーキテクチャとなったとしても、異

種複数のプロセッサを適切に使いこなすための標準プログラミングインタフェースの重要性

は変わらず、むしろ増すものと考えられる。

1.1.2 大規模並列性

担当： 田浦 課題 エクサスケールマシンにおいては、非常に多数のノード、ノード内の多数のコア,コア内の

SIMD 並列性、という階層的かつ膨大な並列性を有効活用する必要がある。また、ノード内

の並列性についても、消費電力を抑えるためにクロックを下げ、並列性によってスループッ

トを向上させるアクセラレータ(GPU や MIC)を有効に活用する必要がある。さらに、ノード

内のメモリも NUMA 構成となり、コア内、ソケット内、ソケット間のメモリアクセスコスト

の違いを意識したプログラミングが必要になる。ノード間通信もフルバイセクションネット

ワークは期待できず、ノード間の通信コストも非均質になる。 比較的最近までは、ノード内のコア数も少なく、MPI を用いて 1 プロセスを 1 コアにマッピ

ングする、いわゆる FlatMPI モデルを用いれば並列性を uniform に記述しつつ、SMP クラス

タや MPP に対応させることが可能であった。これによりプログラムの可搬性とある程度の

性能可搬性を享受してきた。しかし、ノード内の並列度増加、アクセラレータの役割の増大、

コアあたりのメモリの減少などにより,それは昨今すでに困難になっており、エクサスケール

マシンにおいては不可能である。

参考資料 2 ロードマップ未定稿 13

現在の対策・現状 (プログラミングの困難さへの対応) このような大規模かつ、階層的な並列性を持つマシン上で提供するプログラミングモデル

として、一つには各レベル用に設計された最低限の抽象化を直接プログラマに露出し、それ

ら全てを陽にプログラミングさせるというアプローチが考えられる。しかし、均一かつ規則

的な格子上の計算など一部の問題を除けば、あらゆるレベルでの並列化、およびその最適化

を明示的かつ個別に行うのは今日においてもすでに困難であり、エクサスケールにおいては

ますます困難が予想される。従って大規模な並列処理をサポートするプログラミング言語や

その処理系には、統一的な記述からあらゆる階層の並列性を抽出し、プラットフォームに適

したマッピング・実行を行うことが求められる。 (大規模並列用に設計されたアルゴリズムのサポート) また、エクサスケールへ向けて、アルゴリズムおよびアプリケーションも,大規模並列化を

見据えて変化・進化をすることにも注意が必要である。並列性の源が一階層のデータ並列性

ではなく、アルゴリズム自身が階層的な並列性を持ち,通信量の少ない粗粒度の並列性を抽出

するように再設計されていくことが予想される(例: 櫻井-杉浦による部分空間への分割による

固有値計算など)。また,アプリケーション自身も複数の並列化されたプログラムを組み合わ

せて構成されるなど、階層的な並列処理を活用していくことが予想される。そのような階層

的、かつ一部に粗粒度並列度を取り入れたアプリケーションに対して、現在主流の SPMD 方

式は、入れ子並列性、階層的な並列性を素直に表現できないばかりでなく、複数の並列プロ

グラムの部品化、複数の並列プログラムの合成が行えない、粗粒度な処理に対してさえ動的

負荷分散が行えないなどさまざまな問題点がある。 今後のアプローチ [プログラミングの困難さへの対応] (アプローチ 1) 領域固有、アルゴリズム固有な言語(Domain Specific Language; DSL)の設計 直交格子差分法、有限要素法、粒子法など、科学技術計算で多用される解法で,計算機へのマ

ッピング方法がある程度よく知られているものがある。そのようなドメイン(ないしアルゴリ

ズム)では、統一的な並列性の記述から、計算機の個々の階層への適切な分割、マッピングを

行う言語処理系を作ることは実現可能性の高いアプローチである。 (アプローチ 2) 汎用性を持った基盤言語の設計 DSL は、あるドメインやアルゴリズムのための、効率的な実装方式(領域分割,負荷分散)を、

処理系に組み込むことで、各階層での個別のプログラミングを不要にし、大規模並列プログ

ラミングの負担を軽減する。一方でサポートされた定型的な処理からはみ出したプログラム

を記述することが出来ず、適用ドメインを広げるごとに、実質的には言語の再設計、再実装

が必要になる。現状の DSL では、木構造や適用格子などを用いるアルゴリズムで必須な、動

的なデータ生成,階層的な並列性などをサポートしておらず、汎用化が必要である。 汎用並列言語は、分散データ構造、並列ループ、タスク生成などの原始的な要素機能をベー

スに言語を設計していくアプローチである。それらの原始的な要素を組み合わせて、文字通

り汎用的な処理が記述されるため、記述されているアルゴリズムの「全体像(holistic view)」に関する組み込まれた知識がなく,最適な実行を行うのは困難である。適切に抽象化された性

能モデルをいかにプログラマに露出させることができるかが鍵となる。 [大規模並列用に設計されたアルゴリズムのサポート] MPI などの SPMD 型の並列処理や、ドメイン固有言語で書かれたデータ並列処理を,複数タ

スク並列に実行できる、SPMD 型並列に加えてタスク並列をサポートするフレームワークや、

複数の並列プログラムを組み合わせるスクリプト言語や Glue 言語などのアプローチが考えら

れる。 今後 2012 年から 2015 年頃まで関連する要素技術として、(1) 領域固有型アプローチの拡

大・汎用化：これまでよりも広範なアルゴリズム領域に対する領域固有言語の設計および各

種アーキテクチャ上でのスケーラビリティ検証・デモンストレーションが進む。(2) 汎用的

高水準言語の発展：メモリ階層の抽象化, 通信の最適化に焦点を当てつつ, 汎用性を持った言

語が進み、それらの各応用領域, 様々なアーキテクチャ上でのデモンストレーションが進む。

それにより生産性と性能のトレードオフに関する知見が蓄積する。もちろん領域固有型アプ

ローチと汎用的高水準言語の研究は互いに孤立して進むのではなくお互いの知見を共有しつ

参考資料 2 ロードマップ未定稿 14

つ発展する。2015 年以降、ターゲットとしてエクサスケールマシンを明確に見据えた処理

系の開発、普及・標準化を目指した言語の設計が行われる。

1.1.3 複雑化するメモリアーキテクチャへの対応

担当： 平石 課題 現在の多くの HPC システムは分散メモリ型であるため、アプリケーションプログラマは

MPI 等を用いて各ノードのメモリ間の通信を考慮したプログラムを書かなければならず、既

に大きな負担となっている。また最近では、各ノードに GPU を搭載したヘテロジニアス構成

をとるシステムも増えつつある。このようなシステムでは、メインメモリと GPU 間のデータ

のやりとりも CUDA などを用いて記述しなければならない。将来的には、HPC システムのさ

らなる大規模分散化に加え、ノード内においても、メモリウォール問題やプロセッサの多コ

ア化にともないキャッシュコヒーレンシを自動的に保つことが困難となる問題などに対応す

るため、キャッシュメモリのさらなる高階層化・複雑化が進むと考えられる。また、省電力

のために、メモリの一部の電力を動的に止める、NVRAM を活用するなどの機構も提案され

ている。そのようなシステムの性能を引き出すためには、これまで以上にメモリアーキテク

チャを意識したプログラミングをしなければならなくなり、生産性の著しい低下が懸念され

る。 現在の対策・現状 このように複雑化するハードウェア環境においてプログラマの負担を軽減するための言語

の研究としては、過去には High Performance Fortran（HPF）がある。これは、データ配置や

通信をプログラマから完全に隠蔽するというものであったが、コンパイラ最適化の限界で満

足する性能を達成できないなどの理由により、現在ではあまり使われなくなっている。最近

では、X10、Fortress、UPC、XcalableMP などの PGAS 言語に見られるように、データ配置や

通信をプログラマに意識させつつ、それらの表現を抽象化することで記述を簡便にしようと

する研究が主流である。なお、これらの一部はヘテロジニアス環境にも対応している。ただ

し、これらの言語もまだ開発中であることや、既存のアプリケーションからの移行コストの

問題、MPI や CUDA を直接用いたプログラムと比較して必ずしも満足する性能が得られると

は限らないという問題もあり、広く用いられるには至っていない。複雑なキャッシュメモリ

の階層を意識しやすくするようなプログラミングモデルはまだあまり一般的ではないが、メ

モリ階層を含む抽象マシンを扱うプログラミングモデルである Sequoia++などの試みがある。 今後のアプローチ 今後 2012 年～2017 年頃においては、既に直面しているメモリの大規模分散化やヘテロジ

ニアス化に対応するため、すでに研究開発が行われている PGAS 言語、ヘテロジニアス環境

対応言語の実用化に向けた努力が必要となろう。具体的には、言語の標準化や優れたコンパ

イラ最適化などの実装レベルでの洗練化、ライブラリの充実やアプリケーション分野との共

同研究などによる移行支援が挙げられる。また同時に、将来のキャッシュメモリの高階層化

等、さらなるハードウェアの複雑化に備えた言語の提案も行っていく必要がある。具体的な

言語設計は、その時にどのようなハードウェアアーキテクチャが提案されているかにも依存

するが、例えば、ノード内のメモリにおけるデータ配置やメモリの一部電力供給停止などを

システム任せではなくプログラムで（より明示的に）操作できるようにする言語機構の開発

が必要となる可能性がある。 2018 年～2020 年頃においては、上述の新しいハードウェア環境に対応して開発された言

語の実用化を進める必要がある。

1.1.4 耐故障

担当： 窪田 課題

参考資料 2 ロードマップ未定稿 15

エクサスケールのシステムでは、システムの大規模化によって MTBF が非常に短くなり、

数分程度となる可能性もある。この場合、チェックポイント/リスタートによる故障への対応

では、チェックポイント間隔よりも故障間隔が短くなって処理が進まなくなってしまう、さ

らには、チェックポインティングに要する時間が故障間隔を上回ってしまうこともありうる。 また、システムが複雑化し、故障要因が判明しづらい場合が増加することが予想される。

そのため、故障への対処を局所化することができず、システム全体がチェックポイントまで

戻ってリスタートすることになり、故障からの復旧のオーバヘッドが大きくなる。 さらに、半導体の微細化によってソフトエラーなどの増加することも予想される。ソフト

エラーなどは、ECC のようにハードウェアレベルで故障を検知して対処することができず、

ジョブは一見正常に終了するが、結果に誤りが含まれることになる。このような難検出故障

が故障全体に占める割合も増加すると予想されるため、その対処が望まれる。 現在の対策・現状

現在、システム全体の定期的なチェックポインティングと故障時のリスタートが実現され、

BLCR[5]や SCR[6]などのミドルウェアも用いられるようになってきている。しかし、システ

ムの大規模化や MTBF が短くなることにより、チェックポインティングに要する時間が増大

しつつある。また、MPI などのシステムソフトウェアレベルで耐故障性のサポートが試みら

れており、標準化も進められている[7]。 今後のアプローチ エクサスケールのシステムにおいて、耐故障のための解決策として、ハードウェアからア

プリケーションプログラムまでの全システムスタックにおける耐故障対応が考えられる。特

にアプリケーションプログラマの耐故障対応への積極的な関与が重要となる。 第一に、アプリケーションプログラムからシステムソフトレベルの API などによって、チ

ェックポイント/リスタートを制御することが望まれる。故障時のリスタートに必要最小限の

データを、どのタイミングで保存しておくべきかを明示的に指定することで、保存すべきデ

ータ量を削減し、チェックポインティングのオーバヘッドを削減する。また、ノード間通信

が発生しないタイミングをチェックポイントとして指定することで、リスタートに要するオ

ーバヘッドも削減できる。 第二に、アプリケーションレベルでしか検出できないような故障が発生した際に、故障の

発生をシステムソフトウェアに対して API などによって通知し、必要があればシステムレベ

ルのロールバックなどで対処することが望ましい。 これらの故障に対応するための記述をすべてアプリケーションプログラムが負うことにな

ると、プログラム開発の生産性の低下につながりかねない。そこで、耐故障に関連する機能

をプログラミング言語レベルで記述するためのフレームワークを提供することが必要となる。

これによって故障に対処するためのオーバヘッドを小さくして性能低下防ぎつつ、プログラ

ム開発の生産性の低下も抑えることができる。 今後、2011 年～2015 年頃までは、以下に挙げるような技術課題の解決が必要となる。

第一に故障の検出のその伝播手法が挙げられる。まず、故障個所がノード全体、ノードの

一部、ネットワークなど、どの個所なのかを特定することになる。さらに、故障情報をどの

範囲に伝播させ、どの範囲までを故障とみなすのかを言語レベルから特定できるようにする。

そのため、MPI などのシステムソフトウェアのレイヤとの間で故障情報を伝播するプロトコ

ルの標準化が必要である。 第二にチェックポインティングと故障からの復旧手法が挙げられる。故障情報を一定のロ

ーカルな範囲(ノード内、複数ノードからなるグループなど)にしか伝播させず、そのローカ

ルな範囲で故障から復旧し、範囲外へ故障の影響を与えずオーバヘッドを少なくする故障の

囲い込み(confinement)が必要となる。このようなローカルな復旧のため、故障個所に応じて

ロールバック対象をプログラミング言語レベルで指定する手段が必要となる。また、チェッ

クポインティングの高速化のため、イメージの保存先として SSD や不揮発性 RAM の利用が

考えられる。これらのデバイスを明示的に指定できるようにする必要がある。 第三に耐故障性をソフトウェアやハードウェアのレイヤ間で隠蔽するか隠蔽しない(開示す

る)かに応じた対応が挙げられる。PGAS や DSL などの言語では、上下のソフトウェアレイヤ

間で故障を隠蔽する/しないに応じた対応が必要となる

参考資料 2 ロードマップ未定稿 16

システムソフトウェア・ハードウェアレベルで故障を隠蔽する/しない アプリケーションに対して、言語レイヤで故障を隠蔽する/しない システムソフトウェアやハードウェアレベルで故障を隠蔽しないモデルの場合、言語レイヤ

でチェックポインティングや復旧方法を指定する手段が必要である。具体的には、プログラ

ム上でのチェックポイント個所、チェックポイント時のバックアップ対象、複製(replication)すべき対象、故障からの復旧対象(MPI の全プロセス、MPI の一部のプロセス、ノード内のス

レッドなど)、復旧方法(故障ノードのマイグレーション、ノード内の遊休コアの利用など)などの指定が必要となる。 第四にプログラミングモデルに応じた耐故障性のサポートが挙げられる。SPMD に比べ、

Master-Worker モデルや Map Reduce モデルなどは、耐故障性をサポートしやすい。これら

のモデルでは、タスクレベルの再実行を言語レベルでサポートすることが望ましい。また、

先天的耐故障対応アルゴリズム(Fault Oblivious Algorithm)を言語レベルでのサポートするこ

とも考えられる。 2016 年～2020 年頃には、関連技術の進展による耐故障性の進展、具体的には故障予測を

利用したマイグレーションが挙げられる。故障予測精度の向上により、故障前にマイグレー

ションすることでオーバヘッドを削減することが見込まれる。言語レイヤで故障予測情報の

取得、それに基づくマイグレーションを実行できることが必要となる。

1.1.5 電力

担当： 八杉 課題 消費電力はポストペタスケール／エクサスケール計算の重大な制約であり、ハードウェア

に関する新しい装置や技術だけでなく、ハードウェアとソフトウェアが協調して電力制約下

での性能最大化を実現する必要がある。 現在の対策・現状

2011 年現在、ソフトウェアからみたハードウェアの消費電力/消費エネルギーに関する標

準インタフェースは整備されているとは言い難い。 今後のアプローチ 近い将来、情報取得と(ハードウェアの各種電力つまみに関する)電力設定に関する標準イ

ンタフェースの整備が進む必要がある。まずはオペレーティングシステムやミドルウェアな

どのシステムソフトウェアが主体となり、標準インタフェースを利用して、さまざまな時間

的・空間的スケールで電力制約を満たすための制御(電力予算の配分)と電力制約下での性能

最大化(の試み)を行うと考えられる。関連技術となるハードウェア・オペレーティングシス

テム間インタフェース仕様としては ACPI 仕様 (執筆時点では Revision 4.0a [4])が知られてお

り、Revision 4.0 (2009 年)から加わった消費電力情報取得や消費電力ハードウェア上限設定

の仕様は今後の標準インタフェースのベースとなる可能性が高い。 システムソフトウェアが持つさまざまな時間的・空間的スケールでの電力制約や実際に消

費した電力/エネルギーに関する情報を、アプリケーションが取得するための API の整備も

早急に(例えば 2014 年)必要である。また、電力に関するパラメータ設定のための API も整

備される必要がある。電力標準 API の整備により、電力を考慮したプログラミングモデルが

提供可能となる(例えば 2015 年)。このとき、複数のアプリケーションがシステム全体やノ

ード等を分割使用する場合は、アプリケーション毎の消費量をその内訳(計算コアやメモリな

どの各部での消費)とともに取得できるとよい。 アプリケーションから事前に/直前に(次のフェーズなどの)情報(例: メモリインテンシブに

切り替わること)をシステムソフトウェアに提供可能とすることで、フェーズの切り替わりに

素早く対応できる。API の直接利用、注釈の利用、コンパイラが解析した結果の利用、など

によって情報を伝えるプログラミング／コンパイル技術が考えられる。(2015 年) 消費電力の削減や消費電力あたりの性能最大化のためには、エラーが増加しないぎりぎり

の低電圧制御や、温度(熱)制約ぎりぎりの(オーバー)クロック周波数制御を、フェイルセー

フに行うことが考えられ、結果として各コアや各ノードの性能ばらつきの拡大を許容するよ

参考資料 2 ロードマップ未定稿 17

うな電力制御も考えられる。そのためには、性能ばらつきの問題を予測や負荷分散により軽

減するプログラミング／コンパイル技術が重要となる。(2015-18 年) 消費電力の削減には、不揮発性メモリ(NVRAM)のような新しい省電力デバイスを特性を(う

まく／自動)利用するプログラミング／コンパイル技術も重要となる。特に、不揮発性メモリ

は、物理メモリが占める電力消費の割合は決して低くないこともからも重要である。その際、

(メモリ/ディスクの)キャッシュや仮想記憶のように意識しなくてもプログラムは動作するが、

意識あるいは忘却してよいような形で局所性を高めることで性能向上するという場合や、性

質の異なるメモリが異なる部分アドレス空間に存在するように見せるという場合が考えられ

る。(2017 年) プログラミング／コンパイル技術から電力制約問題への最も重要なアプローチの一つは、

電力制約下において性能最適な計算方法を選択することである。そのためには、各選択肢に

おいて消費電力あるいは性能がどうなるのかを予測するモデルが必要となる。選択可能な項

目としては、プログラムにおける各種パラメータをはじめ、データの移動・保持と計算のト

レードオフ、CPU と GPGPU の利用コア数や電力予算比率等がある。(2015-19 年) さらに動的に変化する電力制約に追従して計算方法を選択し直すことができるアプリケー

ション(すなわち、電力つまみを持ち、かつ、取得した電力制約情報に基づき適応するアプリ

ケーション)を作成するためのプログラミング／コンパイル技術も重要となる。(2015-19 年)

1.1.6 生産性（ツール）

担当： 中尾 課題 エクサスケールシステムは非常に大規模かつ複雑な構成であるため、その上で高い性能を

発揮するアプリケーションを効率的に開発するためには、プログラムのデバッグ作業および

性能チューニングを支援するツールが重要である。 現在の対策・現状 並列数が増えるにつれ、デバッグおよび性能チューニングに必要なログデータの総量およ

びデータ転送のバンド幅が大きくなるため、ログデータの削減に関する研究が活発になりつ

つある。具体例としては、並列アプリケーションの特性情報をもとにログデータの圧縮を行

う研究、アプリケーションのイベントに重要度を設定し確率的にログデータを取得する研究

などが行われている。さらにログデータを取得した後に、どう可視化してユーザに提示する

かについても重要である。ドイツのユーリッヒ研究センタで開発されている並列アプリケー

ション最適化ツール Scalasca およびその可視化ツール Cube は、ユーザが指定した範囲毎に

負荷率を色分けして表示することで、1 ペタフロップス級のシステム上で、約 300 万並列で

動作するアプリケーションのログデータの可視化を行い、その実用性を示している。しかし

ながら、エクサスケールシステムの並列数は 10 億のオーダと予測されているため、現状の

ツールではエクサスケールシステムに対応することはできない。そのため、ログデータの削

減および可視化についてさらなる研究が必要である。 今後のアプローチ 2012 年から 2014 年頃までは、少ない負荷でログデータを収集する研究、膨大なログデー

タの中から有用なデータを自動抽出するデータマイニングに関する研究などが重要になると

考えられる。また、生産性向上の点から既存資産を活用したいという要求がある。性能可搬

性を高めるため、数値計算ライブラリ等の自動チューニングの研究に加え、新しいハードウ

ェアに移行することを支援するツールの開発も平行して行う必要がある。 2015 年頃からは 100 ペタフロップス級のポストペタスケールマシンが開発され、エクサ

スケールシステムに向けて、実機と実アプリケーションを利用した研究が進むと考えられる。

また、エクサスケールシステムで動作する OS、ミドルウェア、数値計算ライブラリ、プログ

ラミング言語などのプロトタイプが利用可能になると考えられる。エクサスケールシステム

では、システムの大規模化によりハードウェアの MTBF が非常に短くなるためアプリケーシ

ョンが実行途中でエラー終了する、OS ジッタなどが原因で性能が期待していたよりも低くな

る、といったアプリケーション以外の不具合も考慮する必要がある。これらの問題を解決す

るために、ログデータを取得するためのインタフェースをレイヤ毎に定義し、そこから得ら

参考資料 2 ロードマップ未定稿 18

れたログデータを用いて問題箇所を自動抽出する、もしくはそれぞれのログデータを統合し

て可視化するといった、不具合の原因特定をサポートするツールの研究が行われると考えら

れる。また、情報取得のためのインタフェースを定義することにより、デバッグ作業および

性能チューニングのためのツールの可搬性を向上させることも必要であると考える。 2018～2020 年以降は、ポストペタスケールマシンで得た知見、例えば性能のボトルネッ

クになるパターンなどをデータベース化しておき、それを利用してエクサスケールアプリケ

ーションのデバッグ作業および性能チューニングを半自動化させることで、生産性を向上さ

せるなどの研究が考えられる。

1.2 想定プログラミング環境 上述の基礎研究を進展させることによりポストペタスケールおよびエクサスケールコンピ

ュータにおけるプログラミング上の種々の課題の解決が期待できる 。例えば、現状のアクセ

ラレータ利用技術では個々のアーキテクチャに強く依存した可搬性に欠けたプログラミング

が必要だが、上述の異種アーキテクチャ上の統一プログラミングインターフェイスの整備や

性能最適化のための自動チューニング手法の開発により可搬性、生産性の向上が期待できる。

同様に大規模並列性や深いメモリ階層を自然にかつ簡便に扱える記述法や、耐故障性、低電

力化のためのプログラミングを支援する記述法に関する基礎研究を進展させ、今後のアーキ

テクチャに対応したプログラミング環境構築のための要素技術を開発していく必要がある。 実システムにおいてアプリケーションプログラマが 上記要素技術を簡便に利用可能にする

ためには、個々の基礎研究に加えてそれらを統合したプログラミング環境を整備する必要が

ある。プログラミング環境として統合する方針に関しては、いくつかのアプローチが考えら

れる。以下、想定される統合プログラミング環境を 2 つ例示する。

1.2.1 アプリケーションドメイン特化型フレームワーク（丸山） プログラミング環境の例として、特定のアプリケーションドメインに特化した高い抽象度

を持った専用フレームワークが考えられる。これは特定のドメイン向けにライブラリやミド

ルウェア等のソフトウェアスタックをカスタマイズして提供し、それによりアプリケーショ

ンの簡潔な記述およびソフトウェアレイヤをまたがった最適化やアプリケーションドメイン

固有の最適化手法の導入による高い実行効率を狙ったものである。フレームワーク内に透過

的に自動チューニング等の各種最適化技術や耐故障技術を実現することが可能であり性能と

生産性の高い次元で両立が期待できる。 プログラミング環境としては性能、生産性、柔軟性、可搬性等を高い次元で実現すること

が理想的だが、一般的にはこれらはトレードオフの関係にあり相互のバランスを適切に考慮

した設計が求められる。今日の高性能計算プログラミング環境としては性能のみを重視した

環境や生産性のみを重視した環境は存在するが、より高い次元でそれらを兼ね備えた環境は

実現されていない。特に高性能を指向したハードウェアアーキテクチャを強く意識したプロ

グラミングではその低い生産性が課題となっているが、前述した今後の高性能計算システム

における問題点、特にヘテロジニアス構成や深いメモリ階層等によるプログラミングの複雑

さの増大によりその問題がより顕著になってきている。このような今後のアーキテクチャや

システム設計上の制約から来る課題に対して、ドメイン特化型フレームワークは汎用性に欠

けるもののその高い生産性により将来有望なアプローチの一つと言える。 しかしながら、ドメイン特化型フレームワークをポストペタスケールおよびエクサスケー

ルシステムにおけるプログラミング環境として実現するためには未だ以下の課題があり、そ

れらを解決する研究開発が今後望まれる。 フレームワークの柔軟性と最適化のトレードオフ フレームワークはより多くの種類

のアプリケーションに対応可能な柔軟性を備えるべきであるが、一般的には柔軟なソ

フトウェアアーキテクチャは特定のパターンに特化した場合に比べて実行効率に劣る

トレードオフが存在する。従って、フレームワークの設計には柔軟性と性能のトレー

ドオフを考慮した適切な制約条件を定義する必要があるが、その制約条件の制定は対

象ドメインに強く依存し自明ではない。

参考資料 2 ロードマップ未定稿 19

フレームワーク開発方法論の確立 高性能計算環境向けアプリケーション向けのドメ

イン特化型フレームワークは従来から存在するが、しかしながら依然としてその開発

方法論は確立されておらず、フレームワーク開発のコストが大きな問題となっている。

より簡便に高品質フレームワークを構成するためのソフトウェア工学的な研究開発、

特にそれを支援するソフトウェアコンポーネントの充実が強く望まれる。 将来のより複雑化・大規模化した高性能計算環境向けのアプリケーションドメイン特化型

フレームワークを実現するためには上記課題を解決するための基礎研究、及びそれと並行し

た実証のための研究開発を進める必要がある。まず、1 つ目の課題に関しては計算科学分野

との密な協力に基づき、性能を担保可能なアプリケーションドメインの設定を行う。これは、

今日の大規模計算科学アプリケーションを計算機科学的に抽象化する作業であり、アプリケ

ーションドメインに対する理解・学習が求められる。さらに、設定したドメインに対して実

際にそのフレームワークを設計し、具体的なアプリケーションを用いた実証評価を進める必

要がある。アプリケーションの現時点における並列化・最適化の如何に関わらず将来の大規

模計算環境を有効に活用していくためにはその都度人手による最適化が必要だが、その人手

による最適化に対してフレームワークへの移植コストが十分低くかつそれと同等の性能を達

成できなくてはならない。そのためには特に既存の高度に最適化された大規模アプリケーシ

ョンを参照実装として用い、それと同等の性能を高い生産性をもってフレームワークにより

実現可能であることを示すことが非常に重要である。 フレームワークの実証的な開発に並行して、その開発方法の確立に向けた研究が必要であ

る。今日スーパーコンピュータ上で用いられている計算科学アプリケーションは多岐に渡り、

それらをサポートするためには多くの種類のフレームワークを開発する必要がある。従って

フレームワーク開発のコスト削減を目的とした開発方法論の確立が求められる。フレームワ

ークには異種プロセッサ間のロードバランスや自動チューニングなど共通して備えるべき特

性が多く存在するが、それらを再利用性を有したフレームワークコンポーネントとして実現

することによって新規フレームワークの開発コストの削減が期待できる。また、対象アプリ

ケーションドメインの記述性向上のために専用プログラミング言語の有効性が確認されてい

るが、そのようなドメイン特化型言語（DSL）の開発を支援するためのコンパイラ技術に関

する研究も必要である。このようなフレームワーク開発を支えるソフトウェア技術に関する

研究開発を上述の単体フレームワークによる実証開発と共に進めることが必要である。 現在から数年後 ============ - 分野限定のアプリケーションフレームワークの開発およびその有効性の大規模スーパーコ

ンピュータ上で 実証 5 年後 ========= - アプリケーションフレームワークが成熟し、100PFLOPS マシンにおいてプロダクションと

して動作 - 同時にアプリケーションフレームワークそのものの開発方法論に関する予備的な実証 2018-2020 年 ============== - フレームワーク開発方法論が成熟し、新規フレーワークの開発が容易に。

1.2.2 アプリケーション進化支援への応用（滝沢） 本ロードマップでも随所で強調されているとおり、エクサスケール時代の高性能計算シス

テムでは超並列化や複合化がより一層進行し、現在よりもシステム構成がさらに複雑化する

ことが予想される。一方、現在一般的に開発・利用されているアプリケーションコードは、

そのような複雑なシステム構成を意識して記述されていない。したがって、現在のコードそ

のままの状態では、エクサスケールシステム上での高い実効性能の達成は期待できない。し

かし、システムの世代が変わるたびにアプリケーションやライブラリなどのソフトウェア開

参考資料 2 ロードマップ未定稿 20

発をやり直すことは非現実的であるため、既存のコードを何らかの方法で新しいシステム向

けに修正していく方法論が求められる。 このような動機から、既存のコードを出発点として新しいシステム向けのコードに段階的

に移行することを考え、その作業を支援するために上述の種々の要素技術を利用する研究開

発が想定される。例えば、高度に最適化された数値演算ライブラリやランタイムシステム、

および自動チューニング技術等でシステムの複雑さを可能な限り隠ぺいすることを前提とし、

それらの技術では隠ぺいしきれない差異のみをソフトウェア開発者がコード修正によって埋

めることが想定される。このためには、MPI や OpenMP、CUDA/OpenCL などの主要 API においては、現在の仕様から段階的に改善することでエクサスケール時代の問題解決を図るべ

きである。可能な限りインタフェースを変更せず、現在の API と互換性を保ちつつ透過的に

各種最適化機能や耐故障性を実現することが理想である。 アプリケーション開発者によるコード修正においても、比較的安全かつ容易にコードを修

正できるように様々なアプローチで支援ツールを提供する必要がある。例えば、コンパイラ

指示行や高度なエディタ機能(リファクタリング等)を提供することが考えられる。これらの

技術は個々で検討するだけでなく、上記の隠ぺい技術と併せて統合された一つの環境として

開発していくべきである。 しかし、既存のアプリケーションコードを出発点とし、新規開発を前提としないアプロー

チであることから課題や制約が数多く残されており、それを解決する研究開発が今後求めら

れている。 ソフトウェア進化の指針の確立 コードを整理・改善することで既存のソフトウェアを

進化させることを考える場合、既存のコードをどのような基準で見直し、どのような方

針で改善していくのかを示す指針が必要である。そのような指針を計算科学者と計算機

科学者の協働で体系化・明文化し共有する必要があるが、これまでにそのような共通認

識が確立されているとは言い難い。 コードの可読性・保守性と高性能の両立 可読性や保守性の高いコード開発の方向性と、

高性能を実現するコード開発の方向性は必ずしも一致しない。むしろ、高性能化のため

に特定のシステム依存のコーディングが求められ、可読性や保守性が低下することも多

い。このため、可読性・保守性と高性能の両立が可能なプログラミング開発の方法論や

その支援技術の確立が必要である。 ソフトウェアの進化を支援するためには、実用的な大規模アプリケーションを新世代のシ

ステム向けに修正していく作業において頻出するパターンをデータベース化し、それを一般

化することによってその効果的な支援方法を検討する必要がある。そのような現状分析と一

般化を目指す研究アプローチと並行して、ソフトウェア進化の作業コストを軽減するために

システムの複雑さを隠ぺいする抽象化技術の研究開発が必要である。そのような抽象化技術

を効果的に使うためのコード修正/再構成の指針を整備し、その指針に基づく既存アプリケー

ションの新世代システムへの段階的移行を支援する。 === いまから数年後 === コンパイラ指示行や既存言語・API の拡張など、既存のソフトウェアとの親和性の高いイン

タフェースから、1.1 節で述べられている要素技術を利用するための研究開発が求められる。

また、既存コードの維持管理作業および新システムへの移行作業において頻出するパターン

を整理し、その作業を支援するための技術およびツール群を開発する。さらには、それらの

技術を効果的に組み合わせて使うためのコード修正/再構成の指針を体系化する。 ＝＝＝5 年後＝＝＝ 実用的なアプリケーションを 5 年後の大規模化かつ複雑化が進行したシステム向けに移植

する作業を通じて、アプリケーションの進化を支援する技術の有効性を実証。 ＝＝＝2018 年~2020 年＝＝＝ システム構成の変遷に対応しやすいプログラム構成法およびアルゴリズム設計法が確立さ

れ、それに基づくソフトウェア開発の要素技術が共通基盤として提供される。その結果とし

て、エクサスケール時代の複雑なシステムへのコードの移植の支援が可能となる。共通基盤

自体もシステム変遷に伴って進化し続ける必要があることから、その共通基盤の進化の支援

が重要な研究課題となる。

参考資料 2 ロードマップ未定稿 21

1.3 まとめ (滝沢、中尾) エクサスケール時代に向けて HPC システムの構成は今後さらに複雑化し、性能が最重要視

される HPC のアプリケーション開発においてはシステム構成を意識することが避けられない

ことから、プログラミングの高度化やアプリケーション開発の生産性の低下が懸念されてい

る。さらには、電力や障害対策などの問題もより一層深刻化することが予想されている。本

節の前半では、それらの課題に対する現在の取組みと今後の研究ロードマップを述べた。 また、各課題を解決するための要素技術の研究開発に加えて、それらの技術を利用するア

プリケーションを開発するためのプログラミング環境も必要である。このため、本節の後半

では、アプローチの異なる想定プログラミング環境を 2 つ例示し、それぞれの研究ロードマ

ップを示した。 プログラミング言語やモデルの研究開発においては、それらの開発体制の確立と普及活動

も極めて重要である。 HPC アプリケーションは長期間に渡って利用・メンテナンスされるため、開発に用いられ

る言語は最低 10 年間の継続的な開発やサポートが保証されることが望ましい。国内におけ

る例では、文部科学省の支援を受け開発されている並列言語 XcalableMP の仕様策定および

開発は、多くの大学、研究機関、企業で構成された委員会により行われている。複数の機関、

特に企業の協力を得ることにより、中長期的な開発や保守管理を期待できる。 普及活動という観点では、開発されたプログラミング言語を web で公開・配布することは

もちろんのこと、実用的な大規模アプリケーションが開発可能であることを実証することが

効果的である。さらには、国際的な標準化活動や他の有用なソフトウェアとの連携機能を実

現することにより、世界規模でのコミュニティの形成を期待できる。また、マニュアル・チ

ュートリアルなどの整備や、メーリングリスト・プログラミング講習会・ワークショップの

開催などによるコミュニティ構築も普及のために重要である。 以上のように研究開発および普及活動を中長期的に継続するためには、安定的な予算や人

的資源に基づく持続可能な研究体制の確立が必要不可欠であると言える。我が国でもそのよ

うな研究体制を一刻も早く確立し、世界標準として広く受け入れられる優れたプログラミン

グ言語・モデルを数多く輩出することを目指すべきである。その結果として計算科学アプリ

ケーション開発の生産性を飛躍的に向上させ、我が国の学術界および産業界における優位性

を維持・発展させるための礎となることが期待される。

関連研究リスト [1] CUDA, http://www.nvidia.com/object/cuda_home_new.html. [2] OpenCL, http://www.khronos.org/opencl/. [3] OpenACC, http://www.openacc-standard.org/. [4] Hewlett-Packard, Intel, Microsoft, Phoenix, Toshiba: Advanced Configuration and Power Interface (ACPI) Specification, Revision 4.0a, http://www.acpi.info/ 2010. [5] Berkeley Lab Checkpoint / Restart (BLCR), https://ftg.lbl.gov/projects/CheckpointRestart/. [6] Scalable Checkpoint / Restart Library (SCR), http://sourceferge.net/projects/scalablecr/. [7] MPI 3.0 Standardization Effort, http://meetings.mpi-forum.org/MPI_3.0_main_page.php/.

参考資料 2 ロードマップ未定稿 22

1.はじめに 1.1 概要 本節は、エクサフロップスを達成する技術について数値計算ライブラリの観点からまとめ

たものである。以下に示す観点ごとに挑戦すべき技術項目とロードマップを記載した。 数値計算ライブラリに必要な技術、および数値計算ライブラリで使われる数値計算ア

ルゴリズムの観点（数値計算ライブラリ分野） 数値シミュレーションを行うためのミドルウェア、および分野を限定したプログラミ

ングで有効となるフレームワーク（数値計算ミドルウェア分野） 数値計算ライブラリ、および数値計算ミドルウェアで必要となる処理に対する自動性

能チューニング（数値計算ライブラリのための自動チューニング分野） 上記の分野において、重要となる技術項目を主項目とした。主項目を達成するに当たり、

必要となる細分化した研究開発項目を副項目とした。 副項目は、5 年後に達成すべき技術項目を副項目（短期）とした。達成するのに 5 年以上

必要とする技術項目、もしくは、現在、基礎研究すら開始されていない項目を副項目（長期）

とした。 主項目と副項目は、エクサフロップスを達成するための必要性、重要性について、以下の

ランキングをつけてキーワードを抽出した。 ☆、★、★★、★★★（→重要度が高い）

2011 年度の研究開発の進捗の度合いについて、以下のフェーズを記載した。 フェーズ I ：これから基礎研究を行うもの フェーズ II ：基礎研究が進行中のもの フェーズ III ：プロトタイプが進行中のもの フェーズ IV ：もうすぐ実用化の目途がつくもの 主項目の技術においてエクサフロップス達成のために、従来技術を適用することで展開で

きると思われる事項を＜既存技術＞とした。また、従来技術を単純に適用し展開するだけで

は実現できない事項は＜革新技術＞とした。 1.2 アプリケーション上の主演算の抽象化の重要性 数値計算ライブラリや数値計算ミドルウェア構築の目的は、できるだけ多くのアプリケー

ションの主要演算を抽象化することで、その機能と高性能実装を提供することにある。この

ことで、アプリケーション開発者のプログラミング生産性を格段に高めて、かつ高性能化を

実現する。できるだけ多くのアプリケーション上の主演算の抽象化をすることは重要である。 アプリケーションの主演算を、たとえば以下の尺度で分類し特性として抽象化することは

重要である。 計算機ノード内におけるメモリアクセスパターン 計算機ノード間の通信パターン 通信回数（通信レイテンシ）と通信量（通信バンド幅） I/O 性能（データアクセス頻度とデータ量） その他アプリケーションから抽出できる尺度 この尺度を用いた抽象化により、計算機ハードウェア構成方式、数値計算ライブラリや数

値計算ミドルウェアのインターフェース、数値計算のための自動チューニング機能、などの

構築指針を示すことは重要である。これらの尺度を実アプリケーションから抽出し、主演算

の分類することは、エクサフロップスを達成する数値計算ライブラリ構築のために重要であ

る。したがって、実アプリケーションでの主演算の分類に関する調査は重要課題となる。

参考資料 2 ロードマップ未定稿 23

2.数値計算ライブラリ分野 2.1 はじめに 数値計算ライブラリは、科学技術アプリケーションプログラムにおいて共通に使われる数

値計算プログラムをライブラリの形にまとめたものである。数値計算ライブラリには 線形方程式 固有値問題 高速フーリエ変換 乱数

などのルーチンが含まれている。 現在、大規模数値シミュレーションを行う際には、数値計算ライブラリの性能が実行時間

に大きく影響する。したがって、エクサフロップス級マシンにおいて高い実行効率を達成で

きる数値計算ライブラリを実現することは重要である。 エクサフロップス環境のための数値計算ライブラリが実現する機能としては以下が挙げら

れる。 ● アプリケーション開発者および利用者からエクサフロップス級マシンの複雑なシステム

構成が見えないように抽象化されたインターフェースを提供すること。 ● エクサフロップス級マシンの高い性能をできるだけ引き出すようなアルゴリズムおよび

実装手法を用いること。 本節では、エクサフロップス級マシンにおける数値計算ライブラリを実現する上で必要な

技術項目について述べる。 2.2 技術動向 図 2-1 に、数値計算ライブラリに関する技術マップを示す。図 2-1 から分かるように、

1990 年代後半から分散メモリ型並列計算機向けの数値計算ライブラリの研究開発が始まっ

ている。さらに、2005 年以降は GPU およびマルチコアアーキテクチャ向けの数値計算ライ

ブラリの研究開発が行われている。また、これらの数値計算ライブラリには自動チューニン

グ機構が備わっているものも多い。

数値計算ライブラリ技術マップ

アプリケーション

システムソフトウェア

数値計算ライブラリ

年

数値計算ミドルウェア

2002年 FFTEhttp://www.ffte.jp/並列FFTライブラリ

1995年 PHiPAChttp://www.icsi.berkeley.edu/~bilmes/phipac/自動チューニングを用いた高速な行列積

2005年 OSKIhttp://bebop.cs.berkeley.edu/oski/自動チューニング機能付き疎行列ライブラリ

2008年 MAGMAhttp://icl.cs.utk.edu/magma/GPUおよびマルチコアアーキテクチャ

向けの基本線形計算ライブラリ

2007年 PLASMAhttp://icl.cs.utk.edu/plasma/マルチコアアーキテクチャ向けの並列線形計算ライブラリ

2006年 P3DFFThttp://code.google.com/p/p3dfft/高並列環境に向けたFFTライブラリ

1997年 FFTWhttp://www.fftw.org/自動チューニング機能付きFFTライブラリ

1996年 ATLAShttp://math-atlas.sourceforge.net/自動チューニング機能付き基本線形計算ライブラリ

2000年 SPIRALhttp://www.spiral.net/自動チューニング機能付きFFTコードジェネレータ

1995年 ScaLAPACKhttp://www.netlib.org/scalapack/分散メモリ型並列計算機向けの線形計算ライブラリ

2007年 Lishttp://www.ssisc.org/lis/並列反復解法ライブラリ1995年 PETSc

http://www.mcs.anl.gov/petsc/petsc-as/疎行列ライブラリ

図 2-1 数値計算ライブラリの技術マップ

2.3 技術項目と優先度

参考資料 2 ロードマップ未定稿 24

本節では、今後 5～10 年で挑戦すべき技術項目と達成時期について述べる。表 2-1 に数値

計算ライブラリ分野の技術項目のうち、主項目を示す。 主項目は以下のようにまとめることができる。 1. 通信最適化

【革新技術】 Allgather や Allreduce 等の集合通信を避けたライブラリ（アルゴリズムの変更

が必要） 通信（回数またはデータ転送量，またはその両方）を最小限にしたアルゴリズ

ム 通信量を増やしてでもレイテンシの影響を削減し、通信時間を削減する通信方

式 2. 演算量を増やしてでも通信量やメモリアクセス回数を削減するアルゴリズム

【革新技術】 データは他のノードから持ってくるのではなく、自ノードで計算できるものは

計算する。 3. 高精度計算

【革新技術】 高精度計算の CPU／GPU 最適化

4. 混合精度演算・精度保証計算 【革新技術】 単精度演算や倍精度演算と 3 倍精度・4 倍精度演算を組み合わせる。 【既存技術】 区間演算を用いることにより、精度を保証する。

5. 精度をユーザが確認する方法 【革新技術】 verbose モード、逐次実行・演算順序保証実行モード

6. フォールトトレラント機能 【革新技術】 システムソフトウェアのレベルではなく、数値計算ライブラリにチェックポイ

ント／リスタートの機能を持たせる。 耐故障性の必要性の調査

7. ライブラリ利用形態に関する検討 【革新技術】 数値計算ライブラリがどのような階層で使用されるか、されるべきかの再検討

8. 適切な HW を選択するための情報を得る仕組み 【革新技術】 電力効率最大 HW がどれかを知るためには、電力情報をうまく利用できる仕組

み（API）が必要。 9. 非均質プロセッサ環境に対応するライブラリ

【既存技術】 マルチコア、メニーコア、GPU への対応 【革新技術】 ハイブリッド並列処理対応

10. 生産性の高いアプリケーション記述用言語（フレームワーク） 【革新技術】 ライブラリ自体をどのような言語で記述するのかについての検討

主項目から派生する副項目を表 2-2 に示す。

表 2-1 数値計算ライブラリ分野の技術項目（主項目）

参考資料 2 ロードマップ未定稿 25

表 2-2 数値計算ライブラリ分野の技術項目（副項目）

2.4 ロードマップ 前節の技術項目のうち主項目を達成するための数値計算ライブラリ分野のロードマップを、

以下にまとめる。 2011 年～2012 年 10 ペタ級のスパコンである「京」が供用開始になると共に、大学センター群等のぺタスケ

ールマシンが運用開始となるため、それらのマシンを用いて数値計算アルゴリズムを検討す

る段階。1 万並列程度の処理が対象となる。以下の技術項目の研究開発を行う。 1. 非均質プロセッサへの対応 2. 高精度計算のシリアル／CPU／GPU 最適化

参考資料 2 ロードマップ未定稿 26

3. 通信量を増やしてでもレイテンシの影響を削減し、通信時間を削減する通信方式 2013 年～2014 年 大学センター群等で 10 ペタ級スパコンが運用開始となる。それらのマシンを用いて数値

計算アルゴリズムの検討ならびに評価を行う段階。10 万並列程度の処理が対象となる。以下

の技術項目の研究開発を行う。 1. 非均質プロセッサへの対応 2. 通信最適化数値ライブラリ 3. 高精度計算のシリアル／CPU／GPU 最適化 4. 演算量を増やしてでも通信量やメモリアクセス量を減らす数値計算アルゴリズム

2015 年～2016 年 プリエクサ級のスパコンが運用開始となる。それらのマシンを用いて数値計算ライブラリ

の実装を行う段階。100 万並列程度の処理が対象となる。以下の技術項目の開発を行う。 1. 非均質プロセッサへの対応 2. 高精度計算の並列版の実装 3. 混合精度演算・精度保証計算

2017 年～2020 年 エクサ級のスパコンが運用開始となる。それらのマシンを用いて数値計算ライブラリのアプ

リケーション上での評価を行う段階。1000 万並列程度の処理が対象となる。以下の技術項

目の開発を行う。 1. フォールトトレラント機能を持つ数値計算ライブラリ 2. エクサ級アプリでの利用を実現 3. エクサ級アプリでのテスト

3.数値計算ミドルウェア分野 3.1 はじめに 本章で述べる数値計算ミドルウェアはアプリケーションを効率的に構築するための技術で，

ライブラリ形式あるいはフレームワーク形式により提供される．両者とも適用範囲をある特

定分野に絞り開発している．特に，フレームワークは提供する機能の抽象化のレベルと範囲

の自由度が高く，特定分野向けの機能を提供している．これまで開発されてきたライブラリ，

フレームワークの主目的はプログラム開発時の生産性の向上にある．ここで，ライブラリは

ある特定分野の有用かつ汎用的なサブルーチン群でアプリケーション構築法とは独立なソフ

トウェアパッケージとして定義する．フレームワークは，ある特定分野のアプリ開発に再利

用できる機能モジュール，ライブラリ群から構成されたパッケージで，アプリケーションア

ーキテクチャを形成する．また，ミドルウェアはアプリケーションと OS のソフトウェアス

タック間にあるソフトウェアパッケージの総称であり，ライブラリとフレームワークを含ん

でいる．アプリケーション・ミドルウェアは，最もアプリに近い階層のミドルウェアとする．

ハードウェアの制約条件として電力の問題が大きく，電力の制約からアクセラレータの利用，

メモリモジュールの構成ポリシ（容量優先あるいは速度優先），深いメモリ階層，非均質な

帯域のネットワーク構成など，エクサスケールのプログラミングに関して，考慮すべき事項

が組み合わせ的に増大し，アプリケーション開発のコストが増大することが容易に想像でき

る．このため，コード開発の生産性を高め，アプリケーションのプロトタイプ開発の効率化

や開発後の保守にも役立つコード開発環境が必要になる．したがって，エクサに向けては前

述のような問題を緩和する機能を開発する必要がある．加えて，超高速な計算能力を使って，

現時点では解決できない複雑な問題を解く高性能なプログラムを短時間で開発し，成果を創

出することも非常に重要なチャレンジであり，そのための取り組みも必要である．

参考資料 2 ロードマップ未定稿 27

ここでは，エクサフロップスを実現する数値計算ライブラリに必要な技術項目に焦点をし

ぼり，本ロードマップを作成した． 3.2 技術動向 図 3-1 にアプリケーション開発のミドルウェア技術の観点から見た技術マップを示す． ラ

イブラリについては，かなり以前から様々なレベルで提供されていたが，1990年後半からフ

レームワークを用いたアプリケーション開発が本格化している．日本国内においても 2000年

以降，いくつかのフレームワーク研究が進められている．

図 3-1 アプリケーション開発に用いる数値計算ミドルウェアの技術マップ

3.3 技術項目と優先度 以下に挑戦すべき技術項目と達成時期を記載する．末尾の※は，今後新たに技術開発が必

要な項目を示す．

高生産性ミドルウェアの開発 1. 高性能アプリの開発・実行・メンテナンスを支援するアプリケーションプログラ

マ向けフレームワーク オブジェクト指向，マルチレベル API（非 OOP を含む多言語対応）をもつ軽

量クラスライブラリ群 並列分割管理，データ管理，I/O 処理，AMR 処理，プロセスマッピン

グ，格子生成機能など 対象とするデータ構造は，直交等間隔，八分木，非構造，一般曲線座

標系構造格子，重合格子，離散点群など． 必要なアプリ領域のコミュニティに対して，データ構造と離散化方法

に適したミドルウェアを提供． 2. 記述性と実行性能の高い PDE 系プログラム記述のユーザ向けアプリケーション・

ミドルウェア ※ アプリケーションの迅速なプロトタイピングを可能にする枠組み 実行時の最適候補選択が可能な（AT 技術）簡潔かつ高い実行効率の記述法 利用しやすいアルゴリズム記述のフロントエンドとの組み合わせにより，簡

便に高性能アプリケーションを記述するミドルウェアを構築 対象とする問題に適した超並列アプリの並列記述フレームワークをデータ構

造毎にテンプレートとして提供する．

高性能・高信頼アプリの要素技術開発 1. 超並列対応の領域分割と並列データ管理技術

参考資料 2 ロードマップ未定稿 28

高いロードバランスで領域を分割し，省メモリで並列領域を管理するデータ

構造 2. 高性能ファイル I/O 管理技術 ※

大規模・多量のファイルハンドリング技術 ※ データ圧縮を併用した高速ファイル I/O 技術

3. 領域分割法に対する高レイテンシ・非均質ネットワーク利用技術 計算空間の並列性と物理コアの並列性のマッピングの最適化 直接網ネットワークトポロジに対応した高速通信アルゴリズムの開発 ※

4. 超並列対応の負荷分散技術 計算中に著しく負荷が変動するケースの動的負荷分散技術

外部制約条件（電力消費など），マイグレーション ※ 粒度（計算量）の異なる連成現象の負荷分散技術

Eulerian-Lagrangian coupling, Radiation coupling ※ 動的負荷分散に伴う格子細分化ライブラリの整備

5. 故障コアに対するリカバリー対応技術 不可避な故障コア発生を前提として，故障発生時の継続実行をアプリレベル

のポリシに応じて制御するしくみの標準化 ※ 6. ヘテロジーニアスな実行コアの利用技術

CPU,GPU, FPGA などの各実行コアに最適化された数値ライブラリの利用環境

整備，およびアプリ実行時の動的な実行コア選択 ※ 7. 超並列探索・最適化アルゴリズム

大規模な制約充足問題、最短経路問題、プランニング問題など ※ 8. ストロングスケーリング対応

通信隠蔽可能で，同期点の少ないアルゴリズム開発 ※ マシンの Byte/Flop 値の低下に対応する低 B/F 対応アルゴリズム開発 ※

参考資料 2 ロードマップ未定稿 29

表 3-1 にミドルウェア分野の技術項目における主項目を示す．

表 3-1 ミドルウェア分野の技術項目（主項目） 技術完成

目標年度 技術項目 必要性 重要性 2011 年におけ

る研究進捗 2012 高性能ファイル I/O 管理技術 ★★★ ★★★ フェーズ II 2012 超並列対応の分割並列データ

管理技術 ★★ ★★ フェーズ II

2013 高性能アプリの開発・実行・

メンテナンスを支援するアプ

リケーションプログラマ向け

フレームワーク

★★ ★★ フェーズ II

2014 領域分割法に対する高レイテ

ンシ・非均質ネットワーク利

用技術

★★★ ★★ フェーズ II

2015 超並列対応の負荷分散技術 ★★★ ★★★ フェーズ I 2017 記述性と実行性能の高い PDE

系プログラム記述のユーザ向

けフレームワーク

★★ ★★★ フェーズ I

主項目から派生する副項目を表 3-2 に示す．

表 3-2 ミドルウェア分野の技術項目（副項目）

技術完成

目標年度 技術項目 必要性 重要性 2011 年におけ

る研究進捗 2012 高性能/高機能ファイルハン

ドリング技術 ★★ ★★ フェーズ II

2014 データ圧縮を併用した高速フ

ァイル I/O 技術 ★ ★ フェーズ I

2014 プロセスマッピングの最適化 ★ ★★ フェーズ II 2015 動的負荷分散アルゴリズム開

発 ★ ★★ フェーズ II

2015 粒度の異なる負荷分散アルゴ

リズム開発 ★★ ★★ フェーズ II

2016 超並列探索・最適化アルゴリ

ズム ★★ ★ フェーズ I

2017 故障コアに対するリカバリー

対応技術 ★ ★ フェーズ I

2018 ヘテロジーニアスな実行コア

の利用技術 ★★ ★★ フェーズ I

参考資料 2 ロードマップ未定稿 30

3.4 ロードマップ 前節の技術項目のうち主項目を達成するためのロードマップを表 3-3 にまとめる．

フレームワーク開発は要素技術開発とその進展に左右される．また，アプリと計算機科学

のチームとの強固な連携がなければ成功しない．さらに付け加えれば，コミュニティとファ

ンドの規模を考えると，適用領域を絞り，一点突破的なアプローチが必要と思われる．一方

で，エクサスケール計算機の有効利用という点からは，適用分野（利用者）を拡大し，より

広範囲の分野で計算科学の成果を国民の生活に反映できるような取り組みが必要になる．つ

まり，これまでスパコンとは縁のなかったコミュニティの取り込みと利用促進を考えなけれ

ばいけない．この点を考慮すると，最高性能は出せずとも，アプリ開発の期間とコストが小

さく，できるだけ高性能な偏微分方程式系のアプリケーションを簡単に記述できるミドルウ

ェアへと進化させていく方針がある． これらの点を考慮し，エクサ向きのアプリ開発を支援するフレームワークと優れたユー

ザインターフェイスをもつ汎用のアプリケーション開発ミドルウェアの 2 つを開発すること

を提案する．プロダクトは 2 つであるが，アプリケーション開発ミドルウェアはフレームワ

ークを包含しているので，連続的で効率的な開発が可能である． ペタオーダとエクサオーダでは，適用アルゴリズムや解法が異なると予想され個別の要素

技術は異なるが，アプリ構築方法や利用するフレームワークの大枠は統一可能というポリシ

である．最初に，ペタ〜エクサを睨んだフレームワークを設計開発する．一方，要素技術開

発はペタオーダから，サブエクサ，エクサオーダと推移していく．

表 3-3 ミドルウェア分野のロードマップ

目標年度 研究開発内容 2011〜2012

フィージビリティスタディと開発計画の詳細化 １．アプリ，計算機科学，ミドル開発分野の研究者の議論 ２．対象アプリ領域選定，共通機能の選定，開発プライオリティ ３．ミドルウェア実装の検討

2012〜2013

フレームワークのプロトタイプ開発 １．軽量クラスライブラリ群の設計開発 ２．エクサ向けの機能要素開発 ネットワークトポロジ特性を利用した通信最適化など ３．ペタスケール環境での性能評価

2014〜2015

フレームワークのアップデートと展開 １．要素技術のアップデートに対応して，実装変更 ２．機能拡張とエクサ向けアルゴリズムの導入 ３．フレームワークのリリースと既存関連アプリの移植

2016〜2017

アプリケーションミドルウェアの構築 １．開発したフレームワークを用いて高レベル記述のラピッドプロトタイピン

グ用のミドルウェアを構築 ２．フレームワークの継続的なアップデートとサポート ３．プリエクサ級環境での実証

2018〜2019

エクサスケールへの展開 １．エクサスケール環境でミドルウェアの有効性を検証 ２．ミドルウェアとアプリの継続的なアップデートとサポート

参考資料 2 ロードマップ未定稿 31

4.数値計算ライブラリのための自動チューニング分野 4.1 はじめに 数値計算ライブラリのための自動チューニング（AT）技術は、数値計算ライブラリで現れ

る主演算において、計算機環境に自動適応し、高性能となる実装方式を自動生成できる技術

である。AT 技術で実現される実装方式の最適化は、単にプログラミングの仕方に留まらず、

数値計算アルゴリズムも考慮し最適アルゴリズムを選ぶ＜アルゴリズム選択＞も含まれる技

術である。実行速度の高速化のみだけではなく、ユーザが要求する演算精度に適合する最適

化や、実行時のメモリ量を最小化する最適化も含む。AT を行うタイミングは、ソフトウェ

アのインストール時だけではなく、ユーザが所望した時や実行時も含まれる。 以上のように＜汎用的＞に行われる AT 技術について、エクサフロップスを実現する数値

計算ライブラリに必要な技術項目に焦点をあて本ロードマップを作成した エクサフロップス環境のための AT技術が実現する機能として以下があげられる。

エクサフロップス環境で想定される多様な計算機環境に自ら柔軟に適応すること。ソフ

トウェア性能を自動最適化できる枠組み（ソフトウェア構築法）を提供すること。この

ことで、より高い実行性能を実現するソフトウェアが開発可能となる。

コンパイラが行うことができない最適化（コード最適化、自動並列化など）を提供する

こと。性能チューニングに関する工数を削減することで、結果として、ソフトウェア開

発工数の削減が可能となる。

研究開発の背景と技術的な制約として以下がある。

非均質 CPU(マルチコア CPUと GPUの混合)が普及する

実行時に判明するなんらかの電力制約がある

通信性能が劇的に低下する（高レイテンシになる）

大規模問題実行時に演算精度が著しく劣化する

高性能を達成するためにはアルゴリズム選択が必要となる

ハードウェア故障を考慮しないと安定実行ができなくなる 4.2 技術動向 図 4-1 に、AT 技術を適用した数値計算ライブラリと AT 専用言語の開発に関する技術マッ

プをのせる。図 4-1から、1990年後半から特定の数値計算ライブラリ、特に密行列用の基本

演算ライブラリ BLAS(Basic Linear Algebra Subprograms)に対する ATの技術開発が始まっ

た。2000 年前半になり、数値計算ライブラリレベルの AT 技術の開発が始まっている。2010

年前後において、より汎用的な AT技術の開発がコンパイラ最適化を拡張する方法で始まって

おり、現在まで研究開発が継続されている。

参考資料 2 ロードマップ未定稿 32

図 4-1 AT技術を基にした数値計算ライブラリと専用言語の技術マップ

4.3 技術項目と優先度 本節は、今後 5 年～10 年で挑戦すべき技術項目と達成時期を記載する。表 4-1 に主項目

を示す。なお本節で示される技術項目は、AT の観点から対象となる最適化を自動化する技

術を意味する。ここで示された技術項目を実現するための要素技術は他分野において重要項

目となっている場合がある。しかし他分野の最適化は必ずしも最適化自体を自動化する技術

を意味しない。ここでの AT 技術とは、最適化自体を自動化する技術を指す。

表 4-1 AT 分野の技術項目（主項目）

主項目は以下にまとめられる。

1. ヘテロジニアス環境最適化 マルチコア最適化、ハイブリッド MPI 最適化、のための AT 機構 CPU-GPU の切り替えのための AT 機構 既存技術：CPU-GPU 切り替え機能を自動付加する AT 言語 革新技術：ヘテロジニアス環境に適用可能な性能モデル化手法

2. 電力最適化

参考資料 2 ロードマップ未定稿 33

ジョブレベル、演算カーネルごとに適する電力最適化（周波数の変更、電力が

低い CPU の選択、等）のための AT 機構 どのようなポリシで電力最適化するかという「電力最適化ポリシ」と、自動チ

ューニング専用言語の確立 既存技術：コンパイル時の周波数切り替え最適化 革新技術：電力最適化のための、性能モデル、最適化ポリシ指定方式、AT 言語

3. 超低レイテンシ通信最適化 完全網から 3D トーラス網などへのネットワークアーキテクチャ変更に伴う＜高

レイテンシ化＞に対応する通信処理の最適化のための AT 機構 通信ライブラリ（MPI）の実行時の実装方式・アルゴリズム切り替えのための

AT 機構 実行時の物理ノード割り当て情報からの通信最適化のための AT 機構 既存技術：実行時の MPI 実装方式切り替え 革新技術：通信実装方式を実行時に切り替える AT 方式および AT 機構

4. 数値計算アルゴリズム選択 入力データ特性（行列の数値特性や問題サイズ等）を自動抽出して、最適アル

ゴリズムを選択するための AT 機構 数値シミュレーションが進むたびに変化する数値特性に応じた最適化のための

AT 機構 既存技術：アルゴリズム選択のための AT 言語 革新技術：アルゴリズム選択のための性能モデルとその AT 言語への適用

5. 混合演算・精度保証による数値計算安定化 以下の演算の導入を行うことで実現する AT 機構

混合精度演算、多倍長演算、区間演算の導入 基本演算に対する高精度演算と混合精度演算の導入

反復解法中で内積演算のみ高精度化する等の混合演算の AT 機構 「実行速度」「メモリ量」「演算精度」のうち、何を重視し最適化するかとい

うポリシの記述（「数値計算ポリシ」記述） 解の一覧を与えた上、プログラム変換により、ソルバ実装が変化してもテスト

問題は正しく解けていることを保証してくれるメカニズム（アルゴリズム検証） 既存技術：多倍長演算ライブラリ、混合演算ライブラリ、特定アルゴリズムの

部分高精度化手法 革新技術：精度保証手法とそのライブラリ、数値計算ポリシ指定方式、アルゴ

リズム検証方式、数値計算安定化のための AT 言語 6. 耐故障性対応

数値計算アルゴリズム特有の知識記述でチェックポイント・リスタートを低レ

イテンシ化する技術を利用した AT 機構 実行時間と耐故障性のトレードオフ考慮し、方式を自動選択する「耐故障性ポ

リシ」の確立 「ある確率で失敗するかもしれない計算」という部品を記述し、それをもとに

100%に近い確率で成功するよう計算全体を組み立てるフレームワーク（耐故障

ソフトウェア部品化） 既存技術：アプリケーション知識を利用する低レイテンシ耐故障技術 革新技術：低レイテンシ耐故障化のための AT 方式と AT 言語、耐故障性ポリシ

記述方式、耐故障ソフトウェア部品化 主項目から派生する副項目（短期）と副項目（長期）を表 4-2、表 4-3 に示す。

表 4-2 AT 分野の技術項目（副項目、短期）

参考資料 2 ロードマップ未定稿 34

表 4-3 AT 分野の技術項目（副項目、長期）

4.4 ロードマップ 前節の技術項目のうち主項目を達成する、数値計算のための AT 技術のロードマップを以

下にまとめる。

2011 年～2012 年 現存スパコンを用いた AT の有効性検証をおこなう段階。 1. 非均質環境最適化 AT のプロトタイピング 2. 電力最適化 AT の基本設計 3. 通信最適化 AT の基本設計 4. 数値計算アルゴリズム選択 AT のプロトタイピング

2013 年～2014 年

10 ペタ級スパコンが運営される。それを用いて AT の有効性検証を行う段階。 1. 非均質環境最適化 AT の実現 2. 電力最適化 AT のプロトタイピング 3. 通信最適化 AT のプロトタイピング 4. 数値計算アルゴリズム選択 AT の実現 5. 数値計算安定化 AT の基本設計

参考資料 2 ロードマップ未定稿 35

2015 年～2016 年 100 ペタ級のスパコンが実現される。それを用いて AT の有効性検証を行う段階。

2. 電力最適化 AT の実現 3. 通信最適化 AT の実現 5. 数値計算安定化 AT のプロトタイピング 6. 耐故障性対応 AT の基本設計

2017 年～2020 年 エクサ級のスパコンが実現される。それを用いて AT の有効性検証を行う段階。

5. 数値計算安定化 AT の実現 6. 耐故障性対応 AT のプロトタイピング

以上

参考資料 2 ロードマップ未定稿 36

5.我が国でファンディングされた課題

5.1 はじめに 本資料は、数値計算ライブラリ関連の研究について、我が国でファンディングされた研究

課題を列挙したものである。文部科学省科学技術研究費補助金、基盤研究(S)、(A)、および

科学技術振興機構(JST)戦略的創造研究推進事業(CREST)による採択課題を列挙した。 5.2 数値計算ライブラリ分野

我が国でファンディングされた数値計算ライブラリ研究俯瞰図

平成22年度～平成26年度：

科学技術振興機構、戦略的国際科学技術協力推進事業（共同研究型）「日本－フランス共同研究」，ポストペタスケールコンピューティングのためのフレームワークとプログラミング，代表者：佐藤三久，Serge Petiton

平成23年度～平成27年度：科学技術振興機構，CREST，「ポストペタスケール高性能計算に

資するシステムソフトウェア技術の創出」研究領域，「自動チューニング機構を有するアプリケーション開発・実行環境」，代表者：中島研吾

平成14年度～平成19年度：科学技術振興機構，CREST，「シミュレーション技術の革新と

実用化基盤の構築」研究領域，「大規模シミュレーション向け基盤ソフトウェアの開発」，代表者：西田晃

アプリケーション

システムソフトウェア

数値計算ライブラリ

採択年

平成19年度～平成24年度：科学技術振興機構，CREST，「情報システムの超低消費電力化

を目指した技術革新と統合化技術」研究領域，「ULP-HPC：次世代テクノロジのモデル化・最適化による

超低消費電力ハイパフォーマンスコンピューティング」，代表者：松岡聡

GPUによる基本演算（行列積，FFT）や線形ソルバの開発

自動チューニング機構によりプログラムの修正なしに最適な性能で安定に実行可能となる環境を開発

並列数値計算を可能とする標準的なソフトウェア基盤を構築

数値計算アルゴリズムGMRES(m)法に

おける自動チューニング方式の研究

平成21年度～平成23年度：科学研究費補助金，基盤研究（A），「次世代シミュレーション環境のための一般化固有値解法の開発と応用」，代表者：櫻井鉄也

一般化固有値解法の開発

数値計算ミドルウェア

平成23年度～平成27年度：科学技術振興機構，CREST，「ポストペタスケール高性能計算に

資するシステムソフトウェア技術の創出」研究領域，「ポストペタスケールに対応した階層モデルによる超並列固有値解析エンジンの開発」，代表者：櫻井鉄也

階層的並列構造に対応した「超並列固有値解析エンジン」の開発

平成20年度～平成23年度：科学研究費補助金，基盤研究（A），「マルチコアプロセッサに対応した革新的

特異値分解ライブラリーの開発」，代表者：中村佳正

マルチコア向けの2重対角化

アルゴリズムの開発

図 5-1 我が国でファンディングされた課題（数値計算ライブラリ分野）

5.3 数値計算ミドルウェア分野

参考資料 2 ロードマップ未定稿 37

図５−2 我が国でファンディングされた課題（数値ミドルウェア分野）

5.4 数値計算ライブラリのための自動チューニング分野

図 5‐3 我が国でファンディングされた課題（自動チューニング分野）

以上

参考資料 2 ロードマップ未定稿 38