Comment le marketing déforme les « générations » : le « nouveau » CPU qui est en réalité ancien

Ce que « génération » signifie réellement (et pourquoi c’est flou)

En ingénierie, « génération » devrait impliquer une frontière architecturale significative : nouveau design de cœurs, nouvelle topologie de cache, nouveau
sous-système mémoire, nouvel interconnect, nouvel ensemble d’instructions, ou au moins un nouveau nœud de procédé avec de réels gains fréquence-par-watt.
En marketing, « génération » signifie souvent « il nous fallait une nouvelle histoire SKU pour le T3 ».

Le problème central est que la performance CPU n’est pas un nombre unique. « 10% plus rapide » est un fragment de phrase à moins que vous précisiez :
mono-thread vs multi-thread, soutenu vs rafale, limites de puissance, canaux mémoire, topologie NUMA, et le goulot de votre charge.
Un CPU peut être « nouveau » et se comporter comme l’ancien sous vos limites de puissance et de bande passante mémoire.

Si vous gérez des systèmes en production, traitez « génération » comme une étiquette peu fiable et exigez trois choses :
(1) la lignée microarchitecturale, (2) les changements de plateforme (mémoire, I/O, PCIe), et (3) la performance dans vos contraintes.
Tout le reste est du théâtre.

Comment le marketing déforme les générations : la méthode habituelle

1) Le rebranding : même silicium, nouvel emballage

La « nouvelle génération » la plus simple est un renommage avec de légers changements de binning. Parfois c’est littéralement le même die, parfois un
stepping refresh avec de petites atténuations ou ajustements d’alimentation. Le nom du produit change ; la microarchitecture non.
Votre charge ne prêtera pas attention au nouveau label. Votre outil d’inventaire d’actifs, si.

Les rebrands ne sont pas automatiquement mauvais. Ils peuvent améliorer la disponibilité, corriger des errata ou offrir un meilleur prix.
Mais si votre décision est « upgrader pour la performance », un rebrand est coupable jusqu’à preuve par benchmark.

2) La promesse « jusqu’à » : des maths turbo déguisées en certitude

Beaucoup de CPU « nouveaux » affichent des fréquences turbo maximales plus élevées, mais des fréquences soutenues par cœur similaires sous de vraies limites de puissance.
« Jusqu’à 5,7 GHz » a fière allure sur une fiche produit ; elle l’est moins à 2h du matin quand votre charge tout-cœurs bride le package,
atteint les contraintes PL1/PL2 et tourne aux mêmes fréquences tout-cœurs que la puce « ancienne ».

Si vous ne comparez que la fréquence de base ou le turbo max, vous faites essentiellement des benchmarks pour le département marketing.

3) Plus de cœurs, moins de marge par cœur

Ajouter des cœurs sans augmenter la bande passante mémoire, le cache ou le budget puissance déplace souvent le goulot au lieu de l’éliminer.
Vous pouvez vous retrouver avec plus de threads se battant sur les mêmes canaux mémoire et un p99 légèrement pire.
Le débit peut augmenter ; les services sensibles à la latence, non.

4) « Génération » de plateforme vs « génération » CPU

Les vendeurs aiment agréger le nom du CPU avec des changements de plateforme : nouveau socket, nouveau chipset, nouveaux I/O.
Parfois la plateforme est vraiment nouvelle alors que les cœurs ne le sont pas ; parfois c’est l’inverse.
Pour les SRE, les changements de plateforme importent car ils modifient les modes de défaillance : maturité du firmware, disposition des lignes PCIe, compatibilité des NIC,
particularités NVMe et comportement de distribution d’alimentation.

5) Le buffet de benchmarks : choisissez celui qui vous flatte

Le marketing choisit des charges qui mettent en valeur les forces du CPU : noyaux lourds en AVX-512, flags de compilateur spécifiques, ensembles de données en cache,
ou profils de puissance que personne n’exécute dans un datacenter partagé. Votre monde réel est plus désordonné.

Un CPU peut être réellement meilleur et pourtant ne pas être meilleur pour vous. Ce n’est pas philosophique. C’est de la physique plus le comportement de l’ordonnanceur
plus des stalls mémoire.

Blague n°1 : Un CPU « nouvelle génération » sans données de charge ressemble à un régime sans calories — vous serez quand même surpris par la facture.

Faits intéressants et contexte historique (court et concret)

