Des P-Core Lion Cove au pipeline toujours plus large
Les rumeurs l’annonçaient, la chose est désormais officielle : les P-Core ont perdu leur HyperThreading. Ou plutôt, la version Lunar Lake de Lion Cove (la microarchitecture du P-Core) en est dépourvue.... ce qui ne signifie pas que toute la gamme en sera privée : l’idée de Lunar Lake — un SoC basse consommation concurrençant Arm/l’Apple M1 — est en fait arrivée 2 ans après le début de la conception de Lion Cove ; et a entraîné le passage en revue de tous les éléments aisément supprimables (une décision qui n’a rien d’un bricolage, mais qui est liée aux différences de temporalité dans les cycles de développement des produits). De fait, l’HyperThreading devient désormais l’un des outils des bleus pour fournir toujours plus de performances multithreadées, que nous risquons de retrouver cantonnée aux Xeons et, éventuellement, à Arrow Lake si la firme le juge pertinent — ce dont nous doutons à présent.
Car c’est bien sur cette question de la pertinence que la firme a fondé son choix : un hyperthread apporte quelques 30 % de gains en débit (IPC du cœur physique) pour 20 % de la consommation : chouette… dans la théorie. Dans la pratique des tâches grand public confiée à un ultraprotable, avoir plus de 4 threads actifs en une application reste un cas rare ; et la perspective de « se partager 130 % du cœur à deux » n’est pas si reluisante que cela lorsque le but est de maximiser la performance single-thread. Hé oui, dans ce cas, chaque thread n’a plus que 65 % de la performance du cœur sans HyperThreading : pas glop.
Ainsi, le géant bleu a jugé plus rationnel de limiter la plateforme Lunar Lake à 4 P-Core non hyperthreadés pour offrir un niveau de performance maximal tout en diminuant au plus la consommation sous contrainte de performance ; et tant pis pour le marketing et ses 8 cœurs logiques ! Sur une plateforme de bureau où 8 P-Core physiques sont déjà permis, pas sûr que l’HyperThreading ne survive non plus, pour les mêmes raisons… au prix des performances dans certaines tâches fortement parallélisables.
Fort heureusement, Lion Cove ne se limite pas à l'abandon de l'HyperThreading : le pipeline est entièrement revu, qu'il s'agit des capacités de calcul comme du front-end. Commençons par ce dernier : la prédiction de branchement est améliorée — un point crucial pour réussir à extraire assez d’instructions valides pour les donner à manger aux unités de calcul — en pouvant opérer sur les blocs jusqu’à 8 fois plus long. La bande passante du décodeur est également plus large (8 micro-instructions [ou µOps, prononcé « mu-op »], contre 6 sur Raptor Cove) tout comme le cache des µOps aperçus récemment, qui peut débiter 12 de ces µOps par cycle (contre 8 auparavant). Enfin, la file chargée de transporter tout ce petit monde au back-end (les unités d’exécution) est également plus profonde… sans savoir de combien. En revanche, le reorder buffer (endroit où patientes les instructions avant d’être assignées à un port, situé après une passe visant à optimiser en renommant les registres ou en supprimant certaines instructions triviales) compte 576 µOps contre 512 sur la génération précédente.
Justement, côté ports, il y a du changement. Leur nombre est même en explosion (18, contre 12 auparavant), du fait d’une raison simple : Intel est allé bigloucher du côté du voisin rouge, et sépare désormais son pipeline de calcul entier de celui flottant/vectoriel. Ainsi, 6 ports contrôlent les diverses unités entières, 4 ports sont devant les unités vectorielles, 2 ports s’occupent d’écrire dans la RAM et 6 s’occupent de la génération d’adresse et des chargements mémoires. Le tout propose une puissance de calcul maximale de 48 FLOP par cycles en FP32, qui se décomposent en 2 FMA (multiplication-accumulation) et 2 additions vectorielles AVX2, soit 6 opérations sur des vecteurs de 8 valeurs. Tout cela est cohérent avec la limite de 12 µOps pouvant finir (retire) simultanément en un cycle, ce qui permet de faire 3 fois la séquence load -compute-store. Attention cependant, car la limite de débit de l’étage d’optimisation (renommage/allocation) n’est que de 8 µOps, ce qui pourra freiner le débit si ce composant venait à saturer.
Côté sous-système mémoire, Intel fait maintenant apparaître un cache L0D de 48 Kio, probablement hérité des load et store queue, en accès direct des ports, capable de réaliser 3 chargements AVX-2 ou 2 chargements AVX-512 (qui, rappelons-le, n’est pas actif sur Lunar Lake) au moyen d’une latence de 4 cycles au chargement. À contrario, sur la génération précédente, le L1 était à 5 cycles… alors que le L1 explose en latence pour passer à 9 cycles, mais 192 Kio non-inclusif de capacité ; et une bande passante conservant les 2 vecteurs AVX-512 par cycle. Le L3 suit la même tendance avec 2,5 ou 3 Mio (par cœur, mais partagés) à 17 cycles de latence et une bande passante identique. Côté instruction, le L1-I affiche 64 kio et miss directement en L2 : une hiérarchie inchangée. Pour ce qui est du côté de la table des pages, chargée de faire la traduction entre l’espace d’adressage virtuel utilisé par les programmes et celui physique du CPU, le cache des pages de données (D-TLB) passe de 96 à 128 entrées, ce qui permet de nourrir le 3 unités de génération d’adresse (contre 2 unités auparavant).
Enfin, citons le passage d’une granularité plus fine dans la gestion de la fréquence d’horloge, qui passe de pas de 100 MHz à des pas de 16,67 MHz et un contrôle de cela par IA (pour le meilleur comme pour le pire !). Tous ces changements permettent à Intel de proclamer un gain d’IPC de 14 % à isofréquence par rapport à Meteor Lake. De plus, les P-Core sont complètement désactivés (leur système de gestion de l’alimentation coupe tout bonnement et simplement le jus) lorsque ces derniers sont inutilisés, ce qui permet un gain considérable en consommation — un fonctionnement déjà à l’œuvre chez Arm sur smartphone depuis un bon petit moment ! Dans ces cas-là, le boulot sera intégralement traité par les E-Core : direction page suivante pour découvrir leurs changements !
Tout cela est très intéressant
Ça peut paraître bizarre qu intel produit un cpu pas avec ça gravure
Le n3b est le die le plus efficient et le plus dense actuellement en plus intel est mauvais en transistors gpu ( haute densité ) voulant faire ultra compact et efficient c'est une bonne idée
A l'inverse le die soc en n6 me surprends
Pas besoin du n3b pour ce die il est ultra cher pour un gain très réduit ( les transistors hors ceux pour la logique progresse très peu voir quasiment pas vs le n5 )
Le n6 est "vieux" maintenant alors oui il est moins cher mais j'aurais plus vu n5 ou un de ses dérivé piur gagner en taille et en consommation
Bon après lecture approfondie j'ai l'impression que intel est revenue en arrière sur un point
Meteor lake avait explosé en mcm
La on revient comme avant Meteor lake le compute die intègre se qu'avait le die gen 13/14 et le second due c'est le chipset qui était côté
C'est la même chose mais emballé en 2.5d avec une nouvelle gravure
Le SMT s’avère surtout être une faille de sécurité perpétuelle, entre les fix et les patchs pas sur que ce soit vraiment une perte de performances de le virer 😅
Intel avec son lunar lake, qualcomm avec son xlite, amd machin truc et nvidia cpu machin truc... windows qui va devoir jongler avec les 4 ... Et tous les logiciels qui ne sont pas en natif et sans oublier tous les dell, asus et autre qui vont faire des variantes matérielles de leur ordinateur....
Quelle horreur la complexité des variantes et la fragmentation infinie que ça va engendrer et les bugs que Windows ne sait pas gérer...
Bonne chance pour que ça fonctionne sans accroche.... Faudrait songer à utiliser apple
Passez chez Apple, ils ont peu de variantes matérielle, ils créent leur propre puce, Ils font leur propre OS, tous les logicielles suivent Apple.
Amd et intel c'est du x86 donc pas de soucis et arm il y a emulateur apprement aussi performant que rosetta 2
Donc ça devrait aller
Apple ces gens qui décident arbitrairement quand ton ordinateur est obsolète en arrêtant de le mettre a jour, non merci 😬
Article beaucoup trop "technique" pour moi et mes maigres connaissances néanmoins je suis sûr que cela a fait plaisir à d'autres lecteurs qui ont du apprécier votre expertise et c'est bien là l'essentiel.
J'ai eu l'impression de relire certains articles de HFR !
C'était le bon temps hfr
J'avoue c'est complexe mais c'est aussi complet du coup
Après il y a les slides et les graphiques d intel plus simple à comprendre
Je ne cache pas que HFR ça a été notre référence et que c'est le type de contenu que nous visons. Le souci c'est qu'il faut vulgariser 20 ans de progrès hardware avant de lister les changements de la nouvelle génération ; dur dur pour quelqu'un qui débarque ! Cependant, avec un format récurrent expliquant certains mécanismes CPU peut etre une bonne idée pour pouvoir les référencer à divers endroits du dossier :-)
Moi jai compris les autres ..... 🤣