JP2012511204A - リソースを最適化するためのタスク再編成方法 - Google Patents

Abstract

ある環境においてリソースと実行時間を最適化するべく複数のタスクを再編成する方法を開示する。一実施形態において前記方法は、各タスクをマッピングして、各タスクを実行するべくタイムフレーム内で各関数要素及び変数の質的及び量的査定を得ることと、前記マッピングから得たデータをＮ×Ｎ（Ｎはタスクの総数を示す）の大きさのマトリックスで表すことと、前記マトリックス中に示すデータによって、前記タスクを再編成して実行することを含み、前記タスクの再編成は静的方法及び動的方法の両方を提供する。本発明はタスクを実際に全て完了する時間に必要なリソースの最適な数を決定すると共に、コンピュータアプリケーションではないものにも適用できるため、有利である。

Description

本発明は、概して少なくとも１つの処理要素を含む環境においてリソース及び実行時間を最適化するためにタスクを再編成する方法に関する。

コンピュータプログラムは、特定のシーケンス及び時間で実行される複数のタスクを含むが、これらのシーケンス及び時間は、対応するソースコードの論理と使用する処理ハードウェアの制約によって決まる。コンピュータシステム、詳細には複数の処理要素を含むコンピュータシステムは、コンピュータプログラムを含むタスクを実行する際のタスクの編成を効率化する方法が備わっていれば、コンピュータプログラムをより速く実行できると共に、処理ハードウェアのリソースに対しても合理的に要求を行うことができる。

一般にタスクの編成とは、実行キュー中のタスク又はプロセスにおいて優先度を論理的に割り当てることを指す。入力コード中の実行ユニットを識別し、その実行を編成してより速く正確に前記ソースコードを実行することは、多重処理／並列処理システム、そして特に実時間オペレーティングシステムの多重タスク処理効率と処理能力を決める重要なパラメータである。多重処理環境に合ったタスク編成方法の構築は、当技術分野で早急に必要とされてきた。

タスク編成機能を提供するオペレーティングシステムの部分は、タスクオーガナイザとして知られている。タスクオーガナイザの仕事は、単一ＣＰＵシステムの場合にはタスク／スレッド／プロセスを実行するＣＰＵ時間を割り当てることである。これらのタスクオーガナイザは一般的にはタイムシェアリング方法を実行し、各プロセス／タスク／スレッドに対して、それを実行するためのＣＰＵタイムスロットを割り当てる。ＣＰＵを複数備えるシステムの場合に、タスクオーガナイザに求められるのは、ＣＰＵ同士の間の負荷にバランスが取れるように、及び／又は実行時間が最短となるように、異なる処理要素同士の間でタスクを分配することである。より良いタスクの編成方法を編み出す際に直面する課題は、依存関係にあるタスク同士の間の同期及び通信時間を最短化すること、実行時間を最適化すること、リソース又はＣＰＵの使用を最適化すること等である。

この点に関して、種々の従来技術では、次のような方法により上記問題を処理しようとした；例えば、データの競合を減らすと共にデータ局所性を最大化する目的で、反復する実行シーケンスを連続配列した形態で表す方法；並列処理できるタスクを識別し、これらを異なる処理ユニットに編成する方法；時点を起こった順に同期化することにより、総処理時間を分割することによって得た異なるレベルのタスクを分配することに基づく並列処理及び編成を行う方法等である。この他、プレランタイム技術とランタイム技術を組み合わせた方法、共通のコード分配バスを共有する埋め込みプロセッサの集まりを含む方法；タスクのリソース要求に基づいてタスクを編成する方法等を含む手段が幾つかある。

しかし、既存の従来技術における方法には、並列処理システムの効率が全面的に達成されないと共に、方法がタスクの静的編成又は動的編成のいずれかに限定されているという欠点がある。さらにこれらの方法は、フィードバック構造に依存すると共に、使用する処理要素の数に基づいたタスクの最適な編成を決定することができない。また、従来技術による方法は、所定のタスクを編成するために必要な処理要素の最適な数を提供することもなければ、処理要素の使用を最適化するようにタスクを編成することもない。さらに、これらの方法はデータ依存関係、関数コールチャート、利用可能な処理要素のマッピング等の関連するパラメータを考慮しないため、タスクの実行を最適に編成するまでに至っていない。

これらの問題に対処する試みに関する情報は、以下の特許文献１から特許文献１１に記載されている。しかし、それらの文献にはそれぞれ、上に挙げた欠点が１つ以上ある。

そのためこれまでの方法では、最先端の上記問題を満足のいくように対処することができなかった。よって、実行リソースと実行時間の使用を最適化する静的且つ動的なタスク編成を可能にする方法を提供することにより、上記欠点に対処する方法が必要である。

欧州特許第１４１６３８５号 欧州特許第５３３４４５号 米国特許第２００７０１４３７５９号 米国特許第２００７０２５５９２９号 米国特許第５４５２４６１号 米国特許第７１６５２５２号 米国特許第２００８０２６３５５５号 米国特許第６２９２８２２号 米国特許第２００７０１９２５４５号 米国特許第２００７０１１３０３８号 米国特許第２００８０２６３５５５号

開示する発明の幾つかの態様の基本的な理解を促すように、発明の概要を以下に示す。この概要は詳細に関わる要約ではなく、鍵となる／重要な要素を特定するものでもなければ、発明の範囲を明確に示すよう意図したものでもない。その唯一の目的は、後程示す、より詳細な説明の前置きとして、本発明の幾つかの概念を簡単に示すことである。

