News Schalter entdeckt: Windows 11 wird für Advanced Performance Extensions gerüstet

[foofoobar]

AKTUELL alles, was AVX512 verwendet. das darf schon heute bis zu 32 - spezialisierte - Register nutzen.

Weswegen ich von GPR (General Purpose Register) spreche. Und das sind keine Register für SIMD.

 

[Matthias B. V.]

Interessant wird sein ab wann auch AMD es unterstützen wird - Zen7 - vermute ich mal…

Als APX von Intel in die Entwicklung eingesteuert wurde war es noch bevor man zusammen mit AMD im x86 Advisory gearbeitet hatte…

Daher zu spät für Zen6

 

[mcdexter]

Also ein Cheat-Schalter in Windows für Intel-Prozessoren.
Wenn man die Konkurrenz nicht anders schlagen kann, muss man halt mit sowas kommen.

Enthält Ironie..Oder 🤔

 

[stefan92x]

Also ein Cheat-Schalter in Windows für Intel-Prozessoren.

Einfach nur Support für neue Hardware. Das hat nichts mit Cheaten zu tun.

Wenn man die Konkurrenz nicht anders schlagen kann, muss man halt mit sowas kommen.

Mit neuen Entwicklungen? Ja, wie sich das gehört.

 

[Matthias B. V.]

Nein, das ist an der Stelle vollkommen falsch!

APX erweitert die grundlegende x86-ISA um 16 weitere Register, sowie die Möglichkeit, dass viele Operationen ab jetzt nicht mehr zwangsweise ein Register überschreiben.

Für letzteres kurzes Beispiel A = A + B. Das kann nun auch ein A = B + C sein. Das verhindert an der Stellen, dass eine Kopie von einem Register angelegt werden muss - womit man sich eben genau das sparrt und mit den andegen beiden Registern weiter arbeiten kann.

Die Vergrößerung von 16 auf 32 Register wiederum ist für den Compiler primär wichtig, weil weniger Load, Store, sowie eben Copy-Anweisungen im Binary zu finden sind. Auch für die µ-Arch kann das später vorteile haben, weil das Programm wesentlich länger mit den vorhanden Registern arbeiten kann - das "Fehlen" von Load- und Store-Anweisungen entlasstet an der Stelle die Infrastruktur der CPU. Ebenso wird es für OoO und die spekulative Ausführung einfacher, weil zwar weiterhin hier mit Schattenregister und Register-Renaming gearbeitet wird, gleichzeitig sinkt jedoch der Aufwand für dessen Verwaltung.

Damit ist es am Ende auch einfacher für einen Thread einen CPU-Kern wirklich auszulasten, weil man nicht auf Daten im Cache oder schlimmsten Fall RAM warten muss, viel mehr Optionen hat Werte "zwischen" Zulagern direkt im Kern und am Ende die Verwaltung dessen auch einfacher wird.


Nein, es ist nicht kompatibel mit älterere Software, die alte Software kann weiterhin nur die 16 Register nutzen. Damit die Software es nutzen kann, muss sie neu kompiliert werden.

Sollte einmalig und überschaubar sein…

So richtig wird sich APX sobald man auch weiß, ob AMD hier "mitziehen" darf. Bis dahin klingt APX toll und wird bei Software, die APX unterstützt auch dafür sorgen, dass die Kerne besser ausgelastet werden können. Die breite Unterstütztung wird allerdings erst kommen, wenn AMD es auch hat.

Werden sie ziemlich wahrscheinlich so wie auch mit ACE

Schon alleine um x86 nicht wie in der Vergangenheit zu fragmentieren.

Zudem die Leistung sicherlich in einigen Anwendungen klar von profitieren wird. Ist ja aktuell ein x86 Problem und ARM unterstützt es bereits?

 

[Bigfoot29]

@foofoobar : Dann denk mal drüber nach, WARUM es im Moment so wenig x86/AMD64 Software gibt, die mehr als 16 Register nutzt... Weil es das da noch nicht gibt. facepalm

Anders sieht es bei ARM64 (AARCH64) aus. Aktuelle Versionen können da schon eine Weile 31 Register nutzen. Gut möglich, dass da ein Teil der Performance herkommt...

