レンタルサーバ + Webシステム開発 = E-business
|
レンタルサーバ + Webシステム開発 = E-business
|
|
■レンタルサーバご利用参考資料 サーバご利用の参考にJF Project によるJF (Japanese FAQ)を掲載しています。
Linux JF(Japanese FAQ)Project. 一覧に戻る
Beowulf HOWTO
Jacek Radajewski and Douglas Eadline
v1.1.1, 22 November 1998
Hisakuni NOGAMI hisakuni@iterlink.or.jp
1999 年 9 月 20 日
本文書では Beowulf スーパーコンピュータアーキテクチャを紹介し、並列プ
ログラミングの背景知識を提供します。もっと詳細な文書やウェブページへの
リンクもあります。
______________________________________________________________________
目次
1. 前書き
1.1 免責
1.2 著作権
1.3 この HOWTO について
1.4 著者について
1.5 謝辞
2. はじめに
2.1 この HOWTO を誰が読むべきか？
2.2 Beowulf って何？
2.3 分類
3. アーキテクチャ概要
3.1 これは、どんな風に見えますか？
3.2 その他のノードを使えるようにする方法は？
3.3 Beowulf と COW （ワークステーションのクラスタ）はどう違うの？
4. システム設計
4.1 並列計算の背景概要
4.2 並列計算の方式
4.2.1 なぜ一つ以上の CPU か？
4.2.2 並列計算のお店
4.2.2.1 シングルタスクのオペレーティングシステム
4.2.2.2 マルチタスクのオペレーティングシステム
4.2.2.3 複数の CPU を使ったマルチタスクのオペレーティングシステム
4.2.2.4 複数の CPU のマルチタスクのオペレーティングシステム上でのスレッド
4.2.2.5 複数の CPU を持つマルチタスクのオペレーティングシステム上のメッセージ送 信
4.3 並列計算のアーキテクチャ
4.3.1 ハードウェアアーキテクチャ
4.3.2 ソフトウェア API アーキテクチャ
4.3.2.1 メッセージ
4.3.2.2 スレッド
4.3.3 アプリケーションのアーキテクチャ
4.4 適合性 (Suitability)
4.5 並列ソフトウェアを書くことと移植すること
4.5.1 あなたのプログラムでの並行部分を判断する
4.5.2 並列の効率性を見積もる
4.5.3 あなたのプログラムのその並行部分を記述する
4.5.3.1 明示的方法
4.5.3.2 暗黙的方法
5. Beowulf の情報源
5.1 出発点
5.2 文書
5.3 論文
5.4 ソフトウェア
5.5 Beowulf マシンたち
5.6 その他の面白いサイト
5.7 歴史
6. ソースコード
6.1 sum.c
6.2 sigmasqrt.c
6.3 prun.sh
______________________________________________________________________
1. 前書き
1.1. 免責
We will not accept any responsibility for any incorrect information
within this document, nor for any damage it might cause when applied.
（免責の仮訳： 私たちは、本文書中のどんな不正確な情報にも、使った結果
のどんな損害にも、何の責任も負いません。）
1.2. 著作権
Copyright (C) 1997 - 1998 Jacek Radajewski and Douglas Eadline.
Permission to distribute and modify this document is granted under the
GNU General Public Licence.
（著作権の仮訳： Copyright (C) 1997 - 1998 Jacek Radajewski and
Douglas Eadline. 本文書の配布と改変は GNU General Public Licence に
従って許可します。）
1.3. この HOWTO について
Jacek Radajewski が 1997 年 11 月に本文書を書き始め、すぐに Douglas
Eadline が加わりました。 2 、 3 ヵ月を過ぎて、 Beowulf HOWTO は大きな
文書に成長し、 1998 年 8 月に 3 つの文書に分割されました - Beowulf
HOWTO と、 Beowulf Architecture Design HOWTO 、 Beowulf Installation
and Administration HOWTO です。 Version 1.0.0 の Beowulf HOWTO は
Linux Documentation Project に 1998 年 11 月 11 日にリリースされまし
た。私たちはこれが完全な Beowulf Documentation Project となる手始めに
すぎないと思っています。
1.4. 著者について
o Jacek Radajewski は Network Manager として働いています、また、
University of Southern Queensland, Australia の computer science で
honors degree のために勉強しています。 Jacek の最初の Linux との出
会いは 1995 年で、一目ぼれでした。 Jacek は最初の Beowulf クラスタ
を 1997 年 5 月に構築し、それ以来この技術で遊んでおり、新しくて良い
セットアップ方法をいつも試しています。 Jacek には jacek@usq.edu.au
への電子メールで連絡できます。
o Douglas Eadline, Ph.D. は Paralogic, Inc., Bethlehem, PA, USA の社
長兼主任科学者です。物理/分析的化学の訓練を受け、化学機具で使うため
のシングルボードコンピュータを初めて 1978 年に構築して以来、コン
ピュータに関わってきました。 Dr. Eadline が今興味を持つものには、
Linux と、 Beowulf クラスタ、並列アルゴリズムが入っています。Dr.
Eadline には deadline@plogic.com への電子メールで連絡できます。
1.5. 謝辞
Beowulf HOWTO を書くのは長い道のりでしたが、ついに完成しました、多くの
方々に感謝します。以下の方々の助力と本 HOWTO への寄与に感謝したいと思
います。
o Becky には彼女の愛情とサポートと理解に。
o NASA で Beowulf プロジェクトを開始した Tom Sterling 、 Don Becker
他の人々に。
o Thanh Tran-Cong と Faculty of Engineering and Surveying が、実験用
に topcat Beowulf マシンを使えるようにしてくれたことに。
o 私の監督 Christopher Vance の偉大なアイデアに。
o 私の友人 Russell Waldron の偉大なプログラミングのアイデアと、本プロ
ジェクトへの全般的な興味とサポートに。
o 私の友人 David Smith の本文書の査読に。
o Beowulf メーリングリストの、その他大勢の方々の私へのフィードバック
とアイデアに。
o Linux オペレーティングシステム、また、 topcat その他の Beowulf マシ
ンで使われた、その他全てのフリーソフトウェアパッケージに責任を持つ
全ての人々に。
o （訳注：日本語訳については、武井 伸光さん、後藤 正徳さん他のＪＦの
皆さんのご指摘を頂き、感謝しております。）
2. はじめに
日用品のコンピュータとかネットワークハードウェアの性能が向上し、安価に
なるにつれて、非常に高価なスーパーコンピュータの CPU 時間を買うより
も、簡単に入手できる部品で並列計算システムを構築するのがますます実用的
になってきています。実際に、 Beowulf タイプのマシンの価格性能比は、伝
統的なスーパーコンピュータよりも 3 倍から 10 倍良好です。 Beowulf アー
キテクチャはうまく規模拡大可能で、構築が容易ですし、殆どのソフトウェア
は無料なので、ハードウェアを買うだけですみます。
2.1. この HOWTO を誰が読むべきか？
この HOWTO は、少なくとも Linux オペレーティングシステムで何かの経験を
持つ人の為に書かれています。 Beowulf 技術の知識とか、もっと複雑なオペ
レーティングシステムとかネットワーク概念の理解は、不可欠ではありませ
ん。でも、並列計算の何がしかの経験があれば有利です（結局のところ、あな
たは本文書を読むべき理由がきっとあるはずです）。この HOWTO は、
Beowulf についての疑問全部には答えないでしょうが、あなたにアイデアを示
し、あなたが正しい方向に向かえる道標になることでしょう。本 HOWTO の目
的は、背景情報と、更に進んだ文書へのリンクと参考文献を提供することで
す。
2.2. Beowulf って何？
Famed was this Beowulf: far flew the boast of him, son of Scyld, in
the Scandian lands. So becomes it a youth to quit him well with his
father's friends, by fee and gift, that to aid him, aged, in after
days, come warriors willing, should war draw nigh, liegemen loyal: by
lauded deeds shall appearl have honor in every clan.
（訳注：この韻文の和訳は以下のとおりです。これは、「中世イギリス英雄叙
事詞 ベーオウルフ」忍足欣四郎訳岩波文庫からの抜粋ですが、一部漢字は引
用の都合で違ってしまいました。）
シェルドの御子ベーオウルフは、声望あまねく広まり、シェデランドにてその
名は隠れなきものであった。王子たる者、かくのごとく、父君の庇護の下にあ
る時より、すべからく徳を施し、惜しみなく財宝をわかち与うるべきである。
さすれば、やがて年老いたる後、いざ合戦の時いたるや、忠義なる郎党は、王
を助けつかまつるであろう。いかなる民にあっても、人は名誉ある行いをもっ
て栄えるものである。
（訳注：この詞は、古代英詞 ベオウルフの 17 行目から 25 行目までの現代
英語訳であろうと思わますが、「古代英詞 ベオウルフ」鈴木重威編研究社刊
の p68 によれば、この部分の Beowulf は詞の主人公の Beowulf と同名の別
の王だ、としています。しかし、特に本文書のテーマに関係はしません。）
Beowulf は英語で書かれた最古の叙事詩です。この話は、 Grendal と呼ばれ
た怪物を倒した、偉大な強さと勇気を持った英雄の物語です。この英雄
Beowulf を更に知りたければ ``History'' を参照のこと。
多分、 Beowulf の定義の数は、 Beowulf スーパーコンピュータ設備を構築し
たり使った人の数だけあります。 NASA の元祖のマシンと同じ方法で構築され
たものだけが Beowulf と呼べる、と主張する人もいます。その他にも、もう
一方の極端に走って、ワークステーションのシステムで並列コードを走らせて
いるもの全てを Beowulf と呼ぶ人もいます。私の Beowulf の定義はこの二つ
の中間のどこかにありまして、 Beowulf メーリングリストへの多数の投稿に
基づくものです。
Beowulf は並列計算に使える複数コンピュータのアーキテクチャです。
Beowulf は普通、一つ以上のクライアントノードと、一つのサーバノードがあ
り、それらをイーサネットなどのネットワークで一緒に接続して構成したシス
テムです。 Beowulf を構築するのに使う部品は、 Linux が走る任意の PC と
か、標準イーサネットアダプタとスイッチなどの、ありふれたハードウェア部
品です。 Beowulf は、特注ハードウェアを全く使わないで簡単に再現できま
す。また、Beowulf で使うソフトウェアは、 Linux オペレーティングシステ
ムや PVM(Parallel Virtual Machine) 、 MPI(Message Passing Interface)
などの、ありふれたソフトウェアです。このサーバノードは、クラスタ全体の
制御とクライアントへのファイル提供を行います（訳注：クラスタとは「ひと
かたまり」にしたもの、という意味）。また、サーバノードは、そのクラスタ
のコンソールであり、外部世界へのゲートウェイでもあります。大きな
Beowulf マシンは一つ以上のサーバノードを持つかもしれませんし、コンソー
ルとか、各ステーションのモニタ等の、特定業務専用のノードもあるかもしれ
ません。殆どの場合、 Beowulf システム中のクライアントノードは何もでき
ません、できなければできない程良いのです。クライアントノードはサーバノ
ードによって設定され制御され、するように言われたことだけを行います。
ディスクレスクライアントの設定では、クライアントは自分の IP アドレスと
か名前さえ、サーバーが教えるまでは知りません。 Beowulf と COW （ワーク
ステーションのクラスタ Cluster of Workstations ）との主な違いの一つ
は、多数のワークステーションとしてよりも、単一のマシンのように振る舞う
方に Beowulf は近い、という事実です。殆どの場合に、クライアントノード
はキーボードとかモニタを持たず、リモートログイン（シリアル端末かもしれ
ませんが）を介してだけアクセスされます。 Beowulf のノードは、ちょうど
マザーボードの中に差し込める CPU とかメモリモジュールのように、そのク
ラスタに差し込める CPU ＋ メモリのパッケージと考えられます。
Beowulf は、特別なソフトウェアパッケージでも、新規ネットワークトポロジ
でも、最新のカーネルハックでもありません。 Beowulf は、複数の Linux コ
ンピュータをクラスタ化して、並列仮想スーパーコンピュータを形成する技術
です。 Beowulf アーキテクチャをもっと高速に、設定をもっと簡単に、もっ
と使い易くする、カーネル修正とか、PVM と MPI ライブラリ、設定ツール等
のソフトウェアパッケージは多数あります。しかし、標準的な Linuxディスト
リビューションを使って、何のソフトウェアも追加しないで Beowulf クラス
のマシンを構築できます。あなたがネットワーク化された Linux コンピュー
タを 2 台持っていて、少なくとも NFS を介して /home を共有しており、お
互い信用できてリモートシェル (rsh) を実行するのなら、あなたは単純な 2
ノードの Beowulf マシンを持っている、と論じられるでしょう。
2.3. 分類
Beowulf システムは多様な部品で構築されてきました。性能のために、ありき
たりでない部品（つまり、単一の製造業者の製品）いくつかも採用されてきま
した。システムのタイプが何通りかを数え上げるためと、マシンの議論を少し
は簡単にするために、私たちは次の単純なクラス分けの枠組みを提案します。
CLASS I BEOWULF
このクラスのマシンは、完全にありきたりの「簡単に入手できる」パーツを
使って全部が構築されます。ありきたりの「簡単に入手できる」パーツを定義
するのに、「 Computer Shopper 」検証テストを使うことにしましょう（
Computer Shopper は PC システムとか部品の、 1 インチ厚の月刊雑誌/カタ
ログです）。このテストは次のようなものです。
CLASS I Beowulf とは、少なくとも 3 つの国で入手できるか、世界的に入手
できる、というのに丸が付けられた広告カタログで見付かるパーツで組み立て
られるマシンである。
CLASS I システムの利点は
o ハードウェアが複数の提供元から入手可能（低価格、容易な保守）
o 単一のハードウェアベンダへの依存なし
o Linux コミュニティからのドライバサポート
o 普通は標準準拠（ SCSI、イーサネット 等々）
CLASS I システムの欠点は
o 最高性能には CLASS II のハードウェアが必要かもしれない
CLASS II BEOWULF
CLASS II Beowulf は単純に、 Computer Shopper 検証テストをパスしないマ
シン全てです。これは悪いことではありません。全くこれはマシンの分類にす
ぎません。
CLASS II システムの利点は
o 性能が結構良好になれる！
CLASS II システムの欠点は
o ドライバサポートが変わるかもしれない
o 単一のハードウェアベンダへの依存
o CLASS I システムよりも高価になるかもしれない
一つのクラスが他方のクラスより良好だとは限りません。全てはあなたのニー
ズと予算に依存することです。システムをこう分類するのは、 Beowulf シス
テムについての議論を若干実りあるものにさせるためにすぎません。「システ
ム設計」の節は、どの種類のシステムがあなたのニーズに一番合うかを判断す
るのに役立つでしょう。
3. アーキテクチャ概要
3.1. これは、どんな風に見えますか？
Beowulf スーパーコンピュータアーキテクチャを分かってもらうには、実際の
Beowulf と非常に似ていて、殆どのシステム管理者に身近な、例示を使うのが
一番だと私は思います。 Beowulf マシンに一番近い例は、一つのサーバと多
数のクライアントがある Unix コンピュータ実験室です。もっと具体的には、
私は DEC Alpha undergraduate computer laboratory at the Faculty of
Sciences, USQ を例に取りましょう。このサーバコンピュータは beldin と呼
ばれ、クライアントマシンは、 scilab01、 scilab02、 scilab03か
ら、scilab20 までと呼ばれます。全てのクライアントは Digital Unix 4.0
オペレーティングシステムのローカルコピーを持ち、インストールされていま
すが、ユーザのファイル空間 (/home) と /usr/local はサーバから NFS
(Network File System) で持ってきています。各クライアントはサーバにエン
トリを持ち、それぞれの /etc/hosts.equiv ファイルの中にはその他全てのク
ライアントが入っています。ですから、全てのクライアントはその他全てに対
してリモートシェル (rsh) を実行できます。このサーバマシンは実験室全体
の NIS サーバですから、全てのマシンにわたりアカウント情報は同じです。
誰かが scilab02 のコンソールに座りログオンすれば、彼がサーバとか
scilab15 にログインしたのと同じ環境を持ちます。全てのクライアントが同
じ使い勝手を持つのは、このオペレーティングシステムがインストールされて
全マシンで同一の方法で設定されており、ユーザの /home と /usr/local 領
域が物理的にサーバ上にあり NFS を介してアクセスされるからです。 NIS と
NFS を更に知りたいなら NIS と NFS の HOWTO を読んで下さい。
3.2. その他のノードを使えるようにする方法は？
ここまでで、このシステムのアーキテクチャについて少し分かりました。この
コンピュータ実験室内のマシンの利用可能な CPU サイクルを、どうやって使
えるようにするかを見てみましょう。誰でも任意のマシンにログインでき、自
分のホームディレクトリ中のプログラムを走らせられますし、単なるリモート
シェルの実行によって別のマシン上で同一のジョブを spawn もできます。例
えば、 1 から 10 までの全ての整数の平方根の合計を計算したいとしましょ
う。私たちはそれをきっちり行う sigmasqrt （ ``source code'' を参照して
下さい）と呼ばれる簡単なプログラムを書きます。 1 から 10 までの数の平
方根の合計を計算するには、私たちは次を実行します。
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278
real 0m0.029s
user 0m0.001s
sys 0m0.024s
この time コマンドで、このジョブが走る時間を柱時計（経過時間）でチェッ
クできます。見ての通り、この例は実行するのに何十分の 1 秒（ 0.029 秒）
しかかかりませんが、もし私が 1 から 10 億までの整数の平方根を加算した
いとすればどうでしょうか？それを試してみましょう、そして再び柱時計の時
間を計算しましょう。
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000
real 16m45.937s
user 16m43.527s
sys 0m0.108s
今度は、このプログラムの実行時間は相当長いです。誰でも聞きたくなる疑問
は、このジョブの実行時間を高速化するために何ができるか、です。このジョ
ブが走る方法をどう変更すれば、このジョブが走る柱時計の時間を最小にでき
るでしょうか？誰でも答える解答は、このジョブを多数のサブジョブに分割し
て、全てのコンピュータ上で並列にこれらのサブジョブを走らせることです。
私たちは一つの大きな加算タスクを 20 の部分に分割して、各ノードの上で一
つの範囲の平方根を計算して合計できるでしょう。全てのノードが計算を終了
して結果を返した時に、その 20 個の数値は合計されて最終解を得ます。この
ジョブを走らせる前に、全てのプロセスが自分の結果を書き込むのに使われる
ことになる名前付きパイプを作成しましょう。
[jacek@beldin sigmasqrt]$ mkfifo output
[jacek@beldin sigmasqrt]$ ./prun.sh & time cat output | ./sum
[1] 5085
21081851083600.941000
[1]+ Done ./prun.sh
real 0m58.539s
user 0m0.061s
sys 0m0.206s
今度は約 58.5 秒でした。これはジョブがスタートしてから、全てのノードで
各自の計算が終わり、パイプへ結果を書き込み終わるまでの時間です。この時
間には 20 個の数字を最後に加算するのは含みませんが、その時間は非常に僅
かなので無視できます。このジョブを並列に走らせて相当の改善を見ることが
できます。実際に、並列ジョブは約 17 倍高速に走りました、これは CPU の
数にして全部で 20 倍増やした場合としては、とても合理的です。この例の目
的は、並行コードを並列化する一番単純な方法を描写することです。実際には
こんな単純な例はまれで、別の技術（ PVM と PMI の API ）が並列性を達成
するのに使われます。（訳注：並行 concurrent と並列 parallel は混乱しが
ちです。並行はスレッドのようにソフトウェア的に動作が並行するもので、並
列は SMP のようにハードウェア的に並列しているもののようです。これにつ
いては``適合性''の節を参照して下さい。）
3.3. Beowulf と COW （ワークステーションのクラスタ）はどう違うの？
上記のコンピュータ実験室は完全にワークステーションのクラスタ (Cluster
of Workstations (COW)) の例です。それでは、 Beowulf の何が特別で、どん
なふうに COW と違うのでしょうか？ 真実はこうです、さほどの違いはあり
ません、しかし Beowulf には、数少ないですが独自の性格が間違いなくあり
ます。まず始めに、 Beowulf クラスタのクライアントノードは、キーボード
も、マウス、ビデオカード、モニターも持たないのが殆どです。このクライア
ントノードへのアクセスにはリモート接続を介して、サーバノードから、ある
いは、専用コンソールノード、シリアルコンソールから行われます。クライア
ントノードからクラスタ外部のマシンにアクセスする必要はありませんし、ク
ラスタ外部のマシンからクライアントへ直接アクセスする必要もありませんか
ら、 10.0.0.0/8 とか 192.168.0.0/16 のアドレス範囲（ RFC 1918
http://www.alternic.net/rfcs/1900/rfc1918.txt.html 訳注：原著のアドレ
スは訳者はアクセスできず、ここの方はアクセスできました）等のプライベー
トアドレスをクライアントノードに使用するのがよくある習慣です。二枚目の
ネットワークカードを使って外部世界にも接続するマシンはサーバノードだ
け、というのはよくあります。このシステムの使い方で一番よくあるのは、そ
のサーバのコンソールに直接アクセスするか、個人のワークステーションから
サーバノードに telnet かリモートログインするものです。一旦サーバノード
上に入れば、ユーザは自分のコードを編集してコンパイルでき、クラスタ中の
全ノード上でのジョブの spawn もできます。殆どの場合に、COW では、人々
が実際には日常業務に使っていないのでアイドルの CPU サイクルを活用でき
る、夜間とか週末に、並列計算用に利用されます。それに対して Beowulf は
普通は並列計算専用のマシンで、その目的に最適化されています。また
Beowulf はすぐに入手できる部品で構築されており、主にフリーのソフトウェ
アを走らせますので、より高い価格性能比を得られます。また、 Beowulf ク
ラスタが単一の計算ワークステーションだ、とユーザから見えるのに役立つ、
単一システムイメージの機能を Beowulf はより多く持ちます。
4. システム設計
ハードウェアを購入する前に、あなたのシステム設計を考察しておく方が良い
でしょう。 Beowulf システムの設計で基本的なハードウェア事項は 2 つあり
ます - あなたが使おうとするノードとかコンピュータのタイプ、コンピュー
タノードに接続する方法です。ハードウェア選択に影響するかもしれないソフ
トウェア事項が一つあります - 通信ライブラリとか API です。ハードウェア
と通信ソフトウェアについては、後程もっと詳細に議論します。
選択肢は多くありませんが、 Beowulf システムを構築する上で大事な設計上
の決定が幾つかあります。「並列計算」の科学（または技法）にはたくさんの
違う解釈がありますので、以下に紹介します。もし背景事項を読むのがお好き
でないなら、本節は飛ばせますが、あなたが最終的なハードウェアを決定する
前に ``適合性''の節を読むよう、アドバイスしておきます。
4.1. 並列計算の背景概要
本節は並列計算という概念の背景を示します。これは決して、並列計算の科学
とか技術の網羅的で完全な説明ではありません。これは Beowulf の設計者と
ユーザには大切と思われる事柄の概要を説明したものです。
あなたの Beowulf の設計と構築の際に、以下で説明する事柄の多くはあなた
の決定プロセスで重要になることでしょう。 Beowulf は本質的に私たちが選
んで構成するものですから、 Beowulf スーパーコンピュータの多くの要素を
私たちが注意深く考慮する必要があります。一般的に、並列計算に含まれる事
柄を理解するのは決して難しくはありません。本当に、一旦これらの事柄が理
解されれば、あなたの予想はさらに現実的になり、成功はさらに確実になりま
す。プロセッサの速度が唯一で最重要の要素と考えられる「逐次的世界（
sequential world ）」とは違って、「並列の世界（ parallel world ）」に
おけるプロセッサの速度は、システム全体の性能と効率を決定する幾つかの要
素の中の一つにすぎません。
4.2. 並列計算の方式
並列計算は多くの形態をとれます。ユーザの視点から、各方式の利点と欠点を
考察するのが重要です。以下の節では、並列計算の方式をどう見るかを幾つか
示し、 Beowulf マシンがそれらの中でどれに当たるのかを示すつもりです。
4.2.1. なぜ一つ以上の CPU か？
この質問への解答は重要です。あなたのワードプロセッサで 8 CPU を走らせ
るのはちょっと「やりすぎ」のように聞こえるでしょうし、その通りです。で
はウェブサーバとか、データベース、レンダリングプログラム、プロジェクト
スケジューラならどうでしょうか？ 多分追加の CPU が役立ちます。複雑なシ
ミュレーションとか、流体力学のコード、データマイニングアプリケーション
ならどうでしょう？このような状況では追加の CPU が間違いなく役立ちま
す。本当に、ますます多くの問題解決に複数の CPU が使われるようになって
います。
その次の質問は多分こうでしょう、「なぜ 2 つとか 4 つの CPU が私に必要
なのですか？私は 986 ターボハイパーチップが出てくるのを待つだけにした
いな」。これには幾つかの理由があります。
1. マルチタスクのオペレーティングシステムの利用で、同時に幾つかを実行
できます。これは、一つ以上の安価な CPU によって簡単にできるようにな
る自然な「並列性」です。
2. プロセッサ速度は 18 ヵ月毎に倍増してきていますが、 RAM 速度とかハー
ドディスク速度はどうでしょうか？残念ながら、これらの速度は CPU 速度
程早くは増加していません。殆どのアプリケーションは「キャッシュ以外
のメモリアクセス」とハードディスクアクセスが必要だということを念頭
に置きましょう。並列に物事を行うのは、このような制約の幾つかを乗り
越える一つの方法です。
3. 予想によれば、 2005 年以降は 18 ヵ月毎のプロセッサ速度倍増は続かな
いでしょう。この増加傾向を維持するために乗り越えなければならない障
害には、非常に深刻なものが幾つかあるのです。
4. アプリケーションによりますが、並列計算で高速化できる度合いは、 2 倍
から 500 倍の間のどこか（幾つかの場合には更に高速に）です。これだけ
の性能は単一のプロセッサを使うのでは得られません。スーパコンピュー
タでさえ、一時は極めて高速の特注プロセッサを使っていたのが、今では
複数の「ありふれたすぐに入手できる」 CPU で構築されています。
あなたが、計算限界問題 および / または 入出力限界問題のために、速度が
必要だとしたら、並列化が検討に値します。並列計算は多様な方法で実装され
ますので、あなたの問題を並列化で解決するには幾つか非常に大事な決定が必
要になります。これらの決定は、あなたのアプリケーションの可搬性と性能と
費用に、劇的に影響するかもしれません。
技術的になる前に、店で長い列に並んで待つという、私たちに身近な問題を例
にとって、実際の「並列計算問題」を眺めてみましょう。
4.2.2. 並列計算のお店
店の正面に 8 つのキャッシュレジスタを一緒に置いている大きな店を考えま
しょう。キャッシュレジスタがそれぞれ一つの CPU で、お客さんがそれぞれ
一つのコンピュータプログラムだと想定します。このコンピュータプログラム
のサイズ（業務の量）は、お客さんそれぞれの注文のサイズです。以下の比喩
は、並列計算の概念を描写するのに使えます。
4.2.2.1. シングルタスクのオペレーティングシステム
一つのキャッシュレジスタがオープン（使用可能状態）で、それぞれのお客さ
んを一時に一人ずつ処理しなければならない。
コンピュータの例 - MS DOS
4.2.2.2. マルチタスクのオペレーティングシステム
一つのキャッシュレジスタがオープンです、しかし、ここではそれぞれの注文
の一部分だけを一時に処理し、次のお客さんに移ってそちらの注文の幾らかを
処理します。お客は皆その行列で一緒に動いていると「見え」ますが、その行
列に他に誰も居なければその行列をもっと早く通過するでしょう。
コンピュータの例 - 単一の CPU を使う UNIX 、 NT
4.2.2.3. 複数の CPU を使ったマルチタスクのオペレーティングシステム
今度は、店に幾つかのキャッシュレジスタがオープンしています。それぞれの
注文は別々のキャッシュレジスタで処理できて、行列はかなり早く通過できま
す。これは SMP - Symmetric Multi-processing と呼ばれます。追加のキャッ
シュレジスタがオープンしていても、キャッシュレジスタが一つでお客があな
た一人だけの時よりも早い行列通過は、決してできません。
コンピュータの例 - 複数 CPU の UNIX と NT
4.2.2.4. 複数の CPU のマルチタスクのオペレーティングシステム上でのス
レッド
あなたの注文の品目をあなたが「細分化」すれば、一時に幾つかのキャッシュ
レジスタを使うことで、行列をもっと早く通り抜けられるでしょう。最初にあ
なたの品物の分量が大量だと想定しなければなりません、なぜなら、「あなた
の注文の細分化」での投資が複数のキャッシュレジスタ利用で取り戻さねばな
らないからです。理論的には、あなたは以前よりも「 n 」倍早く行列を通過
できるはずです、この「 n 」はキャッシュレジスタの数です。キャッシュレ
ジスタが小計をとる必要がある時には、キャッシュレジスタたちは別の「ロー
カル」キャッシュレジスタ全てを見たり話したりして即座に情報交換できま
す。キャッシュレジスタたちは別のキャッシュレジスタを覗きまわって、自分
がもっと早く仕事するのに必要な情報を見つけたりさえできます。しかし、制
限があります、その店のどこか一個所でキャッシュレジスタを効率的に設置で
きる数には、限りがあります。
また、 Amdals の法則によって、そのアプリケーションの高速化は、そのプロ
グラムの最低速の逐次的部分に制限されます。
コンピュータの例 - マルチスレッド化されたプログラムを走らせている、同
一のマザーボード上に複数 CPU を持たせた UNIX か NT
4.2.2.5. 複数の CPU を持つマルチタスクのオペレーティングシステム上の
メッセージ送 信
性能向上のために、この店では店の後ろに 8 つのキャッシュレジスタを追加
しました。この新しいキャッシュレジスタは、自分の小計を店の正面のキャッ
シュレジスタに送信するのに、電話を掛けねばなりません。この距離はキャッ
シュレジスタ同士の通信に余分のオーバーヘッド（時間）を加えますが、もし
通信が最小限にされたなら、それは問題にはなりません。もしあなたが、全部
のキャッシュレジスタを必要とするような、本当に大きな注文をしたなら、上
記と同様に同時に全てのキャッシュレジスタを使うことで、速度を改善できま
す、余分のオーバーヘッドも考慮に入れなければなりません。ある場合には、
この店は単一のキャッシュレジスタ（またはキャッシュレジスタの島）が店の
中全体に散らばっているかもしれず、それぞれのキャッシュレジスタ（か島）
同士が、電話で通信しなければならないかもしれません、全てのキャッシュレ
ジスタがお互いに電話で話し合えますから、その場所の数多さは問題になりま
せん。
コンピュータの例 - 複数 CPU を同一または複数のマザーボード上に持ち、
メッセージを介して通信する UNIX や NT （等のコピー）
ここまでのシナリオは、正確ではなくとも、並列システムで起きる制約をうま
く表現しています。単一の CPU （つまりキャッシュレジスタ一台）だけとは
違って、通信が課題です。
4.3. 並列計算のアーキテクチャ
並列計算でよくある手法とアーキテクチャを以下に説明します。決して網羅的
な説明にはなりませんが、 Beowulf 設計に必要な基本的事項を理解するには
十分です。
4.3.1. ハードウェアアーキテクチャ
並列コンピュータのハードウェアを一つにまとめるには、基本的に二つ方法が
あります。
1. ローカルメモリマシンでメッセージで通信を行うもの（ Beowulf クラス
タ）
2. 共有メモリマシンでメモリを介して通信を行うもの（ SMP マシン）
典型的な Beowulf は、高速なイーサネットを使って接続された単一 CPU マシ
ンの集合ですから、ローカルメモリマシンです。 4 CPU の SMP ボックスは共
有メモリマシンで、並列計算に使えます - 並列アプリケ−ションは共有メモ
リを使って通信します。ちょうど、コンピュ−タの店の比喩で、ロ−カルメモ
リマシン（個々のキャッシュレジスタ）は多数の CPU にまで規模拡大が可能
な一方では、メモリ取り合いのために共有メモリマシンの CPU 数（一個所に
設置できるキャッシュレジスタの数）に制約が生じるかもしれない、というの
と同じです。
しかし、多数の共有メモリマシンを接続して「ハイブリッド」共有メモリマシ
ンを作成できます。このようなハイブリッドマシンは、ユーザにとっては単一
の大きな SMP マシンのように「見え」、プログラマから見えて全ての CPU が
共有するグローバルメモリは異なるレーテンシを持ちうることから、
NUMA（一様ではないメモリアクセス non uniform memory access ）としばし
ば呼ばれます。しかし、幾つかのレベルでは、 NUMA マシンはローカル共有メ
モリのプールの相互間で「メッセージのパス」をしなければなりません。
ローカルメモリ計算ノードとして SMP マシンを接続するのも可能です。典型
的なクラス I マザーボードは 2 個か 4 個の CPU を持ち、しばしばシステム
コスト全体を下げる方法として使われます。 Linux 内部のスケジューラはこ
れらの CPU を共有させる方法を判断します。ユーザは特定の SMP プロセッサ
に（この点では）特定のタスクを割り当てることはできません。しかし、ユー
ザは二つの独立したプロセスとかスレッド化されたプロセスをスタートさせ
て、単一 CPU マシンよりも性能向上を見るように期待できます。
4.3.2. ソフトウェア API アーキテクチャ
基本的に、一つのプログラム中での平行性を「表現する」のに二つの方法があ
ります。
1. プロセッサ間で送信されるメッセージの使用
2. オペレーティングシステムのスレッドの使用
その他の方法も間違いなく存在しますが、これらは最も広く使われる二つの方
法です。平行性の表現は、想定するハードウェアに必ずしも左右されません、
このことを忘れないようにするのが大事です。メッセージもスレッドもとも
に、 SMP でも、 NUMA-SMP でもクラスタでも実装できます、ただし、以下に
説明するように、効率性と可搬性が大事な事柄です。
4.3.2.1. メッセージ
歴史的に、メッセージパッシング技術は、初期のローカルメモリ並列コンピュ
ータの設計を反映しました。メッセージはデータをコピーする必要があります
が、スレッドはデータを適宜使います。コピー可能なメッセージでのレーテン
シと速度は、メッセージパッシングモデルでの制約要素です。メッセージは十
分単純です - 何かのデータと送り先のプロセッサです。共通のメッセージ
パッシング API はPVM か MPI にあります。メッセージパッシングはスレッド
を用いて効率的に実装可能で、 SMP マシン上でもクラスタのマシン間でもう
まく働きます。スレッドと比べて、 SMP マシン上でメッセージを使う利点
は、あなたが将来クラスタを使う決心をしたとしても、マシンの追加とかあな
たのアプリケーションの規模拡大が容易だということです。
4.3.2.2. スレッド
共有メモリ SMP （対称マルチプロセッシング）が設計されたので、一つのプ
ログラム中での並行部分の相互で、非常に高速の共有メモリ通信と同期が可能
となりました、そのために、オペレーティングシステムのスレッドは開発され
ました。通信は共有メモリを介するので、 SMP システム上のスレッドはうま
く働きます。この理由により、ユーザはローカルデータをグローバルデータか
ら隔離しなければなりません、さもなければ、プログラムは適正に働かないで
しょう。メッセージと対比して、スレッドでは大量のコピーが省略できます、
そのデータはプロセス（スレッド）間で共有されるからです。 Linux は
POSIX スレッドをサポートします。スレッドでの問題は、一つの SMP マシン
を超えてのスレッドの拡張が難しいことです、また、データが CPU の間で共
有されますから、キャッシュの首尾一貫性の問題がオーバヘッドになるかもし
れません。 SMP の境界を超えてのスレッドの拡張を効率的に行うには、
Linux でネイティブにサポートされていない高価な NUMA 技術を必要としま
す。メッセージの上へのスレッド実装は既に行われていますが（
(http://syntron.com/ptools/ptools_pg.htm) 訳注：訳者はここはアクセスで
きませんでした）、メッセージを使ってのスレッドの実装は非効率的なことが
多いです。
性能について、以下のことが言えます。
SMP マシン マシンのクラスタ 拡張可能性
性能 性能 （ scalability ）
----------- ------------------- -----------
メッセージ 良好 最高 最高
スレッド 最高 貧弱 ＊ 貧弱 ＊
＊ 高価な NUMA 技術が必要
4.3.3. アプリケーションのアーキテクチャ
複数 CPU 上で並列にアプリケーションを走らせるためには、アプリケーショ
ンを並行部分に明確に分割しなければなりません。標準的な単一 CPU アプリ
ケーションは、複数プロセッサ上で単一 CPU アプリケーションよりも早く走
ることはありません。プログラムを分割できるツールとコンパイラは幾つかあ
りますが、コードを並列化するのは「プラグアンドプレイ」操作ではありませ
ん。そのアプリケーションに依存して、コードの並列化は簡単にもなれば、極
端に難しくもなり、アルゴリズムの依存性のために不可能になる場合もあるか
もしれません。
ソフトウェアの事柄を述べる前に、適合性 (Suitability) の考え方を導入す
る必要があります。
4.4. 適合性 (Suitability)
並列計算についての殆どの疑問は同じ答えになります。
「それはアプリケーションに全て依存します。」
この事柄に飛び込む前に、一つとても大事な区別をしておく必要があります -
並行 (CONCURRENT) と 並列 (PARALLELL) の違いです。議論を進めるために、
この二つの概念を次のように定義しましょう。
並行 (CONCURRENT) 一つのプログラムで、独立して計算可能な部分
並列 (PARALLELL) 一つのプログラムで、同時に別個の処理要素上で実行さ
れる並行部分
この区別は非常に重要です、なぜなら、平行性はそのプログラムの属性であ
り、効率的な並列性はそのマシンの属性だからです。理想的には、並列実行は
より高速の性能を生むはずです。並列性能を制約する要素は計算ノード間の通
信速度とレーテンシです。（レーテンシは、スレッド化された SMP アプリケ
ーションにも、キャッシュの一貫性のために存在します。）よくある並列ベン
チマークの多くは、高度に並列で、通信とレーテンシはボトルネックではあり
ません。このタイプの問題は「明らかに並列」と呼ぶことができます。これ以
外のアプリケーションはそれ程単純ではなく、そのプログラムの並行部分を並
列に実行すると、実際には低速に走らせることになってしまい、そのためにプ
ログラム中の他の並行部分での性能向上を相殺してしまうかもしれません。簡
単に言うと、計算時間節約のために通信時間の費用を支払わねばなりません、
さもなければ並行部分の並列実行は非効率的になります。
プログラマの仕事は、そのプログラムのどの並行部分が並列に実行されるべき
で、どの部分が実行されるべきでないかを判断することです。これの解答はア
プリケーションの効率性を決定付けるでしょう。以下のグラフはそのプログラ
マの立場をまとめています。
アプリケ | *
ーション | *
の％ | *
| *
| *
| *
| *
| *
| *
| *
| *
| ****
| ****
| ********************
+-----------------------------------
通信時間 / 処理時間
完全な並列コンピュータでは、通信/処理の比率は等しくなるでしょうし、並
行部分は全て並列で実装できるでしょう。残念ながら、共有メモリマシンを含
む現実の並列コンピュータは、このグラフで描かれた影響を受けます。
Beowulf を設計する時には、ユーザがこのグラフを心がけておくようにしま
しょう、何故なら、並列の効率は特定の並列コンピュータの通信時間と処理時
間の比率に依存するからです。アプリケーションは並列コンピュータの相互で
可搬かもしれませんが、異なるプラットフォームの上で効率的である保証はあ
りません。
一般的に、可搬でかつ効率的な並列プログラムは存在しません
もう一つの結論が上記のグラフから出て来ます。効率は通信/処理比に依存し
ますから、この比率の一方だけを変えても、必ずしも特定のアプリケーション
を高速化するとは限らないことです。通信速度を変えないでおいてプロセッサ
速度を変えると、あなたのプログラムで直感的には分からない影響を及ぼすか
もしれません。例えば、 CPU 速度を 2 、 3 倍にして、通信速度を同じにし
ましょう。今度は、以前にあなたのプログラム中で効率的だった 並列的部分
が、逐次的に実行した方が効率的になるかもしれません。これは、以前は並列
的だった部分を、今度は、逐次的に走らせた方が、もっと高速になるかもしれ
ないということです。更に、並列に走らせれば非効率的な部分が、そのアプリ
ケーションの最大速度の達成を実際には邪魔してしまうでしょう。従って、よ
り高速のプロセッサの追加によって、実際にはあなたのアプリケーションを低
速化させてしまうかもしれないのです（あなたはそのアプリケーションで新
CPU が最大速度で走るのを邪魔するのです）。
より高速な CPU へのアップグレードが実際にはあなたのアプリケーションを
低速化させるかもしれない。
それで、結論として、あなたが並列ハードウェア環境を使えるか否かを知るに
は、あなたのアプリケーションが特定のマシンに適合するかどうかを、見抜く
必要があります。あなたは、 CPU 速度とか、コンパイラ、メッセージパッシ
ング API 、ネットワークなどを含む多数の事柄を調べる必要があります。気
を付けることは、あるアプリケーションのプロファイルを作成するだけでは、
全体は分からないことです。あなたはあなたのプログラムの計算量的に重たい
部分を特定できるでしょうが、その部分の通信コストは分かりません。ある与
えられたシステムにおいては、通信コストのおかげで、そのコードを並列的に
しない方が効率的になる、ということが有り得ます。
よくある誤解についての最後の注意です。「あるプログラムが並列化された」
と言われるのが、実際には、そのプログラムの並行部分の場所が分かったに過
ぎないことが多いのです。今までに述べた全ての理由のせいで、そのプログラ
ムは並列化されたのではありません。効率的な並列化はそのマシンの属性なの
です。
4.5. 並列ソフトウェアを書くことと移植すること
一旦、あなたが並列計算が必要だと決心し、 Beowulf を設計して構築しよう
とするなら、ここまでの議論に照らして、あなたのアプリケーションをちょっ
とした時間をかけて検討するのは良い考えです。
一般的にあなたができることは二つあります。
1. 前に進み、CLASS I の Beowulf を構築してから、あなたのアプリケーショ
ンをそれに「適合」させます。あるいは、あなたの Beowulf 上で動くこと
が分かっている既存の並列アプリケーションを走らせます（しかし、今ま
で述べてきた移植性と効率性の事項に気を付けるように）。
2. あなたの Beowulf 上で走らせる必要があるアプリケーションを調べて、あ
なたが必要なハードウェアとソフトウェアのタイプについての、何らかの
想定を行うこと。
いずれの場合でも、あなたは効率性の事柄について、いくつかを調べる必要が
あるでしょう。一般的には、あなたは 3 つ行う必要があります。
1. あなたのプログラムでの並行部分を判断する
2. 並列の効率性を見積もる
3. あなたのプログラムのその並行部分を記述する
この３つをちょっと調べてみましょう。
4.5.1. あなたのプログラムでの並行部分を判断する
このステップはしばしば「あなたのプログラムを並列化すること」、と考えら
れています。並列化の決定は第二ステップで行われます。本ステップではデー
タ依存性を判断する必要があります。
実用的見地から、アプリケーションは二つのタイプの平行性を示すでしょう -
計算（大量データ処理 number crunching ）と入出力（データベース）です。
しかし、多くの場合、計算と入出力の二つの平行性は直交します、両方が必要
なアプリケーションが存在します。既存のアプリケーションの平行性分析を行
えるツールが入手できます。これらのツールの殆どは FORTRAN 用に設計され
ています。 FORTRAN が使われる理由は二つあります - 歴史的に殆どの大量デ
ータ処理（ナンバークランチ）のアプリケーションが FORTRAN で書かれてい
ること、そして、分析がより容易なことです。どのツールも入手できなけれ
ば、既存のアプリケーションに対するこのステップは、やや困難になるかもし
れません。
4.5.2. 並列の効率性を見積もる
ツールの助けがなければ、本ステップには、試行錯誤とか、豊富な経験から割
り出した推測が必要かもしれません。あなたが特定のアプリケーションを念頭
に置いているのなら、 CPU が頭打ち（計算限界）なのか、ハードディスクが
頭打ち（入出力限界）なのかを判断してみましょう。あなたの Beowulf の所
要条件は、あなたの必要性に応じて相当違ってくるかもしれません。例えば、
計算限界問題には少数の極めて高速の CPU と低レーテンシネットワークが必
要かもしれませんし、入出力限界の問題にはもっと低速の CPU と高速なイー
サネットがもっと良く機能するかもしれません。
ここでお薦めしていることは殆どの人々を大概驚かせます、なぜなら、プロ
セッサは早ければ早い程常に良いというのが標準的予想だからです。あなたが
無限の予算を持っていればこの予想は真なのですが、コストの制約の元で最高
性能を目指すのが現実のシステムでしょう。入出力問題については、結構役立
ちますがあまり知られていない法則（ Eadline-Dedkov の法則と呼ばれます）
があります。
二つの並列コンピュータで累積的 CPU 性能指標が同一のものが与えられたと
して、より低速のプロセッサを持つ方（そして多分、分相応に、より低速のプ
ロセッサ相互の通信ネットワークを持つ方）が、入出力が支配的なアプリケー
ションにはより良い性能を持つことになる。（訳注：少数の高速 CPU を使っ
た並列コンピュータと、多数の低速 CPU を使った並列コンピュータとの二つ
があったとして、総計では同じ CPU 性能だったとすれば、入出力で時間がか
かるアプリケーションでは多数の低速 CPU を使った方が早い、という趣旨の
ようです。）
この法則の証明は本文書の範囲を超えますが、あなたはPerformance
Considerations for I/O-Dominant Applications on Parallel Computers
(Postscript format 109K ) (ftp://www.plogic.com/pub/papers/exs-
pap6.ps) 論文をダウンロードすれば興味深いでしょう。（訳注：原著の上記
アドレスは(ftp://www.plogic.com/plogic/papers/exs-pap6.ps) に変わって
いるようです。）
あなたのアプリケーション中の平行性のタイプを一旦判断したら、並列にして
どれ程効率的になるかを見積もる必要があるでしょう。ソフトウェアツールの
説明は ``Software'' の節を見てください。
ツールがなくても、推測によって本ステップをたどるのはできます。もし、計
算限界のループが数分単位で測定されて、データが秒単位で転送できるのな
ら、並列化の良い候補になるかもしれません。しかし、忘れないでおくのは、
16 分間かかるループを 32 の部分に分割して、あなたのデータ転送が各部分
ごとに数秒必要だとすれば、ぎりぎりになりかけている、ということです。あ
なたは収穫が減少するポイントに達するでしょう。
4.5.3. あなたのプログラムのその並行部分を記述する
あなたのプログラムの並行部分を記述する方法は幾つかあります。
1. 明示的並列実行
2. 暗黙的並列実行
この二つの主な違いは、明示的並列化はユーザが判断し、暗黙的並列実行はコ
ンパイラが判断することです。
4.5.3.1. 明示的方法
明示的方法では基本的に、ユーザがソースコードを、並列コンピュータ専用に
修正しなければなりません。ユーザは PVM か MPI を用いてメッセージを追加
するか、あるいは、 POSIX スレッドを用いてスレッドを追加するかしなけれ
ばなりません（しかし、留意することは、スレッドは SMP マザーボード間を
移動できないことです）。
明示的方法は実装とデバッグが最も困難になりがちです。ユーザは典型的に
は、標準 FORTRAN 77 とか C/C++ ソースコード中に明示的関数呼び出しを埋
め込みます。この MPI ライブラリには、幾つかの標準的並列手法を実装しや
すくする関数を幾つか追加しています（例えば、scatter/gather 関数）。そ
れに加えて、並列コンピュータ用に書かれてきた標準ライブラリも使えます。
（しかし、留意するのは、可搬性 vs. 効率性 のトレードオフです。）
歴史的理由から、殆どの大量データ処理（ナンバークランチ）のコードは、
FORTRAN で書かれています。このため、並列計算では、 FORTRAN にはサポー
ト（ツール、ライブラリ、その他）が一番多くあります。今では、Ｃではもっ
と高速実行できると考えて、多くのプログラマがＣを使ったり、既存の
FORTRAN のアプリケーションをＣに書き直したりします。Ｃは汎用マシンコー
ドに最も近いものですから、これは真かもしれませんが、幾つか大きな欠点が
あります。Ｃでのポインタ使用はデータ依存性の判定を極端に難しくします。
ポインタの自動分析は極端に困難です。あなたが既存の FORTRAN プログラム
を持っていて、将来的にそれを並列化させたくなるかもしれないと考えている
なら - それをＣに変換してはいけません。
4.5.3.2. 暗黙的方法
暗黙的方法は、並列化の決定の幾つか（または全て）をコンパイラにまかせる
ようなものです。例は、 FORTRAN 90 と、 High Performance FORTRAN (HPF)
、 Bulk Synchronous Parallel (BSP) 、そして、開発中のその他の方法、全
てです。
暗黙的方法は、ユーザのアプリケーションの並行的性質について何らかの情報
をユーザが与える必要がありますが、そうすれば、この並行的部分を並列に実
行する方法について、コンパイラが多くの決定を行います。これらの方法はあ
るレベルの可搬性と効率性をもたらしますが、それでも並列コンピュータのた
めに並行問題を記述する「最善の方法」は存在しません。
5. Beowulf の情報源
5.1. 出発点
o Beowulf メーリングリスト。参加するには beowulf-
request@cesdis.gsfc.nasa.gov 宛て、subscribe をメッセージ本文にして
メールを送ります。
o Beowulf ホームページ http://www.beowulf.org
o Extreme Linux http://www.extremelinux.org
o Red Hat からの Extreme Linux ソフトウェア
http://www.redhat.com/extreme
5.2. 文書
o Beowulf HOWTO の最新版
http://www.sci.usq.edu.au/staff/jacek/beowulf
o Beowulf システムの構築
http://www.cacr.caltech.edu/beowulf/tutorial/building.html
o Jacek's Beowulf Links
http://www.sci.usq.edu.au/staff/jacek/beowulf.
o Beowulf Installation and Administration HOWTO (DRAFT)
http://www.sci.usq.edu.au/staff/jacek/beowulf.
o Linux Parallel Processing HOWTO
http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html
5.3. 論文
o Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
Donald Becker, and Phillip Merkey A Design Study of Alternative
Network Topologies for the Beowulf Parallel Workstation.
Proceedings Fifth IEEE International Symposium on High Performance
Distributed Computing, 1996.
http://www.beowulf.org/papers/HPDC96/hpdc96.html
o Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
Becker, and Phillip Merkey. Harnessing the Power of Parallelism in
a Pile-of-PCs. Proceedings, IEEE Aerospace, 1997.
http://www.beowulf.org/papers/AA97/aa97.ps
o Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael R.
Berry, and Chance Res. Achieving a Balanced Low-Cost Architecture
for Mass Storage Management through Multiple Fast Ethernet Channels
on the Beowulf Parallel Workstation. Proceedings, International
Parallel Processing Symposium, 1996.
http://www.beowulf.org/papers/IPPS96/ipps96.html
o Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce Fryxell,
Kevin Olson. Communication Overhead for Space Science Applications
on the Beowulf Parallel Workstation. Proceedings,High Performance
and Distributed Computing, 1995.
http://www.beowulf.org/papers/HPDC95/hpdc95.html
o Donald J. Becker, Thomas Sterling, Daniel Savarese, John E.
Dorband, Udaya A. Ranawak, Charles V. Packer. BEOWULF: A PARALLEL
WORKSTATION FOR SCIENTIFIC COMPUTATION. Proceedings, International
Conference on Parallel Processing, 95.
http://www.beowulf.org/papers/ICPP95/icpp95.html
o Beowulf サイトの論文 http://www.beowulf.org/papers/papers.html
5.4. ソフトウェア
o PVM - Parallel Virtual Machine
http://www.epm.ornl.gov/pvm/pvm_home.html
o LAM/MPI (Local Area Multicomputer / Message Passing Interface
http://www.mpi.nd.edu/lam
o BERT77 - FORTRAN conversion tool http://www.plogic.com/bert.html
o Beowulf プロジェクトのページからの Beowulf ソフトウェア
http://beowulf.gsfc.nasa.gov/software/software.html
o Jacek's Beowulf-utils ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-
utils
o bWatch - cluster monitoring tool
http://www.sci.usq.edu.au/staff/jacek/bWatch
5.5. Beowulf マシンたち
o Avalon は 140 の Alpha プロセッサ、 36 GB の RAM で構成され、多分最
速の Beowulf マシンで、 47.7 Gflops で巡航し、 Top 500 リストの 114
番目です。 http://swift.lanl.gov/avalon/ （訳注：上記アドレス
はhttp://cnls.lanl.gov/avalon/ になっているようです。 top 500 list
によれば、 160 位でした。なお、 129 位には CPlant Cluster が入って
います。）
o Megalon-A Massively PArallel CompuTer Resource (MPACTR) は 4 CPU
Pentium Pro 200 のノードが 14 個と 14 GB の RAM で構成されていま
す。 http://megalon.ca.sandia.gov/description.html （訳注：訳者はア
クセスできませんでした。）
o theHIVE - Highly-parallel Integrated Virtual Environment はもう一つ
の高速 Beowulf スーパーコンピュータです。 theHIVE は 64 ノードの
128 CPU マシンで全部で 4 GB RAM を持ちます。
http://newton.gsfc.nasa.gov/thehive/
o Topcat はもっと小さなマシンで、 16 CPU と 1.2 GB RAM で構成されま
す。 http://www.sci.usq.edu.au/staff/jacek/topcat
o MAGI cluster - これは非常に面白いサイトで良いリンクがたくさんありま
す。 http://noel.feld.cvut.cz/magi/
5.6. その他の面白いサイト
o SMP Linux http://www.linux.org.uk/SMP/title.html
o Paralogic - Beowulf を買えるhttp://www.plogic.com
5.7. 歴史
o 遺産 - Beowulf http://legends.dm.net/beowulf/index.html
o Beowulf の冒険
http://www.lnstar.com/literature/beowulf/beowulf.html
6. ソースコード
6.1. sum.c
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */
#include
一覧に戻る
グリーンネット・トップページへ戻る |
