性能評価シミュレータの高速化

本節では，性能評価シミュレータの高速化手法と課題を整理する．

5.2.1. 性能評価シミュレータに搭載されたバイナリ変換方式

性能評価目的のシミュレータに使用されているバイナリ変換方式には，静的バイナリ変 換と動的バイナリ変換がある．静的バイナリ変換の有利な点は，ホストのアーキテクチャ に最適化したバイナリを生成できる，分岐のオーバヘッドを小さくできる，データキャッ シュメモリを圧迫しないことである．不利な点は，使用頻度の低いコードも変換するため 変換処理に時間が掛かる，変換後のコードを格納する領域として広いメモリ領域が必要と なることである．更に，命令コードとデータの分離が困難である，命令コードの自己修飾 への対応ができない，ダイナミックリンクライブラリに対応できないという実用上の課題 もあるため，使用上の制約が大きい．それに対して，動的バイナリ変換ではこれらが課題 とならずかつ実装が容易なため，主流となってきた．

WSSが行っているバイナリを解析しC言語に展開したシミュレーションコードをファイ ル出力してコンパイラを通す変換方法は，静的変換の派生形でありその短所と課題を受け 継いでいる．つまり，ダイナミックリンクライブラリに対応できない，静的に解析できる バイナリモジュールに限定される，などの課題がある．また，コアループがないため，マ ルチプロセッサシミュレーションに必要なシミュレーション対象の切り替えが困難になる．

加えて，静的変換より更にコンパイル時間が長く掛かる．そのため，パイプラインの詳細 シミュレータのフロントエンドとして使う場合はよいが，キャッシュシミュレーションで もシミュレーションに比べて10倍ほどのコンパイル時間が掛かり効率的でない．

5.2.2. インタプリタ方式の高速化方式

インタプリタ方式は，命令語の読出し，デコード，実行処理への分岐がバイナリ変換に 比べて多いため，低速である．バイナリ変換以外の手法により，その速度性能の課題を緩 和する方式として次の(a)～(d)のレベルがある^†23．

a) プログラムロード時の事前デコード：

命令コードのデコードをプログラムロード時に行う方法があり，SimpleScalar/PISA はこの方法を採っている．これにより，複数フィールドに別れたコードのデコードの処 理時間を短縮できる．しかし，命令とデータがセクション内に混在したバイナリモ ジュールではこの方法が使えない．

b) ハッシュテーブルによるデコード結果の再利用：

これは，プログラムカウンタ値を使ってハッシュテーブルを引き，デコード結果をテー ブルに格納する方法である．SimCore/Alpha でも使用している手法であるが，デコー ドがもともと速いとその効果は小さい．バイナリ変換方式の機能を限定した場合（114 ページの表22に記載したESPRIT/simの変換レベル1のサブセット）の動作と効果の 一部と考えることができる．

c) インタプリタ関数を呼び出すバイナリ命令列：

インタプリタの命令実行部を function 方式で実装し，それらの関数呼出しをコアルー プで行わずにバイナリに展開されたコードから呼び出す．これは(b)より高速であり，

デコード時間のほとんどの 時間を削減できる． 表 22（114ページ ）に記載した

ESPRIT/simの変換レベル1～3 がこれに該当するが，従来研究では言及されてない．

d) スレデッドコード：メモリリード，メモリライト，演算実行などの部品を関数として 定義しておき，あらかじめまたは動的にプログラムを解析してそれらを呼び出すバイナ リを生成する方式である．部品となる関数が互いに次の関数に直接分岐をすることによ りデコードや分岐のオーバヘッドを削減できる．SimICS はこの方式を採用しており，

ホストとレガシーISAへの依存性がバイナリ変換より軽減できる長所がある．SimICS ではシミュレーション対象ISAの命令仕様をデータ定義しSimGENというジェネレー タで変換しているが，そのデータ定義のデバッグが課題である．バイナリ変換と方式は 異なるが，ホストへの依存性も強いようである． 更に，標準のC／C++には変数値に より飛び先を変更するgoto文の仕様はないが，SimICSではそれが可能なgccのgoto 文の方言も利用している．この方式は，十分な性能とはいえないがインタプリタとバイ ナリ変換の中間の処理性能を実現できる実用的な方式の1つであるといえる．

