JP2006099579A - 情報処理装置及び情報処理方法 - Google Patents

Abstract

【課題】動作アプリケーションのリアルタイム性を維持したまま、消費電力を適切に制御することができる情報処理装置及び情報処理方法を提供すること。
【解決手段】複数のプロセッサ１１〜１３を備え、データストリームをリアルタイム処理可能な情報処理装置において、前記データストリームに施される処理が定義された複数のモジュール間の関係を示す構成ファイルを読み出して、各プロセッサの処理能力に応じて、少なくとも１つのプロセッサに前記複数のモジュールを割り当てる手段２１と、前記割り当て手段による、前記プロセッサへの前記複数のモジュールの割り当てに関する情報に基づいて、バッファ情報を設定する手段２１と、前記各プロセッサに、前記モジュールと前記設定手段によって設定された前記バッファ情報とをロードする手段２１と、前記ロード手段によってロードした前記バッファ情報を用いて、ロードしたモジュールを所定のタイミングで、各プロセッサにおいて実行する手段２１と、を備えた。
【選択図】 図１

Description

本発明は、情報処理装置及び情報処理方法に関し、特に、マルチプロセッサシステムにおいて、ストリームデータを処理するための情報処理装置及び情報処理方法に関する。

ストリームデータを処理するためのストリーム処理装置として、構成の自由度を向上させたものが提案されている（特許文献１参照）。この提案では、マトリクススイッチ内のスイッチの設定を変更することにより、システム構成を自由に変更できるようにしている。このため、ソフトウェアにより処理方法を変更しようとするものではない。

また、分散型マルチプロセッサ環境のプログラマブルプラットフォームに展開配置することにより、画像のシーケンス処理を実行するための、ソフトウェアシステムが提案されている（特許文献２参照）。この提案は、医療Ｘ線画像のシーケンスを処理するように設計されており、その処理に要求されるリアルタイム性を実現するために、なるべく高速な処理が要求される。従って、消費電力の適切な制御ということは、考えられていない。
特開２００３−１５３１６８号公報 特開２００４−５１９０４３号公報

本発明は、動作アプリケーションのリアルタイム性を維持したまま、消費電力を適切に制御することができる情報処理装置及び情報処理方法を提供することを目的とする。

本発明の局面に係る発明は、複数のプロセッサを備え、データストリームをリアルタイム処理可能な情報処理装置において、前記データストリームに施される処理が定義された複数のモジュール間の関係を示す構成ファイルを読み出して、各プロセッサの処理能力に応じて、少なくとも１つのプロセッサに前記複数のモジュールを割り当てる手段と、前記割り当て手段による、前記プロセッサへの前記複数のモジュールの割り当てに関する情報に基づいて、バッファ情報を設定する手段と、前記各プロセッサに、前記モジュールと前記設定手段によって設定された前記バッファ情報とをロードする手段と、前記ロード手段によってロードした前記バッファ情報を用いて、ロードしたモジュールを所定のタイミングで、各プロセッサにおいて実行する手段と、を具備することを特徴とする。すなわち、実行するシステムのプロセッサの処理能力に応じて、リアルタイム処理できない部分を複数のプロセッサに分割して処理することにより、プログラムの書き換えをすることなく実行できることを特徴とする。本発明は、装置の発明に限らず、方法の発明としても成立する。

本発明によれば、システムの負荷に応じてプロセッサの速度モード(動作周波数)を切り替えることにより、動作アプリケーションのリアルタイム性を維持したまま、消費電力を適切に制御することができる。

図面を参照して本発明の実施の形態を説明する。

図１は、本発明の一実施形態に係る情報処理装置の概略構成を示すブロック図である。
図１に示すように、本発明の一実施形態に係る情報処理装置は、第１から第Ｎのプロセッサ１１から１３が主記憶装置である共有メモリ１５を共有する共有メモリ型マルチプロセッサシステムの情報処理装置である。なお、共有メモリ１５は、各プロセッサ１１から１３に論理的に共有されていればよく、物理的に各プロセッサ１１から１３に分散していても良い。すなわち、分散共有メモリでも良い。また、各プロセッサ１１から１３に共有されるメモリ領域は、共有メモリ１５の全領域でなくても良く、共有バッファ領域として利用する領域が共有されていればよい。

