Analyse • Lunar Lake, ou le x86 plus efficient que jamais !

Des E-Core efficients, mais tout de même sacrément puissants

Comme nous vous le racontions à la page précédente, Lunar Lake a été conçu pour peu consommer et couper complètement ses P-Core en cas d’inactivité. De ce fait, les E-Core se doivent d’être complètement indépendant architecturalement (et dans leur circuit d’alimentation), ce qui explique la filiation de Skymont (la microarchitecture des E-Core de Lunar Lake) comme provenant des 2 LP-Core de Meteor Lake — ceux de la tuile SoC, et non des E-Core de cette même architecture — ceux collés sur la tuile de calcul. En revanche, cette deuxième option est toujours possible et sera très probablement employée pour Arrow Lake, ne vous faites pas de souci ! Cela permet en outre de comparer les gains en matière de consommation et de performances à une implémentation basée sur de l’Intel 7… au moins, cela a l’avantage d’être sémantiquement correct.

Architecturalement, ces progrès sont dus — une fois encore — à un travail combiné sur le front comme le back-end. Côté front, la prédiction de branchement prédit jusqu’à 128 octets en allant chercher un maximum de 96 instructions. Ce beau monde est confié à 3 décodeurs (contre 2 auparavant), qui permettent de casser les blocs d’instructions, par exemple suite à un branchement. De plus, la dépendance au microcode est supprimée en utilisant un mécanisme nommé « nanocode », qui n’est ni plus ni moins qu’un accès multiple au microcode par tous les décodeurs, évitant ainsi la sérialisation forcée. Enfin, la queue des µOps est aussi agrandie avec 96 entrées, qui atterrissent dans un ROB de 416 entrées (contre 256 précédemment).

1/2

2/2

Précédent Suivant

Côté back-end, contrairement à ce que l’on pourrait penser, Skymont contient en fait davantage de ports que Lion Cove : 26 très exactement. Cela s’explique par une spécialisation plus importante de ces derniers, ce qui permet de gagner en simplicité. Ces 26 ports se décomposent en :

• 8 ports d’exécution de calculs entiers (4 doublés)
• 3 ports de branchement (sauts)
• 3 ports de chargement
• 4 ports de stockage (2 entier, 2 vectoriel et flottant)
• 4 ports de calcul flottant (aiguillant vers des unités… SSE)

1/3

2/3

3/3

Précédent Suivant

Sur le papier, le sous-système flottant permet d’exécuter 4 FMA vectoriels SSE par cycle, soit un total de 16 FLOP/cycles. En revanche, il sera compliqué de les utiliser de cette manière, puisque seuls 3 ports de chargement 128-bit sont disponibles. Certes, il est possible de les faire fonctionner en AVX-2, ce qui monopolise 2 unités FMA 128-bit pour un FMA 256-bit (AVX2, quoi !), mais ne règle pas le souci ne permettant de charger qu’un total de 384 bit par cycle. Intel nous a confié avoir utilisé une telle répartition pour simplifier la tâche du scheduler, mais admet que le pipeline n’est pas totalement équilibré. Un choix d’autant plus étrange que des Xeon — Sierra Forest — feront également usage de ces E-Core sans modification (sans AVX-512 à fortiori). Certes, une partie des usages des data centers sont des tâches de type serveur web ou les flottants sont en écrasante minorité (et les bandes passantes des caches auraient dû être revues, ce qui aurait pris plus de silicium), mais il est difficile de ne pas y voir une occasion manquée de designer un CPU spécialement pour le machine learning, avec un front-end plus léger mais un débit et une densité démentiel - similairement aux grands principes de conception des GPU, en fait. La chose est d'autant plus étrange que Skymont est compatible avec les extensions VNNI pour le machine learning, portées en AVX2 !

Pour ce qui est de la mémoire, le L2 double (en prenant pour base les 2 LP-Core de Meteor Lake !) pour culminer à 4 Mio, mais de bande passante améliorée (128 octets par cycle, soit 32 octets/cœur : tout pile 2 chargements vectoriels 128-bit chacun). De plus, la cohérence de cache entre L1 de cœurs différent est améliorée pour être plus rapide, un bon point pour le multithreading. Côté TLB, ce dernier suit le L2 et passe de 3192 entrées à 4192, sachant que le L1-I conserve ses 64 kio, et le L1-D ses 32 kio. Basse performance consommation, on a dit !

Tout ce beau monde est bien difficile à évaluer niveau performance, car ces E-Core pourront, au choix, être utilisées comme des unités d’appoint des P-Core (pour Arrow Lake) ou comme des cœurs basse consommation dans un but d’autonomie maximale. Cela signifie que le design possède différents points d’utilisation sur la courbe vitesse/consommation, qu’il est difficile de comprendre dans la totalité au premier abord. Ainsi, par rapport aux LP E-Core, en monothread :

• La consommation est réduite de 66 % à isoperformance
• OU les performances sont améliorées d’un facteur 1,7 à isoconsommation
• OU la performance double, sans qu’Intel nous communique la consommation finale

Mais ce n’est pas tout ! En multithread, les cœurs affichent des gains encore plus faramineux, mais à 4 contre 2, le match est évidemment pipé… En revanche, en utilisation auxiliaire (c’est-à-dire sur les prochains Arrow Lake), le bousin affiche (par rapport à Raptor Lake — wouhou —, en monothread et calcul entier [en flottant, tout doit s’effondrer !]) :

• 40 % de gain en consommation à isoperformances
• OU 20 % de gains en performance à isoconsommation

1/3

2/3

3/3

Précédent Suivant

Ainsi, nous avons sur Lunar Lake des P-Core affutés pour de la performance single-thread entière et flottante, et des E-Core conçus pour une réduction maximale de la consommation en accélérant très efficacement les calcul entiers et les applications à flot de contrôle irrégulier, mais s’effondrant en charge flottante/vectorielle. Se pose alors la question du placement des threads sur ces unités… à laquelle Intel répond par Intel Thread Director, que nous étudions à la page suivante !