電総研研究速報 TR-2001-1

SC2000 参加報告
A report on High performance
networking and computing SC2000

2001年1月12日

1. 巻頭言

2. Contents

1. 巻頭言
2. Contents
3. Conference at a glance
4. Opening & 基調講演
5. 招待講演 (State of the Field Talks)
6. パネル
7. Masterworks
8. テクニカルペーパ
9. Research Gems
10. Birds-of-a-Feather (BOFS)
11. Exhibition
12. 観光

3. Conference at a glance

4. Opening & 基調講演

SC2000のテクニカルプログラムは、Conference ChairのLouis Turcotte氏のOpening Speechで開始されたが、その直前、観衆が集合する際に、我が国のを含む過去から現在に 至る様様なスパコンの写真がフラッシュバックされて、機種名当てクイズが可能であった。

Louis Turcotte (Rose-Human Institute of Technology), SC2000 Chair

さて、Turcotte氏のスピーチの内容は、基本的にはSC2000という会議の総括(SC2000 Conference Snapshot)であるが、過去と比較して特にExhibitとNetworkingが重点化さ れ、またState-of-the-field speechやVenture Villageなどの新しい試みがなされている、 と報告していた。以下に、その要点を幾つかまとめる:

• SC2000の遂行のために、300人以上の人が組織委員会に関わっている(もぎりの方々や Student volunteerなども含まれていると思われる)
• 今年は4つのState-of-the-field speechが催される。(内容はOyanagiレポートに詳しいので、それも参照のこと。)
  • Thomas Sterling (JPL/Caltech): COTS Cluster Systems for High Performance Computing - COTS Cluster, BeowulfなどがどんどんHPCでdominantになって いくという話。
  • Eugene H. Spafford (Purdue): A Small Dose of Infosec - Information Securityの 最新の動向の紹介
  • Margaret H. Wright (Bell Labs, Lucent Technologies): Numbers, Lots of Numbers, and Insight Too - 基本的に数値計算の進歩で、計算によって物理的な 直感にフィードバックがかかるという(あたりまえの)話。
  • J. C. Browne (U. Texas Austin): Parallel/Distributed Programming: Research Success---Application Failure - 並列分散プログラミング、モデル、および言語の 研究の長い歴史があるが、あまり実世界的なインパクトは少なく、相変わらず並 列プログラミングは難しいという、反論もできるが耳の痛い話。
• Masterworksという、どちらかというとIndustryよりの最新の技術紹介などを目的と したさまざまな分野の総合報告の招待講演のセッションを設けた。Genome, Seti@Home, 運送業でのHPC, CFDなどのアプリよりの話から、VIA, Web Proxy Cachingなどのシステムよりの話まで様様である。
• Research Gemsという名称で、Poster+Multimedia presentationをexhibit 会場で行う。
• その他、24のtutorial、7つのパネルが催される。
• 本年度のHPC Games では$10K computer challengeと称し、1万ドル以内で最も性能 の良い計算機を作成する、というものである。Gordon Bell は、Gordon Bell Prizeに 加え、このコンテストにもcash prizeを提供する。
• その他、様様なAwardが授与される。(詳細はOyanagi Report参照)
• SC2000は教育、特に学生やMinority institutionの参加者に対して様様な便宜をはか っている。二年間で、$2.2 millionもの教育関係のプログラムを遂行している。例えば、 Student Volunteerは75名で、全米の27の州、および16カ国から来ている(日本人の student volunteerはいるのであろうか?)。また、ACM IEEE minority institution participation supportも行っている。
• 展示はSCの歴史上最大規模であり、以下のようなデータである:
  • 95 industry exhibitors
  • 60 research exhibitors
  • 732,000 sq. feet exhibit area (約80,000平方m、つまり、8ヘクタールである)
  • venture village
  • 6 sitting lounge
• ネットワーク(SCInet)も最大規模である。例年SCでは展示会場に(とても臨時とは思え ない規模の)SCInetのNOCが立ち上がるのだが、本年はTerabitにかなり近づいてい る:
  • 60 hourse 1.4 miles/hour cable layout
  • 6 Gigabit external linkage (OC48 x 3か?)
  • 335 Gigabit aggregate bandwidth on floor (OC192とか、OC48 x X, OC12 x Xと か?)
  • 200,000 sq. ft (22,000平方m) coverage of 802.11b Wireless LAN (実際、展示会 場のみならず、sessionを含む様様な会合室、Ballroom、廊下、などなど、会場く まなくWirelessでアクセス可能であった。ただし、会場ではときたまDHCPのア ドレスが足りなくなって、アクセス不能になったのはちょっと詰めが甘い。)
  • Demo 10GB Ethernet
  • Network bandwidth challenge - innovative apps
  • Email and proc. (Sun) , videoconferencing
  • Webcast of Keynote talks: 特に、Turcotte氏はここで「これで私の母も息子の晴 れ舞台を見ることができている」といって笑いをとっていた。

SCINet NOC at the SC2000 Exhibition Floor

次に、SC2001の紹介が行われた。SC2001は2001年11月10-16の期間Denver, Colorado にて開催される。委員長のCharles Slocomb氏(Los Alamos National Laboratory)が以下の 点の紹介を行った:

SC2001委員長のCharles Slocomb氏

SC2001 Introduction

• SC2001はDenver, Colorado Nov. 10-16にDenverのConvention Centerで開催され る。今年は天気が悪いようだが、来年は必ず良いであろう。年間は300日晴れの日があ る。
• プログラムとしては、今年のを踏襲し、さらにプラスアルファがある。
• SCINetはさらに規模が拡大

目新しい企画として、SC Globalがある。これはArgonne NLのMultiparty Video Conference SystemであるAccessGridを用いて、世界中に同時開催でSCのイベントを行 うものである。単にDenverの会議場の様子をWebcastするだけはなく、Shared Contents として、相互での発表の共有、パネルやBOFの協調開催、バーチャルな展示、その他のイ ベントなどを企画している。現状で10ものconstellation siteが国内に、また4つの国際 サイトがある。ちなみに、ApGridとしても、(このSC Globalに協力をする予定である。)

次に、ICの発明で2000年のノーベル物理学賞をとったJack Kilby氏が何と登場し、SC2000 の開会を宣言した。無論会場はstanding ovationである。無論Kilby氏はTexasとかかわ りが深いので、登場したのであろう。

Jack Kilby 氏

Kilby氏がノーベル賞にいたるまでの幾つかの功績が紹介された

• 1958 - First IC invention during summer
• Handheld calculator and Thermal printer at Texas Instruments
• Distinguished Prof. At Texas A&M
• Numerous awards
• Alongside Ford, Edison, and Wright Brothers in National Inventors Hall of Fame

Kilby氏自身はもうかなり高齢で、ほんの短いスピーチであったが、一番最初に述べた各ス パコンのflashbackについて、"Brings back a lot of memory, but the progress is not over" とコメントしていて、感慨深かった。我々も引退するときにPC8001とかMacとかSP2 とかRWCクラスタとかPentium4の写真を見て過去に浸るのであろうか。

その次に、Keynote speakerのFormal Introductor(紹介者)としてJoe Thomas氏 (Mississippi State Univ.)が登場した。

Joe Thomas教授, Mississippi State Univ.

Thomas氏は著名なFluid Dynamics Specialistであり、ounding director of NSF engineering research center for computational field simulation @ Mississippi State Univ. であり、さらにClinton's information technology advisory committee (PTAC)のメンバー でもある。氏によると、Mississippi は全米の州の中でCaliforniaとNew Mexicoに続いて 3rd in computational powerなのだそうだ。

さて、Thomas氏に紹介されて、いよいよKeynote SpeakerのSteve Wallach氏が登場し た。Wallach氏はConvexのChief Designerとして有名であり、かつConvexがHPに買 収されてからは、Exemplarのデザインチームを率いた。現在ではCenterPoint Venture Partners に在籍する傍らChiaro NetworksでVPとしてAON (All-Optical Network)の研 究開発をしているそうである。また、Thomas氏と同様、PTACのメンバーでもある。

SC2000 KeynoteのSteve Wallach 氏 (CenterPoint Venture Partners / Chiaro Networks)

さてWallach氏の講演 " Petaflops by 2009" の内容は、基本的にASCI流の COTS クラスタ(ASCIがCOTSというのも多少抵抗感があるが)の構築法により、 半導体と光ネットワークの技術、およびソフトウェア技術が正常進化すれば、 2009年には汎用のPetaFLOPSマシンの構築が可能になる、というものである。 (ちなみに、以下の内容の記述には、Oyanagi SC 2000 report を大幅に参照している。)

• プロセッサ技術としては、Mooreの法則が順調にまず、プロセス技術では、SIA (アメ リカ半導体工業会)の予測があり、1997年の予測と1999年を比較すると、1年分ほど 加速されている。そこで1999年の予測によると2008年には、0.07μプロセスで内部 6Ghz, 外部2.5GhzでCPUは動作するであろう。この場合、チップ内も大幅なクロッ クのレーテンシが生じる(もっとも、東北大の近見先生によると2010年には20Ghzも 可能だそうだが)。
• 問題は消費電力で、P = C * V ^ 2 * fの関係があり、fが数倍になるわけ だが、プロセスの微細化により、二乗で効いてくる電圧を下げることによ り、省電力化が可能になる。また、銅配線やSOIにより、Cの減少で消費電 力が減る。実はCの減少は重要で、遅延はlosslessなら T = √(LC) であり、 lossyなら T = CR であるので、銅配線+SOI によってdelayを減らし、クロッ クを大幅に上昇できる(一般的に30%以上可能である、といわれている。銅 +SOIはIBM Power 4や次期Itanium, Alpha EV7, AMD のx86-64bitのHammer などで導入される予定である。もっとも、その観点からはPentium 4のAl, 0.18μで2Ghzが可能というのもすざまじいが。)　さらに、もう一つの問題 点は、Chip内bandwidthとChip外bandwidthに、ピンネックや周波数の問題 により益々差が生じることである。一方、結合網の技術は、Photonic技術 がMooreの法則を超えてバンド幅を提供している。WDM (wavelength division multiplexing) により、光通信は急速に進歩している。光アンプ も4THzから25THzまで進歩した。も可能になりつつある。光は次世代のスー パーコンピュータの技術である。http://www.ll.mit.edu/aon/ 参 照
• 1997年以降、プロセッサ速度はMooreの法則にほぼ従って伸びているので、1997年 に対して2001年の速度は6倍程度(松岡注: x86系のPC processorではもう少し差が大 きく、10-14倍程度)である、それに対して光伝送速度は10Gbps(OC192)から 40Gbps(OC768)に伸びたが、光のバンド幅はWDMとAONテクノロジにより急激に 拡大する傾向にある。チップ内の光と電気の転送速度の違いは、1996には5倍であっ たが、2001年には20倍も違う。このテクノロジプッシュはもっぱらインターネットを 含む広域バックボーンの需要の高まりとそれに応える技術開発によるものであり、その 速度・規模・技術においてスパコンのスィッチと現状でも差はない；しかも今後はむし ろ光WANテクノロジをスパコンに応用していく方向になるのであろう (LAN,WAN,SANのconvergence)。例えば、Switching nodeは50本のファイバ、40 波長、10Gb/波長だとすると、4方向のswitchは40Tbの入出力のスイッチングを行う 必要がある。
• クラスタにおいてはソフトウェアが大変重要だが、Linuxを中心に現在でも 開発が進んでおり、この傾向は続くだろう。特にLinuxのコード量はOpen Source開発により急激に膨れ上がっており、そのfeature setは増している。 HPCでは Extreme Linux があり、HPC/クラスタ用のLinuxの拡張やツールを提供して一種の標準化 を目指している(このあたりは結構疑わしい；あまりWallach氏はソフト には詳しくないのか?)。これらもOpen Sourceであり、NTではなく、弁護 士と関わる必要もない。
• 実際のプログラミングではFortran, C, C++, Javaを用いて、自動並列化+Explicit Message PassingのHybrid Programming Modelが用いられるであろう。過去から現 在に至るまで自動並列化の研究がいろいろあったが、数千プロセッサにおいて(とどの つまり)近年行われているのは連続系のプログラムというのは、x, y, z, tと反復軸の5レ ベルから成っており、最内のx,y,.z,tについては32-64プロセッサのSMP上の自動並列 化で、反復については明示的並列化でチューニング、ということになっている。それぞ れのレベルの問題のみならず、自動並列化と明示的並列化をいかに効率よく、かつプロ グラミングが容易なようにインターフェースするか、が問題である。
• 将来のアーキテクチャとしては、32-64プロセッサのCOTS(?というにはちょっと高い が)SMPがAONで結ばれるようになるであろう。このとき、地理的に離れていてもバ ンド幅は問題にならない可能性が高い。そのような際にGrid上でのMegacomputing がfeasibleになるかもしれないが、無論latencyの問題などは残る。
• SIAの予測に基づくPetaflops用のMPUの仕様は以下のようになる。
  • 64Gbits of dram (8 Gbits of sram), つまり、64億トランジスタ
  • 520million MPU transistors available (per die?)
  • .07 micron 2.54cm x 2.54cm die size
  • 6Ghz clock On Chip clock, 2.5Ghz off chip
  • 2500 external pins (もっと多い? Power4のMCMはすでに5500pins)
  • 9 million Transistor RISC CORE w/L1 cache, Quad-Issue Superscalar or VLIW FP, 24GFLOPS Peak
  • 1/4-1/2 MByte cache per 100MFlops => 96MB L2 cache (6MB Instruction, 90MB Data)
  • 170Watts, (Per CPU or Die? 多分Dieだろう) .6-.9Volts
• これらは無論チップ内バンド幅を利用するためにMultiprocessor-on-Dieになる。この 場合、以下の二つのデザインが考えられる。
  1. 6-to-8-way SMP
     • 160Gigabyte L2 bandwidth, 512bit/wide (96MB L2)
     • 2.5Ghz bus, 80Gbytes/sec 256 data pins
     • 24GFLOPS Core
  2. 4-way SMP + 4GB On-chip DRAM
     • 160Gigabyte L2 bandwidth, 512bit/wide (96MB L2)
     • 160Gigabyte/s to 4GigaByte Highly-interleaved On-chip RAM, crossbar connected
     • 24GFLOPS Core
  (メモリバランスを考えると後者の方が良い?)
• そこで、4CPU/Die とすると以下の構成により、ASCI PetaFLOPSマシンが可能にな る
  • 120GF/Die
  • Direct fiber interconnect from chip
    • 128 channels per die (DWDM) - 5.12Thz
    • OC768 channels (40Ghz)
    • All optical switching]
    • 2004/5 commercial transmission
  • On-chip, off-chip 2-level memory,
  • 8192 Dies (4 CPU/Die minimum)
    • 1Petaflops (Peak)
  • 消費電力は8192 x 2000W = 1.6MegaWatt
    • ただし、Extra memory (512TB)により3MegaWatt
    • (Los Alamosの建物ならば5MWは大丈夫!)
  • 15TFlops/Rack (128 Die)
    • Rack bandwidth 15TFlops * .1 = 12Thz
    • 10 meters - 50ns delay
  • 30KWatts/Rack - 64 racks
  • Common System I/O (バンド幅は問題なし)
  • Bisection bandwidth 50TBytes/sec
  • 2-4 MT-RJ optical connectors per rack
• これらの進歩は経済誌にすら予測されていることである(Forbes Magazine)

さて、この原稿を仕上げているときに、Intelから2000年12月11日にプロセス技術のロ ードマップの発表があった。図に示す。

これによると、Intelは今までも、今後も二年おきにプロセステクノロジの微細化を着実に 行って行く予定で、2005年のP1264プロセスでは線幅.07μ、ゲート長.03μ商用化する予 定である。これにより、MPUチップ内のトランジスタは4億個で、10Ghzで動作するよう である。

これをWallach氏の講演と比較すると、プロセス技術が大幅に(3年以上)加速されているこ とがわかる。そこで、2005年のOptical技術をInterconnectに使うのであれば、2005年 にすでにPetaflopsは可能になることになる。(危うし地球)。