Regards, Bigfoot29

 

[xexex]

27.05.2025: Intel APX Ready With Linux 6.16 - ganz ohne schalter

Nur was bewirkt es unter Linux? Zunächst einmal nichts!

The X86_FEATURE_APX feature flag is added, APX state support is now handled, and various other changes around Intel APX. Intel APX isn't intended to be used by kernel code but rather user-space. Various changes though to the Linux kernel were needed for properly managing APX state and being able to report the capability to user-space.

Der Schalter bei Windows soll hingegen die Nutzung der Erweiterung aktivieren.

the recent future "Rubidium" platform Insider build 29695 has the option for developers to enable APX with a simple toggle, with the description of the feature stating "Let Windows use APX for better performance". A restart is prompted if we toggle it on.

Auch wenn die Beschreibung an dieser Stele wage ist, sollen damit scheinbar irgendwelche Funktionen unter Windows beschleunigt werden. Ähnliches muss unter Linux dann zunächst in den den jeweiligen Applikationen implementiert werden, nur weil der Kernel diesen Flag kennt, beschleunigt nichts.

 

[person unknown]

Intel™ tut mal wieder Intel-Sachen®.
Intrigieren, mauscheln, mogeln. Wie ich das nicht mag...

 

[stefan92x]

@person unknown Intel bringt eine neue Funktion in seine Prozessoren.

Was daran ist intrigieren, mauscheln oder mogeln?
Und hast du auch AMD vorgeworfen, dass sie intrigieren, mauscheln und mogeln, als sie genau die gleiche Maßnahme als Teil von x86-64 umgesetzt haben?

 

[Blackhorse79]

Bevor heutige CPUs die Geschwindigkeit beim Aufruf von Funktionen / Programmen begrenzen wird es wohl zuerst der Speicher tun, von dem gelesen wird. Verstehe den Knopf daher nicht wirklich.

Schreit für mich nach Marketinggag.

 

[xexex]

Intel™ tut mal wieder Intel-Sachen®.

Richtig! Sich vorbildlich ein halbes Jahr vor dem Release neuer Hardware um die Software Unterstützung zu kümmern. Da könnten sich andere Hersteller ein gutes Beispiel dran nehmen.

 

[Bigfoot29]

Im Prinzip macht MS hier nix anderes als unter Linux vergleichbar mit "aktiviere APX im Kernel" über die Kernel optionen mitzugeben. Danach kann dann Software, die APX optional kann, das Feature nutzen. Das würde dann für Außenstehende ggf. wie ein "Turbo" wirken. (Schon die Compiler-Flags unter Linux, die AMD64-v3 - aktuell wird unter Debian wie gesagt noch pures AMD64-v1 benötigt - unter CachyOS liefern, bringen einen spürbaren Leistungsschub. Zen3/Zen4 dann noch einmal ähnlich viel.)

Also ja, APX wird mehr Leistung bringen. Die Frage ist, ab wann das für die Masse spürbar sein wird.

Regards, Bigfoot29

 

[foofoobar]

Anders sieht es bei ARM64 (AARCH64) aus. Aktuelle Versionen können da schon eine Weile 31 Register nutzen. Gut möglich, dass da ein Teil der Performance herkommt...

Immer her mit konkreten Beispielen.

 

[WinnieW2]

APX ist, wenn ich das korrekt verstanden habe, eine Erweiterung des Basisbefehlssatzes. Von daher werden für dessen Unterstützung, in abwärtskompatibler Form, zwei Code-Versionen von Software erforderlich sein.
Weil die Bestands-CPUs unterstützen kein APX und werden auch nie in der Lage dazu sein.

Und weil aufgrund der hohen DRAM und SSD Preise die Verkaufszahlen niedrig sind wird es wohl viele Jahre brauchen bis CPUs mit APX wirklich massenhaft in Bestand vorhanden sein werden.
Und solange werden Softwareentwickler wohl zwei Versionen compilieren müssen, mit und ohne APX.
Oder die Unterstützung von APX wird sich auf eine begrenzte Anzahl an Programmen beschränken.

Ergänzung (Dienstag um 10:04)

