JPH10143486A - 並列計算機におけるデータ送受信方法 - Google Patents

Abstract

(57)【要約】 【課題】 並列計算機上でリモートメモリ書き込みを用
いたデータ転送を高速に行う手段を提供する。 【解決手段】 並列計算機上でリモートメモリ書き込み
によりデータ転送する際に、各要素計算機上のデータ転
送用のメモリ領域を、あらかじめ通信相手ごとにアドレ
スの割り当てられているメモリ領域と動的に割り当てら
れる領域とに分割し、転送データ長によってこれら領域
を使い分け、更に、大きなデータに対してはパイプライ
ン処理で高速にデータ転送を行う。 【効果】 限られたメモリを用いて高速にデータの転送
を行う事が出来る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は複数の要素計算機
（プロセッシングユニット、以下PU）を通信網によって
結合した並列計算機におけるPU間のデータ送受信方法に
係わり、特にメッセージパッシングの高速性とデータの
安全性の確保するデータ送受信方法に関する。

【０００２】

【従来の技術】並列計算機は、複数のPUを通信網によっ
て結合し、それらを同時に稼働させることによって処理
速度を向上させる。本発明では特に、各PUがそれに付随
するメモリ空間のみをアクセスすることができる分散メ
モリ型の並列計算機を対象とする。分散メモリ型並列計
算機では、他のPUのメモリ上にあるデータを直接アクセ
スすることはできない。データが必要となる度に送受信
を行ってそのデータを自PUに移動する必要がある。

【０００３】分散メモリ型並列計算機では、PU間のデー
タのやりとりをすべてプログラム中に記述する必要があ
る。ここでPU間で受け渡されるデータをメッセージと呼
ぶ。このメッセージをやりとりすることをメッセージパ
ッシングと呼ぶ。並列計算機用プログラムでは、他のPU
で必要となるデータが自PUのメモリ上にある場合には自
PUはあらかじめこれらデータを他のPUへ送信し、他のPU
のメモリ上にあるデータを自PUが必要とする場合には自
PUはあらかじめ他のPUからこれらデータを受信しておく
ような指示を各PUのプログラム中に明示的に記述する必
要がある。

【０００４】多くの並列計算機システムでは、このよう
なPU間のメッセージの送受信をサポートする目的で、メ
ッセージパッシングライブラリと呼ばれる関数（あるい
はサブルーチン）群があらかじめ用意されており、通信
はCやFORTRANなどのプログラムからの関数コールとして
記述できるようになっている。メッセージパッシングラ
イブラリの中には、異なる並列計算機ハードウェア上に
インプリメントされ、事実上の標準としての通信環境を
提供するものも現れている。米国のOak RidgeNational
Laboratoryで開発されたPVMや、近年標準化が進められ
ているMPIはその例である。これらの通信ライブラリを
コールすることにより書かれた並列プログラムは、異な
る並列計算機上でも再コンパイルのみで動作させうる可
能性（可搬性）が高い。

【０００５】通信ライブラリでPU間のメッセージの受け
渡しを行うには、送信側PUでメッセージの送信関数をコ
ールし、受信側PUでそれに対応するメッセージの受信関
数をコールし、これらの間でメッセージを送受信する方
式が現在一般に用いられている。送信関数より受信関数
が先にコールされた場合には受信関数はデータの到着ま
でブロック（停止）し、送信関数が先にコールされた場
合には受信関数の開始までブロックするか、メッセージ
がシステム内にバッファリングされる。これはsend/rec
eive方式と呼ばれる。

【０００６】PU間のデータ移動を高速に実現する方法と
して、リモートメモリ書き込み機構を持つ分散メモリ型
の並列計算機がある。リモートメモリ書き込みでは、各
PUは相手PUの介入なしに直接相手PU内の特定メモリ領域
へのデータ転送が可能である。リモートメモリ書き込み
を行うことのできる特定メモリ領域は、リモートメモリ
書き込み領域と呼ばれる。リモートメモリ書き込み領域
は、実アドレスが連続であり、スワッピングされないた
めに各PUが随時データ転送することができる。

