News Intel AVX10.2: Intel Core alias Nova Lake bekommt neue Zusatzinstruktionen

[TechFA]

@Volker Deine Tabelle im Artikel ist seit einigen Monaten nicht mehr aktuell, da Intel im März die Unterstützung für optionale Gleitkomma-Integer bei AVX10.1 hat fallen lassen (512 FP/int).

So sah es bisher aus …

Und so mit der Revision v3.0 seit jetzt März 2025;

Intel hat ihr Technical Whitepaper revidiert, v3.0 führt kein optionales 512 fb/int mehr …

Revision	Number Description Date	Date
1.0	Initial release of the document.	June 2023
2.0	Updated Section 1.2, “Introduction to Intel® AVX10,” to remove the 32-bit mask register limitation.	December 2023
3.0	Removed references to 256-bit maximum vector register size, enumeration of vector-length support, and 256-bit instructions supporting embedded rounding.	March 2025

Intel – The Converged Vector ISA: Intel Advanced Vector Extensions 10 [Intel-AVX10-Technical-paper.pdf]
Phoronix.com – Intel AVX10 Drops Optional 512-bit: No AVX10 256-bit Only E-Cores In The Future

 

[Volker]

Richtig. Die hatte ich sogar schon hochgeladen gehabt, aber nicht eingebunden ich Depp.
Danke!

 

[fdsonne]

AMD erzielt mit einer Architektur und einem logischen Design, aber unterschiedlichen Silizium-Implementierungen (taktoptimiert vs flächenoptimiert) einen ähnlichen Effekt wie Intel mit zwei verschiedenen Designs. Es ist offensichtlich, dass sich AMD da einiges an Entwicklungskosten und Scheduling-Komplexität sparen kann.

Der Flächenbedarf bei AMD ist aber um ein vielfaches Größer. Dass das "ähnlich" sein soll, kann man so auch nicht sagen.
Gemessen am alten Design kommen 4xE-Cores auf die Fläche eines P-Cores mit SMT. Die neuere E-Core Generation die aktuell im Umlauf ist, ist meine ich im Verhältnis leicht größer.
Bei AMD hingegen sprechen wir nicht über 4x vs. 1x sondern über 35% Flächenreduktion, weil man primär einfach die Transistoren dichter packt und das obenraus dann maximal Takt kostet, den man im Powerlimit aber eh nicht ausfahren kann.

Nichts desto trotz ist der AMD Ansatz nicht unbedingt schlechter, aber in manchen Punkten auch nicht wirklich besser. AMD hat gerade im Mobile Markt auch Endprodukte im Programm, da ist das sogar eher hinderlich den Takt derart hart einzugrenzen. Die 4+6 und 4+8C APUs bspw. sind da oben je nach Last schon nicht zwingend Powerlimitiert, sondern eben Taktlimitiert durch die C-Cores.

 

[latiose88]

Ja dank AMD kostet avx 512 keine Leistung mehr weil zuvor war das immer bei mir gewesen. Allerdings Gewinn davon habe ich dennoch nicht obwohl die Software mit avx 1 und 2 umgehen kann . Allerdings scheint AMD was getan zu haben weil das es ein plus gibt ist seid Zen 4 so . Bei Zen 3 war das Verhalten nicht so . Ich weiß das meine Anwendung mmx und sse Anwendung ist. Aber bisher sobald ich avx überhaupt mal eingeschaltet hatte kostete es was . Sobald es dann aufwendiger Sachen waren brachte das allerdings wiederum plus bei avx ein .
Das hat sich ja seid Zen 4 grundlegend geändert und ist nun deutlich besser als vorher . Durch Zen 5 war avx so dermaßen gut gewesen das es sogar in der Hinsicht mit einem threadripper mit halten konnte der eingeschränkt unterwegs war .
Wenn man allerdings threadripper voll Ausfährt dann rennt der richtig los und überrundet ryzen sogar .
Das ich das nicht nutzen kann ,da kann ja threadripper nix dafür . Ich bin überzeugt das Intel damit einen richtigen Weg geht und bin gespannt wie gut es bei Intel so funktionieren wird . Von daher Intel hat gute Chancen es AMD gleich zu tuen aber es kann auch noch schiefgehen . Das wird sich noch zeigen .
Zumindest der kleine boost finde ich ne gute Sache . Damit habe auch ich nutzen davon . Es ist also in unserem Interesse das Intel das durch Ziehen wird.

