ハードウェアを購入する前に、 あなたのシステム設計を考察しておく方が良いでしょう。 Beowulf システムの設計で基本的なハードウェア事項は 2 つあります - あなたが使おうとするノードとかコンピュータのタイプ、 コンピュータノードに接続する方法です。 ハードウェア選択に影響するかもしれないソフトウェア事項が一つあります - 通信ライブラリとか API です。ハードウェアと通信ソフトウェアについては、 後程もっと詳細に議論します。
選択肢は多くありませんが、 Beowulf システムを構築する上で大事な設計上の決定が幾つかあります。 「並列計算」の科学（または技法）にはたくさんの違う解釈がありますので、 以下に紹介します。 もし背景事項を読むのがお好きでないなら、本節は飛ばせますが、 あなたが最終的なハードウェアを決定する前に 適合性の節を読むよう、アドバイスしておきます。
本節は並列計算という概念の背景を示します。これは決して、 並列計算の科学とか技術の網羅的で完全な説明ではありません。これは Beowulf の設計者とユーザには大切と思われる事柄の概要を説明したものです。
あなたの Beowulf の設計と構築の際に、以下で説明する事柄の多くは あなたの決定プロセスで重要になることでしょう。 Beowulf は本質的に私たちが選んで構成するものですから、 Beowulf スーパーコンピュータの多くの要素を私たちが注意深く考慮する必要がありま す。 一般的に、並列計算に含まれる事柄を理解するのは決して難しくはありません。 本当に、一旦これらの事柄が理解されれば、 あなたの予想はさらに現実的になり、成功はさらに確実になります。 プロセッサの速度が唯一で最重要の要素と考えられる 「逐次的世界（ sequential world ）」とは違って、 「並列の世界（ parallel world ）」におけるプロセッサの速度は、 システム全体の性能と効率を決定する幾つかの要素の中の一つにすぎません。
並列計算は多くの形態をとれます。ユーザの視点から、 各方式の利点と欠点を考察するのが重要です。 以下の節では、並列計算の方式をどう見るかを幾つか示し、 Beowulf マシンがそれらの中でどれに当たるのかを示すつもりです。
この質問への解答は重要です。あなたのワードプロセッサで 8 CPU を走らせるのはちょっと「やりすぎ」のように聞こえるでしょうし、 その通りです。 ではウェブサーバとか、データベース、レンダリングプログラム、 プロジェクトスケジューラならどうでしょうか？ 多分追加の CPU が役立ちま す。 複雑なシミュレーションとか、流体力学のコード、 データマイニングアプリケーションならどうでしょう？ このような状況では追加の CPU が間違いなく役立ちます。本当に、 ますます多くの問題解決に複数の CPU が使われるようになっています。
その次の質問は多分こうでしょう、 「なぜ 2 つとか 4 つの CPU が私に必要なのですか？ 私は 986 ターボハイパーチップが出てくるのを待つだけにしたいな」。 これには幾つかの理由があります。
あなたが、計算限界問題 および / または 入出力限界問題のために、 速度が必要だとしたら、並列化が検討に値します。 並列計算は多様な方法で実装されますので、 あなたの問題を並列化で解決するには幾つか非常に大事な決定が必要になりま す。 これらの決定は、あなたのアプリケーションの可搬性と性能と費用に、 劇的に影響するかもしれません。
技術的になる前に、店で長い列に並んで待つという、 私たちに身近な問題を例にとって、実際の「並列計算問題」を眺めてみましょ う。
店の正面に 8 つのキャッシュレジスタを一緒に置いている大きな店を考えまし ょう。 キャッシュレジスタがそれぞれ一つの CPU で、 お客さんがそれぞれ一つのコンピュータプログラムだと想定します。 このコンピュータプログラムのサイズ（業務の量）は、 お客さんそれぞれの注文のサイズです。 以下の比喩は、並列計算の概念を描写するのに使えます。
一つのキャッシュレジスタがオープン（使用可能状態）で、 それぞれのお客さんを一時に一人ずつ処理しなければならない。
コンピュータの例 - MS DOS
一つのキャッシュレジスタがオープンです、しかし、 ここではそれぞれの注文の一部分だけを一時に処理し、 次のお客さんに移ってそちらの注文の幾らかを処理します。 お客は皆その行列で一緒に動いていると「見え」ますが、 その行列に他に誰も居なければその行列をもっと早く通過するでしょう。
コンピュータの例 - 単一の CPU を使う UNIX 、 NT
今度は、店に幾つかのキャッシュレジスタがオープンしています。 それぞれの注文は別々のキャッシュレジスタで処理できて、 行列はかなり早く通過できます。これは SMP - Symmetric Multi-processing と呼ばれます。 追加のキャッシュレジスタがオープンしていても、キャッシュレジスタ が一つでお客があなた一人だけの時よりも早い行列通過は、 決してできません。
コンピュータの例 - 複数 CPU の UNIX と NT
あなたの注文の品目をあなたが「細分化」すれば、 一時に幾つかのキャッシュレジスタを使うことで、 行列をもっと早く通り抜けられるでしょう。 最初にあなたの品物の分量が大量だと想定しなければなりません、 なぜなら、「あなたの注文の細分化」 での投資が複数のキャッシュレジスタ利用で取り戻さねばならないからです。 理論的には、あなたは以前よりも「 n 」倍早く行列を通過できるはずです、 この「 n 」はキャッシュレジスタの数です。 キャッシュレジスタが小計をとる必要がある時には、 キャッシュレジスタたちは別の「ローカル」 キャッシュレジスタ全てを見たり話したりして即座に情報交換できます。 キャッシュレジスタたちは別のキャッシュレジスタを覗きまわって、 自分がもっと早く仕事するのに必要な情報を見つけたりさえできます。 しかし、制限があります、 その店のどこか一個所でキャッシュレジスタを効率的に設置できる数には、 限りがあります。
また、 Amdals の法則によって、そのアプリケーションの高速化は、 そのプログラムの最低速の逐次的部分に制限されます。
コンピュータの例 - マルチスレッド化されたプログラムを走らせている、 同一のマザーボード上に複数 CPU を持たせた UNIX か NT
性能向上のために、この店では店の後ろに 8 つのキャッシュレジスタを追加しました。 この新しいキャッシュレジスタは、 自分の小計を店の正面のキャッシュレジスタに送信するのに、 電話を掛けねばなりません。 この距離はキャッシュレジスタ同士の通信に余分のオーバーヘッド （時間）を加えますが、もし通信が最小限にされたなら、 それは問題にはなりません。もしあなたが、 全部のキャッシュレジスタを必要とするような、 本当に大きな注文をしたなら、 上記と同様に同時に全てのキャッシュレジスタを使うことで、 速度を改善できます、余分のオーバーヘッドも考慮に入れなければなりません。 ある場合には、この店は単一のキャッシュレジスタ （またはキャッシュレジスタの島）が店の中全体に散らばっているかもしれず、 それぞれのキャッシュレジスタ（か島）同士が、 電話で通信しなければならないかもしれません、 全てのキャッシュレジスタがお互いに電話で話し合えますから、 その場所の数多さは問題になりません。
コンピュータの例 - 複数 CPU を同一または複数のマザーボード上に持ち、 メッセージを介して通信する UNIX や NT （等のコピー）
ここまでのシナリオは、正確ではなくとも、 並列システムで起きる制約をうまく表現しています。単一の CPU （つまりキャッシュレジスタ一台）だけとは違って、通信が課題です。
並列計算でよくある手法とアーキテクチャを以下に説明します。 決して網羅的な説明にはなりませんが、 Beowulf 設計に必要な基本的事項を理解するには十分です。
並列コンピュータのハードウェアを一つにまとめるには、 基本的に二つ方法があります。
典型的な Beowulf は、高速なイーサネットを使って接続された単一 CPU マシンの集合ですから、ローカルメモリマシンです。 4 CPU の SMP ボックスは共有メモリマシンで、並列計算に使えます - 並列アプリケ−ションは共有メモリを使って通信します。 ちょうど、コンピュ−タの店の比喩で、ロ−カルメモリマシン （個々のキャッシュレジスタ）は多数の CPU にまで規模拡大が可能な一方で は、 メモリ取り合いのために共有メモリマシンの CPU 数（一個所に設置できるキャッシュレジスタの数） に制約が生じるかもしれない、というのと同じです。
しかし、多数の共有メモリマシンを接続して「ハイブリッド」 共有メモリマシンを作成できます。このようなハイブリッドマシンは、 ユーザにとっては単一の大きな SMP マシンのように「見え」、 プログラマから見えて全ての CPU が共有するグローバルメモリは 異なるレーテンシを持ちうることから、 NUMA（一様ではないメモリアクセス non uniform memory access ）と しばしば呼ばれます。しかし、幾つかのレベルでは、 NUMA マシンはローカル共有メモリのプールの相互間で 「メッセージのパス」をしなければなりません。
ローカルメモリ計算ノードとして SMP マシンを接続するのも可能です。 典型的なクラス I マザーボードは 2 個か 4 個の CPU を持ち、 しばしばシステムコスト全体を下げる方法として使われます。 Linux 内部のスケジューラはこれらの CPU を共有させる方法を判断します。 ユーザは特定の SMP プロセッサに（この点では）特定のタスクを 割り当てることはできません。しかし、ユーザは二つの独立した プロセスとかスレッド化されたプロセスをスタートさせて、 単一 CPU マシンよりも性能向上を見るように期待できます。
基本的に、一つのプログラム中での平行性を「表現する」のに 二つの方法があります。
その他の方法も間違いなく存在しますが、これらは最も広く使われる 二つの方法です。平行性の表現は、想定する ハードウェアに必ずしも左右されません、このことを忘れないように するのが大事です。メッセージもスレッドもともに、 SMP でも、 NUMA-SMP でもクラスタでも実装できます、ただし、以下に説明するように、 効率性と可搬性が大事な事柄です。
歴史的に、メッセージパッシング技術は、 初期のローカルメモリ並列コンピュータの設計を反映しました。 メッセージはデータをコピーする必要がありますが、 スレッドはデータを適宜使います。コピー可能なメッセージでの レーテンシと速度は、メッセージパッシングモデルでの制約要素です。 メッセージは十分単純です - 何かのデータと送り先のプロセッサです。 共通のメッセージパッシング API は PVM か MPI にあります。メッセージパッシングはスレッドを用いて効率的に実装可能で、 SMP マシン上でもクラスタのマシン間でもうまく働きます。スレッドと比べて、 SMP マシン上でメッセージを使う利点は、 あなたが将来クラスタを使う決心をしたとしても、 マシンの追加とかあなたのアプリケーションの規模拡大が容易だということで す。
共有メモリ SMP （対称マルチプロセッシング）が設計されたので、 一つのプログラム中での並行部分の相互で、 非常に高速の共有メモリ通信と同期が可能となりました、そのために、 オペレーティングシステムのスレッドは開発されました。 通信は共有メモリを介するので、 SMP システム上のスレッドはうまく働きます。この理由により、 ユーザはローカルデータをグローバルデータから隔離しなければなりません、 さもなければ、プログラムは適正に働かないでしょう。 メッセージと対比して、スレッドでは大量のコピーが省略できます、 そのデータはプロセス（スレッド）間で共有されるからです。 Linux は POSIX スレッドをサポートします。スレッドでの問題は、 一つの SMP マシンを超えてのスレッドの拡張が難しいことです、また、 データが CPU の間で共有されますから、 キャッシュの首尾一貫性の問題がオーバヘッドになるかもしれません。 SMP の境界を超えてのスレッドの拡張を効率的に行うには、 Linux でネイティブにサポートされていない高価な NUMA 技術を必要とします。 メッセージの上へのスレッド実装は既に行われていますが （ (http://syntron.com/ptools/ptools_pg.htm) 訳注：訳者はここはアクセスできませんでした） 、メッセージを使ってのスレッドの実装は非効率的なことが多いです。
性能について、以下のことが言えます。
SMP マシン マシンのクラスタ 拡張可能性
性能 性能 （ scalability ）
----------- ------------------- -----------
メッセージ 良好 最高 最高
スレッド 最高 貧弱 ＊ 貧弱 ＊
＊ 高価な NUMA 技術が必要
複数 CPU 上で並列にアプリケーションを走らせるためには、 アプリケーションを並行部分に明確に分割しなければなりません。 標準的な単一 CPU アプリケーションは、 複数プロセッサ上で単一 CPU アプリケーションよりも早く走ることはありません。 プログラムを分割できるツールとコンパイラは幾つかありますが、 コードを並列化するのは「プラグアンドプレイ」操作ではありません。 そのアプリケーションに依存して、コードの並列化は簡単にもなれば、 極端に難しくもなり、 アルゴリズムの依存性のために不可能になる場合もあるかもしれません。
ソフトウェアの事柄を述べる前に、適合性 (Suitability) の考え方を導入する必要があります。
並列計算についての殆どの疑問は同じ答えになります。
「それはアプリケーションに全て依存します。」
この事柄に飛び込む前に、一つとても大事な区別をしておく 必要があります - 並行 (CONCURRENT) と 並列 (PARALLELL) の違いです。 議論を進めるために、この二つの概念を次のように定義しましょう。
並行 (CONCURRENT) 一つのプログラムで、独立して計算可能な部分
並列 (PARALLELL) 一つのプログラムで、同時に別個の処理要素上で 実行される並行部分
この区別は非常に重要です、なぜなら、平行性 はそのプログラムの属性であり、効率的な並列性 はそのマシンの属性だからです。理想的には、並列 実行はより高速の性能を生むはずです。 並列性能を制約する要素は計算ノード間の通信速度とレーテンシです。 （レーテンシは、スレッド化された SMP アプリケーションにも、 キャッシュの一貫性のために存在します。） よくある並列ベンチマークの多くは、高度に並列で、 通信とレーテンシはボトルネックではありません。このタイプの問題は 「明らかに並列」と呼ぶことができます。 これ以外のアプリケーションはそれ程単純ではなく、そのプログラムの 並行部分を並列に実行すると、 実際には低速に走らせることになってしまい、 そのためにプログラム中の他の 並行部分での性能向上を相殺してしまうかもしれません。 簡単に言うと、計算時間節約のために通信時間の費用を支払わねばなりません、 さもなければ並行部分の並列 実行は非効率的になります。
プログラマの仕事は、そのプログラムのどの並行部分が 並列に実行されるべきで、どの部分が実行される べきでないかを判断することです。 これの解答はアプリケーションの 効率性を決定付けるでしょう。 以下のグラフはそのプログラマの立場をまとめています。
アプリケ | * ーション | * の％ | * | * | * | * | * | * | * | * | * | **** | **** | ******************** +----------------------------------- 通信時間 / 処理時間
完全な並列コンピュータでは、通信/処理の比率は等しくなるでしょうし、 並行部分は全て並列で実装できるでしょう。 残念ながら、共有メモリマシンを含む現実の並列コンピュータは、 このグラフで描かれた影響を受けます。 Beowulf を設計する時には、 ユーザがこのグラフを心がけておくようにしましょう、 何故なら、並列の効率は特定の並列コンピュータ の通信時間と処理時間の比率に依存するからです。 アプリケーションは並列コンピュータの相互で可搬かもしれませんが、 異なるプラットフォームの上で効率的である保証はありません。
一般的に、可搬でかつ効率的な並列プログラムは存在しません
もう一つの結論が上記のグラフから出て来ます。 効率は通信/処理比に依存しますから、この比率の一方だけを変えても、 必ずしも特定のアプリケーションを高速化するとは限らないことです。 通信速度を変えないでおいてプロセッサ速度を変えると、 あなたのプログラムで直感的には分からない影響を及ぼすかもしれません。 例えば、 CPU 速度を 2 、 3 倍にして、通信速度を同じにしましょう。 今度は、以前にあなたのプログラム中で効率的だった 並列的 部分が、逐次的に実行した方が効率的になるかもしれません。 これは、以前は並列的だった部分を、 今度は、逐次的に走らせた方が、 もっと高速になるかもしれないということです。更に、 並列に走らせれば非効率的な部分が、 そのアプリケーションの最大速度の達成を実際には邪魔してしまうでしょう。 従って、より高速のプロセッサの追加によって、 実際にはあなたのアプリケーションを低速化させてしまうかもしれないのです （あなたはそのアプリケーションで新 CPU が最大速度で走るのを邪魔するのです）。
より高速な CPU へのアップグレードが実際には あなたのアプリケーションを低速化させるかもしれない。
それで、結論として、 あなたが並列ハードウェア環境を使えるか否かを知るには、 あなたのアプリケーションが特定のマシンに適合するかどうかを、 見抜く必要があります。あなたは、 CPU 速度とか、コンパイラ、 メッセージパッシング API 、 ネットワークなどを含む多数の事柄を調べる必要があります。 気を付けることは、あるアプリケーションのプロファイルを作成するだけでは、 全体は分からないことです。 あなたはあなたのプログラムの計算量的に重たい部分を特定できるでしょうが、 その部分の通信コストは分かりません。ある与えられたシステムにおいては、 通信コストのおかげで、そのコードを並列的にしない方が効率的になる、 ということが有り得ます。
よくある誤解についての最後の注意です。「あるプログラムが並列化 された」と言われるのが、実際には、そのプログラムの 並行部分の場所が分かったに過ぎないことが多いのです。 今までに述べた全ての理由のせいで、そのプログラムは並列化 されたのではありません。効率的な並列化 はそのマシンの属性なのです。
一旦、あなたが並列計算が必要だと決心し、 Beowulf を設計して構築しようとするなら、ここまでの議論に照らして、 あなたのアプリケーションをちょっとした時間をかけて検討するのは良い考えで す。
一般的にあなたができることは二つあります。
いずれの場合でも、あなたは効率性の事柄について、 いくつかを調べる必要があるでしょう。一般的には、 あなたは 3 つ行う必要があります。
この３つをちょっと調べてみましょう。
このステップはしばしば「あなたのプログラムを並列化すること」、 と考えられています。並列化の決定は第二ステップで行われます。 本ステップではデータ依存性を判断する必要があります。
実用的見地から、アプリケーションは二つのタイプの平行性を示すでしょう - 計算（大量データ処理 number crunching ）と入出力（データベース）です。 しかし、多くの場合、計算と入出力の二つの平行性は直交します、 両方が必要なアプリケーションが存在します。 既存のアプリケーションの平行性分析を行えるツールが入手できます。 これらのツールの殆どは FORTRAN 用に設計されています。 FORTRAN が使われる理由は二つあります - 歴史的に殆どの大量データ処理（ナンバークランチ）のアプリケーションが FORTRAN で書かれていること、そして、分析がより容易なことです。 どのツールも入手できなければ、 既存のアプリケーションに対するこのステップは、 やや困難になるかもしれません。
ツールの助けがなければ、本ステップには、試行錯誤とか、 豊富な経験から割り出した推測が必要かもしれません。 あなたが特定のアプリケーションを念頭に置いているのなら、 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 の部分に分割して、 あなたのデータ転送が各部分ごとに数秒必要だとすれば、 ぎりぎりになりかけている、ということです。 あなたは収穫が減少するポイントに達するでしょう。
あなたのプログラムの並行部分を記述する方法は幾つかあります。
この二つの主な違いは、明示的並列化はユーザが判断し、 暗黙的並列実行はコンパイラが判断することです。
明示的方法では基本的に、ユーザがソースコードを、 並列コンピュータ専用に修正しなければなりません。 ユーザは PVM か MPI を用いてメッセージを追加するか、あるいは、 POSIX スレッドを用いてスレッドを追加するかしなければなりません （しかし、留意することは、スレッドは SMP マザーボード間を移動できないことです）。
明示的方法は実装とデバッグが最も困難になりがちです。 ユーザは典型的には、標準 FORTRAN 77 とか C/C++ ソースコード中に明示的関数呼び出しを埋め込みます。 この MPI ライブラリには、 幾つかの標準的並列手法を実装しやすくする関数を幾つか追加しています （例えば、scatter/gather 関数）。 それに加えて、並列コンピュータ用に書かれてきた標準ライブラリも使えます。 （しかし、留意するのは、可搬性 vs. 効率性 のトレードオフです。）
歴史的理由から、殆どの大量データ処理（ナンバークランチ）のコードは、 FORTRAN で書かれています。このため、並列計算では、 FORTRAN にはサポート（ツール、ライブラリ、その他）が一番多くあります。 今では、Ｃではもっと高速実行できると考えて、 多くのプログラマがＣを使ったり、既存の FORTRAN のアプリケーションをＣに書き直したりします。 Ｃは汎用マシンコードに最も近いものですから、これは真かもしれませんが、 幾つか大きな欠点があります。 Ｃでのポインタ使用はデータ依存性の判定を極端に難しくします。 ポインタの自動分析は極端に困難です。あなたが既存の FORTRAN プログラムを持っていて、 将来的にそれを並列化させたくなるかもしれないと考えているなら - それをＣに変換してはいけません。
暗黙的方法は、並列化の決定の幾つか（または全て） をコンパイラにまかせるようなものです。例は、 FORTRAN 90 と、 High Performance FORTRAN (HPF) 、 Bulk Synchronous Parallel (BSP) 、 そして、開発中のその他の方法、全てです。
暗黙的方法は、ユーザのアプリケーションの並行的性質に ついて何らかの情報をユーザが与える必要がありますが、 そうすれば、この並行的部分を並列に実行する方法について、 コンパイラが多くの決定を行います。 これらの方法はあるレベルの可搬性と効率性をもたらしますが、 それでも並列コンピュータのために並行問題を記述する 「最善の方法」は存在しません。