【０００７】図２は、リモートメモリ書き込み機構を持
つ並列計算機上でメッセージパッシングを実現するため
の従来手法を示す。各PU間の実際のデータ転送は、リモ
ートメモリ書き込み領域間で行われる。まず送信関数が
コールされると、送信側のユーザプログラム中のバッフ
ァ(２０１)からリモートメモリ書き込み領域内のバッフ
ァ(２０２)へデータがコピーされる。次にそこから受信
側のリモートメモリ書き込み領域内のバッファ(２０３)
にリモートメモリ書き込みを用いてデータが転送され
る。最後に受信関数がコールされて、リモートメモリ書
き込み領域(２０３)からユーザプログラム中のバッファ
(２０４)にメッセージがコピーされて、メッセージの受
け渡しが完了する。

【０００８】

【発明が解決しようとする課題】上述のように、リモー
トメモリ書き込みでは相手PUの介入なしにデータの転送
を行う際は、受信側のリモートメモリ書き込み領域の使
用を確認しないと、受信側で必要なメモリ領域を書き込
みデータで上書きしてしまい、受信側のデータを壊して
しまう恐れがあった。そこで受信側のリモートメモリ書
き込み領域を確認しないと、続けてデータ転送を行うこ
とができなかった。また、送信側でのユーザプログラム
のバッファからリモートメモリ書き込み領域へのデータ
転送、送信側のリモートメモリ領域から受信側のリモー
トメモリ領域へのデータ転送、受信側でのリモートメモ
リ書き込み領域からユーザプログラム内のバッファへの
データ転送と、計３回のデータ転送が必要であった。ま
た、リモートメモリ書き込み領域に別々に送られてきた
データ間の順序を保証する事も出来なかった。

【０００９】本発明の目的は、リモートメモリ転送を限
られた量の転送用メモリで高速に行うことと、相手PUが
独自に送ってきたデータの順序を保証することにある。

【００１０】

【課題を解決するための手段】本発明は、複数台の計算
機とこれらを相互接続する通信路からなる並列計算機に
おいて、各計算機内に、通信相手となる計算機毎に固定
された領域である静的受信バッファ領域と、通信の発生
時に動的に割り当てられる動的受信バッファ領域を確保
するステップと、送信データのデータ長が予め定められ
た値より短い場合には、送信先の該静的バッファ領域に
送信データを書き込むステップと、送信データのデータ
長が予め定められた値より長い場合には、送信先の該動
的バッファ領域のアドレスを該静的バッファ領域を用い
て受信するステップと、送信先での該受信したアドレス
の該動的バッファ領域に当該送信データを書き込むステ
ップを設けることによって、達成される。

【００１１】また予め定められた値より長いデータを転
送する場合には、パイプライン処理でデータを転送する
ことで、限られたメモリ量において高速にデータ転送を
行うことができる。

【００１２】また、送られたデータの順序性を、使用し
た転送用メモリ（バッファ）を順につなぐことで保証す
ることができる。

【００１３】

【発明の実施の形態】以下、図を参照して本発明の詳細
を説明する。

【００１４】まず、本発明の実装方法の具体例を図を参
照して説明する。図１に本発明の全体構成図を示す。１
０１,１０２はPU（プロセッサユニット）を示し、１０
３,１０４はそれらのCPU、１０５,１０６はメモリであ
る。１０７はそれらを結ぶ通信路（ＰＵを相互接続でき
るネットワークであればよい）である。PUの数は任意で
あるが、説明のために２つのPUからなる並列計算機を示
している。１０８,１０９はOS(オペレーティングシステ
ム)である。ユーザプログラムを実行する際には、まず
メモリ上にユーザプログラムが図１に示されない補助記
憶装置等からローディングされる(１１０,１１１)。な
お、ユーザプログラムはあらかじめ本発明のメッセージ
パッシングライブラリ(１１２,１１３)とリンクされて
いるものとする。メッセージパッシングライブラリ中に
は他PUからリモートメモリ書き込み可能なリモートメモ
リ書き込み領域(１１４,１１５)が設けられている。さ
らに、リモートメモリ書き込み領域内部は通信相手PUご
とにあらかじめアドレスが割り当てられている静的バッ
ファ(１１６,１１７)とアドレスが動的に変化する動的
バッファ(１１８,１１９)が存在する。

【００１５】以上の構成要素のうち、メッセージパッシ
ングライブラリが本発明の特徴をなす構成要素である。
以下、詳細に説明する。

【００１６】（Ａ）バッファの構成 図３、図４を用いて、本発明におけるメッセージパッシ
ング用のバッファ構成について説明する。上述したよう
に本発明では、静的バッファ(３０１)と動的バッファ
(４０１)の二種類のバッファを用いる。なお、静的バッ
ファ３０１は図１の静的バッファ１１６、１１７に相当
し、動的バッファ４０１は図１の動的バッファ１１８、
１１９に相当する。