• « guerre des MHz » (fin des années 1990–début 2000) : Les vendeurs vendaient la fréquence comme métrique principale jusqu’à ce que les différences d’IPC rendent les comparaisons MHz trompeuses.
• NetBurst vs IPC : Le Pentium 4 d’Intel poussait la fréquence mais perdait souvent face à des designs à fréquence plus basse et IPC supérieur dans le travail réel.
• Turbo n’est pas une promesse : Le comportement turbo dépend des limites de puissance, de la température et du courant ; la performance soutenue peut être très différente du « max turbo ».
• Les atténuations des spéculations ont changé la réalité : Les microcodes et atténuations noyau post-2018 ont déplacé les performances, surtout pour les charges intensives en syscall et la virtualisation.
• Le modèle « tick-tock » est terminé : La cadence prévisible (réduction de procédé puis nouvelle architecture) a cédé la place à des rafraîchissements plus irréguliers, rendant la notion de « génération » plus floue.
• NUMA est devenu plus visible : Avec l’augmentation du nombre de cœurs, les pénalités d’accès mémoire à distance comptent davantage, surtout pour les bases de données et caches en mémoire.
• La topologie du cache est devenue une caractéristique produit : Les designs avec de plus grands caches de dernier niveau partagés peuvent gagner sans « nouvelle » fréquence ni nombre de cœurs.
• Les générations PCIe ne sont pas cosmétiques : Passer de PCIe 3.0 à 4.0 puis 5.0 peut changer les plafonds de stockage et NIC même si les cœurs CPU sont similaires.
• Les canaux mémoire sont une limite dure : Un CPU avec plus de cœurs mais le même nombre de canaux mémoire peut devenir en pénurie de bande passante en analytique, stockage et virtualisation.

Ce qui change vraiment les performances : les parties qu’on ne peut pas ignorer

Lignée microarchitecturale : l’arbre généalogique compte

Si vous voulez savoir si le CPU est « essentiellement ancien », cessez de regarder le label de génération et commencez par la
microarchitecture et le stepping. La différence entre un nouveau nom et un nouveau design de cœurs, c’est la différence entre « on a fait bouger
l’aiguille » et « on a changé l’autocollant ».

Qu’est-ce qui compte comme changement significatif ?

• Améliorations du front-end (meilleure prédiction de branchement, décodage/dispatche plus large) : aide le code général et réduit les stalls.
• Améliorations du back-end (plus d’unités d’exécution, meilleur ordonnancement) : améliore le débit et réduit les bulles de dépendance.
• Changements dans la hiérarchie de cache (taille L2, slices LLC, latence) : souvent énormes pour les bases de données, les systèmes de build et tout ce qui a des jeux de travail chauds.
• Changements du sous-système mémoire (canaux, génération DDR, contrôleurs) : décisifs pour l’analytique, la densité de virtualisation et les workloads metadata-heavy de stockage.
• Changements d’interconnect (ring vs mesh, chiplets, fabric) : affecte la communication inter-cœurs et le comportement NUMA.

Limites de puissance : PL1/PL2 et le mensonge de la « fréquence de base »

En serveur, la performance soutenue est contrainte par les limites de puissance configurées et le refroidissement.
En poste de travail, c’est souvent contraint par des paramètres de carte mère qui ressemblent parfois à un défi.

Le « nouveau » CPU qui performe bien sur un site de tests peut tourner avec des limites de puissance permissives et un boosting agressif.
Dans votre datacenter, vous avez des budgets de puissance par rack, un flux d’air partagé et un firmware de gestion qui ne partage pas votre optimisme.
Mesurez ce que vous allez exécuter.

Bande passante et latence mémoire : où les CPU meurent en silence

Vous pouvez acheter plus de cœurs et être plus lent. Cela arrive quand la charge est liée à la mémoire et que le nouveau CPU accroît la contention.
Surveillez une augmentation des misses LLC, plus de cycles en stall et un plateau de scaling au-delà d’un certain nombre de cœurs.

Si votre chemin chaud touche la mémoire de manière aléatoire (bases de données, caches, métadonnées de stockage, nombreuses charges VM), le sous-système mémoire est
l’histoire de performance, pas le nombre de cœurs.

I/O et PCIe : votre « upgrade CPU » peut être en réalité un upgrade I/O déguisé

Parfois le CPU est correct et la plateforme est le gain : plus de lignes PCIe, une génération PCIe plus récente, meilleure bifurcation et
comportement IOMMU amélioré. Cela peut débloquer le débit NVMe, réduire la variance de latence et améliorer la performance NIC.

Mais n’appelez pas cela une victoire CPU. Appelez-la ce qu’elle est : une victoire plateforme. Cela change la façon dont vous planifiez la capacité et où vous dépensez ensuite.

