Ça n’est un secret pour personne, dans les processeurs modernes, c’est un sacré bordel. Agencer ensemble des dizaines de milliards de transistors n’est pas une mince affaire, si bien que des bugs se frayent parfois un chemin jusqu’au design final. Nous pouvons par exemple citer les extensions de mémoire transactionnel d’Intel, nommées TSX, buggées sur Skylake, ou encore le Loop Buffer qui s’est également retrouvés mis hors d’état de nuire sur cette même génération du fait de soucis de compatibilité avec l’Hyper-Threading sur des boucles courtes.
Hé bien, ce composant n’a pas fini de faire parler de lui, puisqu’AMD se retrouve à son tour à le désactiver, cette fois-ci sur les processeurs de la génération Zen 4 — la seule à en être pourvu. Est-ce catastrophique ? Dans les faits, très peu. Ce composant se situe dans la partie nommée front-end du CPU, celle chargée de récupérer et décoder les instructions. Comme son nom l’indique, le Loop Buffer est chargé de traquer les instructions des boucles de petite taille sous une forme facilement compréhensible par le processeur, évitant ainsi de redécoder et d’encombrer d’autres unités.
Si cela est bien beau sur papier, la chose est assez différente en pratique. D’une part parce que le bousin est peu documenté (seul un compteur de performance documente la chose dans l’entièreté des manuels d’optimisation de la firme), et que, selon AMD, l’optimisation permet surtout aux CPU de moins consommer dans certains cas bien spécifiques (et non d’augmenter directement ses performances). D’autre part parce que, comme nous vous le rapportions en introduction, les rouges ont silencieusement désactivé le composant quelque part entre l’AGESA 1.0.0.6 et la 1.2.0.2a.
Cela n’est pas suffisant pour nos confrères de Chips and Cheese, qui ont fait tourner quelques benchmarks pour se rendre compte de l’impact de la chose, et le couperet et tombé : sur SPEC CPU2017, les performances étaient en baisses de moins de 1 %, en monothread comme en multicœur. Sur Cyberpunk 2077, le constat est plus tranché avec des pertes allant jusqu’à 5 % de FPS en moins dans le cas où le jeu tourne sur un die dépourvu de 3D V-Cache (avec les performances sont quasi indiscernables), un chiffre explicable par le fait que le jeu tire en moyenne près de 22 % de ses instructions du buffer, lorsqu’il est actif. Néanmoins, dans la majorité des cas, le buffer global des instructions décodées (Op-Cache) est amplement suffisant pour nourrir le CPU en instructions, ce qui explique probablement le choix d’AMD de laisser glisser la chose sous la table. Quant à la raison première de la désactivation, difficile de penser à autre chose qu’un bug matériel, particulièrement vue l’ancienneté des processeurs impactés ! (Source : Chips and Cheese)
J'adore site qui sert de source les articles sont ultra complet
Il n'y a pas une erreur ? J'ai lu l'article et je pense que les 5% de fps perdu c'est quand le jeu tourne sur le cpu sans 3d vcache car avec il n'y a pas de perte
Wè.
Par contre si j'ai bien suivi l'article il serait GPU limited et il y aurait quand même une perte en 3D Vcache (1.25 IPC contre 1.07 sans le loop buffer).
Moi mauvais, c'est ce qui aurait eu du sens... Mais non, c'est bien la version sans V-Cache qui se retrouve ralentie. Mystère !
Par contre attention à l'IPC, ça peut être une mesure extrêmement trompeuse suivant ce qui est calculé, particulièrement dans des programmes multithreadés et avec le SMT activé :-).
Ben c'est ce qu'on disait, tu as même corrigé le billet 😅 Toi mauvais non, bien au contraire. Ca arrive juste de faire des erreurs. L'honnêteté intellectuelle est d'ailleurs quelque chose qui me plait ici. J'ai en tête un rédacteur sur un autre site (non pas le comptoir) qui, lorsqu'on signale une erreur ou émet un désaccord, coupe toute discussion, ne corrige rien, et attend patiemment que son billet soit enterré par des nouveaux.
Ma foi, je ne fais que relayer l'analyse de Chester Lam :
Ahah de rien, on corrige systématiquement ici :).
Pour l'IPC, j'avais fait un petit topo ici au temps du comptoir. Il est possible, comme le dit Chester, que l'augmentation de l'IPC fait que les calculs sont plus rapides, mais que le CPU attende simplement le GPU. Sans regarde exactement les instruction, l'information est difficilement interprétable, surtout dans une situation aussi complexe qu'un jeu multithreadé. Les changements de performances des cœurs peuvent modifier des synchronisations différentes et donc des chemin d'exécutions différents... Compliqué !
Je me demande d'ailleurs si le fait qu'autant d'instructions proviennent du loop buffer ne veut pas juste dire que le coeur passe son temps à attendre un signal, dans une boucle du type "tant que tu ne reçois rien, bah attend" ^^'.
Bon, même si l'optimisation n'est pas cruciale, sa désactivation a bel et bien un impact sur les performances de certains logiciels friands de boucles courtes (144 octets, ce n'est d'ailleurs pas si "court" que cela, et cela concerne beaucoup de boucles !).
Du coup, je suis moins étonné de certaines fluctuations que j'ai pu observer dans les performances d'un AGESA à l'autre dans certaines conditions, avec mon 7900X. Par exemple, avec le client OpenGL pour Second Life dont le moteur de rendu mono-tâche et plein de ces boucles est extrêmement sensible aux performances mono-coeur du CPU, ou encore lors de la compilation de gros logiciels (1 à 5% de moins se traduisent alors en quelque dizaines de secondes voire quelques minutes de temps de compilation en plus).
Certes, les AGESA successifs ont eux-mêmes apporté leur lot d'optimisations, qui ont parfois pu compenser cette perte de performance.
Néanmoins, ce manque total de transparence de la part d'AMD est inacceptable !
Pourquoi cette désactivation: bogue associé, vulnérabilité (dont je me bat les couilles vu l'usage mono-utilisateur de mon PC), ou simple flemme ?
Par ailleurs, pourquoi ne pas simplement avoir ajouté une option dans l'UEFI, à l'instar de ce qui se fait déjà pour une tripoté d'autres optimisations du CPU, et laisser le choix à l'utilisateur final de l'activer ou non ???
Ce genre de coup en douce à le don de m'horripiler !!! >:-(
Quand vous dites qu'il n'y à pas d'impact avec un processeur type "X3D" sur Cyberpunk2077 par exemple, vous voulez dire en 1080p, 1440p et 4K ? Puisque en dehors des 9000x3d, les gen 5000x3d et 7000x3d performent essentiellement en 1080p, peu en 1440p et rien en 4K.
En outre, est-ce que dans l'article que vous relayez/traduisez, ils supputent que derrière le discours officiel, on peut s'interroger sur la partie du cpu dont-il est question et l'ampleur des attaques dont sont victimes entre autre les processeurs grand publique depuis quelques années ?
Lorsque votre confrère parle d'un élément d'un cpu chargé d'analyser et rejeter le code non reconnu envoyé au processeur, ça fait pensé de près ou de loin, aux incessantes rustines, en particulier sur les processeurs AMD pour colmater les failles par laquelle des hackeurs tentent de passer ?