【発明の詳細な説明】
離散イベントシミュレーションを分散するシステムアーキテクチャ
関連出願の相互参照
本出願は、１９９７年７月１日に出願され、参照により関連付けられる米国仮
特許出願第６０／０５２，７７８号の特典として特許請求する。
発明の分野
本発明は、全般的には離散イベントシミュレーション（ＤＥＳ）および並列処
理に関する。
発明の背景
ＤＥＳの一般的なモデルについて説明するが、特定のシミュレーションアプリ
ケーション・ドメインを対象とするわけではない。ＤＥＳをそのオブジェクトお
よびイベント、イベント入力およびイベント出力、時間およびイベントの実行に
関して論じる。
オブジェクトおよびイベント
ＤＥＳは、指定されたシステムのふるまいを状態変化のシーケンスに分解する
ことによって、このふるまいを予測または再現することを試みる。システムの各
状態変化と、状態変化が起こる可能性のある各瞬間とを「イベント」と呼ぶ。
一般に、シミュレートされるシステムは、「オブジェクト」と呼ばれるシステ
ム要素の集合からなる。オブジェクトは、静的エンティティ（永久的であり定義
済みである）でも、あるいは動的エンティティ（必要に応じて作成され破壊され
る）でもよい。各オブジェクトはそれ自体のプライベートな状態を維持すること
ができる。これを「オブジェクトローカル状態」と呼ぶ。また、システムは、特
定のオブジェクトに属しない状態を有することができる。これを「システムグロ
ーバル状態」と呼ぶ。
一般的に言えば、イベントは通常、特定のオブジェクトに関連付けられる。特
にＤＥＳアプリケーションで、複数のオブジェクトに関連付けられた単一のイベ
ントを有することが可能である場合、このようなイベントを個々のオブジェクト
に関する一連のイベントに分解することによって、このシステムを一般的なモデ
ルに変換することができる。また、特定のオブジェクトに関連付けられないイベ
ントを有することが可能である場合、そのようなイベントの受容体となる特殊な
「グローバルオブジェクト」が作成される。したがって、ＤＥＳの一般的なモデ
ルの下では、イベントに応答して１つのオブジェクトのみが「アクティブ」にな
るとみなされる。このオブジェクトを「アクティブオブジェクト」と呼ぶ。
イベント入力およびイベント出力
イベントの間、システムの新しい状態がＤＥＳの状態のあるサブセットの関数
として算出される。この新しい状態をイベントの「入力」と呼ぶ。イベントは単
一のオブジェクトに関連付けられるが、イベントの計算が行われている間にシス
テムの状態の任意の部分を調べることができる。この任意の部分には、表１に示
すように、このオブジェクトおよびその他のオブジェクトのオブジェクトローカ
ル状態と、システムグローバル状態およびその他の情報が含まれる。
用語「イベントの詳細」は、生じるイベントを記述した情報の集合を指す。イ
ベントの詳細には、たとえば、イベントと共に「供給される」データを含めるこ
とができ、あるいはイベントの詳細はイベント自体の性質を表わすことができる
。因果関係を有するＤＥＳのみが考慮されることに留意されたい。このことは、
将来のイベントに含まれる情報ではイベント計算に影響を及ぼすことができず、
し
たがって、将来のイベントの詳細は、イベント入力として許容されないことを意
味する。
イベントの間に、システムの状態はいくつかの方法で変化する。変化のプライ
マリーエージェントはアクティブオブジェクトであり、アクティブオブジェクト
は「アクション」を実行することができる。また、オブジェクトおよびシミュレ
ーショングローバル状態を管理するＤＥＳの部分も同様に状態変化を生じさせる
ことができる。ＤＥＳのこれらの部分を集合的に「シミュレーションカーネル」
と呼ぶ。シミュレーションカーネルは基本的にＤＥＳのインフラストラクチャで
あり、通常、シミュレートされている特定のシステムに特有のものではない。た
だし、専用シミュレーションの場合は特定のシステムに特有のものでよい。
すべてのシステム状態変化を「イベント出力」と呼ぶ。イベント出力のリスト
を表２に与える。これらのイベント出力は基本的に、イベントを実行した場合の
有意の結果である。将来行われる新しいイベントの挿入および削除がイベント出
力とみなされることに留意されたい。新しいイベントの挿入は、ＤＥＳに新しい
仕事を与え、それによってＤＥＳが将来も引き続き実行することを可能にするメ
カニズムである。将来のイベントの集合は、それがすべてのＤＥＳのコア状態要
素であるので、システムグローバル状態の特殊なサブセットと考えられると明確
に言える。
時間およびイベントの実行
ＤＥＳ内のイベントは、「イベントリスト」と呼ばれる構造に格納される。イ
ベントリストは外部的には、イベントがシーケンスＥ［０］、Ｅ［１］、．．．
Ｅ［ｎ］を形成するという意味でリストとして働く。しかし、実際の基本的なイ
ンプリメンテーションは、効率を向上させるためにより複雑なデータ構造に依存
することができる。イベントが起こるかあるいは「実行される」ことが予定され
たシミュレーション時間がイベントにタグ付けされ、イベントは、単調増加する
シミュレーション時間の順にイベントリストから抽出することができる。概念的
には、イベントリストは表３に類似している。
シミュレーションの開始時には、イベントリストに特殊な「初期イベント」が
挿入される。イベントが実行されるにつれて、アクティブオブジェクトは、０個
、１個、あるいはそれよりも多くの追加のイベントをイベントリストに挿入させ
るか、あるいは「スケジューリングさせる」ことができる。アクティブオブジェ
クトは、現在のイベントとまったく同じシミュレーション時間の特殊な場合を含
め、将来の任意の時間に新しいイベントをスケジューリングすることができる。
１つのイベントしか残っておらず、このイベントが追加のイベントを生成しな
い場合、イベントリストが空になることが可能である。これは、ＤＥＳを終了さ
せるいくつかの条件のうちの１つである。
シミュレーション時間は、現在実行されているイベントの時間として定義され
る。したがって、図１の時間軸上に示すように、シミュレーション時間は、シミ
ュレーション全体にわたって通常は不規則な間隔で「ジャンプ」する。いくつか
のＤＥＳは、「時間ステップ」と呼ばれる範疇に分類され、「時間ステップ」は
、すべてのイベントが時間軸上で均等に分離されることを意味する（すなわち、
Ｅ［ｎ＋１］−Ｅ［ｎ］が一定である）。これは、イベント同士の間の任意の間
隔を許容する前述のより一般的な「イベントスケジューリング」手法の特殊な場
合に過ぎない。
ＤＥＳ内のイベントは従来、順次に実行される。ＤＥＳを実行する従来型のア
ーキテクチャは、イベントへのリスト式アクセスを実現する構造の中でイベント
を維持する。イベントは、実行される場合にリストから一度に１つずつ削除され
る。このイベントが完了するまで、すべての利用可能な計算資源がこのイベント
の計算に使用され、完了した時点で、次のイベントの処理を開始することができ
る。イベントは通常、新しい実行を開始する時間になったときに最も早いイベン
トへの定時アクセスを可能にするように順序付けられた状態に維持される。この
ような従来型のシステムを「逐次イベント実行」（ＳＥＥ）ＤＥＳと呼ぶ。この
ような従来型のシステムにおける有意の計算源を表４にリストする。
表４の定義が与えられた場合、ＳＥＥ ＤＥＳでイベントを完全に処理するた
めに必要な平均時間は、
Ｘ＝ｄ＋ｃ＋（ｎ・ｉ）
で表わされ、上式で、ｄは平均ｄであり、ｃは平均ｃであり、ｎは平均ｎであり
、
ｉは平均ｉである。
定常常態では、イベントリストが安定なサイズを有するので、各イベントの間
にイベントリストに挿入される新しいイベントの平均数は１である。したがって
、Ｘはｄ、ｃ、およびｉの単純な和になる。リストを順序付けることができるの
で、ｄは基本的に、リストのヘッドイベントを削除し、このヘッドイベント用の
適切なハンドラを呼び出すのに必要な非常に短い一定の時間である。さらに、ｃ
は主として、シミュレートされているイベントの複雑さに依存し、特定の種類の
シミュレーション問題に関して所与の値であると仮定することができる。
さらに、ｉは、イベントリスト構造での順序付けられた配置を必要とするので、
イベントリストを管理するために使用されるストラティジー(ｓｔｒａｔｅｇｙ)
の関数である。
ｄおよびｉの最適化は単純な問題であり、これらの変数に関しては大部分の従
来型のＤＥＳが効率的である。したがって、シミュレーション実行時間を改善す
るには、ｃを短縮することに注目しなければならない。ｃを短縮する場合、プロ
グラマはイベントの計算をできるだけ効率的に実施しなければならない。イベン
トの計算をできるだけ効率的に行った後で、ＳＥＥパラダイムの下でシミュレー
ションを加速するためにできることは、より高速のプロセッサを使用することを
除いてほとんどない。
したがって、所与の問題領域内および所与のプロセッサ上で、ＳＥＥ ＤＥＳ
はそのイベントスループットに対する固有の限界を有する。さらなる向上を図る
には、イベントスループットを増大しなければならない。一般に、ＳＥＥのすべ
ての代替形態は、同時処理、すなわち、複数のイベントを複数のプロセッサに分
散することによってそれらのイベントを並行して処理することに依存する。これ
を行うためにいくつかの手法が提案されており、実験または商業製品として実施
されている。各手法は利点を有し、したがって特定の種類のシミュレーション問
題に適用できるが、これらの手法のうちで、一般的な場合にイベントスループッ
トを大幅に増大することのできる手法はなく、各手法は、インプリメンテーショ
ンおよび実行面で欠点および難点を有する。発明の概要
本発明の目的は、単一のイベントリストを使用してＤＥＳのイベントスループ
ットを増大することである。
本発明の他の目的は、特定のコンピュータハードウェアインプリメンテーショ
ンと共に使用できる並列シミュレーションを実施するアーキテクチャを提供する
ことである。
本発明の他の目的は、複数のプロセッサを並行して使用することによってＤＥ
Ｓの実行を加速する技法を提供することである。
本発明の他の目的は、シミュレーションプログラマまたはユーザがＤＥＳの基
本的なイベント処理アーキテクチャを意識しないＤＥＳを提供することである。
たとえば、シミュレーションプログラマまたはユーザは、利用可能なプロセッサ
に小部分を割り付けるにはＤＥＳシステムを物理的にどのように区画すればよい
かを考える必要がなくなる。その代わり、本発明は、追加のプロセッサを利用す
るように自動的にスケーリングし、１つのプロセッサしか利用できないときには
従来型のＤＥＳになる。
本発明は、方法、コンピュータシステムを備える装置、およびコンピュータプ
ログラムを実現するコンピュータ読取り可能媒体を含むがこれらに限らない、い
くつかの方法で実現することができる。
方法で実現される本発明は、ヘッドイベントを有する離散イベントシミュレー
ション用のイベントリストを維持すること、ヘッドイベントが未計算であるか、
それとも計算中であるか、あるいはそれとも計算済みであるかを判定することを
含む、離散イベントシミュレーションのイベントスループットを増大する方法を
含む。ヘッドイベントは、未計算であると判定された場合には実行される。ヘッ
ドイベントは、計算中であると判定された場合には、このヘッドイベントの計算
が完了したときに計算済みとして示される。ヘッドイベントが計算済みであると
判定された場合には、このヘッドイベントの計算が有効であるか、それとも無効
であるかが判定される。ヘッドイベントの計算が有効であると判定された場合は
、このヘッドイベントの計算が適用され、ヘッドイベントの計算が無効であると
判定された場合は、ヘッドイベントが実行される。
方法の場合、離散イベントシミュレーションは現在のシステム状態を有し、ヘ
ッドイベントの計算を適用することは、ヘッドイベントの計算に基づいて現在の
システム状態を変更することを含む。さらに、ヘッドイベントの計算が有効であ
るか、それとも無効であるかの判定では、入力不変性を使用することができる。
さらにイベントリストは、イベントの順序付けられた集合でよい。また、イベン
トリストは、複数のイベントと、未計算イベントとして示された少なくとも１つ
のイベントとを含み、この方法はさらに、イベントリストから未計算イベントを
選択すること、および未計算イベントの計算を実行することを含む。
他の方法で実現される本発明は、複数のイベントと、未計算イベントとして示
された少なくとも１つのイベントとを有する離散イベントシミュレーション用の
イベントリストを維持すること、未計算イベントとして示されたイベントをイベ
ントリストから選択すること、選択されたイベントをイベント事前計算プロセス
に割り当てること、イベントリスト内の選択されたイベントを計算中イベントと
して示すこと、イベント事前計算プロセスを使用して、選択されたイベントの計
算を行うこと、イベント事前計算プロセスから計算を受け取ること、イベントリ
スト内の選択されたイベントを計算済みイベントとして示すことを含む、離散イ
ベントシミュレーションのイベントスループットを増大する方法を含む。
この方法では、イベント事前計算プロセスを使用して選択されたイベントの計
算を行うことは、イベント事前計算プロセスにイベント入力を与えること、選択
されたイベントおよびイベント入力に基づいてシステム状態の変化を判定するこ
とを含む。イベント事前計算プロセスから計算を受け取ることは、イベント入力
とシステム状態の変化とをイベント事前計算プロセスから受け取ることを含み、
イベントリスト内の選択されたイベントを計算済みイベントとして示すことは、
イベント入力とシステム状態の変化とを選択されたイベントに関連付けることを
含む。
さらに、この方法はさらに、選択されたイベントをイベントリスト内の計算済
みヘッドイベントとして示すこと、およびヘッドイベントに関連するイベント入
力と現在のシステム状態を比較することによって、ヘッドイベントを検証し、ヘ
ッドイベントが有効であるか、それとも無効であるかを判定することを含む。ヘ
ッドイベントが有効である場合、ヘッドイベントに関連するシステム状態の変化
を使用して現在のシステム状態を更新することによってヘッドイベントの計算が
適用される。
他の方法で実現される本発明は、計算済みイベントとして示された複数のイベ
ントを有する離散イベントシミュレーション用のイベントリストを維持すること
、計算済みイベントとして示された複数のイベントをイベントリストから選択す
ること、および選択されたイベントが有効であるか、それとも無効であるかを判
定することを含む、離散イベントシミュレーションのイベントスループットを増
大する方法を含む。選択されたイベントが無効である場合、この選択されたイベ
ントがイベント事前計算プロセスに割り当てられ、イベントリスト内のこの選択
されたイベントが計算中イベントとして示され、イベント計算プロセスを使用し
て、選択されたイベントの計算が行われ、イベント事前計算プロセスからこの計
算が受け取られ、イベントリスト内のこの選択されたイベントが計算済みイベン
トとして示される。
装置で実現される本発明は、１つのイベントがヘッドイベントとして示され、
各イベントが未計算イベント、計算中イベント、または計算済みイベントとして
示される複数のイベントを含むイベントリストを維持する手段と、未計算イベン
トの計算を行う少なくとも１つのイベント事前計算プロセスを実行する手段と、
未計算イベントを選択し、この未計算イベントを１つのイベント事前計算プロセ
スに転送する手段と、未計算イベントを実行し計算済みイベントを検証する手段
とを備える、離散イベントシミュレーションを実行するコンピュータシステムを
備える。
この装置では、少なくとも１つのプロセッサは、イベントリストを維持する手
段と、未計算イベントを選択しこの未計算イベントを転送する手段と、未計算イ
ベントを実行し計算済みイベントを検証する手段とを実装することができる。さ
らに、複数のプロセッサが、未計算イベントの計算を行う手段を実装することが
できる。
本発明では、コンピュータシステムは、ネットワークと介して接続された１つ
または複数のコンピュータを備える。さらに、コンピュータシステム内の各コン
ピュータは、１つまたは複数のプロセッサを有することができる。
製造品で実現される本発明は、離散イベントシミュレーションを実行するコー
ドセグメントを実現するコンピュータ読取り可能媒体を備える。コードセグメン
トは、各イベントが未計算イベント、計算中イベント、または計算済みイベント
として示される、ヘッドイベントを含む複数のイベントを含むイベントリストを
維持するコードセグメントと、未計算イベントの計算を行う少なくとも１つのイ
ベント事前計算プロセスのそれぞれ用のコードセグメントと、イベントリストを
スキャンし、未計算イベントを選択し、１つのイベント事前計算プロセスにこの
未計算イベントを割り当て、イベント事前計算プロセス用のコードセグメントに
従って計算を行わせるイベントリストスキャンプロセス用のコードセグメントと
、未計算イベントを実行し計算済みイベントを検証するイベントリストマネージ
ャ用のコードセグメントとを備える。
本発明では、コンピュータプログラムを実現するコンピュータ読取り可能媒体
は、１つまたは複数のプロセッサを本発明を実行するように制御するコードセグ
メントを備える。「コンピュータ読取り可能媒体」の非制限的な例には、磁気ハ
ードディスクや、フロッピィディスクや、光ディスクや、磁気テープや、メモリ
チップや、電子メールを送受信するか、あるいはインタネットなどの電子データ
ネットワークにアクセスする際に使用されるような電子データを保持するために
使用される搬送波が含まれる。さらに、「コードセグメント」の非制限的な例に
は、ソフトウェアや、命令や、コンピュータプログラムや、１つまたは複数のプ
ロセッサを制御する手段が含まれる。
図面の簡単な説明
本発明の実施形態は図面を介して詳しく説明される。
図１は、時間軸に沿ったＤＥＳの不規則なイベント間隔を示す図である。
図２は、本発明のイベントアーキテクチャの選択的な事前計算を使用するイベ
ント処理を示す図である。
発明の詳細な説明
本発明は、単一のイベントリストのパラダイム内で働く加速メカニズムとして
イベントの選択的な事前計算（ＳＰＥ）を使用する。本発明を用いた場合、イベ
ントの管理は、１つのプロセッサを用いて集中化され、イベントの実行は他の利
用可能なプロセッサに分散される。
ＳＰＥは、従来型のイベントリストを使用し、リスト内のイベントを実行する
ために、「イベントリストマネージャ」（ＥＬＭ）と呼ばれる単一のプロセスま
たはスレッドに依存する。（用語「プロセス」は、１つまたは複数のプロセッサ
上で実行される１つまたは複数のプログラムを指す。）ＳＰＥは、イベントスル
ープットを増大することが可能なときには、イベントを「事前計算」するために
、他のプロセッサ上で実行することのできる追加のプロセスにも依存する。この
ようなプロセスを「イベント事前計算プロセス」（ＥＰＰ）と呼ぶ。本発明の一
実施形態では、各ＥＰＰは別々のプロセッサ上で実行される。ＳＰＥの目的は、
できるだけ多くの将来のイベントを自由なプロセッサに割り当て並行して実行し
、かつイベントの実際のシミュレーション時間に達したときに、これらのプロセ
ッサによって実行された「仕事」または計算が依然として有効でかつ使用可能で
あるように、この仕事を記憶することである。
標準イベント処理アーキテクチャの場合と同様に、通常のイベントは本発明の
イベントリストに入り、実行を待つ。イベントリストは、事前計算すべきある種
のイベントを選択する「イベントリストスキャンプロセス」（ＥＳＰ）によって
スキャンされる。ＥＳＰは、たとえばＥＬＭのサブタスクとして実施することが
できる。イベントは、任意の時間に未計算イベント（ＵＣＥ）、計算中イベント
（ＩＣＥ）、および計算済みイベント（ＰＣＥ）の３つの範疇の１つに入ること
ができる。関連する仕事が実際の実行時間まで有効なままであるＰＣＥを使用可
能計算済みイベント（ＵＰＣＥ）と呼ぶ。この４種類のイベントを表５に定義す
る。 図２は、本発明のＳＰＥアーキテクチャを使用するイベント処理を示す。ＥＳ
Ｐは、イベントリストをスキャンしてＵＣＥがあるかどうかを調べる。ＵＣＥが
見つかった場合、ＥＳＰがそのＵＣＥを処理のためにＥＰＰへ送り、イベントリ
スト内のＵＣＥの表示がＵＣＥからＩＣＥに変更される。ＥＰＰが終了すると、
結果として得られたＰＣＥが出力され、イベントリスト内のＩＣＥがＰＣＥに変
更される。
すべてのイベントは、その状態にかかわらず、実行されるまで引き続きイベン
トリスト内に表わされる。イベントを実行することができるのは、そのイベント
がイベントリストのヘッド部に到達し、ヘッドイベントと呼ばれるようになった
ときだけある。この時点で、イベントの処理はイベントの状態に依存する。図２
で、ヘッドイベントは、イベントリストの１番下に示され、ＰＣＥであるイベン
トとして示されている。
図２に示すように、ヘッドイベントには３つの可能な状態がある。第１に、ヘ
ッドイベントは、ＵＣＥである場合には、ＳＥＥアーキテクチャの場合と同様に
、イベントリストを管理する責任を負うプロセスによって処理される。
第２に、ヘッドイベントがＩＣＥである場合、このヘッドイベントがＰＣＥに
なるまで、ＥＬＭによる追加のイベント実行は進行することができない。ＥＬＭ
が進行した場合、イベント同士の間の因果関係が損なわれる可能性がある。ＥＬ
Ｍは、事前計算が完了するまで他の処理をブロックするか、あるいはイベントリ
ストをスキャンするための時間を使用して、事前計算すべき他のイベントを選択
することができる。
第３に、ヘッドイベントが（図２に示されている）ＰＣＥである場合、ＥＬＭ
は、事前計算が依然として有効であること（すなわち、ヘッドイベントがＵＰＣ
Ｅでもあること）を検証しなければならない。ヘッドイベントがＵＰＣＥである
場合、イベント実行は、記憶されている結果の「適用」のみからなる。言い換え
れば、記録されているイベント出力を使用してシステム状態が修正される。
イベント計算の入力
イベントがＳＰＥアーキテクチャ内のＥＰＰによって事前計算されるか、それ
ともＥＬＭによって直接計算されるかにかかわらず、イベントの計算が行われる
とき、イベントは同じ１組の「イベント入力」に依存する。用語「イベント入力
」は、イベント計算中に分析することのできるＤＥＳの部分に記憶される状態情
報のすべての要素の集合を指す。
本発明は、ＥＬＭにイベントを計算させるのではなく、ＥＰＰにより計算され
るＥＬＭ確認イベントを持つことによって、ＤＥＳのスループットを増大する。
本発明を用いた場合、ＤＥＳのイベントスループットは、単一のプロセッサがど
れだけ高速にイベントを完全に計算できるかではなく、単一のプロセッサがどれ
だけ高速にイベントを確認できるかの関数である。より高い性能を実現する本発
明の条件は、イベントの確認がイベントの完全な計算よりも簡単であるというこ
とである。したがって、ＰＣＥ確認メカニズムはＳＰＥアーキテクチャの重要な
部分である。
事前計算が、ＥＬＭによるイベントの直接実行と比較したときに同一の結果を
生成するかどうかを判定するには、イベントの事前計算中にどの入力が使用され
たかについての知識が必要である。このような入力が変化すると、イベントの計
算が異なるものになる可能性があり、保守的な見方により、このような変化は事
前計算を無効化するとみなすべきである。入力の介入的な修正を行うことを不要
にすることは、ＳＰＥベースのシステムが計算済みイベントを確認するための簡
単な手法である。この手法を「入力不変性(ｉｎｐｕｔ ｉｎｖａｒｉａｎｃｅ)
」と呼ぶ。イベントが実行を開始すると、一般に、どの入力がアクセスされるか
を事前に判定することは不可能である。このことは、条件付き制御フローを含め
、イベントの間に一般的な命令をサポートするシステムで特にそうである。した
がって、入力不変性を実施するには、事前計算中にどの入力が使用されたかを検
出し保持するある種の方法が必要である。
イベントの入力の変化の性質と、入力を使用する方法とに応じて、イベントは
変化にかかわらず厳密に展開することが可能である。したがって、入力不変性は
、ＳＰＥ ＤＥＳで確認を実施する保守的な手法である。より高度な確認方式は
、イベント入力の使用に関するより詳細な情報を考慮し、したがって、確認に必
要な条件を緩和することができる。
イベント計算の出力
イベントの実行中に、多数の異なるアクションを行うことができる。ある種の
アクションは、イベントの完全に内部のアクションであり、他のイベントに対す
る影響を有さないものとみなすことができる。内部アクションは、たとえば、ロ
ーカル計算で使用される一時変数を修正したアクションでよい。内部アクション
は他のイベントに影響を与えないので、このような内部アクションは、それが行
われたことを「記憶する」必要なしに事前計算の一部として実行することができ
る。
イベントには、外部効果を有するアクションを含めることができる。このよう
な外部アクションまたはイベント出力は、他の進行中のイベント計算または将来
のイベント計算に干渉しないように行わなければならない。この問題に対するＳ
ＰＥ手法は、本発明を他の従来型のシミュレーションアーキテクチャと区別する
いくつかの要因のうちの１つである。
各イベント出力は、ＤＥＳの状態に１つまたは複数の変化を生じさせることが
できる。イベントＥがＰＣＥとして算出された場合に、このような変化を生じさ
せると、他の進行中のイベント計算によって認識されるシステム状態のビューが
修正される。さらに、変化を生じさせることによって、イベントＥの最初の実行
と最後の実行との間に行われるＰＣＥ計算によって認識されるシステム状態が修
正される。
本発明のＳＰＥアーキテクチャでは、イベント出力は基本的に、実際のシステ
ム状態に安全に適用できるようなときまで「バッファされる」。このことは、変
化が起こった場合でも、最後のイベント実行の時間までこの変化がシステム状態
に影響を及ぼすことが許可されないことを示す。前述のように、入力不変性など
の基準に従ってＰＣＥが無効であると判定された場合、すべての変化が破棄され
る。したがって、変化は、２つの要件を満たすように特別なコンテキストで起こ
る。
第１に、実行時に出力を同様に再生できるように出力に関する十分な情報を記
録しなければならない。検証が成功した場合、図２に示すように、アクションが
実際に実施されるのは「結果の適用」フェーズの間である。
第２に、イベントの事前計算中にシミュレーション状態の一貫したビューを与
えるために、出力の実際の適用を一時的にエミュレートしなければならない。た
とえば、オブジェクトがオブジェクトの１つの属性を修正し、次いで同じイベン
ト（および任意選択で後続のＰＣＥ）の間にこの属性の値を問い合わせた場合、
この問合せから、新たに割り当てられた値が得られる。したがって、各オブジェ
クトに関連するイベント処理メソッドは、それが事前計算のために実行されるの
か、それとも直接計算のために実行されるのかを知る必要がなくなる。
第２の要件が与えられた場合、システム状態の２つの異なるビュー（またはシ
ステム状態のサブセット）が一時的に共存する。一方のビューは、当該のＰＣＥ
のコンテキストで有効であり、他方のビューはＥＬＭによる最後のイベント実行
のコンテキストで有効である。しかし、この場合、この２つの時間の間に起こる
イベントにはこれらのビューのどちらが有効であるかという問題が残る。最後の
イベント実行で使用される確認メカニズムによって、イベントを計算するときに
適切なシステム状態が使用されるので、２つのビューのどちらを使用しても正し
い解決策を与えることができる。各手法は異なる性能を有し、ＤＥＳ用にどの手
法を選択するかは、特定のＤＥＳまたはＤＥＳ環境に関して検討すべきである。
イベントのディスパッチおよび検索
本発明のＳＰＥアーキテクチャを効率的に実施するうえでの１つの重要なキー
ファクターは、イベントの制御をＥＰＰに転送するために使用されるメカニズム
である。イベントの最後の実行に関わるＥＬＭをサポートする同じプロセッサ上
でこのタスクを実行する場合、一度に確認して実行の適用フェーズを通過させる
ことのできるイベントは１つだけなので、ＥＰＰのオーバヘッドによって総イベ
ントスループットが低減する。したがって、イベントリスト情報にアクセスする
独立のプロセッサを使用してイベントディスパッチを実行するか、あるいは効率
に留意してイベントディスパッチを実施すべきである。
ＵＣＥであるイベントＥに対するイベントディスパッチの目的は、ＥＰＰがイ
ベントＥをＰＣＥにするのに必要なすべての状態情報をＥＰＰに供給することで
ある。イベントＥを事前計算した後、何らかの方法でこのイベントの出力を最後
の実行までにＥＬＭに戻さなければならない。このメカニズムを「イベント出力
検索」と呼ぶ。
イベントＥをＥＰＰにディスパッチした後、イベントＥのすべての入力がＥＰ
Ｐにアクセスできなければならない。上記で指摘したように、イベントＥを実際
に計算する前にイベントＥがどの入力を必要とするかを知っておくことは困難で
ある。したがって、ＥＰＰにすべての可能な入力情報を供給しなければならず、
あるいはＥＰＰが必要に応じてこの情報にアクセスできなければならない。
多数の異なるインプリメンテーションが可能であり、これらのメカニズムの効
率はサポートするハードウェアの基本アーキテクチャに強く依存する。たとえば
、すべてのプロセッサが、ＵＣＥに関する情報を転送するのではなく、単一のメ
モリ空間を共用できる場合、ＵＣＥをＥＰＰにディスパッチする際にＥＰＰに転
送する必要があるのはＵＣＥの参照だけである。高度にスケーリングできるハー
ドウェアアーキテクチャはこの機能を実現できないので、ＳＰＥアーキテクチャ
のいくつかのインプリメンテーションはメッセージベースのディスパッチ検索メ
カニズムを必要とする。
ＳＰＥアーキテクチャの変形形態
当業者には認識されるように、本発明のＳＰＥアーキテクチャを実施するため
の多数のオプションが可能である。特定のＤＥＳおよび特定のハードウェアの特
定の態様を利用して重要な効率上の利益を実現することができる。すでに前節で
論じた点だけでなく、インプリメンテーションに特有の以下の３つの点を、可能
な効率上の利得について分析すべきであり、これらは現行の技術を使用して実施
することができる。
第１に、イベントの選択を検討すべきである。ＥＳＰがイベントリストから事
前計算すべきイベントを選択する際、ＥＳＰは、それがイベントに出会う順にイ
ベントを選択する必要はない。その代わり、ＥＳＰは、ＳＰＥアーキテクチャの
利得を最大にすることを試みるヒューリスティクスに基づいてイベントをインテ
リジェントに選択することができる。この場合の重要な点は、ＰＣＥが、イベン
トの種類や関連するオブジェクトなどの情報に基づいて、有効なままでありＵＰ
ＣＥになる可能性が高いことである。また、イベントのディスパッチおよび検索
に関するオーバヘッドが等しい場合、より計算を多用するある種のイベントが事
前計算に有利である可能性がある。イベント選択ヒューリスティクスは、複雑で
、かつＤＥＳに関する特定の知識に強く依存することがある。
第２に、プロセスの割当てを検討すべきである。単一のプロセスまたは独立の
プロセスがＥＬＭとＥＳＰの両方を実施することができる。ＥＬＭおよびＥＳＰ
は、単一のプロセッサまたは別々のプロセッサ上で実行されるように実施するこ
とができる。図２に示すように、追加のプロセッサを検証フェーズ、適用フェー
ズ、および完全実行フェーズに使用することができる。
第３に、状態情報の動的分散を検討すべきである。システムの状態を記憶する
ときに中央に集中された共用メモリに依存しないイベントディスパッチ手法を使
用する場合、イベント入力にアクセスする効率を向上させるために様々な技法を
使用することができる。たとえば、オブジェクトまたはＤＥＳの状態の他の部分
が特定のプロセッサに関連付けられた後、このプロセッサの専用メモリ内にこの
情報を保持し、このオブジェクトに関するイベントを同じプロセッサに優先順位
に基づいてディスパッチすることが最も効率的である可能性がある。このような
手法は、ある種のＤＥＳに関する通信オーバヘッドを低減することができる。シ
ミュレーションが行われている間、利用可能なプロセッサにシステムの状態を動
的に分散することができる。このような技法の適用性は、ＤＥＳの性質とサポー
トするハードウェアのアーキテクチャとに強く依存する。
ＳＰＥアーキテクチャの変形形態として、ＥＳＰの代替形態を使用することが
できる。たとえば、ＥＳＰに、ＵＣＥをＥＰＰに割り当てさせるのでなく、ＥＰ
Ｐがイベントリストにアクセスし、ＥＰＰ自体が、事前計算すべきＵＣＥを選択
することができる。別の例として、ＥＬＭは、ＥＳＰの機能を実行することがで
き、ＥＰＰがＥＬＭをＵＣＥについてポーリングした後、ＥＬＭはＥＰＰにＵＬ
Ｅを供給することができる。一般に、本発明では、ＵＣＥがＥＰＰに転送され、
これを様々な方法で行うことができる。
ＳＰＥアーキテクチャの変形形態として、未処理、処理中、および処理済みな
ど他のラベルを用いてイベントリスト内のイベントを示すことができる。さらに
、イベントリストは、本明細書で説明した３種類のイベントのみに限らず、ＤＥ
Ｓのインプリメンテーションの必要に応じて他の種類のイベントを含むことがで
きる。
ＳＰＥアーキテクチャの他の変形形態として、イベントリストは複数のヘッド
イベントを有することができる。複数のイベントリストを未計算イベントリスト
、計算中イベントリスト、または計算済みイベントリストとして示すことができ
る。複数のヘッドイベントは、「互いに十分に独立した」イベントである場合、
１つまたは複数のＥＬＭによって並行して確認または実行することができる。互
いに十分に独立させるには、各ヘッドイベントの出力が他のヘッドイベントの計
算にそれほど影響を与えないようにすべきである。たとえば、複数のイベントが
同じシミュレーション時間を用いて示され（表１と同様に、イベントＥ［１］と
イベントＥ［２］が同じ時間０．１を有する）、イベントリストのヘッド部に到
着する場合、これらの複数のイベントは、複数のヘッドイベントとみなすことが
でき、並行して確認または実行されるほど互いに独立したイベントである。一般
に、複数のヘッドイベントを使用すると、イベントがいつ互いに十分に独立した
イベントになるかに関してアプリケーション特有の決定が下され、性能上の十分
な利得を得ることができる。
ＳＰＥアーキテクチャの改良形態として、ＥＬＭは、イベントリストをスキャ
ンしてＰＣＥがあるかどうかを調べ、ヘッドイベントであるＰＣＥの場合と同じ
方法をイベントリスト内のＰＣＥに適用することができる。イベントリスト内の
各ＰＣＥについて、ＥＬＭは、ＰＣＥの事前計算が依然として有効であるかどう
かを判定する。イベントリスト内の検証すべきＰＣＥを選択する場合、ＥＬＭ、
あるいはおそらく他のプロセスがイベントリストを周期的または非周期的にスキ
ャンすることができる。ＰＣＥを選択した後、ＥＬＭ、あるいはおそらく他のプ
ロセスがイベントリスト内のＰＣＥを検証する。ＰＣＥの事前計算が有効である
場合、ＥＬＭはＰＣＥを修正しない。ＰＣＥの事前計算が無効である場合、ＥＬ
ＭはＰＣＥをＩＣＥとして示し、１つのＥＰＰを選択し、新たに示されたＩＣＥ
の計算を再開する。計算を再開するこの方法は、上記でＩＣＥの計算を行う場合
に論じた方法と同じである。
ＥＬＭのスキャンによってイベントリストからＰＣＥが選択された直後にこの
ＰＣＥを検証することの代替形態として、ＥＬＭは、ＰＣＥを検証する前にまず
、そのＰＣＥが最近検証されたかどうかを判定することができる。この場合、た
とえば、各ＰＣＥは検証時間インディケータを含むことができる。検証時間イン
ディケータは最初、イベントリスト内のイベントの表示がＩＣＥからＰＣＥに変
更される時間に設定される。ＥＬＭは、検証すべきＰＣＥを選択した後、現在時
間とこのＰＣＥについての検証時間インディケータとの間の差としきい値を比較
することによって、このＰＣＥが最近検証されたかどうかを検査する。この差が
しきい値よりも小さい場合、このＰＣＥは、最近検証されているので検証されな
い。差がしきい値以上である場合、このＰＣＥは、最近検証されておらず、前述
の検証方法を使用して検証される。ＰＣＥが検証された後、検証時間インディケ
ータは現在時間に変更される。各ＰＣＥについての検証時間は最初、そのイベン
トがＰＣＥとして示された時間に設定される。
本発明をＤＥＳ向けに実施することの代替形態として、本発明は、複数のプロ
セッサを用いて実施されるコンピュータプログラムのタスクスループットを増大
するように実施することができる。この代替実施形態では、イベントはタスクま
たはサブタスクと等価である。言い換えれば、タスクおよびサブタスクで構成さ
れたコンピュータプログラムの実行速度を、複数のプロセッサおよび上記の方法
を使用して高めることができる。
さらに、本発明は、ある程度の独立性を有する一連の演算からなるプログラム
に適用することができる。当業者には自明なように、これらの演算が互いに独立
である程度は、実現できる性能の向上を決定する１つの要因である。多くの実際
的な場合に、ＤＥＳは、本発明の手法を利用できるほど互いに独立したイベント
に分解することができる。
本発明を好ましい実施形態に関して詳しく説明したが、当業者には、上記のこ
とから、本発明の広義の態様において本発明から逸脱せずに変更および修正を加
えられることが明らかであろう。したがって、本発明は、添付の請求の範囲で定
義されるように、本発明の真の趣旨の範囲内に入るすべてのこのような変更およ
び修正をカバーするものである。DETAILED DESCRIPTION OF THE INVENTION System Architecture for Distributed Discrete Event Simulation Cross-reference of related applications This application claims the benefit of US Provisional Patent Application Ser. No. 60 / 052,778, filed Jul. 1, 1997, and incorporated by reference. Field of the invention The present invention relates generally to discrete event simulation (DES) and parallel processing. Background of the Invention A general model of DES is described, but is not intended for a particular simulation application domain. DES is discussed in terms of its objects and events, event inputs and outputs, time and execution of events. Objects and Events DES attempts to predict or reproduce this behavior by decomposing the specified system behavior into a sequence of state changes. Each state change of the system and each moment at which a state change may occur is called an "event." Generally, a simulated system consists of a collection of system elements called "objects". Objects can be static entities (permanent and defined) or dynamic entities (created and destroyed as needed). Each object can maintain its own private state. This is called "object local state". Also, the system can have states that do not belong to a particular object. This is called a “system global state”. Generally speaking, events are usually associated with a particular object. If it is possible, especially in a DES application, to have a single event associated with multiple objects, this system can be modeled by breaking such events into a series of events for individual objects. Can be converted to Also, if it is possible to have events that are not associated with a particular object, a special "global object" is created that will accept such events. Thus, under the general model of DES, only one object is considered to be "active" in response to an event. This object is called an “active object”. Event input and event output During an event, the new state of the system is calculated as a function of some subset of the state of DES. This new state is called the "input" of the event. Although the event is associated with a single object, any part of the state of the system can be examined while the calculation of the event is taking place. This optional part includes the object local state of this and other objects, as well as the system global state and other information, as shown in Table 1. The term "event details" refers to a collection of information describing the event that occurs. The event details may include, for example, data "supplied" with the event, or the event details may represent the nature of the event itself. Note that only causally related DESs are considered. This means that the information contained in future events cannot affect the event calculation, and therefore the details of future events are not allowed as event inputs. During an event, the state of the system changes in several ways. The primary agent of change is the active object, which can perform "actions". In addition, the DES part that manages the object and the simulation global state can also cause a state change. These parts of the DES are collectively called the "simulation kernel". The simulation kernel is fundamentally the infrastructure of the DES and is usually not specific to the particular system being simulated. However, in the case of the dedicated simulation, it may be specific to a specific system. All system state changes are called "event outputs." A list of event outputs is given in Table 2. These event outputs are basically the significant results of executing the event. Note that future insertions and deletions of new events are considered event outputs. Inserting a new event is a mechanism that gives DES new work, thereby allowing DES to continue running in the future. The set of future events can clearly be considered as a special subset of the system global state, since it is the core state element of all DES. Time and Event Execution Events in the DES are stored in a structure called an "event list". The event list externally stores events in the sequence E [0], E [1],. . . It works as a list in the sense that it forms E [n]. However, actual basic implementations can rely on more complex data structures to increase efficiency. The simulation time at which the event occurs or is scheduled to be "executed" is tagged to the event, and the event can be extracted from the event list in order of a monotonically increasing simulation time. Conceptually, the event list is similar to Table 3. At the start of the simulation, a special “initial event” is inserted into the event list. As events are executed, the active object can cause zero, one, or more additional events to be inserted or "scheduled" into the event list. The active object can schedule a new event at any time in the future, including the special case of exactly the same simulation time as the current event. If only one event remains and this event does not generate additional events, the event list can be empty. This is one of several conditions that terminate DES. Simulation time is defined as the time of the currently executing event. Thus, as shown on the time axis of FIG. 1, the simulation time “jumps”, usually at irregular intervals throughout the simulation. Some DES fall into a category called "time steps", which means that all events are evenly separated on the time axis (i.e., E [n + 1] -E [ n] is constant). This is just a special case of the more general "event scheduling" approach described above, which allows for arbitrary intervals between events. Events in the DES are conventionally executed sequentially. Traditional architectures implementing DES maintain events in a structure that provides list-based access to the events. Events are removed from the list one at a time when executed. Until this event is completed, all available computing resources are used to calculate this event, at which point processing of the next event can begin. Events are typically maintained in an ordered state to allow for scheduled access to the earliest event when it is time to start a new execution. Such a conventional system is called "sequential event execution" (SEE) DES. Table 4 lists the significant sources of calculations in such conventional systems. Given the definitions in Table 4, the average time required to fully process an event in SEE DES is: X = d + c + (ni), where d is the average d , C is the average c, n is the average n, and i is the average i. In steady state, the average number of new events inserted into the event list during each event is one, because the event list has a stable size. Thus, X is a simple sum of d, c, and i. Since the list can be ordered, d is basically the very short fixed time required to delete the head event of the list and invoke the appropriate handler for this head event. Further, c depends primarily on the complexity of the event being simulated and can be assumed to be a given value for a particular type of simulation problem. Furthermore, i is a strategy function used to manage the event list, as it requires an ordered arrangement in the event list structure. The optimization of d and i is a simple problem, and for these variables most conventional DESs are efficient. Therefore, in order to improve the simulation execution time, attention must be paid to shortening c. In reducing c, the programmer must perform the computation of the event as efficiently as possible. After making the calculation of events as efficient as possible, there is little that can be done to accelerate the simulation under the SEE paradigm, except using a faster processor. Thus, within a given problem area and on a given processor, SEE DES has an inherent limit on its event throughput. To achieve further improvements, the event throughput must be increased. In general, all alternatives to SEE rely on simultaneous processing, that is, processing multiple events in parallel by distributing the events to multiple processors. Several approaches have been proposed to do this, and have been implemented as experimental or commercial products. Although each approach has advantages and is therefore applicable to certain types of simulation problems, none of these approaches can significantly increase event throughput in the general case, and each approach is: It has drawbacks and difficulties in implementation and implementation. Summary of the Invention It is an object of the present invention to increase the DES event throughput using a single event list. It is another object of the present invention to provide an architecture for performing parallel simulations that can be used with a particular computer hardware implementation. It is another object of the present invention to provide a technique for accelerating DES execution by using multiple processors in parallel. It is another object of the present invention to provide a DES in which a simulation programmer or user is unaware of the basic event processing architecture of DES. For example, a simulation programmer or user does not need to consider how to physically partition the DES system to allocate a small portion to available processors. Instead, the present invention automatically scales to utilize additional processors and becomes a conventional DES when only one processor is available. The invention can be implemented in several ways, including but not limited to a method, an apparatus comprising a computer system, and a computer-readable medium for implementing a computer program. The invention, implemented in a method, maintains an event list for a discrete event simulation having a head event, and determines whether the head event has not been calculated, is being calculated, or has been calculated. And increasing the event throughput of the discrete event simulation. The head event is executed when it is determined that the head event has not been calculated. If it is determined that the head event is being calculated, the head event is indicated as calculated when the calculation of the head event is completed. If it is determined that the head event has been calculated, it is determined whether the calculation of the head event is valid or invalid. When it is determined that the calculation of the head event is valid, the calculation of the head event is applied, and when it is determined that the calculation of the head event is invalid, the head event is executed. For the method, the discrete event simulation has a current system state, and applying the head event calculation includes changing the current system state based on the head event calculation. In addition, input invariance can be used to determine whether the head event calculation is valid or invalid. Further, the event list may be an ordered set of events. Also, the event list includes a plurality of events and at least one event indicated as an uncalculated event, the method further includes selecting an uncalculated event from the event list, and calculating the uncalculated event. Including doing. The invention, implemented in another manner, comprises maintaining an event list for a discrete event simulation having a plurality of events and at least one event indicated as an uncomputed event; From the event list, assigning the selected event to the event pre-computation process, indicating the selected event in the event list as an in-computation event, using the event pre-computation process to select the selected event , Calculating from the event pre-computation process, and indicating the selected event in the event list as a calculated event, including increasing the event throughput of the discrete event simulation. In this method, calculating a selected event using the event pre-computation process includes providing an event input to the event pre-computation process, and determining a change in system state based on the selected event and the event input. Including doing. Receiving a computation from the event precomputation process includes receiving an event input and a change in system state from the event precomputation process, and indicating a selected event in the event list as a computed event comprises: Associating a change in system state with a selected event. Further, the method further comprises verifying the head event by indicating the selected event as a calculated head event in the event list, and comparing the current system state with an event input associated with the head event. This involves determining whether the event is valid or invalid. If the head event is valid, the calculation of the head event is applied by updating the current system state using the system state change associated with the head event. The invention, implemented in another manner, maintains an event list for a discrete event simulation having a plurality of events indicated as calculated events, and selects a plurality of events indicated as calculated events from the event list. And increasing the event throughput of the discrete event simulation, including determining whether the selected event is valid or invalid. If the selected event is invalid, this selected event will be assigned to the event pre-computation process, this selected event in the event list will be shown as a calculating event, and the event calculation process will be used to select A calculation of the calculated event is made, the calculation is received from the event pre-calculation process, and the selected event in the event list is shown as a calculated event. The invention, embodied in a device, comprises: means for maintaining an event list including a plurality of events, one event being indicated as a head event, each event being indicated as an uncalculated event, a calculating event, or a calculated event; Means for executing at least one event pre-calculation process for calculating uncalculated events; means for selecting an uncalculated event and transferring the uncalculated event to one event pre-calculation process; Means for verifying the calculated event, the computer system performing a discrete event simulation. In the apparatus, at least one processor implements means for maintaining an event list, means for selecting an uncalculated event and forwarding the uncalculated event, and means for executing the uncalculated event and verifying the calculated event. can do. Further, a plurality of processors may implement means for calculating an uncalculated event. In the present invention, a computer system includes one or more computers connected via a network. Further, each computer in a computer system can have one or more processors. The invention embodied in an article of manufacture comprises a computer readable medium that implements a code segment that performs a discrete event simulation. The code segment includes a code segment that maintains an event list that includes a plurality of events, including a head event, where each event is indicated as an uncalculated event, a calculating event, or a calculated event, and at least one for calculating the uncalculated event. Scan the code list for each of the one event precomputation process and the event list, select the uncomputed events, assign this uncomputed event to one event precomputation process, and calculate according to the code segment for the event precomputation process And a code segment for an event list manager that executes uncalculated events and verifies the calculated events. In the present invention, a computer-readable medium for implementing a computer program comprises code segments that control one or more processors to perform the present invention. Non-limiting examples of "computer-readable media" include magnetic hard disks, floppy disks, optical disks, magnetic tapes, memory chips, send and receive e-mail, or access electronic data networks such as the Internet. And the carrier used to hold the electronic data as used in the transmission. Further, non-limiting examples of "code segments" include software, instructions, computer programs, and means for controlling one or more processors. BRIEF DESCRIPTION OF THE FIGURES Embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a diagram showing DES irregular event intervals along the time axis. FIG. 2 is a diagram illustrating event processing using selective precomputation of the event architecture of the present invention. DETAILED DESCRIPTION OF THE INVENTION The present invention uses selective precomputation of events (SPE) as an acceleration mechanism that works within a single event list paradigm. With the present invention, management of events is centralized using one processor, and execution of events is distributed to other available processors. The SPE uses a conventional event list and relies on a single process or thread called an "event list manager" (ELM) to execute the events in the list. (The term "process" refers to one or more programs running on one or more processors.) SPEs "pre-compute" events when it is possible to increase event throughput. It also relies on additional processes that can be run on other processors. Such a process is called an “event pre-computation process” (EPP). In one embodiment of the present invention, each EPP runs on a separate processor. The purpose of the SPE is to allocate as many future events as possible to free processors and execute them in parallel, and that when the actual simulation time of an event is reached, the "work" or computation performed by these processors is still The task is to remember this task so that it is valid and usable. As in the standard event processing architecture, normal events enter the event list of the present invention and wait for execution. The event list is scanned by an "event list scanning process" (ESP) that selects certain events to be pre-calculated. The ESP can be implemented, for example, as a subtask of the ELM. Events can fall into one of three categories at any time: uncomputed events (UCE), computed events (ICE), and computed events (PCE). PCEs whose associated work remains valid until the actual execution time are called available calculated events (UPCE). Table 4 defines these four types of events. FIG. 2 illustrates event processing using the SPE architecture of the present invention. The ESP scans the event list to see if there is a UCE. If a UCE is found, the ESP sends the UCE to the EPP for processing, and the indication of the UCE in the event list changes from UCE to ICE. When the EPP ends, the resulting PCE is output and the ICE in the event list is changed to PCE. All events, regardless of their state, continue to be represented in the event list until executed. An event can only be executed when it reaches the head of the event list and is called a head event. At this point, the processing of the event depends on the state of the event. In FIG. 2, the head event is shown at the bottom of the event list, and is shown as an event that is a PCE. As shown in FIG. 2, there are three possible states for a head event. First, the head event, if it is a UCE, is handled by the process responsible for managing the event list, as in the SEE architecture. Second, if the head event is an ICE, no further event execution by the ELM can proceed until the head event becomes a PCE. As the ELM progresses, the causal relationship between events may be compromised. The ELM can block other processing until the pre-computation is complete, or use the time to scan the event list to select other events to pre-compute. Third, if the head event is a PCE (shown in FIG. 2), the ELM must verify that the pre-computation is still valid (ie, the head event is also a UPCE). . If the head event is UPCE, event execution consists only of "applying" the stored result. In other words, the system state is modified using the recorded event output. Input for Event Calculation Whether an event is pre-calculated by the EPP in the SPE architecture or calculated directly by the ELM, when the calculation of the event takes place, the event depends on the same set of "event inputs" I do. The term "event input" refers to the set of all elements of state information stored in the portion of the DES that can be analyzed during event calculation. The present invention increases DES throughput by having ELM-confirmed events calculated by EPP, rather than having the ELM calculate the events. With the present invention, the event throughput of a DES is not a function of how fast a single processor can fully calculate an event, but a function of how fast a single processor can see an event. . A condition of the present invention that achieves higher performance is that the confirmation of the event is easier than the complete calculation of the event. Therefore, the PCE confirmation mechanism is an important part of the SPE architecture. Determining whether the precomputation produces the same result when compared to the direct execution of the event by the ELM requires knowledge of which inputs were used during the precomputation of the event. Changes in such inputs can result in different calculations of events, and from a conservative perspective, such changes should be considered as invalidating pre-computation. Eliminating the need to make intervening modifications of the input is a simple way for SPE-based systems to identify calculated events. This technique is called "input invariance". When an event starts executing, it is generally not possible to determine in advance which input will be accessed. This is especially true in systems that support general instructions during events, including conditional control flows. Therefore, implementing input invariance requires some way of detecting and maintaining which inputs were used during precomputation. Depending on the nature of the change in the input of the event and the way the input is used, the event can evolve exactly regardless of the change. Therefore, input invariance is a conservative approach to performing validation in SPE DES. More sophisticated confirmation schemes allow for more detailed information about the use of event inputs, and thus can reduce the conditions required for confirmation. Output of event calculations Many different actions can be taken during the execution of an event. Certain actions are actions that are completely internal to the event and can be considered as having no effect on other events. The internal action may be, for example, an action that modifies a temporary variable used in local computation. Since internal actions do not affect other events, such internal actions can be performed as part of a pre-computation without having to "remember" that it has taken place. Events can include actions that have external effects. Such external actions or event outputs must be performed so as not to interfere with other ongoing or future event calculations. The SPE approach to this problem is one of several factors that distinguish the present invention from other conventional simulation architectures. Each event output can cause one or more changes in the state of DES. Making such a change, if event E was calculated as a PCE, would modify the view of the system state recognized by other ongoing event calculations. In addition, effecting the change modifies the system state as perceived by the PCE calculations performed between the first and last execution of event E. In the SPE architecture of the present invention, event outputs are essentially "buffered" until such time as they can be safely applied to the actual system state. This indicates that even if a change has occurred, it is not allowed to affect the system state until the time of the last event execution. As described above, if the PCE is determined to be invalid according to criteria such as input invariance, all changes are discarded. Therefore, the change takes place in a special context to meet two requirements. First, sufficient information about the output must be recorded so that the output can be similarly reproduced at runtime. If the verification is successful, the action is actually performed during the "apply result" phase, as shown in FIG. Second, the actual application of the output must be temporarily emulated to provide a consistent view of the simulation state during event precomputation. For example, if an object modifies one attribute of the object and then queries the value of this attribute during the same event (and optionally a subsequent PCE), the query will yield the newly assigned value . Thus, the event handling method associated with each object does not need to know whether it is performed for precomputation or for direct computation. Given the second requirement, two different views of the system state (or a subset of the system state) coexist temporarily. One view is valid in the context of the PCE in question and the other is valid in the context of the last event execution by the ELM. However, in this case, the event that occurs between the two times has the question of which of these views is valid. Either of the two views can provide the correct solution, as the confirmation mechanism used in the last event execution will use the appropriate system state when calculating the event. Each approach has different performance, and which approach to choose for DES should be considered for a particular DES or DES environment. Event Dispatch and Search One important key factor in the efficient implementation of the SPE architecture of the present invention is the mechanism used to transfer control of the event to the EPP. When performing this task on the same processor that supports the ELM involved in the last execution of the event, the overhead of the EPP will only allow one event to be checked at a time and pass the apply phase of execution, so the total event Throughput is reduced. Therefore, event dispatching should be performed using an independent processor that accesses the event list information, or the event dispatching should be performed with efficiency in mind. The purpose of event dispatching for event E, which is a UCE, is to provide the EPP with all the state information needed to make event E a PCE. After precomputing event E, the output of this event must be returned to the ELM in some way by the last run. This mechanism is called “event output search”. After dispatching event E to the EPP, all inputs of event E must be able to access the EPP. As pointed out above, it is difficult to know what inputs E needs before it actually calculates E. Therefore, the EPP must be provided with all possible input information, or the EPP must be able to access this information as needed. Many different implementations are possible, and the efficiency of these mechanisms depends strongly on the underlying architecture of the supporting hardware. For example, if all processors can share a single memory space instead of transferring information about UCE, then only UCE references need to be transferred to EPP when dispatching UCE to EPP. . Some implementations of the SPE architecture require a message-based dispatch search mechanism because a highly scalable hardware architecture cannot implement this functionality. Variations of the SPE Architecture As will be appreciated by those skilled in the art, many options are possible for implementing the SPE architecture of the present invention. Significant efficiency benefits can be realized utilizing certain aspects of specific DES and specific hardware. In addition to the points already discussed in the previous section, the following three implementation-specific points should be analyzed for possible efficiency gains, which can be implemented using current technology: . First, the choice of event should be considered. When the ESP selects an event to pre-compute from the event list, the ESP does not need to select events in the order in which it encounters the event. Instead, the ESP can intelligently select events based on heuristics that attempt to maximize the gain of the SPE architecture. An important point in this case is that the PCE is likely to remain valid and become an UPCE based on information such as the type of event and associated objects. Also, if the overhead for dispatching and retrieving events is equal, certain more computationally intensive events may be advantageous for pre-computation. Event selection heuristics can be complex and strongly dependent on specific knowledge about DES. Second, process allocation should be considered. A single process or an independent process can implement both ELM and ESP. The ELM and ESP may be implemented to run on a single processor or on separate processors. As shown in FIG. 2, additional processors can be used for the verification, apply, and full execution phases. Third, the dynamic distribution of state information should be considered. When using an event dispatching approach that does not rely on a centralized shared memory when storing the state of the system, various techniques can be used to increase the efficiency of accessing event inputs. For example, after an object or other part of the state of the DES is associated with a particular processor, keep this information in its own memory and dispatch events for this object to the same processor on a priority basis. May be the most efficient. Such an approach can reduce communication overhead for certain DESs. While the simulation is taking place, the state of the system can be dynamically distributed to the available processors. The applicability of such techniques is highly dependent on the nature of the DES and the architecture of the supporting hardware. As a variant of the SPE architecture, alternatives to the ESP can be used. For example, rather than having the ESP assign a UCE to an EPP, the EPP can access the event list and the EPP itself can select a UCE to pre-compute. As another example, the ELM may perform the functions of the ESP, and after the EPP polls the ELM for UCE, the ELM may supply the EPP with ULE. In general, in the present invention, the UCE is forwarded to the EPP, which can be done in various ways. As a variant of the SPE architecture, other labels, such as unprocessed, in process, and processed, can be used to indicate events in the event list. Further, the event list is not limited to the three types of events described herein, but may include other types of events as needed for the implementation of the DES. As another variation of the SPE architecture, the event list can have multiple head events. Multiple event lists can be shown as an uncalculated event list, a calculating event list, or a calculated event list. Multiple head events can be acknowledged or performed in parallel by one or more ELMs if they are "well independent of each other" events. To be sufficiently independent of each other, the output of each head event should not significantly affect the calculation of other head events. For example, multiple events are shown using the same simulation time (similar to Table 1, event E [1] and event E [2] have the same time 0.1) and arrive at the head of the event list. In these cases, these multiple events can be considered multiple head events and are events that are independent of each other so as to be confirmed or executed in parallel. In general, the use of multiple head events will result in an application-specific decision as to when the events will be sufficiently independent of each other to achieve a significant gain in performance. As a refinement of the SPE architecture, the ELM can scan the event list for PCEs and apply the same method to the PCEs in the event list as for the head event PCE. For each PCE in the event list, the ELM determines whether the pre-computation of the PCE is still valid. When selecting a PCE to verify in the event list, the ELM, or perhaps another process, can scan the event list periodically or aperiodically. After selecting a PCE, the ELM, or perhaps another process, verifies the PCE in the event list. The ELM does not modify the PCE if the PCE pre-computation is valid. If the pre-calculation of the PCE is invalid, the ELM indicates the PCE as an ICE, selects one EPP, and resumes the calculation of the newly indicated ICE. This method of restarting the calculation is the same as the method discussed above for performing the ICE calculation. As an alternative to verifying a PCE immediately after an ELM scan selects the PCE from the event list, the ELM can first determine whether the PCE was recently verified before verifying the PCE. . In this case, for example, each PCE may include a verification time indicator. The verification time indicator is initially set to the time at which the display of events in the event list changes from ICE to PCE. After selecting the PCE to be verified, the ELM checks whether this PCE was recently verified by comparing the threshold between the difference between the current time and the verification time indicator for this PCE. If the difference is less than the threshold, the PCE is not verified because it has been recently verified. If the difference is greater than or equal to the threshold, the PCE has not been recently verified and is verified using the verification method described above. After the PCE has been verified, the verification time indicator is changed to the current time. The verification time for each PCE is initially set to the time when the event was designated as a PCE. As an alternative to implementing the present invention for DES, the present invention can be implemented to increase the task throughput of computer programs implemented using multiple processors. In this alternative embodiment, an event is equivalent to a task or subtask. In other words, the execution speed of a computer program composed of tasks and subtasks can be increased by using a plurality of processors and the above method. Further, the present invention can be applied to a program including a series of operations having a certain degree of independence. As will be appreciated by those skilled in the art, the degree to which these operations are independent of one another is a factor in determining the achievable performance improvement. In many practical cases, DES can be broken down into events that are independent of each other so that the inventive approach can be used. Although the invention has been described in detail with reference to preferred embodiments, it will be apparent to those skilled in the art from the foregoing that changes and modifications can be made in the broader aspects of the invention without departing from the invention. Accordingly, the invention covers all such changes and modifications that fall within the true spirit of the invention, as defined by the appended claims.
─────────────────────────────────────────────────────
フロントページの続き
(81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，
ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ
Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＣＡ，ＪＰ────────────────────────────────────────────────── ───
Continuation of front page
(81) Designated country EP (AT, BE, CH, CY,
DE, DK, ES, FI, FR, GB, GR, IE, I
T, LU, MC, NL, PT, SE), CA, JP