初版 2007年7月24日
改訂 2007年9月17日
ISC'07報告
小柳義夫(工学院大学)
http://olab.is.s.u-tokyo.ac.jp/~oyanagi/reports/ISC2007.html
http://olab.is.s.u-tokyo.ac.jp/~oyanagi/conf.htmlには他の会議報告などがあります)
 
 International Supercomputing Conferenceは、Prof. Hans Meuer(University of Manheim)が主宰するヨーロッパ最大のHPC国際会議である。今年は6月26日(火)から29日(金)までドイツのドレスデンの国際会議場で開かれた。はじめはマンハイム大学での小さな国内会議であったが、その後国際会議に成長し、HPCN Europeが無くなってからは、ヨーロッパでの事実上唯一の総合的HPC会議に成長した。2001〜2005はHeidelbergで開かれていたが、会場が狭く、とくに展示会のスペースが不足していた。昨年からは会場を旧東ドイツのドレスデンに移した。昨年も参加したのだが、報告をしなければと思いながらまだ実現していない。なお、昨年はISC2006と称していたが、どういうわけか今年はISC'07と称している。
 
 ドレスデンは、August der Starkeという強い王様がいて、一時はポーランドまで配下にする程であった。エルベ川の真珠ともいわれ、街全体が中世のたたずまいを残し、世界遺産に登録されている。昨年は、建都800年で、しかも街のシンボルであるFrauenkircheの再建が前年10月に実現し、大変盛り上がっていた。1945年のアメリカによる大空襲で、町中が廃墟となったが、精力的に復興されている。
 
 今回のドレスデンは大変涼しいというか寒いくらいであった。同じ頃、それほど遠くないイタリアやギリシャでは摂氏45度に及ぶ熱波であったが、ドレスデンは10度台で、風もあり、フード付きのヤッケを着ている人も少なくなかった。
 
 この会議は、contributed talksがScientific Dayにあるだけで、主要部は招待講演だけで構成されている。研究ポスターは展示会場で発表された。展示も毎年賑やかになっている。特徴としては、hot seatというセッションがある。これは、20ほどのベンダーがそれぞれ10分講演し、これに対し、Inquisitor(審問官)と呼ばれる4人が鋭い質問を出すという趣向である。質疑応答は5分。以前の印象ではかなり激しいやりとりがあったような気がするが、今回は、だいぶおとなしくなり、おもしろさが減少した。
 
 この会議に日本から協力しているのは下記の方々。
Advisory Board:
Program Committee:
Scientific Program Committee
ISC Award Committee:
三浦謙一(NII)、渡辺貞(理研)
佐藤哲也(地球シミュレータ)
三浦謙一(NII)
関口智司(産総研)
 
0.会議概要
 会議の講演のスライドが手に入ったので、会議中にメモしきれなかった情報までフォローすることができた(しかし英語が完全に理解できたわけではない)。その結果、A4で60ページにも及ぶ報告になってしまった。最初に全体の印象を記す。
 今回、わたしが興味を持ったのはmulticore/manycoreの技術動向である。この会議でもかなり重点が置かれていた。現在、Dualcoreとかquadcoreとかが商品になっているが、何でもコア数は18ヶ月毎に倍になる(新しい「ムーアの法則」?)そうで、我が国の次世代スーパーコンピュータが完成する2011年頃には数十コアが普通になっているであろう。それも、汎用プロセッサを多数チップ上に搭載したmulticoreだけでなく、簡単化した演算器をもっと多数チップ上に搭載したいわゆるmanycoreも多数登場するであろう。
 
 Burton Smith (3.5節)は、今後の問題点として、The ILP wall, The Power wall, The Memory wallの3つを挙げ、いずれもが高度並列処理により解決されるだろうと述べた。そのために、フォン・ノイマンのモデルを脱却して、新しいコンピュータモデルを生み出し、新しいソフトウェア環境を作ることの重要性を指摘した。
 Tom Sterling (3.7節)は、過去一年を総括して、今年の特徴を「新しいムーアの法則としてのマルチコア」と位置づけた。しかしそのためのソフトウェア環境は整備されていないと指摘した。
 Tom Sterling のマルチコアに関する講演(4.2節)では、それをさらに精密化し、種々のマルチコアの実例を紹介しながら、改良的なアプローチではだめで、もっと根本的なパラダイム変革が必要だと述べた。
 牧本次生氏(4.3節)は、有名な「牧本ウェーブ」の考察に基づき、コンシューマ電子機器のデジタル化はますます進行し、市場の収束をもたらすこと、チップの技術革新により、価値指数は今後の10年に1000倍に増大すること、将来のアーキテクチャにとって、プログラム可能性と再構成可能性はキーであると述べ、ロボットは新しい機会を開くであろうと期待を述べた。
 John Shalf(5.1節)は、マルチコアの問題点はメモリバンド幅だと言われているが、これは嘘だと常識を覆した。家電などの組み込みプロセッサの方が多くの経験を積んでおり、われわれはそれから学ぶべきだと主張した。フォン・ノイマンのモデルを捨て、トランザクション・メモリという新しいモデルに移るべきことを強調した。
 Julien Langou(5.2節)は、マルチコアの時代に数学ライブラリはいかにあるべきかを述べ、密行列線形代数ライブラリの新しい動向について述べた。
 石川裕氏(5.3節)は、ペタフロップスのソフトウェアやミドルウェアについて、階層的資源管理、Jittering、メモリ・アフィニティ、電力管理、フォールト・トレランスとファイルシステム、プログラミング環境の問題を指摘し、T2K連合ではこれをどういう方向性で解決しようとしているか、について述べた。
 
 
1.展示
 アメリカのSupercomputing XY と同様に、この会議には展示会が併設されている。ハイデルベルクからドレスデンに移った理由の一つは展示会場が狭かったからである。今年は、2400m2の会場に大小85件の展示が行われた(昨年は74)。
 企業関係がほとんどだが、大学などの非営利団体ではBarcelona Supercomputer Center, EGEE (The Enabling Grids for E-sciencE project), EPCC Edinburgh University, Fraunhofer ITWM, FZ Karlsruhe, HLRN, HLRS Stuttgart, Karlsruhe Institute of Technology, KISTI, Leibniz Rechenzentrum, Research Centre Jülich, Riken, The University of Machester, TOP500, University of Mannheim が挙げられる(一部分類不明のものあり)。日本関係では、上記理化学研究所の他に、企業では富士通、NECが出展していた。目についたものだけ紹介する。
 
1.1 IBM
 今回最も注目されたのは、IBMのBlueGene/P の発表である。これはBlueGene/Lの後継機であり、1チップにPowerPC 450 のプロセシング・コアを4個搭載し、これを850 Mhzで動作させる(ピーク13.6 GF)。現在のBlueGene/Lは、PowerPC440を2個搭載し700 Mhzで動作するので、チップあたり2.4倍の高性能化であるが、消費電力は20%しか増加していないという。外形は同じ箱を用いているようだ。ボードに32個のチップで、32ボードでラックを構成し、256台のラック(今の4倍)を接続することができ、3.56 PF というピーク性能が出てくる。メモリが増強され、BlueGene/L と比べて、主記憶は4倍、メモリバンド幅は2.4倍である。
 共有のL2やL3キャッシュをsnoop filterによりコヒーレントにできる機能を付加した。これによりSMPが可能になった。3種のモードがあり、Quad Mode (VNM)では、各プロセッサに1個のプロセスを走らせ、その上で1個のスレッドを許すモードである。スレッド間はMPIで通信する。Dual Modeでは、2個のプロセッサに1個のプロセスを乗せ、1〜2個のスレッドを走らせる。すなわちチップ内では2個のプロセスが走る。プロセス間はMPIで通信する。SMP Modeでは、4プロセッサに(すなわちチップ上に)1つのプロセスを走らせ、1〜4個のスレッドを走らせる。後で別の機会に、LINPACKはどのモードで実行したのかと聞いたが、いろいろ試してみた、というだけではっきりしなかった。ちなみに、Top500の今回の表では、31位にBlueGene/Pの2ラック(8192 CPU)が登場し、Rmax=20.86 TF, Rpeak=27.85 TFという性能を出している。
 トーラスネットワークに対しては、DMA(6.8 Gb/s)を装備し、高速化(2.4倍)を計るとともに、remote put/get を可能にした。BG/Lでは、プロセッサがネットワークへのデータ送出を行っていたので、この点は大きな改良である。トリーネットワークも2.4倍の高速化。イーサーネットは10倍の高速化。
 メモリのfault tolerancyのために、memory-chip-kill の機能を加えた。プロセッサチップ当たり10個のメモリチップが組まれているが、そのうち1チップは余分であり殺すことができる。メモリは2.0 GB (DDR2)で希望により4.0 GBにもできる。Flops/Byte比は6.8(3.4)である。地球シミュレータが4.0であったことを考えると、かなりの数値で、BlueGeneはメモリをけちっているとはもはや言えない。詳細については27日、28日のTom Sterlingの講演を参照。
 ニュースによると、アメリカのANLやドイツのMax Planck InstituteやResearch Centre Jülichが2007年中に導入を予定しているほか、CUNY/BNLやイギリスでも計画されているそうである。ANLには最初32ラックのシステムが入るとのことだが、最終的に何ラックのシステムが導入されるであろうか(72ラックだとちょうどピーク1 PF)。今のところ、PFクラスの受注はないようである。
 28日(木曜日)の朝7時15分から、ドレスデン市内の別のホテルで、IBMのBlueGene/Pに関する説明会があった。私は行かなかったが、そこでのプレゼンのファイルを見せてもらった。新しい情報は特に無かったようである。
 
1.2 Sun Microsystems
 展示会場で目を引いたのが、入口近くのサンのブースにおかれた巨大なInfiniband SwitchのMagnum (ラテン語で「大きい」の中性形)である。何しろ、3456個のポートが一面に設置されている。全部のポートにラインが接続されたらさぞかし壮観であろう。スイッチ用のチップはMellanox社のものを使っているそうである。
 quadcoreのOpteron(Barcelona)のブレード・サーバ82台をこれ2台で接続したConstellation Systemは、500 TF の性能を持ち、テキサス大学のTACCに納入される予定である。いわば東工大のTSUBAMEの巨大化版ともいうべきシステムである。Barcelonaのチップが調達できれば、次回のTop500で、BlueGene/Pに先んじてトップを飾れるかもしれない。
 Sun Microsystemsは、HPCSのPhase III で敗れて以来、HPCの分野で陰が薄くなっていたが、これで一挙に挽回することをねらっているようだ。
 
1.3 NVIDIA
 もう一つ注目されるのがNVIDIAである。この会社はグラフィック用のGPUを製作していたが、この技術をHPCに振り向けようとしている。いわゆる、GPGPU (General Purpose Graphic Processor Unit) である。NVIDIAは、GeForce 8(G8x)アーキテクチャベースのGPUコンピューティング製品ファミリ「Tesla(テスラ)」を発表した。同時に開発環境として、GPU上での汎用的なコンピューティングを可能にするプログラミングモデルCUDA(クーダ:compute unified device architecture)を発表した。現在のところ32ビット浮動小数点しかサポートしていないが、次の版G9xでは倍精度をサポートする予定である。展示でデモしていたのは旧版であった。
 今後Multicore/Manycoreの時代に入ると考えられ、このような製品がいろいろ出てくるものと思われる。
 
1.4 理化学研究所
 今回日本から唯一の研究機関の展示であった。直前に日本で次世代スーパーコンピュータのアーキテクチャが一部公表され、その展示もあったが、現段階ではあまりにも漠然としていて参加者の注目を集めたとは言えない。
 
 
2.6月26日(火曜日)
 火曜日は、会議前のイベントがいくつかあった。Automotive Sessionという自動車業界でのHPCの利用に関するセミナーは、この会議の最近の恒例であるが、今年はこのセッションに別料金を取るということであった。また、Scientific Dayとして、2セッション並列のイベントがあり、投稿論文の発表があった。私はどれにも出ずに、市内の美術館巡りをしていた。
 6時からは展示の開会パーティーがあり、ちょっとした飲み物とおつまみが出た。HPのブースではソフトクリームを提供していたが、なかなかトリッキーで、手に取ると本体は空中高く舞い上がって手にはコーンしか残らないとか、技を披露していた。私は「ちゃんとよこせ」と騒いだので、各方向に6個もコーンのくっついたソフトクリームを獲得した。
 数人の女性のブラスバンドが会場内を練り歩き、そこら中でパーフォーマンスをやっていた。
 
3.6月27日(水曜日)
 
3.1 開会式(10:00)
 万年組織委員長のHans Meuerが開会の挨拶をした。今年は44カ国からの参加があった。68%はヨーロッパ(ドイツは37%)、20%が合衆国、16%がアジアである。参加者は昨日までで1100人であった。このうちscientific programに参加するのは520人。ハイデルベルクでやっていたとき、2001年は340人、2005年は647人だったのでずいぶん増えた。ちなみに、最初のドレスデンでの去年の参加者は915人であった。
 昨日のScientific Session では二つの論文賞が選ばれた。
  a) Ron Brightwell, Sandia NL, USA
  b) Satoshi Amamiya, Kyushu Univerisity, Japan(九州大学大学院システム情報科学研究院雨宮聡史氏(博士課程))である。
 展示は2400m2の会場に85のブースが出展されている
 BoF, Exhibitor Forum, Hot Seat Session, Research Poster Session などが紹介された。
 なお、ISC '07 のmain sponsorはMicrosoftであり、co-sponsorsは、AMD, Cray, CISCO, DataDirect Networks, Dell, Fujitsu, HP, IBM, Intel, Mellanox, Myricom, NEC, Panasas, Partec, SAP, SGI, Sun, Supermicro, transtec とのことである。
 
3.2 来賓祝辞
 ザクセン州の科学芸術大臣のKnut Nevermann氏が祝辞を述べた。
 
3.3 論文賞表彰
 上記2件の論文賞が表彰状を授与され、5件のHonorable Mentionsが披露された。
 
3.4 Top500の発表
 恒例により、Strohmaier (LBNL)が発表した。replacement rate(今回の新顔の数であろう)の推移グラフを示し、これまでだいたい毎回平均200であったが、今回は284に上ったことが発表された。半分以上入れ替わったわけだ。
 使用したプロセッサとしては、システム数では、












 
Woodcrest
Opteron Dualcore
Power PC 440
Pentium 4 Xeon
Itanium 2
Power 5+
Xeon 53xx (Clovertown)
Opteron
Power 5
PA-8900
Xeon EM64T
Power 4+
Others
41.0%
18.0%
6.8%
5.4%
5.0%
4.0%
3.8%
3.2%
2.0%
1.4%
1.4%
1.2%
4.6%












 
 歴史的なトレンドとしては、今年はトップが405TFになるはずであったが、相変わらずトップはBG-Lの280.6TFであった。
 賞状が授与された。まず全体の1位から3位まで、ヨーロッパ1位としてバルセロナに、アジア1位として東工大(遠藤君)に賞状が授与された。
 
Top10は、以下の通り。
1) 280.6TF BlueGene/L, DOE/NNSA/LLNL 前回と変わらず
2) 101.7TF
 
Jaguar - Cray XT4/XT3, Oak Ridge National Laboratory
前回は10位であった。相当増強したらしい。
3) 101.4TF
 
