コンピュータ システムのシミュレータ: おなじみのフルプラットフォーム シミュレータと未知の時計回りのシミュレータとトレース

コンピュータ システム シミュレータに関する記事の後半では、コンピュータ シミュレータ、つまり平均的なユーザーが最も頻繁に遭遇するフルプラットフォーム シミュレーションとクロックバイについて、簡単な入門形式で引き続き説明します。 - クロック モデルとトレース。開発者サークルではより一般的です。

В 最初の部分 シミュレータとは一般的に何なのか、またシミュレーションのレベルについて説明しました。 さて、その知識に基づいて、私はもう少し深く掘り下げて、フルプラットフォームのシミュレーション、トレースの収集方法、後でそれらをどう扱うか、そしてクロックバイクロックのマイクロアーキテクチャエミュレーションについて話すことを提案します。

フルプラットフォームシミュレータ、または「フィールドにいるだけでは戦士ではない」

XNUMX つの特定のデバイス (ネットワーク カードなど) の動作を調査したい場合、またはこのデバイスのファームウェアまたはドライバーを作成したい場合は、そのようなデバイスを個別にシミュレートできます。 ただし、他のインフラストラクチャから分離して使用するのはあまり便利ではありません。 対応するドライバーを実行するには、中央プロセッサ、メモリ、データ バスへのアクセスなどが必要です。 さらに、ドライバーが機能するにはオペレーティング システム (OS) とネットワーク スタックが必要です。 さらに、別個のパケット ジェネレーターと応答サーバーが必要になる場合があります。

フルプラットフォーム シミュレーターは、完全なソフトウェア スタックを実行するための環境を作成します。これには、BIOS やブートローダーから、OS 自体と、同じネットワーク スタック、ドライバー、ユーザー レベルのアプリケーションなどのさまざまなサブシステムに至るまで、すべてが含まれます。 これを行うために、プロセッサとメモリ、ディスク、入出力デバイス (キーボード、マウス、ディスプレイ)、および同じネットワーク カードなど、ほとんどのコンピュータ デバイスのソフトウェア モデルを実装します。

以下は、Intel の x58 チップセットのブロック図です。 このチップセット上のフルプラットフォームのコンピューター シミュレーターには、ブロック図には詳しく示されていない IOH (入出力ハブ) および ICH (入出力コントローラー ハブ) 内のデバイスを含む、リストされているほとんどのデバイスの実装が必要です。 。 ただし、実際に見てみると、これから実行するソフトウェアで使用されないデバイスはそれほど多くありません。 このようなデバイスのモデルを作成する必要はありません。

ほとんどの場合、フルプラットフォーム シミュレータはプロセッサ命令レベル (ISA、以下を参照) で実装されます。 前の記事）。 これにより、シミュレータ自体を比較的迅速かつ安価に作成できます。 ISA レベルは、頻繁に変更される API/ABI レベルとは異なり、ほぼ一定のままであるため、優れています。 さらに、命令レベルでの実装により、いわゆる未変更のバイナリ ソフトウェアを実行できます。つまり、実際のハードウェアで使用されているのとまったく同じように、すでにコンパイルされたコードを変更せずに実行できます。 つまり、ハード ドライブのコピー (「ダンプ」) を作成し、それをフル プラットフォーム シミュレーターのモデルのイメージとして指定すれば、出来上がりです。 – OS およびその他のプログラムは、追加の操作を行わずにシミュレータにロードされます。

シミュレータのパフォーマンス

先ほど述べたように、システム全体、つまりすべてのデバイスをシミュレートするプロセスはかなり時間がかかります。 これらすべてを非常に詳細なレベル (マイクロアーキテクチャまたは論理レベルなど) で実装すると、実行が非常に遅くなります。 ただし、命令レベルは適切な選択であり、ユーザーが快適に操作するのに十分な速度で OS とプログラムを実行できます。