Jeux d’instructions et accélérateurs : les gains sont conditionnels

De nouvelles instructions (extensions vectorielles, crypto, compression) peuvent être énormes si votre logiciel les utilise. Si ce n’est pas le cas, rien ne se passe.
Si votre build manque des bons flags de compilateur ou d’un dispatch runtime, vous avez acheté du silicium que vous n’exploitez pas.

Il y a aussi un angle fiabilité : pousser de nouveaux jeux d’instructions à travers une flotte peut révéler des problèmes de headroom thermique/puissance et
déclencher des baisses de fréquence qui surprennent les équipes habituées à des charges plus légères.

Virtualisation et voisins bruyants : vous avez benchmarké le mauvais univers

Plus votre environnement repose sur la virtualisation ou une densité de conteneurs élevée, plus l’ordonnancement, le placement NUMA et la pression mémoire
dominent. Un « nouveau CPU » ne corrige pas la surallocation. Il se contente de sur-allouer plus vite.

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

Guide de diagnostic rapide : trouver le goulot vite

Quand quelqu’un dit « le nouveau CPU n’est pas plus rapide », votre travail n’est pas de débattre. Votre travail est d’isoler le facteur limitant en moins d’une heure.
Voici l’ordre qui fonctionne en production.

Premier point : confirmez ce que vous avez réellement reçu

• Vérifiez le modèle, la version microcode, le nombre de cœurs/threads, les sockets et la topologie NUMA.
• Vérifiez si vous êtes sur le profil d’alimentation et la version de firmware prévus.
• Confirmez la vitesse mémoire, les canaux peuplés et si des DIMMs ont forcé un downclock.

Second point : déterminez si vous êtes CPU-bound, memory-bound ou I/O-bound

• CPU-bound : forte utilisation user CPU, faible iowait, fréquences soutenues élevées, faibles stalls mémoire.
• Memory-bound : utilisation CPU modeste mais IPC bas, nombreuses cache misses, cycles stalled élevés, saturation de bande passante.
• I/O-bound : iowait élevé, profondeur de file, latence stockage ; le CPU peut sembler « inactif » mais le service est bloqué.

Troisième point : faites correspondre la charge à la ressource

• Bouchon mono-thread ? Regardez le comportement boost par cœur, le pinning du scheduler et les limites turbo.
• Charge parallèle ? Regardez le placement NUMA, la bande passante mémoire et le trafic inter-socket.
• Axé stockage ? Examinez les interruptions, softirq, offloads NIC, la file NVMe, le comportement du système de fichiers/ZFS.

Quatrième point : testez avec un benchmark minimal et contrôlé

• Utilisez des microbenchmarks pour isoler CPU vs mémoire vs I/O.
• Puis lancez un benchmark de production représentatif avec la même configuration que votre déploiement.
• Enregistrez les limites de puissance, la version du kernel, le microcode, les réglages BIOS et le gouverneur.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les vérifications que j’exécute réellement quand un système « nouvelle génération » arrive et que quelqu’un attend des miracles.
Chaque tâche inclut : commande, ce que signifie une sortie typique, et la décision que vous prenez.

Task 1: Identify the exact CPU model, family, stepping

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|Vendor ID|Model:|Stepping:|CPU family'
Model name:                           Intel(R) Xeon(R) Gold 6338N CPU @ 2.20GHz
CPU(s):                               64
Thread(s) per core:                   2
Core(s) per socket:                   32
Socket(s):                            1
Vendor ID:                            GenuineIntel
CPU family:                           6
Model:                                106
Stepping:                             6

Signification : « Model/Stepping » est la piste vers la vraie révision du silicium. Le nom du modèle seul ne suffit pas.
Décision : Si la « nouvelle gen » est la même famille/modèle avec un petit stepping, attendez-vous à un changement incrémental sauf si la plateforme a changé.

Task 2: Check microcode version (mitigations and behavior can differ)

cr0x@server:~$ grep -m1 microcode /proc/cpuinfo
microcode	: 0x2c0002e0

Signification : Le microcode affecte les atténuations de spéculation, les cas limites du turbo et les errata.
Décision : Si vous comparez des CPUs, alignez microcode et mitigations du noyau sinon vous mesurez des différences de correctifs, pas des puces.

Task 3: Confirm kernel sees NUMA layout you expect

cr0x@server:~$ numactl --hardware
available: 1 nodes (0)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63
node 0 size: 257542 MB
node 0 free: 243110 MB