Red Storm, NNSA/Sandia National Laboratories
前回2位。わずかの差でJaguarに惜敗。
4) 91.2TF
 
BGW, IBM Thomas J. Watson Research Center
前回3位。
5) 82.16TF

 
New York Blue, Stony Brook/BNL,
New York Center for Computional Sciences
新顔。Brookhaven用のBG/Lと思われる。
6) 75.76TF ASC Purple, DOE/NNSA/LLNL。前回6位。
7) 73.03TF

 
Blue Gene Solution, Rensselaer Polytechnic Institute,
Computional Center for Nanotechnology Innovations
新顔。
8) 62.68TF
 
Abe - PowerEdge, NCSA
新顔
9) 62.63TF
 
MareNostrum, Barcelona Supercomputing Center
前回5位。
10) 56.52TF Leibniz Rechenzentrum, SGI。新顔
 
東工大のTsubameは14位、地球シミュレータは20位となった。Top500に入るための最小性能は4.005TFであある。時間的な推移を見ると、Top1がTop500に落ちるまでの期間は6-8年、Top500の性能がパソコンで達成されるのに8-10年掛かっている。
 製造会社では、システム数ベースで
    HP  40.6%
    IBM  38.4%
    Dell   4.6%
    SGI   3.8%
    Cray   2.2%
   Linux Networx   1.6%
   Sun Microsystems   1.2%
     Hitach   1.2%
     self-made   1.0%
     others   5.4%
性能ベースでは、
IBM 41.6%
HP 24.3%
Dell 8.85
Cray 7.3%
SGI 6.7%
Linux Networx 2.1%
Bull SA 1.8%
NEC/Sun 1.1%
Hitachi 1.0%
others 5.3%
となり、IBMとHPが逆転している。BGのためと思われる。Top50だけを見ると、システム数ベースで、
IBM 46.0%
Dell 18.0%
SGI 10.0%
Cray 10.0%
Bull SA 4.0%
NEC
NEC/Sun
2.0%
2.0%
Appro International 2.0%
Linux Networx 2.0%
self-made 2.0%
California Deigital Corp. 2.0%
 
となり、HPが入っていないことが分かる。
 国・地域別では、システム数ベースで、
USA 56.2%
UK  8.6%
Germany  4.8%
Japan  4.6%
France  2.6%
China  2.6%
Sweden  2.0%
Taiwan  2.0%
Canada  2.0%
India  1.6%
Netherlands  1.8%
Russia  1.0%
Italy  1.0%
Switerland  1.0%
South Korea  1.0%
Spain  1.0%
others  6.4%
 
 「(Gordon) Bellの法則」[そんなのあったっけ?]では、10年ごとにアーキテクチャが変わると言われているが、これをTop500のリストから検証してみよう。たしかに、90年代前半まではベクトルやSIMDが主流であり、その後は2004年くらいまでcustom scalarの時代であり、その後はcommodity clusterが主流になっている。現在重要な問題は消費電力であり、BlueGene型のものが今後どのように主流になっているかが注目される。
 その意味で重要なのは、multicoreとmanycoreである。我々はMooreの法則を安易に(安価に)乱用してきたので、チップはシステムの消費電力は膨大になっている。もはや、Mooreの法則のただ乗り(free lunch)はできない。消費電力を下げるために周波数を上げられないので、必然的に並列度が増大し、multicoreが到来する。消費電力あたり最適なコアの大きさは、現在の贅沢なコアよりは小さいので、manycoreの時代がやってくる。
 Manycoreとは、より小さな(限定された機能の)コアを数十から数百個、一つのチップに収容したものである。たとえば、
●Intel Polaris --- 80 cores
●ClearSpeed CSX600 -- 96 cores
●NV IDIA G80 -- 128 cores
●CISCO Metro -- 188 cores
などがある。
 
3.5 Burton Smith (11:10)
本日の基調講演として、MicrosoftのBurton Smithが"Reinventing Computing" と題して講演した。
 
 トランジスタ数は年々増大しているが、クロック周波数やソケットのピン数は増えない。つまり単一プロセッサの性能は頭打ちである。従って並列処理が重要になる。しかし、命令レベル並列性は限界に来ている(the ILP Wall)。チップあたりの消費電力は耐え難いほど大きい(the Power Wall)。また、キャッシュメモリの効果は大きくない(the Memory Wall)。
 当分の間、ロジックの費用(ゲート数×周波数 当たりの費用)は下がりつつある。このようなハードウェアをどう使いこなせばよいか。
 新しい「キラーアプリ」が登場して、より大きな性能を必要とすることを期待している。たとえば、意味解析、検索、ヒューマンインタフェース、言語、画像、ゲームなど。
 マイクロプロセッサは今やマルチコアであり、マルチスレッドである。しかしこれまではアーキテクチャ的に同じものがたくさん並んでいるだけである。このようなシステムをどうプログラムしたらよいのか。
 まず、ILP Wallについて考える。これまでILPへの二つのアプローチがあった。一つは、ベクトル命令や、SSEなどであり、もう一つはout-of-order実行、in-order retirement、レジスタリネーミング、分岐予測、投機的実行などである。しかしどちらのスキームも並列度を増やすことはできなかった、それは命令依存や、データ依存アドレス(ポインタを追跡するとか)などのせいである。実際のところ、クロックあたり2-3程度のILCしか実現できていない。ハイパフォーマンスには並列計算が必要である。
 次にPower Wallを考えよう。速度をσ倍にスケールするためには2つの方法がある。一つはコアの数をσ倍に増やすことであり、そうすれば消費電力もσ倍に増える。もう一つは、クロック周波数と電圧をσ陪にすることであり、そうすれば動的電力はσの3乗に比例し、静的な電力はσの1乗に比例する。平均はその中間であろう。つまり、σ>1ならクロックのスケーリングはコアを増やすより悪い。しかし、σ<1なら、逆にうまくいく。教訓は、「もしマルチプロセッサが完全に利用されているが熱すぎるとき、プロセッサ数ではなく電圧と周波数をスケールダウンせよ。」並列計算は電力を節約するためにも必要である。
 次はMemory Wallである。多くのトランジスタにより、より大きいキャッシュを作ることができるようになった。では、それで十分か、それともスケールアップに問題はあるか? 同一のDRAM合計バンド幅により性能を倍増するためには、キャッシュ・ミス率は半分にしなければならない。では、キャッシュはどこまで大きくする必要があるか。密行列のかけ算やLU分解なら4倍、ソーティングやFFTなら前の2乗、疎行列や密行列とベクトルとのかけ算なら、考えるだけ無駄。クロック周波数がより高速になり、相互接続がより深くなると、ミスのレイテンシーが増加する。すなわち、高性能にすればするほど、より大きいレイテンシーは不可避になる。レイテンシーとバンド幅は密接に関係している。入力から出力までデータをそのまま輸送するシステムでは、レイテンシー×バンド幅=(必要な)並列度 となる。これは待ち行列理論でLittleの法則と呼ばれるものである。
 Memory Wallを克服するにはどうすればよいか。
1) メモリバンド幅を増やすこと。DRAMの合計バンド幅をギガバイト単位で増やすこと。そしてチップのピンのバンド幅を増やすこと。
2) メモリ・レイテンシーに対応するために、マルチスレッドのコアを使うこと。もしレイテンシーが増えても、スレッド数を増やせばよい。これによりプログラミングモデルは大きくは変わらない。
3) バンド幅とレイテンシーを改善するためにキャッシュを用いよ。コンパイラがより簡単に局所性を最適化できるようにせよ。キャッシュ・ラインを短くし、投機のミスを防げ。
 結局メモリのバランスを保つためには並列計算が必要である。
 我々はフォン・ノイマンの前提に60年間依拠してきた。いまや、それ(とそれに附属するもの)は代えなければならない。逐次処理は変数がどんな値を取るかということでプログラムをスケジュールしているが、並列処理ではこのスキームは危険である。逐次プログラミングは並列プログラミングより簡単であるが、逐次プログラムは今や遅いプログラムである。だれでもうまくプログラムすることができるような並列プログラミングが必要である。我々の分野の懸賞金は高い。コンピューティングは再発明されなければならない。
 この問題をどう解決すればいいのか。マイクロプロセッサはものすごい勢いで高速化している。最近20年で1000倍以上になった。HPCは特殊化のスパイラルに落ち込んでいる。つまり、HPCの応用とはHPCシステムがうまく処理できるような応用のことを意味している。DARPA HPCSプログラムは、この傾向に棹を差そうとしている。並列システムに関する大学の研究は干上がっている。興味もない、アイデアもない、必要性もない、お金もない。しかし、並列計算への興味は必ず再起する。1970年から2000年までの国際会議の論文の分野を調べると、前半はマルチプロセッサが増えたが後半は減っている。
 過去から何を学ぶか。並列計算について多くのことはすでに知られている。たとえば、コンパイラ最適化、デバッグと性能チューニング、OS、アーキテクチャなど。これまでのほとんどの研究は、HPCを頭に置いてなされてきた。アイデアのなかには成功したものもしなかったものもある。また、技術的な成功は商業的な成功を意味するわけではない。
 まず並列プログラミング言語を取り上げる。現在のところ少なくとも二つのアプローチが成功しそうである。関数プログラミングとアトミックなメモリ・トランザクションである。どちらもそれ自身完全に満足はできるものではない。関数的プログラムはmutable state を許さないし、トランザクションのプログラムの依存性の実装法は汚い。データベースの応用はこの二つのアイデアを統合している。SQLは「最も関数的な」言語である。[データベースの]トランザクションはアトミシティーとisolationを保ってデータの更新を行っている。多くの人は関数言語は効率が悪いと考えている。しかし、SisalやNESLはすばらしい反例である。クレイのシステム上で両者はFortranと十分競争できる。またある人々は、メモリ・トランザクションも効率が悪いと考えている。今のところそうかもしれない。やっと最適化を始めたところである。
 トランザクションと不変量(invariants)について考えよう。不変量はプログラムの保存則である。反復や再帰における量の間の関係であり、データ構造の統一性の法則である。もし文pとqが不変量Iを保存し、両者が干渉しないなら、並列合成{p||q}もIを保存する。もし、pとqがトランザクションのようにアトミックなら、両者は干渉しない。色々な操作は、状態について交換可能であることは少ないが、トランザクションは不変量についての可換性を与える。従って、もしコンパイラが不変量を利用することができればすばらしい。プログラマーにそれを与えるよう要求できるか?
 LINQ (Language Integrated Query)を例に取ろう。これはC#やVisual Basicの新しい機能で、F#にも近々取り入れられる。これはメモリ上のデータまたは外部データベースのデータを操作する。例を示す。
 
public void Linq93() {
double startBalance = 100.0;
int[] attemptedWithdrawals = { 20, 10, 40, 50, 10, 70, 30 };
double endBalance =     attemptedWithdrawals.Fold(startBalance,
 (balance, nextWithdrawal) =>
( (nextWithdrawal <= balance) ? (balance - nextWithdrawal) : balance ) );
Console.WriteLine("Ending balance: {0}", endBalance); }
 
Result: Ending balance: 20
 
 並列性のスタイルについて考えよう。われわれは複数のプログラミングスタイルをサポートしなければならない。関数型もトランザクション型も、データ並列もタスク並列も、メッセージパッシングも共有メモリ型も、宣言型も命令型も、暗黙型も明示型も。これを実現するにはいくつかの言語が必要かもしれない。結局現在も複数の言語を用いている。言語間の相互通用性(.NETのような)は大いに助けになるであろう。本質的なことは、並列性がコンパイラに提示されることである。それにより、コンパイラがそれをターゲット・システムに適応できる。また、同じ理由で局所性もコンパイラに提示されることが重要である。
 並列性に対するコンパイラの最適化は可能か? ある人は、自動並列化が失敗したことは実証済みであるという。そうではない、ベクトル化も並列化コンパイラも、正しいアーキテクチャに対して用いれば、非常に大きな成功を収めてきた。これによりマシン独立な言語を可能にした。なにをやったかというと、並列性のパッケージ化をやった。明示的な並列プログラムでさえそれが必要である。何が失敗だったかというと、それは並列性の発見である。大まかに言って依存性解析は主に局所的な成功にとどまった。大規模な局所性の発見も大変である。局所性解析は依存性解析の別名だからである。大規模な局所性パッケージングが可能かどうか、まだ判断がなされていない。
 では並列デバッギングやチューニングはどうであろうか。現在、デバッグには、1ステップずつの実行とprintf()に依存している。これはあまり有効な方法ではない。条件付きのデータ・ブレークポイントは有効であった。つまり、不変量が不変量でなくなったときに停止させるのである。アドホックなデータ精査も非常に重要である。これは一種のデータマイニングの応用である。逐次プログラムのチューニングは、プログラムカウンタが最もしばしば滞在する場所を見つけることである。その答は多くの場合サンプリングで見いだすことができる。それに対して、並列プログラムのチューニングは、並列性が不十分な場所を探そうとする。最も良いとされるアプローチは、タイムスタンプ付きのイベントのログを取ることである。
 では並列性に適したOSは何であろうか。まず、[並列]OSはプロセッサのスケジュールを止めなければならない。この仕事はプロセッサや他の資源の仕事である。また資源の変更は、ランタイムと交渉しなければならない。仕事はユーザレベルでスケジュールしなければならない。従って、特権を変更する必要はなく、局所性を保存することが望ましく、最適化はより可能になり、ブロック化された計算は一級になる[何を言いたいのか?]。用途によってはサービスの質が重要になる。このようなばあい、優先度よりデッドラインの方が重要である。ほとんどの並列アプリにおいてデマンド・ページングは悪い考えである。ページ・フォールトで待ちばかり起こってしまう。
 並列アーキテクチャについて述べる。並列性はハードウェアから始まった。しかしそれだからと言って、ハードウェアが進んでいるわけではない。じゃまなのはフォン・ノイマンの前提である。たとえば、割り込みとか。ほとんどは修復することは易しい。大きな問題は小粒度の並列性のサポートである。スレッドの粒度はスレッドあたりの状態の量に依存し、ブロックしたときそれをスワップするのにどのくらいの手間が掛かるかに依存する。もう一つの問題は、すべてのプロセッサが同一に見えるべきかどうかということである。異質性という選択はある。ヘテロなアーキテクチャや、ヘテロな実装である。その間で通信をするために共有メモリを用いることができる。しかし、同質のアーキテクチャのデータ型の方が性能は上がるであろう。最大の問題はシステムバランスをどうやって保つかということである。
 以上の考察からHPCに対して何が言えるか。これまでHPCは、逐次処理の世界における、孤独な並列処理の前哨部隊であった。しかし今や並列計算はメインストリームである。HPCへの帰結は以下のようにまとめることができる。
 1) HPCの主流のソフトウェアの適応と利用
 2) 共有メモリとメッセージ・パッシングの実行時の結合
 3) プログラミング言語選択のスペクトルを広げること
