Méthodologie du benchmark

PCBenchmarkX mesure l’exécution de scénarios CPU/GPU définis et la latence de réaction à un signal logiciel. Le volume de travail est fixe, les formules d’évaluation sont ouvertes. Les exécutions répétées permettent de vérifier la stabilité du résultat.

Cette documentation se rapporte au moteur 0.5.2, à la charge phase4.6-dev-1, aux statistiques stats-phase4.6-v1 et au modèle score-model-1.2-candidate-1. Le nom du modèle utilise Candidate. Ses valeurs de normalisation sont préliminaires : elles ne peuvent pas être considérées comme les moyennes de tous les ordinateurs. L’étalon est décrit plus en détail dans le calcul des scores.

Préparation

BoosterX pilote le lancement d’un moteur natif distinct, affiche la progression du test et enregistre le résultat. Pendant la mesure, il suspend sa propre surveillance du matériel et de la mémoire et réduit ses fenêtres, puis restaure leur état. Cela réduit l’influence de l’interface BoosterX elle-même ; les programmes externes peuvent néanmoins créer de la charge.

Répétez les tests avec une même version du moteur et du pilote, des réglages d’alimentation, d’overclocking et de refroidissement identiques. Fermez les programmes d’arrière-plan superflus. Si vous avez un ordinateur portable, effectuez tous les tests avec le chargeur branché. Lors d’une comparaison avant et après une modification, notez précisément quel réglage vous avez changé.

Séquence Candidate

Partie de l’exécution	Durée définie	Fonction
Préchauffage	15 s	Préparer la charge avant les mesures comptabilisées
CPU	20 s au total	Trois blocs d’environ 6,67 s
GPU	30 s au total	10 s pour Geometry, Shader et Compute, chacun en trois blocs
Combined	30 s au total	Trois blocs de 10 s
Calibrage	10 s	Ajuster la complexité de Loaded Latency
Préchauffage latence	2 s	Préparer le chemin de mesure distinct de la latence
Baseline Latency	5 s	Mesurer la latence sous charge de base
Loaded Latency	20 s	Mesurer la latence sous charge calibrée

Les transitions, la préparation des ressources, les images CPU préliminaires et la finalisation ajoutent du temps. C’est pourquoi la durée totale d’une exécution dépasse la somme des étapes mesurées : dans la série vérifiée, les intervalles entre les débuts d’exécutions voisines au sein d’une même charge étaient d’environ 157–172 secondes — en tenant compte de la pause entre les exécutions ; la durée exacte d’une exécution ne peut pas être déterminée à partir des données publiées.

Les blocs de tests de performance alternent en trois tours. Pour le CPU, chaque bloc comptabilisé est précédé d’un état initial fixe et de 512 images préparatoires. Si la vitesse d’exécution évolue progressivement d’un bloc à l’autre, cela apparaît dans les diagnostics. Les résultats obtenus ne sont pas corrigés pour autant.

Profils d’exécution et durées

Le moteur prend en charge quatre profils : candidate, quick, extended et custom. Durées exactes des étapes :

Profil	Tâche	Transition	Préchauffage	CPU	GPU	Combined	Calibrage	Préchauffage latence	Baseline	Loaded
Candidate	canonique	0,5 s	15 s	20 s	30 s	30 s	10 s	2 s	5 s	20 s
Quick	diagnostique	0,25 s	7,5 s	10 s	15 s	15 s	5 s	1 s	2,5 s	10 s
Extended	diagnostique	1 s	30 s	40 s	60 s	60 s	20 s	4 s	10 s	40 s
Custom	personnalisé	au choix de l’utilisateur dans les limites admises

Candidate est le profil par défaut, et seules ses exécutions sont classées. Quick, Extended et Custom sont toujours considérés comme diagnostiques : ils ne peuvent pas être mélangés avec Candidate dans une même comparaison et ne peuvent pas être publiés dans le classement. Dans Custom, on peut conserver une partie des tests et définir ses propres durées : les blocs comptabilisés acceptent 1–180 s, les transitions — 0,1–180 s, le préchauffage de latence — 0,5–180 s. Toute redéfinition de durée rend l’exécution diagnostique.