【００１７】まず、静的バッファは通信相手PU（＃０、
＃１、＃２、・・・＃ｎ）ごとに複数のブロック（図３
ではPU＃１に対して６個のブロックが示される）が用意
されている。静的バッファの各ブロックは、大きく分け
てヘッダ(３０２)とメッセージ本体(３０３)の二つに分
かれており、さらにヘッダ内にはtag(３０４)、length
(３０５)、first address(３０６)、last address(３０
７)の情報が含まれている。tagは対応する送受信の組を
選択するための識別子、lengthは通信するメッセージの
長さ、first addressは動的バッファを割り当てた時の
先頭アドレス、last addressは動的バッファを割り当て
た時の最終アドレスを格納するための領域である。な
お、通信路（ネットワーク）内での送信先ＰＵおよび送
信元ＰＵの識別情報は別途管理され、メッセージはネッ
トワーク内を転送されるものとする。静的バッファは各
PUごとに送信用(３０１)と受信用(３０９)の同一形状の
バッファが用意されており、バッファの使用状況などの
情報が通信相手PUと共有化されている。静的バッファは
通信相手PUごとにあらかじめ設定されており初期化の時
点でお互いのPUがアドレスを知ることが出来る。送信側
は送信用バッファに空きがある限りは常に受信側の受信
用バッファにデータの転送を行う事が出来る。

【００１８】動的バッファは、通信相手PUごとに区別さ
れていない複数のブロック(４０１)からなる。各ブロッ
クは、ヘッダ(４０２)とメッセージの本体(４０３)とに
分けられ、ヘッダは受信側がデータが到着したかどうか
の確認を行うために使用される。なお、ヘッダ部分の領
域の構成は静的バッファの構成と同じであり、送信先Ｐ
Ｕおよび送信元ＰＵのネットワーク内での識別情報（ア
ドレス）は別途管理されるものとする。さらにメッセー
ジ長に合わせたバッファ量を選択するために、各ブロッ
クは幾つかで束になって管理されている（図４の複数ブ
ロック４０１ではでは、この束を太線の枠で示してい
る）。その束ごとに管理ヘッダ(４０４)に登録されてお
り、受信側PUはメッセージ長に合わせて最適なサイズの
バッファ束を取得する（図４の例では１ブロックの束と
４ブロックの束がそれぞれ複数面用意されており、メッ
セージが１ブロックのサイズより小さい時は１ブロック
の束が、それより大きい時には４ブロックの束が取得す
る）。受信側PUは取得したバッファ束の先頭アドレスと
最終アドレスを静的バッファのヘッダ内のfirst addres
s、last addressに格納し送信側PUへと送信することに
なる。また、送信側は動的バッファを２面用意しており
(４０５)、これを交互に使用することでパイプライン処
理が可能となる。パイプライン処理の詳細については後
述する。

【００１９】（Ｂ）通信プロトコル 一般にメッセージ長が短い時には、より高速にメッセー
ジの転送が行われる（レイテンシが低い）ことが求めら
れ、一方メッセージ長が長い時には、単位時間当りによ
り大量のメッセージの転送が行われる（スループットが
大きい）ことが求められる。この２つの必ずしも両立し
ない要求を満たすため、本発明ではメッセージ長が短い
メッセージを送信する場合に使用するショートプロトコ
ルとメッセージ長が長いメッセージを送信する場合に使
用するロングプロトコルの２つの通信プロトコルを用意
し、これを切り替えて用いることで遅延の少ないデータ
転送を実現する。

【００２０】図５は、ショートプロトコルのタイミング
チャートを表している。ショートプロトコルは、メッセ
ージの転送に静的バッファを用いる。ユーザプログラム
により送信関数がコールされると(５０１)、送信側PUは
静的バッファのヘッダとメッセージ本体を受信側に送信
する(５０３)。一方、受信関数がコールされると(５０
２)、受信側PUは静的バッファでメッセージを受け取
り、送信側に受信完了通知を送信し(５０４)する。１往
復のデータ通信でメッセージの通信を完了することがで
きる。