Signification : Un nœud unique est plus simple. Plusieurs nœuds signifient des pénalités mémoire distantes et le placement importe.
Décision : Pour les systèmes multi-socket ou à base de chiplets, appliquez un placement NUMA-aware pour DBs et JVMs, sinon votre « upgrade » devient trafic cross-node.

Task 4: Validate memory speed and populated channels

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Locator:|Size:|Speed:|Configured Memory Speed:'
Locator: DIMM_A1
Size: 32 GB
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s
Locator: DIMM_B1
Size: 32 GB
Speed: 3200 MT/s
Configured Memory Speed: 2933 MT/s

Signification : Des DIMMs notés 3200 mais configurés à 2933 indiquent un downclock (règles de population, DIMMs mixtes, BIOS).
Décision : Corrigez la population/vitesse mémoire avant d’accuser le CPU. Les charges liées à la mémoire bougeront peu avec des « nouveaux cœurs ».

Task 5: Check CPU frequency scaling governor

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

Signification : « powersave » peut être acceptable sur certaines plateformes serveur (il peut toujours booster), ou limiter la réactivité selon le driver/politique.
Décision : Si la latence importe, mettez le gouverneur en performance (ou assurez-vous que le firmware plateforme gère ça de manière prévisible) et retestez.

Task 6: Confirm turbo/boost capability is enabled

cr0x@server:~$ cat /sys/devices/system/cpu/intel_pstate/no_turbo
1

Signification : « 1 » signifie que le turbo est désactivé.
Décision : Si vous avez payé pour des bins de boost supérieurs, activez le turbo (si puissance/températures le permettent) ou arrêtez d’attendre des gains de « génération » en mono-thread.

Task 7: Watch real-time CPU and iowait under load

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

12:02:01 PM  CPU    %usr   %sys  %iowait  %idle
12:02:02 PM  all    72.10   6.20    0.10  21.60
12:02:02 PM   0    98.00   1.00    0.00   1.00
12:02:02 PM   1    96.00   2.00    0.00   2.00

Signification : %usr élevé avec iowait faible suggère calcul CPU ou stalls mémoire, pas stockage.
Décision : Si iowait est élevé, cessez de débattre de la génération CPU et allez regarder la latence stockage et le queueing.

Task 8: Check CPU throttling and thermal/power limits via dmesg

cr0x@server:~$ dmesg | egrep -i 'thrott|thermal|powercap|rapl' | tail -n 5
intel_rapl_common: Found RAPL domain package
thermal thermal_zone0: critical temperature reached (105 C), shutting down
CPU0: Core temperature above threshold, cpu clock throttled

Signification : Le throttling efface les gains de « nouvelle génération » et ajoute de la jitter de latence.
Décision : Réparez le refroidissement, les limites de puissance, les profils BIOS. Si vous ne pouvez pas, achetez moins de cœurs avec des fréquences soutenues plus élevées ou améliorez le flux d’air.

Task 9: Measure per-core frequency behavior during load

cr0x@server:~$ sudo turbostat --Summary --quiet --interval 1 --num_iterations 3
     Core     CPU Avg_MHz   Busy%  Bzy_MHz  TSC_MHz  IPC   PkgWatt
       -       -     980    68.2     1437     2200  0.72     165.4
       -       -     990    69.1     1432     2200  0.70     168.1
       -       -     975    67.5     1440     2200  0.73     164.9

Signification : Busy MHz vs turbo all-core attendu vous indique si des limites de puissance ou headroom thermique vous plafonnent.
IPC ~0.7 suggère stalls mémoire ou code branchy.
Décision : Si Bzy_MHz est bas, ajustez puissance/refroidissement. Si IPC est bas, concentrez-vous sur mémoire/cache/algorithme, pas la « génération » CPU.

Task 10: Check virtualization flags and nested virtualization assumptions

cr0x@server:~$ lscpu | egrep 'Virtualization|Flags'
Virtualization:                       VT-x
Flags:                                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon ... vmx ...

Signification : La présence d’extensions de virtualisation n’assure pas la performance ; le comportement EPT/NPT et les mitigations comptent.
Décision : Si votre « nouveau CPU » sous-performe en VM, vérifiez les mitigations du noyau hôte et l’exposition du modèle CPU dans la VM avant d’accuser le matériel.

Task 11: Inspect block device queueing and scheduler (I/O can masquerade as CPU slowness)

cr0x@server:~$ lsblk -o NAME,MODEL,ROTA,TYPE,SIZE,MOUNTPOINT
NAME        MODEL             ROTA TYPE  SIZE MOUNTPOINT
nvme0n1     SAMSUNG MZVL21T0     0 disk  1.8T
├─nvme0n1p1                     0 part  512M /boot
└─nvme0n1p2                     0 part  1.8T /

