Vous ne le savez peut-être pas, mais les CPU ont des bugs. Ils sont généralement documentés par les fabricants — du moins ceux qui vendent leurs CPU, comme Intel ou AMD — et parfois corrigés. Et AMD a un bug particulier dans ses processeurs EPYC 7002 (l'équivalent serveur des Ryzen 3000) : le CPU peut ne plus répondre après 1 044 jours (un peu moins de 3 ans).
Les bugs sont courants
Les CPU contiennent des milliards de transistors et peuvent donc avoir des bugs. Pour les corrections, les fabricants ont trois choix : corriger matériellement le CPU avec une nouvelle révision, corriger de façon logicielle le problème avec du microcode ou ne rien faire. Le bug le plus célèbre est évidemment celui du Pentium, dans les années 90 : l'image d'Intel avait été sérieusement écornée à l'époque et avait remplacé les CPU défectueux par une nouvelle révision. Dans certains cas particuliers, les premiers Pentium pouvaient en effet donner une réponse inadéquate à un type de calcul précis, ce qui est évidemment un problème.
La correction par microcode, plus courante, consiste à passer par du code intégré dans le firmware (BIOS, UEFI, etc.) qui va prendre en charge les bugs. C'est une solution efficace si le bug est rare et n'arrive que dans des conditions extrêmement précises, étant donné qu'il peut y avoir une perte de performances.
Dans le cas du bug d'AMD, la marque indique que le problème ne va pas être corrigé, car le bug reste assez peu probable : même dans les serveurs, un uptime de pratiquement 3 ans demeure finalement assez rare (mais pas improbable). Qui plus est, un redémarrage reste nécessaire de temps en temps pour appliquer les corrections de bugs par microcode.
Un problème de temps
Maintenant, d'où vient cette valeur de 1 044 jours ? Probablement de la fréquence du CPU et d'un compteur, selon ce message sur Reddit. En effet, en prenant comme base la fréquence du TSC — Time Stamp Counter, le composant qui compte le nombre de cycles — et en supposant qu'il stocke le nombre de cycles dans une variable flottante en double précision, le nombre de jours est proche de la limite de la variable.
Vous n'avez rien compris ? Expliquons. Le compteur de cycle dépend généralement d'une fréquence de base, qui est souvent de 100 MHz dans un CPU moderne. Chaque cent-millionième de seconde, c'est-à-dire toutes les 10 ns, un compteur est incrémenté. Une variable flottante en double précision contient 64 bits, mais avec une structure particulière : 1 bit pour le signe (+ ou -), 11 bits pour l'exposant et 53 bits pour les données. Avec un compteur de ce type, il est donc possible de compter jusqu'à 9 007 199 254 740 989 (253). Maintenant, prenons ce nombre et faisons le calcul : avec un compteur incrémenté toutes les 10 ns, la valeur maximale est de 1 042 jours et 12 heures environ, un nombre très proche de celui annoncé par AMD. Une fois la valeur dépassée, le compteur repart probablement à 0, ce qui provoque une erreur.
Pourquoi est-ce qu'AMD parle de 1 044 jours et pas 1 042 ? Parce que comme l'explique le document de la marque, la valeur de référence (REFCLK
) peut varier légèrement en fonction des cartes mères. Si la fréquence de base attendue est de 100 MHz, elle peut être légèrement plus élevée1 ou plus faible pour des raisons matérielles et donc induire un léger décalage.
Notons enfin qu'Apple a probablement des bugs de ce type dans ses CPU, mais que la documentation n'est pas publique : ce qui se passe chez Apple reste chez Apple.
-
C'est une astuce assez courante pour grappiller une première place dans des benchmarks, en fournissant une fréquence un rien plus élevée que celle prévue. ↩︎