HPC製品の提供が成功するためには
 1) 今後ますます登場する利用者のアプリとツールのHPC版
 2) 利用者のアプリを可能にし、加速するHPCのサービス
 3) 利用者の想定しているアーキテクチャのモデルをスケールアップできるHPCシステム
 HPCはその他すべてのものとともに再発明されなければならない。
 
 結論として、われわれはいまや計算の基礎の多くを考え直さなければならない。やるべきことは山ほどある。私はいくつかのテーマ、特にアプリの問題に触れなかった。それから、われわれは並列性に関して価値のある経験をたくさん持っている。その多くは今後も有用であろう。
 
 
3.6 CFD
 
 昼からCFD関連の講演がいくつかあったが、まじめに聞いていなかった。
 
3.7 Tom Sterling (16:00)
 
 これも恒例のようであるが、Thomas Sterling (Louisiana State University / CalTech)が、過去一年を振り返って"HPC Achievement and Impact --- 2007, A personal retrospective"という招待講演があった。
 
 今までの私[Tom]の挙げた各年の標語を集めると、
2004 Constructive Continuity
2005 High Density Computing
2006 Multicore to Petaflops
であった。今年の標語は、"Multicore: the Next Moore's Law" である。
 
1) 今年のトレンドのハイライト
a) BG/Lが今年も先頭
b) ペタフロップスへ向けて全開。2010年がターゲット
c) Multicoreは今や当たり前、そしてmanycoreが辞書に載るようになった。次はmyriacoreか?
d) ヘテロ構成、Cell, GPGPU などが噂になっている。ところで、プログラミングモデルは?
e) 他のアクセラレータも魅力的
f) LinuxとIBAのコモディティ・クラスタが進入中。
g) クロック周波数はほとんどフラットだが、少しは上昇中。
h) ソフトウェアの進歩もゆっくりだが、重要な進歩もあり。
i) アプリの広がり
j) 重要なテクノロジーの進歩がムーアの法則を押し進めている。
k) Exaflops! Just when you thought it was safe to ignore the Top-500 List.
 
2) まずトップについて。まだ平ら。
a) IBMのBG/Lは以前世界最速。BG/Lの説明
b) Cray XT4。
 (1)ネットワークとの接続は、GbE, 10GbE, ファイバーチャネル、インフィニバンド(将来)。相互接続はCray SeaStar2, 7.5 GB/s, 3D torus。
 (2) 64-bit AMD Opteron
 (3) メモリバンド幅 10.6〜12.8 GB/s per Opteron
 (4) 8 GB RAM per Opteron
 (5) OS: SISE Linux
 (6) 1 TF per cabinet
c) MareNostrumの説明。
d) TSUBAMEの説明
 (1) 日本最大のクラスタ。Sun Fire X4600に基づきNECによりインテグレイトされた。
 (2) Opteron processors, ClearSpeed accelerators and Infiniband Interconnect
 (3) 2006年11月のTop500で9位。
 (4) 47.38 TF (ClearSpeedを入れて)
 (5) 1.1 P B storage
 
3) ペタフロップスへのスプリント
 
a) DARPA HPCS Phase 3
 (1) DARPAはHPCSのPhase IIIとしてIBMとCrayとを選んだ。
 (2) 今後4年間に、Crayは$250M、IBMは$244Mを支給される。
 (3) Phase IIIの間に両社はハード、ソフトの設計を行い、実行速度2PFで、4PFまで拡張可能なマシンを技術開発する。
 (4) 両社は、ランダムメモリアクセスの速度を増加する。目標性能は、8000から64000 GUPSの間。BG/Lはわずか35 GUPS。
 (5) 最終的なプロトタイプは2010年。
 (6) IBMとCrayはSun Microsystemsを打ち負かした。
 
b) DARPA HPCS -- Cray Cascade
 (1) CrayのHPCS向けシステムはCascadeと呼ばれ、adaptive computingのビジョンにに基づく。
 (2) CascadeはHeterogeneous Processing Modelに基づく。システムソフトウェアやコンパイラや実行時システムが、応用をハードウェアに写像する。
 (3) Cascadeは非常に高いメモリバンド幅、高度な同期、多重プロセッサアーキテクチャ(スカラ、ベクタ、マルチスレッド、ハードウェアアクセラレータ)を持つ。
 (4) プロセッサ技術のパートナーはAMD (Multicore Opteron, HyperTransport Technolgoy)
 (5) ソフトウェア技術のパートナーは、PGI(コンパイラ)、Cluster File Systems(ファイルシステム)、DataDirect Network(ストレージ)。
 
b) DARPA HPCS -- IBM PERCS
 (1) PERCS (Productive , Easy-to-use, Reliable Computer System)
 (2) POWER7 processor, AIX operating system, General Parallel File Syste, IBM's Parallel environment, IBM's Interconneect and Storage Systems.
 (3) team members: IBM, LANL and several universities
 (4) レガシーソフトのためには、MPI, OpenMP, C, C++, Fortran、新規のソフトのためにはPGA, UPC, etc.
 (5) X10 新しいプログラミングモデル。
 
c) NSF Cyber Infrastructure / Big Iron
 (1) HPC System Acquisition programにより、4つのシステムが選定され予算が与えられる。
 (2) その1番目として、TACCのSunベースのクラスタは$59Mを獲得。400TF以上、100TBメモリ、1.7PBディスク。
 (3) AMD quadcore Opteronを用いたSun Fire X86-64bit serversに基づく
 (4) 2007年中頃に稼働すれば、TerGridのインフラの一部となる。
 (5) 第2の勝者は近々発表される。
 (6) 2007年後半には、提案の最終締め切り。
 [その後の情報では、NSFはTrack 1 と呼ばれるシステム一つと、Track 2 と呼ばれるシステムをいくつか選定するようです。Track 1 は、A Leadership-Class Systemということで、10ペタフロップスクラスのマシンです。8月はじめに、UIUCに4年半に$208Mの予算がつきました。名前はBlue Watersで、IBMのPERCS ではないかと言われています。2011年に完成予定。
 Track 2 は、Mid-Range High-Performance Computing Towards the Petascaleということで、1つ目がTACCのMagnum switchを使ったConstellation System(ピーク500 TF)で、昨年9月に予算が下りました。今年は、Tennessee at KnoxvilleのJICSに、5年間で$65Mの予算が付きました。ORNL, TACC, NCARなどと連携しています。マシンはBaker-class Cray machine ではないかと言われています。年に1個のペースであと1〜2個予算をつけるそうで、SDSCやPSCなどがねらっているものと思われます。我が国は次世代スーパーコンピュータで盛り上がっていますが、このように重層的な予算措置がなされているアメリカの現状はうらやましくもあり、脅威でもあります。]
 
d) IBM BlueGene/P
 (1) チップ上に、PowerPC 450 (850 MHz) x 4 = 13.6 GF
 (2) 72ラックで1PFのBG/P
  -- 294,912 processors
  -- 2 GB SDRAM-DDR
  -- 3D Torus Network 5.1 GB/s, 3.5μs latency
[6方向の合計であろうか?]
  -- Collective Network 1.7 GB/s, 2.5 μs latency
  -- Optical 10 GbE (machine control and external) and 1 GB control network
  -- Peak performance PER RACK 13.9 TF, consuming 40KW/rack
 (3) ANLが最初のBG/Pを装備。
 (4) ドイツではMax Planck Institute, Forschunguszentrum Julichが購入予定。
 
 BlueGene/LとBlueGene/Pとの比較(cacheのあたり原図に乱れあり)
 Property     BlueGene/L BlueGene/P




Node Processors



 
Coherency Software Control SMP
L1 cache (private) 32KB/proc 32KB/proc
L2 cache (private) 14 stream prefetching 14 stream prefetching
L3 cache (shared) 4MB 8MB
     
Main Store 512MB/1GB 2GB/4GB
Main Store Bandwidth 5.6GB/s (16B wide) 13.6GB/s (16B wide)
Peak Performance
 
5.6 GF/node
8F/clock
13.9GF/node
16F/clock
 
 72ラックで比較すると(BG/Lでは64ラックまでであろうが)、


Torus Network

 
Bandwidth 6*2*175MB/s=2.1GB/s 6*2*425MB/s=5.1GB/s
Hardware Latency
(Nearest Neighbor)
200ns (32B packet)
1.6μs(256B packet)
100ns (32B packet)
800ns (256B packet)
Hardware Latency
Worst case
6.4μs(64 hops)
 
3.2μs(64hops)
 

Tree Network
 
Bandwidth 2*350MB/s=700MB/s 2*0.85GB/s=1.7GB/s
Hardware Latency
(round trip worst)
5.1 μs
 
3.5μs
 
System Properties
 
Area (sqft) 1225 1728
Peak Perf (72Knode) 410Tf 1PF
Tital Power 1.7MW 2.3MW
 
4) Multicore -- the Next Moore's Law
 
a) IBM Power 6
 (1) Peak 4.7 GHz
 (2) 65 nm SOI process with 10 Levels of Cu interconnect and low-k dielectric
 (3) 2 SMT core
 (4) 8 MB Level 2 cache
 (5) support for 32 MB L3
 (6) 341 mm2 die
 (7) > 790 M transistors per microprocessor
 
b) Dualcore Intel Itanium 2
 (1) EPIC (Explicitly Parallel Instruction Computing) architecture
 (2) Intel's first product with two complete 64-bit cores on one processor
 (3) Includes Hyper-threading
 (4) 24 MB on-die L3 Cache
 (5) 6-wide and 8-stage deep pipeline, running at 1.6 GHz.
 (6) 6 integer units, 6 multimedia units, 2 load and 2 store units, 3 branch units, 2 extended-precision floating point units, and one additional sigle-precision floating point unit per core.
 
c) Cell Components and Layout
 (1) One Power Processing Element
  -- 2x32KB L1, 512KB L2 cache, 32x128-bit register file, VMX
 (2) Eight Synergistic Processing Element
  -- 256KB local store, 128x128-bit register file, 128-bit SIMD
 (3) Element Interconnect Bus
  -- 96 B/cycle (300 GB/s peak)
 (4) Dual channel XDR memory controller
 (5) FlexIO external I/O interface
 
まとめ(Cellは32-bit演算のみ)
Processor
 
Number of Cores Clock Speed
 
Peak GF
 
Aggregate on-die Storage GF/W
 
Opteron 2 2.8 11.2 >2 MB 0.093
CSZ600 96 0.25 48 600 KB 4.8
BlueGene/L 2 0.7 5.6 >4 MB 0.43
Clovertown 4 2.66 42.56 >8 MB 0.35
Intel Terascale 80 2.16 1010 >8 MB 16
STI Cell 8+1 3.2 204.8 >2 MB N/A
 
5) アーキテクチャの多様性の爆発
 
a) GPGPU
 (1) グラフィックのための道具を、もっと広い範囲の応用に用いる。GPUのスレッドは非常に軽いので、スレッドの切り替えのコストはほとんどない。
 (2) 主要な制限は、配列のような規則的なデータ構造を一様に処理するようなものでなければならない。
 (3) NVIDIA
 (4) ATI R580 は48個のコアを持ち、NVIDIAのG80は128のプロセッサを含む。
 (5) ATIはAMDに買収されたので、AMDのTorrenzaイニシアチブにより、2008年にも統合されたCPU/GPUがFusionという名前で出現する。
 
b) Sun UltraSparc Niagara
 (1) マルチコアでマルチスレッディングのCPUである。
 (2) 単一のダイの上に、4, 6, 8 cores
 (3) 各コアは多くのスレッドが走り、各サイクルでスレッドの間のスイッチングが起こる。
 (4) SPARC V9 の完全命令セットが動く
 (5) UltraSPARC T1の特徴
  -- 350 mm2 die, 90nm, 9 layer Cu
  -- 32 threadsを1.2GHzでサポート
  -- コア毎に640x64-bit register file
  -- 統一された3MB L2 cache, バンド幅 25.6 GB/s
  -- 暗号処理のためのモジュロ演算機能
  -- 200 GB/sの内部クロスバにより、パイプ、L2 cache、共有CPU資源を結合。
  -- 一つのFPUをすべてのコアが共有。単精度は40 cycles、倍精度は400 cyclesのレーテンシ。
  -- 消費電力は、平常時72W、最大79W。
 
c) IntelのTera-scale Processor
 (1) 単一チップ上に80個の単純なコア
 (2) コアあたり2個のプログラム可能な浮動小数エンジン
 (3) デザインの特徴
  -- タイル型のデザイン
  -- チップ上にネットワーク(各コアは5ポートのメッセージパッシングルーターを持ち、ルータは2次元メッシュで結合)
  -- 細粒度電力管理:コンピュート・エンジンもルータも個別に眠らせられる。
  -- sleep transistor(何?)、mesochronous clocking, clock gating
  -- 62wで1TFを実現
 
d) Roadrunner
 (1) 1.6 PF以上を実現
 (2) COTSからなるハイブリッドクラスタ
  -- 16000 Opterons
  -- 16000 Cell BE based systems
 
e) IBM Cyclops-64 multicore Chip
 (1) PIM (processor-in-memory)アーキテクチャ
 (2) 75個のプロセッサからなる。各プロセッサは、
  -- 2個のスレッド・ユニット
  -- 共有のFPU(加算、乗算、FMA、割り算、平方根)
  -- 2個の32KBのSRAM メモリ
 (3) 各スレッドユニットは、
  -- デコーダ、シークエンサ(in-order, single issue)
  -- register file (64x32-bitまたは2つつなげて倍精度)
  -- 固定小数演算
 (4) load-store は3オペランド方式のISA。命令数は60.
 (5) 相互接続は、96ポートの7段クロスバ。これは外部とのゲートウェイも提供する。
 (6) 3次元メッシュ接続。GigEやATAも持つ。
 (7) 各ノードはディスクのインタフェースを持つ。
 (8) 0.18μCMOSで500MHzで走る。
 
f) TRIPS
 (1) Tera-ops Reliable Intelligently adaptive Processing System, DARPAの予算でテキサス大学が開発。
 (2) 高性能を得るために、命令レベル並列性を用いる。
 (3) コンパイラがデータ依存性を解析し、ハードウェアが実行時に自分で再構成する必要のないように、EDGE ISAを用いる。
 (4) テキサス大学のデモでは、1024個の実行中の命令から、クロックあたり16個の命令を実行することができた。
 (5) 試作器は、IBMにより130nmテクノロジを用い、366MHzで走った。45Wで12 GFを実現した。
 
6) In Memoriam
最近の1年に亡くなられた方、
a) Ken Kennedy, 61
b) Jim Gray, 62
 1998年のTuring賞受賞。2007年1月28日に母親の散骨のためにサンフランシスコ近海のファラロン諸島にヨットで向かい、行方不明となった。
c) John Backus, 82
 Fortranの開発者。Backus-Nauer Formの発明者。
 
7) 受賞者
a) Seymour Cray Award -- 渡辺貞氏
b) Sidney Fernback Award -- Edward Seidel
 
8) 技術の進歩
a) IntelのハフニウムHfによる、45nmプロセッサ。IBMもAMDと協力して同様な技術を開発している。
b) 100 Gigabit Ethernet
 Finistar, Infinera, Internet2により、TampaからHoustonまで、10本の10 Gb/s DWDMチャンネルを用いて実現。現在の10Gb/sのインフラのままで、波長多重により、100Gb/sが可能かもしれない。
