JP2010134614A - 並列化処理方法、システム、及びプログラム - Google Patents

Abstract

【課題】マルチプロセッサ環境で、個々のプロセッサに処理をアサインするためのクラスタ生成の際に、繰り返し実行される処理の高速化を図る。
【解決手段】フルビークル・シミュレーション・システムなどの場合、強連結成分によってクラスタを形成すると、１つのクラスタ中にブロックが、所定の個数以上あるとか、１つのクラスタの期待される処理時間が、所定の閾値を超えるなどの肥大クラスタであると同定されたクラスタに対しては、展開(unrolling)処理が適用され、肥大クラスタの処理を複数個コピーして、それを個別のプロセッサに割当てる。これにより、複数のプロセッサ上でパイプライン的に処理が進み、処理を高速化できるが、繰り返し実行される肥大クラスタのある一回の処理結果が、それ以前の処理結果に依存することがある場合には、実行に必要な入力などの値は、ある予測に基づき生成し、肥大クラスタを投機的に実行する。
【選択図】図５

Description

この発明は、マルチプロセッサ・システムにおいて、プログラムの実行を高速化する技法に関する。

近年、科学技術計算、シミュレーションなどの分野で、複数のプロセッサをもつ、いわゆるマルチプロセッサ・システムが使用されている。そのようなシステムでは、アプリケーション・プログラムは、複数のプロセスを生成して、個別のプロセッサに、プロセスを割り当てる。それらのプロセッサは、例えば、共有のメモリ空間を利用して互いに通信しながら、処理を進める。

最近になって特に盛んに開発されるようになってきたシミュレーションの分野として、ロボット、自動車、飛行機などのメトカトロニクスのプラントのシミュレーション用ソフトウェアがある。電子部品とソフトウェア技術に発展の恩恵により、ロボット、自動車、飛行機などでは、神経のように張り巡らされたワイヤ結線や無線ＬＡＮなどを利用して、大部分の制御が電子的に行われる。

それらは、本来的には機械的装置であるのに、大量の制御ソフトウェアをも内蔵している。そのため、製品の開発に当たっては、制御プログラムの開発とそのテストに、長い時間と、膨大な費用と、多数の人員を費やす必要が出てきた。

このようなテストにために従来行われている技法として、ＨＩＬＳ(Hardware In the Loop Simulation)がある。特に、自動車全体の電子制御ユニット（ＥＣＵ）をテストする環境は、フルビークルＨＩＬＳと呼ばれる。フルビークルＨＩＬＳにおいては、実験室内で、本物のＥＣＵが、エンジン、トランスミッション機構などをエミュレーションする専用のハードウェア装置に接続され、所定のシナリオに従って、テストが行われる。ＥＣＵからの出力は、監視用のコンピュータに入力され、さらにはディスプレイに表示されて、テスト担当者がディスプレイを眺めながら、異常動作がないかどうか、チェックする。

しかし、ＨＩＬＳは、専用のハードウェア装置を使い、それと本物のＥＣＵの間を物理的に配線しなくてはならないので、準備が大変である。また、別のＥＣＵに取り替えてのテストも、物理的に接続し直さなくてはならないので、手間がかかる。さらに、本物のＥＣＵを用いたテストであるため、テストに実時間を要する。従って、多くのシナリオをテストすると、膨大な時間がかかる。また、ＨＩＬＳのエミュレーション用のハードウェア装置は、一般に、非常に高価である。

そこで近年、高価なエミュレーション用ハードウェア装置を使うことなく、ソフトウェアで構成する手法が提案されている。この手法は、ＳＩＬＳ(Software In the Loop Simulation)と呼ばれ、ＥＣＵに搭載されるマイクロコンピュータ、入出力回路、制御のシナリオ、エンジンやトランスミッションなどのプラントを全て、ソフトウェア・シミュレータで構成する技法である。これによれば、ＥＣＵのハードウェアが存在しなくても、テストを実行可能である。

このようなＳＩＬＳの構築を支援するシステムとして例えば、CYBERNET SYSTEMS CO.,LTD.から入手可能なシミュレーション・モデリング・システムである、MATLAB(R)/Simulink(R)がある。MATLAB(R)/Simulink(R)を使用すると、図１に示すように、画面上にグラフィカル・インターフェースによって、機能ブロックA,B,...,Mを配置し、矢印のようにその処理の流れを指定することによって、シミュレーション・プログラムを作成することができる。

こうして、MATLAB(R)/Simulink(R)上で、機能ブロックA,B,...,Mなどのブロック線図が作成されると、Real-Time Workshop(R)の機能により、等価な機能のＣ言語のソース・コードに変換することができる。このＣ言語のソース・コードをコンパイルすることにより、別のコンピュータ・システムで、ＳＩＬＳとして、シミュレーションを実行することができる。

特に、別のコンピュータ・システムが、マルチプロセッサ・システムである場合、可能な限り、処理を分割して、個別のプロセッサに、別々のプロセスを割り当てて並列処理する方が、処理速度の向上に有利である。

そこで、図２に示すように、機能ブロックA,B,...,Mを、クラスタ２０２、２０４、２０６、２０８及び２１０のように複数のクラスタに分け、それぞれを個別のＣＰＵにアサインする技法が従来より実施されている。このようなクラスタリングのために、例えば、コンパイラの技術で知られている強連結成分の検出などの技法が用いられる。クラスタリングする主要な目的は、同一クラスタ内の機能ブロックの通信コスト削減である。

ところが、図２に示すように、各機能ブロック間には依存関係が存在し、これらの依存関係を破るような並列化はできないため、処理の並列化に制約があった。