本発明の目的は、ある環境においてリソースと実行時間を最適化するべくタスクを再編成する方法を提供することである。本発明の一態様では、リソース及び実行時間を最適化するために複数のタスクを再編成する方法を示す。該方法は、各タスクをマッピングして各タスクを実行するべくタイムフレーム内で各関数要素及び変数の質的及び量的査定を得るステップと；マッピングから得たデータをＮ×Ｎの大きさのマトリックスで表すステップであって、Ｎはタスクの総数を示すステップと；マトリックス中に示すデータによって、タスクを再編成して実行するステップであって、タスクの再編成が静的方法及び動的方法の両方を提供するステップと；を含む。

従って、本発明は、例えばマルチコア要素、対称型要素、及び非対称型要素等（これらに限定しない）の多重処理要素を含む環境において使用する方法を提供する。

本発明の別の目的は、タスクの実行に必要なリソースの最適な数を決定することである。

従って本発明は、リソースの利用可能性を無限と仮定して、タスクの実行に必要な最短時間を決定し、任意の所与の実行時間に必要な最小のリソースを決定し、リソースの数が一定である場合に必要な実行時間を決定し、リソースの数が一定である場合にリソースの使用を決定し、所与の実行時間及び利用可能なリソースに対するリソースの使用を決定する方法を提供する。

本発明は、実際の全タスク完了時間を達成するのに必要なリソースの最適な数を決定するものであるが、コンピュータではない用途に適用でき、有利である。

本明細書で開示するシステム及び装置は、様々な態様を達成する任意の手段で実行可能である。添付の図面及び以下の詳細な記載から、その他の特徴が明らかとなろう。

幾つかの実施形態を例として示すが、実施形態は添付の図面に限定されない。また図面では、同じ要素については同じ参照番号を付して示している。

本発明は多くの実施形態が可能であると共に、明細書の記載及び図面で示す範囲に決して限定されない。

複数の処理要素を含む環境での本発明によるタスク再編成をグラフで示した図である。 本発明によるタスク依存関係のグラフである。 図３Ａ、Ｂ、Ｃ及びＤは、異なる数の処理要素を含む環境での、本発明によるタスク再編成をグラフで示した図である。

添付の図面を参照して、本発明の実施形態を説明する。ただし、開示する実施形態は本発明の一例にすぎず、本発明は様々な形態で実施できることを理解されたい。以下の記載と図面は本発明を制限するものととらえるべきではなく、また特許請求の範囲の基礎として、そして本発明の構築及び／又は使用を当業者に教示するための基礎として、特定的な詳細を複数示す。ただし場合によっては、本発明の詳細を不必要に不明瞭にしないように、周知又は従来の技術に関する詳細については記載しない。

本発明は少なくとも１つの処理要素を含む環境においてリソース及び実行時間を最適化するためにタスクを再編成する方法を示す。「リソース要素」、「処理要素」、及び「プロセッサ」等の用語は明細書を通して同義的に使用する。タスク又はプロセス又はスレッドは、コンピュータプログラムコードであり得ると共に、「タスク再編成手段」又は「再編成手段」は元々の実行によるタスクの実行を再編成する。

一例示的な実施形態では、ある環境においてリソース及び実行時間を最適化するべく複数のタスクを再編成する方法は、各タスクをマッピングしてタスクそれぞれを実行するタイムフレーム内の各関数要素及び変数の質的及び量的査定を得るステップを含む。このマッピングステップでは、個々のタスクの実行時間、実行シーケンス、タスク同士の依存関係、及び上流のタスクを実行した結果として下流のタスクを解放する図式等、元々の実行による対象タスクの特徴が明らかとなる。さらに、マッピングから得たデータをＮ×Ｎの大きさのマトリックスで表すことになるが、Ｎはタスクの総数を示す。さらに、マトリックス中に示すデータによってタスクを再編成して実行するが、タスクの再編成は静的方法及び動的方法の両方を提供する。

換言すれば、実行時間及び実行リソースの効果的な最適化を達成するためにタスクを再編成する方法は、静的方法及び動的方法の両方を提供する。実行可能な単位（タスク）を識別し、その後実行パイプラインにおいてタスクに優先度を論理的に割り当てる際に、関数を綿密に構築することが求められる。

タスクを再編成する動的方法
一実施形態では、並列計算システムのメインメモリは、並列計算システムにおけるすべてのリソース又は処理要素とタスクプログラムを共有する。並列計算システムは複数の処理要素を含む。さらに、並列システムのすべての処理要素においてタスクプログラムを実行する。全ての処理要素が共有するメインメモリにおけるデータ構造は、実行すべきタスクに関する情報を含む。異なる処理要素で実行される全てのタスク再編成プログラムが、このデータ構造を共有する。一例示的な実施形態では、一般的な技術であるミューテックス（Mutex）等のロックを使用すれば、共有するデータ構造への排他的アクセスを保証することができる。なお、処理要素又はタスク再編成手段の間にはマスタースレーブ関係は存在しない、即ち、全ての処理要素とタスク再編成手段は同レベルである。上記環境におけるタスク再編成手段の働きについて、以下で説明する。

一例示的な実施形態では、全ての処理要素で実行するタスク再編成手段は、共有するデータ構造にアクセスして実行準備状態にあるタスクがあるかどうかをチェックする。実行準備状態にあるタスクの中で最も優先度の高いタスクを選んで実行する。タスク再編成手段は実行中のタスクの状態又はタスクのデータ構造中のフラグを変更し、そのタスクのフラグ又は状態を実行中と記録する。これは別の処理要素が同じタスクを選択した実行しないことを保証するためである。この共有データ構造への排他的アクセスを保証するために、ミューテックス及びセマフォ等の一般的なロック技術を使用できる。ロックが利用できない場合には、共有データ構造にアクセスするためのロックを利用できるようになるまで、タスクプログラムは待機する。タスクの実行が処理要素のいずれかにおいて終了すると、その処理要素において次のタスクの実行が開始される。