Solange man keinen neuen Speicher oder SSDs benötigt, ist es kein großes Problem. Weder CPUs noch Boards sind relevant im Preis gestiegen. Theoretisch könnten diese Produkte sogar günstiger werden, da weniger Leute bereit sind bei den aktuellen Preisen einen neuen Rechner zu kaufen.

Das stimmt, aber angenommen Leute haben bereits ein Mainboard mit DDR5-RAM u. akt. SSD... wieviele davon werden auf ein neues Board u. eine neue CPU wechseln, nur wg. APX?
Zumal bislang noch unklar ist welche Softwareschmieden in welchen Zeitraum Programme mit APX veröffentlichen werden.
Ich bezweifle dass Notebooks und PCs preisgünstiger werden aufgrund geringerer Nachfrage... weil DDR5-RAM und SSDs dennoch teuer bleiben... weil die Rechenzentren weiterhin hohen Bedarf haben, und die Produktionskapazität der Chipfertiger ausgebucht ist.

Interessant wird sein ab wann auch AMD es unterstützen wird - Zen7 - vermute ich mal…

Zen 6 soll APX noch nicht unterstützen, nachdem was ich recherchiert habe, von daher wird AMD wohl erst mit der Zen 7 Generation APX unterstützen... aber CPUs der Zen 7 Gen. sollen erst Ende 2028 / Anfang 2029 auf den Markt kommen.
Bei Intel werden CPUs der Nova Lake Generation APX unterstützen u. die sind für 27Q1 angekündigt.

 

[DevPandi]

Mir fallen auf Anhieb wenig Funktionen, Methoden oder Algorithmen ein die von mehr als 16 Registern (speziell GPR) profitieren.

Wenn du ein Programm nur als einzelne Funktionen, Methoden und Algorithmen begreifst, dann ist es natürlich relativ einfach zu schreiben, dass mehr als 16 Register nicht benötigt werden. Mit der gleichen Argumentation könnte man allerdings auch 16 Register hinterfragen, weil 8 früher auch gereicht haben und wenn man heute händisch einen Algorithmus umsetzt, ist es einfacher das mit 8 Registern zu machen als mit 16.


Nur besteht heute eine Software nicht mehr aus einzelnen Funktionen, Methoden oder Algorithmen, sondern eine Vielzahl davon, die auch teilweise miteinander interaggieren.

Hast du konkrete Beispiele parat?

https://www.intel.de/content/www/de...ons-intel-apx-architecture-specification.html - In der PDF von Intel steht alles zu dem Thema drin, wie die 16 zusätzichen Register dabei helfen Load- und Store-Anweisungen zu reduzieren und wie das auch in Verbindung mit den Befehlen nun auf drei Register auch dabei hilft, "Wide-Core-Designs" besser auszulasten.

In wie weit sich weitere Vorteile zeigen, kann man erst sehen, wenn quasi wirklich einen Compiler einmal x86 mit 16 Registern und einmal später x86 mit 32 Registern nebeneinander liegt als fertiges Binary.

Es geht hier nämlich nicht mehr darum, dass man händisch irgendwelche Algorithmen, Funktionen und Methoden überträgt, sondern was der Compiler zur Verfügung hat und daraus machen kann und welche Optimierungen er damit vornehmen kann und ebenso welche Optimierungen die CPU im ganzen am Ende "leichter" vornehmen kann.

Anders sieht es bei ARM64 (AARCH64) aus. Aktuelle Versionen können da schon eine Weile 31 Register nutzen. Gut möglich, dass da ein Teil der Performance herkommt...

Natürlich kommt am Ende auch da ein Teil der Preformance her, weil weniger Load- und Store vorhanden sind, dazu kann die CPU im OoO-Fenster und Co wesentlich mehr optimieren und das auch simpler, weil die "Register-Alias"-Tabelle weniger komplex wird.

Nur ist Software heute eben deutlich komplexer und ein Zusammenspiel aus verschiednen Ebenen. Wirklich gute Beispiele wird man erst bekommen, wenn - wie bei AVX512 vor zig Jahren - man wirklich Code nebeneinander legen kann und dann sieht was los ist.

Immer her mit konkreten Beispielen.