Caveat:

今回一番良かったのは、会場全体に802.11bのワイアレスLANがくまなく配置してあった ことであった。これは、単にShow floorだけでなく、セッション会場や、meeting roomな ど、数百mに渡る会場全てであり、大変便利であった。

文責：松岡聡(東工大/JST)

5. 招待講演 (State of the Field Talks)

T. Sterling and E.Spafford

Awards and Invited Speaker

・Best Technical Paper Award 
  "Is Data Distribution Necessary in OpenMP?".
  Dimitrios S. Nikolopoulos, Theodore S. Papatheodorou, Constantine
  D. Polychronopoulos, Jesus Labarta, Eduard Ayguade.

・Best Technical Student Paper Award
  "A Comparison of Three Programming Models for Adaptive Applications on the
  Origin 2000".
  Hongzhang Shan, Jaswinder P. Singh, Leonid Oliker, Rupak Biswas.
  MPI model，SHMEM modelとcache-coherent shared address space (CC-SAS) modelの比

・Best Research Gem of the Conference Award
  "Automatic TCP Window Tuning Implemented in an FTP Application".
  Jian Liu, Jim Ferguson.

・HPC Games Awards
- Grand Prize: Air Force Research Laboratory, "The Red Team" - James Hanna et. al.
- Most Innovative Hardware Prize: University of Kentucky, "The Aggregate" - Hank 
  Dietz et. al.
- Most Innovative Software Prize: Air Force Research Laboratory, "The Red Team"
  - James Hanna et. al.
- Most Leading Edge Technology Prize: Black Lab Linux - Kai Staats et. al.
- Honorable Mention: MITRE - David Koester, John Ramsdell.

・SC2000 Network Challenge Award
- Fastest and Fattest Award: "Visaput -- Using High-Speed WANs and Network Data
  Caches to Enable Remote and Distributed Visualization" -- W. Bethel et. al.
- Hottest Infrastructure Award: "A Data Management Infrastructure for Climate
  Modeling Research" - A. Chervenak et. al.
- Most Captivating and Best Tuned Award: "QoS Enabled Audio Teleportation"
  C. Chafe et. al.

・Gordon Bell Prizes
- Peak Performance Category
  "1.34 Tflops Molecular Dynamics Simulation for NaCl with a Special-Purpose
  Computer: MDM" Tetsu Narumi et. al.
  "A 1.349 Tflops Simulation of Black Holes in a Galactic Center on GRAPE-6" 
  Junichiro Makino et. al.
  (両者受賞)

- Price/Performance Category
  "92¢/Mflops/s, Ultra-Large-Scale Neura-Network Training on a PIII Cluster"
  Douglas Aberdeen et. al.

- Honorable Mention, Price/Performance Category
  "High-Cost CFD on a Low-Cost Cluster" Thomas Hauser et. al.

- Special Category
  "High Performance Reactive Fluid Flow Simulation Using Adaptive Mesh
  Refinement on Thousands of Processors" Alan Calder et. al.

・IEEE Computer Society Awards
-Seymour Cray Computer Engineering Award
  Dr. Glen J. Culler
-Sidney Fernbach Memorial Award
  Dr. Steven W. Attaway

cooperative web proxy cachingに関する技術は進んできているが，まだその性能等に関 する理解，解析が少ない．その理由は複数かつ同時に起こるweb proxyのトレースが必要 であることや，多様な組織を越えた情報収集が必要であるといったような性能の測定のた めの実験環境の構築が容易ではないからである．彼らは複数の組織にまたがったトレース を行ない，解析モデルを構築してその性能評価を行なった．トレースは以下の3パターン で行なった．

1. University Trace
University of Washington(UW)で行なった．皮肉にもほとんどのリクエストはクライアン トから直接行なわれ，0.5%のみがproxyからのものであった．

2. Multi-organizational Trace
UWの200のキャンパス内の組織にわたってトレースを行なった．利用者は5万人程度． organizational cooperationを評価するために下記のような実験を行なった． ・各organizationにproxy cacheを置く ・UW client traceを使って各cacheの効率(ヒット率)を評価．これは，協調しないcache を評価することになる． ・協調するcacheをシミュレートする ・idealおよびcacheable cachingを評価(ヒット率を測定) ideal cachingの場合，協調しないcacheのヒット率は43%であるのに対し，協調するcache のヒット率は69%となった．cacheable cachingの場合，協調しないcacheのヒット率は20% であるのに対し，協調するcacheのヒット率は41%となった．このようにUW内では協調する ことによってヒット率が上昇することが分かったが，規模を大きくした場合にも有効であ るかどうかはこの実験結果からは分からない． 規模はクライアント数で決まるので，1つの大きなcacheに対してクライアント数を変化さ せることにより．モデル化を行なった．クライアント数を増やすとヒット率も上昇し，特 に小さな組織ではクライアント数の増加に伴うキャッシュのヒット率の上昇率も大きくな ることが分かった．大きな組織ではクライアント数の増加はキャッシュのヒット率に対し

3. Large-Scale Trace
UWとMicrosoftの間でトレースを行なった．両方あわせたクライアント数は8万程度になる． cooperative web proxy cachingをすることにより，2〜5%程度の性能向上が得られた．

結論としては，

• cooperative web proxy cachingを膨大な数のクライアントに対して不必要にスケーリ ングすることは望ましくない．
• cooperative web proxy cachingの効果が最も得られるのはクライアント数が少ない(2〜 5000程度)場合である．
• document cacheabilityは現在のworkloadでは厳しい限界がある．

文責：田中良夫(電総研)

6. パネル

Is TCP an adequate protocol for high performance computing need?

高速性能通信を行う上でのTCPの現状の問題点については、TCP擁護 派もTCP否定派もほぼ同じ認識のようで、具体的な問題点として、 輻輳制御によるスループットの低下、バッファサイズによる制限、 シーケンス番号の限界等があげられていた。

TCP否定派からは、これらの問題点によりTCPが高性能通信には適当 ではないという結論が出されるとともに、次のような代替案が出さ れた。 TCPは信頼性の低いネットワークのためのプロトコルなので、 現在のように信頼性の向上したLAN環境ではUDPで十分、プライベー トネットワーク上では簡単化したTCPで十分である(Jamshid)。高性 能通信にはTCPのようなベストエフォートではなくQOSを実現するプ ロトコルが必要である、高性能(分散)アプリケーションはネットワー クトラフィックの予測を必要としている、つまりTCPではトラフィッ ク量の予測が難しい(Stuart)。 OSを経由せず、アプリケーション から直接NICを制御する OS-Bypass Protocol が有効である (Wu-chun)。

これに対してTCP擁護派は皆、先に述べたTCPの現状の問題点は congestion window やバッファサイズの細かいチューニングにより 解決可能という意見であった。つまり、現在のTCPは最適ではない が改良により高性能通信にも適するようになるという主張であっ た。

パネル全体を通しての印象であるが、TCP擁護派、TCP否定派ともに 現状のTCPのままでは高性能通信に適さないという認識では一致し ており、新たな方式が必要であるという認識でも一致していた。た だし、その「新たな方式」をTCP改良版と呼ぶか、新しいプロトコ ルと呼ぶかという点で、両者の主張が分かれたようだ。

さて、最初に書いたようにこのパネルはディベート形式である。パ ネルの最後に座長から会場の観客に対して、TCP擁護派とTCP否定派 どちらが優勢だったかを判断する挙手が求められた。結果は、TCP 否定派の圧勝であった。

文責：合田 憲人(東工大)

7. Masterworks

Computational BioSciences: Genomics

Computational Biochemistry and Drug Discovery

8. テクニカルペーパ

Numerical Algorithms

Landing CG on EARTH: A Case Study of Fine-Grained Multithreading on an Evolutionary Path
Kevin B. Theobald, Gagan Agrawal, Rishi Kumar, Gerd Heber, Cornell University, Guang R. Gao, University of Delaware, Paul Stodghill, Keshav Pingali, Cornell University

パイプラインの段数が大きくなると，通信立ち上げや同期のオーバヘッドが問 題となるが，我々はそれらの小さい EARTH に Threaded-C を用いて実装した． EARTH Threaded-C を用い，ダブルバッファリングすることによりパイプライ ン処理を行っている．

最後に EARTH のマルチスレッド処理をいかして，それぞれのブロックを二つ に分け（図５）パイプライン行列ベクトル積をマルチスレッド化した．このと き，それぞれのブロックの行列ベクトル積は二つのファイバで実行される.

共役勾配法には行列ベクトル積の他に内積と DAXPY (ベクトルの実数倍の和) が必要である．計算量的にはこれらの処理は問題とはならないが，リダクショ ンおよびブロードキャストが必要であり，プロセッサ数が多くなったときに問 題となる．これらに対しては EARTH DATA_SYNC 操作を用いた二入力のデータ フロー同期処理を用い，非同期的細粒度リダクション，ブロードキャストを行っ ている．

EARTH モデルは典型的には EU (実行ユニット)と SU (同期ユニット)で構成さ れる．EU はファイバを実行し，SU はファイバが実行可能かどうかの決定（同 期）と通信処理を行う．また，実行可能ファイバの Ready Queue および EARTH 操作のEvent Queue がある．EARTH の実装では，完全に off-the-shelf のシステムからフルカスタムまで四つのステージ, Single, Dual, External SU, Internal SU, がある．Single は 1 プロセッサで EU と SU の処理を行 うもの，Dual は EU と SU の二つのプロセッサを用い，Event Queue と Ready Queue は共有メインメモリを用いるもの．External SU は SU をカスタ ム化したものであり，Internal SU は EU, SU をカスタム化して一つのパッケー ジにしたものである．

評価は EARTH モデルを実装した MANNA 並列計算機を元とし，SEMi と呼ばれ る MANNA のプロセッサ，システムバス，メモリ，ネットワークのサイクルレ ベルのシミュレータで行った．20 ノードまでの Dual あるいは Single のシ ステムは実際に動いている．シミュレータでは 200MHz のプロセッサと 100MB/s のネットワークを用いている．

NPB CG Class A では 120 ノードくらいになるとそれぞれのスピードアップは 23, 44, 63, 79 となり，問題サイズが小さいため External SU あるいは Internal SU のシステムが必要となる．Class B では Dual, Ext. SU, Int. SU はそれぞれ 55, 78, 90 である.

本研究では，局所同期を用いた細粒度マルチスレッド処理を用いたアルゴリズ ムを Threaded-C を用い実装した．EARTH は COTS でも実装でき，またカスタ ム化による拡張もある．細粒度データフロー処理は高速リダクション，ブロー ドキャストを可能とし，また共役勾配法においてこれだけ高い性能を得るため に EARTH は重要な役割を果たしている．

文責：建部修見(電総研)

Visualization

Using High-Speed WANs and Network Data Caches to Enable Remote and Distributed Visualization
Wes Bethel, Brian Tierney, Jason Lee, Dan Gunter, Stephen Lau, Lawrence Berkeley National Laboratory

Visapultというテラスケールの科学データのリモート可視化のためのアプリケー ション及びフレームワークのプロトタイプのデザインと実現について述べ、 WANを用いた性能評価・解析を行っている。Visapultはviewerとback endから 構成されており、IBRAVR(Image Based Rendering Assisted Volume Rendering)を並列分散化した実装となっている。

Visapultのback endではデータをDPSSなどのストレージから読み込み、各back endプロセッサが、視点の情報を用いずにデータのサブセットをレンダリング する。ここで使われるデータは奥行き方向に分割されており、各プロセッサで 並行して読み出され、レンダリングされる。各プロセッサのレンダリング結果 である画像はネットワークを介して、対応したVisapultのviewerのレシーバへ 送られる。

Visapultのviewerでは各back endから送られた画像を結合して表示する。この ときのviewer側での処理量はレンダリングに比べ圧倒的に小さいので、ハード ウェアの支援がなくても十分行える。viewerではback endから送られる画像を インタラクティブに表示するスレッドとネットワークから画像を受け取るスレッ ドが動作しており、表示とI/Oが非同期に行われている。このため、各パイプ ラインが埋まっていれば、ネットワーク及び計算リソースを効率よく扱えてい ることになる。

性能評価では、SC'99行われたWANを利用したデモの時の結果などが示されてい る。評価環境は、Giga ethernetでつながれた会場内の計算ノード(8ノード)・ ストレージ(DPSS)・ディスプレイマシン、WAN上の計算ノード(OC-48(2.4Gbps)、 32ノード)・ストレージ(OC-12(622Mbps)DPSS)から構成されている。ここでは Visapultのback endとストレージ間の通信が非常に多く、back endとviewer間 の通信は少ないと言う結果が得られている。この他Corridorプロジェクトの一 部として行った評価結果からVisapultが有効であると述べているが、テラスケー ルの可視化には現在の高速ネットワークでも不十分であると結論付けている。

High Performance Visualization of Time-Varying Volume Data over a Wide-Area Network Status
Kwan-Liu Ma, David M. Camp, University of California, Davis

時間変化のあるデータの可視化を、高速なネットワークやParallel I/Oなどの 高価なシステムを利用せずにWAN上で実現する手法を示し、その評価を行って いる。提案している手法は、レンダリングのパイプライン化とプロセッサのグ ループ化によって、I/Oのオーバーヘッドを隠蔽し、プロセッサの利用効率を 高める、また、レンダリング結果の画像を圧縮して転送するという順当な方法 である。

レンダリングのパイプライン化では、レンダリングのステージをデータの読み 出し・各プロセッサでのレンダリング・画像の生成・出力に分割する。プロセッ サの割り当て方法では、1パーティションづつ全プロセッサでレンダリングす る、各プロセッサが1パーティションづつレンダリングする方法があるが、こ こではそのハイブリッド版として、プロセッサをいくつかのグループに分け、 各プロセッサグループが同時に1パーティションづつレンダリングする方法を とっている。

性能評価ではWAN上に存在するリモートの計算機としRWCPのPCクラスタおよび NASA AmesのSGI Origin2000を用い、表示はUC DavisのSGI O2上で行われる。 まず、PCクラスタを用いた場合、プロセッサグループの数を8以上に増やすと inter-frameレイテンシ・スタートアップレイテンシが大きくなり、実行時間 の多くを占めるようになる。O2Kでは画像を素のX-Windowで転送する場合と圧 縮(JPEG+LZO)して転送する場合を比較している。画像サイズが1024x1024の場 合、フレームレートが20倍以上、画像の転送・描画時間が30倍以上と、圧縮の 効果が得られている。

パイプライニングでI/Oのコストをある程度隠蔽できているが、データサイズ や表示頻度が高くなると隠蔽しきれない。このため、Parallel I/Oやレンダリ ングの前処理を利用することで高速化できるであろうとしている。しかし、こ の結果送られる画像が大きくなるため、高速なネットワークも必要であるとし ている。また、データはリモートの計算機(またはそのLAN内)に保持されてい るとしているため、データが分散しているような状況には対応できない。

Distributed Rendering for Scalable Displays
Greg Humphreys, Ian Buck, Matthew Eldridge, Pat Hanrahan, Stanford University

WireGLはCAVEなどに代表される高解像度でスケーラブルなディスプレイを対象 としたクラスタレンダリングシステムである。WireGLの大きな特徴は、安価な PC・グラフィックスカードで構成されたクラスタを用い、高価なWorkstation を上回る性能を達成できること、OpenGLとほぼ同じAPIで実現されているため、 プログラミングが容易であること、さらに既存のアプリケーションが変更なく 動作できることである。

WireGLはディスプレイホストでは、OpenGLのドライバとして実装されている。 このため、OpenGLを利用するアプリケーションであれば変更なしで動作するこ とができる。このドライバ内部ではレンダリング処理を、ネットワークを通じ てレンダリングサーバーへ送る。レンダリングサーバーは、グラフィックスカー ド(nVidia GeForce2GTS)と、プロジェクタを持ったPCであり、それぞれ Myrinetで結合されている。