【００２１】しかし、リモートメモリ書き込み領域には
限りがあるため、静的バッファの長さ、数量には制限が
生じる。そのため全てのメッセージを静的バッファで送
信すると大量のメッセージを通信する時には、静的バッ
ファが空くのを待つ必要があり、逆に通信速度が落ちて
しまう。そのためメッセージ長が長い時には、PUごとに
区別されていない、それがゆえに大量に用意の出来る動
的バッファを用いてメッセージ転送を行う。これが、ロ
ングプロトコルである。静的バッファのメッセージ本体
部分の長さを境界として、静的バッファの容量より少な
いメッセージ長のメッセージを送信する場合にショート
プロトコルを用い、静的バッファの容量より大きいメッ
セージ長のメッセージを送信する場合にロングプロトコ
ルを用いるように、制御される。

【００２２】図６は、ロングプロトコルのタイミングチ
ャートを表している。ユーザプログラムにより送信関数
がコールされると(６０１)、送信側PUはまず、送信する
データ長の長さ（送信するデータのデータ量）を検出
し、このデータ量が静的バッファの容量より大きいと、
ロングプロトコルを用いると判定する。静的バッファの
容量より送信するデータ量が小さい場合は、前述のショ
ートプロトコルを用いる。ロングプロトコルの場合、静
的バッファのヘッダを受信側に送信する(６０３)。一
方、受信関数がコールされると(６０２)受信側PUは静的
バッファでメッセージの情報を受け取り、それに合わせ
た動的バッファのアドレス情報を静的バッファを用いて
送り返し(６０４)、以後送信側PUが受け取ったバッファ
情報に基づきメッセージを送信し(６０５)、最後に受信
側PUが送信側に受信完了通知を送信する(６０６)。２往
復のデータ転送が必要でありショートプロトコルに比較
してレイテンシは高くなるが、動的バッファは静的バッ
ファに比べ大量のデータ転送を可能とするためスループ
ットを大きくすることが可能である。

【００２３】以下、各プロトコルの動作を詳細に説明す
る。まず、ショートプロトコルの動作を図７を用いて説
明する。送信側PUは、静的バッファのヘッダにメッセー
ジ長と識別子を格納する(７０１)。さらにメッセージを
ユーザ領域からメッセージ本体部にコピーする(７０
２)。次いで、送信側から受信側へ静的バッファのリモ
ートメモリ書き込みを行う(７０３)。一方、受信側PU
は、メッセージを静的バッファで受け取り(７０５)、そ
こからユーザ領域へとコピーし、受信が完了する(７０
６)。最後に受信側は受信完了通知を静的バッファを使
い送り出し(７０７)、それを受けて送信側も処理を終了
する(７０４)。

【００２４】次に、ロングプロトコルの動作を図８を用
いて説明する。まず送信側PUはショートプロトコルと同
様、静的バッファのヘッダにメッセージ長と識別子を格
納する(８０１)。ロングプロトコルの場合静的バッファ
ではメッセージを送りきれないためヘッダのみを受信側
へリモートメモリ書き込みする(８０２)。受信側PUは静
的バッファでメッセージの情報を受け取る(８０７)と、
lengthに合わせて適当な長さの動的バッファを確保しそ
の先頭アドレスと最終アドレスを取得する(８０８)。そ
れらのアドレスを静的バッファのfirst address、last
addressにセットして、送信側に送り返す(８０９)。送
信側はバッファ情報を受け取り(８０３)、全てのメッセ
ージを送信するまでループを繰り返し(８０４)、動的バ
ッファのブロックを単位として、ユーザ領域からバッフ
ァにコピーし送信する(８０５)。さらに受信側も全ての
メッセージを受信するまでループを繰り返し(８１０)、
受信したブロックからユーザ領域にメッセージをコピー
する(８１１)。最後に受信側は受信完了通知を静的バッ
ファを使い送り出し(８１２)、それを受けて送信側も処
理を終了する(８０６)。

【００２５】（Ｃ）ロングプロトコルにおけるパイプラ
イン転送 リモートメモリ書き込みを用いたメッセージパッシング
では、ユーザ領域からリモートメモリ書き込み領域への
コピー、送信側から受信側へのリモートメッセージ転
送、リモートメモリ書き込み領域からユーザ領域へのコ
ピー、とメッセージの転送が３回必要となる。したがっ
て少なくともリモートメモリ書き込みの約３倍の時間が
必要となる。そこで本発明では送信側の動的バッファを
２面用意し、パイプライン処理を行う事で性能向上を図
る。