特開平９−９７２４３号公報は、マルチプロセッサシステムにおいて並列タスクで構成されたプログラムのターンアラウンドタイムを短縮することを課題とするものであり、開示されているシステムにおいて、並列タスクで構成されるプログラムのソースプログラムをコンパイラがコンパイルして目的プログラムを生成し、コンパイラは、並列タスクの各タスク間で行われるタスク間通信のデータ量を保持するタスク間通信量テーブルを生成する。タスクスケジューラは、タスク間通信量テーブルとマルチプロセッサシステムの全プロセッサの組における単位データ当たりのデータ通信時間を定義するプロセッサ通信コストテーブルとからタスク間通信の通信時間が最短となるプロセッサを並列タスクのタスクに割り当てる旨決定し、プロセッサ管理テーブルに登録する。

特開平９−１６７１４４号公報は、複数種類の演算手順、および、プロセッサ間での通信処理に対応する、複数種類の通信手順を記述した、並列処理を行なうための並列プログラムを変更する方法であって、現在使用している通信手順にしたがって行なわれている通信処理の通信量を増加したと仮定すると、前記並列処理の開始から終了までの時間が短くなる場合、並列プログラム内での通信手順の並べ替えを行ない、２以上の通信手順を合体するように、記述内容を変更する、プログラム作成方法を開示する。

特開２００７−０４８０５２号公報は、並列処理を最適化するコンパイラに関するものであって、コンパイラは、対象プログラムを実行するプロセッサ・コアの個数である実行コア数を記録している。コンパイラは、まず、対象プログラムの中から単一のプロセッサ・コアで連続して実行すべき実行パスの候補である支配的パスを検出する。次に、実行コア数以下の数の支配的パスを選択することによりマルチコア・プロセッサにおいて並列にまたは連続して実行すべきタスクのクラスタを生成する。次に、生成されたクラスタ毎に、実行コア数以下の１つまたは複数の自然数の各々について、当該クラスタを当該自然数に等しい個数のプロセッサ・コアで実行した場合の実行時間を算出する。そして、算出された実行時間に基づいて各クラスタの実行のために割り当てるべきプロセッサ・コアの個数を選択する。

特開平９−９７２４３号公報 特開平９−１６７１４４号公報 特開２００７−０４８０５２号公報

しかし、上記従来の技術は、依然として、機能ブロック間の依存関係による処理の並列化の制約に対する解決策を与えるものではない。本発明者は、特に、繰り返し実行される処理が処理のボトルネックであり、そこを並列化することが処理の高速化に貢献する程度が大きいと考えた。

従って、本発明の目的は、マルチプロセッサ環境で、個々のプロセッサに処理をアサインするためのクラスタ生成の際に、繰り返し実行される処理の高速化を図るための技法を提供することにある。

本発明の他の目的は、典型的にはブロック線図であらわされるような、複数のブロックとそれを接続するフローの辺からなるグラフ構造をもち、それらが繰り返し実行される処理プログラムのクラスタリング及び並列化実行に適合する技法を提供することにある。

本発明の更に他の目的は、マルチプロセッサ環境で、自動車のフルビークル・シミュレーション・システムに適合する、並列処理高速化技法を提供することにある。

上記目的は、本発明に従い、クラスタの展開(unrolling)技法を適用することによって達成される。すなわち、本発明において、本発明に係る処理プログラムが、ソースコードの解析により強連結成分を見出すことによって、複数の処理ブロックからなるプログラムをクラスタリングする。それに伴って、プロセッサ間の通信量が低減するように、クラスタが適宜併合される。

好適な実施例では、このクラスタリング・ステップの前に、平坦化(flattening)という処理が行われる。すなわち、Simulink(R)などのシミュレーション・システムにおいて、１つのブロックの中に、サブシステムと呼ばれる別のブロックが存在することがある。サブシステムはそれ自体の入力ポートと出力ポートをもつので、平坦化処理では、サブシステムから入力ポートと出力ポートを除去して、サブシステムの内部のロジックを外と直接繋ぐという処理が行われる。

このとき、強連結成分によってクラスタを形成すると、特にフルビークル・シミュレーション・システムなどの場合、肥大クラスタが形成される。ここでの肥大クラスタの定義は、１つのクラスタ中にブロックが、所定の個数以上あるとか、１つのクラスタの期待される処理時間が、所定の閾値を超えるなどである。

本発明によれば、このように肥大クラスタであると同定されたクラスタに対して、展開(unrolling)処理が適用される。ここでいう展開処理とは、肥大クラスタの処理を複数個コピーして、それを個別のプロセッサに割当てることである。このような処理によって、複数のプロセッサ上でパイプライン的に処理が進むので、処理を高速化することができる。但し、繰り返し実行される肥大クラスタのある一回の処理結果は、同クラスタのそれ以前の処理結果に依存することがあり、よって肥大クラスタをパイプライン的に実行できないことがある。このような場合、肥大クラスタの実行に必要な入力などの値は、ある予測に基づき生成し、肥大クラスタを投機的に実行することでこれに対処する。また、パイプライン化すると、プロセッサ間の通信コストがかかる。従って、あまりに多くのプロセッサを使ってパイプライン化すると却って処理が低下することがあるので、妥当なパイプラインの数を決める必要がある。この明細書においては、パイプラインの数を、展開因子(unrolling factor)と呼ぶことにする。

本発明の一実施例によれば、妥当な展開因子は、肥大クラスタの期待される処理時間と、パイプラインの部分の繰り返し回数と、ロールバック・コストと、パイプラインに処理をロードするコストと、展開因子と、投機成功率の関数である、パイプラインの期待される実行時間を最適化するように決定される。なお、このとき、パイプラインの部分の繰り返し回数に依存しない関数を用いることもできる。

こうして、クラスタと、クラスタのうちの肥大クラスタに対する展開因子が決定されると、個々のプロセッサに割り当たるべきソースコードが決定されるので、それらは必要に応じてコンパイルされ、実行可能コードとして、実行環境上で、個々のプロセッサに割り当てられて実行される。

