厳密なフルシステム・タイミングシミュレーションの復活への歩み

現状と課題

正確なタイミングシミュレーションはコンピュータアーキテクチャにおいて重要なツールですが、現代のシステムでは以下の要因により実現が困難になっています。

• 複雑性の増大: 多数コア CPU、深層メモリエラヤー、アクセラレーター、複雑な I/O、膨大なソフトウェアスタックが組み合わさることで、詳細なシミュレーションは極端に低速化しています。
• 「タイミングシミュレーションの壁」: 秒単位の動作をシミュレートするのに数ヶ月かかります。
• 既存手法の限界: アプリケーション単体や固定命令ウィンドウといった近似手法（gem5 など）では、厳密なエンドツーエンドの計測が犠牲化されています。

フルシステム・シミュレーションへの回帰提言

本研究は、厳密かつ包括的なフルシステム・タイミングシミュレーションへの復帰を主張します。それは「全ての時刻を詳細にシミュレートする」ことではなく、以下のアプローチによる実現可能性の回復を目指します。

• 適切な実行区間の選択
• 正しい性能指標の使用
• 統計的に妥当な手法の適用

なぜフルシステム・シミュレーションが必要か

CPU、メモリ、OS、アプリケーションを含むシステム全体のエミュレーションが重要です。ユーザーレベルのみをシミュレートすると、以下の要因による挙動を見落とす可能性があります。

• OS アクティビティや割り込み
• I/O やメモリエラータメント
• システム間の同期とデバイス相互作用

これらを無視すると、実際のボトルネックやパフォーマンスを誤評価します。特に現代のワークロードでは以下のような複雑な依存関係が存在するため、フルシステム・シミュレーションが不可欠です。

1. サービス志向・マルチテナント環境: マイクロサービス、RPC、ストレージスタック、OS を介した相互作用が主である。
2. OS への依存度の高さ: サーバーやモバイルワークロードの多くはカーネル挙動に時間を使い、これが性能解析の中核となる。
3. 不斉システム: CPU と GPU、アクセラレーター、スマート NIC が連携し、CPU/OS が調整や同期を主導する。
4. エージェント型 AI ワークロード: ツール呼出し、スケジューリング、API 利用など、CPU と OS の挙動がエンドツーエンド性能に決定的に影響する。

技術的な障壁：タイミングシミュレーションの壁

シミュレータは抽象化とパフォーマンスのスペクトルを持っていますが、詳細さが増すほど速度は低下します（下表参照）。

行	方式	特徴・速度特性
1	JIT 翻訳を用いたフルシステム・シミュレータ	ネイティブ速度の一桁以内（例：SimOS）
2	ISA エミュレーター（QEMU）	キャッシュミス率や分岐予測器を解析可能だが、さらに一桁遅い
3	マイクロアーキテクチャ機能シミュレーション	キャッシュ/TLB/プリフェッチャーなどをモデル化。さらに速度低下
4	全命令（OS 含む）機能シミュレーション	より詳細なトレース生成により大幅な速度低下
5	タイミングシミュレーション	サイクル単位での相互作用をモデル化。著しい速度低下

• 現代ワークロードの変動性: ネットワークアクティビティ、リソース競合、OS 割り込み、DVFS チョッリングなどにより、パフォーマンスは時間とともに変動します。
• 統計的厳密性の必要性: Alameldeen らの手法により、信頼水準内の性能変動を捉えるには5〜120 秒の実行が必要とされています。
• 現実的な課題: 最新でも最も高速な gem5（250 KIPS）を用いても、単一コアの数秒分のシミュレートに数ヶ月かかるのが現状です。

測定すべき性能指標

IPC の限界と U-IPC の採用

タイミングシミュレータでは通常「サイクル数」を計測し、設計者は**IPC（命令/サイクル）**を報告します。

• 単一コアワークロード: プログレスに寄与する命令が多いので、IPC は妥当な指標です。
• マルチコアワークロード: 以下のような状況で IPC は誤解を招きます。
  • スピニング（空回り）、ポーリング、ロック待ち
  • 有用な作業を進めない OS コードの実行
  • 結果: 高い総 IPC でも実質的な前進がない場合があり、「バスイティング（待つこと）が賞賛」されてしまう。

対策として「ユーザーレベル IPC（U-IPC）」を推奨します。

