ベンチマーク手法
目次
PCBenchmarkXは、指定されたCPU/GPUシナリオの実行と、ソフトウェア信号に対する反応遅延を測定します。作業量は固定されており、評価式は公開されています。繰り返し実行することで、結果の安定性を確認できます。
このドキュメントは、エンジン 0.5.2、負荷 phase4.6-dev-1、統計 stats-phase4.6-v1、モデル score-model-1.2-candidate-1 に関するものです。モデル名にはCandidateが使われています。その正規化値は暫定的なものであり、すべてのコンピューターの平均指標と見なすことはできません。基準の詳細はスコア計算で説明しています。
BoosterXは、個別のネイティブエンジンの起動を制御し、テストの進行状況を表示し、結果を保存します。測定中は、自身のハードウェアとメモリの監視を一時停止し、自身のウィンドウを最小化してから、その状態を復元します。これによりBoosterXのインターフェース自体の影響を減らしますが、外部プログラムは依然として負荷を生じさせる可能性があります。
テストは、同じバージョンのエンジンとドライバー、同じ電源・オーバークロック・冷却の設定で繰り返してください。不要なバックグラウンドプログラムは閉じてください。ノートパソコンの場合は、すべてのテストを充電器を接続した状態で実行してください。変更の前後を比較する際は、どの設定を変更したのかを正確に記録してください。
Candidateのシーケンス
Section titled “Candidateのシーケンス”| 実行部分 | 指定された長さ | 目的 |
|---|---|---|
| ウォームアップ | 15秒 | 本測定前に負荷を準備する |
| CPU | 合計20秒 | 約6.67秒の3ブロック |
| GPU | 合計30秒 | Geometry、Shader、Computeに各10秒、それぞれ3ブロック |
| Combined | 合計30秒 | 10秒の3ブロック |
| キャリブレーション | 10秒 | Loaded Latencyの難易度を調整する |
| 遅延ウォームアップ | 2秒 | 遅延測定専用の経路を準備する |
| Baseline Latency | 5秒 | 基本負荷時の遅延を測定する |
| Loaded Latency | 20秒 | キャリブレーション済み負荷時の遅延を測定する |
遷移、リソースの準備、事前のCPUフレーム、終了処理には追加の時間がかかります。そのため、実行の総時間は測定対象の段階の合計よりも長くなります。検証済みのシリーズでは、1回の負荷内で隣接する実行の開始間隔は約157～172秒でした — 実行間のポーズを含みます。公開されているデータから1回の実行の正確な長さを特定することはできません。
パフォーマンステストのブロックは3ラウンドで交互に実行されます。CPUでは、各本測定ブロックの前に固定された初期状態と512の準備フレームがあります。ブロックごとに処理速度が徐々に変化する場合、それは診断に反映されます。ただし、得られた結果は補正されません。
実行プロファイルと長さ
Section titled “実行プロファイルと長さ”エンジンは4つのプロファイルをサポートしています: candidate、quick、extended、custom。各段階の正確な長さ:
| プロファイル | タスク | 遷移 | ウォームアップ | CPU | GPU | Combined | キャリブレーション | 遅延ウォームアップ | Baseline | Loaded |
|---|---|---|---|---|---|---|---|---|---|---|
| Candidate | カノニカル | 0.5秒 | 15秒 | 20秒 | 30秒 | 30秒 | 10秒 | 2秒 | 5秒 | 20秒 |
| Quick | 診断用 | 0.25秒 | 7.5秒 | 10秒 | 15秒 | 15秒 | 5秒 | 1秒 | 2.5秒 | 10秒 |
| Extended | 診断用 | 1秒 | 30秒 | 40秒 | 60秒 | 60秒 | 20秒 | 4秒 | 10秒 | 40秒 |
| Custom | ユーザー定義 | 許容範囲内でユーザーが選択 |
Candidateはデフォルトのプロファイルであり、その実行のみがランキングされます。Quick、Extended、Customは常に診断用と見なされます。これらをCandidateと同じ比較で混在させることはできず、ランキングに公開することもできません。Customでは一部のテストを残し、独自の長さを設定できます。本測定ブロックは1～180秒、遷移は0.1～180秒、遅延ウォームアップは0.5～180秒を受け付けます。長さを上書きすると、その実行は診断用になります。
各フレームでのディスク書き込みなしの収集
Section titled “各フレームでのディスク書き込みなしの収集”測定値は、あらかじめ確保されたメモリブロックに保存されます。各フレームの収集時に、プログラムはJSONをフォーマットせず、ベクターを拡張せず、ファイルに書き込みません。バッファのサイズは、テストの長さと予想される最大記録頻度から余裕を持って事前に計算されます。この実装では768 MiBの制限が適用されます。
GPU処理の完了後、データは統合されて処理されます。これによりデータ収集がテストに与える影響を減らしますが、収集自体もリソースを消費します。その影響を測定するには、測定値の収集ありとなしの実行を別途比較する必要があります。
結果には集計メトリクスが含まれます。別個の生測定ファイルにより、負荷を新たに実行することなく統計処理を繰り返すことができます。このような再計算は計算を検証しますが、ハードウェア上での再現性を検証するには新しい実行が必要です。
実行の品質と結果の不適格性
Section titled “実行の品質と結果の不適格性”各ブロック中に、エンジンは実行の品質 — Run Quality — を評価します。主な指標はCPUのバックグラウンド負荷、つまりベンチマーク自体以外でシステムに負荷をかけるすべてのものです。これはブロックごとに、システム全体の負荷とベンチマークプロセスの負荷の差として、同じ時間カウンターで測定して計算されます。Candidateプロファイルのしきい値: 20%超で警告、50%超で実行は不適格と判定されます。
Run Qualityは付随する条件も記録します: デバッガーの接続、リモートセッション、バッテリー駆動と省電力モード、ハイパーバイザーの存在、ウィンドウフォーカスの喪失、ディスプレイの切り替え。ハイパーバイザー、バッテリー、リモートセッションは警告として開示されます。それ自体は結果を棄却しませんが、「クリーンな」ベンチ環境と数値が異なる理由を説明します。本測定ブロック中のディスプレイの切り替えは、実行を不適格にします。
適格な本測定結果には、さらに以下が必要です:
- Loaded Latencyのキャリブレーションの成功 — 目標時間に合わせて難易度を調整できなかった場合、実行は不適格です;
- GPU負荷の終了チェックの通過 — 制御シグネチャの不一致は実行を不適格にします;
- コレクターの記録損失がないこと — いかなる損失も実行を不適格にします。
品質の分類は結果ファイルに保存されるため、「悪い」条件は実行中だけでなく事後にも確認できます。
結果の読み方
Section titled “結果の読み方”| 指標 | 意味 |
|---|---|
| Performance | 固定負荷の相対的な速度 |
| Core Latency Score | 内部遅延の相対的な評価。スコアが高いほど良い |
| Consistency | 実行内での遅いテールの顕著さ |
| PC Score | 重み50/30/20で3つのコンポーネントを幾何学的に統合したもの |
実際の遅延はミリ秒で表示され、それらは小さいほど良いです。Consistencyを実行間のPC Scoreの再現性と混同しないでください。式と正規化定数はスコア計算で公開されています。
- 合成シナリオはシステムの変化を検出するのに役立ちますが、特定のゲームのテストを置き換えるものではありません。
- 実行間のばらつきが小さいことは、各タイムスタンプの正確さや系統的誤差の不在をまだ証明しません。
- 1台のPCでの8回の実行は、すべてのCPU、GPU、Windowsバージョンに対する結果の分布を確立するものではありません。
- 互換性のある負荷バージョンと同じプロファイルを比較してください。高速化、拡張、ユーザー定義のプロファイルをCandidateと無条件に混在させることはできません。
- キャンセルされた実行や不完全な実行を、完了した測定の代わりに使用しないでください。
次へ: 負荷、遅延とPresentMon、式、再現性、実行の比較、ランキング。
確認済み: 2026-09-20。