この発明によれば、複数の処理ブロックの繰り返しによって実行されるフルビークル・シミュレーションなどのためのプログラムを処理をマルチプロセッサ向けに並列化する際に、形成された肥大クラスタに対してパイプライン処理によって処理を高速化できる、という効果が得られる。

以下、図面を参照して、本発明の一実施例の構成及び処理を説明する。以下の記述では、特に断わらない限り、図面に亘って、同一の要素は同一の符号で参照されるものとする。なお、ここで説明する構成と処理は、一実施例として説明するものであり、本発明の技術的範囲をこの実施例に限定して解釈する意図はないことを理解されたい。

次に、図３を参照して、本発明を実施するために使用されるコンピュータのハードウェアについて説明する。図５において、ホスト・バス３０２には、複数のＣＰＵ１ ３０４ａ、ＣＰＵ２ ３０４ｂ、ＣＰＵ３ ３０４ｃ、・・・ＣＰＵｎ ３０４ｎが接続されている。ホスト・バス５０２にはさらに、ＣＰＵ１ ３０４ａ、ＣＰＵ２ ３０４ｂ、ＣＰＵ３ ３０４ｃ、・・・ＣＰＵｎ ３０４ｎの演算処理のためのメイン・メモリ３０６が接続されている。

一方、Ｉ／Ｏバス３０８には、キーボード３１０、マウス３１２、ディスプレイ３１４及びハードティスク・ドライブ３１６が接続されている。Ｉ／Ｏバス３０８は、Ｉ／Ｏブリッジ３１８を介して、ホスト・バス３０２に接続されている。キーボード３１０及びマウス３１２は、オペレータが、コマンドを打ち込んだり、メニューをクリックするなどして、操作するために使用される。ディスプレイ３１４は、必要に応じて、後述する本発明に係るプログラムをＧＵＩで操作するためのメニューを表示するために使用される。

この目的のために使用される好適なコンピュータ・システムのハードウェアとして、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｘがある。その際、ＣＰＵ１ ３０４ａ、ＣＰＵ２ ３０４ｂ、ＣＰＵ３ ３０４ｃ、・・・ＣＰＵｎ ３０４ｎは、例えば、インテル（Ｒ）Ｘｅｏｎ（Ｒ）であり、オペレーティング・システムは、Ｗｉｎｄｏｗｓ（商標）Ｓｅｒｖｅｒ ２００３である。オペレーティング・システムは、ハードティスク・ドライブ３１６に格納され、コンピュータ・システムの起動時に、ハードティスク・ドライブ３１６からメイン・メモリ３０６に読み込まれる。

本発明を実施するためには、マルチプロセッサ・システムを用いることが必要である。ここでマルチプロセッサ・システムとは、一般に、独立に演算処理し得るプロセッサ機能のコアを複数もつプロセッサを用いるシステムを意図しており、従って、マルチコア・シングルプロセッサ・システム、シングルコア・マルチプロセッサ・システム、及びマルチコア・マルチプロセッサ・システムのどれかでよいことを理解されたい。

なお、本発明を実施するために使用可能なコンピュータ・システムのハードウェアは、ＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｘに限定されず、本発明のシミュレーション・プログラムを走らせることができるものであれば、任意のコンピュータ・システムを使用することができる。オペレーティング・システムも、Ｗｉｎｄｏｗｓ（Ｒ）に限定されず、Ｌｉｎｕｘ（Ｒ）、Ｍａｃ ＯＳ（Ｒ）など、任意のオペレーティング・システムを使用することができる。さらに、シミュレーション・プログラムを高速で動作させるために、ＰＯＷＥＲ（商標）６ベースで、オペレーティング・システムがＡＩＸ（商標）のＩＢＭ（Ｒ）Ｓｙｓｔｅｍ Ｐなどのコンピュータ・システムを使用してもよい。

ハードティスク・ドライブ３１６にはさらに、MATLAB(R)/Simulink(R)、Ｃコンパイラまたは、Ｃ＋＋コンパイラ、後述する本発明に係る解析、平坦化、クラスタリング、展開のためのモジュール、ＣＰＵ割り当て用コード生成モジュール、処理ブロックの期待される実行時間を測定するためのモジュールなどが格納されており、オペレータのキーボードやマウス操作に応答して、メイン・メモリ３０６にロードされて実行される。

尚、使用可能なシミュレーション・モデリング・ツールは、MATLAB(R)/Simulink(R)に限定されず、オープンソースのScilab/Scicosなど任意のシミュレーション・モデリング・ツールを使用することが可能である。

あるいは、場合によっては、シミュレーション・モデリング・ツールを使わず、直接、Ｃ、Ｃ＋＋などでシミュレーション・システムのソース・コードを書くことも可能であり、その場合にも、個々の機能が、互いに依存関係にある個別の機能ブロックとして記述できるなら、本発明は適用可能である。

図４は、本発明の実施例に係る機能ブロック図である。各々のブロックは、基本的に、ハードティスク・ドライブ３１６に格納されているモジュールに対応する。

図４において、シミュレーション・モデリング・ツール４０２は、MATLAB(R)/Simulink(R)、Scilab/Scicosなどの既存の任意のツールでよい。シミュレーション・モデリング・ツール４０２は、基本的には、オペレータが、ディスプレイ３１４上でＧＵＩ的に機能ブロックを配置し、数式など必要な属性を記述し、必要に応じて、機能ブロック間を関連付けてブロック線図を記述することを可能ならしめるような機能をもつ。シミュレーション・モデリング・ツール４０２はさらに、記述されたブロック線図に等価な機能を記述するＣのソースコードを出力する機能をもつ。Ｃ以外にも、Ｃ＋＋、ＦＯＲＴＲＡＮなどを使用することができる。特に、後述するＭＤＬファイルは、Simulink(R)独自のフォーマットであり、機能ブロック間の依存関係を記述するためのものである。

なお、シミュレーション・モデリング・ツールは、別のパーソナル・コンピュータに導入して、そこで生成されたソース・コードを、ネットワークなどを経由して、ハードティスク・ドライブ３１６にダウンロードするようにすることもできる。

