Comment lire les benchmarks CPU sans se faire avoir

Ce que mesurent réellement les benchmarks CPU (et ce qu’ils ne mesurent pas)

Un benchmark CPU est une charge de travail synthétique avec une fonction de score. C’est tout. Parfois la charge est un microbenchmark (boucle serrée, petit jeu de données), parfois c’est une suite de benchmarks (plusieurs programmes, jeux de travail plus grands), parfois c’est un benchmark applicatif (requêtes réelles de BD, jobs de rendu réels).

Le score est une compression de la réalité en un seul nombre. Cette compression jette des détails dont vous avez besoin en exploitation : latence tail, jitter, comportement thermique, stabilité de fréquence, pénalités NUMA, limites de bande passante mémoire, bizarreries d’ordonnancement du noyau, et interactions avec le stockage et le réseau. En production, ces « détails » sont le spectacle entier.

Trois couches : silicium, système et charge

Quand on parle de « performance CPU », on entend souvent trois choses différentes :

• Capacité du silicium : IPC, fréquence, hiérarchie de cache, unités vectorielles, prédiction de branchements, nombre de cœurs.
• Livraison système : réglages BIOS/UEFI, limites d’alimentation, refroidissement, vitesse et canaux mémoire, topologie NUMA, noyau et microcode, overhead de virtualisation.
• Comportement de la charge : mix d’instructions, branchements, empreinte cache, contention sur les verrous, appels système, attentes IO, pauses GC, sérialisation, goulots single-thread.

Un score de benchmark est généralement un cocktail des trois. C’est pourquoi comparer deux scores sans les conditions d’exécution revient à comparer deux chiffres « miles per gallon » sans savoir si une voiture a roulé en descente avec du vent arrière.

Les questions sur les benchmarks à poser en premier

• Quel est le goulot d’étranglement du benchmark ? Calcul, bande passante mémoire, latence mémoire, cache, prédiction de branchement ou autre ?
• Est-ce limité à un seul thread ou parallèle ? Est-ce que ça scale avec les cœurs, ou ça bute sur un mur sériel ?
• Quels jeux d’instructions sont utilisés ? AVX2, AVX-512, AMX, NEON — ils peuvent faire varier les résultats de façon spectaculaire et inégale selon les CPU.
• Quel est l’environnement d’exécution ? Version de l’OS, noyau, microcode, compilateur, politique d’alimentation, comportement turbo, réglages BIOS.
• Quelle est la métrique ? Débit, temps de complétion, opérations par seconde, requêtes par seconde, ou un « score » propriétaire ?

Si le graphique ne répond pas à ces questions, ce n’est pas un graphique de benchmark. C’est une ambiance.

Une citation pour rester honnête : « L’espoir n’est pas une stratégie. » — Général Gordon R. Sullivan

Les benchmarks sont l’endroit où l’espoir s’habille en mathématiques. Ne vous laissez pas avoir.

Faits et contexte historique qui changent la lecture des graphiques

Les benchmarks ne sont pas devenus confus parce que les ingénieurs ont oublié comment mesurer. Ils le sont devenus parce que la pile s’est compliquée et que les incitations sont devenues bruyantes. Un peu d’histoire vous aide à voir venir les astuces.

1. La fréquence d’horloge a cessé d’être un proxy propre au milieu des années 2000. La « course au GHz » s’est heurtée aux limites de densité de puissance et thermiques ; l’IPC, les caches et le parallélisme sont devenus les différenciateurs.
2. Les benchmarks SPEC ont façonné les achats pendant des décennies. Les suites SPEC CPU ont été conçues pour standardiser les comparaisons, mais elles restent sensibles aux compilateurs, flags et choix d’optimisation.
3. Turbo/boost a transformé la « fréquence CPU » d’une constante en une négociation. Les CPU modernes boostent opportunistement selon la température, la puissance et le courant ; deux CPU identiques peuvent produire des résultats différents selon le refroidissement et les limites d’alimentation.
4. Les jeux d’instructions vectorielles ont créé des « falaises de performance ». Les workloads AVX2/AVX-512 peuvent déclencher des réductions de fréquence sur certains CPU ; le CPU « le plus rapide » en code scalaire peut faiblir sous vecteurs lourds, ou inversement.
5. Hyper-threading/SMT a déplacé les marqueurs du « nombre de cœurs ». Les CPU logiques ne sont pas de vrais cœurs. Le SMT peut améliorer le débit, dégrader la latence tail, ou faire les deux à la fois.
6. NUMA est devenu la norme sur les serveurs. Les designs multi-socket et à chiplets introduisent un accès mémoire non uniforme ; « plus de cœurs » peut signifier « plus de latence cross-die » si vous planifiez mal.
7. Les atténuations de sécurité ont rendu certains anciens chiffres de benchmark obsolètes. Les mitigations du noyau et du microcode pour les vulnérabilités side-channel ont changé les workloads riches en appels système et en changements de contexte.
8. Les CPU dans le cloud ont transformé les benchmarks en « comportement d’instance ». Voisins bruyants, ordonnancement vCPU, limites de turbo, et crédits CPU signifient que le même type d’instance peut benchmarker différemment selon le moment.