Ergänzung (7. August 2025)

ich hab das avx512 schon in handbrake aktiviert geschwindigkeitsvorteil hmm unter 5%
deswegen auch mehr als zwei hände

OK das überrascht mich sehr wie wenig plus das bei Handbrake ist. Und dabei ist das die beste optimierte Software in dieser Hinsicht . Schafft dennoch nicht mehr als 16 kerne und dazu bei avx 512 so wenig .
Nun ja hängt zudem auch ab wie aufwendig das Video ist . Mit 4k oder noch mehr und alles andere ,da wird avx mehr ne Rolle spielen . Da bin ich mir sicher für die Zukunft .

 

[stefan92x]

Bei AMD hingegen sprechen wir nicht über 4x vs. 1x sondern über 35% Flächenreduktion

Das stimmt, aber auch bei Intel sind wir mittlerweile weit weg vom 4:1 Verhältnis und nähert sich langsam dem Zustand bei AMD an. Da muss man dann irgendwann schon die Sinnfrage stellen, wenn Intel mit den E-Cores so weiter macht.

 

[SweetOhm]

Sorry, bin aktuell nicht ganz auf der Höhe: Aber wo steht jetzt, dass es schon für Nova Lake und damit auch für die E-Cores kommen soll?

"Soweit ist dies aber keine neue Erkenntnis. Die Unterstützung von AVX10.2 soll sowohl für die nächste Generation der E-Kern-Xeons (Clearwater Forest) wie auch der P-Kern-Xeons (Diamond Rapids) bereitstehen.


Neu ist die Nennung der Unterstützung von AVX10.2 für die zukünftigen Desktop-Prozessoren alias Nova Lake."

https://x.com/InstLatX64/status/1953173338911850991

In dem Tweet wird von future INTEL Core Processors gesprochen/geschrieben. Also Nova Lake.

 

[pioneer3001]

Die Bezeichnungen AVX10.1 und AVX10.2 sind genau so blöd wie AVX-512. Man hätte das schlicht AVX3/4/5 nennen können. Und die Frage ist was AMD mit diesen dummen Bezeichnungen anfangen soll. Sollen die jetzt etwa auch AVX10.1 und AVX10.2 raus bringen, weil Intel nichts gebacken bekommt? Und selbst bei Bezeichnungen versag Intel die für alle x86-Hersteller geeignet wären. Wie ich immer sage: Charakter ist nicht heilbar.

Ich fände es gut, wenn AMD Intel ordentlich aufs Maul geben würde als Antwort indem sie selbst ein AVX3 raus bringen, das dann 1024 Bit breit ist und doppelt so viele Register hat wie jetzt.

Anderer Trick: Intern könnte AMD 1024 Bit breite ALUs verwenden. Denn so weit ich weiß kann jeder CPU-Kern bislang nur zwei 512-Bit-Register zur gleichen Zeit verrechnen, obwohl es 32 von denen gibt (zmm0 bis zmm31). Man kann während dessen die anderen Register nur mit Daten voll stopfen (pre-cacheing). Mit 1024 Bit breiten internen ALUs könnte man statt zwei dann vier der 32 Register gleichzeitig verrechnen. Das würde in manchen Anwendungen die Performance fast verdoppeln. Problem: Ström.

PS: Intel hat z. B. im Skylake-X zwei 512-Bit FMA-Einheiten (Fused Multiply-Add) - nicht eine 1024-Bit-Einheit, sondern zwei funktional getrennte ALUs. Das heißt AMD könnte das künftig auch tun mit zwei ALUs oder einer die doppelt so breit ist.

 

[stefan92x]

In dem Tweet wird von future INTEL Core Processors gesprochen/geschrieben. Also Nova Lake.

Tatsächlich steht das da aber nirgends explizit im verlinkten Code. Könnte auch der Nachfolger von Nova Lake sein, der damit gemeint ist.

Ergänzung (7. August 2025)

