基准测试方法
本页内容
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 秒 |
| GPU | 总计 30 秒 | Geometry、Shader 和 Compute 各 10 秒，每个分三个区块 |
| Combined | 总计 30 秒 | 三个区块，每个 10 秒 |
| 校准 | 10 秒 | 调整 Loaded Latency 的复杂度 |
| 延迟预热 | 2 秒 | 为单独的延迟测量路径做准备 |
| Baseline Latency | 5 秒 | 测量基础负载下的延迟 |
| Loaded Latency | 20 秒 | 测量校准负载下的延迟 |
过渡、资源准备、预备 CPU 帧和收尾会增加时间。因此总运行时间大于各测量阶段之和：在已验证的系列中，同一次加载中相邻两次运行开始之间的间隔约为 157–172 秒——其中包含运行之间的暂停；仅凭已发布的数据无法确定单次运行的准确时长。
性能测试区块在三轮中交替进行。CPU 在每个计分区块前都有固定的初始状态和 512 个预备帧。如果运行速度逐块逐渐变化，这会在诊断中体现出来。此时获得的结果不会被修正。
运行配置文件和时长
Section titled “运行配置文件和时长”引擎支持四种配置文件：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 权重进行的几何合并 |
实际延迟以毫秒显示，且对它们而言越小越好。Consistency 不能与 PC Score 在多次运行之间的可重复性混为一谈。公式和归一化常数在分数计算中公开。
- 合成场景有助于发现系统变化，但不能替代具体游戏的测试。
- 较低的运行间离散度尚不能证明每个时间戳的准确性或不存在系统性误差。
- 同一台 PC 的八次运行并不能确定所有 CPU、GPU 和 Windows 版本的结果分布。
- 请比较兼容的负载版本和相同的配置文件。加速、扩展和用户自定义配置文件不能无条件地与 Candidate 混用。
- 已取消或不完整的运行不要用来代替已完成的测量。
接下来：负载、延迟与 PresentMon、公式、可重复性、运行比较、排行榜。
已验证：2026-09-20。