JP2014049074A - 計算ノード間メッセージ通信状況取得プログラム、方法、及びシステム - Google Patents

Abstract

【課題】ユーザプログラムを変更せずに、並列コンピューティングを効率的に実行させるための情報を簡便に取得する。
【解決手段】第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するプログラムであって、前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する。
【選択図】図１

Description

本発明は、複数の計算ノードで互いにメッセージを通信する際における通信状況の取得に関する。

複数の計算ノードを持つ並列コンピュータにおいては、複数の計算ノードの間で連繋して処理を遂行するために、計算ノード間でメッセージ通信（データの伝送）を行う場合がある。

計算ノード間のメッセージ通信を行う標準インタフェースとしては、メッセージパッシングインタフェース（ＭＰＩ）がある。このＭＰＩの一般的実装には、短メッセージ通信用のEager通信や、長メッセージ通信用のRendezvous通信が含まれる。Eager通信は、送受信バッファを介した通信であり、比較的短いメッセージを転送する通信である。また、Rendezvous通信は、ＲＤＭＡ（リモートダイレクトメモリアクセス）を利用した通信であり、比較的長いメッセージを転送する通信である。

例えば、計算ノード１からのメッセージを、計算ノード２が利用して処理を実行する場合を想定する。この場合、計算ノード１の送信準備が完了した後、直ちに計算ノード１から計算ノード２にメッセージが送信されるのが理想である。しかしながら、例えば計算ノード１におけるメッセージの送信の準備が間に合わず、メッセージ受信に待ち時間が発生してしまう場合がある。これは、例えば、計算ノード２の処理の負荷に比して計算ノード１の処理の負荷が重いために、第１の計算ノードのメッセージ送信の準備が遅れる場合に発生し得る。

並列コンピューティングを効率的に実行させるためには、この待ち時間を可能な限り短くすることが望ましい。そのために、ユーザは、各計算ノードに、適切な処理の配分を行いたいと欲する。この処理の配分は、ユーザに委ねられているため、ユーザは、各計算ノードにおける待ち時間を把握することが必要である。ユーザは、待ち時間を知ることができれば、この待ち時間が短くなるように、各計算ノードの処理配分を決定することができる。

例えば、以下のユーザプログラムを実行してメッセージを送信側から受信側に転送する場合を考える。
（送信側計算ノード） （受信側計算ノード）
MPI_Send(...,comm); MPI_Recv(...,comm,&status);
上記の命令は、送信側で送信関数MPI_Send()を実行し、受信側で受信関数MPI_Recv()を実行することで送信側から受信側にメッセージの転送が行われる（なお、引数commは、通信を行うグループの指定であり、statusは、受信状況を受け取る配列を指定する）。この場合、通信待ち時間やメッセージ転送時間をユーザが把握することができない。このため、例えば、上記ユーザプログラムに以下に示す複数の関数を挿入することで対処することが考えられる。すなわち、
（送信側） （受信側）
ds1 = MPI_Wtime() dr1 = MPI_Wtime();
MPI_Barrier(comm); MPI_Barrier(comm);
ds2 = MPI_Wtime(); dr2 = MPI_Wtime();
MPI_Send(...,comm); MPI_Recv(...,comm,&status);
ds3 = MPI_Wtime(); dr3 = MPI_Wtime();
上記のプログラムにおいて、MPI_Barrier(comm)は、バリヤ同期を取る関数である。すなわち、送信側と受信側で対応するバリヤ関数が同期して実行される。commによって、同期を取るグループが指定される。すなわち、送信側と受信側に存在するバリヤ関数のうち、同じcommの値を持つバリヤ関数が同時に実行される。対応するバリヤ関数が同時に実行されることで、同期を取ることができる。

MPI_Wtime()は、現在の時刻を取得する関数である。上記の場合には、MPI_Wtime()は、その関数の実行された時刻を返す。このような複数の関数を挿入すれば、通信待ち時間やメッセージ転送時間の近似値が計測できる。例えば、ds2−ds1（dr2−dr1）を計算することによって、送信側（受信側）の通信待ち時間の近似値を得ることができる。また、ds3−ds2（dr3−dr2）を計算することによって、送信側（受信側）のメッセージ転送時間の近似値を取得することができる。待ち時間が取得できれば、ユーザは、各計算ノードに割り当てるプログラムの負荷の配分を調整することができる。こうすることで、各計算ノードの同期すべき時刻を近づけて、待ち時間を短縮することができる。待ち時間が短縮されることにより、並列コンピューティングの、より効率的な実行が可能となる。

しかしながら、上述のように、待ち時間等を取得するためには、ユーザプログラムに追加的なプログラムを挿入しなければならない。このためには、プログラムの構造を理解していなければならない。また、追加的なプログラムを挿入することは、ユーザに対して負担をかけることにもつながる。

１つの側面では、本発明は、並列コンピューティングを効率的に実行させるための情報を簡便に取得することを目的とする。

実施態様によれば、第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するプログラムであって、前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する、処理をコンピュータに実行させるプログラムが提供される。

実施態様によれば、並列コンピューティングを効率的に実行させるための情報を簡便に取得することができる。