図２は、共有バッファ領域として利用する領域が共有メモリ領域として共有されている例を示す図である。図２に示すように、メモリ領域２０１と２０３、メモリ領域２０２と２０４が、それぞれ同一内容が別々のプロセッサのメモリ空間にマッピングされている。このように、同一内容をそれぞれのプロセッサのメモリ空間にマッピングすることで、データを共有する。なお、前述したように、図２に示すメモリ空間は論理空間であって、物理的には、どの部分にあってもよい。

本発明で扱うアプリケーションは、データストリームをリアルタイム処理することを目的とし、図３に示すように、複数のモジュール群（第１から第５のモジュール）が共通のバッファメモリ（第１から第５のバッファ）を介して連携動作するようなアプリケーションである。図３において、矩形はモジュールまたはバッファを示し、矢印はデータストリームの流れを示す。入力されたデータは複数のモジュールを通してパイプライン処理されて、出力される。この場合において、各モジュールは、マネージャ２１によって割り当てられたプロセッサ上で実行される（割り当てについての詳細は後述する）。
図３に示すように、第１のモジュールに入力したデータストリームは、処理後に２つの出力端１−１と１−２に分けて、例えば、映像と音声とに分けて出力される。出力端１-１から出力されたデータは第１のバッファを介して第２のモジュールに入力して所定の処理がなされる。第２のモジュールから出力されたデータは第３のバッファを介して第３のモジュールに入力して所定の処理がなされた後に、第４のバッファを介して第５のモジュールの入力端５-１を介して第５のモジュールに入力する。一方、出力端１-２から出力されたデータは第２のバッファを介して第４のモジュールに入力して所定の処理がなされた後に、第５のバッファを介して第５のモジュールの入力端５-２を介して第５のモジュールに入力する。第５のモジュールから、所定の処理を行った後のデータストリームが出力される。

図３に示すような各モジュールは、図４に示すとおり、入力バッファにあるデータを処理して出力バッファに書き出すという処理を行う（ステップＳ４０１）。なお、入力バッファの数と出力バッファの数は１つでも良いし、複数であっても良い。例えば、図３では、第１のモジュールの出力バッファの数は２つである。ただし、本実施形態において、最前段のモジュール（例えば、図３の第１のモジュール）はバッファメモリではなくハードウェア装置等から入力するものとし、また最後段のモジュール（例えば、図３の第５のモジュール）もバッファメモリでなくハードウェア装置等へ出力するものとする。さらに、各モジュール間で使用されるバッファは、各モジュールが配置されるプロセッサ間で共有されているものとする（例えば図２のメモリ領域２０１と２０３）。

本実施形態では、特に映像と音声を含むビデオストリームを処理するものとし、ストリームを１フレーム単位で処理することを前提とする。従って、各モジュールは各フレームのデータをフレーム間周期以内に処理するものとする。