さらに、タスク再編成手段は、共有データ構造にアクセスすることによって、任意のタスクが実行準備状態であるかどうかを再度チェックする。実行準備状態にあるタスクがない場合には、タスク再編成手段はタスクが実行準備状態となるまで周期的にチェックを続け、実行を開始する。別の例示的な実施形態では、複数のタスクが実行準備状態である場合には、タスク再編成手段は最も優先度の高いタスクを選び出す。このように、上述のタスク再編成手段の作用とメカニズムは、環境の処理要素全てにおいて継続する。

さらに、タスクの実行が継続すると、事前に行ったデータ依存関係の解析に基づいて、より多くのタスクが実行準備状態となる。共有データ構造は、事前にプログラム解析を行なうことによって計算したデータ依存関係情報を含む。データ依存関係は複数存在し得るが、データ構造にはデータ依存関係情報が含まれる。別の例示的な実施形態では、各データ依存関係を解決した後にタスクプログラムコードをタスクに挿入することで、特定のデータ依存関係が完了したことを示すよう共有データ構造が修正される。すべての依存関係が解決されると、タスクは実行準備状態となる。タスク再編成手段が最も優先度の高いタスクを選んで実行すると、この時点でコンテキストスイッチが発生できる。タスクはI／Oに対して、又は一部のリソースに対して、又はミューテックスに対して待機状態となることが可能である。この場合にはタスクは実行されず、待機状態となる。リソースが利用可能となれば、タスクは実行準備状態となるであろう。タスクの状態としては、実行準備状態、非実行準備状態、待機状態、実行済又は完了状態がある。

例えば：タスクのデータ依存関係全てが解決し、そのタスクは実行準備状態となっているが、これを実行できる処理要素がない場合には、以下のケースが生じ得る：

ケース１：新たなタスクが実行準備状態にあり、別のタスクが実行中であるが、この実行中のタスクの優先度が、実行準備状態にあるタスクより低い場合。このような場合には、タスク再編成手段はコンテキストスイッチを実行して、優先度の高いタスクの実行を開始し、優先度の低いタスクは一時的に中断させる。中断されたタスクの状態は「実行準備状態」となり、新たなタスクの状態は「実行状態」となる。

ケース２：新たなタスクが実行準備状態にあり、現在実行中の全てのタスクの優先度が新たなタスクの優先度より高い場合。この場合には、コンテキストスイッチは発生せず、新たなタスクは処理要素が利用可能となるまで実行されない。よって、新たなタスクの状態は「実行準備状態」である。

ケース３：新たなタスクが実行準備状態にあるが、すべての処理要素がビジー状態である。ただし新たなタスクの優先度と同じ優先度を有するタスクが実行されているという場合。この場合には、ラウンドロビンタイムスライスタスク再編成手段を使用して、特定の期間、両方のタスクを実行する。この期間に、何か他のプロセッサを利用できるようになれば、２つの異なる処理要素において両方のタスクを同時に実行できる。

一例示的な実施形態では、上記システムを対称型マルチプロセッサシステムに適用可能である。しかし、非対称型マルチコアシステムでも上記システムを実行できる。非対称型マルチプロセッサシステムには、アプリケーションを実行する主要な処理要素が１つ存在し、これは大抵の場合ＲＩＳＣ構造であり、また特定の計算の実行を専門的に行うコプロセッシング要素が１つ以上存在する。ＲＩＳＣ処理要素は特殊命令、そして積和演算（ＭＡＣ）のような特殊演算を実行するＤＳＰコプロセッサ等の補助プロセッサを使用する。このような非対称型マルチプロセッサシステムの場合には、タスク再編成手段はメインのＲＩＳＣプロセッサのみで実行する。この場合には、コプロセッサを使用するタスクプログラムコードの生成はコンパイラが行う。

タスクを再編成するための静的方法
一実施形態において、静的方法によるタスクへの優先度の割り当て手法は、特定のタスクに依存するタスク数が多くなる程、再編成手段はそのタスクに高い優先度を付与するため、特定のタスクの実行によってより多くのタスクが解放される、ということに基づく。さらに、別のタスクは実行準備状態にあっても、このやり方によって遅延される可能性がある。そのため、実行するタスクの選択やタスクの待機状態の維持に対しては主な基準が２つあり、例えば実行時間や実行する現タスクに依存するタスク数といったものである。

さらに静的再編成方法では、再編成方針を決定するのに必要な情報全てを収集するために、タスクプログラムコードをオフラインで複数回実行する必要がある。関連情報としては、実行時間に関するタスクの分割とタスクの依存関係等がある。さらに、これらの入力に基づいて、タスク依存関係マトリックスを作成する。表Ｉは、別個の時間に沿ったマッピングによって明らかとなるプログラムコードのデータを示し、図１は多重処理要素を含む環境におけるタスクの再編成をグラフで示す。

表Ｉでは、タスク１を１０ｍｓ実行し終わるとすぐに、タスク２を開始することができる。タスク１を２０ｍｓ実行し、タスク２を１０ｍｓ実行し終わった時に、タスク３を開始できる。この表の６行目は、タスク６は２０ｍｓの持続時間を有するが、このタスク６に関しては、図１で示すようにタスク２を３０ｍｓ実行し、タスク３を２０ｍｓ実行し、タスク４を１０ｍｓ実行し、そしてタスク５を１５ｍｓ実行した後でしか実行することができないことを示している。表Ｉに基づいて、タスク依存関係マトリックスを形成し得る。

従って、実行中のタスクを有する行に沿ってマトリックスＡを作成する。縦列に沿って実行準備状態となるタスクがある。ｉ行目の各要素は、ｊ番目の縦列におけるタスクｊを解放する時間に等しい。よって、Ｔijはｉ番目のタスクがＴijの時間の後にｊ番目のタスクを解放することを示している。いったん解放されると、タスクｊは実行準備状態となる。