Ce ne sont pas des détails. Ce sont les raisons pour lesquelles votre « classement CPU » préféré échoue régulièrement à prédire la performance en production.

Les façons classiques dont le marketing des benchmarks vous embobine

1) Le benchmark utilise des jeux d’instructions que votre charge n’utilise pas

Beaucoup de benchmarks populaires vectorisent agressivement. Si votre charge est principalement logique métier branchée, parsing JSON, recherches d’index en base, ou temps noyau, ce débit vectoriel est décoratif.

Que faire : Identifiez votre mix d’instructions. Si vous ne pouvez pas, au moins catégorisez : scalaire/branché vs charge heavy-vector. Si vos fonctions les plus chaudes ne ressemblent pas à de l’algèbre linéaire, considérez les scores boostés par vectoriels comme « agréable à avoir », pas comme critère d’achat.

2) Le benchmark tient dans le cache ; votre charge non

Les microbenchmarks tournent souvent sur de petits jeux de données. Ils mesurent l’exécution maximale, pas ce qui arrive quand vous débordez le L3, puis la DRAM, puis commencez à vous battre avec le contrôleur mémoire pendant que d’autres cœurs font la même chose.

Que faire : Préférez des benchmarks qui reportent plusieurs tailles de jeu de données, ou exécutez les vôtres avec des jeux réalistes. Le cache amplifie la performance jusqu’à ce qu’il ne le fasse plus.

3) Turbo rend la « performance mono-cœur » une cible mobile

Les graphiques mono-thread reflètent souvent la fréquence de boost maximale dans des conditions idéales. Dans une armoire avec recirculation d’air chaud, ou avec des limites d’alimentation strictes, vous ne verrez pas ce chiffre de façon cohérente.

Que faire : Cherchez la fréquence soutenue sous charge et les limites de puissance (PL1/PL2), pas seulement le pic.

4) Les différences de configuration mémoire sont masquées

On peut présenter des benchmarks comme « comparaisons CPU » alors qu’un système a moins de canaux mémoire peuplés, des DIMM plus lents, des rangs différents, ou un interleaving BIOS différent. Si le benchmark touche la mémoire, ce n’est pas un détail mineur — c’est le résultat.

Que faire : Vérifiez la population des canaux mémoire et la vitesse. Si le rapport ne le mentionne pas, supposez qu’il a été optimisé pour gagner.

5) SMT/HT est activé pour une exécution et désactivé pour une autre

Certaines charges aiment le SMT ; d’autres voient leur latence tail empirer parce que deux CPU logiques se disputent les ressources du cœur. Comparer des scores sans parité SMT est au mieux bâclé.

Que faire : Décidez de ce qui compte : débit ou latence. Testez les deux configurations si votre charge est sensible à la latence.

6) Le « score » cache la distribution

Les systèmes de production échouent au p99 et p999, pas sur le « score moyen ». Un CPU qui brille sur le débit moyen peut être catastrophique quand il atteint des limites thermiques ou des contentions d’ordonnancement.

Que faire : Exigez les distributions de latence, pas seulement les moyennes. Si un benchmark ne peut pas rapporter la variance, il ne décrit pas les opérations.

7) « Même CPU » n’est pas le même CPU

Les mises à jour de microcode, les révisions de stepping, des limites d’alimentation par défaut différentes, et les updates BIOS du fournisseur peuvent affecter le comportement. Même au sein d’un même SKU.

Blague #1 : Les graphiques de benchmark sont comme les photos de restaurant : techniquement liées à la réalité, mais les frites ne ressemblent à rien à la maison.

Faire correspondre les résultats de benchmark à votre charge : une couche de traduction pratique

Lire correctement les benchmarks CPU tient moins de l’adoration du « meilleur score » que de la traduction d’un benchmark vers votre goulot d’étranglement. Vous pouvez le faire sans doctorat. Il suffit de poser les bonnes questions et de refuser d’accepter un seul nombre comme identité.

Étape 1 : Classifiez votre charge par contraintes

• Limitée par un seul thread : beaucoup de travail sériel, verrous, une boucle d’événement principale, un seul thread de requête, pauses GC stop-the-world.
• Embarrassingly parallel : rendu, encodage, transformations ETL par lot, travail par requête sans état.
• Limitée par la bande passante mémoire : scans analytiques, traitement en colonnes en mémoire, grands hash joins.
• Sensible à la latence mémoire : chase de pointeurs, workloads graphe, recherches clé-valeur, OLTP avec cache misses.
• IO-bound avec pointes CPU : services intensifs en stockage, compactage, checksum, chiffrement, compression.
• Noyau/réseau intense : traitement de paquets, terminaison TLS, fort taux d’appels système.