性能評価では、32台のレンダリングサーバー、4台のコントロールサーバー(い ずれもPentiumIII 800MHz)を用い、各ディスプレイの解像度は1024x768である。 ディスプレイの数を1x1〜8x4まで変化させ、1台で実行させた場合に対する性 能を、March、Nurbs、Quakeの3つを用いて測定した。この結果、8x4で単体1ディ スプレイの場合に比べ、Marchでは15%、Nurbsでは25%、Quakeでは55%の性能低 下が見られた。この性能低下は、March、Nurbsの場合、ネットワークが飽和し てしまったためであり、Quakeの場合は、複雑なテクスチャを使い、ポリゴン の数が増大してしまったためである。しかし、通信を最適化しない場合などに 比べると、十分スケールしており、またアプリケーションの変更も不要である ため、かなり有効なシステムであると思われる。

文責：早田恭彦(東工大)

Parallel Programming

A Comparative Study of the NAS MG Benchmark across Parallel Languages and Architectures
Bradford L. Chamberlain, Steven J. Deitz, Lawrence Snyder ; University of Washington

F90＋MPI はデータ配置や通信を明示的に記述する必要があり、コード量が多く記述性も 低いが、性能は良い。対応プラットフォームも多いのでポータビリティもある。

HPF ではグローバルな視点、ディレクティブによるデータ配置、通信は暗黙的でサポート されているプラットフォームが多いという特徴を持つが、階層型配列を４次元配列を用い て表現する必要があり実行時のメモリ使用量が大きくこの性能評価では非常に性能が低 い。

CAF はプラットフォームが Cray のみということを除いて F90＋MPI と特徴が似ている。 性能は良いが記述性・ポータビリティに欠ける。

SAC はグローバルな視点、データ配置は自動、通信は暗黙的でサポートプラットフォーム は Linux/Solaris SMP。記述性が高くコードは少なくてすみ、Sun Enterprise 上での評 価結果では F90+MPI や ZPL に僅かに劣る程度の性能を示している。

ZPL では region という並列配列の宣言や配列に対する操作を指定するためのユーザ定義 index set の概念が基本となる。記述に必要なコード量は少なく、多くのプラットフォー ムがサポートされており、性能評価結果も F90＋MPI とほぼ同程度。

結論として、階層型配列が必要最低限のメモリ消費で実現するよう記述可能なこと、ステ ンシルの最適化をプログラマが明示的に、あるいはコンパイラが自動で行えること、通信 パラダイムがアーキテクチャにマッチしていることが性能面で重要となる。記述性に関し て、明示的な通信・データ配置が良い性能を示すのは確かだがプログラマの負担が大き い。ZPL および SAC はグローバルな視点を提供しつつも優れた性能を示している。

Is Data Distribution Necessary in OpenMP?
Dimitrios S. Nikolopoulos, Theodore S. Papatheodorou ; University of Patras, Constantine D. Polychronopoulos ; University of Illinois at Urbana-Champaign, Jesus Labarta, Eduard Ayguade ; Technical University of Catalonia

まず、16 プロセッサの SGI Origin2000 上において、First-touch なページ配置に最適 化された OpenMP 版 NAS BT, SP, CG, MG, FT を用い、IRIX によるページ配置を First-touch, Round-robin, Random, Worst-case と変えた場合にどの程度性能に影響が 出るかを調べている。この結果、worst-case では BT を除く４つのベンチマークで First-touch に比べて 50〜248% の性能低下が見られた(平均では 90%)。Round-robin お よび Random では BT, SP, CG, MG, FT でそれぞれ 2%, 12%,ｚ 26%, 27%, 45% の性能低 下と、FT 以外はそれほど影響は出ていない。これは Origin2000 のローカル／リモート メモリのアクセスレイテンシが 16ノードの場合におよそ 1:2 程度と低いことと、リモー トメモリへのアクセスによるメッセージトラフィックが比較的うまくバランスされたから であろうとしている。IRIX の動的ページマイグレーションを有効にした場合には、いく つかのケースを除いて First-touch の性能に近づいている。

これらの結果を元に、UPMlib(user-level page migration library)というランタイムシ ステムを開発し OpenMP に組み合わせている。UPMlib では Origin2000 のページ毎の参 照カウンタと、ユーザレベルで利用可能な IRIX のページマイグレーション機能を利用す る。１回目のループ中にメモリ参照のトレースを記録し、ループの終わりでデータの配置 を行う。また、１回目のループ中に各フェーズ間のメモリ参照パターンも記録し、２回目 以降のループではこの情報を元にフェーズの移行時にデータの再配置を行う (record-replay)。

UPMlib を用いた場合の性能を、先に記述した評価方法と同様に測定している。この結 果、CG 以外では First-touch では 6〜22% の性能向上が見られる。Round-robin では First-touch に比べ平均 5%、Random では 6%、worst-case では 14% の性能低下にとど まり、UPMlib を用いない場合に比べかなり性能の改善が見られる。

結論として、最近の ccNUMA はリモート／ローカルのメモリアクセスレイテンシの比が小 さく、バランスのとれたページ配置であれば最適な配置の性能と比べても大きな性能低下 はない。ページ配置が性能に大きい影響を与える場合には、動的ページマイグレーション などのソフトウェア機構で改善することができる。これらのことから、OpenMP にページ 配置用ディレクティブを導入する必要はないとしている。

Extending OpenMP For NUMA Machines
John Bircsak, Peter Craig, RaeLyn Crowell, Zarka Cvetanovic, Jonathan Harris, C. Alexander Nelson, Carl D. Offner ; Compaq Computer Corporation

NUMA 上でデータ配置・再配置を効率良く行える可能性のある方法として、Round-robin によるページ配置、First-touch によるページ配置、自動ページマイグレーションが考え られるが、これらの方法にはそれぞれ以下のような問題がある。

• Round-robin はそもそも実行するプログラムについての情報を一切利用 しないので、データにアクセスするスレッドと同じモジュール上にペー ジが配置されることを期待できない。
• First touch では各ページが最初にどのスレッドに参照されるか、とい う情報しか用いないため、それ以降の参照パターンには一切感知せず、 プログラム終了まで効率的なデータ配置である可能性は少ない。
• 自動ページマイグレーションはページをマイグレーションさせるかどう かを決めるのに統計情報を用いるわけだが、この情報を得られるまで待 たなければならない。

一方、熟練した並列プログラマならスレッドのデータへのアクセスパターンに関する知識 を用いて最適なデータ配置をコンパイラに指定することができるし、こうした知識は最適 なキャッシュ性能を得られるようアプリケーションを調整する場合にも必要とされてき た、と動機付けている。

Compaq のコンパイラで拡張されたデータ配置ディレクティブは主に High Performance Fortran の機能を元にしている。具体的な機能については論文を参照して頂きたいが、大 別するとページマイグレーションに関するディレクティブと、データレイアウトに関する ディレクティブが拡張されている。また、ページ単位でのデータ配置だけでなく、配列の 要素単位での配置もサポートしている。

これらの拡張による性能評価を AlphaServer GS320(Tru64 UNIX Ver.5.1)上で LU を用い て行っている。ページマイグレーションを用いた場合は素の OpenMP とほぼ同等の性能を 示している。素の OpenMP ４ノード時の性能を１とした場合、素の OpenMP 32ノードでは およそ 3.5倍程度の性能であるのに対し、Page Granularity および Element Granularity のデータレイアウトディレクティブを追加したものでは、５倍および６倍の 性能となっており、スケーラビリティの向上は確かに得られているように見える。

文責：岩崎聖(東工大)

MPI

The Implementation of MPI-2 One-Sided Communication for the NEC SX-5
Jesper Larsson Traff, Hubert Ritzdorf, Rolf Hempel, C&C Research Laboratories, NEC Europe Ltd.

Single sided MPI implementations for SUN
S. Booth, E. Mourao, EPCC, The University of Edinburgh

Automatically Tuned Collective Communications
Sathish S. Vadhiyar, Graham E. Fagg , Jack Dongarra, University of Tennessee

文責：野田 裕介(東工大)

QoS/FAULT TOLERANCE

MPICH-GQ: Quality-of-Service for Message Passing Programs
Alain J. Roy, University of Chicago, Ian Foster, Argonne National Laboratory and University of Chicago, William Gropp, Argonne National Laboratory, Nicholas Karonis, Northern Illinois University, Volker Sander, Forschungszentrum Juelich GmbH, Brian Toonen, Argonne National Laboratory

Scalable Fault-Tolerant Distributed Shared Memory
Florin Sultan, Thu Nguyen, Liviu Iftode, Rutgers University

Realizing Fault Resilience in Web-Server Cluster
Chu-Sing Yang, Mon-Yen Luo, National Sun Yat-Sen University

文責：野田 裕介(東工大)

Networking

ここでは上記のテクニカルセッションでの3件の研究発表を紹介す る。

○The Failure of TCP in High-Performance Computational Grids
W. Feng (LANL), P. Tinnakornsrisuphap (Univ. of Wisconsin)

TCP通信では、輻輳制御として、ネットワークにパケットを送出す るためのウインドウ(congestion window)を設け、congestion window の大きさ(window size)を制御することによりネットワーク 上での輻輳を回避する仕組みが採用されている。現在よく用いらて いる TCP Reno では、初めに小さく設定された window size をパ ケット損失が発生するまで大きくし、パケット損失が発生すると window size を再び小さく設定してまた増やしていくという方法を とっている。また TCP Vegas では、window size をデータ転送速 度の期待値と実際の転送速度を用いて決定する手法をとっている。 このような輻輳制御(特に TCP Reno)ではウインドウサイズが大き く変動するため、ネットワークに利用可能な十分なバンド幅がある にも関わらず window size が小さすぎてデータ転送性能が低下し たり、また逆に window size が実際のネットワークのバンド幅よ りも大きくなりすぎてパケット損失が大きくなる、即ち通信性能が 低下する可能性が高い。特にギガビット級の高速ネットワーク上で はこの性能低下も非常に大きなものとなる可能性が高い。

この発表では、この点に注目し、広域ネットワーク上でのTCPによ るデータ転送の性能低下をシミュレーションにより評価している。 具体的には、ネットワークシミュレータ(ns)を用い、Los Alamos National Laboratory と Sandia National Laboratory 間の広域ネッ トワーク(ESnet)上での通信シミュレーションを行っている。結論 としては、特にウインドウサイズの変動が大きい TCP Reno では性 能低下が著しいことを示している。また、広域ネットワーク上には 複数のサイトからの転送データが流れるが、各々の転送元サイトが 同じTCPによる輻輳制御を行っているので、各々の転送元サイトで のウインドウサイズの変動が同期してしまう可能性があり、この場 合には性能低下が顕著になる点も指摘している。

○PSockets: The Case for Application-level Network Striping for Data Intensive Applications using High Speed Wide Area Networks
H. Sivakumar (Univ. of Illinois at Chicago), S. Bailey (Inforbox), R. L. Grossman (Univ. of Illinois at Chicago)

TCPによるデータ転送では、データ転送速度がTCPにおける congestion window の大きさによって制限されるため、高速ネット ワーク上での通信では十分なデータ転送速度を得られないという問 題がある。これを解決するために、システム管理者が window size を調整するというようなシステムレベルのチューニングが行 われるが、このチューニングは非常に難しいだけでなく、当然アプ リケーションユーザが行うことはできない。

これに対してこの発表では、PSoketsと呼ばれるライブラリを用い た手法を紹介している。PSocketsはその名の通り、データ転送を行 うアプリケーション同士が複数のソケットコネクションを確立し、 転送するデータを分割して並列に転送することにより、データ転送 速度を向上させる手法である。発表者は PSocketsを実現するため のライブラリをC++による開発するとともに、Chicago と Ann Arbor間の広域ネットワーク上で評価実験を行い、開発した PSocketsライブラリの有効性を示している。

○Efficient Wire Formats for High Performance Computing
F. E. Bustamante, G. Eisenhauer, K. Schwan, P. Widener (Georgia Institute of Tech.)

分散システム上のマシン間でデータ転送を行うためにMPIやRPC等を 用いることが多いが、これらの方法ではデータ転送速度が比較的速 いが、転送データの形式についての情報が予めデータの送信側と受 信側のマシンに用意されている必要があり、柔軟性に欠けるという 問題がある。一方柔軟性を高めるために、Java RMIのようなシリア ライズされたオブジェクトやXMLを用い方法があるが、この方法で はデータのマーシャリングに要するオーバーヘッドが高く、転送性 能が低くなるという問題がある。

この発表では、上記の柔軟性と高性能転送を両立するための手法で あるNDRについて述べている。NDRでは、データの転送側は相手に関 係なく転送側の形式に従った方法でデータを受信側に送信する。こ の際、送信側は転送するデータに関する情報も同時に転送する。受 信側は、送信側から受け取ったデータを受信側の形式に変換する必 要があるが、この処理は、DCG (Dynamic Code Generation) により 生成することにより、変換オーバーヘッドを低く抑える。発表者は、 NDRを実装したPBIO (Portable Binary I/O)を開発するとともに、 MPI、XML、CORBAとの性能比較を行ってPBIOの有効性を評価してい る。

文責：合田 憲人(東工大)

Networking

The Failure of TCP in High-Performance Computational Grids
W. Feng, Los Alamos National Lab, P. Tinnakornsrisuphap, Univ of Wisconsin

この後、Energy Sciences network (ESnet) で行なわれた実験について述べられ た。この実験では、Los Alamos National Laboratory (LANL) と Sandia National Laboratory (SNL) 間のグリッドを使って行なわれた。この実験では、Renoと Vegasの違い、REDアルゴリズムの有無による性能の違いが調べられた。その結果、 VegasのスループットはRenoの比べて良好であり、Vegasではパケットロスがほと んど起こっていないといったものであった。 最後に、WANのスピードアップによって悪化する現在のTCPの問題が述べられた。 1GbpsでRTTが100msの環境では、輻輳回避アルゴリズムによるウィンドウサイズ の回復に3分以上かかると言う物である。それは、一回だけではなく、繰り返し 行なわれる。

PSockets: The Case for Application-level Network Striping for Data Intensive Applications using High Speed Wide Area Networks
H. Sivakumar, University of Illinois at Chicago, S. Baliey, Infoblox Inc, R. L. Grossman, University of Illinois at Chicago

現在のTCPで標準的に用いられるWindowsサイズ変更のアルゴリズムでは、前発表 であったように問題がある。 そこで、性能を出す必要がある場合にはRFC1323に そった手作業でのチューニング作業が必要になる。その作業は、何週間にもわた ることもあり、管理者の助けも必要とする。それに対し、PSocketではアプリケー ションレイヤーでチューニングを行なう。

PSocketはライブラリとして実装されており、アプリケーションのTCPコネクショ ンをいくつもの独立したコネクションに分け、データを非同期的に送る。そのた め、手作業でウィンドウサイズを調整した時と同じように、TCPコネクションの 始めからパイプをパケットで埋められる。このPSocketのライブラリを使うこと により、アプリケーションはTCPのウィンドウサイズをチューニングすることな く、最大限のスループットを出せる。また、TCPのコネクションの数などは隠蔽 されており、またAPIは標準的なソケットを用いているため、アプリケーション 実装者の負担は少ない。

その後の実験結果により、PSocketを用いることにより、手作業でウィンドウサ イズを調整した場合と同じだけのスループットが出ることが分かる。

Efficient Wire Formats for High Performance Computing
Fabian E. Bustamante, Greg Eisenhauer, Karsten Schwan, Patrick Widener, Georgia Institute of Technology

現在のワイヤーフォーマットとして、まず、MPIなどの伝統的なHPCスタイルやク ライアントサーバモデルの RPC などがある。これらのフォーマットでは、パフォー マンスが良いが、互いに密に関連していないアプリケーションには適さない。一 方、XMLなどのオブジェク指向でメタ的なデータフォーマットがある。これは逆 に柔軟性があるがパフォーマンスが良くない。

そこで、データを送信側のネイティブなフォーマットで送信する NDR を提案す る。現在の NDR は、Portable Bianary I/O (PBIO) として実装されている。デー タの送信側は、名前、型、サイズ、そのフィールドの位置などの情報を提供する。 受信側も同じような情報を提供し、それに従いデータを所得する。

