Zen 2 et Ice Lake embarquent une optimisation novatrice : le "renommage mémoire"

Un processeur, vous n’êtes sans le savoir, c’est compliqué. Caser plus de 1,75 milliard de transistors (pour un i7 Skylake quadcore), même amputés de la partie graphique, des contrôleurs USB/PCIe/RAM et du cache et lier tous ces bousins entre eux est source de nombreux choix et compromis. Néanmoins, et depuis une bonne dizaine d’années, les fabricants patinent de plus en plus pour trouver des solutions d’amélioration des performances de nos chers engins.

En effet, après avoir multiplié les cœurs, difficile de grignoter sans exploser le coût de production. Cependant, une analyse poussée du fonctionnement interne des derniers processeurs, à savoir Zen 2 chez les rouges et Ice Lake chez les bleus, a révélé la présence d’un nouveau mécanisme interne que l’on peut nommer Memory File. Qu’est-ce que cette sorcellerie ? Pour le comprendre, revenons à un peu plus haut niveau : pour accéder à des valeurs situées en mémoire, un CPU doit d’abord les stocker dans des registres avant d’effectuer ses opérations. Or, depuis le début des CPU x86 modernes (c’est-à-dire les premiers Pentium), ces registres ne sont plus des emplacements physiques distincts dans le processeur, mais sont tous sauvegardés dans un Register File, ce qui permet notamment d’implémenter en interne bien plus de registres que ce que le jeu d’instructions expose. Pourquoi cela ? Dans certains cas d’usage, le CPU peut ainsi augmenter le parallélisme — et donc l’IPC — lorsque différentes opérations utilisant les mêmes registres s’avèrent être tout de même exécutables en parallèle, typiquement lorsqu’un registre est réinitialisé pour une nouvelle utilisation, séparée de la précédente.

Comme si ça n’était pas déjà assez complexe ! (crédits : die de Nehalem, par Chip Architect)

Or, dans Zen2 et Ice Lake, les architectes ont également implémenté ce mécanisme pour la mémoire : si jamais vous stockez quelque chose à une adresse, la valeur semble en fait stockée d’abord dans un registre, afin d’être à nouveau accessible en un cycle sur un chargement futur. Bien entendu, si d’autres opérations de stockage sont effectuées entre temps, la valeur se retrouvera en cache, voire en RAM... par contre, lorsque seul du calcul se déroule, le Memory File reste inchangé. Cela semble toujours obscur ? Dans des manipulations complexes de passage de valeur par la pile (typiquement, des appels de fonction), l’opération peut diminuer le nombre de cycles d’un chargement-rangement de plus d’un facteur 4 ! Auparavant, les designs implémentaient bien déjà une Load Queue et une Store Queue, c’est à dire des buffers retenant les dernières opérations effectuées avant de les renvoyer en mémoire, ainsi que des ponts entre ces emplacements, mais les échanges restaient relativement coûteux. De plus, cet ancien mécanisme censé raccourcir les temps entre chargement et rangement pouvait avoir des effets contre-productifs sur les performances, du fait d’une latence d’accès à cette queue non nulle (de l’ordre de 4 cycles). Avec le Memory File, l’accès est gratuit, puisque directement accessible par le CPU : miracle ? Notez par contre que ces mémoires tampons ont été sujettes à certaines failles type Meltdown ; nous espérons donc très fortement que cet aspect ait bien été pris en compte lors de l’implémentation de cette heuristique. En outre, les adresses accédées sont également sujettes à spéculation, et la pénalité peut être grave : en cas de mauvaise spéculation, le processeur se bloquera pendant une durée de l’ordre de 40 cycles pour tout remettre en ordre! Enfin, il est fortement possible que ce Memory File partage en interne l’espace de stockage du Register File, celui-là même dont nous vous parlions un paragraphe plus haut.

Le plus amusant dans cette histoire reste le manque de communication des firmes à propos de cette avancée. Certes, le mécanisme ne fonctionne clairement pas dans 100 % des cas applicables (il faut que l’adresse source soit elle-même dans un registre, par exemple), mais la chose a un potentiel certain, surtout dans le cas d’ancien code produit par des compilateurs encore faiblement optimisant. Une bonne surprise, donc ? (Source : Agner Fog, dont la page d’accueil vaut le détour)