【００２６】以下に図９を用いてパイプライン処理時の
動作を説明する。図９において送信側PUのリモートメモ
リ書き込み領域内のバッファ(２０４)は、図４における
２面ある送信側の動的バッファ(４０５)を、受信側PUの
リモートメモリ書き込み領域内のバッファ(２０３)は、
受信側の動的バッファ(４０１)を簡易化して表してい
る。受信側の動的バッファは多面用意されているが、こ
こではABCDのデータを転送するのに必要な４面のみ表記
している。ステップ１で送信側においてユーザ領域から
リモートメモリ書き込み領域へメッセージAのコピーを
行う(９０１)。次にステップ２で、メッセージAを送信
側から受信側へリモートメッセージ転送で送信する(９
０２)と同時に、メッセージBをリモートメモリ書き込み
領域へコピーする(９０３)。ステップ３では、受信側で
メッセージAをリモートメモリ書き込み領域からユーザ
領域へコピーし(９０４)、メッセージBを送信側から受
信側へリモートメモリ転送し(９０５)、送信側でメッセ
ージCをユーザ領域からリモートメモリ書き込み領域へ
コピーする(９０６)。ステップ４では、受信側でのメッ
セージBのコピー(９０７)、メッセージCの送信側から受
信側へのリモートメモリ書き込み転送(９０８)、送信側
でのメッセージDのコピー(９０９)を同時に行う。

【００２７】図１０は、パイプライン処理の送信側PUと
受信側PUごとの動作を示す。送信側では、まずデータA
をユーザ領域からリモートメモリ書き込み領域へメモリ
コピーし(１００１)、次にデータAを受信側に送信する
と同時にデータBのメモリコピーを行い(１００２)、以
下順次同様の動作が続き(１００３,１００４)、最後に
データDの送信が行われる(１００５)。一方、受信側で
は、まずデータAを送信側から受信し(１００６)、次に
データBを受信すると同時にデータAのメモリコピーを行
い(１００７)、以下順次同様の動作が続き(１００８,１
００９)、最後にデータDのメモリコピーが行われる(１
０１０)。

【００２８】（Ｄ）メッセージパッシングライブラリの
インタフェース メッセージパッシングライブラリは、ユーザプログラム
の中から関数コールの形でメッセージパッシングを行う
ための関数群である。以下に、本発明におけるメッセー
ジパッシングライブラリの関数のインタフェースとその
動作を説明する。なお、関数名称、引き数名称などは任
意であり、必ずしもここで説明する仕様と同じである必
要はない。

【００２９】(１)Init() 本関数中で、メッセージパッシングライブラリは必要な
初期化操作を行う。メッセージパッシングライブラリの
使用時には、全てのPUが必ず最初に本関数をコールしな
ければならない。本関数がユーザプログラムからコール
されると、リモートメモリ書き込み領域に静的バッファ
(図１：１１６,１１７)と動的バッファ(図１：１１８,
１１９)を作成し、各バッファの初期化を行う。静的バ
ッファは各PUごとにアドレスが固定であり、全てのPUは
静的バッファの送信時の相手先アドレスをこの初期化時
に通信しあうことが出来る。以下に挙げる関数は、初期
化関数をコールした後にのみ使用する事が出来る。

【００３０】(２)Send(buf, dest, tag, length) ここで、bufは送信するメッセージの格納されたユーザ
メモリの先頭アドレスで、destは送信先PU番号（ネット
ワーク内での送り先ＰＵを識別する情報）、tagはメッ
セージの識別子、lengthはメッセージの長さを表す。ユ
ーザが本関数をコールすると、ライブラリはlengthによ
ってショートプロトコル(図７：７０１〜７０４)かロン
グプロトコル(図８：８０１〜８０６)を用いてメッセー
ジの送信を行う。

【００３１】(３)Recv(buf, src, tag) 本関数のbufは受信したメッセージを格納するユーザメ
モリの先頭アドレスで、srcは送信元PU番号（ネットワ
ーク内でＰＵを識別する情報）、tagはメッセージ識別
子を表す。ユーザが本関数をコールすると、送信元ＰＵ
番号が一致した静的バッファのヘッダ部分でメッセージ
の長さを受け取り、それに合わせてショートプロトコル
(図７：７０５〜７０７)またはロングプロトコル(図
８：８０７〜８１２)でメッセージの受信を行う。