NDR のパフォーマンスを調べるために NDR を MPI、XML、CORBA の通信と比較し た。その結果、これらと比べて、送信側、受信側でのデータのコピーのオーバヘッ ドを無くしているといえる。また、受信側でのデータを解析するオーバーヘッド も減らしている。

文責：白砂 哲(東工大)

Data Grid

Efficient Wire Formats for High Performance Computing
Fabian E. Bustamante, Greg Eisehauer, Karsten Schwan, Patrick Widener, Georgia Institute of Technology

IPG は、NSSA のコミュニティ上に分散する CPU、データストレジ、器具、人材 などのを用いる問題の解決を楽にするためるためのものを提供することを目標と する。その目標としては、以下があげられる。分散アプリケーションのためのプ ログラミング環境をサポートする。独立だが首尾一貫したツールとサービスを提 供する。分散した資源を管理し、まとめるインフラを提供する。共同作業を楽に 行なうための環境を提供する。資源を管理する方法を提供する。NASAないで使わ れている計算とデータ資源を組み入れるためのグリッド環境を提供する。

現在、全米にわたる大規模なIPGのプロトタイプを作成している。2000年の11月 には、600個ののCPUノード、数個のワークステーションクラスタ、30-100テラバ イトのストレジ、少なくとも100Mbpsのネットワーク接続、安定した操作環境を もつグリッドができる予定である。

The MicroGrid: a Scientific Tool for Modeling Computational Grids
H. J. Song, X. Liu, D. Jakobsen, R. Bhagwan, X. Zhang, University of California, San Diego, K. Taura, University of California, San Diego, University of Tokyo, A. Chien, University of California, San Diego

文責：白砂 哲(東工大)

Cluster Infrastructure

PM2: High Performance Communication Middleware for Heterogeneous Network Environments
Toshiyuki Takahashi, Shinji Sumimoto, Atsushi Hori, Hiroshi Harada, Yutaka Ishikawa ; Real World Computing Partnership

PM は元々は Myrinet 用高速通信ライブラリ[1,2]。PM ではコネクション型通信の代わり に、並列アプリケーションが排他的に利用可能なチャネルという仮想ネットワークを用い る。複数の並列アプリケーションを同時に扱えるよう、チャネルのコンテキスト切り替え の機能も持っている。PM は Pentium Pro 200MHz のシステムで 15 μ秒のラウンドト リップ遅延(4byteメッセージ時)と 100MB/sec 以上のバンド幅を実現していた。Gigabit Ethernet 用の実装も行われ、48.3 μ秒のラウンドトリップ遅延(4byte)、56.7MB/sec の バンド幅を実現していた。

PM2 は、PM の機能はそのままに性能を低下させることなくヘテロなネットワーク環境を サポートするよう設計されている。PM2 は、各ネットワーク毎に同一の API を実装した PM2 driver と、下位の PM デバイスへの dispatcher として働く PM/Composite という ドライバとで構成される。PM/Composite はノード番号とそれに対応するネットワークコ ンテキストのルーティングテーブルを保持しており、メッセージ送信の際にはこのルー ティングテーブルを参照して下位の PM ドライバにメッセージを dispatch する。 PM/Composite のコンテキストはネットワークコンフィギュレーションに応じて動的に変 更することもできる。

現在は PM2 デバイスとして PM/Myrinet, PM/Ethernet, PM/Shmem が実装されている。 PM/Myrinet は以前の Myrinet 用 PM を移植。PM/Ethernet は Ethernet ドライバの上に カーネルドライバとして実装、通信保証はカーネル内で行われる。PM と IP プロトコル を同時に扱えるようにするため、Ethernet ドライバの上のレイヤでパケットの振り分け を行う。PM/Shmem はノード内プロセス間通信を実現するためのカーネルドライバで、プ ロセス間でダイレクトなメモリアクセスを可能にする。

基本性能評価では、4byte メッセージ時のラウンドトリップ遅延が Myrinet で 16.3 μ 秒、Gigabit Ethernet で 56.7 μ秒と従来の PM と比較してもそれほど性能低下は見ら れない。PM2 上に実装した MPICH-SCore と、MPICH-GM, MPICH-BIP/SMP(共に Myrinet)、 および LAM, MPICH/p4(Giga/100Mbps Ethernet)を ping-pong, burst および bidirection のバンド幅で比較した結果、Myrinet では一部のメッセージサイズで MPICH-BIP/SMP に劣ったものの、Ethernet では常に LAM, MPICH/p4 以上の性能を得てい る。Shmem の性能では MPICH-BIP/SMP のほうが全体的に良い。

NAS Parallel Benchmark, class A による性能評価(PentiumIII 500MHz, single/dual プ ロセッサ x 16)でも、Ethernet においては常に LAM, MPICH/p4 以上の性能を示してい る。Myrinet 上でも MPICH-BIP/SMP とほぼ同等かそれ以上の性能が得られている。

[1] Hiroshi Tezuka, Atsushi Hori, Yutaka Ishikawa, and Mitsuhisa Sato, "PM: An Operating System Coordinated High Performance Communication Library," In Peter Sloot and Bob Hertzberger, editor, High-Performance Computing and Networking, Vol. 1225 of Lecture Notes in Computer Science, pp. 708-717, Springer-Verlag, April 1997.
[2] Hiroshi Tezuka, Francis O'Carroll, Atsushi Hori, and Yutaka Ishikawa, "Pin-down Cache: A Virtual Memory Management Technique for Zero-copy Communication," In IPPS/SPDP'98, pp. 308-314, IEEE, April 1998.

Performance and Interoperability Issues in Incorporating Cluster Management Systems within a Wide-Area Network-Computing Environment
Sumalatha Adabala, Nirav H. Kapadia, Jose A. B. Fortes ; Purdue University

クラスタ管理システムが提供するコマンドの機能はほぼ等しいものの、その書式やオプ ションなどが異なる。これらのシステム上にジョブをサブミットする場合、ユーザは環境 変数やリソース要求、入出力リダイレクションなどの実行時環境を記述した "サブミッ ションファイル" を用意する必要がある。サブミッションファイルには、ちょっとしたア プリケーションの実行でも大量の情報を記述する必要があり、クラスタ管理システム毎に 書式が異なるため、ユーザがこれらのシステムを相互利用するには敷居が高い。

PUNCH(Purdue University Network Computing Hubs)ではこれらのクラスタ管理システム を統一的に利用する機構を提供している。PUNCH ではユーザは WWW ブラウザを介して、 実行するアプリケーションや作業ディレクトリなど少数の設定をするだけで下位のクラス タ管理システムにジョブをサブミットすることができる。

PUNCH 内ではジョブをサブミットさせるクラスタ管理システムに応じて、サブミッション ファイルの生成やアプリケーションの再コンパイル・再リンクを行う。これらのプロトコ ル変換処理を行うモジュールはおよそ２・３百行のコードからなる。サブミットしたジョ ブの ID はユーザに代わって PUNCH が管理し、ユーザからジョブの状態表示や停止など の要求があった場合に利用する。サブミットしたジョブの終了は、クラスタ管理システム のジョブキューを定期的にポーリングするか、ジョブに関連付けられたログファイルをモ ニタすることで確認している。このような方法を取っているのは、現状のほとんどのクラ スタ管理システムがシグナルベースのジョブ完了通知に必要な機能をサポートしていない ためである。

PUNCH システムを広域計算環境においてスケーラブルなものとするために(クラスタ管理 システム側が)解決すべき問題をいくつか挙げている。

まず先に述べたジョブ完了通知問題の解決策として、指定したジョブの実行が完了するま でブロックするコマンド、もしくはジョブ完了時に指定されたスクリプトを呼び出す機構 が必要としている。

次に実行ファイルのキャッシュ機能の必要性について述べている。PUNCH の経験では、特 定のツールの実行間隔は非常に短く、毎回実行ファイルをクラスタサイトに転送するため にネットワークのトラフィックが浪費される。これを回避するため、クラスタ管理システ ムと PUNCH が共通のキャッシュ管理プロトコルを用いて実行ファイルをクラスタサイト 側にキャッシュさせる方法を挙げている。

この他、セキュリティ面に関してユーザプログラムをシャドウアカウントで実行すること で解決すると同時に、ユーザ管理とアカウント管理を分離、サイト毎の利用ポリシーを ユーザに強制、サイト利用者数の制限などを実現している。

Architectural and Performance Evaluation of GigaNet and Myrinet Interconnects on Clusters of Small-Scale SMP Servers
Jenwei Hsieh, Tau Leng, Victor Mashayekhi, Reza Rooholamini ; Dell Computer Corporation

1) Dell PowerEdge 6350 server, PentiumII Xeon 450MHz(FSB 100MHz, L2:2MB) x 4, 512MB EDO, 64bit 33MHz PCI
2) Dell PowerEdge 2450 server, PentiumIII 733MHz(FSB 133MHz, L2:256KB) x 2, 512MB SDRAM, 32bit 33MHz PCI

"perf", "ring" の評価結果については論文のほうを見て頂きたいが、メッセージサイズ が数 K byte までは MPI/Pro に比べて MPICH-GM のほうがレイテンシが小さくバンド幅 が高い(PowerEdge 2450 server では 4byte メッセージ時に Myrinet:15μ秒, GigaNet:46μ秒)。

NAS Parallel による評価結果では、IS, FT, LU においては MPI/Pro のほうが高い性能 を示しており、特に LU では MPICH-GM にくらべ２倍近い性能を示している。逆に MG で は MPICH-GM のほうがわずかながら MPI/Pro より高い性能を示している。LU は実行時間 のうち 2〜3 割が通信時間であり、また NPB の中でも平均メッセージサイズが一番小さ い。MPICH-GM はポーリングドリブンな実装であり、これが LU での大幅な性能低下を引 き起こしたと見ている。MG もメッセージサイズが小さいが、実行のほとんどは演算部分 であり、小さいメッセージにおいてレイテンシの低い MPICH-GM のほうがわずかに性能が あがったものとしている。BT, SP, CG ではそれほど性能差は見られない。両クラスタの アーキテクチャの相違による性能の違いの詳細は論文を参照して頂きたい。

MPI ライブラリの実装方法はネットワークの性能に、すなわちクラスタの性能に大きな影 響を与え、MPICH-GM では Myrinet の理想バンド幅の 23% も削減させてしまっている。 MPICH-GM はポーリングにより超低レイテンシを実現しているものの、NPB のような中粒 度〜粗粒度の並列プログラムでは性能が出せず、CPU load も高くなってしまう、と結論 付けている。

文責：岩崎聖(東工大)

Scheduling

Randomization, Speculation, and Adaptation in Batch Schedulers
Dejan Perkovic , Peter J Keleher - University of Maryland

Backfillingジョブスケジューリングアルゴリズムは，ユーザの実行 時間の見積もりをもとに，各ジョブに定められたジョブの開始遅延 時間を保証しつつ，ジョブキュー内の小さめのジョブ積極的に割り 当てていくものである．Backfillingはジョブの到着順にスケジュー ルする単純なFCFSより性能[*1]がよいことが知られており，ジョブ キュー内のジョブのソーティング手法により性能が向上する．この 論文では，いくつかのソーティング手法を提案し，それら拡張Backfilling 手法の性能を比較している．

彼らの提案するソーティング手法を以下にあげる．ここで，ジョブ キューのソーティング手法には静的な手法と投機的な手法があり， 前者はジョブの並列性と実行時間の見積もりが一定であるのに対し， 後者はそれらの修正を許すものである．

• 静的手法

  sorting queue by length

  ジョブ長（見積もり）の短いものから処理する．

  randomizing queue

  priority-basedとfully-randomizedがあり，いずれもランダムに割 り当てられたジョブのpriorityをソーティングポリシに反映させる もので，前者はジョブに割り当てられたpriorityが一定で，後者は Backfillingが行われるたびにpriorityが変化するものである．

  removing guarantees

  大抵のジョブはすぐに実行されて遅延時間保証は少数のジョブのみ に適用される，またその保証は不確かなものであるということを前 提とし，shortest-first順の場合には実行時間の長いジョブのpriority を削除し，小さなジョブがより多くbackfillされるようにする．

• 投機的手法

  speculation

  ユーザのジョブ実行時間の見積もりは実際の実行時間よりも短い場 合が多いことを前提とし，通常のbackfillingの後で楽観的にbackfill する．この手法は通常のbackfillingよりアルゴリズムの複雑さが増し， 他のジョブと同期をとるような副作用のある場合には適用できない． 投機的に実行されたジョブの実行時間が予想より長くなった場合は， そのジョブは強制終了され，再びジョブキューに入れられる．

  application adaptation

  計算機の負荷が高い場合は並列ジョブへ割り当てるプロセッサ数を 減らしてBackfillする機会を増やし，低い場合は増やして実行時間 を短くする．この手法が適用できるアプリケーションは，実行時プ ロセッサ数とその場合の実行時間の見積もりが複数定義されている ものに限られる．

Cornell Theory Centerでの1年間の実行トレースとその際のユーザ の見積もり時間を用いて，上記ソーティング手法を組み合わせたス ケジューリングアルゴリズムの性能評価を行い，通常の conservative backfillingより高性能であることを示した．

[*1] ここでの「性能」とは，以下のslowdownで示される
slowdown = [response time]/[execution time]

An Object-Oriented Job Execution Environment
Lance Smith, Rod Fatoohi - San Jose State University, NASA Ames Research Center

流体動力学（CFD）シミュレーション等を行う場合，通常は数百もの ジョブの実行とその入出力データの処理を複雑なシェルスクリプト とPBS等のジョブスケジューラを用いて実行する． しかし，扱うジョブやデータは容易に増大し，このような方法では すぐに破綻してしまうため，インタラクティブなジョブの異機分散 実行環境を構築した． この分散実行環境システムはバッチジョブのサブミットとジョブの 制御の容易さ，コードの再利用性の向上と，多数計算機での分散ジョ ブ処理を目標としている． 既存のオブジェクト指向技術（Java, CORBA, UML, デザインパターン） を用いて実装されており，このシステム上でNQS，Condor，PBS，LoadLeveler， LSF等既存ジョブスケジューラが利用可能である．

このシステムはAdmin，Dispather，Solverの3層からなり，各層を 構成するオブジェクトは，CORBAオブジェクト，workerオブジェクト， utilityオブジェクトに分けられる．

Admin

コンソールやユーザインターフェイスから得たジョブ情報を取得し， Dispatcherオブジェクトに送る．ここで，Console-Admin間はJava オブジェクト，Admin-Dispather間はCORBA Anyオブジェクトとして データを授受する．AdminのWorkerオブジェクトには，GUIとのデー タの授受を担うTranslatorとデータのチェックおよびCORBA Any用 に再パッキングするPackingがある．

Dispatcher

Adminオブジェクトから送られたジョブ群を受け取り，そのスケジュー ルを行う．各ジョブ群はDispatcherのworker objectにより処理され たのち，SolverにCORBA Anyオブジェクトとして送られる．Dispatcher のWorkerオブジェクトには，ジョブの属性を分析してEnvironment オブジェクトを生成するparse，ジョブキューの初期化・維持を行う queue，およびDispatcherとジョブの状況の記録と参照をサポートす るdispatcher statusがある．

Solver

SolverオブジェクトはDispatcherオブジェクトに登録されており， Dispatcherのジョブキューからジョブのサブセットを取り出して， そのジョブの実行環境を用意し，実行する．Solverオブジェクトは Dispatcherから受け取ったジョブの処理中やそのマシンの負荷が高 い間はDispatherへの登録を削除し，負荷が低い場合のみ動的に登録 される．SolverのWorkerオブジェクトには，ジョブの実行環境を用 意するReceiver，あるプラットフォームから別のプラットフォーム へファイルを移動するための詳細を処理するTransport，ジョブの実 行またはサブスケジューラへのジョブの引渡しを行うEngine，ジョ ブの後処理を制御するPost，実行状況の記録と参照をサポートする SolverStatusがある．