定義：
Ｔ_AMWT−タスクｊの実行が開始された後、タスクｉを開始するのに必要な絶対時間（上記ケースではＴ２１＝タスク１の実行を開始した後タスク２を開始するのに必要な時間）
Ｔi−タスク番号ｉ
Ｐi−プロセッサ番号ｉ
Ｔ−タスク依存関係マトリックス
Ｔij−タスク依存関係マトリックスの要素であり、タスクｊが単位時間Ｔijの実行を完了すると、タスクｉがそのジョブを開始できることを意味する
Ｐ_iwait−プロセッサｉがそのジョブを終了し、次に利用可能なタスクに対して準備が整うまでに必要な時間
Ｐ_istat−プロセッサの状態（ビジー又は利用可）
Ｔxi−タスクｉを逐次実行する総時間
Ｔi_stat−タスクIの状態（実行中、完了、未開始）
Ｔi_dep−Ｔiに依存するタスクの数
Ｎ_proc−プロセッサの数
Ｔiexec−Ｔiが実行されてからの時間＜Ｔi

一実施形態では、タスクの再編成はタスク依存関係マトリックスに完全に基づいて、下に示すように実行される。

実行すべき第１のタスクを見出すために、依存関係を有さないタスクを選択する。表IIでは、タスク１が第１のタスクである。第１のタスクとなり得る候補が多く存在する場合には、タスクを実行する優先度を設定して、これらタスクのうちのどのタスクの実行を開始し、どれを遅延させるかを決定する。これを決定するには３つの要素がある：Ｔxi、Ｎ_proc、及びＴi_depである。このように、この方法ではタスクの最適な再編成を決定することに対してこれらの３つの要素を考慮する。利用可能なプロセッサがより多く存在する場合には、より多くのＴi_depを有するタスクに高い優先度を付与する。実行により多くの時間を要するタスクは、より小さいＴxiを有するタスクより早くは開始されない。同時に、現在のタスク実行を開始した場合に準備状態となるタスクの数は、実行すべき次のタスクを決定するための決定要素である。従って、他のタスクの依存関係の解除が保証される。こうしてプロセッサの最適な使用が保証される。

一実施形態では、実行するタスクの優先度を決定するために、(min(Ｔxi × Ｔidep))を有するタスクにより高い優先度が付与される．．．．．．．．．．．．（１）

第１のタスクの実行が開始されると、以下の値を更新する：
Ｔistat−実行中
Ｐistat−タスクｉを実行中
Ｐiwait−Ｔxi（プロセッサが空くまでに時間Ｔxiが残っていることを意味する）

さらに、開始すべき次のタスク（１つ以上）を見出す際には、第１のステップで識別したタスクか、式（１）を用いて残りのタスクから選択したタスクか、のいずれかが選択される。次のタスクを選択するために、タスク依存関係マトリックスを精査して、現在実行中のタスクに依存するタスクがあるかどうかをチェックする。Ｔjがこのようなタスクであり、Ｔjは現在実行中のタスク番号ｉに依存すると仮定する。実行の優先度を決定する論理は以下の通りである：
ａ．Ｔijを見出す
ｂ．Ｔiexec > Ｔijであるかどうかをチェックする
ｃ．プロセッサの利用可能性をチェックする
ｄ．プロセッサが利用可能な場合には、タスクｊの実行を開始する
ｅ．タスクｘ，ｙ，ｚ...もこの条件を満たす場合には、式（１）を使用して優先度を決定し、利用できるプロセッサ数に基づいてこれらのタスクの同時実行を開始する
ｆ．全てのタスクの実行を開始し、実行し終わるまでプロセスを反復する。

タスク依存関係マトリックスの特性：タスクｉの絶対最短待機時間であるＴ_Aiは、０からタスクｉの実行時間Ｔ_Xiである。Ｔ_Ai＝０である場合には、（ｉ＋１）番目のタスクをタスクｉと同時に開始できることを意味する。一方、Ｔ_Ai＝Ｔ_Xiである場合には、タスクｉが完了するまでは次のタスクを実行できないことを意味している。

特性１：
0 <=T_Ai <=T_Xi

特性２：
逐次実行に対する総時間、T_max=T_X1+T_X2+T_X3+T_X4+T_X5 ... T_XM

特性３：
並列実行に要する最短総時間、Ｔ_min＝Ｍａｘ（Ｔ_Xi）、ここでｉは１からＭ、即ちタスクの最大数まで変化する。
上記ケースでは、Ｔ_Aiは全てゼロであると仮定するため、全てのタスクを同時に実行開始できる。

特性４：
最後の実行は常にＴ_Alast＝Ｔ_Xlastを有する。
タスクｉの実行時間＝Ｔ_Xi
異なる処理要素で次のタスクが開始された場合、現プロセッサでの実行にかかる残りの時間は（Ｔ_Xi−Ｔ_Ai）となる。これは、並列処理によって節約される時間である。
ケース１：
(T_Xi-T_Ai)=0
モジュールを同時に実行することができない。
ケース２：
(T_Xi-T_Ai) <=T_A(i+1)
この（ｉ＋１）番目のタスクを新たなプロセッサで開始できる。ただし、（ｉ＋２）番目のタスクは実行開始できない。よってプロセッサを追加しても意味がない。
ケース３：
(T_Xi-T_Ai) > T_A(i+1)
この場合には以下のことを実行する必要がある：
合計＝０
フラグ＝０、Ｎ＝０、ここでＮは処理要素の数である
sum = 0
flag = 0
N = 0, where N is the number of processing elements（Ｎは処理要素数である）
loop (flag!=1)
N = N+1
sum = sum + T_A(i+N)
loop from j =0 to j < N && flag==0
if ( sum > (T_X(i+j) - T_A(i+j)))
flag = 1
j=j+1
end loop
end loop