こうして出力されたソース・コード４０４は、ハードティスク・ドライブ３１６に保存される。ソース・コード４０４は、コンパイラ４０６でコンパイルされ、結果の実行可能プログラムは、テスト・モジュール４０８に渡される。

テスト・モジュール４０８は、実行テストを行う機能と、投機テストを行う機能を有する。実行テストでは、所定のシナリオにより、図１に示すような各ブロックの平均処理時間、プロセッサ間通信時間、及び投機成功確率が測定される。平均時間を測定するために、好適には同一のシナリオが、複数回実行される。その測定結果４１０は、後で使用するために、ハードティスク・ドライブ３１６に保存される。

投機テストでは、別の所定のシナリオにより、結果の実行可能プログラムを投機実行させる。そのシナリオを繰り返すことにより、投機準備の処理時間すなわち、投機が失敗してロールバックする場合に備えて、予測した入力値を保存したりする処理のための時間と、投機成否確認の処理時間すなわち、実際のデータが来たときにそれが予測していたデータと一致するかを確認する処理の時間と、ロールバック処理時間すなわち、投機が失敗した、つまり予測した入力と実際の値が異なっていたことが分かったときに、間違った入力に基づいて行われた処理を止めたり、データの消去などの後処理に要する時間が計測される。そのような値もまた、その測定結果４１０として、後で使用するために、ハードティスク・ドライブ３１６に保存される。

なお、投機成功確率は、実は実際に投機実行を行わなくても算出することができる。投機実行では、本来来るべき入力が来る前に処理が実行されるので、その入力を予測して処理が実行される。従って、投機が成功する確率は、入力に対する予測が的中する確率と等しくなる。その入力を予測するアルゴリズムが定まっていれば、実際に投機実行をしなくても（すなわち、予測した入力データに基づくブロックの処理を実行しなくとも）実際の入力データのみから、予測アルゴリズムの予測成功確率を算出することができる。すなわち、単に「実行テスト」において、各ブロックに対する入力を記録しておき、その入力データ系列から、入力予測アルゴリズムの予測成功率を算出することで、投機成功確率を求めることができる。一方、投機実行をしたとき、あるいは投機実行が失敗したときにどの程度の時間がかかるかは、実際に投機実行をしてみないと分からない。そのため、それらの情報を得るために投機テストが行なわれる。ただし、投機実行の実装が定まれば、投機準備や投機の成否確認、投機失敗時のロールバックに要する処理時間は、入力データ量に比例した処理時間となることが予想される。従って、「投機テスト」においては、全てのブロックを投機実行しなくてもよく、いくつかの、入力データ量の異なるブロックを投機実行してみることで、入力データ量と投機関連処理時間の関係が得られ、それに基づいて全てのケースのコストを算出することができる。

解析モジュール４１２は、ソースコード４０４を入力して構文解析し、ブロックのつながりを、同期グラフ表現４１４に変換する。同期グラフ表現４１４のデータは、好適には、ハードディスク３１６に格納される。

平坦化モジュール４１６は、同期グラフ表現４１４を読み取って、そこのブロック中に含まれているサブシステムを展開することにより、ブロックを平坦化し、同期グラフ表現４１４として書き戻す。平坦化処理については、図７のフローチャート及び、図８と図９を参照して後で説明する。

クラスタリング・モジュール４１８は、同期グラフ表現４１４を読み取って、強連結成分を見出すことによるクラスタリングと、その後の通信量削減処理のためのクラスタ併合処理によるクラスタ数減少処理を行う。クラスタリング・モジュール４１８は、必要に応じて、計測結果４１０に記録されている各ブロックの平均処理時間、プロセッサ間通信時間、投機成功確率、投機準備の処理時間、ロールバック処理時間などの値を使用して、クラスタ間の通信時間の計算などの処理を行う。クラスタリングの結果は、同期グラフ表現４１４に書き込まれる。

展開モジュール４２０は、同期グラフ表現４１４を読み取って、肥大クラスタに対して、展開(unrolling)、すなわち、処理を複数コピーして、パイプライン的に複数のプロセッサに割り当てるように同期グラフ表現４１４を変更する。展開モジュール４２０もまた、必要に応じて、計測結果４１０に記録されている値を参照する。

コード生成モジュール４２２は、同期グラフ表現４１４に基づき、各プロセッサに割り当てるためのソーコードを生成する。

コンパイラ４２４は、生成されたソースコードをコンパイルし、実行環境４２６上で、コンパイルされた実行可能コードを、各プロセッサＣＰＵ１ ３０４ａ、ＣＰＵ２ ３０４ｂ、ＣＰＵ３ ３０４ｃ・・・に割当てる。

図５は、図４の機能ブロック図を、処理フローとして見た場合の図である。図５において、ＭＤＬファイル５０２は、図４では、ソースコード４０４に関連付けられて保存されている。

ステップ５０４では、解析モジュール４１２が、ＭＤＬファイル５０２を解析して、同期グラフ表現４１４を生成する。

ステップ５０６では、平坦化モジュール４１６が、同期グラフ表現４１４を読み取って、平坦化する。

ステップ５０８では、クラスタリング・モジュール４１８が、同期グラフ表現４１４を読み取って、クラスタリング処理を行う。クラスタリング・モジュール４１８の一部である判断ステップ５１０では、クラスタの通信量が削減可能かどうかが判断される。ここで、クラスタの通信量が削減可能であるとは、クラスタを別のクラスタに取り込むことによって、合弁したクラスタを形成し、以ってクラスタ同士の通信量を減らすことを意味する。

