YOU ARE DOWNLOADING DOCUMENT

Please tick the box to continue:

Transcript
Page 1: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

コンピュータアーキテクチャ・コンパイラ・システムソフトウェア作業部会における検討の中間報告

石川裕(東大)

丸山直也(東工大)

石井康雄(東大)

2011/11/28

中間報告@第7回HPCI推進委員会

1

Page 2: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

まとめに向けて

1. はじめに (1PPT)– 目的・趣旨

2. サイエンスロードマップ(科学的・社会的課題)(5PPT)– Science分野ごと(20?)に計算科学技術により5~20年後に達成すべき科学的・社会的課題を整理

3. コモディティアーキテクチャ動向(1PPT)4. アプリケーション(5PPT)

– 5~10年後の課題達成に必要なアプリケーションとそれを実現するためのアーキテクチャに対する要件

5. アーキテクチャ技術開発目標(5PPT)– アーキテクチャパラメータに応じてアーキテクチャを分類、2018年前後に実現可能な仕様

6. 研究開発ロードマップ(5PPT+5PPT)– 検討 (Feasibility Study) すべきシステムの実現に向けて必要となる技術的課題ならびにロードマップ

– 複数のアーキテクチャについてFSの可能性があるというまとめになる。ただし、報告書に示す複数アーキテクチャすべてについてFSをすべしという報告書になるのではなく、あくまで、技術的観点での候補を

示しているにすぎないという立場。

7. 今後の推進体制(1PPT)– 公募により産学官連携チームを作るべしというのは、HPCI計画推進委員会のWGにおいて提言されて

いることなのでこれは踏襲。

• 附録

– アプリ側詳細

– システム側詳細 (もともとSDHPCで考えていたものが基本)

2011/11/28 2中間報告@第7回HPCI推進委員会

Page 3: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

1. はじめに

• 作業部会でのプロセス

– 2018年頃、現在技術の延長、すなわち、国が新たなる研究開発をしなくても達成できるアーキテクチャの分類とシステム性能値を予想 (20~30MW、1000平米)

– アプリ作業部会において、どのアーキテクチャがよりアプリケーション実行に適しているか検討

– 新たなるアーキテクチャ:コンパイラ、OS、ミドルウェア、プログラミングモデ

ル・言語、数値計算ライブラリの研究開発課題について検討

• 未達

– 開発目標の設定は出来ていない。どこまで踏み込むか?

• サイエンス毎に基本となるアーキテクチャを設定するのか?汎用性を重視するのか?

– 求められる性能、メモリ容量、

– 利用イメージが出来ていない

– 実時間性を有するアプリケーションの検討は今後

2011/11/28 中間報告@第7回HPCI推進委員会 3

Page 4: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

総演算性能PetaFLOPS

総メモリ帯域PetaByte/s

総メモリ容量PetaByte

汎用(従来型) 400 40 40

容量・帯域重視 100 100 100

帯域・演算重視 1000 500 0.2

演算重視 2000 10 10

3. コモディティアーキテクチャ動向

• 2018年ごろ、現在技術の延長で、新たなる革新的ブレークス

ルーがなく達成できるシステム性能値を予想(現在はラフスケッチであり、今後精査必要)

• アーキテクチャの研究としては、本分類のいずれかのアーキテクチャを研究開発すべきというメッセージではない。これをベースにアプリケーションがどういうアーキテクチャによりフィットするか検討し、さらによいアーキテクチャをFSすべきである。

2011/11/28 中間報告@第7回HPCI推進委員会 4

プロセッサ: 最大(20MW)システム性能値の例

InjectionGB/s

P-to-PGB/s

BisectionPB/s

Min.遅延nsec

Max 遅延nsec

High-radix (Fat Tree)

32 32 2.0 200 1000

Low-radix(4次元トーラス)

128 16 0.13 100 5000

総容量 総帯域

1 EB~4EB 20TB/s~50TB/s

総メモリ容量(10PB~40PB) の100倍

メモリ容量を1000秒でローカルデバイスに退避

ネットワーク ストレージ

Page 5: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. 技術課題「アーキテクチャ」

2011/11/28 中間報告@第7回HPCI推進委員会 5

消費電力:20~30MWの電力でサイエンスドリブンマシンの実現 (20~30 pJ / flop)

課題項目

• 電力効率に優れたアクセラレータ(Throughput Core)を導入

• プロセッサ性能増大に対するメモリ性能(Byte/Flop)およびメモリ容量の向上

• 低電圧・低周波数による性能限界に対して超大規模並列化およびストロングスケーリング

• 電力効率を現在の60倍にするための低

消費電力化

• アプリ・システムソフトウェアとのCo-designによるアーキテクチャ設計

ヘテロジニアスアーキテクチャ:•Throughput Core導入方式の検討•Latency CoreとThroughput Coreの結合方式・データ共有方