一実施形態のEagerプロトコルのメッセージ転送を示す図である。 一実施形態のEagerプロトコルのメッセージ送信を示すフローチャートである。 一実施形態のEagerプロトコルのメッセージ受信を示すフローチャートである。 一実施形態のRendezvous(Put)プロトコルのメッセージ転送を示す図である。 一実施形態のRendezvous(Put)プロトコルのメッセージ送信を示すフローチャートである。 一実施形態のRendezvous(Put)プロトコルのメッセージ受信を示すフローチャートである。 一実施形態のRendezvous(Get)プロトコルのメッセージ転送を示す図である。 一実施形態のRendezvous(Get)プロトコルのメッセージ送信を示すフローチャートである。 一実施形態のRendezvous(Get)プロトコルのメッセージ受信を示すフローチャートである。 一実施形態のハードウエア構成を例示する図である。 一実施形態の機能ブロック図である。 図１のEagerプロトコルのメッセージ転送の他のタイミングを示す図である。

以下に、図面を用いて本発明の実施形態を詳細に説明する。なお、以下の実施形態は、発明を理解するためのものであり、本発明の範囲を限定するためのものではない点に留意すべきである。また、以下の複数の実施形態は、相互に排他的なものではない。したがって、矛盾が生じない限り、異なる実施形態の各要素を組み合わせることも意図されていることに留意すべきである。また、請求項に記載された方法やプログラムに係る発明は、矛盾のない限り処理の順番を入れ替えてもよく、あるいは、複数の処理を同時に実施してもよい。そして、これらの実施形態も、請求項に記載された発明の技術的範囲に包含されることは言うまでもない。

また、コンピュータが読み出したプログラムコードを実行することにより、後述の実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳなどの他のプログラムが実際の処理の一部または全部を行ない、その処理によって実施形態の機能が実現される場合も、本発明に含まれることは言うまでもない。

なお、メッセージの転送は、１つの計算ノードが複数のコアを持つ場合には、１つの計算ノード内でもコア間で発生し得る。これをノード内通信と呼ぶ。また、計算ノード間の通信は、ノード間通信と呼ばれ、計算ノード間を結ぶインタフェースをインターコネクトと呼ぶ。また、グリッドと呼ばれる単体の計算機間を結ぶ比較的距離の長いインタフェースとしては、一般的なネットワーク（ＬＡＮ、ＷＡＮ、インターネット等）が用いられる。なお、本明細書においては、主にインターコネクト及びネットワークの語を用いるが、いずれも、計算ノード間の通信を行うインタフェースとして用いられ得るものである。

以上の説明で用いた「計算ノード」の語は、プロセッサエレメント（ＰＥ）、プロセス、グリッドなどの語を代表する言葉として用いている点に留意すべきである。また、計算ノードは、物理的に特定できる計算資源でなくてもよく、仮想的なプロセッサ、あるいは、所定のソフトウエアを実行するプロセス等であってもよい。

また、メッセージとは、計算ノード間で転送すべきデータを意味する。

加えて、「メッセージ転送時間」及び「通信待ち時間」を以下のように定義する。
「メッセージ転送時間」：実際にインターコネクト上にデータが流れている時間。
「通信待ち時間」：送信処理関数が実行され、データを送信しようとした場合、受信側がデータの受信準備ができていないために送信が開始できない時間。或いは、受信処理関数が実行され、受信側でデータの受信準備ができているが、送信側からデータが送られてこない時間。

また、明細書においては、説明を分かりやすくするために、第１の計算ノードと第２の計算ノードを用いて説明するが、３以上の計算ノードが関与するシステムにおいても、同様に、本発明の各実施形態が適用できることは言うまでもない。なお、第１の計算ノードと第２の計算ノードは、単に便宜上付与した名前に過ぎず、「第１」及び「第２」の語が、計算ノードの機能に関して特別な意味を持つものではない。したがって、第１の計算ノードと第２の計算ノードは、それぞれについて説明されている役割を交換しても、実施形態の実行に影響を及ぼすことはない。

また、本明細書における実施形態は、プログラムによってインプリメントすることができる。したがって、各種の時間計測においては、プログラムの実行に伴う遅延や、タイマ設定の命令のプログラム上での位置等によって、実際に計測されるべき時間と、タイマ等によって得られる値には誤差が伴う点にも留意すべきである。なお、この誤差は、無視し得る範囲に収まると予測される。当業者であれば、本発明の実施形態に即して、このような誤差を考慮して適切なインプリメンテーションを行うことができることは言うまでもない。

図１は、一実施形態のEagerプロトコルのメッセージ転送を示している。図１には、第１の計算ノードにおいて送信処理関数が実行され、第２の計算ノードにおいて受信処理関数が実行された例が示されている。受信処理関数の例を以下に示す。
（第１の計算ノード） （第２の計算ノード）
MPI_Send(...,comm); MPI_Recv(...,comm,&status);
図１において、送信処理関数は以下のシーケンスを有する。Eagerプロトコルのメッセージ転送は、比較的小さいデータを転送する際に利用される。メッセージの転送には、バッファが利用される。

時刻ｔ１５１において、送信処理関数MPI_Send(...,comm);が実行され、送信処理が開始される。

時刻ｔ１５１からｔ１５２の間の待ち時間１０１は、主に送信処理関数の準備処理にかかる時間である。ｔ１５２において、第１の計算ノードから、メッセージの転送の起点となる制御通信１４０が、第２の計算ノードに送信される。この起点となる制御通信１４０は、受信側の第２の計算ノードに対して、メッセージ転送が開始されることを伝える役割を果たす。受信側の第２の計算ノードは、この起点となる制御通信１４０を受信した時刻を知ることによって、その後にメッセージの転送が速やかに開始されることを知ることができる。この起点となる制御通信１４０は、時刻ｔ１６２に、第２の計算ノードに到達している。したがって、第２の計算ノードにおいては、ｔ１６２以降、速やかにメッセージ転送が実行されることを知ることができる。したがって、時刻ｔ１５２は、第１の計算ノードにおける、待ち時間１０１とメッセージ転送時間１０２との境界の時刻に極めて近い時刻であると認識することができる。同様に時刻ｔ１６２は、第２の計算ノードにおける待ち時間１１１と、メッセージ転送時間１１２との境界の時刻に極めて近い時刻であると認識することができる。