c) 3D Stacking
  -- Samsungはウェーファーレベルで実現。8個の2G bのNANDを積み上げて、16GbのNANDを作り上げた
  -- 東芝はthrough-hole technologyにより3D memory cell arrayを構成した。
  -- IBMは、3D stackingを用いて、SRAMを作成
 
9) Preparing for the Preposterous(「非常識の時代に向かって」の意味か)
a) エクサスケール(1018 flops)への蛙跳び
  -- 3rd Workshop on Frontiers of Extreme Computing
  -- DOE: Town Hall meetings
  -- DARPA study
 
10) 終わりに
a) 標準的なHECシステム---2007年版
  -- コモディティクラスタ(トップはMPPか?)
  -- Intel 64-bit x86 microprocessor (Woodcrest) (私は本当はOpteronが好きなのだが)
  -- Hewlett-Packardがシステム統合
  -- Dualcore
  -- 2048 scalar Processors
  -- 10 Teraflopsの性能(Top500の平均)
  -- 2 TB main memory (1 GB/proc. core)
  -- Infiniband interconnect
  -- MPICH-2
  -- Linux
  -- 8 racks
 
b) 2006から2007へのまとめ
  -- ハードウェアの進歩した年であった。
  -- 商品のどのレベルでもマルチコアが優位
  -- ソフトウェア環境の洗練さと頑強さについて詳しい研究が行われたが、進歩は大きくない。
  -- リーダー達、友人達の死去
  -- ペタスケールがメインストリームになることが見えてきた今日、次のエクサスケールの未来が見え始めた。
 
3.8 BOF (17:15〜)
 
 この後10のBoF (Birds of a feather) sessionsが行われた。
 
3.9 Get-Together Party (19:00〜)
 
 スポンサーの提供により、夕方7時から会場内で、Get-Together Partyが開かれた。
 
4.6月28日(木曜日)
 
4.1 Financial Applications and HPC(8:30-)
 4つの講演があった。
 
4.2 Thomas Sterling (11:00--) "Multicore---the Next "Moore's Law"
 前日の1年回顧の講演でも触れていたが、この講演はマルチコアにテーマを絞ったものであった。なかなか詳細にわたった講演であり、スライドを見ても技術の詳細は理解していない。だいたいの感じをつかんでいただくだけのメモです。
 
 2007年はマルチコアの元年と言われるであろう。これまでのマイクロプロセッサの時代は、マルチコア/ヘテロの時代に移りつつある。
 
1) マルチコアとは何か
a) マルチコアの動機
  -- 拡大したサイズと密度を活用するために
  -- チップあたりの機能ユニット(空間的効率)を増加するために
  -- 演算あたりのエネルギー消費を制限するために
  -- プロセッサの複雑さの増加を制約するために
b) マルチコアから来るチャレンジ
  -- 多重スレッド並列性の有効利用を前提としている。並列計算モデルや並列プログラミングモデルが必要。
  -- メモリ・ウォールを悪化させる。メモリバンド幅、レイテンシ、L3キャッシュのフラグメンテーション
  -- ピンがネックになる。ピン数の増加もピン当たりのバンド幅もあまり改善されていない。
  -- プロセッサ間を有効に調整するメカニズム(同期、排他制御、コンテキスト切り替え)の必要性。
c) ヘテロなマルチコアのアーキテクチャ。違うタイプのプロセッサの結合。
  -- 各々は異なる動作モードに最適化されている。そのため、n個のプロセッサを組み合わせたとき、n倍以上の性能向上がある。
d) 従来のコプロセッサ
  -- GPU
  -- ネットワーク制御装置
  -- 専用目的の要素を一般的なアプリに応用する努力が行われている。
e) 特定の目的のために設計されたアクセラレータ
  -- 1ないし複数の計算のクラスのある種のクリティカルな側面を加速する
  -- IBM Cell アーキテクチャ
  -- ClearSpeedのSIMD型アレープロセッサ
 
2) HPCのマルチコア利用者の直面する根本的諸問題
a) マルチコアは今後10年のMooreの法則の進歩を架橋できるか?
b) ピンやキャッシュは、今後のマルチコアの有効性の弱点とならないか?
c) 何かの革新的なアルゴリズムのテクニックがこの好機を逃さず、マルチコアのチャレンジに答えうるか?
d) プログラミングモデルやそれをサポートするシステムソフトウェアが、マルチコア構造のユニークな性質や特質を活用するように変わっていくだろうか?
 
3) メニーコア
[一つのコアを単純化し、チップ上に多数搭載したものを特にmanycoreと言う]
a) メニーコアは今に始まったわけではない。1993年にはExecubeが作られた。これはおそらく最初のマルチコアであろう。
  -- PIM (Processor-in-Memory) アーキテクチャ
  -- IBMのPeter Koggeによって1993年に開発された。
  -- 0.8μのCMOSで実装
  -- 8-wayのハイパーキューブの相互接続。
  -- クロックは25MHzで、ピーク性能は50 MIPS
  -- 局所(チップ内?)のメモリは512KB。16個のDRAMマクロにまとめられていた。
  -- 消費電力は2.7W
4) IBM BlueGene/Lのノード
a) 2個のPowerPC440プロセッサと組み込みDRAMキャッシュをASICにまとめた。
b) 11層Cu配線、130nm CMOS, 0.95億トランジスタ
c) 2x32KB L1 caches (2つのコア間のコヒーレンスなし)、15x128-bit L2 prefetch buffer, 4MB L3 cache/scratchpad
d) プロセッサ毎に、2本のパイプライン("double-hummer")FPU
e) クロックは700MHz, 倍精度のピーク性能は5.6GF
f) 外部メモリとのバンド幅は5.6 GB/s
g) 消費電力12.9W
 
5) BlueGene/Lは依然世界最速の計算機
 
6) AMD Opteron
a) Dualcoreは2005年5月に導入
b) 90nmプロセスで199mm2ダイ、2.33億トランジスタ。
c) 2.8 GHzで11.2 GF
d) 2x64 KB L1, 1MB L2 caches (per core)
e) Integrated memory controllerによりピークバンド幅10.7 GB/s (DDR2-667)
f) 3個までのハイパートランスポートで24GB/sの転送速度
g) 消費電力119W (2220SE at 2.8 GHz)
h) 2007年中頃にBarcelonaが出る予定。
  -- 65nmプロセスによるquadcore
  -- 128-bit 幅のFP実行パイプライン(コア当たりのピークGFを倍増)
  -- サイクル当たり2つの128bit loadsが可能
  -- 2 MB 共有L3キャッシュ
  -- 68, 96, 120 W thermal envelopes (?)
 
6) Intel Xeon Clovertown
a) 一つのパッケージに2つのdualcoreを乗せてquadcore
b) 65nmプロセスで2x143mm2(5.82億トランジスタ)
c) 2x32KB L1 caches per core
d) 4MB L2 cache per die(2つのコアで共有)、全体では8MB
e) 発熱量は2.66Ghzで120W
f) クロックは3GHzまで行ける。その場合の消費電力は150W
g) 1333 MHz front side busにより最大21GB/sメモリバンド幅
 
7) Sun UltraSPARC Niagara
a) Multithreading, multicore CPU
b) 4, 6, 8 cores on a single die
c) 各コアでbarrel processing (サイクル毎にスレッドの間でスイッチする)により多重スレッドが可能。
d) SPARC V9 命令セットをフルにサポート
e) UltraSPARC T1 の特徴
  -- 90nm, 9層Cu配線CMOSプロセスにより、350mm2ダイに実装。
  -- 1.2GHzで合計32スレッドをサポート
  -- 640x64-bit register file per core
  -- 16KB instruction, 8 KB L1 data cache per core
  -- コア当たり、16KB 命令キャッシュ、8KB L1データキャッシュ
  -- 統合された3MB L2 cache, 25.6 GB/s bandwidth
  -- 暗号解読のためモジュロ演算をサポート
  -- パイプライン、L2キャッシュ、共有CPU資源を200GB/sの内部クロスバで結合。
  -- すべてのコアに共有される1個のFPU[これはひどい]。単精度で40サイクル、倍精度で400サイクルのレイテンシ。
  -- 消費電力は、平均72W、ピーク79W
 
8) Sun UltraSPARC Niagara II
a) Niagaraアーキテクチャの改良版
b) 2007年後半に発表される予定[8月7日に発表された]
c) T1と比べて、スループットやワット当たりの性能で2倍、浮動小数演算では10倍の向上[前がひどすぎた]
d) UltraSPARC T2の特徴
  -- 11層配線、65nmプロセス、342mm2
  -- 1.4 GHzで64本の並行スレッドをサポート
  -- コア当たり2個の実行ユニット
  -- コア当たり2個のALUと1個のFPU(8スレッドで共有)
  -- コア当たり、16KB 命令キャッシュ、8KBデータキャッシュ
  -- 4MB L2 cacheを共有
  -- 8x9 のクロスバースイッチ
  -- 2個のdual-speed 10G/1G Ethernet ports and 8-lane PCI-Express interface
  -- 消費電力は84W (1.1V)
 
9) Cell Broadband Engine
a) "STI" alliance(ソニー、東芝、IBM)の産物
b) 開発費は$400Mと推定される
c) デザインセンターはテキサス州オースチンに2001年3月発足
d) 増強されたPOWER4 toolchainを利用
e) 400人の技術者と、11のIBM研究センターとにより4年掛かった。
f) 元々のターゲットアプリ
  -- Sony Playstation 3
  -- IBM blade server
  -- Toshiba HDTV
g) 2005年にLinux kernelが導入された
 
10) Cellのパラメータ
a) 234Mトランジスタ
b) 90nmプロセスで221mm2ダイ
c) SOI, low-k dielectrics, 銅配線
d) クロック3.2 GHz
e) ピーク性能
  -- 205 GF (単精度)
  -- 26 GF(倍精度)
  -- メモリバンド幅25.6 GB/s
  -- I/O バンド幅76.8GB/s(外向き48.8 GB/s、内向き32 GB/s)
  -- 動作電圧1〜1.2V
  -- 5種の電力状態がある
 
11) Cellの要素とレイアウト
a) PPE (Power Processing Element)1個
  -- 2x32 KB L1, 512KB L2 cahce
  -- 32x128-bit register file
  -- VMX
b) SPE (Synergistic Processing Elements)8個
  -- 256 KB local store
  -- 128x128-bit register file
  -- 128-bit SIMD
c) EIB (Element Interconnect Bus)
  -- 96 B/ccle (300 GB/s peak)
d) Dual channel XDR memory controller
e) FlexIO external I/O interface
 
12) IBM Cyclops-64 Multicore Chip
a) PIM型のデザイン:組み込みDRAM、処理回路、通信回路がチップ上に
b) 75プロセッサから成る。各プロセッサは、
  -- 2個のスレッドユニット
  -- 共有のFPU
  -- 2個のSRAMバンク(32KB)
c) 各スレッドユニットは
  -- デコーダーと命令シークエンサ
  -- register file (64x32bit、二つ組み合わせて64bitデータとして処理できる)
  -- 固定小数点ユニット
d) 3-operando load-store ISAを持つ。命令型は60。
e) 相互接続は、96-port 7 stage corssbar network。これは同時に外部ノードへのゲートウェイを提供。外部は3Dメッシュ、GigE portおよびATAディスクインターフェースを各ノードが持つ。
f) 0.18μCMOSで500MHzで動作
 
13) Intel Tera-scale Processor
a) チップ上に80個の単純なコア
b) コア当たり2個のプログラム可能な浮動小数エンジン
c) デザインの特徴
  -- タイル上のデザイン
  -- チップ上のネットワーク(各コアは5-portのメッセージ・パッシング・ルーターを持ち、2Dメッシュに接続される)
d) 細粒度の電力管理。計算エンジンやルーターは個別に眠らせられる。
e) 他の技術革新:sleep transistors , mesochronous clocking, clock gating 中身不明
f) 62Wの消費電力で1 TF peak性能
 
14) ClearSpeed CSX600 アクセラレータ
a) 96 PE's
b) 128 M transisteors
c) peak 48 GF (64-bit), 33 GF (DGEMM)
d) 25,000 MIPS, 25 integer GMAC/s
e) 内部96 GB/s、外部3.2 GB/sのメモリバンド幅
f) 250MHzで約10W
 
15) マルチコアは、次の10年のMooreの法則の進展を架橋できるか
a) 空間的スケーリングへの制約
  -- 空間的オーバーヘッドはいろいろある。
  -- チップ内、コア間の通信(コア数の1乗以上で増加)
  -- 各コアのコンテキスト状態を記憶するオンチップメモリ
  -- レイテンシ隠蔽のための資源(クロック周波数、チップ上レイテンシとともに増加)
  -- チップのI/Oピンのための面積
  -- キャッシュサイズ
  -- 共有キャッシュのポート
b) すでに8コアのチップまである。もし毎年2倍に成るとすると、2012年には128コアが出現。
c) キャッシュ・コヒーレントにできるか?
  -- たぶんできるだろうが、他のキャッシュにアクセスすることになり、高価。
  -- たとえば、core 1からのデータ要求がL1キャッシュミスを引き起こしたとすると、要求はL2キャッシュに送られる。もしこの要求がcore 2のL1データキャッシュの修正されたラインにぶつかるとすると、ある種の内部的条件によってはcore 1に誤ったデータを返すことになる。
  -- 64 coresでこれが起こったらどうなるか。1024なら?
d) 128個の並行しているが異なるメモリ参照のメモリレイテンシを、プリフェッチにより隠蔽できるか?
e) マルチコアプロセッサ上のMPI
  -- Darius Buntinas and Guillaume Mercierの研究
  -- 340 ns MPI ping/pong latency
  -- 改良の余地がある(よりよいソフトウェアツールが必要だが)
 
16) マルチコアに対応するための従来の戦略
a) 現状を守れ
  -- 現在のコードへの投資
  -- コアのデザインへの投資
b) L2/L3 cahce sizeを増大せよ
  -- 現状の時間的局所性を活用せよ
c) チップのI/Oバンド幅を増加せよ
  -- 衝突を減らせ
  -- チップ間接続のための光接続をしないとダメであろう
d) "weaver"(機織り?)チップによりメモリバンド幅を集める(?)
  -- プロセッサのデータ需要をメモリの供給速度にバランスさせる
  -- 多重に重複するメモリバンクを可能にし、調整する
e) Job stream parallelismを活用せよ。
  -- 独立なジョブ(OSのスケジューリング)
  -- 並行するパラメータ走査(同一のジョブをパラメータを変えながら実行)
  -- 疎粒度で通信している複数の逐次プロセス
 
17) 並列処理の「黙示録の4匹の馬」
[新約聖書黙示録6章1-8節では、小羊(キリスト)が第一の封印を解くと白い馬が、第二の封印を解くと真っ赤な馬が、第三の封印を解くと真っ黒な馬が、第四の封印を解くと蒼白い馬が現れる。4匹の馬とそれに乗る騎士は、戦争、内乱、死と飢餓、悪疫などを象徴する。ここでは、4匹の馬は、「オーバーヘッド」「レイテンシ」「衝突」「スターべーション」であろう。]
a) オーバーヘッド
  -- 並列な資源や並行する動作を管理するためのクリティカル・パスを探す。
  -- 厳密なスケーリングへの上限を与える。
b) レイテンシ
  -- 遠くへのアクセスやサービスに対するサイクル単位の遅延