深い記憶階層:プロセッサ内データ移動の削減方式の検討• 並列計算モデルの選定とそれに適したコア間接続・メモリ階

層• アルゴリズム毎への最適化機能

再構成メモリ階層、スマートメモリ、リコンフィギャラブル技術• 3次元積層DRAM• 次世代NVRAM (PCRAM, MRAM,…)

低消費電力化の検討• 新デバイスの検討:半導体微細化、トライゲート、SOTB、不

揮発メモリ、極低電圧回路、3次元積層。これらに対応したアーキ技術(ばらつき影響の緩和、信頼性低下への対策など)

• メモリ・インターコネクトの低消費電力化• システムレベル電力制御による性能/電力効率の大幅改善

大規模並列・ストロングスケーリング・ネットワーク の検討• 通信遅延削減 (ネットワークインターフェイスのCPU統合等)• トポロジとルーティング• 集団通信支援• 耐故障・信頼性に対するアーキテクチャ支援Cross Cutting 課題項目

• 耐故障

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

• メモリ階層

• 大規模並列性

• 大規模ストレージ

Page 6: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. 技術課題「システムソフトウェア」

2011/11/28 中間報告@第7回HPCI推進委員会 6

スケーラビリティ、互換性&標準化、耐故障

課題項目

• ヘテロジニアスアーキテクチャ対応

• O(100K)~O(1M)超大規模並列システ

ム対応

ヘテロジニアスアーキテクチャ対応:•Throughput Core上のOS

小規模キャッシュ上でのキャッシュアウェアOS•Latency CoreとThroughput CoreのOS処理負荷分散方式

•ポータビリティおよび標準化の考慮POSIX互換OSとするか軽量APIを提供するか。新

規APIは国際標準が原則

超大規模並列システム対応• OSノイズの除去

• 低遅延非同期通信ライブラリ• 高性能ファイルI/Oシステム

• 細粒度電力制御• スケジューリング• 耐故障性

アプリケーションプログラムレベル耐故障プログラミング支援

Page 7: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. 技術課題「プログラミングモデル・言語・フレームワーク」

2011/11/28 中間報告@第7回HPCI推進委員会 7

性能と生産性の確保

課題項目

• 様々なヘテロジニアスアーキテクチャの隠ぺい

• 階層的大規模並列計算環境を効率的に利用

• 複雑化するメモリ階層の隠ぺい

• 故障時対応を容易にプログラミング

• 電力制約下での性能最大化

• デバッギング・性能チューニングのためのツール

フレームワークの提供:•アプリケーション記述時に必要となる典型的機能や枠組みを提供し生産性と性能を確保する

例1: 流体向けフレームワークOpenFOAM

• 離散化、データ入出力、など共通計算パターンを抽出しライブラリとして提供

例2: 非構造計算向けフレームワークListz

• 計算したいこと(WHAT)を記述し、計算の仕方(HOW)は記述させない。各種アーキ

テクチャ向け実行コードを自動生成•アプリケーション分野との協業が必須

普及に向けての取り組み:•成功体験・キラーアプリケーション•ポータビリティ•継続的支援•教育•標準化

アプリケーション移行支援:•これまでに蓄積されてきた膨大なソフトウェア資産の継承•現状維持では性能向上困難 段階的・システマ

ティックな移行を支援例1: 注釈によるプログラム並列化支援

•XcalableMP: 逐次プログラムの注釈によるPGAS化•OpenACC: 逐次プログラムの注釈によるGPU対応

例2: リファクタリングツールの整備

Page 8: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. 技術課題「数値計算ライブラリ」

2011/11/28 中間報告@第7回HPCI推進委員会 8

課題項目

• 通信量およびメモリアクセス回数の削減

• 演算精度

• ライブラリインターフェイス

• 耐故障性

通信量およびメモリアクセス回数の削減:•通信最適化

• AllgatherやAllreduce等の集合通信を避けた

ライブラリ(アルゴリズムの変更が必要)• 通信(回数またはデータ転送量,またはその両

方)を最小限にしたアルゴリズム• 通信量を増やしてでもレイテンシの影響を削減

し,通信時間を削減する通信方式

•演算量を増やしてでも通信量やメモリアクセス回数を削減するアルゴリズム

演算精度:•高精度計算(大規模並列化に伴う演算精度保障)•Byte/Flop減少に伴う単精度・倍精度混合演算およ

び精度保証•精度確認機能

ライブラリインターフェイス:•既存アプリケーションプログラムからの移行コスト低減•ヘテロジニアスアーキテクチャでも,同じAPI提供•ノード数増加に伴う最適データ分散が変っても、同一API提供

耐故障性:•数値計算ライブラリレベルでの耐故障機能の検討

• 例:分散行列におけるパリティノード

Page 9: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. 技術課題「Cross-Cutting & Co-Design」