これ以上クラスタを合弁しても通信量が減らないなら、ステップ５１２に進み、そこで展開モジュール４２０によって、肥大クラスタの展開、すなわち処理をコピーし、コピーした処理をパイプラインとしてプロセッサにアサインする。この展開処理５１２は、ステップ５１４に示すように、変数Unroll_factorがNを超えない間、反復される。ここでNは、好適には、肥大クラスタの期待される処理時間と、パイプラインの部分の繰り返し回数と、ロールバック・コストと、パイプラインに処理をロードするコストと、投機成功率できまる数である。変数Unroll_factorがNと等しくなると、ステップ５１６では、コード生成モジュール４２２によって、プロセッサにアサインするためのコードが生成される。

図６は、図５の概要フローチャートにおける、解析処理５０４を詳細に示す図である。図６に示す処理は、解析モジュール４１２によって行われる。図６のＭＤＬファイル６０２は、図５のＭＤＬファイル５０２と同じものである。

ステップ６０４では、ＭＤＬファイル６０２から、ステートメントが読取られる。そして、ステップ６０６では、ステートメントがサブシステムかどうかが判断される。ここでいうサブシステムとは、図８のブロック８０４で示す、その内部にブロックを含むブロックを指す。

ブロックは、システムとも呼ばれるので、サブブロックはサブシステムとも呼ばれる。もしステートメントがサブシステムであると、ステップ６０８で、新しいシンボル・テーブル・レイヤが作成される。

ステートメントがサブシステムでないと、ステップ６１２で、ステートメントがブロックかどうかが判断される。ステートメントがブロックであると、ステップ６１４で、現在のシンボル・テーブル・レイヤ中に、新しいノードが作成される。

ステートメントがブロックでないと、ステップ６１６で、ステートメントが、ブロック間のリンクかどうかが判断される。ステートメントがブロック間のリンクであると、ステップ６１８で、始点ブロックが読取られ、また、終点ブロックが読取られる。そして、ステップ６２０で、現在のシンボル・テーブル・レイヤ中で、始点ブロックと終点ブロックが探される。

そして、ステップ６２２で、始点ブロックと終点ブロックが見つかったと判断されると、ステップ６２４で、同期グラフ表現４１４中で、エッジとノードが作成される。そして、処理は、ファイルの終わりに達したかどうかの判断ステップ６２６に行く。ステップ６２６で、ファイルの終わりに達したと判断されると、処理は、次の平坦化処理に進む。ファイルの終わりに達していないなら、処理は、ステップ６０４に戻る。

ステップ６２２に戻って、始点ブロックと終点ブロックが見つからなかったと判断されると、ステップ６２８でエラー終了する。この場合は、Simulink(R)を用いてＭＤＬファイル６０２を作成し直すなどの作業が必要になる。

ステップ６１６に戻って、ステートメントがブロック間のリンクでないなら、処理は、ファイルの終わりに達したかどうかの判断ステップ６２６に行く。こうして、ファイルの終わりに達したと判断された段階で、階層的シンボル・テーブル６１０と、同期グラフ表現４１４が作成されている。

こうして処理は、図７のフローチャートで示す平坦化処理に進む。図７は、図５の概要フローチャートにおける、平坦化処理５０６を詳細に示す図である。図７に示す処理は、平坦化モジュール４１６によって行われる。

ステップ７０２では、以下、同期グラフ表現４１４の全てのノードについて順次処理を行うことが指定される。

ステップ７０４では、ノードがサブシステムかどうかが判断される。もしノードがサブシステムであるなら、ステップ７０６で、階層的シンボル・テーブルから、対応するレイヤＬが取り出される。次にステップ７０８で、レイヤＬから、全ての入力ポートと、それに続くブロックＳが集められる。

ステップ７１０では、入力ポートが削除される。また、先行ノードからＳへのエッジが作成される。この様子は、図９に例示されている。

ステップ７１２では、レイヤＬから、全ての出力ポートと、その後続のブロックＰが集められる。次のステップ７１４では、図９に示すように、出力ポートが削除され、ブロックＰから、後続ノードにエッジが作成される。そして、ステップ７１６に行って、グラフの終わりかどうかが判断される。

ステップ７１６で、グラフの終わりと判断されると、次のクラスタリング処理に進む。

まだグラフの終わりでないと判断されると、処理は、ステップ７０２に戻り、グラフの次のノードの処理に移る。

ステップ７０４で、ノードがサブシステムでないと判断されると、ステップ７１８に行き、そこで、ノードが葉(leaf)かどうかが判断される。ここで葉とは、先行ノードのないノードを指す。もし葉なら、ステップ７２０で、ＥＮＴＲＹ（入口）からノードへのエッジが作成されて、判断ステップ７１６に進む。

ステップ７１８で、ノードが葉でないと判断されると、ステップ７２２で、ノードが根(root)かどうかが判断される。ここで根とは、後続ノードのないノードを指す。ノードが根であると、ステップ７２４で、ノードからＥＸＩＴ（出口）へのエッジが作成される。そして、処理は、判断ステップ７１６に進む。

ステップ７１６で、グラフの終わりに到達した段階で、平坦化された同期グラフ表現４１４が得られている。こうして、次のクラスタリング処理に進む。

図１０は、図５の概要フローチャートにおける、クラスタリング処理５０８を詳細に示す図である。図１０に示す処理は、クラスタリング・モジュール４１８によって行われる。

ステップ１００２では、平坦化処理された同期グラフ表現４１４に対して、強連結成分の計算が行われる。ここで強連結であるとは、コントロール・フローを有向グラフとみたとき、グラフ上の任意の２点間に有向路が存在することをいう。なお、コントロール・フローにおいて強連結成分を見出す技法については、例えば、本出願人に係る特開平９−３１９７２２号公報、及び特開２００４−２７２８２６号公報などを参照されたい。

ステップ１００２で、強連結成分が見出されると、先ず、その見出された強連結成分に基づきクラスタリングが行われ、ステップ１００４では、各強連結成分について、クラスタ依存グラフ１００６中に、ノードが作成される。クラスタ依存グラフとは、クラスタを生成した後に、各クラスタを一つのノードだと見なしたノード間の依存関係を表すグラフ構造である。