【００３２】（Ｅ）ノンブロッキング動作における順序
性の保証 メッセージパッシングライブラリにおける送受信には、
ブロッキング関数とノンブロッキング関数がある。ブロ
ッキング関数とは、送受信関数がコールされてから送受
信が完了するまでプログラムの動作をブロック(停止)す
る関数であり、ノンブロッキング関数とは、関数のコー
ル後送受信が完了する前にリターンし、PUはその間に他
の動作を行う事が可能な関数である。前項まではブロッ
キング関数を前提としていた。本項ではノンブロッキン
グを実現するための追加機構を説明する。ノンブロッキ
ング関数では、送受信が完了する前に複数の送受信関数
が発行される事がある。この時にtagの同じ送受信関数
では、発行された順序で送信関数と受信関数が対応しな
い事がある。以下に本発明の送受信関数の順序性の保証
法について図１１を用いて説明する。

【００３３】本発明のメッセージパッシングライブラリ
は、送信時には、まず静的バッファのヘッダにメッセー
ジ情報(tag, length)をセットして受信側へと連絡する
(ショートプロトコル時にはメッセージの本体も同時に
送信する)。この時に静的バッファのヘッダにnext(１１
０１)というメンバを加え、このnextで次に送信する静
的バッファのブロックを指定する。使用中の静的バッフ
ァの各ブロックは、nextによりチェーンでつながれてお
り、チェーンの順に送信されることになる。受信側が受
け取る静的バッファは送信側から送られたものであり、
送信側と同様nextでつながっている。したがってチェー
ンの順で検索し、送信関数の発行順序を確定することが
出来る。

【００３４】また、送信側での送信関数発行時に静的バ
ッファが空いていない時や、受信側での受信関数発行時
に静的バッファのヘッダがまだ送られてきていない時に
は、送受信関数の順序を静的バッファのブロックの順序
で表す事が出来ない。そこで本発明では、関数発行時に
すぐに処理できない関数の順序を保持しておくために、
未処理の関数の発行順序を管理するためのリクエストオ
ブジェクトを導入する(１１０２,１１０３)。リクエス
トオブジェクトには、メッセージの情報を保持するtag
(１１０４,１１０５)、dest(src)(１１０６,１１０
７)、length(１１０８,１１０９)と順序を保持するnext
(１１１０,１１１１)の計４つの要素を持つ。終了して
いない関数は静的バッファのブロックと同様、nextによ
ってチェーンでつながれ、送信側、受信側、それぞれ
で、その順に処理される。静的バッファのブロックが順
に処理された後は、リクエストオブジェクトの順に処理
が進む。以上の方式によりノンブロッキング関数におけ
る順序性は保証される。

【００３５】（Ｆ）ノンブロッキング動作の追加インタ
フェース 順序性が保証されれば、以下のインタフェースを追加す
ることによってノンブロッキング関数を実現できる。

【００３６】(１)Isend(buf, dest, tag, length) 各引き数はSendと同じ仕様である。ユーザが本関数をコ
ールすると静的バッファに空きがある場合には使用する
バッファをチェーンにつないでから転送し、静的バッフ
ァに空きがない場合にはリクエストオブジェクトを作成
して本関数をチェーンにつなぐ。リクエストオブジェク
トのチェーンは発行順に処理される。静的バッファを受
信側に転送した後は、ショートプロトコル(図７：７０
１〜７０４)かロングプロトコル(図８：８０１〜８０
６)で非同期にデータが転送される。

【００３７】(２)Irecv(buf, src, tag) 各引き数はRecvと同じ仕様である。ユーザが関数をコー
ルするとリクエストオブジェクトを作成してチェーンに
つなぐ。チェーンの先頭の関数から順に処理され、静的
バッファのチェーンの先頭から順に対応するtagを持つ
送信関数が発行されているかを検索する。対応する送信
が検索された後は、ショートプロトコル(図７：７０４
〜７０７)かロングプロトコル(図８：８０７〜８１２)
で非同期にデータが転送される。

【００３８】(３)Wait() 本関数は、ノンブロッキング関数の完了を待つための関
数である。ノンブロッキング関数は、関数コール後すぐ
にリターンしてしまうため、関数がいつ完了するかユー
ザには分からない。そのためノンブロッキング関数の完
了を明示するために本関数は使われる。本関数が発行さ
れると、完了確認をしていないノンブロッキング関数が
完了するまでPUはブロックされる。全ての関数が完了す
ることで本関数も完了する。本関数完了後はまた新たに
Send/Isend、Recv/Irecvが発行され通信が再開される。