図５は、複数のモジュールをプロセッサに割り当てる場合の流れを示すフローチャートである。
まず、マネージャ２１がモジュールとモジュール間の接続を示す構成ファイルを読み込む（ステップＳ５０１）。なお、マネージャ２１を省略して、例えば、第１のプロセッサ１１が構成ファイルを読み込んでも良い。以下の説明において、ステップＳ５０６までの処理は、マネージャ２１（又は、第１から第Ｎのプロセッサのうちの１つのプロセッサ）が実行するので、特に記載しない。なお、ステップＳ５０７における処理については、各プロセッサの実行の開始の通知はマネージャ２１（又は、第１から第Ｎのプロセッサのうちの１つのプロセッサ）が行い、各プロセッサによる実行が開始した後は、各プロセッサにより、独立して実行が行われる。この構成ファイルの具体的な構成例を図６に示す。
図６に示すように、構成ファイルは、モジュール群の一覧と、モジュール間の接続関係の一覧をデータとして備えている。ここで、モジュール群一覧にはモジュールの識別子とモジュール構成ファイルが記述されており、モジュール間の接続関係一覧にはどのモジュールのどの出力端子と、どのモジュールのどの入力端子とが接続されるのかが記述されている。具体的には、図３に示す例では、モジュール群一覧として、第１から第５のモジュールが記述され、接続関係一覧として、第１のモジュールと第２のモジュールについては、出力端１−１と入力端２−１が接続されていることが記述される。なお、モジュール構成ファイルは、マネージャが有するメモリに記憶されていても良いし、バスに接続された図示しない記憶装置や外部記憶装置に記憶されていても良い。
また、各モジュールには、モジュールの構成を示すモジュール構成ファイルが対応付けられているものとし、その記述例を図７に示す。図７に示すように、モジュール構成ファイルには、入力端の数とそれぞれの識別子とサイズ、出力端の数とそれぞれの識別子とサイズ、及び実行に必要な処理量が記述されている。ここで、識別子は、例えば、入力端１、入力端２のように表される。また、サイズは、最大ＸｋＢ（Ｘは自然数）といったようにあらわされる。

次に、各モジュールの処理時間を見積もる（ステップＳ５０２）。この処理時間は、図７に示したモジュールの構成ファイル中に記述された、実行に必要な処理量と、実行しようとしているプロセッサの処理能力から求められる。ここで、実行に必要な処理量とは、例えば想定するプロセッサの動作周波数と処理時間の対応表でもよい。

実際に各モジュールが各プロセッサに割り当てられる（ステップＳ５０３）。このとき、モジュール間のデータ依存関係を図８に示すようなグラフで表す。図８に示すように、本実施形態で扱うグラフは、分岐や合流を含むが、後戻りはないものとする。例えば第３のモジュールの結果を第２のモジュールで使うような場合を含まないものとする。なぜなら、後戻りさせたデータの世代（すなわち、何周期前のデータか）がその処理結果に影響するため、実行させる周期を自由に選べないためである。その場合は第２のモジュールと第３のモジュールを１つのモジュールとして扱う必要があるので、１つのモジュールとして構成ファイルが作成される。
図９を参照して、ステップＳ５０３におけるモジュールをプロセッサに割り当てる具体例を説明する。
まず、モジュール間のデータ依存グラフを作成し、「未割り当てグラフ」とする。図８がこの未割り当てグラフに相当するものであって、図８において、各矩形がモジュールを示し、矩形の横幅が処理時間を示すものとする。

次に、割り当て可能プロセッサ数を変数Ｎに代入する(ステップＳ９０２)。そして、変数Ｐに１を代入する(ステップＳ９０３)。変数Ｐは割り当て可能なプロセッサのプロセッサ番号を示すものとし、本実施形態においては、１〜Ｎが有効とする。

ステップＳ９０４において、変数Ｐが有効範囲かどうか（すなわち、Ｐ≦Ｎ)を確認する。Ｐ＞Ｎなら空きプロセッサがなく実行不可能であるため異常終了する。もし、変数Ｐが有効範囲であれば、ステップＳ９０６に進み、「未割り当てグラフ」の「根」にあたる部分の処理（すなわち、データ依存がないモジュール）を空きプロセッサの１つに割り当てる（ステップＳ９０６）。例えば、第１のプロセッサ１１が空いていれば、第１のプロセッサ１１に第１のモジュールを割り当てる。そして、第１のプロセッサ１１に割り当て可能な他の処理（例えば、図８の例では、第２のモジュール又は第４のモジュール）があれば、当該処理を第１のプロセッサ１１に割り当てる。ここで、モジュールをプロセッサに割り当ている場合に、空き時間ができるだけ小さくなるように割り当てることが好ましい（ステップＳ９０７）。このために、例えば処理時間が長い順にモジュールをプロセッサに割り当てていくという単純な方法でもよい。なお、図８の例において、第３のモジュールは第２のモジュールに、第５のモジュールは第４のモジュールと第３のモジュールにそれぞれ依存するため対象外である。