cr0x@server:~$ cat /sys/block/nvme0n1/queue/scheduler
[none] mq-deadline kyber bfq

Signification : NVMe utilise souvent « none » (ok), mais certaines charges bénéficient de mq-deadline.
Décision : Si la latence stockage est en pics et que vous voyez des files profondes, testez mq-deadline et mesurez le p99 avant d’optimiser le CPU.

Task 12: Check filesystem and mount options (especially for latency)

cr0x@server:~$ findmnt -no SOURCE,TARGET,FSTYPE,OPTIONS /
/dev/nvme0n1p2 / ext4 rw,relatime,errors=remount-ro

Signification : Les options de montage peuvent modifier le comportement de writeback et la latence. « relatime » est généralement OK.
Décision : Si votre « upgrade CPU » coïncide avec une réinstallation, validez que les montages n’ont pas changé (p.ex. barriers, discard) et n’ont pas déplacé la latence.

Task 13: Measure context switching and run queue pressure

cr0x@server:~$ vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 8  0      0 245100000 120000 8200000    0    0     1    12  920 18000 70  6 24  0  0
 9  0      0 245080000 120000 8200100    0    0     0     8  890 17650 72  6 22  0  0

Signification : Un r élevé par rapport au nombre de CPU suggère contention ; un cs élevé suggère overhead d’ordonnancement ou des timeslices trop courts.
Décision : Si la file d’exécution est élevée et que cs est massive, ajustez la concurrence et les pools de threads ; « plus de cœurs » ne résoudra pas une tempête de threads.

Task 14: Identify top CPU consumers and whether they scale

cr0x@server:~$ ps -eo pid,comm,pcpu,pmem,psr --sort=-pcpu | head
  9123 java            780.2  12.1  18
  1044 postgres        210.4   3.8   2
  2211 node            115.0   1.2  44

Signification : Un seul processus à plusieurs centaines de %CPU peut être limité par quelques threads chauds.
Décision : Si le plus gros consommateur est limité par un seul thread, concentrez-vous sur la performance par cœur, la contention de locks et l’affinité — pas seulement le nombre de cœurs.

Task 15: Check perf counters for stalls (cheap reality check)

cr0x@server:~$ sudo perf stat -a -e cycles,instructions,cache-misses,branches,branch-misses -I 1000 sleep 3
#           time             counts unit events
     1.000307907    12,345,678,901      cycles
     1.000307907     5,432,109,876      instructions
     1.000307907        98,765,432      cache-misses
     1.000307907       876,543,210      branches
     1.000307907        12,345,678      branch-misses

Signification : L’IPC est approximativement instructions/cycles. De gros cache-misses peuvent indiquer memory-bound.
Décision : Si l’IPC est bas et que les cache misses sont élevés, un « nouveau » CPU avec un sous-système mémoire similaire n’aidera pas ; privilégiez la localité de cache, NUMA et la vitesse mémoire.

Task 16: Validate PCIe link speed/width for NICs and NVMe (platform matters)

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16, ASPM L1, Exit Latency L1 <64us
LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)

Signification : Le périphérique est capable de PCIe 4.0 (16GT/s) mais tourne en PCIe 3.0 (8GT/s). Ce n’est pas un problème CPU.
Décision : Réglez le BIOS, changez les risers, le choix du slot ou le câblage avant de benchmarker la « génération » CPU. Sinon vous testez sur un lien rétrogradé.

Blague n°2 : Si votre lien PCIe s’est rétrogradé en Gen3, félicitations — vous avez inventé un mode « efficacité » que personne n’a demandé.

Trois mini-récits d’entreprise issus du pays du « ça devrait être plus rapide »

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne a renouvelé un lot de nœuds de calcul. Le bon de commande les qualifiait de « prochaine génération », et ce label
s’est glissé dans le modèle mental de chacun comme « plus rapide par cœur ». Le plan de déploiement supposait qu’ils pouvaient réduire le nombre de nœuds et conserver
les mêmes SLO. Les finances ont adoré. Les opérations ont toléré.

Le premier symptôme n’a pas été une panne spectaculaire. C’était pire : une érosion lente. La latence p95 de l’API a commencé à remonter, puis le p99 a
commencé à piquer les jours de déploiement. L’astreinte voyait l’utilisation CPU à 60–70% et a écarté une saturation. « On a de la marge. »
Pendant ce temps, les timeouts sur les appels downstream ont augmenté juste assez pour déclencher des retries, ce qui a généré plus de charge. Classique.

