HPCI 技術ロードマップ白書
2012 年 3 月
執筆者一覧
全体取りまとめ
·
·
石川裕（東京大学大学院情報理工学系研究科教授）
丸山直也（東京工業大学大学学術国際情報センター助教）
アーキテクチャ
·
·
·
·
·
·
·
·
近藤正章*（電気通信大学大学院情報システム学研究科准教授）
石井 康雄* （ＮＥＣ）
塙 敏博 （筑波大学計算科学研究センター 准教授）
佐野 健太郎 （東北大学大学院情報科学研究科 准教授）
鯉渕 道紘 （国立情報学研究所アーキテクチャ科学研究系 准教授）
佐藤 幸紀 （北陸先端科学技術大学院大学情報社会基盤研究センター 助教）
安島 雄一郎 (富士通)
井上 弘士 （九州大学大学院システム情報科学研究院 准教授）
システムソフトウェア
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
·
野村哲弘*（東京工業大学学術国際情報センター産学官連携研究員）
清水正明（日立製作所）
高野了成（産業技術総合研究所情報技術研究部門研究員）
宇野俊司（富士通）
松葉浩也（日立製作所）
今田俊寛（理化学研究所計算科学研究機構リサーチアソシエイト）
南里豪志（九州大学情報基盤研究開発センター准教授）
建部修見（筑波大学計算科学研究センター准教授）
佐藤仁（東京工業大学学術国際情報センター特任助教）
安井隆（日立製作所）
大野善之（理化学研究所計算科学研究機構リサーチアソシエイト）
中田秀基（産業技術総合研究所情報技術研究部門研究員）
竹房あつ子（産業技術総合研究所情報技術研究部門研究員）
遠藤敏夫（東京工業大学学術国際情報センター特任准教授）
鴨志田良和（東京大学情報基盤センター特任助教）
滝澤真一朗（東京工業大学学術国際情報センター特任助教）
實本英之（東京大学情報基盤センター助教）
プログラミング
·
·
·
·
·
·
滝沢寛之*（東北大学大学院情報科学研究科准教授）
田浦健次朗（東京大学大学院情報理工学系研究科准教授）
平石拓（京都大学学術情報メディアセンター助教）
窪田昌史（広島市立大学大学院情報科学研究科助教）
八杉昌宏（京都大学大学院情報学研究科准教授）
中尾昌広（筑波大学計算科学研究センター研究員）
数値計算ライブラリ
·
片桐孝洋* （東京大学情報基盤センター准教授）
2
·
·
·
·
·
須田礼仁*（東京大学大学院情報理工学系研究科教授）
高橋大介（筑波大学計算科学研究センター准教授）
岩下武史（京都大学学術情報メディアセンター准教授）
小野謙二（東京大学生産技術研究所特任研究員）
伊東聰（東京大学情報基盤センター特任助教）
（*印は各パート取りまとめ)
アドバイザ
アーキテクチャ
·
·
·
松岡 聡 （東京工業大学学術国際情報センター 教授）
平木 敬 （東京大学大学院情報理工学系研究科 教授）
中村 宏 （東京大学大学院情報理工学系研究科 教授）
システムソフトウェア
·
·
·
·
朴泰祐（筑波大学計算科学研究センター教授）
堀敦史（理化学研究所計算科学研究機構）
並木美太郎（東京農工大学工学部教授）
住元真司（富士通）
プログラミング
·
·
·
中島浩（京都大学学術情報メディアセンター教授）
佐藤三久（筑波大学計算科学研究センター教授）
米澤明憲（理化学研究所計算科学研究機構副機構長）
数値計算ライブラリ
·
·
·
·
·
中島研吾（東京大学情報基盤センター教授）
姫野龍太郎（理化学研究所基盤センター室室長）
関口智嗣（産業総合研究所情報技術研究部門研究部門長）
平尾公彦（理化学研究所計算科学研究機構機構長）
宇川彰（筑波大学大学院数理物質科学研究科教授）
3
目次
計算科学研究ロードマップ白書 ................................................................................................... 1
1.
はじめに ...................................................................................................................................... 6
2.
スーパーコンピュータの技術動向 ...................................................................................... 7
2.1 ハードウェア・技術トレンド ....................................................................................................... 7
2.1.1 プロセッサ(ロジック LSI) ....................................................................................................... 7
2.1.2 メモリ ................................................................................................................................................ 8
2.1.3 データ転送技術 ............................................................................................................................ 9
2.1.4 2018 年までのプロセス世代別性能諸元予想 ............................................................. 10
2.2 システムアーキテクチャ・ソフトウェアトレンド ........................................................ 13
2.2.1 システムアーキテクチャの変遷と日本での技術開発の成果 .............................. 13
2.2.2 日本における今後の開発課題............................................................................................. 14
2.2.3 プロセッサとメモリ 2018 年のシステム性能予想 .................................................. 16
2.3 将来の技術開発に向けて.............................................................................................................. 18
2.4 参考文献 ............................................................................................................................................... 18
3.
技術課題 ....................................................................................................................................20
3.1 ヘテロジニアスアーキテクチャ ............................................................................................... 20
3.1.1 概要・前提 ................................................................................................................................... 20
3.1.2 課題.................................................................................................................................................. 21
3.2 メモリ .................................................................................................................................................... 24
3.2.1 メモリ階層によるメモリ帯域の改善 .............................................................................. 25
3.2.2 システムソフトウェアによる改善 ................................................................................... 26
3.2.3 プログラミングモデル ........................................................................................................... 26
3.2.4 参考文献 ........................................................................................................................................ 27
3.3 大規模並列性...................................................................................................................................... 27
3.3.1 通信時間の削減 ......................................................................................................................... 28
3.3.2 システムソフトウェアのスケーラビリティ................................................................ 28
3.3.3 スケーラブルプログラミング............................................................................................. 29
3.3.4 数値計算ライブラリにおける高い並列性の確保 ...................................................... 30
3.3.5 参考文献 ........................................................................................................................................ 30
3.4 耐故障性 ............................................................................................................................................... 30
3.4.1 エクサスケールにおける故障............................................................................................. 31
3.4.2 エクサスケールにおける耐故障技術 .............................................................................. 32
3.4.3 エクサスケールにおける耐故障性のコスト................................................................ 33
3.4.4 エクサスケールにおける耐故障性の課題 .................................................................... 33
3.4.5 参考文献 ........................................................................................................................................ 34
3.5 低消費電力 .......................................................................................................................................... 35
3.5.1 ハードウェアの省電力技術 ................................................................................................. 35
3.5.2 ソフトウェア電力制御のためのアーキテクチャ機構 ............................................ 37
3.5.3 ソフトウェアによる省電力技術........................................................................................ 37
3.6 大規模データ処理 ............................................................................................................................ 38
3.6.1 概要・前提 ................................................................................................................................... 38
3.6.2 課題.................................................................................................................................................. 39
3.7 生産性 .................................................................................................................................................... 40
3.7.1 はじめに ........................................................................................................................................ 40
3.7.2 システムソフトウェアの課題............................................................................................. 40
4
3.7.3 デバッグおよび性能プロファイルの問題 .................................................................... 41
3.7.4 プログラミング方法論の課題............................................................................................. 41
3.7.5 性能チューニングの課題 ...................................................................................................... 43
3.7.6 参考文献 ........................................................................................................................................ 45
3.8 周辺技術課題...................................................................................................................................... 45
3.8.1 外部資源連携 .............................................................................................................................. 45
3.8.2 参考文献 ........................................................................................................................................ 47
4.
研究開発ロードマップ ..........................................................................................................48
4.1 アーキテクチャ ................................................................................................................................. 48
4.1.1 はじめに ........................................................................................................................................ 48
4.1.2 エクサスケールを可能にする技術・研究アプローチ ............................................ 48
4.1.3 エクサスケールシステム構成例........................................................................................ 54
4.1.4 まとめ ............................................................................................................................................. 60
4.1.5 参考文献 ........................................................................................................................................ 61
4.2 システムソフトウェア .................................................................................................................. 63
4.2.1 はじめに ........................................................................................................................................ 63
4.2.2 オペレーティングシステムおよびランタイム ........................................................... 63
4.2.3 システム管理 .............................................................................................................................. 67
4.2.4 外部資源連携 .............................................................................................................................. 70
4.2.5 まとめ ............................................................................................................................................. 71
4.2.6 参考文献 ........................................................................................................................................ 72
4.3 プログラミング ................................................................................................................................. 73
4.3.1 はじめに ........................................................................................................................................ 73
4.3.2 要素技術研究項目..................................................................................................................... 74
4.3.3 エクサスケールプログラミング環境例 ......................................................................... 80
4.3.4 まとめ ............................................................................................................................................. 83
4.3.5 参考文献 ........................................................................................................................................ 85
4.4 数値計算ライブラリ ....................................................................................................................... 85
4.4.1 はじめに ........................................................................................................................................ 85
4.4.2 数値計算ライブラリ ................................................................................................................ 86
4.4.3 数値計算ミドルウェア ........................................................................................................... 89
4.4.4 数値計算ライブラリのための自動チューニング ...................................................... 94
4.4.5 我が国でファンディングされた課題 .............................................................................. 98
4.4.6 まとめ ........................................................................................................................................... 100
4.4.7 参考文献 ...................................................................................................................................... 101
5.
おわりに ................................................................................................................................. 104
付録 1. 進行中関連研究課題 ...................................................................................................... 106
5
1. はじめに
シミュレーションや解析などの計算によるサイエンスである計算科学を推進するために，
スーパーコンピュータの研究開発が世界中で活発に進められている．これまで我が国で
は 2011 年に世界初の 10 ペタフロップスを達成した理化学研究所の京コンピュータや各
大学基盤センターによるスーパーコンピュータの開発・運用が進められてきており，今
後も最先端のハイパフォーマンスコンピューティング技術の研究開発により計算科学へ
の貢献が求められている．
本白書は今後のハイパフォーマンスコンピューティングに向けた技術課題およびそれ
に向けた研究開発ロードマップについて，戦略的高性能計算システム開発に関するワー
クショップ（以下，SDHPC と略す）におけるこれまでの議論，さらに，文部科学省研究
振興局長の諮問会議「HPCI 計画推進委員会」の下に組織されたアプリケーション作業部
会とコンピュータアーキテクチャ・コンパイラ・システムソフトウェア作業部会での議
論をもとにまとめたものである．SDHPC は 2010 年から 2011 年にかけて計 6 回開催、２
つの作業部会の合同作業部会は計３回開催され，それぞれ自由参加形式にて今後のハイ
パフォーマンスコンピューティングに関する技術動向の調査，課題の同定，研究開発の
方向性について議論を重ねてきた．特に，2018 年頃に達成が見込まれている高性能並列
計算機を念頭におきつつ，アプリケーション作業部会によるサイエンスロードマップを
実現するためのスーパーコンピュータ開発について活発な議論が行われた．本白書では、
2018 年頃達成すべきシステムをエクサスケールシステムと呼ぶことにする。ここでいう
エクサスケールシステムは Linpack ベンチマーク性能値に基づいた性能目標設定値とし
てのエクサスケールではない。Linpack ベンチマークによる性能指標に基づく世界ランキ
ング公表は高性能並列計算機研究開発の競争を促し一定の貢献をしてきている一方、本
性能値に基づく高性能並列計算機が必ずしもアプリケーションが必要とする並列計算機
環境を実現しているとは限らないからである。
本白書の構成は以下の通りである．まず 2 章にてこれまでのスーパーコンピュータ開
発および 2018 年から 2020 年頃までの動向について議論をし，3 章にて同技術動向に基
づいた技術課題をまとめる．4 章では重点技術課題の解決に向けた研究開発のロードマ
ップについて議論し，5 章にてロードマップを達成するためのあるべき体制であるコデ
ザインについて議論する．最後に第 6 章にて全体のまとめを行う．
6
2. スーパーコンピュータの技術動向
過去 20 年以上にわたり，計算機アーキテクチャはハードウェアの性能を最大化するため
に発展を遂げており，この傾向は今後も変わることはない．将来のスーパーコンピュー
タのアーキテクチャを議論するには，関連する技術がどういった基礎技術に基づいてい
るかを議論することが重要である．
本節では，現在の技術トレンドから予測される 2018 年頃のハードウェア技術に関して議
論を行い，将来のアーキテクチャ検討の土台とする．また，2018 年に実現されるシステ
ム性能の予測も行う．予測は発表済の研究成果や企業のロードマップ[2-1,2,3,4]に基づい
て行うが，2018 年までのロードマップが発表されている場合は多くない為，そうした情
報がない部分に関しては外挿によって予測を行っている．
2.1 ハードウェア・技術トレンド
システムの性能の予測を行う前に，計算機を構成する各種部品の性能に関して議論を行
う．ここでは，現在利用可能な技術が 2018 年頃にどうなるか，という観点で予測を行う．
従って，現在利用されていない革新的なデバイス（例えば，超電導や単電子デバイスな
ど）を用いた技術に関しては議論をしない．ただし，半導体の 3 次元実装やシリコンフ
ォトニクスなどの実験室での実績があり，実用化が近いと考えられる技術に関しては発
表された性能見積もりをベースに議論を行う．
2.1.1 プロセッサ(ロジック LSI)
ロジック LSI の性能向上は半導体プロセスの進化に支えられてきた．半導体プロセスは
10 年以上にわたり 2 年に一世代のペースでプロセスが進化している．2011 年現在で
32nm プロセス～45nm プロセスが最先端のプロセスとして活用されており，その傾向に
従うと 2018 年には 8nm～15nm 程度のプロセスが活用されると予想される．プロセスは
世代を追うごとに集積度が 75%程度向上し，トランジスタあたりの電力が 30%倍程度改
善される．動作速度の増加は鈍化する傾向にあると予想されているが，世代ごとに
5~10%程度の動作速度の向上が得られると予想されている[2-1]．
(1)
演算器
2018 年に標準的な演算器として利用されると考えられる積和演算機の電力・コスト・性
能に関して考察を行う．現在のプロセスでは 1.0GHz～2.0GHz で動作する積和演算器
7
(FMA)でおよそ 0.1mmsq の面積で 1 演算あたり約 10pJ の電力を消費する．消費電力や面
積は FMA の動作周波数やパイプラインステージ数に依存して大きくばらつく可能性が
ある[2-2]．
FMA 演算器はパイプライン化などを行うことで更に高い性能を実現することができ，例えば
5GHz 以上で動作可能な演算器も存在する[2-5]．ただし，こうした演算器では，より高い電
圧，より大きいトランジスタ，より深いパイプラインステージを必要とする．これは動作電
圧の向上，トランジスタ容量の増加，パイプラインレジスタの増加など，本来計算に必要で
ない点で電力消費を増加させるため，結果として電力効率を悪化させると考えられる．
(2)
オンチップメモリ
オンチップで利用できるメモリ素子には Logic(Flipflop/Latch)，SRAM，eDRAM が広く利
用されている．Flip-Flop や Latch は 1bit あたり 3～6umsq 程度のエリア，20fF 程度の容量
を持ち，1 度のリード処理で平均 5～10pJ の電力を消費する．パイプラインや小規模な
バッファを実現するために利用される．
SRAM は 1RW や 1R1W で 0.1～0.2umsq 前後のセルサイズでアクセス速度が 200ps ～
2ns で最大動作周波数は～4GHz 前後まで実現できる[2-6]．1word(72bit) のアクセスで約 3
～10pJ 程度の電力を消費する．多ポートの SRAM はポート数の約 2 乗に比例して面積・
電力が増加する．SRAM はセンスアンプなどの専用回路を持つため小規模な場合にはレ
ジスタファイルよりも効率が悪い場合がある．また，SRAM のビットサイズが巨大にな
るとより大きなアクセスタイムを必要とする．ばらつきなどに起因する生産性（歩留ま
り）・信頼性問題を緩和するために，一般的にはデバイスレベルで sparing（リダンダン
シ）を行い，生産性（歩留まり）・信頼性を高めている．
eDRAM は～0.1umsq 前後のセルサイズでアクセス速度が～2ns 程度である．SRAM と
比較して低速だが，その分 1bit あたりのコストを削減できる[2-7]．
(3)
オンチップデータ伝送
データの転送は計算・記憶と並び重要な要素の一つである．チップ内でのデータ転送は
半導体プロセスの進化と共に増加することが予想され，例えば，演算器の電力性能比が
10 倍になる場合には同じペースで性能向上が得られる．ただし，配線の微細化で配線抵
抗が増加するため，同一距離でのデータ転送の遅延時間は伸びる傾向にあると予想され
る．もしも，現代と同じ速度で信号を伝搬する場合には，配線抵抗を下げるために容量
の大きい配線を活用する必要があり，その場合にはプロセス進化による性能向上の恩恵
は得られない[2-2]．
2.1.2 メモリ
プロセッサと同様に重要なのがメモリ技術の進歩である．メモリもロジック LSI 同様に
ムーアの法則に従い 2 年に 1 世代のペースで技術が進歩してきている．ただし，メモリ
は半導体プロセスの進化を速度向上ではなくメモリ容量の増加に活用してきたため，メ
モリ素子自体の動作速度の向上が殆ど無い．メモリの性能向上は DDR 系にみられるよ
うにバーストアクセスを前提としたデータのプリフェチとそれを転送する伝送技術に支
えられており[2-8]，今後もその傾向は継続すると予想される．
8
(1) DRAM
オフチップのメモリ素子としては DRAM が圧倒的に多くのシステムで利用されている．
その中でも最も普及しているのは DDR 系列のメモリ技術である．2011 年現在で最も普
及しているのは DDR3 メモリである．1033Mhz, 8bit 幅のデバイスでおおよそ 1Gbit のメ
モリ容量，1GB/sec のメモリ帯域を実現し，その消費電力 300 mW ～ 500 mW である．
消費電力はランク数，メモリデバイス数，ページヒット率に影響されて変化し，より高
速・大容量なデバイスほどより多くの電力を消費するようになる[2-9]．
もしも，京コンピュータと同水準のメモリ帯域をエクサスケールシステムでも実現す
るには約 500PB/sec のメモリ帯域が必要であり，現行の技術では 200MW の電力が必要で
ある．Exa のシステム電力を 20MW と仮定すると，デバイス自体が 50 倍～100 倍程度の
電力効率の改善をする必要がある．現在のハードウェアトレンドに基づいて予測を行う
と，2018 年には DDR メモリの転送帯域はおよそ 10Gbps 程度になり 10 倍程度の性能向
上にとどまると予想される．
伝送系の電力効率の改善は Through-Silicon Via (TSV) [2-4]を用いて超幅広のバスを構
成する Wide I/O という方式と，DRAM をスタッキングしたデバイスから高速伝送路を用
いてデータを供給する Memory cube があり得る．キーテクノロジは TSV による 3 次元実
装技術であり，1bit の伝送を～10fJ/bit 程度の電力で実現でき，これは DRAM の伝送の
12.8GB/sec を約 600mW で実現できる（DRAM 全体で 6pJ/bit）[2-10]．あるいは，効率の
よい differential I/F は 200mW で 6GB/sec 程度の帯域を実現できる(3pJ/bit)ため，これを
DRAM の I/F に用いることで電力の削減を行うことも可能である[2-11]．
DRAM はスーパーコンピュータで最もチップ数が多く，それ故に，故障が多い部品で
ある．Soft Error Rate がチップあたり 10FIT (Fault in Time)程度で，世代ごとのデバイス自
体の信頼性の向上はない．従って，上位のスタックで信頼性を向上させる必要がある．
たとえば，京コンピュータでは Chipkill 機能などを導入することで DRAM チップの故障
によるシステムダウンを回避している．
(1)
不揮発メモリ
フラッシュメモリは計算機だけでなくスマートフォンなどのコンシューマーデバイスで
も多く活用されており，スーパーコンピュータの分野でも HDD よりも高速な不揮発記
憶として利用されている．その他， PRAM や MRAM といった不揮発性メモリの技術が
盛んに研究されている．これらのメモリは容量が DRAM と比較して増やせる・リフラッ
シュが不要なため電源を切ることで待機電力が減らせる・HDD よりは高速なアクセスが
可能・小さいフォームファクタといった特徴がある[2-12,13,14,15,16]．こうした特徴を生
かして，主記憶の代替や相対的に容量が減ると予想される主記憶をカバーする 1.5 次記
憶，不揮発であることを生かした高速なチェックポインティングデバイスとしての活用
が期待されており，実際に TSUBAME2.0 等の一部のスーパーコンピュータにおいて利用
されている．NAND フラッシュ以外の不揮発メモリは技術的に未成熟な面もあるが，そ
れを上回る効能が期待できるとして 2011 年現在では多くの研究開発がなされている．
2.1.3 データ転送技術
近年の大規模スーパーコンピュータでは 10000 以上のプロセッサを接続し，並列処理を
行うのが一般的である．並列処理では大規模な演算を実現するために，プロセッサ間で
通信を行う．プロセッサ数の増加に伴い，プロセッサ間通信のレイテンシ・帯域は今後
より重要になると予想される．
9
プロセッサ間通信に用いられるデータ転送技術はディジタル回路を構築するロジック
LSI と異なりアナログ技術に起因する部分が大きく，性能向上のトレンドは異なったも
のとなる．
(1)
電気転送
電気での高速転送技術としては，遅延を優先するパラレル転送と帯域や配線性を重視す
るシリアル転送が存在する．シリアル転送ではクロックをデータ信号に混ぜ送出するた
め 8B10B などのエンコードが必要である．こうした高速伝送技術も低電力・高帯域を目
指してロジック LSI やメモリデバイス同様に研究がなされている[2-17,18]．
パラレル転送は主に HyperTransport[2-19]や QPI などのメモリ系トラフィックを処理す
るプロセッサ間結合網で利用され，後者は PCI Express や Infiniband[2-20]などの I/O 系の
トラフィックを扱う通信で活用される．リンクあたり帯域はパラレル転送の場合にはシ
リアル転送の 50%～60%ほどの帯域となるが，エンコードする必要がないためレイテン
シが 10ns 程度短い．
2011 年現在，I/O では Infiniband QDR が 1 レーンあたり 8Gbps (10Gbps，8B10B)のシリ
アルインターフェースを活用し，約 150mW/lane の電力を消費する．2011 年現在では，
2013 年の EDR(26Gbps, 64B66B)までしかロードマップが提示されていないため，技術ト
レンドの外挿によって 2018 年の Infiniband の性能を予測すると，1 レーンあたり約
56Gbps (56Gbps，64B66B)の伝送帯域が同程度の電力で実現されると予測される．なお，
電気転送は信号の減衰問題から長距離転送を行うことができない．20Gbps を越える帯域
においては 2m～8m 程度の伝送距離となることが予想される．パラレル転送での伝送遅
延はおおよそ 2m で片道 20ns 程度である．
(2)
光転送
現代の技術トレンドで電気転送では 10m 以上の高速伝送を実現することは困難であるた
め，それ以上の距離の伝送を実現するためには光ケーブルを用いる．通信可能な帯域は
光波長多重通信などを用いることで電気転送と比較して高い転送速度を実現することが
できる．
現在のところ，計算を行うロジック LSI は電気通信を行うため，光通信のためには光電気変換を実施する必要がある．光電気変換には 5ns 程度の遅延が必要で片道あたり
10ns 程度のオーバーヘッドとなる．また，光がケーブル内を通過する際には 1m あたり
5ns 程度の遅延が発生する．2011 年現在，通信分野で 100Gbit Ethernet などで光ケーブル
あたり 100Gbps を達成しており，将来的にも電気転送の数倍の帯域を実現できることが
予想される．
また，光伝送は電気伝送と比較して高コストで信頼性も低いという問題点があったが，
2010 年に外部レーザーを用いたシリコンフォトニクス技術が実用化され，コストと信頼
性の問題が改善している[2-21]．この技術は Infiniband のケーブル等で既に実用化されて
市場に普及しており，国内では TSUBAME2.0 のインターコネクトで同技術が採用されて
いる．
2.1.4 2018 年までのプロセス世代別性能諸元予想
以上の技術動向を踏まえて，本節では将来のスーパーコンピュータ設計で利用可能な技
術に関して予測を行う．ここで予想する数値は適切，かつ，継続的な研究開発の結果と
して得られるであろう性能値である．
10
表 2-1 に半導体プロセスの世代別の性能を示す．表中の性能は 2.0GHz 前後で動作させ
ることを前提として演算器・SRAM などのサイズ・電力を予測した．そのため，より高
い周波数で動作させる場合には表中の数値より大きな規模・電力が必要となり，逆に低
い周波数では表中の数値よりも小さな規模・電力で各種コンポーネントは動作する．
表 2-1 プロセス世代別の性能予測
単位
利用可能時期
倍精度演算器サイズ
倍精度演算器消費電力
SRAM サイズ
SRAM 電力
レジスタファイル電力
On-chip バス(64bit)電力
TSV 転送電力(64bit)
Off-chip シリアル転送
Off-chip バス
シリアル転送チャネルサイズ
On-chip バスサイズ
光ケーブル転送レイテンシ
西暦年
um2
pJ/FLOP
MB/mm2
pJ/access
pJ/access
pJ/mm
pJ
pJ/bit
pJ/bit
mm2/ch
mm2/ch
ns/m
40nm45nm
2009
160000
20
0.24
6.30
12.00
7.00
12.00
50.00
0.60
4.00
5.00
28nm32nm
2011
90000
10.5
0.42
3.60
7.00
4.00
0.64
6.60
30.00
0.60
4.00
5.00
20nm22nm
2013
51000
6.0
0.74
2.06
4.00
2.29
0.37
3.77
17.14
0.60
4.00
5.00
15nm16nm
2015
29000
3.5
1.29
1.18
2.29
1.31
0.21
2.16
9.80
0.60
4.00
5.00
10nm11nm
2017
17000
2.0
2.25
0.67
1.31
0.75
0.12
1.23
5.60
0.60
4.00
5.00
7nm8nm
2019
13000
1.1
3.92
0.35
0.75
0.42
0.08
0.70
3.20
0.60
4.00
5.00
利用可能時期はそのデバイスが初めて登場する時期を示している．その為，大規模な
システムを構築する場合には普及までの期間を考慮する必要がある．例えば，京のプロ
セッサは 2009 年に動作していたが 10PFLOPS のシステムは 2011 年の 11 月まで待つ必要
があり，同様のタイムラグがあり得ることは留意するべきである．
性能面で留意するべき点は(1)データ転送の消費エネルギーと(2)データ転送のレイテン
シである．表中の数値から外挿すると 2018 年時点では，Off-chip バスでの 64 bit のデー
タ転送(約 200pJ)と On-chip バス(5mm)の 64 bit データ転送(約 2pJ)を比較すると，前者の
消費エネルギーが約 100 倍大きいということが分かる．将来のスーパーコンピュータは
消費電力に大きな課題を抱えていると言われており，Off-chip のデータ転送を如何に減
らすかが電力性能向上の重要な課題の一つであるといわれている．また，転送レイテン
シは光の速度以上に高速になることはないためテクノロジが進歩しても改善されないと
いう点にも留意するべきで，レイテンシを隠ぺいする技術や配線長を短くする実装技術
などが重要になると考えられる．
次に，この半導体デバイスに基づいてプロセッサの性能を予測した．2011 年時点で，
非常に多品種のプロセッサが普及しており，一つのオプションで将来の性能を予測する
ということは正確性に欠く恐れがある．そこで，本白書ではプロセッサを(1)高いシング
ルスレッド性能を指向する「レイテンシプロセッサ」と，(2)高いスループット性能を指
向する「スループットプロセッサ」の 2 種類に大別して予測を行なうこととした．また，
レイテンシプロセッサ上のコアを「レイテンシコア」，スループットプロセッサ上のコ
アを「スループットコア」と呼ぶ．何故ならば，将来のプロセッサは複数種類のコアを
搭載したヘテロジニアスマルチコアとなる可能性も指摘されているため，こうした特性
の異なるコアを同一のプロセッサに搭載する可能性もあるためである．
なお，現代のプロセッサでは PC/ワークステーション向けプロセッサ（Intel Xeon, IBM
Power，ARM Cortex-A シリーズ）がレイテンシプロセッサ・レイテンシコアに該当し，
GPU や ClearSpeed など，アクセラレータとして利用されるプロセッサがスループットプ
ロセッサ・スループットコアに該当する．各タイプのプロセッサを半導体トレンドに基
づいてスケールさせた場合の性能をそれぞれ表 2-2，表 2-3 に示す．
11
表 2-2 レイテンシプロセッサの性能予測
設計プロセス
レイテンシコア数
クロック周波数
演算器数
演算レイテンシ
ハードウェアスレッド数
スレッドあたりレジスタ数
キャッシュ容量
コア間共有キャッシュ容量
コア間同期・通信レイテンシ
コア間同期・通信帯域
CPU チップあたりメモリ容量
CPU チップあたりメモリ帯域
メモリレイテンシ
ノード内 CPU チップ数
ノード内通信レイテンシ
ノード内通信帯域
nm
個/chip
GHz
FMA/Core
ns
Thread/Core
本/スレッド
MB/core
MB
ns
GB/sec
GB
GB/sec
ns
個/node
ns
GB/sec
2012 年
32
4～8
3.0～4.0
4
1.0
4
16～64
2.0～4.0
16.0
65.0
64.0
32.0
50.0
40.0～80.0
2
80.0～200.0
8.0
2014 年
22
8～16
3.0～4.0
4
1.0
4
16～64
2.0～4.0
32.0
65.0
64.0
64.0
100.0
40.0～80.0
2
80.0～200.0
16.0
2016 年
16
16～32
3.0～4.0
8
1.0
4
16～64
2.0～4.0
64.0
65.0
128.0
128.0
200.0
40.0～80.0
2
80.0～200.0
32.0
2018 年
11
32～64
3.0～4.0
8
1.0
4
16～64
2.0～4.0
128.0
65.0
128.0
256.0
400.0
40.0～80.0
2
80.0～200.0
64.0
表 2-3 スループットプロセッサの性能予測
設計プロセス
レイテンシコア数
スループットコア数
クロック周波数
演算器数
演算レイテンシ
ハードウェアスレッド数
スレッドあたりレジスタ数
キャッシュ容量
コア間共有キャッシュ容量
コア間同期・通信レイテンシ
コア間同期・通信帯域
CPU チップあたりメモリ容量
CPU チップあたりメモリ帯域
メモリレイテンシ
ノード内 CPU チップ数
ノード内通信レイテンシ
ノード内通信帯域
nm
個/chip
個/chip
GHz
FMA/Core
ns
Thread/Core
本/スレッド
KB/core
MB
ns
GB/sec
GB
GB/sec
ns
個/node
ns
GB/sec
2012 年
32
0
32
1.0～2.0
8
4.0
4
64
32.0～64.0
16.0
100.0
64.0
8.0
150.0
40.0～80.0
4
80.0～200.0
8.0
2014 年
22
2
64
1.0～2.0
8
4.0
8
64
32.0～64.0
32.0
100.0
64.0
16.0
250.0
40.0～80.0
2
80.0～200.0
16.0
2016 年
16
4
128
1.0～2.0
16
4.0
16
64
32.0～64.0
64.0
100.0
128.0
32.0
500.0
40.0～80.0
1
80.0～200.0
32.0
2018 年
11
8
256
1.0～2.0
16
4.0
32
64
32.0～64.0
128.0
100.0
128.0
64.0
1000.0
40.0～80.0
1
80.0～200.0
64.0
プロセッサのハードウェアトレンドとしては(1)動作周波数の向上がない，(2)コア数の大
幅な増加がある，(3)メモリ・ネットワーク帯域の改善は演算性能の改善に比較して小さ
い，(4)レイテンシの改善はない，といった特徴が挙げられる．コア数の増加とメモリ・
ネットワーク性能の相対的な低下から大規模並列を意識したアプリケーション開発の支
援が重要な課題となることが予想できる．
表 2-2，表 2-3 に現れない定性的な要素としてコア間の通信・同期のメカニズムが挙げ
られる．基本的に，プロセッサ数・コア数の増加に伴い，より緩い通信モデルを採用す
る必要がある．例えば，GPU は L1 キャッシュ間や GPU チップ間での L2 のコヒーレン
スは保持しない設計で緩い通信モデルを採用している．さらに，そうした一貫性の緩和
が予想される中で同時に機能強化もなされると予想される．例えば，GPU に対する直接
の RDMA，同期専用プリミティブ，共有メモリの導入などがそうした点に相当する．た
だし，こうした機能はハードウェアトレンドのみで決定されるものでは無く，システム
ソフトウェアやプログラミング言語の発展に同期する必要がある．
12
2.2 システムアーキテクチャ・ソフトウェア
トレンド
スーパーコンピュータを構成する基本的な部品のトレンドに関して議論をしてきた．こ
こからはその部品を組み合わせて設計されたシステムに関して議論をする．その中で，
2000 年から 2011 年にかけての日本と世界のアーキテクチャの変遷に関して議論を行い，
現在までに実現されてきた技術を明らかにする．さらに，ハードウェアトレンドに沿っ
てシステム緒元の性能を外挿で予測を行い，今後のスーパーコンピュータ開発のための
出発点とする．
2.2.1 システムアーキテクチャの変遷と日本での技術開発
の成果
スーパーコンピュータのアーキテクチャは 1990 年代前半ではベクトル型・SMP が主流
であったが，2000 年代以降ワークステーションや PC に利用されるコモディティプロセ
ッサを用いたクラスタシステムが主流となっている．2011 年現在では Intel や AMD の開
発した x86 プロセッサを用いたクラスタシステムが TOP500 に登録されたシステムの約
90%（448 システム）を占める．これらの多く（446 システム）は OS として Linux を採
用している．
さらに，2000 年代中盤以降では GPU や Cell などのコンシューマ向けのプロセッサを
アクセラレータとして活用したシステムや組み込みプロセッサを搭載した SoC を用いる
システムがそれぞれ TOP500 で 1 位を獲得している．これらは x86 などの汎用プロセッ
サと比較してチップ上に搭載される演算器の個数が多く，電力・価格あたりの演算性能
が高く出来る傾向にある．現在のところ組み込みプロセッサでは PowerPC 以外のプロセ
ッサは HPC 領域に於いて殆どシェアを持っていないが，携帯電話の分野で圧倒的なシェ
アを誇る ARM が 64bit アドレス空間のサポートをしてサーバ領域へ進出することを表明
しており，構成や性能次第で普及する可能性もあると考えられる．
日本では，1990 年代～2000 年代前半にかけて，専用 LSI を含むハードウェア・ソフト
ウェアを開発するプロジェクトを遂行してきた．その成果としては数値風洞(NWT)，CPPACS，地球シミュレータ(ES)，京などがある．これらのシステムはそれぞれその時代で
の世界一を達成している．京を除くシステムはベクトル型，あるいは，擬似ベクトル型
とよばれる演算方式を採用していた．NWT は 1993 年稼動で 166PE，CP-PACS は 1996
年稼動で 2048CPU，ES は 2002 年稼動で 5120CPU，京は 2011 年稼動で 88128CPU と世
代毎にシステムに搭載されるプロセッサ数が増加している．
システムソフトウェアでは SCore などがクラスタ型並列実行環境の整備に貢献してき
た．SCore は今日においては世界的に広く使われるようになった Linux クラスタの初期
の発展・普及に大きく貢献した．その成果は Titech Grid，RSCC，PACS-CS の運用など
に用いられ，現在も開発が継続している．さらに，TSUBAME，T2K では専用の LSI を
開発せずに，コモディティのハードウェアを最大限に活用し，システムソフトウェアや
運用面での研究開発を行なってきた．
プログラミング言語では HPF や VPP Fortran から影響を受けた指示文に基づいた並列
言語 XcalableMP[2-22]，ライブラリでは行列演算や FFTE[2-23]，GPU に特化したライブ
ラリとしては NUFFT[2-24,25]，フレームワークは V-Sphere, HPC-Middleware[2-26]などが
研究開発されてきた．こうしたソフトウェア資産は京においても活用されつつある．た
13
とえば，京は Linux ベースの OS を採用しており，V-Sphere が京での 30720 コアを用い
た動作報告がされている．
GRAPE[2-27]，MD-GRAPE，QCDPAX では特定の目的に特化した計算機の設計が行わ
れ，ターゲットのアプリケーションに特化した専用の機能を設けることで汎用計算機と
比較して高い性能を得ている．完全な専用計算機でなく，N 体問題や行列積などの演算
回数に対して外部メモリとのデータ転送量が少ない処理からなるアプリケーションに対
応することを目指したアクセラレータとしては GRAPE-DR[2-28]があり 2010 年 11 月の
Green500 で 2+位に登録されている．現代では，こうしたアクセラレータ技術は広く普及
しており，TSUBAME は世界に先駆けて HPC 専用のアクセラレータ(ClearSpeed)や GPU
を活用して大規模なヘテロシステムを構築・運用している．TSUBAME はプロセッサや
メモリなどの主要な部品は Intel 社や NVIDIA 社などが販売するコモディティの部品を用
いているが，高性能・高密度・低消費電力を目指した計算ノードを開発し，更なる高性
能・低消費電力を実現している．2010 年稼働の TSUBAME2.0 では 2010 年 11 月の
TOP500 で 4 位・Green500 で 2 位の高い性能を実現している．
2.2.2 日本における今後の開発課題
今後，2018 年に向けて研究・開発をするにあたり前述のプロジェクトで得られた資産を
有効に扱うことは高い成果を出すために必要不可欠であるといえる．同時に，時代・技
術の移り変わりと共に変化しなくてはならない点を踏まえることもまた重要である．
2000 年以降，プロセッサのクロック周波数の向上はほぼ頭打ちとなったため，性能を
向上させるためにシステム中の演算器の数を大幅に増加させることで性能向上を実現し
てきた．これはチップ内の並列性（コア数）の増加，システム中のノード数の増加から
確認することが出来る．例えば，京は約 80 万コアを用いたシステムであり，NWT の
166 PE から 20 年間でコア数が約 4000 倍増加したことを示している．
しかし，同時にこの傾向はシステム中の部品点数の増加を招いている．それぞれの部
品の故障率が一定であると仮定した場合，部品点数が増加するとシステム全体の障害発
生率が増加する．京では，各部品に冗長回路やリトライ機能などの RAS 機能を搭載する
ことで故障率を低減し，約 10 万プロセッサでの動作に耐える高信頼なシステムを実現し
ている．
また，超並列計算機ではアプリケーションは並列化されなくては高い性能が得られな
いという問題を生じさせる．アプリケーションの並列化は利用するデータの分散化・プ
ロセス間の同期などを考慮する必要があるため逐次プログラムと比較すると難しく生産
性が低下する懸念がある．しかし，VPP Fortran や HPF などの開発経験に基づいた
XcalableMP や，すでに 1 万コア以上の並列計算機にて動作実績のある V-Sphere などのフ
レームワークの開発が進んでおり，今後これらの開発および普及を進めることでアプリ
ケーション開発における生産性低下の問題が低減されることが期待される．
また，性能指標として旧来の「演算性能あたりのメモリ帯域」などの指標に加えて，
2000 年代以降では｢演算性能あたりの電力｣という新たな指標が導入され，Green500[229]などの新しいベンチマークも登場している．地球シミュレータに代表される大型のベ
クトル計算機は，インタリーブメモリなどの機能が電力あたりの演算性能の向上を妨げ
ることが知られており，日本のスーパーコンピュータにおける大きな課題であった．例
えば，地球シミュレータ(42TFlops@6MW[2-30])の後継で 2008 年 6 月に TOP500 に登録さ
れた地球シミュレータ 2[2-31]は初代地球シミュレータから電力あたり性能を 6 倍向上さ
せているが，同時期（2008 年 6 月）の世界一位を獲得している RoadRunner の商用機は
Green 500 で 488MFlops/Watt の電力性能を達成しており，約 10 倍の大きな差があった．
京では地球シミュレータ 2 よりも 1 世代先の 45nm のプロセスで 2010 年 11 月の
14
Green500 で 829MFlops/Watt を達成し，国内で開発されたプロセッサとしては大幅に電力
効率を改善させている．しかしながら，2011 年 6 月の Green500 での 1 位は BlueGene/Q
であり，2079MFlops/Watt の電力効率を達成している．約 2.5 倍とその差を大きく縮め
たが，依然として差は大きいためキャッチアップするためにも今後の重点的な設計・開
発が必要である．
表 2-4 2018 年に向けた目標値と現在実現された数値の差分
課題
2018 年の目標値の例
2011 年までに国内で達成した成果
大規模並列
十万 CPU，数百コア/CPU のシステム
88128CPU，8 コア/CPU
ヘテロジニ
アスアーキ
テクチャ
特性の異なるコア（レイテンシコア・
スループットコア）が混じり合った環
境で高効率・高性能な計算を実現する
TSUBAME2(GPU)でノード内・ノ
ード間の不均一性を有する大規模
システムを構築
メモリ
B/F = 0.1 で高効率な計算を実現
メモリ階層を活用したライブラ
リ・フレームワークの開発
耐故障性
10 万プロセッサで MTBF=1 日以上
高信頼 CPU 約 10 万個を利用した
Linpack で 28 時間動作させ
10PFLOPS を実現
電力
50GFLOPS/Watt の演算性能
アクセラレータ利用で約
1.6GF/Watt
大規模構成で 829MFlops/Watt
（京）
生産性
上記環境での生産性向上
SCore, XcalableMP, HPC-MW で~1
万コア程度まで実績がある
表 2-4 に 2018 年に向けた技術開発の目標例（4.1.3. エクサシステムの構成例参照）と
現在の日本が実現している技術レベルをまとめた．京では約 10 万 CPU でのシステム運
用を実現しており，今後の目標値を省みても十分なスケーラビリティを実現したといえ
る．だが，コア数（8 コア/チップ）は 2018 年の目標の数百コアからは大きな乖離がある
ことがわかる．さらに，信頼性の観点では，10 万プロセッサの超大規模システムで 24
時間以上の MTBF を達成する信頼性も実現している．ヘテロジニアスアーキテクチャ，
メモリ階層，高信頼，低消費電力に関しても既に実現できている部分も多いことがわか
る．
さらに，SC11 では京および TSUBAME2.0 を用いた科学技術計算の成果がそれぞれ地
球シミュレータ以来となるゴードン・ベル賞を獲得した．これは単に計算機を作る，あ
るいは，Linpack などのベンチマークで高いスコアを達成する以上に重要な「その計算機
を用いて科学的成果を出す」という実績があることを示している．1 章冒頭で述べたと
おり，スーパーコンピュータはサイエンスを実現する強力なツールであり，こうしたア
プリケーションとの協調できる素地があることは最も重要な資産であると言える．
こうした幅広い技術的な資産（プロセッサ開発，システムソフトウェア，アプリケー
ションとの協調）を持つ国は米国の他には日本だけであり，最先端のスーパーコンピュ
ータ開発を主導出来る立場にあるといえる．
15
2.2.3 プロセッサとメモリ 2018 年のシステム性能予想
次に，将来のシステムの性能に関して述べる．将来のシステム構成を検討するにあたり，
2011 年から 2012 年にかけてアプリケーション開発者を交えた合同作業部会を複数回に
わたって開催し，サイエンスロードマップを達成する為に最適と考えられる計算機構成
を議論した．その中で 32 種類のアプリケーションに関して分析を行い，必要な演算性
能・メモリ量・メモリ帯域・通信性能などに関して議論を行った．
作業部会の議論の結果，アプリケーションごとに最適と考えられるシステム構成は異
なっており，プロセッサ・メモリ構成とネットワーク構成はそれぞれ数種類に分類する
のが望ましいということが分かった．今回の検討では京とほぼ同程度の消費電力・設置
面積で実現できること(20MW～30MW，2000m2～3000m2)を制約条件としている．作業
部会での検討の結果，プロセッサ・メモリ構成は 4 種類に分類するのが適当であると結
論付けられた．その分類とは(1)京のように汎用的に様々な問題に適用可能な「汎用型」，
(2)汎用型から演算性能を落としてメモリ性能により多くの資源を割いた「容量・帯域重
視型」，(3)メモリ性能を落として演算性能により多くの資源を割いた「演算重視型」，
メモリ容量を極限まで削減し，(4)オンチップメモリですべての計算を完結させることを
目指した「メモリ容量削減型」の 4 つである．表 2- 5 に各分類で実現される性能予測を，
図 2-1 にアプリケーションの要求性能と上記の 4 分類が適するアプリケーション領域の
相関を示す．ここでの性能予測は、今後の適切、かつ、継続的な技術開発が行われるこ
とを想定している。
表 2-5 20MW で実現できるシステム性能予測（ただし，京のみ消費電力 12.66MW）
総演算性能
総メモリ帯域
総メモリ容量
汎用（従来型）
200～400 PFLOPS
20~40 PB/s
20～40 PB
容量・帯域重視
50～100 PFLOPS
50~100 PB/s
50～100 PB
演算重視
1000～2000 PFLOPS
5~10 PB/s
5～10 PB
メモリ容量削減
500～1000 PFLOPS
250～500 PB/s
0.1～0.2 PB
京（参考）
10 PFLOPS
5 PB/s
1.2 PB
16
1.0E+1
容量・帯域
要求メモリ帯域(B/F)
1.0E+0
容量削減
汎用型
1.0E-1
1.0E-2
演算重視
1.0E-3
1.0E-4
1.0E-3
1.0E-2
1.0E-1 1.0E+0 1.0E+1
要求メモリ容量(PB)
1.0E+2
1.0E+3
図 2-1 アプリケーションの要求性能と各計算機の実現する性能の相関
ネットワークは(1)隣接するデータ同士が情報を交換することに適している Low-Radix ネ
ットワークと，(2)Bisection 帯域やシステム直径の短縮に注力した High-Radix ネットワー
クの 2 つに分類した．ストレージに関しては計算ノードに付加するローカルストレージ
と，任意の計算ノードからアクセス可能なグローバルストレージの 2 段階構成で検討を
行った．表 2-6，表 2-7 に 2018 年に上記の分類に基づいて 20MW で実現できるシステム
諸元を見積もった．ネットワーク構成・ストレージ構成に関してはプロセッサ・メモリ
構成と比較して検討が不十分な点もあり，今後の研究開発のなかで必要な機能・性能を
明確化することが必要である．
表 2-6 ネットワーク諸元
High Radix (Dragonfly)
Low-Radix (4D-Torus)
Injection
P-to-P BW
Bisection
最短遅延
最長遅延
32 GB/s
128 GB/s
32 GB/s
16 GB/s
2.0 PB/sec
0.13 PB/sec
200 ns
100 ns
1000 ns
5000 ns
表 2-7 ストレージ諸元
総容量
1EB
おおよそメモリ容量の 100 倍程度
総帯域
10 TB/s
メモリ容量を約 1000 秒で退避する程度
17
2.3 将来の技術開発に向けて
本節では，今後のスーパーコンピュータに用いられる基本的なハードウェア・システム
アーキテクチャの技術とその成長トレンドに関して予測を行い，適切，かつ，継続的な
技術開発をした場合に 2018 年に得られる技術に関して述べた．この数値は現時点で考え
られる現実的な性能予想ではあるが「開発目標」ではない．また，サイエンスロードマ
ップで要求される性能は本節の予測性能を上回るものであり，この予測性能を上回る高
性能なスーパーコンピュータを開発することは，サイエンスロードマップ達成のために
も必須である．本白書では，ここから更なる高性能計算を実現するにあたり，3 章で現
在のスーパーコンピュータが抱える課題を明確化し，4 章でその課題を乗り越えるため
にどのような研究開発を行なうべきかを述べる．
2.4 参考文献
[2-1] ITRS roadmap, http://www.itrs.net/
[2-2] Peter Kogge, Keren Bergman, Shekhar Borkar, Dan Campbell, William Carlson, William
Dally, Monty Denneau, Paul Franzon, William Harrod, Kerry Hill, Jon Hiller, Sherman
Karp, Stephen Keckler, Dean Klein, Robert Lucas, Mark Richards, Al Scarpelli, Steven
Scott, Allan Snavely, Thomas Sterling, R. Stanley Williams, Katherine Yelick, ExaScale
Computing Study: Technology Challenges in Achieving Exascale Systems, September 28,
2008
[2-3] Mark Bohr, The New Era of Scaling in an SoC World, ISSCC2009,ftp://download.intel.com/technology/architecturesilicon/ISSCC_09_plenary_bohr_presentation.pdf
[2-4] ISSCC 2011 Trend Reports, http://isscc.org/doc/2011/2011_Trends.pdf
[2-5] Son Dao Trong, Martin Schmookler, Eric M. Schwarz , Michael Kroener, P6 Binary
Floating-Point Unit, In Proceedings of the 18th IEEE Symposium on Computer Arithmetic.
[2-6] J. Pille, D. Wendel, O. Wagner, R. Sautter, W. Penth, T. Froehnel1, S. Buettner, O.
Torreiter, M. Eckert, J. Paredes, D. Hrusecky, D. Ray, M. Canada, A 32kB 2R/1W L1 Data
Cache in 45nm SOI Technology for the POWER7TM Processor (ISSCC2010)
[2-7] J. Barth, D. Plass, E. Nelson1, C. Hwang, G. Fredeman, M. Sperling, A. Mathews, W.
Reohr, K. Nair, N. Cao, A 45nm SOI Embedded DRAM Macro for POWER7TM 32MB
On-Chip L3 Cache (ISSCC2010)
[2-8] JEDEC Committee JC-42.3 JESD79-3D, 2009
[2-9] Micron Technologies, Inc. DDR3 SDRAM system-power calculator, revision 0.1, 2007
[2-10] J-S. Kim, C. Oh, H. Lee, D. Lee, H-R. Hwang, S. Hwang, B. Na, J. Moon, J-G. Kim,H.
Park, J-W. Ryu, K. Park, S-K. Kang, S-Y. Kim, H. Kim, J-M. Bang, H. Cho, M. Jang,C.
Han, J-B. Lee, K. Kyung, J-S. Choi, Y-H. Jun, A 1.2V 12.8GB/s 2Gb Mobile Wide-I/O
DRAM with 4×128 I/Os Using TSV-Based Stacking (ISSCC2011)
[2-11] J. Thomas Pawlowski, "Hybrid Memory Cube: Breakthrough DRAM Performance with a
Fundamentally Re-Architected DRAM Subsystem" Hot-Chips 23, 2011.
[2-12] Kang et al. A 0.1um 1.8V 256Mb 66MHz synchronous burst PRAM. In International SolidState Circuits Conference, 2006.
[2-13] M. Motoyoshi, et al., ”A study for 0.18um high-density MRAM.”, 2004 VLSI Symposium,
22, 2004
[2-14] H. Kim, J-H. Park, K-T. Park, P. Kwak, O. Kwon, C. Kim, Y. Lee, S. Park, K. Kim, D.
Cho, J. Lee, J. Song, S. Lee, H. Yoo, S. Kim, S. Yu, S. Kim, S. Lee, K. Kyung, Y-H. Lim,
C. Chung, A 159mm2 32nm 32Gb MLC NAND-Flash Memory with 200MB/s
Asynchronous DDR Interface (ISSCC2010)
18
[2-15] H. Chung, B. Jeong, B. Min, Y. Choi, B-H. Cho, J. Shin, J. Kim, J. Sunwoo, J-M. Park,Q.
ang, Y-J. Lee, S. Cha, D. Kwon, S. Kim, S. Kim, Y. Rho, M-H. Park, J. Kim, I. Song,S. Jun,
J. Lee, K. Kim, K-W. Lim, W-R. Chung, C. Choi, H. Cho, I. Shin, W. Jun, S. Hwang,K-W.
Song, K. Lee, S-W. Chang, W-Y. Cho, J-H. Yoo, Y-H. Jun, A 58nm 1.8V 1Gb PRAM with
6.4MB/s Program BW, Samsung Electronics (ISSCC2011)
[2-16] D. Takashima, M. Noguchi, N. Shibata, K. Kanda, H. Sukegawa, S. Fujii, An Embedded
DRAM Technology for High-Performance NAND Flash Memories, (ISSCC2011)
[2-17] G. Balamurugan, F. O'Mahony, M. Mansuri, J. E. Jaussi, J. T. Kennedy, B. Casper , A 5-to25Gb/s 1.6-to-3.8mW/(Gb/s) Reconfigurable Transceiver in 45nm CMOS
[2-18] M-S. Chen, Y-N. Shih, C-L. Lin, H-W. Hung, J. Lee, A 40Gb/s TX and RX Chip Set in
65nm CMOS, (ISSCC2011)
[2-19] HyperTransport Consortium, http://www.hypertransport.org/
[2-20] Inifiniband Trade association, http://www.infinibandta.org/
[2-21] Brian Welch, Silicon Photonics: Optical Connectivity at 25 Gbps and Beyond, Hot Chips
2010
[2-22] XcalableMP, http://www.xcalablemp.org/
[2-23] FFTE: A Fast Fourier Transform Package, http://www.ffte.jp/
[2-24] A. Nukada, Y. Ogata, T. Endo, S. Matsuoka, “Bandwidth intensive 3-D FFT kernel for
GPUs using CUDA,” Proceedings of ACM/IEEE Supercomputing (SC’08), 2008.
[2-25] A. Nukada, S. Matsuoka, “Auto-tuning 3-D FFT library for CUDA GPUs,” Proceeding of
ACM/IEEE Supercomputing (SC’09), 2009.
[2-26] Kengo Nakajima, Preconditioned Iterative Linear Solvers for Unstructured Grids on the
Earth Simulator, 2004
[2-27] The Grape Project, http://www.astrogrape.org/
[2-28] Junichiro Makino, Kei Hiraki, Mary Inaba, GRAPE-DR: 2-Pflops massively-parallel
computer with 512-core, 512-Gflops processor chips for scientific computing, SC07
[2-29] The Green500, http://www.green500.org/
[2-30] 地球シミュレータ,http://www.jamstec.go.jp/esc/publication/brochures/pdf/esc2004.pdf,
[2-31] JAMSTEC 地球シミュレータ 2 プレスリリー
ス,http://www.jamstec.go.jp/j/about/press_release/20080512/index.html
19
3. 技術課題
本章では 2 章で述べた技術動向に基づき，2018 年前後までのスーパーコンピュータ開発
に関する重要技術課題を提示する．最初にアプリケーション作業部会によるサイエンス
ロードマップを達成するための特に重要である，ヘテロジニアスアーキテクチャ，メモ
リ，大規模並列性，耐故障性，低消費電力，大規模データ処理，生産性の 7 つの重点課
題についてまとめ，最後にスーパーコンピュータに関する周辺技術課題について述べる．
3.1 ヘテロジニアスアーキテクチャ
3.1.1 概要・前提
従来の CPU は主にレイテンシコアのみから構成され，その面積・電力あたりの性能改善
率が著しく低下してきており，微細化やアーキテクチャの改良に対し CPU 単体の大幅な
演算性能向上が困難となっている．このためレイテンシコアを多数搭載するメニーコア
化により並列処理を前提として性能を向上させるアプローチが主流となっているものの
電力あたり性能の改善は十分ではない．これに対し，より電力性能に優れたスループッ
トコアを多数搭載したアクセラレータの研究開発が世界的に近年盛んに行われている．
アクセラレータでは単体コア性能は従来のレイテンシコアと比較して劣るものの，それ
らを多数搭載することでプロセッサ全体のスループットを大幅に向上させ，かつ電力性
能の向上が可能である．
このようなアクセラレータを従来のレイテンシコアから構成される CPU と共用した
「ヘテロジニアスアーキテクチャ」がシステム全体の電力性能を向上させる方法として
有望視されている．既に GPU といったコモディティなアクセラレータが利用可能であり，
ピーク性能の大部分をアクセラレータに頼るアプローチのスーパーコンピュータが実際
に運用されている実績もある．以下，これまでに開発されてきた主なアクセラレータに
ついてその特徴を示す．
·
NVIDIA 社 GPU (Tesla): 細粒度並列性に基づく，ホスト CPU と疎結合のスループ
ットコアから構成されるアクセラレータ．MIMD 並列実行を行う複数のストリーミ
ングマルチプロセッサから成る．各プロセッサは SIMD 並列性を利用するための複
数のスレッドプロセッサにより構成されている．大きな特徴として，複数のスレッ
ドを切り替えて実行するマルチスレッディングによりメモリおよび演算レイテンシ
を隠蔽し，高スループット実行を実現する．このため細粒度かつ並列度の高いプロ
グラミングモデルに適している．一方，現時点においてはホスト CPU とはメモリ空
間を共有せず PCI-Express などにより接続されることから，ホスト CPU とアクセラ
レータ間のデータ転送は比較的低帯域かつ長レイテンシとなる．
20
·
·
·
·
·
Intel 社 Many Integrated Core (Knights Ferry ): 粗粒度の並列スレッド実行にも適
した，ホスト CPU と疎結合のアクセラレータ．各コアは比較的汎用性が高く，仮想
メモリをサポートしスレッド実行をソフトウェア管理可能である．このため，
NVIDIA 社 GPU と比較してより粗粒度の並列プログラミングモデルも対象となる．
主にコヒーレントキャッシュを含むオンチップメモリ階層により平均メモリレイテ
ンシを削減し，演算器の稼働率を維持する．PCI-Express を介したホスト CPU と疎結
合のアクセラレータではあるが，仮想メモリサポートにより OS レベルでホスト
CPU とのメモリ空間を共有可能である．
AMD 社 Fusion APU: ダイ上にホスト CPU と GPU が実装されている密結合の細粒
度コアアクセラレータである．ホスト CPU とはメモリ空間が共有されている．
Sony/Toshiba/IBM 社 CELL/B.E.: チップ内にホスト CPU と粗粒度のコアが実装さ
れ，オンチップネットワークやローカルメモリを介して相互に接続される密結合の
アクセラレータ．コヒーレントキャッシュやマルチポートキャッシュが用いられて
いないため，ホスト CPU とアクセラレータ間でメモリ空間は共有されておらず，明
示的なデータ転送が必要となる．
NEC 社 SX9 ベクトルプロセッサ: ホスト CPU のデータパスの一部がアクセラレー
ションのためのベクトルパイプラインとなっている，融合結合のアクセラレータ．
ホスト CPU の命令セットによりアクセラレーション部を使用する．高いメモリバン
ド幅とチェイニングなどのパイプライン実行により高スループット演算を実現する．
FPGA（回路再構成可能デバイス）: 任意の論理回路に構成可能なロジックブロッ
ク，整数演算器，オンチップメモリとこれらを自由に接続するための配線リソース
により構成される疎結合の極細粒度プログラマブルロジックアクセラレータ．必要
に応じて対象計算の計算アルゴリズムやデータ移動に特化したデータパスや制御ハ
ードウェアを構成することにより，効率の良い並列演算が様々な粒度で可能である．
これまで FPGA はビット演算等の整数演算の高速化に用いられてきた一方で，近年
では浮動小数点演算性能でも CPU を超えるまでに至っている．他のアクセラレータ
と異なり，構成するハードウェアを決定する必要があるため生産性の点で不利とな
る.
上記の例に加えて今後もさらに性能および生産性を改善するアクセラレータの開発が
世界的に見込まれ，その優れた電力効率を有効に活用することはサイエンスロードマッ
プ達成のためのスーパーコンピュータの実現に重要となりうる．以下，アクセラレータ
のアプリケーションへの適用における主要な課題について述べる．
3.1.2 課題
(1)
アーキテクチャ設計
多数のアクセラレータが用いられるシステムにおいて電力性能比を向上させるためには，
個々のアクセラレータの稼働率を維持しながら台数に応じた実効性能を与える高スケー
ラビリティの実現が課題である．これに対し，レイテンシコアとスループットコア間，
あるいはチップ内外におけるスループットコア間の同期やデータ共有のオーバーヘッド
を低減するアーキテクチャが求められる．さらに，演算処理およびデータ参照の特性が
異なる個々の対象計算問題に対しても，不要なデータ移動などを低減し過剰な電力消費
を抑えることの可能なアーキテクチャ設計が重要となる．以下に特に実効性能を大きく
左右するレイテンシコアとの結合方式，およびスループットコア間の結合方式について
述べる．
21
·
·
レイテンシコアとの結合方式：現在の代表的なアクセラレータである GPU は一般に
PCI-Express などの I/O を介してレイテンシコアと接続されているため，その帯域不
足や遅延がアクセラレータによる高性能計算のオーバーヘッドとなっている．この
ような問題を軽減するために，レイテンシコアとスループットコア間の結合を改善
する必要がある．
スループットコア間結合方式：レイテンシコアとの結合に加え，チップ内外におけ
るスループットコア間の結合も重要である．特に複数のノード上の複数のアクセラ
レータを用いて並列に計算を行う場合には，現在の GPU クラスタではアクセラレー
タ間のデータ通信や同期を I/O およびノード間ネットワークを経由して行う必要があ
ることから，その大きな遅延を隠蔽できない問題ではスケーラビリティが低下する．
また，以下に述べるアプリケーション開発における課題の多くはアクセラレータアー
キテクチャの制約に起因するものであり，電力効率最適化と同時にプログラミングの生
産性改善のためのアーキテクチャ支援も重要である．例えば PCI-Express によって CPU
と疎結合されたアクセラレータにおいてもシステムソフトウェアおよびそれを支援する
ハードウェアにより仮想的な共有メモリ空間を実現する研究開発が既に進行している．
今後，システムソフトウェアなどのソフトウェアレイヤとの協調設計などにより柔軟性，
生産性を改善するアーキテクチャ研究開発が望まれる．
サイエンスロードマップを達成するのに相応しいアクセラレータアーキテクチャ，ノ
ード構成を選定し，必要に応じてコモディティ製品を調達するか，独自開発を行う必要
がある．一方，アーキテクチャおよびコンパイラの開発には莫大な開発コストおよび技
術的積み重ねが必要であるためその設計や開発の決定は慎重に行うことが求められる．
現在の GPU，MIC 等はコモディティ製品との設計共通化による経済的・技術的レバレッ
ジを実現し，それによる開発コストの大幅な削減を実現している．今後のアクセラレー
タの開発においても電力効率向上と同時にその開発コストの削減を可能とする設計が望
まれる．また実際の開発には年単位で開発期間がかかることから，完成時のテクノロジ
を見据えた上で早い時期に着手すべきであり，ソフトウェアスタック開発にできるだけ
早く情報を提示するべきである．
(2)
ヘテロジニアスシステム向けシステムソフトウェアの開発
既存のシステムソフトウェアは多くの場合にアクセラレータの存在を考慮していない．
その利用は各ユーザプログラムの責任により各アクセラレータベンダーが用意したラン
タイムやドライバを介して行われているのが現状である．以下ではシステムソフトウェ
アがアクセラレータを first class のオブジェクトとして扱っていないことに起因する課題
について挙げる．より詳細には，現在主流の疎結合アクセラレータにおいて生じる課題，
および将来増加すると見られる密結合アクセラレータや高機能なアクセラレータにおい
て生じる課題について述べる．
1. 現在の OS およびジョブスケジューラにおいては，原則的にアクセラレータは CPU
のようなスケジュール対象リソースとしては考慮されていない．システムソフトウ
ェアが，利用率や affinity を考慮して最適なスケジューリングを行い，CPU 上のプロ
セスと密に連携させで管理することは課題の一つであり，そのためにはプロセス管
理モデル，ロードモジュール形式，プログラムロード方式の検討が必要である．
2. 現在の実装では MPI などの通信ランタイムとアクセラレータのランタイムが別であ
るために，複数ノード・複数アクセラレータを用いたアプリを記述するには，複数
ホップの通信をユーザが記述する必要がある．このようなヘテロジニアス環境を実
行性能に影響を与えない範囲で隠ぺいし，統一的な API を持ち，また非同期通信や
通信と計算のオーバーラップを支援するメモリシステムと通信ランタイムを実現し
なければならない．
22
3. ホストとメモリ空間を共有する密結合アクセラレータの場合に，OS のページング処
理などのメモリ管理処理が現在のままでよいか，アーキテクチャを考慮し検討する
必要がある．また，アクセラレータコアが高機能となりシステムコールや I/O の一部
が可能となった場合に，ホスト側 OS とアクセラレータ側 OS またはランタイム間の
切り分けなど，システムソフトウェア設計の再検討が課題である．
4. ホストとメモリ空間を共有しない疎結合アクセラレータの場合においても，アクセ
ラレータ上のメモリをホストメモリ上の一つの階層として捉え，OS のメモリ管理機
構によって統一的に管理することが可能である．プログラミング言語やアプリケー
ションなどのソフトウェア階層に対して疎結合アクセラレータの適切なメモリ階層
の検討が必要である．
上記課題に対するシステムソフトウェア研究開発は対象とするアクセラレータのアー
キテクチャに強く依存する．例えば現状ではアクセラレータ間の直接通信は一部を除い
て不可能だが，ポストペタおよびその先の世代のアクセラレータではそのような機能も
備えることが想定される．アーキテクチャ開発と密な連携を取り，ハードウェア処理部
分およびソフトウェア処理部分の適切な切り分けに考慮した研究開発が必要である．
(3)
ヘテロジニアスシステムにおけるアプリケーション設計・開発
並列化のためのプログラミングモデルとして MPI や OpenMP などがすでに確立されてお
り，それらを用いて開発されたアプリケーションは今後も中長期的に継続して利用可能
であることが見込まれる．一方，アクセラレータのためのソフトウェア開発手法は確立
されているとは言い難く，現在主流となっている CUDA に代表されるプログラミングモ
デルや性能最適化技法もアクセラレータの種類やその世代によって流動的である．例え
ば，GPU の機能向上に伴って CUDA の仕様は頻繁に更新されており，いくつかのパラメ
ータを GPU の種類や世代ごとに再設定する必要もある．このような状況下では，ヘテロ
化したシステム向けにアプリケーションを開発したとしてもその中長期的な利用は見込
めない．この状況を解決するために多様なアクセラレータを共通のプログラミングモデ
ルで利用できる環境の構築が課題である．
またそのようなプログラム記述上の可搬性を達成することに加えて高効率アプリケー
ションの開発支援が必要である．異種複数のプロセッサから構成されるシステムにおい
て最大のパフォーマンスを得るためには，対象環境に合わせた問題の分割や割り当てが
必要である．そのため，同一アーキテクチャのコアから構成されるシステム向けのアプ
リケーション開発と比較して，ヘテロジニアスアーキテクチャにおいてはアプリケーシ
ョンの設計やその実装の選択肢が大幅に広がり難易度が著しく高くなる可能性がある．
また，今日では異なるアクセラレータアーキテクチャではアプリケーション性能の最適
化手法も異なり，常に最適な性能を実現するためには個々のアクセラレータアーキテク
チャを強く意識したプログラミングが必要であり，プログラミングの負荷が大きい．そ
のようなアーキテクチャの違いを透過的に吸収し，各プロセッサへの役割分担やそれに
伴うデータの配置を適切に行うためのプログラミングモデルやアルゴリズムの開発，お
よびそれを支援する機構やツールの実現が課題である．
また，アプリケーションを中長期的に継続して利用するためには，上記の研究開発に
加えて，ソフトウェアの設計指針をアプリケーション開発者に示すことも重要である．
ヘテロジニアスアーキテクチャ化によるソフトウェアの短命化を回避するためには，ア
プリケーション開発者が必要以上にシステム構成を意識する必要のない，適切な抽象化
を提供する高水準プログラミング言語やフレームワーク，ライブラリなどの実現が必要
である．
23
3.2 メモリ
古くからプロセッサ性能向上に対してメモリ性能の向上が見込めないというメモリウォ
ール問題が指摘されているが，エクサスケールでは加えて「容量」「電力」という新た
な制約がメモリウォール問題をより深刻にすると予測される．
実際に，2002 年に TOP500 で一位だった地球シミュレータはノードあたりの性能が
64GFLOPS に対してメモリ帯域が 256GB/sec，メモリ容量 16GB であったが，2011 年の
TOP500 の一位である京コンピュータではノードあたりの性能が 128GFLOPS に対してメ
モリ帯域 64GB/sec，メモリ容量 16GB となっており，FLOPS あたりのメモリ帯域・容量
は年を追う毎に低下する傾向にある．
メモリウォールを解決するには，今後登場する様々なメモリテクノロジデバイスを知
り，それぞれの長所を生かして，短所を補うアーキテクチャの設計が必要となる．まず，
候補となるメモリデバイスの特徴を以下に列挙する．一般に，メモリデバイスは小容量
なものほど高速で大容量なものほど低速になるという特性を持つ．この節ではエクサス
ケールシステムで実現されるメモリシステムの制約をハードウェア技術トレンドから吟
味する．
現代のスーパーコンピュータでは，コストと性能の観点から DDR メモリが広く利用
されている[3.2-1]．しかしながら，近年，DDR メモリの性能と電力がシステム設計の大
きな制約となって来ており，将来のスーパーコンピュータに向けて様々な代替案が提案
されている．主記憶には演算に必要な電力の約 15%から 25%が利用されているが，エク
サを実現するにはその割合を下げる必要があると考えられている[3.2-2]．ここでは主記
憶に 2MW（目標のシステム電力 20MW の約 10%）を割り振った場合に実現可能な主記
憶の構成に関して吟味する．
·
·
·
·
DDR 系の DRAM: DRAM チップの電力はほぼ横ばいの状態が続いており，今後も
その傾向は継続すると予想される．現在の DDR3 メモリの電力[3.2-3]から，2018 年
頃の DRAM チップは 1 枚あたりバス帯域 6.4GB/sec (DDR5-6400)，容量 2GB，電力
400mW 程度になると予想される．従って，2MW の電力で実現できるメモリシステ
ムはメモリ帯域 32PB/sec (B/F=0.03)，メモリ容量 10PB である．
メモリキューブ: メモリキューブは Single-End Full Swing の DDR 系インターフェー
スと比較して効率の良いシリアルインターフェースをメモリインターフェースとし
て用いることで DDR メモリの電力効率を改善する技術である[3.2-4]．DRAM のコン
トローラをメモリ側に持たせることで，従来の DDR と比較して細粒度のメモリアク
セスを可能にするという特性も併せ持つ．2018 年のメモリキューブチップの性能は
チップ 1 枚あたり 256GB/sec(20Gbps * 128ch)，容量 8GB，電力 5W 程度になると予
想される．2MW の電力では，102.4PB/sec (B/F = 0.1), メモリ容量 3.2PB である．
Wide I/O（DRAM 積層）: メモリキューブ同様に注目されているのがロジック LSI
に対して直接 DRAM を積層する Wide I/O 技術である．これはモバイル系のデバイス
に利用されることを前提に検討されているメモリ規格である．2018 年の Wide I/O は
1 モジュールあたり 50GB/sec (533MHz * 128B)，1GB，250mW 程度となると予想さ
れる．2MW の電力では，メモリ帯域 400PB/sec (B/F = 0.4)，メモリ容量 8PB 程度と
なる．ただし，プロセッサ上にメモリを積層するという技術は他の方式と比較して
未成熟であり 2018 年に低コストで実現できない可能性もある．
不揮発メモリ: メモリ階層に Flash メモリや PRAM・MRAM・FeRAM といった不揮
発性メモリを用いることが検討されている．これらのメモリはデバイス毎に異なる
特性をもつ[3.2-5]．多くの場合には，容量が DRAM と比較して増やせる・リフラッ
シュが不要なため電源を切ることで待機電力が減らせる・HDD よりは高速なアクセ
スが可能・小さいフォームファクタといった特徴がある．こうした特徴を生かして，
主記憶の代替や相対的に容量が減ると予想される主記憶をカバーする 1.5 次記憶，不
24
·
揮発であることを生かした高速なチェックポインティングデバイスとしての活用が
期待されている．NAND フラッシュ以外の不揮発メモリは技術的に未成熟な面もあ
るが，それを上回る効能が期待できるとして 2011 年現在では多くの研究開発がなさ
れている[3.2-8]．
オンチップメモリ: 上記でみられるように主記憶のメモリ帯域はエクサスケールス
ーパーコンピュータでは，DDR 系の DRAM の性能トレンドから予測すると，現在の
1/10 程度になることが予想される．そのため，メモリ参照のローカリティを生かし
た計算を行うことが性能を引き出す上でますます重要になる．その際に最も重要に
なるのがオンチップメモリの容量である．
オンチップメモリとしては SRAM と eDRAM が実用化されている．SRAM は 6T～
8T 程度のトランジスタによって記憶素子を構成し，2018 年ではチップ上に 100MB～
200MB 程度集積されることが予想される．eDRAM では更に数倍の容量の集積が可
能になる．このオンチップメモリはキャッシュやローカルメモリとして活用するこ
とが可能である．
この他，高速プロセスでの実用化はされていないが，PRAM や MRAM といった不
揮発メモリを用いる方法もあり得る．不揮発メモリは利用しないときに電源を切っ
ても内容が失われない・一つの素子で多値を記憶することが出来るといった特性か
ら，リーク電力が小さい・大容量のオンチップメモリとして活用されることが期待
されている．
エクサスケールに向けて検討すべきメモリ関連の課題を以下に列挙する．メモリのハ
ードウェアトレンド予測に見られる通り，DDR 系の DRAM デバイスではメモリシステ
ム自体の帯域・容量は現在のアーキテクチャから約 1/10 程度に性能が悪化することが予
想される．計算機では，この問題は「メモリウォール問題」として知られている．伝統
的にキャッシュメモリなどに代表されるメモリ階層を採用することでこの問題を緩和し
ており，今後もその重要性はますます増している．本セクションでは，ハードウェアト
レンドから予測されるメモリシステム性能を補うための技術に関して述べる，
3.2.1 メモリ階層によるメモリ帯域の改善
先ほどのトレンド予測では，エクサスケールシステムでは京と比較して 1/10 程度の低い
B/F 比のメモリシステムしか実現できないと予想された．この問題を緩和するためには，
オフチップメモリとのトラフィックを削減する必要がある．
従来はハードウェアとソフトウェアがそれぞれ個別に対策を行なってきたが，両者が強
調することでより高い成果が期待できると予想される．
·
キャッシュメモリ: キャッシュメモリは一旦アクセスしたデータをオンチップメモ
リに保持することでデータの参照局所性を利用する技術である．参照局所性を強化
するためのライトバッファや Miss Status Holding Register (MSHR)もキャッシュ技術の
一つとする．トラフィックの削減を行うためには，将来利用するデータを様々な情
報を利用して判断する必要がある．一般にはハードウェがデータの取捨選択の決定
を行なうが，ここにヒントを出すことで更なるトラフィックの改善ができると期待
されている．
たとえば，京コンピュータのセクターキャッシュはソフトウェアのヒントによっ
てハードウェアのキャッシュ置き換え方式を制御するというコデザインの一つであ
ると考えられる．こうしたデザインでのソフトウェア I/F のデザインや資源管理をど
う行うかはシステムソフトウェア・アーキテクチャの双方が協力するべき課題であ
るといえる．
25
·
·
ローカルメモリ: キャッシュメモリはハードウェアでの自動制御が前提となって設
計された技術であり，ソフトウェア制御が向かない部分もある．そのため，ソフト
ウェアで制御を行なうローカルメモリを用いるということも広く検討されている．
ローカルメモリではアプリやソフトウェアが必要としたデータのみをオンチップ
メモリに載せるため，不要なデータを保持する危険性はキャッシュと比較して非常
に低い．しかし，同時に明示的にしない限り有効に機能しないという特性も持つ．
こうした利害得失を総括し，管理をするということが必要になる．例えば，GPU
ではスレッド実行開始時に共有メモリの初期化を行わないというシステムデザイン
をしているため，共有メモリに対してデータをコピーする必要を排除している．
1.5 次記憶: ハードウェアトレンドとしては演算性能に対する主記憶の容量は低下す
る傾向にある．しかしながら，大きなメモリ空間を利用するアプリケーションもあ
りそうしたアプリにも対応する必要がある．
現在，その方法として NAND フラッシュなどの不揮発メモリを用いて実現される
1.5 次記憶を用いるアプローチが検討されている．1.5 次記憶は HDD によって実現さ
れる 2 次記憶（スワップ領域）と比較して高速にアクセスできるという特性を持つ．
現在の計算機では SSD を用いた実装が一般的だが，メモリ空間にマッピングするな
どの高速化が可能で研究開発が望まれる．
3.2.2 システムソフトウェアによる改善
3.1 節でも一部述べたが，アクセラレータとホストが I/O バスで接続されているシステム
や 1.5 次記憶などを有するシステムを想定する場合，効率のよい新しいページングシス
テムをシステムソフトウェアが提供することにより，メモリ階層を隠ぺいすることが可
能である．デマンドページングシステムを実現するためには，TLB のようなアドレス変
換機構がアクセラレータ側で提供される必要があるなど，アーキテクチャとの協調設計
が必須となる．
3.2.3 プログラミングモデル
このように複雑化するメモリアーキテクチャに対応するためにどのようなプログラミン
グモデルを設計するかも大きな課題である．現状においては，アプリケーションプログ
ラマは分散メモリやヘテロジニアスアーキテクチャに対応するために，MPI や CUDA な
どを用いてメモリデバイス間のメモリの配置を意識したプログラミングを行わなければ
ならず，大きな負担を強いられている．今後，HPC システムのさらなる大規模分散化に
加え，ノード内のアーキテクチャにおいてもキャッシュアーキテクチャの複雑化，
NVRAM，メモリの一部電力の能動的な停止などの技術を採用する必要がある．これら
性能と省電力化のためにプログラマに対して低レベル操作を強いるのではなくプログラ
ミング言語処理系により適切な抽象 API を提供すべきである．
PGAS 言語のようにデータ配置や通信をプログラマに意識させつつ，それらの表現を
抽象化することで記述を簡便にしようとする研究はすでに進んでいるが，既存のアプリ
ケーションからの移行コストの問題，MPI や CUDA を直接用いたプログラムと比較して
必ずしも満足する性能が得られるとは限らないという問題もあり，広く用いられるには
至っていない．従って，ノード内におけるアーキテクチャの複雑化に対応した言語機能
の提案，開発も進め，それをサポートするための OS およびランタイムの機能拡張も必
要である．
26
3.2.4 参考文献
[3.2-1] JEDEC Committee JC-42.3 JESD79-3D, 2009
[3.2-2] Peter Kogge, et. al., "ExaScale Computing Study: Technology Challenges in Achieving
Exascale Systems," DARPA ITPO, Sep. 2008.
[3.2-3] Micron Technologies, Inc. DDR3 SDRAM system-power calculator, revision 0.1, 2007
[3.2-4] J. Thomas Pawlowski, "Hybrid Memory Cube: Breakthrough DRAM Performance with a
Fundamentally Re-Architected DRAM Subsystem" Hot-Chips 23 (2011)
[3.2-5] M. Motoyoshi, et al., ”A study for 0.18um high-density MRAM.”, 2004 VLSI
Symposium, 22 (2004).
[3.2-6] M. Hosomi et al., “A Novel Nonvolatile Memory with Spin Torque Transfer
Magnetization Switching: Spin-RAM,” IEDM, pp. 459-462, 2005.
[3.2-7] H. Horii et al. A novel cell technology using N-doped GeSbTe lms for phase change
RAM. In Symposium on VLSI Technology, 2003.
[3.2-8] S. Kang et al. A 0.1um 1.8V 256Mb 66MHz synchronous burst PRAM. In International
Solid-State Circuits Conference, 2006.
[3.2-9] Benjamin C. Lee, et al. Architecting phase change memory as a scalable dram alternative,
ISCA 2009
[3.2-10] Guangyu Sun, A Novel Architecture of the 3D Stacked MRAM L2 Cache for CMPs,
HPCA 2009
3.3 大規模並列性
近年では消費電力の限界を背景に，プロセッサのクロック周波数の伸びが鈍化しており，
ILP の活用も限界に達しつつある．1 コアあたりのデータ並列性は 4～32FLOP の範囲で
留まると予想されることから，エクサスケール級の計算機システムでは 107～109 ものコ
アが必要となる．この実現には，ノードあたりのコア数，あるいはノード数を増やすこ
とが必要であり，各ノードのコア数は O(103)～O(104)のオーダに，ノード数も O(104)～
O(105)のオーダになることが予想される．特に，このような大規模な超並列システムで
は，例えば，最悪の場合 109 コア対 109 コアというような大規模なノード間での通信が必
要となることや，ノード内コア数の増加によるノード性能に対する相対的な通信性能比
の低下や，ノード内の 1000 スレッドが共有資源にアクセスする可能性があるなど，多く
の課題が存在する．そのため，このようなシステムをどう構築するかは非常に重要な課
題である．また，このような超並列システムでのシステムソフトウェア・プログラミン
グ言語・数値計算ライブラリにおいては，その高い並列性を有効に活用できることが要
求される．
これまでに開発されてきた多くの並列計算機では，1 コア当たりのメモリ容量がほぼ
一定になるように，コア数が増えてきている．しかし，O(N)のデータに対して O(NlogN)
や(N2)の演算量を必要とするアルゴリズムでは，Weak Scaling の場合に計算時間の増大が
無視できなくなってきているのが現状である．つまり，同一時間内に計算できるデータ
量の増加は緩やかにならざるを得なくなることから，今後は Weak Scaling よりも Strong
Scaling で計算する機会が増えると考えられる．Strong Scaling を実現するためには，シス
テムの特徴としてバンド幅向上のためのメモリシステム・ネットワークの階層化が進む
とも予想され，相対的なレイテンシ増大による速度向上の阻害への対処も重要であると
考えられる．
本節では大規模並列に向けて重要な項目について以下に議論する．なお，これ以降，
想定するエクサスケールシステムは、ノード数 1 万～10 万(O(104)～O(105))，コア数 10
億(O(109))規模で実現されると想定する．
27
3.3.1 通信時間の削減
Strong Scaling においては，Weak Scaling の場合に比べてノード間通信におけるメッセー
ジサイズが小さくなることにより，レイテンシの影響が顕在化する．報告書[3.3-1]によ
るとノードバンド幅は 100GB/s 以上，レイテンシは緩やかに減少する姿が述べられてい
る．その結果，全実行時間に占める通信時間の割合が増大し，高い速度向上率を得るこ
とが困難になる可能性がある．
そのため，レイテンシの影響が大きい集合通信の使用を極力避けるようなアルゴリズ
ム再構成や，演算量を増やしてでも通信時間が減るようなアルゴリズムの開発も重要で
ある．特に，これまでは通信時間の削減には，演算と通信をオーバーラップさせること
が有効であると言われてきた．しかし，演算と通信のオーバーラップを行うためにメッ
セージを分割する必要がある場合，1 回の通信あたりのメッセージサイズはさらに小さ
くなるため，Strong Scaling においては，演算と通信のオーバーラップが通信時間の削減
に対して有効でないこともあり得る．したがって，通信時間を削減するためには，仮に
通信量が増えたとしても 1 回の通信あたりのメッセージサイズができるだけ大きくなる
ようにアルゴリズム自体を見直す必要がある．また，インターコネクトは小さいサイズ
のメッセージの遅延最小化，高いメッセージスループット（100 万メッセージ/s レンジ）
が重要となることが報告書で述べられている[3.3-1]．さらに，ネットワークインターフ
ェースにおけるメッセージパッシングセマンティクスのオフロード，Independent
Progress, 通信種別に応じた処理構成，将来を見越したネットワークインターフェース
の高度化の視点が挙げられている[3.3-1]
また，ノード数の増加に対応するためネットワークトポロジも Fat Tree などの多段結
合網から Torus のような直接網にすることが考えられるが，その場合は Torus に適した
通信アルゴリズムを使用するなどの工夫が必要になる．さらに high-radix スイッチを活
用した低遅延トポロジと高度なルーティング，QoS による資源の有効活用の検討，それ
らのトポロジに最適化した並列アルゴリズムの研究，オンチップとオフチップネットワ
ークの連携なども課題となる．
3.3.2 システムソフトウェアのスケーラビリティ
ノード数 O(104)～O(105)，コア数 O(109)と予想されるエクサスケールシステムでは，各
ノードまたは各コアで利用可能なメモリ量はこれまでと比べ少なくなる．このため，シ
ステムソフトウェアにおいては，単に O(105)あるいは O(109)の並列プロセス数規模の実
行環境の研究開発だけではなく，各ノードまたは各コアあたりのランタイムシステム，
OS がシステム全体のプロセスやスレッドを管理するために利用するメモリ量削減のため
の研究開発が必要となる．
並列プロセス数が増加することにより，計算ノード OS やランタイムシステムによる
ジッタが並列アプリケーション実行性能に大きく影響する．そのため，ジッタを削減す
るための計算ノード OS の研究開発が必要となる．アプリケーションの Strong Scaling 性
能を高めるためには，通信遅延を最小にすることが求められ，同期用ハードウェアを含
めたランタイムシステムなどの研究開発が必要となる．通信ライブラリとして MPI を提
供すべきなのかどうかは議論のあるところである．コレクティブ通信や MPI データタイ
プなど MPI 通信ライブラリ実現上の問題点を精査する必要がある．MPI 通信ライブラリ
のセマンティックスを維持したままではスケーラビリティに問題が生じるという結論が
出れば，アプリケーションの移植を考慮しながら新しい通信ライブラリを設計すること
が求められる．並列 I/O については，並列プロセス数が増加することにより，同時アク
28
セス数が増加する．また，並列プロセス全体での I/O バンド幅性能も向上させる必要が
ある．エクサスケール計算機においてこれらの問題に対処するため，ストレージアーキ
テクチャ，並列ファイルシステム，および I/O ミドルウェアの研究開発が必要となる．
システム管理における，リソーススケジューリング，モニタリング，ロギングについて
も，対象となるリソース数が増大することにより，線形に増大する処理量，記憶域サイ
ズを並列に処理するための研究開発が必要である．
各ノードまたは各コアあたりのメモリ削減を実現するために，ランタイムシステム，
OS においてノード数とともに増加するメモリ管理を極力排除することが必須となる．特
に，コレクティブ通信において，プロセス数を p としたとき，ノード当たりで O(p)ある
いは O(log p)のメモリ管理が必要となる実装については大幅な見直しが必要となる．
また，従来の大規模数値シミュレーションによる計算科学だけではなく，大規模な実
験データなどの解析によるデータインテンシブ科学をエクサスケール計算機でサポート
することも重要な課題である．プロセス数の増大，プロセスあたりのメモリ量削減とい
う状況で，データインテンシブ科学をサポートするためのプログラミングモデル，ラン
タイムシステム，そのためのストレージアーキテクチャ，並列ファイルシステム，I/O
ミドルウェアの研究開発が必要となる．
3.3.3 スケーラブルプログラミング
エクサスケールマシンにおいては，非常に多数のノード，ノード内の多数のコア 2，コ
ア内の SIMD 並列性，という階層的かつ膨大な並列性を有効活用する必要がある．また，
ノード内の並列性についても，消費電力を抑えるためにクロックを下げ，並列性によっ
てスループットを向上させるアクセラレータ（GPU やメニィコア）を有効に活用する必
要がある. さらに，ノード内のメモリも NUMA 構成となり，コア内，ソケット内，ソケ
ット間のメモリアクセスコストの違いを意識したプログラミングが必要になる．ノード
間通信もフルバイセクションネットワークは期待できず，ノード間の通信コストも非均
質になる.
比較的最近までは，ノード内のコア数も少なく，MPI を用いて 1 プロセスを 1 コアに
マッピングする，いわゆる FlatMPI モデルを用いれば並列性を uniform に記述しつつ，
SMP クラスタや MPP に対応させることが可能であった．これによりプログラムの可搬
性とある程度の性能可搬性を享受してきた．しかし，ノード内の並列度増加，アクセラ
レータの役割の増大，コアあたりのメモリの減少などにより，それは昨今すでに困難に
なっており，エクサスケールマシンにおいては不可能である．
(1) プログラミングの困難さへの対応
このような大規模かつ，階層的な並列性を持つマシン上で提供するプログラミングモデ
ルとして，一つには各レベル用に設計された最低限の抽象化を直接プログラマに露出し，
それら全てを陽にプログラミングさせるという，例えば MPI+OpenMP のようなアプロー
チが考えられる．しかし，均一かつ規則的な格子上の計算など一部の問題を除けば，あ
らゆるレベルでの並列化，およびその最適化を明示的かつ個別に行うのは今日において
もすでに困難であり，エクサスケールにおいてはますます困難が予想される．従って大
規模な並列処理をサポートするプログラミング言語やその処理系には，統一的な記述か
らあらゆる階層の並列性を抽出し，プラットフォームに適したマッピング・実行を行う
ことが求められる．
29
(1)
大規模並列用に設計されたアルゴリズムのサポート
また，エクサスケールへ向けて，アルゴリズムおよびアプリケーションも，大規模並列
化を見据えて変化・進化をすることにも注意が必要である．並列性の源が一階層のデー
タ並列性ではなく，アルゴリズム自身が階層的な並列性を持ち,通信量の少ない粗粒度の
並列性を抽出するように再設計されていくことが予想される（例: 櫻井-杉浦による部分
空間への分割による固有値計算[3.3-2]など）．また，アプリケーション自身も複数の並
列化されたプログラムを組み合わせて構成されるなど，階層的な並列処理を活用してい
くことが予想される．そのような階層的，かつ一部に粗粒度並列度を取り入れたアプリ
ケーションに対して，現在主流の SPMD 方式は，入れ子並列性，階層的な並列性を素直
に表現できないばかりでなく，複数の並列プログラムの部品化，複数の並列プログラム
の合成が行えない，粗粒度な処理に対してさえ動的負荷分散が行えないなどさまざまな
問題点がある．
3.3.4 数値計算ライブラリにおける高い並列性の確保
Strong Scaling においては，問題サイズを一定として計算時間を短縮させることになるこ
とから，Weak Scaling に比べて並列性が低くなることは避けられない．この場合，エク
サスケールマシンが持つ O(109)とも言われる高い並列性をどのようにして使い切ること
ができるかということが深刻な問題となる．エクサスケールマシンにおいては，複数の
階層で並列性が存在していると予想されることから，数値計算ライブラリの内部で用い
るアルゴリズムが階層的に並列性を利用できるように構築される必要がある．
また，データ分散方法は高い並列性を確保する上で重要である．これまでは三次元デ
ータにおいて，一次元方向のみでデータを分散する方法(slab decomposition)が広く用いら
れてきた．しかし，Strong Scaling においては，一次元方向のみの並列性よりも MPI プロ
セス数が多くなるケースがあるため，高い並列性で実行することができない．したがっ
て，二次元方向でデータを分散する方法(pencil decomposition)や三次元方向でデータを分
散する方向(cube decomposition)を用いる必要がある．また，データ分散方法の見直しは
もちろんであるが，アルゴリズム自体に含まれる並列性が高くなるような解法に切り替
えるなどの工夫が必要になる．
3.3.5 参考文献
[3.3-1] Report on Instutute for Advanced Architectures and Algorithms, Interconnection
Networks Workshop 2008
[3.3-2] T. Sakurai and H. Sugiura, A Projection Method for Generalized Eigenvalue Problems, J.
Comput. Appl. Math. Vol. 159, pp.119-128, 2003.
3.4 耐故障性
故障はハードウェア・ソフトウェアのいずれでも発生する．故障によりシステムは正常
でない状態に陥る．故障により直接起きた異常は連鎖的に他の異常を引き起こす．その
結果，仕様を満たす動作をしなくなることを障害という．故障が起きて異常な状態に陥
30
っても，異常の伝搬を阻止して故障の影響を限定し，仕様を満たす動作を継続できるこ
と，すなわち故障があっても障害を引き起こさない性質を耐故障性と呼ぶ．また，故障
はシステムにおいて継続して発生するため，耐故障のための処理は故障発生間隔(MTBF)
より短時間で完了可能なものでなければならない．
耐故障性を実現するには，以下の 3 つの点を検討しなければならない
1. どこでどのような故障が発生するのか．
2. システムのどの部分がどのようにして異常の伝搬を阻止するのか．
3. 耐故障のためのコストはどれだけか．また，複数の方式があるなら，その利害得失
は何か．
以下では，まず初めに上記 3 つの項目について議論し，エクサスケールシステムにお
ける課題をまとめる．
3.4.1 エクサスケールにおける故障
故障には様々な性質が存在し，以下のようなものがある．
1. ハードウェア・ソフトウェアあるいは，ファイルシステムなどの外部システムとい
った発生場所・要因
2. 永続的故障・一時的故障などの障害期間
3. 故障が計算環境のどこかで検知できるのか，あるいはできないのか
4. 故障によりシステムが停止してしまうのか動き続けるのか
エクサスケールのスーパーコンピュータは，ハードウェア/ソフトウェア共に増大・複
雑化していくと考えられる．これらにより，従来環境に比べ，特に 2 つの故障について
対応する必要がある．1 つは環境の大規模化による難検知故障 (Silent Error) ，中でも
ECC の対応能力を超えるデータ化けの増加である．難検知故障は従来の主な故障検出位
置であったシステムソフトウェアレベルでの検知が困難な故障であり，表面上は致命的
なエラーが起きていないようにアプリケーションが進行する場合もある．もう 1 つは，
検知はできるが発生場所・要因の特定が困難な複合故障である．これらは複数の故障が
同時に発生する，あるいは，故障要因が 1 つでも故障の伝搬が大規模で要因の分析や局
所化が困難なものである．このような故障は，原因不明のシステムの性能低下等で現れ
ることもある．
また，エクサスケールのスーパーコンピュータ全体の故障率は構成要素の増加につれ
て増大していく傾向にある．加えて，各要素自身の故障率も増加傾向にあり，例として，
ハードウェアにおいては，エクサスケールを実現する為の部品の高集積化や微細化，低
電力化などが，故障率の増加につながっている．こうした結果，エクサスケールの並列
性を持つアプリケーションの平均故障間隔(MTBF: Mean Time Before Failure)または平均
中断間隔(MTTI:Mean Time To Interrupt)は極めて短くなる．平均故障間隔が 35 から 39 分
になるとの試算もある[3.4-1]．一方で，過去の大規模 HPC システムの統計データ[3.4-2]
から計算すると，およそ 1 ソケット当たり年間 0.1 回程度の故障が発生することになる．
100 万ソケットのシステムを仮定すると，5 分程度の平均故障間隔になる．
このような環境において正常にアプリケーションを実行するためには耐故障技術が必
要不可欠である．
31
3.4.2 エクサスケールにおける耐故障技術
まず，以下に主な耐故障技術を論ずる．
·
·
·
·
·
·
ECC: データに冗長な情報を追加することで，ビット反転やビット消失が生じた際
に，それらを検出し，本来のデータを復帰させる．線形符号が広く用いられている．
パリティ付き行列積など，ライブラリレベルで実現する方式も提案されている．
ハートビート: 各要素に一定間隔で決まった処理をさせ，その処理が正常に実施さ
れていないことから故障を検出する．
異常状態検出: ハードウェア・システムソフトウェア・アプリケーションソフトウ
ェアが正常実行では到達し得ない異常状態に陥っていることを検出することで故障
が発見される．
冗長実行: 同一の処理を複数のハードウェアで処理させる．ジョブ複製(job
replication)とも呼ばれる．通信は複製して送られる．2 重に実行すれば 1 つの停止に
対応でき，3 重に実行すれば 1 つの異常出力の検出訂正ができる．
再実行: アプリケーションやジョブを最初からやり直す．外部入出力がある場合に，
実行不可能なことがある．
チェックポイント・リスタート: 正常時の状態を保存（チェックポイント）してお
き，故障発生時に保存した状態を復帰してリスタートする．メッセージログを含む．
並列アプリの場合は一貫性を保って保存する必要がある．
並列アプリケーションの構成プロセスの持つ冗長イメージの一貫性保証．並列アプリ
は複数のプロセスがイベントを送受信しながら実行される．一貫性は，冗長化される構
成プロセスが冗長化以前に受信した全てのイベントに対し，その送信者が，イベントを
送信したことを確認できるような状態で冗長化されていることにより保証される[3.4-3]．
手法としては大きく分けて，冗長化前に同期をとるものと，非同期に冗長化する手法が
存在し，非同期冗長化の際はイベントを考慮し一貫性のあるタイミングで冗長化を行う
ものと，作成した冗長イメージのうち，一貫性を持つものを選出する手法がある．また
これらの組み合わせも存在する．
·
·
·
·
故障予測: どこでどのような故障がどのような頻度で発生するかを評価する．耐故
障技術の最適化に役立てる．
故障解析: 故障により生ずる異常がどのように伝搬・連鎖するかを分析する．
インターフェース: 検出された故障や異常の情報を他の部分と共有するための仕組
み．これを実現するには，故障モデルと復旧モデルの定義，プロトコルの標準化，
効率のよい情報送受信の仕組みが必要である．
予防復旧: 通常時／故障時のログ等を用い，アプリが故障に至る挙動を解析．異常
の予兆に対して予防的な再起動などにより障害の発生を未然に予防する．
次に，耐故障技術の実装個所を論ずる．大きく分けてハードウェア階層とソフトウェ
ア階層があり，ソフトウェア階層ではシステムレベルとアプリケーションレベルがある．
ハードウェアでは ECC や冗長実行を利用した耐故障が主として提案され，実際に利用
されている．システムレベルでは各種故障検出，プロセス単位のチェックポイント・リ
スタート，マイグレーション，通信やプロセスの再実行などがある．ハードウェア・シ
ステムレベルでは，アプリケーションユーザに故障情報を隠蔽し，プログラムの変更な
しに耐故障機能を実現できるが， ECC を超えるデータ化けの検出は困難である．
アプリケーションレベルの実装では，アプリケーションプログラマが直接記述するも
ののほか，プログラミング言語が自動・（指示行などにより）半自動に実装するもの，
タスク並列・master-worker・map-reduce などのフレームワークで実装するもの，行列計
算などのライブラリで実装するものがある．耐故障性を有しないアプリケーションレベ
32
ルで耐故障性を実現するためにはプログラミングコストが高く，バイナリ配布のソフト
ウェアもあることから，システムレベルの耐故障性も必要である．
このように，耐故障性は単独の階層では達成されない．すべての構成要素が耐故障性
を有し，多重にまた相補的に障害発生を防止する枠組みを fault resilience という．
3.4.3 エクサスケールにおける耐故障性のコスト
次に，主な耐故障技術についてそのオーバーヘッドやコストを論ずる．エクサスケール
計算機では，要素数の増大に伴い MTBF が短くなる．加えて，要素間同期などの基本コ
ストの増大が懸念されており，それを利用する耐故障方式のオーバーヘッド増加が予想
される．
ECC では，冗長にデータを記憶する必要があり，メモリ・ネットワークの実効的な利
用効率を低下させる．エラー率と耐故障に必要な冗長性との関係は通信路符号化定理で
明らかにされている．しかし現状では，通信路符号化定理の限界に漸近する LDPC 符号
やターボ符号よりも，低レイテンシへの要求から符号化・復号化の容易な代数符号であ
る CRC などが広く用いられている．
チェックポイント・リスタートでは，チェックポイントを保存する時間と記憶容量が
大きなオーバーヘッドである．しかしトータルなメモリ容量の増加に二次記憶のバンド
幅が追い付いておらず，全メモリを退避するには MTBF を上回る時間がかかる可能性も
指摘されている．このためアプリケーションの知識を利用して，状態を再現できる最小
限のチェックポイントサイズにする工夫が必要である．リカバリ時に，代替ノードの割
り付け方による効率的ネットワーク利用の崩れや，アプリケーションが利用するデータ
からの隔離化が発生する．
冗長実行・再実行においては，プロセッサ，メモリ，ネットワークのすべてを多重に
利用する．リソースの実効的利用効率とともに，消費電力・エネルギー効率という観点
でもコストを評価する必要がある．
ソフトウェア，とりわけアプリケーションレベルの耐故障性実装においては，プログ
ラミングコストが大きな問題となる．
3.4.4 エクサスケールにおける耐故障性の課題
最後に，以上の分析に基づき，エクサスケール計算機における耐故障性実現のための研
究課題について論ずる．
(1) 故障と対処モデルの解析
·
·
故障分析・故障モデル・故障予測: エクサスケール計算機がどのようなハードウェ
ア・ソフトウェア要素から構成され，それぞれどのような故障を起こしうるのかを
分析・特定すること．異常の連鎖から故障ポイントを割り出してゆく仕組みと，そ
れを活用した故障モデルの構築，故障予測の精度向上．連続的故障を構成する単体
故障の相関解析，複数の復旧モデル・予防モデルの比較解析．
エクサスケール計算機における全体的な耐故障性実現への戦略: アプリケーション
からエクサシステムに求められる耐故障性に関する要求要件の特定．どの方式をど
のように組み合わせて，必要とされる耐故障性を実現するか，という戦略．新規開
33
発が必要であれば，誰がどう分担してそれを実現するかを計画．プロトコル統一や
標準化が必要であれば，どのように進めるのかを計画
(1)
·
·
·
(2)
·
(3)
·
Fault Resilience
Fault resilience のためのフレームワーク: 発生した故障やアプリケーションを構成
する各レイヤの情報を互いに通知し合うための仕組み，効率のよい情報送受信の仕
組み，レイヤ間で故障に関連する情報を交換するプロトコルの標準化．要素間連携
による故障範囲の限定，連鎖／横断故障の解析・対応の分担，耐故障性のためのコ
ストの削減．複数要素で実装された耐故障性機能の重複削減，相補的運用，階層的
故障対応，連係動作，ならびにこれらの戦略の記述方式と実現の支援．Fault
Resilience フレームワーク上で実際にアプリケーションレベル耐故障機能をモデル
化・実装すること．
Resilience を実現するシステムソフトウェア: 各種の異常検知機構の実装．異常要
素の局所化，部分的な措置による回復．信頼性の高い並列耐故障ミドルウェア，故
障に対応できるシステムミドルウェアの開発．システムソフトウェア自身の故障対
応と，故障を加味した管理の双方を考える必要がある．
アプリケーションレベル耐故障性実装支援: アプリケーションプログラマがメモリ
利用法やデータの更新タイミングなどを指示（アドバイス）するだけで，効率の良
い耐故障機能を容易に実装できる言語機能．アプリケーションの自動並列化ディレ
クティブや並列化ライブラリの利用を耐故障機能のアドバイスとして利用．耐故障
性を備えたライブラリ，フレームワーク，言語等．データの逸脱チェック，故障復
旧機能を有したアルゴリズムの研究開発，アプリケーションの知識を利用したチェ
ックポイントサイズの最小化などの実装の支援
ハードウェア・システムソフトウェアレベル耐故障
耐故障機能を提供する効率的なシステムソフトウェア: 故障頻度やノード・I/O 負
荷などの環境情報による耐故障機能の自動最適化，コンパイラの解析による自動耐
故障付与，ローカルディスクや不揮発性メモリを利用した高速化．故障プロセッサ
を避けてのリスタート時におけるプロセス・ランク配置の最適化．冗長性の最適化，
余剰ノードの冗長実行へ活用，電力を含めたシステム全体での定量的な評価．
新ハードウェアに対応した耐故障性技術
新ハードウェアの耐故障および，
新ハードウェアによる高性能な耐故障機能: アクセ
ラレータにおけるチェックポインティングや，不揮発メモリを利用した耐故障性の
効率化．新ハードウェア自身の耐故障性．
3.4.5 参考文献
[3.4-1] Peter Kogge, et. al., "ExaScale Computing Study: Technology Challenges in Achieving
Exascale Systems," DARPA ITPO, Sep. 2008.
[3.4-2] B. Schroeder, G.A. Gibson, “A large-scale study of failures in high-performance
computing systems,” Intl. Conf. on Dependable Systems and Networks (DSN 2006), 2006.
[3.4-3] E. N. Elnozahy, L. Alvisi, Y. M. Wang, and D. B. Johnson, "A survey of rollbackrecovery protocols in message-passing systems", In ACM Computing Surveys,
34(3):375-408, September 2002
34
3.5 低消費電力
消費電力は，大規模スーパーコンピュータの開発において最も重要な制約条件の 1 つで
ある．2011 年 12 月現在で世界 No1 の性能を誇る京コンピュータでは 10MW 程度の電力
を消費することで 10 ペタフロップス級の実効性能を達成している．これに対し， 2018
年の稼働を目指すエクサスケール・スーパーコンピュータでは，20～30MW で現在の京
コンピュータの 100 倍近い性能が要求される．大きな課題は「如何にして消費電力当り
の性能を劇的に向上するか？」にあり，この課題の解決無くしてエクサスケール・スー
パーコンピュータの実現はあり得ない．この目標を達成するためには，半導体微細化技
術に頼るだけの従来のアプローチでは全く不十分であり，新しい革新的技術を積極的に
取り入れた新たな挑戦が必要となる．
まず，各種ハードウェア部品それぞれの更なる低消費電力化に関しては，継続的な最
小加工寸法の縮小に加え，極低電圧回路技術の確立や，3 次元積層メモリといった新デ
バイスの活用が重要である．次に，エクサスケール・スーパーコンピュータにおいては，
数十万オーダの計算ノードで構成される巨大システム全体を見渡し，その上で適切な性
能／消費電力トレードオフを決定できなければならない．これを実現するためには，部
品レベルでの改善に留まらず，アプリケーション特性を踏まえたシステムレベル電力制
御技術の確立が急務の課題となる．そこで本節では，特に分野横断型の研究開発が必要
不可欠であるシステムレベル電力制御技術に着目し，特にエクサに向けて重要な項目に
ついて議論する．
また，スーパーコンピュータの平常運転時には，ピーク消費電力の半分程度の電力消
費であることが報告されている．これは電源系や空調系の設備投資を最大限利用するこ
とができていない問題がある．そこで，スーパーコンピュータのピーク消費電力が電源
系や空調系の限界を超えるように設置( over provisioning) して，ソフトウェア・ハードウ
ェアの制御により，設備的限界の範囲内に消費電力・温度をおさえる(power cap)ことが
考えられる．ここでは，機能や性能を高めるべき要素を空間的に選択し，それらに時間
的に集中して多くの消費電力バジェットを割当て，電力性能比を最適化する必要がある．
このとき，設備的限界を超えないように制御する多重の安全機構が必要である．また，
電力性能比の最適化のためには，モデリングや予測が必要である．なお，多数のアプリ
ケーションが同時に走る大規模システムで，公平性と電力効率を両立させるスケジュー
リング指針には議論が必要である．
本節では，以降，省電力の実現の基礎となるハードウェアの省電力技術について述べ，
次にソフトウェア電力制御のためのアーキテクチャ機構について論ずる．さらに，これ
らを用いたソフトウェアによる省電力技術の方向性を論ずる．
3.5.1 ハードウェアの省電力技術
プロセッサの消費電力は電源電圧の 2 乗に比例する．130nm プロセスまでのプロセッサ
は，デナードのスケーリング則に従ってプロセス世代毎に電源電圧を 0.7 倍に下げるこ
とにより，トランジスタ数倍増と周波数向上分の消費電力増を打ち消してきた．しかし，
低いスレッショルド電圧がリーク電流を増大させるため，90nm プロセス以降のプロセッ
サでは電源電圧が 1.0V 近辺で下げ止まっている．このためプロセッサの動作周波数向上
は止まり，さらに微細化で増えたトランジスタを有効活用するための省電力技術が開発
されてきた．以下に既存の省電力技術を示す．
·
微細化に伴う消費電力削減: トランジスタあたりの負荷容量は，楽観的にはプロセ
ス 1 世代毎に 0.7 倍に減少する．よって，2010 年の 45nm プロセスから 4 世代後にあ
35
·
·
·
たる 2018 年の 11nm プロセスでは，同じプロセッサを微細化するだけで，電力あた
り性能が 0.7-4=4 倍に向上する．一方，プロセス 4 世代で単位面積当たりのトランジ
スタ数は 16 倍になるので，同面積のプロセッサの消費電力はプロセス 4 世代で 4 倍
に増える．
パワーゲーティング: パワーゲーティングはプロセッサコア，キャッシュメモリと
いった大きな論理ブロック単位でパワースイッチを挿入し，電源供給を遮断する．
しかし電源供給が遮断されると論理ブロック内の状態は失われるため，状態の退避
／復元が必要になる場合がある．また，パワースイッチのオン／オフ自体にもマイ
クロ秒オーダの時間がかかり，ミリ秒オーダの長期間に渡って回路が使用されない
という情報が必要になる．このためファームウェア，OS，ミドルウェア，アプリケ
ーション等のソフトウェアとの連携が重要となる．
DVFS (Dynamic Voltage and Frequency Scaling): DVFS は動作周波数と電源電圧を
下げることにより消費電力を削減する技術である．動作周波数は電源電圧に比例し，
消費電力は（電源電圧）2×（動作周波数）に比例するため，動作周波数を下げる際
に電源電圧も下げることにより，動作周波数の 3 乗に比例する消費電力削減が実現
できる．動作周波数はチップ内の PLL で制御する一方，電源電圧はチップ外の電源
レギュレータで制御する．このため電源電圧制御は時間，空間とも粒度が大きい．
電圧レギュレータのオンチップ化による DVFS 制御粒度の細分化が研究されており，
Intel の Single Chip Cloud (SCC)ではチップを 6 つの領域に分け，独立に電圧を制御し
ている．DVFS は省電力効果が大きいが，ミリ秒オーダの長期間に渡って周波数を下
げても良いというハードウェアからは知ることが出来ない情報が必要になる．DVFS
の有効活用のためには，ファームウェア，OS，ミドルウェア，アプリケーション等
のソフトウェアとの連携が重要となる．
クロックゲーティング: クロックゲーティングは状態を変える必要のないトランジ
スタへのクロック供給を遮断し，動的な消費電力を削減する技術である．クロック
ゲートの挿入は自動化されており，RTL レベルの条件文により容易に利用できるた
め，クロックゲーティングは一般的に普及している．クロックゲーティングの導入
により動的な消費電力が 2～3 割程度削減されることが，経験的に知られている．ク
ロックゲーティング技術はハードウェア設計で完結しており，ソフトウェアからは
透過的に行われているように見える．
厳しい消費電力制約を満たしつつエクサフロップス級の高い性能を実現するためには，
さらなる微細化を推し進めると共に，今まで以上の低消費電力化が必要不可欠となる．
現在研究開発が進められている新しい省電力デバイスを以下に示す．
·
·
3 次元構造トランジスタ（Fin FET，トライゲート・トランジスタ）: 3 次元トライ
ゲート・トランジスタではチャネル領域を立体構造とし，チャネルを囲うようにゲ
ートを形成する．これにより，トランジスタを小型化しスイッチング速度を改善で
きるだけでなく，サブスレッショルド・リークの削減や低電圧動作による動的消費
電力の削減が可能となる．
不揮発メモリ（MRAM，PRAM など）: 現在一般的な SRAM では各メモリセルに
おけるリーク消費電力，DRAM ではリフレッシュ動作に伴う消費電力が必要である．
これに対し，MRAM や PRAM は，1)電源グランド間に流れる電流値が小さくなる構
造となっておりリーク消費電力が極めて小さい（たとえば SRAM の 1/5 程度），2)
不揮発性であるため電源供給を間欠的に停止する事ができる，といった利点がある．
また，一般的には高い実装密度を有するため，3)同一チップ面積制約下において
SRAM や DRAM より大容量化できる．これにより，キャッシュメモリとして使用す
る場合にはヒット率向上に伴うオフチップアクセス消費電力の削減や，主記憶とし
て使用する場合には必要チップ数の削減（とそれに伴う総消費電力の削減）を期待
できる．ただし，書込み回数の制限や，書込みレイテンシと書込み消費エネルギー
が大きいといった課題もある．
36
·
·
3 次元積層デバイス: 複数のダイを 3 次元方向に積層し，これらの間を貫通ビア
(TSV：Through Silicon Via)で接続するのが 3 次元積層デバイスである．これにより，
1)2 次元実装のグローバル配線を TSV で置き換えることによる低レンテンシ化と低
消費電力化，2)たとえばプロセッサと DRAM のように複数チップ・サブシステムの
1 チップ化（とそれに伴うプロセッサ－DRAM 間通信の低消費電力化），3)微細化に
頼らないメモリの大容量化，を期待できる．特に，MICRON 社の Hybrid Memory
Cube(HMC)は 4 つの DRAM ダイと 1 つのロジックダイを積層した 512MB のプロト
タイプで，従来の DRAM モジュールと比較して性能ならびに消費エネルギーの改善
効果を確認している．また，モバイル機器向け次々世代 DRAM 規格として JEDEC
が定めている Wide I/O も注目すべきデバイスであり，Samsung 社は試作チップ開発
を報告している．
シリコンフォトニクス: データ転送に要する消費電力の増大に対する一つの解決策
として，現在は化合物半導体で形成されている光デバイスを，シリコンで実現する
シリコンフォトニクスの実用化が期待できる．光通信の特性を活用することで通信
性能を飛躍的に向上させると共に，通信に要する低消費電力の削減を達成できる可
能性がある．例えば，IBM の SNIPER プロジェクトでは CMOS とナノフォトニクス
を融合したチップ設計環境を構築している．特に，チップ間／ノード間通信でのシ
リコンフォトニクスの応用は近い将来に実現される可能性が高い．一方，チップ内
光通信技術に関しては未だ発展途上にあり，チップ量産も考慮した場合にはその実
用化にはまだまだ時間がかかると思われる．
3.5.2 ソフトウェア電力制御のためのアーキテクチャ機構
一定の消費電力量でアプリケーション性能を最大化するには，プロセッサ，メモリ，イ
ンターコネクト等それぞれにおいて動作周波数，チャネル数，電源電圧や閾値電圧等を
最適なバランスに調整する必要がある．どのハードウェア要素の性能が重要であるかは
アプリケーションに依存するため，アプリケーション単位で消費電力特性を設定するた
めの「Power knob」が必要である．同一アプリケーションの中でも最適な消費電力特性
は変化するため，Power knob はアプリケーションプログラムから制御可能であることが
望ましい．このため，消費電力特性を変更する各種パラメータがハードウェア実装に依
存する，消費電力特性の変更制御には遅延時間がある，システム側で最大消費電力量を
超えないように保護する必要があるなどの問題を解決する必要がある．異種システム間
で可搬性のある Power knob の抽象的定義の研究や，システムが消費電力量を管理するた
めに必要な精度を空間方向にも時間方向にも備えたオンライン消費電力モニタリング・
ハードウェアの研究などが必要になる．
3.5.3 ソフトウェアによる省電力技術
最後に，ソフトウェア技術による省電力設計の課題について，システムソフトウェア，
コンパイラ，アプリケーションの各レイヤについて論ずる．
·
システムソフトウェアレイヤ: (1) 省電力化のためのスケーラブルな情報収集・制
御．数百万ノード級の電力情報をハードウェアからリアルタイムに取得し，また多
数の Power knob を制御する処理を，スケーラブルに行う基盤を提供する．(2) 大域省
電力スケジューリング．Power knob による電力抑制とアプリケーション性能最大化
のバランスを，多数ジョブ間の公平性・プライオリティを考慮しつつ対応する．さ
37
·
·
らに冷却効率向上のため，物理的ノード位置等を考慮したスケジューリングについ
ても研究する．(3) 階層 I/O システムソフトウェアによる省電力化．現在のシステム
ではノード間で共有された大容量ストレージとノード局所ストレージという階層を，
ユーザの責任において使い分けている．この階層（二階層に限らない）を，効率的
かつユーザ透過的に利用可能とする I/O システムソフトウェアの開発により，データ
移動に関する消費電力を低減する．
プログラミングレイヤ: システムソフトウェアあるいはアーキテクチャと連携する
ためのプログラミングインターフェースの整備．各レイヤで責任をどのように持つ
べきかの整備．フェーズの切り替わりを早めに伝えるためのコンパイル時の解析を
含めた技術．電力制約下で最大性能を得るために生じる各コアや各ノードの性能ば
らつきの拡大への対策．不揮発メモリ等の効率的利用のためのプログラミング／コ
ンパイル技術．電力制約下で最大性能を得るために，設定変更がどのような効果を
持つのか予測するためのモデル．全体の電力制約が一定でも各部の電力制約は動的
に変化することがあり，動的に適応して，性能が最大となる計算方法（利用コア数
などを含む）を自動的に選択するようなアプリケーション開発を可能とするプログ
ラミング／コンパイル技術．
アプリケーションレイヤ: アプリケーションの問題をひとつ定めたときに，問題の
定式化（例：決定的手法 vs.モンテカルロ），連続系の離散化（例：FEM vs.
Spectral），アルゴリズムやデータ構造などの選択は複数考えられる．これらの選択
を省電力という視点でハードウェアの電力性能特性に適した選択を行い，またハー
ドウェアの power knob を適切に選択することにより，電力性能比を最適化する．
Power cap のための電力制御を実現するため，ソフトウェアの knob とハードウェア
の knob をあわせて性能および電力をモデリングし，制約条件を満たしつつ効率を最
大化する動的制御の実現．履歴依存性が生じる温度制約条件に対し，時間的変動も
含めてモデリングと制御を行う手法の開発．また，システムソフトウェアやコンパ
イラにおける電力制御機構との連携協調のための機構および制御・最適化アルゴリ
ズム．
3.6 大規模データ処理
3.6.1 概要・前提
今後の計算科学アプリケーションに於いてはストレージが非常に重要な要素となること
が予測される．これは，主記憶，二次記憶の大容量化に伴い，アプリケーションの初期
入力として必要となるデータや中間データのサイズが飛躍的に増大していることや，将
来のスーパーコンピュータでは計算ノードやストレージが莫大な数のコンポーネントか
ら構成されるため耐故障のためにアプリケーションの定期的なチェックポイントがこれ
まで以上に必要となること等が要因として挙げられる．それだけではなく，今日のスー
パーコンピュータ上の主流アプリケーションであるシミュレーションを軸とした高性能
計算だけでなく，実験器や観測器から生成された大量のデータに対して解析や可視化な
どの処理を行う大規模データ処理などの新しいアプリケーションの実行も重要になるこ
とが想定される．
典型的な大規模データ処理アプリケーションは従来のアプリケーションと比較して
主に以下の違いがある．
·
シミュレーションではプログラムは単体でプログラム中のカーネルが処理の中心で
あるのに対し，典型的な大規模データ処理では複数のプログラムを連結して処理を
行う．
38
·
シミュレーションでは頻繁に通信処理が行われるのに対し，大規模データ処理では
粗くストリーム的に行われる．
従って，シミュレーションの場合はレイテンシに敏感であるのに対し，大規模データ
処理ではスループット重視でレイテンシに鈍感であることが多い．ここでは，上述のよ
うな特性の異なる高性能計算アプリケーションに対して，今後のスーパーコンピュータ
上で高性能な I/O を実現するための技術的課題について述べる．
3.6.2 課題
(1) 大規模データ処理向けアーキテクチャ
ストレージ階層を形成するメモリデバイスとディスクデバイスの性能差は大きく，その
差は広がり続けている．現在と同様にディスクデバイスをベースとしてエクサスケール
システムのストレージシステムを構成する場合，I/O 性能を達成するために膨大な数の
ディスクデバイスを搭載する必要があり，電力消費や設置スペース，コストの側面から
実現が困難となることが考えられる．一方で，近年，Solid State Drive(SSD)や StorageClass Memory(SCM)などの不揮発性デバイスが登場していることもあり，これらの不揮
発のメモリデバイスを記憶素子として使用する新たな記憶デバイスをストレージ階層に
持ち込みことが有望と考えられる．しかしながら，依然としてその消費電力改善に対す
る効果や耐故障性に対する詳細な検討はされているとは言えない．特に，ウェアレベリ
ングなどの研究開発がされてはいるものの新記憶デバイスでは記憶素子の書き込み回数
では従来のデバイスと比較して劣っており，大規模並列処理ワークロードの特性に応じ
た信頼性の改善が必要である．
また，エクサスケールシステム上では，データ転送，特にオンチップとオフチップ
間のデータ転送がアプリケーションの実行性能だけでなく，システム全体の電力消費の
大幅な増加を招きうる．しかし，従来の Lustre や GPFS などの並列ファイルシステムの
ような集中的なストレージアーキテクチャでは必然的に大量のデータ転送が計算ノー
ド・ストレージシステム間で発生するため，性能および消費電力上のボトルネックにな
るため，よりデータアクセスの局所性を考慮した最適化が可能なストレージアーキテク
チャが課題である．このため，計算ノードのローカルストレージを集約して利用するよ
うな分散型のストレージアーキテクチャによりスケールアウトするシステムの検討が必
要である．
(1)
大規模データ処理向けソフトウェア
エクサスケールシステムでは，10 億並列級のプロセス・スレッドからの I/O が発生しう
ると目されている．しかし，現在のファイルシステムは，このような膨大な数や量の
I/O 数を処理することは困難である．また，これまでの POSIX 準拠の I/O API や MPI-IO
のような I/O インターフェースだけでは，アプリケーションで扱いやすいデータレイア
ウトや I/O パターンを記述できないため最大限に I/O 性能を達成できない．このため，
アプリケーションが発行する膨大な数や量の I/O を最適化し，ファイルシステムとの性
質の差異を吸収することで，ファイルシステムの性能を最大限に発揮できるようなミド
ルウェアの開発が今後の課題である．
また，大規模データ処理アプリケーションにおいて高い効率を実現するためにはそ
のような大規模データ処理向けミドルウェアと共にプログラミングモデルの開発も課題
である．特に局所性が性能および電力上重要であることから，局所性を考慮した大規模
データ処理アプリケーションの開発を支援することが重要である．
39
3.7 生産性
3.7.1 はじめに
エクサスケールシステムにおけるソフトウェア開発の高生産性とは，エクサスケールシ
ステムにおけるソフトウェア開発工数をペタスケールシステムにおけるソフトウェア開
発工数と同等程度に少なく保つことと定義する．
エクサスケールシステムの並列数はペタスケールシステムより増加し，CPU とアクセ
ラレータを併用するヘテロジニアスな構成になると見込まれることから，開発工数は増
加すると予想される．したがって，ペタスケールシステムにおける開発工数と同等に保
つことすら挑戦的な課題である．
一般にソフトウェアの開発工数評価は難しいが，工数削減を達成すると思われる自明
な要求に対する課題を本節では検討する．以下にその課題を挙げる．
·
·
·
·
システムソフトウェアの課題: システムソフトウェアがアプリケーションソフトウ
ェアの開発工数に与える影響について，システムソフトウェア性能の観点から課題
を述べる．
デバックおよび性能プロファイルの課題: プログラム開発時のデバックが容易であ
ること．また，性能に関するプロファイルができること．これにより，エクサスケ
ールを達成するアプリケーションソフトウェア開発の工数削減に寄与する．
プログラミング方法論の課題: 既存のプログラミング方法を用いたアプリケーショ
ンソフトウェア開発に対し，開発工数が削減できるプログラミングの枠組みの課題．
自動並列化コンパイラや数値計算ミドルウェアの利用が相当する．
性能チューニングの課題: エクサスケールを達成するアプリケーションソフトウェ
ア開発時に，性能チューニングに関する工数が削減できること．そのためには数値
計算ライブラリの利用，自動性能チューニング技術の導入が相当する．
3.7.2 システムソフトウェアの課題
エクサスケールシステムにおいてはメニーコアプロセッサやアクセラレータの使用は不
可避と考えられる．メニーコアプロセッサの各コアやアクセラレータは，汎用サーバに
用いられるプロセッサよりも機能面で劣ることが予想され，それに伴いオペレーティン
グシステムがアプリケーションに提供できる機能も限定されることが予想される．
ハードウェアが提供する機能に合わせた新たなアプリケーションプログラミングイン
ターフェース(API)を提供すれば，システムソフトウェアのオーバーヘッドは最小化でき
実行性能は最大化されるが，アプリケーションは新たな API を習得した上での書き直し
が必要となり生産性は低下する．逆に生産性を重視して，汎用 OS との互換性の高い
API を提供しようとすると，ソフトウェアエミュレーション等が必要となり実行速度が
犠牲になる可能性が高い．
通信 API，ファイル I/O の API，プロセス・スレッド管理，メモリ階層管理などのあら
ゆる分野においてこのトレードオフを検討し，実行性能と生産性のバランスが取れたイ
ンターフェースを定義することがシステムソフトウェア分野における課題である．
40
3.7.3 デバッグおよび性能プロファイルの問題
効率的なデバッグおよび性能プロファイルを行うことにより，高い実効性能を持つアプ
リケーションを少ない工数で開発できることが期待できる．しかしながら，通常の並列
環境に対応したデバッグおよび性能プロファイルを行うツールは存在するが，エクサス
ケールシステムは大規模かつ複雑なシステムであるため，そのままでは適用することは
できない．
以下に，エクサスケールシステムにおけるデバッグおよび性能プロファイルの課題を
示す．
(1) 大規模環境への適用
デバッグや性能プロファイルを行うためには，アプリケーションの各イベントのログを
保存する必要があるが，一般に並列度に応じて保存されるログのデータサイズは大きく
なる．そのため，エクサスケールシステムでは，データ記憶容量，IO バンド幅が不足す
る．さらに，仮に保存できたとしても，その膨大なデータログを解析する人的コストも
並列度に応じて大きくなるという問題点がある．
現状では，ユーザがログを取得するプログラムの範囲を限定するなどの工夫を行うこと
により，特定のアプリケーションに対して 1PetaFlops 程度のシステムでログの取得を行
っている事例がある[3.7-1]．しかしながら，より大規模なエクサスケールシステム上で
動作する様々なアプリケーションに対応するためには，より洗練された新しい手法を開
発する必要がある．また，新規ロギング手法の検討と並行してそもそもイベントログに
頼らないデバッグ手法についても検討をするべきである．
(2) 複雑なアーキテクチャへの対応
エクサスケールシステムで高い実効性能を得るためには，エクサスケールシステムを構
成する複数の演算処理装置や多層構造を持つメモリなど，すべてのアーキテクチャを有
効に用いる必要がある．そのためには，各アーキテクチャのプロファイル情報を統一化
した形式でプログラマに提示することで，効率的な性能プロファイルを行うことができ
ると考えられる．しかしながら，現在そのようなツールは一般的ではない．
3.7.4 プログラミング方法論の課題
(1) プログラミング言語・モデルの観点から
エクサスケールシステムは非常に多くのノードで構成され，かつノード内においても，
異なる種類の演算処理装置，深いメモリ階層，といった複雑なアーキテクチャで構成さ
れる可能性がある．また，ノード間の通信コストも非均質になる可能性が高い．エクサ
スケールシステムの性能を最大限に発揮するためには，すべてのアーキテクチャを考慮
してアプリケーションを開発する必要があるため，生産性の大幅な低下が予測されてい
る．そのため，プログラミング言語およびそのモデルにより，アーキテクチャの適切な
抽象化などを行うことで，生産性の低下を防ぐことが期待されている．
以下に，エクサスケールシステムにおけるプログラミング言語およびそのモデルの課
題について述べる．
41
ヘテロジニアスアーキテクチャへの対応
エクサスケールシステムは，汎用プロセッサと演算に特化したアクセラレータといった
異なる性質の演算処理装置が搭載されている．汎用プロセッサとアクセラレータの両方
を有効に利用するには，各演算処理装置およびアプリケーションの性質を考慮した上で，
問題を適切に分割する必要があるため，そのプログラミングコストの大きさが課題とな
る．現在は，プログラマが手動で問題の分割を行っている場合がほとんどであるため，
適切な問題分割の自動化や支援が望まれている．
大規模並列性
エクサスケールシステムは大規模かつ複雑な並列性を持つため，その潜在性能を十分に
発揮できるアプリケーションを作成することは非常に難しい．この問題点を解決するた
めの，生産性と高性能性を両立するエクサスケールシステムに対応した新しい言語モデ
ルの作成が期待されている．
複雑なメモリアーキテクチャへの対応
アプリケーションが高い実効性能を発揮するためには，システムに搭載されるメモリを
適切に利用する必要がある．しかし，エクサスケールシステムでは，ノード間のデータ
通信に加え，ノード内においても深い階層構造を持つメモリ間のデータ転送コストを意
識する必要があり，そのプログラミングコストの大きさが問題となる．現在，特にノー
ド内の階層構造を意識させるような言語モデルは一般的ではない．
性能可搬性・移植性
開発するアプリケーションは，エクサスケールシステムのみで動作させるのではないた
め，システム間のマイグレーションパスを考慮する必要がある．しかしながら，エクサ
スケールシステムを構成する演算処理装置，メモリアーキテクチャ，ネットワークトポ
ロジなどはシステムによって異なり，かつそれらに対するプログラムの最適化手法も異
なるため，性能可搬性および移植性が課題となる．現在は，システムを熟知したプログ
ラマが手動で性能チューニングを行っているため，その作業を少ない工数で行えるよう
な新しい研究が期待されている．
既存アプリケーション資産の継続性
上に関連するが今後開発するアプリケーションに限らずこれまでに開発された膨大なア
プリケーション資産について今後のアーキテクチャによる性能向上を実現することが重
要であり，そのためにはアプリケーションプログラムの変更が必要になる場合があり得
る．これは特に数万，数十万行におよぶ既存の大規模アプリケーションではその変更箇
所が多岐に渡る可能性があり，大きな工数となり得るため，その工数を最小化するため
の研究開発が必要である．
(2)
数値計算ミドルウェアの観点から
数値計算ミドルウェア（以下，数値計算 MW と記載する）はアプリケーションプログラ
ムの開発効率，信頼性の向上や移植性の確保などを目的とし，入出力，代数演算，数値
ライブラリへのインターフェース，自動並列化などの機能を網羅したソフトウェアであ
る．エクサスケールシステムで予想される並列数の増加やヘテロジニアス化に起因する
プログラミングに伴う問題点を，数値計算 MW を用いることでアプリケーションから切
り離すことができれば，開発工程の普遍化および工数削減を実現できる[3.7-2]．数値計
算ライブラリは，数値計算 MW を特定機能・目的に特化したものと捉えることができる．
そのため，アプリケーションとの整合性や分散並列処理など数値計算 MW によって解決
される問題もあるが，継続的な保守や性能に関しては同様の問題を内包している．ここ
では，それ以外の数値計算 MW における問題点ついて以下に述べる．
42
対象の範囲
物理，現象，離散化手法などの違いにより，アプリケーションの利用するデータ構造，
アルゴリズム，並列化手法は異なってくる．汎用性を高めるためには対象範囲を広くと
る必要があるが，有用性（使いやすさ，効率など）の観点からは対象範囲は絞られるべ
きである．現在，離散化手法，計算対象などを限定した数値計算 MW は散見することが
できる[3.7-3]が，両者を兼ね備えたものは存在しない．
新しいアーキテクチャへの対応
アプリケーションの寿命は数十年の単位に及ぶが，この間にハードウェアの性能，構成
は著しく変化する．高性能計算を行うために必要な最適化（チューニング）にはデータ
構造が密接に関連するが，データ構造は数値計算 MW の基礎であり，その変更はシステ
ム全体の再構築に等しい作業となるため難しい．したがって，機能の抽象化が重要にな
る．
既存アプリケーションへの対応
すでに開発されている多くのアプリケーションをエクサスケールシステムに対応させる
ことが数値計算 MW の重要な役割の一つである．しかし，既存アプリケーションを数値
計算 MW 上に移植する作業は新規開発に比べて作業量が多く，数値計算 MW の保守期
間の不透明性などから，開発者に対する心理的障壁も大きい．
3.7.5 性能チューニングの課題
アプリケーションの性能チューニングを支援するためには数値計算ライブラリや自動チ
ューニングなどのソフトウェア技術の開発が必要である．本節では両技術についての性
能チューニングに関する課題を述べる．
(1) 数値計算ライブラリの観点から
数値計算ライブラリは，高度にチューニングされたプログラム群を簡便な形式によりア
プリケーションプログラムで活用することができるため，高性能計算プログラムの実現
やプログラムの可搬性・移植性の向上の点で多くの計算科学，シミュレーションプログ
ラムの生産性の向上に寄与してきた．特に，エクサスケールシステムで高い実効性能を
実現する為には，多様化・複雑化している計算環境への対応や，最新の数値解法技術や
並列化アルゴリズムの導入が不可欠である．これらを一般のアプリケーションプログラ
マが習得し，プログラムとして実現する工数は莫大であり，現実的に不可能である．数
値計算ライブラリを利用することで，現実的な工数で通常のプログラミング手法では容
易に達成できないプログラム性能を実現することができる．
以下に，数値計算ライブラリに関する課題について述べる．
性能
エクサスケールシステムで高い性能を有する数値計算ライブラリの実現は挑戦的課題で
あり，以下に挙げるような個別の課題がある．
·
·
·
·
·
プロセス通信性能を考慮したライブラリの実現
高精度演算・精度保証演算への対応
ヘテロな計算環境での高い実効性能
電力最適化/低電力実行のサポート
耐故障性の考慮
43
これらの課題の内，高精度演算・精度保証演算については既存研究があり，これらを
実装することで対応が可能と考えられるが，ヘテロな計算環境への対応や通信性能を考
慮したライブラリ等はアルゴリズムの変更や方式自体の提案を伴う可能性が高く，現在
の技術の延長で対応ができないと考えられる．
分散並列処理
既存の数値計算ライブラリでは，分散メモリ型の並列計算環境に十分対応している関数
／ルーチンの数が少ない．これは，各アプリケーションとの親和性を保つデータ構造に
関する設計が困難な点や高い演算性能の実現が容易でないことによると考えられる．分
散並列環境での高性能なライブラリの実現はエクサスケールシステムに不可欠であり，
数値計算ライブラリもしくはフレームワークによる対応が課題となる．
数値ライブラリにより本課題を解決する場合，いくつかの関数については既存技術の
実装により対応が可能であると考えられるが，およそ数千以上程度のプロセス並列です
ら十分な性能を得るためには新規アルゴリズムや新しい実装手法が必要であり，その開
発が急務となっている．
継続的な保守・サポート
数値計算ライブラリ等の計算科学向けソフトウェアの開発は計算機やソフトウェアベン
ダが行う場合と研究プロジェクトによる場合の二通りがある．後者は最新の解法技術や
チューニング技術を取り入れられている点で特に計算科学で重要度は高いが，プロジェ
クト終了後の保守やサポートが十分に行われるかが不明であることが多いため，それが
アプリケーションへの導入の妨げとなっている．数値計算ライブラリ等の計算科学向け
ソフトウェアの継続的な保守の実現は重要な課題といってよい．
(2)
数値計算のための自動チューニングの観点から
エクサスケールシステムでは，ペタスケールシステムと比較して並列数は増加し，さら
にそのアーキテクチャはヘテロジニアス化すると予想されているため，性能チューニン
グに対する工数増加が避けられないと予想されている．また複雑化された近年のアーキ
テクチャでは，すべてのソフトウェア開発者が高効率実装をすることは極めて困難であ
り，さらに並列実行数によって最適アルゴリズムや実装方式が異なる場合もあることか
ら，手動による選択も困難になりつつある．
これらの問題を解決するため，アーキテクチャや問題サイズ等のアプリケーション固
有の事項に自動適応し，数値アルゴリズムや実装方式選択の自動化を行う自動チューニ
ング（Auto-tuning，以降 AT と記載）技術[3.7-5]が研究されている．AT 技術を適用する
ことにより，全体の開発工数を減らしつつエクサスケールを達成できるソフトウェアが
構築可能となると考えられる．
以下に生産性の観点からの AT 技術課題を述べる．
低コストの AT 適用
任意のソフトウェアに容易に AT 機能が付加できることは開発工数削減に寄与する．逐
次最適化や自動並列化を問わず，コンパイラと AT 技術の連携が幅広い分野のソフトウ
ェアへの AT 技術適用に必要である．既存技術としては，任意のプログラムに適用でき
る AT 言語[3.7-6]やランタイムライブラリ[3.7-7]が開発されている．これらがもつ機能の
適用や拡張をすることで問題を解決できる．一方，より汎用性を高めるため，AT 機能
の規格化，および AT 機能の自動付加ツールの開発が必要であるが，これらは現在実現
されていない．
44
AT 品質保証
付加された AT 機能について，ソフトウェア開発者の意図したように正しく，かつ，意
図した品質（AT の効果）が得られるかを評価・判断・保証すること（AT 品質保証）は
重要である．
既存技術としては，得られるチューニング結果に対する最適化方針を，どのようにソ
フトウェア開発者が AT 機能に与えるかという記述方式である「数値計算ポリシ」が AT
機能として実現[3.7-8]されている．
一方，AT 品質保証の実現のための原理，フレームワーク，ツールの開発は，現在実
現されていない．
3.7.6 参考文献
[3.7-1] Markus Geimer, Felix Wolf, Brian J. N. Wylie, Erika Ábrahám, Daniel Becker, Bernd
Mohr: The Scalasca performance toolset architecture. Concurrency and Computation:
Practice and Experience, Vol.22, No.6, pp.702-719 (2010)
[3.7-2] S. Gallopoulos, E. Houstis, and J. Rice: Computer as Thinker/Doer: Problem-Solving
Environments for Computational Science, IEEE Computational Science and Engineering
(1994)
[3.7-3] M. S. Friedrichs, P. Eastman, V. Vaidyanathan, M. Houston, S. LeGrand, A. L. Beberg, D.
L. Ensign, C. M. Bruns, V. S. Pande: Accelerating Molecular Dynamic Simulation on
Graphics Processing Units,J. Comp. Chem., Vol.30, No.6, pp.864-872 (2009)
[3.7-4] http://www.openfoam.org/
[3.7-5] 片桐孝洋ほか：特集「科学技術計算におけるソフトウェア自動チューニング」，
情報処理学会会誌「情報処理」，Vol.50，No.6 (2009)
[3.7-6] Katagiri, T., Kise, K., Honda, H., Yuba, T.: ABCLibScript: A Directive to Support
Specification of An Auto-tuning Facility for Numerical Software, Parallel Computing,
Vol.32, Issue 1, pp.92-112 (2006)
[3.7-7] Hollingsworth, J.K., Keleher, P.: Prediction and Adaptation in Active Harmony, IEEE
International Symposium on High Performance Distributed Computing (HPDC) (1998)
[3.7-8] 櫻井隆雄，直野健，片桐孝洋，中島研吾，黒田久泰：OpenATLib:数値計算ライ
ブラリ向け自動チューニングインターフェース，情報処理学会論文誌. コンピュ
ーティングシステム Vol.3, No.2, pp.39-47 (2010)
3.8 周辺技術課題
3.8.1 外部資源連携
外部資源連携とは，エクサスケール HPC システムと他のシステムを相互連携した計算機
環境を活用し，科学技術計算の実行支援を行う，エクサスケール HPC システムを中心と
した分散コンピューティング環境の構築を意味する．ここで言う他のシステムとは，他
の HPC システム，クラウドデータセンター，データアーカイブ，センサーネットワーク
等である．分散コンピューティング分野には長年の研究開発の実績があるが，近年〜
2020 年にかけて利用されるネットワーク基盤，計算機基盤，ストレージ基盤を活用する
ための研究開発が必要である．
45
ネットワーク
現行の学術ネットワーク SINET4 において，主要情報基盤センターに 10Gbps（最大で
40Gbps まで拡張可能）の通信回線が張り巡らされていること，また，日米間でも
20Gbps で接続されているように，今後 WAN の広帯域化はますます進むことが予想され
る．その一方で遅延の変化は少ないため，Long Fat Pipe (LFP)を考慮した通信が重要にな
る．マルチストリーム転送や，UDT[3.8-1]で採用されている TCP/IP の再送制御によらな
い転送手法等 LFP 環境でも高効率を達成できる転送手法が必要である．また，エクサス
ケール HPC システムと外部資源を連携させるためには，通常ならば外部から隔離された
ネットワークに配備されている計算ノードやストレージデバイスを，一時的，部分的に
外部資源からセキュアチャネルによりアクセス可能にする必要がある．このためにはネ
ットワークが柔軟にプログラマブルである必要があり，OpenFlow[3.8-2]に代表される
Software-Defined-Network (SDN)技術の活用が期待される．複数サイト間のネットワーク
帯域・各種資源の動的確保も重要であり，従来より OSCARS[3.8-3]や AutoBAHN[3.8-4]，
OpenDRAC[3.8-5]， G-lambda[3.8-6]等研究開発されていたが，相互運用製が無く，今後
の開発が必要である．
外部ストレージとの連携
データの生成・蓄積拠点と，データ解析拠点（エクサスケール HPC システム）は往々に
して異なるため，2 者間でのデータ転送・共有が必須であり，そのためのインターフェ
ース，効率，利便性の観点で研究課題がある．特に近年では Amazon S3 に代表されるク
ラウドストレージの活用が進んでいるが，異種クラウドストレージ間での共通インター
フェースが無く，使い分けが困難で，ベンダーロックインに陥りやすい．広域でのデー
タ共有を透過的に行うために Gfarm[3.8-7]に代表される分散ファイルシステムが用いら
れる．分散ファイルシステムでは，データ複製を複数のストレージに分散して管理する
ことで，データへの到達性や転送性能の向上を実現しているが，複製配置アルゴリズム
やメタデータ管理の性能向上，耐故障性機能向上のための研究開発が必要である．
Globus Online[3.8-8]や RENKEI-PoP[3.8-9]では広域データ転送のサービス化を実現してお
り，簡易な広域データ転送が実現されるが，これら技術の普及が異種システム間連携に
は不可欠である．
外部計算資源との連携
エクサスケール HPC システムと外部計算資源を連携させるシナリオとしては次の２パタ
ーンある．エクサスケール HPC システムがメンテナンスで停止，あるいは多数のジョブ
によりスケジューリングシステムが混雑してジョブの makespan が増加し長時間実行され
ない場合に，外部計算資源を使う方法．もう 1 つは，エクサスケール HPC システムの有
休時間を有効活用するために，外部計算資源からエクサスケール HPC システムを使う方
法である．これらを実現するシステムとしてグリッドワークフローエンジンが研究開発
されてきたが，クラウドへの対応が必要である．前者のシナリオへの対応例として，文
献[3.8-10]では，一定条件を満たすジョブ（性能を求めない，ランタイム制約の少ない等）
を外部クラウド計算資源に実行させることで，全体のスケジューリング効率が向上する
ことを実証している．しかしながらこれを汎用的に実現するには，標準的なインターフ
ェースで，外部計算資源を動的かつ透過的に確保する技術が必要である．
外部資源とのネットワーク連携とストレージ連携が出来て初めて外部の計算資源との
連携技術は可能になるため，これの実現には上記２研究項目の実現が必要である．
46
3.8.2 参考文献
[3.8-1] “UDT: UDP-based data transfer for high-speed wide area networks”, Yunhong Gu and
Robert L. Grossman, Computer Networks, Volume 51, Issue 7, 2007.
[3.8-2] “OpenFlow: enabling innovation in campus networks”, Nick McKeown, Tom Anderson,
Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker and
Jonathan Turner, ACM SIGCOMM Computer Communication Review, Volume 38, Issue
2, April 2008.
[3.8-3] “Intra and Interdomain Circuit Provisioning Using the OSCARS Reservation System”,
Chin Guok, David Robertson, Mary Thompson, Jason Lee, Brian Tierney and William
Johnston, In Proceedings of BROADNETS'2006.
[3.8-4] “AutoBARHN”, http://www.geant.net/service/autobahn/pages/home.aspx.
[3.8-5] “OpenDRAC the Open Dynamic Resource Allocation Controller”,
https://www.opendrac.org/.
[3.8-6] “G-lambda: Coordination of a Grid scheduler and lambda path service over GMPLS”,
Atsuko Takefusa, Michiaki Hayashi, Naohide Nagatsu, Hidemoto Nakada, Tomohiro
Kudoh, Takahiro Miyamoto, Tomohiro Otani, Hideaki Tanaka, Masatoshi Suzuki,
Yasunori Sameshima, Wataru Imajuku, Masahiko Jinno, Yoshihiro Takagawa, Shuichi
Okamoto, Yoshio Tanaka and Satoshi Sekiguchi, Future Generation Computer Systems,
Volume 22, Issue 8.
[3.8-7] “Gfarm Grid File System”, Osamu Tatebe, Kohei Hiraga and Noriyuki Soda, New
Generation Computing Volume 28, Number 3, 2010.
[3.8-8] “Globus Online: Accelerating and Democratizing Science through Cloud-Based Services”,
Ian Foster, IEEE Internet Computing, Volume 15, Issue 3, 2011
[3.8-9] “Point-of-Presence 連携による e-サイエンス分散環境”, 滝澤真一朗, 松岡聡, 友石正
彦, 佐藤仁, 東田学, Internet Conference 2011, 2011.
[3.8-10] “Elastic Site: Using Clouds to Elastically Extend Site Resources”, Paul Marshall, Kate
Keahey and Tim Freeman, 10th IEEEACM International Conference on Cluster Cloud
and Grid Computing, 2010.
[3.8-11] “Improving Utilization of Infrastructure Clouds”, Paul Marshall, Kate Keahey and Tim
Freeman, 11th IEEE/ACM International Symposium on Cluster, Cloud and Grid
Computing, 2011.
47
4. 研究開発ロードマップ
3 章で提示した重点技術課題を解決するための研究開発ロードマップについてアーキテ
クチャ，システムソフトウェア，プログラミング，数値計算ライブラリの 4 つの項目か
ら議論する．2018 年頃ハードウェアおよび基本ソフトウェアが実現され，その後，他の
ソフトウェアの整備を進めていく計画である．以降の各節では個々の項目についてそれ
ぞれ課題を解決するロードマップを提示し，各項目について現在進行中の国内研究課題
において既に取り組まれている場合はその番号を付した（付録 1 進行中関連研究課題を
参照）．
4.1 アーキテクチャ
4.1.1 はじめに
3 章で述べた課題を克服し，エクサフロップス級の計算機システムを実現するのは簡単
ではない．本節ではエクサフロップス級の性能を持ち，重要サイエンス分野において高
い実効性能を得ることができる計算機システムをターゲットとし，その実現に向けて必
要な研究開発アプローチについて，アーキテクチャ・ハードウェアの側面から述べる．
まず，検討課題毎にエクサシステムを可能にする技術・研究開発アプローチを述べる．
そして，システムソフトウェアやアプリケーション開発の検討材料とするべく，技術の
応用により実現可能となるであろうエクサスケールシステムの構成例を提示する．最後
にアーキテクチャ・ハードウェアの研究開発ロードマップをまとめる．
4.1.2 エクサスケールを可能にする技術・研究アプローチ
(1) ヘテロジニアスアーキテクチャ
まず，3.1.2 節で述べたコア間結合方式に関する研究開発アプローチについて述べる．
·
レイテンシコアとの結合方式：レイテンシコアとの帯域を向上させ遅延を低下させ
るためには，レイテンシコアと同じダイ上または同一パッケージ内へのスループッ
トコアの実装，レイテンシコアのメモリシステムへの接続[4.1-1]，アクセラレータへ
のレイテンシコアの統合[4.1-2]などが必要であり，それぞれの効果やソフトウェアへ
の影響を現行機種やプロトタイプシステム，アーキテクチャシミュレータ等を用い
て評価，検証を行う必要がある．
48
·
スループットコア間結合方式：近年，CPU が介在することによるノード内アクセラ
レータチップ間のデータ転送オーバーヘッドは Mellanox 社 GPU Direct といった技術
によりホストマシンでの無駄なコピーが削減されたが本質的解決に至ってない．ア
クセラレータ間を PCI-Express を介さずに直接接続する等の方法により，異なるノー
ド間においてもさらに低レイテンシ・広帯域のデータ転送を実現する技術も必要で
ある[4.1-3]．また，チップ内のスループットコア間においては，データ共有や同期の
レイテンシを低減してコアの稼働率を向上させるために，浅いメモリ階層において
データ共有を可能とする明示的共有メモリシステム，スレッドの高速起動や低遅延
での同期を実現する機構などを開発する．
これらの技術項目について，各種アプリケーションの実効性能向上に対する有効性を
明らかにすると共に，現行機種や独自開発のアクセラレータによる実現可能性を評価・
検討するフィージビリティスタディが必要である．また，現在の GPU に見られる既存の
スループットコア[4.1-4]の延長線上での開発に加え，個々の対象計算問題における演算
処理およびデータ参照の特性を考慮し，さらに電力性能比を向上可能なアーキテクチャ
を探求していくことが求められる．このような方向性としては，例えば，パワーゲーテ
ィングや DVFS といった低消費電力回路技術のさらなる導入[4.1-5]，高精度・混合精度
の浮動小数点演算に対するハードウェア支援，様々なメモリ参照パターンに対しても性
能が大幅に低下しないような柔軟なメモリインターフェースサポート[4.1-1]，特性の異
なる様々なアプリケーションに対しても不要なデータ移動を抑えながら効率の良い計算
を実現するコンフィギャラブルメモリ階層システムおよびデータパスの導入[4.1-2]など
があげられる．これらを実現するためには，各アーキテクチャ要素の有効性評価をシミ
ュレータ等を用いて行い，必要に応じてシステムソフトウェアへの要件をフィージビリ
ティスタディの段階で明確にする必要がある．
ヘテロジニアスアーキテクチャの評価や選定を行うために，1）2016-18 年頃に利用可
能となるアクセラレータデバイスの性能見積もり，2）レイテンシコアとの結合方式やス
ループットコア間結合方式の評価・検証を含めたアクセラレータの独自開発に対するフ
ィージビリティスタディを 2013 年までに行い，2015 年頃までに 3）開発の第１ステージ
として複数のヘテロジニアスアーキテクチャ候補に対する実験機構築，をソフトウェア
スタック開発と並行して行うべきである．1）では，既存の製品をベースにした今後想定
される派生品や，開発が告知されている製品に対して，ピーク性能や電力性能比などの
性能見積もりやプログラミングモデルに関する長所・短所を明らかにする．これにより，
候補となる有望なアクセラレータを明らかにする．
2）では，アクセラレータを独自開発することを想定し，利用可能と予想されるデバイ
ス技術を基にアクセラレータアーキテクチャについて検討を行う．特に，1）で明らかと
するコモディティ製品ベースのアクセラレータ候補と性能および生産性を比較し，必要
に応じて，FPGA などによる試作実装を行う．3）では，候補となるアクセラレータを組
み合わせた小規模な実験機を構築し，特にソフトウェアスタックに対し実機による動作
検証およびデータ取得を行う．
(1)
メモリアーキテクチャ
大規模なスーパーコンピュータにおいて主記憶（メインメモリ）は演算を実際に行うプ
ロセッサコアと並び最も重要な要素の一つである．現代の多くのスーパーコンピュータ
は DRAM を主記憶として活用している．しかしながら，DRAM の性能向上の速度はプ
ロセッサの演算性能の向上と比較して鈍く，主記憶の性能がシステム全体の性能を律速
する「メモリウォール問題」が将来にかけてより深刻になると予想されている．
現代の計算機では，キャッシュメモリやローカルメモリを用いるメモリサブシステム
の階層化によってメモリウォール問題の性能への影響を軽減している．将来のエクサス
49
ケール・スーパーコンピュータでは，より深刻になるメモリウォール問題に対してより
積極的なメモリの階層化を実施する必要があると予想される．
·
·
·
メモリ帯域・レイテンシおよび電力効率を改善するメモリ階層：現在のメモリシス
テムにおいてもレジスタファイル，階層化キャッシュメモリ，ローカルメモリのよ
うにメモリ階層は既に採用しているが，演算性能に比するメモリ帯域は年々低下す
る傾向にある．この問題を緩和するためにメモリサブシステムのさらなる階層化が
進展すると予想される．
メモリ階層技術は，キャッシュメモリのように高速だが高コストなメモリデバイ
スと，DRAM のように低速であるが大容量が実現可能なメモリデバイスを，空間及
び時間的局所性に基づき効率的に使い分けるために発展してきた．キャッシュメモ
リ・ローカルメモリはハードウェア・ソフトウェアの制御の下でデータ参照局所性
を利用してデータ再利用性を高めることでレイテンシ短縮とバンド幅向上を向上さ
せる．メモリウォール問題のさらなる緩和のためにはメモリデバイスの進化に合わ
せたメモリ階層の設計やアプリケーションに内在する多種多様なデータ参照局所性
を効率よく利用できるメモリシステム設計が必要になると予想される．
例えば，On-chip に集積される SRAM や eDRAM といった高速なメモリは On-chip
Network を通じて演算器に対して供給されるため低レイテンシかつ低消費電力である
が，Off-chip へのアクセスはコストが高い．On-chip で処理が完結した場合のメモリ
アクセスは Off-chip の DRAM へのアクセスと比較して 10 倍から 1000 倍程度高性能
で高電力効率である．加えて主記憶のレイヤにおいてもノード内の NUMA 構成，イ
ンタリーブ，メモリ参照パターン（連続・ストライド・間接参照）などの違いによ
りレイテンシやバンド幅に変動があり，主記憶における局所性をどのように制御し
ていくかというのも重要な問題である．
データ参照局所性を最大限に利用し高性能かつ高電力効率のメモリアーキテクチ
ャを実現することはエクサスケール・スーパーコンピュータの実現において必要不
可欠である．しかしながら，安易なメモリ階層の複雑化はアプリケーションの最適
化を煩雑化し生産性を低下させる．生産性を維持して高性能計算を実現するために
階層化メモリにおけるメモリのマッピングやアロケーションやそのインターフェー
スをどのように提供していくかという問題をアプリケーションやプログラミングモ
デルと連携して解決していく必要がある．
超並列処理に対応するメモリシステムの構築：現代のメモリ階層は単一のコアの実
行を高速化することに注力してきたという背景があり[4.1-7]，GPU や MIC のような
メニーコアアーキテクチャを利用する際に用いられる多数の細粒度タスクが多数の
独立なメモリアクセスを行う場合に効率が落ちてしまうという問題点がある．こう
した問題を解決するには巨大なページベースの DRAM アーキテクチャへの変更[4.18]やキャッシュリプレースメント方式の変更[4.1-9]，トランザクションメモリ[4.110]や同期用メモリの活用といった技術が必要になる．
細粒度タスクから発生する多数のスレッドはハードウェアに並列度を提供するだ
けではなく，互いに独立に動作をすることでメモリのレイテンシを隠蔽することに
も寄与し，効率の良い演算を実現する．一方，DRAM デバイスは 10 前後のバンクを
切り替えながらメモリアクセスを実施する形態をとっており，現状の規模を大幅に
上回るスレッドからのアクセスに対応するには，スレッド間のリソース競合を回避
するメモリアクセススケジューリング技術[[4.1-11]]やメモリデバイスの
Gather/Scatter アクセスへの対応が有効であると考えられる[4.1-12]．
新しいメモリデバイスの活用：主記憶の性能・電力効率を改善するために新しいデ
バイスの研究が継続的に行われている．近年では，DRAM の実装に TSV を用いた 3
次元実装を用いることで性能や電力効率を高める Wide I/O や Hybrid Memory Cube
[4.1-13]といった新しいデバイスが発表されている． DRAM 代替を目指した技術では
PCRAM や MRAM といった不揮発性メモリの研究が行われている．
しかしながら，こうした新しいメモリデバイスには様々な制約が付くことが多い．
50
·
例えば，TSV を用いた 3 次元実装ではメモリ容量が実装上の都合から，既存の
DRAM と比較して少なくなる．PCRAM などの不揮発性素子は書き込み回数に上限
があるなどの制約が付く場合が多い．
耐故障性の向上：DRAM やキャッシュメモリといった部品は演算器などの他の部品
と比較して故障が多く ECC のように冗長な情報を付加することでソフトエラーなど
の軽度な障害からシステムを保護することが一般的である．
エクサスケール・スーパーコンピュータでは低下する部品の故障に対してより頑
強なシステムを構築する必要があり，ECC，Chipkill などに代表される符号化，CRC
などを用いたリトライ，1 ビットエラーなどのソフトエラーを早期発見しそれが複数
ビットエラーなどの致命的な障害に発展することを防ぐ Scrubbing などの工夫が必要
になる[4.1-14]．
本節で述べた研究アプローチはどれか一つを達成すればよい，といった特性のもので
はない．なぜならば，メモリサブシステムにかかわる各部品はお互いに干渉するという
特性を持つためである．また，2 章でも述べたようにメモリサブシステムへの性能要件
はアプリケーション毎に大きく異なる．そのため，どのようなメモリアクセスをサポー
トするべきかをトップダウンに決定した上で，メモリサブシステムの構成を決定する必
要がある．
2018 年に向けた取り組みとしては，2013 年頃を目処にアプリケーションを意識した上
でメモリ階層構造とデータ共有の方式を決定する必要がある．この際に 2018 年に採用予
定の技術に関してもまだ普及していない可能性があり，その技術が利用不可能な場合の
シナリオも考える必要がある．例えば DRAM の 3 次元実装等の技術を用いる場合には，
その技術が十分に安価に入手できない可能性は十分にあり，そうした場合のシナリオを
考える必要がある．次に，2014 年から 2015 年ごろを目処に開発のための細かいパラメ
ータを利用するテクノロジを決定した上で，システムソフトウェアへ提供する機能のイ
ンターフェースの決定を行う．この時点で，内部メモリのバンク数・ウェイ数・オンチ
ップネットワークの構成等の構成を決定し，以降の LSI の開発に備える必要がある．
(2)
大規模並列・ストロングスケーリング・ネットワーク
ストロングスケーリングにおいては，全実行時間に占める通信時間の増大が深刻な問題
となる．報告書[4.1-15]によるとノードバンド幅は 100GB/s 以上となる一方，レイテンシ
は緩やかに減少する姿が述べられている．End-to-end の通信遅延は，通信ライブラリな
どのコンピュータノード内，ネットワークインターフェース，インターコネクト内と 3
つの構成要素の遅延の和となる．アーキテクチャでは特に後者２つが遅延削減のための
重要なチャレンジとなる．
ネットワークインターフェース(NI)に関しては，オンチップ NI とオフチップ NI の統
合，軽量な通信プロトコル，高度な NIC 設計，オフローディングなどによる Collective
通信の高速化，細粒度同期支援，スケーラブルなコネクション管理，様々な通信用 NI の
集約化が重要であり，これらの機能・特性の実現に向けて，2013 年までにコモディティ
ベースの NI やプロトコルの技術動向調査と各要素技術の効果やコストも含めた妥当性に
関する評価・検証を行う必要がある．そして，エクサスケールシステムにおけるスケー
ラビリティ確保に必要な要素技術を洗い出し，2014～2015 年頃にはその要素技術開発を
行い，その後のエクサスケールシステム開発につなげる必要がる．
トポロジとルーティングに関しては，オンチップとオフチップトポロジのバランスを
考慮にいれた階層網による high-radix スイッチを活用した低遅延トポロジの検討や，QoS
と Congestion Control 機能，小メッセージ（3KB 以下など）の低遅延化，小メッセージ処
理の効率化（100 万メッセージ/s レンジ），パフォーマンスモニタリング・デバッキン
グ・診断機能などの実現が重要となる．そのために，2012 年～2013 年は，各要素技術の
51
検討およびトポロジとルータの要件を検討し，さらに電力測定，耐故障注入ツールなど
も含むシミュレータ・エミュレータの開発や性能予測手法を開発して評価環境を構築す
ことが求められる．その後，トポロジとルータの構成方式を決定して，要素技術を開発
してプロトタイプシステムへ搭載し，評価やソフトウェアの開発を行いつつ，最終的な
エクサスケールシステムを設計していく必要がある．
さらに，低遅延化のためにオンチップ，オフチップネットワークの構成要素をノード
毎に 1 つのチップ，あるいは１か所に集約化することも要素技術として検討すべきであ
る．特に，トポロジとしては４次元トーラスなどの Low-radix ネットワークと
Dragonfly[4.1-16]などの High-radix が候補となると考えられが，これらの中間の構成も可
能であり，それも検討するべきである．究極的には一部ノード間の通信帯域を最大，遅
延を抑えるサーキットスイッチ技術との部分的な併用などの検討により体感通信遅延を
削減，予測可能にするなどの並列アルゴリズムの大規模化支援も要素技術として考慮す
る価値があると考えられる．
(3)
低消費電力
これまでに我が国では，組込みシステム分野を主なターゲットとして，低消費電力化を
目的としたプロセッサ技術やメモリ技術，回路技術などの研究開発が世界的にも先行し
て行われてきた．また，スーパーコンピュータ応用においても，2.2 GFlops/W を達成す
る高性能かつ低消費電力なプロセッサの開発が行われている[4.1-17]．エクサスケール・
スーパーコンピュータを実現するためには，これまでに培われてきた低消費電力化に関
する要素技術を最大限活用し，その上で，更なる電力効率の改善を実現するための新技
術を導入する必要がある．また，幅広いアプリケーションにおいてエクサスケールコン
ピューティングを実現するためには，プロセッサ，メモリ，インターコネクトの電力効
率を大幅に改善するとともに，アプリケーションの特性に応じて性能／電力効率を最大
化するためのシステムレベル電力制御技術が重要になる．以下に研究開発分野を 4 つに
分けて，エクサスケールに向けて開発すべき技術の概要を説明する．
·
·
·
新しいデバイス技術の活用：半導体微細化技術，3 次元トライゲート構造[4.1-18]や
Silicon on thin BOX(SOTB)[4.1-19]，不揮発性メモリなどの新デバイス技術[4.1-20]，
極低電圧動作ロジック／メモリ[4.1-22]や 3 次元積層 LSI[4.1-24][4.1-25]といった回路
／実装技術などを巧みに利用し，電力効率の優れたプロセッサ，メモリ，インター
コネクトを実現するアーキテクチャの開発が重要となる．また，新しいデバイス／
回路／実装技術において生じる各種問題を解決するアーキテクチャ技術（例えば，
微細化に伴い生じる製造ばらつきの影響の緩和，極低電圧化による低速動作や信頼
性低下に対する対策，3 次元積層 LSI における温度制御，など）の開発も必要である．
2015 年からのシステム開発を想定した場合，2013 年までには利用すべき新デバイス
の選定と，それによる消費電力削減効果を明らかにする必要がある．その後，2014
年～2015 年にかけて周辺回路等を整備し，2015 年からのシステム・インテグレーシ
ョンに備える．
電力効率に優れたアクセラレーション技術の確立：極めて高い電力効率を達成する
ためには，GPU[4.1-2]やメニーコアプロセッサ[4.1-26][4.1-27]に代表される何らかの
スループットコアを利用することが必須であり，電力性能効率に優れるスループッ
トコアの構成方式や，そのためのプログラミングモデルやコンパイラといった関連
技術の開発も同時に進める必要がある．2013 年までにはソフトウェア生産性も踏ま
えた上で搭載すべきアクセラレータを選定し，2015 年までにはアクセラレータを活
用した超並列実行方式ならびにシステム構成を決定する必要がある．
メモリならびにインターコネクトの大幅な低消費電力化：厳しい消費電力制約下に
おいてエクサフロップス級の演算性能を実現するためには，消費電力バジェットの
多くを演算（つまり，マイクロプロセッサやアクセラレータ）に配分する必要があ
る．そのためには，メモリ（特に主記憶）ならびにインターコネクトの消費電力を
52
·
(4)
大幅に削減する必要がある．メモリに関しては，新デバイスの採用やきめ細かなメ
モリ動作モードの制御（スタンバイモードの積極活用など）などが考えられる．イ
ンターコネクトに関してはリンク幅，速度の動的スケーリング[4.1-28]，光通信技術
の導入[4.1-29]などが有望である．また，これら技術を導入した場合でも低消費電力
化が不十分な場合には（つまり，十分な消費電力バジェットを演算に分配できない
場合には），搭載すべき総メモリ容量の削減や通信性能の低下，局所性の高いネッ
トワークトポロジを検討する必要があり，その場合にはアプリケーションからミド
ルウェアを含めた横断的な議論を要する．2013 年までにはシステムバランスを考慮
して要求されるメモリ容量ならびに通信帯域を明らかにし，それに基づき必要とな
る消費電力バジェットを明確にすると共に，電力制約を満足するために必要となる
低消費電力化技術を検討する必要がある．そして，2015 年を目処に具体的な低消費
電力技術を確立し，その後のシステム開発へと繋げる．
システムレベルでの電力制御による性能／電力効率の大幅な改善：（ピーク消費電
力といった観点ではなく）アプリケーション実行における実効消費電力に着目し，
様々なアプリケーションの特性に応じて性能／電力効率を最大化するためのシステ
ムレベル電力制御技術の確立が重要となる．性能と消費電力のトレードオフを調整
可能な Power Knob（消費電力特性を変更するための各種パラメータ）を提供し，さ
らに適切な空間粒度（チップ内モジュール単位，コア単位，チップ単位，ボード単
位，ノード単位など）と時間粒度（システム起動単位，アプリケーション実行単位，
アプリケーション実行中も含むある周期時間単位，など）を決定しなければならな
い．また，電力制御ソフトウェアに対して，システム全体の詳細な電力消費状況を
観測可能にするため，各種センサや消費電力推定などに基づく正確かつ高速な消費
電力モニタリングの実現も重要となる．2013 年までには，エクサスケールアプリケ
ーションの特性分析に基づきシステムレベル電力制御方式を検討し，ハードウェア
ならびにソフトウェア間での電力制御を可能とすべく API を策定する必要がある．
その後，2017 年頃を目処に，システムレベルの電力制御技術の確立とその実装を行
う．
耐故障・信頼性
エクサスケールシステムでは，システムを構成する要素数が膨大になり，MTBF が短く
なる．そのため，長時間に及ぶアプリケーション実行を支援する技術を開発していく必
要がある．
·
·
チェックポイント・リスタートの高速化：チェックポイント・リスタートに関して
は，数万ノードからなるペタスケールのマシンでのチェックポイントにも数十分を
要するとの報告もあり[4.1-30]，数十万ノードから構成されるエクサスケールマシン
ではより多くの時間を要すると考えられる．一方，MTBF も数分〜数十分程度であ
るため，現在のチェックポイント技術の延長では実用にならない．従って，チェッ
クポイント時間およびリスタート時間を数秒程度まで改善する必要がある．エクサ
スケールシステムでは，10 分毎に 2PB/s のチェックポイントデータを格納する必要
があるともされている[4.1-31]．そのため，まずは 2013 年頃までに技術トレンドの調
査と，不揮発メモリの導入などのチェックポイント時間削減の候補となる技術をコ
ストや消費電力を勘案しつつ検討する必要がある．
冗長実行の支援機構，消費電力：クリティカルな演算については複数ノードで同時
に演算を実行することでチェックポイント・リスタートを避けることができる．こ
れまでメッセージ通信レベルでの研究は行われてきているが，メッセージ通信以外
のプログラミングモデルに関しては，複数ノードを用いた冗長実行のためには，ジ
ョブのディスパッチや結果のコミットなどを支援する機構の検討を 2013 年頃までに
行うことが必要である．一方で冗長実行は，本質的に演算には不必要な電力を使用
53
することにつながるため，システム全体の電力バジェットとのバランスも定量的に
評価しつつ検討をする必要がある．
· プロセスマイグレーションの支援機構：故障を予測できれば，チェックポイント・
リスタートの代わりに事前にプロセスを他ノードにマイグレーションすることがで
きる．また，故障が発生した際に，ネットワークトポロジに応じた最適な通信経路
を維持するために他ノードにプロセスマイグレーションを行った方が良い場合もあ
る．そこで，高速なプロセスマイグレーションを支援するためのハードウェア機構
を要素技術として 2013 年頃までに検討すべきである．それに加えて，故障検知や予
測を助ける精度の高いモニタリング機構も検討する必要がある．
各項目について有望な技術を選択し，2014～2015 年に要素技術開発を行い，実験システ
ムを構築して効果の検証とソフトウェアの開発を進めることが重要である．その後，エ
クサスケールシステムへ適用させるためのシステム開発を進めていく必要がある．
(5)
ストレージアーキテクチャ
エクサスケールシステム上では，データ転送，特に，オンチップとオフシップ間のデー
タ転送がアプリケーションの実行性能だけでなく，システム全体の消費電力の増加に大
幅に寄与することが問題となる．また，ストレージを構成するコンポーネント数が多く
なるので必然的にシステム全体の故障率も高くなる．従来の Lustre や GPFS などの並列
ファイルシステムのような集中的なストレージアーキテクチャでは，性能，データ転送
に伴う消費電力，信頼性の点で問題となる．このため，計算ノードのローカルストレー
ジを集約して利用するような分散型のストレージアーキテクチャによりスケールアウト
するシステムの検討も必要である．特に，既存のファイルシステムでは I/O スループッ
ト性能に特化したものが多い一方で，アプリケーションの超並列化に伴い，I/O スルー
プット性能だけでなく，IOPS 性能が必要とされる．また，耐故障についても RAID など
の冗長性を実現する手法だけでなく，ファイルの複製作成なども検討が必要である．
4.1.3 エクサスケールシステム構成例
現在の性能向上速度（約 2 倍/年）を維持すると，2018 年ごろには 1Exa Flops を達成する
システムが登場すると予想される．しかしながら，2 章で議論したように各種コンポー
ネントの性能向上だけでは，現在の京のような形のスーパーコンピュータは 200PFlops
～400PFlops の性能に留まると予想されている．この制約は主に消費電力に起因しており，
本白書では電力の問題を克服する為の要素技術の議論を行ってきた．
本節では前述の種々の技術を応用し，適切にそれらを組み合わせることで実現可能と
なると予想されるエクサスケールシステムの構成例を提示する．なお，これはあくまで
技術的なチャレンジをクリアした際に描ける構成の一例であり，将来の開発するべきア
ーキテクチャの詳細を定めるものではないことに注意されたい．
本節では，図 4.1-1 のようにシステムを「プロセッサ構成（コア・キャッシュの構
成）」，「ノード構成（プロセッサとメモリの接続）」，システム構成（ノード間イン
ターコネクト）の 3 階層に分け，各階層それぞれで構成例を示す．なお，各階層の構成
は独立に組み合わせ可能であり，全体としてはその組み合わせ通り数だけのシステム構
成が考えられる．
54
図 4.1-1 システム構成
(1) プロセッサ構成
コアの構成とオンチップネットワーク
ここではプロセッサチップ中の主要コンポーネントであるコアとオンチップネットワー
クに関して述べる．コアは明示的な並列性がないプログラムを高速に実行することを指
向したレイテンシコアと明示的な並列化の上でデータや制御の並列性を扱うスループッ
トコアに分けて説明を行う．
·
レイテンシコア：並列性の乏しいアプリケーションの性能を最大化することを目的
として構成された，L1・L2 キャッシュを持つ大規模なコアをレイテンシコアと呼ぶ．
Xeon，Opteron，ARM（Cortex-A シリーズ），POWER，および，SPARC64 などは，
このタイプに分類できる．
レイテンシコアは狭いデータ並列性（SIMD 幅が 4～8）で高い命令レベル並列性
（4~8 命令の同時実行）の活用を目指している．コアは少ないハードウェアスレッド
をサポートし，分岐予測・プリフェッチ・階層化メモリ・レジスタリネーミングを
利用してアウトオブオーダーに命令の実行を行う．また，シングルスレッド性能を
高めるために高い周波数(2.0 ~ 4.0 GHz)で動作する（図 4.1-2）．4GHz で SIMD 幅が
8 の場合にはコアの演算性能は 64GFLOPS となる．並列化されていないアプリケー
ションを高効率で実行する構成であるため，現代のコンパイラでの最適化の大部分
が適用可能である．
レイテンシコアの設計では動作周波数を高めるために動作電圧を高め，容量が大
きくスイッチング速度の速いトランジスタを多く活用する．こうしたトランジスタ
は消費電力が大きくなるため，レイテンシコアは後述のスループットコアと比較し
て性能あたりの消費電力が大きくなる傾向にある．
図 4.1-2 レイテンシコアの構成
·
スループットコア：スループットコアはデータ並列性・スレッド並列性をもつプロ
グラムを高速に動作させることを目的として構成された，独自の L1 と共有のローカ
55
ルメモリを持つ複数の小規模なコアをスループットコアと呼ぶ．MIC，GPU，Cell，
その他の各種アクセラレータがこのタイプに分類できる．
スループットコアは高いデータ並列性（SIMD 幅が 4 以上）を効率化するためのプ
レディケーションに基づく分岐除去や，スレッド並列性を活用したストールの隠蔽
を行う．さらに多数のスレッドを効率よくスケジューリングするためにスレッド間
同期のサポートなどを行う．動作周波数はレイテンシコアと比較して低く 1.0 ～ 2.0
GHz で動作する．SIMD 幅が 16 (16FMA)で動作周波数が 1GHz の場合にはコアあた
り 32GFLOPS の性能になる．レイテンシコアと異なり動作周波数が低いため，低電
圧・低容量の低速だが低消費電力なトランジスタを活用できる．このような背景か
ら性能あたりの消費電力がレイテンシコアと比較して小さくなる傾向にある．
さらに，スループットコアは上述した並列化手法を適用した場合にのみ高速化が
実現されるため，ソフトウェアでの並列化の支援が必要である．並列化手法に関し
ては｢課題・ヘテロジニアスアーキテクチャ｣で詳細を述べている．
図 4.1-3 スループットコアの構成
·
コアの通信・接続方式：本白書では上記の 2 種類のコアをチップ上に複数集積する
ことで高性能なプロセッサを構築することを想定している．複数のコアを集積する
際には，そのコア間はオンチップネットワークを介して接続される．コアやキャッ
シュメモリはオンチップネットワーク上に配置され，データはスイッチを通じて授
受される．オンチップネットワーク上には概ね 100MB 程度のキャッシュメモリと
100 前後のプロセッサコアが集積される．
ネットワークはメッシュ，リング，クロスバー・ファットツリーなどのトポロジ
を構成する．全コアが同時にオンチップメモリにランダムにアクセスを出す場合に
は，その性能はオンチップネットワークのバイセクション帯域で決定される．
56
図 4.1-4 オンチップネットワーク
プロセッサチップ構成
上記で紹介したレイテンシコア・スループットコアを用いて，プロセッサチップを構成
した場合の性能に関して述べる．レイテンシコア・スループットコアの一方だけを利用
するホモジニアスな構成，各種コアを単一チップに集積するヘテロジニアス構成のアプ
ローチが存在する．プロセッサチップは 100W～200W の電力を消費することを前提と
しているが，コア数を増減することでより小さな電力のプロセッサチップを構築するこ
とも可能である．
·
·
·
(2)
レイテンシコア構成：チップ内にレイテンシコアを敷き詰める場合には 32 個～64 個
搭載できる．LLC (Last Level Cache)は全てのコアから共有される．チップあたりのピ
ーク性能は 2.0TFLOPS～4.0TFLOPS であり，このチップを用いてエクサスケールシ
ステムを構築した場合の電力あたりの性能は 10GFLOPS/W～20GFLOPS/W になる．
スループットコア構成：チップ内にスループットコアを敷き詰める場合には 256 個
～512 個搭載できる．チップあたりのピーク性能は 10TFLOPS～20TFLOPS の性能で
あり，このチップを用いてエクサスケールシステムを構築した場合の電力あたりの
性能は 50GFLOPS/W～100GFLOPS/W になると予想される．周波数を低く抑えるこ
とでコアあたりの消費電力を削減する一方，多数のコアの並列動作により高スルー
プットを得ることができ，高い電力あたりの性能を得ることができる．
ヘテロジニアス構成など：その他のバリエーションとして，少数の比較的大規模な
汎用コアと多数の小規模な汎用コアを組み合わせる構成である．制御が複雑なプロ
グラム部分（スレッド）は大規模汎用コアで実行し，スレッド並列性が高いプログ
ラム部分（スレッド）は多数の小規模コアで並列実行することで，総合的に高い実
効性能を得ることができる．また，各コアの L2 キャッシュを eDRAM などで実装し
た Local Memory (LM)に置き換えることでチップ内の記憶容量を増大させることもプ
ロセッサ構成の候補となる．この場合，データの再利用性を高めることで，高い実
効 B/F を達成することができる．
ノード構成
以下にノードの演算性能とメモリバンド幅の違いで区分した 3 通りのノード構成例を示
す（図 4.1-5 参照）．Thin node の構成は前述のプロセッサチップよりもコア数を削減し，
電力が小さいプロセッサチップで実現することを想定している．その他の構成は前述の
プロセッサチップの一つを利用することを前提としている．
57
図 4.1-5 ノード構成
·
·
·
(3)
Thin node：プロセッサチップ上に 3 次元実装技術により主記憶である DRAM を積層
し(Wide I/O)，それを 1 ノードとする構成である．この技術により，メモリの高性
能・高電力効率化が期待できる．1 ノード 1 チップで構成され，メモリバンド幅と容
量の制限から 1 プロセッサチップをそれほど高性能にできないことから，本システ
ムのノード数は O(1,000,000)になる．以下に本構成におけるノードの性能諸元を示す．
· 演算：性能 1TFLOPS，電力～2W
· メモリ(Wide I/O)：性能 200GB/sec，容量 4～8GB，電力～4W
· ノード：電力 10W～30W
Middle node：Hybrid Memory Cube (HMC)を利用した複数のデバイスを 1 プロセッサ
に接続し，それを 1 ノードとする構成である．本技術も 3 次元実装技術を応用した
ものであり，メモリの高性能・高電力効率化が期待できる．1 ノード 1 チップで構成
されるが，高性能なプロセッサチップを用いることで，システム全体のノード数は
O(100,000)程度になる．以下に本構成におけるノードの性能諸元を示す．
· 演算：性能 10TFLOPS，電力～20W
· メモリ（HMC の場合）：性能 1000GB/sec，容量 64～128GB，電力～40W
· メモリ（DDR4/5 の場合）：性能 300GB/sec，容量 256～512GB，電力～40W
· ノード：電力 100W～300W
Fat node：Hybrid Memory Cube (HMC)を利用した複数のデバイスを複数プロセッサ
と接続し，それを 1 ノードとする構成である．本技術も 3 次元実装技術を応用した
ものであり，メモリの高性能・高電力効率化が期待できるが，プロセッサとの接続
コストが問題となる可能性がある．1 ノード複数チップで構成され，システム全体の
ノード数は O(10,000)程度に抑えられる．以下に本構成におけるノードの性能諸元を
示す．
· 演算：性能 80TFLOPS，電力～200W
· メモリ（HMC の場合）：性能 8TB/sec，容量 512～1024GB，電力～400W
· メモリ（DDR4/5 の場合）：性能 2.4TB/sec，容量 2～8TB，電力～400W
· ノード：電力 1000W～3000W
システム（ノード間インターコネクト）構成
以下にノード間インターコネクトとして，High-radix ネットワークと Low-radix ネットワ
ークを利用した構成例を示す（図 4.1-6 参照）．ここで提示する通信帯域はメモリ帯域
の 1/10 から 1/20 を目安に決定したもので，ノード間インターコネクトにより大きな電力
を費やし，ノード間を接続する配線の本数を増加させることで通信帯域はさらに増加さ
せることも可能である．
58
図 4.1-6 ノード間インターコネクト
·
·
High-radix NW (Dragonfly) 構成：各ノードを高基数のネットワークで接続する構成
である．例えば，Dragonfly エラー! 参照元が見つかりません。などのトポロジが想
定される．以下に本インターコネクトの性能諸元を示す．
· レイテンシ
· 隣接最短： 2hop，200ns/dir
· 隣接最長： 5hop，1000ns/dir （全ノードでメッシュを構築した際の最悪部分）
· 最遠ノード間通信：5hop，1000ns/dir
· バンド幅
· ノードからの injection 帯域： 25.0～50.0GB/s
· 2 ノード間通信帯域： 25.0～50.0GB/s
· バイセクションバンド幅：1.0～5.0PB/s
· その他
· 局所性: 階層的（ネットワーク中で 1 hop 上位側へ進むと別グループのノード
へのアクセスが出来るようになる）
· ケーブル: ばらつきが大きく，巨大なシステムでは 20m 以上の長いケーブル
が必要になる
Low-radix NW (4D Mesh) 構成：各ノードを低基数のネットワークで接続する構成で
ある．例えば，4D トーラスなどのトポロジが想定される．以下に本インターコネク
トの性能諸元を示す．
· レイテンシ
· 隣接最短： 1hop，100ns/dir
· 隣接最長： 1hop，200ns/dir （全ノードでメッシュを構築した際の最悪部分）
· 最遠ノード間通信：～50hop，～5000ns/dir
· バンド幅
· ノードからの injection 帯域： 50.0～200.0GB/s
· 2 ノード間通信帯域： 6.3～25.0GB/s （minimal routing の場合）
· バイセクションバンド幅：0.1～0.5PB/s
· その他
· 局所性: 連続的（ネットワーク中で 1 hop 進むとそのノードに隣接するノード
への通信が可能）
· ケーブル: 比較的均一で 10m 以下の短いケーブルだけで巨大なシステムが実
現できる
59
(4)
·
·
·
その他の特性
I/O とストレージ構成：階層型ストレージアーキテクチャ（ローカルストレージとグ
ローバルストレージ）でグローバルストレージの容量はメモリ容量の 100 倍程度，
ローカルストレージの帯域はメモリ容量を 1000 秒で退避できる程度になると予想し
ている．また，検索などのアプリケーションではランダムに小規模なデータ読み出
しが頻発するが，その I/O 性能は上記のデータ転送帯域ではなく IOPS（1 秒あたり
の IO リクエスト数）で決定される場合が多い．IOPS の要求性能はアプリケーショ
ンに応じて変化する為，設計段階で議論を行う必要がある．
コア間通信方式：共有キャッシュ・共有ローカルメモリ・ローカルメモリへの DMA
などでコア間のデータの授受が行われる．これに伴って，Full/Empty ビットや Active
Message のような Message Driven (Data-Driven) で動作するメモリ階層などが並列化効
率を高めるために利用される可能性もある．
省電力・耐故障:省電力・耐故障のために，システム中の各コンポーネントが以下の
機能を持つことが想定される．省電力のための電力制御としては，2011 年現在で実
用化されている Clock Gating や DVFS に加え，「低消費電力」の章で議論されている
よりアグレッシブな電力制御機能（PowerKnob を用いた電力制御など）を持つこと
が想定される．耐故障機能機能としては，符号化・リトライを用いたデータ保護機
能に加え，10 万ノード超のシステムを安定動作させるためにチェックポイント支
援・プロセスマイグレーションによるフェイルオーバーの支援機構を持つ．
4.1.4 まとめ
これまでに述べた各研究項目について，研究開発を実施していく上でのロードマップを
以下に示す．各項目について，まず現行技術や現状のコモディティ製品についての調査
を行い，今後の技術動向を抑えるとともに，エクサスケールシステムを構築する上で必
要なデバイス技術やアーキテクチャ技術を明らかにすることが求められる．そして，そ
れぞれの要素技術について，エクサスケールシステムが実現されると予想される 2018 年
前後の実現可能性や性能値等のパラメータ見積りを行い，システムを構築した際の妥当
性を検証する必要がある．それと同時に，各要素技術について，我が国独自に開発すべ
き技術，コモディティとして実現され将来的に当該技術を取り入れることで十分に事足
りる技術，コストやリソースの観点から他国と協力して開発に取り組むべき技術とに分
類することも必要になる．また，サイエンスドリブンななエクサスケールシステムの実
現に向けて，重要サイエンス分野のアプリケーションを調査し，それをアーキテクチャ
候補選定の参考にすると共に，各要素技術を利用した際の性能や電力に関する見積もり
や分析を行う環境としてアーキテクチャシミュレータを構築することも必要である．こ
れらを，2012～2013 年頃に Feasibility-Study として行うことで，要素技術開発やシステ
ム開発向けた基盤を構築することが，サイエンスドリブン・エクサスケールシステムの
実現に向けた最初のステップとなる．
2014 年以降では，Feasibility-Study で得られた知見やシミュレーション環境を基に，実
際に要素技術開発やシステム開発を行い，評価・改良を踏まえつつ 2018 年頃のシステム
実現を目指す．
60
2011
ヘテロ
アーキテ
クチャ
2012
2013
2014
コモディティ製品ベー
スの技術調査・適用
検討
メモリ
アーキテ
クチャ
技術調査 要素技術検討
大規模
並列
技術調査 ネットワーク
構成方式検討
活用技術，メ
モリ/インター
コネクト省電
力技術検討
システムレベル電力制御技術検討
開発
システム開発
要素技術開発
開発
新デバイス
活用技術，メ
モリ/インター
コネクト省電
力技術開発
開発
システムレベル電力制御技術開発
新デバイス
技術調査 新デバイス
活用技術検討 活用技術開発
要素技術検討
アプリ
調査
2018
構成方式評価・改良
技術調査 新デバイス
コデザイ
ン
要素技術開発
2017
評価・改良
メモリ階層検討
要素技術検討
耐故障・
信頼性
2016
実験機による
評価・アーキ
テクチャ選定
独自開発ベースの技
術調査・適用検討
消費電力
2015
開発
故障モニタリング，冗長実行，
プロセスマイグレーション支援技術開発
シミュレーシ
ョン評価
アーキ
改良
アーキシミュレ
ータ開発
図 4.1-7 アーキテクチャ分野のロードマップ
4.1.5 参考文献
[4.1-1] R. C. Murphy, "X-caliber and Exascale Grand Challenge Research
Summary,"http://computing.ornl.gov/workshops/FallCreek11/presentations/r_murphy.pd
f, September, 2011.
[4.1-2] S. W. Keckler, W. J. Dally, B. Khailany, M. Garland and D. Glasco, "GPUs and the
Future of Parallel Computing,"IEEE Micro, vol. 31, no. 5, pp. 7-17, September-October,
2011.
[4.1-3] D. E. Shaw, et al., "Anton, a special-purpose machine for molecular dynamics
simulation,"Communications of the ACM, vol. 51, no. 7, pp. 91-97, July, 2008.
[4.1-4] J. Nickolls and W. J. Dally, "The GPU Computing Era," IEEE Micro, vol. 30, no. 2, pp.
56-69, March-April, 2010.
[4.1-5] P. Wang, C. L. Yang, Y. M. Chen, and Y. J. Cheng, "Power Gating Strategies on
GPUs,"ACM Trans. on Archi. and Code Optim., vol. 8, no. 3, article 13, October, 2011.
61
[4.1-6] T.J. Todman, G.A. Constantinides, S.J.E. Wilton, O. Mencer, W. Luk and P.Y.K.
Cheung,"Reconfigurable computing: architectures and design methods," IEE Proc.Comput. Digit. Tech., vol. 152, no. 2, March, 2005.
[4.1-7] Scott Rixner, et al, Memory Access Scheduling (ISCA2000)
[4.1-8] Aniruddha N. Udipi, et al, Rethinking DRAM design and organization for energyconstrained multi-cores, (ISCA2010)
[4.1-9] Aamer Jaleel, et al, High Performance Cache Replacement Using Re-Reference Interval
Prediction, (ISCA2010)
[4.1-10] The IBM Blue Gene/Q Compute chip with SIMD Floating-Point Unit (Hotchips-23),
2011.
[4.1-11] Dimitris Kaseridis, et al, Minimalist Open-page: A DRAM Page-mode Scheduling Policy
for the Many-core Era, (MICRO2011)
[4.1-12] Noboru Tanabe, et al,"A Memory Accelerator with Gather Functions for Bandwidthbound Irregular Applications", Workshop on Irregular Applications: Architectures &
Algorithms, 2011.
[4.1-13] J. Thomas Pawlowski, "Hybrid Memory Cube: Breakthrough DRAM Performance with a
Fundamentally Re-Architected DRAM Subsystem" Hotchips 23 (2011)
[4.1-14] Ruirui Huang, et al, IVEC: Off-Chip Memory Integrity Protection for Both Security and
Reliability (ISCA2010)
[4.1-15] Report on Instutute for Advanced Architectures and Algorithms, Interconnection
Networks Workshop 2008
[4.1-16] J. Kim et al., "Technology-Drivn High-Scalable Dragonfly Topology", International
Symposium on Computer Architecture (ISCA2008), pp. 77-88, 2008.
[4.1-17] T. Maruyama, "SPARC64(TM) VIIIfx: Fujitsu's New Generation Octo Core Processor
for PETA Scale Computing", HOT CHIPS 21, 2009.
[4.1-18] Intel-3DTr, http://download.intel.com/newsroom/kits/22nm/pdfs/22nmAnnouncement_Presentation.pdf, 2011.
[4.1-19] Y. Morita, R. Tsuchiya, T. Ishigaki, N. Sugii, T. Iwamatsu, T. Ipposhi, H. Oda, Y. Inoue,
K. Torii, and S. Kimura, " Smallest Vth variability achieved by intrinsic silicon on thin
BOX (SOTB) CMOS with single metal gate," Symposium on VLSI Technology, pp.166167, 2008.
[4.1-20] Hoeju Chung et.al., "A 58nm 1.8V 1Gb PRAM with 6.4MB/s program BW,"
International Solid-State Circuits Conference (ISSCC), pp.500-502, 2011.
[4.1-21] K. Tsuchida et al., "A 64Mb MRAM with clamped-reference and adequate-reference
schemes," International Solid-State Circuits Conference (ISSCC), pp.258-259, 2010.
[4.1-22] G. Gammie et al., " A 28nm 0.6V low-power DSP for mobile applications," International
Solid-State Circuits Conference (ISSCC), pp.132-134, 2011.
[4.1-23] M. E. Sinangil et al., " A 28nm high-density 6T SRAM with optimized peripheral-assist
circuits for operation down to 0.6V," International Solid-State Circuits Conference
(ISSCC), pp.260-262, 2011.
[4.1-24] U. Kang et al., “8Gb DDR3 DRAM Using Through-Silicon-Via Technology,”
International Solid-State Circuits Conference (ISSCC), pp.130-131, 2009.
[4.1-25] J. Thomas Pawlowski , “Hybrid Memory Cube (HMC),” Hot Chips 2011.
[4.1-26] Carl Ramey, “TILE-Gx100 ManyCoreProcessor: Acceleration Interfaces and
Architecture,” Hopchips 2011.
[4.1-27] Intel® Many Integrated Core Architecture,
http://www.intel.com/content/www/us/en/architecture-and-technology/many-integratedcore/intel-many-integrated-core-architecture.html.
[4.1-28] PCI Express Base 2.0 Specification,
http://www.pcisig.com/specifications/pciexpress/base2/.
[4.1-29] W. Green, S. Assefa, A. Rylyakov, C. Schow, F. Horst, and Y. Vlasov, "CMOS
Integrated Silicon Nanophotonics: Enabling Technology for Exascale Computational
Systems," Invited talk at SEMICON 2010.
http://www.research.ibm.com/photonics/publications/SEMICON_Tokyo_12_1_2010.pdf
[4.1-30] F. Cappello, “Fault tolerance in petascale/exascale systems: Current knowledge,
challenges and research opportunities,” Intl. J. High Perform. Comput. Appl. 23, 3, pp.
212–226, 2009
62
[4.1-31] DoE, “Scientific Grand Challenges: Fusion Energy Sciences and the Role of Computing
at the Extreme Scale – March 18-20, 2009, Washington, D.C. PNNL-19404, U.S.
Department of Energy,” http://extremecomputing.labworks.org/SumReps/FES-SumRepPNNL_19404.pdf, 2011
4.2 システムソフトウェア
4.2.1 はじめに
前節の通り，エクサスケールへ向けて起こるさまざまな制約を満たすためにアーキテク
チャが変化することが必然となる．ノードあたりの演算器の数の増加やメモリ階層・ネ
ットワーク階層の複雑化は不可避であり，コンポーネント数の増加によって平均故障間
隔(MTBF)が無視できない程度に短くなると予想されている．また，計算機の性能の制約
条件もトランジスタ数から電力へと移ってきており，計算機のコンポーネントごとの電
力の把握と制御が必要となってきている．
このように複雑化する環境下においてハードウェアとアプリケーションの橋渡しをす
るシステムソフトウェアの果たすべき役割は重要であり，さまざまな方面での研究開発
が望まれている．研究開発の過程では，実装のメモリおよびオーバーヘッドにおけるス
ケーラビリティの確保が強く要求されており，API における互換性の維持・標準化への
貢献も必要となる．本節ではこれらシステムソフトウェアにおける研究開発項目とロー
ドマップについて記述する．
4.2.2 オペレーティングシステムおよびランタイム
(1) ヘテロジニアスアーキテクチャ
ヘテロジニアスアーキテクチャ向けシステムソフトウェアはその機能について異種コア
間における適切な役割分担を検討する必要がある．具体的にはスカラ性能を要求する機
能はレイテンシコアで実行し，スループットコアではアプリケーション実行に特化した
最低限の機能を提供する OS やランタイムをスループットコアで実行する方式が有力で
ある．具体的には，アプリケーションは両者間で分散もしくはスループットコア上で実
行される．通信，I/O サービスや割り込み処理などもレイテンシコアにオフロードする
方式が有力である．この場合 I/O スループット志向のアプリケーションはレイテンシコ
ア，数値演算主体のアプリケーションはスループットコアで実行される．また，スルー
プットコアが高機能な場合にはスループットコアの一部を OS 処理専用コアとして割り当
てる方式も考えられるが，スループットコアは従来のスカラコアとはキャッシュサイズ
等の違いがあり，スループットコアに適した実装方式を開発する必要がある．これらの
システムソフトウェアの各機能の役割分担等のエクサスケールシステムを見据えた設計
について 2012 年から 2013 年にかけて評価検討を行い，有力な方式については 2014 年
から 2016 年にかけてさらなる効率化に向けた開発を行う．
さらに，ヘテロジニアス化とともに実行コンテキストの数が増大した実行環境下では，
アプリケーションのデバッグが従来のシングルスレッド環境やホモジニアス環境に比べ
て困難になってきている．これは従来の SIMD アプリケーションにも見られた問題であ
ったが，スレッド数のさらなる増加や実行コンテキストおよびメモリ空間のヘテロジニ
63
アス化により深刻化している．スループットコアにおいても必要な粒度で実行を止めて
メモリ情報を取得でき，多量の実行コンテキストを無理なく追跡可能なデバッグ環境の
構築を 2013 年から 2015 年にかけて行う．
(2) メモリ
各種メモリウォールを打破するためのメモリアーキテクチャ，プログラミングモデルの
実現のために，API 定義を含めた OS サービスを最適化することを目指す．OS が関連す
る研究項目としては，コアローカルメモリ，ヘテロジニアスアーキテクチャ対応，不揮
発メモリ等の新規メモリテクノロジの活用が挙げられる．
ローカルメモリについては，アプリケーションからの常に安定した性能を確保できる
静的な領域獲得を行うアプローチが有力である．これを実現するためのメモリの獲得，
マッピングの API の定義をする他，コンテキストスイッチ時の動作等についての設計を
進める．
ヘテロジニアスアーキテクチャについては，異なるアーキテクチャ間での共有メモリ
領域の獲得 API の他，一貫性保証の方式等の各種 API の定義を行うことに加え，ポータ
ビリティを考慮した ELF 形式を拡張もしくは置換するような実行モジュールの形式の標
準化提案も重要となる．合わせてリンカやデバッガ等のツール類の実現方法の検討も重
要な鍵となる．
これらのメモリアクセス方式については，2013 年を目途に方式の概要を決めたうえで，
2015 年を目途にインターフェースの詳細を具体化・確定させるべきである．
また，今後 HPC システムでも実用レベルとなる新規のメモリテクノロジの活用方法に
ついての検討は非常に重要である．特に MRAM， FeRAM のような不揮発メモリについ
ては，チェックポイント・リスタートの高速化[4.2-1][4.2-5]，消費電力削減，マイクロリ
ブートの高速化[4.2-6]等の有望な用途が考えられ，積極的に活用研究を進めるべきであ
る．
(3) 大規模並列
スケーラブルなマルチスレッド処理
ノード内，システム全体において非常に多数のスレッドが動作するため，スレッドの高
速同期機構，切り替え機構をハードウェアの協力を得て実現する必要がある．ネットワ
ークとの関係においても，従来のようにネットワークパケットが到着してプロトコル処
理をしてからターゲットのスレッドをスケジュールし wakeup するのではなく，ネット
ワークパケットが到着するとその足でブロックされていたスレッドが実行されるような
機構が今後の大規模並列性を有効的にアプリケーションから利用するために重要になる
ことが想定される．非常に多数のスレッドを効率良くスケジュールする方式についても
2014 年から 2015 年頃までに API を詳細化し，予備的なプロトタイプ実装をプログラミ
ング言語，数値計算ライブラリの開発用に提供するべきである．また，2015 年頃には
100PF 級のスーパーコンピュータが設置されることが予想されるが，2018 年以降のエク
サスケールシステムにおいて運用プロダクトとして利用可能にするために，アーキテク
チャの進展と同期して開発，評価を進めていく必要がある．
スケーラブルなノード間通信
大規模並列に適したノード間の通信の実装，特に 3.3.2 節で述べたように機能と性能バラ
ンスのトレードオフを考慮した通信方式を設計する．また，ノードあたりのコア数の増
加を利用した通信プリミティブの開発を行う．通信専用コアを利用することで，非同期
集合通信のようなより複雑な通信処理を効率よく実行することによる性能向上が可能に
なると考えられる．また，通信の割り込みを制御することでデータを利用するコアに行
64
わせて，コアレベルで細分化したメモリ階層上に効率的にデータを配置する手法も考え
られる．これらの通信プリミティブ実装技術の取捨選択および組み合わせについても検
討する必要がある．
また，ランタイムシステムにおいて動的に実行時の状況にあわせた最適化を施すこと
によりスケーラビリティの向上を目指す．これにより，大規模化および階層構造がより
深化することが予想されるエクサスケールシステムにおいて静的な最適化では不可能な
より環境に適した高度な最適化が可能になる．具体的な最適化の対象としては，集団通
信等のアルゴリズム選択，プロセスやスレッドの配置，負荷分散，各種性能パラメータ
の調整等が考えられる．これらについて，静的な情報と動的な情報を活用し，最適化と
それによるコストのバランスを考慮したアプローチを検討すべきである．例えばインタ
ーコネクトのトポロジ情報や割り当てられたノードの形状の他，プログラムの通信パタ
ーンや通信と計算の比率等のコンパイル時に得られる情報等を用いて最適化の探索空間
を絞り込むことによりオーバーヘッドの低減を図ることができる．これらの最適化技術
は，ハードウェアの構成や言語処理系，数値計算ライブラリの技術動向に応じた開発が
求められるため，これらのレイヤとの連携が必須である．
(4) 耐故障
Fault Resilience を実現するフレームワークの 1 つとして横断的にシステムを構成するコ
ンポーネントの状態を効率よく開示する情報伝播機構を開発する．萌芽的な研究として
CIFTS[4.2-15]という枠組みが存在するが，これらの情報は莫大な量になる可能性が高く，
計算リソースに影響しないよう，より効率的に伝播する必要がある．このため，専用リ
ソースの利用も視野に入れた，伝播タイミング・経路の効率化手法および，統計処理を
生かした必要な情報の選別・抽象化について検討する．さらに，フレームワーク内のや
り取りされる情報の規格を統一するために故障モデルを検討し，2013 年から 2014 年に
かけて明確に定める．
アプリケーションの改変が不可能であったり，小規模なジョブを実行したりする場合
には，システムソフトウェアレベルで故障を隠蔽することも依然必要である．隠蔽型耐
故障の大規模対応として，半導体ストレージや不揮発メモリを用いたチェックポイン
ト・リスタートの高速化[4.2-1][4.2-2]，アプリケーション実行時の通信パターンや，メモ
リアクセスパターンを利用した最適化[4.2-3]などの研究開発が必要である．また，故障
規模やハードウェアの故障率，I/O 状況といった実行環境にあわせ，並列耐故障アルゴ
リズムに関しても階層的チェックポイント[4.2-4]等の最適化を施す．
また，仮想計算機技術を用いることで，ノード間の移送が容易になり，障害回復や負
荷分散に対する柔軟性を向上させる方式についても検討すべきである．仮想化による性
能低下が問題となりうるため，得失の評価や軽量な仮想化技術の開発などが必要である．
ノード内ヘテロ化に伴い CPU コアが OS 実行用（レイテンシコア）と演算用（スルー
プットコア）に分離することが想定されるため，各コアへの OS 機能の割当てと耐故障
に対するモデル化が 2015 年をめどに必要である．耐故障の観点から見ると故障がどちら
のコアで起こったかによってジョブ継続性への対応が異なる．演算コア故障に対しては，
チェックポイント・リスタート等による再実行が可能なので，ランタイムシステムと連
携してジョブを継続実行する．一方，OS コア故障に対しては，ソフトウェア対応のみな
らずハードウェアの冗長化が必要と考えるが，コスト増に見合う効果が得られるかは要
検討である．実用化にあたっては，より低コストかつ軽量な冗長化技術の開発が必要で
ある．これらの耐故障実行基盤のための各要素技術は 2016 年から 2017 年をめどに実シ
ステムへ統合されることが期待される．
65
(2)
低消費電力
OS とランタイムシステムおよびアーキテクチャと連携したコデザインによりシステム全
体の電力消費量の最適化を目指す．そのために OS としては利用可能な（細粒度）電力
制御パラメータの取得と設定，および電力データを取得するための API を定義する必要
がある．制御例として，CPU の Dynamic Frequency Scaling[4.2-7]や，Dynamic Voltage
Scaling[4.2-8]，パワーゲーティング[4.2-9]の活用や，通信時の同期法を使い分ける[4.210]ことなどが現状では考えられるが，今後の低消費電力化のためのアーキテクチャ技術
開発をアプリケーションレベルから有効に活用するためのインターフェースを定義する
ことが重要である．ランタイムシステムではこれらの API を用いて電力制御ポリシを定
義し，電力バジェットの制約を満たしながらアプリケーションの実行を効率よく行うフ
レームワークの提供を行う必要がある．
(3)
生産性
性能や機能を計算に特化したスループットコア上で動くプログラムから通信や I/O を発
行するための仕組みの確立に取り組む必要がある．スループットコアからの I/O の可否
はハードウェアの仕様に依存するが，新たな API を定義した上で，ハードウェアが I/O
機能を提供する場合はその機能を利用し，提供しない場合はソフトウェアエミュレーシ
ョンを行う等，ハードウェア構成の差異を吸収するソフトウェアレイヤを提供して統一
的なアプリケーションプログラミング環境を提供する．
また，キャッシュ，レイテンシコアのコアローカルメモリ，スループットコアのメモ
リ，他ノードのメモリなど，メモリ階層が複雑化し，それぞれの性質を生かすべく新た
な OS レベルの API が作られていくことが予想されるが，プログラミング言語実装と協
調してこれらをユーザに対して性能劣化を起こすことなく透過的に見せる実装を行う．
既存のプログラムとの互換性を確保するため，POSIX 互換インターフェースの提供も
検討すべきである．特にスクリプト言語を利用できるようにすることは，利用者の生産
性を高めることにつながると期待できる．完全な POSIX 互換インターフェースを提供し
てすべての既存プログラムを動作可能とする方式と，スクリプト言語の処理系や言語の
クラスライブラリを新たな API で再実装してスクリプト自体の互換性を確保する方式の
利害得失について 2014 年を目途に検討する必要がある．
(4)
大規模データ処理向けミドルウェア
エクサスケールシステムにおいては，10 億並列級のプロセス・スレッドからの I/O を効
率的に処理することが求められる．そこで，ファイルシステムやファイルシステムとの
性質の差異を吸収して，それぞれのファイルシステムの性能を最大限に発揮できるよう
なミドルウェアの開発が必須となる．特に以下に注力した研究開発が望まれる．
·
·
様々な I/O 最適化方式の検討: 現在においても，I/O の集約，I/O データの並び替え，
I/O 順序のスケジューリングなど，様々な I/O の最適化方法の研究開発が行われてい
る．今後はより効率的に I/O を行える最適化方式の検討を進める必要がある．
I/O 最適化のためのヒント情報取得に関する検討: 上記のような最適化のためには，
ミドルウェアにおいてアプリケーションの I/O の特徴を取得して，得られた情報をも
とに I/O の方式を選択する必要がある．そのためにはどのような I/O 情報を取得する
かを取捨選択したうえで，アプリケーションから I/O の特徴をヒントとして与えるた
めのインターフェースの構築が必要となる．インターフェースの構築にあたっては
アプリケーション開発者，プログラミング言語開発者との連携が必須となる．
66
·
ヒントを用いた I/O 方式の最適化: 上記のアプリケーションプログラマによるヒン
トを活用し，それを用いたファイルシステムやデータストアなどの I/O ミドルウェア
の最適化を 2017 年までを目途に行う．
表 4.2-1 オペレーティングシステムおよびシステムソフトウェアに関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2013
研究開発内容
· 非同期通信・スループットコア間通信の高速化 14・省メモリ化
· Light-Weight OS の実装方式の検討 14
· プログラミングインターフェースの検討
· I/O 最適化方式の検討
2014-2015
· ノード間通信，スレッド管理 14，メモリ階層管理の API の詳細化
· ロードモジュール形式の策定
· 並列・ヘテロジニアス環境向けデバッガの開発
· 電力管理フレームワークの開発 3,4
· 通信の動的最適化技術の開発 17
· I/O 最適化のためのヒント情報取得方式の開発
· 耐故障フレームワークのための故障モデルの設計
· 数十 PF 環境での検証
2016-2017
· 各種通信基礎技術の統合
· 各種耐故障基礎技術の統合
· I/O 最適化技術を適用したファイルシステムやデータストアの開発 16
· 数百 PF 環境での検証
2018-
· 実システム上での実装と評価・調整
4.2.3 システム管理
本章ではエクサスケールシステムに求められるジョブスケジューリング機構，資源モニ
タリング機構の課題と研究開発項目についてまとめる．
(1) 大規模並列
スケーラブルなスケジューリング
エクサスケールシステムにおいては，スケジューラ自身のスケーラビリティを確保する
ことが非常に重要になるため，スケジューラ自身のマルチスレッド化や，通信の非同期
化，必要があれば複数ノードにまたがる並列化等の手法について 2014 年を目途に開発す
る必要がある．
さらに，ノード群，タスク群を類似性によってグループわけし，グループ単位でスケ
ジューリングを行う手法が利用状況によっては有望である．ギャングマッチングと呼ば
れる，同等な資源，同等なジョブをグループわけし，グループ単位でスケジューリング
することでスケジューリングのコストを低減する手法が提案されているが[4.2-11]，エク
67
サスケールにおける有効性については実証されておらず，グループの階層化などの技術
開発が 2016 年を目途に必要である．
ネットワーク構造を意識したスケジューリング
現状の HPC システムのスケジューリングにおいては，ネットワーク構造への対処につい
ては非常に単純なもの（トーラス上の連続領域をジョブに割り当てるなど）か，管理者
による人為的なもの（ネットワークの木構造に合わせたキュー分割など）が行われてい
る．しかし今後のエクサスケールにおいて，特に Butterfly 構造や Dragonfly 構造などの
ネットワークロポロジにおいてはジョブの通信密度などを意識したジョブ配置が必要と
なる．
多種多様なジョブを最適配置するスケジューリング
大規模システムにおいては多種多様な性質を持つジョブ群を効率的にノード群に配置す
る必要がある．現在運用中の HPC システムで対応が不足している点の一つはネットワー
ク負荷の多様性である．ここでは並列ジョブを，(a) 密結合ジョブ，(b) ワークフロージ
ョブ，(c) アレイジョブに大別して考える（(c)は(b)に含まれるなど，明確に区別できる
ものではない）．これらはネットワークにかける負荷が全く異なるにも関わらず，現状
のシステムではほぼ画一的にスケジュールされる．エクサスケールシステムのネットワ
ークではバイセクションバンド幅が相対的に低下するため，このままでは各ジョブの性
能・システム全体の効率とも下がってしまう．今後はジョブの特性と，ネットワーク構
造の双方を考慮することによってシステム全体の利用効率を改善するスケジューリング
アルゴリズムの研究開発を 2017 年から 2018 年にかけて行う必要がある．
スケーラブルなモニタリング
HPC システムにおいてはモニタリングシステムにより，各コンポーネントの負荷・障害
（予兆も含む）・電力などのシステムの状況をリアルタイムに取得し，スケジューラや
アプリケーション，エンドユーザにフィードバックする必要がある．エクサスケールに
向けて，そのモニタリングシステム自身もスケーラブルなものでなければならない．ノ
ード数の増加に対応するための情報の集約技術として，オーバーレイネットワークの利
用[4.2-12]などが研究されているが，さらなる効率化のためには，通信ライブラリ層との
協調によるデータのピギーバック，OS 層との協調によるジッタの削減などの階層をまた
いだ技術の開発を 2015 年までを目途に行う必要がある．
上記に加えて，エクサスケールシステムにおいては，重要な情報を失うことなく収集
データ量を大幅に削減する技術の重要性が高くなる．部分的な解決としては，MPI のロ
グを圧縮する手法[4.2-13]や，性能データを並列にサンプリング・クラスタリングする手
法[4.2-14]が提案されている．今後はさらに，データマイニングの導入や検索技術，スト
レージ資源の節約と対応の即時性の両方の観点から，継続的に生成されるデータをリア
ルタイム的に処理する技術の研究開発が求められる．
(2) 耐故障性
現在運用されているシステムにおいても対応はされているものの，ノード故障を検知し
た場合にジョブを再投入するなどの限定的なものが典型的である．今後のシステムの巨
大化とともに故障率は高くなるため，故障時に被るオーバーヘッドの削減などが必要不
可欠となる．具体的には，故障ノードの代替ノードの選出においてもネットワーク構
成・ジョブ特性を考慮するアルゴリズム，致命的な故障のみならず障害の予兆の検知時
に走行中ジョブを順次退避させる技術の研究開発を行い，先述のスケジューラに適宜組
み込まれていくことが求められる．
システムソフトウェアの継続性の観点からは，システム間のインターフェースにも注
意を払うべきである．モニタリングシステムとスケジューリングシステム間の故障情報
68
のやりとりを行う基盤として CIFTS[4.2-15]が提案段階にあり，国際連携によりそのよう
なデファクトスタンダード技術との協調を行う必要がある．
(3) 低消費電力
エクサスケールシステム実現のためには，電力性能比の最適化を，アーキテクチャ・シ
ステムソフトウェア・アプリケーションの各層の連携により行う必要がある．システム
管理層においては，電力データのモニタリングと power cap を行うジョブスケジューリ
ングの研究開発を行う．
電力データモニタリング
現状の HPC システムにおける電力モニタリングシステムは，精度や情報の利用方法が限
定されているか，そもそも電力が監視されていない場合すらある．エクサスケールシス
テムを実現するための電力最適化のために，モニタリングシステムは，各ノード・各コ
ンポーネントの消費電力情報をリアルタイムに取得し，スケジューリングシステムやア
プリケーションにフィードバックする役割を持つ．（上記項目ともオーバーラップする
が）その情報は膨大になるため，最適化に必要十分な情報の取得のために，精度を調整
可能とする手法やデータ圧縮技術の研究開発が必要である．
Power cap ジョブスケジューリング
エクサスケールシステムにおけるスケジューリングシステムは，システム全体の消費電
力限界の遵守を目的として，多数ジョブ間の調停をする役割も果たす必要がある．現在
運用中のスケジューリングシステムはこのような機能を持たず，また研究レベルにおい
てさえも，多くが単一ジョブ内の電力最適化に限定されている．このため，システム全
体の power cap を可能とするスケジューリングシステムの研究開発が 2018 年までに必要
である．必要となる研究項目は， power knob の調整の影響を予測可能な電力性能モデル，
ジョブ特性に応じて最適な power knob を選択するアルゴリズム，ジョブ間の電力バジェ
ットを調整する運用手法などを含む．
(4) 大規模データ処理向けジョブスケジューリング
データインテンシブな計算を行う場合，データと計算ノードの位置が近くなるように配
置（データアフィニティスケジューリング）するほど，ネットワーク帯域の消費量の削
減と計算効率の向上ができることが知られており，例えば Hadoop では簡単なデータア
フィニティスケジューリングが行われている．この重要性は，計算ノード数が 100 万を
超えるエクサスケールシステムでは特に高くなる．データアフィニティスケジューリン
グ手法のスケーラビリティの向上技術の研究および，ワークフローエンジン(Condor
DAGMan[4.2-16]， Pegasus[4.2-17]， GXP make[4.2-18]， Pwrake[4.2-19]など)との統合が
必要である．
またファイルシステム層などとの連携により，情報を共有する手法の整備が必要とな
る．具体的にはデータの所在を知るための API，またそれに基づくスケジューリング結
果をワークフローエンジンに伝えるための API などである．これらの API の整備を 2015
年から 2016 年にかけて行う必要がある．
表 4.2-2 システム管理に関するロードマップ
達成時期
研究開発内容
2012-2014
· スケーラブルなジョブスケジューラの開発
· モニタリング方式の検討・モニタリング機構の開発
69
2015-2016
· ネットワークを考慮したジョブスケジューラの開発
· 効率的なモニタリング情報伝播機構の開発
· データ配置に基づいたスケジューリング方式の開発
2017-2018
· ジョブの性質・power cap を考慮したジョブスケジューラの開発
· ジョブスケジューリングにおける各種要素技術の統合
4.2.4 外部資源連携
外部資源連携の課題は多岐にわたり，特に各種サービス間連携のためのインターフェー
ス統一・標準化は基幹であり重要であり，国際協力しつつ進めるべきである．外部資源
連携を行うことにより，エクサスケール HPC システムの利用者に対して大きな恩恵とな
る以下の 2 項目をロードマップの重点項目とする．
·
·
広域データ転送・共有の効率化
HPC システムの計算性能が向上するに従い，膨大な計算性能を活用した科学技術計
算を実行するために，膨大な入力データを外部組織から転送する，膨大な出力デー
タを外部組織に転送する事例が増えることが予想される．データ転送を効率化しつ
つも，容易性を保つ必要がある．
効率の面に関して，WAN が以前に増して LFP となるので，このような環境を意識し
た輻輳制御・通信最適化を行う通信手法の研究開発，およびデータ管理システムの
研究開発が必要である．広域でのデータ管理システムとしては，分散ファイルシス
テムや，レプリカカタログが開発されているが，データのキャッシングの最適化が
必要である．また，センサ等が生成する大量な小規模データの管理も，on-the-fly で
集約する等の最適化が求まれる．
容易性に関しては，分散ファイルシステムや特殊な通信手法を用いる場合は専用の
ソフトウェアを導入しなければならないが，小規模な研究室では困難である．サー
ビス化，アプライアンス化も必要である．
外部計算資源への計算移譲
一般的な HPC システムでは全体を使った大規模計算はまれであり，通常運用ではバ
ッチジョブ管理システムにより，多数の利用者の多数のジョブが実行されている．
このため，繁忙期には混雑により makespan の増長が起こるが，外部計算資源を活用
して一部のジョブ実行を移譲することにより，混雑の軽減が可能である．
これを実現するためには，異種外部計算資源を統一的に動的管理する機構が必要で
ある．HPC システムと外部計算資源間でネットワークやアカウントの連携を行うた
めには，一定時間限られた資源のみ許可する等，時限・空間管理機構の研究開発も
必要である．また，ジョブと関連するデータの転送が発生するため上記広域データ
転送の課題の解決も求められる．
また，これらの実施に先立ち，エクサスケール HPC システムと外部資源とのネットワー
クインターフェース部分のシステムアーキテクチャの設計が必要である．
実施計画を以下にまとめる．2012 年から 2013 年にかけて，要素技術の調査を行い，
外部資源連携のためのシステムアーキテクチャ設計，および，外部資源間への計算ジョ
ブ移譲機構の研究開発を実施する．2014 年から 2016 年では，通信最適化技術の研究開
発，および，広域環境でのデータ管理の最適化のための研究開発を行う．2016 年以降は
ジョブ管理機構とデータ共有機構の統合を実施しつつ，最適化を行う．並行して普及の
ためのサービス化，アプライアンス化のための開発を行う．
表 4.2-3 外部資源連携に関するロードマップ
70
達成時期
2012-2013
研究開発内容
· 要素技術調査開始
· 外部資源連携アーキテクチャの検討
· ジョブ管理機構の開発
2014-2016
· 通信技術の開発
· 広域データ管理最適化技術の開発
2016-
· ジョブ管理機構と広域データ管理機構の統合
· 普及に向けたサービス化，アプライアンス化のための開発
4.2.5 まとめ
アーキテクチャの複雑化および電力という新たな制約項目の出現によってソフトウェア
が考慮しなければならない項目の増大は既に不可避であるが，それらすべてをアプリケ
ーションユーザに委ねることもまた非現実的である．システムソフトウェアが果たすべ
き役割はアーキテクチャとアプリケーションプログラマの橋渡しであり，アプリケーシ
ョンプログラマから見て高性能でかつ使いやすいシステムソフトウェアの開発が強く求
められている．
本節ではエクサスケールの時代へ向けてシステムソフトウェアに求められている研究
開発項目とそのロードマップについて述べた．個別の研究開発項目の実施時期は各項目
に示した通りであるが，図 4.2-1 にシステムソフトウェア分野全体としての線表を示す．
なお，本線表中の 2013 年までの方式検討においては，本ロードマップで例示した研究開
発項目についてその実現可能性，性能，ユーザビリティ，開発費用の見積もりの面から
その適否を検討し，研究開発体制及び研究計画を具体化することが期待される．
2012
2013
機能提案
2014
Arch.
SIM V1
連携
&deploy
OS
ランタイムAPI
方式検討・シミュレーション
通信
方式検討
実装・評価
I/Oシステム
方式検討
API開発・評価
システム管理
外部連携
耐故障技術
国際標準化
要素技術整理
方式検討
方式検討
API詳細化
API策定
FTAPI策定・評価
FS・Draft策定・評価
2015
Arch.
API SIM V2 API
API整備
Prototype
2016
2018
2019
2020
Update
プロトタイプ実装・評価 実システム実装・評価
移植・改良・評価
移植・改良・評価
データストア開発・評価
個別技術実装・評価
実装・評価
2017
Arch.
Arch.
Runtime Testbed OS
Full Impl Full System
Impl
Prototype
移植・改良・評価
新デバイス対応・評価
統合・評価・改良
評価・改良・運用
改良・評価
改良・評価・策定
図 4.2-1 システムソフトウェア分野のロードマップ
線表上にもある通り，ユーザに対するインターフェースのようにシステム間で標準化
されるべきものについては国際的に協調して国際標準を用いる・国際標準の策定に資す
ることが強く期待される．また，設計開発の各段階でアーキテクチャやプログラミング
言語・ライブラリおよびアプリケーションの開発者とも協調してユーザに真に求められ
るシステムが開発されることが強く期待される．
71
4.2.6 参考文献
[4.2-1] Adrian M. Caulfield, Joel Coburn, Todor I. Mollov, Arup De, Ameen Akel, Jiahua He,
Arun Jagatheesan, Rajesh K. Gupta, Allen Snavely, and Steven Swanson, Understanding
the Impact of Emering Non-volatile Memories on High-performance, IO-Intensive
Computing, In Proceedings of the 2010 IEEE/ACM Supercomputing Conference, 2010.
[4.2-2] Adam Moody, Greg Bronevetsky, Kathryn Mohror, and Bronis R. de Supinski, Design,
Modeling, and Evaluation of a Scalable Multi-level Checkpointing System, In
Proceedings of the 2010 IEEE/ACM Supercomputing Conference, 2010.
[4.2-3] T. Ropars, A. Guermouche, B. Uçar, E. Meneses, Laxmikant V. Kalé, F. Cappello, On the
Use of Cluster-Based Partial Message Logging to Improve Fault Tolerance for MPI HPC
Applications, Proceedings of Europar 2011.
[4.2-4] Leonardo Arturo Bautista Gomez, Dimitri Komatitsch, Naoya Maruyama, Seiji Tsuboi,
Franck Cappello, Satoshi Matsuoka, and Takeshi Nakamura, "FTI: High Performance
Fault Tolerance Interface for Hybrid Systems," Proceedings of the 2011 ACM/IEEE
conference on Supercomputing (SC'11), pp. 1--12, Seattle, WA, USA, Nov 2011.
[4.2-5] X. Dong, Y. Xie, N. Muralimanohar, N. P. Jouppi, Hybrid checkpointing using emerging
nonvolatile memories for future exascale systems, ACM Transactions on Architecture and
Code Optimization, 2011
[4.2-6] R. Coulson, J. Garney, J. Matthews, R. Royer, System Boot Time Reduction Method, US
Patent 6,920,533, 2005
[4.2-7] Andreas Weissel and Frank Bellosa, "Process cruise control: event-driven clock scaling
for dynamic power management", CASES '02, 2002.
[4.2-8] Padmanabhan Pillai and Kang G. Shin, "Real-time dynamic voltage scaling for lowpower embedded operating systems" SOSP '01, 2001
[4.2-9] Chi-Hoon Shin, Myeong-Hoon Oh, Jae-Woo Sim, Jae-Chan Jeong, and Seong Woon Kim,
"Fine-Grained FSMD Power Gating Considering Power Overhead", ETRI Journal,
vol.33, no.3, Jun. 2011.
[4.2-10] Atushi Hori, Toyohisa Kameyama, Mitarou Namiki, Yuichi Tsujita, and Yutaka Ishikawa,
"Low Energy Consumption MPI Using Hardware Synchronization", Information
Processing Society of Japan HPC-132(7), 1-7, Nov. 2011.
[4.2-11] Rajesh Raman, Miron Livny and Marvin Solomon, "Resource Management through
Multilateral Matchmaking,” Proceedings. The Ninth International Symposium on HighPerformance Distributed Computing, 2000.
[4.2-12] Philip C. Roth, Dorian C. Arnold, and Barton P. Miller, “MRNet: A Software-Based
Multicast/Reduction Network for Scalable Tools”, Supercomputing 2003 (SC’03)
[4.2-13] Michael Noeth, Frank Mueller, Martin Schulz, Bronis R. de Supinski, “Scalable
Compression and Replay of Communication Traces in Massively Parallel Environments”,
In IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2007.
[4.2-14] Todd Gamblin, Bronis R. de Supinski, Martin Schulz, Rob Fowler, and Daniel A. Reed,
“Clustering Performance Data Efficiently at Massive Scales,” In IEEE International
Conference on Supercomputing (ICS), 2010.
[4.2-15] R. Gupta, P. Beckman, H. Park, E. Lusk, P. Hargrove, A. Geist, D. K. Panda, A.
Lumsdaine and J. Dongarra,“CIFTS: A Coordinated infrastructure for Fault-Tolerant
Systems,” Proceedings of the International Conference on Parallel Processing (ICPP),
2009.
[4.2-16] Peter Couvares, Tevik Kosar, Alain Roy, Jeff Weber and Kent Wenger, "Workflow in
Condor,” In Workflows for e-Science, Editors: I.Taylor, E.Deelman, D.Gannon,
M.Shields, Springer Press, January 2007.
[4.2-17] Ewa Deelman, Gurmeet Singh, Mei-Hui Su, James Blythe, Yolanda Gil, Carl Kesselman,
Gaurang Mehta, Karan Vahi, G. Bruce Berriman, John Good, Anastasia Laity, Joseph C.
Jacob, Daniel S. Katz, "Pegasus: a Framework for Mapping Complex Scientific
Workflows onto Distributed Systems,” Scientific Programming Journal, Vol 13(3), 2005,
Pages 219-237.
72
[4.2-18] Kenjiro Taura, Takuya Matsuzaki, Makoto Miwa, Yoshikazu Kamoshida,. Daisaku
Yokoyama, Nan Dun, Takeshi Shibata, Choi Sung Jun, and Jun'ichi Tsujii, "Design and
Implementation of GXP Make -- A Workflow System Based on Make,” IEEE Sixth
International Conference on e-Science (e-Science),2010.
[4.2-19] Masahiro Tanaka and Osamu Tatebe, "Pwrake: A parallel and distributed flexible
workflow management tool for wide-area data intensive computing,” Proceedings of
ACM International Symposium on High Performance Distributed Computing HPDC
2010, pp.356-359, 2010.
4.3 プログラミング
4.3.1 はじめに
３章で述べた課題の全てをプログラマから透過的に解決することは困難である．透過的
に解決できる可能性のある課題においても，プログラマからの指示によってその問題解
決の難易度を大幅に下げることができる．従ってエクサスケールにおけるプログラミン
グ言語および環境は，課題解決に有用な詳細情報を記述するために比較的抽象度の低い
プログラミングモデルや API 等を提供しなければならない．例えば，電力効率を重視し
たアプリケーション開発を支援するために消費電力の計測および制御のための API が必
要になるが，高性能計算環境においてはそのような機能を備えた標準 API は未整備であ
る．同様に耐故障性，10 億スレッド規模の大規模並列プログラミング，より複雑かつ深
い階層のメモリシステム等を表現するプログラミングモデルも未確立であり，今後の研
究開発が必要である．
また，エクサスケール時代の課題は多岐にわたるため，その全てにプログラマが配慮
する抽象度の低いプログラミングにおいてはソフトウェア開発の生産性の著しい低下が
懸念される．すでに現在においても異種プロセッサを混載するノードから構成されるヘ
テロジニアススーパーコンピュータ等のプログラミングでは，適切な抽象化を提供する
プログラミングモデルが存在しないため生産性の大幅な低下が問題になっている．今後
さらにシステムのヘテロジニアスアーキテクチャ化や大規模並列化が進むことを考える
と，性能を始めとする必要要件と生産性を両立するための研究が必要不可欠である．生
産性を高めるためには何らかの着眼点に基づいて抽象度を高め，上述のような低水準プ
ログラミングの必要性をアプリケーション開発者から隠ぺいする，抽象度の高いプログ
ラミング環境が求められる．そのような性能等の必要要件と生産性との両立を実現する
ための研究開発は，今後のエクサスケール時代に向けてますます重要となる研究課題で
ある．高い生産性を実現する高水準プログラミング言語の研究として，以下の 2 つのア
プローチが考えられる．
1. 汎用並列言語の設計
2. ドメイン特化型言語(Domain Specific Language; DSL)の設計
1 つ目の汎用並列言語の設計は，分散データ構造，並列ループ，タスク生成などの原
始的な要素機能をベースに言語を設計していくアプローチである．例として，全ノード
からアクセス可能なグローバルメモリ空間を提供する PGAS 言語が挙げられる．これは
メッセージパッシング等による分散メモリ並列プログラミングの煩雑さを隠ぺいするも
のである．比較的原始的な要素の組み合わせであるため，後述の DSL よりも汎用的な処
理を記述することが可能である．しかしながら，汎用並列言語にはアルゴリズムの「全
体像(holistic view)」に関する組み込まれた知識がないため，アルゴリズムの作成および
73
性能チューニングはプログラマが負担することになる．本アプローチでは，適切に抽象
化された性能モデルをいかにプログラマに露出させることができるかが鍵となる．
2 つ目の DSL の設計は，あるドメインやアルゴリズムのための効率的な実装方式（領
域分割,負荷分散）を処理系に組み込むことで，各階層での個別のプログラミングを不要
にし，大規模並列プログラミングの負担を軽減することを目的とする．科学技術計算で
多用される解法で，計算機へのマッピング方法がある程度よく知られているもの（直交
格子差分法，有限要素法，粒子法など）を，統一的な並列性の記述から計算機の個々の
階層への適切な分割およびマッピングを行う言語処理系を作成するという実現可能性の
高いアプローチである．しかしながら，サポートされた定型的な処理からはみ出したプ
ログラムを記述することが出来ず，適用ドメインを広げるごとに，実質的には言語の再
設計，再実装が必要になる場合がある．
本章では，以上の研究課題に対して，アーキテクチャ，システムソフトウェアおよび
アプリケーションとの協調のもと解決するプログラミング環境の研究開発ロードマップ
を示す．
4.3.2 要素技術研究項目
(1) ヘテロジニアスアーキテクチャ
ポストペタスケールやエクサスケールの時代に利用可能な多種多様なアクセラレータを
使いこなすためには，各種アクセラレータを統一的に利用可能なプログラミングインタ
ーフェースや，自動最適化・自動チューニングに必要な情報を記述するためのインター
フェースの開発が求められる．また，現在主流のアクセラレータである GPU における課
題を考慮すると，異種複数のプロセッサへの処理の割り当てを自動化する研究アプロー
チも期待される．また，FPGA 等のプログラマブルロジックアクセラレータの利用が
HPC 分野で一般化するためには，ハードウェア構成を設計・記述することなく，アプリ
ケーションから利用可能となることが強く求められる．
2012～2014 年には，CUDA[4.3-1]などのそれぞれのアクセラレータに特化して設計さ
れてきたプログラミングインターフェースの共通化を行い，現在の OpenCL[4.3-2]等やそ
の拡張によって標準的なプログラミング環境が確立する必要がある．現在の
OpenACC[4.3-3]のように，汎用プログラミング言語（C++など）を使ってアクセラレー
タを利用するための研究も必要であり，それよって標準的なアプリケーション開発者に
よるアクセラレータ利用が現在よりも容易にする必要がある．
2015～2017 年には，共通のインターフェースが十分に普及していることが予想される．
ただし，インターフェースを共通化してもアクセラレータごとに求められる性能最適化
技法を共通化することは困難であるため，その作業を支援するための研究も必要である．
アプリケーション開発者の指示に基づく半自動最適化や自動チューニングに関する研究
開発を行い，性能最適化作業の労力が軽減することが必要である．
また，システム構成ごとに汎用プロセッサとアクセラレータの役割分担が変化するこ
とを考えると，その役割分担の自動化や半自動化を前提とし，システム構成を極力意識
させないプログラミングモデルの設計・開発が強く求められる．さらには，アクセラレ
ータが独自のメモリ空間を持っている場合には，汎用プロセッサとアクセラレータとの
間のデータ転送の自動化や高効率化も重要な研究課題である．
以上のようなアクセラレータの存在を意識したプログラミングモデルや言語に加えて，
アプリケーションドメイン特化等によって，アクセラレータの存在を意識することなく
特定の種類の処理を簡潔に記述するための研究のアプローチも考えられる．すなわち，
ヘテロジニアスアーキテクチャのシステムをきめ細かく制御するための低水準プログラ
74
ミング環境に加えて，標準的なアプリケーション開発者向けの生産性の高い高水準プロ
グラミング環境も確立することが必要である．
2018～2020 年には，現在とは全く異なるアーキテクチャに基づくアクセラレータが利
用可能となっている可能性がある．例えば，HPC 分野におけるプログラマブルロジック
アクセラレータの利用の可能性も模索され，OpenCL 等，他のアクセラレータと同様の
プログラミングインターフェースでプログラマブルロジックアクセラレータを利用する
ための研究開発が必要である．この時期には，消費電力などの制約から，レイテンシコ
アとスループットコアを混載するシステム構成が現在よりもさらに一般的になると予想
される．このため，各種コアの機能や性能が発展し，現在とは異なるアーキテクチャと
なったとしても，異種複数のコアを適切に使いこなすための標準プログラミングインタ
ーフェースの重要性は変わらず，むしろ増すものと考えられる．
表 4.3-1 ヘテロジニアスアーキテクチャに関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
研究開発内容
2012-2014
· アクセラレータ向けプログラミングインターフェースの共通化
2015-2017
· アプリケーション開発者の指示に基づく半自動最適化や自動チューニン
グによる性能最適化作業労力の軽減 19
· アクセラレータの存在を意識することなく，アクセラレータの計算能力
を利用できる高水準プログラミング環境の実現
2018-2020
· エクサスケールを構成するアクセラレータにおいて標準プログラミング
インターフェースを実現．
(2) 大規模並列性
3.3.3 節で述べたように，大規模な並列処理をサポートするプログラミング言語やその処
理系には，統一的な記述からあらゆる階層の並列性を抽出し，プラットフォームに適し
たマッピング・実行を行うことが求められる．このため，それらの要件を満足する生産
性の高い汎用並列言語や DSL，およびそれらの処理系を研究開発していくべきである.
また，大規模並列用に設計されたアルゴリズムのサポートとして，MPI などの SPMD
型の並列処理や，ドメイン固有言語で書かれたデータ並列処理を，複数タスク並列に実
行できる，SPMD 型並列に加えてタスク並列をサポートするフレームワークや，複数の
並列プログラムを組み合わせるスクリプト言語や Glue 言語などのアプローチが考えられ
る．
今後 2012 年から 2015 年頃まで関連する要素技術として，(1) DSL アプローチの拡大・
汎用化：これまでよりも広範なアルゴリズム領域に対する領域固有言語の設計および各
種アーキテクチャ上でのスケーラビリティ検証・デモンストレーションを進める．(2) 汎
用的高水準言語の発展：メモリ階層の抽象化，通信の最適化に焦点を当てつつ，汎用性
を持った言語の開発を進め，それらの各応用領域，様々なアーキテクチャ上でのデモン
ストレーションを行う．それにより生産性と性能のトレードオフに関する知見を蓄積す
る．もちろん領域固有型アプローチと汎用的高水準言語の研究は互いに孤立して進むの
ではなくお互いの知見を共有しつつ発展する．2015 年以降，ターゲットとしてエクサス
ケールマシンを明確に見据えた処理系の開発，普及・標準化を目指した言語の設計を行
う．
表 4.3-2 大規模並列性に関するロードマップ
75
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2014
研究開発内容
· DSL アプローチの拡大・汎用化 11
· 汎用的高水準言語の発展 1, 21
2015-2017
· エクサスケールマシンを明確に見据えた処理系の開発，普及・標準化を
目指した言語の設計
2018-2020
· エクサスケールマシンにおいて実証
(3) 複雑化するメモリアーキテクチャへの対応
3.2.3 章で述べたようにメモリウォールに起因する種々の課題を解決するために以下の
研究開発が必要である．まず，今後 2012 年～2017 年頃においては既に直面しているメ
モリの大規模分散化やヘテロジニアス化に対応するため，すでに研究開発が行われてい
る PGAS 言語（UPC[4.3-5], X10[4.3-6], Chapel [4.3-7], XMP [4.3-8]等）やヘテロジニアス
環境対応言語の実用化が必要である．具体的には，言語の標準化や優れたコンパイラ最
適化などの実装レベルでの洗練化，ライブラリの充実やアプリケーション分野との共同
研究などによる移行支援が挙げられる．また同時に，将来のキャッシュメモリの高階層
化等，さらなるハードウェアの複雑化に備えた言語の提案も行っていく必要がある．具
体的な言語設計は，その時にどのようなハードウェアアーキテクチャが提案されている
かにも依存するが，例えば，ノード内のメモリにおけるデータ配置やメモリの一部電力
供給停止などをシステム任せではなくプログラムで（より明示的に）操作できるように
する言語機構の開発が必要となる可能性がある．
2018 年～2020 年頃においては，上述の新しいハードウェア環境に対応して開発され
た言語の実用化を進める必要がある．
表 4.3-3 メモリアーキテクチャに関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2017
研究開発内容
· PGAS 言語やヘテロジニアス環境対応言語の実用化 21
· 高階層キャッシュやハードウェアの複雑化に備えた言語の提案
2018-2020
· エクサスケールマシンにおいてそれまでに開発された言語の実用化
(4) 耐故障
3.4.4 節で述べたように，アーキテクチャからアプリケーションまでの全システムスタッ
クが耐故障への積極的な対応が今後重要になることが想定される．しかしながら，これ
らの故障に対応するための記述をすべてアプリケーションプログラムが負うことになる
と，プログラム開発の生産性の低下につながりかねない．そこで，耐故障に関連する機
能をプログラミング言語レベルで記述するためのフレームワークを提供することが必要
となる．これによって故障に対処するためのオーバーヘッドを小さくして性能低下防ぎ
つつ，プログラム開発の生産性の低下も抑えることができる．
今後，2012 年～2015 年頃までは，以下に挙げるような技術課題の解決が必要となる．
第一にシステムソフトウェアと協調した故障モデルの表現が挙げられる．まず，シス
テムソフトウェアが故障個所を特定するためにはどのようなイベントを故障とみなすの
かをアプリケーションから指定できるようにすべきである．
76
第二にチェックポインティングと故障からの復旧手法が挙げられる．故障情報を一定
のローカルな範囲（ノード内，複数ノードからなるグループなど）にしか伝播させず，
そのローカルな範囲で故障から復旧し，範囲外へ故障の影響を与えずオーバーヘッドを
少なくする故障の囲い込みが必要となる．このようなローカルな復旧のため，故障個所
に応じてロールバック対象をプログラミング言語レベルで指定する手段が必要となる．
第三にアプリケーションレベル耐故障性実現を支援するインターフェースの研究開発
も必要である．システムソフトウェアにより完全に透過的にチェックポイント等による
耐故障性が実現される場合はアプリケーション側の耐故障実現のためのプログラミング
は必須ではないが，今後のエクサスケールシステムに向けては下位のシステムスタック
のみによる対応は限界に近づくことが想定される．従ってアプリケーションレベルにお
いてもチェックポイント個所，チェックポイント時のバックアップ対象，複製すべき対
象，故障からの復旧対象（MPI の全プロセス，MPI の一部のプロセス，ノード内のスレ
ッドなど），復旧方法（故障ノードのマイグレーション，ノード内の遊休コアの利用な
ど）などの指定をすることにより，システムソフトウェアと連携した高効率な耐故障性
が重要になると考えられる．そのようなアプリケーションレベルの耐故障性記述を支援
するプログラミングインターフェースが必要である．
第四にプログラミングモデルに応じた耐故障性のサポートが挙げられる．SPMD に比
べ，Master-Worker モデルや MapReduce モデルなどは，耐故障性をサポートしやすい．
これらのモデルでは，タスクレベルの再実行を言語レベルでサポートすることが望まし
い．また，先天的耐故障対応アルゴリズム(Fault Oblivious Algorithm)を言語レベルでのサ
ポートすることも考えられる．
2016 年～2020 年頃には，関連技術の進展による耐故障性の進展，具体的には故障予測
を利用したマイグレーションが挙げられる．故障予測精度の向上により，故障前にマイ
グレーションすることでオーバーヘッドを削減することが見込まれる．言語レイヤで故
障予測情報の取得，それに基づくマイグレーションを実行できることが必要となる．
表 4.3-4 耐故障に関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2015
研究開発内容
· 共通インターフェースによる故障モデルの表現 10
· 故障の囲い込みを支援するプログラミングインターフェース
· チェックポイント，復旧等の耐故障支援記述インターフェース 10,23
· 先天的耐故障対応アルゴリズムの記述支援プログラミングモデル
2016-2020
· エクサスケールシステムにおける実証
· 故障予測を利用したマイグレーション
(5) 電力
消費電力はポストペタスケール／エクサスケール計算の重大な制約であり，ハードウェ
アに関する新しい装置や技術だけでなく，ハードウェアとソフトウェアが協調して電力
制約下での性能最大化を実現する必要がある．このためにはまずは情報取得とハードウ
ェアの各種電力つまみに関する電力設定に関する標準インターフェースの整備を進め，
それに基づいたより積極的な省電力化のための研究開発が必要である．まずはオペレー
ティングシステムやミドルウェアなどのシステムソフトウェアが主体となり，標準イン
ターフェースを利用して，さまざまな時間的・空間的スケールで電力制約を満たすため
の電力予算の配分と電力制約下での性能最大化を行うと考えられる．関連技術となるハ
ードウェア・オペレーティングシステム間インターフェース仕様としては ACPI 仕様
77
（執筆時点では Revision 4.0a[4.3-4]）が知られており，Revision 4.0 （2009 年）から加わ
った消費電力情報取得や消費電力ハードウェア上限設定の仕様は今後の標準インターフ
ェースのベースとなる可能性が高い．
2014 年から 2015 年頃までにシステムソフトウェアが持つさまざまな時間的・空間的
スケールでの電力制約や実際に消費した電力/エネルギーに関する情報を，アプリケーシ
ョンが取得するための API の整備も必要である．また，電力に関するパラメータ設定の
ための API も整備される必要がある．電力標準 API の整備により，電力を考慮したプロ
グラミングモデルが提供可能となる．このとき，複数のアプリケーションがシステム全
体やノード等を分割使用する場合は，アプリケーション毎の消費量をその内訳（計算コ
アやメモリなどの各部での消費）とともに取得できるとよい．
アプリケーションから事前に次のフェーズなどの情報（例: メモリインテンシブに切
り替わること）をシステムソフトウェアに提供可能とすることで，フェーズの切り替わ
りに素早く対応できる．2015 年頃までには API の直接利用，注釈の利用，コンパイラが
解析した結果の利用，などによって情報を伝えるプログラミング・コンパイル技術が考
えられる．関連技術として，国内で策定されたマルチコア向け API [4.3-9]で低消費電力
制御 API が提供され，コンパイル技術が開発されているが，ポストペタスケール／エク
サスケール計算では，全体の電力制約やシステムソフトウェアの介在といった点の考慮
が必要となる．
消費電力の削減や消費電力あたりの性能最大化のためには，エラーが増加しない低電
圧制御や，温度（熱）制約を満たすクロック周波数制御を，フェイルセーフに行うこと
が考えられ，結果として各コアや各ノードの性能ばらつきの拡大を許容するような電力
制御も考えられる．このようなアグレッシブな電力制御を行うことがアーキテクチャお
よびシステムソフトウェアの技術の発展により実現可能になった場合には，それによる
性能ばらつきの問題を予測や負荷分散により軽減するプログラミング・コンパイル技術
が重要となる．
2016 年から 2018 年頃にかけては，消費電力の削減を目的とした不揮発性メモリ
(NVRAM)のような新しい省電力デバイスを効果的に利用するプログラミング／コンパイ
ル技術を開発されるべきである．特に，不揮発性メモリは物理メモリが占める電力消費
の割合は決して低くないこともからも重要である．その際メモリやディスクのキャッシ
ュや仮想記憶のように意識しなくてもプログラムは動作するが，意識あるいは忘却して
よいような形で局所性を高めることで性能向上するという場合や，性質の異なるメモリ
が異なる部分アドレス空間に存在するように見せるという場合が考えられる．
さらに，プログラミング／コンパイル技術から電力制約問題への最も重要なアプロー
チの一つである電力制約下において性能最適な計算方法を選択する技術の開発を進める
必要がある．そのためには，各選択肢において消費電力あるいは性能がどうなるのかを
予測するモデルが必要となる．選択可能な項目としては，プログラムにおける各種パラ
メータをはじめ，データの移動・保持と計算のトレードオフ，CPU とアクセラレータの
利用コア数や電力予算比率等がある．さらに動的に変化する電力制約に追従して計算方
法を選択し直すことができるアプリケーションを作成するためのプログラミング／コン
パイル技術も重要となる．
表 4.3-5 電力に関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2015
研究開発内容
· 電力情報取得・設定のための標準 API の整備 4
· 省電力のためのアプリケーション情報伝達のための標準 API の整備 4
2016-2020
· 性能ばらつきを軽減するプログラミング・コンパイル技術の整備
· 不揮発性メモリを用いた省電力化を支援するプログラミング技術の整備
78
· 電力制約に応じた計算方法選択方式
(6) 生産性（ツール）
エクサスケールシステムは非常に大規模かつ複雑な構成であるため，その上で高い性能
を発揮するアプリケーションを効率的に開発するためには，プログラムのデバッグ作業
および性能チューニングを支援するツールが重要である．エクサスケールシステムの並
列数は 10 億のオーダと予測されているため，現状のツールではエクサスケールシステム
に対応することはできない．そのため，ログデータの削減および可視化についてさらな
る研究が必要である．
2012 年から 2014 年頃までは，少ない負荷でログデータを収集する研究，膨大なログ
データの中から有用なデータを自動抽出するデータマイニングに関する研究などが重要
になると考えられる．また，生産性向上の点から既存資産を活用したいという要求があ
る．性能可搬性を高めるため，数値計算ライブラリ等の自動チューニングの研究に加え，
新しいハードウェアに移行することを支援するツールの開発も並行して行う必要がある．
2015 年頃からは 100 ペタフロップス級のポストペタスケールシステムが開発され，エ
クサスケールシステムに向けて，実機と実アプリケーションを利用した研究が進むと考
えられる．また，エクサスケールシステムで動作する OS，ミドルウェア，数値計算ラ
イブラリ，プログラミング言語などのプロトタイプが利用可能になると考えられる．エ
クサスケールシステムでは，システムの大規模化によりハードウェアの MTBF が非常に
短くなるためアプリケーションが実行途中でエラー終了する，OS ジッタなどが原因で性
能が期待していたよりも低くなる，といったアプリケーション以外の不具合も考慮する
必要がある．これらの問題を解決するために，ログデータを取得するためのインターフ
ェースをレイヤ毎に定義し，そこから得られたログデータを用いて問題箇所を自動抽出
する，もしくはそれぞれのログデータを統合して可視化するといった，不具合の原因特
定をサポートするツールの研究が行われると考えられる．また，情報取得のためのイン
ターフェースを定義することにより，デバッグ作業および性能チューニングのためのツ
ールの可搬性を向上させることも必要である．
2018～2020 年以降は，ポストペタスケールマシンで得た知見，例えば性能のボトルネ
ックになるパターンなどをデータベース化しておき，それを利用してエクサスケールア
プリケーションのデバッグ作業および性能チューニングを半自動化させることで，生産
性を向上させるなどの研究が必要である．
表 4.3-6 生産性・ツールに関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2014
研究開発内容
· デバッグ・性能チューニング支援のためのスケーラブルかつ低オーバー
ヘッドデータ収集
· 膨大なデータから有用な情報を抽出するデータマイニング技術
· 性能可搬性を高めるための自動チューニング 2, 12
· 異なるハードウェアへの移行支援ツール 19
2015-2017
· ポストペタスケールマシン上でのツールの開発・評価
· エクサスケールマシンにおけるデバッグ・性能解析のためのツールの開
発
2018-2020
· ポストペタスケールマシンにおいて得た知見をもとに，デバッグ作業お
よび性能チューニングの半自動化
79
(7) 大規模データ処理
エクサスケールシステム上での大規模データ処理のためのプログラミングモデルにおい
ては，局所性を考慮した大規模データ処理アプリケーションを簡便に記述可能にする高
い生産性が求められる．
まず，2012 年から 2014 年頃までには現状のペタスケールシステムにおいて
MapReduce[4.3-10]等の局所性最適化に適したプログラミングモデルの実現が必要である．
まずはレイテンシコア上において実現し，さらにスループットコアを共用したヘテロジ
ニアスアーキテクチャに拡張する必要がある．同時にそのようなプログラミングモデル
を実際の大規模データ処理アプリケーションに適用しその有効性の評価検討を行うべき
である．
2015 年から 2018 年ころにはポストペタスケールシステムが利用可能になる時期であ
り，大規模データ処理用プログラミングモデルについてもそのような大規模環境におい
て特にスケーラビリティの評価，改善やエクサスケールに向けた新しいシステムソフト
ウェアを活用したプログラミングの評価が必要である．
2018 年以降はポストペタスケールシステムにおいて開発されたプログラミングモデル
をさらにエクサスケールシステム上で実現し，実際の大規模データ処理アプリケーショ
ンの高い実行効率および生産性を達成可能であることの実証が求められる．
表 4.3-7 大規模データ処理に関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
2012-2014
研究開発内容
· 現状のペタスケールシステムにおいて MapReduce 等の局所性最適化に適
したプログラミングモデルの実現 13
· 実際の大規模データ処理アプリケーションに適用しその有効性の評価検
討 16
2015-2017
· ポストペタスケールシステムを用いて大規模データ処理用プログラミン
グモデルについて特にスケーラビリティの評価，改善 16
· エクサスケールに向けた新しいシステムソフトウェアを活用したプログ
ラミングの評価
2018-2020
· ポストペタスケールシステムにおいて開発されたプログラミングモデル
をさらにエクサスケールシステム上で実現
· 実際の大規模データ処理アプリケーションの高い実行効率および生産性
を達成可能であることの実証
4.3.3 エクサスケールプログラミング環境例
上述の基礎研究を進展させることによりポストペタスケールおよびエクサスケールシス
テムにおけるプログラミング上の種々の課題の解決が期待できる．例えば，現状のアク
セラレータ利用技術では個々のアーキテクチャに強く依存した可搬性に欠けたプログラ
ミングが必要だが，上述の異種アーキテクチャ上の統一プログラミングインターフェー
スの整備や性能最適化のための自動チューニング手法の開発により可搬性，生産性の向
上が期待できる．同様に大規模並列性や深いメモリ階層を自然にかつ簡便に扱える記述
80
法や，耐故障性，低電力化のためのプログラミングを支援する記述法に関する基礎研究
を進展させ，今後のアーキテクチャに対応したプログラミング環境構築のための要素技
術を開発していく必要がある．
実システムにおいてアプリケーションプログラマが上記要素技術を簡便に利用可能に
するためには，個々の基礎研究に加えてそれらを統合したプログラミング環境を整備す
る必要がある．プログラミング環境として統合する方針に関しては，いくつかのアプロ
ーチが考えられる．以下，想定される統合プログラミング環境を 2 つ例示する．
(1) アプリケーション移行支援への応用
本白書でも随所で強調されているとおり，エクサスケール時代の高性能計算システムで
は超並列化や複合化がより一層進行し，現在よりもシステム構成がさらに複雑化するこ
とが予想される．一方，現在一般的に開発・利用されているアプリケーションコードは，
そのような複雑なシステム構成を意識して記述されていない．したがって，現在のコー
ドそのままの状態では，エクサスケールシステム上での高い実効性能の達成は期待でき
ない．しかし，システムの世代が変わるたびにアプリケーションやライブラリなどのソ
フトウェア開発をやり直すことは非現実的であるため，既存のコードを何らかの方法で
新しいシステム向けに修正していく方法論が求められる．
このような動機から，既存のコードを出発点として新しいシステム向けのコードに段
階的に移行することを考え，その作業を支援するために上述の種々の要素技術を利用す
る研究開発が想定される．例えば，高度に最適化された数値演算ライブラリやランタイ
ムシステム，コンパイラによる自動並列化・自動ベクトル化，および自動チューニング
技術等でシステムの複雑さを可能な限り隠ぺいすることを前提とし，それらの技術では
隠ぺいしきれない差異のみをソフトウェア開発者がコード修正によって埋めることが想
定される．このためには，MPI や OpenMP，CUDA/OpenCL などの主要 API においては，
現在の仕様から段階的に改善することでエクサスケール時代の問題解決を図るべきであ
る．
アプリケーション開発者によるコード修正においても，比較的安全かつ容易にコード
を修正できるように様々なアプローチで支援ツールを提供する必要がある．例えば，コ
ンパイラ指示行や高度なエディタ機能（リファクタリング等）を提供することが考えら
れる．これらの技術は個々で検討するだけでなく，上記の隠ぺい技術と併せて統合され
た一つの環境として開発していくべきである．
しかし，既存のアプリケーションコードを出発点とし，新規開発を前提としないアプ
ローチであることから課題や制約が数多く残されており，それを解決する研究開発が今
後求められている．
·
·
ソフトウェア進化の指針の確立: コードを整理・改善することで既存のソフトウェ
アを進化させることを考える場合，既存のコードをどのような基準で見直し，どの
ような方針で改善していくのかを示す指針が必要である．そのような指針を計算科
学者と計算機科学者の協働で体系化・明文化し共有する必要があるが，これまでに
そのような共通認識が確立されているとは言い難い．
コードの可読性・保守性と高性能の両立: 可読性や保守性の高いコード開発の方向
性と，高性能を実現するコード開発の方向性は必ずしも一致しない．むしろ，高性
能化のために特定のシステム依存のコーディングが求められ，可読性や保守性が低
下することも多い．このため，可読性・保守性と高性能の両立が可能なプログラミ
ング開発の方法論やその支援技術の確立が必要である．
ソフトウェアの進化を支援するためには，実用的な大規模アプリケーションを新世代の
システム向けに修正していく作業において頻出するパターンをデータベース化し，それ
を一般化することによってその効果的な支援方法を検討する必要がある．そのような現
状分析と一般化を目指す研究アプローチと並行して，ソフトウェア進化の作業コストを
81
軽減するためにシステムの複雑さを隠ぺいする抽象化技術の研究開発が必要である．そ
のような抽象化技術を効果的に使うためのコード修正/再構成の指針を整備し，その指針
に基づく既存アプリケーションの新世代システムへの段階的移行を支援する．
表 4.3-8 アプリケーション移行支援に関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
研究開発内容
2012-2013
· 既存アプリケーションの現状分析により，エクサスケールシステム向け
に必要となる移行作業の検討・明確化 19
2015-2018
· 移行作業を支援する技術を設計し，ポストペタシステムで支援技術の有
効性を予備的に実証 19
2018-2020
· システム構成の変遷に対応しやすいプログラム構成法およびアルゴリズ
ム設計法の確立
· 同設計法に基づくソフトウェア開発要素技術の共通基盤としての提供
し，エクサスケール時代の複雑なシステムへのコードの移植を支援
· システム変遷に伴う共通基盤の拡張およびそれの支援
(2) アプリケーションドメイン特化型フレームワーク
プログラミング環境の例として，特定のアプリケーションドメインに特化した高い抽象
度を持った専用フレームワークが考えられる．これは特定のドメイン向けにプログラミ
ング言語やライブラリ，ミドルウェア等のソフトウェアスタックをカスタマイズして提
供し，それによりアプリケーションの簡潔な記述およびソフトウェアレイヤをまたがっ
た最適化やアプリケーションドメイン固有の最適化手法の導入による高い実行効率を狙
ったものである．ソフトウェアスタックの主なカスタマイズ手法としては，コンパイラ
によるコード生成，テンプレートメタプログラミング，ソースコード変換等の生成的な
手法がある．これによりアプリケーションプログラマに透過的に自動チューニング等の
各種最適化技術や耐故障技術を実現する．ドメイン特化型フレームワークは汎用性に欠
けるものの高い生産性と性能の両立が期待でき，将来有望なアプローチの一つと言える．
本節ではドメイン特化型フレームワークにおけるプログラミング技術について，特に
フレームワーク開発方法論の確立に向けたロードマップを述べる．関連する技術として
は 4.4.3 節で述べる数値計算ミドルウェアが存在するが，数値計算ミドルウェアでは単体
フレームワークの開発が主体であるのに対して，本ロードマップではそれを構成するプ
ログラミング技術の基礎研究および実証が主目的であることが主な違いである．
今日スーパーコンピュータ上で用いられている計算科学アプリケーションは多岐に渡
り，それらをサポートするためには多くの種類のフレームワークを開発する必要がある．
一部のアプリケーションドメインについてはこれまでもフレームワークの開発がされて
きたが，その開発方法論は依然として確立されておらず，フレームワーク開発のコスト
が大きな問題となっている．より簡便に高品質フレームワークを構成するためのソフト
ウェア工学的な研究開発，特にそれを支援するソフトウェアコンポーネントの充実が必
要である．フレームワークにはヘテロジニアスアーキテクチャにおけるロードバランス
や自動チューニングなど本節で述べた各種要素技術を共通して備えるべきだが，再利用
性を有したフレームワークコンポーネントとしてそれらの特性を実現することによって
新規フレームワークの開発コストの削減が期待できる．また，対象アプリケーションド
メインの記述性向上のために専用プログラミング言語の有効性が確認されているが，そ
のようなドメイン特化型言語（DSL）の開発を支援するためのコンパイラ技術に関する
研究も必要である．
82
このようなフレームワーク開発支援のためのプログラミング技術の基礎研究と共にそ
れらの実証が必要である．実証のためにはまず計算科学分野との密な協力に基づき，性
能を担保可能なアプリケーションドメインの設定を行う．これは，今日の大規模計算科
学アプリケーションを計算機科学的に抽象化する作業であり，アプリケーションドメイ
ンに対する理解・学習が求められる．さらに，設定したドメインに対して実際にそのフ
レームワークを設計し，具体的なアプリケーションを用いた実証評価を進める．アプリ
ケーションの現時点における並列化・最適化の如何に関わらず将来の大規模計算環境を
有効に活用していくためにはその都度人手による最適化が必要だが，その人手による最
適化に対してフレームワークへの移植コストが十分低くかつそれと同等の性能を達成で
きなくてはならない．そのためには特に既存の高度に最適化された大規模アプリケーシ
ョンを参照実装として用い，それと同等の性能を高い生産性をもってフレームワークに
より実現可能であることを示すことが特に重要である．
以下にドメイン特化型フレームワーク研究開発のロードマップ線表を示す．まず，
2012 年から 2013 年の 2 年間で予備調査として各種要素技術をアプリケーションプログ
ラマに透過的に実現するフレームワークの設計および開発を行う．要素技術としては
4.3.1 節で述べたものを中心に，またシステムソフトウェアおよび数値計算ライブラリと
いったソフトウェア階層における技術開発を積極的に取り込むべきであり，システム階
層をまたがる協調設計が必要である．2014 年から 2017 年頃にかけては，100PF 級のスー
パーコンピュータにおいて，性能と生産性を達成するための課題の洗い出しおよびそれ
の解決を行い，2018 年から 2020 年頃のエクサスケールマシンにおけるフレームワーク
開発方法論の確立につなげる．また，これらの一連の研究開発ロードマップにおいて開
発されたフレームワークおよび周辺ソフトウェアは迅速にオープンソースとして提供さ
れるべきであり，フレームワークの利用およびそれ自体の開発のためのコミュニティの
形成を目指すべきである．
表 4.3-9 アプリケーションドメイン特化型フレームワークに関するロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
研究開発内容
2012-2013
· エクサスケールコンピューティングに向けた各種既存要素技術のフレー
ムワークとしての設計および実装 11,18
2014-2017
· フレームワーク開発方法論の 100PF 級マシンにおける予備的な実証 11,18
· エクサスケールに向けた要素技術の進展を受け，そららのフレームワー
クへの取り込み
2018-2020
· エクサスケールマシンにおける実証
4.3.4 まとめ
エクサスケール時代に向けて HPC システムの構成は今後さらに複雑化し，性能が最重要
視される HPC のアプリケーション開発においてはシステム構成を意識することが避けら
れないことから，プログラミングの高度化やアプリケーション開発の生産性の低下が懸
念されている．さらには，電力や障害対策などの問題もより一層深刻化することが予想
されている．本節の前半では，それらの課題に対する現在の取組みと今後の研究ロード
マップを述べた．
また，各課題を解決するための要素技術の研究開発に加えて，それらの技術を利用す
るアプリケーションを開発するためのプログラミング環境も必要である．このため，本
83
節の後半では，アプローチの異なる想定プログラミング環境を 2 つ例示し，それぞれの
研究ロードマップを示した．
2018 年頃にエクサスケールのシステムが稼働することを想定し，そのシステム向けの
プログラム開発に資する技術を確立するためには，時期的に図 4.3-1 に示すような研究
ロードマップに則って研究開発を進めていく必要がある．特に初めの 2 年間において，
要素技術の洗い出しおよびその予備評価を行い，それらの移行支援技術およびドメイン
特化型フレームワークへの応用について最初の評価を行うべきである．その結果に基づ
き 2014 年頃には最初のプロトタイプをリリースするべきである．同プロトタイプは
2015 年頃に想定されている 100PFLOPS 級のマシンにおいて実証することを目的とした
ものであり，またそこで新たに得られる知見等を基に 2016 年頃にはプロトタイプの改良
版を公開するべきである．同様に要素技術についてもエクサスケールに向けた技術開発
を続け，2018 年にはプロダクトとしてリリースするべきである．このように，プログラ
ミングに関する成果はソフトウェアとして早期に公開し，継続的に機能改善および拡張
を施す体制が重要である．また，2018 年にプロダクトをリリースした後も，エクサスケ
ールシステム上で得られる知見を基にした改善を続け，その後も継続的にソフトウェア
の改良・拡張を行う必要がある．
2012 2013 連携
&deploy 2014 2015 プロトタイプ Arch.
SIM
v1.0
方式検討 技術開発 1. 移行支援 方式検討 試作＆評価 2. ドメイン
化
方式検討 試作＆評価 特
要素技術 2016 2017 2018 2019 リリースv1.0
Arch.プロトタイプ
ES v2.0
普及活動・整備・保守 実証実験・改良・拡張 要素技術統合 要素技術統合 2020 リリースv2.0
ユーザへ提供
外部から提供
実証実験・改良 機能整備 実証実験・改良 機能整備 図 4.3-1 プログラミング分野のロードマップ
プログラミング言語やモデルの研究開発においては，それらの開発体制の確立と普及
活動も極めて重要である．
HPC アプリケーションは長期間に渡って利用・メンテナンスされるため，開発に用い
られる言語は最低 10 年間の継続的な開発やサポートが保証されることが望ましい．国内
における例では，文部科学省の支援を受け開発されている並列言語 XcalableMP の仕様策
定および開発は，多くの大学，研究機関，企業で構成された委員会により行われている．
複数の機関，特に企業の協力を得ることにより，中長期的な開発や保守管理を期待でき
る．
普及活動という観点では，開発されたプログラミング言語を Web で公開・配布するこ
とはもちろんのこと，実用的な大規模アプリケーションが開発可能であることを実証す
ることが効果的である．さらには，国際的な標準化活動や International Exascale Software
Project (IESP) ，また他の有用なソフトウェアとの連携機能を実現することにより，世界
規模でのコミュニティの形成を進める必要がある，マニュアル・チュートリアルなどの
整備や，メーリングリスト・プログラミング講習会・ワークショップの開催などによる
コミュニティ構築も普及のために重要である．
以上のように研究開発および普及活動を中長期的に継続するためには，安定的な予算
や人的資源に基づく持続可能な研究体制の確立が必要不可欠であると言える．我が国で
もそのような研究体制を一刻も早く確立し，世界標準として広く受け入れられる優れた
プログラミング言語・モデルを数多く創出することを目指すべきである．そのような研
究と並行して，自動並列化・自動ベクトル化といったコンパイラ技術にもさらなる進展
を期待しなければならない．その結果として計算科学アプリケーション開発の生産性を
飛躍的に向上させ，我が国の学術界および産業界における優位性を維持・発展させるた
めの礎となることが期待される．
84
4.3.5 参考文献
[4.3-1] J. Nickolls, I. Buck, M. Garland, and K Skadron, "Scalable Parallel Programming with
CUDA," ACM Queue, Vol. 6, Issue 2, March/April 2008.
[4.3-2] OpenCL, http://www.khronos.org/opencl/.
[4.3-3] OpenACC, http://www.openacc-standard.org/.
[4.3-4] Hewlett-Packard, Intel, Microsoft, Phoenix, Toshiba: Advanced Configuration andPower
Interface (ACPI)Specification, Revision 4.0a, http://www.acpi.info/, 2010.
[4.3-5] The UPC Consortium, "UPC Language Specification (V 1.2)," June 2005.
[4.3-6] P. Charles, C. Grothoff, V. Saraswat, C. Donawa, A Kielstra, K. Ebcioglu, C. von Praun,
V. Sarkar, "X10: an object-oriented approach to non-uniform cluster computing,"
Proceedings of the 20th annual ACM SIGPLAN conference on Object oriented
programming, systems, languages, and applications, October 2005.
[4.3-7] Cray Inc, Chapel Language Specification Version 0.82, 2012.
[4.3-8] 李珍泌，朴泰祐，佐藤三久. "分散メモリ向け並列言語 XcalableMP コンパイラの
実装と性能評価," 情報処理学会論文誌コンピューティングシステム, Vol.3, No.3,
pp. 153-165, 2010.
[4.3-9] NEDO「リアルタイム情報家電用マルチコア技術の研究開発」
[4.3-10] Jeffrey Dean, Sanjay Ghemawat, "MapReduce:Simplified Data Processing on Large
Clusters,” OSDI'04, 2004.
4.4 数値計算ライブラリ
4.4.1 はじめに
本節は，エクサスケールシステムにおいて必要とされる技術について数値計算ライブラ
リの観点からまとめたものである．以下に示す観点ごとに挑戦すべき技術項目とロード
マップを記載した．
·
·
·
数値計算ライブラリに必要な技術，および数値計算ライブラリで使われる数値計算
アルゴリズムの観点（数値計算ライブラリ分野）
数値シミュレーションを行うためのミドルウェア，および分野を限定したプログラ
ミングで有効となるフレームワーク（数値計算ミドルウェア分野）
数値計算ライブラリ，および数値計算ミドルウェアで必要となる処理に対する自動
性能チューニング（数値計算ライブラリのための自動チューニング分野）
上記の分野において，重要となる技術項目を主項目とした．主項目を達成するに当た
り，必要となる細分化した研究開発項目を副項目とした．
副項目は，5 年後に達成すべき技術項目を副項目（短期）とした．達成するのに 5 年
以上必要とする技術項目，もしくは，現在，基礎研究すら開始されていない項目を副項
目（長期）とした．
主項目と副項目は，エクサフロップスを達成するために，必要な技術となる必要性の
観点，および，技術的に重要となる重要性の観点から，以下のランキングをつけてキー
ワードを抽出した．
☆，★，★★，★★★（→重要度が高い）
85
エクサフロップスを達成するために，必要であるが新規技術開発として重要ではない
技術（たとえば，既存技術を適用することで実現されるもの），および，重要であるが
必要でない技術（たとえば，生産性に関わる技術の一部）が存在する．
2011 年度の研究開発の進捗の度合いについて，以下のフェーズを記載した．
·
·
·
·
フェーズ I ：これから基礎研究を行うもの
フェーズ II ：基礎研究が進行中のもの
フェーズ III ：プロトタイプが進行中のもの
フェーズ IV ：もうすぐ実用化の目途がつくもの
主項目の技術においてエクサフロップス達成のために，従来技術を適用することで展
開できると思われる事項を＜既存技術＞とした．また，従来技術を単純に適用し展開す
るだけでは実現できない事項は＜革新技術＞とした．
4.4.2 数値計算ライブラリ
(1) はじめに
数値計算ライブラリは，科学技術アプリケーションプログラムにおいて共通に使われる
数値計算プログラムをライブラリの形にまとめたものである．数値計算ライブラリには
·
·
·
·
線形方程式
固有値問題
高速フーリエ変換
乱数
などのルーチンが含まれている．
現在，大規模数値シミュレーションを行う際には，数値計算ライブラリの性能が実行
時間に大きく影響する．したがって，エクサフロップス級マシンにおいて高い実行効率
を達成できる数値計算ライブラリを実現することは重要である．
エクサフロップス環境のための数値計算ライブラリが実現する機能としては以下が挙
げられる．
·
·
アプリケーション開発者および利用者からエクサフロップス級マシンの複雑なシス
テム構成が見えないように抽象化されたインターフェースを提供すること．
エクサフロップス級マシンの高い性能をできるだけ引き出すようなアルゴリズムお
よび実装手法を用いること．
本節では，エクサフロップス級マシンにおける数値計算ライブラリを実現する上で必
要な技術項目について述べる．
(1)
技術マップ
図 4.4-1 に，数値計算ライブラリに関する技術マップを示す．図 4.4-1 から分かるように，
1990 年代後半から分散メモリ型並列計算機向けの数値計算ライブラリの研究開発が始ま
っている[4.4-1]．さらに，2005 年以降は GPU よびマルチコアアーキテクチャ向けの数値
計算ライブラリの研究開発が行われている．また，これらの数値計算ライブラリには自
動チューニング機構が備わっているものも多い[4.4-2]．
86
数値計算ライブラリ技術マップ
アプリケーション
1995年 PETSc
http://www.mcs.anl.gov/petsc/petsc-as/
疎行列ライブラリ
1995年 ScaLAPACK
http://www.netlib.org/scalapack/
分散メモリ型並列計算機向けの
線形計算ライブラリ
数値計算
ミドルウェア
数値計算
ライブラリ
2007年 Lis
http://www.ssisc.org/lis/
並列反復解法ライブラリ
2005年 OSKI
http://bebop.cs.berkeley.edu/oski/
自動チューニング機能付き疎行列ライブラリ
1996年 ATLAS
http://math-atlas.sourceforge.net/
自動チューニング機能付き
基本線形計算ライブラリ
2007年 PLASMA
http://icl.cs.utk.edu/plasma/
マルチコアアーキテクチャ向けの
並列線形計算ライブラリ
1995年 PHiPAC
http://www.icsi.berkeley.edu/~bilmes/phipac/
自動チューニングを用いた高速な行列積
2008年 MAGMA
http://icl.cs.utk.edu/magma/
GPUおよびマルチコアアーキテクチャ
向けの基本線形計算ライブラリ
2000年 SPIRAL
http://www.spiral.net/
自動チューニング機能付きFFTコードジェネレータ
1997年 FFTW
http://www.fftw.org/
自動チューニング機能付きFFTライブラリ
2006年 P3DFFT
http://code.google.com/p/p3dfft/
高並列環境に向けたFFTライブラリ
2002年 FFTE
http://www.ffte.jp/
並列FFTライブラリ
システムソフトウェア
年
図 4.4-1 数値計算ライブラリの技術マップ
(2)
技術項目と優先度
本節では，今後 5～10 年で挑戦すべき技術項目と達成時期について述べる．表 4.4-1 に数
値計算ライブラリ分野の技術項目のうち，主項目を示す．
主項目は以下のようにまとめることができる．
3. 通信最適化
· Allgather や Allreduce 等の集合通信を避けたライブラリ（アルゴリズムの変更が
必要）
· 通信（回数またはデータ転送量，またはその両方）を最小限にしたアルゴリズム
· 通信量を増やしてでもレイテンシの影響を削減し，通信時間を削減する通信方式
4. 演算量を増やしてでも通信量やメモリアクセス回数を削減するアルゴリズム
· データは他のノードから持ってくるのではなく，自ノードで計算できるものは計
算する．
5. 高精度計算
· 高精度計算の CPU／GPU 最適化
6. 混合精度演算・精度保証計算
· 単精度演算や倍精度演算と 3 倍精度・4 倍精度演算を組み合わせる．
· 区間演算を用いることにより，精度を保証する．
7. 精度をユーザが確認する方法
· verbose モード，逐次実行・演算順序保証実行モード
8. フォールトトレラント機能
· システムソフトウェアのレベルではなく，数値計算ライブラリにチェックポイン
ト／リスタートの機能を持たせる．
· 耐故障性の必要性の調査
9. ライブラリ利用形態に関する検討
· 数値計算ライブラリがどのような階層で使用されるか，されるべきかの再検討
10. 適切な HW を選択するための情報を得る仕組み
87
·
電力効率最大 HW がどれかを知るためには，電力情報をうまく利用できる仕組み
(API)が必要．
11. 非均質プロセッサ環境に対応するライブラリ
· マルチコア，メニーコア，GPU への対応
· ハイブリッド並列処理対応
12. 生産性の高いアプリケーション記述用言語（フレームワーク）
· ライブラリ自体をどのような言語で記述するのかについての検討
主項目から派生する副項目を表 4.4-2 に示す．
表 4.4-1 数値計算ライブラリ分野の技術項目（主項目）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2016 年
非均質プロセッサ対応
★★★
★★★
フェーズ II
2014 年
高精度計算
★★
★★
フェーズ I
2016 年
通信最適化
★★★
★★★
フェーズ II
2014 年
演算量を増やしてでも通信量やメモ
リアクセス回数を削減するアルゴリ
ズム
★★★
★★★
フェーズ II
2018 年
混合精度演算・精度保証計算
★★
★★
フェーズ II
2020 年
フォールトトレラント機能
★★★
★★★
フェーズ I
表 4.4-2 数値計算ライブラリ分野の技術項目（副項目）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2014 年
ハイブリッド並列処理対応
★★★
★★★
フェーズ II
2014 年
Allgather や Allreduce 等の集合通
信を避けたライブラリ
★★★
★★★
フェーズ II
2014 年
混合演算・精度保証演算による
数値計算安定化
★★
★★
フェーズ II
2014 年
耐故障性の必要性の調査
★★★
★★★
フェーズ II
2014 年
高精度計算の CPU/GPU 最適化
★★
★★
フェーズ I
2014 年
生産性の高いアプリケーション
記述用言語（フレームワーク）
★★
★★
フェーズ II
2016 年
適切な HW を選択するための情
報を得る仕組みの開発
★★
★★
フェーズ I
(3)
まとめ
前節の技術項目のうち主項目を達成するための数値計算ライブラリ分野のロードマップ
を，以下にまとめる．初めの 2 年間は要素技術検討期間とし，アプリケーションプログ
ラムの非均質プロセッサへの対応，高精度計算の最適化，および，通信時間を削減する
通信方式の調査を行う．
88
表 4.4-3 数値計算ライブラリ分野のロードマップ
注：研究開発内容に関連する既存研究について付録１にまとめ、その参照番号を記載
達成時期
研究開発内容
2012-2013
10 ペタ級のスパコンである京コンピュータが供用開始になると共に，大学
センター群等のぺタスケールマシンが運用開始となるため，それらのマシン
を用いて数値計算アルゴリズムを検討する段階．1 万並列程度の処理が対象
となる．以下の技術項目の研究開発を行う．
· 非均質プロセッサへの対応 12,15,19
· 高精度計算のシリアル／CPU／GPU 最適化 19
· 通信量を増やしてでもレイテンシの影響を削減し，通信時間を削減する
通信方式
2014-2015
大学センター群等で 10 ペタ級スパコンが運用開始となる．それらのマシン
を用いて数値計算アルゴリズムの検討ならびに評価を行う段階．10 万並列
程度の処理が対象となる．以下の技術項目の研究開発を行う．
· 非均質プロセッサへの対応 12,15,19
· 通信最適化数値ライブラリ
· 高精度計算のシリアル／CPU／GPU 最適化 19
· 演算量を増やしてでも通信量やメモリアクセス量を減らす数値計算アル
ゴリズム
2016-2017
プリエクサ級のスパコンが運用開始となる．それらのマシンを用いて数値計
算ライブラリの実装を行う段階．100 万並列程度の処理が対象となる．以下
の技術項目の開発を行う．
· 非均質プロセッサへの対応 12,15,19
· 高精度計算の並列版の実装 19
· 混合精度演算・精度保証計算 19
2018-2020
エクサ級のスパコンが運用開始となる．それらのマシンを用いて数値計算ラ
イブラリのアプリケーション上での評価を行う段階．1000 万並列程度の処
理が対象となる．以下の技術項目の開発を行う．
· フォールトトレラント機能を持つ数値計算ライブラリ
· エクサ級アプリでの利用を実現
· エクサ級アプリでのテスト
4.4.3 数値計算ミドルウェア
(1) はじめに
本章で述べる数値計算ミドルウェアはアプリケーションを効率的に構築するための技術
で，ライブラリ形式あるいはフレームワーク形式により提供される．両者とも適用範囲
をある特定分野に絞り開発している．特に，フレームワークは提供する機能の抽象化の
レベルと範囲の自由度が高く，特定分野向けの機能を提供している．これまで開発され
てきたライブラリ，フレームワークの主目的はプログラム開発時の生産性の向上にある．
ここで，ライブラリはある特定分野の有用かつ汎用的なサブルーチン群でアプリケーシ
ョン構築法とは独立なソフトウェアパッケージとして定義する．フレームワークは，あ
る特定分野のアプリ開発に再利用できる機能モジュール，ライブラリ群から構成された
89
パッケージで，アプリケーションアーキテクチャを形成する．また，ミドルウェアはア
プリケーションと OS のソフトウェアスタック間にあるソフトウェアパッケージの総称
であり，ライブラリとフレームワークを含んでいる．アプリケーションミドルウェアは，
最もアプリに近い階層のミドルウェアとする．本節では，特にフレームワークに焦点を
当てて説明する．
本ロードマップにおいて議論されているエクサスケール計算機システムの問題点を考
慮すると，コード開発の生産性を高め，アプリケーションのプロトタイプ開発の効率化
や開発後の保守にも役立つコード開発環境が必要になる．従来も高生産性のために，い
くつものフレームワークが開発されてきた．フレームワーク設計における課題として，
汎用性を考慮した提供機能の抽象化レベルと実行性能のトレードオフをうまく調整する
点が挙げられる．機能を抽象的にしすぎると，具体的な処理のためにコーディング量が
多くなるし，逆に問題に特化すると再利用性が低下する．このため，これまでのフレー
ムワークはあるアプリケーション範囲をカバーする粒度で設計されたものが多い．エク
サに向けては，スケールするアルゴリズムが限られてくる可能性もあり，アプリケーシ
ョンのカテゴリ，データ構造と解法を絞り，フレームワークの設計を行うことが肝要で
ある．アプリケーションのライフサイクルは 10 年を超えるものもあり，計算機ハードウ
ェアのサイクルよりも長い．このため，エクサスケールのアプリ開発は，新規のアプリ
開発と既存アプリのポーティングの 2 つを考慮する必要がある．
フレームワーク開発は要素技術開発とその進展に左右される．また，プログラミング
言語などの計算機科学チームやターゲットとなるアプリ分野との強固な連携がなければ
成功しない．さらに，コミュニティとファンドの規模を考えると，適用領域を絞る必要
もある．一方で，エクサスケール計算機の有効利用という点からは，適用分野（利用者）
を拡大し，より広範囲の分野で計算科学の成果を国民の生活に反映できるような取り組
みが必要になる．超高速な計算能力を使って，現時点では解決できない複雑な問題を解
く高性能なプログラムを短時間で開発し，成果を創出することも非常に重要なチャレン
ジであり，そのための取り組みも必要である．
ここでは，エクサフロップスを実現する数値計算ライブラリに必要な技術項目に焦点
をしぼり，本ロードマップを作成した．
(1)
技術マップ
図 4.4-2 にアプリケーション開発のミドルウェア技術の観点から見た技術マップを示す．
ライブラリについては，かなり以前から様々なレベルで提供されていたが，1990 年後半
からフレームワークを用いたアプリケーション開発が本格化している[4.4-11]．日本国内
においても 2000 年以降，いくつかのフレームワーク研究が進められている[4.4-16]．
90
図 4.4-2 アプリケーション開発に用いる数値計算ミドルウェアの技術マップ
(2)
技術項目と優先度
以下に挑戦すべき技術項目と達成時期を記載する．末尾の※は，今後新たに技術開発が
必要な項目を示す．
高生産性ミドルウェアの開発
1. 高性能アプリの開発・実行・メンテナンスを支援するアプリケーションプログラマ
向けフレームワーク
·
オブジェクト指向，マルチレベル API（非 OOP を含む多言語対応）をもつ軽量
クラスライブラリ群[7]並列分割管理，データ管理，I/O 処理，AMR 処理，プロセ
スマッピング，格子生成機能など対象とするデータ構造は，直交等間隔，八分木，
非構造，一般曲線座標系構造格子，重合格子，離散点群など．必要なアプリ領域
のコミュニティに対して，データ構造と離散化方法に適したミドルウェアを提供．
2. 記述性と実行性能の高い PDE 系プログラム記述のユーザ向けアプリケーションミド
ルウェア ※
·
·
·
·
アプリケーションの迅速なプロトタイピングを可能にする枠組み 1, 11
実行時の最適候補選択が可能な（AT 技術）簡潔かつ高い実行効率の記述法 2, 12, 21
利用しやすいアルゴリズム記述のフロントエンドとの組み合わせにより，簡便に
高性能アプリケーションを記述するミドルウェアを構築
対象とする問題に適した超並列アプリの並列記述フレームワークをデータ構造毎
にテンプレートとして提供する．
91
高性能・高信頼アプリの要素技術開発
1. 超並列対応の領域分割と並列データ管理技術
·
高いロードバランスで領域を分割し，省メモリで並列領域を管理するデータ構造
2. 高性能ファイル I/O 管理技術 ※
·
·
大規模・多量のファイルハンドリング技術 ※
データ圧縮を併用した高速ファイル I/O 技術 13
3. 領域分割法に対する高レイテンシ・非均質ネットワーク利用技術
·
·
計算空間の並列性と物理コアの並列性のマッピングの最適化
直接網ネットワークトポロジに対応した高速通信アルゴリズムの開発 ※
4. 超並列対応の負荷分散技術
·
·
·
計算中に著しく負荷が変動するケースの動的負荷分散技術
· 外部制約条件（電力消費など），マイグレーション ※
粒度（計算量）の異なる連成現象の負荷分散技術
· Eulerian-Lagrangian coupling, Radiation coupling ※
動的負荷分散に伴う格子細分化ライブラリの整備
5. 故障コアに対するリカバリ対応技術
·
ポリシに応じて制御するしくみの標準化 10, 21 ※
6. ヘテロジニアスな実行コアの利用技術
·
CPU,GPU, FPGA などの各実行コアに最適化された数値ライブラリの利用環境整
備，およびアプリ実行時の動的な実行コア選択 14, 19, 21, 23, 26 ※
7. 超並列探索・最適化アルゴリズム
·
大規模な制約充足問題，最短経路問題，プランニング問題など 13, 16 ※
8. ストロングスケーリング対応
·
·
通信隠蔽可能で，同期点の少ないアルゴリズム開発 ※
マシンの Byte/Flop 値の低下に対応する低 B/F 対応アルゴリズム開発 ※
表 4.4-4 にミドルウェア分野の技術項目における主項目を示す．
表 4.4-4 ミドルウェア分野の技術項目（主項目）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2012
高性能ファイル I/O 管理技
術
★★★
★★★
フェーズ II
2012
超並列対応の分割並列デー
タ管理技術
★★
★★
フェーズ II
2013
高性能アプリの開発・実
行・メンテナンスを支援す
るアプリケーションプログ
ラマ向けフレームワーク
★★
★★
フェーズ II
2014
領域分割法に対する高レイ
テンシ・非均質ネットワー
ク利用技術
★★★
★★
フェーズ II
92
2015
超並列対応の負荷分散技術
★★★
★★★
フェーズ I
2017
記述性と実行性能の高い
PDE 系プログラム記述のユ
ーザ向けフレームワーク
★★
★★★
フェーズ I
主項目から派生する副項目を表 4.4-5 に示す．
表 4.4-5 ミドルウェア分野の技術項目（副項目）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2012
高性能/高機能ファイルハン
ドリング技術
★★
★★
フェーズ II
2014
データ圧縮を併用した高速
ファイル I/O 技術
★
★
フェーズ I
2014
プロセスマッピングの最適
化
★
★★
フェーズ II
2015
動的負荷分散アルゴリズム
開発
★
★★
フェーズ II
2015
粒度の異なる負荷分散アル
ゴリズム開発
★★
★★
フェーズ II
2016
超並列探索・最適化アルゴ
リズム
★★
★
フェーズ I
2017
故障コアに対するリカバリ
対応技術
★
★
フェーズ I
2018
ヘテロジニアスな実行コア
の利用技術
★★
★★
フェーズ I
(3)
まとめ
前節の技術項目のうち主項目を達成するためのロードマップを表 4.4-6 にまとめる．
フレームワーク開発は，ハードウェアの進展に依存して，要素技術開発とその発展に
左右されるため，長期にわたる開発とユーザ支援が必要となる．ロードマップとして，
最初の 2 年は開発計画の詳細化について検討する．アプリと計算機科学分野で，まずコ
ミュニティ形成とフレームワーク機能のディスカッションが必要である．その後，いく
つかの分野（例えば，連続体力学分野，分子/粒子系分野，データインテンシブ系分野な
ど）のフレームワーク設計とプロトタイピングを行う．フレームワークを用いた具体的
なアプリ構築とその過程でのフレームワーク側へのフィードバックを続け，継続的なア
ップデートとユーザサポートにより展開を図る．
一方で，エクサスケール計算機の有効利用を考慮し，アプリ開発の期間とコストが小
さく，できるだけ高性能な偏微分方程式系のアプリケーションを簡単に記述できるミド
ルウェアを開発し，これまでスパコンとは縁のなかったコミュニティの取り込みと利用
促進を図る．
表 4.4-6 ミドルウェア分野のロードマップ
達成時期
2011-2012
研究開発内容
フィージビリティスタディと開発計画の詳細化
93
· アプリ，計算機科学，ミドル開発分野の研究者の議論
· 対象アプリ領域選定，共通機能の選定，開発プライオリティ
· ミドルウェア実装の検討
2012-2013
フレームワークのプロトタイプ開発
· 軽量クラスライブラリ群の設計開発
· エクサ向けの機能要素開発（ネットワークトポロジ特性を利用した通信
最適化など）
· ペタスケール環境での性能評価
2014-2015
フレームワークのアップデートと展開
· 要素技術のアップデートに対応して，実装変更
· 機能拡張とエクサ向けアルゴリズムの導入
· フレームワークのリリースと既存関連アプリの移植
2016-2017
アプリケーションミドルウェアの構築
· 開発したフレームワークを用いて高レベル記述のラピッドプロトタイピ
ング用のミドルウェアを構築
· フレームワークの継続的なアップデートとサポート
· プリエクサ級環境での実証
2018-2019
エクサスケールへの展開
· エクサスケール環境でミドルウェアの有効性を検証
· ミドルウェアとアプリの継続的なアップデートとサポート
4.4.4 数値計算ライブラリのための自動チューニング
(1) はじめに
数値計算ライブラリのための自動チューニング(AT)技術は，数値計算ライブラリで現れ
る主演算において，計算機環境に自動適応し，高性能となる実装方式を自動生成できる
技術である．AT 技術で実現される実装方式の最適化は，単にプログラミングの仕方に
留まらず，数値計算アルゴリズムも考慮し最適アルゴリズムを選ぶ＜アルゴリズム選択
＞も含まれる技術である．実行速度の高速化のみだけではなく，ユーザが要求する演算
精度に適合する最適化や，実行時のメモリ量を最小化する最適化も含む．AT を行うタ
イミングは，ソフトウェアのインストール時だけではなく，ユーザが所望した時や実行
時も含まれる．
以上のように＜汎用的＞に行われる AT 技術について，エクサフロップスを実現する
数値計算ライブラリに必要な技術項目に焦点をあて本ロードマップを作成した
エクサフロップス環境のための AT 技術が実現されると，以下の事項が達成できる．
·
·
エクサフロップス環境で想定される多様な計算機環境に自ら柔軟に適応できる．ソ
フトウェア性能を自動最適化できる枠組み（ソフトウェア構築法）が提供できる．
このことで，より高い実行性能を実現するソフトウェアが開発可能となる．
コンパイラが行うことができない最適化（コード最適化，自動並列化など）を提供
できる．性能チューニングに関する工数を削減し，結果として，ソフトウェア開発
工数の削減が可能となる．
研究開発の背景と技術的な制約として以下がある．
94
·
·
·
·
·
·
非均質プロセッサ（マルチコア CPU とアクセラレータ(GPU)の混合）が普及する
実行時に判明するなんらかの電力制約がある
通信性能が劇的に低下する（高レイテンシになる）
大規模問題実行時に演算精度が著しく劣化する
高性能を達成するためにはアルゴリズム選択が必要となる
ハードウェア故障を考慮しないと安定実行ができなくなる
(2) 技術マップ
自動チューニング（数値計算ライブラリ、AT専 言語）技術マップ
用
図 4.4-3 に，AT 技術を適用した数値計算ライブラリと AT 専用言語の開発に関する技術
マップをのせる．図 4.4-3 から，1990 年後半から特定の数値計算ライブラリ，特に密行
列用の基本演算ライブラリ BLAS(Basic Linear Algebra Subprograms)に対する AT の技術開
発が始まった[4.4-22]．2000 年前半になり，数値計算ライブラリレベルの AT 技術の開発
が始まっている[4.4-20]．2010 年前後において，より汎用的な AT 技術の開発がコンパイ
ラ最適化を拡張する方法で始まっており[4.4-24]，現在まで研究開発が継続されている．
アプリケーション 理
2011年、自動チューニング機能
付き数値計算ミドルウエア
ppOpen-HPC、情報処 学会
研究報告HPC 、中島ほか
理
片
1998年、ランタイムパラメタ
自動チューニング機構　Ac ve Harmony
Proc. HPDC、Jeffrey K. Hollingsworth et.al.
2011年、非均質 境向き
自動チューニング
専 言語HxABCLibScript、
情報処 学会
研究報告HPC、 桐ほか
理
1997年、BLAS
チューニング方式
PHiPAC, SC97、J. Blimes et.al.
2000年、コード最適化コンパイラROSE
in special issue of Parallel Processing Le ers、
Quinlan, D
環
2006年、自動チューニング専 言語
ABCLibScript, Parallel Compu ng,
T. Katagiri et.al.
用
1999年、自動チューニング機能付き
FFTライブラリFFTW, Proc. PLDI,
M. Frigo、ほか
用
数値計算
ライブラリ
2009年、自動チューニング
機能付き 行列反復解法
ライブラリXabclib, ATのAPI集
OpenATLib、情報処 学会
研究報告HPC、 桐ほか
2006年、自動チューニング
機能付き数値計算ライブラリ
ABCLib_DRSSED,
Parallel Compu ng,
T. Katagiri et.al.
片
片
2000年、自動チューニング
機能付き数値計算ライブラリILIB
JSPP論文集、 桐ほか
2005年、自動チューニング
機能付き 行列ライブラリ OSKI
SIAM CSE2005、R. Vuduc et.al.
疎
2000年、自動チューニング
機能付きFFTコードジェネレータSpiral
Proc. HPEC、 José M. F. Moura et.al.
疎
数値計算
ミドルウェア
2001年、自動チューニング
機能付きBLASライブラリ ATLAS
Parallel Compu ng、C. Whaley et.al.
2007年、コード最適化に
関する自動チューニング
POET、Proc. Workshop on
Performance Op miza on for
High-Level Languages and Libraries,
Qing Yi et.al.
2008年、コンパイラベースの自動
チューニング,　CHiLL: Composable
High-Level Loop Transforma on
Framework, Mary Hall et.al システムソフトウェア 年
図 4.4-3 AT 技術を基にした数値計算ライブラリと専用言語の技術マップ
(1)
技術項目と優先度
本節は，今後 5 年～10 年で挑戦すべき技術項目と達成時期を記載する．表 4.4-7 に主項
目を示す．なお本節で示される技術項目は，AT の観点から対象となる最適化を自動化
する技術を意味する．ここで示された技術項目を実現するための要素技術は他分野にお
いて重要項目となっている場合がある．しかし他分野の最適化は必ずしも最適化自体を
自動化する技術を意味しない．ここでの AT 技術とは，最適化自体を自動化する技術を
指す．
95
表 4.4-7 AT 分野の技術項目（主項目）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2014 年
非均質環境最適化
★★★
★★★
フェーズ III
2016 年
電力最適化
★★
★★★
フェーズ II
2016 年
超低レイテンシ通信最適化
★★★
★★★
フェーズ I
2014 年
数値計算アルゴリズム選択
★★
★★
フェーズ II
2018 年
数値計算安定化
★
★★
フェーズ I
2018 年
耐故障性対応
★★
★★
フェーズ I
主項目は以下にまとめられる．
1. 非均質環境最適化 11, 12, 23
·
·
·
マルチコア最適化，ハイブリッド MPI 最適化，のための AT 機構
CPU-GPU の切り替えのための AT 機構[4.4-29]，CPU-GPU 切り替え機能を自動付
加する AT 言語[4.4-30]
非均質環境に適用可能な性能モデル化手法
2. 電力最適化 4, 26
·
·
·
ジョブレベル，演算カーネルごとに適する電力最適化（周波数の変更，電力が低
い CPU の選択，等）のための AT 機構
どのようなポリシで電力最適化するかという「電力最適化ポリシ」と，自動チュ
ーニング専用言語の確立
電力最適化のための，性能モデル，最適化ポリシ指定方式，AT 言語
3. 超低レイテンシ通信最適化 17
·
·
·
·
完全網から 3D トーラス網などへのネットワークアーキテクチャ変更に伴う＜高
レイテンシ化＞に対応する通信処理の最適化のための AT 機構
通信ライブラリ(MPI)の実行時の実装方式・アルゴリズム切り替えのための AT
機構
実行時の物理ノード割り当て情報からの通信最適化のための AT 機構
通信実装方式を実行時に切り替える AT 方式および AT 機構
4. 数値計算アルゴリズム選択 2, 21, 23
·
·
·
入力データ特性（行列の数値特性や問題サイズ等）を自動抽出して，最適アルゴ
リズムを選択するための AT 機構[4.4-28]
数値シミュレーションが進むたびに変化する数値特性に応じた最適化のための
AT 機構
アルゴリズム選択のための性能モデルとその AT 言語への適用
5. 混合演算・精度保証による数値計算安定化 19
·
·
·
·
以下の演算の導入を行うことで実現する AT 機構
· 混合演算に対する高精度演算と混合精度演算の導入
· 反復解法中で内積演算のみ高精度化する等の混合演算の AT 機構
「実行速度」「メモリ量」「演算精度」のうち，何を重視し最適化するかという
ポリシの記述（「数値計算ポリシ」記述）
解の一覧を与えた上，プログラム変換により，ソルバ実装が変化してもテスト問
題は正しく解けていることを保証してくれるメカニズム（アルゴリズム検証）
精度保証手法とそのライブラリ，数値計算ポリシ指定方式，アルゴリズム検証方
式，数値計算安定化のための AT 言語
96
6. 耐故障性対応 10
·
·
·
·
数値計算アルゴリズム特有の知識記述でチェックポイント・リスタートを低レイ
テンシ化する技術を利用した AT 機構
実行時間と耐故障性のトレードオフ考慮し，方式を自動選択する「耐故障性ポリ
シ」の確立
「ある確率で失敗するかもしれない計算」という部品を記述し，それをもとに
100%に近い確率で成功するよう計算全体を組み立てるフレームワーク（耐故障
ソフトウェア部品化）
低レイテンシ耐故障化のための AT 方式と AT 言語，耐故障性ポリシ記述方式，
耐故障ソフトウェア部品化
主項目から派生する副項目（短期）と副項目（長期）を表 4.4-8，表 4.4-9 に示す．
表 4.4-8 AT 分野の技術項目（副項目，短期）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2014 年
非均質環境最適化(CPU-GPU)：疎行
列用のデータフォーマット切り替え
★★★
★★★
フェーズ III
2014 年
非均質環境最適化(CPU-GPU)：自動
チューニング専用言語への適用
★★★
★★★
フェーズ III
2014 年
電力最適化：自動チューニング専用
言語への適用（含，周波数切り替
え，電力最適化ポリシ）
★★
★★
フェーズ II
2014 年
超低レイテンシ通信最適化：実行時
の通信ライブラリの実装最適化
★★★
★★★
フェーズ I
2014 年
数値計算アルゴリズム選択：疎行列
反復解法アルゴリズム選択
★★
★★
フェーズ II
2014 年
数値計算アルゴリズム選択：自動チ
ューニング数理コアのライブラリ化
★★
★★
フェーズ II
2016 年
数値計算安定化：多倍長計算，制度
保証計算の基本線形計算ライブラリ
への適用
★
★★
フェーズ I
表 4.4-9 AT 分野の技術項目（副項目，長期）
技術完成
目標年度
技術項目
必要性
重要性
2011 年におけ
る研究進捗
2016 年
自動チューニング向け性能プロファ
イル（データベース化）
・可視化
★
★★
フェーズ I
2016 年
自動チューニングプログラムのデバ
ッグ支援，AT 品質保証
★★
★★★
フェーズ I
2018 年
自動チューニング指向システムソフ
トウェア（OS，ミドルウェア，スケ
ジューラの自動チューニング化）
★
★★
フェーズ I
2018 年
AT のためのコスト推定モデルの，自
動推薦，自動選択，自動構築（数値
計算ポリシの自動記述）
★
☆
フェーズ I
2018 年
耐故障性ポリシ，耐故障性ソフトウ
ェア部品化
★★
★★
フェーズ I
97
(2)
まとめ
前節の技術項目のうち主項目を達成する，数値計算のための AT 技術のロードマップを
以下にまとめる．初めの 2 年間は要素技術検討期間とし，アプリケーションに対し，AT
の適用を前提とした，演算・通信パターン調査，および，演算精度の調査を行う．ライ
ブラリインターフェース，非均質環境最適化，および，混合演算・精度保証による数値
計算安定化の技術項目の観点から調査を行う．
表 4.4-10 AT 分野のロードマップ
達成時期
2012-2013
研究開発内容
· AT の適用を前提とした，アプリケーションに対する，演算・通信パタ
ーン調査，演算精度調査を，＜ライブラリインターフェース＞21，23＜非
均質環境最適化＞2，12＜混合演算・精度保証による数値計算安定化＞の
技術項目の観点から行う．
· ＜超低レイテンシ通信最適化＞17 の AT 方式検討および AT 基本部分設計
を行う．
· ＜電力最適化＞4 と＜耐故障性対応＞について，ハードウェア設計調査と
AT 必要性検討を行う．
2014-2015
·
AT 基本部分開発を，＜ライブラリインターフェース＞＜非均質環境
最適化＞＜超低レイテンシ通信最適化＞の技術項目に対して行う．
· ＜非均質環境最適化＞＜超低レイテンシ通信最適化＞の機能の高度化を
行う．
2016-2017
· AT 方式検討と AT 基本部分開発を，＜電力最適化＞＜耐故障性対応機能
＞について行う．
· アプリケーション，および他のシステム領域と連携し，開発した AT 機
能を高度化し整備する．
2018-2020
· エクサスケール環境で開発した AT 機能の実証を行う．
· エクサスケール環境における開発 AT 機能の問題を整理し，次世代環境に
向けた技術開発項目を整備する．
4.4.5 我が国でファンディングされた課題
(1) はじめに
本資料は，数値計算ライブラリ関連の研究について，我が国でファンディングされた研
究課題を列挙したものである．文部科学省科学技術研究費補助金，基盤研究(S)，(A)，
および科学技術振興機構(JST)戦略的創造研究推進事業(CREST)による採択課題を列挙し
た．
98
我が国でファンディングされた
数値計算ライブラリ研究俯瞰図
アプリケーション
平成20年度～平成23年度：科学研究費補助金，
基盤研究（A），「マルチコアプロセッサに対応した革新的
特異値分解ライブラリーの開発」，代表者：中村佳正

平成21年度～平成23年度：科学研究費補助金，基盤研究（A），
「次世代シミュレーション環境のための一般化固有値解法の
開発と応用」，代表者：櫻井鉄也
数値計算
ミドルウェア
数値計算
ライブラリ
マルチコア向けの2重対角化
アルゴリズムの開発

一般化固有値解法の開発
平成14年度～平成19年度：
科学技術振興機構，CREST，「シミュレーション技術の革新と
実用化基盤の構築」研究領域，「大規模シミュレーション向け
基盤ソフトウェアの開発」，代表者：西田晃

平成22年度～平成26年度：
科学技術振興機構、戦略的国際科学技術協力推進事業
（共同研究型）「日本－フランス共同研究」，ポストペタスケールコン
ピューティングのためのフレームワークとプログラミング，
代表者：佐藤 三久，Serge Petiton

数値計算アルゴリズムGMRES(m)法に
おける自動チューニング方式の研究
平成23年度～平成27年度：
科学技術振興機構，CREST，「ポストペタスケール高性能計算に
資するシステムソフトウェア技術の創出」研究領域，
「ポストペタスケールに対応した階層モデルによる超並列固有値
解析エンジンの開発」，代表者：櫻井鉄也

階層的並列構造に対応した「超並列
固有値解析エンジン」の開発
平成23年度～平成27年度：
科学技術振興機構，CREST，「ポストペタスケール高性能計算に
資するシステムソフトウェア技術の創出」研究領域，
「自動チューニング機構を有するアプリケーション開発・実行環
境」，代表者：中島研吾
並列数値計算を可能とする標準的な
ソフトウェア基盤を構築

自動チューニング機構によりプログラム
の修正なしに最適な性能で安定に実行
可能となる環境を開発
平成19年度～平成24年度：
科学技術振興機構，CREST，「情報システムの超低消費電力化
を目指した技術革新と統合化技術」研究領域，
「ULP-HPC：次世代テクノロジのモデル化・最適化による
超低消費電力ハイパフォーマンスコンピューティング」，代表者：松岡聡
GPUによる基本演算（行列積，FFT）や
線形ソルバの開発

システムソフトウェア
採択年
図 4.4-4 我が国でファンディングされた課題（数値計算ライブラリ分野）
我が国でファンディングされたミドルウェア研究俯瞰図 産
生
平成23年度～平成27年度：　JST CREST 「高性能・高
性アプリケーションフレーム
ワークによるポストペタスケール高性能計算の実 」
代表者：丸山直也
平成16年度～平成18年度：　NEDO 業技術研究助成事業
「陰関数形 操作APIと先進可視化技法による有機的CAEフレームワーク
シミュレーションの融合 」
とボクセルベース
代表者：小野謙二 状
現
産
アプリケーション 理
物
牧
平成16年度～平成22年度：　VCADシステム研究プログラム
サブテーマ「機能情報モデリング」
代表者： 野内昭武，分担者：小野謙二 数値計算
ミドルウェア





アプリケーションミドルウェア
オブジェクト指向クラスライブラリ
線形ソルバクラスライブラリ
グリッドジェネレータ
可視化システム
略
平成17年度～平成19年度：　文部科学省次世代IT基盤構築のための研究開発プログラム
「戦 的革新シュミレーションソフトウェアの研究開発」プロジェクト
サブテーマ「ハイエンド計算ミドルウェアカーネル援 構造解析
連成シミュレーション・システム」
システムによる
代表者：加藤千幸，分担者：奥 洋司 田



各種マシン向け最適化
大規模構造解析ソフトウェア開発
連成解析対応
平成21年度～平成25年度：　科研基盤S 「ルビーによる高
代表者：平木敬
な超並列・超分散計算ソフトウェア基盤」
用


オブジェクト指向アプリ・ミドル
連成解析
産
生
産
平成11年度～平成17年度：　新エネルギー・ 業技術総合開発機構NEDO委託事業
「 研究情報基盤研究開発」 プロジェクト サブテーマ
「離散化数値解法のための並列計算プラットフォームに関するソフトウェア開発」、
代表者：手塚明 

用
田
有限要素法コード開発インターフェース
数値計算ライブラリ
前処 付線形代数ソルバー
理



平成20年度～平成22年度：　次世代計算科学研究プログラム
サブテーマ「基盤ソフトウェア開発」
代表者：茅幸二，分担者：小野謙二 用
汎
平成14年度～平成16年度：　文部科学省ITプログラム「戦 的基盤ソフトウェアの開発」
サブテーマ「HPCミドルウェア」
代表者：加藤千幸，分担者：奥 洋司 垂直統合型のアプリケーションフレーム
ワークにより
性と性能の両立
略
数値計算
ライブラリ

オブジェクト指向フレームワーク
アプリケーションデザイン
産
生


PCクラスタ 並列化支援プラットフォーム
線形代数ソルバー
システムソフトウェア 採択年 図 4.4-5 我が国でファンディングされた課題（数値ミドルウェア分野）
99
用
我が国でファンディングされた
自動チューニング（数値計算ライブラリ、AT専 言語）研究俯瞰図 国際協調（日-仏） アプリケーション 略
平成２２年度～平成２６年度：　科学技術振興機構、戦 的国際科学技術協力
推進事業（共同研究型）
「日本－フランス共同研究」、ポストペタスケール
コンピューティングのためのフレームワークと
プログラミング（代表者：佐藤 三久、Serge Pe ton） 現
産
生産
生
環
片
数値計算
ミドルウェア
自動チューニング機能つき
行列反復解法ライブラリXabclibの開発
疎

片

 自動チューニングの流体シミュレーション
および分子動力学法への適
現
平成２３年度～平成２５年度：　科学技術研究費補助金、基盤研究(A)、
「
自動チューニング機構を実 するための
ソフトウェア基盤の研究」、代表者：須 礼仁　用
汎
自動チューニング機能つき
密行列ライブラリABCLibの開発
自動チューニング言語ABCLibScriptの
基礎技術開発
平成２３年度～平成２７年度：　科学技術振興機構、CREST、「ポストペタスケール高性能計算に
資するシステムソフトウェア技術の創出」、
「高性能・高
性アプリケーションフレームワーク
によるポストペタスケール高性能計算の実 」、
代表者：丸山直也 用

 自動チューニング言語ppOpen-AT
によるCPU－GPU切り替え機構の開発 現
環
科学技術振興機構、PRSTO、「情報基盤と利
境」領域、
並列実行 境に依存しない高性能数値計算ライブラリ、
代表者： 桐孝洋 平成２３年度～平成２７年度：　科学技術振興機構、CREST、「ポストペタスケール高性能
計算に資するシステムソフトウェア技術の創出」領域、
「自動チューニング機構を有するアプリケーション開発・
実行 境」、代表者：中島研吾 産
生
環
用
数値計算
ライブラリ 平成１３年度～平成１７年度：　数値計算アルゴリズム
GMRES(m)法における
自動チューニング方式の研究
環
平成２０年度～平成２３年度：　文部科学省、e-サイエンス実 のためのシステム統合・連携
ソフトウェアの研究開発、「シームレス高
・高性能
高可搬性ライブラリに
プログラミング 境」、サブテーマ、「高
関する研究」、分担者： 桐孝洋、代表者：石川裕 
田
平成１９年度～平成２４年度：　科学技術振興機構、CREST、「情報システムの超低消費電力化
を目指した技術革新と統合化技術」領域、
ULP-HPC：次世代テクノロジのモデル化・最適化による
超低消費電力ハイパフォーマンスコンピューティング、代表者：松岡聡 システムソフトウェア  自動チューニング言語ABCLibScript
による電力最適化機構の開発 
自動チューニング言語
ABCLibScriptによる実行時
アルゴリズム選択機能の開発 採択年 図 4.4-6 我が国でファンディングされた課題（自動チューニング分野）
4.4.6 まとめ
数値計算ライブラリの目的は以下の 2 点である．
1. 計算科学ソフトウェア構築に必要な共通機能を定め，高性能実装を提供し，ソフト
ウェアの生産性・性能を高めること．
2. 複数の異なる計算機アーキテクチャに対し，チューニングされたサブルーチンを提
供し，高い処理性能を実現すること．
上記目的に対して本節では 3 章で議論した課題を解決するための研究開発ロードマッ
プを提示した．以下に数値計算ライブラリ全体の 2018 年から 2020 年頃までの線表を示
す．
100
2012 2013 2014 FW LP,
連携&deploy LI, HP,
RCM
LI 演算・通信パタン調査 HP アプリ利 調査
・設計 マルチコア lib LI & CA
FT
2015 HP &
RCM
2016 CA, LP,
FT
2017 LP, FT
整備 2018 2019 2020 整備 ユーザへ提供
方式検討 評価　&　改良 基本部開発 外部から提供
用
RCM CA LP & FT 方式検討 基本部開発 アプリ精度調査 ハードウェア設計調査 GPU lib メニーコア lib 評価&改良 評価&改良 方式検討 基本部開発 方式検討 評価&改良 プロト開発 基本部開発 評価&改良 画
FW 開発計 の
詳細化 軽量プロト
開発 評価・展開 アプリ・ミドル開発 評価・改良・サポート 図 4.4-7 数値計算ライブラリ線表（LI: ライブラリインターフェース，HP: 非均質プロ
セッサ対応，RCM: 通信量およびメモリアクセス回数の削減，CA: 演算精度，LP: 低電力
化，FT: 耐故障性，FW: フレームワーク）
線表の通り，高精度演算・精度保証演算，数値計算ライブラリのインターフェース，
計算科学者とのコデザイン・ミドルウェア，ヘテロジニアス環境最適化，電力最適化，
耐故障性対応等に取り組み，最終的には，シミュレーションソフトウェアの高性能化・
高生産性化・低保守コスト化，コンパイラ等の基盤ソフトウェアの機能向上，WS から
スパコンまでシームレスな開発基盤の提供を実現する．これによって計算科学の裾野の
拡大が期待される．
4.4.7 参考文献
[4.4-1] L. S. Blackford, J. Choi, A. Cleary, E. D’Azevedo, J. Demmel, I. Dhillon, J. Dongarra, S.
Hammarling, G. Henry, A. Petitet, K. Stanley, D. Walker and R. C. Whaley,
“ScaLAPACK Users' Guide”, SIAM, 1997.
[4.4-2] R. C. Whaley, A. Petitet and J. Dongarra, “Automated Empirical Optimization of
Software and the ATLAS Project”, Parallel Computing, Vol. 27, pp. 3—35, 2001.
[4.4-3] Jeff Bilmes, Krste Asanovic, Chee-Whye Chin and Jim Demmel, “Optimizing Matrix
Multiply using PHiPAC: a Portable, High-Performance, ANSI C Coding Methodology”,
Proc. 1997 International Conference on Supercomputing, pp. 340—347, 1997.
[4.4-4] Markus Püschel, José M. F. Moura, Jeremy Johnson, David Padua, Manuela Veloso,
Bryan Singer, Jianxin Xiong, Franz Franchetti, Aca Gacic, Yevgen Voronenko, Kang
Chen, Robert W. Johnson and Nicholas Rizzolo, “SPIRAL: Code Generation for DSP
Transforms”, Proc. IEEE, Vol. 93, pp. 232—275, 2005.
[4.4-5] Matteo Frigo and Steven G. Johnson, “The Design and Implementation of FFTW3”, Proc.
IEEE, Vol. 93, pp. 216—231, 2005.
[4.4-6] Richard Vuduc, James W. Demmel and Katherine A. Yelick, “OSKI: A library of
automatically tuned sparse matrix kernels”, Journal of Physics: Conference Series, Vol.
16, pp. 521—530, 2005.
[4.4-7] A. Haidar, H. Ltaief and J. Dongarra, “Parallel Reduction to Condensed Forms for
Symmetric Eigenvalue Problems using Aggregated Fine-Grained and Memory-Aware
Kernels”, Proc. 2011 International Conference for High Performance Computing,
Networking, Storage and Analysis (SC11), 2011.
[4.4-8] R. Nath, S. Tomov, T. Dong and J. Dongarra, “Optimizing Symmetric Dense MatrixVector Multiplication on GPUs”, Proc. 2011 International Conference for High
Performance Computing, Networking, Storage and Analysis (SC11), 2011.
101
[4.4-9] Robert D. Falgout and Ulrike Meier Yang, "hypre : A Library of High Performance
Preconditioners", Lecture Notes in Computer Science, (ICCS 2002), 2002, Vol.
2331/2002, pp. 632-641, 2011.
[4.4-10] PETSc: http://www.mcs.anl.gov/petsc/
[4.4-11] Baden, S. B., Colella, P., Shalit, D. and Van Straalen, B., “Abstract KeLP,” 10th SIAM
Conference on Parallel Processing for Scientific Computing, Portsmouth, Virginia, March,
2001.
[4.4-12] Wijesinghe, H. S., Hornung, R. D., Garcia, A. L. and Hadjiconstantinou, N. G., “Threedimensional Hybrid Continuum-Atomistic Simulations for Multiscale Hydrodynamics,”
Journal of Fluids Engineering, Vol.126, pp.768–777, 2004.
[4.4-13] Hornung,R.D. and Kohn,S.R., “ManagingApplication Complexity in the SAMRAI
Object- Oriented Framework,” Concurrency and Computation: Practice and Experience
(Special Is- sue), Vol. 14, pp. 347–368 , 2002.
[4.4-14] Henshaw, W. D., “Overture: An Object-Oriented Framework for Overlapping Grid Applications,” AIAA conference on Applied Aerodynamics, 2002.
[4.4-15] 松田勝之, 武宮博, “データ可視化機能を持つ並列プログラムデバッグツール :
vdebug,” 技術報告, JAERI–Data/Code 2000–014, 2000.
[4.4-16] 太田高志, 白山晋, “オブジェクト指向フレームワークによる流体計算統合環境”
日本計算工学会論文集, No. 19990001, 1999.
[4.4-17] 小野謙二, 玉木剛, 野田茂穂, 岩田正子, 重谷隆之, “オブジェクト指向並列化クラス
ライブラリの開発と性能” 評価. 情報処理学会論文誌:コンピューティングシステ
ム, Vol. 48, No. SIG 8(ACS 18), pp. 44–53, 2007.
[4.4-18] Satoshi ITO and Hiroshi OKUDA, HPC-MW:A Problem Solving Environment for
Developing Parallel FEM applications, Applied Parallel Computing, State of the Art in
Scientific Computing, Springer (LNCS4699), pp.694-702. 2007.
[4.4-19] 手塚明, 鈴木健, 高瀬慎介, 松本純一, 松原聖,"離散化数値解法のための並列計算プ
ラットフォーム(Parallel Computing Platform/PCP)Ver1.2(OS17d 次世代 CAD/CAE)",
計算力学講演会講演論文集, Vol.2004, Num.17, pp.373-374. 2004.
[4.4-20] Frigo, M., Johnson, S.G., “FFTW: An Adaptive Software Architecture for the FFT,” In
Proceedings IEEE International Conference on Acoustics, Speech, and Signal Processing,
Vol. 3, IEEE Press, Los Alamitos, CA, pp. 1381-1384, 1998.
[4.4-21] Hollingsworth, J.K., Keleher, P., “Prediction and Adaptation in Active Harmony,” IEEE
International Symposium on High Performance Distributed Computing (HPDC), 1998.
[4.4-22] Whaley, R.C., Petitet, A., Dongarra, J.J, “Automated Empirical Optimizations of
Software and The ATLAS Project,” Parallel Computing, Vol.27, Issue 1-2, pp. 3-35, 2001.
[4.4-23] Vuduc, R., Demmel, J.W., Yelick, K.A., “OSKI: A Library of Automatically Tuned
Sparse Matrix Kernels, In Proceedings of SciDAC,” Journal of Physics: Conference
Series, Vol. 16, pp. 521-530, 2005.
[4.4-24] Chen, C., Chame, J., Hall, M., “Combining Models and Guided Empirical Search to
Optimize for Multiple Levels of the Memory Hierarchy,” Proceedings of CGO 2005,
2005.
[4.4-25] Katagiri, T., Kise, K., Honda, H., Yuba, T., “ABCLib_DRSSED: A Parallel Eigensolver
with An Auto-tuning Facility,” Parallel Computing, Vol.32, Issue 3,pp.231-250, 2006.
[4.4-26] Katagiri, T., Kise, K., Honda, H., Yuba, T., “ABCLibScript: A Directive to Support
Specification of An Auto-tuning Facility for Numerical Software,”Parallel Computing,
Vol.32, Issue 1, pp.92-112, 2006.
[4.4-27] Yi, Q., Seymour, K., You, H., Vuduc, R., Quinlan, D., “POET: Parameterized
Optimizations for Empirical Tuning,” Proceedings of Parallel and Distributed Processing
Symposium (IPDPS2007), 2007.
[4.4-28] 櫻井隆雄，直野健，片桐孝洋，中島研吾，黒田久泰，”OpenATLib:数値計算ライ
ブラリ向け自動チューニングインターフェース”，情報処理学会論文誌：コンピ
ューティングシステム， Vol. 3, No,2, pp.39-47, 2010.
[4.4-29] Maruyama, N., Nomura, T., Sato, K., Matsuoka, S., “Physis: An Implicitly Parallel
Programming Model for Stencil Computations on Large-scale GPU-accelerated
Supercomputers,” Proceedings of SC2011, 2011.
102
[4.4-30] 片桐孝洋，”ppOpen-AT：ポストペタスケール時代の数値シミュレーション基盤
ソフトウェア ppOpen-HPC のための自動チューニング基盤”，京都大学数理解析
研究所研究集会「科学技術計算における理論と応用の新展開」，2011.
103
5. おわりに
本白書ではまず今後のスーパーコンピュータの開発について，2020 年頃にかけた技術動
向を調査し，重点的に取り組むべき技術課題を 7 項目提示した．具体的には，電力効率
の大幅な改善を目的としたヘテロジニアスアーキテクチャの活用，継続して B/F 値の低
下が予想されるメモリ，10 億規模の大規模並列性，さらなる低下が見込まれる平均故障
間隔に対する耐故障性，大規模データ処理，およびすべての課題の最大の要因である消
費電力についてまとめた．またそれらの課題によって派生する生産性に関する課題につ
いても議論した．さらに，技術課題に対して今後取り組むべき研究開発ロードマップを
提示した．ロードマップはスーパーコンピュータを構成する，ハードウェアアーキテク
チャ，システムソフトウェア，プログラミング，数値計算ライブラリの各項目について
それぞれまとめた．
こうした技術はその性能向上をアプリケーション・ソフトウェア・ハードウェアの協
調設計（コデザイン）によって実現する性質のものも多い．こうした多分野に渡る協調
は過去のスーパーコンピュータプロジェクト（数値風洞，CP-PACS，地球シミュレータ，
京）に於いても行われてきたが，今後はより強い協調を求められる．コデザインは，ア
プリケーション・ソフトウェア・ハードウェアの各コンポーネントの特性を理解し，シ
ステム全体を見据えた協調設計を行うことで，消費電力や信頼性など様々な制約を満足
しつつ高い性能を実現するというものである．そのためには，計算の特性を理解した上
でそれを実現するソフトウェア・ハードウェアの環境を決定・構築する，というステッ
プが必要になる[5-1]．
コデザインが上手く機能すると，従来実現できない性能が実現できる場合がある．例
えば，専用計算機の Anton では計算のボトルネック箇所である分散 3 次元 FFT をメモリ
システムの工夫などで高速化し，コモディティの計算機の 10 倍以上の性能向上を実現し
ている[5-2]．その他，GPU 計算を汎用化する CUDA は GPU というハードウェアの特殊
性をランタイムやプログラミング言語によって隠蔽するコデザインの形と言える．日本
では，CP-PACS が格子 QCD シミュレーションのカーネル部分の高速化のために擬似ベ
クトル機構を構築したことや，GRAPE プロジェクトが N 体問題に向けて専用パイプラ
インを持つ LSI を設計したことが積極的なコデザインの例として挙げられる．また，古
くは CRAY-1 のようなベクトル計算機も行列・ベクトルを多く扱う科学技術計算をベク
トル命令によって効率化するコデザインであったといえる．
コデザインの実現のためには前述のとおりアプリケーション・ソフトウェア・ハード
ウェアの特性を理解した上で議論を行なう必要がある．アプリケーションの特性を理解
するためには，例えばアプリケーションを以下の尺度で分類し抽象化することが有効で
ある．
·
·
·
·
·
計算機ノード内におけるメモリアクセスパターン
計算機ノード間の通信パターン
通信回数（通信レイテンシ）と通信量（通信バンド幅）
I/O 性能（データアクセス頻度とデータ量）
その他アプリケーションから抽出できる尺度
104
アプリケーション分類に基づき例えば次のようにコデザインを進めることが考えられ
る．第一ステップとして対象とする分類について最大化すべき要素を明確化する．これ
は性能のみでなく，生産性（単位時間あたりにアプリケーション開発者が生み出せる価
値）などの「最終的な性能」に見えない要素も含まれて良い．次に，第二ステップとし
て明確化した要素を最大化するために必要なパラメータを列挙し，モデル化などにより
必要な要件を検討する．例えば，密行列積等のアプリケーション分類の効率を高めるた
めには必要なメモリ帯域とローカルメモリの容量がトレードオフの関係になる．こうし
たトレードオフを理解するステップが必要である．最後に，第三ステップとしてこうし
て決定した値をシミュレーション，あるいは，プロトタイピングという形で検証する．
現代の計算機は非常に多くの構成要素からなっており，その挙動をモデル化によって詳
細に予想を行なうことは困難である．そうした不確定な要素をシミュレーションやプロ
トタイプによって検証し，最終的なデザインの決定を行なう必要がある．前述の CPPACS や GRAPE の例ではこうしたステップを着実に踏んでいたため，高い成果が出せた
と考えられる．
計算機の進化を推進した重要な要素であった「半導体の進化」に限界が見え始めた昨
今に於いては，こうしたステップを踏み開発対象の理解を深め，アプリケーション・ソ
フトウェア・ハードウェアの協調設計を行なうことが高度な高性能計算を実現するため
に必須である．今後はコデザインによる研究開発体制を整え，2012 年から 2013 年にか
けては目標アプリケーション性能の精緻化，アーキテクチャ概念設計，および種々の要
素技術の方式検討を進め，それに基づいた 2018 年前後に運用開始の実現性を有するシス
テム設計を提示する必要がある．アーキテクチャ，システムソフトウェア，プログラミ
ング，数値計算ライブラリそれぞれについてプロトタイプを開発し，2014 年から 2018
年に向けた研究開発の基盤を提示することが望まれる．
将来のスーパーコンピュータにおいて重要な要素技術であるにも関わらず本白書では
十分に取り上げることの出来なかった事項も存在する．本白書において議論されたロー
ドマップやその他の研究開発課題を含めて，計算科学と計算機科学の協調によるサイエ
ンスロードマップの実現に向けた研究開発を進めていくべきである．
参考文献
[5-1] Rick Stevens et al, A decadal DOE plan for providing exascale applications and
technologies for DOE mission needs
http://science.energy.gov/~/media/ascr/ascac/pdf/meetings/mar10/Awhite.pdf
[5-2] Jeffrey S. Kuskin, et al, "Incorporating Flexibility in Anton, a Specialized Machine for
Molecular Dynamics Simulation," Proceedings of the 14th Annual International
Symposium on High-Performance Computer Architecture (HPCA '08), New York, NY:
IEEE, 2008.
105
付録1. 進行中関連研究課題
プロジェクト名
代表者
種別
開始年度
終了年度
分野
1
ルビーによる高生
産な超並列・超分
散計算ソフトウェ
ア基盤
平木 敬
基盤 S
2009
2013
プログラミン
グ
2
汎用自動チューニ
ング機構を実現す
るためのソフトウ
ェア基盤の研究
須田 礼
仁
基盤 A
2011
2013
数値ライブラ
リ
3
革新的電源制御に
よる次世代超低電
力高性能システム
LSI の研究
中村 宏
CREST
(ULP)
2006
2011
アーキテクチ
ャ, システム
ソフトウェア
4
次世代テクノロジ
のモデル化・最適
化による超低消費
電力ハイパフォー
マンスコンピュー
ティング
松岡 聡
CREST
(ULP)
2007
2012
アーキテクチ
ャ, システム
ソフトウェア
5
ロバストファブリ
ックを用いたディ
ペンダブル VLSI プ
ラットフォーム
小野寺
秀俊
CREST
（ディ
ペンダ
ブル）
2007
2012
アーキテクチ
ャ
6
アーキテクチャと
形式的検証の協調
による超ディペン
ダブル VLSI
坂井 修
一
CREST
（ディ
ペンダ
ブル）
2007
2012
アーキテクチ
ャ
7
フィールド高信頼
化のための回路・
システム機構
梶原 誠
司
2008
2013
アーキテクチ
ャ
8
超高信頼性 VLSI シ
ステムのためのデ
ィペンダブルメモ
リ技術
吉本 雅
彦
CREST
（ディ
ペンダ
ブル）
CREST
（ディ
ペンダ
ブル）
2008
2013
アーキテクチ
ャ
9
自己修復機能を有
する 3 次元 VLSI シ
ステムの創製
小柳 光
正
CREST
（ディ
ペンダ
ブル）
2009
2014
アーキテクチ
ャ
106
10
10 億並列・エクサ
スケールスーパー
コンピュータの耐
障害性基盤
松岡 聡
基盤 S
2011
2015
システムソフ
トウェア
11
高性能・高生産性
アプリケーション
フレームワークに
よるポストペタス
ケール高性能計算
の実現
丸山 直
也
CREST
（ポス
トペ
タ）
2011
2015
プログラミン
グ
12
自動チューニング
機構を有するアプ
リケーション開
発・実行環境
中島 研
吾
CREST
（ポス
トペ
タ）
2011
2015
数値ライブラ
リ
13
ポストペタスケー
ルデータインテン
シブサイエンスの
ためのシステムソ
フトウェア
建部 修
見
CREST
（ポス
トペ
タ）
2011
2015
システムソフ
トウェア, プ
ログラミング
14
メニーコア混在型
並列計算機用基盤
ソフトウェア
堀 敦史
2011
2015
システムソフ
トウェア
15
ポストペタスケー
ルに対応した階層
モデルによる超並
列固有値解析エン
ジンの開発
櫻井 鉄
也
CREST
（ポス
トペ
タ）
CREST
（ポス
トペ
タ）
2011
2015
数値ライブラ
リ
16
ポストペタスケー
ルシステムにおけ
る超大規模グラフ
最適化基盤
藤澤 克
樹
CREST
（ポス
トペ
タ）
2011
2016
システムソフ
トウェア
17
省メモリ技術と動
的最適化技術によ
るスケーラブル通
信ライブラリの開
発
南里 豪
志
CREST
（ポス
トペ
タ）
2011
2016
システムソフ
トウェア
18
ポストペタスケー
ル時代のスーパー
コンピューティン
グ向けソフトウェ
ア開発環境
千葉 滋
CREST
（ポス
トペ
タ）
2011
2016
プログラミン
グ
19
進化的アプローチ
による超並列複合
システム向け開発
環境の創出
滝沢 寛
之
CREST
（ポス
トペ
タ）
2011
2016
プログラミン
グ, 数値ライ
ブラリ
107
20
ポストペタスケー
ルシミュレーショ
ンのための階層分
割型数値解法ライ
ブラリ開発
塩谷 隆
二
CREST
（ポス
トペ
タ）
2011
2016
数値ライブラ
リ
21
シームレス高生
産・高性能プログ
ラミング環境
石川 裕
e サイ
エンス
2008
2011
システムソフ
トウェア, プ
ログラミング,
数値ライブラ
リ
22
研究コミュニティ
形成のための資源
連携技術に関する
研究
三浦 謙
一
e サイ
エンス
2008
2011
システムソフ
トウェア
23
ポストペタスケー
ルコンピューティ
ングのためのフレ
ームワークとプロ
グラミング
ECS: Enabling
Climate Simulation at
Extreme Scale
佐藤 三
久, Serge
Petiton
JSTANR
FP3C
2010
2014
システムソフ
トウェア, プ
ログラミング,
数値ライブラ
リ
Franck
Cappello,
松岡 聡,
佐藤 三
久
Graeme
Ackland,
朴 泰祐
G8
2011
2013
システムソフ
トウェア, プ
ログラミング
G8
2011
2013
プログラミン
グ
24
25
NuFuSE: Nuclear
Fusion Simulation for
Exascale
26
低消費電力メニー
コア用アーキテク
チャとコンパイラ
技術
井上 弘
士
NEDO
2010
2012
アーキテクチ
ャ, プログラ
ミング
27
スパコン・クラウ
ド情報基盤におけ
るウルトラグリー
ン化技術の研究推
進
佐伯 元
司，松岡
聡
概算要
求特別
経費
（プロ
ジェク
ト分）
2011
2015
アーキテクチ
ャ，システム
ソフトウェア
108

2018 年満期円貨建転換社債型新株予約権付社債の120%コール

2018年満期ユーロ円建転換社債型新株予約権付社債の転換

2018年満期円貨建転換社債型新株予約権付社債の転換価額の

メキシコに新会社を設立

73 第10回 （メモリアーキテクチャ、キャッシュメモリと仮想メモリ1）

小形風車型式認証登録簿

オイラックスクリーム 10% オイラックスHクリーム

「パリ協定」第一回特別作業部会終了 いよいよルール作りが始動！

1 財務的な課題とクラブへの支援改善の必要性を