ステップ１００８では、肥大クラスタＦが見出される。肥大クラスタとは、１つのクラスタ中にブロックが、所定の個数以上あること、１つのクラスタの期待される処理時間が、所定の閾値を超えるなどの条件で定義される。１つのクラスタの期待される処理時間は、図４に示す計測結果４１０に記録されている各ブロックの平均処理時間、プロセッサ間通信時間、投機成功確率、投機準備の処理時間、ロールバック処理時間などの値を使用して、計算することができる。なお、本発明者は、特に、自動車のような物理プラントのシミュレーション・システムのブロック線図は、システム全体が大きなループ構造を形成する特徴があり、本発明の手法でクラスタリングした際に、このような肥大クラスタがあらわれる傾向があることを見出した。

また一般に、これらループバックエッジは、システムの繰り返し実行の中で、次の繰り返し実行の入力となるため、肥大クラスタを展開してパイプライン的に実行するためには、ループバックエッジの部分を予測して投機実行する必要がある。一般の物理プラントのシミュレーションでは、そのような値が連続的な変化を示す傾向にあり、予測しやすいため、投機実行に適している、という特徴もあることに留意されたい。

さて、こうして肥大クラスタＦが見出されると、その親Ｐが見出され、さらに、Ｆの子Ｋが見出される。その様子を図式的に示したのが、図１１である。図１１において、肥大クラスタＦの親クラスタは、クラスタ９と、クラスタ１０であり、肥大クラスタＦの子クラスタは、クラスタ２、クラスタ３及びクラスタ５である。ＰとＫの全ての要素が、スタックＤにプッシュされる。Ｄ＝｛Ｐ，Ｋ｝である。

ステップ１０１０では、Ｄが空かどうかが判断される。Ｄが空なら、処理は次のクラスタ展開処理に進む。

Ｄが空でないなら、処理はステップ１０１２に進み、ＤからクラスタをポップしてそれをＤｉとし、Ｄｉの部分木をスタックＥにプッシュする処理が行われる。ここで、図１１の例を再度参照すると、クラスタ２の部分木として、クラスタ７、クラスタ０、クラスタ１が示されている。

ステップ１０１４では、スタックＥが空かどうかが判断され、もし空なら、判断ステップ１０１０に戻る。

もしＥが空でないなら、Ｅからクラスタをポップし、それがＺと置かれる。次のステップ１０１８では、ＺがＤｉに取り込まれているかどうかが判断され、もしそうでなければ、ステップ１０２０でＺをＤｉに取込んでから、Ｚを取込み済みとマークしてステップ１０１４に戻り、そうでなければ直ちに、ステップ１０１４に戻る。要するに、ここでの処理は、あるクラスタが他のクラスタを取り込むことであるので、クラスタ同士を併合することでもある。ステップ１０２０の取込みまたは併合の結果は、クラスタ依存グラフ１００６に反映される。

こうして結果的に、ステップ１０１０で、Ｄが空と判断されると、処理は次のクラスタ展開処理に進む。

図１２は、強連結成分によるクラスタリングと、その後のクラスタ取込み処理の例を示すものである。先ず、ブロック線図であらわされる、あるプログラムに、強連結成分によるクラスタリングを施すと、図１２（ａ）に示すようなクラスタの集まりとなる。これは、図１０のステップ１００２、１００４及び１００８の処理の結果である。クラスタの間の接続関係は、クラスタ依存グラフ１００６に記述されている。なお、図１２で、クラスタに振った番号は、クラスタにつけたＩＤである。

そこで、図１０のステップ１０１０、１０１２、１０１４、１０１６、１０１８、及び１０２０の結果として、クラスタの取込みが行われ、図１２（ｂ）に示すように、クラスタの数が低減した、より簡易化されたグラフとなる。図１２（ｂ）では、図１２（ａ）にあった番号のクラスタがいくつか消失していることが見て取れる。これは、消失したクラスタは実は、他のクラスタに取り込まれたのであることを理解されたい。

図１３は、図５の概要フローチャートにおける、展開処理５１２及び５１４を詳細に示す図である。図１３に示す処理は、展開モジュール４２０によって行われる。

ステップ１３０２では、パイプラインの数を決めるパラメータであるNが計算される。この計算のために、次のようなパイプラインに関するコストの式T(n)を想定する。

ここで、tは、当該の肥大クラスタの処理時間、iは処理の繰り返し回数、cは、ロールバック・コストと、パイプラインに処理プログラムを埋めるためのコスト、nは展開因子(unrolling factor)、P(n)は、展開因子nの場合の投機成功率である。c及びP(n)は、図４の計測結果４１０の値から、計算することができる。なお、この式で、iに依存しないように、例えば、i = 1とおいた式を用いることもできる。

ステップ１３０２は、原則的に、コストの式T(n)が最小になるようなnとして、Nを決定する。原則的という意味は、利用可能なプロセッサの数が、T(n)を最小にするnよりも少ないことがあるからである。その場合は例えば、Nとして、利用可能なプロセッサの数が選ばれる。

なお、上記T(n)の式は一例であって、コストをあらわす他の適当な式を使うこともできる。例えば、事前の実行テストによって得た値に基づきブロットした関数でもよい。

ステップ１３０４では、肥大クラスタＦが見出される。また、変数unrolling_factor = 0とセットされる。

ステップ１３０６では、unrolling_factorがNより小さいかどうかが判断され、もしそうなら、ステップ１３０８で、肥大クラスタＦ中の全ての要素（ノード）について、同期グラフ表現４１４とクラスタ依存グラフ１００６中に、コピーが作成される。また、対応する依存エッジが作成される。

ステップ１３１０では、unrolling_factorが1だけ増分され、判断ステップ１３０６に戻る。こうして、unrolling_factorがNに等しくなった時点で、コード生成処理に進む。