そして、割り当てたモジュール群を未割り当てグラフから除く（ステップＳ９０８）。プロセッサ（この場合は、第１のプロセッサ１１）に新たに１つ以上の割り当てをされたのであれば（ステップＳ９０９）、更にモジュール群を割り当てられる可能性があるので、ステップＳ９０７に戻る。この場合において、例えば、第１、第２、第４のモジュールを第１のプロセッサに割り当てた場合に、第３のモジュールを割り当てられるかどうかを判断することになる。なお、第５のモジュールは第３のモジュールの後段の処理になるので、この場合は、まず、第３のモジュールのみについて割り当て可能かどうかを判断する。第１のプロセッサにこれ以上モジュールを割り当てられないのであれば、未割り当てフラグが空になったかどうかを判定し（ステップＳ９１０）、空であればモジュール群のプロセッサへの割り当てを終了する。ステップＳ９１０において、未割り当てフラグが空でなければ、Ｐをインクリメントして（ステップＳ９０５）、ステップＳ９０４の処理に戻る。
上記のようにして、モジュール群がプロセッサに割り当てられる。

図５のフローチャートに戻ると、モジュール群がプロセッサに割り当てられたら、プロセッサへのモジュール群の割り当てと接続関係から、各バッファに必要なバンク数を設定する（ステップＳ５０４）。バッファサイズとバンク数を求めるための詳細な流れを図１０に示す。
図１０において、すべての接続に対して、入力端側と出力端側とでサイズが一致しているかどうかの判定を行い（ステップＳ１３０１）、一致していなければ異常終了する。一致していれば、出力端側に対してモジュール構成ファイルで指定されたサイズに、バッファサイズを設定する（ステップＳ１３０２）。例えば、図３の例では、モジュール構成ファイルにおける、出力端１−１と入力端２−１のサイズが一致していなければならない。ここにおいて、バッファは、図６に示した接続関係一覧の分だけ必要になる。例えば、図３の例では、第１のモジュール→第２のモジュール、第１のモジュール→第４のモジュール、第２のモジュール→第３のモジュール、第３のモジュール→第５のモジュール、第４のモジュール→第５のモジュールの合計５つの接続があるが、それぞれの接続に対してバッファを確保する必要がある（すなわち、図３における第１のバッファ〜第５のバッファ）。また、バッファサイズは、図７に示したモジュール構成ファイル中に記述されたサイズを利用する。そして、バンク数を（終点のプロセッサ番号−始点のプロセッサ番号＋１）に設定する（ステップＳ１３０３）。そして、バッファサイズとバンク数の積をメモリサイズに設定する。
上記の処理において、バンク数を求めるステップＳ１３０３に関して、詳細に説明する。話を単純化するため、２つの処理（例えば、図３における第２のモジュールと第３のモジュール）を２通りの方法でプロセッサへ配置した場合を考える。図１１では、高速なプロセッサで構成したシステムと低速なプロセッサで構成したシステムにおける違いの例を示している。高速なプロセッサでは第２のモジュールによる処理Ａと第３のモジュールによる処理Ｂを１周期以内に処理することができるため、１つのプロセッサで逐次処理をする。一方、低速なプロセッサでは処理Ａと処理Ｂを１周期以内に処理することができないため、２つのプロセッサを組み合わせてパイプライン処理をする。ここでは処理Ａが処理したデータを処理Ｂが次の周期で処理する。

