<!doctype linuxdoctr system>

<article>
<title>Beowulf HOWTO


<author>Jacek Radajewski and Douglas Eadline

<date>v1.1.1, 22 November 1998
<trans>Hisakuni NOGAMI  <htmlurl name="hisakuni@iterlink.or.jp"
url="mailto:hisakuni@interlink.or.jp"></trans>
<tdate> 1999 年 9 月 20 日 </tdate>

<abstract>
<!--This document introduces the Beowulf Supercomputer architecture and
provides background information on parallel programming, including
links to other more specific documents, and web pages.
-->
本文書では Beowulf スーパーコンピュータアーキテクチャを紹介し、
並列プログラミングの背景知識を提供します。
もっと詳細な文書やウェブページへのリンクもあります。
</abstract>

<toc>

<sect><!--Preamble-->前書き

<sect1><!--Disclaimer-->免責
<p>
We will not accept any responsibility for any incorrect information
within this document, nor for any damage it might cause when applied.
<p>（免責の仮訳： 私たちは、本文書中のどんな不正確な情報にも、
使った結果のどんな損害にも、何の責任も負いません。）
<sect1><!--Copyright-->著作権
<p>
Copyright &copy 1997 - 1998 Jacek Radajewski and Douglas Eadline.
Permission to distribute and modify this document is granted under the
GNU General Public Licence.
<p>
（著作権の仮訳：
Copyright &copy 1997 - 1998 Jacek Radajewski and Douglas Eadline.
本文書の配布と改変は GNU General Public Licence に従って許可します。）

<sect1><!--About this HOWTO
-->
この HOWTO について
<p>
<!--Jacek Radajewski started work on this document in November 1997 and
was soon joined by Douglas Eadline.  Over a few months the Beowulf
HOWTO grew into a large document, and in August 1998 it was split into
three documents: Beowulf HOWTO, Beowulf Architecture Design HOWTO, and
the Beowulf Installation and Administration HOWTO.  Version 1.0.0 of
the Beowulf HOWTO was released to the Linux Documentation Project on
11 November 1998.  We hope that this is only the beginning of what
will become a complete Beowulf Documentation Project.
-->
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
となる手始めにすぎないと思っています。


<sect1><!--About the authors-->著者について
<p>
<itemize>

<item><!--Jacek Radajewski works as a Network Manager, and is studying
for
an honors degree in computer science at the University of Southern
Queensland, Australia.  Jacek's first contact with Linux was in 1995
and it was love at first sight.  Jacek built his first Beowulf cluster
in May 1997 and has been playing with the technology ever since,
always trying to find new and better ways of setting things up.  You
can contact Jacek by sending e-mail to <htmlurl
name="jacek@usq.edu.au" url="mailto:jacek@usq.edu.au">
-->
Jacek Radajewski は Network Manager として働いています、また、
University of Southern Queensland, Australia の computer science で
honors degree のために勉強しています。 Jacek の最初の Linux との出会いは
1995 年で、一目ぼれでした。 Jacek は最初の Beowulf クラスタを
1997 年 5 月に構築し、それ以来この技術で遊んでおり、
新しくて良いセットアップ方法をいつも試しています。 Jacek には <htmlurl
name="jacek@usq.edu.au" url="mailto:jacek@usq.edu.au">
への電子メールで連絡できます。

<item><!--Douglas Eadline, Ph.D. is President and Principal Scientist at
Paralogic, Inc., Bethlehem, PA, USA.  Trained as Physical/Analytical
Chemist, he has been involved with computers since 1978 when he built
his first single board computer for use with chemical instrumentation.
Dr. Eadline's interests now include Linux, Beowulf clusters, and
parallel algorithms.  Dr. Eadline can be contacted by sending
email to <htmlurl name="deadline@plogic.com"
url="mailto:deadline@plogic.com">
-->
Douglas Eadline, Ph.D. は Paralogic, Inc., Bethlehem, PA, USA
の社長兼主任科学者です。物理/分析的化学の訓練を受け、
化学機具で使うためのシングルボードコンピュータを初めて
1978 年に構築して以来、コンピュータに関わってきました。
Dr. Eadline が今興味を持つものには、 Linux と、 Beowulf
クラスタ、並列アルゴリズムが入っています。Dr. Eadline には
<htmlurl name="deadline@plogic.com"
url="mailto:deadline@plogic.com"> への電子メールで連絡できます。

</itemize>

<sect1><!--Acknowledgements-->謝辞
<p>
<!--The writing of the Beowulf HOWTO was a long proces and is finally
complete, thanks to many individuals.  I would like to thank the
following people for their help and contribution to this HOWTO.
-->
Beowulf HOWTO を書くのは長い道のりでしたが、ついに完成しました、
多くの方々に感謝します。以下の方々の助力と本 HOWTO
への寄与に感謝したいと思います。
<itemize>

<item><!--Becky for her love, support, and understanding.
-->
Becky には彼女の愛情とサポートと理解に。
<item><!--Tom Sterling, Don Becker, and other people at NASA who started
the Beowulf project.
-->
NASA で Beowulf プロジェクトを開始した Tom Sterling 、
Don Becker 他の人々に。

<item><!--Thanh Tran-Cong and the Faculty of Engineering and Surveying
for making the <it>topcat</it> Beowulf machine available for
experiments.
-->
Thanh Tran-Cong と Faculty of Engineering and Surveying が、実験用に
<it>topcat</it> Beowulf マシンを使えるようにしてくれたことに。

<item><!-- My supervisor Christopher Vance for many great ideas.
-->
私の監督 Christopher Vance の偉大なアイデアに。

<item><!--My friend Russell Waldron for great programming ideas, his
general interest in the project, and support.
-->
私の友人 Russell Waldron の偉大なプログラミングのアイデアと、
本プロジェクトへの全般的な興味とサポートに。

<item><!--My friend David Smith for proof reading this document.
-->
私の友人 David Smith の本文書の査読に。

<item><!--Many other people on the Beowulf mailing list who provided me
with feedback and ideas.
-->
Beowulf メーリングリストの、
その他大勢の方々の私へのフィードバックとアイデアに。

<item><!--All the people who are responsible for the Linux operating
system and all the other free software packages used on
<it>topcat</it> and other Beowulf machines.
-->
Linux オペレーティングシステム、また、 <it>topcat</it> その他の Beowulf 
マシンで使われた、
その他全てのフリーソフトウェアパッケージに責任を持つ全ての人々に。

<item>
（訳注：日本語訳については、武井 伸光さん、後藤 正徳さん他のＪＦ
の皆さんのご指摘を頂き、感謝しております。）

</itemize>

<sect><!--Introduction
-->
はじめに
<p>

<!--As the performance of commodity computer and network hardware
increase, and their prices decrease, it becomes more and more
practical to build parallel computational systems from off-the-shelf
components, rather than buying CPU time on very expensive
Supercomputers.  In fact, the price per performance ratio of a Beowulf
type machine is between three to ten times better than that for
traditional supercomputers.  Beowulf architecture scales well, it is
easy to construct and you only pay for the hardware as most of the
software is free.
-->
日用品のコンピュータとかネットワークハードウェアの性能が向上し、
安価になるにつれて、非常に高価なスーパーコンピュータの CPU
時間を買うよりも、簡単に入手できる部品で並列計算システムを構築するのが
ますます実用的になってきています。実際に、 Beowulf
タイプのマシンの価格性能比は、伝統的なスーパーコンピュータよりも
3 倍から 10 倍良好です。 Beowulf アーキテクチャはうまく規模拡大可能で、
構築が容易ですし、殆どのソフトウェアは無料なので、
ハードウェアを買うだけですみます。

<sect1><!--Who should read this HOWTO ?
-->
この HOWTO を誰が読むべきか？
<p>
<!--This HOWTO is designed for a person with at least some exposure to
the
Linux operating system.  Knowledge of Beowulf technology or
understanding of more complex operating system and networking
concepts is not essential, but some exposure to parallel computing
would be advantageous (after all you must have some reason to read
this document).  This HOWTO will not answer all possible questions you
might have about Beowulf, but hopefully will give you ideas and guide
you in the right direction.  The purpose of this HOWTO is to provide
background information, links and references to more advanced
documents.
-->
この HOWTO は、少なくとも Linux オペレーティングシステム
で何かの経験を持つ人の為に書かれています。 Beowulf 技術の知識とか、
もっと複雑なオペレーティングシステムとかネットワーク概念の理解は、
不可欠ではありません。でも、並列計算の何がしかの経験があれば有利です
（結局のところ、あなたは本文書を読むべき理由がきっとあるはずです）。
この HOWTO は、 Beowulf についての疑問全部には答えないでしょうが、
あなたにアイデアを示し、
あなたが正しい方向に向かえる道標になることでしょう。
本 HOWTO の目的は、背景情報と、
更に進んだ文書へのリンクと参考文献を提供することです。

<sect1><!--What is a Beowulf ?
-->
Beowulf って何？
<p>
<!--<it>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 an earl have honor in every clan.</it> Beowulf is
the earliest surviving epic poem written in English.  It is a story
about a hero of great strength and courage who defeted a monster
called Grendel.  See <ref id="history" name="History"> to find out
more about the Beowulf hero.
-->
<it>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.</it>
<p>（訳注：この韻文の和訳は以下のとおりです。これは、
「中世イギリス英雄叙事詞 ベーオウルフ」忍足欣四郎訳
岩波文庫からの抜粋ですが、一部漢字は引用の都合で違ってしまいました。）
<p>
シェルドの御子ベーオウルフは、
声望あまねく広まり、シェデランドにて
その名は隠れなきものであった。
王子たる者、かくのごとく、父君の庇護の下にある時より、
すべからく徳を施し、惜しみなく財宝をわかち与うるべきである。
さすれば、やがて年老いたる後、いざ合戦の時いたるや、
忠義なる郎党は、王を助けつかまつるであろう。
いかなる民にあっても、人は名誉ある
行いをもって栄えるものである。
<p>
（訳注：
この詞は、古代英詞 ベオウルフの 17 行目から 25 行目までの現代英語訳
であろうと思わますが、「古代英詞 ベオウルフ」鈴木重威編研究社刊の
p68 によれば、この部分の Beowulf は詞の主人公の Beowulf と同名の別の王
だ、
としています。しかし、特に本文書のテーマに関係はしません。）
<p>
Beowulf は英語で書かれた最古の叙事詩です。この話は、 Grendal
と呼ばれた怪物を倒した、偉大な強さと勇気を持った英雄の物語です。この英雄
Beowulf を更に知りたければ <ref id="history" name="History"> 
を参照のこと。
<p>
<!--There are probably as many Beowulf definitions as there are people
who
build or use Beowulf Supercomputer facilities.  Some claim that one
can call their system Beowulf only if it is built in the same way as
the NASA's original machine.  Others go to the other extreme and call
Beowulf any system of workstations running parallel code.  My
definition of Beowulf fits somewhere between the two views described
above, and is based on many postings to the Beowulf mailing list:
-->
多分、 Beowulf の定義の数は、
Beowulf スーパーコンピュータ設備を構築したり使った人の数だけあります。
NASA の元祖のマシンと同じ方法で構築されたものだけが Beowulf と呼べる、
と主張する人もいます。その他にも、もう一方の極端に走って、
ワークステーションのシステムで並列コードを走らせているもの全てを
Beowulf と呼ぶ人もいます。私の Beowulf
の定義はこの二つの中間のどこかにありまして、
Beowulf メーリングリストへの多数の投稿に基づくものです。
<p>
<!--Beowulf is a multi computer architecture which can be used for
parallel computations.  It is a system which usually consists of one
server node, and one or more client nodes connected together via
Ethernet or some other network.  It is a system built using commodity
hardware components, like any PC capable of running Linux, standard
Ethernet adapters, and switches.  It does not contain any custom
hardware components and is trivially reproducible.  Beowulf also uses
commodity software like the Linux operating system, Parallel Virtual
Machine (PVM) and Message Passing Interface (MPI).  The server node
controls the whole cluster and serves files to the client nodes.  It
is also the cluster's console and gateway to the outside world.  Large
Beowulf machines might have more than one server node, and possibly
other nodes dedicated to particular tasks, for example consoles or
monitoring stations.  In most cases client nodes in a Beowulf system
are dumb, the dumber the better.  Nodes are configured and controlled
by the server node, and do only what they are told to do.  In a
disk-less client configuration, client nodes don't even know their IP
address or name until the server tells them what it is.  One of the
main differences between Beowulf and a Cluster of Workstations (COW)
is the fact that Beowulf behaves more like a single machine rather
than many workstations.  In most cases client nodes do not have
keyboards or monitors, and are accessed only via remote login or
possibly serial terminal.  Beowulf nodes can be thought of as a CPU +
memory package which can be plugged in to the cluster, just like a CPU
or memory module can be plugged into a motherboard.
-->
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 ＋ メモリのパッケージと考えられます。
<p>
<!-- Beowulf is not a special software package, new network topology or
the latest kernel hack.  Beowulf is a technology of clustering Linux
computers to form a parallel, virtual supercomputer.  Although there
are many software packages such as kernel modifications, PVM and MPI
libraries, and configuration tools which make the Beowulf architecture
faster, easier to configure, and much more usable, one can build a
Beowulf class machine using standard Linux distribution without any
additional software.  If you have two networked Linux computers which
share at least the <tt>/home</tt> file system via NFS, and trust each
other to execute remote shells (rsh), then it could be argued that you
have a simple, two node Beowulf machine.
-->
Beowulf は、特別なソフトウェアパッケージでも、
新規ネットワークトポロジでも、最新のカーネルハックでもありません。
Beowulf は、複数の Linux コンピュータをクラスタ化して、
並列仮想スーパーコンピュータを形成する技術です。
Beowulf アーキテクチャをもっと高速に、設定をもっと簡単に、
もっと使い易くする、カーネル修正とか、PVM と MPI ライブラリ、
設定ツール等のソフトウェアパッケージは多数あります。
しかし、標準的な Linuxディストリビューションを使って、
何のソフトウェアも追加しないで Beowulf
クラスのマシンを構築できます。あなたがネットワーク化された Linux
コンピュータを 2 台持っていて、少なくとも NFS を介して <tt>/home</tt>
を共有しており、お互い信用できてリモートシェル (rsh) を実行するのなら、
あなたは単純な 2 ノードの Beowulf マシンを持っている、
と論じられるでしょう。