• U-IPC は、各リクエストあたりのユーザ指令数をカウントします。
• 仮定：スピニングの大部分は OS 内で発生するため、時間経過に伴うユーザレベル指令数が実際のスループットを反映する。
• 注意点: ユーザースペースでスピニングが発生する場合は（例：ユーザ級ネットスタック）、補正が必要です。
• 検証の重要性: 厳密なシミュレーション手法は、選択した指標が実際にワークロードの前進を反映しているかを示す必要があります。

測定方法とサンプリング戦略

固定命令数（1 億〜10 億命令）での単一単位計測では、実行内のどのタイミングで行うかによって結論が偏るリスクがあります。フェーズベースのサンプリング（SimPoint など）も、OS の効果や割り込みを無視する可能性があります。

統計的サンプリング手法（SMARTS）

厳密なサンプリングとして推奨されるのは、統計的サンプリング手法です。

• 方法: 実行を代表する多数（例：数百）の小型計測単位（例：20 万サイクル）を、等間隔に採取します。
• 効果: 推定誤差の上限を設定し、信頼可能な定量結果を提供します。

比較実験の結果

フルタイミングシミュレーションにおける性能推定の誤差尺度は以下の通りです。

1. 固定単一単位（開始点・1/3・2/3）: 実行を代表せず、高い誤差をもたらす。
2. BBV クラスタリング（100 マイクロ秒）: 頻繁な命令のみを表し、高い誤差をもたらす。
3. 統計的サンプリング（100 マイクロ秒×数百個）: 誤差上限を 5%、信頼水準を 95% に確保。マイクロアーキテクチャ的な足跡を含み、精度が高い。

SOTA サンプルリングフレームワーク（QFlex 3.0）

最新の QFlex 3.0 は、ARM ISA のフルシステムタイミングシミュレーションにおける最先端のサンプリングフレームワークです。

手順概要

1. ウォーミングアップ: ソフトウェアスタックと OS を実プラットフォームで読み込みます。
2. 最小ウィンドウ同定: Alameldeen らの手法を用い、5〜120 秒の「population」を特定します。
3. 機能シミュレータ実行（QEMU）: population の全期間にわたって平均約6 MIPSで動作させます。
   • キャッシュ/TLB、分岐テーブルなどをシミュレートし、定期的にチェックポイントにダンプします。
   • 時間近似として IPC=1 または近傍を使用します。
4. タイミングシミュレーション: チェックポイントを 100 マイクロ秒ごとに独立して並列に実行します。
   • 短期状態（パイプラインバッファなど）をウォームし、計測を行います。
5. 集約と適応: サンプル結果を集約し、所望の信頼水準（例：誤差 5%・95%）を満たすか判断します。
   • 満たない場合は、チェックポイント間隔を短くした新しいライブラリを作成します。

課題と未解決問題

正確な計測手法を用いても、以下の本質的な課題が残されています。

• 正確な状態生成: 時間近似によるバイアスが、マルチティアワークロードで顕著です。
• 機能シミュレーションの壁: ボトルネックを機能シミュレータに移動（250 KIPS→6 MIPS）。並列化は可能ですが、通信粒度が制限されます。
• チェックポイントへのサポート: 全チェックポイントの保存・復元は非現実的。増分的な保存が必要です。
• 非平均指標のサンプリング: 最大温度や最悪ケースのパワーなど、希有事象の指標は捉えにくい。
• サービスレベル指標の捉えどころ: リクエストレイテンシ（p99.9 など）を捉えるには桁違いに大きな population と時間が必要で、両方のシミュレーション方式で困難です。
• マルチノードフルシステムシミュレーション: データセンター規模の振る舞いを表現するには不十分であり、依然として未解決です。
• 相互運用性: ツール間でのチェックポイントライブラリの共有には、状態を記述するインターフェース定義言語が必要です。

著者について

• Shanqing Lin: EPFL 博士課程見込み。QFlex v3.0 の主要開発者。
• Mohammad Alian: Cornell University 准教授（電気電子工学）。
• Babak Falsafi: EPFL 教授。スイスデータセンター効率性協会 (sdea.ch) 初代会長。

---

免責事項: この記事は、個人がコミュニティのため「コンピュータアーキテクチャ今日」ブログを通じて自らの考えを共有するために書かれました。ACM SIGARCH や ACM の公式見解を表すものではありません。