Tiger Lake également dans les mains d'Agner Fog : Intel a-t-il tenu ses promesses ? |
————— 29 Mars 2021 à 13h36 —— 11105 vues
Tiger Lake également dans les mains d'Agner Fog : Intel a-t-il tenu ses promesses ? |
————— 29 Mars 2021 à 13h36 —— 11105 vues
Après une apparition sur notre bar à l’occasion de son test maison du Ryzen 5800, voilà que le chemin d’Agner Fog, chercheur au Danemark de son état, croise une nouvelle fois celui du comptoir. En effet, suivant son accès aléatoire aux processeurs de « dernière » génération, c’est un Tiger Lake (non explicité) qui s’est retrouvé il y a quelques jours sur le banc de test ; une date finalement pas si mal tombée, puisque l’embargo des tests de Rocket Lake — dont les cœurs partagent la base commune de Sunny Cove — sera levé d’ici quelques jours.
Le meilleur, peut-être pas, mais un concentré de technologie, pour sûr !
En résumé, Intel a été correct dans ses annonces : le processeur permet effectivement d’effectuer deux chargements mémoires et deux rangements mémoires en parallèle, pour un nombre d'exécution de micro-ops (des blocs élémentaires issus des instructions x86) maximal de 5 (contre 6 sur Zen 3). Pour le front-end, l’histoire se répète, et les bleus n’ont pas réussi mieux que les rouges à outrepasser le goulot d’étranglement de x86 limitant la lecture du code assembleur à hauteur de 16 octets par cycle maximum (soit entre 4 et 8 micro-ops selon la complexité des instructions décodées).
Par contre, les bleus conservent un avantage sur les rouges en ce qui concerne le renommage mémoire — une optimisation dont l’intégration a justement été découverte par Agner —, qui reste bel et bien présent sur cette nouvelle fournée de processeurs, alors que le passage à Zen3 en avait eu raison chez les rouges. Mieux, sur Ice Lake et Tiger Lake, le processeur ne spécule même pas sur l’adresse concernée par les données, et ne sera ainsi inactive que si l’adresse n’est pas alignée, qu’un vecteur soit utilisé ou si l’adresse est calculée à partir du program counter ($RIP
sur x86).
Autre avantage : l’AVX-512 est bel et bien présent et fonctionne à pleine balle (notez des latences particulièrement faibles d’un seul cycle pour les opérations entières et 4 pour les flottants, inchangées par rapport au SSE ou l’AVX1/AVX2), mais au prix d’une fréquence possiblement en throttling afin d’éviter la surchauffe. De la bouche des bleus eux-mêmes, un code AVX-512 peut être plus lent que son homologue AVX2, néanmoins la popularité de cette extension devrait être croissante, autant dire qu’il vaudrait mieux miser sur son support si vous vous attelez à la conception d’un logiciel visant à durer dans le temps. Reste à voir la déclinaison pour PC de bureau - coucou Rocket, c’est bientôt à ton tour de faire la fusée !
![]() | Un poil avant ?ASUS aussi adopte le mini-ITX pour la RTX 3060 | Un peu plus tard ...Ventes de jeux vidéo : fin mars bien calme | ![]() |
|
Par rapport à cette news, j'étais très dubitatif sur l'argument du "cela a un coût en hardware donc il l'ont retiré". Et bien ces derniers jours AMD a publié un document en rapport à la sécurité (1) et update son "Architecture Programmer's Manual" pour parler d'une nouvelle optimisation nommé "Predictive Store Forwarding" (PSF) dans Zen 3.
Je rappel que le renommage mémoire c'est utile pour faire du Store-to-Load Forwarding (2) avec une latence très faible. Mais la version utilisé dans le Zen2 n'est pas très intelligente, elle tiens juste compte des noms de registre de l'adresse du load et du store: si ça match alors ils forward le Store vers le Load spéculativement.
La nouvelle optimisation de AMD dans Zen3 parle elle d'utiliser un mécanisme de prédiction pour déterminer si il faut forward un Store vers un Load. On ne connais pas bien le détail de ce que fait cette optimisation (à quel niveau est fait le forwarding et donc sa latence) mais pour sûr c'est en relation avec l'optimisation de memory renaming. Et je ne serais pas surpris de voir dans Zen4 ces deux optimisations réunis, ce qui réunirait à la fois du memory renaming et à la fois l'intelligence d'un prédicteur.
(1) security-analysis-predictive-store-forwarding.pdf
(2) Store-to-Load Forwarding: le Store-to-Load Forwarding ou Store Forwarding c'est une optimisation dont le principe est de rediriger la valeur d'un store vers les load à la même adresse avant que l'accès mémoire soit vraiment réalisé/terminé, ce qui permet de réduire la latence entre les Store et Load vers la même adresse