<sect1><!--Classification
-->
分類
<p>
<!--Beowulf systems have been constructed from a variety of parts.  For
the sake 
of performance some non-commodity components (i.e. produced by a single 
manufacturer) have been employed.   In order to account for the
different 
types of systems and to make discussions about machines a bit easier, we 
propose the following simple classification scheme:
-->
Beowulf システムは多様な部品で構築されてきました。
性能のために、ありきたりでない部品（つまり、単一の製造業者の製品）
いくつかも採用されてきました。
システムのタイプが何通りかを数え上げるためと、
マシンの議論を少しは簡単にするために、
私たちは次の単純なクラス分けの枠組みを提案します。
<p>
<!--CLASS I BEOWULF:
-->
CLASS I BEOWULF
<p>
<!--This class of machines built entirely from commodity "off-the-shelf"
parts.  
We shall use the "Computer Shopper" certification test to define
commodity 
"off-the-shelf" parts.  (Computer Shopper is a 1 inch thick monthly 
magazine/catalog of PC systems and components.) The test is as follows:
-->
このクラスのマシンは、完全にありきたりの「簡単に入手できる」
パーツを使って全部が構築されます。ありきたりの
「簡単に入手できる」パーツを定義するのに、「 Computer Shopper 」
検証テストを使うことにしましょう（ Computer Shopper は PC
システムとか部品の、 1 インチ厚の月刊雑誌/カタログです）。
このテストは次のようなものです。

<!--   A CLASS I Beowulf is a machine that can be assembled
   from parts found in at least 3 nationally/globally circulated
   advertising catalogs.  
-->
CLASS I Beowulf とは、少なくとも 3 つの国で入手できるか、
世界的に入手できる、
というのに丸が付けられた広告カタログで見付かるパーツで
組み立てられるマシンである。

<!--The advantages of a CLASS I system are:
-->
CLASS I システムの利点は
<itemize>
<item><!-- hardware is available form multiple sources (low prices, easy
maintenance)
-->
ハードウェアが複数の提供元から入手可能（低価格、容易な保守）
<item><!-- no reliance on a single hardware vendor
-->
単一のハードウェアベンダへの依存なし
<item><!-- driver support from Linux commodity
-->
Linux コミュニティからのドライバサポート
<item><!-- usually based on standards (SCSI, Ethernet, etc.)
-->
普通は標準準拠（ SCSI、イーサネット 等々）
</itemize>

<!--The disadvantages of a CLASS I system are:
-->
CLASS I システムの欠点は
<itemize>
<item><!--best performance may require CLASS II hardware
-->
最高性能には CLASS II のハードウェアが必要かもしれない
</itemize>
<p>
CLASS II BEOWULF
<p>
<!--A CLASS II Beowulf is simply any machine that does not pass the
Computer 
Shopper certification test.  This is not a bad thing.  Indeed, it is
merely a 
classification of the machine.
-->
CLASS II Beowulf は単純に、 Computer Shopper
検証テストをパスしないマシン全てです。
これは悪いことではありません。全くこれはマシンの分類にすぎません。

<!--The advantages of a CLASS II system are:
-->
CLASS II システムの利点は
<itemize>
<item><!-- Performance can be quite good!
-->
性能が結構良好になれる！
</itemize>

<!--The disadvantages of a CLASS II system are:
-->
CLASS II システムの欠点は
<itemize>
<item><!-- driver support may vary
-->
ドライバサポートが変わるかもしれない
<item><!-- reliance on single hardware vendor
-->
単一のハードウェアベンダへの依存
<item><!-- may be more expensive than CLASS I systems.
-->
CLASS I システムよりも高価になるかもしれない
</itemize>

<!--One CLASS is not necessarily better than the other.  It all depends
on your 
needs and budget.  This classification system is only intended to make 
discussions about Beowulf systems a bit more succinct.  The "System
Design" 
section may help determine what kind of system is best suited for your
needs.
-->
一つのクラスが他方のクラスより良好だとは限りません。
全てはあなたのニーズと予算に依存することです。システムをこう分類するの
は、
Beowulf システムについての議論を若干実りあるものにさせるためにすぎませ
ん。
「システム設計」の節は、
どの種類のシステムがあなたのニーズに一番合うかを判断するのに役立つでしょ
う。


<sect><!--Architecture Overview
-->アーキテクチャ概要
<p>

<sect1><!--What does it look like ?
-->
これは、どんな風に見えますか？
<p>
<!--I think that the best way of describing the Beowulf supercomputer
architecture is to use an example which is very similar to the actual
Beowulf, but familiar to most system administrators.  The example that
is closest to a Beowulf machine is a Unix computer laboratory with a
server and a number of clients.  To be more specific I'll use the DEC
Alpha undergraduate computer laboratory at the Faculty of Sciences,
USQ as the example.  The server computer is called <it>beldin</it> and
the client machines are called <it>scilab01</it>, <it>scilab02</it>,
<it>scilab03</it>, up to <it>scilab20</it>.  All clients have
a local copy of the Digital Unix 4.0 operating system installed, but
get the user file space (<tt>/home</tt>) and <tt>/usr/local</tt> from
the server via NFS (Network File System).  Each client has an entry
for the server and all the other clients in its
<tt>/etc/hosts.equiv</tt> file, so all clients can execute a remote
shell (rsh) to all others.  The server machine is a NIS server for the
whole laboratory, so account information is the same across all the
machines.  A person can sit at the <it>scilab02</it> console,
login, and have the same environment as if he logged onto the server
or <it>scilab15</it>.  The reason all the clients have the same look
and feel is that the operating system is installed and configured
in the same way on all machines, and both the user's <tt>/home</tt>
and <tt>/usr/local</tt> areas are physically on the server and
accessed by the clients via NFS.  For more information on NIS and NFS
please read the <htmlurl name="NIS"
url="http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html"> and <htmlurl
name="NFS" url="http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html">
HOWTOs.
-->
Beowulf スーパーコンピュータアーキテクチャを分かってもらうには、
実際の Beowulf と非常に似ていて、殆どのシステム管理者に身近な、
例示を使うのが一番だと私は思います。
Beowulf マシンに一番近い例は、一つのサーバと多数のクライアントがある
Unix コンピュータ実験室です。もっと具体的には、私は DEC
Alpha undergraduate computer laboratory at the Faculty of Sciences,
USQ を例に取りましょう。
このサーバコンピュータは <it>beldin</it> と呼ばれ、
クライアントマシンは、 <it>scilab01</it>、 <it>scilab02</it>、
<it>scilab03</it>から、<it>scilab20</it> までと呼ばれます。
全てのクライアントは Digital Unix 4.0
オペレーティングシステムのローカルコピーを持ち、
インストールされていますが、ユーザのファイル空間
(<tt>/home</tt>) と <tt>/usr/local</tt> はサーバから
NFS (Network File System) で持ってきています。
各クライアントはサーバにエントリを持ち、それぞれの
<tt>/etc/hosts.equiv</tt>
ファイルの中にはその他全てのクライアントが入っています。
ですから、全てのクライアントはその他全てに対してリモートシェル
(rsh) を実行できます。このサーバマシンは実験室全体の
NIS サーバですから、全てのマシンにわたりアカウント情報は同じです。
誰かが <it>scilab02</it> のコンソールに座りログオンすれば、
彼がサーバとか <it>scilab15</it>
にログインしたのと同じ環境を持ちます。
全てのクライアントが同じ使い勝手を持つのは、
このオペレーティングシステムがインストールされて
全マシンで同一の方法で設定されており、ユーザの <tt>/home</tt> と
<tt>/usr/local</tt> 領域が物理的にサーバ上にあり NFS
を介してアクセスされるからです。 NIS と NFS を更に知りたいなら
<htmlurl name="NIS"
url="http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html">
と <htmlurl name="NFS"
url="http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html">
の HOWTO を読んで下さい。


<sect1><!--How to utilise the other nodes ?
-->
その他のノードを使えるようにする方法は？
<p>

<!--Now that we have some idea about the system architecture, let us
take
a look at how we can utilise the available CPU cycles of the machines
in the computer laboratory.  Any person can logon to any of the
machines, and run a program in their home directory, but they can also
spawn the same job on a different machine simply by executing remote
shell.  For example, assume that we want to calculate the sum of the
square roots of all integers between 1 and 10 inclusive. We write a
simple program called <tt>sigmasqrt</tt> (please see <ref
id="sigmasqrt" name="source code">) which does exactly that.  To
calculate the sum of the square roots of numbers from 1 to 10 we
execute :
-->
ここまでで、このシステムのアーキテクチャについて少し分かりました。
このコンピュータ実験室内のマシンの利用可能な CPU サイクルを、
どうやって使えるようにするかを見てみましょう。
誰でも任意のマシンにログインでき、自分のホームディレクトリ中の
プログラムを走らせられますし、
単なるリモートシェルの実行によって別のマシン上で同一のジョブを
spawn もできます。例えば、 1 から 10
までの全ての整数の平方根の合計を計算したいとしましょう。
私たちはそれをきっちり行う <tt>sigmasqrt</tt>
（ <ref id="sigmasqrt" name="source code"> を参照して下さい）
と呼ばれる簡単なプログラムを書きます。
1 から 10 までの数の平方根の合計を計算するには、私たちは次を実行します。
<verb>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278

real    0m0.029s
user    0m0.001s
sys     0m0.024s

</verb>
<!--The <tt>time</tt> command allows us to check the wall-clock (the
elapsed time) of running this job.  As we can see, this example took
only a small fraction of a second (0.029 sec) to execute, but what if
I want to add the square root of integers from 1 to 1 000 000 000 ?
Let us try this, and again calculate the wall-clock time.
-->
この <tt>time</tt> コマンドで、このジョブが走る時間を柱時計
（経過時間）でチェックできます。見ての通り、
この例は実行するのに何十分の 1 秒（ 0.029 秒）しかかかりませんが、
もし私が 1 から 10 億までの整数の平方根を加算したいとすれば
どうでしょうか？
それを試してみましょう、そして再び柱時計の時間を計算しましょう。