この２つの場合において、必要になるバッファメモリのバンク数が異なる。図１２は１台のプロセッサで逐次処理した場合のバッファの使われ方を示している。図１２において、処理Ａおよび処理Ｂの実行中、またバッファが使われている状態を矩形で示している。ここでは処理Ａからの書き込みと処理Ｂからの読み込みが交互に行われるためバッファは１つでよい。一方、図１３は２台のプロセッサでパイプライン処理した場合のバッファの使われ方を示している。ここでも処理Ａおよび処理Ｂの実行中とバッファが使われている状態を矩形にて示している。この場合には、処理Ａの書き込みと、前回のデータに対する処理Ｂの読み込みが並行して行われるため、２つのバッファが必要である。一般に、データが書き込まれてからデータが読み込まれるまでの周期数分のバンク数が必要になる、従って、必要なバンク数は、（終点のプロセッサ番号−始点のプロセッサ番号＋１）で求めることができる。

図５のフローチャートに戻り、バンク数が設定されたら、ステップＳ１３０２で設定されたバッファサイズに応じたバッファ領域を確保する（ステップＳ５０５）。なお、各バッファに必要なメモリサイズはステップＳ１３０４に示したとおり、バッファサイズにバンク数を乗じた量である。

そして、各プロセッサへモジュールと設定情報をロードし（ステップＳ５０６）、各プロセッサで割り当てられた処理を実行する（ステップＳ５０７）。この場合において、設定情報は、図１４に示すような、各入出力端に対応するバッファ情報であって、アドレス、バッファサイズ及びバンク数を含む情報である。

そして、各プロセッサへ、モジュールとモジュールに対する設定情報をロードし（ステップＳ５０６）、各モジュールは、この設定情報を元にバッファへのアクセス手順を設定する。

最後に各プロセッサでの実行を開始する（ステップＳ５０７）。ここで各プロセッサは１周期ずつ遅れて実行開始する。その手順を図１５に示す。

まず、初期化条件として、使用するプロセッサ数Ｎをセットし（ステップ１５０１）、変数Ｐに１をセットする（ステップ１５０２）。ＰがＮを越えるまで、ステップＳ１５０４からＳ１５０６を実行する（ステップ１５０３）。なお、ＰがＮを越えたら処理を終了する。

ステップＳ１５０３において、ＰがＮ以下であれば、プロセッサＰを実行し（ステップθ１５０４）、１周期待つ（ステップＳ１５０５）。そして、Ｐ＝Ｐ＋１（ステップＳ１５０６）として、この処理をＰ＞Ｎとなるまで続ける。

上記のような処理を実行することにより、同一のアプリケーションソフトウェアをそのまま異なる処理能力のプロセッサ群上で実行することができる。なお、上記の処理において、複数のプロセッサを１周期づつ遅らせながら処理しなければならないので、ターンアラウンドタイム（周期数）は増えるが、スループット（リアルタイム性）は維持できる。例えば、上記の方法によれば、高速な４台構成のマルチプロセッサシステムで動作するシステムを、低速な８台構成のマルチプロセッサシステムに対しても修正なしで動作させることができる。そのためプロセッサの数と処理能力に対する選択の柔軟性が高くなる。そしてアプリケーション開発がプロセッサ構成に左右されない。

上記の実施形態では、事前に決定した構成のまま動作し続ける実施形態について説明したが、以下の実施形態ではシステム負荷に応じてアプリケーション構成を動的に切り替える実施形態について説明する。下記の実施態様では、プロセッサの動作周波数が動的に切り替えられるマルチプロセッサシステムを対象としており、プロセッサ上で複数のアプリケーションが動作し、それに応じてプロセッサの利用率が適宜変化するものとする。

ここでは、簡単のため高速モードと低速モードという２つのモードを考える。高速モードから低速モードへの切り替えの様子を図１６に、低速モードから高速モードへの切り替えの様子を図１７に示す。ここでは、ストリームデータに対して処理Ａと処理Ｂの２つの処理を実行する例を示している。以下、具体的な制御について説明する。
低速モードではプロセッサ２台を使い、２周期でストリームデータを処理するものとする。ストリームを乱さないため、高速モードでも同じ周期数（この例では２周期）でストリームを処理する必要があるので、処理Ａの出力を次の周期で処理Ｂが処理するようにする。またこのとき、処理Ｂ、処理Ａの順で処理することによりバッファのバンク数を１つ減らすことができる。図１６及び図１７に示す例では高速モード時はバンク数１で実行可能になる。