現状では，INS2D（NASAの非圧縮Navier-Stokes方程式を解く問題） をNT，IBM AIX，SGI IRIX上で実行しており，今後他のCFDコードの 実行と，異なるPOA（Portable Object Adapter）間でもテストを行 うとのことである．

Towards an Integrated, Web-executable Parallel Programming Tool Environment
Insung Park, Nirav H. Kapadia, Renato J. Figueiredo, Rudolf Eigenmann, Jose A. B. Fortes - Purdue University

一般に並列プログラムの最適化を行う場合，様々な並列処理技術を 適用し，実行・プロファイルしてボトルネックを検出し，改善して いくという一連のプロセスを繰り返す．Parallel Programming Hub （ParHub）[*1]はこれらのプロセスをサポートする並列プログラミ ングツールであり，Webブラウザベースで既存並列プログラミング および性能チューニングツールを統合させたものである．ParHubは NETCARE（NETwork computing for Computer Architecture Research and Education） プロジェクトの一環であり，network computing infrastructure: PUNCH（Purdue University Network Computing Hubs)をその基盤と して用いている．PUNCHはユーザ側からはWebブラウザ経由でソフト ウェアツールへのアクセス・実行を可能とするWeb Portalであり， 計算基盤としてはデータとインターフェイスを管理するネットワー クディスクトップとリソースを管理するSCIONにより構成されるシ ステムとなっている．

現在ParHubがサポートする並列プログラミングツールには以下のも のがある．

• Polaris: OpenMPを用いたsource-to-sourceの自動並列化
• UrsaMinor: マニュアルによるインタラクティブなチューニングをサポート
  e.g. Standard Fortran -[Polaris]-> OpenMPコード -> manual tuning (UrsaMinor)
• MaxP: 実行時にプログラム固有の並列性を評価するPolarisベースのツール
• Trimaran: 命令レベル並列性
• SUIF: 並列化コンパイラ
• COMPEX

ParHubのアクセス効率の比較のため，Java Appletインターフェイス を実装し，上記のUrsaMinorのいくつかのオペレーションの応答時間 をParHubとJava Appletで比較した．評価では，ParHubでは速くて安 定したインタラクティブネットワークコンピューティングが行える のに対し，Appletベースのツールではユーザの計算機の性能や通信 バンド幅によって応答時間が長くなるという結果を示している．た だし，同時にアクセスするユーザ数が増加した場合に現状のParHub で安定したサービス提供が出来るのか疑問である．今後はGridの Portalとして利用できるようにするとのことである．

[*1]The parallel Programming Hub: http://punch.ecn.purdue.edu/ParHub/

文責：竹房あつ子(JSPS/東工大)

Grid Middleware

The AppLeS Parameter Sweep Template: User-Level Middleware for the Grid
Henri Casanova, Graziano Obertelli, Francine Berman - University of California, San Diego, Rich Wolski - University of Tennessee, Knoxville

parameter sweepアプリケーションは依存関係のない多数のタスクを 平行に実行するもので，Computational Grid上で効率よく実行でき ることが知られている．ただし，より効率的に実行するには，I/Oの 制約，タスク間のファイルの共有，出力データの後処理，実行環境 の状況の変化への対応等を考慮したスケジューリングが必要となる． 一方で，複数のGridミドルウェアが提案されている．よって，Grid のハード・ソフトウェア的ヘテロジニティを隠し，かつ，Parameter Sweepアプリケーションに特化してそのスケジューリングをサポート するユーザレベルミドルウェア: APST（AppLeS Parameter Sweep Template） [*1]を提案している．

Parameter Sweepアプリケーションのスケジューリング手法として， Self-schedulingアルゴリズムとGantt chartを用いたHeuristicアル ゴリズムがある．前者は実装が容易でスケジューリングのコストが 低く，性能予測を考慮する必要はないが，リソース選択やデータや タスクのco-allocationが行われないため，膨大な入出力データを扱 うGrid上で実行するParameter Sweepアプリケーションには不十分で ある．後者はそれらをサポートするものの，実装が複雑でスケジュー リングのコストが高く，性能予測を考慮する必要があるため，予測 情報の質が性能に影響することが懸念される．よって，シミュレー ションによる評価[*2]を行い，スケジューリング結果が予測の質に 大きな影響を受けず，Grid環境ではXSufferageと呼ばれるHeuristic アルゴリズムがよい性能を示すことを報告した．

APSTはロバストな実アプリケーションのためのシステムであり，Grid システムの試験利用を可能にするとともにスケジューリングの研究 をサポートすることを目的としている．現状では，INS2D, 3D, MCell, Tphot, NeuralObjectsやシミュレーションアプリケーションに使わ れている．APSTはAPST Client，APST Daemonと既存のGridシステム からなり，APST Client/Daemonは以下のようになっている．

APST Client

コマンドラインのユーザインターフェイスを提供

APST Daemon

Controller, Scheduler, Actuator, Metadata Bookkeeperからなる． Controllerはユーザからジョブの実行要求を受け取ると，Scheduler に通知する．Schedulerでは複数のスケジューリングアルゴリズムが 登録されており，それらを動的に適応させるためのScheduler APIを 提供している．Actuatorは既存Gridシステムのコンポーネントを組 み合わせて利用するためのAPIを提供する．すなわち，バックグラウ ンドのGridシステムとして，NetSolve+IBPや，Globus GRAM+GASSま たはGRAM+NFS等を自由に選択して利用することができる．また， Metadata Bookkeeperではリソースやアプリケーションの静的・動的 な情報を管理する．

評価では，UTKにNetSolve+IBP，UCSDにGRAM+GASS，TITECHにNetSolve+IBP とNetSolve+NFSのリソースを用意し，APST Daemon/ClientをTITECH に設置してタスク数1200のMCellシミュレーションを実行した． MCellは6つのMonte-Carloシミュレーションからなるアプリケーショ ンで，1, 20, 100MBの入力ファイルを要するため，入力ファイルの 格納場所を変化させて，入力ファイルの場所とMCellの実効性能との 相関を示した．評価の結果，入力ファイルがタスクを実行する場所 にあらかじめ格納されている場合はHeuristicアルゴリズムがよい性 能を示したのに対し，それ以外の場合はシミュレーション結果[*2] とは異なり，Self-Schedulingの方がはるかによい性能を示していた． これは，Gridリソースへのアクセスにおけるソフトウェア・ネット ワーク的な遅延が影響していたためで，マルチスレッド化すること により回避できることを示していた．

[*1] APST: http://apples.ucsd.edu/apst/html/
[*2] H. Casanova, A. Legrand, D. Dzagorodnov, F. Berman. Heuristics for Scheduling Parameter Sweep Applications in Grid Environments. In Proc. HCW'00, 2000.

Requirements for and Evaluation of RMI Protocols for Scientific Computing
Madhusudhan Govindaraju, Aleksander Slominski, Venkatesh Choppella, Randall Bramley, Dennis Gannon - Indiana University

分散ソフトウェアコンポーネントアーキテクチャは大規模科学技術 Gridアプリケーション構築の有望なアプローチの1つと考えられて いる．このコンポーネント間の通信は，Java RMI（Remote Method Invocation） やSORP（Simple Object Access Protocol）[*1]等のRMIをベースに して行われる．この発表ではSOAPの性能を示すとともに，マルチプ ロトコルRMI環境下でのSOAPの利用可能性について言及している．

分散環境での通信に対する要求として，信頼性，ロバストネス，シ ンプルなユーザAPI，プログラミング言語サポートやコンポーネントフレーム ワーク間の互換性，既存Gridシステムとの統合，標準化などがあげ られるが，これらすべてをサポートする万能なRMIの設計は難しい． 一方，HTTPはインターネット上でのデータ交換を一般的にサポート するプロトコルとして，XMLはプラットフォーム非依存のデータ表現 の標準として知られており，HTTPとXMLからなるSOAPは，上記の要求 を満たすRMIと考えられる．SOAPはIBMやMicrosoftらにより提案され たオブジェクト指向インターネットベースプロトコルであり，プロ グラミング言語や通信メカニズムに依存しない，HTTP以外のプロト コル（e.g. SMTP, JMS）が利用可能である，request/responseパターン の一方向通信メッセージ交換モデルを採用しているなどの特徴をもつ．

評価では，SOAP RMIのrawパフォーマンス，他のRMIとの性能差，SOAP の性能ボトルネックを調査している．
Java RMI，Nexus RMI（通信手段としてNexusを用いており，Javaと C++との互換性をサポートしている），SOAP RMIでRound Tripスルー プットを比較したところ，SOAP RMIはJava RMIより10倍遅く，メッ セージサイズが小さい場合のみNexus RMIよりもSOAP RMIの方が速い という結果が得られた． ただし，SOAPはデータ表現としてXMLを採用しているため，double型 の数値を送る場合にJava/C/C++では8バイトのデータ量で済むのに 対し，SOAPでは
<double>3.141592653589793E+000</double>
のような記述をしなければならないため，UTF-8では 16 digits(precision) + 17 character = 33バイト以上，Unicode では66バイト以上のデータ量になってしまうという違いがある． また，serialization/deserializationの比較では，SOAPベースの 実装（ApacheSOAPと彼らの実装したnanoSOAP）が他のRMIより100 倍遅い結果が得られた．

SOAPは性能面で他のRMIに劣っている（圧縮するなど，実装により ある程度の性能向上が望めるが）が，性能は通信プロトコルの 選択における1要素であり，通信プロトコルの選択には他の要素も 考慮する必要がある．例えば，JavaRMIは性能は良いが言語の制限 や再帰スタック長に制限によるアプリケーションプログラマへの 負担があり，Nexus RMIは高速データ通信の反面ロバストネスの問 題がある．科学技術計算におけるすべての状況において適切なプロ トコルは存在しないが，マルチプロトコルシステムは，公分母的な プロトコルの提供，ユーザによる動的なプロトコルの変換，プロ トコルの動的な発見，異機種環境でのfailsafeメカニズムの提供 を可能にするなどの利点がある．よって，彼らはデフォルトの プロトコルとして互換性の高いSOAPを採用したマルチプロトコル RMIシステムを設計した．これは，今後Common Component Architecture Toolkit(CCAT)[*2]に統合される予定である．

[*1] SOAP: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[*2] R. Bremley, K. Chiu, S. Diwan, D. Gannon, M. Govindaraju, N. Mukkhi, B. Temko, and M. Yechuri. A Component based Service Architecture for building distributed applications. In Proc. HPDC-9, 2000.

Expressing and Enforcing Distributed Resource Sharing Agreements
Tao Zhao, Vijay Karamcheti - New York University

計算・ネットワーク技術の発展により，様々な管理ドメインのリソー スを利用したアプリケーションの実現が可能となった．それに伴い， リソース管理ではオーナー間でのリソース共有合意をとる必要が出 てきたが，既存リソース管理基盤（GridシステムやMarketNet， Spawn等の経済モデル）はリソース共有のための表現法とその施行 メカニズムを提供するのみである．そこで，チケットと通貨を用い たリソース共有メカニズムの提案をしている．また，リソース共有 合意を施行する割り当て問題を線形プログラミングモデルとして定 式化した．これは，連鎖合意によりリソースの推移的な利用可能性 を計算に入れるものである．

共有合意とはユーザ間でアクセスと量的な制限を明確にすることで， 合意のタイプとして承諾と共有があり，絶対的（e.g. 10MB disk） または相対的（e.g. available CPUの50%）な表現が必要とされる． これらを一意に表現するため，ここではチケットと通貨を用いている． チケットはリソースの共有を表現する抽象的な実体であり，そのタ イプと価格が異なる．また，絶対的な量のリソースを利用する権利 を獲得するための絶対的なチケットと，発行する通貨に応じてその 価格を変える相対的なチケットがある．通貨はチケットに価格を与 えるもので，チケットにより換金され，それにより独自のチケット を発行することができる．すなわち，実体A，B間の合意はBの通貨を サポートするチケットを発行するAの通貨により表現できる． 異なるリソースを価格の異なるチケットで表すことで，リソースヘ テロジニティを抽象化し，通貨で発行されたチケットに基づいて同 意をとることができる．また，通貨の価値をリソース状況等で動的 に変動させることで，実際のチケットの価格に影響させ，絶対的・ 相対的な共有合意を可能にする．

共有合意を施行するには，スケジューラが直接的・推移的な合意を 介して動的に変化するリソースの利用可能性を把握し，リソース割 り当て手法を選択時に包括的な尺度を最適化しなければならない． よって，共有合意の際に分散リソース内のリクエストにリソースを 割り当てる問題を線形方程式としてモデル化した． 1つめのモデルは，1つのリソースタイプと1つの相対的な共有合意を 考慮するベーシックモデルであり，2つめのモデルはベーシックモデ ルを拡張したもので，k種類のリソースタイプ（CPU, Memory, ...） を同時に要求する共有合意を扱うk次線形モデルである．

共有合意と割り当て手法の有効性を示すため，リソース共有合意を 用いて協調するISPレベルウェブプロキシモデルを用いたトレース ベースシミュレータで評価した．このモデルでは各プロキシがそのロー カルユーザに対してウェブコンテンツを提供するもので，ユーザか らのリクエストはプロキシサーバのCPU，ネットワークバンド幅等の リソースを消費する．ユーザに対するサービスを向上させるために， ISPレベルリソース共有合意メカニズムを用いている． 評価では，共有合意を用いることによりプロキシの処理能力を向上 させることなく，各プロキシで高い性能を示した．また，推移的な 合意の施行は利用可能なリソースにリクエストをリダイレクトする コストが無視できるほどの性能向上を示した． 今後の課題として，このメカニズムのGlobusへの実装と，合意構造 を利用した分散アルゴリズムの開発を挙げている．

文責：竹房あつ子(JSPS/東工大)

Compiler Optimization

最初の発表は、

Tiling Imperfectly-nested Loop Nests：Nawaaz Ahmed, Nikolay Mateev and Keshav Pingali - Cornell University

本論文ではループにおけるデータアクセスのローカリティを高めるための手法の ひとつとして知られているタイリング(配列データのアクセスに際して一時期に アクセスする部分を限定・ブロック化し同一データへの再アクセスまでの時間間 隔を短くすることによりキャッシュミスをなくそうとする技術)を Imperfectly-nested loop(外側ループの中にひとつの内側ループがすっぽりと入っ たPerfectly-nested Loopではないループ：Nontightly Nested Loopとも呼ぶ) にも適用できるようにするための一手法を提案している。一般的にタイリングは loop strip-miningとloop interchange(permutation)と呼ばれるリストラクチャ リングで実現されるが、これらはループがperfectly-nestedとなっていないと適 用できない。

これに対し、著者らが先にISC2000で示したImperfectly-nested Loop を Perfectly-nested Loopに変換するためのembeddingと呼ぶ手法の一応用例として、 これをタイリングに適用するための手法を示している。embeddingは従前のloop sinkingやloop distribution(fission)、 loop fusionといったループリストラ クチャ手法を、Imperfectly-nested Loop をPerfectly-nested Loopに変換する という切り口から一般化したものと見ることもできる。本論文の主要な部分は、 必ずしも解がひとつではないembeddingの仕方から、タイリングにより適した結 果となるembeddingを見つけ出す方法を示している点であると受け取った。これ に付随してスキューイングの方法やタイルサイズの決定方法も示している。

性能評価としてSGI Octane(R12000 300MHz, 32KB一次キャッシュ、2MB二次キャッ シュ)上でコレスキー分解やtomcatvなどを実行した結果を示し、提案手法の有効 性を主張している。データからはタイリングによる効果は確認でき、また比較対 象のSGI MIPSProコンパイラよりは優れていることがわかるが、 Imperfectly-nested Loop をPerfectly-nested Loopに変換する他の方式との比 較は示されていない。

発表の際の質疑では、他のリストラクチャリングとの親和性に関しての疑問が投 げかけられたが明確な回答は無かった。また本方式をblock- recursive codeに 応用したものをEuro-Par 2000で発表していると言っていた(多分この論文： "Automatic Generation of Block-Recursive Codes" by Nawaaz Ahmed and Keshav Pingali)がこちらは未調査。