Ich fände es gut, wenn AMD Intel ordentlich aufs Maul geben würde als Antwort indem sie selbst ein AVX3 raus bringen, das dann 1024 Bit breit ist und doppelt so viele Register hat wie jetzt.

So ein Kindergarten wäre bald der Tod von x86. Ganz im Gegenteil haben AMD und Intel erst vor kurzem vereinbart, enger zusammenzuarbeiten, wenn es um die Einführung neuer Instruktionen geht. Es mag als Nachfolger eine 1024bit-Variante geben, aber die wird sicher nicht so konfrontativ eingeführt werden.

Mit 1024 Bit breiten internen ALUs könnte man statt zwei dann vier der 16 Register gleichzeitig verrechnen. Das würde in manchen Anwendungen die Performance fast verdoppeln. Problem: Ström.

Das wäre natürlich möglich. Oder, was Intel schon gemacht hat: Zwei AVX512 Einheiten pro Kern verbauen.

 

[FlashBFE]

Ein Problem von AVX512 wurde überhaupt noch nicht angesprochen: Dass es nicht ein Befehlssatz war sondern ein Sammelsurium von verschiedenen optionalen Befehlen, die man per Flags abfragen musste und die meines Wissens nach von Intel auch nie alle auf einmal unterstützt wurden.

Ein großes Plus ist deshalb die neue Versionierung. Man fragt per Software nur noch einmal ab, welchen Befehlssatz es gibt und kann sich dann drauf verlassen, ohne nochmal später Verzweigungen für einzelne exotische Befehle einbauen zu müssen.

 

[Yosup]

Die absolut richtige Entscheidung, die (projezierte) Attraktivität von Nova Lake ist damit bei mir erheblich gestiegen. Allerdings hat intel das auch bitter nötig!

Wenn bei aktuellen hybrid-CPUs von intel ein Prozess als "AVX-verwendend" erkannt wird, dann kann er vom Scheduler nicht auf die E-Cores verschoben werden, er ist quasi auf die P-Cores gepinned.

Selbst langsame AVX-"light"-Einheiten in den E-Cores würden da schon Abhilfe schaffen, weil dann zumindest ein auf die E-Cores verschobener Prozess nicht in die Bredoullie gerät, wenn er mal eine AVX-Instruktion aufruft. Das Scheduling wäre in Folge erheblich vereinfacht und flexibler.

intel hatte sich mit der Einführung der bigLITTLE-Architektur echt das Leben schwer gemacht, der Scheduler musste nicht nur zwischen E- und P-Cores entscheiden, sondern auch noch SMT-Cores und welche mit unterschiedlichen Instruktionssätzen differenzieren. Gleichzeitig hatte intel da noch recht wenig Erfahrung mit dem Hybridansatz. Ein entsprechend schlechtes Bild hat AlderLake daher vor allem anfangs auch abgegeben.

Wenn NovaLake weder SMT noch unterschiedliche Instruktionssätze aufweist wird das Scheduling quasi trivial. Und bisher habe ich noch gar nicht über das gesprochen, was AVX10.2 selbst leisten kann. Ich bin insofern gespannt.

 

[CDLABSRadonP...]

Ja und nein. AMD schafft es auch, kleine und große Cores mit AVX512 zu bauen, das scheint sich zu lohnen.

Seit wann hat AMD kleine und große Kerne? Die Dense-Cores sind komprimiert, hingegen nicht von sich aus klein.

Das stimmt, aber auch bei Intel sind wir mittlerweile weit weg vom 4:1 Verhältnis und nähert sich langsam dem Zustand bei AMD an. Da muss man dann irgendwann schon die Sinnfrage stellen, wenn Intel mit den E-Cores so weiter macht.

In letzter Zeit klang es ja ein Bisschen so, als würden vielleicht die E-Cores die P-Cores fressen...

 

[Yosup]

Auch bei Intel sind wir mittlerweile weit weg vom 4:1 Verhältnis und nähert sich langsam dem Zustand bei AMD an. Da muss man dann irgendwann schon die Sinnfrage stellen, wenn Intel mit den E-Cores so weiter macht.

 

[latiose88]