Étape 2 : Décidez de votre métrique : débit, latence ou coût

Les discussions de benchmarks en entreprise portent généralement sur le débit (« plus de requêtes/sec »). Les opérations se soucient souvent de la latence tail sous charge. La finance s’intéresse au $/requête. Ces objectifs ne choisissent pas le même CPU.

Si vous exploitez une base de données, un broker de messages, ou tout service orienté latence client, traitez le p99 comme une métrique de première classe. Un CPU qui augmente le débit de 15 % mais détériore le p99 n’est pas « plus rapide ». Il est juste plus occupé.

Étape 3 : Reliez les catégories de benchmarks à des choix concrets

Voici une traduction qui aide réellement les achats et la planification de capacité :

• Benchmark mono-cœur : indicateur des goulots single-thread, sérialisation des requêtes, pauses GC, et « un verrou chaud ». Si c’est faible, ajouter des cœurs ne résoudra pas.
• Benchmark multi-cœurs de débit : indicateur pour jobs batch, services parallèles, et débit agrégé. Surveillez l’efficacité de scaling : doubler les cœurs vous donne 1.9× ou 1.2× ?
• Benchmarks mémoire : indicateur pour analytics, couches de cache, et toute charge avec grands working sets. Les scores CPU ne vous sauveront pas si vous êtes à court de bande passante.
• Suites applicatives mixtes : mieux que les microbenchmarks, mais toujours pas votre appli. Utiles pour décider si « ce CPU est dans le bon voisinage ».

Étape 4 : Refusez les comparaisons injustes

Une comparaison CPU équitable maintient constants :

• Population des canaux mémoire identique ; même vitesse et rangs de DIMM
• Même stockage et version du noyau
• Mêmes réglages BIOS de puissance et politique turbo
• Même famille de compilateur et flags (si pertinent)
• Même refroidissement et flux d’air du châssis
• Même mode de virtualisation (bare metal vs VM)

Si le graphique ne prouve pas la parité, supposez qu’elle n’existe pas. Ce n’est pas du cynisme ; c’est de la reconnaissance de motifs.

Playbook de diagnostic rapide : trouvez le goulot d’étranglement avant de débattre des CPU

Avant de vous disputer sur des deltas de benchmark, répondez à une question plus simple : le CPU est-il réellement votre goulot d’étranglement ? La moitié des incidents « il nous faut des CPU plus rapides » sont en réalité de la pression mémoire, de la latence stockage, de la contention sur les verrous, ou du throttling.

Première étape : le CPU est-il occupé ou juste ordonnancé ?

• Vérifiez l’utilisation CPU globale et la longueur de la file d’exécution.
• Vérifiez iowait et steal time (VMs).
• Vérifiez les hotspots par cœur (un cœur bloqué à 100 %).

Deuxième étape : le CPU est-il throttlé ?

• Cherchez des chutes de fréquence sous charge.
• Cherchez des événements thermiques ou de power cap.
• Vérifiez le gouverneur de performance.

Troisième étape : la mémoire est-elle le vrai limitateur ?

• Vérifiez les défauts de page majeurs, le swapping, et les stalls pour cause de pression mémoire.
• Vérifiez le déséquilibre NUMA et les accès mémoire distants.
• Vérifiez les symptômes de saturation de la bande passante mémoire.

Quatrième étape : la charge est-elle sérialisée ?

• Cherchez la contention sur les verrous, la saturation single-thread, ou un seul thread de processus très chaud.
• Vérifiez les métriques applicatives : profondeur des files, saturation des pools de threads, GC.

Cinquième étape : confirmez avec un micro-test contrôlé

• Exécutez un test CPU reproductible sur la même machine avec des réglages stables.
• Comparez fréquence, compteurs perf (si disponibles), et comportement de scaling.

Cette séquence vous évite d’« upgrader les CPU » pour résoudre un problème d’iowait. Oui, ça arrive. Sans cesse.

Tâches pratiques : 12+ commandes pour valider la performance CPU sur une machine réelle

Les benchmarks sur Internet sont des ouï-dire. Les mesures sur la machine sont des témoignages. Ci-dessous des tâches pratiques à exécuter sur des serveurs Linux. Chacune inclut : commande, sortie d’exemple, signification et décision à prendre.

Tâche 1 : Identifier le modèle de CPU, les sockets, cœurs, threads

cr0x@server:~$ lscpu
Architecture:                         x86_64
CPU(s):                               64
On-line CPU(s) list:                  0-63
Thread(s) per core:                   2
Core(s) per socket:                   16
Socket(s):                            2
NUMA node(s):                         2
Model name:                           Intel(R) Xeon(R) Gold 6338 CPU @ 2.00GHz
CPU max MHz:                          3500.0000
CPU min MHz:                          800.0000

Ce que cela signifie : Vous connaissez maintenant la topologie. Threads per core indique SMT/HT. Sockets + NUMA nodes indiquent que la localité mémoire compte.