図１４は、クラスタの展開処理を示す図である。図１４（ａ）は、図１０のフローチャートで示すクラスタリング処理の結果、生成されたクラスタのグラフ表示である。

そこで、肥大クラスタに対して、図１３のフローチャートで示す展開処理が適用されて、図１４（ｂ）に示すように、肥大クラスタが４つのコピーとして、パイプライン的に並列実行される。

図１５は、肥大クラスタのパイプライン的な並列実行を説明するための模式図である。図１５（ａ）は、肥大クラスタを、展開することなく普通に実行する図である。この場合、例えば、１００Ｈｚのクロックに相当する処理が行われると想定する。そこで、図１５（ｂ）では、肥大クラスタの４つのコピーが作成される。

こうして、図１５（ｃ）では、肥大クラスタが、４つのコピーによってパイプライン化され並列実行されるので、理論的には、図１５（ａ）の場合の４倍の４００Ｈｚで実行可能となる。実際は、プロセッサ間の通信コスト、投機コストなどがあるので、コピーの数の倍率での速度向上にはならない。

図１６は、ブロックＡ，（Ｂ，Ｃ，Ｄ，Ｅ），Ｆというブロックの処理をパイプライン化する様子を示す図である。ここで、（Ｂ，Ｃ，Ｄ，Ｅ）のところが、繰り返しのループになっている。そこで、本発明の技法によれば、外側のブロックＡと、ブロックＦは、それぞれ単一のＣＰＵ１とＣＰＵＮ＋１に割当てられ、（Ｂ，Ｃ，Ｄ，Ｅ）のところが、ＣＰＵ２、ＣＰＵ３・・・ＣＰＵＮに、並列的に割当てられ、（Ｂ，Ｃ，Ｄ，Ｅ）のループは、図示されているように、ＣＰＵ２、ＣＰＵ３・・・ＣＰＵＮによってパイプライン的に実行される。

この時、例えばＢの２回目の実行（Ｂ２）には、Ｅの１回目の実行（Ｅ１）の結果が必要となるが、パイプライン化して実行することにより、Ｂ２の開始時点ではＥ１の結果が得られていない場合がある。このような場合、Ｂ２以降の処理を投機的に実行する。すなわち、Ｅ１の出力を予測して、Ｅ１の実際の出力を待たずにＢ２以降の処理を開始する。その後、実際にＥ１の処理結果が算出され出力を得た後、予測したＥ１の出力と実際のＥ１の出力を比較し、そのずれが許容できない場合は、Ｂ２以降の先行している処理を停止し、再度処理をやり直す。許容できる場合はそのまま処理を続けるなどする。

また、前述のように、自動車のような物理プラントのシミュレーション・システムのブロック線図は、システム全体が大きなループ構造を形成する特徴があり、本発明の手法でクラスタリングした際に現れる肥大クラスタには、このループエッジが、図１６のブロックＥからブロックＢへのリンクのような形で現れることになる。したがって、通常投機実行が必要となる。本発明者は、特に、一般の物理プラントのシミュレーションでは、そのようなループエッジの値が連続的な変化を示す傾向にあり、予測しやすく、投機実行による高速化が期待できることも見出した。

図１７は、図５の概要フローチャートにおける、コード生成処理を詳細に示す図である。図１７に示す処理は、コード生成モジュール４２２によって行われる。

ステップ１７０２では、クラスタ依存グラフ１００６の全てのクラスタＣが順次取得される。

ステップ１７０４では、関数Ｇが生成される。この段階では、空の関数である。

ステップ１７０６では、クラスタＣの全てのノードＮが順次取得される。

ステップ１７０８では、同期グラフ表現４１４を参照することによって、ノードＮのコードが生成される。

ステップ１７１０では、生成されたノードＮのコードが、Ｇに集められる。次にステップ１７１２で、クラスタＣでまだ取得されていないノードＮがあるかどうかが判断され、もしそうなら、ステップ１７０６に戻って、次のノードＮが取得される。

ステップ１７１２で、クラスタＣでまだ取得されていないノードＮが最早ないと判断されると、ステップ１７１４で、関数Ｇが書き出される。このとき書き出されるコードは、単一のＣＰＵに割り当てられる。

ステップ１７１６では、まだ取得されていないクラスタＣがあるかどうかが判断され、もしそうなら、ステップ１７０２に戻って、次のクラスタＣが取得される。

ステップ１７１６で、全てのクラスタＣについて処理が行われたと判断されると、結果的に、個々のＣＰＵに割り当てるべきコード１７１８が生成されている。

生成されたコードは、コンパイラ４２４でコンパイルされて、実行環境４２６で、個々のＣＰＵに割り当てて実行される。

以上、この発明を特定の実施例に基づき説明してきたが、この発明は、この特定の実施例に限定されず、当業者が自明に思いつく様々な変形、置換などの構成、技法適用可能であることを理解されたい。例えば、特定のプロセッサのアーキテクチャ、オペレーティング・システムなどに限定されない。

また、上記実施例は、主として、自動車のＳＩＬＳのシミュレーション・システムにおける並列化に関連するものであったが、このような例には限定されず、航空機、ロボットその他の物理システムのシミュレーション・システムに広く適用可能であることを理解されたい。

シミュレーション・モデリング・ツールのブロック線図の例を示す図である。 ブロックのクラスタの例を示す図である。 本発明を実施するためのハードウェアのブロック図である。 本発明の一実施例の機能ブロック図である。 本発明の一実施例の処理の流れを示す図である。 解析処理のフローチャートを示す図である。 平坦化処理のフローチャートを示す図である。 平坦化処理を説明するための図である。 平坦化処理を説明するための図である。 クラスタリング処理のフローチャートを示す図である。 クラスタリング処理を説明するための図である。 クラスタを併合する処理の例を示す図である。 展開処理のフローチャートを示す図である。 展開処理の例を示す図である。 展開によりパイプライン的に実行される処理を説明するための図である。 展開によりパイプライン的に実行される処理を説明するための図である。 コード生成処理のフローチャートを示す図である。