c) 衝突
  -- 共有資源のための待ち時間
d) スターべーション
  -- すべての労働者に十分な仕事が与えられていない。
  -- 不十分な並列性
  -- 負荷バランスがうまく行っていない
 
18) マルチコアに対する従来の改良的アプローチの限界
a) チップ上のSMPだけではない
  -- ピンの逆側のコア[何のこと?]
  -- ユーザは、今のアプリ上で性能が向上することを期待する
b) 時間的局所性に非常に敏感である
  -- メモリ・レイテンシが存在する状況の中では弱い
  -- チップの面積の大部分をキャッシュのために使うことになる。
c) ALUを貴重な資源であるかのごとく強調している
  -- ALUは空間的にコストがかからない
  -- メモリバンド幅は、データインテンシブは問題にとって律速要素である。
d) エネルギー利用の有効性は低い
  -- コアの複雑性に苦しんでいる
e) なぜ効率が低いかの本質的な問題に対応していない
  -- Mooreの法則に単純に期待している
  -- ピーク性能と実効性のの比は一桁(%)である
  -- ALUがクリティカル・パスである場合は悪い
f) メモリ・ウォールはますます悪くなる。
 
14) 私の見解と偏見
a) マルチコアは、Mooreの法則が成り立たせるための現状のアーキテクチャ的な戦略である
  -- 得られるべき性能を達成する重荷は、不可避的にコンパイラやアプリの開発者に移る。
  -- このようなことは、計算のパラダイムが変わるたびにいつでも起こってきた(スーパースカラ、ベクトル、並列、....)
  -- それについて行こうという努力は、ソフトウェアのユーザビリティの進歩を阻害してきた。
b) マルチコアは80年代後半のSMP技術の単純な復活ではない
  -- バンド幅の制約:ピン数はコア数に比例しない
  -- メモリの階層構造がさらに複雑になる(共有や部分共有キャッシュとか)連想性はコア数にスケールしない。
c) マルチコアチップはクラスタに用いられるであろう
  -- 多次元並列性が問題になる
d) 並列計算標準ソフトウェアの移植は、うまくいかない
 
15) システムソフトウェアへの重荷
a) マルチコアチップは種々の実装が実現するであろう
  -- コア数
  -- キャッシュサイズ
  -- キャッシュ階層性における共有のパターン
  -- チップ上の不均一性
b) プログラム開発者に、特定のマルチコア・プラットフォーム向きにプログラムを開発することを奨励したくない
  -- 希望する性能を出すためには、チップ毎にアプリを書き直さなければならないであろう。
  -- 笑ってはいけない。これは過去にも起こってきた。メモリの階層性が深くなったときなど。
c) コンパイラやシステムソフトウェアは、抽象的なプログラミングモデルを特定のプラットフォームに翻訳するものでなければならない。
  -- これまでは、SMPやクラスタのソフトを単純に移植するだけであった。このやり方では、性能の問題が不可避である。
 
16) バンド幅の管理
a) マルチコアは計算のパワーを急速に増大させる
  -- しかしチップへのバンド幅はそれについて行けそうもない
b) マルチコアは共有キャッシュが特徴となるであろう
  -- false sharingの代わりにconflictの確率が増大する
c) バンド幅の有効利用へのチャレンジ
  -- 複数のプロセッサがキャッシュを使うときに再利用を増大する
  -- キャッシュブロックの利用密度を増加するためにデータを再構成する
  -- データの再利用を保証するために、計算を再構成する(ループ融合、タイリング、コア間パイプライニング)
  -- キャッシュミスの衝突の管理(アーキテクチャの補助あり、なし)
d) アーキテクチャの補助なしで
  -- ページ間のデータ再構成と、ミスの衝突を最小限にするための同期(おそらく、特別なメモリ配置のための実行時プリミティブが必要になるであろう)。
 
17) 疑問
a) 特定の計算でミスの衝突が最小化できるように、データを正確にぺージ内に配置することができるか?
  -- 自己衝突ミスを最小化するための研究が行われている
  -- アレイ間の衝突のメカニズムについてはほとんど研究がなされていない
  -- プロセッサ間の衝突を最小化する研究は、私の知る限りない。
  -- ページサイズが小さかったり、どこにページがロードされるか制御できない状態ではこれはほとんど不可能である。
b) 複数のコアが互いに干渉しないように計算を同期できるか?
  -- プロセッサを越えてのブロックの再利用は
c) このような問題を解決するような新たな特徴を付加するようベンダを説得できるか?
  -- キャッシュの一部をスクラッチパッドに配置すること
  -- キャッシュマッピングの動的な修正
  -- 同期へのハードウェアサポート
 
18) マルチコアへの二つの戦略
a) 構造
  -- 並列実行管理のためのオーバーヘッドの少ないメカニズム
  -- メモリ内計算(時間的局所性の少ないとき)や高いデータ再利用ストリーミング(時間的局所性の大きいとき)に対するヘテロなサポート
  -- 貴重な技術要素(ALUは安いが、バンド幅は高い)を考慮した資源の再バランス
b) 実行モデル
  -- 並列粒度の形式とスケールの多様性を活用する
  -- 固有のレイテンシ隠蔽
  -- 動的で柔軟な資源管理
 
19) マルチコアとメモリの融合
a) ダイをコアで埋めてしまうと、外部メモリとのバンド幅のためにダイ面積を必要とする。
b) 「メモリ中での処理」局所バンド幅は十分。
c) Xcaliber Systemの例
 
20) Multicore ParalleX Model
a) 局所性のドメイン
  -- 内部局所性:同期性が保たれている
  -- 外部局所性:局所性の間では非同期
b) 分散共有メモリ
  -- キャッシュはコヒーレントでない
  -- コピーのセマンティックス
  -- アフィニティの関係
c) Split-phase transactions
  -- Work queue model(局所的な状態の上でのみ動作、遠隔アクセスに対し、ブロッキングもアイドルタイムもない
d) メッセージ駆動計算
  -- パーセルが、データ、ターゲットアドレス、動作、次を運ぶ
  -- パーコレーション
[データフローと違う?]
e) マルチスレッド
  -- 第一級オブジェクト
  -- 過渡的な値のデータフロー
f) 局所的(ライトウェイトの)制御オブジェクト(?)
  -- 未来
  -- データフロー
  -- データ指向並列制御
g) アドレス変換を組み込んだメタデータ
h) Failure-oriented with micro-checkpointing
i) 動的最適化
 
21) Multicore ParalleX & Xcaliber and the Four Horsemen
a) オーバーヘッド
  -- パーセル、マルチスレッディング、細粒度ストリーミング実行、アドレス変換をサポートするハードウェア
b) レイテンシ
  -- ストリーミングアクセラレータに対するパーコレーション
  -- パーセルは大域的レイテンシを、非同期の仕事のキューで隠す
  -- マルチスレッディングは局所的な実行とメモリレイテンシを隠す
  -- ALUからメモリバンクへのレイテンシは低い
c) 衝突
  -- ストリーミングアクセラレータへのバンド幅は高い
  -- 高度なメモリバンド幅に対応
  -- 遠隔サービス要求をバッファーする
  -- ノンブロッキング並行動作をサポート
d) スターべーション
  -- 有向グラフのデータ並列性を有効に示す
  -- スレッド間データフロー並列性
  -- マルチスレッド並列性の利用
  -- アクセラレータにおけるストリーミング並列性
 
22) 結論と私見
a) Multicore/Manycore/Myriacoreは技術の進歩であり、アーキテクチャの進歩ではない。
  -- 目的とする最適化機能を考え直さなければならない:ALU利用率、メモリバランス
  -- チップへのバンド幅:チップ間の直接光接続
  -- 軽いコアアーキテクチャを考え直せ
b) 英雄的なアプリのプログラマにとって、近未来は過去10年と同様であろう
  -- 苦痛、不安、辞任
  -- 勝利の高揚もあれば絶望の時もある
c) アーキテクチャの構造と固有のセマンティックスの本格的な再考(ハードウェアサポートの仕組み)
  -- 時間的局所性プログラム属性に基づく処理の二つの型(PIM+データフローストリーミング)
  -- 大域的なネーム空間における軽い同期を持つ、拡張されたアクティブ・メッセージ駆動のマルチスレッド実行
d) 新世代の実行モデルとプログラミング環境に導かれて
 
4.3 Tsugio Magimoto (11:47-)
 基調講演として牧本次生氏(元ソニー、TechnoVision Consulting)の講演があった。タイトルは、"Impact of Chip Innovations Driving the Computing Power"。牧本氏とえいば日本の半導体業界の顔ともいえる存在で、1991年に,半導体産業には「標準品化」を重視しする時期と「カスタム化(専用化)」を追い求める時期が10年の周期で繰り返すとの知見を披露,この説は「牧本ウエーブ」として知られている。
 
 まず、かれは、これまでComputer, Communication, Consumerとして別々の産業が興ってきたが、いまやそれがDigital Consumer Productsに収束しつつある状況を指摘した。PCは年々減少しているが、TVやDVDやDSC(Digital Still Camera)は急激に増大している。IBMは1981年にPCビジネスを始めたが、売り上げは頭打ちになり、2005年にはPCビジネスを中国のLenovoに売却した。
 このようにコンピュータ産業の様相はどんどん変化している。AppleのiPodは可搬型音楽プレーヤの新しいトレンドを切り開いた。Microsoftはゲームビジネスを始めた。Dellはフラットパネルテレビを始めた。IBMはゲームチップを3つのメジャーな会社に提供している。
 カメラもアナログからデジタルに転換した。日本では東京、大阪、名古屋で地デジが始まった。2011年には1億台のテレビがデジタルに置き換えられる。これは200兆円の経済効果がある。
 このようにエレクトロニックスは波状的に変化している。1970年頃からanalogue wave が始まったが、1990年頃には第一のデジタルの波であるPCがこれを追い抜いた。しかし、第二のデジタルの波があり、2000年ころにはデジタルな家庭機器やネットワークがこれを追い抜きつつある。
 チップの技術革新には独自のメカニズムがある。まず、技術革新は不連続だということである。1947年にBell研でトランジスタが発明されたが、1958年のKilbyや1959年のNoyceによってICが発明された。そして、1971年にはIntelによってマイクロプロセッサが発明された。そして、技術革新は指数的であるということである。1965年のMooreの法則がそれを示している。そして、私が1991年に提唱したように、技術革新は周期的である。
 これらの変化はPS-2のチップの1999年から2004年までの変化をみるとよく分かる。1999年にはEmotion Engineが240mm2で、Graphic Synthesizerが279mm2で2つのチップからできていたが、2004年には両社が86mm2の一つのチップにのってしまった。SoC (System on Chip) のインパクトは大きい。前はボードに5個のチップでできていたものが、今や一つのチップにすべて収まっている。しかも性能は4倍である。しかし反面、開発のコストは急激に増大している。
 私は1991年に半導体の動向が10年ごとに交代していることを見いだし、牧本ウェーブと呼ばれるようになった。1957年から1967年までは標準化のフェーズであったが、1967年から1977年頃まではテレビや電卓のためにカスタム化の時代となった。1977年からの10年は、メモリやマイクロプロセッサの標準化の時代になった。1987年からの10年はASICが盛んになり、再びカスタム化の時代になった。1997年から2007年はField Programmabilityが重要視され、再び標準化が優勢となった。この時代は、製造としては標準化されているが、応用ではカスタム化されているという特徴がある。今後どういう時代になるであろうか。
 では、なぜField Programmabilityが重要なのだろうか。それは、従来の製品が3年から5年の寿命を持っていたのに、新しいデジタルなコンシューマ機器は寿命が1年前後と短く、Field ProgrammabilityはMUSTである。FPGAは、医療画像処理、HPC、データ解析など広い範囲に応用されている。
 牧本ウェーブの周期は振り子に例えられる。標準化に振れているとき、それを推し進めているのは新しいデバイスや新しいアーキテクチャである。逆にカスタム化の方向に押しているのは、差別化、高性能化、省電力化である。カスタム化の方に振れているとき、それをカスタム化の方向に押しているのは、デザイン・オートメーションとデザイン方法論である。逆に、標準化の方向に押しているのは、市場に出るまでの時間の短縮化、開発費用、運転の効率化である。
 さて、この周期を振り子にすると、どのくらいの長さが必要だろうか。勿論、重力加速度は地上と同じとして。答は8.6光年である。[牧本氏はこのジョークが好きらしい。]
 さて、コンピュータ革命の歴史を見てみよう。1950年前後最初にコンピュータができた頃は国に1つもあればよい、と思われた。1960年代になってIBM360が出現し会社に1台ということになった。1970年代にはVAX-11が出現して部門に一台となった。1980年代にはPCの出現により一人に1台となり、その後はどこでもコンピュータということになった。初期のUNIVAC-1と現在の携帯用PCとを比較すると、性能は2万倍になったのに、価格は1000分の一、大きさも電力も10万分の一である。
 電気機器の価値指数を
            (知性)
      -------------------------------
      (サイズ)×(費用)×(消費電力)
で表すと、1940年代から現在まで1018増加している。これは10年に1000倍である。
 Cray-1は1976年Cray Research Inc.によって発売されたが、160MFLOPSという(当時としては)とてつもない性能を持っていた。これは、4ゲートのNANDのICを使って組み立てたもので、値段は$6M、重量は5.5 tonsであった。このCray-1の性能は今のiPodと同程度であった。
 地球シミュレータは2002年に開発され、40TFLOPSのピーク性能を持っていたが、その1チップベクトルプロセッサは、一昔前の大きな筐体の性能に匹敵している。
 それでは今後どうなるであろうか。CELLプロセッサはIBMと東芝とソニーとの共同開発であり、9コアのmulticore chipであり、256GFLOPSの性能を持っている。単精度ではあるが、地球シミュレータの32プロセッサ分に相当する。いつか、卓上の地球シミュレータが出現するであろうか。
 将来のインテグレーション密度はどんどん上昇する。2018年にはチップ上に5 BTr.が乗るであろう。しかし、チップの技術はどんどん多様化するである。たとえば、光学センサ、慣性力センサ、外力センサ、表示デバイス、アクチュエータ、RFデバイスなど。特にロボットの知能の進歩は著しい。ロボカップの目標は2050年までに人間とサッカーのできるロボットを開発することである。
 まとめると、
●コンシューマ電子機器のデジタル化はますます進行し、市場の収束をもたらす。
●チップの技術革新により、価値指数は今後の10年に1000倍に増大する。
●将来のアーキテクチャにとって、プログラム可能性と再構成可能性はキーである。
●ロボットは新しい機会を開くであろう。
 
4.4 Exhibitor Forum (9:30-12:30)
 木曜日の午前は、一般セッションと並行して二つの会場でExhibitor Forumがあった。展示を出している企業が30分ずつ講演した。ClearSpeedだけ紹介する。
 