この起点となる制御通信１４０は、メッセージ転送への影響を考え、極めて短い通信時間にすることが望ましい。実際のＭＰＩ通信は、タグ情報などを格納したヘッダとデータとを含む。したがって、データ長を０バイトとすれば、転送データ長は、ヘッダ長だけとなるため、最短の転送データ長となる。なお、転送データを高速に転送可能なハードウエア機構を持つ場合には、ヘッダにデータを付けたものを用いてもよい。この起点となる制御通信を図１に示すEager通信プロトコルに実装することによって、待ち時間とメッセージ転送時間を分離して認識することが可能となる。待ち時間とメッセージ転送時間とがどのように利用できるかについては後述する。

時刻ｔ１５２からｔ１５３の間のメッセージ転送時間１０２において、メッセージ転送１５０が行われて、メッセージが第２の計算ノードに転送される。

時刻ｔ１５３からｔ１５４の終了処理１０３は、Eager通信の送信処理の終了処理であり、所定の処理を実行するための時間である。終了処理１０３は、予め予測し得る時間である。

図１において、第２の計算ノードの受信処理関数は、時刻ｔ１６１に開始される。そして、時刻ｔ１６２に、起点となる制御通信１４０が受信されるため、時刻ｔ１６１からｔ１６２の間は、待ち時間１１１となる。

時刻ｔ１６２からｔ１６３の間は、メッセージ転送時間１１２であり、メッセージ転送１５０が行われる。

時刻ｔ１６３からｔ１６４の終了処理１１３は、Eager通信の受信処理の終了処理であり、所定の処理を実行するための時間である。終了処理１１３は、予め予測し得る時間である。

図１において、待ち時間１０１よりも待ち時間１１１が長くなっている。この長い待ち時間１１１が存在する第２の計算ノードは、計算資源を有効に利用できていないことを示している。例えば、ユーザは、第２の計算ノードに対して、受信処理関数の前に、より重い処理プログラムを配置することにより、計算資源をより有効に活用することができる。したがって、ユーザは、待ち時間１０１及び待ち時間１１１の情報に基づいて、計算資源をより有効に活用するように、計算ノード１と計算ノード２の処理プログラムの配置の決定を行うことができる。

また、メッセージ転送時間１０２とメッセージ転送時間１１２とは、必ずしも同じ時間になるとは限らない。メッセージ転送時間は、通信経路のトラフィックにも影響を受ける。例えば、物理的に近い複数の計算ノードは、高速なインターコネクト１０１２（図１０）を利用できるが、コンピュータ１０１０（図１０）の計算ノードと物理的に離れている他のコンピュータ１０６０（図１０）に存在する計算ノードとは、ネットワーク１０１９や通信制御装置１０１８（図１０）を介することとなる。特にバッファを介するEager通信の場合には、例えば、メッセージ転送時間１０２よりもメッセージ転送時間１１２が長くなることがあり得る。このような状況が発生した場合には、処理プログラムを同一コンピュータ内の複数の計算ノードに割り当てることが有効となる。あるいは、メッセージの大きさに比してメッセージ転送時間１０２とメッセージ転送時間１１２の両者が長いと判断される場合には、利用している通信路のトラフィックが混んでいることが予測される。このような場合には、トラフィックが集中しないように、処理プログラムの再配置をすることが有効な場合がある。

このように、複数の計算ノードのメッセージ転送時間を比較検討することにより、ネットワーク資源の効率的活用を行うことができる。

図２は、一実施形態のEagerプロトコルのメッセージ送信を示すフローチャートである。

ステップ２０２において、送信処理関数が実行され送信処理が開始される。

ステップ２０４において、待ち時間１０１を取得するために、タイマのカウントが開始されてもよい。このステップの実行時刻は、図１における時刻ｔ１５１である。

ステップ２０６において、所定の通信準備処理が行われる。

ステップ２０８において、待ち時間１０１が終了するため、待ち時間１０１の計測のためのタイマのカウントを終了させる。そして、メッセージ転送時間１０２を取得するために、タイマのカウントが開始される。このステップの実行時刻は、図１における時刻ｔ１５２である。

以上の処理は、所定の処理であるため、待ち時間１０１は、所定の時間となることが予測される。なお、所定の時間よりも長くなる場合としては、割り込み処理の存在、他のタスク処理の存在等が挙げられる。

ステップ２１０において、メッセージの転送の開始の起点となる制御通信１４０の送信指示が行われる。

ステップ２１２において、起点となる制御通信１４０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ２１４に移る。このチェックが「いいえ」であれば、ステップ２１２が繰り返される。

ステップ２１４において、メッセージ転送１５０の送信指示がなされる。

ステップ２１６において、メッセージ転送１５０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ２１８に移る。このチェックが「いいえ」であれば、ステップ２１６が繰り返される。メッセージ送信の完了は、ハードウエアによるチェック機構によって検知してもよい。

ステップ２１８において、メッセージ転送時間１０２が終了するため、メッセージ転送時間１０２の計測のためのタイマのカウントを終了させてもよい。