プロセッサ数Ｋ（ｉ）＝Ｎ
Ｎは処理要素数、ｊは処理要素に対する反復、Ｍはタスク数、そしてｉはタスクの反復であると仮定すると、プロセッサ（同一プロセッサ）が空くまでの残り時間は、異なる幾つかのタスクを考慮する場合、異なる可能性がある。よって、
T_R1=T_X10-T_A10
又は
T_R1=T_X1-T_A1

プロセッサの最適な数対最適な時間
別の実施形態では、タスクを実行する最適な速度を達成するのに必要なプロセッサ数を決定する。さらに、タスクの実行に関するむだ時間及び待機時間に基づいて、任意の所与の逐次タスクプログラムを実行するのに必要な処理要素の最適な数を決定することができる。待機時間とむだ時間は全ての処理要素の最大処理能力をもって最短とすることができることを考慮することにより、処理要素の最適な数を決定する。

従って一実施形態では、実行時間及び／又は処理要素数に関して、性能の最適化を以下のように達成できる：

用途又はユーザの要件に基づいて、タスク依存関係マトリックスを作成することによって、上記方法は所望の性能を発揮するよう調整を行う。

Ｔ_ij＝ｉ番目のタスクの実行を開始した後、ｊ番目に実行開始すべきタスクの待機時間を示す。即ち、ｊ番目のタスクのｉ番目のタスクに対する依存関係は、ｉ番目のタスクが時間Ｔ_ijの間実行されると終了する。
Ｔ_ji＝ｉ番目のタスクの開始後に実行を開始されるまでのタスクｊの待機時間を示す。

図２は、本発明によるタスク依存関係のグラフを示す。詳細には、図２はタスクと、丸括弧内にそれぞれの実行時間を示している。例えば、タスク０は５０ｍｓの実行時間を有し、タスク５は２０ｍｓの実行時間を有する。図２で示す黒枠円内の数字は、新たな処理要素でそれぞれのタスクを開始するのに必要な待機時間を示す。開始時間は絶対時間であり、タスク０はプロセッサ０で開始されると仮定する。

タスク３の絶対待機時間は、３つの依存関係（Ｔ₁₃、Ｔ₀₃、Ｔ₂₃）のうちの最大値であるというだけでＴ₁₃＝２５にはならず、タスク３はタスク２に依存し、タスク２はタスク０に依存しているため、実行時間は３０ｍｓとなる。このように、これら前のタスクに対する待機時間を考慮しなければならない。従って、この場合には最長時間はタスク２の待機時間である２０ｍｓとＴ₂₃である１０ｍｓを加算したものである。さらに、実行時間対プロセッサ番号は表IVで示す通りである。

図３Ａ、図３Ｂ、図３Ｃ、及び図３Ｄは、表IIIに示す依存関係マトリックスを有するアプリケーションに対するタスク再編成のシミュレーション結果を示す。このシミュレーションから以下のことが明らかである。
T_exec α(1/N_proc) ．．．．．．．．．．．．（２）

さらに別の実施形態では、以下に示すように、必要なプロセッサの最適な数を決定する。 実際のケースでは、コードを並列実行するためにＮ個のプロセッサを有することができない場合もある。例えば、プロセッサが４つ存在する場合
１番目はマスター＝プロセッサ番号０
２番目にタスク又は関数Ｆ１を実行する＝プロセッサ番号１
３番目にタスク又は関数Ｆ２を実行する＝プロセッサ番号２
４番目にタスク又は関数Ｆ３を実行する＝プロセッサ番号３

タスクＦ４が実行準備状態にあるが、利用できるプロセッサがない場合には、むだ時間（Ｔ_dead）を計算する。

各モジュールは固有のインデックスを有するが、このインデックスは、タスクプログラムにおける並列処理コードインデックスセクションの番号に等しいものである。さらにインデックスはコールグラフにおいてそのタスクの近隣にある各タスクの実行時間にも依存するが、コールグラフは、逐次コンピュータコードの実行の実際のタイムスケールにおいて異なるタスクを実行するシーケンスをグラフで示したものを含む。

例えば、Ｆ１、Ｆ２、及びＦ３の実行にはそれぞれα_１、α_２、及びα_３の時間がかかるとする。Ｆ４が実行準備状態にあるが、プロセッサ１、２、及び２はＦ１、Ｆ２、及びＦ３の実行でビジー状態である場合には、タスクＦ４は、Ｆ４を実行できるプロセッサを利用できるようになるまで最低α_１、α_２、及びα_３の間待機しなければならない。このα_minがむだ時間となる。この状況を解決する方法の１つは、Ｆ１、Ｆ２、Ｆ３、及びＦ４の実行にかかる専用の時間を見出して、最長実行時間を見出すことである。Ｆ４の実行には（Ｆ１＋Ｆ２＋Ｆ３）を実行するための最長時間がかかる、又はＦ１／Ｆ２／Ｆ３の任意の組み合わせを同時に実行しなければならないと仮定する。

さらに、本明細書で示す方法は、むだ時間と待機時間に基づいて、任意の所与の逐次タスクプログラムの実行に必要な処理要素の最適な数を決定する。最適な数は、全ての処理要素の最大処理能力により待機時間とむだ時間を最短にできることを考慮することによって、決定される。