<verb>
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000

real    16m45.937s
user    16m43.527s
sys     0m0.108s
</verb>


<!--This time, the execution time of the program is considerably longer.
The obvious question to ask is what can we do to speed up the
execution time of the job?  How can we change the way the job is
running to minimize the wall-clock time of running this job?  The
obvious answer is to split the job into a number of sub-jobs and to
run these sub-jobs in parallel on all computers.  We could split one
big addition task into 20 parts, calculating one range of square roots
and adding them on each node.  When all nodes finish the
calculation and return their results, the 20 numbers could be added
together to obtain the final solution.  Before we run this job we will
make a named pipe which will be used by all processes to write their
results.
-->
今度は、このプログラムの実行時間は相当長いです。
誰でも聞きたくなる疑問は、
このジョブの実行時間を高速化するために何ができるか、です。
このジョブが走る方法をどう変更すれば、
このジョブが走る柱時計の時間を最小にできるでしょうか？ 
誰でも答える解答は、このジョブを多数のサブジョブに分割して、
全てのコンピュータ上で並列にこれらのサブジョブを走らせることです。
私たちは一つの大きな加算タスクを
20 の部分に分割して、各ノードの上で一つの範囲の平方根を計算して合計
できるでしょう。全てのノードが計算を終了して結果を返した時に、
その 20 個の数値は合計されて最終解を得ます。このジョブを走らせる前に、
全てのプロセスが自分の結果を書き込むのに使われることになる
名前付きパイプを作成しましょう。