ステップ２２０において、送信処理が終了する。このステップにおいて実行される送信処理の終了処理１０３は、極めて短いものであるので、計測を省略してもよい。

図３は、一実施形態のEagerプロトコルのメッセージ受信を示すフローチャートである。

ステップ３０２において、受信処理関数が実行され受信処理が開始される。

ステップ３０４において、待ち時間１１１を取得するために、タイマのカウントが開始される。このステップの実行時刻は、図１における時刻ｔ１６１である。

ステップ３０６において、メッセージの転送の開始の起点となる制御通信１４０の受信が完了したか否かがチェックされる。このチェックの結果が「はい」であればステップ３０８に移動する。このチェック結果が「いいえ」であれば、ステップ３０６を繰り返す。このステップ３０６において、起点となる制御通信１４０の到来を待つことができる。

ステップ３０８において、待ち時間１１１の計測のためのタイマのカウントを終了させる。そして、メッセージ転送時間１１２を取得するために、タイマのカウントが開始される。このステップの実行時刻は、図１における時刻ｔ１６２である。

ステップ３１０において、メッセージ転送１５０の受信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ３１２に移る。この判断が「いいえ」であれば、ステップ３１０が繰り返される。このステップ３１０が繰り返されている間、メッセージ転送１５０が継続されることになる。

ステップ３１２において、メッセージ転送時間１１２が終了するため、メッセージ転送時間１１２の計測のためのタイマのカウントを終了させてもよい。

ステップ３１４において、受信処理が終了する。このステップにおいて実行される受信処理の終了処理１１３は、極めて短いものであるので、計測を省略してもよい。

図４は、一実施形態のRendezvous(Put)プロトコルのメッセージ転送を示している。Rendezvousプロトコルは、上述のEagerプロトコルと比較して、より長いメッセージを転送する場合に利用されてもよい。メッセージの転送量に応じて、Eagerプロトコル又はRendezvousプロトコルが、システムにおいて自動的に選択されるように設定してもよい。Rendezvousプロトコルには、RDMA（Remote Direct Memory Access）が利用される。メッセージ送信側が積極的に動作して、メッセージを受信側のメモリにPutする場合と、メッセージ受信側が積極的に動作して、メッセージを送信側のメモリからGetする場合がある。図４は、PutのRendezvousプロトコルの処理を示している。GetのRendezvousプロトコルについては、図７ないし図９を用いて後述する。

図４に戻る。図４に示されたRendezvous(Put)プロトコルと、図１に示されたEagerプロトコルとの主な違いとしては、Rendezvous(Put)プロトコルには、制御通信４３０とメッセージ送信開始要求４５０が存在することである。したがって、その他の処理については、説明を簡略化する。

制御通信４３０は、メッセージのPut送信４５５の受信側である第２の計算ノードから第１の計算ノードに送られる。制御通信４３０には、RDMAをPutで実行するために、受信側（第２の計算ノード）のメモリアドレスなどの情報が含まれる。第１の計算ノードは、第２の計算ノードのメモリアドレスに対してRDMAを実行することによって、メッセージを第２の計算ノードのメモリに書き込むことができる。なお、第２の計算ノードは、RDMAを実行するために、メッセージ送信開始要求４５０を送る。このメッセージ送信開始要求４５０は、RDMAを実行するための要求であるため、ハードウエアレベルにおける要求であり、第２の計算ノードのソフトウエアレベルに伝達されない。以上がRendezvousプロトコルの概要である。

本実施形態においては、時刻ｔ４６１において、第２の計算ノードから制御通信４３０が送信される。制御通信４３０は、時刻ｔ４５１で、第１の計算ノードにおいて受信される。

時刻ｔ４５２において、メッセージ転送の起点となる制御通信４４０が第２の計算ノードに送信される。

時刻ｔ４６２において、この起点となる制御通信４４０が、第２の計算ノードによって受信される。第２の計算ノードが、この起点となる制御通信４４０を受信することによって、第２の計算ノードは、その後速やかにPut送信４５５によるメッセージ転送が行われることを知ることができる。

時刻ｔ４５３において、第１の計算ノードは、メッセージ送信開始要求４５０を送信する。

時刻ｔ４６３において、第２の計算ノードは、メッセージ送信開始要求４５０を受信する。なお、上述のように、このメッセージ送信開始要求４５０は、ハードウエアレベルで、RDMAを実行するために利用される要求であるため、第２の計算ノードは、ソフトウエアレベルにおいて、このメッセージ送信開始要求４５０を関知しなくてもよい。

その後、Put送信４５５により、RDMAが順次実行される。

したがって、待ち時間４０１は、送信処理関数の開始時刻ｔ４５０から時刻ｔ４５２までの時間であると判断してもよい。また、待ち時間４１１は、受信処理関数の開始時刻ｔ４６０から時刻ｔ４６２までの時間であると判断してもよい。

また、メッセージ転送時間４０２は、時刻ｔ４５２からｔ４５４までの時間であると判断してもよい。そして、メッセージ転送時間４１２は、時刻ｔ４６２からｔ４６４までの時間であると判断してもよい。

なお、終了処理４０３及び終了処理４１３については、図１において述べたように、計測を省略してもよい。

図５は、一実施形態のRendezvous(Put)プロトコルのメッセージ送信を示すフローチャートを示している。

ステップ５０２において、送信処理関数が実行され送信処理が開始される。

ステップ５０４において、待ち時間４０１を取得するために、タイマのカウントが開始される。