4.4.1 ClearSpeed
 ClearSpeedは、CTOのJohn Gustafsonが講演した。題名は、"Using Accelerators to Escape the Shackles of 20th Century Software"であった。
 
 これまでは、FLOP/secとかストレージとかが主要なコストであったが、今では、プログラマーや消費電力やバンド幅である。レガシーコードではなくとも古いアルゴリズムを動かす必要がある。猛烈なトランジスタ数を使いこなす方法論として、
  -- まずベクトル、次にスレッドを加える。
  -- 電力予算に対する高い絶対性能を考えると、プログラマーが高い効率を実現する圧力が減る。
  -- 不均一なスレッドに対するロバストな可視化ツールが必要。
 20世紀からの3つの足かせ。
   -- 浮動小数演算、特に64ビット演算は高価なので、演算数をできるだけ少なくするアルゴリズムを使うべきである。
  -- メモリは高価であり、システムのコストの大部分を占めるので、バイト数が最も少なくなるようにプログラムしなければならない。
  -- 並列処理は多くのイベントを制御しなくてはならないので困難である。下あってアルゴリズムは逐次処理で表現すべきである。
 この足かせは今でもシステムを使う時に影響している。しかし、われわれは努めてこのような考え方から脱却しなければならない。
 21世紀の真実は、トランジスタはゴミのように安いということである。
  -- 浮動小数演算は実行時間や費用の小さな部分であり、データのフェッチやストアの時間に隠れている。
  -- メモリはバイトあたり非常に安いので、ギガバイトを遊ばせても気にする必要はない。
  -- 単一スレッドはデータ並列性を簡単に表現することができる。ヘテロな並列スレッドは、もし完全な可視化ツールがあれば、使いこなすことができる。
 古いアルゴリズムをうまく行かせるには、まず線形解法を考えよう。疎行列の疎度がある程度以上なら、密行列の解法を使った方が、演算量は多いが時間は短くなる。
  -- 最近のIEEE Computerの論文によると、4000x4000行列で非ゼロ率2%の方程式にFPGAを使うことにより、時間を67.3秒から33.8秒に短縮できた。
  -- しかし、密行列の解法を使えば3秒以下である。メモリは128MB必要だが、今なら$10だ。
  -- 1970年代のアルゴリズムの新版を作るのに何百時間も使って10倍のスローダウンを実現している。こういう間違ったことすべては無駄だ。
  -- 対称行列用のコードを作っても演算量やメモリは高々2倍しか得しない。しかし実行時間は増大し、プログラマの努力は大変だ。
 ではFFT はどうか。FFTはn2の演算量をn log n まで減少させた。
  -- 大きなradixを使ったFFTは演算量は多いが時間は短い。
  -- このことは最初Cray-1でradix-64のFFTで観測された。昔の「遅い」アルゴリズムは今は速い。
  -- その理由は、物理的なfetch/storeはFFTでも依然n2なので、データ並列性をハードウェアにより活用することは、演算量を減らすより遙かに重要である。
 250W 使ってよければ何ができるか。
  平均ワット数 32-bit peak GF 64-bit peak GF
Clovertown 3.6GHz 250 86 57
Nvidia Tesla 170 〜500 0
Future Nvidia 64-bit 〜200 538 538
ATI Radeon 〜200 550 0
Future 64-bit Radeon 〜200 575 575
Cell BE 210 230 15
Future Cell HPC 220 200 104
10 ClearSpeed Advance Boards
250

806

806
2005年のClearSpeed製品だって他の製品(今後のものも)勝てる。
 超省電力のアプローチによってより高いGFLOPSが可能になる。ClearSpeedは32-bitでも64-bitでも最大のGFlops性能を有する。最低の電力は、結局最小の面積に設置できる。
 50 GFを実現するのに高い効率が必要でないのは利点。
  -- 4-core x86なら90%の効率を出さなければならない。
  -- 将来版の64-bit Cellなら50%の効率が必要。
  -- 将来版の64-bit GPUなら、10%の効率でよい。
  -- ClearSpeed boardならわずか6%でよい。
ClearSpeedの省電力性により、プログラマは最適化の必要が減るので使いやすさに通じる。
 ClearSpeed CSX600について
  -- 96個のProcessor Elementsのアレイ。64-bit と32-bitの両方。
  -- 電力効率のため210 MHzという低いクロックレートで動作。
  -- 論理が47%、メモリが53%。論理の約半分はFPU。すなわちチップの1/4は浮動小数ハードウェアで占める。
  -- 内部バンド幅は約1 TB/s(Tier 0のことか?)
  -- 1.28億トランジスタ
  -- 消費電力は10W。しかし、DGEMMの実行速度は33 GF。
 高いバンド幅は、ベクトル的な(SIMD的な)並列性から来ている。
  -- Tier 0: PEの演算回路(0.5 GF)からレジスタメモリ(128B)へ。load 2本、store 1本。
  -- Tier 1: レジスタメモリからPoly Memory (6 KB)へ(以上はPE毎)。
  -- Tier 2: Poly Memoryから2バンクメモリ(CSX DRAM 0.5 GB)へ。
  -- Tier 3: バンクメモリからホストのDRAMへ
数学関数(sqrt, exp, sinなど)はTier 1で計算されるので速い。
 ヘテロなマルチコアシステムを使いこなすには、
  -- OS, アプリ、コード、ツール、ホストの言語などはできる限り変更しない。
  -- 特別なマルチコアCPU向きの新しいツールは、可能な限り知っていると思われるものを。
  -- それらを、すべてのリソースのシステム全体の性能を表示できる可視化ソフトと統合せよ。
  -- まずデータ並列を使い尽くせ。それからスレッドの管理を。
 プログラマに必要なレベルは、
  -- 命令レベル並列性:自動的(何の苦労も要らない)
  -- データ並列性:ハードウェアのベクトル長がアルゴリズムのベクトル長を越えない限り簡単に表現できる。ただ、"plural" 変数を定義せよ。ちょっとした通信の管理は必要だが。
  -- スレッド並列性:プログラマは、共有/非共有データ、同期、負荷分散、通信バンド幅、レイテンシ、隠蔽などを考える必要がある。
 まとめて、
●演算量とメモリ量という古い足かせは新しいものに置き換えられた、すなわち、プログラミング(の苦労)、バンド幅、消費電力である。
●ClearSpeedはこの3つの新しいコストを解決する。Advance boardは、複数のスレッドを管理するのではなく、トランジスタをHPCのベクトル並列性に振り向ける。
●ClearSpeedのより現代的な特徴は、プログラマに、演算量やメモリは浪費しても、より少ない電力とエネルギーでより少ない時間に仕事を終わらせることを勧告する。
●今後はヘテロなマルチコアの時代が来る。ClearSpeedは優れた可視化ツールにより、この複雑性を使いこなせるようにする。
 (以下、このツールのデモと宣伝)
 
4.5 Hot Seat Session (14:00--19:00)
 木曜日の午後は恒例のhot seat session で、18の会社が10分のプレゼンと5分の質疑応答を行った。質問は、Inquisitors(審問官)という名の4人が壇上にいて、容赦ない質問を行う。
 前半のInquisitorsは、Andreas Ademann (PSI), Wolfgang Becker (SAP), Galen Gisler (U of Oslo), ThomasSterling (Louisian S U)で、後半はFrank Behrendt (Berlin U of Tech), Tohmas Lippert (Julich), Marie-Christine Sawley (CSCS), John Shalf (LBNL)であった。
 5年前に初めて聞いた時にはずいぶん激しいやりとりだなあ、と感心したが、今回の印象はそれほど厳しいつっこみもなく、昔の熱気は冷めた感じである。慣れてしまったからなのかもしれない。
 
4.6 Microsoft Saxon Night at Castle Albrechtsberg (20:00--23:30)
 木曜日の晩は、この会議のメインスポンサーであるマイクロソフトの提供で、バスで20分ほど走ったところにあるザクセン州の古城でパーティーがあった。
 中世の格好をした人が出迎え、演奏や歌や踊りなどいろいろアトラクションもあった。
 
5 6月29日(金曜日)
 
5.1 John Shalf (9:00--) "Overturning the Conventinal Wisdom for the Multicore Era"
 副題に"Everything You Know is Wrong" とあったので、何を言い出すかと思ったが、よく分からなかった。前日の疲れで眠かったためもあるが。
 
1) 性能向上の伝統的源泉は平坦化
a) 15年間続いていたクロック周波数の指数的増大は終わった
b) しかしMooreの法則は続く
  -- 増えたトランジスタをどう使って性能を向上することができるか?
  -- 産業からの答:チップ当たりのコア数は18ヶ月に倍増する
2) ハードウェア:何が問題か
a) 現状のハードウェア/リソグラフィの制約
  -- 最先端のチップの設計の最大問題は消費電力(IntelのTejas Pentium 4は電力問題で開発中止)
  -- 最先端のプロセッサのイールド(良品率)は劇的に落下(IBMの発表によると、8プロセッサのCelloでは10-20%)
  -- 最先端のチップの設計・検証はほとんど管理不能(検証の方が人手が掛かる)
b) 解決法:「小さいことは美しい」
  -- 中庸の段数(5--9)のパイプラインのCPU, FPT, vector, SIMD PEなど(小さなコアでも大きいコアよりそれほど遅いわけではない)
  -- 並列性は性能への電力効率のよいアプローチ:CV2F(閾値を下げれば、供給電圧も下がって演算当たりのエネルギーが減る)
  -- プロセッサに冗長性を持たせればチップのイールドが改善される(Cisco Metroは188 CPUs + 4 soaresの構成。Sun Niagaraは6 or 8 CPUとして余裕を持たせている)
  -- 小さく、規則的な処理エレメントは検証も易しい
 
3) 「小さい」はどの程度小さいか?
a) Power5 (Server)
  -- 389 mm2
  -- 120W@1900MHz
b) Intel Core2 sc (Laptop)
  -- 130 mm2 
  -- 15W@1000MHz
c) ARM Cortex A8 (BMW Auto)
  -- 5 mm2
  -- 0.8W@800MHz
d) Tensilica DP (cell phones)
  -- 0.8 mm2
  -- 0.09W@600MHz
e) Tensilica Xtensa (Cisco Router)
  -- 0.32 mm2 for 3 !
  -- 0.05W@600MHz
 小さなコアは大きなチップの1/3から1/10の効率で動作するが、チップ上に100倍詰め込むことができ、しかも電力は1/20。
 
4) 比較
  伝統的コア スループット重視コア 単位
μアーキテクチャ Out of Order In Order  
サイズ 50 10 mm2
電力 37.5 6.25 W
クロック 4 4 GHz
スレッド数 2 4  
1スレッドの性能 1 0.3 相対性能
ベクトル 4 (128-bit) 16(512-bit)  
ピークのスループット 32 128 GFLOPS
面積性能 0.6 13 GFLOPS/mm2
電力性能 0.9 20 GFLOPS/W
 20倍の電力性能の向上の可能性がある。
 
5) 電力性能はManycoreを動機づける(なぜHPC "users"は心配するのか?)
a) 産業界では電力効率の関心からmanycoreに向かっている。
  -- 電力コスト>ハードウェアコスト
  -- ORNL 2010では、冷却を含めた電力コストが$33M/年 と予想される。
  -- 現在の技術に基づいて外挿するとExascaleの電力は130MW(安い電力を使っても、>$130M/year)
  -- 予算の多くの部分が電力に食われると研究費がなくなる
b) 間違った心配
  -- 昔の基準:計算効率はピークに対する実効性能比
  -- 今の基準:計算効率はワット当たりの性能
    [Old CW, New CW の意味は不明]
  -- ワット当たりの性能は、必然的にプログラムの容易性の考察も含む
  -- ということは、次世代アーキテクチャに進むためには、ハードウェアのアーキテクトはアプリからの要求を理解しなければならない(これは現状からの離脱を必要とする)
 
6) Multicore vs. Manycore
a) Multicore: 現在の路線の上にある
  -- 現在の最高速のコアを踏襲
  -- 18ヶ月毎に複製を増やしていく(2, 4, 8, .....)
  -- 利点:逐次的な処理を疎んじない
  -- 例:AMX X2 (2 cores), Inter Core2 Duo (2 cores), Madison (2 cores), AMD Barcelona (4 cores)
b) Manycore: この方向に収束しつつある(?)
  -- コアを単純化せよ(パイプラインを短縮し、クロック周波数を下げ、in-orderに制御)
  -- 100程度のコア数からはじめ、18ヶ月毎に倍増せよ
  -- 利点:最高の面積当たりの演算数、最良の電力効率、容易な検証、欠陥に慣用、デザインのコストは低い
  -- 例:Cell SPE (8 cores), Nvidia G80 (128 cores), Intel Polaris (80 cores), Cisco/Tensilica Metro (188 cores)
 c)収束:究極的にはManycoreに向かうであろう
  -- プログラムさえ可能ならManycoreがいい
  -- 安全策:Heterogenous Multicore
 
7) HPCシステムの並列度は急速に増大している。1M cores は案外早く来るかも。
 
8) 全コンピュータ産業はその勝利を並列性に賭けている
a) 古いCW:技術革新は先端的計算からPCや家電にしたたり落ちる
b) 新しいCW:流れは逆になった。技術革新は家庭電器アプリからHPCへと流れ上る(ペタフロップス携帯電話?)
  -- 家電の方が電力当たりの計算効率についてわれわれよりよく知っている。
  -- 家電の方が価格性能比についてわれわれよりよく知っている。
c) この転換はHPCだけではない
  -- あなたはこの技術革新の運転席にはいない(それを乗り越えてしまっている)
  -- あなたのモトローラのRazor 携帯電話は8個のCPUコアを搭載している(そして、そこから幾何級数的に成長する)
  -- Cisco CRS-1ルータはソケット当たり188個のtensilica CPU コアを持つ(Metro)。そしてすでに40万コアを売っている(現在のHPCより多い。しかもOSが走っている)。
  -- あなたのトースターもmanycoreプロセッサ上で並列アプリが走るようになる。
d) 産業界は、ソフトウェアを解決しないまま、並列に向かって走っている。
  -- かれらはわれわれ同様怖がっている。
 
9) マルチコア・ソリューションの失敗モード
 マルチコアは次のような理由でうまくいかないと思われている。
a) システムバランス:メモリや相互接続の性能が、究極的にマルチコアの性能の上限を決める
b) 信頼性:「可動部分」が多くなると、欠陥の可能性も増える。
c) プログラム可能性:百万を超えるコアを有効にプログラムできるか?
一つずつ検証してみよう。
 
10) システムバランス(メモリバンド幅)
a) メモリバンド幅が将来のマルチコアの性能の第一の制限ファクターである、と言われれている。。
b) XT3のsingle coreとDualcoreの性能を、いくつかの応用で比較して、メモリバンド幅は広い範囲の応用に対し、実質的に何の効果ももたない。
c) XT4のDualcore Opteronの性能分析から、
  -- FLOPやメモリバンド幅を無限大にしても、性能は15%しか増えない
  -- latency stallのような他の部分を改良するほうが利益は大きい
  -- これはアプリの制限ではない。これはCPUアーキテクチャの問題である。
  -- これはマルチコアになっても状況が悪くなるわけではない。
 
11) システムバランス(相互接続網)
a) バイセクションバンド幅は、将来のMPPの性能の主要な制限要素である(従って、相互接続網はクロスバかCLOSでなければならない)と言われている。
b) アプリの分析から相互接続網(チップ上もチップ間も)に対する要求が分かってきた。
  -- チップ上の接続は2D平面である(クロスバはスケールしない)
  -- dwarfs (?)には疎な接続を。クロスバはやり過ぎ。
  -- 一つのベストなトポロジーはない
