News Intel Arrow und Lunar Lake: Diese Befehlssatzerweiterungen unterstützen die neuen CPUs

[PCGH-Redaktion]

Jetzt ist Ihre Meinung gefragt zu 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.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: Intel Arrow und Lunar Lake: Diese Befehlssatzerweiterungen unterstützen die neuen CPUs

 

[Rollora]

was ist mit AVX 512?

 

[Locuza]

was ist mit AVX 512?

Sieht schwer danach aus, als ob das bei Arrow-Lake und Lunar-Lake nicht enthalten bzw. aktiv sein wird.

 

[latiose88]

vielleicht wollen sie es so machen wie bei AMD auf Basis von AVX2 wer weis.
Und alle diese genannten kennt bestimmt mein Programm nicht oder geschieht dies alles im hintergrund wie Maschinelles lernen usw Automatisch bei jedem Programm.Daten werden ja schlieslich auch beim Video verarbeitet oder ist das ein zu einfacher code wo diese nicht abdeckt oder beherrscht?

 

[Locuza]

vielleicht wollen sie es so machen wie bei AMD auf Basis von AVX2 wer weis.
Und alle diese genannten kennt bestimmt mein Programm nicht oder geschieht dies alles im hintergrund wie Maschinelles lernen usw Automatisch bei jedem Programm.Daten werden ja schlieslich auch beim Video verarbeitet oder ist das ein zu einfacher code wo diese nicht abdeckt oder beherrscht?

AVX512 ist ein "neues" Set an Befehlen bzw. Instruktionen, mit neuem EVEX encoding (definiert/ermöglicht 512b register/operationen, Mask Register, doppelt soviele Vektor Architekturregister und mehr).
Da gibt es sehr viele unterschiedliche Befehle und Möglichkeiten, was vielen Programmen hilft, Emulatoren (PS3, Switch, etc.), Multi-Media, Kryptographie und Spielprogrammierung, Deep Learning Anwendungen, etc..
AMD hat mit Zen 4 angefangen AVX512 zu unterstützen, dass kann man dabei nicht "auf Basis von AVX2" machen.
Was Intel tut ist effektiv Instruktionen "runter" zu porten.
Einige Befehle die mit AVX512/EVEX umgesetzt worden sind, haben später bzw. jetzt eine VEX-Variante (AVX1/2) bekommen, damit man (einige) nützliche Befehle auch auf den kleinen E-Kernen umsetzen kann, wo der ganze AVX512 "Ballast" zuviel wäre.
Die P-Cores unterstützen die neuen VEX-Befehle auch, damit man den gleichen ISA-Support bei beiden Kerntypen hat.

Programme müssen dabei explizit diese Befehle verwenden, automatisch, ganz ohne Update/recompiling, geht es nicht.

 

[latiose88]

ok verstehe,das sind ja nur neue Befehle,keine extra neue Einheiten.Das heißt es spielt keine Rolle wie viele neue Befehle dazu kommen,mehr Transistoren wird dazu ja nicht dazu kommen oder ist das bei Intel doch der Fall?

 

[Locuza]

ok verstehe,das sind ja nur neue Befehle,keine extra neue Einheiten.Das heißt es spielt keine Rolle wie viele neue Befehle dazu kommen,mehr Transistoren wird dazu ja nicht dazu kommen oder ist das bei Intel doch der Fall?

Diese Befehle sind keine reine Softwaresache, die Hardware muss diese umsetzen.
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.

 

[PCGH_Torsten]

Ein Problem könnte auch das Scheduling sein: Eine 4:1-Umsetzung von AVX512 (die technisch sicherlich auch nicht ganz so einfach ist) wäre sehr langsam und würde Teile des E-Kernes für untypisch lange Zeiträume blockieren und könnte ganze Programmabläufe durcheinander bringen. Eigentlich müsste der entsrechende Thread also immer vorausschauend auf einen P-Core verlegt werden, bevor AVX512-Befehle in nennenswertem Umfange ausgeführt werden. Aber so schnell muss das Scheduling erstmal reagieren können und vor allem braucht man erst einmal genug P-Cores dafür: Wenn ein Programm intensiven Gebrauch von AVX512 machen würde, weil die CPU Kompatibilität signalisiert, wären die E-Cores praktisch stillgelegt. Dabei kann es durchaus sein, dass die gleiche Aufgabenstellung in AVX2, aber auf viermal so vielen Kernen pro cm² Silizium sogar schneller abgearbeitet werden könnte. Nur sieht das Programm nicht, wie performant welcher Kern mit welchem Befehlssatz arbeitet und die CPU kann nachträglich nichts mehr ändern, wenn die Aufgabe einmal im falschen Befehlssatz gestellt wurde.

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".

 

[latiose88]

Ja mit der schlechten oder kaum bis garnicht vorhanden sein von avx 512, wird es auch mit den Programmen schwierig umzusetzen sein. Und mit alten aber fördernden Programmen sieht die Sache auch nicht viel besser aus. Mag zwar sein das ich ein Programm habe das 5 % bei avx 512 zu legt. Und das dank AMD wo esauf 2xavx 256 verteilt drauf reagiert hat. Besser wird es mit avx 512 darum ja nicht werden. Es sei denn ich hoffe auf ein Wunder. Aber da kann ich lange drauf warten. Denke mal so schlecht ist ja AMDs Lösung ja nicht oder doch?

 

[Rollora]

Sieht schwer danach aus, als ob das bei Arrow-Lake und Lunar-Lake nicht enthalten bzw. aktiv sein wird.

Weil wir geredet haben:

Intel Unveils AVX10 and APX Instruction Sets: Unifying AVX-512 For Hybrid Architectures

www.anandtech.com