ステップ５０６において、制御通信４３０の受信が完了したか否かがチェックされる。上述のように、制御通信４３０には、PutによるRDMAを実行するために必要なメモリアドレス等が含まれる。

ステップ５０８において、待ち時間４０１の計測を終了させるため、タイマのカウントを終了させてもよい。そして、メッセージ転送時間４０２を取得するために、タイマのカウントが開始されてもよい。

ステップ５１０において、メッセージ転送の起点となる制御通信４４０の送信指示が行われる。

ステップ５１２において、起点となる制御通信４４０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ５１４に移る。このチェックが「いいえ」であれば、ステップ５１２が繰り返される。

ステップ５１４において、メッセージのPut送信４５５の送信指示がなされる。

ステップ５１５において、メッセージのPut送信４５５の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ５２６に移る。このチェックが「いいえ」であれば、ステップ５１５が繰り返される。メッセージ送信の完了は、ハードウエアによるチェック機構によって検知してもよい。

ステップ５２６において、メッセージ転送時間４０２が終了するため、メッセージ転送時間４０２の計測のためのタイマのカウントを終了させてもよい。

ステップ５２７において、送信処理が終了する。このステップにおいて実行される送信処理の終了処理４０３は、極めて短いものであるので、計測を省略してもよい。

図６は、一実施形態のRendezvous(Put)プロトコルのメッセージ受信を示すフローチャートを示している。

ステップ６０２において、受信処理関数が実行され受信処理が開始される。

ステップ６０４において、待ち時間４１１を取得するために、タイマのカウントが開始される。

ステップ６０６において、制御通信４３０の送信指示がなされる。

ステップ６０８において、制御通信４３０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理は６１０に移る。このチェックが「いいえ」であれば、ステップ６０８が繰り返される。

ステップ６１０において、メッセージ転送の起点となる制御通信４４０の受信完了がなされたか否かがチェックされる。このチェックにおいて「はい」であれば処理はステップ６１２に移る。このチェックが「いいえ」であれば、ステップ６１０が繰り返される。

ステップ６１２において、待ち時間４１１の計測のためのタイマのカウントを終了させる。そして、メッセージ転送時間４１２を取得するために、タイマのカウントが開始される。このステップの実行時刻は、図４における時刻ｔ４６２である。

ステップ６１４において、Put送信４５５のRDMA書き込みが完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ６１６に移る。この判断が「いいえ」であれば、ステップ６１４が繰り返される。このステップ６１４が繰り返されている間、Put送信４５５が継続されてもよい。

ステップ６１６において、メッセージ転送時間４１２が終了するため、メッセージ転送時間４１２の計測のためのタイマのカウントを終了させてもよい。

ステップ６１８において、受信処理が終了する。このステップにおいて実行される受信処理の終了処理４１３は、極めて短いものであるので、計測を省略してもよい。

図７は、一実施形態のRendezvous(Get)プロトコルのメッセージ転送を示している。図４のRendezvous(Put)プロトコルとの主な相違点は、制御通信７３０が計算ノード１から計算ノード２に送られる点、メッセージ転送の起点となる制御通信７４０及びメッセージ送信開始要求７５０が、第２の計算ノードから送信され、第１の計算ノードで受信される点である。

RendezvousプロトコルにおけるGet通信は、受信処理関数が存在する第２の計算ノードが、第１の計算ノードのメモリのデータをRDMAによってGetすることによってなされる。

制御通信７３０は、第１の計算ノードが、時刻ｔ７５１において送信する。送信された制御通信７３０は、時刻ｔ７６１において、第２の計算ノードによって受信される。

起点となる制御通信７４０は、第２の計算ノードの時刻ｔ７６２で送信され、ｔ７５２で第１の計算ノードによって受信される。

その後、メッセージ送信開始要求７５０が第２の計算ノードから第１の計算ノードに送信される（ｔ７６３）。メッセージ送信開始要求７５０は、ｔ７５３で第１の計算ノードによって受信される。そして、その後メッセージのGet送信７５５がなされる。

したがって、待ち時間７０１は、送信処理関数の開始時刻ｔ７５０から時刻ｔ７５２までの時間であると判断してもよい。また、待ち時間７１１は、受信処理関数の開始時刻ｔ７６０から時刻ｔ７６２までの時間であると判断してもよい。

また、メッセージ転送時間７０２は、時刻ｔ７５２からｔ７５４までの時間であると判断してもよい。そして、メッセージ転送時間７１２は、時刻ｔ７６２からｔ７６４までの時間であると判断してもよい。

なお、終了処理７０３及び終了処理７１３については、図１において述べたように、計測を省略してもよい。

図８は、一実施形態のRendezvous(Get)プロトコルのメッセージ送信を示すフローチャートを示している。

ステップ８０２において、送信処理関数が実行され送信処理が開始される。

ステップ８０４において、待ち時間７０１を取得するために、タイマのカウントが開始される。

ステップ８０６において、制御通信７３０の送信指示がなされる。

ステップ８０８において、制御通信７３０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理は８１０に移る。このチェックが「いいえ」であれば、ステップ８０８が繰り返される。

ステップ８１０において、メッセージ転送の起点となる制御通信７４０の受信完了がなされたか否かがチェックされる。このチェックにおいて「はい」であれば処理はステップ８１２に移る。このチェックが「いいえ」であれば、ステップ８１０が繰り返される。

ステップ８１２において、待ち時間７０１の計測のためのタイマのカウントを終了させる。そして、メッセージ転送時間７０２を取得するために、タイマのカウントが開始される。このステップの実行時刻は、図７における時刻ｔ７５２である。