c) データに対するバンド幅指向のネットワーク
  -- ほとんどの1対1通信は疎なトポロジーを持ち、バンド幅で制約される。
  -- たとえばTMCのCM-5や、Cray T3D、IBM BlueGene/L&P
d) 究極的にはチップ外の相互接続トポロジーに加えて、チップ上のトポロジーも意識する必要がある。
  -- 適応的なトポロジー接続(HFAST)
  -- 知的なタスクマイグレーション
e) 3次元FFTは高いバイセクションバンド幅を必要とする応用として知られている。
  -- 1次元分解において、すべてのプロセッサは他のすべてのプロセッサにメッセージを送らなければならない(all-to-all)。
  -- しかし、ほとんどの実装では、小さなメッセージを送るオーバーヘッドで制限されている(PTRANSは現実より適している)
  -- 2次元ドメイン分解(高い並列度のためには必要)では、sqrt(N)個のパートナーとの通信しか必要ない(some-to-some)。
f) AMR(?)でも同様
 
11) 信頼性:コア数が多いと信頼性は減少するか?
a) 未来は不確実
  -- シリコン・リソグラフィは原子のサイズに近づいているので、ハードウェアのエラーの可能性は劇的に増える
b) システムの信頼性は、システム中のコア数に比例するとは限らない
  -- 信頼性はシステム中のソケット数に比例する(チップ当たりのコア数ではない)
  -- LLNL BG/LはPurpleより12倍のプロセッサコアを持っているがMTBFは長い。
  -- 周辺デバイス(キャッシュ、メモリコントローラ、相互接続など)を一つのチップに統合すると、チップ数が減少し信頼性が増大する(SOC/System-on-Chip)
c) キーとなる制限因子はソフトウェアの下部構造である
  -- ソフトウェアはデータの統合性が完全だと仮定して設計されている(しかし、これはマルチコアの問題ではない)
  -- ソフトウェアはそれほど大きくない並行度を陰に仮定して書かれている(百万コアはもともとの設計の前提に入っていない)。
  -- したがって、OSや数学ライブラリの設計の前提については、根源的に考え直さなければならない。
 
12) CMP(チップマルチプロセッサ)に対するOS
a) 携帯電話でもOSが必要(でも我々の考えるOSでは大きすぎる)
  -- OSは、多くのコアの資源を仲介し、ウィルスから護り、増加するコードの複雑さを管理する。
  -- しかし、非常に小さくモジュラでなければならない(embedded Linux)
b) 古いOSの前提は数百のコアに対しては正しくない
  -- 共有しなければならないCPUの数を仮定している
  -- 有限なI/O デバイスインタフェースをグリーディに割り当てようとする
   - 古いOS:ロックを最初に獲得したプロセスがデバイスを使える
   - 新しいOS:対称的なデバイスアクセスに対しQoS管理をする
  -- バックグランドタスクの処理はスレッドとシグナルで管理
   - 古いOS:割り込みとスレッド(時間分割で非効率)
   - 新しいOS:DMAと非同期I/O専門のコアを用意する
  -- フォールトの検出
   - 古いOS:CPU failure →カーネルパニック
   - 新しいOS:CPU failure→パーティションをリスタートする
  -- 古いOSはすべてのプロセッサ間通信やスケジュリングを直接のハードウェアアクセスにより呼び出す
c) 新しいOSはどのようなものか
  -- それがどのようなものであれ、Linuxに似ているであろう(そうでないとソフトウェアベンダは大変だ)
  -- Linuxは大きすぎる、しかしマイクロカーネルは十分ロバストでない
  -- modular kernelsが、組み込みLinuxでは普通に使われる
 
13) 超並列におけるI/O
a) 超並列システムに対するスケーラブルなI/O
  -- ノード内(オンチップまたはCMP)のディスクアクセスを調整することについての多くの問題
  -- OSは有限の資源を巡って競合するコアに対するQoSにもっと注目する必要が今後出てくる(mutex locksやグリーディー割り当て方針はうまくいかない。これはラグビーのボールを争うようなものだ。)。
 
タスク数 I/O Rate (16 tasks per node) I/O Rate (8 tasks per node)
8 -- 131 MB/s
16 7 MB/s 139 MB/s
32 11 MB/s 217 MB/s
64 11 MB/s 318 MB/s
128 25 MB/s 471 MB/s
 
14) プログラミングモデル
 HPC(高生産性計算)は並列計算言語の究極の設計目標である。
 
15) Programmability
a) 「並行性のツナミ」に波乗りできるプログラミングモデルにはいろんなパニックが起こる
b) プログラミング環境に対する互いに独立な要求
  -- 生産性
  -- 性能
  -- 正しさ
c) アプローチ
  -- 単一チップの並列性の抽象化(情報家電やコンピュータ業界に広く焦点を置く。HPCでさえ、チップ数の増加はコア数の増加よりはるかに小さい)
  -- 大域的並列性の複雑さを隠蔽する(フレームワーク、進んだコンパイラやプログラミング言語、自動チューニング)
  -- 悪夢のシナリオ:マイクロソフトがin-socketプログラミングモデルを解決し、C#コードの走るソケットの間のMPIで立ち往生。
d) 競合する目標
  -- 生産性の層:解決すべきプログラムや問題の使用を簡単化する
  -- 性能の層:すべてのハードウェアの能力をプログラマに開放する
 
16) マルチコアは親近感のあるプログラミングの目標ではない
a) チップ上のメッセージ・パッシングはどうか
  -- MPIバッファやデータ構造はO(N)またはO(N2)で増大するので、制約のあるメモリでは問題。
  -- 共有変数や共有プログラムイメージに対しメモリを冗長に使用する
  -- マルチコアシステムの階層的な性質からみて、並列性の平面的な描像は意味がない。
b) チップ上のSMPはどうか
  -- ハイブリッドモデル(MPI+OpenMP):長い歴史があるが失敗の歴史だ
  -- しかしチップ上では通常のSMPとは違う
   - チップ上ではバンド幅が10倍から100倍
   - チップ上ではレイテンシも10倍から100倍低い
  -- SMPモデルは、このようにコアが遙かに密に結合している可能性を無視している。
  -- 階層的なマシンアーキテクチャを活用しなくては、並列性を有効活用する能力を劇的に阻害する(コード構造を変えなくては)
c) SMPを越えて
  -- キャッシュのコヒーレンシ:必要であるが十分でない(そしてmanycoreでは有効でない)
  -- 細粒度の言語要素をCCプロトコルの上に構築することは困難である
  -- 細粒度のハードウェア同期に対するハードウェアサポート
  -- メッセージのキュー:メッセージに対する直接のハードウェアサポート
  -- トランザクション:平行性に関する誤った考えから保護せよ
 
17) ハードウェア・トランザクション・メモリは並列性を易しくする
  「銀の弾丸はすでに我々の手にある」
 [銀の弾丸とは、ソフトウエアの開発プロジェクトにおいて,どんなに困難な課題も一気に解決できるような,幻の手法や理論のこと。〔ソフトウエア技術者のブルックス(Frederick P. Brooks)が 1986 年に発表した論文「No Silver Bullet(銀の弾丸などない)」が直接の語源。「銀の弾丸は狼人間を一発で倒せる」とする欧州の伝説から,「魔法の解決策」をいう〕---- goo辞書より]
 
18) トランザクション・メモリは我々を救う
a) トランザクションとは何か
  -- 投機的に実行するが、結果をメモリに返さず、HW支援トランザクションのためにキャッシュに留まる
  -- もし他のスレッドが私のスレッドが読んだのと同じメモリアドレスに書いたなら、結果をすて再実行(ロールバック)
  -- もしデータフロー衝突が起こらなければメモリに結果を書く
b) なぜトランザクションは良いか
  -- すべての反復がトランザクションであるようなループ反復の並列化を仮定しすることができる(Lay-Z-boy parallelization!)
  -- もしデータフローハザード(read-after-write)を不正に推定すると、性能は遅くなるが、答は正しい。これは非常によい性質である
  -- 自動並列化コンパイラはもっとアグレッシブになることができる。
c) なぜトランザクションは悪いか
  -- 入れ子のトランザクションはどうなるか
  -- トランザクション領域と非トランザクション領域とを混ぜたらどうなるか。
  -- トランザクションはどこまで大きくできるか?(有限のハードウェア資源)
 
19) スレッドやロックは汚いプログラミングモデルである
  (といいながら豚の絵を見せた)
 
20) トランザクション・メモリは多少は助けになる
  (といいながら、豚がサングラスを掛け、口紅を塗った絵を見せた)
 
21) プログラミング・モデル
 ある種の進んだコンパイラ技術がわれわれを救うであろう
a) 昔の伝統的な知恵:アーキテクチャの詳細を隠すためにコンパイラに信頼せよ
  -- われわれは、コンパイラによる最適化やバックエンドが扱う情報量を過小評価していた。
  -- コンパイル時には不明で実行時にのみ解決する不定性がたくさんある
  -- 「正しさ」を保証するためには保守的にならざるを得ない
  -- 息を止めて自動並列化を待っていても、そんなものはできない
b) 新しいアプローチ:「自動チューナー」つまりまずプログラムをコンピュータの上で走らせてみて、発見的に最良の最適化(ブロッキング、ぱっでぃんぐなど)やデータ構造の組み合わせを探索する。それから改めてCコードを作る。
  -- 例:PHiPAC (BLAS), Atlas (BLAS), Spiral (DSP), FFT-W
  -- 従来のコンパイラより10倍は速くなる。
  -- チューニング戦略を考えながら知識の本体をコード化する
c) テストケースを作るためにもコンパイラが助けになるかもしれない
 
22) コミュニティ・コードとフレームワーク
a) Frameworks (eg. Chombo, Cactus, SIERRA, UPIC, etc....)
  -- あなたの専門家のプログラマの役割と責任をを、その領域の専門家、科学者、ユーザのそれから明確に分離する(生産性の層と性能の層)
  -- 専門家のプログラムと領域の加賀宇社との間の社会的契約を定義する
  -- SWエンジニアリングのスタイルと訓練を正しさを保証するために強要し助長せよ
  -- 複雑な領域に特有な性能を上げるための並列抽象化を科学者・ユーザから隠せ(コミュニティ・コードに適用したとき最も有効である)。
  -- 科学者・ユーザに、並列ドライバ(DAGとしてまたは制約ベースのスケジューラとして)から呼び出される名目的に逐次的なプラグインをコードすること許し生産性を向上させよ。
b) 成功するフレームワーク(CSE07)に対する「プラグイン」の性質
  -- main()の制御を放棄せよ。フレームワークがベストと思うときにユーザモジュールを起動せよ。
  -- モジュールはステートレスでなければならない
  -- モジュールは渡されたデータにだけ操作を行う(サイドエフェクトなし)
c) フレームワークは、疎粒度データフローのドライバみたいなものと考えられる。
  -- おおよそ古典的なデータフローと似ている。違うのは、疎粒度のオブジェクトが宣言的な言語で書かれていることである。つまり関数言語でないデータフロー。
  -- データフロー制約の有向グラフをスケジュールする広い柔軟性がある。
  -- Jack Dongarra & Parry HusbandsのDAG-based schedulingの論文参照
 
23) マルチコアの可能性(コア数が非常に大きい場合)
a) OSは
  -- 時間多重でなく、OS専用のコアを用意せよ
  -- OS servicesや割り込みのための"Side-cores"を用意せよ
b) 有効な一方向通信のためのエンジン
c) 真に非同期でバックグランドのI/O
d) 負荷分散の計算とデータ移動
  -- 負荷分散は将来のスケール性を損なう
  -- 現在は、計算のバランスを取ろうとして負荷のアンバランスを引き起こしている。
  -- 専用のコアを使って、計算と並行してバランスを取れ
e) チップ上のバンド幅の活用(データフロー)
  -- SPMD並列性に分解するのではなく、文字通り分解し(feedforward pipelines)チップ上のバンド幅を再利用する。
  -- 良い点:ストリーミングより一般的。チップ上のバンド幅とデータ局所性を活用している。
  -- 悪い点:副作用を厳密にコントロールする必要がある。
  -- データフローと関数プログラミング言語の再発見から多くのものを得るであろう。
f) SoC:おそらく面積を単にコアの数を増やすためだけに使うべきではないであろう。
  -- 統合されたメモリコントローラとか、信頼性を高める
 
24) どこでも並列処理
 CiscoのCRS-1 Terabit Router の例
 
25) 結論
a) 「プロセッサは新しいトランジスタだ」Chris Rowen
b) ものすごい転換が起こっていて、これはコンピュータ業界のすべてのセクターに影響を及ぼす
  -- 電力制限のために
  -- 並列プログラミングモデルが創発する前の過程である
c) プログラミングモデルや実行モデルの曖昧さを考えると、これからアーキテクチャの探索の新しい時代に入る(探索しなければならないのだ)
d) 今始めなければならない
  -- 新しいハードウェアデザインが生まれるまでに3〜5年かかる
  -- 新しいハードウェアをサポートするの必要な新しいソフトウェアのアイデアが生まれるまでに3〜5年かかる
  -- 新しいソフトウェアが一般に受容されるのには5年以上かかる
 
26) 参考資料
a)“The Landscape of Computing Architecture: A View from Berkeley”
  -- http://view.eecs.berkeley.edu
b) Discussion of Impact of Embedded Technology on HPC
  -- http://vis.lbl.gov/~jshalf/SIAM_CSE07
c) RAMP Architectural Simulator
  -- http://ramp.eecs.berkeley.edu/
 
 
5.2 Julien Langou (9:30--) "Scalability and Fault Tolerance of Dense Linear Algebra Kernels for Petascale System"
 続いて、ペタスケール時代に密行列線形代数カーネルのスケーラビリティやフォールト・トレランスをどう高めるか、という講演があった。講演者のLangouはUniversity of Colorado at Denver所属である。
 
1) ペタスケールコンピューターのOSとアルゴリズム─用意はいいか?
a) この講演はアルゴリズムについてだけ話す
b) 我々がよいアルゴリズムを持っているかを知るには、まずペタスケールのコンピュータがどんなものかを考える必要がある。
  -- アルゴリズムのコミュニティは、ハードウェアのコミュニティからの情報を必要とする。
c) ペタスケールコンピュータのためのアルゴリズム─用意はいいか?
  -- 答はノー、今は用意がない。しかしアルゴリズムの連中はよいアルゴリズムを間に合わせると予見できる。
d) われわれはカーネル・デベロッパや、スケジューリングのコミュニティや、コンパイラや言語のコミュニティからの助けを必要とするであろう。
 
2) 密行列線形代数の2006〜2007における進歩の要約
a) 2007年:LAPACKにおいて二つの新しいアルゴズムが利用可能になった。
  -- MRRR (Multiple Relatively Robust Representation) 対称3重対角固有値問題をO(n3)ではなくO(n2)で解く。
  -- TSQR (Aggressive early deflation) Hessenberg Eigenvalue Problemで、5倍から10倍速い(近々ScaLAPACKに登場)
