Aller au contenu

Comment les scores sont calculés

Sur cette page

PC Score est un indice sans dimension. Dans le nouveau modèle, il combine CPU, GPU et la latence interne. Poids de base : CPU 60%, GPU 20%, Latency 20%. Les étalons et les poids ci-dessous décrivent la configuration de base, et non la promesse de réglages immuables du classement en ligne : le serveur peut publier une nouvelle méthodologie.

Pour un bloc, la capacité de traitement est calculée à partir du nombre d’enregistrements valides et du temps entre le premier et le dernier :

throughput = (N_valid − 1) × QPC_frequency / (last_QPC − first_QPC)

Pour les trois blocs d’une même charge, la moyenne arithmétique du throughput est utilisée. Le CPU frame time décrit le temps de travail du CPU. Pour GPU et Combined, les intervalles de trames sont déterminés à partir des GPU timestamps voisins du début du travail ; la durée du travail GPU lui-même est stockée séparément. Le nombre de trames conventionnelles du benchmark n’est pas un FPS de jeu.

Les mesures manquantes ne sont pas remplacées par des zéros. Si les données sont insuffisantes pour l’évaluation, l’indisponibilité d’un composant ne peut pas être interprétée comme une performance nulle.

Les percentiles sont calculés par interpolation linéaire Hyndman–Fan Type 7 pour les valeurs triées :

h = (n − 1) × p
i = floor(h)
percentile = x[i] + (h − i) × (x[min(i + 1, n − 1)] − x[i])

P50 est la médiane. P99 du temps de trame caractérise la queue lente : environ 99% des observations ne dépassent pas cette limite.

  • 1% Low = 1000 / P99 du temps de trame en millisecondes.
  • 0,1% Low = 1000 / P99,9 du temps de trame.

Ici, Low FPS est un percentile inverse, et non le FPS moyen du pire pour cent des trames. Les chiffres d’un autre test avec une définition différente du Low FPS peuvent différer même sur des données identiques. Le 0,1% Low est sensible aux événements rares et à la longueur de l’enregistrement. Dans la nouvelle formule de base, le CPU utilise P99 ; P99,9 est affiché comme métrique supplémentaire et n’a pas de poids distinct dans le PC Score.

Pour la vitesse, la valeur normalisée est égale à measurement / reference, pour la latence à reference / measurement. Moyenne géométrique pondérée :

G(x, w) = exp(Σ(w × ln(x)) / Σw)

Les étalons sont des nombres fixes servant à la normalisation, et non des moyennes sur tous les ordinateurs ni un standard du marché. L’échelle de l’évaluation de base est de 10 000 : la coïncidence de toutes les entrées utilisées avec l’étalon donne 10 000 points. Les poids sont normalisés par leur somme.

Le CPU combine la vitesse d’exécution du scénario CPU et le P99 de son temps de trame. Étalons de base : throughput 4000 trames conventionnelles/s, P99 0,3 ms. Poids internes du CPU : 60% de vitesse et 40% de queue du temps de trame.

CPU Score = 10000 ×
(CPU throughput / 4000)^0.60 ×
(0.3 / CPU frame P99_ms)^0.40

La seconde partie équivaut à normaliser le 1% Low CPU vers 1000 / 0.3, soit environ 3333,33 trames conventionnelles/s. Des latences plus rares peuvent améliorer le CPU Score même avec un throughput moyen proche. Ce n’est pas le 1% Low dans CS2 ou un autre jeu : c’est la propre simulation CPU du benchmark qui est mesurée.

Scénario Étalon throughput, trames conventionnelles/s Poids dans le GPU
Geometry 740 45%
Shader 360 45%
Compute 7600 10%
GPU Score = 10000 ×
(Geometry / 740)^0.45 ×
(Shader / 360)^0.45 ×
(Compute / 7600)^0.10

Compute a un poids plus faible que les deux scénarios graphiques. Une vitesse élevée isolée du shader de calcul ne signifie donc pas un score global proportionnellement élevé. Le GPU Score dépend aussi du pilote, de la soumission des commandes et de l’état du système ; ce n’est pas une évaluation isolée de la fiche technique de la carte graphique.