Collecte sans écriture sur disque à chaque image

Les mesures sont conservées dans des blocs de mémoire alloués à l’avance. Lors de la collecte de chaque image, le programme ne formate pas de JSON, n’agrandit pas le vecteur et n’écrit pas dans un fichier. La taille des tampons est calculée à l’avance d’après la durée du test et la fréquence d’enregistrement maximale attendue, avec une marge. Dans cette implémentation, une limite de 768 MiB s’applique.

Une fois le travail GPU terminé, les données sont fusionnées et traitées. Cela réduit l’influence de la collecte de données sur le test, bien que la collecte elle-même consomme aussi des ressources. Pour mesurer son influence, il faut comparer séparément les exécutions avec et sans collecte des mesures.

Le résultat contient des métriques synthétiques. Un fichier distinct de mesures brutes permet de répéter le traitement statistique sans nouvelle exécution de la charge. Un tel recalcul vérifie les calculs ; pour vérifier la répétabilité sur le matériel, une nouvelle exécution est nécessaire.

Qualité de l’exécution et inaptitude du résultat

Pendant chaque bloc, le moteur évalue la qualité de l’exécution — Run Quality. L’indicateur principal est la charge CPU en arrière-plan, c’est-à-dire tout ce qui charge le système en plus du benchmark lui-même. Elle est calculée par bloc comme la différence entre la charge de tout le système et la charge du processus du benchmark, mesurées par les mêmes compteurs de temps. Valeurs seuils pour le profil Candidate : au-dessus de 20% — avertissement, au-dessus de 50% — l’exécution est déclarée inapte.

Run Quality enregistre aussi les conditions associées : débogueur connecté, session distante, alimentation sur batterie et mode d’économie de charge, présence d’un hyperviseur, perte de focus de la fenêtre et changement d’écran. L’hyperviseur, la batterie et la session distante apparaissent comme des avertissements : en eux-mêmes, ils ne rejettent pas le résultat, mais expliquent pourquoi les chiffres peuvent différer d’un banc « propre ». Un changement d’écran pendant un bloc comptabilisé rend l’exécution inapte.

Un résultat comptabilisé apte exige en outre :

• un calibrage réussi de Loaded Latency — si la complexité n’a pas pu être ajustée au temps cible, l’exécution est inapte ;
• une vérification réussie de la sortie des charges GPU — une non-concordance de la signature de contrôle rend l’exécution inapte ;
• l’absence d’enregistrements perdus du collecteur — toute perte rend l’exécution inapte.

La classification de la qualité est conservée dans le fichier de résultat, de sorte que les conditions « mauvaises » soient visibles après coup, et pas seulement pendant l’exécution.

Comment lire le résultat

Indicateur	Signification
Performance	Vitesse relative des charges fixes
Core Latency Score	Évaluation relative de la latence interne ; plus de points, mieux c’est
Consistency	Expression d’une queue lente au sein d’une exécution
PC Score	Combinaison géométrique de trois composants avec les poids 50/30/20

Les latences réelles sont affichées en millisecondes, et pour elles, moins c’est mieux. Consistency ne doit pas être confondu avec la répétabilité du PC Score entre les exécutions. Les formules et les constantes de normalisation sont ouvertes dans le calcul des scores.

Limites du résultat

• Un scénario synthétique aide à détecter des changements du système, mais ne remplace pas un test d’un jeu précis.
• Une faible dispersion entre les exécutions ne prouve pas encore l’exactitude de chaque horodatage ni l’absence d’erreur systématique.
• Huit exécutions sur un même PC n’établissent pas la distribution des résultats pour tous les CPU, GPU et versions de Windows.
• Comparez des versions de charges compatibles et des profils identiques. Les profils accéléré, étendu et personnalisé ne peuvent pas être mélangés sans réserve avec Candidate.
• N’utilisez pas une exécution annulée ou incomplète à la place d’une mesure achevée.

Ensuite : charges, latences et PresentMon, formules, répétabilité, comparaison des exécutions, classement.

Vérifié : 2026-09-20.