b) 05〜07年:2次元分解に基づく新しいアルゴリズム
  -- UTexas (van de Geijn): SYRK, CHOL (multicore), LU, QR (out‐of‐core)
  -- UTennessee (Dongarra): CHOL (multicore)
  -- HPC2N (Kågström)/IBM (Gustavson): Chol (Distributed)
  -- UCBerkeley (Demmel)/INRIA(Grigori): LU/QR (distributed)
  -- UCDenver (Langou): LU/QR (distributed)
c) 密行列線形代数に対する第3の革命か?
 
3) 新世代のアルゴリズムか?
a) 80年代のLINPACKはベクトル処理向きに設計され、Level-1 BLASに依拠していた。
b) 90年代のLAPACKはブロッキングを用いてキャッシュ向きに設計され、Level-3 BLASに依拠している。
c) 00年代の新アルゴリズムは、マルチコアに親和的で、a DAG/scheduler, block data layout, some extra kernelsに依拠する。
d) このような新しいアルゴリズムは、
  -- 非常に小粒度で、スケーリングが良い(マルチコア、ペタスケールコンピューティング)
  -- タスク間の従属性をかなり取り除いている(マルチコア、分散コンピューティング)
  -- レイテンシを避ける(アウト・オブ・コアの分散コンピューティング)
  -- 高速なカーネルに依拠する
e) このような新しいアルゴリズムは新しいカーネルを必要とし、効率の良いスケジューリング・アルゴリズムに依拠している。
 
4) ペタスケール・マシンはどのようなものか
1. ノード当たりのコア数:10〜100コア
2. ノード当たりの性能:100〜1000 GF
3. ノード数:1000〜10000ノード
4. ノード間の通信のレイテンシ:1μs
5. ノード間のバンド幅:10 Gb/s
6. ノード当たりのメモリ:10 GB
 
a) 第1部:線形代数の第1法則:効率の高いDGEMMを用意せよ。上の2. 5. 6.のモチベーション
b)第2部:LU, QRなどに対する、マルチコアでレイテンシに強いアルゴリズム。上の1. 2. 4.のモチベーション
c) 第3部:フォールト・トレランスのためのアルゴリズム。上の1. 3.のモチベーション
 
5) 線形計算の第1法則:効率の高いDGEMMを用意せよ
a) すべての密行列線形代数操作は効率の高いDGEMM (行列行列積)
b) これはこれまで密行列線形代数において最も易しいO(n3)の演算である
  -- 従って、もしDGEMMを正しく(ピーク性能で)実装できなければ、他の演算がうまくいくはずはない。.
c) ブロッキング通信と非ブロッキング通信との性能モデルの式を提示
.  -- Time with blocking = time comp + time comm
  -- Time with nonblocking = max( time comp , time comm )
  -- 演算はn3で、通信はn2である。
d) 性能モデル:4個のPS3のTNクラスタを考え、通信はGigEで600Mb/s、演算は149.85 GFとせよ。グラフを示す。
  -- ノンブロッキングで90%の性能を得るには、14848以上のサイズの行列を扱わなければならない。
  -- ブロッキングで90%の性能を得るには、146949以上のサイズの行列を扱わなければならない。
  -- でもPS3のメモリは256MBしかない。
  -- つまり、n2の項をn3の項で隠す手段はない。
  -- 密行列線形代数は立ち往生。何もできない。
 
6) 3つの不満と3つの解答
a) 3つの不満の宛先
  -- ネットワークが遅すぎるのだ(GigEに文句)
  -- ノード上のメモリが少なすぎるのだ(Sonyに文句)
  -- ノードが速すぎるのだ(IBMに文句)
b) 3つの解答
  -- メモリを増やす:3.3GBに
  -- ネットワークのバンド幅を増やす:1.39Gb/sに
  -- ノードの計算性能を減らす:SPEを6個から2個に減らす
 
7) この議論からの教訓
a) この議論は、「2. ノード当たりの性能、5. ノード間のバンド幅、6. ノード当たりのメモリ」の三つ組みを選ぶ際、注意が必要であることを示す。
b) ノード当たり1TF(非ブロッキング)のクラスタをピークの99.9%で動かすには、
ノード当たりのピーク性能 ノード間のバンド幅 ノード当たりのメモリ (n, time)
 
1 TF 10 Gb/s 1 GB (n=13,000, t=5 ms)
1 TF 5 Gb/s 4 GB (n=26,000, t=20 ms)
1 TF 2.5 Gb/s 16 GB (n=52.000, t=80 ms)
 
8) ブロック化LUおよびQRアルゴリズム(LAPACK)
a) dgetrfとdgeqrtの説明
b) その並列化の説明
c) 動的スケジューリングによるパネルの分解の隠蔽
d) lookaheadによるパネルの分解の隠蔽(HPLの例)
 
9) strong scalabilit(問題サイズ一定のスケーラビリティ)はどうなるか
a) パネル分解を行列積に隠すことはできない。行列積がパネル分解に隠れるのだ。
b) 新しい世代のアルゴリズムは可能か
  -- 高速パネル分解の可能性
  -- Rだけが必要ならMPI_Allreduceを使え
  -- Q and R: Strong scalability
 
10) 結論
a) skinny matrices(皮だけの行列?)のHouseholder分解の新しい方法について議論してきた。この方法はAllreduce Householderの呼ばれ、4つの長所がある。
 1. アルゴリズム中同期点は1カ所のみ
 2. この方法は、大きな局所演算により演算器の効率を得る
 3. この方法は安定である
 4. 特にRだけが必要な場合はエレガントである。
b) ここでは、AllreduceアルゴリズムをHouseholder QR分解を例に示した。しかしこの方法は何にでも、特にGram-SchmidtやLUに使える。
c) 現在、このアイデアに基づいて2次元ブロック・サイクリックQR分解とLU分解を開発中。
                           
11) フォールトトレランスについて:行列積での実験
a) 目標:FT-PDGEMM (Fault Tolerant Matrix-Matrix Multiply)を書く
b) テスト:ループ中でFT-PDGEMMを実行し、残差チェックにより結果を検証する。その上で、自動的にプロセスをキルする。
 
12) ABFT-BLAS:ABFTテクニックに基づく並列でフォールト・トレラントなBLAS
a) FT-MPIの上に構築
b) ユーザのフォールト・トレラントな環境を提供する
  -- 欠陥の検出
  -- データの自動回復
  -- 他の上に計算ルーチンを積み上げることができる
  -- 目標:フォールト・トレランスの実験ができうるような研究用ライブラリ
  -- 自動的なプロセス・キラーとともに提供する
 
13) Diskless checkpointingの説明
a) チェックサムのためには浮動小数演算でも2進演算でもどちらでも使える
b) Reed-Solomonアルゴリズムにより種々のフェイリャがサポートされている。このアルゴリズムは、p個の同時フェイリャをサポートするために、p個のプロセスを付加するだけでよいからである。
c) Infiniband上のMPI_Reduce(MVAPICHを用いて)の時間のグラフ
 
14) ABFT (Algorithm Based Fault Tolerance)
a) K. Huang, J. Abraham, "Algorithm‐Based Fault Tolerance for Matrix Operations," IEEE Trans. on Comp. (Spec. Issue Reliable & Fault‐Tolerant Comp.), C‐33, 1984, pp. 518‐528.
b) もしチェックポイントが浮動小数演算で実行されたら、オブジェクト上の数学的関係の線形性を用いて、チェックサムを使うことができる。
c) まとめ
  -- 浮動小数演算のチェックサムに依拠する
  -- チェックサムプロセッサを活用できる
  -- どんな線形演算にもアルゴリズムが存在する
   ? AXPY, SCAL, (BLAS1)
   ? GEMV (BLAS2)
   ? GEMM (BLAS3)
   ? LU, QR, Cholesky (LAPACK)
   ? FFT
 
15) ABFTの利点
a) 表面積(n2)/体積(n3)の比に依存しない
  -- FFTのようなn/n演算にとって重要
  -- nの小さな行列行列積にとって重要
b) フェイリャ率に依存しない
  -- パラメータを予測する必要なし
c) アルゴリズムときれいに釣り合う
  -- 例示のために明示的な同期は不必要
 
16) 終わりに
a) かなり効率の良いDGEMMを得ることができそうである。DGEMMは密行列線形代数を高効率化するためのsine qua non(必須条件)である。
b) 第3世代の密行列線形代数アルゴリズムは、1年かそこらのうちに、マルチコア、アウト・オブ・コア、並列分散を取り扱うことができるであろう。主要なソフトウェアは2〜3年のうちに現れるであろう。
c) このフレームワークを構築するさいには、コンパイラ・言語・スケジューリングなどからのサポートを必要とする。いくつかの共同研究は進行中。
d) もしフォールト・トレランスが必要なら、研究は成熟段階に来ている。
 
5.3 Yutaka Ishikawa (10:00--) "System Software, Operating Systema and Middleware Issues"
 
 このセッション最後の講演は石川裕氏(東大・コンピュータ科学/情報基盤センター)であった。氏は、OSやミドルウェアの問題とともに、いわゆるT2K計画についても触れた。
 
1) SCORE
 氏はまず SCORE System Softwareの特徴について述べた。
 
2) RWC SCORE Cluster III
 続いて、2001年当時世界最速のPC clusterであったRWC SCORE Cluster III (Linpack 618.3 GF)を紹介した。
 
3) SCORE Big Users
 現在のSCOREを使った大きなクラスタとしては、理研のSuper Combined Cluster Systemと筑波大計算科学研究センターのPACS-CSがある。
 
4) Information Technology Center, University of Tokyo
 続いて、東大の情報基盤センターにおけるスーパーコンピュータについての歴史を述べ、現在、18.8 TF, 16 TB のHitachi SR11000/J2があるが、2008年に新しいスーパーコンを調達する予定である。これはT2K Opern Supercomputerと呼ばれ、150 TF, 30 TBのクラスタを予定している。
 T2K Allianceとは、東京大学、筑波大学、京都大学の連合であり、この3大学は、それぞれの大学で調達する次のスーパーコンピュータを共通の仕様で入札を行うことに合意した。性能は、筑波大学が80 TF、京都大学が66 TFである。通常のアプリのユーザへのサービス業務に加えて、並列プログラミング環境などの先進的研究プロジェクトで協力を進めることが計画されている。
 
5) Types of Peta Flops Machines
 ペタフロップスコンピュータにはいろいろなタイプがある。
a) ノードの構成
  -- マルチコア
  -- CPU+SIMD
  -- GPUまたはI/Oで結合されたアクセラレータ
b) ノード数
  -- 1 TFノード1K個
  -- 100 GFノード10K 個
c) 全主記憶
  -- 1 PBまたは1/4 PB
d) ネットワーク

 
年度
 
ノード性能GF
 
ネットワークGB/s Byte/Flops
 
SCore III 2001 0.933 0.25 0.268
RIKEN 2004 12.24 0.5 0.041
TSUBAME 2006 76.8 2 0.026
T2K 2008 150 5 0.033





 
 
6) 諸問題
a) 階層的資源管理
b) Jittering
c) Memory affinity
d) Power management
e) Fault tolerance and File System
f) Programming environment
g) Security
 
7) 階層的資源管理
a) 1 TFのノード1K個の場合
  -- ノード数としては現在のクラスタと同程度
b) アプローチ
  -- ローカルなOS
   - Many Coreのスケジュリング(ユーザのアプリもシステム・デーモンも)
  -- グローバルなOS
   - ギャングスケジュリング(jitteringのないシステムプロセスが焦点)
c) ギャングスケジュリング(RWC III (512個のdualcore nodes)の場合
 
8) Jitteringの問題
a) Jitteringとは
  -- 並列アプリの実行が、各ノードでのシステムプロセスによって乱されグローバルな操作を遅くする。
b) 我々のアプローチ
  -- クラスタは普通、計算用のネットワークと、管理用のネットワークと2種のネットワークを持つ。
  -- 管理用のネットワークは大域的クロックを配給するために使う
   - インターバルタイマーを止める
   - グローバル・クロック・ジェネレータから放送パケットを送出し、すべてのシステムプロセスとアプリのプロセスはそれを用いる。
c) 予備実験
  -- 特別な放送パケットが到着すると、tick counterを更新する(カーネルコードを修正する)
  -- バッチスケジューラや情報デーモンは走っていない。システムデーモンだけが走っている。
d) 実験結果
 Global clock がある場合とない場合とで、NAS MG, FT, CGの20回の実行時間を示す。
 
8) NUMAの問題
a) NUMAにおけるメモリ・アフィニティ
  -- CPUとメモリ
  -- ネットワークとメモリ
b) Dualcoreノード2個の場合の実験結果
  -- 通信の性能はデータの所在に依存する
  -- データは(ネットワークだけでなく)CPUも参照する
  -- データの所在は、両CPUとネットワークの所在に基づいて決定すべき。
   - 動的なデータマイグレーション機構が必要では??
9) 消費電力の問題
a) 150 TFのコモディティに基づくクラスタ
  -- 約1.2 MW ($1M/year)
b) 電力節減は重要
  -- 10%減らしただけで小さめの別のクラスがが買える
c) 何ができるか
  -- OSによる細粒度電力コントロール(コア、メモリ、ネットワーク)
   - 例:もしアプリがデータインテンシブなら、コア周波数やボルトは下げるとか
 
10) フォールト・トレランスとファイルシステムの問題
a) チェックポイントアンドリスタートまたはマイグレーション
  -- 1 PBまたは1/4 PBのメモリがディスクに記憶する必要
b) ネットワークのフェイリャ
  -- ネットワークのトランキング(複数のリンクを張る)は、ネットワークの性能のためだけでなく、フォールト・トレランスのためにも重要
c) アプリのファイル利用
  -- 1 PBまたは1/4 PBのデータをスナップショットとしてダンプする
 
11) プログラミング環境の問題
a) 現在のプログラミングスタイル
  -- MPI
  -- OpenMP とMPI
b) SIMDやGPUを持つペタスケールマシンをどうプログラムするか
  -- SIMD or GPU programming
c) ポータビリティの問題
  -- PC クラスタからペタスケールマシンへ
 
12) T2Kのアプローチ
a) 目標
  -- 易しいプログラミングとPCクラスタからペタスケールマシンへのプログラム/性能のポータビリティとが保証される
b) アプローチ
  -- 並列プログラミング言語
   - Open MP+some directives for memory distribution
   - No more MPI
  -- 標準ライブラリとチューニングツール
   - SIMD, GPU用
  -- 学術的なアプリの設計問題
   - 科学アプリのプログラミング例(テンプレート)を収集
 
13) まとめ
a) ペタフロップスマシンへの諸問題
  マシンのタイプとノード数に依存
  -- 階層的資源管理
  -- Jittering
  -- メモリアフィニティ
  -- 電力管理
  -- フォールト・トレランスとファイルシステム
  -- プログラミング環境
b) ペタフロップスマシンにおけるプログラミングのT2Kアプローチ
 
5.4 High Performance Networking (11:00〜12:30)
 最後のセッションはネットワークに関する3つの講演があった。内容は省略。
 
 金曜日の昼でISC'07は終了した。午後は博物館などを巡り、エルベ川沿いでビールを飲んだりした。夜は、Frauenkircheでベルディのレクイエム(死者のためのミサ曲)を聞いた。
 このころ週末はドレスデン空港が改修工事のため閉鎖になり、空港からLufthanzaのバスでライプツィッヒまで走って飛行機に乗った。
 
[完]