二件目の発表は、

Tiling Optimizations for 3D Scientific Computations: Gabriel Rivera, Chau-Wen Tseng - University of Maryland

本論文は従来の二次元配列のタイリング手法をJacobiなどのstencil codeで三次 元配列をアクセスする場合に拡張する方式を提案しその評価を行っている。特に 著者らがこれまでに開発した手法の拡張に重点が置かれている。本論文はタイリ ングの方法を述べた部分とコンフリクトミスを回避する手法を述べた部分そして 評価結果の3話仕立てとなっている。

まず三次元配列のタイリングに際して著者らは(1)時間ループのスキューなどに よるタイリングは行わず時間ループの内側ループでタイリングを行う、(2)三次 元配列の二次元にのみタイリングを施す、ことを前提としている。(1)の理由は Multigrid codeでは時間ループのタイリングが難しいからとしている。(2)に関 してはstencil codeの場合ひとつの次元方向(タイリングしない次元方向)には- 1,0,+1の距離の要素のみを保持すればローカリティの確保に十分であり、また三 次元分割してしまうとタイルの数が多くなり境界データの再利用ができなくなる からと主張している。次にタイルサイズを決定するのに用いるCost functionと いう概念を導入している。これはキャッシュミスの回数を見積もろうとするもの で、具体的にはタイル内の全てのデータをアクセスした際のアクセスする総キャッ シュライン数で近似している。この際self-interferenceは起こらないものと仮 定している。結局この段ではタイルサイズはキャッシュサイズにフィットしなく てはいけない、またその中でもCost functionの小さいものがよいとのもっとも な結論となっている。

タイル内をアクセスしている際のコンフリクトミスの回避については、従前の方 式と著者らが従来提案した手法の3Dへの拡張した二つの手法について述べられて おり、本論文の主要な部分と受け取れる。著者らの提案方式の一つ目は、これま でに2Dを対象として提案したEucと呼ぶ手法(タイルサイズ決定に際し、 Euclidean remainder algorithmを用いてコンフリクトが起きない次元を適切に 選ぶ)を3Dに拡張したEuc3Dのアルゴリズムが提案されている。本方式は計算量が 低いという特徴があるため配列の操作対象が動的に変化するmultigrids codeに 向いていると主張している。二つ目はこれまで著者らが提案した2Ｄ用の Padding(コンフリクトが起きないようデータのメモリ配置を調整する)の一手法 の拡張である。ふたつのヒューリスティックスを提案しており、一つ目はあらか じめタイルサイズを決めた後にpaddingを行うGcdPadと呼ぶ手法、二つ目はEuc3D と組み合わせてタイルサイズを決めながらpaddingを行うPadと呼ぶ手法である。 前者では計算量は少ないがpaddingのためのオーバーヘッドが大きい、後者はそ の逆という性質も持っている。

性能評価では、Jacobiコード(JACOBI)、Red-block SORコード(READBLACK)、 Multigridコード(RESID)を用いて評価を行っている。L1キャッシュミス率と総合 性能を360MHzのSun UltraSparc2で計測している。L2キャッシュのミス率も見積 もりによって算出して示している。結果をまとめた表はひとつであるが、異なる データサイズに対してのグラフは9ページに渡り圧巻。評価の結果はGcdPadとPad がほぼ同等の性能を示して、Padで17%〜121%の性能向上となっておりタイリング のみ比べて性能が二倍ちかく高い。またpaddingのみではその性能向上は微々た るものであることが見て取れる。paddingによるメモリ使用のオーバーヘッドも 示されておりGcdPadがPadよりオーバーヘッドが倍程度であることがわかる。

質疑では、提案手法がpaddingの際キャッシュのラインサイズを考慮しているの か(回答はNo.)や他の例題への適用につてい話がされた。

三件目の発表は、

Improving Fine-Grained Irregular Shared-Memory Benchmarks by Data Reordering：Y.Charlie Hu, Alan Cox and Willy Zwaenepoel - Rice University

本論文では、Barnes-Hutなどのfine-grained irregular application をDSMシ ステム上で実行する際、簡単なデータリオーダリングによってデータのメモリ配 置を最適化することにより、データアクセス空間的局所性を高めfalse sharing を減少させプログラムの実行性能を飛躍的に向上できることを実証している。

論文ではまずこれらのアプリケーションではtreeやmolecule arrayなどのデータ 構造をとっているため、共有メモリだからといって不用意にデータをメモリに配 置すると、多数のプロセッサが同一のページを共有してしまうような極度な false sharing が発生してしまうことを具体的な例を用いて示している。

これに対しこのようなアプリケーションで用いられるデータ構造二つのカテゴリ に分け、またこのデータ構造に応じて二つのリオーダリング手法を示している。 リオーダリングのためのコードは簡単なライブラリで実現でき、ユーザがデータ 構造に応じて適切なリオーダリングすることも簡単であると主張している。

データ構造のカテゴリの一つ目は、距離の近いオブジェクトをまとめるように treeなどのデータ構造を用いたもので、二つ目は特にそのようなことは考えずに 単純にブロック分割しinteraction listなどを用いるものである。

リオーダリング手法として紹介されている二つの手法では、まず各オブジェクト にキーを与え次にそのキーをソートしランク分けし、その後ランクによってオブ ジェクトをリオーダリングしている。二つの手法はキーの与え方が異なり、一方 はHilbert space-filling curveによるもので、もうひとつは行または列の順と するものである。この二つをアプリケーションのデータ構造の違いによって使い 分けようというわけである。

評価では、対象プログラムとしてSPLASH-2 benchmarkのBarnes-Hut, Fast Multiport Method, Water-Spatialと共有メモリプログラムにポーティングした Chaos benchmarkのMoldyn ,Unstructuredを用いている。これらのプログラムに データリオーダリングを施した結果、16台(MIPS R12000 300MHz)のOrigin2000上 で12%-99%, 16PEのPentium II(300MHz) クラスタ(100M Ethernet)での TreadMarks上で30%-366%, 同HLRC(TreadMarksにhome-based LRCをインプリメン トしたもの)上で14%-269%の性能向上を達成している。Originでの評価ではプロ グラムの実行時間、リオーダリングに必要な時間、L2キャッシュのミスの回数と TLBミスの回数を測定し、クラスタでの評価では実行時間、リオーダリングに必 要な時間、メッセージ数、データ量を測定している。またプログラムごとに詳細 な考察がなされている。ただ、実際にどのようなリオーダリングがなされている かは示されておらずその点は残念。

文責：本多弘樹(電通大)

MPI/OpenMP

近年のHPCプラットフォームにおいて、分散メモリのみあるいは共有メモリの みという、単一メモリ・アーキテクチャでは性能限界が見えており、両者を融 合した形が主流となりつつある。RISCベースのシステムでもベクトル機の世界 でもこれは同じで、SMP結合されたベクトルまたはRISCプロセッサをネットワー ク結合するような形で大型システムが形成されている。本セッションはこうい う背景を踏まえ、共有メモリ・分散メモリの代表的なプログラミング・パラダ イムであるOpenMPとMPIのハイブリッドプログラミングや、同一マシン上での 両者の性能比較等を取り挙げた論文の発表が行なわれた。

Performance of Hybrid Message-Passing and Shared-Memory Parallelism for Discrete Element Modeling
D. S. Henty (University of Edinburgh)

SMPクラスタはHPCプラットフォームの一つの主流になってきている。この ようなシステムでは、分散メモリと共有メモリの両方の特性を活かしたハイブ リッド並列プログラムが最も効率的である。著者らはDEM (Discrete Element Modeling)における分散メモリ、共有メモリ、及びクラスタの効率を評価し、 シングルノードのSMPシステムではMPIよりもOpenMPの方が効率が良くなるが、 彼らの現在のOpenMPの実装にはまだ問題があると述べている。

SMP上のMPIプログラムには、MPI自身の実装の問題、プロセッサ毎にデー タを持つことによるメモリ利用率の低下、アルゴリズム自体の問題等により、 SMPそのものを活かしたプログラムよりも性能が低下する可能性がある。DEMは 一種の粒子計算法であるが、粒子のクラスタが存在するため負荷分散の制御が 難しくなる場合が多い問題である。基本的なアルゴリズムは、各粒子に対し、 カットオフ半径内の粒子リストを作り、それに従って力の計算をし、粒子の位 置をアップデートするというオーソドックスな方法である。

ベンチマークは344 CPUのCray T3E、8 CPUのSUN HPC 3500、そしてノード 当たり4 CPUを持つCompaq ES40 SMPを5ノード結合したクラスタの3種で行なう。 MPIバージョンは一般的なドメイン分割法で、負荷分散を考慮して空間をブロッ ク・サイクリック分割する。性能評価は基本的にスケーラビリティだけで判断 する。まず、MPIだけのプログラムでは、少数プロセッサにおけるキャッシュ の効率の悪さにより、意外に良いスケーラビリティが得られている。ただし、 Compaqでは、ノード内の複数プロセッサを使うより、ノード数を増やした方が ずっと性能が良くなる(これは、ノード内のメモリバンド幅の面から考えると 自然である)。また、ブロック・サイクリック分割による負荷分散もうまくいっ ている。

これに対し、共有メモリによるプログラミングでは、粒子を追跡する形で 自然に並列化を行なっているため、基本的に負荷分散の問題は生じない。 OpenMPによってプログラムの外側ループで並列化を行なう。DEMの粒子間のポ テンシャルから力の計算をする際、いくつかの異なる方法で排他制御をかけて いる。Sun(KAIのコンパイラを使用)では、スレッド数が4以上のところでは性 能が向上しなかった。これはソフトウェアによるアトミック・ロックのためだ と思われる。一方Compaqではハードウェアによるロックがうまく働き、ノード 内の4スレッドまでに対し、良好なスケーラビリティが得られた。OpenMP 2.0 では配列に対するreductionがサポートされるので、この排他制御の方法は重 要な意味を持つ。以上の結果より、Sunでは常にMPIの方が有利であるのに対し、 Compaqでは排他制御のブロックに注意すれば、OpenMPの方が有利であるという 結果になった。

また、MPIとOpenMPのハイブリッドプログラムでは、MPIを用いた負荷分散 を意識した粗粒度並列処理と、SMP上のOpenMPによる細粒度並列の組み合わせ となる。Compaqでこれを行なったところ、ハイブリッドの性能はMPIのみの場 合よりも悪くなる結果となった(性能差は粒子間ポテンシャルのカットオフ半 径に依存するが)。著者らはこの原因は主としてOpenMPにあり、スレッド制御 のオーバヘッドに加え、力の計算においてOpenMPのスケーラビリティがそれほ ど良くないことにあるとしている。

最近、この種のハイブリッドプログラミングの他の例を見ても、意外にMPI のみの方が性能が良い場合が多く目立つ。特にOrigin2000を用いた場合などで は、そもそも分散共有メモリの性能がなかなか上がりにくいため、MPIのみの 方が有利になりがちなのはわかるが、ES40のようなメモリバンド幅にかなり余 裕のあるSMPを用いたクラスタでも厳しいとなると、ハイブリッドプログラム の難しさが改めて認識される。

A Comparison of Three Programming Models for Adaptive Applications on the Origin2000
H. Shan, J. P. Singh (Princeton Univ.), L. Oliker (LBNL), R. Biswas (NASA Ames Research Center)

Origin2000は分散共有メモリをサポートしているため、問題の並列化にお いていくつかのアプローチを選択できる。問題がadaptiveな性質を持つ場合、 動的負荷分散の問題が必ず生じるが、この論文ではそれをいくつかの手法でプ ログラミングし、その容易さと性能の比較を行なっている。ここではメッセー ジパッシング(MPI)、プライベートなアドレス空間と一方向のデータ転送を用 いる方法(SHMEMでput&getを用いる)、キャッシュコヒーレントな共有アドレス 空間を用いる方法(CC-SAS)、という3つの手法を比較する。なお、ここではSGI のオリジナルMPIではなく、性能上の理由でMPICHを用いている。

対象とするアプリケーションはDynamic RemeshingとN-body (Barnes-Hut) で、どちらも動的負荷分散が必要となり、通信も細粒度になりがちである。こ こでは、通信の粒度とデータの局所性に絞って性能を評価する。プログラムは 基本的にMPIとCC-SASについてコーディングする(SHMEMは、MPIと基本的に似て おり、send&receiveの代わりにput&getを用いる一方向制御の通信と考える)。 性能評価としては、各種問題サイズとプロセッサ数による実行時間比較と、実 行時間の内訳を用いた解析を行なう。

まずDynamic Remeshingでは、データサイズが小さい場合は、MPIやSHMEME はCC-SASより性能が良い。しかし、大きな問題ではそれが逆転する。分析によ ると、MPIとSHMEMでは、メッシュの再計算を行なうフェーズで各プロセッサは メッシュの局所部分に対する処理を行ない、最後に比較的粗粒度の通信を行なっ ている。これに対し、CC-SASではプログラムを単純化している代わりに、低レ ベルでの細かい通信を要しており、問題が小さいとこれらのオーバヘッドが浮 き上がってくる。また、CC-SASでは頻繁に同期をとらなければならない点も重 要である。一方、メッシュ再構成の後で負荷分散を決定するフェーズでは、 MPIやSHMEMに比べ、CC-SASははるかに少ない実行時間で済んでいる。結局、プ ログラミングモデルの違いにより、計算コストがかかる部分が全く変わってお り、さらにそれぞれの部分に対する全体の問題サイズの与える影響の差により、 結果として総合時間で優劣の差が生じているのがわかった。

次にN-bodyでは、MPIとSHMEMは基本的なアルゴリズムが同じであるため性能差 はほとんどない。また、問題サイズが小さい領域では、CC-SASが他の2つより も性能が優っている。実行時間内訳を見ると、そもそも処理時間自体が他より も小さくなっている。また、ツリーのデータ構造を作成する際に、MPIとSHMEM では局所的な作業が多くなり、細粒度通信が発生する。問題サイズが大きくな ると、メッセージパッシングの方がずっと有利になり、CC-SASは最も遅くなる。 これは、大きな問題になると力の計算がメインになり、一旦局所的にデータを 溜め込むMPIやSHMEMに比べ、CC-SASではメモリ参照に多くの時間を要するよう になるためである。

この論文は、一般的にメッセージパッシング対共有メモリという二極構図 で捉えがちな並列プログラムパラダイムに、SHMEMを加えている点がユニーク である。しかし、実際にはSHMEMは通信の形が違うだけで基本的にはメッセー ジパッシングであり、多くの場合でMPIとほとんど変わらない結果となってい る。また、プログラミングの容易さに関する議論がやや薄い。

MPI versus MPI+OpenMP on the IBM SP for the NAS Benchmarks
F. Cappello and D. Etiemble (LRI, Universite Paris-Sud)

このセッションの最後の発表は、1件目に似ていて、IBM SP上でMPIのみを 用いた場合とMPI+OpenMPのハイブリッドプログラミングについて、NAS並列ベ ンチマーク(NPB)を題材に性能比較を行なっている(基本的には、2000年3月に つくばで行なわれたWGCC2000ワークショップの発表とほぼ同じであった)。こ こで対象としているIBM SPは2種類で、1つは4つのPower3+をSMP結合した Winter Hawk IIノードを32台用いたもの、もう1つは4つのPower3をSMP結合し たNight Hawk Iノードを8台用いたものである。ネットワークはどちらも同じ である。

NPBバージョン2.3は基本的にMPIで並列化されているため、ハイブリッド版 のコーディングはこれをベースに、実行時間プロファイリングをとって、SMP 並列化が効きそうな部分に対してOpenMPのディレクティブを入れ、最適化して いる(遅くなる部分は並列化しない)。また、MPIはSMPノード内では共有メモリ を用いるという最適化がなされている。さらに、ノード間通信性能を調べたと ころ、4-way SMPの場合では、各プロセッサのノード間通信バンド幅は1-way (ノード内1プロセッサ)の場合の丁度1/4になっており、綺麗に負荷分散されて いる。