Décision : Si vous comparez des graphiques, ne comparez qu’à des systèmes avec une topologie et des caractéristiques NUMA similaires. Si votre charge est sensible à la latence, planifiez des tests avec SMT activé/désactivé.

Tâche 2 : Vérifier la fréquence CPU actuelle et le gouverneur (la machine est-elle en « powersave » ?)

cr0x@server:~$ cpupower frequency-info
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  available cpufreq governors: performance powersave
  current policy: frequency should be within 800 MHz and 3500 MHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 1200 MHz

Ce que cela signifie : Si le gouverneur est powersave et que le CPU tourne à 1.2 GHz sous charge, votre « benchmark » est accidentellement une démonstration d’économie d’énergie.

Décision : Pour les tests de performance, définissez le gouverneur sur performance (avec gouvernance de changement et attention à la consommation/thermique).

Tâche 3 : Passer au gouverneur performance (temporaire, pour les tests)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que cela signifie : Le noyau privilégiera des fréquences plus élevées. Cela réduit la variance pendant les benchmarks.

Décision : Si votre politique de production est powersave, testez aussi dans ce mode. N’achetez pas un CPU basé sur un mode que vous n’allez pas utiliser.

Tâche 4 : Repérer le temps de steal de virtualisation (le « vCPU est occupé ailleurs » du cloud)

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.5.0 (server)   01/12/2026  _x86_64_  (64 CPU)

12:00:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
12:00:02 PM  all   45.20   0.00  7.10    0.40  0.00   0.30   8.50  38.50
12:00:03 PM  all   46.10   0.00  7.40    0.30  0.00   0.40   8.20  37.60

Ce que cela signifie : %steal est le temps où votre VM voulait du CPU mais l’hyperviseur ne l’a pas ordonnancée.

Décision : Si le temps de steal est significatif sous charge, arrêtez de blâmer le modèle CPU. Changez de type d’instance, migrez d’hôte, ou passez à du dédié/bare metal.

Tâche 5 : Vérifier la load average versus la saturation réelle du CPU

cr0x@server:~$ uptime
 12:01:10 up 32 days,  4:12,  2 users,  load average: 48.20, 44.10, 39.77

Ce que cela signifie : La load average compte les tâches exécutrices et certains états bloqués ; ce n’est pas le « pourcentage CPU ». Sur un hôte 64-vCPU, une charge d’environ 48 peut être correcte ou signe de contention selon les exigences de latence.

Décision : Croisez cela avec la file d’exécution et l’analyse par thread. N’achetez pas de CPU sur des captures d’écran de load average.

Tâche 6 : Observer la file d’exécution et les stalls de pression CPU (moderne, utile)

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=12.45 avg60=10.22 avg300=8.01 total=1234567890
full avg10=3.10 avg60=2.05 avg300=1.20 total=234567890

Ce que cela signifie : PSI rapporte le temps durant lequel les tâches attendaient le CPU. full signifie que le système était complètement saturé pour ces tâches.

Décision : Un PSI élevé sous trafic normal suggère une vraie contention CPU. C’est alors que les discussions sur l’upgrade CPU ou l’optimisation des charges deviennent rationnelles.

Tâche 7 : Identifier si votre « problème CPU » est en réalité iowait