従って、任意のアプリケーションに必要なプロセッサの最適な数を得るために、Ｎ_proc＝１を選択することによって、タスク依存関係マトリックスを考慮する。この場合の実行時間を書き留めておく。Ｎ_procを一回に１増やし、Ｔ_exec(total)を書き留める。プロセッサを追加しても総実行時間に効果がでない場合もある。この場合のプロセッサ数を、このアプリケーションに必要な最適プロセッサ数（Ｎ_procopt）と称する。
Ｎ_procopt＝（その後実行時時間が一定＝Ｔ_constとなるＮ_proc）

このように、ここで示す方法は任意のアプリケーションに対して必要な処理要素の数を決定する。ユーザが実行時間に満足している場合もある（Ｔ_opt < Ｔ_const）。このような場合には、t >Ｔ_optとなるとすぐにシミュレーションを停止する必要がある。この場合には、プロセッサの最適な数はＮ < Ｎ_procoptとなる。上記の例は、ユーザが９５ｍｓよりも高速化する必要なしと考えている場合である。それ故、このように使用する場合のプロセッサの最適な数は５ではなく２となるであろう。図１、図３Ａ、図３Ｂ、図３Ｃ、及び図３Ｄは、実時間フレームに沿ったタスクＴ０、Ｔ１、Ｔ２、Ｔ３、Ｔ４、及びＴ５の再編成をグラフでして示している。図１は複数の処理要素を含む環境におけるタスクの再編成を示し、一方図３Ａから図３Ｄは、１つの追加的処理要素を含む状況を示している。

要約すると、処理要素の最適化は、実行する複数の処理要素にタスクを入力し、処理要素がタスクを実行し、各タスクの総実行時間を記録し、各処理要素の稼働時間を記録し、実行時間で稼働時間を割ることでリソースの使用を決定することにより、必要なリソースを最適化することを含む。さらに、最短実行時間を達成するために使用する処理要素数は、タスクの最速な実行を達成するのに必要なリソースの最小数である。

一実施形態では、実行に必要な最短時間とドル関数（Ｔ_max−Ｔ_min）＊（コスト関数）により、タスクの実行を並列処理した場合に節約される費用を決定する。従って、所与のアプリケーションを並列処理することに関して、費用対効果が高いかどうかを決定する。さらに、最大限の最適化を行うのに必要な追加コストを、一定数の処理要素と無限数の処理要素に対する実行時間の差で決定できる。

タスク依存関係の解析とタスクプログラムコード機能：
一実施形態で、開示する方法はデータ依存関係解析を実行し、並列実行できるタスクを見出す。なお、タスクプログラムは並列実行できる、又は元々の実行時間より前に実行できるコードピースを暗示する。

さらに、タスク依存関係情報とタスク状態情報を、共有データ構造メモリに格納する。１つのタスクが、１つ以上の他のタスクに対して複数のデータ依存関係を有する可能性がある。さらにタスクプログラムコード解析を実行する間に、アプリケーションプログラミングインタフェース（ＡＰＩ）コールを、それぞれのデータ依存関係が解消された後にタスクプログラムコードに挿入することができる。ＡＰＩは、タスク依存関係の解消を記すべく、共有データ構造メモリを変更する。

加えて、多数のデータ依存関係がある場合には、タスク再編成手段はすべてのデータ依存関係を解消した後にのみ、並列タスクを実行する。これは、機能を備えたコードを使用することで可能となるが、これは各データ依存関係の後に挿入したＡＰＩコードが各タスクに対して、そして全てのデータ依存関係に対してデータ構造中のデータ依存関係の解消を継続して行うためである。

依存関係を決定するには、個々のタスクを時間に沿ってマッピングすることが必要である。図２は、コードの実行中のタスクとそれらの依存関係との間のデータの流れを示す。タイムスケールを明確にするために実行時間も示している。

主記憶装置におけるデータ構造：
表Ｖは、処理要素で実行しているタスク再編成手段がアクセスする共有データ構造の必須要素である種々のヘッドを示す。

なお、各タスクに対してかかるデータ構造エントリが１つある。すべてのタスクに対して表Ｖを生成することで、データ依存関係解析を実行することができる。
タスクＩＤ：タスクを識別する独自の番号
状態：タスクの状態 − 実行準備状態、実行状態、非実行準備状態、待機状態等。
データ依存関係数：タスクの実行を開始する前に解消すべきデータ依存関係数。上述のＡＰＩ（タスクプログラムコードに挿入される）は本質的にこの数を減分することで、データ依存関係の解消を示す。よって、最初にこの数はこのタスクのデータ依存関係の数を示す。フィールドがゼロである場合には、すべてのデータ依存関係が解消されて、タスクを実行する準備が整っていることを示している。
このタスクの実行により利用可能となるタスクの数：このフィールドは他のタスクが幾つ、このタスクに依存しているかを示している。これはタスクの優先度として作用する。より多くのタスクがこのタスクに依存している場合には、利用できるタスクの全ての中でまずこのタスクを実行すべきである。
データポインタ：タスクを実行するのに必要なデータへのポインタ。これはグローバル変数を含み得る。
スタックポインタ：このタスクの実行中にコールスタックとローカル変数を含むスタックへのポインタ。

これらはタスク再編成手段が必要とする共有データ構造の必須のフィールドであることに留意されたい。システムの実際の実行によっては、この表により多くのフィールドが必要となる場合もある。

タスクの優先度の決定：一実施形態では、タスクの優先度の決定に関しては２つの要素、すなわちタスクの実行時間とそのタスクに依存している他のタスクの総数に基づいて行う。

まず、タスクに依存している他のタスクの数をカウントすることにより、タスクの優先度を設定する。他のタスクが多く依存しているタスクには、より高い優先度を割り当てる。以下のような持続時間によって優先度を再調整する：
ａ．タスク全てを持続時間の長い順に分類する；
ｂ．可変カウント値をタスクの総数に設定する；
ｃ．分類したリストにおける第１のタスクの優先度にカウント値を加算する；
ｄ．カウント値を減分する；
ｅ．分類したリストにおけるタスク全てに対して、優先度にカウントを加算しカウントを減分する操作を続ける。