Quand ils ont finalement profilé les hôtes, l’IPC était bas et les cycles en stall mémoire élevés. La pièce « nouvelle gen » avait plus de cœurs, mais la
configuration mémoire était mauvaise : moins de canaux peuplés par socket en raison d’une substitution d’approvisionnement. La bande passante de pointe a chuté.
Sous l’ancienne flotte, ils étaient CPU-bound ; sous la nouvelle flotte, ils sont devenus memory-bound. Même code, physique différent.

La cause racine de l’incident n’était pas le modèle CPU. C’était l’hypothèse que « génération » implique un gain par cœur quel que soit le détail de la plateforme.
La correction a été ennuyeuse et efficace : corriger la population DIMM, valider la vitesse mémoire configurée et mettre à jour le modèle de capacité avec le débit mesuré par nœud.
L’étiquette « génération » n’est jamais apparue dans le postmortem. Elle n’aurait pas dû.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe stockage exploitait une flotte de nœuds faisant compression, chiffrement et checksumming. Ils ont migré vers un CPU commercialisé avec
de meilleures « accélérations AI » et des « capacités vectorielles avancées ». Le plan était d’exploiter ces fonctions : activer une compression plus agressive
et augmenter la taille des lots, en attendant un meilleur débit par watt.

Dans des tests synthétiques, c’était prometteur. Puis la production est arrivée avec des charges mixtes, de fréquentes petites écritures et des scrubs en arrière-plan.
La nouvelle configuration a causé des pics périodiques de latence. Les utilisateurs se sont plaints de « lenteurs aléatoires », la plainte la plus coûteuse à diagnostiquer
car elle ne s’aligne pas sur les tableaux de bord.

Le coupable était l’effondrement de la fréquence soutenue sous des instructions vectorielles lourdes combiné à des plafonds de puissance stricts dans le datacenter.
La puce pouvait aller vite en rafales, mais sous les nouveaux réglages optimisés elle restait dans un mode d’instructions énergivore assez longtemps pour se throttler.
Le débit n’a pas augmenté ; la latence tail s’est aggravée parce que le travail en arrière-plan concurrençait plus agressivement.

Ils ont annulé la politique de compression agressive, puis l’ont réintroduite sélectivement pour les écritures séquentielles larges où le gain de débit compensait le risque de latence.
La leçon : les gains liés aux jeux d’instructions sont conditionnels et peuvent déclencher des effets secondaires puissance/thermique.
« Nouvelle génération » ne veut pas dire « repas gratuit », mais « nouveaux compromis ».

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation a fait un rafraîchissement de la manière peu glamoureuse. Avant l’arrivée du matériel, ils ont défini un test d’acceptation spécifique à la charge :
trois microbenchmarks (CPU, mémoire, I/O) plus un benchmark de service représentatif sous une configuration proche de la production.
Ils ont noté les versions de firmware, le kernel, le microcode et les options BIOS. Ils ont traité le test comme un artefact de release.

Quand les premiers nœuds sont arrivés, le benchmark de service a sous-performé par rapport à la flotte précédente. Pas de manière catastrophique, mais suffisamment
pour échouer le seuil d’acceptation. Personne n’a argumenté. Le test a dit « non ».

Ils ont trouvé le problème rapidement : les réglages de bifurcation PCIe différaient de la config dorée, forçant les NIC à négocier à une vitesse inférieure.
Cela a augmenté la charge softirq et accru la latence des requêtes. Le CPU était innocent ; la configuration plateforme était coupable.
Parce que le test d’acceptation incluait un run de service lourd en réseau, le problème a été détecté avant le déploiement.

La partie « sauvé la mise » est la discipline ennuyeuse : comparer les systèmes avec firmware aligné, profils d’alimentation et gates d’acceptation mesurables.
Pas d’héroïsme, juste une checklist et la volonté de retarder un déploiement. Ce n’est pas excitant, mais c’est comme ça qu’on préserve les SLO.

Erreurs courantes : symptôme → cause racine → correctif

• Symptôme : La performance mono-thread inchangée après la « mise à niveau ».
  Cause racine : Turbo désactivé, gouverneur conservateur, ou limites de puissance plus strictes que la plateforme précédente.
  Correctif : Vérifier intel_pstate/no_turbo, le gouverneur, le profil d’alimentation BIOS ; retester avec des paramètres identiques et confirmer le boost soutenu avec turbostat.