Willst du damit behaupten, dass Intel hier ein vollkommen sinnlose Erweiterung schaft? Interessant, dass ab den 80er, als die Compiler sich immer stärker durchgesetzt haben, quasi alle neuren ISAs plötzlich auf 32 und mehr Register gesetzt haben, Die hätten ja alle damals auf 8 oder 16 bleiben können.

Bitte jetzt nicht falsch verstehen, aber wäre es so dass man hier nicht von profitiert, Intel würde es nichbt umsetzten und man hätte in den 80er und 90er nicht teilweise bei neuren Architekturen direkt auf 32 oder gar 64 Register gesetzt.

Wenn du natürlich immer nur jedes Problem einzeln isoliert betrachtest, klar okay. Aber heutige Compiler sind teilweise zu optimierungen fähig, die kein normaler Mensch wirklich schafft, weil LLVM und Co deutlich komplexeren Optimerungsroutinen haben und je mehr Futter man den gibt, um so besser arbeiten sie.

 

[Piktogramm]

Dann denk mal drüber nach, WARUM es im Moment so wenig x86/AMD64 Software gibt, die mehr als 16 Register nutzt... Weil es das da noch nicht gibt. facepalm

Du hast die Aussage dahinter glaube nicht verstanden. Bei vielen grundlegenden Algorithmen für Hashes, Kryptografie, Suche, ... sind oftmals nicht so viele Werte vorzuhalten, sodass 16 GPRs durchaus ausreichend sind und ein Zuwachs um 16 weitere GRPs erwartbar kleine bis keine Vorteile bringt.
Typische Konventionen beim Programmieren raten ja auch von all zu vielen Ebenen verschachtelter Schleifen ab. Zum einen aufgrund der Verständlichkeit als auch wegen der Implikation für die Performance.

Realer Code ist aber gern mal anderer Natur, manchmal aus Schlamperei, manchmal weil sehr kluge Köpfe es nicht besser hinbekommen. So n-dimensionale Arrays, Structs etc. durchwandern über geschachtelte Schleifen und schon hat man Bedarf an mehr Registern, als die ISA einen adressieren lässt.

Anders sieht es bei ARM64 (AARCH64) aus. Aktuelle Versionen können da schon eine Weile 31 Register nutzen. Gut möglich, dass da ein Teil der Performance herkommt...

Zu einem gewissem Teil kann mit einem größerem Registersatz der Compiler Optimierungen betreiben, die sonst die CPU intern vornehmen müsste. Wobei bei den schnellsten ARM CPUs (Apple), die internen Registersätze für Registerrenaming auch extrem groß sind. Ein unbestreitbarer Vorteil ist jedoch, dass je nach Code, die Anzahl an Load/Store Instruktionen verringert wird und weniger Instruktionen zu dekodieren sind. Zumindest wenn man die Selbe ISA betrachtet und nur die Anzahl an GRPs verändert.

##########################

APX auf Betriebssystemebene, egal ob Linux oder Windows.

An sich wäre es Imho sinnvoll, die Betriebssystemimages direkt mit APX-flag zu bauen. Die Images wären dann aber nur auf Prozessoren lauffähig, die APX unterstützen. Eine Verzweigung in einzelnen Bibliotheken wie z.B. für Softwareraid wo es Verzweigung auf "generisch", SS2, SS4, AVX2 und AVX512 [1] ist nicht all zu sinnvoll. An der Stelle muss dann aber der Bootloader entscheiden, welches Images zu booten sind. Entweder über gesetzte Flags, oder durch selbstständiges Erkennen und Zuordnen von Featureflags der CPU.

Wenn Microsoft einen "use APX" Schalter einbaut, dann deutet mir das auf entsprechende Überlegungen hin. Den der NT-Kernel kann mit bestehenden Mechaniken auch schon auf div. Befehlssatzerweiterungen verzweigen. So ein Flag bringt Imho nur etwas, wenn da in Zukunft beim Bootvorgang ein entsprechendes Kernelimage gestartet wird.


[1]nur x86, ARM, RISC-V etc. verzweigen entsprechend ihren Erweiterungen

 

[Land_Kind]

So richtig wird sich APX sobald man auch weiß, ob AMD hier "mitziehen" darf.