ステップ８１４において、Get送信７５５のRDMAが完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ８１６に移る。この判断が「いいえ」であれば、ステップ８１４が繰り返される。このステップ８１４が繰り返されている間、Get送信７５５が継続されてもよい。

ステップ８１６において、メッセージ転送時間７０２が終了するため、メッセージ転送時間７０２の計測のためのタイマのカウントを終了させてもよい。

ステップ８１８において、送信処理が終了する。このステップにおいて実行される送信処理の終了処理７０３は、極めて短いものであるので、計測を省略してもよい。

図９は、一実施形態のRendezvous (Get)プロトコルのメッセージ受信を示すフローチャートを示している。

ステップ９０２において、受信処理関数が実行され受信処理が開始される。

ステップ９０４において、待ち時間７１１を取得するために、タイマのカウントが開始される。

ステップ９０６において、制御通信７３０の受信が完了したか否かがチェックされる。上述のように、制御通信７３０には、GetによるRDMAを実行するために必要な、メモリアドレス等が含まれる。

ステップ９０８において、待ち時間７１１の計測を終了させるため、タイマのカウントを終了させてもよい。そして、メッセージ転送時間７１２を取得するために、タイマのカウントが開始されてもよい。

ステップ９１０において、メッセージ転送の起点となる制御通信７４０の送信指示が行われる。

ステップ９１２において、起点となる制御通信７４０の送信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ９１４に移る。このチェックが「いいえ」であれば、ステップ９１２が繰り返される。

ステップ９１４において、メッセージのGet送信７５５の受信指示がなされる。

ステップ９１６において、メッセージのGet送信７５５の受信が完了したか否かがチェックされる。このチェックが「はい」であれば、処理はステップ９１８に移る。このチェックが「いいえ」であれば、ステップ９１６が繰り返される。メッセージ受信の完了は、ハードウエアによるチェック機構によって検知してもよい。

ステップ９１８において、メッセージ転送時間７１２が終了するため、メッセージ転送時間７１２の計測のためのタイマのカウントを終了させてもよい。

ステップ９２０において、受信処理が終了する。このステップにおいて実行される受信処理の終了処理７１３は、極めて短いものであるので、計測を省略してもよい。

図１０は、一実施形態のハードウエア構成１０００を例示している。コンピュータ１０１０は、複数の計算ノード１、計算ノード２、ないし計算ノードｎを有している。計算ノード１は、ＣＰＵ１、メモリ１及び通信モジュール１を含む。計算ノード２は、ＣＰＵ２、メモリ２及び通信モジュール２を含む。計算ノードｎは、ＣＰＵｎ、メモリｎ及び通信モジュールｎを含む。

各々の計算ノードは、ネットワーク１０１９で接続されてもよい。加えて、各々の計算ノードは、インターコネクト１０１２で接続されてもよい。或いは、コンピュータ１０１０は、複数のインターコネクトを含み、各々のインターコネクトは物理的に近い位置に配置された複数の計算ノードのうちの一部を接続する構成であってもよい（不図示）。

また、コンピュータ１０１０は、ストレージ１０１４、可搬記録媒体駆動装置１０１５、通信制御装置１０１８を有してもよい。ストレージ１０１４は、計算ノード１ないしｎにおいて計測された通信時間結果１ないしｎを記憶してもよい。可搬型記憶媒体駆動装置は、記録媒体１０１６を読み書きするよう構成されてもよい。通信制御装置１０１８は、コンピュータ１０１０の外部の機器との通信を制御するよう動作してもよい。

また、コンピュータ１０１０は、他のコンピュータ１０６０及びユーザ端末１０５０にネットワーク１０１９を介して接続されてもよい。他のコンピュータ１０６０は、コンピュータ１０１０と同様の計算ノードを有し、コンピュータ１０１０と連繋して、計算処理を実行するようにプログラムが配置されてもよい。ユーザ端末１０５０は、たとえば、ストレージ１０１４に記憶された通信時間結果１ないしｎを加工する処理を行ってもよい。そして、ユーザ端末１０５０は、この加工された通信結果１ないしｎを表示装置に出力し及び／又はプリンタ等に出力してもよい。また、ユーザ端末１０５０は、ユーザの入力を受け付ける入力装置を備えてもよい（不図示）。

図１１は、一実施形態のシステム１１００の機能ブロック図を示している。システム１１００は、送信部１１１２、受信部１１１４、時刻検出部１１２０、経過時間特定部１１３０を有し、通信時間結果１１４０を出力してもよい。

送信部１１１２は、起点となる制御通信、メッセージを含む諸データを送信してもよい。受信部１１１４は、起点となる制御通信、メッセージを含む諸データを受信してもよい。

時刻検出部１１２０は、起点となる制御通信の送受信時刻を検出してもよい。また、時刻検出部１１２０は、実行開始時刻検出部１１２２、及びメッセージ送受信完了時刻検出部１１２４を含んでもよい。実行開始時刻検出部１１２２は、送信処理関数及び受信処理関数の実行開始時刻を検出してもよい。メッセージ送受信完了時刻検出部１１２４は、メッセージの送受信の完了時刻を検出してもよい。