アプリケーション構成を動的に切り替える場合の基本的な流れを図１８に示す。
まず、各速度モードに対して構成情報を決定する（ステップＳ１８０１）。次に、アプリケーションが動作可能な適切な速度モードにシステムを切り替える（ステップＳ１８０２）。
そして、現速度モードに対応する構成で、アプリケーションを実行する（ステップＳ１８０３）。アプリケーション終了後に、適切な速度モードにシステムを切り替える（ステップＳ１８０４）。

上記の手順により、動的にアプリケーション構成を切り替えることができる。なお、上記の流れにおいて、各速度モードにおける構成の決定方法について図１９を参照して説明する。
まず最低速モードで構成を決定する（ステップＳ１９０１）。この手順は、図５で説明した実施形態の手順と同様であるので、詳細な説明は省略する。次に、各速度モードにおけるモジュールのプロセッサへの割り当てを決める（ステップＳ１９０２）。この手順は図２０に示すように、プロセッサＰ＋１に割り当てられた全てのモジュールに対し、プロセッサＰで実行可能なモジュールをプロセッサＰへ順次移すことによって行われる。
そして、プロセッサへの割り当てより、各モジュールの実行順序と、バッファの構成を決める（ステップＳ１９０３）。この手順を図２１に示す。
まず、すべてのモジュールに対し、最低速モードでの割り当てプロセッサ番号が大きいものから順に実行するようにする（ステップＳ２１０１）。その際に、実行開始タイミングは、最低速モードでの割り当てプロセッサ番号で決める（ステップＳ２１０２）。そして、すべての接続に対し、最低速モードでは別プロセッサ間、現速度モードではプロセッサ内の接続なら、バッファのバンク数を1つ減らす（ステップＳ２１０３）。

そして、図１８のステップＳ１８０２において、このようにして得られた構成情報を元にして、アプリケーションを動作させるのに適切な速度モードにシステムを切り替えることになる。システムの切替に関する具体的手順を図２２に示す。
対応するすべても速度モードに対して、低速側から順に対応可能なモードを選択する（ステップＳ２２０１）。ここで、該当モードで必要なプロセッサ数が使用可能プロセッサ数を越えたのであれば（ステップＳ２２０２）、異常終了する。この場合には、動作させようとするアプリケーションは実行できないことになる。ステップＳ２２０２において、該当モードで必要なプロセッサ数が使用可能プロセッサ数以下であれば、プロセッサのモードを該当速度モードに切り替える（ステップＳ２４０３）。
ここで、ステップＳ２２０２における必要なプロセッサ数とは、現在動作中のもの、またこれから動作させようとするアプリケーション全てを実行させるために必要なプロセッサの合計であって、各アプリケーションに対してステップＳ１９０２で見積もったプロセッサ数と同様である。

上記のような流れにおいて、図１６に示すように現在の速度モードからより低速なモードに切り替える場合の切り替え手順を図２３に、図１７に示すようにより高速なモードに切り替える場合の切り替え手順を図２４に、それぞれ示す。

図１６に示す処理では、図２３に示すように、まず、バンク数が変わるすべての接続に対し、バッファのバンク数を低速モードのバンク数に切り替える（ステップＳ２３０１）。すなわち、低速モードになるために、プロセッサ数が増える場合には、それに応じて、バンク数を増やす。次に、移動するすべてのモジュールに対し、モジュールを移動先のプロセッサ（プロセッサ２）にロードする（ステップ２３０２）。図１６では、処理Ｂをプロセッサ２へロードする処理がこれに当たる。そして、モジュール（処理Ｂ）の状態を移動先（プロセッサ２）へ移動してから、移動先（プロセッサ２）でモジュール（処理Ｂ）の実行を開始し（ステップ２３０３）、システムを低速モードに切り替えることになる（ステップＳ２３０４）。