ここで、シミュレータのパフォーマンスについて触れておくのが適切でしょう。 通常、IPS (命令/秒)、より正確には MIPS (百万 IPS)、つまり XNUMX 秒間にシミュレータによって実行されるプロセッサ命令の数で測定されます。 同時に、シミュレーションの速度は、シミュレーション自体が実行されるシステムのパフォーマンスにも依存します。 したがって、元のシステムと比較したシミュレーターの「速度の低下」について話す方が正確かもしれません。

QEMU、VirtualBox、VmWare Workstation など、市場で最も一般的なフルプラットフォーム シミュレータは、優れたパフォーマンスを備えています。 シミュレータで作業が進行していることにユーザーは気付かない場合もあります。 これは、プロセッサに実装された特別な仮想化機能、バイナリ変換アルゴリズム、その他の興味深い機能のおかげで実現します。 これはすべて別の記事のトピックですが、簡単に言うと、仮想化は最新のプロセッサのハードウェア機能であり、シミュレータが命令をシミュレートするのではなく、命令を実際のプロセッサに直接送信して実行できるようにします。シミュレータとプロセッサは似ています。 バイナリ変換とは、ゲスト マシン コードをホスト コードに変換し、その後実際のプロセッサ上で実行することです。 その結果、シミュレーションは 5 ～ 10 倍とわずかに遅くなるだけで、多くの場合、実際のシステムと同じ速度で実行されることもあります。 これには多くの要因が影響しますが。 たとえば、数十個のプロセッサを備えたシステムをシミュレートしたい場合、速度はすぐに数十倍低下します。 一方、最新バージョンの Simics などのシミュレータは、マルチプロセッサ ホスト ハードウェアをサポートし、シミュレートされたコアを実際のプロセッサのコアに効果的に並列化します。

マイクロアーキテクチャ シミュレーションの速度について言えば、通常、シミュレーションを行わない通常のコンピューターでの実行よりも数桁遅く、約 1000 ～ 10000 倍遅くなります。 また、論理要素レベルでの実装は数桁遅くなります。 したがって、このレベルでは FPGA がエミュレータとして使用され、パフォーマンスが大幅に向上します。

以下のグラフは、モデルの詳細に対するシミュレーション速度のおおよその依存性を示しています。

ビートごとのシミュレーション

実行速度は低いにもかかわらず、マイクロアーキテクチャ シミュレータは非常に一般的です。 各命令の実行時間を正確にシミュレートするには、プロセッサの内部ブロックのシミュレーションが必要です。 ここで誤解が生じる可能性がありますが、結局のところ、単に各命令の実行時間をプログラムすればよいのではないかと思われるかもしれません。 しかし、同じ命令の実行時間は呼び出しごとに異なる可能性があるため、このようなシミュレーターは非常に不正確になります。

最も単純な例はメモリ アクセス命令です。 要求されたメモリの場所がキャッシュ内にある場合、実行時間は最小限になります。 この情報がキャッシュにない場合 (「キャッシュミス」)、命令の実行時間が大幅に増加します。 したがって、正確なシミュレーションにはキャッシュ モデルが必要です。 ただし、問題はキャッシュモデルに限定されません。 プロセッサは、データがキャッシュにない場合、メモリからデータが取得されるのをただ待つわけではありません。 代わりに、メモリからの読み取り結果に依存しない命令を選択して、次の命令の実行を開始します。 これは、プロセッサのアイドル時間を最小限に抑えるために必要な、いわゆる「アウトオブオーダー」実行 (OOO、アウトオブオーダー実行) です。 対応するプロセッサ ブロックをモデル化すると、命令の実行時間を計算するときにこれらすべてを考慮するのに役立ちます。 これらの命令のうち、メモリからの読み出し結果を待って実行される命令の中には、条件ジャンプ動作が発生する場合があります。 現時点で条件の結果が不明な場合、プロセッサは実行を停止せず、「推測」を行い、適切な分岐を実行し、遷移点から積極的に命令を実行し続けます。 このようなブロックは分岐予測子と呼ばれ、マイクロアーキテクチャ シミュレーターにも実装する必要があります。