いくつかの実施例により本発明をより詳細に述べるが、本発明は以下の実施例に限定されるととらえるべきではない。以下の例は、本発明の実施を例証するためのものであるが、それらの中で示す詳細は単なる例示であり、本発明の実施形態を説明するために用いるものであることを理解されたい。

実施例１
表VIで示すようにデータを有する７つのタスクを含む仮想コンピュータアプリケーションに関して考察する。
Ｔｉｄは、対象とするアプリケーションにおいてタスク名を指定するために使用する名前、即ちタスクのＩＤである。
Ｔｘは対応するタスクの実行に必要な時間である。
ＮＤＴは、対応するタスクの実行開始後にのみ実行を開始できるタスクの数である。優先度をタスクに割り当てる際には、特定のタスクによって解放される従属タスクの数を十分考慮する。
ＬＤＴは対応するタスクの実行中に解放されるタスクＩＤのリストである。
Ｔｗは、解放した特定のタスクの実行に要する時間であり、それまでは対応するタスクの実行を開始できない。
Ｔｓは、タスクがその実行を開始する実時間スケールにおける絶対時間である。この時間は、第１のタスクがスケジューリングされている第１リソースに対するものである。
Ｔｅは、その時点において経過した、実時間スケールにおける総時間である。この時間は、タスクがスケジューリングされているリソースに対して経過した時間に相当する。
ＳＦは、次の値を有するタスクの状態に対するフラグである：
ａ．Ｓ→スケジューリングされている又は実行開始されたタスク；
ｂ．ＮＳ→まだスケジューリングされていないタスク；
ｃ．Ｃ→タスクの実行が完了した。

タスク依存関係解放マトリックス（ＴＤＭ）＝Ｔ［Ｎ］［Ｎ］
Ｔ［ｉ］［ｊ］＝ｉ番目のタスクの実行が開始した後、ｊ番目のタスクの実行を開始するまでの待機時間を示す。すなわち、ｉ番目のタスクに対するｊ番目のタスクの依存関係は終了する。
Ｔ［ｊ］［ｉ］＝ｉ番目のタスクの開始後に、タスクｊが実行を開始するまでの待機時間を示す。

さらに、タスクの依存関係を決定すると、個々の処理要素にタスクを論理的に送って、複数の処理要素の完全な能力を把握ことが、本発明の目的である。利用可能な複数の処理要素のマッピングは、前記処理環境において処理を行うために利用可能なタスクを再編成する論理を導出することへの次のステップである。単一のプロセッサを有すると仮定することから始めるが、同じ論理により、対象とするコードを最も速く実行するようプロセッサの最適な数を決定することになる。このために、実時間で更新したプロセッサ状態シートを維持する。上に示した詳細には、本発明の適用可能性を制限するものは一切ないと理解できる。実施例２でより特定して示す。

実施例２：
同じ技術を有するエンジニアが、実行すべき種々のタスクに関する情報を含む中央の共有データベースにアクセスできると考える。データベース中の各タスクは固有の持続時間を有し、タスク同士の間には依存関係が存在する。エンジニアが行うことは、任意のタスクが実行準備状態にあるかどうかを周期的にチェックし、そのタスクの実行を開始することである。複数のタスクが実行準備状態にある場合には、エンジニアは常に最も優先度の高いタスクを選択し、そのタスクの実行を開始する。タスクを実行する間に、一部の他のタスクの依存関係が解消されると、エンジニアは中央データベースにおけるそのタスクに対するデータを修正する。この依存関係データの修正後に、より優先度の高いタスクが開始準備状態となる。このような場合、エンジニアは最も優先度の高いタスクの実行を開始する。最も優先度の高いタスクを開始する前に、エンジニアが現行のタスクの現在の状態を中央データベースに格納することで、他のエンジニアは手が空いていれば、そこでそのタスクに着手することができる。エンジニアはタスクを完了すると、タスクを実行したと中央データベース中のデータを修正し、開始準備状態にあるタスクを再びチェックする。その時点で準備状態にあるタスクがなければ、エンジニアは全てのタスクが完了するまで、開始準備状態にあるタスクがあるかどうか周期的にチェックし続ける。

タスクは関数と同義ではなく、タスクの再編成に関して考慮し得る最小単位のプログラム要素とすることが有利である。本発明の利点は次の通りである：
ａ．実際のタスク完了総時間を達成するのに必要なリソースの最適な数を決定する。
ｂ．コンピュータアプリケーションではないものに適応できる。

本発明を説明した特定の実施形態を参照することにより、本発明をより容易に理解できよう。ただし、上記の実施形態は単なる例示であり、本発明はその主旨及び範囲から逸脱することなく、特定的に示したものとは別の形態で実施できることを理解されたい。理解されるように、本発明は様々なその他の実施形態が可能であり、その幾つかの要素及びそれらに関連する詳細は、本発明の基本的概念を逸脱することなく、多様に変更することが可能である。従って本明細書の記載は本質的に例示であり、いかなる形態にも限定されない。当業者には、本明細書で示したシステム及び装置の変更及び変形が明らかであろう。かかる変更及び変形は、添付の特許請求の範囲に含むものと意図している。

Claims (23)

1. ある環境においてリソースを最適化するべく複数のタスクを再編成する方法であって、
   各タスクをマッピングして、各タスクを実行するべくタイムフレーム内で各関数要素及び変数の質的及び量的査定を得るステップと；
   前記マッピングから得たデータをＮ×Ｎの大きさのマトリックスで表すステップであって、Ｎはタスクの総数を示すステップと；
   前記マトリックス中に示すデータによって、前記タスクを再編成して実行するステップであって、前記タスクの再編成が静的方法及び動的方法の両方を提供するステップと；
   を含む方法。