また、図１７に示す処理では、図２４に示すように、まず、システムを高速モードへ切り替える（ステップＳ２４０１）。次に、移動するすべてのモジュール（処理Ｂ）に対し、モジュールを移動先（プロセッサ１）でロードする（ステップＳ２４０２）。そして、モジュール（処理Ｂ）の状態を移動先（プロセッサ１）へ移動してから、移動先（プロセッサ１）でモジュール（処理Ｂ）の実行を開始し（ステップＳ２４０３）、バンク数が変わるすべての接続に対し、バッファのバンク数を高速モードのバンク数に切り替える（ステップＳ２４０４）。具体的には、処理Ａ−Ｂ間のバッファのバンク数を１つ減らす。

なお、図１６及び図１７において、切り替え時において、全ステップ（処理Ａ及び処理Ｂ）を１周期以内に終わらせる必要はないが、処理Ａ及び処理Ｂのそれぞれの処理は１周期以内に終わらせる必要がある。

上記のように、本発明の実施形態によれば、システムの負荷に応じてプロセッサの速度モード(動作周波数)を切り替えることにより、動作アプリケーションのリアルタイム性を維持したまま、消費電力を適切に制御することができる。

本発明は、上記各実施の形態に限ることなく、その他、実施段階ではその要旨を逸脱しない範囲で種々の変形を実施し得ることが可能である。さらに、上記各実施形態には、種々の段階の発明が含まれており、開示される複数の構成要件における適宜な組合せにより種々の発明が抽出され得る。

また、例えば各実施形態に示される全構成要件から幾つかの構成要件が削除されても、発明が解決しようとする課題の欄で述べた課題が解決でき、発明の効果で述べられている効果が得られる場合には、この構成要件が削除された構成が発明として抽出され得る。

本発明の一実施形態に係る情報処理装置の概略構成を示すブロック図。 共有バッファ領域として利用する領域が共有メモリ領域として共有されている例を示す図。 データストリームの処理の流れの一例を示す図。 各モジュールの処理を示す図。 複数のモジュールをプロセッサに割り当てる場合の流れを示すフローチャート。 構成ファイルの具体的な構成例を示す図。 モジュール構成ファイルの記述例を示す図。 モジュール間のデータ依存関係を示すグラフ。 ステップＳ５０３におけるモジュールをプロセッサに割り当てる具体例を説明するためのフローチャート。 バッファサイズとバンク数を求めるための詳細な流れを示すフローチャート。 高速なプロセッサで構成したシステムと低速なプロセッサで構成したシステムにおける違いの例を示す図。 １台のプロセッサで逐次処理した場合のバッファの使われ方を示す図。 ２台のプロセッサでパイプライン処理した場合のバッファの使われ方を示す図。 設定情報の具体的な内容を示す図。 各プロセッサの実行開始の手順を示すフローチャート。 高速モードから低速モードへの切り替えの様子を示す図。 低速モードから高速モードへの切り替えの様子を示す図。 アプリケーション構成を動的に切り替える場合の基本的な流れを示す図。 各速度モードにおける構成の決定方法について説明するための図。 各速度モードにおけるモジュールのプロセッサへの割り当てを決める手順を示すフローチャート。 各モジュールの実行順序と、バッファの構成を決める手順を示すフローチャート。 システムの切替に関する具体的手順を示す図。 現在の速度モードからより低速なモードに切り替える場合の切り替え手順を示す図。 現在の速度モードからより高速なモードに切り替える場合の切り替え手順を示す図。

符号の説明

１１〜１３…第１〜第Ｎのプロセッサ
１５…共有メモリ
２１…マネージャ

Claims (11)