cr0x@server:~$ iostat -x 1 3
Linux 6.5.0 (server)  01/12/2026  _x86_64_  (64 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.10  0.00    3.20   28.50    0.00   56.20

Device            r/s     w/s   r_await  w_await  aqu-sz  %util
nvme0n1         120.0   200.0     8.20    15.40   12.30   98.00

Ce que cela signifie : %iowait est élevé ; l’%util du disque est ~98 %. Vos CPUs s’ennuient en attendant le stockage.

Décision : Réparez la latence/queueing du stockage avant d’acheter des CPU. C’est le graphique préféré des ingénieurs stockage pour « prouver » que le CPU n’est pas le problème.

Tâche 8 : Confirmer les signaux de throttling thermique

cr0x@server:~$ sudo dmesg | grep -i -E "thrott|thermal|powercap" | tail -n 5
[123456.789012] CPU0: Package temperature above threshold, cpu clock throttled
[123456.789123] CPU0: Core temperature/speed normal

Ce que cela signifie : Le système a réduit les horloges CPU à cause de la température.

Décision : Si un CPU « sous-performe » par rapport à un graphique, vérifiez le refroidissement et les réglages d’alimentation avant de déclarer le CPU lent.

Tâche 9 : Mesurer la fréquence soutenue sous charge

cr0x@server:~$ sudo turbostat --quiet --Summary --interval 5 --num_iterations 3
Avg_MHz  Busy%  Bzy_MHz  PkgTmp  PkgWatt
2850     72.10  3950     83      205.30
2710     74.40  3640     86      205.00
2550     76.80  3320     89      205.10

Ce que cela signifie : À mesure que la température augmente, la fréquence effective diminue. Le CPU est power-capé (~205W) et thermiquement stressé.

Décision : Si vous avez besoin d’une performance prévisible, ajustez les limites de puissance, améliorez le refroidissement, ou choisissez un SKU avec un TDP adapté au châssis.

Tâche 10 : Vérifier la topologie NUMA et la localité mémoire

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-31
node 0 size: 257696 MB
node 0 free: 201234 MB
node 1 cpus: 32-63
node 1 size: 257696 MB
node 1 free: 198765 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

Ce que cela signifie : Accéder à la mémoire d’un nœud distant coûte plus cher (distance 21 vs 10). Certains benchmarks masquent cela en pinning optimal ; votre ordonnanceur peut ne pas le faire.

Décision : Pour les services sensibles à la latence, épinglez processus/threads et mémoire sur un nœud NUMA ou assurez-vous que l’application est NUMA-aware.

Tâche 11 : Observer la pression mémoire et le swapping (le CPU paraît lent quand la mémoire est en feu)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  3  524288  10240  1200  45000  200  180   900  1200 9000 15000 35 10  5 50  0

Ce que cela signifie : Swap in/out (si/so) et un iowait élevé signifient que le CPU attend du paging et de l’IO, pas qu’il calcule.

Décision : Ajoutez de la RAM, corrigez les fuites mémoire, ajustez les caches, ou réduisez le working set. N’achetez pas un CPU plus rapide pour compenser du swap lent.

Tâche 12 : Vérifier quels threads consomment réellement le CPU (trouver le thread unique chaud)

cr0x@server:~$ top -H -p 24811
top - 12:05:01 up 32 days,  4:16,  2 users,  load average: 48.20, 44.10, 39.77
Threads:  96 total,   1 running,  95 sleeping,   0 stopped,   0 zombie
%Cpu(s):  98.0 us,  2.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

  PID   TID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
24811 24837 app       20   0  5220m  1200m  32000 R  100.0   6.0  10:22.11 app-main

Ce que cela signifie : Un thread est saturé. Votre service peut être limité par un seul thread même sur une machine 64-vCPU.

Décision : Concentrez-vous sur le profiling et la réduction de la sérialisation/contention avant d’acheter plus de cœurs.

Tâche 13 : Valider le statut SMT/HT et envisager de le désactiver pour la latence

cr0x@server:~$ cat /sys/devices/system/cpu/smt/active
1

Ce que cela signifie : SMT est actif.

Décision : Pour les workloads critiques en latence, testez avec SMT désactivé (BIOS ou contrôles noyau), mesurez le p99. Le débit peut baisser ; la latence peut s’améliorer. Décidez avec des données.

Tâche 14 : Test de débit CPU rapide et sale (ce n’est pas une religion, juste un sanity check)

cr0x@server:~$ sysbench cpu --threads=32 --cpu-max-prime=20000 run
CPU speed:
    events per second:  1245.67

General statistics:
    total time:                          10.0003s
    total number of events:              12459

Ce que cela signifie : C’est un microbenchmark compute. Il est sensible à la fréquence et au comportement de l’ordonnanceur, pas à votre schéma de base de données.

Décision : Utilisez-le pour détecter « quelque chose ne va pas sur cette machine » (gouverneur, throttling, voisin bruyant), pas pour choisir un CPU pour des charges complexes.

Tâche 15 : Mesurer les compteurs de performance par cœur (quand vous avez besoin de preuve, pas d’ambiance)

cr0x@server:~$ sudo perf stat -a -- sleep 10
 Performance counter stats for 'system wide':

        1,234,567,890      cycles
          987,654,321      instructions              #    0.80  insn per cycle
            12,345,678      cache-misses
            98,765,432      branches
             1,234,567      branch-misses            #    1.25% of all branches

      10.001234567 seconds time elapsed

Ce que cela signifie : L’IPC est bas (0.80), des cache misses existent, le taux de branch mis est modéré. Cela suggère que la charge peut être sensible à la latence mémoire ou subir des stalls.

Décision : Si l’IPC est bas et les cache misses élevés, courir après un « meilleur score mono-cœur » peut aider moins que d’améliorer la localité mémoire, réduire l’empreinte cache, ou changer les algorithmes.

Tâche 16 : Confirmer que le noyau n’impose pas un comportement d’ordonnancement conservateur

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Ce que cela signifie : Le gouverneur est défini comme attendu.

Décision : Si votre exécution de benchmark est incohérente, éliminez la « dérive du gouverneur » et le mismatch de politique d’alimentation comme variables.

Blague #2 : Si votre benchmark a besoin d’un réglage BIOS spécifique pour être beau, ce n’est pas un test CPU — c’est une chasse au trésor.

Trois mini-récits d’entreprise tirés du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse (mono-cœur vs « plus de cœurs répare tout »)

Une société SaaS de taille moyenne a subi une régression de latence visible par les clients après un lancement de fonctionnalité. L’on-call voyait l’usage CPU flotter autour de 55–65 % sur leurs nœuds API. La direction a entendu « CPU un peu élevé », et les achats ont validé un type d’instance plus grand avec plus de vCPU. Deux fois plus de cœurs. Problème résolu, non ?

La première montée en production n’a rien fait. Le p99 est resté moche. Puis ça a empiré aux pics. Les instances plus grosses avaient une complexité NUMA supérieure et un comportement de boost légèrement inférieur sous charge soutenue. Leur chemin de requête le plus chaud comportait une étape sérialisée : un verrou autour d’une structure mémoire partagée protégeant un remplissage de cache. Sous contention, un thread devenait le métronome du service.

Quand ils ont finalement exécuté top -H et un profiling basique, l’histoire était évidente : un thread saturé, les autres cœurs attendant surtout des verrous, plus des pauses périodiques de l’allocateur. Ils n’étaient pas à court de CPU ; ils étaient sérialisés.

La correction était ennuyeuse : réduire la granularité des verrous, déplacer le remplissage de cache vers une coordination par clé, et limiter les stampedes de cache avec un coalesceur de requêtes. Après cela, le type d’instance d’origine gérait de nouveau les pics, et l’« upgrade » a été discrètement annulé.

Leçon : Si un graphique vend « plus de cœurs », confirmez que vous pouvez réellement les utiliser. La loi d’Amdahl reste invaincue en production.

Mini-récit 2 : L’optimisation qui s’est retournée contre l’équipe (speedup AVX lourd qui a déclenché du throttling)

Une équipe de plateforme de données interne a optimisé un pipeline de compression. Ils sont passés à une bibliothèque compilée utilisant des instructions vectorielles larges sur des CPU récents. Les microbenchmarks étaient fantastiques : débit en hausse, temps CPU en baisse, graphiques dans la bonne direction pour une promotion.

Puis le batch nocturne a commencé à rater sa fenêtre de complétion. Pas toujours — juste assez pour être rageant. Sur certains hôtes, les CPU chauffaient plus, atteignaient les limites de puissance, et se mettaient à throttler. Le code vectorisé augmentait la puissance du package, ce qui forçait une fréquence soutenue plus basse pour tout le socket. D’autres parties du pipeline, scalaires et branchées, ralentissaient suffisamment pour annuler les gains.

Pire, le comportement thermique variait selon le châssis et l’emplacement dans la baie. Des SKU CPU identiques se comportaient différemment selon le flux d’air. Le pipeline « optimisé » est devenu une loterie de performance, et l’on-call a appris à la dure la différence entre pic et soutenu.

La correction mixte combinait trois changements : limiter le parallélisme de la portion vectorielle, ajuster les limites de puissance pour correspondre à l’enveloppe de refroidissement, et garder un chemin non-vectorisé pour les hôtes incapables de soutenir les thermiques. Ils ont aussi changé les critères de succès de débit moyen à distribution des temps de complétion entre hôtes.

Leçon : Un gain de benchmark peut être une perte système. La vectorisation n’est pas gratuite ; c’est un compromis puissance/fréquence.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise (baseline et détection de dérive)

Une société financière exploitait une flotte de nœuds de calcul pour des calculs de risque. Rien de fancy — juste beaucoup de jobs CPU-bound avec des deadlines strictes. Ils avaient une habitude apparemment péniblement peu sexy : chaque nouveau nœud exécutait une suite de validation standardisée avant de rejoindre le cluster, et chaque trimestre ils la réexécutaient sur un échantillon de la flotte.

Un trimestre, les résultats ont dérivé. Pas catastrophiquement — juste assez pour que les temps de complétion augmentent progressivement. Parce qu’ils avaient des baselines historiques, ils ont pu prouver que ce n’était pas « la charge qui grossit ». C’étaient les machines qui se comportaient différemment.

Ils ont tracé cela à une mise à jour BIOS qui avait changé le comportement par défaut d’alimentation plus une mise à jour noyau qui avait modifié les gouverneurs par défaut sur cette build de distro. Le cluster n’était pas « des CPU plus lents » ; il était « des politiques différentes ». Ils ont rollbacké le réglage fautif, verrouillé les profils BIOS, et ajouté des alertes pour fréquence et événements de throttling.

Les deadlines ont cessé de glisser. L’équipe avait l’air paranoïaque les semaines calmes et prophétique les semaines chargées, ce qui ressemble à peu près à la description du job SRE.

Leçon : Les baselines sont ennuyeuses jusqu’à ce qu’elles soient la seule chose entre vous et un carnaval de blâme de plusieurs semaines.

Erreurs courantes : symptôme → cause racine → correction

1) Symptom : « Le benchmark CPU dit 30 % plus rapide, mais en prod rien ne change »