2. 前記タスクの質的及び量的査定が、各タスクの実行時間、時間に沿ったデータ、前記タスク同士の依存関係、及び上流のタスクを実行した結果として下流のタスクを解放する図式を査定することを含む、請求項１に記載の方法。
3. 前記環境が少なくとも１つの処理要素と、タスクの値及び実行優先度の関数として各処理要素の状態値を記録するための共通した共有主記憶装置とを含む、請求項１に記載の方法。
4. 前記処理要素が、限定しないがマルチコアプロセッサ、対称型プロセッサ、及び非対称型プロセッサ等のプロセッサを含む、請求項３に記載の方法。
5. 前記タスクの動的再編成が、前記環境における全ての処理要素における前記タスクプログラムの実行と、前記共通した主記憶装置にタスクの実行状態を格納することを含む、請求項１に記載の方法。
6. ミューテックス又はセマフォ等の一般的なロック技術を使用して、前記主記憶装置における共有データへの排他的アクセスを保証する、請求項５に記載の方法。
7. タスクを実行する順序を決定する方法が前記タスクの優先度に基づく、請求項５に記載の方法。
8. 実行中、非実行準備状態、待機状態、又は完了状態等のフラグを介して前記タスクの状態をマーキングすることにより、前記主記憶装置中のデータを前記タスクの実行時間において修正することで、別の処理要素が同じタスクを選択して実行しないことを保証する、請求項５に記載の方法。
9. 動的タスク再編成手段と前記処理要素が同じレベルにあり、マスタースレーブ関係が存在しない、請求項５に記載の方法。
10. 前記タスクの静的再編成が前記タスクの優先度によって決定され、前記タスクの優先度が各タスクの実行時間と前記タスクに依存する他のタスクの数とに基づく、請求項１に記載の方法。
11. 前記タスクの値がタスクＩＤ、タスクの実行時間、依存するタスクの数、依存するタスクのリスト、タスクを解放するための待機時間、各処理要素に対する開始時間、対応する処理要素に対する経過時間、タスク状態フラグを含む、請求項３に記載の方法。
12. 前記処理要素の状態が、処理要素ＩＤ、実行すべきタスクのリスト、実時間スケールにおける各タスクの開始時間、実時間スケールにおける各タスクの完了時間、処理要素が利用可能となる時間、処理要素の処理能力、処理要素の転換、処理要素の待機時間、処理要素の応答時間を含む、請求項３に記載の方法。
13. 前記マトリックスが実行すべきタスクの数に等しい数の行及び縦列を有する正方行列であり、さらに前記マトリックスではＴ［ｉ］［ｊ］が、ｉ番目のタスクの実行が開始した後ｊ番目のタスクの実行を開始するまでの待機時間を示すと共に、ｉ番目のタスクの開始後に実行開始されるタスクｊの待機時間を示すことを特徴とする、請求項１に記載の方法。
14. 前記タスクを実行する優先度を決定することが、
    タスク全てを実行時間の長い順に分類するステップと；
    可変カウント値をタスクの総数に設定するステップと；
    分類したリストにおける第１のタスクの前記優先度にカウント値を加算するステップと；
    前記カウント値を減分するステップと；
    実行する優先度を割り当てるために、前記分類したリストにおけるタスク全てに対して、優先度にカウントを加算しカウントを減分する操作を反復して行うステップと；
    を含む、請求項３に記載の方法。
15. 全てのタスク依存関係を解消した後で、各タスクに対して、及び各タスク依存関係に対して前記データ構造中のデータ依存関係の解消を各タスク依存関係が記録した後、アプリケーションプログラムインタフェース（ＡＰＩ）コードとしての機能コードを挿入することにより、依存するタスクの実行を行うことができる、請求項１４に記載の方法。
16. リソースの最適化が、
    実行するために複数の処理要素にタスクを入力するステップと；
    前記処理要素が前記タスクを実行するステップと；
    各タスクの総実行時間を記録するステップと；
    各処理要素の稼働時間を記録するステップと；
    前記稼働時間を前記実行時間で割ることで前記リソースの使用を決定し、必要なリソースを最適化するステップと；
    により決定される、請求項１に記載の方法。
17. 実行時間が既定の実行時間以下になるまで処理要素の数を１つ増分することにより、各タスクの実行時間を計算するステップと、使用する前記処理要素の数を記録するステップと、によってタスクの実行に必要な処理要素の最適な数を決定する、請求項１に記載の方法。
18. 最短実行時間を達成するよう使用する処理要素の数が、前記タスクの最速な実行を達成するのに必要なリソースの最小数である、請求項１７に記載の方法。
19. 処理要素の数が一定である場合に必要な実行時間の決定が、処理要素が空くまで前記タスクの一部を遅延させ、依存関係から解放されるタスクの実行時間と数に基づいて実行すべきタスクを選択することを含む、請求項１に記載の方法。
20. 一定数の処理要素と無限数の処理要素に対する実行時間の差によって、最大限の最適化に必要な追加のコストを決定できる、請求項１に記載の方法。
21. 全ての処理要素の使用をチェックし、その後前記タスクが実行されるよう前記処理要素に割り当てられることにより、前記リソースの数が一定である場合のリソースの最適な使用を決定できる、請求項１に記載の方法。
22. コンピュータアプリケーションではないものにも前記方法を適用できる、請求項１に記載の方法。
23. 命令を有する記憶媒体を含む製品であって、コンピュータは前記命令を実行すると、請求項１に記載の方法を実行する製品。

Images