まずNPBの各ベンチマークに対し、ノード内で1プロセッサのみを使う場合 (1-way)でノード数に対するスケーラビリティを測定した。CGとLUにおいては、 データセットがclass-Bになるとsuper-linear特性が生じた(これは単体ノード の性質によるところが大きい。つまり、単一ノード性能が悪すぎることによっ てsuper-linearが出るケースがほとんどである)。

次にノード内の全プロセッサを使ってMPIプログラミングを行ない、その速 度向上を見ると、ノード内プロセッサを増やした場合の特性について、ベンチ マーク毎に大きな差があることがわかった。1-wayと4-wayの比率について、ノー ド数を増やした場合の振舞いを見てみると、例えばCG class-Aではノード数の 増加に伴ない実行時間は減少するが(ただしlinearではない)、多くのベンチマー クではそれほど減少せず、MG等では逆に増加する傾向にある。また、FT等は global communicationを要するためIBM SPではうまくスケールしない。

このような前提の下で、MPIのみの性能とハイブリッドの性能を比較する。 指標として、4-way SMPを用いた場合にの、MPIのみとハイブリッドの実行時間 比を用いる(前者を後者で割るので、値が1以下であればMPIのみの方が性能が 良い)。結果として、CGとFT以外ではMPIのみの方が性能が高くなった。CGでは、 ノード数が少ない場合はハイブリッドが不利だが、ノード数の増加に応じて性 能が逆転し、差が開いていく。逆にLU、MG、BTではMPIのみの方がはるかに性 能が良く、しかもノード数が増えるとその差は開いていく。これらの傾向は問 題サイズにはあまり依存しない。

性能解析のために、計算時間と通信時間の内訳を取ってみると、例えばCG class-Aの場合、プロセッサの総計算時間はMPIよりもハイブリッドの方が高く なっているが、ノード数が増えるとその差は縮まり、逆にMPIのみの方の通信 時間が急激に増加するため、上記のような現象が生じることがわかる。これに 対し、LUでは通信時間についてはCGと同傾向だが、そもそも計算時間ではハイ ブリッドの方が圧倒的に大きくなっている。要因は3つ考えられる。第一は OpenMP化が効く並列可能部分の大きさがノード数の増加に伴なって減少するこ と(アムダールの法則)、第二はデータの局所性の問題(データの分割がMPIと OpenMPでは、記述性の差で異なってくる)、第三はOpenMPによるスレッド管理 のオーバヘッドである。この他、メモリアクセスのパターンとネットワーク上 での通信パターンも、それぞれ特性に大きな影響を与える。

この発表でも結論としてMPIのみの方が全般的に性能が良くなるという結果 が示された。直感的にはハイブリッドは理想的に見えるのだが、実際のシステ ムではなかなかそういう例が見つからないという印象が残る。

文責：朴 泰祐(筑波大)

Hardware-Based Tools

本セッションでは、プロセッサまたはシステムの持つハードウェア的な性 能評価用機能を用いて、チューニングや性能解析に役立てるようなツールに関 する論文発表が3件行なわれた。

Using Hardware Performance Monitors to Isolate Memory Bottlenecks
B. R. Buck and J. K. Hollingsworth (University of Maryland)

最初の発表は、単一プロセッサによるプログラム実行において、メモリボ トルネックを発見するためにメモリ参照カウンタを間接的に用いるツールの話 である。最近のプロセッサには一般的にメモリ参照回数を数えるカウンタが備 わっており、例えばプログラムの一部の実行コードを走っている間の総メモリ 参照回数を調べたりすることに用いられる。この話のミソは、「プログラムの 命令コード上の部分」を特定するのではなく、「データ側を追ってどのデータ 構造のアクセスがボトルネックになっているかを突き止める」という点である。

元々、メモリの参照番地とキャッシュミスヒットの関係を正確に洗い出す ためには、データの各番地(あるいはキャッシュライン、少なくともページ単 位)毎の参照履歴とヒット率が出なければ難しい。ここで提案されている手法 は、プログラムの実行ブロックを部分毎に割っていき、さらに各部分の実行ス テップを前半と後半に分け、どちらの方がよりキャッシュミスヒットが大きい かを調べながら、binary searchによって、特にミスが集中する部分を洗い出 すという、かなり気の長い方法である。従って、調査のための実行時間もかな り長い。ただし、調査する部分をキューで管理し、優先度をつけて調査時間を 減らす工夫はしている。

現段階ではシミュレータ上でこの手法の有効性を確認しており、SPEC95を 対象としたシミュレーションが行なわれた。結果として、まず性能解析の質は サンプリングを行なう間隔に依存する(当たり前だが)。また、この測定自体の 副作用として生じるキャッシュミスは非常に小さいことがわかった。ただし、 例外もあり、ijpegベンチマークでは、元々のキャッシュミスがそもそも小さ いため、副作用は無視できる大きさではなかった。また、当然ながら測定自身 のオーバヘッドは非常に大きなものとなる。

また、binary searchではなく、このway数を例えば10-wayぐらいに拡張す ると、アプリケーションによってはかなり精度が上がる(場合によっては、 2-wayでは全く異なる結果が出てしまうこともある)が、多くの場合はそれほど 影響はない。その他、アプリケーションの大きなループを回っている間に、特 性が変化してしまうような場合があり、そういう場合は命令コードの範囲限定 だけでは限界が生じる。シミュレーションのコストに関しては、キャッシュシ ミュレーションを行なっている時間がほとんどで、測定自体の命令に要するサ イクルはかなり小さい。

今後の予定としては、スタックや動的にアロケートされるメモリへの配慮、 実際のハードウェアで動かすこと、得られた結果をアプリケーションの最適化 にどう反映させるか等である。

Hardware Prediction for Data Coherency of Scientific Codes on DSM
J. T. Acquaviva (French Atomic Energy Commission), W. Jalby, (Versailles University)

現在、DSMは実用になりつつあるが、スケーラビリティはまだまだ低く、か つてのようにコヒーレンス制御のためのハードウェアの複雑さよりも、もはや 性能そのものが問題になってきている。この論文では、実際のアプリケーショ ンではコヒーレンシ制御のためのイベントは構造的な場合が多いことに着目し、 そのオーバヘッドを低減するような機構を提案している。

コヒーレンシ制御を正確に行なうとどうしてもオーバヘッドは無視できな くなり、プロセッサ台数の増加と共に深刻な問題になる。一つの解決法は、1 つのデータのコピーを利用して、複数の書き込みが同時に行なわれることを許 し、後で整合性を取ることである。このためには、周期的に生じるコヒーレン シ制御イベントを観測し、これを予測することが有効である。これを実証する ため、PRISMと呼ばれるシミュレータ上でデータへの構造的なアクセスの振舞 いを観測し、一連のアドレスの流れを捕まえる。

実際にアドレス・ストリームを観測するには、ハードウェア機構でストリー ムを識別し、これを抽出する必要がある。プログラムの一定の実行範囲中で、 キャッシュラインに対するアクセスを観測し、サマライズする。彼らの提案す る機構を用いてチューニングを行なうと、例えばSplash-2ベンチマークを対象 にした場合、最大で30%のゲイン、最大で12%のロスが生じた。マイクロベンチ マークの場合はもっとうまくいき、最大で40%まで性能が向上する。

問題点もいろいろある。まず、コヒーレンス・イベントについては、ネッ トワーク上でスタックするものは扱えず、基本的に1フェーズ分のみが対象と なる。検出されるパターンの種類も限られており、さらにストリームが複雑化 するとそれに対応するのが難しくなる。今後の課題としてこれらの問題に対処 することと、コンパイラとの連携をうまくとって、効率的な観測を行なうこと が必要である。

具体的な機構が今一つわかりにくい発表であったが、この種の研究は理論 的には成り立っても、実際のハードウェア化はなかなか難しいだろう。また、 実際問題では時間方向のアクセスの広がりと、空間方向のそれとを組み合わせ ないと、本当のストリームの構造解析はできないのではないだろうか。

A Scalable Cross-Platform Infrastructure for Application Performance Tuning Using Hardware Counters
S. Browne, J. Dongarra, N. Garner, K. London, P. Mucci (University of Tennessee)

本セッション最後の発表は、Tennessee大学のDongarraらが行なっている、 PAPI (Performance API)と呼ばれるパフォーマンスカウンタのためのAPIに関 するものである(2000年3月につくばで開催されたWGCC2000ワークショップでほ ぼ同一内容の発表があった)。基本的には、現在の多くのプロセッサが持って いるパフォーマンスカウンタをユーザから統一的に使い易くするために、API を定めそのインタフェースに従った情報提供を行うライブラリ群とカーネルパッ チを提供するものである。

現在のプロセッサはクロックカウンタに始まり、実行命令数、キャッシュ の結果を含めたメモリアクセス数とその種類、ブランチの種類とその結果といっ た種々のプロセッサ内統計を提供するカウンタが用意されている。これを統一 的にアクセスできるようにすれば、プラットフォームに跨る性能チューニング やシステム比較が容易になる。プログラムにも可搬性が生じ、さらにこれを用 いたセルフチューニングなどの可能性も出てくる。また、最終的にはユーザと ベンダーがこういうインタフェースを共有すれば、こういうものを元にパフォー マンスカウンタの標準化が行なわれるかもしれない。

PAPIは、EventSetと呼ばれるイベント集合を管理する低レベルのインタフェー ス(ハードウェア依存)と、ユーザにれらを使い易く見せるための高レベルのイ ンタフェース、そして性能解析結果をグラフィカルに表示するJavaを用いた GUIからなる。現在、Pentium系及びAthlon (Linux)、Power系(AIX)、 UltraSparc系(Solaris)、MIPS系(IRIX)、さらにCray T3EとSV1&SV2がサポート されており、近々Alpha EV6&EV67もサポート予定である。Linuxについては、 カーネルパッチも提供される。

実際にDongarraのノートPC上でmatrix-multiplyを750MHzのPentium-III上 でリアルタイムに実行させ、これが30Mflop/sの性能を出していることをデモ ンストレーションして見せていた。そして、同じプログラムに対し、ATLASで チューニングをかけると、性能が500Mflop/sまで上がることを示した(ATLASの 宣伝にもなっている)。また、LAPACKを走らせながら、プログラムのflop/s値 が時間区間で変化する様子(matrixが小さくなるため絶対性能が低くなってい く)や、SWIMでサブルーチン毎に色が変化して振舞いがわかり易く示されるこ となどがデモンストレーションされた。

現在、PAPIの並列インタフェースもできていて、例えばSMP構成の場合にス レッド毎のトレースを間違いなく取ることもできる。スレッドがプロセッサ上 でマイグレートされると、プロセッサのカウンタだけを追っていても正しいア プリケーションの振舞いが示されないため、これは重要な機能である。

この発表は、著者名から考えて、最初は学生が発表するのかと思っていた ら、登壇したのはDongarra自身であった。そのためか、発表の最初は空席があっ た会場が、最後の方では満員になっていた。また、1つ前の発表がかなり短か く終わってしまったのだが、Dongarraがその分の時間までしっかり使い、質問 も次々に出てきて、セッションの最後を大いに盛り上げてくれた。

文責：朴 泰祐(筑波大)

Software Tools

A Tool Framework for Static and Dynamic Analysis of Object-Oriented Software with Templates
Kathleen A. Lindlan, Janice Cuny, Allen D. Malony, Sameer Shende, CIS, University of Oregon, Bernd Mohr, ZAM, Forschungszentrum Juelich, Reid Rivenburgh, CRAG, Los Alamos National Laboratory, Craig Rasmussen, ACL, Los Alamos National Laboratory

C++のプログラムやライブラリは、EDG (Edison Design Group) の C++ フロントエンドによってハイレベルの中間言語(IL)が生成され る。IL アナライザーによって、 Program Database (PDB)が作成さ れる。

PDT は DUCTAPE Library によって操作される。DUCTAPE を使った アプリケーションには、単純なユーティリティの他に、静的解析や ドキュメンテーション作成としてプログラムの構造を html 表現に 変換する pdbhtml, ファイルの包含関係、クラス階層、呼出し関係 を表示する pdbtree がある。Source-to-Source 変換のアプリケー ションとして、パフォーマンスプロファイリングを置行なう TAU (Tuning and Analysis Utilities)がある。TAU はオリジナルのソー スファイルを PDT によって解析し、性能評価を行うために命令を 自動的に追加し、プロファイリング可能なソースファイルに変換す るものである。

また、コード生成のアプリケーションとして SILOON (Scripting Interface Language for Object-Oriented Numerics) がある。こ れは、perl や python のようなスクリプト言語から C++等で作成 された数値計算用のライブラリを呼びだすコードを作成する。

From Trace Generation to Visualization: A Performance Framework for Distributed Parallel Systems
C. Eric Wu, Anthony Bolmarcich, Marc Snir , David Wootton, Farid Parpia, IBM T.J. Watson Research Center, David Wootton, Farid Parpia, IBM RS6000 Division, Anthony Chan, Ewing Lusk, William Gropp, Argonne National Laboratory

ASCI Blue Pasific, ASIC White で動く。ユーザとシステムのイベ ントを同時に収集することが重要であり、低オーバヘッドで行う。 トレースファイルは各ノード毎に生成し、ポスト処理によってこれ らの変換、マージを行う。ノード毎に独立にトレースファイルを生 成するために、クロックの同期を取る必要がある。後で、タイムス タンプを調節できるように、間引いて得たスイッチのグローバルク ロックとローカルクロックの両方を保存する。また、保存するデー タは 個々のイベントの記録の他に task ID, node ID, process id, thread id, local thread id, thread type がある。raw レベ ルのトレースファイルに時刻修正等の変換は、powerPC で 12K events/sec 程度のスピードで行える。更に、この変換したファイ ルをマージし、これを使って可視化を行う。

Dynamic Software Testing of MPI Applications with Umpire
Jeffrey S. Vetter, Bronis R de Supinski, Center for Applied Scientific Computing, Lawrence Livermore National Laboratory

プログラミングエラーの収集には、デッドロック検出、ミスマッチ のコレクティブ通信、リソース枯渇も含まれる。デッドロックの検 出は、ブロッキング通信、ノンブロッキング通信、コレクティブ通 信、ワイルドカードの使用に原因を分けて検討している。また、コ レクティブ通信のミスマッチに対しては、順序関係のミスとオペレー ションのミスに分けている。更に、リソース枯渇では、単純なメモ リーリーク、リクエストの紛失、リソースのIDトラッキングエラー る。

sPPM, Sweep3d, NAS BT, NAS FT を IBM SP システム (332Mhz の 604e 4way SMP) で実行したところ、21% から 49% のslow down で あった。

今後の課題が結構あった。

• 全ての MPI call を扱う事
• ユーザインターフェイスの向上
• 分散メモリへの実装
• MPI デバッグ拡張を行えるか？
• MPI の実装の検証に使えるか？

Science Applications Support

Integrating Parallel File I/O and Database Support for High-Performance Scientific Data Management
Jaechun No, Rajeev Thakur, Argonne National Laboratory, Alok Choudhary, Northwestern University

SDM はコレクティブ I/O や非連続要求のようなMPI-IOの様々なI/O 最適化を取り込み、透過的にユーザに見せる。ユーザは高性能の並 列ファイルI/O に対するデータの読み書きが実際の細かい部分に気 にせずに利用できる。

適用例として、

• Level-1 タイムステップ毎に、別々のファイル
• Level-2 データセットでファイルを共通
• Level-3 ほとんどのデータセットを一つのファイルにする。

IBM SP は、level 3 では open するファイルの数が 19 から 3 に 減るので、バンド幅は増加する。SGI では file open のコストが 低いために、level の違いは見られない。

A Framework for Sparse Matrix Code Synthesis from High-level Specifications
Nawaaz Ahmed, Nikolay Mateev, Keshav Pingali, Paul Stodghill Cornell University