<verb>
[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
</verb>

<!--This time we get about 58.5 seconds.  This is the time from starting
the job until all the nodes have finished their computations and
written their results into the pipe.  The time does not include the
final addition of the twenty numbers, but this time is a very small
fraction of a second and can be ignored.  We can see that there is a
significant improvement in running this job in parallel.  In fact the
parallel job ran about 17 times faster, which is very reasonable for a
20 fold increase in the number of CPUs.  The purpose of the above
example is to illustrate the simplest method of parallelising
concurrent code.  In practice such simple examples are rare and
different techniques (PVM and PMI APIs) are used to achieve the
parallelism.
-->
今度は約 58.5 秒でした。これはジョブがスタートしてから、全てのノードで
各自の計算が終わり、パイプへ結果を書き込み終わるまでの時間です。
この時間には 20 個の数字を最後に加算するのは含みませんが、
その時間は非常に僅かなので無視できます。
このジョブを並列に走らせて相当の改善を見ることができます。
実際に、並列ジョブは約 17 倍高速に走りました、これは
CPU の数にして全部で 20 倍増やした場合としては、とても合理的です。
この例の目的は、並行コードを並列化する
一番単純な方法を描写することです。実際にはこんな単純な例はまれで、
別の技術（ PVM と PMI の API ）が並列性を達成するのに使われます。
（訳注：並行 concurrent と並列 parallel は混乱しがちです。
並行はスレッドのようにソフトウェア的に動作が並行するもので、
並列は SMP のようにハードウェア的に並列しているもののようです。
これについては<ref id="suitability" name="適合性">の節を参照して下さ
い。）

<sect1><!--How does Beowulf differ from a COW ?
-->
Beowulf と COW （ワークステーションのクラスタ）はどう違うの？
<p>
<!--The computer laboratory described above is a perfect example of a
Cluster of Workstations (COW).  So what is so special about Beowulf,
and how is it different from a COW?  The truth is that there is not
much difference, but Beowulf does have few unique characteristics.
First of all, in most cases client nodes in a Beowulf cluster do not
have keyboards, mice, video cards nor monitors.  All access to the
client nodes is done via remote connections from the server node,
dedicated console node, or a serial console.  Because there is no need
for client nodes to access machines outside the cluster, nor for
machines outside the cluster to access client nodes directly, it
is a common practice for the client nodes to use private IP addresses
like the 10.0.0.0/8 or 192.168.0.0/16 address ranges (RFC 1918 <htmlurl
name="http://www.alternic.net/rfcs/1900/rfc1918.txt.html"
url="http://www.alternic.net/rfcs/1900/rfc1918.txt.html">).  Usually
the only machine that is also connected to the outside world using a
second network card is the server node.  The most common ways of using
the system is to access the server's console directly, or either
telnet or remote login to the server node from personal workstation.
Once on the server node, users can edit and compile their code, and
also spawn jobs on all nodes in the cluster.  In most cases COWs are
used for parallel computations at night, and over weekends when people
do not actually use the workstations for every day work, thus
utilising idle CPU cycles.  Beowulf on the other hand is a machine
usually dedicated to parallel computing, and optimised for this
purpose.  Beowulf also gives better price/performance ratio as it is
built from off-the-shelf components and runs mainly free software.
Beowulf has also more single system image features which help the
users to see the Beowulf cluster as a single computing workstation.
-->
上記のコンピュータ実験室は完全にワークステーションのクラスタ
(Cluster of Workstations (COW)) の例です。それでは、 Beowulf の
何が特別で、どんなふうに COW と違うのでしょうか？  真実はこうです、
さほどの違いはありません、しかし Beowulf には、数少ないですが独自の
性格が間違いなくあります。まず始めに、 Beowulf クラスタの
クライアントノードは、キーボードも、マウス、ビデオカード、
モニターも持たないのが殆どです。
このクライアントノードへのアクセスにはリモート接続を介して、
サーバノードから、あるいは、専用コンソールノード、
シリアルコンソールから行われます。
クライアントノードからクラスタ外部のマシンにアクセスする必要は
ありませんし、クラスタ外部のマシンからクライアントへ直接アクセス
する必要もありませんから、 10.0.0.0/8 とか 192.168.0.0/16 のアドレス範囲
（ RFC 1918 <htmlurl
name="http://www.alternic.net/rfcs/1900/rfc1918.txt.html"
url="http://www.alternic.net/rfcs/1900/rfc1918.txt.html"> 
訳注：原著のアドレスは訳者はアクセスできず、 
<htmlurl name="ここ" 
url="http://www.faqs.org/rfcs/rfc1918.html"> 
の方はアクセスできました）等の
プライベートアドレスをクライアントノードに使用するのがよくある習慣です。
二枚目のネットワークカードを使って外部世界にも接続するマシンは
サーバノードだけ、というのはよくあります。
このシステムの使い方で一番よくあるのは、
そのサーバのコンソールに直接アクセスするか、
個人のワークステーションからサーバノードに
telnet かリモートログインするものです。一旦サーバノード上に入れば、
ユーザは自分のコードを編集してコンパイルでき、
クラスタ中の全ノード上でのジョブの spawn もできます。
殆どの場合に、COW では、人々が実際には日常業務に使っていないので
アイドルの CPU サイクルを活用できる、夜間とか週末に、
並列計算用に利用されます。それに対して
Beowulf は普通は並列計算専用のマシンで、その目的に最適化されています。
また Beowulf はすぐに入手できる部品で構築されており、
主にフリーのソフトウェアを走らせますので、
より高い価格性能比を得られます。また、
Beowulf クラスタが単一の計算ワークステーションだ、
とユーザから見えるのに役立つ、単一システムイメージの機能を
Beowulf はより多く持ちます。

<sect><!--System Design
-->
システム設計
<p>
<!--Before you purchase any hardware, it may be a good idea to consider
the design of your system.  There are basically two hardware issues
involved with design of a Beowulf system: the type of nodes or
computers you are going to use; and way you connect the computer
nodes.  There is one software issue that may effect your hardware
decisions; the communication library or API. A more detailed
discussion of hardware and communication software is provided later in
this document.
-->
ハードウェアを購入する前に、
あなたのシステム設計を考察しておく方が良いでしょう。
Beowulf システムの設計で基本的なハードウェア事項は 2 つあります - 
あなたが使おうとするノードとかコンピュータのタイプ、
コンピュータノードに接続する方法です。
ハードウェア選択に影響するかもしれないソフトウェア事項が一つあります - 
通信ライブラリとか API です。ハードウェアと通信ソフトウェアについては、
後程もっと詳細に議論します。
<p>
<!--While the number of choices is not large, there are some important
design decisions that must be made when constructing a Beowulf
systems.  Because the science (or art) of "parallel computing" has
many different interpretations, an introduction is provided below.  If
you do not like to read background material, you may skip this
section, but it is advised that you read section  <ref id="suitability"
name="Suitability"> before you make you final hardware decisions.
-->
選択肢は多くありませんが、
Beowulf システムを構築する上で大事な設計上の決定が幾つかあります。
「並列計算」の科学（または技法）にはたくさんの違う解釈がありますので、
以下に紹介します。
もし背景事項を読むのがお好きでないなら、本節は飛ばせますが、
あなたが最終的なハードウェアを決定する前に <ref id="suitability"
name="適合性">の節を読むよう、アドバイスしておきます。

<sect1><!--A brief background on parallel computing.
-->
並列計算の背景概要
<p>
<!--This section provides background on parallel computing concepts.  It
is NOT an exhaustive or complete description of parallel computing
science and technology. It is a brief description of the issues that
may be important to a Beowulf designer and user.
-->
本節は並列計算という概念の背景を示します。これは決して、
並列計算の科学とか技術の網羅的で完全な説明ではありません。これは
Beowulf の設計者とユーザには大切と思われる事柄の概要を説明したものです。
<p>
<!--As you design and build your Beowulf, many of these issues described
below will become important in your decision process. Due to its
component nature, a Beowulf Supercomputer requires that we consider
many factors carefully because they are now under our control. In
general, it is not all that difficult to understand the issues
involved with parallel computing.  Indeed, once the issues are
understood, your expectations will be more realistic and success will
be more likely. Unlike the "sequential world" where processor speed is
considered the single most important factor, processor speed in the
"parallel world" is just one of several factors that will determine
overall system performance and efficiency.
-->
あなたの Beowulf の設計と構築の際に、以下で説明する事柄の多くは
あなたの決定プロセスで重要になることでしょう。
Beowulf は本質的に私たちが選んで構成するものですから、
Beowulf
スーパーコンピュータの多くの要素を私たちが注意深く考慮する必要がありま
す。
一般的に、並列計算に含まれる事柄を理解するのは決して難しくはありません。
本当に、一旦これらの事柄が理解されれば、
あなたの予想はさらに現実的になり、成功はさらに確実になります。
プロセッサの速度が唯一で最重要の要素と考えられる
「逐次的世界（ sequential world ）」とは違って、
「並列の世界（ parallel world ）」におけるプロセッサの速度は、
システム全体の性能と効率を決定する幾つかの要素の中の一つにすぎません。
<p>

<sect1><!--The methods of parallel computing
-->
並列計算の方式
<p>
<!--Parallel computing can take many forms.  From a user's perspective,
it is 
important to consider the advantages and disadvantages of each
methodology.  
The following section attempts to provide some perspective on the
methods of 
parallel computing and indicate where the Beowulf machine falls on this 
continuum.
-->
並列計算は多くの形態をとれます。ユーザの視点から、
各方式の利点と欠点を考察するのが重要です。
以下の節では、並列計算の方式をどう見るかを幾つか示し、
Beowulf マシンがそれらの中でどれに当たるのかを示すつもりです。
<p>
<sect2><!--Why more than one CPU?
-->
なぜ一つ以上の CPU か？
<p>
<!--Answering this question is important.  Using 8 CPUs to run your word
processor sounds a little like "over-kill" - - and it is.  What about a
web server, a database, a rendering program, or a project scheduler?
Maybe extra CPUs would help.  What about a complex simulation, a fluid
dynamics code, or a data mining application.  Extra CPUs definitely
help in these situations.  Indeed, multiple CPUs are being used to
solve more and more problems.
-->
この質問への解答は重要です。あなたのワードプロセッサで 8 CPU
を走らせるのはちょっと「やりすぎ」のように聞こえるでしょうし、
その通りです。
ではウェブサーバとか、データベース、レンダリングプログラム、
プロジェクトスケジューラならどうでしょうか？ 多分追加の CPU が役立ちま
す。
複雑なシミュレーションとか、流体力学のコード、
データマイニングアプリケーションならどうでしょう？ 
このような状況では追加の CPU が間違いなく役立ちます。本当に、
ますます多くの問題解決に複数の CPU が使われるようになっています。
<p>
<!--The next question usually is: "Why do I need two or four CPUs, I
will
just wait for the 986 turbo-hyper chip." There are several reasons:
-->
その次の質問は多分こうでしょう、
「なぜ 2 つとか 4 つの CPU が私に必要なのですか？ 
私は 986 ターボハイパーチップが出てくるのを待つだけにしたいな」。
これには幾つかの理由があります。
<enum>
<item><!-- Due to the use of multi-tasking Operating Systems, it is
possible to do several things at once.  This is a natural
"parallelism" that is easily exploited by more than one low cost CPU.
-->
マルチタスクのオペレーティングシステムの利用で、
同時に幾つかを実行できます。これは、一つ以上の安価な
CPU によって簡単にできるようになる自然な「並列性」です。

<item><!-- Processor speeds have been doubling every 18 months, but what
about RAM speeds or hard disk speeds? Unfortunately, these speeds are
not increasing as fast as the CPU speeds.  Keep in mind most
applications require "out of cache memory access" and hard disk
access.  Doing things in parallel is one way to get around some of
these limitations.
-->
プロセッサ速度は 18 ヵ月毎に倍増してきていますが、
RAM 速度とかハードディスク速度はどうでしょうか？
残念ながら、これらの速度は
CPU 速度程早くは増加していません。殆どのアプリケーションは
「キャッシュ以外のメモリアクセス」
とハードディスクアクセスが必要だということを念頭に置きましょう。
並列に物事を行うのは、このような制約の幾つかを乗り越える一つの方法です。

<item><!-- Predictions indicate that processor speeds will not continue
to double 
every 18 months after the year 2005. There are some very serious
obstacles to 
overcome in order to maintain this trend.
-->
予想によれば、 2005 年以降は 18 ヵ月毎のプロセッサ速度倍増は続かないでし
ょう。
この増加傾向を維持するために乗り越えなければならない障害には、
非常に深刻なものが幾つかあるのです。

<item><!-- Depending on the application, parallel computing can speed
things up by any 
where from 2 to 500 times faster (in some cases even faster). Such
performance 
is not available using a single processor.  Even supercomputers that at
one 
time used very fast custom processors are now built from multiple
"commodity-
off-the-shelf" CPUs.
-->
アプリケーションによりますが、並列計算で高速化できる度合いは、
2 倍から 500 倍の間のどこか（幾つかの場合には更に高速に）です。
これだけの性能は単一のプロセッサを使うのでは得られません。
スーパコンピュータでさえ、
一時は極めて高速の特注プロセッサを使っていたのが、
今では複数の「ありふれたすぐに入手できる」
CPU で構築されています。
</enum>

<!--If you need speed - either due to a compute bound problem and/or an
I/O bound 
problem, parallel is worth considering.  Because parallel computing is 
implemented in a variety of ways, solving your problem in parallel will 
require some very important decisions to be made.  These decisions may 
dramatically effect portability, performance, and cost of your
application.
-->
あなたが、計算限界問題 および / または 入出力限界問題のために、
速度が必要だとしたら、並列化が検討に値します。
並列計算は多様な方法で実装されますので、
あなたの問題を並列化で解決するには幾つか非常に大事な決定が必要になりま
す。
これらの決定は、あなたのアプリケーションの可搬性と性能と費用に、
劇的に影響するかもしれません。
<p>
<!--Before we get technical, let's look take a look at a real "parallel
computing 
problem" using an example with which we are familiar - waiting in long
lines 
at a store. 
-->
技術的になる前に、店で長い列に並んで待つという、
私たちに身近な問題を例にとって、実際の「並列計算問題」を眺めてみましょ
う。

<sect2><!--The Parallel Computing Store
-->
並列計算のお店
<p>
<!--Consider a big store with 8 cash registers grouped together in the
front of 
the store.  Assume each cash register/cashier is a CPU and each customer
is a 
computer program.  The size of the computer program (amount of work) is
the 
size of each customer's order. The following analogies can be used to 
illustrate parallel computing concepts.
-->
店の正面に 8 つのキャッシュレジスタを一緒に置いている大きな店を考えまし
ょう。
キャッシュレジスタがそれぞれ一つの CPU で、
お客さんがそれぞれ一つのコンピュータプログラムだと想定します。
このコンピュータプログラムのサイズ（業務の量）は、
お客さんそれぞれの注文のサイズです。
以下の比喩は、並列計算の概念を描写するのに使えます。
<p>
<sect3><!--Single-tasking Operating System
-->
シングルタスクのオペレーティングシステム
<p>
<!--One cash register open (is in use) and must process each customer
one at a 
time. 
-->
一つのキャッシュレジスタがオープン（使用可能状態）で、
それぞれのお客さんを一時に一人ずつ処理しなければならない。
<p>
<!--Computer Example: MS DOS
-->
コンピュータの例 - MS DOS
<p>
<sect3><!--Multi-tasking Operating System:
-->
マルチタスクのオペレーティングシステム
<p>
<!--One cash register open, but now we process only a part of each order
at a 
time, move to the next person and process some of their order. Everyone 
"seems" to be moving through the line together, but if no one else is in
the 
line, you will get through the line faster.
-->
一つのキャッシュレジスタがオープンです、しかし、
ここではそれぞれの注文の一部分だけを一時に処理し、
次のお客さんに移ってそちらの注文の幾らかを処理します。
お客は皆その行列で一緒に動いていると「見え」ますが、
その行列に他に誰も居なければその行列をもっと早く通過するでしょう。
<p>
<!--Computer Example: UNIX, NT using a single CPU
-->
コンピュータの例 - 単一の CPU を使う UNIX 、 NT
<p>
<sect3><!--Multitasking Operating Systems with Multiple CPUs:
-->
複数の CPU を使ったマルチタスクのオペレーティングシステム
<p>
<!--Now we open several cash registers in the store. Each order can be 
processed 
by a separate cash register and the line can move much faster.  This is
called 
SMP - Symmetric Multi-processing.  Although there are extra cash
registers 
open, you will still never get through the line any faster than just you
and a 
single cash register.  
-->
今度は、店に幾つかのキャッシュレジスタがオープンしています。
それぞれの注文は別々のキャッシュレジスタで処理できて、
行列はかなり早く通過できます。これは
SMP - Symmetric Multi-processing と呼ばれます。
追加のキャッシュレジスタがオープンしていても、キャッシュレジスタ
が一つでお客があなた一人だけの時よりも早い行列通過は、
決してできません。
<p>
<!--Computer Example: UNIX and NT with multiple CPUs
-->
コンピュータの例 - 複数 CPU の UNIX と NT
<p>

<sect3><!--Threads on a Multitasking Operating Systems extra CPUs
-->
複数の CPU のマルチタスクのオペレーティングシステム上でのスレッド
<p>
<!--If you "break-up" the items in your order, you might be able to move
through 
the line faster by using several cash registers at one time.  First, we
must 
assume you have a large amount of goods, because the time you invest
"breaking 
up your order" must be regained by using multiple cash registers.   In
theory, 
you should be able to move through the line "n" times faster than
before*; 
where "n" is the number of cash registers.  When the cashiers need to
get sub-
totals, they can exchange information quickly by looking and talking to
all 
the other "local" cash registers. They can even snoop around the other
cash 
registers to find information they need to work faster. There is a
limit, 
however, as to how many cash registers the store can effectively locate
in any 
one place.
-->
あなたの注文の品目をあなたが「細分化」すれば、
一時に幾つかのキャッシュレジスタを使うことで、
行列をもっと早く通り抜けられるでしょう。
最初にあなたの品物の分量が大量だと想定しなければなりません、
なぜなら、「あなたの注文の細分化」
での投資が複数のキャッシュレジスタ利用で取り戻さねばならないからです。
理論的には、あなたは以前よりも「 n 」倍早く行列を通過できるはずです、
この「 n 」はキャッシュレジスタの数です。
キャッシュレジスタが小計をとる必要がある時には、
キャッシュレジスタたちは別の「ローカル」
キャッシュレジスタ全てを見たり話したりして即座に情報交換できます。
キャッシュレジスタたちは別のキャッシュレジスタを覗きまわって、
自分がもっと早く仕事するのに必要な情報を見つけたりさえできます。
しかし、制限があります、
その店のどこか一個所でキャッシュレジスタを効率的に設置できる数には、
限りがあります。

<!--Amdals law will also limit the application speed-up to the slowest 
sequential portion of the program. 
-->
また、 Amdals の法則によって、そのアプリケーションの高速化は、
そのプログラムの最低速の逐次的部分に制限されます。

<!--Computer Example: UNIX or NT with extra CPU on the same motherboard
running 
multi-threaded programs.
-->
コンピュータの例 - マルチスレッド化されたプログラムを走らせている、
同一のマザーボード上に複数 CPU を持たせた UNIX か NT

<sect3><!--Sending Messages on Multitasking Operating Systems with extra
CPUs:
-->
複数の CPU を持つマルチタスクのオペレーティングシステム上のメッセージ送
信
<p>
<!--In order to improve performance, the store adds 8 cash registers at
the back 
of the store.  Because the new cash registers are far away from the
front cash 
registers, the cashiers must call on the phone to send their sub-totals
to the 
front of the store. This distance adds extra overhead (time) to
communication 
between cashiers, but if communication is minimized, it is not a
problem.   If 
you have a really big order, one that requires all the cash registers,
then as 
before your speed can be improved by using all cash registers at the
same 
time, the extra overhead must be considered. In some cases, the store
may have 
single cash registers (or islands of cash registers) located all over
the 
store - each cash register (or island) must communicate by phone.  Since
all 
the cashiers working the cash registers can talk to each other by phone,
it 
does not matter too much where they are.  
-->
性能向上のために、この店では店の後ろに
8 つのキャッシュレジスタを追加しました。
この新しいキャッシュレジスタは、
自分の小計を店の正面のキャッシュレジスタに送信するのに、
電話を掛けねばなりません。
この距離はキャッシュレジスタ同士の通信に余分のオーバーヘッド
（時間）を加えますが、もし通信が最小限にされたなら、
それは問題にはなりません。もしあなたが、
全部のキャッシュレジスタを必要とするような、
本当に大きな注文をしたなら、
上記と同様に同時に全てのキャッシュレジスタを使うことで、
速度を改善できます、余分のオーバーヘッドも考慮に入れなければなりません。
ある場合には、この店は単一のキャッシュレジスタ
（またはキャッシュレジスタの島）が店の中全体に散らばっているかもしれず、
それぞれのキャッシュレジスタ（か島）同士が、
電話で通信しなければならないかもしれません、
全てのキャッシュレジスタがお互いに電話で話し合えますから、
その場所の数多さは問題になりません。

<!--Computer Example: One or several copies of UNIX or NT with extra
CPUs on the 
same or different motherboard communicating through messages.
-->
コンピュータの例 - 複数 CPU を同一または複数のマザーボード上に持ち、
メッセージを介して通信する UNIX や NT （等のコピー）


<!--The above scenarios, although not exact, are a good representation
of 
constraints placed on parallel systems.  Unlike a single CPU (or cash 
register) communication is an issue.
-->
ここまでのシナリオは、正確ではなくとも、
並列システムで起きる制約をうまく表現しています。単一の
CPU （つまりキャッシュレジスタ一台）だけとは違って、通信が課題です。

<sect1><!--Architectures for parallel computing
-->
並列計算のアーキテクチャ
<p>
<!--The common methods and architectures of parallel computing are
presented 
below.  While this description is by no means exhaustive, it is enough
to 
understand the basic issues involved with Beowulf design. 
-->
並列計算でよくある手法とアーキテクチャを以下に説明します。
決して網羅的な説明にはなりませんが、
Beowulf 設計に必要な基本的事項を理解するには十分です。

<sect2><!--Hardware Architectures
-->
ハードウェアアーキテクチャ
<p>

<!--There are basically two ways parallel computer hardware is put
together:
-->
並列コンピュータのハードウェアを一つにまとめるには、
基本的に二つ方法があります。

<enum>
<item><!-- Local memory machines that communicate by messages (Beowulf
Clusters)
-->
ローカルメモリマシンでメッセージで通信を行うもの（ Beowulf クラスタ）
<item><!-- Shared memory machines that communicate through memory (SMP
machines)
-->
共有メモリマシンでメモリを介して通信を行うもの（ SMP マシン）
</enum>

<!--A typical Beowulf is a collection of single CPU machines connected
using fast 
Ethernet and is, therefore, a local memory machine.  A 4 way SMP box is
a 
shared memory machine and can be used for parallel computing - parallel 
applications communicate using shared memory.  Just as in the computer
store 
analogy, local memory machines (individual cash registers) can be scaled
up to 
large numbers of CPUs, while the number of CPUs shared memory machines
(the 
number of cash registers you can place in one spot) can have is limited
due to 
memory contention.  
-->
典型的な Beowulf は、高速なイーサネットを使って接続された単一
CPU マシンの集合ですから、ローカルメモリマシンです。
4 CPU の SMP ボックスは共有メモリマシンで、並列計算に使えます - 
並列アプリケ−ションは共有メモリを使って通信します。
ちょうど、コンピュ−タの店の比喩で、ロ−カルメモリマシン
（個々のキャッシュレジスタ）は多数の CPU にまで規模拡大が可能な一方で
は、
メモリ取り合いのために共有メモリマシンの CPU
数（一個所に設置できるキャッシュレジスタの数）
に制約が生じるかもしれない、というのと同じです。

<!--It is possible, however, to connect many shared memory machines to
create a 
"hybrid" shared memory machine.  These hybrid machines "look" like a
single 
large SMP machine to the user and are often called NUMA (non uniform
memory 
access) machines because the global memory seen by the programmer and
shared 
by all the CPUs can have different latencies.  At some level, however, a
NUMA 
machine must "pass messages" between local shared memory pools.
-->
しかし、多数の共有メモリマシンを接続して「ハイブリッド」
共有メモリマシンを作成できます。このようなハイブリッドマシンは、
ユーザにとっては単一の大きな SMP マシンのように「見え」、
プログラマから見えて全ての CPU が共有するグローバルメモリは
異なるレーテンシを持ちうることから、
NUMA（一様ではないメモリアクセス non uniform memory access ）と
しばしば呼ばれます。しかし、幾つかのレベルでは、 NUMA
マシンはローカル共有メモリのプールの相互間で
「メッセージのパス」をしなければなりません。

<!--It is also possible to connect SMP machines as local memory compute
nodes.  
Typical CLASS I motherboards have either 2 or 4 CPUs and are often used
as a 
means to reduce the overall system cost. The Linux internal scheduler 
determines how these CPUs get shared.  The user cannot (at this point)
assign 
a specific task to a specific SMP processor.  The user can however,
start two 
independent processes or a threaded processes and expect to see a
performance 
increase over a single CPU system.
-->
ローカルメモリ計算ノードとして SMP マシンを接続するのも可能です。
典型的なクラス I マザーボードは 2 個か 4 個の CPU を持ち、
しばしばシステムコスト全体を下げる方法として使われます。
Linux 内部のスケジューラはこれらの CPU を共有させる方法を判断します。
ユーザは特定の SMP プロセッサに（この点では）特定のタスクを
割り当てることはできません。しかし、ユーザは二つの独立した
プロセスとかスレッド化されたプロセスをスタートさせて、
単一 CPU マシンよりも性能向上を見るように期待できます。

<sect2><!--Software API Architectures
-->
ソフトウェア API アーキテクチャ
<p>
<!--There basically two ways to "express" concurrency in a program:
-->
基本的に、一つのプログラム中での平行性を「表現する」のに
二つの方法があります。
<enum>
<item><!-- Using Messages sent between processors
-->
プロセッサ間で送信されるメッセージの使用
<item><!-- Using operating system Threads
-->
オペレーティングシステムのスレッドの使用
</enum>
<p>
<!--Other methods do exist, but these are the two most widely used. It
is 
important to remember that the expression of concurrency is not
necessary 
controlled by the underlying hardware.  Both Messages and Threads can be 
implemented on SMP, NUMA-SMP, and clusters - although as explained below 
efficiently and portability are important issues.  
-->
その他の方法も間違いなく存在しますが、これらは最も広く使われる
二つの方法です。平行性の表現は、想定する
ハードウェアに必ずしも左右されません、このことを忘れないように
するのが大事です。メッセージもスレッドもともに、 SMP でも、
NUMA-SMP でもクラスタでも実装できます、ただし、以下に説明するように、
効率性と可搬性が大事な事柄です。
<p>
<sect3><!--Messages
-->
メッセージ
<p>
<!--Historically, messages passing technology reflected the
design of early local memory parallel computers. Messages require
copying data while Threads use data in place.  The latency and speed
at which messages can be copied are the limiting factor with message
passing models. A Message is quite simple: some data and a destination
processor.  Common message passing APIs are <htmlurl
url="http://www.epm.ornl.gov/pvm" name="PVM"> or <htmlurl
url="http://www.mcs.anl.gov/Projects/mpi/index.html" name="MPI">.
Message
passing can be efficiently implemented using Threads and Messages work
well both on SMP machine and between clusters of machines.  The
advantage to using messages on an SMP machine, as opposed to Threads,
is that if you decided to use clusters in the future it is easy to add
machines or scale your application.
-->
歴史的に、メッセージパッシング技術は、
初期のローカルメモリ並列コンピュータの設計を反映しました。
メッセージはデータをコピーする必要がありますが、
スレッドはデータを適宜使います。コピー可能なメッセージでの
レーテンシと速度は、メッセージパッシングモデルでの制約要素です。
メッセージは十分単純です - 何かのデータと送り先のプロセッサです。
共通のメッセージパッシング API は<htmlurl
url="http://www.epm.ornl.gov/pvm" name="PVM"> か <htmlurl
url="http://www.mcs.anl.gov/Projects/mpi/index.html" name="MPI"> 
にあります。メッセージパッシングはスレッドを用いて効率的に実装可能で、
SMP マシン上でもクラスタのマシン間でもうまく働きます。スレッドと比べて、
SMP マシン上でメッセージを使う利点は、
あなたが将来クラスタを使う決心をしたとしても、
マシンの追加とかあなたのアプリケーションの規模拡大が容易だということで
す。 
<p>
<sect3><!--Threads
-->
スレッド
<p>
<!--Operating system Threads were developed because shared memory SMP
(symmetrical multiprocessing) designs allowed very fast shared memory
communication and synchronization between concurrent parts of a
program.  Threads work well on SMP systems because communication is
through shared memory.  For this reason the user must isolate local
data from global data, otherwise programs will not work properly. In
contrast to messages, a large amount of copying can be eliminated with
threads because the data is shared between processes (threads). Linux
supports POSIX threads. The problem with threads is that it is
difficult to extend them beyond one SMP machine and because data is
shared between CPUs, cache coherence issues can contribute to
overhead. Extending threads beyond the SMP boundary efficiently
requires NUMA technology which is expensive and not natively
supported by Linux. Implementing threads on top of messages has been
done (<htmlurl name="(http://syntron.com/ptools/ptools_pg.htm)"
url="http://syntron.com/ptools/ptools_pg.htm">), but Threads are often
inefficient when implemented using messages.
-->
共有メモリ SMP （対称マルチプロセッシング）が設計されたので、
一つのプログラム中での並行部分の相互で、
非常に高速の共有メモリ通信と同期が可能となりました、そのために、
オペレーティングシステムのスレッドは開発されました。
通信は共有メモリを介するので、 SMP
システム上のスレッドはうまく働きます。この理由により、
ユーザはローカルデータをグローバルデータから隔離しなければなりません、
さもなければ、プログラムは適正に働かないでしょう。
メッセージと対比して、スレッドでは大量のコピーが省略できます、
そのデータはプロセス（スレッド）間で共有されるからです。
Linux は POSIX スレッドをサポートします。スレッドでの問題は、
一つの SMP マシンを超えてのスレッドの拡張が難しいことです、また、
データが CPU の間で共有されますから、
キャッシュの首尾一貫性の問題がオーバヘッドになるかもしれません。
SMP の境界を超えてのスレッドの拡張を効率的に行うには、
Linux でネイティブにサポートされていない高価な NUMA 技術を必要とします。
メッセージの上へのスレッド実装は既に行われていますが
（ <htmlurl name="(http://syntron.com/ptools/ptools_pg.htm)"
url="http://syntron.com/ptools/ptools_pg.htm"> 
訳注：訳者はここはアクセスできませんでした）
、メッセージを使ってのスレッドの実装は非効率的なことが多いです。
<p>
<!--The following can be stated about performance:
-->
性能について、以下のことが言えます。
<!--<verb>
          SMP machine     cluster of machines  scalability
          performance        performance
          - - - - - -     - - - - - - - - - -  - - - - - -
messages    good                best              best

threads     best               poor*              poor*

* requires expensive NUMA technology.
</verb>
上記で - の連続は - - に変えています
-->
<verb>
           SMP マシン      マシンのクラスタ      拡張可能性
              性能               性能         （ scalability ）
           -----------     -------------------  -----------
メッセージ   良好                最高              最高

スレッド     最高                貧弱 ＊           貧弱 ＊

＊ 高価な NUMA 技術が必要
</verb>

<sect2><!--Application Architecture
-->
アプリケーションのアーキテクチャ
<p>
<!--In order to run an application in parallel on multiple CPUs, it must
be 
explicitly broken in to concurrent parts.  A standard single CPU
application 
will run no faster than a single CPU application on multiple processors. 
There are some tools and compilers that can break up programs, but 
parallelizing codes is not a "plug and play" operation.  Depending on
the 
application, parallelizing code can be easy, extremely difficult, or in
some 
cases impossible due to algorithm dependencies.  
-->
複数 CPU 上で並列にアプリケーションを走らせるためには、
アプリケーションを並行部分に明確に分割しなければなりません。
標準的な単一 CPU アプリケーションは、
複数プロセッサ上で単一 CPU
アプリケーションよりも早く走ることはありません。
プログラムを分割できるツールとコンパイラは幾つかありますが、
コードを並列化するのは「プラグアンドプレイ」操作ではありません。
そのアプリケーションに依存して、コードの並列化は簡単にもなれば、
極端に難しくもなり、
アルゴリズムの依存性のために不可能になる場合もあるかもしれません。
<p>
<!--Before the software issues can be addressed the concept of
Suitability 
needs to be introduced.
-->
ソフトウェアの事柄を述べる前に、適合性
(Suitability) の考え方を導入する必要があります。

<sect1><!--Suitability<label id="suitability">
-->
適合性 (Suitability)<label id="suitability">
<p>
<!--Most questions about parallel computing have the same answer:
-->
並列計算についての殆どの疑問は同じ答えになります。
<p>
<!--"It all depends upon the application."
-->
「それはアプリケーションに全て依存します。」
<p>
<!--Before we jump into the issues, there is one very important
distinction that 
needs to be made - the difference between CONCURRENT and PARALLEL.  For
the 
sake of this discussion we will define these two concepts as follows:
-->
この事柄に飛び込む前に、一つとても大事な区別をしておく
必要があります - 並行 (CONCURRENT) と 並列 (PARALLELL) の違いです。
議論を進めるために、この二つの概念を次のように定義しましょう。
<p>
<!--CONCURRENT parts of a program are those that can be computed
independently.
-->
並行 (CONCURRENT)  一つのプログラムで、独立して計算可能な部分
<p>
<!--PARALLEL parts of a program are those CONCURRENT parts that are
executed on 
separate processing elements at the same time.
-->
並列 (PARALLELL)   一つのプログラムで、同時に別個の処理要素上で
実行される並行部分
<p>
<!--The distinction is very important, because CONCURRENCY is a property
of the 
program and efficient PARALLELISM is a property of the machine. 
Ideally, 
PARALLEL execution should result in faster performance.  The limiting
factor 
in parallel performance is the communication speed and latency between
compute 
nodes. (Latency also exists with threaded SMP applications due to cache 
coherency.) Many of the common parallel benchmarks are highly parallel
and 
communication and latency are not the bottle neck. This type of problem
can be 
called  "obviously parallel".  Other applications are not so simple and 
executing CONCURRENT parts of the program in PARALLEL may actually cause
the 
program to run slower, thus offsetting any performance gains in other 
CONCURRENT parts of the program.   In simple terms, the cost of
communication 
time must pay for the savings in computation time, otherwise the
PARALLEL 
execution of the CONCURRENT part is inefficient.   
-->
この区別は非常に重要です、なぜなら、<em>平行性</em>
はそのプログラムの属性であり、効率的な<em>並列性</em>
はそのマシンの属性だからです。理想的には、<em>並列</em>
実行はより高速の性能を生むはずです。
並列性能を制約する要素は計算ノード間の通信速度とレーテンシです。
（レーテンシは、スレッド化された SMP アプリケーションにも、
キャッシュの一貫性のために存在します。） 
よくある並列ベンチマークの多くは、高度に並列で、
通信とレーテンシはボトルネックではありません。このタイプの問題は
「明らかに並列」と呼ぶことができます。
これ以外のアプリケーションはそれ程単純ではなく、そのプログラムの
<em>並行</em>部分を<em>並列</em>に実行すると、
実際には低速に走らせることになってしまい、
そのためにプログラム中の他の
<em>並行</em>部分での性能向上を相殺してしまうかもしれません。
簡単に言うと、計算時間節約のために通信時間の費用を支払わねばなりません、
さもなければ<em>並行</em>部分の<em>並列</em>
実行は非効率的になります。
<p>
<!--The task of the programmer is to determining what CONCURRENT parts
of the 
program SHOULD be executed in PARALLEL and what parts SHOULD NOT.  The
answer 
to this will determine the EFFICIENCY of application.  The following
graph 
summarizes the situation for the programmer:
-->
プログラマの仕事は、そのプログラムのどの<em>並行</em>部分が
<em>並列</em>に実行される<em>べき</em>で、どの部分が実行される
<em>べきでない</em>かを判断することです。
これの解答はアプリケーションの
<em>効率性</em>を決定付けるでしょう。
以下のグラフはそのプログラマの立場をまとめています。
<p>
<!--<verb>



         | *
         | *
         | *
 % of    | *
 appli-  |  *
 cations |  *
         |  *
         |  *
         |    *
         |     *
         |      *
         |        ****
         |            ****
         |                ********************
         +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - -
          communication time/processing time
</verb>
訳注：上記で - の連続の所は - - に変えています
-->
<verb>

アプリケ　| *
ーション　| *
の％　　　| *
　　　　　| *
　　　　　|  *
　　　　　|  *
　　　　　|  *
　　　　　|  *
　　　　　|    *
　　　　　|     *
　　　　　|      *
　　　　　|        ****
　　　　　|            ****
　　　　　|                ********************
　　　　　+-----------------------------------
　　　　　        通信時間 / 処理時間
</verb>
<p>
<!--In a perfect parallel computer, the ratio of
communication/processing would be 
equal and anything that is CONCURRENT could be implemented in PARALLEL.  
Unfortunately, Real parallel computers, including shared memory
machines, are 
subject to the effects described in this graph.  When designing a
Beowulf, the 
user may want to keep this graph in mind because parallel efficiency
depends 
upon ratio of communication time and processing time for A SPECIFIC
PARALLEL 
COMPUTER.  Applications may be portable between parallel computers, but
there 
is no guarantee they will be efficient on a different platform.
-->
完全な並列コンピュータでは、通信/処理の比率は等しくなるでしょうし、
<em>並行</em>部分は全て<em>並列</em>で実装できるでしょう。
残念ながら、共有メモリマシンを含む現実の並列コンピュータは、
このグラフで描かれた影響を受けます。
Beowulf を設計する時には、
ユーザがこのグラフを心がけておくようにしましょう、
何故なら、並列の効率は<em>特定の並列コンピュータ</em>
の通信時間と処理時間の比率に依存するからです。
アプリケーションは並列コンピュータの相互で可搬かもしれませんが、
異なるプラットフォームの上で効率的である保証はありません。
<p>
<!--IN GENERAL, THERE IS NO SUCH THING AS A PORTABLE AND EFFICIENT
PARALLEL 
PROGRAM
-->
<em>一般的に、可搬でかつ効率的な並列プログラムは存在しません</em>
<p>
<!--There is yet another consequence to the above graph.  Since
efficiency depends 
upon the comm./process. ratio, just changing one component of the ratio
does 
not necessary mean a specific application will perform  faster.  A
change in 
processor speed, while keeping the communication speed that same may
have non-
intuitive effects on your program.   For example, doubling or tripling
the CPU 
speed, while keeping the communication speed the same, may now make some 
previously efficient PARALLEL portions of your program, more efficient
if they 
were executed SEQUENTIALLY.  That is, it may now be faster to run the 
previously PARALLEL parts as SEQUENTIAL.  Furthermore, running
inefficient 
parts in parallel will actually keep your application from reaching its 
maximum speed. Thus, by adding faster processor, you may actually slowed
down 
your application (you are keeping the new CPU from running at its
maximum 
speed for that application)
-->
もう一つの結論が上記のグラフから出て来ます。
効率は通信/処理比に依存しますから、この比率の一方だけを変えても、
必ずしも特定のアプリケーションを高速化するとは限らないことです。
通信速度を変えないでおいてプロセッサ速度を変えると、
あなたのプログラムで直感的には分からない影響を及ぼすかもしれません。
例えば、 CPU 速度を 2 、 3 倍にして、通信速度を同じにしましょう。
今度は、以前にあなたのプログラム中で効率的だった <em>並列的</em>
部分が、<em>逐次的</em>に実行した方が効率的になるかもしれません。
これは、以前は<em>並列的</em>だった部分を、
今度は、<em>逐次的</em>に走らせた方が、
もっと高速になるかもしれないということです。更に、
並列に走らせれば非効率的な部分が、
そのアプリケーションの最大速度の達成を実際には邪魔してしまうでしょう。
従って、より高速のプロセッサの追加によって、
実際にはあなたのアプリケーションを低速化させてしまうかもしれないのです
（あなたはそのアプリケーションで新
CPU が最大速度で走るのを邪魔するのです）。
<p>
<!--UPGRADING TO A FASTER CPU MAY ACTUALLY SLOW DOWN YOUR APPLICATION
-->
<em>より高速な CPU へのアップグレードが実際には
あなたのアプリケーションを低速化させるかもしれない。</em>
<p>
<!--So, in conclusion, to know whether or not you can use a parallel
hardware 
environment, you need to have some insight into the suitability of a 
particular machine to your application.  You need to look at a lot of
issues 
including CPU speeds, compiler, message passing API, network, etc. 
Please 
note, just profiling an application, does not give the whole story.  You
may 
identify a computationally heavy portion of your program, but you do not 
know the communication cost for this portion.  It may be that for a
given 
system, the communication cost as do not make parallelizing this code 
efficient.
-->
それで、結論として、
あなたが並列ハードウェア環境を使えるか否かを知るには、
あなたのアプリケーションが特定のマシンに適合するかどうかを、
見抜く必要があります。あなたは、 CPU 速度とか、コンパイラ、
メッセージパッシング API 、
ネットワークなどを含む多数の事柄を調べる必要があります。
気を付けることは、あるアプリケーションのプロファイルを作成するだけでは、
全体は分からないことです。
あなたはあなたのプログラムの計算量的に重たい部分を特定できるでしょうが、
その部分の通信コストは分かりません。ある与えられたシステムにおいては、
通信コストのおかげで、そのコードを並列的にしない方が効率的になる、
ということが有り得ます。
<p>
<!--A final note about a common misconception. It is often stated that
"a program 
is PARALLELIZED", but in reality only the CONCURRENT parts of the
program have 
been located. For all the reasons given above, the program is not 
PARALLELIZED.   Efficient PARALLELIZATION is a property of the
machine.   
-->
よくある誤解についての最後の注意です。「あるプログラムが<em>並列化</em>
された」と言われるのが、実際には、そのプログラムの
<em>並行</em>部分の場所が分かったに過ぎないことが多いのです。
今までに述べた全ての理由のせいで、そのプログラムは<em>並列化</em>
されたのではありません。効率的な<em>並列化</em>
はそのマシンの属性なのです。
<p>

<sect1><!--Writing and porting parallel software
-->
並列ソフトウェアを書くことと移植すること
<p>
<!--Once you decide that you need parallel computing and would like to
design and 
build a Beowulf, a few moments considering your application with respect
to 
the previous discussion may be a good idea. 
-->
一旦、あなたが並列計算が必要だと決心し、
Beowulf を設計して構築しようとするなら、ここまでの議論に照らして、
あなたのアプリケーションをちょっとした時間をかけて検討するのは良い考えで
す。
<p>
<!--In general there are two things you can do:
-->
一般的にあなたができることは二つあります。
<enum>
<item><!--Go ahead and construct a CLASS I Beowulf and then "fit" your
      application to it.  Or run existing parallel applications that
      you know work on your Beowulf (but beware of the portability and
      efficiently issues mentioned above)
-->
前に進み、CLASS I の Beowulf を構築してから、
あなたのアプリケーションをそれに「適合」させます。あるいは、
あなたの Beowulf
上で動くことが分かっている既存の並列アプリケーションを走らせます（しか
し、
今まで述べてきた移植性と効率性の事項に気を付けるように）。

<item><!--Look at the applications you need to run on your Beowulf and
     make some estimations as to the type of hardware and software you
     need.
-->
あなたの Beowulf 上で走らせる必要があるアプリケーションを調べて、
あなたが必要なハードウェアとソフトウェアのタイプについての、
何らかの想定を行うこと。
</enum>

<!--In either case, at some point you will need to look at the
efficiency issues. 
In general, there are three things you need to do:
-->
いずれの場合でも、あなたは効率性の事柄について、
いくつかを調べる必要があるでしょう。一般的には、
あなたは 3 つ行う必要があります。
<enum>
<item><!-- Determine concurrent parts of your program
-->
あなたのプログラムでの並行部分を判断する
<item><!-- Estimate parallel efficiently
-->
並列の効率性を見積もる
<item><!-- Describing the concurrent parts of your program
-->
あなたのプログラムのその並行部分を記述する
</enum>

<!--Let's look at these one at a time.
-->
この３つをちょっと調べてみましょう。

<sect2><!--Determine concurrent parts of your program
-->
あなたのプログラムでの並行部分を判断する
<p>
<!--This step is often considered "parallelizing your program". 
Parallelization 
decisions will be made in step 2.  In this step, you need to determine
data 
dependencies.  
-->
このステップはしばしば「あなたのプログラムを並列化すること」、
と考えられています。並列化の決定は第二ステップで行われます。
本ステップではデータ依存性を判断する必要があります。
<p>
<!--From a practical standpoint, applications may exhibit two types of 
concurrency: compute (number crunching) and I/O (database). Although in
many 
cases compute and I/O concurrency are orthogonal, there are application
that 
require both. There are tools available that can perform concurrency
analysis 
on existing applications.  Most of these tools are designed for
FORTRAN.  
There are two reasons FORTRAN is used: historically most number
crunching 
applications were written in FORTRAN and it is easier to analyze.  If no
tools 
are available, then this step can be some what difficult for existing 
applications. 
-->
実用的見地から、アプリケーションは二つのタイプの平行性を示すでしょう
- 計算（大量データ処理 number crunching ）と入出力（データベース）です。
しかし、多くの場合、計算と入出力の二つの平行性は直交します、
両方が必要なアプリケーションが存在します。
既存のアプリケーションの平行性分析を行えるツールが入手できます。
これらのツールの殆どは FORTRAN 用に設計されています。
FORTRAN が使われる理由は二つあります - 
歴史的に殆どの大量データ処理（ナンバークランチ）のアプリケーションが
FORTRAN で書かれていること、そして、分析がより容易なことです。
どのツールも入手できなければ、
既存のアプリケーションに対するこのステップは、
やや困難になるかもしれません。
<p>
<sect2><!--Estimate parallel efficiency
-->
並列の効率性を見積もる
<p>
<!--Without the help of tools, this step may require trial and error
tests or just 
a plain old educated guess.  If you have a specific application in mind,
try 
to determine if it is CPU limited (compute bound) or hard disk limited
(I/O 
bound).  The requirements of your Beowulf may be quite different
depending 
upon your needs.  For example, a compute bound problem may need a few
very 
fast CPUs and high speed low latency network, while an I/O bound problem
may 
work better with more slower CPUs and fast Ethernet.
-->
ツールの助けがなければ、本ステップには、試行錯誤とか、
豊富な経験から割り出した推測が必要かもしれません。
あなたが特定のアプリケーションを念頭に置いているのなら、
CPU が頭打ち（計算限界）なのか、
ハードディスクが頭打ち（入出力限界）なのかを判断してみましょう。
あなたの Beowulf の所要条件は、
あなたの必要性に応じて相当違ってくるかもしれません。
例えば、計算限界問題には少数の極めて高速の
CPU と低レーテンシネットワークが必要かもしれませんし、
入出力限界の問題にはもっと低速の CPU
と高速なイーサネットがもっと良く機能するかもしれません。
<p>
<!--This recommendation often comes as a surprise to most people
because, the 
standard assumption is that faster processor are always better.  While
this is 
true if your have an unlimited budget, real systems may have cost
constraints 
that should be maximized.  For I/O bound problems, there is a little
known 
rule (called the Eadline-Dedkov Law) that is quite helpful:
-->
ここでお薦めしていることは殆どの人々を大概驚かせます、なぜなら、
プロセッサは早ければ早い程常に良いというのが標準的予想だからです。
あなたが無限の予算を持っていればこの予想は真なのですが、
コストの制約の元で最高性能を目指すのが現実のシステムでしょう。
入出力問題については、結構役立ちますがあまり知られていない法則（
Eadline-Dedkov の法則と呼ばれます）があります。
<p>
<!--   For two given parallel computers with the same cumulative CPU
performance
   index, the one which has slower processors (and a probably
correspondingly 
   slower interprocessor communication network) will have better
performance
   for I/O-dominant applications.
-->
二つの並列コンピュータで累積的 CPU 性能指標が同一のものが与えられた
として、より低速のプロセッサを持つ方（そして多分、分相応に、より低速の
プロセッサ相互の通信ネットワークを持つ方）が、入出力が支配的な
アプリケーションにはより良い性能を持つことになる。
（訳注：少数の高速 CPU を使った並列コンピュータと、多数の低速 CPU を
使った並列コンピュータとの二つがあったとして、
総計では同じ CPU 性能だったとすれば、入出力で時間がかかる
アプリケーションでは多数の低速 CPU を使った方が早い、
という趣旨のようです。）
<p>
<!--While the proof of this rule is beyond the scope of this document,
you
find it interesting to download the paper <it>Performance
Considerations for I/O-Dominant Applications on Parallel
Computers</it> (Postscript format 109K ) <htmlurl
url="ftp://www.plogic.com/pub/papers/exs-pap6.ps"
name="(ftp://www.plogic.com/pub/papers/exs-pap6.ps)">
-->
この法則の証明は本文書の範囲を超えますが、あなたは<it>Performance
Considerations for I/O-Dominant Applications on Parallel
Computers</it> (Postscript format 109K ) <htmlurl
url="ftp://www.plogic.com/pub/papers/exs-pap6.ps"
name="(ftp://www.plogic.com/pub/papers/exs-pap6.ps)"> 
論文をダウンロードすれば興味深いでしょう。
（訳注：原著の上記アドレスは<htmlurl
url="ftp://www.plogic.com/plogic/papers/exs-pap6.ps"
name="(ftp://www.plogic.com/plogic/papers/exs-pap6.ps)"> 
に変わっているようです。）
<p>
<!--Once you have determined what type of concurrency you have in your
application, you will need to estimate how efficient it will be in
parallel.  See Section <ref id="software" name="Software"> for a
description of Software tools.
-->
あなたのアプリケーション中の平行性のタイプを一旦判断したら、
並列にしてどれ程効率的になるかを見積もる必要があるでしょう。
ソフトウェアツールの説明は
<ref id="software" name="Software"> の節を見てください。
<p>
<!--In the absence of tools, you may try to guess your way through this
step.  If 
a compute bound loop measured in minutes and the data can be transferred
in 
seconds, then it might be a good candidate for parallelization.  But
remember, 
if you take a 16 minute loop and break it into 32 parts, and your data 
transfers require several seconds per part, then things are going to get 
tight.  You will reach a point of diminishing returns. 
-->
ツールがなくても、推測によって本ステップをたどるのはできます。
もし、計算限界のループが数分単位で測定されて、
データが秒単位で転送できるのなら、
並列化の良い候補になるかもしれません。
しかし、忘れないでおくのは、 16 分間かかるループを 32 の部分に分割して、
あなたのデータ転送が各部分ごとに数秒必要だとすれば、
ぎりぎりになりかけている、ということです。
あなたは収穫が減少するポイントに達するでしょう。
<p>
<sect2><!--Describing the concurrent parts of your program
-->
あなたのプログラムのその並行部分を記述する
<p>
<!--There are several ways to describe concurrent parts of your program:
-->
あなたのプログラムの並行部分を記述する方法は幾つかあります。
<enum>
<item><!-- Explicit parallel execution 
-->
明示的並列実行
<item><!-- Implicit parallel execution
-->
暗黙的並列実行
</enum>

<!--The major difference between the two is that explicit parallelism is 
determined by the user where implicit parallelism is determined by the 
compiler.
-->
この二つの主な違いは、明示的並列化はユーザが判断し、
暗黙的並列実行はコンパイラが判断することです。

<sect3><!--Explicit Methods
-->
明示的方法
<p>
<!--These are basically method where the user must modify source code
specifically for a parallel computer.  The user must either add
messages using <htmlurl url="http://www.epm.ornl.gov/pvm" name="PVM"> or
<htmlurl url="http://www.mcs.anl.gov/Projects/mpi/index.html"
name="MPI"> or
add threads using POSIX threads. (Keep in mind however, threads can
not move between SMP motherboards).
-->
明示的方法では基本的に、ユーザがソースコードを、
並列コンピュータ専用に修正しなければなりません。
ユーザは <htmlurl url="http://www.epm.ornl.gov/pvm" name="PVM"> か
<htmlurl url="http://www.mcs.anl.gov/Projects/mpi/index.html"
name="MPI">
を用いてメッセージを追加するか、あるいは、
POSIX スレッドを用いてスレッドを追加するかしなければなりません
（しかし、留意することは、スレッドは SMP
マザーボード間を移動できないことです）。
<p>
<!--Explicit methods tend to be the most difficult to implement and
debug.  Users 
typically embed explicit function calls in standard FORTRAN 77 or C/C++
source 
code.  The MPI library has added some functions to make some standard
parallel 
methods easier to implement (i.e. scatter/gather functions).  In
addition, it 
is also possible to use standard libraries that have been written for
parallel 
computers.  Keep in mind, however, the portability vs. efficiently
trade-off)
-->
明示的方法は実装とデバッグが最も困難になりがちです。
ユーザは典型的には、標準 FORTRAN 77 とか
C/C++ ソースコード中に明示的関数呼び出しを埋め込みます。
この MPI ライブラリには、
幾つかの標準的並列手法を実装しやすくする関数を幾つか追加しています
（例えば、scatter/gather 関数）。
それに加えて、並列コンピュータ用に書かれてきた標準ライブラリも使えます。
（しかし、留意するのは、可搬性 vs. 効率性 のトレードオフです。）
<p>  
<!--For historical reasons, most number crunching codes are written in
FORTRAN. 
For this reasons, FORTRAN has the largest amount of support (tools, 
libraries, etc.) for parallel computing.  Many programmers now use C or
re-
write existing FORTRAN applications in C with the notion the C will
allow 
faster execution.  While this may be true as C is the closest thing to a 
universal machine code, it has some major drawbacks.  The use of
pointers in C 
makes determining data dependencies extremely difficult.  Automatic
analysis 
of pointers is extremely difficult. If you have an existing FORTRAN
program 
and think that you might want to parallelize it in the future - DO NOT
CONVERT 
IT TO C!
-->
歴史的理由から、殆どの大量データ処理（ナンバークランチ）のコードは、
FORTRAN で書かれています。このため、並列計算では、 FORTRAN
にはサポート（ツール、ライブラリ、その他）が一番多くあります。
今では、Ｃではもっと高速実行できると考えて、
多くのプログラマがＣを使ったり、既存の
FORTRAN のアプリケーションをＣに書き直したりします。
Ｃは汎用マシンコードに最も近いものですから、これは真かもしれませんが、
幾つか大きな欠点があります。
Ｃでのポインタ使用はデータ依存性の判定を極端に難しくします。
ポインタの自動分析は極端に困難です。あなたが既存の
FORTRAN プログラムを持っていて、
将来的にそれを並列化させたくなるかもしれないと考えているなら
- <em>それをＣに変換してはいけません</em>。
<p>
<sect3><!--Implicit Methods
-->
暗黙的方法
<p>
<!--Implicit methods are those where the user gives up some (or all) of
the 
parallelization decisions to the compiler.  Examples are FORTRAN 90,
High 
Performance FORTRAN (HPF), Bulk Synchronous Parallel (BSP), and a whole 
collection of other methods that are under development.
-->
暗黙的方法は、並列化の決定の幾つか（または全て）
をコンパイラにまかせるようなものです。例は、 FORTRAN 90 と、
High  Performance FORTRAN (HPF) 、 Bulk Synchronous Parallel (BSP) 、
そして、開発中のその他の方法、全てです。
<p>
<!--Implicit methods require the user to provide some information about
the 
concurrent nature of their application, but the compiler will then make
many 
decisions about how to execute this concurrency in parallel.  These
methods 
provide some level of portability and efficiency, but there is still no
"best 
way" to describe a concurrent problem for a parallel computer. 
-->
暗黙的方法は、ユーザのアプリケーションの並行的性質に
ついて何らかの情報をユーザが与える必要がありますが、
そうすれば、この並行的部分を並列に実行する方法について、
コンパイラが多くの決定を行います。
これらの方法はあるレベルの可搬性と効率性をもたらしますが、
それでも並列コンピュータのために並行問題を記述する
「最善の方法」は存在しません。