2011/11/28 中間報告@第7回HPCI推進委員会 9

設計項目

• アーキテクチャパラメータ探索

• システムソフトウェアによるヘテロジニティ(Latency&Throughput Cores)の隠ぺいと最適実行

• ネットワーク

• 低消費電力、信頼性、耐故障性

アーキテクチャパラメータ探索:•アプリの性能を最大限に引き出すアーキパラメータの検討が必要•アプリとの連携が必須 → 「議論」ができる環境の整備

システムソフトウェアによるヘテロジニティの隠ぺいと最適実行:•SIMD化: 演算効率向上、レイテンシ隠蔽、命令処理の

電力削減•マルチスレッド化:演算効率向上、レイテンシ隠蔽•分岐命令の除去(predicationの利用)

•ローカルメモリの利用、グローバル同期の削減、•コンテキスト退避の除去(軽量スレッドの活用)•メモリ階層の利用

アプリケーション、システムソフトウェア(ライブラリ、言語モデル・フレームワーク、OS)、アーキテクチャのCo-Design

ネットワーク:•片側通信・ノンブロッキング集合通信の活用 → ライブラ

リ整備•必要に応じたLow-Level APIの利用

例:PGAS言語+MPIのハイブリッドプログラミングで

のリソース管理•同期・集合演算などの専用ハードウェアの利用

L3/L2/L1 L2/L1 L2 L3のみenergy energy energy energy

演算回数 pJ 10.500 10.500 10.500 10.500RF Read pJ 5.876 5.876 5.876 5.876RF Write pJ 2.912 2.912 2.912 2.912L1 Read pJ 2.268 2.268 0.000 0.000L1 Write pJ 0.900 0.900 0.000 0.000L2 R/W pJ 2.180 2.180 17.600 0.000L3 R/W pJ 4.200 0.000 0.000 176.000Mem R/W pJ 3.990 30.300 30.300 3.990Total pJ 32.826 54.936 67.188 199.278

ブロッキング

例:DGEMMの1演算あたりの消費エネルギー(制御系を除いた演算のエネルギー試算値・30nm世代)L1/L2/L3を使ったブロッキングの方がL3のみでブロッキングをするよりも消費エネルギーが1/5程度で済む

Page 10: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

6. ロードマップ (未完成)

2011/11/28 中間報告@第7回HPCI推進委員会 10

2011 2012 2013 2014 2015 2016 2017 2018 2019 2020JST CREST: ポストペタスケール高性能計算に資するシステムソフトウェア技術の創出

アプリケーション

1期2期

3期

HPC技術の高度化のための

調査研究

ライブラリ

プログラミングモデル・言語、フレームワーク

OS、ミドルウェア

アーキテクチャ・コンパイラ

Page 11: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

7. 今後の体制 (議論中)

• サイエンスドリブンにシステムソフトウェアからアーキテクチャまでをco-designできる継続的体制と

なっていること

– 国の推進委員会としてもサイエンスドリブンが対外的に見える体制とすべき

• 2018年前後の運用開始実現性を有すること(製造技術の裏付け)

• 産学官連携が重要である( HPCI計画推進委員会のWGにおいて提言)

• 採択課題間での協力体制を作るべき

– アプリケーションの特徴抽出などの共通項

• 産業界への下方展開が考慮されている提案であること?

• 課題数を言うべきなのか?

• Feasibility Studyとして求められる内容案

– 社会的要請とサイエンスロードマップの精査

– サイエンスドリブン目標性能の設定

– ベンチマークセットの開発

– アーキテクチャ概念設計・評価・検証

– ソフトウェア課題精査

– (予算に応じた)要素技術のプロトタイプ開発

• ソフトウェア・ハードウェア

– 開発計画および開発予算。購入設置予算、運用経費2011/11/28 中間報告@第7回HPCI推進委員会 11

Page 12: コンピュータアーキテクチャ・コンパイラ・ システムソフトウェア … · – 複数のアーキテクチャについてfsの可能性があるというまとめになる。ただし、報告書に示す複数アー

ロードマップ参加者

• アーキテクチャ

– 塙 敏博、佐野 健太郎、鯉渕 道紘、佐藤 幸紀、石井 康雄、近藤 正章、安島 雄一郎、井上 弘士

• システムソフトウェア

– 清水、松葉、宇野、高野、野村、實本、今田、南里、鈴村、三浦、建部、佐藤、山本、大野、安井、滝澤、遠藤、鴨志田、竹房

• プログラミング

– 丸山直也、滝沢寛之 、中尾昌広、千葉滋 、田浦健次朗 、八杉昌宏、平石拓、窪田昌史

• 数値計算ライブラリ

– 須田、片桐、小野、伊東、高橋、岩下、大島

2011/11/28 12中間報告@第7回HPCI推進委員会


Related Documents