【００３９】

【発明の効果】本発明のリモートメモリ転送制御方式に
よれば、リモートメモリ書き込みを用いたデータ転送に
おいて、データの長さによってあらかじめPUごとにアド
レスの割り当てられた領域を用いて転送するか、転送時
に動的に割り当てられる領域を用いてパイプライン処理
で転送するかを選択することができ、それによって高速
にデータの転送が出来るようになる。図１２に示す通り
パイプライン動作を導入すると、最初と最後の２回ずつ
を除き、３回のメッセージ転送が重なって生じる。した
がって、従来のリモートメモリ書き込みを用いたメッセ
ージパッシングに比べ、約３倍の性能が得られる。

【００４０】また、本発明のリモートメモリ転送制御方
式によれば、送信関数が発行された順にデータが転送さ
れ、受信関数が発行された順に転送されたデータを受け
取る事を保証することができる。これにより、ノンブロ
ッキング動作を行う送受信関数におけるデータの順序性
を保証することができるようになる。

【図面の簡単な説明】

【図１】本発明の実施例の全体構成図。

【図２】従来のリモートメモリ書き込みを用いたデータ
転送制御方式。

【図３】静的バッファの説明図。

【図４】動的バッファの説明図。

【図５】ショートプロトコルのタイミングチャート。

【図６】ロングプロトコルのタイミングチャート。

【図７】ショートプロトコルのフローチャート。

【図８】ロングプロトコルのフローチャート。

【図９】パイプライン動作の説明図。

【図１０】パイプライン動作のフローチャート。

【図１１】順序性保証のための説明図。

【図１２】パイプライン動作の動作図。

【符号の説明】

１０１,１０２...要素計算機、１０３,１０４...CPU、
１０５,１０６...メモリ、１０７...通信路、１０８,１
０９...オペレーティングシステム、１１０,１１１...
ユーザプログラム、１１２,１１３...メッセージ通信ラ
イブラリ、１１４,１１５...データ転送用メモリ領域、
１１６,１１７,３０１,３０９...静的バッファ、１１
８,１１９,４０１,４０５,９１０,９１１...動的バッフ
ァ、２０１,２０４...ユーザバッファ、２０２,２０
３...データ転送用バッファ、３０２...静的バッファの
ヘッダ、３０３,３０８...静的バッファのメッセージ本
体、３０４...メッセージの識別子を格納する領域、３
０５...メッセージの長さを格納する領域、３０６...確
保した動的バッファの先頭アドレスを格納する領域、３
０７...確保した動的バッファの最終アドレスを格納す
る領域、４０２...動的バッファにメッセージが到着し
ているかを確認するためのヘッダ、４０３...動的バッ
ファのメッセージの本体、４０４...動的バッファの管
理ヘッダ、１１０１...静的バッファの順序を格納する
領域、１１０２,１１０３...リクエストオブジェクト、
１１０４,１１０５...メッセージの識別子を格納するリ
クエストオブジェクトの領域、１１０６,１１０７...メ
ッセージの送受信相手を格納するリクエストオブジェク
トの領域、１１０８,１１０９...メッセージの長さを格
納するリクエストオブジェクトの領域、１１１０,１１
１１...リクエストオブジェクトの順序を格納する領
域。

Claims (4)

【特許請求の範囲】
1. 【請求項１】複数台の計算機とこれらを相互接続する通
   信路からなる並列計算機の該計算機間のデータ転送方法
   であって、 該各計算機内に、通信相手となる計算機毎に固定された
   領域である静的受信バッファ領域と、通信の発生時に動
   的に割り当てられる動的受信バッファ領域を確保するス
   テップと、 送信データのデータ長が予め定められた値より短い場合
   には、送信先の該静的バッファ領域に送信データを書き
   込むステップと、 送信データのデータ長が予め定められた値より長い場合
   には、送信先の該動的バッファ領域のアドレスを該静的
   バッファ領域を用いて受信するステップと、送信先での
   該受信したアドレスの該動的バッファ領域に当該送信デ
   ータを書き込むステップを有することを特徴とする並列
   計算機におけるデータ送受信方法。