Was passiert wenn die p kerne überlastet sind es aber zwei Anwendung mit avx gibt . Dann werden doch auch die e Kerne verwendet oder wird dennoch alles in die p kerne gequetscht ?

 

[SweetOhm]

Tatsächlich steht das da aber nirgends explizit im verlinkten Code. Könnte auch der Nachfolger von Nova Lake sein, der damit gemeint ist.

"Intel AVX10.2 Ab Nova Lake auch wieder in P- und E-Kernen"​

https://www.hardwareluxx.de/index.p...-nova-lake-auch-wieder-in-p-und-e-kernen.html

 

[stefan92x]

@SweetOhm Ja das ist die gleiche Überschrift wie hier und verlinkt den gleichen Tweet, aber nochmal: Ich habe in dem im Tweet verlinkten Pull Request keinen Codenamen erwähnt gesehen. Vielleicht habe ich es übersehen, aber in keinem der Commits sehe ich etwas, was mir bestätigen würde, dass es um Nova Lake geht.

 

[fdsonne]

Das stimmt, aber auch bei Intel sind wir mittlerweile weit weg vom 4:1 Verhältnis und nähert sich langsam dem Zustand bei AMD an. Da muss man dann irgendwann schon die Sinnfrage stellen, wenn Intel mit den E-Cores so weiter macht.

Hast du ne genaue Zahl bei der aktuellen Umsetzung? Das ist gar nichtmal so einfach zu finden. Aber die Flächendifferenz sollte nach wie vor deutlich über den 35% von AMD liegen.

 

[Piktogramm]

Für jemanden und andere, die das nicht kennen:
Was genau macht AVX10.2, warum ist das so anzustreben?

AVX bedingt, dass man viele Werte mit der selben Operation in einem Takt erledigt werden können. AVX, AVX2 und AVX512 je immer doppelt soviel wie der Vorgänger (128bit, 256bit, 512bit). Wobei AVX512 fürchterlich fragmentiert ist, da es mehrere Suberweiterungen gibt und die Verfügbarkeit über das Produktportfolio einfach gewürfelt ist.
AVX10 und alles danach bringt Ordnung in das Ganze. Suberweiterungen sind Geschichte und es gibt einen einheitlichen Satz an Registern für die 128, 256 und 512bit Operationen.

Es wird wohl so wie bei AMD funktionieren. 2 256 Bit avx 2 können dann zusammen zu avx 512 zusammen geschaltet werden. Ist dann nicht mehr so schlimm weil es am Ende noch immer auf avx 2 also 256 basiert .

Nicht 2x AVX2, sondern die FPUs/ALUs können so ausgelegt werden, dass sie je nur die Hälfte der Vektoren bearbeiten. Also zwei 256bit µOps für ein 512bit AVX Befehl. Wobei es da ein paar Nachteile gibt. Gelegentlich sind bei der Zerlegung mehr als zwei µOps nötig, um die 512bit AVX Operation abzubilden.
Zerlegung in 128bit bei 512AVX Befehlen ginge auch, aber tendenziell braucht es dann nicht vier µOps sondern >=8µOps, was ein erheblicher Nachteil wäre.

Mit dem Big.Little Konzept waren die unterschiedlichen unterstützten Instruktionen aber wohl zu kompliziert im scheduling.

Das geht eher in die Richtung Unmöglich, im Regelfall weiß das Betriebssystem ja nicht welche Operationen im Programmcode kommen. Es könnte also schlicht keine Zuordnung an entsprechende Kerne erfolgen. Wobei Prozessoren (sinnvoller weise) bei illegalen Instruktionen den Programmablauf unterbrechen und ans Betriebssystem übergeben. Das was dir vorschwebt würde bedeuten, einfach mal grundlegend Prozessordesign und Betriebssysteme umzubauen und tendenziell Sicherheitsprobleme zu eröffnen.

Wieviel Software außer Benchmark gibt es eigentlich die AVX512 benötigen bzw. unterstützen? Kann man das an zwei Händen abzählen?

