Intel Arrow und Lunar Lake: Diese Befehlssatzerweiterungen unterstützen die neuen CPUs
Für den Juni hat Intel ein Update seiner Architektur-Befehlssatzerweiterungen veröffentlicht, welches auch die zukünftigen CPU-Generationen Arrow und Lunar Lake berücksichtigt. Unterstützt werden etwa AVX-VNNI, SHA512, SM3, SM4 und LAM. Zudem hat Intel neue CPUIDs für den Raptor-Lake-Refresh ergänzt.
Der Raptor-Lake-Refresh wird dieses Jahr als 14. CPU-Generation für den Desktop erwartet. Wie es danach weitergeht, ist wie so häufig nicht gesichert, Intel hat aber nun Arrow und Lunar Lake im aktualisierten "Handbuch" der "Architecture Instruction Set Extensions and Future Features" erwähnt. Mit diesen Desktop-CPU-Reihen, beginnend mit Arrow Lake 2024, wird es dann voraussichtlich weitergehen, während Meteor Lake auf mobile Umgebungen beschränkt sein soll.
Arrow und Lunar Lake mit Unterstützung gewisser Befehlssatzerweiterungen
Intels aktualisierte Dokumentensammlung für die Befehlssatzerweiterungen legt nun also dar, welche von diesen durch Arrow und Lunar Lake unterstützt werden. Videocardz hat die entsprechende Tabelle aus dem fast 200 Seiten langen PDF herausgepickt und die Befehlssatzerweiterungen festgehalten. Zuerst wäre da AVX-VNNI, die auch eine gewisse Bedeutung hat. Diese Befehlssatzerweiterung soll die Leistung von Inferenz-Workloads neuronaler Netzwerke verbessern, indem sie eine spezielle Funktion für 8-Bit- und 16-Bit-Integer-Operationen bereitstellt. Dies heißt also, dass Anwendungen, die künstliche Intelligenz, maschinelles Lernen und Deep-Learning-Algorithmen nutzen, mit einer Steigerung der Verarbeitungsgeschwindigkeit und Effizienz rechnen können.
Auch interessant: Intel Core Ultra: Kommt Meteor Lake-S doch noch durch die Hintertür?
Ebenso wie die Prozessor-Familien Sierra Forest und Grand Ridge für andere Anwendungszwecke bekommen Alder und Lunar Lake auch Unterstützung für Linear Address Making (LAM). Damit ließen sich nicht übersetzte Adressbits von linearen 64-Bit-Adressen für Metadaten nutzen. Erwähnt werden überdies die Befehle SHA512, SM3 und SM4, die die Sicherheits- und Verschlüsselungsfähigkeiten der CPU-Serien der nächsten Generationen verbessern sollen.
Quelle: Intel
Befehlssatzerweiterungen für Arrow und Lunar Lake.
Alle weiteren Neuigkeiten bei den Befehlssatzerweiterungen sind im Intel-Dokument (auf den PDF-Seiten 20 und 21) farblich unterlegt und so leicht nachzuvollziehen. Intel hat letztlich noch weiter CPUIDs für zukünftige Prozessoren der Raptor-Lake-Mikroarchitektur hinzugefügt, was den Refresh-Release dieses Jahr weiter bekräftigen würde.
Quelle: Intel via Videocardz
[Ins Forum, um diesen Inhalt zu sehen]
Aktuell scheint Intel wohl der Meinung zu sein, dass "gar kein AVX512" in der Mehrheit der Anwendungsszenarien die bessere Wahl ist. Respektive man integriert die Befehle, die doch sinnvoll erscheinen, einfach in neue 256-Bit-basierte Befehlssätze – "AVX512" als solches gibt es ja sowieso nicht, sondern meinem Wissen nach mittlerweile rund ein dutzend verschiedene Zusammenstellungen mit 512-Bit-Befehlen, die sich zwar alle überlappen, die aber nicht identisch sind. Da ist es dann vermutlich auch aus Entwicklersicht unattraktiv, irgendeine Inkarnation vollständig auszureizen und stattdessen sollte man sich einzelne Kommandos rauspicken, die für den jeweilien Use-Case wirklich Sinn ergeben. In Anbetracht dessen, dass selbst für die Sierra-Forest-Xeons bislang kein Support bekannt ist, sind das aber wohl öfters "gar keine".
Abseits von ein paar sehr langsamen Implementierungen und praktisch der Emulation über Microcode, werden viele Befehle über neue Hardware und Verschaltungen verwirklicht, was dann auch (deutlich) mehr Transistoren benötigt.
Je nachdem wie man es macht, kommen auch mehr (ganze) Recheneinheiten ins Spiel.
Z.B. wenn man 512b Operationen in einem Zyklus unterstützen möchte, dann braucht es doppelt soviele Execution Units gegenüber 256b Ops.
Intels Server-Produkte haben logisch gesehen an Port 5 eine extra 512b Unit.
Der Support für AVX512 zieht sich aber durch den ganzen Kern, auch bei den normalen Client-Cores.
Denn für AVX512 (was auch die Client-Cores in HW unterstützen), hat Intel die Datenpfade zu den Caches verdoppelt, auch die Shuffle Unit wurde auf 512b erweitert.
Das frisst alles extra Transistoren.
Das Dumme ist nun, dass Intel kein AVX512 auf den E-Cores in der HW unterstützt, entsprechend schaltet man es auch auf den P-Cores ab, damit der Befehlssatz zwischen beiden gleich bleibt.
Jetzt war die Frage, ob irgendwann der Tag kommt, mit neuen Fertigungsknoten und Shrink, wo Intel AVX512-Support auch zu den E-Cores bringt?
Zumindest kann man das nun höchstwahrscheinlich für Meteor Lake, Arrow Lake und Lunar Lake verneinen.
Falls AVX512 umgesetzt wird, dann in/nach 2025.
Im Zweifel ist es auch gar nicht sooo teuer, AVX512 zu unterstützen, man könnte es auch (sehr) langsam umsetzen.
Anstatt 512b Register zu verbauen, könnte die HW auch einfach entsprechend mehr 128b oder 256b Register reservieren.
Genauso könnte man 128/256b EUs 512b Befehle über mehrere Zyklen abarbeiten lassen, AMD macht das mit Zen 4.
Zen 1 hatte auch nur 128b Register und EUs, dabei aber 256b AVX1/2-Befehle unterstützt.
Aktuell sind die E-Kerne auf 128b auf der FPU-Seite ausgelegt, die Brücke bzw. die Kompromisse für AVX512 sind vielleicht zu krass aus Intels Sicht und vielleicht möchte man sich auch nicht ein Upgrade auf 256b leisten.