<sect><!--Beowulf Resources
-->
 Beowulf の情報源
<p>

<sect1><!--Starting Points
-->
出発点
<p>

<itemize>

<item><!--Beowulf mailing list.  To subscribe send mail to <htmlurl
url="mailto:beowulf-request@cesdis.gsfc.nasa.gov"
name="beowulf-request@cesdis.gsfc.nasa.gov"> with the word
<it>subscribe</it> in the message body.
-->
Beowulf メーリングリスト。参加するには <htmlurl
url="mailto:beowulf-request@cesdis.gsfc.nasa.gov"
name="beowulf-request@cesdis.gsfc.nasa.gov"> 宛て、<it>subscribe</it>
をメッセージ本文にしてメールを送ります。

<item><!--Beowulf Homepage <htmlurl name="http://www.beowulf.org"
url="http://www.beowulf.org">
-->
Beowulf ホームページ <htmlurl name="http://www.beowulf.org"
url="http://www.beowulf.org">

<item>Extreme Linux <htmlurl name="http://www.extremelinux.org"
url="http://www.extremelinux.org">

<item><!--Extreme Linux Software from Red Hat <htmlurl
name="http://www.redhat.com/extreme"
url="http://www.redhat.com/extreme">
-->
Red Hat からの Extreme Linux ソフトウェア
<htmlurl name="http://www.redhat.com/extreme"
url="http://www.redhat.com/extreme">