下の図はプロセッサの主要ブロックを示しています。これを知る必要はありません。マイクロアーキテクチャ実装の複雑さを示すためにのみ示されています。

実際のプロセッサ内のこれらすべてのブロックの動作は特別なクロック信号によって同期されており、モデルでも同じことが起こります。 このようなマイクロアーキテクチャ シミュレータはサイクル アキュレートと呼ばれます。 その主な目的は、開発中のプロセッサのパフォーマンスを正確に予測したり、ベンチマークなどの特定のプログラムの実行時間を計算したりすることです。 値が必要な値よりも低い場合は、アルゴリズムとプロセッサ ブロックを変更するか、プログラムを最適化する必要があります。

上で示したように、クロックごとのシミュレーションは非常に遅いため、プログラムの実行の実際の速度を調べ、デバイスの将来のパフォーマンスを評価する必要がある、プログラム動作の特定の瞬間を研究する場合にのみ使用されます。プロトタイプをシミュレーション中です。

この場合、関数シミュレーターを使用して、プログラムの残りの実行時間をシミュレートします。 この組み合わせは実際にはどのように起こるのでしょうか? まず、関数シミュレーターが起動され、OS と研究対象のプログラムを実行するために必要なものがすべてロードされます。 結局のところ、私たちは OS 自体には興味がなく、プログラムの起動やその構成などの初期段階にも興味がありません。 ただし、これらの部分をスキップして、すぐに途中からプログラムの実行に移ることもできません。 したがって、これらの準備ステップはすべて機能シミュレーターで実行されます。 関心のある時点までプログラムが実行された後、XNUMX つのオプションが可能になります。 モデルをクロックバイサイクル モデルに置き換えて、実行を続行できます。 実行可能コード (つまり、通常のコンパイルされたプログラム ファイル) を使用するシミュレーション モードは、実行駆動シミュレーションと呼ばれます。 これは最も一般的なシミュレーション オプションです。 別のアプローチ、トレース駆動シミュレーションも可能です。

トレースベースのシミュレーション

これは XNUMX つのステップで構成されます。 機能シミュレータまたは実際のシステムを使用して、プログラム動作のログが収集され、ファイルに書き込まれます。 このログをトレースと呼びます。 検査対象に応じて、トレースには実行可能命令、メモリ アドレス、ポート番号、および割り込み情報が含まれる場合があります。

次のステップは、クロックバイクロック シミュレータがトレースを読み取り、そこに書き込まれたすべての命令を実行するとき、トレースを「再生」することです。 最後に、プログラムのこの部分の実行時間と、このプロセスのさまざまな特性 (キャッシュ内のヒット率など) を取得します。

トレースを操作する際の重要な特徴は決定論です。つまり、上記の方法でシミュレーションを実行することで、同じ一連のアクションを何度も繰り返し再現します。 これにより、モデル パラメーター (キャッシュ、バッファー、キュー サイズ) を変更し、さまざまな内部アルゴリズムを使用したり、それらを調整したりすることで、特定のパラメーターがシステム パフォーマンスにどのような影響を与えるか、どのオプションが最良の結果をもたらすかを調査することが可能になります。 これらすべては、実際のハードウェア プロトタイプを作成する前に、プロトタイプ デバイス モデルを使用して行うことができます。

このアプローチの複雑さは、最初にアプリケーションを実行してトレースを収集する必要があることと、トレース ファイルのサイズが巨大であることにあります。 利点としては、実行によるシミュレーションには通常、完全なモデルが必要であるのに対し、対象のデバイスまたはプラットフォームの一部のみをシミュレートすれば十分であるという事実が含まれます。

そこで、この記事では、フルプラットフォーム シミュレーションの機能を検討し、さまざまなレベルでの実装の速度、クロックごとのシミュレーション、およびトレースについて説明しました。 次の記事では、個人的な目的と大企業での開発の観点の両方で、シミュレーターを使用する主なシナリオについて説明します。

出所： habr.com