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 © 1997 - 1998 Jacek Radajewski and Douglas Eadline. Permission to distribute and modify this document is granted under the GNU General Public Licence. <p> （著作権の仮訳： Copyright © 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>