• Symptôme : Débit multi-thread à peine amélioré ; utilisation CPU élevée mais IPC bas.
  Cause racine : Saturation de la bande passante mémoire ou accès mémoire NUMA à distance ; plus de cœurs ajoutent de la contention.
  Correctif : Valider les canaux et la vitesse mémoire, épingler les processus/NUMA, réduire les allocations cross-node, envisager moins de cœurs plus rapides ou plus de canaux mémoire.
• Symptôme : Latence tail pire sur le nouveau CPU sous charge mixte.
  Cause racine : Throttling thermique/puissance, tâches d’arrière-plan en collision avec le premier plan, ou chute de fréquence sous instructions vectorielles lourdes.
  Correctif : Améliorer refroidissement/limites de puissance, planifier le travail d’arrière-plan, ajuster la taille des lots et mesurer les clocks soutenus pendant la concurrence maximale.
• Symptôme : La pile stockage « semble plus lente », pourtant le CPU paraît inactif.
  Cause racine : Queueing I/O et latence : lien NVMe rétrogradé, ordonnanceur inadapté, ou valeurs par défaut du firmware modifiées lors de la réinstallation.
  Correctif : Vérifier la vitesse PCIe, la latence NVMe, la profondeur de file et l’ordonnanceur ; valider que les configurations de stockage/montage correspondent à l’ancienne flotte.
• Symptôme : Les workloads VM régressent malgré un « meilleur CPU ».
  Cause racine : Mitigations différentes, exposition du modèle CPU différente, différences de virtualisation imbriquée, ou placement NUMA dans l’hyperviseur.
  Correctif : Aligner noyau hôte/microcode, confirmer le type de CPU exposé aux VM, valider vNUMA et comparer pommes avec pommes en ressource dédiée.
• Symptôme : Les benchmarks montrent une amélioration mais la production non.
  Cause racine : Le benchmark tient dans le cache, utilise d’autres flags de compilateur, ou tourne à faible concurrence ; la production rencontre mémoire, verrous ou I/O waits.
  Correctif : Utiliser des datasets et une concurrence représentatifs ; ajouter des compteurs perf et des percentiles de latence ; traiter les benchmarks synthétiques comme des tests composants, pas comme critères d’acceptation.
• Symptôme : « Même génération CPU » se comporte différemment entre nœuds.
  Cause racine : Versions BIOS différentes, microcode, mixes DIMM, ou profils d’alimentation ; dérive firmware.
  Correctif : Imposer des configs de base, auditer avec automatisation et bloquer le déploiement en cas de dérive détectée.

Listes de contrôle / plan étape par étape (mise à niveau sans se nuire)

Étape 1 : Définir ce que « meilleur » signifie pour votre charge

• Choisir 2–4 métriques clés : latence p99, débit, coût par requête, watts par requête, temps de compilation, durée de requête.
• Choisir un scénario de production représentatif : même taille de dataset, même concurrence, mêmes tâches d’arrière-plan.
• Rédiger des seuils d’acceptation que vous êtes prêts à défendre.

Étape 2 : Normaliser l’environnement avant de comparer les CPU

• Même OS, kernel, politique microcode et réglages de mitigations.
• Même profil d’alimentation BIOS (performance vs balanced), même politique turbo.
• Mêmes règles de population mémoire et vitesse configurée vérifiée.
• Même firmware NIC et vérification de la vitesse de lien.

Étape 3 : Lancer une suite de triage par composants

• CPU : test soutenu tout-cœurs et test mono-thread ; vérifier clocks et comportement puissance.
• Mémoire : sanity check bande passante et latence ; vérifier pénalités NUMA.
• Stockage : tests séquentiels et aléatoires ; confirmer ordonnanceur I/O et comportement de file.
• Réseau : confirmer débit ligne, distribution IRQ et comportement softirq.

Étape 4 : Lancer le benchmark de service et capturer le contexte

• Collecter : résumé turbostat, compteurs perf stat, iostat et métriques clés du service.
• Enregistrer : versions firmware, réglages BIOS et toute déviation.
• Stocker les résultats comme artefacts ; ne comptez pas sur des captures d’écran dans un chat.

Étape 5 : Décider en fonction des goulets, pas du branding

• Si memory-bound : prioriser canaux mémoire, vitesse, cache et topologie NUMA plutôt que la « nouvelle génération ».
• Si I/O-bound : prioriser lignes/gen PCIe, configuration stockage/NIC et gestion des interruptions.
• Si CPU-bound : alors oui — la microarchitecture et les clocks soutenues importent ; vérifiez headroom puissance et refroidissement.

Étape 6 : Déployer avec garde-fous

