1999年4月1日

Petaflops II 報告


東京大学理学部情報科学
小柳義夫
oyanagi@is.s.u-tokyo.ac.jp
 

PETAFLOPS II, 2nd Conference on Enabling Technologies for Peta(fl)ops Computing と言う会議が、1999年2月15−19日に、Santa Barbara, CA の Doubletree Hotel で開催された。DARPA, DOE/Defense Programs, DOE/Science Office, NASA, NSA, NSF, NIHがSponsors として 名を連ねている会議である。参加者は約100人。Supercomputing XYの常連 (Jack Dongarra, Steve Ashby, David Baily, Adolfy Hoisieなど)もたく さんいた。筆者は、日本学術振興会未来開拓「計算科学」研究推進委員会 からの調査ということで参加させていただいたので、ここに概略を報告し たい。詳しくは、web page http://www.cacr.caltech.edu/pflops2/ およ びそのうちに発行される Proceedings を参照していただきたい。

 

1.Petaflops 計画とは

人類が1 Tflops (64bit演算で)を実現してまだ1年余りにしかならない のに、その1000倍のPetaflops を2010年までに実現しようとする計画がア メリカで進められている。この計画自体に予算が付いたわけではないが、 この会議のsponsorsとなった研究機関が調査の予算をつけている。

この会議は2回目であるが、第1回は1994年2月22-24日にPasadenaの Doubletree Hotel で開かれた。第1回の記録が "Enabling Technologies for Petaflops Computing" edited by T. Sterling, P. Messina and P. H. Smith としてMIT Press から発行されている。ちなみに、この本の日 本語訳が「ペタフロップス・コンピュータ」(小林 達・栗本 武訳)とし て1997年7月に筑波出版会から出版されたが、この出版社はその後破産し てしまった。この会議でも、前回の報告書が日本語訳されたことが話題に なり、「いったい誰が買ったのだ」などと質問された。今回までに様々な ワークショップが開かれている。

1995年8月 Summer Study
1996年4月 Architecture Workshop
1996年6月 Software Workshop
1996年10月 Petaflops Frontier 2
1997年1月 Layered SW Workshop
1997年4月 Algorithms Workshop
1998年6月 Petaflops-systems Operations Working Review

これらの活動の総まとめがこの会議であった。なお、今回は初めてのオー プンな会だとのことである。

ざっとした印象としては、アーキテクチャ屋がえらく元気だったのと対 照的に、アプリケーション屋が元気がなかった。

2.Santa Barbara について

Santa Barbara は、Los Angeles の北西約150キロの海沿いの都市で、 金持ちの街として知られている。スペイン風の赤い屋根(赤い半円筒形の 瓦を凹面・凸面を口語に組み合わせて並べたもの)と白い壁のスペイン植 民地風の建物が目立つ、落ち着いた小さな町である。開会が15日(月曜日、 president dayで休日)の夕方だったので、昼間down town (State Street) まで歩いて行ったが、ショッピングモールは大変な人だかりであっ た。裁判所(Santa Barbara County Courthouse) が公開されていた。ダウ ンタウンと海岸通りには、1回25セントの電気自動車のミニバスが走って いた。昼は20度台(mid seventy)まで上がることもあるが、朝晩は2〜4度 にまで下がる。

Dobletree Hotel は海岸沿いのリゾートホテルで、昔は Fress Parker Red Lion Resort と呼ばれていたようである。かなり大きなホテルで、普 通は1泊200数十ドルもするようである。我々以外にも多くの客が入ってい た。

3.16日午前

3.1 Paul Messina (DOE) "Welcome"

会議はConference Chair のPaul Messina (DOE) の歓迎の挨拶で開会し た。彼は、この会議が前回以来の5年間の活動の総決算であり、The End of the Beginning であることを強調した。さらに、今回が初の open meeting であることを指摘した。

3.2 Paul H. Smith (DOE) "Petaflops Initiative"

続いてSteering Committee Chair のPaul H. Smith (DOE)が5年間の歴 史を回顧した。10年前にはTFlops の先を考えた人はいなかったが、現在 では6つの政府機関が支援している。また多くのコンピュータ会社の技術 者も本気で考えている。ASCI project では、2004年に100TFlopsを実現す ることになっている。1996年12月4日にASCI Red が初めてTera Flops を 実現した。

3.3 Thomas Stirling(CACR CalTech and NASA/JPL) "Goals and Agenda"