2. 【請求項２】複数台の要素計算機を通信路によって結合
   しており、任意の要素計算機上のデータ転送用メモリ領
   域上にあるデータを任意の他の要素計算機上のデータ転
   送用メモリ領域に書き込むリモートメモリ書き込み機構
   を有する並列計算機における任意の２つの要素計算機の
   間のデータ送受信方法であって、 各要素計算機は、利用者プログラムからの通信初期化要
   求を契機として、該データ転送用メモリ領域上に、通信
   相手となる計算機毎にあらかじめアドレスの固定された
   静的受信バッファ領域と、通信が発生するたびにそこか
   らバッファが動的に割り当てられる動的受信バッファ領
   域を確保するステップと、 利用者プログラムからの送信要求を契機として、送信側
   要素計算機は、利用者メモリ上の送信データを該データ
   転送用メモリ領域にコピーし、データ長に関する情報を
   含むヘッダを構成し、該送信データのデータ長があらか
   じめ定められた値より短い場合には、該ヘッダおよびデ
   ータを受信側の要素計算機上に用意された該静的バッフ
   ァ領域にリモートメモリ書き込み機構を用いて書き込
   み、該送信データのデータ長があらかじめ定められた値
   より長い場合には、該ヘッダを受信側の要素計算機上に
   用意された該静的バッファ領域にリモートメモリ書き込
   み機構を用いて書き込むステップと、 受信側の要素計算機は、該ヘッダの到着を契機として、
   該ヘッダを参照してデータ長を取得し、該送信データの
   データ長があらかじめ定められた値より長い場合には、
   該データ長が必要なバッファを該動的バッファ領域上に
   確保してそのバッファのアドレス情報を送信側の要素計
   算機に通知するステップと、 送信側の要素計算機は、該送信データのデータ長があら
   かじめ定められた値より長い場合には、該アドレス情報
   の到着を契機として、該アドレス情報を参照してデータ
   を受信側の要素計算機の該確保された動的バッファ上に
   リモートメモリ書き込み機構を用いて書き込むステップ
   と、 利用者プログラムからの受信要求を契機として、受信側
   要素計算機は、該静的バッファ領域または該動的バッフ
   ァ領域に書き込まれた該データを利用者メモリ上の受信
   バッファにコピーするステップとを有するデータ送受信
   方法。
3. 【請求項３】利用者プログラムから複数の送信要求が発
   行された場合に、該ヘッダ情報中に次の送信要求に対し
   て確保されるべきヘッダへのポインタ情報を格納するス
   テップを有する請求項２記載のデータ送受信方法。
4. 【請求項４】複数台の要素計算機を通信路によって結合
   しており、任意の要素計算機上のデータを他の任意の要
   素計算機のメモリに書き込むリモートメモリ書き込み機
   構を有する並列計算機における任意の２つの要素計算機
   の間のデータ送受信方法であって、 各要素計算機は、該データ転送用メモリ領域上に、通信
   が発生するたびにそこからバッファが動的に割り当てら
   れる動的受信バッファ領域と、２つの送信バッファを確
   保する。該動的受信バッファ領域は、あらかじめ定めら
   れた固定長の複数のブロックよりなるように構成するス
   テップと、 送信側要素計算機は、利用者プログラムからの送信要求
   を契機として、該送信データを、該あらかじめ定められ
   た複数の固定長のパケットに区切り、データの長さに関
   する情報を含むヘッダを構成し、該ヘッダを受信側の要
   素計算機に通知するステップと、 受信側の要素計算機は、該ヘッダ情報の到着を契機とし
   て、該ヘッダ情報を参照して必要な数の該ブロックより
   なる受信バッファを該動的受信バッファ領域上に確保
   し、該バッファのアドレス情報を送信側の要素計算機に
   通知するステップと、 送信側要素計算機は、該バッファのアドレス情報の到着
   を契機として、該複数のパケットのうちｎ番目のパケッ
   トを該データ転送用メモリ領域上の該２つの送信バッフ
   ァのうち一方にコピーし、既に該データ転送用メモリ領
   域上の該２つの送信バッファのうちもう一方にコピーさ
   れたｎ−１番目のパケットを、リモートメモリ書き込み
   機構を用いて、受信側の要素計算機上の該動的受信バッ
   ファのｎ−１番目のブロックに書き込み、上記２つのス
   テップをすべての該複数のパケットについて順次適用す
   るステップと、 利用者プログラムからの受信要求を契機として、受信側
   要素計算機は、該受信バッファの複数のブロックに書き
   込まれた該データを利用者メモリ上の受信バッファに順
   次コピーするステップとを有するデータ送受信方法。