Es wäre seltsam, wenn AMD nicht mitmachen würde/dürfte, fragt sich nur, in welchem Zeitraum.
(Reine Spekulation meinerseits: Vielleicht ist das ja ein Zücherchen an Intel, dass die diesen Support früher rausbringen dürfen, weil sie ihn "erfunden" haben?)

Es geht ja um die Weiterentwicklung des x86er Standarts, also nicht um ein eigenes Süppchen von Intel.:
"Obwohl der APX-Support ursprünglich von Intel im Jahr 2023 konzipiert und vorgeschlagen wurde, wird er im Rahmen der neugegründeten x86 Ecosystem Advisory Group gemeinsam von Intel und AMD weiterentwickelt und standardisiert."

 

[DevPandi]

Realer Code ist aber gern mal anderer Natur, manchmal aus Schlamperei, manchmal weil sehr kluge Köpfe es nicht besser hinbekommen.

Wobei man an der Stelle auch schreiben muss, dass ein Mensch an der Stelle die "Komplexität", die bereits 16 und nun auch 32 Register mit sich bringen, so überhaupt nicht mehr wirklich sinnvoll verwalten kann.

Als Mensch ist man mit 8 Registern schon glücklich. Genauso wie ein Mensch bei der Optimierung von Algorithmen, wenn man Vektorisierung einbezieht oft einen Vektor mit zwei Elementen noch sehr gut erfassen kann, spätestens ab 4 Elementen wird es dann schon sehr komplex und bei den heutigen 8 bis 16 Elementen steigt man eigentlich vollkommen aus, weswegen quasi fast jedes moderne OS auch entsprechende APIs dafür anbietet, die solche Optimierungen selbst vornehmen.

Zu einem gewissem Teil kann mit einem größerem Registersatz der Compiler Optimierungen betreiben, die sonst die CPU intern vornehmen müsste. Wobei bei den schnellsten ARM CPUs (Apple), die internen Registersätze für Registerrenaming auch extrem groß sind.

Und die in er CPU dann auch wieder Schaltungsflächen wegnehmen, die man für andere Sachen verwenden kann.

Und die RAT wird vermutlich durch die mehr Register sogar noch größer werden, nur bedeutet eine größere RAT nicht unbedingt, dass sie komplexer wird. Mit den 32 Registern und weniger Load, Store, Move und Copy-Anweisungen wird mit hoherwahrscheinlichkeit die "Tiefe" der RAT abnehmen, weil weniger Write-After-Read, Write-After-Write-Fälle abgefangen werden müssen. Ebenso fällt das Renaming in dem Fall einfacher, weil mehr Register da sind und der Compiler entsprechende Abhängigkeiten wesentlich früher schon auflösen kann.

Nur wir reden hier jetzt von Sachen, die KEIN Entwickler, egal wie Hardwarenah er noch programmiert, wirklich machen wird und machen will. Moderne Compiler sind hier deutlich besser drin, genau solche Optimierungen vorzunhemen und die CPU wird damit auch wieder ein Stückweit entlastet.

 

[stefan92x]

@Land_Kind wurde hier von einem AMD-Verantwortlichen auch offiziell in dem Rahmen genannt: https://www.linkedin.com/pulse/advancing-x86-together-robert-hormuth-v4ywc/

FRED, APX und AVX10 sind definitiv Themen, die im Rahmen der x86 EAG angegangen werden und die dann auch irgendwann von AMD unterstützt werden dürften.

 

[DevPandi]

Es wäre selsam, wenn AMD nicht mitmachen würde/dürfte, fragt sich nur, in welchem Zeitraum.

@Matthias B. V. ich schreib euch beiden mal direkt gemeinsam eine Antwort: Ihr habt natürlich recht. Deswegen hatte ich das Wort Mitziehen auch in Anführungszeichen gesteckt. Zen 6 wird APX noch nicht haben, das steht fest. Ob es mit Zen 7 schon kommt oder erst mit Zen 8 wird sich zeigen.

Das es kommen wird, auf jeden Fall. Nur ihr beiden wisst doch, wie hier teilweise Aussagen für bare Münzen genommen werden und man vorsichtig sein muss, was man schreibt, weil man sonst entsprechend Vorwürfe bekommt, dass man etwas zu rosig gemalt hat.