続いてProgram ChairのThomas Stirling が、この会議の目標と問題点 を解説した。93年にNASAからPetaflopsをやれと言われたが、当時 Teraflopsも実現していなかったのにPetaflopsなんてバカだと思われてい た。しかし、6回のワークショップと8通りのdesign studiesにより段々方 向が見えてきた。ASCIでTeraflopsも実現し、PITACの勧告もあり、もはや 夢ではない。High End Computingの将来が不安な点が気がかりだが。

この会議の目標は、我々の新しい理解を検証し、研究の成果を示し、競 争関係にある観点を整理し、可能な選択肢について新鮮な議論を行うこと である。特に、interdisciplinary であることが重要である。

3.4 Ken Kennedy (Rice), Keynote Address I

この会議には基調講演が2つ用意されていたが、1番目はPITAC (Presidential Information Technology Advisory Council)の共同議長 (もう1人はBill Joy)であるProf. Ken Kennedy (Rice University)であっ た。かれはまず、今週だかに発表するPITAC最終報告の骨子を紹介した。 だいたい中間報告と同じで、アメリカの連邦政府の情報分野の方針が、 「長期的というより短期的であり」「基礎的というより応用的であり」 「リスクのないテーマばかりやっていた」と批判し、これを逆転すべきこ と、予算を倍増($2B/yearに)し、NSFを中心とすべきことを主張した。

そのPetaflopsに対するimplicationとして、予算が増えるだろうと言う こととともに、ソフトウェアの重要性を強調した。2007年にPetaflopsが できるとすると、104〜105個のプロセッサで、プロセッサ当たり10〜 100 GFlopsとなるであろう。おそらく10レベルほどの深いメモリ階層が存 在し、大きなlatencyの並列性をうまく利用しなければならない。これは ソフトウェアにとって大問題である。prefetchingやblockingといった技 法はregular problemには有効であろうが、重要なのはirregularな問題で ある。

3.5 Andrew While(LANL) "Petaflops and Society"

休憩のあと、Andy WhiteがSocial-scale Applications for Petaflops Computingという講演を行った。Petaflopsに相応しい応用とは、従来の科 学の枠を越えるようなものである。すなわち、社会の生活、財産、福祉、 安全に関係する問題を解決することである。IPCC (Intergovernmental Panel for Climate Change)のアセスメントによると、2003年には気象予 測のために40 TFの計算能力が必要とされる。大気海洋結合モデルでは、 現在使われているT42というメッシュ(300 km間隔)では64台のOrigin2000 を用いて、1世紀当たり2週間掛かる。これを30 kmメッシュで、二酸化炭 素、エアロゾル、雲、太陽輻射などの効果を考慮にいれて精度を上げると、 1 PFの能力が必要になる。山火事のような問題では、短時間に実時間より 速く計算しなくてはならない。

このような社会のインフラに関わる問題はいろいろある。例えば電力系 の問題がある。これは年間$230Bの産業である。world-wide restructuringが必要である。需要への応答は秒の単位だが、建設には何 年も掛かる。政策決定は大問題である。また山火事や伝染病のような場合 には、危機のの同定のためには、Petaflopsコンピューティングだけでは なく、調和のとれた監視体制が必要であり、また現在の計算システムに比 べて格段にレベルの高いRAS (reliability, availability, serviceability) が要求される。人間の生死に関わることであるから、こ のようなシミュレーションに内在する不確定性の定量化が重要である。最 終的には、意志決定のプロセスの中にこのようなツールを組み込まなくて はならない。Edward Wenckが1977年にすでに"Political Limits to Forecasting"について述べていることは意味深い。

3.6 Thomas Stirling, "Challenges and Opportunities"

続いてProgram ChairのThomas Stirlingが、この会議の目的を定義し、 過去の歴史と関連づけて説明した。この会議の目的は、ペタフロップス級 のコンピュータ技術の現状に関するコンセンサスを確立し、実用的なペタ フロップスコンピュータシステムを実現するための今後の研究方針を決定 することである。

ここで1994年のPetaflops IにおけるSeymour Cray氏の基調講演の貴重 なビデオが上映された。ご存じのように、Cray氏はこのころクロック1 ns のCray-4を発表し意気揚々としていた。同時に、政府筋からの注文でSIMD のような機械(暗号解読用?)をも開発していた。しかし、彼の会社Cray Computer Corporationは、95年3月に倒産してしまった。そして彼自身も、 96年9月にコロラド州のインターステート25号でチェロキーを運転中事故 に巻き込まれ、2週間後の10月5日に亡くなられた(71歳)。