</itemize>


<sect1><!--Documentation
-->
文書
<p>

<itemize>

<item><!--The latest version of the Beowulf HOWTO <htmlurl
name="http://www.sci.usq.edu.au/staff/jacek/beowulf"
url="http://www.sci.usq.edu.au/staff/jacek/beowulf">.
-->
Beowulf HOWTO の最新版 <htmlurl
name="http://www.sci.usq.edu.au/staff/jacek/beowulf"
url="http://www.sci.usq.edu.au/staff/jacek/beowulf">

<item><!--Building a Beowulf System <htmlurl
url="http://www.cacr.caltech.edu/beowulf/tutorial/building.html"
name="http://www.cacr.caltech.edu/beowulf/tutorial/building.html">
-->
Beowulf システムの構築 <htmlurl
url="http://www.cacr.caltech.edu/beowulf/tutorial/building.html"
name="http://www.cacr.caltech.edu/beowulf/tutorial/building.html">

<item>Jacek's Beowulf Links <htmlurl
name="http://www.sci.usq.edu.au/staff/jacek/beowulf"
url="http://www.sci.usq.edu.au/staff/jacek/beowulf">.

<item>Beowulf Installation and Administration HOWTO (DRAFT) <htmlurl
name="http://www.sci.usq.edu.au/staff/jacek/beowulf"
url="http://www.sci.usq.edu.au/staff/jacek/beowulf">.