符号の説明

４０４・・・ソースコード
４０６、４２４・・・コンパイラ
４１２・・・解析モジュール
４１８・・・クラスタリング・モジュール
４２０・・・展開モジュール

Claims (20)

1. コンピュータの処理によって、マルチプロセッサ・システムで、個々のプロセッサに割当てて並列実行させるためのコードを生成する方法であって、
   相互に連結された複数のブロックからなる、プログラムのソースコードを入力するステップと、
   強連結成分を検出することによって、前記ブロックをクラスタリングするステップと、
   所定の閾値を超えるクラスタを見出して、該クラスタを少なくとも１つコピーし、該コピーしたクラスタと併せて並列化されたパイプラインを形成するように処理の流れを与えるクラスタ展開ステップとを有する、
   コード生成方法。
2. 前記クラスタリングするステップは、プロセッサに割当れられた際の通信コストを低減するように、クラスタを併合するステップを有する、請求項１のコード生成方法。
3. 前記所定の閾値は、前記クラスタ内のブロックの数である、請求項１のコード生成方法。
4. 前記所定の閾値は、前記クラスタの期待される処理時間である、請求項１のコード生成方法。
5. マルチプロセッサ・システムで、処理を個々のプロセッサに割当てて並列実行させるための方法であって、
   前記処理をあらわす、相互に連結された複数のブロックからなる、プログラムのソースコードを入力するステップと、
   強連結成分を検出することによって、前記ブロックをクラスタリングするステップと、
   所定の閾値を超えるクラスタを見出して、該クラスタを少なくとも１つコピーし、該コピーしたクラスタと併せて並列化されたパイプラインを形成するように処理の流れを与えるクラスタ展開ステップと、
   前記クラスタ毎のコードを生成するステップと、
   前記コードをコンパイルして、個別の実行可能コードを得るステップと、
   実行環境上で、前記各実行可能コードを個別のプロセッサに割当てて実行させるステップを有する、
   並列実行方法。
6. 前記クラスタリングするステップは、プロセッサに割当れられた際の通信コストを低減するように、クラスタを併合するステップを有する、請求項５の並列実行方法。
7. 前記所定の閾値は、前記クラスタ内のブロックの数である、請求項５の並列実行方法。
8. 前記所定の閾値は、前記クラスタの期待される処理時間である、請求項５の並列実行方法。
9. マルチプロセッサ・システムで、処理を個々のプロセッサに割当てて並列実行させるためのシステムであって、
   前記処理をあらわす、相互に連結された複数のブロックからなる、プログラムのソースコードを保存する記憶手段と、
   強連結成分を検出することによって、前記ブロックをクラスタリングする手段と、
   所定の閾値を超えるクラスタを見出して、該クラスタを少なくとも１つコピーし、該コピーしたクラスタと併せて並列化されたパイプラインを形成するように処理の流れを与えるクラスタ展開手段と、
   前記クラスタ毎のコードを生成する手段と、
   前記コードをコンパイルして実行可能コードを得るためのコンパイラと、
   実行環境上で、前記各実行可能コードを個別のプロセッサに割当てて実行させる手段を有する、
   並列実行システム。
10. 前記クラスタリングする手段は、プロセッサに割当れられた際の通信コストを低減するように、クラスタを併合する手段を有する、請求項９の並列実行システム。
11. 前記所定の閾値は、前記クラスタ内のブロックの数である、請求項９の並列実行システム。
12. 前記所定の閾値は、前記クラスタの期待される処理時間である、請求項９の並列実行システム。
13. コンピュータの処理によって、マルチプロセッサ・システムで、個々のプロセッサに割当てて並列実行させるためのコードを生成するプログラムであって、
    前記コンピュータをして、
    相互に連結された複数のブロックからなる、プログラムのソースコードを入力するステップと、
    強連結成分を検出することによって、前記ブロックをクラスタリングするステップと、
    所定の閾値を超えるクラスタを見出して、該クラスタを少なくとも１つコピーし、該コピーしたクラスタと併せて並列化されたパイプラインを形成するように処理の流れを与えるクラスタ展開ステップを実行させる、
    コード生成プログラム。
14. 前記クラスタリングするステップは、プロセッサに割当れられた際の通信コストを低減するように、クラスタを併合するステップを有する、請求項１３のコード生成プログラム。
15. 前記所定の閾値は、前記クラスタ内のブロックの数である、請求項１３のコード生成プログラム。
16. 前記所定の閾値は、前記クラスタの期待される処理時間である、請求項１３のコード生成プログラム。
17. マルチプロセッサ・システムで、処理を個々のプロセッサに割当てて並列実行させるためのプログラムであって、
    前記マルチプロセッサ・システムをして、
    前記処理をあらわす、相互に連結された複数のブロックからなる、プログラムのソースコードを入力するステップと、
    強連結成分を検出することによって、前記ブロックをクラスタリングするステップと、
    所定の閾値を超えるクラスタを見出して、該クラスタを少なくとも１つコピーし、該コピーしたクラスタと併せて並列化されたパイプラインを形成するように処理の流れを与えるクラスタ展開ステップと、
    前記クラスタ毎のコードを生成するステップと、
    前記コードをコンパイルして、個別の実行可能コードを得るステップと、
    実行環境上で、前記各実行可能コードを個別のプロセッサに割当てて実行させるステップを実行させる、
    並列実行プログラム。
18. 前記クラスタリングするステップは、プロセッサに割当れられた際の通信コストを低減するように、クラスタを併合するステップを有する、請求項１７の並列実行プログラム。
19. 前記所定の閾値は、前記クラスタ内のブロックの数である、請求項１７の並列実行プログラム。
20. 前記所定の閾値は、前記クラスタの期待される処理時間である、請求項１７の並列実行プログラム。

Images