Stirling氏は、多くのCを高める必要性を強調した。

  1. capability---computing, storage, bandwidth
  2. cost---component, complexity
  3. consumption of power
  4. concurrency
  5. cycles of latency
  6. customer and C(K)iller applications (この辺の語呂合わせは苦しい)
  7. confidence

おそらく1つのノードは、3 GHz 10 GFであろう。これを105個並べれば ペタフロップスになる。しかし、

  1. アーキテクチャは重要である。特にバンド幅、レイテンシー、オーバー ヘッド
  2. memory requirements
  3. MPP very difficult, COTS (commercial off-the-shelf) interprocessor load balancing

未解決の問題としては、

  1. network of processors/memory 限られたtransistorsの有効な利用法
  2. アーキテクチャの議論は本当に収束するのか。
  3. 半導体技術は何mまで行くのか。
  4. alternate technologies/fabrications? 超伝導、DNA?
  5. どの程度のlatencyまで耐えられるのか?
  6. 言語は?
  7. プロセッサの粒度? fat and many or fat and few?

集合写真を撮ったあと、Plaza del Sol(円形の中庭)で昼食。スペイ ン風のシーフード。

4.16日午後

午後はアーキテクチャのセッションであった。結局3つの路線を中心に 議論されているようだ。一つは、COTS (commercial off-the-shelf)とい う路線で、2007年の商用チップ等は相当進歩しているので、これを組み合 わせてペタフロップスを実現しようという非常に保守的な路線である。次 がPIM (Processor-in-Memory)を中心にした路線で、メモリのバンド幅が 問題だから、プロセッサとメモリを同一チップにおいてこの問題を解決し ようという方向である。もう一つが、HTMT(Hybrid Technology with Multi-Threading)という路線で、超伝導、PIM、opticalなどあらゆる技術 を総動員し、multithreadingでlatencyを克服しようという路線である。 何とも奇怪で、とても実現しそうにもないが、結構人気を博していた。

4.1 Steve Wallach "Architecture Introduction"

まずはじめに、Steve Wallachがアーキテクチャに関する総括的な話をし た。彼はConvex社の創立者で、現在はCenterPoint Venture Partnersに属 している。