†23 インタプリタ自体の高速化手法として，本研究の第3章で提案している手法やホストのスーパスカラの 並列性を引き出すために複数命令を同時にインタプリタ実行する方式[16][17]は，ここでは特に扱わない．

5.2.3. 並列処理によるシミュレータの高速化

科学技術シミュレーションでは，複数のコンピュータを並列使用したシミュレーション が一般的となっている．一方，シミュレーション対象をコンピュータにした場合は，シミュ レータの構成要素となるモデル間の結合度が強くかつモデル内で閉じた計算量が小さく並 列シミュレーションに不向きなせいか，コンピュータの並列シミュレーションに関する研 究は少ない．

N個のCPUからなるシミュレーション対象を N個のスレッドに分割してN/K個のホス トにCPUを割り付ける方式がある．この例としてはSimOSのParallel-Embraが挙げら れるが，ホストが4-CPU時に1.4～1.8倍程度にしか性能向上しないなどスケーラビリティ は悪い．キャッシュシミュレーションに PC クラスタを使用した例としては Shaman[48]

がある．これも，ホスト8個で6割，16個で3～4割の速度性能しか出せないなどスケー ラビリティは悪い．

このようなデータ並列を指向した方式に対して，ホストごとにシミュレーションを担当 する部分を時間方向に分割する方式がある．これは，まずトレースドリブンシミュレータ のフロントエンド部を用いて粗いシミュレーションを行い，その結果から区間を分割する．

次に，複数ホストでそれぞれの区間に対して詳細なシミュレーション（バックエンド）を 同時に行う[60]．この方式では，フロントエンドとバックエンドの処理性能が大きく異なら ないと効果が出ない．また，隣り合った区間との重複処理が必要となる．そのため，パイ プラインシミュレーションのように時間が掛かるシミュレーションでは，効果があるとい える．

このように，従来は 4 台までのマルチプロセッサやネットワーク接続のクラスタを中心 に，並列シミュレーションの研究が行われてきた．現在，マルチコアを搭載したPCが普及 してきており，2次キャッシュメモリなどの共有によるスレッドレベル並列シミュレーショ ンに関する研究が，今後は増えると思われる．

5.2.4. エミュレータと性能評価シミュレータの差異

特別なハードウェアを用いずにバイナリ変換のみで，命令セットの異なるアーキテク チャを厳密かつ高速にエミュレーションするのは困難であり，性能を優先すると機能や例 外動作に制約が出る^†24．しかし，使用目的を性能評価用のシミュレータに限定すると，下 記の理由によりバイナリ変換方式のアクセラレーションがより容易となる．

・ 通常の動作では例外発生がしない（ページフォールト例外などは必要）．

・ 浮動小数のアンダーフローなどによる精度の違いが，探求対象である性能の評価や解析 に及ぼす影響は小さい．

・ 既存のバイナリモジュールにある潜在的な障害まで互換動作を求められることは稀で

†24 専用ハードウェアなしにバイナリ変換でエミュレーションしたものは数少なくアップル社のExecutor (M68K→PowerPC)くらいであり，その安定性は課題であったといえる．同社の最近の事例である RosettaではPowerPCとx86のそれぞれに対応したバイナリの両方を持っておりエミュレーションは補 完的な役割に留めている．

ある．

・ 互換エミュレータ並みのバイナリ変換の信頼性は必須ではない．

・ エミュレータでは従来使用してきた機種より処理が遅いとその存在価値が薄れるが，性 能評価目的のシミュレータでは性能に対する厳密な指標がないためインタプリタより 数倍高速なだけでもその価値はある．

したがって，性能評価シミュレータのバイナリ変換への取組みは，エミュレータ用途のバ イナリ変換に比べて容易となる．

5.2.5. 性能評価シミュレータの高速化に関する課題

一方，性能評価を目的としたシミュレーションゆえに次の点が新たな課題となる．

・ 性能評価のためだけにバイナリ変換機能の開発に多大なコストを掛けられない．

・ ある程度の品質を確保しないとシミュレーションができないため，バイナリ変換の導入 の敷居は高くなる．

・ 複数の命令セットの CPU が混載可能なシミュレータの開発では，CPU を供給してい

るコンピュータメーカが異なるため必要な命令セットのバイナリ変換機構を取り揃え るのは困難となる．

・ 性能評価に必要な命令数などの情報やマルチプロセッサシミュレーション時のCPUの

切替え処理などが別途必要となる．