Multimedia, Verschlüsselung, Kompression, Textparser, Aufbau/Änderung von Binärbäumen, ..
Es gibt vergleichsweise wenig Anwendungen, wo Vektorisierung nichts bringt und mitunter lohnt es sich das Programm bzw. Algorithmen zu ändern um die Vorteile mitzunehmen. Wobei die Teilaspekte in den allermeisten Anwendungen vorkommen.
Die Adaption von AVX512 ist ansonsten halt mau wegen der bereits erwähnten Probleme. AVX512 ist Fragmentiert und Intel CPUs haben zu große Wartezeiten, als das es sich lohnen würde ein paar hundert AVX512 Befehle loszutreten.

So ganz erschließt sich mir nicht, warum man weiterhin nach E und P Kerne aufteilt, wenn - soweit mein Verständnis - das den Sinn der E Kerne komplett in Frage stellt. Eigentlich sollten es ja mal auf Fläche optimierte Kerne sein. Ich kann mir nicht vorstellen, dass AVX nicht doch wieder eine Große Menge an Fläche schluckt.

P Core bekommt ein oder zwei 512bit breite FPUs, E-Core bekommt eine 256bit FPU und zerlegt die 512bit breiten Befehle. Zudem bekommen die P-Cores wahrscheinlich deutlich dickere Load/Store-Einheiten im Vergleich zum E-Core. Der E-Core hat damit geringeren Platzbedarf, kann aber überhaupt AVX10.2, wenn auch zwischen E- und P-Core mindestens der Faktor zwei beim Durchsatz liegt.
AMD macht das bei Zen5 ja auch, die mobilen Chips haben auch nur 256bit Rechenwerke und bieten dennoch AVX512 an.

Die Bezeichnungen AVX10.1 und AVX10.2 sind genau so blöd wie AVX-512. Man hätte das schlicht AVX3/4/5 nennen können. Und die Frage ist was AMD mit diesen dummen Bezeichnungen anfangen soll. Sollen die jetzt etwa auch AVX10.1 und AVX10.2 raus bringen, weil Intel nichts gebacken bekommt? Und selbst bei Bezeichnungen versag Intel die für alle x86-Hersteller geeignet wären. Wie ich immer sage: Charakter ist nicht heilbar.

Der Name ist egal, hauptsache der Spaß wird einheitlich!

Ich fände es gut, wenn AMD Intel ordentlich aufs Maul geben würde als Antwort indem sie selbst ein AVX3 raus bringen, das dann 1024 Bit breit ist und doppelt so viele Register hat wie jetzt.

Je größere die Vektoren werden, desto geringer werden tendenziell die Einsatzmöglichkeiten. Zudem alle Bereiche die tendenziell von so dicken Vektoren profitieren auf Matrixrechenwerken und/oder GPUs sowieso Größenordnungen schneller laufen könnten.

nderer Trick: Intern könnte AMD 1024 Bit breite ALUs verwenden. Denn so weit ich weiß kann jeder CPU-Kern bislang nur zwei 512-Bit-Register zur gleichen Zeit verrechnen, obwohl es 32 von denen gibt (zmm0 bis zmm31). Man kann während dessen die anderen Register nur mit Daten voll stopfen (pre-cacheing). Mit 1024 Bit breiten internen ALUs könnte man statt zwei dann vier der 32 Register gleichzeitig verrechnen. Das würde in manchen Anwendungen die Performance fast verdoppeln. Problem: Ström.

Wieso der Aufwand, ein zweiter 512bit breiter Executionport und die CPU kann zwei 512bit Instruktionen parallel abfeiern, ohne neue Instruktionen einzuführen. Es müsste halt "nur" die Anzahl an Load/Store-Einheiten ebenso verdoppelt werden, die Bandbreite zu allen Caches und zum Arbeitsspeicher.
Oder man schiebt entsprechende Jobs in Richtung GPU, schaut aus wie ein Vektorrechenmonster, hat eine Speicheranbindung als wäre es für ein Vektorrechenmonster optimiert, ..

 

[fdsonne]

Multimedia, Verschlüsselung, Kompression, Textparser, Aufbau/Änderung von Binärbäumen, ..
Es gibt vergleichsweise wenig Anwendungen, wo Vektorisierung nichts bringt und mitunter lohnt es sich das Programm bzw. Algorithmen zu ändern um die Vorteile mitzunehmen. Wobei die Teilaspekte in den allermeisten Anwendungen vorkommen.