目標は、10年後にASCI級のシステムを、ASCI級のコストで創ること。で ある。すなわち、8192ノード(でもノードとは何だ)で、$100Mのコスト。 SIA(米国半導体工業会)の予測(http://notes.sematech.org)によると、 2009年には、0.07mの技術、チップ上で6 GHz、die間で2.5 GHz、DRAMなら 64 Gb、SRAMなら8 Gb、MPUなら520M transistors、2500 external siganl pinsであろう。

この仮定で設計すると。コアは25 GFlops、これはVLIWかRISCであろう。 2L cacheは100 MFlops当たり1/4〜1/2 MB必要だから96 MBで、プロセッサ との間は64bで結合し160 GB/sのバンド幅。外へは256 pin, 2.5 GHzで80 GB/s程度の幅。0.6〜0.9 Vの駆動で170Wの消費電力。

もし、チップ内に4 CPUのSMPを作るなら、クロスバと96MB 2L cacheと、 チップ間の光結合(multi wave length, 640 GB/s)を組み込める。

COTS PF systemとしては、die当たり4 CPUで120 GFlops出れば、8192 diesで1 PFlopsが実現する。電力は8192×200W=1.6 MW。外部メモリ(お そらく2レベル)を512 TBとするとさらに電力が3 MW必要。1 rack当たり 12 TFlopsとして、光結合はOC768(40Gb/s)が必要。光スイッチを使う。 Bisection bandwithは50 TB/s。

4.2 Tilak Agerwala (IBM), "Advance MPPs"

続いてAgerwalaが、Power路線の延長でPetaflopsができると講演した。 Power 4は、£0.18m、1 GHz(4 GFLops)、32 wayのnode、つまりnode当た り128 GFLops。大きなL3 cacheを置く。新しいスイッチは、バンド幅で4 倍、リンク数で2倍。一種のNUMAになる。

2008年には、2 GHz(8 GFLops)、ノード当たり128 CPUとすると、512 nodesで(半)Petaflopsになる。電力は3〜4MW。

メモリレイテンシは、サイクル当たり10倍悪くなり、バンド幅はSMP構 成のため5〜10倍悪くなる。並列性は150倍(すなわち80K以上のthreads) が必要。プロセッサもメモリも階層構造を持ち、データの局所性が問題に なるであろう。

4.3 Peter Kogge (Notre Dame), "PIM-based architecture"

本当はここでBurton Smith (Tera Computer)がmultithreaded architectureの話をするはずだったが現れず、PIMに移った。

SIAのroad mapを見ると、partsの個数はどうにかなりそうだが、相互結 合が問題である。サイクルが急速に増大するので、レイテンシが大問題。 そこで、logicとDRAMを同居させることが考えられる。設計においては、 バンド幅、メモリ量、MFlopsのバランスが問題。新しいメモリの semanticsも必要になる。このようなチップの呼び方だが、我々は PIM(Processor-in-Memory)とよぶが、BerkeleyではIRAM(Intelligent RAM)という(日本の話は出なかった)。

DRAMの構造の話の後、PIMにすればレイテンシは10倍、バンド幅は100倍 となり、一つまたは複数のコンピュータノードがチップの中に入れられる。 すでにいろいろな実験が行われている。シリコン何とかとか、Samsungな ど。

インターフェースが問題。チップ間、多重PIMチップシステム間、PIMと non-PIM subsystem間など。

PIMをどう使うかについてもいろいろな考えがある。fetch-and-addのよ うなatomic命令はPIM上では特別なものでなくなる。PIMとCPUをどう使い 分けるか、単独の命令セット体系の中で互いに独立、独立だが共通の命令 セット、CPUがPIMのcoprocessor、PIMだけで構成、などいろいろある。 ASAP(at-the-sense-amp.) logic も使える。ASAP ISA(instruction-set architecture)についての選択肢:pure SIMD, data driven ALU, VLIW-like, multi-threading for local latency hidingなど(よく分か らず)。

SRAM PIMとDRAM PIMとの分業?

"Architecture is fun again."と結んだ。

4.4 Greg Chesson (SGI), "Interconnects Scaling and Evolution"

続いてChessonが、あらゆるレベルの相互接続のスケーリングについて 論じた。大規模システムはCPUスピードもメモリ容量も増大するので、階 層構造のレベル数が増える。Mooreの法則はすべてに当てはまるわけでは なく、部分ごとに異なる速度で進化する。チップ内のアーキテクチャとし ては、micro-interconnect problemとmemory system interconnect problemとがある。チップ外では、光接続が重要になる。ペタフロップス システムとして、CPU= 10〜100 GFlops、CPU数=105〜104と仮定すると、 内部接続と外部接続とを融合せざるをえない。

baseline technologyとして
packaging 1500 R 3000〜5000
logic 1 GHz→4〜10 GHz
memory 1〜4→10〜80 GB/s on chip
signal 1〜2→4 GHz/channel
launch rate 1.5 M→10 M/sec

筐体間は現在HIPPI-6400が最高だが、次世代はもっと上がるであろう。 OSやAPIとの関係も重要。

結論として、「ペタフロップス用の相互接続は、通常の接続技術で可能 である。」

4.5 Thomas Stirling, "Hybrid Technology Approach to Petaflops Computing"

アーキテクチャのトリとして、HTMT (Hybrid Technology Multi-Threaded) architectureの講演があった。これは、超伝導、PIM、 光接続、光記憶など異種の技術を組み合わせて、ペタフロップスを実現し ようという構想である。つまり、電力、コスト、複雑性などを考えると、 適材適所に技術を使うことが重要だという。とても実現出来そうには思え ないが、この会ではペタフロップスの正道として語られていた。くわしく は、HTMTだけのワークショップがあったのでそれを参照。

構想によれば、このシステムはヘリウム温度部分、液体窒素部分、常温 部分に分けられる。ヘリウム温度では、超伝導を使ったRSFQ (Rapid single flux quantum) logic とCRAM (Cryo-RAM)を使う。RSFQがどんなも のかは理解していないが、後藤英一先生のquantum-flux parametronとの 関係が注目される。超伝導なので、0.25mで200 GHzが実現できる。Nb on Siの0.8mでも100GHz, 100K gates/chipが実現可能。ただし、外部との接 続は33 GHz。4096個でペタフロップスが実現できる。もし、150 GHz, 600 GFlopsが出来れば2048個で十分。CRAMは16K個で512 MB。

液体窒素温度にはSRAM PIMを置く。16 K個で1 TB。ヘリウム温度との接 続には、高温超伝導の線を使う。

液体窒素からは光で外に接続し光パケットスイッチ(data vortex optical interconnect)経由でDRAM PIMをつなぐ。32 K個で16 TB。さらに HRAM(holographic 3/2 memory)を1 PB置く。Diskは10〜100 PB。テープロ ボットは、100PB〜1 EB。

このシステムは比較的低価格で、効率もよく、プログラムも容易 (global shared memory and hierarchical parallel thread flow control model)。本当か? 全体で2.4 MW。

4.6 Panel

このあと、これらの講演者の間でパネル討論が行われた。Petaflopsマ シンを集めてExaflops マシンが作れるかとか、市場はあるかとか議論さ れた。「ENIACのときも、Cray-1のときも、世界に数台あれば十分と言わ れた」

4.7 Birds-of-a-Feather Session "Meeting the PITAC Challenge"

夕食後、PITAC答申に関するインフォーマルミーティングが開かれた。 Ken Kennedyが帰った後だったので、あまり盛り上がらなかった。

5.17日(水曜日)午前

水曜日午前中は素子技術について議論した。

5.1 Arnold Silver (TRW), "Technology Introduction"

Device technologyについての、Petaflops Iからの議論を総括した。4 つのWGが開かれた。Architecture WGでは、clock speed, cost, diameter/clock, levels of memory hierarchyについて議論した。Device technology WGでは、半導体の先進技術(GaAsは未成熟)、光素子、超伝 導などについて議論した。

2000年前後には、resonant tunneling device (RTD)、 metal-semiconductor transition, opto-electronics, nano-technology, single-electron transistors, quantum dots, biological systemsなど が登場する。

量子計算は現実的な素子技術になるか疑問。

5.2 Ken Wang (UCLA), "Off the SIA Roadmap"

SIAによれば、CMOS技術は3年に1世代進んでいる。CMOSは、コスト、機 能性/密度、発熱、性能の面で優位である。現在、10〜20nmのサイズまで 実証され、今後も10年はこのスピードで進化するであろう。

roadmapより上に行くには、3次元実装、量子素子、新しいアーキテクチャ、 新しい材料(SiGeなど)、vertical MOSFET, patterningなど。

相互接続の問題、3D integration, ISX fabrications, nanoelectronics architecture, quantum computingなどが重要。

5.3 Konstantin Likharev (SUNY, SB) "Cool-O: Design of an RSFQ Subsystem for Petaflops-scale Computing"

RSFQ (Rapid Single Flux Quantum) logic の研究者のリストの中に、 日本人や日本の研究所があった。Y. Kameda, M. Maezawa, S. Yorozu, ... , ETL, NEC. U. Tokyoなど。

CMCM (Cool Multi-Chip Module)の絵を示した。room temperature interface pins (16K)というのがすごい。NECなども協力しているとこの こと。

switching networkはself-routingでなければならない。このスピード では同期は不可能。

  1. 1.2 ps pulse, 6 ps async., 15 ps sync., 30 ps CRAM
  2. Processing element (SPELL): 64 bit words, 16 threads, 250 GFlops, 15W(at refrigerator)
  3. Cryo-RAM: 1 MB, 15 mW(at 4K), 5W(at refrigerator)
  4. Cryo-network Cool-O, 512 CMCM, 200W@4K, 100KW@room temperature

5.3 Jon Sauer, "Optical SAM" メモなし

5.4 Hans Coufal (IBM), "Holographic Storage, Dream and Reality" メモなし

5.5 Lynn Abelson (TRW), "Superconducting Logic Manufacture"

問題は、チップの製造、パッケージ、電力、インターフェース、局所メ モリなど。NECは4 Kb RAMを製造。超伝導チップの製造可能性の問題、接 続、はんだ、I/O (fiber, WDM, ribbon cable, ...), assembly/repairablility, 3D socket, cooling, ....

結論、"Technology aggressive, yet achievable. Fabrication tools exist, yield yet unknown."

6.17日(水曜日)午後

水曜日午後は、応用について討論した。

6.1 Rick Stevens (ANL), "Applications Introduction"

種々の応用をPetaflopsへ向けての準備状況から分類した。

量子計算については、デバイス、プログラミング、アルゴリズム、シミュ レーションが問題である。

計算電子工学では、デバイスモデル、回路モデル、材料モデル、プロセ スモデルが問題である。

計算神経科学では、現実のニューロンのシミュレーション、コネクショ ニストモデル、実現可能性。

計算生態学、計算経済学、地球惑星物理学、ウェブマイニング、計算認 識論などなど。

6.2 John Salmon(CalTech), "Cosmology Tree-codes"

109個の粒子のN体問題を104steps実行するには、1.5 PFlops・hour の計算量が必要。ペタフロップスの計算機は多くのメモリ階層を持ち、 latencyは106も違うが、

PC disks / PC CPU = 10 ms / 2 ns = 5×106
HTMT DRAM / HTMT CPU = 100 ns / 0.004 ns = 2.5×104

であるから、HTMTはPCをout-of-coreで使うよりは条件がよい。

Tree codeは空間的局所性があり、メモリ階層が多くても大丈夫。問題 は粒子のソーティングで、多分、CRAMでのbucket sortが有効であろう。

6.3 Bill Shelton (ORNL), "Materials Science"

スケールの違いが問題。density function theoryによるlocal density approximationが中心。複雑なエネルギー面の計算。昨年のGordon Bell Awardsは1500 PEのT3Eを用いた、1.02 TFlopsの計算であった。この分野 はPetaflops向きだと言いたいらしい。

6.4 Marks Sears (Sandia NL), "High Performance Electronic Structure Calculations"

非経験密度関数理論に基づく電子構造計算法の困難と成功について述べ た。並列処理により高速化し、スケーラビリティを実現した。現在のMPを 用いて、数千個の原子を含む問題を現実的な時間で計算することができる。 固有値の計算がネックである。

6.5 Robert Harrison (Pacific North-West National Lab), "Scaling Computational Chemistry to Petaflops Computers"

6.6 Paul Woodward (Minnesota), "Issues of Building Applications"

プログラミングの易しさの問題について議論した。結局Petaflops machineはDSMのクラスタと見ることができる。MPIはポータブルだが、ハー ドウェアの特徴を活用できない。threads-based programmingはメモリの distributed nature を扱える。この二つを組み合わせて、new portable programming modelを構築する。それは、hierarchical shared memoryに 基づき、MPIの上につくり、数MBに最適化したput/getを用意し、shared memory modelをもちいて単純化する。(どのようなものかはよく分からな かった)

Virtual Petaflops machineは、SMPかPSMのクラスタで、latencyもband widthも異なる4段のメモリ階層(coherent cache, local shared memory, global shared memory, global disk system)を含む。NCSAの例、 l(DSM)/l(CPU)=1200000.

プログラマは共有メモリを好む。だから、shared memory but private workspaceがよい(VPP Fortranみたいなものか?)。重要なのはバンド幅 でレイテンシではない(本当か?)。応用プログラムは、大域共有メモリ への非常に粗粒度なアクセスをするよう再構成しなければならない。 OpenMPのdirectivesが必要なシンタックスを与える。

6.7 Application Panel

このあと午後の講演者による応用に関するパネル討論が開かれた。寝て いたのかつまらなかったのか、メモはなし。

この日の夕方は、ホテル内でBanquetが開かれた。

7.18日(木曜日)午前

木曜日の午前は、アルゴリズムのセッションであった。机上の空論も多 かった。

7.1 David Bailey (LBL), "Algorithms Introduction"

問題点のまとめ。

  1. The concurrency challenge --- 107〜108のthreadsが動いていな ければならない。
  2. Hierarchical algorithm が必要。
  3. Latency tolerant algorithms が必要。
  4. Bandwidth friendly algorithmsが必要。
  5. Numerical accuracyの問題。64ビットで大丈夫か?
  6. Numerical scalability --- computational work (n4) vs memory (n3) grid sizeとtime stepとの制約は破れるか(MGやDDで)?
  7. Exploring trade-offs in the space of algorithms variants

7.2 Adolfy Hoise (LANL), "Performance and Scalability Modeling of Applications on Teraflops-scale Architecture"

http://www.c3.lanl.gov/cic19/teams/par-arch/ を見よ。

Parallel wavefront algorithmが重要。70年代終わりにはhyperplane algorithmと呼ばれた。2次元分割の3次元wavefront。ブロッキングが必要 だが、そのサイズにはtrade-offsがある。pipelined wavefront abstractionのモデル化。modeling gives insight.

7.3 Vipin Kumar (Minnesota), "Scalable Algorithms"

これまでの認識は以下の通りである。

  1. (性能が同じなら)より少数のより速いプロセッサが望ましい。
  2. レイテンシーが問題
  3. バンド幅が問題
  4. もしメッセージのサイズが十分大きければ、ネットワークのレイテン シーは隠すことが出来る。
  5. データコンテクストが大きいほど、データの再利用度が上がる。

科学技術計算からいくつかの例を取り(密行列演算、FFT、疎行列計算、 非構造不規則グリッドなど)スケーリングを分析。スケーラビリティとし ては、isoefficiency metricが重要。O(p3)はだめ、O(p log p)はよい、 O(p)なら理想的。CPU速度とともに、バンド幅もスケールしなければなら ない。なんか当たり前の話であった。

7.4 David Keyes (NASA Langley), "Latency Tolerant Algorithms"

典型的な偏微分方程式解法のアルゴリズムを例にあげ、ペタフロップス に到達するための4桁のパーフォーマンスの改良を可能にする、アーキテ クチャとアルゴリズムについて考察する。

広域同期によるアルゴリズムでは、プロセッサ数に応じて性能が向上す るためには、リダクション演算がプロセッサ数に対して線形より短い時間 で実行できるアーキテクチャが必要である。しかし価格性能比は、大域的 リダクション演算の頻度とレイテンシに敏感であり、完全な負荷分散など 期待できない。

偏微分方程式には、時間発展と平衡状態とがある。実際には混合してい る。陽解法におけるレイテンシ隠蔽。領域分割陰解法の問題、など。

7.5 Tony Drummond (UCLA), "The UCLA Earth System Model: Performance, Scalability and Computational Challenges"

7.6 Jake Maizel (National Cancer Institute), "Some Petaflops Challenge for Biological Research"

ヒトゲノム解析は3×109の塩基配列を完全に決定しようとしている。 配列の比較研究は遺伝子に関する強力な知識を与える。遺伝子配列の情報 から機能を理解するには3次元分子構造を実験的にまたはコンピュータシ ミュレーションで決定しなければならない。X線結晶学やNMRのために は高性能な計算機が必要である。

8.18日(木曜日)午後

基調講演とシステムソフトウェアのセッションであった。

8.1 Gil Weigand (DOE, Deputy Assistant Secretary, Research Development and Simulation, Office of Defense Program), "Keynote Address"

二番目の基調講演である。まずASCIプログラムを総括し、2004年に100 TFLopsを実現することから、その延長上でPetaflopsを実現する展望を述 べた。曰く

Government support is essential. people=government
Consistent policy is essential. people=policy
PITAC follow-on.

8.2 John van Rosendale (DOE), "System Software Introduction: Impact of Architecture Design on Software"

システムソフトの問題は

  1. プログラミングモデル
  2. どれだけの並列度が必要か
  3. アーキテクチャの選択がソフトウェアに及ぼす影響

プログラミング言語の発展の歴史を見ると、Algol68, SETL, Modula, Obelinと抽象度が上がっているが、並列モデルでは、HPF, MPI, C+MPI+Threadsと抽象度が下がっている。これは逆行だ。

プログラミングモデルは、性能の問題から規定されている。ソフトウェ アは問題解決環境をよりよいものにする。

簡単な計算から、キャッシュのヒット率を90%、主記憶のレイテンシを 1msとすると、ペタフロップスにおける並列度は108以上必要である。

アーキテクチャとしてCOTS (Commercial Off-The-Shelf)を考えると、 プログラミングの複雑度は、記憶階層のレベルの数、異なるレベル間の性 能の違い、異なるレベル間のsemantic variationとともに増大する。しか し市場動向は深い階層構造を要求する一方、製造会社は最下位のレベルし か面倒を見ないであろう。

PIMに基づくアーキテクチャでは、flatなMPI programming modelが使わ れる。メモリレイテンシを減少することにより、必要な並列度も減らせる。 新しいアーキテクチャはより効果的だ。

結論として、有効な高レベル並列言語を開発しなければならない。

8.3 Greg Astfalk (Hewlett-Packard), "Operating System Scalability for Petaflops"

ペタフロップスシステムのように多数のプロセッサからなるシステムの OSを設計するのは難しい。現在のOSよりも何桁もスケーラビリティの よいOSでなければならない。そのためにはアーキテクチャに強い要求が 課せられる、すなわち大域アドレス空間を持つか、分散システムでなけれ ばならない。プログラミングの方法論も影響を受ける、共有メモリに基づ くかMPIでなければならない。非常に難しい問題である。

8.4 Dan Reed (Illinois), "Petabyte I/O and Distributed Archives: An Adaptive View"

市販のディスクは、密度は年に100%増大し、転送速度は40%増大してい るが、アクセス時間は7%しか減少してない。そのため、会話的なデータ解 析や可視化に必要なI/O速度を保つには、多くの記憶装置に渡ってデータ のストライピングが必要である。ペタスケールなシステムもI/Oは、予期 しないアクセスパタンや資源の可用性の変化に対応するために、適応型の インテリジェントなシステムが必要である。

8.5 Jack Dongarra (University of Tennessee and ONRL), "PSE's, Libraries and Tools: Challenges of Future High-End Computing"

PetaflopsとGrid-based computingとは両極端のようであるが、共通の 点も多い。例えば、多くの異なるプロセッサが共存すること、異なるスピー ドのネットワークが共存すること、fault toleranceが重要なことなどで ある。

ソフトウェアは、ますます広がるギャップに橋を架ける必要がある。こ れは、ライブラリ、PSE (Problem Solving Environment)、ツールなどに とって大きな挑戦である。

数値計算ライブラリの歴史を振り返ると、

20年前は、1 MFの時代で、スカラー計算機、level-1 BLASであった。
10年前は、1 GFの時代で、ベクトルとSMPであった。キャッシュが問題 で、level-2/3のBLASが用いられた。ブロック化、レイテンシ耐用性。
今日では、1 TFの時代で、network-based, message passing. scaLAPACK.
10年先には、1 PFで、より多くのメモリ階層、より多くの適応性、レイ テンシー耐用性、バンド幅、耐故障性、拡張精度、......

今後の数値計算ライブラリは、適応的で、反復的、探索的、インテリジェ ントでなければならない。数値計算における決定性は過去のものとなろう。 再現可能性も一定のコストを払わなければならない。128ビットまたはそ れ以上の浮動小数の重要性が高まる。

ASCI用の改良scaLAPACKは、ASCI Redで684 GFlops出た。材料モデルシ ミュレーションMP-Questでは、605 GFlops。対称固有値問題はASCI Redの 計算の10-20%を占める。新しいアルゴリズムとしては、 divide-and-conquerとHoly Grail (J. Demmd, B. Parlett, ...)がある。

アルゴリズムを途中で切り替えるという戦略もある。まず高速な方法で 計算し、a posterioriに結果を検証する方法である。精度と性能の予言性 と頑強性(robustness)、再現性、耐故障性、検査可能性(auditability)が 問題。

性能の問題には、キャッシュとバンド幅が関係する。性能は不安定なも のとなる、耐レイテンシ性をもち、バンド幅をケチった(bandwidth parsimonious)アルゴリズムを考えなくてはならない。商用品のプロセッ サから性能を引き出すためには、広いデザイン空間で多くのパラメータを 調整する必要がある。

我々はATLAS (Automatically Tuned Linear Algebra Software)という システムを開発した。これはレベル3のBLASに基づき、自動的にキャッシュ、 TLB、浮動小数性能、レジスタの再利用、ループのオーバヘッドなどを数 時間掛けて測定し、それに従ってその計算機向きのライブラリを生成する システムである。500×500のかけ算で、ベンダのライブラリと比較して、 ちょっとよいか同じ程度の速度を実現した。LU分解では、left-looking LUを使ってる。今後の問題としては、threading, run-time adaptation (sparsity, iteration), adaptive libraryなどがある。詳しくは、 http://www.netlib.org/atlas を見てほしい。

8.6 Andrew Grimshow (U. of Virginia), "Petaflops and the GRID"

Petaflopsマシンが出来たら、プログラム環境、信頼性、他のインフラ との整合性などへの期待が非常に大きいだろう。さらに、このマシンは、 非常に大きなメタシステム、すなわちGRID環境のなかに存在するであろう。 すなわち、これらすべての環境との整合性が非常に重要である。

Petaflopsで重要なのは、安全性、アクセス制御、資源管理、耐故障性 などであるが、これは実はGRIDの課題でもある。Jave generation is coming!!!

8.7 Bill Gropp (ANL), "Lessons for Petaflops from MPI"

8.8 Panel, "Can Petaflops Computing Survive the System Software Barrier?"

メモ不完全。

夕食後は、ポスターセッション。

9.19日(金曜日)午前

金曜日はまじめに出席しなかったので、タイトルだけ記す。

9.1 Alan Craig, "Exotic Strategies Introduction"

9.2 Jeff Kimble (Caltech), "Quantum Computing"

9.3 Tom Knight (MIT), "Biological Computing"

9.4 Philip Kuekes (Hewlett-Packard), "Nano Technology"

9.5 Jonathan Dowling (NASA JPL), "Quantum Algorithms"

9.6 Craig Lent (Notre Dame), "Quantum Dots"

9.7 Panel "Summary Findings and Recommendations from Pflops2"

 

全体として、Petaflopsへのものすごい意気込みを感じた。本当に出来 るかどうか確信は持てないが、そろそろ視野に入ってきたことは事実であ る。アーキテクチャとしては、COTS, PIM, HPMTの3つに収束しつつあるが、 その他の技術を注目することも忘れていない。今後の問題は、応用ソフト、 利用環境、ユーザインタフェース、データ管理などであろう。日本でも、 このようなhigh end computingに向けての、プロジェクトが必要であるこ とを痛感した。


このページについての御意見は こちらへ。

[LOGO] 「計算科学」研究推進委員会のページ へ戻る。