On utilise les percentiles P50, P95 et P99 de la latence du signal logiciel jusqu’à la fin du travail GPU.

Scénario Étalon P50, ms Étalon P95, ms Étalon P99, ms Poids du scénario
Baseline 2,5 4 6 20%
Loaded 9 12 16 80%

À l’intérieur de chaque scénario, les poids P50/P95/P99 sont de 50/30/20 :

Baseline = (2.5 / B50)^0.50 × (4 / B95)^0.30 × (6 / B99)^0.20
Loaded = (9 / L50)^0.50 × (12 / L95)^0.30 × (16 / L99)^0.20
Core Latency Score = 10000 × Baseline^0.20 × Loaded^0.80

Les latences en millisecondes sont meilleures lorsqu’elles sont plus faibles ; le score correspondant augmente alors. Les métriques de sortie de trame PresentMon ne font pas partie de ce composant.

PC Score = 10000 ×
(CPU Score / 10000)^0.60 ×
(GPU Score / 10000)^0.20 ×
(Core Latency Score / 10000)^0.20

Il s’agit d’une somme géométrique, et non arithmétique. Par exemple, à entrées constantes par ailleurs :

  • une augmentation du CPU throughput de 10% augmente le PC Score d’environ 3,5% : 1.10^(0.60 × 0.60) ;
  • une diminution du CPU P99 de 10% augmente le PC Score d’environ 2,6% : (1 / 0.90)^(0.40 × 0.60) ;
  • un doublement de Compute augmente le PC Score d’environ 1,4% : 2^(0.10 × 0.20).

Ce sont des exemples arithmétiques, et non un effet mesuré d’overclocking ou d’optimisation. En pratique, un seul réglage peut modifier plusieurs métriques à la fois.

Dans les anciens résultats et le diagnostic étendu, Performance peut être conservé. Sa formule de base combine CPU, Geometry, Shader, Compute et Combined avec des poids relatifs 3/1/1/1/3 et des étalons 4000/740/360/7600/665. Dans le modèle CPU/GPU/Latency, Performance n’est pas une entrée du PC Score final. Combined reste un scénario mesuré à part, mais n’entre pas directement dans la nouvelle formule finale.

Consistency décrit le rapport entre la queue lente et le temps typique au sein d’un lancement. Pour le diagnostic de base, on utilise les rapports P99/P50 du CPU, de Shader et de Combined, normalisés vers 1,20 / 1,15 / 1,20 et combinés par moyenne géométrique à poids égaux.

Consistency n’est pas un multiplicateur distinct de la nouvelle formule. Ce n’est pas un abandon de l’évaluation de la fluidité : le P99 du CPU est déjà pris en compte dans le CPU Score, et les latences P95/P99 entrent dans Latency. La répétabilité entre lancements complets est de toute façon vérifiée séparément.

Mise à jour de la méthodologie et anciens résultats

Section intitulée « Mise à jour de la méthodologie et anciens résultats »

Le client reçoit les paramètres d’évaluation depuis le serveur. Après la publication d’une nouvelle méthodologie, le serveur peut recalculer les résultats enregistrés à partir des mesures disponibles et modifier les places dans le classement. Le recalcul change les scores, mais ne répète pas le test et ne corrige pas l’ancienne charge, le pilote ou les conditions de lancement.

Le classement n’est pas divisé en tableaux distincts uniquement à cause de la version de la méthodologie. Pour votre propre expérience avant/après, choisissez de toute façon la même version de charge et les mêmes conditions. Si les données nécessaires manquent pour un composant d’un ancien résultat, on ne peut pas les reconstituer à partir du score global ni considérer la valeur absente comme un zéro.

L’archive série de version 0.5.2 conserve les scores initiaux de l’ancien modèle Performance / Latency / Consistency avec les poids 50/30/20. Ses tableaux et son script ne constituent pas une vérification de la nouvelle formule. Les intermédiaires 70/20/10 relèvent également de l’ancien modèle, et non du modèle CPU/GPU/Latency décrit ici.

Mis à jour : 2026-10-02.