Cause racine : La charge est IO-bound ou sérialisée ; le CPU n’a jamais été le limiteur.

Correction : Vérifiez iostat -x, PSI, et la consommation CPU par thread. Améliorez la latence stockage, réduisez la contention sur les verrous, ou éliminez le goulot sériel avant d’upgrader les CPU.

2) Symptom : « Le nouveau CPU est rapide sur de courts tests, lent sur des runs longs »

Cause racine : Throttling thermique/power ; le turbo est beau pendant 30 secondes, puis la réalité arrive.

Correction : Utilisez turbostat pour observer les MHz soutenus et la puissance du package. Améliorez le refroidissement, ajustez les limites de puissance, ou choisissez un SKU dont la performance soutenue convient au châssis.

3) Symptom : « Le score multi-cœurs est excellent, mais la latence a empiré »

Cause racine : Contention SMT, jitter d’ordonnancement, ou file d’attente accrue due au débit plus élevé poussant des dépendances en aval.

Correction : Benchmarquez pour le p99, pas seulement le débit. Testez SMT désactivé. Appliquez du backpressure et équilibrage de capacité sur les dépendances.

4) Symptom : « Même modèle CPU, performances différentes selon les serveurs »

Cause racine : Différences BIOS, versions microcode, population mémoire, différences de refroidissement, ou dérive de politique d’alimentation.

