Metodología del benchmark

PCBenchmarkX mide la ejecución de escenarios CPU/GPU definidos y la latencia de reacción a una señal de software. El volumen de trabajo es fijo, las fórmulas de evaluación son abiertas. Las ejecuciones repetidas permiten comprobar la estabilidad del resultado.

Esta documentación se refiere al motor 0.5.2, la carga phase4.6-dev-1, la estadística stats-phase4.6-v1 y el modelo score-model-1.2-candidate-1. En el nombre del modelo se usa Candidate. Sus valores de normalización son preliminares: no pueden considerarse promedios de todos los ordenadores. Más detalles sobre el patrón de referencia se explican en el cálculo de puntuaciones.

Preparación

BoosterX controla el lanzamiento de un motor nativo independiente, muestra el progreso del test y guarda el resultado. Durante la medición, suspende su propio monitoreo de hardware y memoria y minimiza sus ventanas, luego restaura su estado. Esto reduce la influencia de la propia interfaz de BoosterX; los programas externos de todos modos pueden generar carga.

Repita los tests con una misma versión del motor y del controlador, y con los mismos ajustes de energía, overclocking y refrigeración. Cierre los programas en segundo plano innecesarios. Si tiene un portátil, realice todos los tests con el cargador conectado. Al comparar antes y después de un cambio, anote qué ajuste exactamente modificó.

Secuencia de Candidate

Parte de la ejecución	Duración definida	Propósito
Calentamiento	15 s	Preparar la carga antes de las mediciones válidas
CPU	20 s en total	Tres bloques de aproximadamente 6,67 s
GPU	30 s en total	10 s por Geometry, Shader y Compute, cada uno en tres bloques
Combined	30 s en total	Tres bloques de 10 s
Calibración	10 s	Ajustar la complejidad de Loaded Latency
Calentamiento de latencia	2 s	Preparar la ruta de medición de latencia independiente
Baseline Latency	5 s	Medir la latencia con carga base
Loaded Latency	20 s	Medir la latencia con carga calibrada

Las transiciones, la preparación de recursos, los fotogramas CPU preliminares y la finalización añaden tiempo. Por eso el tiempo total de la ejecución es mayor que la suma de las etapas medidas: en la serie verificada los intervalos entre los inicios de ejecuciones vecinas dentro de una misma carga fueron de aproximadamente 157–172 segundos — teniendo en cuenta la pausa entre ejecuciones; la duración exacta de una ejecución no puede determinarse a partir de los datos publicados.

Los bloques de los tests de rendimiento se alternan en tres rondas. En CPU, antes de cada bloque válido hay un estado inicial fijo y 512 fotogramas preparatorios. Si la velocidad de trabajo cambia gradualmente de bloque a bloque, esto se refleja en el diagnóstico. Los resultados obtenidos no se corrigen por ello.

Perfiles de ejecución y duraciones

El motor admite cuatro perfiles: candidate, quick, extended y custom. Duraciones exactas de las etapas:

Perfil	Tarea	Transición	Calentamiento	CPU	GPU	Combined	Calibración	Calentamiento de latencia	Baseline	Loaded
Candidate	canónico	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnóstico	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnóstico	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	personalizado	a elección del usuario dentro de los límites permitidos

Candidate es el perfil predeterminado, y solo sus ejecuciones se clasifican. Quick, Extended y Custom siempre se consideran diagnósticos: no pueden mezclarse con Candidate en una misma comparación ni publicarse en la clasificación. En Custom se puede dejar una parte de los tests y definir duraciones propias: los bloques válidos aceptan 1–180 s, las transiciones — 0,1–180 s, el calentamiento de latencia — 0,5–180 s. Cualquier redefinición de duración hace que la ejecución sea diagnóstica.

Recolección sin escritura en disco en cada fotograma

Las mediciones se guardan en bloques de memoria reservados de antemano. Al recolectar cada fotograma, el programa no formatea JSON, no amplía el vector ni escribe en un archivo. El tamaño de los búferes se calcula de antemano según la duración del test y la frecuencia máxima esperada de registros, con margen. En esta implementación rige una limitación de 768 MiB.

Tras finalizar el trabajo de GPU, los datos se combinan y se procesan. Esto reduce la influencia de la recolección de datos sobre el test, aunque la propia recolección también consume recursos. Para medir su influencia, hay que comparar por separado ejecuciones con recolección de mediciones y sin ella.

El resultado contiene métricas resumidas. Un archivo aparte de mediciones originales permite repetir el procesamiento estadístico sin una nueva ejecución de la carga. Tal recálculo comprueba los cálculos; para comprobar la repetibilidad en el hardware se necesita una nueva ejecución.

Calidad de la ejecución e invalidez del resultado

Durante cada bloque, el motor evalúa la calidad de la ejecución — Run Quality. El indicador principal es la carga de CPU en segundo plano, es decir, todo lo que carga el sistema aparte del propio benchmark. Se calcula por bloque como la diferencia entre la carga de todo el sistema y la carga del proceso del benchmark, medidas con los mismos contadores de tiempo. Los valores umbral para el perfil Candidate: por encima del 20% — advertencia, por encima del 50% — la ejecución se considera inválida.

Run Quality también registra condiciones asociadas: depurador conectado, sesión remota, alimentación por batería y modo de ahorro de energía, presencia de hipervisor, pérdida de foco de la ventana y cambio de pantalla. El hipervisor, la batería y la sesión remota se muestran como advertencias: por sí solos no rechazan el resultado, pero explican por qué los números pueden diferir de un banco de pruebas «limpio». El cambio de pantalla durante un bloque válido hace que la ejecución sea inválida.

Un resultado válido además requiere:

• una calibración exitosa de Loaded Latency — si no se logró ajustar la complejidad al tiempo objetivo, la ejecución es inválida;
• una comprobación superada de la salida de las cargas de GPU — una discrepancia de la firma de control hace que la ejecución sea inválida;
• la ausencia de registros perdidos del colector — cualquier pérdida hace que la ejecución sea inválida.

La clasificación de calidad se guarda en el archivo de resultado, por lo que las condiciones «malas» son visibles a posteriori, y no solo durante la ejecución.

Cómo leer el resultado

Indicador	Significado
Performance	Velocidad relativa de cargas fijas
Core Latency Score	Evaluación relativa de la latencia interna; más puntos es mejor
Consistency	Expresividad de la cola lenta dentro de la ejecución
PC Score	Combinación geométrica de tres componentes con pesos 50/30/20

Las latencias reales se muestran en milisegundos, y para ellas menos es mejor. Consistency no puede mezclarse con la repetibilidad de PC Score entre ejecuciones. Las fórmulas y las constantes de normalización son abiertas en el cálculo de puntuaciones.

Límites del resultado

• El escenario sintético ayuda a detectar cambios del sistema, pero no sustituye el test de un juego concreto.
• Una baja dispersión entre ejecuciones todavía no demuestra la precisión de cada marca temporal ni la ausencia de un error sistemático.
• Ocho ejecuciones de un mismo PC no establecen la distribución de resultados para todos los CPU, GPU y versiones de Windows.
• Compare versiones compatibles de cargas y perfiles idénticos. Los perfiles acelerado, extendido y personalizado no pueden mezclarse incondicionalmente con Candidate.
• No use una ejecución cancelada o incompleta en lugar de una medición completada.

A continuación: cargas, latencias y PresentMon, fórmulas, repetibilidad, comparación de ejecuciones, clasificación.

Verificado: 2026-09-20.