(57)【要約】  分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法であって、当該方法は、前記分散型環境において並列に代替実装パラメータをテストするステップと、タイムアウトメカニズムを提供するステップと、を有し、前記タイムアウトメカニズムは、テストのために許容される時間が終了したか、及び所定量の代替実装のための処理のテストが完了したか、という中断条件のうちの１又は複数が満たされるとテスト処理を中断し、前記タイムアウトメカニズムは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを有する、方法。
2016503213.tif 000002
【特許請求の範囲】
【請求項１】
分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法であって、当該方法は、前記分散型環境において並列に代替実装パラメータをテストするステップと、タイムアウトメカニズムを提供するステップと、を有し、前記タイムアウトメカニズムは、
テストのために許容される時間が終了したか、
所定量の代替実装のための処理のテストが完了したか、
という中断条件をチェックし、
前記中断条件のうちの１又は複数が満たされると、テスト処理を中断し、
前記タイムアウトメカニズムは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを有する、方法。
【請求項２】
前記タイムアウトメカニズムは、中断条件が満たされるまで前記分散型環境で実行されるソフトウェアタイムアウト領域を更に有し、実行ファイルは前記中断条件が満たされたとき前記ハードウェアインタフェースを呼び出す、請求項１に記載の方法。
【請求項３】
前記ソフトウェアタイムアウト領域は、アプリケーションプログラミングインタフェースであり、望ましくは前記コンピュータプログラムのソースコードの中に書き込まれる、請求項２に記載の方法。
【請求項４】
前記ソフトウェアタイムアウト領域は、後続の並列テスト処理が実行されるよう、前記テスト処理が中断された後に復旧できるよう設計される、請求項２又は３に記載の方法。
【請求項５】
前記ソフトウェアタイムアウト領域は、全ての完了した並列テスト処理の最小及び／又は最大完了時間の値を返す、請求項２乃至４のいずれか一項に記載の方法。
【請求項６】
前記分散型環境は、複数のコアを有し、前記テストは、前記複数のコアで並列に実行され、望ましくは前記コアは前記分散型環境のノードに一緒にグループ化される、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記ハードウェアインタフェースは、前記分散型環境の各ノードの制御部に含まれる、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記実行ファイルが前記ハードウェアインタフェースを呼び出すと、前記タイムアウトメカニズムは、命令パイプラインから前記タイムアウト領域に関連する命令を削除する、請求項２乃至５、又は請求項２に従属する請求項６乃至７のいずれか一項に記載の方法。
【請求項９】
前記タイムアウトメカニズムは、前記タイムアウト領域の始めをマークするために開始命令を、及び／又は前記中断を生じるためにタイムアウト命令を、送る、請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記タイムアウトメカニズムは、所定の割合の代替実装が完全に処理され、前記テストのために許容される時間が終了していないとき、前記テストを中断する、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記テストのために許容される時間は、より速い代替実装パラメータにのみ対応する処理を完了できるよう設計される、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
分散型環境においてコンピュータプログラムの実装パラメータをテストするアプリケーションプログラミングインタフェース（ＡＰＩ）であって、前記ＡＰＩは、
テストのために許容される時間が終了したか、
所定量の代替実装のテスト処理が完了したか、
という中断条件のうちの１又は複数が満たされると、前記分散型環境における代替実装パラメータの並列テストを中断するタイムアウトメカニズムを実装し、
前記ＡＰＩは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを呼び出す実行ファイルである、ＡＰＩ。
【請求項１３】
それぞれ複数のコアを有するコンピューティングノードの分散型環境の中のノードの制御部であって、前記制御部は、
前記分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法での使用のために構成されるハードウェアインタフェース、を有し、前記方法は、前記分散型環境における代替実装パラメータを並列テストするステップを有し、
前記ハードウェアインタフェースは、
テストのために許容された時間が終了したか、
所定量の代替実装のテスト処理が完了したか、
という中断条件のうちの１又は複数が満たされると前記テストを中断するよう構成される、
制御部。
【請求項１４】
それぞれ請求項１３に記載の制御部を有する複数のノード、を有する分散型コンピューティング環境。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラミングモデル、分散型コンピューティング、ノード間通信、及び高性能ＣＰＵ（central  processing  unit）命令セット拡張を含む高性能コンピューティング（high  performance  computing：ＨＰＣ）に関する。
【背景技術】
【０００２】
次第に、ソフトウェアは、自動調整のような種々の技術を用いて自動的にテストされ及び／又は向上されている。自動調整は、ソフトウェアを良好に実行させるために、該ソフトウェアを自動的に向上することができる。例えば、アプリケーションの自動調整フェーズは、ユーザの目的に最適な１つを識別するために、機能的に等価な実装を分析できる。最適化の重複概念では、（エネルギ使用、処理に要する時間、又は毎秒の符号小数点演算の数のような）動作パラメータに関連する目的関数は、適切に最大化又は最小化される。目的関数がプログラムの性能を測定する場合、目的関数の最適化はプログラムを「調整する」。同様に、アイテムの集合の中で指定された特性を有するアイテムを見付けるために探索フェーズがあっても良い。探索は、可能な実装／実行を識別し、又は利益の少ない実装を削除しても良い。見付かったアイテムが目的関数を最適化する場合、実行される探索は、最適化として見なすことができる。
【０００３】
これらのテスト技術のうちの任意のものは、実行ステージ中に又はソフトウェア開発及び使用の任意の他のステージで使用されても良い。
【０００４】
自動ソフトウェアテストは、分散型環境において特に価値がある。このような環境では、実行ファイルの処理スレッドが平行して自動的に走ることができる複数の処理要素又はコアが存在する。用語「処理要素」又は「コア」は、プログラムコード命令を実行するために必要なハードウェアリソースとして考えられる。
【０００５】
並列分散システムでは、分散型アルゴリズム（並列化ストラテジを用いてコードを実装する）及び／又はより低いレベルではカーネル（並列コンピューティングシステムのノードで実行できるコンパイルされたソフトウェアコード）を準備し及び選択する可能性がある。上述の及び他の使用例においてソフトウェア性能の向上の要求を満たすために効率的且つ迅速なテスト（例えば、自動調整、最適化、及び／又は探索の形式で）を提供することが望ましい。
【０００６】
多くの異なるハードウェア構成及びプログラミングモデルは、高性能コンピューティングに適用可能である。高性能コンピューティングへの現在一般的なアプローチは、それぞれマルチコアプロセッサ（又は「チップ」）を有する複数のノードが高速ネットワークにより相互接続されるクラスタシステムである。クラスタシステムは、一般的機能を実行するために既存のコードライブラリを利用して、ソースコードを書く人間のプログラマによりプログラミングできる。次に、ソースコードは、低級実行可能コード、例えば特定の命令セットを有するプロセッサ種類により実行可能なＩＳＡ（Instruction  Set  Architecture）レベルのコードに、又は特定のプロセッサ専用のアセンブリ言語にコンパイルされる。アセンブリコードを実行可能機械コードにアセンブリング（又は仮想機械の場合には、インタープリティング）する最終段階が存在する場合が多い。実行可能形式のアプリケーション（単に「実行ファイル」として参照される場合が多い）は、オペレーティングシステム（ＯＳ）の管理下で実行される。
【０００７】
記載の発明の理解を助けるために、当分野の幾つかの関連技術の概要を説明する。
【０００８】
複数のコアを有するコンピュータシステムのためのアプリケーションは、（Ｃ／Ｃ＋＋又はＦｏｒｔｒａｎのような）従来のコンピュータ言語で記述され、コンピュータにマルチコアの並列処理能力を活用させるためにライブラリにより補強されても良い。これに関し、通常、コアで動作する「プロセス」を参照する。
【０００９】
このようなライブラリの１つは、ＭＰＩ（Message  Passing  Interface）であり、分散メモリモデルを用い（各プロセスは各自のメモリ領域を有すると想定される）、プロセス間の通信を実現する。ＭＰＩは、プロセスのグループを定め区別できるようにし、複数のプロセス若しくは処理要素が一緒に動作可能なために重要な機能である所謂「バリア同期」のためのルーチンを含む。バリア同期は、全てのプロセスがプログラムの中の同じポイントに到達するまで、プログラムを実行する同期グループの中の全てのプロセスを保留する技術である。これは、実行を更に進める前にグループの全てのメンバにより呼び出されなければならないＭＰＩ関数呼び出しにより達成される。
【００１０】
既に言及したように、ＭＰＩは、各タスクが自身のローカルメモリを有する分散型メモリモデルを用いる。並列プログラミングへの別のアプローチは、複数の同時実行パス又は「スレッド」で命令を実行する得ために複数のプロセス又はコアが同じメモリ又はメモリ領域にアクセスできる共有メモリである。ＯｐｅｎＭＰはこのような共有メモリ処理モデルである。
【００１１】
同期グループは、マルチコアプロセッサの全てのコアにより構成されても良い。次に、バリア同期は、複数のコアからの出力を受信するオンチップ論理回路によるようなハードウェア形式でも可能である。これは、ソフトウェアに基づくバリアと比べて高速であるという利益をもたらす。
【００１２】
ＯｐｅｎＭＰは、プログラムが単一のプロセス又はスレッド（マスタスレッド）として実行を開始する所謂「fork−and−join」モデルを提供する。このスレッドは、並列化命令に遭遇するまで、順次命令を実行する。並列化命令に遭遇するポイントで、マスタスレッドは、プログラムの並列領域の並列ワーカスレッドのグループに分かれる。標準的に、各スレッドは個々のコアにより実行されるが、これは必須ではない。ワーカスレッドは、それらが並列領域の終わりに達するまで並列に命令を実行する。同期（上記を参照）の後、ワーカスレッドは、再び単一のマスタスレッドに結合して戻り、次の並列化命令に達するまで、順次的命令実行を続ける。
【発明の概要】
【課題を解決するための手段】
【００１３】
本発明の一態様によると、実施形態は、分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法であって、当該方法は、前記分散型環境において並列に代替実装パラメータをテストするステップと、タイムアウトメカニズムを提供するステップと、を有し、前記タイムアウトメカニズムは、テストのために許容される時間が終了したか、及び所定量の代替実装のための処理のテストが完了したか、という中断条件のうちの１又は複数が満たされるとテスト処理を中断し、前記タイムアウトメカニズムは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを有する、方法を提供する。
【００１４】
本発明のこの実施形態は、２つの異なる中断条件、したがって２つの異なる環境下でのテストをチェックできるという利点を有する。中断は、テストのために許容される時間が終了すると、行われる。追加で、中断は、所定量の、例えばある割合の代替実装、のテストが完了すると、行われる。所定の割合の代替実装は、数値として設定されても良い。したがって、最速オプション（代替実装）のみが望ましい場合、所定数の代替実装は１であっても良い。したがって、１つの完了のみが十分な／早期完了と考えられる。代替で、所定の割合は、２０個の並列テスト処理が行われている場合、１つの完了を与えるために、百分率の観点で、例えば５％のように直接的に設定されても良い。低速な処理が中断されるだけでなく、（決して成功して完了しない）任意の障害した処理も本方法を用いて効率的に中断できる。
【００１５】
本実施形態の重要な特徴は、タイムアウトメカニズムの一部としてのハードウェアインタフェースの使用である。ハードウェア支援中断は、テスト方法の効率を向上できる。
【００１６】
ハードウェアインタフェースは、ある種の「弱い」バリアとして機能する。これは、知られているバリア同期と異なり、各代替実装の完全な実行を待つ必要がなく、上述の条件に従って中断する。
【００１７】
上述のテスト方法は、自動調整、探索、又は最適化を含む任意の適切な形式のテストであっても良い。本願明細書における用語「実装パラメータ」の使用は、広義に解釈されるものとし、コンピュータプログラムを実装する及び／又は実行する際に取られる、例えば分散型アルゴリズム及び計算カーネルの選択を含む任意の値又は選択を包含する。
【００１８】
このような方法における後続のステップは、テストフェーズに従う実装パラメータを向上するために取られる。例えば、自動調整方法では、後続のステップは最適化を含んでも良い。
【００１９】
ハードウェアインタフェースとソフトウェア制御下のテストとの間の通信は、任意の都合の良い方法で行われる。幾つかの実施形態では、前記タイムアウトメカニズムは、中断条件が満たされるまで前記分散型環境で実行されるソフトウェアタイムアウト領域を更に有し、前記実行ファイルは前記ハードウェアインタフェースを呼び出す。
【００２０】
ソフトウェアタイムアウト領域実行可能コードは、テストの量を効率的に制限する。該コードは、コンピュータプログラムのソースコードの中に書き込まれ得る。例えば、ソフトウェアタイムアウト領域は、ＡＰＩ（application  programming  interface）であっても良い。望ましくは、ソフトウェアタイムアウト領域は、テスト処理が中断された後に復旧できるように設計される。したがって、後続の並列テスト処理を行うことができる。例えば、タイムアウト領域は、タイムアウト領域を出るとき割り当て解除を容易にするために、割り当てられた任意のメモリを登録しても良い。
【００２１】
例えば、コードは、アウトライン化された領域のメモリ割り当て及び／又は関数呼び出しに関連する特定の実装及び制限要件により、概略を示されても良い。本願明細書で用いられるように、用語「アウトライン（outlining）」は、インライン拡張／インライン化の逆である。アウトラインは、ＯｐｅｎＭＰの実装から知られている技術である。基本的に、タイムアウト領域が呼び出されると、制御は、分岐又は呼び出し命令によりその定義に変換される。
【００２２】
ソフトウェアタイムアウト呂域は、テストに有用な任意の値を返しても良い。一実施形態では、ソフトウェアタイムアウト領域は、全ての並列テスト処理の最小及び／又は最大完了時間の値を返す。最小又は最大完了時間を達成する処理は、ＭＰＩを用いて識別されても良い。
【００２３】
分散型環境は、複数の処理要素又はコアを有する任意のものであり得る。望ましくは、分散型環境は複数のコアを有し、テストは複数のコアで並列に実行される。好適な実施形態では、コアは、分散型環境のノードに一緒にグループ化される。
【００２４】
自身のコアのグループを有する単一のノードが存在し、タイムアウトメカニズムは単一のノードにのみ適用しても良い。代替で、タイムアウトメカニズムは、複数のコアのそれぞれに別個に適用できる。ノードは通信しても良く（例えば、スーパーコンピュータの中のノードとして相互作用する）、最小及び最大完了時間又は他の値は、それらが重要な場合にはノード間比較で用いられても良い。
【００２５】
複数のノードを有する環境では、（上述の様々な）別個のハードウェアインタフェースは、分散型環境の各ノードに含まれても良い。代替で、単一のハードウェアインタフェースは、各コアについて１つ、コンポーネント部分の中に設けられても良い。
【００２６】
有利なことに、実行ファイルがハードウェアインタフェースを呼び出すとき、タイムアウトメカニズム、例えばハードウェアインタフェースは、命令パイプラインからタイムアウト領域に関連する命令を除去する。他の命令は影響されず、したがって、ノードの状態は、タイムアウト領域の後に計算を継続する準備が出来ている。
【００２７】
望ましくは、タイムアウトメカニズム（例えば実行ファイル）は、タイムアウト領域の開始点をマークするために開始命令を、及び／又は中断を生じるためにタイムアウト命令を、送る。命令は、ＲＩＳＣ（reduced  instruction  set  computer）命令のようなＣＰＵ命令であり得る。それらは、テストが走っているコアへ送られても良い。
【００２８】
幾つかの環境では、タイムアウトメカニズムは、全ての代替実装が処理されると、テストを中断する。したがって、中断は、テストのために許容される時間が終了していないときに生じ得る。例えば、３０分のタイムアウトが設定されても良いが、全てのオプションが２０分以内に処理される。
【００２９】
他の環境では、テストのために許容される時間は、高速な代替実装パラメータのみに対応する処理の完了を許容するよう設計されても良い。つまり、全てのテスト処理が完了するものではない。幾つかの低速な処理は完了しない。同等に、任意の障害のある処理は完了しない。勿論、幾つかの領域で、１００％の完了が所定割合の代替実装と考えられるように、全部の処理が終了するという要件であっても良い。
【００３０】
本発明の更なる態様の一実施形態によると、分散型環境においてコンピュータプログラムの実装パラメータをテストするアプリケーションプログラミングインタフェース（ＡＰＩ）であって、前記ＡＰＩは、次の中断条件、テストのために許容される時間が終了した、所定量の代替実装のテスト処理が完了した、のうちの１又は複数が満たされると、前記分散型環境における代替実装パラメータの並列テストを中断するタイムアウトメカニズムを実装し、前記ＡＰＩは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースの呼び出しによりテストを開始する、ＡＰＩが提供される。
【００３１】
本発明の更に別の態様の一実施形態によると、それぞれ複数のコアを有するコンピューティングノードの分散型環境の中のノードの制御部であって、前記制御部は、前記分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法での使用のために構成されるハードウェアインタフェース、を有し、前記方法は、前記分散型環境における代替実装パラメータを並列テストするステップを有し、前記ハードウェアインタフェースは、次の中断条件のうちの１又は複数が満たされると前記テストを中断するよう構成される、テストのために許容された時間が終了した、所定量の代替実装のテスト処理が完了した、制御部が提供される。
【００３２】
分散型コンピューティング環境であって、それぞれ上述のような制御部を含む複数のノードを有する、分散型コンピューティング環境が提供されても良い。
【００３３】
上述の態様のうちの任意のものの特徴及び下位の特徴は、任意の方法で結合されても良い。
【図面の簡単な説明】
【００３４】
本発明の前述の構成及び好適な特徴は、純粋に例として添付の図面を参照して以下に説明される。
【図１】従来技術のソフトウェアテストにおける処理を示すフローチャートである。
【図２】本発明の一実施形態によるソフトウェアテストの処理を示すフローチャートである。
【図３】分散型環境における相互接続を実施するコンポーネントの図である（電気又は光ケーブルのネットワークは図示しない）。
【図４】ソフトウェアによる及びハードウェアによる集合的通信処理の間の差を示す概略図である。
【図５】本発明の実施形態の主な技術的側面を示すフローチャートである。
【図６】本発明の実施形態の技術的実装のための異なるコンポーネントの相互作用を示すブロック図である。
【図７】タイムアウトが生じ得る３つの異なる方法を示すフロー図である。
【図８】タイムアウト領域のソフトウェア実装を記述する純粋に説明目的で使用されるフローチャートである。
【発明を実施するための形態】
【００３５】
図１は、発明者等に知られている従来技術で用いられるようなトライアルのソフトウェアに基づくストラテジを示す。ステップＳ１０で、トライアルが開始し又は続けられる。ステップＳ２０で、時間期限が終了したか否かが決定される。終了した場合、ステップＳ４０で、メッセージは、トライアルをキャンセルするために手動で送信される。終了していない場合、ステップＳ３０で、要求されたサブセットが完了したか否かが決定される。ステップＳ３０又はＳ４０の後に、場合に応じて、ステップＳ５０で、キャンセルメッセージが受信されたか否かが決定される。キャンセルメッセージは、「CancelTrials」という名称の変数が０（偽）から１（真）に変更されるように、あるノードが第２のノードへデータを送信することであっても良い。
【００３６】
キャンセルメッセージが受信された場合、処理はステップＳ６０に続く。受信されない場合、トライアルはステップＳ１０で続けられる。ステップＳ６０で、トライアルは手動でキャンセルされ、復旧する。ステップＳ７０で、プログラムは続けられる。ここで、用語「手動で」は、アプリケーションのエンドユーザであっても良いアプリケーション開発者により適用されることを意味し得る。開発者の意志は、プログラム（つまり、アプリケーションソフトウェア）の中に実装される。
【００３７】
図２は、本発明の実施形態の新規な分散型ハードウェア支援タイムアウト装置及び方法を示す同様のフローチャートを示す。実施形態は、トライアル及び復旧のハードウェアに支援された中断を可能にする。従来技術は、低速なソフトウェアに基づくストラテジを利用するため、これらの本発明の実施形態の性能を達成できない。
【００３８】
図２で、Ｓ８０は、トライアルの開始又は継続である。ステップＳ９０で、時間期限が経過したか否かが決定される。経過した場合、ステップＳ１１０で、プロセッサは、トライアルを自動的に中断し、復旧する。経過していない場合、ステップＳ１００で、要求されたサブセットが完了したか否かが決定される。要求されたサブセットが完了していない場合、ステップＳ８０でトライアルは続けられる。要求されたサブセットが完了した場合、ステップＳ１１０で、トライアルの自動中断及び復旧がある。ステップＳ１２０で、プログラムは継続する。
【００３９】
従来技術と本発明の本実施形態との間の別の差異は、従来技術がトライアルのキャンセルのための手動メッセージの送信及び手動キャンセルを必要とすることである。これに対し、本発明の実施形態では、トライアルは自動的に中断される。
【００４０】
＜本発明の実施形態の使用＞
本発明の実施形態は、分散型コンピュータで及び独立型処理要素で長時間を要する自動調整及び他のテスト方法の問題を解決できる。従来技術の構成は、この問題を解決できない。従来技術では、分散型アルゴリズム及び計算カーネルの準備及び選択に僅かな柔軟性しかない。非常に長い実験に基づく試みが必要とされ、このような試みは、自動調整、最適化、又は探索のような方法を実行するのに要する時間を最適化できない。
【００４１】
＜多数の高レベル分散型並列アルゴリズムのテスト＞
多数の異なる高レベル分散型並列アルゴリズムは、最高性能を有するアルゴリズムを見付けるために、本発明を用いて実験に基づきテストされても良い（恐らく干渉しないように並列に走るよう配置される）。本発明を用いる利点は、テストのソースコード実装を簡単にすること、及び非効率なアルゴリズムを素早く拒否するためにハードウェアサポートを用いて効率的に最終的な最適化アルゴリズムに達することを含む。
【００４２】
＜１又は複数のコンピュータ及び／又はスーパーコンピュータの１又は複数のノードの多数の異なる計算カーネルのテスト＞
多数の異なる計算カーネルは、最高性能を有する計算カーネルを見付けるために、本発明を用いて実験に基づきテストされても良い（通常、干渉しないように並列に走るよう配置される）。本発明を用いる利点は、実験に基づく自動調整フレームワークソースコードを簡略化すること、及び非効率なカーネルを素早く拒否するためにハードウェアサポートを用いて最終的な最適化カーネルにより迅速に到達することを含む。
【００４３】
＜最適化処理の実行＞
並列アルゴリズムは、本発明の実施形態を用いて分岐限定法を実行しても良い。この方法は、全ての候補解の体系的列挙を有する種々の最適化問題の最適解を見付ける一般的アルゴリズムである。無益な候補のサブセットは、最適化中の数量の推定上限及び下限を用いることにより集団で廃棄される。
【００４４】
＜探索処理の実行＞
並列アルゴリズムは、本発明の実施形態を用いて木枝刈り探索を実行しても良い。枝刈り技術は、少ない支援しか提供しない木の部分を除去することにより、決定木のサイズを縮小する。
【００４５】
＜ハードウェアに支援される耐障害性の弱バリア＞
本発明の実施形態は、計算の完了のために必要な処理のサブセットのみを継続する仕様を可能にする。この仕様は、テストにおける柔軟性をもたらし、障害に苦しんでおりバリアの完了ポイントに達しない又は妥当な時間内にそのポイントに到達しないであろう処理の完了を待機するのを回避する。
【００４６】
＜実装シナリオ＞
本発明の１つの有利な実装は、Ｆａｔ−Ｔｒｅｅ又はＴｏｒｕｓ  Ｔｏｐｏｌｏｇｙモデルのようなモデルを用いて、多くの相互接続されたノードを有するスーパーコンピュータにおけるものである。ノード間の通信を可能にする相互接続を実施するために必要な２つの基本的な種類のコンポーネントは、ネットワークルータ及びネットワークインタフェースコンポーネントである。これらは、図３のチップ上に示されるが、それらの構成は例によって大きく変化する。例示的な相互接続は、ＱＣＤＯＣ（Quantum  Chromodynamics  on  a  Chip）及びＧｅｍｉｎｉ機械、及び特にFujitsu、Mellanox及びIntelにより開発された技術により使用されるものを含む。
【００４７】
追加機能は、相互接続により提供されても良い。この一例は、同期化動作のためのバリヤインタフェース（ＢＩ）である。図４は、ソフトウェア及びハードウェア（ＢＩ）を用いる集合的通信処理の間の差異を示す。集合的通信がソフトウェアにより処理されるとき、受信及び送信データの両方が、大きな待ち時間を生じる主メモリを通過する。ＢＩによる通信処理は、主メモリアクセスを必要としないので、小さい待ち時間を達成する。
【００４８】
ソフトウェアによる集合的通信処理は、ＯＳジッタによる影響を受ける。ＯＳジッタは、並列計算による計算プロセス間の処理における揺らぎである。これは、デーモンプロセス等に切り替えるプロセスによる計算処理への割り込みにより生じる。標準的な割り込みは、数十マイクロ秒〜数ミリ秒継続するが、集合的通信では、多くのノードはデータを待ち、処理の遅延は伝搬して多くのノードに影響を与える。これは、性能低下を更に深刻にする。これに対し、ハードウェアにより処理される集合的通信は、ＯＳジッタに少ししか影響しないという利点を有する。
【００４９】
本発明の実施形態は、上述の弱いバリアのようなバリアインタフェースのような既存のハードウェアバリアコンポーネントを追加で使用する可能性がある。これは、プロセッサのサブセットのみがテストのための予め完了した場合でも、後続のテスト処理の開始を可能にする。更に高い確実性で、更なるコンポーネントである「タイムアウトインタフェース（ＴＩ）」が存在する。ＴＩは、弱いバリアとして動作し、ＢＩの隣に位置付けられても良く、タイムアウト及び十分な完了を認識しても良い。
【００５０】
図５は、本実施形態の３個の主な要素を示す。
【００５１】
１．「MPEX_ITimeout」と称されるＣ／Ｃ＋＋ＡＰＩ（Application  Programming  Interface）
２．通信ハードウェア機能
３．コンピュータプロセッサ機能及び命令。
【００５２】
ステップＳ２００で、実行前準備が行われる。適切なＡＰＩを用いるソースコードは、ＡＰＩを認識するコンパイラを用いてコンパイルされる。
【００５３】
ステップＳ２１０で、実行ファイルは、本例では相互接続制御部の適切なハードウェアの弱いバリアを呼び出す。
【００５４】
ステップＳ２２０で、実行ファイルは、ＣＰＵタイムアウト命令のような命令を実行させる。タイムアウトコード領域は、全領域のタイムアウト期間、及び／又は「早期完了／十分な完了」と見なされる完了の数を、タイムアウトインタフェースへ送信しても良い。タイムアウトインタフェースは、十分な完了が生じたという通知をプロセッサへ送信しても良い。したがって、幾つかの構成では、実際のタイミングはプロセッサで生じるので、いかなるタイミングもタイムアウトインタフェース（ＴＩ）により実行されない。他の構成では、タイミングはＴＩにおいて生じ得る。これは、追加機能を有する「弱いバリア機能」を拡張しても良い。
【００５５】
図２に実行がより詳細に示される。つまり、Ｓ９０又はＳ１００の条件のいずれかが満たされる場合、自動中断がある。
【００５６】
タイムアウト領域は、任意の適切な方法で、例えば従来のプログラミング言語及び統合関数呼び出しを用いて、ソースコードに書き込まれても良い。これは、ＭＰＩ又はＯｐｅｎＭＰコードの形式であっても良い。コードの実例は以下に示される。
【００５７】
Ｃ／Ｃ＋＋ＡＰＩは次の関数を有しても良い。
【数１】
2016503213.tif 000003
【００５８】
これはＭＰＩコードの実例である。代替で、プログラム機能は、以下に示すＯｐｅｎＭＰの実例で提供されても良い。
【数２】
2016503213.tif 000004
【００５９】
Ｆｏｒｔｒａｎ  ＭＰＩは、以下に示すようなＭＰＩの中のＣ／Ｃ＋＋関数に対応するプロシジャを有し得る。
【数３】
2016503213.tif 000005
【００６０】
タイムアウト領域は、所望のときに実行され中断できるよう説明される。要求される柔軟性に依存して多数の実装の可能性が可能である。これらを以下に示す。
【表１】
2016503213.tif 000006
【００６１】
タイムアウト領域は、「num_early_completion」プロセスの全部が完了するまで、又は「duration」秒が経過するまで、各スーパーコンピュータノードで実行される。「duration」秒があるノードで経過した場合、タイムアウト領域は領域の実行を中断することにより完了される。計算がタイムアウト領域の中断から復旧できることを保証することは、プログラマの責任である。
【００６２】
タイムアウト領域が全てのノードで実行するのを終了した後に、「min_max_time」はダブル（「min_max」に依存して計算の最小又は最大時間を指定する）又は２ダブルのアレイ（「min_max」の適切な選択のために）を指す。
【００６３】
ハードウェアタイムアウト機能は、本願明細書ではこれらの特定の例はタイムアウトインタフェースとして参照され、ノードに組み込むことができる。バリアインタフェースと似ているが、タイムアウト領域を完了するノードのサブセットと共に完了できる。これは、高レベルのソフトウェアの中で非効率な「MPI_Cancel」呼び出しの必要が無く、タイムアウト領域の実行の迅速な中止を保証する。タイムアウトインタフェースは、付属ＣＰＵと直接通信し、ハードウェア支援中断を生じる。したがって、タイムアウト領域に属する全ての命令は、他の命令に影響を及ぼさずに及びＣＰＵをタイムアウト領域の後に計算を開始する準備のできた状態のままにして、パイプラインから削除される。図６は、従来技術と本発明との間の幾つかの相違を明らかにする。図７は、タイムアウトが生じ得る３つの異なる方法を示す。
【００６４】
図６は、本発明の実施形態の実装のために必要な装置の異なるコンポーネントの相互作用を示す任意のレイアウトのブロック図である。従来技術に対する１つの相違を明確化するために、新規な部分は強調表示される。依然のように、図は、特定の実装を表すが、通常、任意の弱いハードウェアバリア及びタイムアウト命令に適用可能である。
【００６５】
図６は、タイムアウト領域アウトライン１００、及びタイムアウトインタフェース１１０の実行へのそのリンクを示す。通常の通信タイムアウトは、１２０として含まれ、通常のＣＰＵ機能１４０にリンクされる。他方で、タイムアウトインタフェース実行１１０は、ＣＰＵタイムアウト命令１５０にリンクされる。また、これらは、タイムアウト領域からの早期終了の後の復旧１６０にリンクされる。アウトライン及び復旧の概念は通常知られているので、特に新規として示される図の部分１３０は、タイムアウトインタフェース及びＣＰＵタイムアウト命令を用いる実行である。
【００６６】
図７は、タイムアウトがプロセッサでの実行中に生じ得る３つの異なる方法を示すフロー図である。ステップＳ３００で、プロセッサの実行は、タイムアウト基準に達するまで継続する。３つの異なるタイムアウト基準があり、それぞれそれ自体のパスを有する。パス１は、ステップＳ３１０における実行完了による早期タイムアウトである。これは、全てのプロセスである十分な完了（所定の割合は１００％である）の場合を含み得る。タイムアウト時間限度が経過する前に、実行が全てのプロセスで完了する場合、領域を中断する任意の特別な手順は不要であり、ユーザ開発者の割り当て解除が実行されているだろう。基本的に、中断及び割り当て解除プロセスは、メモリリークの幾つかの場合を防ぐ幾つかの正しい追加割り当て解除が生じる場合を除き、従来技術と大きく異ならない。メモリが割り当てられるポイントで、タイムアウト領域を出るとき、中断及び割り当て解除プロセスは、割り当て解除のために登録される。これは、任意のポイントでタイムアウト領域を終了する準備ができていなければならないからである。ユーザ開発者が割り当て解除を誤って省略してしまう場合があるので、割り当て解除は以前に正しくない場合がある。パス３は、ステップＳ３３０で開始し、タイムアウトインタフェースが十分な完了によりトリガされていることを示す。これは、十分な完了が全てのプロセス（１００％）として指定される場合を除いても良い。パス２では、ステップＳ３２０で、時間期間の経過によるＣＰＵ命令タイムアウトがある。代替で、タイムアウトインタフェース自体が、タイミング機能を有しても良い。パス１及び２は、ステップＳ３４０におけるタイムアウトインタフェースのシグナリングを生じる。これは、パス３では（タイムアウトインタフェースが、ステップＳ３５０で十分な完了による既にトリガされたタイムアウトであるとき）省略される。したがって、ステップＳ３４０及びＳ３３０の両方は、中断のステップＳ３５０、任意の必要なメモリの割り当て解除、及び他のこのような復旧を生じる。処理は、ステップＳ３６０で、タイムアウト領域の後に実行を続ける。
【００６７】
図８は、説明目的でのみ、タイムアウト領域のソフトウェアのみの実装を示すフローチャートである。ユーザの計算は、「計算」ｐｔｈｒｅａｄで概要を示される。特定の条件下で「計算」ｐｔｈｒｅａｄをキャンセルする「制御」ｐｔｈｒｅａｄが生成される。メモリ割り当て関数ｍａｌｌｏｃ、ｒｅａｌｌｏｃ及びｆｒｅｅは、例えばＧＮＵ  ｇｌｉｂｃ  ｈｏｏｋｓ（http://www.gnu.org/software/libc/manual/html_node/Hooks−for−Malloc.html）を用いて置き換えられる。したがって、メモリの割り当ては、pthread_cleanup_pushの呼び出しを生じ、「計算」ｐｔｈｒｅａｄがキャンセルされる場合、メモリは適切に解放される（freed）。
【００６８】
本発明を実施するために、ハードウェアイベントは、実行中プログラムの動作を変更できなければならない。これは、多数の方法で行われ得る。単純な実装は、図８に示すような「計算」及び「制御」スレッド、及び十分に多くのトライアルが完了しているときを示すために配信される予め決められたメッセージと等価である。
【００６９】
本発明の実施形態においてハードウェアのサポートを有する主な利点は、メッセージのソフトウェアポーリングと比べて待ち時間を短縮することである。このような待ち時間の利益は、前に参照したスライド１５に示される。スライド１５は、相互接続ハードウェアサポートを用いる２つの代替の通知方式を示す（ソフトウェア等価物は、ＣＰＵでより多くのサイクルを占有し、更に大きな待ち時間を与える）。
【００７０】
技術的観点から、標準的なハードウェアバリアに対する主な違いは、プロセス／スレッドの状態を追跡し続ける必要であり、バリアに到達しないスレッドの必要な「ハウスキーピング処理」を実行する。当業者は、例えば割り込みハンドラ、信号ハンドラ、setjmp/longjmpのような例外及び機能を用いる弱いバリアの異なる詳細な実装があることを理解するだろう。
【００７１】
図８は、ソフトウェア実装で、計算スレッドが、キャンセルされたか否かを周期的に調べるために挿入されたコードを有することを提案する。別の実装では、計算スレッドはそのまま進み、制御スレッドは、信号／例外／割り込みを計算スレッドへ送り、次に計算スレッドはクリーンアップし終了する。
【００７２】
＜本発明の実施形態の可能な利点のまとめ＞
１．本発明の実施形態は、アプリケーションの自動調整フェーズの効率を向上し、最終的に、自動調整のための従来のアプローチに比べて短い時間期間でアプリケーションの最適化をもたらす。
２．本発明の実施形態は、自動調整及び最適化中に、ハードウェアに基づく分散型サポートをユーザに与えることができる。
３．本発明の実施形態は、自動調整及び最適化中に、階層的な（スーパーコンピュータ全体及びローカルノードの）ハードウェアに基づくサポートをユーザに与えることができる。
４．本発明の実施形態は、容易なプログラミングを可能にするプログラミングモデルを提供できる。つまり、先に説明したＡＰＩをコーディングするストラテジは、本発明により提供される機能にアクセスする現実的な方法を示す。これらのストラテジは、（ＦＰＧＡ及びＧＰＧＰＵの不慣れなプログラミングとは対称的に）現在のプログラマにとって親しみがある。
５．本発明の実施形態は、多くの異なるレベルの計算システム装置を解決できる。例は、ソフトウェアレベルのコンパイル時間、ＣＰＵハードウェアレベルのタイムアウト、（異なるチップだが同じ回路基板上のＣＰＵと同じチップの）ルーティング要素レベルのタイムアウト、及び実行時間ソフトウェアレベルの計算の復旧を含む。
【図１】
2016503213.tif 000007
【図２】
2016503213.tif 000008
【図３】
2016503213.tif 000009
【図４】
2016503213.tif 000010
【図５】
2016503213.tif 000011
【図６】
2016503213.tif 000012
【図７】
2016503213.tif 000013
【図８】
2016503213.tif 000014
【手続補正書】
【提出日】平成27年12月1日(2015.12.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法であって、当該方法は、前記分散型環境において並列に代替実装パラメータをテストするステップと、タイムアウトメカニズムを提供するステップと、を有し、前記タイムアウトメカニズムは、
テストのために許容される時間が終了したか、
所定量の代替実装のための処理のテストが完了したか、
という中断条件をチェックし、
前記中断条件のうちの１又は複数が満たされると、テスト処理を中断し、
前記タイムアウトメカニズムは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを有する、方法。
【請求項２】
前記タイムアウトメカニズムは、中断条件が満たされるまで前記分散型環境で実行されるソフトウェアタイムアウト領域を更に有し、実行ファイルは前記中断条件が満たされたとき前記ハードウェアインタフェースを呼び出す、請求項１に記載の方法。
【請求項３】
前記ソフトウェアタイムアウト領域は、アプリケーションプログラミングインタフェースであり、望ましくは前記コンピュータプログラムのソースコードの中に書き込まれる、請求項２に記載の方法。
【請求項４】
前記ソフトウェアタイムアウト領域は、後続の並列テスト処理が実行されるよう、前記テスト処理が中断された後に復旧できるよう設計される、請求項２又は３に記載の方法。
【請求項５】
前記ソフトウェアタイムアウト領域は、全ての完了した並列テスト処理の最小及び／又は最大完了時間の値を返す、請求項２乃至４のいずれか一項に記載の方法。
【請求項６】
前記分散型環境は、複数のコアを有し、前記テストは、前記複数のコアで並列に実行され、望ましくは前記コアは前記分散型環境のノードに一緒にグループ化される、請求項１乃至５のいずれか一項に記載の方法。
【請求項７】
前記ハードウェアインタフェースは、前記分散型環境の各ノードの制御部に含まれる、請求項１乃至６のいずれか一項に記載の方法。
【請求項８】
前記実行ファイルが前記ハードウェアインタフェースを呼び出すと、前記タイムアウトメカニズムは、命令パイプラインから前記タイムアウト領域に関連する命令を削除する、請求項２乃至５、又は請求項２に従属する請求項６乃至７のいずれか一項に記載の方法。
【請求項９】
前記タイムアウトメカニズムは、前記タイムアウト領域の始めをマークするために開始命令を、及び／又は前記中断を生じるためにタイムアウト命令を、送る、請求項１乃至８のいずれか一項に記載の方法。
【請求項１０】
前記タイムアウトメカニズムは、所定の割合の代替実装が完全に処理され、前記テストのために許容される時間が終了していないとき、前記テストを中断する、請求項１乃至９のいずれか一項に記載の方法。
【請求項１１】
前記テストのために許容される時間は、より速い代替実装パラメータにのみ対応する処理を完了できるよう設計される、請求項１乃至１０のいずれか一項に記載の方法。
【請求項１２】
分散型環境においてコンピュータプログラムの実装パラメータをテストするアプリケーションプログラミングインタフェース（ＡＰＩ）であって、前記ＡＰＩは、
テストのために許容される時間が終了したか、
所定量の代替実装のテスト処理が完了したか、
という中断条件のうちの１又は複数が満たされると、前記分散型環境における代替実装パラメータの並列テストを中断するタイムアウトメカニズムを実装し、
前記ＡＰＩは、ハードウェア支援中断を生じるよう構成されるハードウェアインタフェースを呼び出す実行ファイルである、ＡＰＩ。
【請求項１３】
それぞれ複数のコアを有するコンピューティングノードの分散型環境の中のノードの制御部であって、前記制御部は、
前記ノードへの及び前記分散型環境への接続と、
前記分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法での使用のために構成されるハードウェアインタフェースと、を有し、前記方法は、前記分散型環境における代替実装パラメータを並列テストするステップを有し、
前記ハードウェアインタフェースは、
テストのために許容された時間が終了したか、
所定量の代替実装のテスト処理が完了したか、
という中断条件のうちの１又は複数が満たされると前記テストを中断するよう構成される、
制御部。
【請求項１４】
分散型コンピューティング環境であって、それぞれ制御部を有する複数のノードを有し、前記制御部は、
前記ノードへの及び前記分散型環境への接続と、
前記分散型環境におけるコンピュータプログラムの実装パラメータをテストする方法での使用のために構成されるハードウェアインタフェースと、を有し、前記方法は、前記分散型環境における代替実装パラメータを並列テストするステップを有し、
前記ハードウェアインタフェースは、
テストのために許容された時間が終了したか、
所定量の代替実装のテスト処理が完了したか、
という中断条件のうちの１又は複数が満たされると前記テストを中断するよう構成される、
分散型コンピューティング環境。
【国際調査報告】
2016503213.tif 000015
2016503213.tif 000016
2016503213.tif 000017