<item>Linux Parallel Processing HOWTO <htmlurl
name="http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html"
url="http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html">

</itemize>


<sect1><!--Papers<label id="papers">
-->
論文<label id="papers">
<p>

<itemize>

<item>Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
Donald Becker, and Phillip Merkey <it>A Design Study of Alternative
Network Topologies for the Beowulf Parallel Workstation</it>.
Proceedings Fifth IEEE International Symposium on High Performance
Distributed Computing, 1996. <htmlurl
name="http://www.beowulf.org/papers/HPDC96/hpdc96.html"
url="http://www.beowulf.org/papers/HPDC96/hpdc96.html">


<item>Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
Becker, and Phillip Merkey. <it>Harnessing the Power of Parallelism in
a Pile-of-PCs</it>.  Proceedings, IEEE Aerospace, 1997. <htmlurl
name="http://www.beowulf.org/papers/AA97/aa97.ps"
url="http://www.beowulf.org/papers/AA97/aa97.ps">


<item>Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael
R. Berry, and Chance Res. <it>Achieving a Balanced Low-Cost
Architecture for Mass Storage Management through Multiple Fast
Ethernet Channels on the Beowulf Parallel Workstation</it>.
Proceedings, International Parallel Processing Symposium, 1996.
<htmlurl name="http://www.beowulf.org/papers/IPPS96/ipps96.html"
url="http://www.beowulf.org/papers/IPPS96/ipps96.html">