アプリケーションによって、疎行列の最適な表現方法が違う。NIST Sparse BLAS ライブラリよりもそれぞれの表現方法で、良い性能を 示している。

A Unified Algorithm for Load-balancing Adaptive Scientific Simulations
Kirk Schloegel, George Karypis, Vipin Kumar, Army HPC Research Center; University of Minnesota

ここでは、新しい統一化再分割アルゴリズムを示す。これはオブジェ クトに対して、他のユーザが記述した他のオブジェクトに対するパ ラメータとトレードオフする。この統一化再分割アルゴリズムは再 分割の正確なオーバヘッドを減らすことができる。 他の手法によ りもプロセッサ間通信とデータの再分散を行う相対的なコストがあ るにもかかわらず、実験結果から、この手法が極めて速く大規模な 問題に対してスケーラブルであることが示された。

文責：板倉憲一(筑波大)

9. Research Gems

Research Gems は Exhibition会場の中央の広場で行われているポスター発表 である。周囲が派手な分、静かで閑散としていた。

Parallel Programming in Java with OpenMP-like Directives
J. Mark Bull, Edinburgh Parallel Computing Centre, Mark E. Kambites, University of York, Jan Obdrzalek, Masaryk University, Brno

JOMPはJava向けのOpenMP bindingである。OpenMPのディレクティブ付きJavaソー スコードを通常のJavaのマルチスレッドプログラムへ変換するJOMPコンパイラ と、ランタイムクラスライブラリから構成されている。JOMPコンパイラ及びク ラスライブラリはJava言語仕様内で実現されているため、全てのJava処理系で 動作する。JOMPはC/C++のOpenMP標準をベースにしているが、threadprivateや atomic、flushなどのディレクティブはサポートされていない。これらはJava 上では意味がないか、PureJavaでは実現不可能なためである。 プログラム変換は、例えば、parallelディレクティブでは、そのparallelブロッ クは(JOMPのタスククラスを継承した)innerクラスへ変換され、元の位置には JOMPのランタイムクラスがinnerクラスのメソッド呼び出しが挿入される。ラ ンタイムクラスライブラリでは、スレッド生成やバリア同期などのメソッドを 提供している。

JavaGrande2000の論文では性能評価がほとんど行われていなかったが、今回の ポスターでは、各ディレクティブの同期オーバーヘッド、アプリケーションと してCFDを用いた性能評価が行われていた。性能環境はSun Enterprise6500(16CPU)上で、VMはSun EVM 1.2.1_04を用いている。

Fortran版(KAI guidef90)と比較した各ディレクティブの同期オーバーヘッド は、Javaの同期機構を用いないparallel、do/for、barrierなどではJOMPの方 が2倍以上速く、逆にJavaの同期機構を用いたもの(single、ordered、 lock/unlock、critical)では倍以上の時間がかかっている。 CFDでは、比較としてFortran・手を記述したもの、mpiJavaを用いたものが出 ていた。JOMP版の性能は手でCFDのマルチスレッド版を記述したものとほぼ同 等、Fortranの約半分、mpiJavaの1.5倍(いずれも16CPU)であった。また、 mpiJavaはCPUが8台を超えると性能がスケールしなくなるが、JOMPとJavaマル チスレッドプログラムはほぼ同等で、16CPUでもスケールしている。

JOMP ホームページ ( http://www.epcc.ed.ac.uk/research/jomp/)

文責：早田恭彦(東工大)

10. Birds-of-a-Feather (BoFs)

Global Grid Forum

また，米国主導のGrid Forumに対し，ヨーロッパ主導のEuropean Grid Forum(EGrid)も昨 年のSC99における内輪のミーティングに続き，今年4月にその第1回の会合が開かれた． EGridもいくつかのワーキンググループを作成し，憲章や白書の作成といった作業を行なっ てきていた．しかし，真にグローバルコンピューティングのフォーラムとなるべく，Grid ForumとEGrid，そしてアジア太平洋地域のグローバルコンピューティングインフラストラ クチャの整備を目指すApGridとが協力しあって(あわさって)一つの大きなフォーラム Global Grid Forum(GGF)を構成することが検討されてきた．GF5ではGGFの組織に関するミー ティングも行なわれ，GGFの方針がほぼ固められた．日本からは早稲田大学の村岡先生が Advisory Committeeに，電総研の関口氏と東工大の松岡先生がSteering Committeeに加わ られている．現在GFでは以下に示すように10のワーキンググループに加え，2つのワーキ ンググループの作成が提案されており，これらはGGFに引き継がれることになる．

・Account Management
・Advanced Programming Model
・Application & Testbeds
・Grid Computing Environment
・Grid Information Services
・Grid Performance
・Remote Data Access
・Scheduling
・Security
・User Services
・(Grid Architecture)
・(Collaborative Environment)

これらのワーキンググループのうち，Scheduling，Grid Performance，Remote Data Access，Advanced Programming Model，Application & Testbedsのワー キンググループがEGridのワーキンググループと合併された．GGFのBOFでは， 各ワーキンググループチェアが今までの活動内容に関して簡単に(数分程度)説 明を行なった．各ワーキンググループのアクティビティに関しては，GGFのホームページを参照されたい．

引き続き，第1回のGlobal Grid Forum(GGF1)は2001年3月4日〜7日の日程でオランダのア ムステルダムで開催されることになっていることと，第2回は7月にワシントンDCで開催さ れる予定であることが発表された． また，最後にIan FosterよりSC Globalに関するアナウンスがあった．SC Globalは来年の Supercomputing(SC2001)に向けての計画である．SCの会場(Denver)，ヨーロッパ(UK, Germanyなど)，オーストラリア，日本，南米(ブラジルなど)をAccess Gridを用いてつな ぎ，例えばSCの会場とヨーロッパとでパネルディスカッションを行なうとか，オーストラ リアでの招待講演をSCの会場に流すといったような企画を検討中である．

文責：田中良夫(電総研)

Cluster Computing

次に、InfiniBandについてのトークがあった。 InfiniBand はlucentが提唱しているアーキテクチャで、 ディスクなどの内部I/O機器からネットワークにまで用いることのできる 通信アーキテクチャらしい。300mほどの距離までも届くとのこと。

VIはすばらしいが高価すぎPCIなのでやはり遅い。ということでPCIを介さない InfiniBandが次の段階としてふさわしい、との主張。

アーキテクチャはこんな感じで、メモリの外側にHCA(HOST CHANNEL Adapter)と よばれるものが付き、そこからInfiniBandのリンクが出る。

                                        taget (I/O)
                                              |
  CPU <-> BUS <-> Mem <--> HCA < iblink -> Switch --> router <-----> Other PC
                    (HOST CHANNEL Adapter)

最後に、どこかのハッカーのような長髪のヒッピー風の人から Making money by clusters HPTi と題して発表があった。 クラスタは一見安いようだが、実はそれは人件費が入っていないからだ、 企業で使おうとすると結構高い、というようなことを言っていた。

BOFは全部で1時間30分ほどで終わってしまい、あまり盛り上がらなかった。

文責：中田秀基(電総研)

TOP500

SCで毎年恒例のTOP500のリスト発表と、様々な統計情報が提示され、フロ アとの間でいろいろな議論が行なわれた。TOP500リストは毎年6月と11月に更 新され、前者はドイツで開かれるヨーロッパ版のSupercomputing Conference で、後者はアメリカのSCの、それぞれ開催直前に発表されている。今回のリス トは第16回目で、11月3日にWWW上で公開された。

まず、今回のトップ3は当然ながらASCIマシンが占めたのだが、トップは LLNLのASCI White (4.94Gflop/s)、2位がSNLのASCI Red (2.38Gflop/s)、そし て3位はLLNLのASCI Blue Pacific SST (2.14Gflop/s)であった。LANLのASCI Blue Mountainは1.61Gflop/sの4位で、これまで上位3位を3つの研究所でshare していた形が崩れた。LLNLは2つのASCIマシンを合わせると、約7G Linpack flop/sを持つことになる。

TOP500の全マシンのLinpack性能総和は88.0Tflop/sで、500位のマシン性能 は55.1Gflop/sであった。また、これまでの8年間でピーク性能、500システム の総性能合計とも順調に推移しており、その延長線上にちゃんと2005年6月の ASCI final (ピーク100Tflop/s、Linpackでは30 Tflop/sぐらい?)や、2002年6 月の地球シミュレータ(ピーク40Tflop/s、Linpackで30Tflop/s以上は出るだろ う)もちゃんと乗っている。ちなみに地球シミュレータは2002年3月完成予定だ が、TOP500に乗るのは6月ということになる。また、その直後にLANLのCompaq ASCI-Qが登場するはずである。

リスト中のマシン数では、もちろんアメリカがトップだが、ヨーロッパ全 体も日本を少し上回っている。ヨーロッパはドイツ、イギリス、フランスがほ とんどを占める。また、全体台数の88%がアメリカ製、残りが日本製である。 ベンダー別に見ると、IBMが圧倒的に多い。実際には、ASCIマシン自身が全体 の中で占める性能割合は非常に小さいが、事実上は同じマシンが多数納入され ているのでその効果は大きい。

国民一人当たりのトップはLuxenburgで、509Kflops/person。もちろん人口 の少ない国にポンと速いマシンが入れば達成できるが、TOP500に入らなければ ならないので結構大変である。カスタマの種類はIndustryが一番多く、これは 市場が健全に延びていることを示している。ただし、Industryの内容(分野)を 特定するのは難しく、またそれは意味がないだろうという議論も出た。

プロセッサのタイプ別では80%以上がスカラーで、ベクトルは20%未満であ る。また、ついに今回でECLベースのマシンは姿を消した。CMOSの特殊マシン も10%程度で、残りはCMOS COTSである。つまり、ここからもASCIタイプが台頭 していることがわかる。また、クラスタもいくつか見えており、本当のCOTSで もTOP500に入れることがわかる。

上位をアメリカが占めているのはもちろんだが、ドイツのライブニッツ計 算センターが日立SR8000で7位に入っている。日本のトップは高エネ研の9位 (SR8000)である。10位ぐらいからは性能は連続している。また、全体性能の歴 史を見ると、1996年の11月と2000年の11月は少しピーキーになっている。 (「選挙のせいか?」という冗談も出た。)

「今後のTOP500はどうなる?」という問いに対しては、商用のデータベース システムが大きな位置を占める、compute farmsのような新しいタイプのシス テムが入ってくる、自家製のクラスタが入ってくる、等の予測もあった。いつ も出る「Linpackでいいのか?」という問いについては、必要に応じて別のリス トができればいいのではないか、という意見があった。結局、当分の間、 TOP500は現状で続けようという結論である。また最後に、クラスタをどう位置 付けるのか、という議論で結構盛り上がった。

文責：朴 泰祐(筑波大)

HPC Asia

11. Exhibition

(1)コラボレーション技術に関する研究

○Cave5D Collaborative Immersive Visualization of Environmental Data (Old Dominton University)

○Molecular Interactive Collaborative Environment (San Diego Supercomputer Center)

この他にも同様の研究として、University of Illinois at Chicago の Collaborative Architectural Layout via immersive Navigation、University of Delaware の Mass Spectrometry: Remote Experimentation and Collaboration 等の紹介も 行われていたが、ここでの説明は省略する。詳細はこれらのWebページを参照 されたい。

また研究展示ではないが、Marconi が、自社のATMスイッチである ASX-4000を使ってHDTV画像を1Gbps以上の帯域を使って転送するデ モンストレーションを行っていた。しかし残念ながら時間の都合で、 報告者は実際の転送画像を見ることはできなかった。

(2)Access Grid

(3)Digital Library, Video on Demand

また、Video on Demand に関する研究紹介も行われており、実際にサービスを 行っている Research Channel Consortium のResearch Channelや、UC Berkeley の The Berkeley Internet Broadcasting System が紹介されていた。

SCINET

今年のSC2000では、コアルータとして、Foundry NetIron800 (8x OC-48, 20 x 1000base-SX, 24 x 100base-FX)、Cisco GSR-12008 (2 x OC-48, 4 x OC-12, 9 x 1000base-SX)、 Juniper M40 (3 x OC-4, 2 x OC-12, 9 x 1000base-SX)の3台のルータが用意され、各 コアルータ間は Pos OC-48 により接続されていた。また、各コア ルータには、 Foundry NetIron800(52 x 1000base-SX, 24 x 100base-FX) 、 Cisco Catalyst6509 x 2台、 Marconi ESR-5000 (2 x OC-12, 2 x 1000base-SX, 10 x 100base-FX)、 Extreme Black Diamond (16 x 1000base-SX, 32 x 100base-FX, 48 x 10/100base-TX)のルータまたはスイッチルータがギガビットイーサ ネットにより接続されていた。さらにATMネットワークも構築され ており、Marconi ASX-4000 (4 x OC-48, 32 x OC-12, 64 x OC-3) が2台用意された。

会場からのインターネット接続としては、vBNS (2 x OC-12)、 HSCC (OC-48)、DARPA (OC-48)、ESnet (OC-48)、Abilene (OC-48)、 その他一般のISPへの接続が確保されている。エキジビジョンに参 加している展示ブースは、それぞれ、これらの外部ネットワークに 対してのルーティングの設定を希望することができる。

またこれらのバックボーンネットワーク以外にも、34個の無線LAN のアクセスポイントが用意されており、会場全室において無線LAN によるネットワーク接続が可能となっていた。

NOCにはバックボーンネットワークを構成する24芯光ファイバケー ブルが 15本集まり、パッチパネルに接続されている。これらの光 ケーブルの総延長は80マイルに達する。また、バックボーンネット ワーク上のトラフィック量の計測は、高バンド幅のネットワークで あるためと思われるが、特殊装置 (PCカード半分くらいの大きさ) を使用して光ファイバを物理的に分岐し、分岐した一方の測定装置 に接続することにより測定を行われていた。測定装置には、 SPIRENT SmartBits (詳細は3節を参照)を使用していた。具体的な トラフィック量は未集計のため知ることができなかったが、これま でのSCにおいてネットワークのバンド幅がパンクしたことはないと いうことである。

またこれは余興とも言えるが、実際の光ファイバの一端にレーザー 光を通して、もう一端から赤いレーザー光が出てくるところを見せ てもらった。NOCのスタッフは使用したMMFファイバなのでレーザー 光はすぐに拡散すると説明していたが、SMだとどれくらい違うのだ ろうか。報告者は、光ファイバは見飽きているが、実際にファイバ を通る光を見たのは初めてであったため、以外と面白かった。

文責：合田 憲人(東工大)
写真：松岡聡(東工大/JST)

１　インダストリ展示

SRC Inc

KAI

API (Alpha Processor Inc)

CRAY Inc

LinuxNetworkX

FASTCLUSTER

IBM

Entropia

２　リサーチ展示

NPACI

Los Alamos National Laboratory

ETL

感想

日本にリサーチ展示の中で目を引いたのは一番はいつものRWCPであったが、 今回は地球シミュレータも会場の関心を引いていた。

今後のために展示ブース設営のための教訓を付け加えておく。

　　　・ブースにはあまり椅子をおかないようにしよう。
　　　　　　椅子をおいたとしても、デモ用であることを忘れないように。
　　　・ブース内で仕事をするのをやめよう。
　　　　　　展示が目的であるから、いくら暇だからといってブース内で
　　　　　　他の仕事をするのは違反。
　　　・客引きすることに努めよう。
　　　　　　会場は研究の発表の場でもあり、交流の場でもあります。
　　　　　　なるべく、この機会にいろいろ人と知り合うことが必要です。
　　　・パネルは簡潔に特徴をつけよう
　　　　　　いろいろな研究をしているのはわかるけど、何が自慢なのか
　　　　　　目玉をつけていくことが重要です。
　　　・客が入りやすいブースにしよう
　　　　　　あまり人が一杯待ちうけていたり、テーブルや椅子でブースが囲ま
　　　　　　れていたりすると非常にブースに入り難くなります。

文責：西克也(ベストシステムズ)
写真：松岡聡(東工大/JST)

12. 観光

The Sixth Floor Musium

写真：松岡聡(東工大/JST)