Correction : Standardisez les profils BIOS ; vérifiez la population mémoire ; suivez le microcode ; basez une fréquence sous charge ; alertez sur le throttling.

5) Symptom : « Les benchmarks d’instances cloud varient énormément d’un jour à l’autre »

Cause racine : Voisin bruyant, steal time, hétérogénéité d’hôte, crédits de bursting, ou restrictions turbo.

Correction : Mesurez %steal, utilisez une location dédiée ou bare metal pour une performance cohérente, et exécutez des tests plus longs qui capturent le comportement de throttling/crédits.

6) Symptom : « L’utilisation CPU est faible, mais les requêtes sont lentes »

Cause racine : Threads bloqués sur de l’IO, des verrous, des défauts de page, ou des délais d’ordonnancement ; un CPU idle ne signifie pas que le service est sain.

Correction : Utilisez PSI (/proc/pressure/*), vmstat, et l’inspection par thread. Identifiez la ressource bloquante et corrigez-la.

7) Symptom : « Après une ‘optimisation’, le débit augmente mais le job rate manqué »

Cause racine : Un parallélisme accru a augmenté la contention, saturé la bande passante mémoire, ou créé des goulots en aval ; le système a déplacé la file, pas supprimée.

Correction : Réduisez la concurrence pour correspondre à la bande passante ; épinglez NUMA ; réévaluez avec des timings bout en bout et des métriques de profondeur de file.

8) Symptom : « Le benchmark A dit CPU X gagne ; le benchmark B dit CPU Y gagne »

Cause racine : Différents goulots et mixes d’instructions ; aucun des deux benchmarks ne correspond à votre charge.

Correction : Cessez de demander « quel CPU est le meilleur ? » Demandez « quel CPU est le meilleur pour mes contraintes ? » Exécutez une charge représentative ou des microbenchmarks proxys qui reflètent votre hot path.

Listes de contrôle / plan étape par étape

Checklist A : Lire un graphique de benchmark comme un adulte

1. Trouvez les conditions d’exécution : modèle CPU, BIOS, config mémoire, OS/noyau, compilateur, profil d’alimentation. Si manquant, diminuez la confiance.
2. Identifiez le goulot d’étranglement : calcul vs mémoire vs cache vs IO. Si inconnu, considérez le score comme non portable.
3. Vérifiez le comportement de scaling : la performance multi-cœurs scale-t-elle linéairement ? Si non, pourquoi ?
4. Cherchez le comportement soutenu : runs plus longs, fréquence stable, notes power/thermie.
5. Exigez la variance : runs multiples, barres d’erreur, ou au moins min/median/max. Si rien, supposez de la sélection de cas.
6. Mappez à votre charge : mono-thread, parallèle, lié à la mémoire, sensible à la latence, heavy virtualisation.
7. Traduisez en décision : choisissez un CPU pour votre goulot, pas pour le leaderboard.

Checklist B : Plan d’évaluation pré-achat de CPU (pratique, pas théâtral)

1. Notez vos 3 contraintes principales : latence p99, débit, coût par requête, temps de complétion, ou budget énergétique.
2. Choisissez 2–3 tests représentatifs : un micro (sanity), un proxy applicatif, un workload bout en bout (ou replay en staging).
3. Définissez des conditions de test stables : gouverneur, politique turbo, profil BIOS fixe, config mémoire cohérente, hôte isolé si possible.
4. Exécutez assez longtemps pour atteindre l’état stable : au moins 10–30 minutes pour capturer effets thermiques/power ; plus long si crédits/voisins bruyants existent.
5. Capturez : fréquence dans le temps, logs de throttling, PSI, file d’exécution, latence tail, et taux d’erreur.
6. Comparez en efficacité : performance par watt et par dollar, pas seulement score absolu.
7. Décidez avec votre lentille de goulot : si le mono-thread est le limiteur, priorisez le mono-cœur soutenu ; si batch parallèle, priorisez le scaling et la bande passante mémoire.

Checklist C : Validation post-déploiement (parce que l’achat n’est pas la fin)

1. Basez la nouvelle flotte : enregistrez lscpu, gouverneur, fréquence sous charge, et un petit test CPU standardisé.
2. Vérifiez le placement NUMA : assurez-vous que le service ne fait pas involontairement du remote-memory thrashing.
3. Alertez sur le throttling : événements thermiques/power, chutes de fréquence soutenue, et changements inattendus de gouverneur.
4. Surveillez le p99 en priorité : des gains de débit qui dégradent la latence tail sont des régressions déguisées.

FAQ

1) Un score mono-cœur plus élevé est-il toujours meilleur pour la latence ?

Non. C’est corrélé, pas causal. La latence est souvent dominée par des verrous, des cache misses, des appels système et du queueing. Un cœur plus rapide aide seulement si le chemin chaud exécute effectivement des instructions plutôt que d’attendre.

2) Ai-je besoin d’AVX-512 (ou d’autres vecteurs larges) pour des charges serveur ?

Seulement si votre charge l’utilise de façon significative : compression, crypto, certains analytics, inférence ML, média. Sinon c’est souvent un trophée sur la fiche technique. Considérez aussi le comportement puissance/throttling sous usage vectoriel lourd.

3) Pourquoi les classements CPU pour gaming ne prédisent pas la performance serveur ?

Les jeux sont souvent sensibles à la vitesse mono-thread et au comportement cache de façons très spécifiques, et le GPU domine souvent. Les serveurs se soucient du débit soutenu, de la latence tail, du NUMA, de l’IO et de l’overhead de virtualisation. Contraintes différentes, gagnants différents.

4) Combien de cœurs devrais-je acheter pour une base de données ?

Assez pour gérer la concurrence sans transformer le système en expérience de contention sur les verrous. Pour l’OLTP, la latence mémoire et le comportement cache comptent beaucoup ; pour les scans analytiques, la bande passante mémoire et le nombre de cœurs comptent davantage. Validez avec un benchmark représentatif, pas des graphiques génériques.

5) Quel est le plus gros signal d’alerte dans une comparaison de benchmark ?

Les conditions de test manquantes. Si vous ne connaissez pas la configuration mémoire, les limites de puissance, l’OS/noyau, et si l’exécution a atteint l’état stable, vous n’avez pas une comparaison — juste deux nombres.

6) Dois-je désactiver SMT/Hyper-Threading ?

Parfois. Le SMT augmente généralement le débit mais peut aggraver la latence tail pour les charges fortement en contention. Testez les deux options sous charge réaliste et décidez selon le p99/p999 et les SLO business.

7) Pourquoi mon CPU cloud « semble plus lent » que le même modèle on-premise ?

Parce que vous ne louez pas seulement un CPU. Vous louez l’ordonnancement, la politique d’alimentation, les voisins, et parfois un silicium d’hôte hétérogène. Mesurez le steal time, vérifiez les crédits de bursting, et exécutez des tests plus longs.

8) Les benchmarks synthétiques sont-ils inutiles ?

Non. Ils sont excellents pour détecter une mauvaise configuration (gouverneur powersave, throttling, mauvaise population mémoire) et pour un dimensionnement approximatif. Ils prédisent mal le comportement de votre application sauf si le benchmark ressemble à votre goulot.

9) Quelle est la bonne façon de comparer rapidement deux CPU ?

Exécutez la même charge représentative sur les deux sous les mêmes conditions, assez longtemps pour atteindre l’état stable, et comparez la latence tail et le débit par watt. Si vous ne pouvez pas faire cela, validez au moins le comportement de fréquence, le NUMA, et la parité de configuration mémoire.

Conclusion : prochaines étapes que vous pouvez réellement faire cette semaine

Si vous retenez une chose : les scores de benchmark sont des affirmations. Traitez-les comme telles. Demandez ce qui a été mesuré, dans quelles conditions, et si cela correspond à votre goulot. Puis vérifiez sur du matériel réel avec des commandes ennuyeuses qui se moquent du marketing.

Étapes concrètes

1. Choisissez un service de production et classifiez-le : mono-thread limité, parallèle, lié à la mémoire, lié à l’IO, ou mixte.
2. Exécutez les tâches 1, 2, 6, 7, 9, et 10 sur un hôte représentatif et enregistrez les sorties comme baseline.
3. Décidez votre métrique de succès (latence p99, temps de complétion, débit par dollar) et cessez de laisser le « score global » décider pour vous.
4. Lors de l’évaluation d’un achat de CPU, exigez une comparaison sous charge soutenue avec mémoire et politique d’alimentation identiques, ou ne prétendez pas faire de l’ingénierie.

Achetez des CPU pour le goulot que vous avez réellement, pas pour le benchmark que vous souhaiteriez avoir.