+50% de cache L2 sur les P-Cores Lion Cove d'Arrow Lake, une logique implacable ?

Tandis que les fuites affluent de plus belle sur les Core de 14e génération aka Raptor Lake Refresh, d'autres rumeurs plus intéressantes se font faire écho au détour des webs, et il s'agit cette fois d'Arrow Lake-S. Cette génération escomptée pour être la 15e génération de processeurs Core, et inaugurer la plateforme LGA 1851 au passage, est clairement attendue pour apporter un gap de performance plus enthousiasment que ce que nous observons depuis l'arrivée de la gen 12 / Alder Lake ; d'autant qu'il devra se fritter avec des Ryzen 8000 qui eux suscitent déjà de l'attente auprès du grand public.

Quoi de mieux pour aider à y parvenir, au-delà du nouveau node de gravure (Intel 20A), des nouveaux Lion Cove (pour les P-core) et Skymont (pour les E-core), qu'une augmentation significative du cache ? C'est en tout cas ce qui se profilerait si l'on en croit le cochon doré, colporté par twiX. Une supposition somme toute de bonne logique, puisque Raptor Lake-S voyait déjà son contingent de cache — 2 Mo par cœur Raptor Cove —augmenté de +60 % par rapport à Alder Lake — 1.25 Mo par cœur Golden Cove —, qui porterait ainsi la quantité de cache L2 sur les cœurs Lion Cove à 3 Mo. Soit un tout aussi massif + 50 % cette fois. Les cœurs Cypress Cove (gen 11) et avant lui Sunny Cove (gen 10) n'en avaient que 512 Ko.

Arrow Lake, c'est là

Mais au fait, il sert à quoi ce cache ? Un processeur, ce n'est pas qu'une histoire de puissance de calcul. Car pour calculer, le CPU doit avoir des données & instructions, et de fait doit y accéder entre ses calculs. C'est le rôle de ces zone de tampon où sont stockées les dernières variables utilisées ; on parle de cache L1, L2, L3, voire L4, où le chiffre indique littéralement la "distance" entre les transistors des cœurs et les transistors des caches, rendant leur accès plus ou moins coûteux en cycles d'horloges. On estime d'ailleurs qu'un CPU « perd » 10 à 30 % de son temps dans ses accès.

Ainsi, il faut ~deux fois plus de temps aux cœurs pour accéder au L1 par rapport aux registres processeurs, ~deux à trois fois plus de temps pour accéder au L2 par rapport au L1, ~dix fois plus de temps pour accéder au L3 par rapport au L1, ~30 fois plus de temps pour accéder à la RAM toujours par rapport au L1.

Pourquoi ne pas concevoir des puces avec des caches L1 ou encore mieux des registres nettement plus importants ? Entre autres, le coût en transistors bien sûr (et donc en complexité), le L1 et la plupart de temps le L2 n'étant pas partagés il sont propres à chaque cœur, et doubler leur quantité ne signifie pas pour autant doubler les performances, bien au contraire. Dans les architectures aux caches multicouches modernes, un gros cache L1 ne servirait pas à grand-chose, puisque dans les grandes lignes chercher une variable dans un L1 trop vaste serait presque aussi coûteux en latence... que d'aller dans la RAM. Sans parler du coût énergétique. Le L2 agit peu ou prou comme le L1 tout en étant plus facile à caser dans le package du CPU que ce dernier ; tandis que le L3, partagé entre tous les cœurs, fait office de pool de cache général.

Bref, revenons à nos moutons, d'autant que ces caches appartiennent peut-être déjà au passé. Faut-il voir dans cette augmentation potentielle du L2 un élargissement des ports d'exécution du back-end, ou plutôt — soyons fous — une unification des tuiles entre les segments grand public et les segments pro qui, on l'a déjà vu dans le passé avec Golden Cove par exemple livrés avec plus de L2  ? Ou rien de ces deux suppositions ? Et qu'en serait-il du L3 ? En attendant des réponses, un Meteor Lake-S / LGA 1851 s'est également retrouvé sous le feu des paparazzis, et donne une bonne idée de ce à quoi Arrow Lake va ressembler physiquement.. Sans grosse loupe pour voir dedans comment c'est fichu :