1. 複数のプロセッサを備え、データストリームをリアルタイム処理可能な情報処理装置において、
   前記データストリームに施される処理が定義された複数のモジュール間の関係を示す構成ファイルを読み出して、各プロセッサの処理能力に応じて、少なくとも１つのプロセッサに前記複数のモジュールを割り当てる手段と、
   前記割り当て手段による、前記プロセッサへの前記複数のモジュールの割り当てに関する情報に基づいて、バッファ情報を設定する手段と、
   前記各プロセッサに、前記モジュールと前記設定手段によって設定された前記バッファ情報とをロードする手段と、
   前記ロード手段によってロードした前記バッファ情報を用いて、前記ロードしたモジュールを所定のタイミングで、各プロセッサにおいて実行する手段と、を具備することを特徴とする情報処理装置。
2. 請求項１に記載の情報処理装置において、前記割り当て手段は、前記データストリームが、１つのプロセッサですべての処理がリアルタイム処理できないときに、複数のプロセッサにモジュールを割り当てて、分割して処理することを特徴とする情報処理装置。
3. 請求項２に記載の情報処理装置において、前記複数のプロセッサにモジュールが割り当てられた場合において、ある処理を実行する第１のモジュールの次に実行される第２のモジュールを実行するプロセッサは、第１のモジュールを実行するプロセッサよりも１周期遅れて実行されることを特徴とする情報処理装置。
4. 請求項１から請求項３のいずれか１項に記載の情報処理装置において、前記構成ファイルは、複数のモジュールの一覧と、前記モジュール間の接続関係を一覧とを含むことを特徴とする情報処理装置。
5. 請求項４に記載の情報処理装置において、前記モジュールの一覧は、プロセッサの処理能力から処理時間を見積もることを可能とするメタ情報を有することを特徴とする情報処理装置。
6. 請求項１から請求項５のいずれか１項に記載の情報処理装置において、前記バッファ情報は、バッファメモリに情報が書き込まれてから読み出されるまでの時間に応じて設定されることを特徴とする情報処理装置。
7. 請求項１から請求項６のいずれか１項に記載の情報処理装置において、前記割り当て手段は、モジュール間のデータ依存グラフを作成する手段と、前記データ依存グラフに基づいて、データ依存がないモジュールを順次割り当て可能なプロセッサに割り当てる手段とを含むことを特徴とする情報処理装置。
8. 請求項１から請求項７のいずれか１項に記載の情報処理装置において、
   前記プロセッサは、処理能力が変更可能であり、
   前記プロセッサによるモジュールの実行中に、情報処理装置の負荷が変動した場合に、前記プロセッサの処理能力に応じて、前記モジュールをプロセッサに再割り当てすることによって、アプリケーション構成を動的に切り替えることを特徴とする情報処理装置。
9. 請求項９に記載の情報処理装置において、前記プロセッサは、動作周波数の切替が可能であり、
   前記情報処理装置の負荷に応じて前記プロセッサの動作周波数を切り替えることを特徴とする情報処理装置。
10. 複数のプロセッサを備え、データストリームをリアルタイム処理可能な情報処理装置に適用される情報処理方法おいて、
    前記データストリームに施される処理が定義された複数のモジュール間の関係を示す構成ファイルを読み出して、各プロセッサの処理能力に応じて、少なくとも１つのプロセッサに前記複数のモジュールを割り当てるステップと、
    前記プロセッサへの前記複数のモジュールの割り当てに関する情報に基づいて、バッファ情報を設定するステップと、
    前記各プロセッサに、前記モジュールと設定された前記バッファ情報とをロードするステップと、
    ロードした前記バッファ情報を用いて、ロードしたモジュールを所定のタイミングで、各プロセッサにおいて実行するステップと、を具備することを特徴とする情報処理方法。
11. 請求項１０に記載の情報処理方法において、
    前記プロセッサは、処理能力が変更可能であり、
    前記プロセッサによるモジュールの実行中に、情報処理装置の負荷が変動した場合に、前記プロセッサの処理能力に応じて、前記モジュールをプロセッサに再割り当てするステップを更に具備することを特徴とする情報処理方法。

Images