Ein großer Teil des Problem ist aber auch, dass eben nicht die ganze Welt da draußen überhaupt derartige Befehle ausführen kann. Das geht soweit, dass es heute immernoch Leute gibt, die sich dann lautstark aufregen, wenn auf ihrem Assbach Bulldozer oder Phenom II irgend eine Software nicht tut und wie können die Entwickler nur...

MMn ist es zwar ein riesiger Vorteil, soweit zurück gehen zu können in der Kompatibilität, aber andererseits ist es eben auch ein gewisser Nachteil, weil die alten Zöpfe immer dran hängen bleiben.
Auch wenn Microsoft nunmehr mit Windows 11 die Messlatte etwas höher schraubt - auch das stößt sehr wenig auf Akzeptanz in den Foren und Communitys. Aber eigentlich ist das durchaus auch ein Vorteil, wenn man da mal einen größeren Bruch erzwingt. Eben weil dann auch mal neuere Befehle die Basis sein können und man nicht immer noch irgendwelche Alternativ Pfade einbauen muss oder sich dann der Einfachheit halber ganz auf nur diesen gemeinsamen Nenner verständigt...

Das stimmt, aber auch bei Intel sind wir mittlerweile weit weg vom 4:1 Verhältnis und nähert sich langsam dem Zustand bei AMD an.

Habs gefunden:

Nach einer stumpfen Pixelmessung kommt eine Mehrfläche von ~45% für das Cluster aus vier Skymont Cores ggü. einem Lion Cove P-Core raus. (inkl. L2 Cache und Interconnects)

Das heißt andersherum gerechnet. Auf die Fläche der 4x4 E-Core passen ca. 5,87, also knapp 6 Lion Cove P-Cores. Es sind also knapp 3/8tel jetzt, anstatt 1/4tel seinerzeit.

Die Aussage, dass wir weit weg vom 4:1 Verhältnis sind, ist damit mMn nicht haltbar. Und wir nähern uns natürlich dem Zustand von AMD an, aber Intel ist nach wie vor bei deutlich mehr Flächenersparnis durch die Nutzung der E-Cores wie bei AMD mit deren ~35% Schrumpfkur.

Was man halt dann absehen muss ist wie sich das in Zukunft ändert. Mehr "Fähigkeiten" in die Core Logik zu bringen bedeutet am Ende mehr Flächenbedarf auch bei den E-Cores. Auf der anderen Seite gibt es gerade bei den Vektoreinheiten relativ viel Spielraum in der Umsetzung. 256Bit breit in zwei Durchläufen ist auch 512Bit. Wie es AMD ja mit den Mobile Produkten ebenso macht oder mit den Vorgängern von Zen5 auf dem Desktop.

 

[Piktogramm]

Ein großer Teil des Problem ist aber auch, dass eben nicht die ganze Welt da draußen überhaupt derartige Befehle ausführen kann.

Viele Programme halten daher ja auch mehrere Codepfade vor. Typisch ist ja "Vanilla X86_64", SSE2, AVX2 und AVX512. Wenn kein handgeschriebenes Assembler vorliegt, dann wird das im Zweifelsfall durch mehrere Compilerläufe und Compilerhints im Code erledigt, dass da Programmbestandteile mit entsprechenden Featues herauskommen. Das war bei AVX512 nur ein Krampf aufgrund der Fragmentierung.

 

[fdsonne]

Viele Programme halten daher ja auch mehrere Codepfade vor. Typisch ist ja "Vanilla X86_64", SSE2, AVX2 und AVX512.

Das stimmt schon, ich meine nur dass es aber real praktisch durch den immer mal wieder medial kommenden Aufschrei durchaus die Gegenfälle auch gibt, wo das eben nicht passiert. Und das betritt sowohl den Zwang zu neuerer Befehlssätze was dann alte CPUs ausschließt oder eben aber auch den Part, es sich einfach zu machen und vor allem AVX512 einfach liegen zu lassen... Weil Verbreitung gerade durch Intel seit Alderlake schwierig