<item>Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce
Fryxell, Kevin Olson. <it>Communication Overhead for Space Science
Applications on the Beowulf Parallel Workstation</it>.
Proceedings,High Performance and Distributed Computing, 1995.
<htmlurl name="http://www.beowulf.org/papers/HPDC95/hpdc95.html"
url="http://www.beowulf.org/papers/HPDC95/hpdc95.html">



<item>Donald J. Becker, Thomas Sterling, Daniel Savarese, John
E. Dorband, Udaya A. Ranawak, Charles V.  Packer. <it>BEOWULF: A
PARALLEL WORKSTATION FOR SCIENTIFIC COMPUTATION</it>.  Proceedings,
International Conference on Parallel Processing, 95.
<htmlurl name="http://www.beowulf.org/papers/ICPP95/icpp95.html"
url="http://www.beowulf.org/papers/ICPP95/icpp95.html">

<item><!--Papers at the Beowulf site <htmlurl
url="http://www.beowulf.org/papers/papers.html"
name="http://www.beowulf.org/papers/papers.html">
-->
Beowulf サイトの論文 <htmlurl
url="http://www.beowulf.org/papers/papers.html"
name="http://www.beowulf.org/papers/papers.html">


</itemize>


<sect1><!--Software<label id="software">
-->
ソフトウェア<label id="software">
<p>
<itemize>
<item>PVM - Parallel Virtual Machine <htmlurl
name="http://www.epm.ornl.gov/pvm/pvm_home.html"
url="http://www.epm.ornl.gov/pvm/pvm_home.html">



<item>LAM/MPI (Local Area Multicomputer / Message Passing Interface
<htmlurl url="http://www.mpi.nd.edu/lam"
name="http://www.mpi.nd.edu/lam">

<item>BERT77 - FORTRAN conversion tool <htmlurl
url="http://www.plogic.com/bert.html"
name="http://www.plogic.com/bert.html">

<item><!--Beowulf software from Beowulf Project Page <htmlurl
name="http://beowulf.gsfc.nasa.gov/software/software.html"
url="http://beowulf.gsfc.nasa.gov/software/software.html">
-->
Beowulf プロジェクトのページからの Beowulf ソフトウェア <htmlurl
name="http://beowulf.gsfc.nasa.gov/software/software.html"
url="http://beowulf.gsfc.nasa.gov/software/software.html">

<item>Jacek's Beowulf-utils <htmlurl
name="ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils"
url="ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-utils">

<item>bWatch - cluster monitoring tool <htmlurl
url="http://www.sci.usq.edu.au/staff/jacek/bWatch"
name="http://www.sci.usq.edu.au/staff/jacek/bWatch">

</itemize>



<sect1><!--Beowulf Machines
-->
Beowulf マシンたち
<p>
<itemize>

<item><!--Avalon consists of 140 Alpha processors, 36 GB of RAM, and is
probably the fastest Beowulf machine, cruising at 47.7 Gflops and
ranking 114th on the Top 500 list.  <htmlurl
name="http://swift.lanl.gov/avalon/"
url="http://swift.lanl.gov/avalon/">
-->
Avalon は 140 の Alpha プロセッサ、 36 GB の RAM で構成され、
多分最速の Beowulf マシンで、 47.7 Gflops で巡航し、
Top 500 リストの 114 番目です。  <htmlurl
name="http://swift.lanl.gov/avalon/"
url="http://swift.lanl.gov/avalon/"> （訳注：
上記アドレスは<htmlurl
name="http://cnls.lanl.gov/avalon/"
url="http://cnls.lanl.gov/avalon/"> になっているようです。
<htmlurl name=" top 500 list " 
url="http://www.top500.org/lists/1999/06/top500.list.html"> 
によれば、 160 位でした。なお、 129 位には <htmlurl
name="CPlant Cluster" 
url="http://www.cs.sandia.gov/cplant/">
が入っています。）

<item><!--Megalon-A Massively PArallel CompuTer Resource (MPACTR)
consists
of 14, quad CPU Pentium Pro 200 nodes, and 14 GB of RAM.  <htmlurl
name="http://megalon.ca.sandia.gov/description.html"
url="http://megalon.ca.sandia.gov/description.html">
-->
Megalon-A Massively PArallel CompuTer Resource (MPACTR) は
4 CPU Pentium Pro 200 のノードが 14 個と 14 GB の RAM
で構成されています。
<htmlurl
name="http://megalon.ca.sandia.gov/description.html"
url="http://megalon.ca.sandia.gov/description.html">
（訳注：訳者はアクセスできませんでした。）
<item><!--theHIVE - Highly-parallel Integrated Virtual Environment is
another fast Beowulf Supercomputer.  theHIVE is a 64 node, 128 CPU
machine with the total of 4 GB RAM.  <htmlurl
name="http://newton.gsfc.nasa.gov/thehive/"
url="http://newton.gsfc.nasa.gov/thehive/">
-->
theHIVE - Highly-parallel Integrated Virtual Environment
はもう一つの高速 Beowulf スーパーコンピュータです。 theHIVE は
64 ノードの 128 CPU マシンで全部で 4 GB RAM を持ちます。 <htmlurl
name="http://newton.gsfc.nasa.gov/thehive/"
url="http://newton.gsfc.nasa.gov/thehive/">

<item><!--Topcat is a much smaller machine and consists of 16 CPUs and
1.2
GB RAM.  <htmlurl name="http://www.sci.usq.edu.au/staff/jacek/topcat"
url="http://www.sci.usq.edu.au/staff/jacek/topcat">
-->
Topcat はもっと小さなマシンで、 16 CPU と 1.2
GB RAM で構成されます。
<htmlurl name="http://www.sci.usq.edu.au/staff/jacek/topcat"
url="http://www.sci.usq.edu.au/staff/jacek/topcat">

<item><!--MAGI cluster - this is a very interesting site with many good
links. <htmlurl name="http://noel.feld.cvut.cz/magi/"
url="http://noel.feld.cvut.cz/magi/">
-->
MAGI cluster - これは非常に面白いサイトで良いリンクがたくさんあります。
 <htmlurl name="http://noel.feld.cvut.cz/magi/"
url="http://noel.feld.cvut.cz/magi/">

</itemize>



<sect1><!--Other Interesting Sites
-->
その他の面白いサイト
<p>

<itemize>
<item>SMP Linux <htmlurl name="http://www.linux.org.uk/SMP/title.html"
url="http://www.linux.org.uk/SMP/title.html">

<item><!--Paralogic - Buy a Beowulf <htmlurl
name="http://www.plogic.com"
url="http://www.plogic.com">
-->
Paralogic - Beowulf を買える<htmlurl name="http://www.plogic.com"
url="http://www.plogic.com">

</itemize>

<sect1><!--History<label id="history">
-->
歴史<label id="history">
<p>
<itemize>

<item><!-- Legends - Beowulf  <htmlurl
name="http://legends.dm.net/beowulf/index.html"
url="http://legends.dm.net/beowulf/index.html">
-->
遺産 - Beowulf  <htmlurl name="http://legends.dm.net/beowulf/index.html"
url="http://legends.dm.net/beowulf/index.html">

<item><!-- The Adventures of Beowulf  <htmlurl
name="http://www.lnstar.com/literature/beowulf/beowulf.html"
url="http://www.lnstar.com/literature/beowulf/beowulf.html">
-->
Beowulf の冒険 <htmlurl
name="http://www.lnstar.com/literature/beowulf/beowulf.html"
url="http://www.lnstar.com/literature/beowulf/beowulf.html">

</itemize>

<sect><!--Source code
-->
ソースコード
<p>
<sect1>sum.c<label id="sum">
<p>
<verb>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include <stdio.h>
#include <math.h>

int main (void) {

  double result = 0.0;
  double number = 0.0;
  char string[80];
  

  while (scanf("%s", string) != EOF) {

    number = atof(string);
    result = result + number;
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</verb>

<sect1>sigmasqrt.c<label id="sigmasqrt">
<p>
<verb>
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */

#include <stdio.h>
#include <math.h>

int main (int argc, char** argv) {

  long number1, number2, counter;
  double result;
  
  if (argc < 3) {
    printf ("usage : %s number1 number2\n",argv[0]);
    exit(1);
  } else {
    number1 = atol (argv[1]);
    number2 = atol (argv[2]);
    result = 0.0;
  }

  for (counter = number1; counter <= number2; counter++) {
    result = result + sqrt((double)counter);
  }
    
  printf("%lf\n", result);
  
  return 0;
  
}
</verb>


<sect1>prun.sh<label id="prun">
<p> 

<verb>
#!/bin/bash
# Jacek Radajewski jacek@usq.edu.au
# 21/08/1998

export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt

# $OUTPUT must be a named pipe
# mkfifo output

export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output

rsh scilab01 $SIGMASQRT         1  50000000 > $OUTPUT < /dev/null&
rsh scilab02 $SIGMASQRT  50000001 100000000 > $OUTPUT < /dev/null&
rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT < /dev/null&
rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT < /dev/null&
rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT < /dev/null&
rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT < /dev/null&
rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT < /dev/null&
rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT < /dev/null&
rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT < /dev/null&
rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT < /dev/null&
rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT < /dev/null&
rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT < /dev/null&
rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT < /dev/null&
rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT < /dev/null&
rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT < /dev/null&
rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT < /dev/null&
rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT < /dev/null&
rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT < /dev/null&
rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT < /dev/null&
rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT < /dev/null&
</verb>


</article>