• Nœuds canaris avec monitoring SLO et rollback automatique.
• Conserver la capacité de l’ancienne flotte jusqu’à ce que la nouvelle flotte se prouve sous pic.
• Bloquer l’expansion si une dérive firmware apparaît ou si les benchmarks d’acceptation régressent.

FAQ

1) Comment savoir si un CPU « nouvelle génération » est en fait un refresh ?

Regardez la lignée microarchitecturale et le stepping, pas seulement le nom. Vérifiez via lscpu et microcode/stepping, puis comparez
les tailles de cache, les canaux mémoire et l’I/O plateforme. Si la plateforme et le design des cœurs sont inchangés, attendez-vous à des différences incrémentales.

2) Pourquoi ma performance mono-thread n’a pas augmenté alors que le turbo max est plus élevé ?

Le turbo dépend des limites de puissance, des thermiques et de la politique. Si le turbo est désactivé, si le gouverneur est conservateur, ou si la plateforme
atteint rapidement des plafonds de puissance, vous ne verrez pas le boost annoncé. Mesurez avec turbostat sous la charge réelle.

3) L’IPC est-il une meilleure métrique que le GHz ?

L’IPC est plus informatif, mais seulement dans son contexte. L’IPC chute quand vous êtes memory-bound ou en cas de nombreux branch-misses. Un nouveau CPU peut augmenter l’IPC
sur des noyaux compute, mais pas sur votre charge à misses cache. Utilisez des compteurs perf et corrélez avec le comportement mémoire/cache.

4) Pourquoi plus de cœurs peut aggraver la latence tail ?

Plus de cœurs peuvent accroître la contention (verrous, caches, bande passante mémoire) et augmenter la concurrence en arrière-plan.
Cela peut augmenter le queueing et la jitter. Si vous vous souciez du p99, considérez « plus de cœurs » comme « plus de façons d’être bruyant » sauf si tout est réglé.

5) Quels changements de plateforme comptent plus que les cœurs CPU ?

Les canaux et la vitesse mémoire, la génération PCIe et la disponibilité des lanes, le comportement IOMMU et la maturité du firmware.
Pour le stockage et le réseau, une meilleure plateforme I/O peut constituer la vraie « upgrade », même si la performance des cœurs est similaire.

6) Comment benchmarker sans se mentir à soi-même ?

Utilisez une approche à deux couches : des microbenchmarks pour isoler les composants, puis un benchmark de bout en bout représentatif avec la taille de dataset et la concurrence proches de la production.
Enregistrez les réglages puissance/thermique et le firmware. Si vous ne pouvez pas reproduire un gain, il n’a pas eu lieu.

7) Les mitigations de sécurité sont-elles une raison légitime pour qu’un nouveau CPU semble plus lent ?

Oui, surtout pour les charges riches en syscalls, en changements de contexte et en virtualisation. Des microcodes différents et des réglages de mitigations noyau peuvent affecter la performance.
Alignez les réglages lors de comparaisons et décidez si la posture de risque permet d’ajuster les mitigations.

8) Quelle est la manière la plus rapide de décider d’acheter une pièce « nouvelle gen » ?

Ne décidez pas à partir des fiches techniques. Exécutez votre charge sur un nœud avec vos contraintes (puissance, refroidissement, config mémoire) et comparez
le débit par watt et la latence p99 avec votre flotte actuelle. Puis mettez le prix en regard de la capacité réellement gagnée.

9) Quand un rebrand vaut-il quand même l’achat ?

Quand l’approvisionnement, le prix ou la fiabilité s’améliorent et que la performance est « suffisante », ou quand les changements de plateforme résolvent un vrai goulot I/O ou mémoire.
Ne le justifiez pas comme un bond générationnel à moins que les tests le prouvent.

Conclusion : prochaines étapes pratiques

Les « générations » de CPU ne sont pas un contrat. Ce sont une histoire. Votre travail est de reconvertir l’histoire en mesures.
La façon la plus rapide de perdre de l’argent en infrastructure est d’acheter du compute pour résoudre un goulot mémoire ou I/O.

Prochaines étapes qui rapportent immédiatement :

• Construisez un test d’acceptation qui inclut turbostat + compteurs perf + votre benchmark de service réel.
• Standardisez les profils BIOS/puissance et imposez la détection de dérive firmware sur la flotte.
• Faites de la population DIMM et de la vitesse configurée une gate de release, pas un détail après-coup.
• Quand quelqu’un dit « nouvelle génération », répondez « montrez-moi les clocks soutenus, l’IPC et le p99 sous nos limites de puissance ».

Achetez du matériel pour des goulets que vous pouvez nommer. Ignorez le reste de la brochure. Votre rotation on-call remarquera la différence.