経過時間特定部１１３０は、待ち時間特定部１１３２、及びメッセージ転送時間特定部１１３４を含んでもよい。待ち時間特定部１１３２は、時刻検出部１１２０で検出された複数の時刻を基にして、送信処理関数及び受信処理関数の待ち時間を特定してもよい。メッセージ転送時間特定部１１３４は、時刻検出部１１２０で検出された複数の時刻を基にして、メッセージの転送時間を特定してもよい。そして、経過時間特定部１１３０は、特定された経過時間を通信時間結果１１４０として、出力してもよい。通信時間結果１１４０は、更に、例えばユーザ端末１０５０で必要な加工が施され、ユーザに分かりやすい形態で、ディスプレイに表示され、又はプリンタ等に出力されてもよい。

図１２を参照する。図１２は、図１のEagerプロトコルのメッセージ転送の他のタイミングを示している。図１と比較してタイミングに関し大きく異なる点は、第１の計算ノードの送信処理関数の開示時刻ｔ１５１ａよりも、第２の計算ノードの受信処理関数の開始時刻ｔ１６１ａが遅い時刻に開始される場合を示している。Eagerプロトコルは、送受信バッファを利用するため、第１の計算ノードのメッセージ転送の開始時刻ｔ１５２ａは、第２の計算ノードの受信処理関数の開始時刻ｔ１６１ａよりも前であってもよい。（なお、図４及び図７を用いて説明したRendezvousプロトコルの場合は、RDMAを利用するため、メッセージ転送の開始に先立ちメッセージ送信開始要求４５０又は７５０を送信する必要がある点に留意する必要がある。）
図１２において、メッセージ転送の起点となる制御通信１４０ａは、第２の計算ノードの受信処理関数の開始時刻ｔ１６１ａよりも前に、第１の計算ノードから送信されてもよい。すなわち、Eagerプロトコルでは、送受信バッファを利用するため、メッセージ転送１５０ａは、第２の計算ノードの受信処理関数の開始時刻ｔ１６１ａに左右されることなく、実行されてもよい。

このため、送信処理関数の開始時刻ｔ１５１ａと、受信処理関数の開始時刻ｔ１６１ａとのタイミングは異なるが、待ち時間１１１ａについては、図１の待ち時間１１１と比較して短くなり得る。また、メッセージ転送時間１０２ａ及びメッセージ転送時間１１２ａについては、図１の場合と略同じ時間になり得る。したがって、図１２に示されるタイミングでメッセージ転送が行われることに関して、待ち時間及びメッセージ転送時間は、略理想的なものであると判断することができる。

しかしながら、その後のメッセージ転送においては、上述のようにタイミングが異なっているために、待ち時間を発生せる原因となる場合も想定される。このため、送信処理関数及び受信処理関数の開始時刻（ｔ１５１ａ、ｔ１６１ａ）、メッセージ転送の開始時刻（ｔ１５２ａ、ｔ１６２ａ）、メッセージ転送の終了時刻（ｔ１５３ａ、ｔ１６３ａ）、送信処理関数及び受信処理関数の終了時刻（ｔ１５４ａ、ｔ１６４ａ）自体、又はその差の時間を、ユーザが検討する情報としてユーザに提示してもよい。図４及び図７を用いて説明したRendezvousプロトコルについても同様である。

以上のように、各通信ノードにおけるメッセージ転送時間と通信待ち時間とを分離して把握することが可能になることで、各計算ノードに対する処理の配置決定を、より適切に行うことができる。

なお、本実施形態の全部又は一部はプログラムによってインプリメントされ得る。このプログラムは、記録媒体１０１６に格納することができる。記録媒体１０１６とは、構造（ｓｔｒｕｃｔｕｒｅ）を有する１つ以上の非一時的（ｎｏｎ−ｔｒａｎｓｉｔｏｒｙ）な、有形（ｔａｎｇｉｂｌｅ）な、記録媒体を言う。例示として、記録媒体１０１６としては、磁気記録媒体、光ディスク、光磁気記録媒体、不揮発性メモリなどがある。磁気記録媒体には、ＨＤＤ、フレキシブルディスク（ＦＤ）、磁気テープ（ＭＴ）などがある。光ディスクには、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）などがある。また、光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）などがある。記録媒体１０１６に格納されたプログラムが読み込まれ、プロセッサによって実行されることにより、本発明の実施形態の全部又は一部が実施され得る。

コンピュータが読み出したプログラムコードを実行することにより、上述の実施形態の機能が実現され得る。

以上の実施形態に関し以下の付記を開示する。
（付記１）
第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するプログラムであって、
前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、
前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する、
処理、をコンピュータに実行させるプログラム。
（付記２）
前記検出する処理は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻とを検出し、
前記メッセージの転送における、メッセージ送信完了時刻と、メッセージ受信完了時刻とを検出する、
処理を含み、
前記特定する処理は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻と、前記メッセージ送信完了時刻と、メッセージ受信完了時刻とを利用する、付記１記載のプログラム。
（付記３）
前記特定する処理は、
前記第１の計算ノードにおける前記メッセージの送信命令の実行開始時刻と、前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定し、又は前記第２の計算ノードにおける前記メッセージの受信命令の実行開始時刻と、前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定する、
処理を含む、付記２記載のプログラム。
（付記４）
前記特定する処理は、
前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第１の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送時間を特定し、又は前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第２の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送時間を特定する、
処理を含む、付記２又は３記載のプログラム。
（付記５）
前記メッセージの転送は、ＣＰＵコア間通信、インターコネクト、バス、ＬＡＮ、ＷＡＮ、インターネットのうち、少なくとも１つを用いて実行される、
付記２ないし４のうちいずれか１項に記載のプログラム。
（付記６）
第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得する方法であって、
前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、
前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する、
処理、を有する方法。
（付記７）
前記検出する処理は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻とを検出し、
前記メッセージの転送における、メッセージ送信完了時刻と、メッセージ受信完了時刻とを検出する、
処理を含み、
前記特定する処理は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻と、前記メッセージ送信完了時刻と、メッセージ受信完了時刻とを利用する、付記６記載の方法。
（付記８）
前記特定する処理は、
前記第１の計算ノードにおける前記メッセージの送信命令の実行開始時刻と、前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定し、又は前記第２の計算ノードにおける前記メッセージの受信命令の実行開始時刻と、前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定する、
処理を含む、付記７記載の方法。
（付記９）
前記特定する処理は、
前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第１の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送時間を特定し、又は前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第２の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送時間を特定する、
処理を含む、付記７又は８項記載の方法。
（付記１０）
前記メッセージの転送は、ＣＰＵコア間通信、インターコネクト、バス、ＬＡＮ、ＷＡＮ、インターネットのうち、少なくとも１つを用いて実行される、
付記７ないし９のうちいずれか１項に記載の方法。
（付記１１）
第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するシステムであって、
前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信する送信部と、
前記起点となる制御通信を、前記他方の計算ノードにおいて受信する受信部と、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出する時刻検出部と、
少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する経過時間特定部と、
を有するシステム。
（付記１２）
前記時刻検出部は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻とを検出する実行開始時刻検出部と、
前記メッセージの転送における、メッセージ送信完了時刻と、メッセージ受信完了時刻とを検出するメッセージ送受信完了時刻検出部と、を含み、
前記経過時間特定部は、
前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻と、前記メッセージ送信完了時刻と、メッセージ受信完了時刻とを利用する、
付記１１記載のシステム。
（付記１３）
前記経過時間特定部は、
前記第１の計算ノードにおける前記メッセージの送信命令の実行開始時刻と、前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定し、又は前記第２の計算ノードにおける前記メッセージの受信命令の実行開始時刻と、前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定する、待ち時間特定部、
を有する、付記１２記載のシステム。
（付記１４）
前記経過時間特定部は、
前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第１の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送時間を特定し、又は前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第２の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送時間を特定する、メッセージ転送時間特定部、
を有する、付記１２又は１３記載のシステム。
（付記１５）
前記メッセージの転送は、ＣＰＵコア間通信、インターコネクト、バス、ＬＡＮ、ＷＡＮ、インターネットのうち、少なくとも１つを用いて実行される、
付記１２ないし１４のうちいずれか１項に記載のシステム。

１１００ システム
１１１２ 送信部
１１１４ 受信部
１１２０ 時刻検出部
１１２２ 実行開始時刻検出部
１１２４ メッセージ送受信完了時刻検出部
１１３０ 経過時間特定部
１１３２ 待ち時間特定部
１１３４ メッセージ転送時間特定部
１１４０ 通信時間結果

Claims (7)

1. 第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するプログラムであって、
   前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、
   前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する、
   処理、をコンピュータに実行させるプログラム。
2. 前記検出する処理は、
   前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻とを検出し、
   前記メッセージの転送における、メッセージ送信完了時刻と、メッセージ受信完了時刻とを検出する、
   処理を含み、
   前記特定する処理は、
   前記メッセージの送信命令の実行開始時刻と、前記メッセージの受信命令の実行開始時刻と、前記メッセージ送信完了時刻と、メッセージ受信完了時刻とを利用する、請求項１記載のプログラム。
3. 前記特定する処理は、
   前記第１の計算ノードにおける前記メッセージの送信命令の実行開始時刻と、前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定し、又は前記第２の計算ノードにおける前記メッセージの受信命令の実行開始時刻と、前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送開始までに要する待ち時間を特定する、
   処理を含む、請求項２記載のプログラム。
4. 前記特定する処理は、
   前記第１の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第１の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第１の計算ノードにおける前記メッセージの転送時間を特定し、又は前記第２の計算ノードにおける前記起点となる制御通信の送信時刻又は前記起点となる制御通信の受信時刻と、前記第２の計算ノードにおける前記メッセージの転送終了時刻との差に基づいて、前記第２の計算ノードにおける前記メッセージの転送時間を特定する、
   処理を含む、請求項２又は３記載のプログラム。
5. 前記メッセージの転送は、ＣＰＵコア間通信、インターコネクト、バス、ＬＡＮ、ＷＡＮ、インターネットのうち、少なくとも１つを用いて実行される、
   請求項２ないし４のうちいずれか１項に記載のプログラム。
6. 第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得する方法であって、
   前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信し、
   前記起点となる制御通信を、前記他方の計算ノードにおいて受信し、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出し、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する、
   処理、を有する方法。
7. 第１の計算ノードがメッセージの送信命令を実行し、第２の計算ノードがメッセージの受信命令を実行する場合に、前記メッセージの転送に関連する時間を取得するシステムであって、
   前記第１の計算ノード及び前記第２の計算ノードのうちの一方から他方に、前記メッセージの転送の開始の起点となる制御通信を送信する送信部と、
   前記起点となる制御通信を、前記他方の計算ノードにおいて受信する受信部と、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とを検出する時刻検出部と、
   少なくとも、前記起点となる制御通信の送信時刻と、前記起点となる制御通信の受信時刻とに基づいて、前記メッセージの送信命令及び前記メッセージの受信命令の各々における、前記メッセージの転送開始までに要する待ち時間及び／又は前記メッセージの転送に要する経過時間を特定する経過時間特定部と、
   を有するシステム。

Images