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

[DKK007]

@xexex Dann sollten aber AMD CPUs mit APX draußen sein.

 

[DevPandi]

Das ist die Ebene auf der ein Compiler Register allokiert und nutzt.

Nein, weder früher noch heute. Ist aber ein kompliziertes Thema und kommt auf die Optimierungen an, die ein Compiler nutzt.

Ein Linker hat keine Kenntnis von Registern.

Es kommt am Ende halt auch darauf an, wie die entsprechenden „Bibliothek“ ein gebunden wird und was es für eine Bibliothek ist. Zu mal auch da heute kaum mehr Grenzen gesetzt sind.

Funktionen sind eine Grenze für den State im Prozessor.

Nein, sind sie nicht. Ich habe früher schon entsprechenden Blödsinn zur Optimierung auf Z80 genutzt, damit man sich teure Operationen spart und Register für nen Sprung zu einer Subroutine vorverlegt. Das ist dann genau das, was du hier als State bezeichnest.

Die CPU kennt allerdings keine Funktionen, Methoden, keine dynamischen oder harten Links. DASS sind Vertäge, die du mit deiner Programmiersprache machst. Die CPU kennt ihre „Sprünge“ und kann da natürlich mit den bestehenden Registern weiter arbeiten.

Im Übrigen ist das, was ich hier gerade beschreibe auch ein Grund, warum man in C ubd C++ verdammt gut auf den Zeiger aufpassen muss!

Wäre das anders könnte man den Code nicht linken.

Und solche Links werden heute je nach Art mal dynamisch, mal statisch aufgelöst. Du wirst erstaunt sein, wie sehr LLVM als auch der GCC moderneren C++ als auch RUST-Code glatt zieht im Junary? Obwohl du zig Klassen, Methoden und Funktionen verwendest.

Das was du Beschreibst ist der „Vertrag“, denn wir mit der Programmiersprache eingehen, damit wir den Überblick behalten. Moderne Compiler machen dann das, was die CPU bekommt und das kann stark von den Abweichen, was wir erwarten. Ist am Ende aber Formal richtig.

 

[blackiwid]

Bei Zen6 ist halt die Frage wie sich die 12 Cores auf einem CCD statt bisher wie beim 3900X auf zweien dann in der Praxis auswirkt.

Hmm da man eben mit 3 Lagen arbeitet und den Cache sandwitch nimmt, seh ich da kein so großes Problem, klar man muss dann gut die Hitze der 3 Layer nach oben bringen, aber das hat ja schon von 1 layer auf 2 gut geklappt.

Insgesamt sind Cache lastige Systeme ja effizienter als einfach mehr Cores drauf zu klatschen, aber ja es kann hotspots geben und die 5 Euro billige Kühlkörper sollte man nicht nehmen, vielleicht wird der boxed kühler da auch mal besser who knows

 

[xexex]

Mach also deine Entscheidung auch davon abhängig ob du ein Frickel-OS oder ein Enterprise-OS nutzt.

Meine Spielzeit mit einem "Frickel-OS", hatte ich irgendwann vor 20 Jahren. Wie gut APX unter Windows unterstützt wird und welche Vorteile es bringen wird, ist für mich eh zweitrangig, entscheidend sind die Spiele und da ist es völlig egal unter welchen OS.

 

[beachblocker]

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

Hast du konkrete Beispiele parat?

z.B. sha3 (keccak). Funktioniert dann pro Runde mit nur einem Load und ganz ohne Stores (erst am Ende der 24 Runden, oder nachdem der komplete Input verarbeitet wurde).

Aber grundschätzlich stimmt es natürlich: Moderne Programmierung versucht kurze Funtion zu schreiben mit entsprechend wenig lokalen Variablen, da helfen zusätzliche Register wenig.

Anderseits hat die moderene ARM ISA auch 32 GPR (also eher 30 + 2 weniger generelle). Und hat auch ähnliche Instruktionen wie die bei APX neu hinzugekommenen.

Die x64 ISA wird damit keine Altlasten los, kann aber (Intel nennt es "Die Software muss nur neu kompiliert werden") deutlich an Performance gewinnen. Nicht unbedingt durch mehr IPC sondern effizentere Instruktionen. Von bestimmer performance kritischer Software wird es dann vermutilich eine spezielle Version geben (müssen). Bei Windos könnte dann für Hashes und Encryption eine andere DLL geben.

Bei OpenSSL ist es z.B. heute schon so ähnlich, für die Hash und Encrypt Funktionalität gibt es Weichen in der Software, die die performanteste Implmentierung wählen, je nachdem, was die CPU unterstützt: BMI2, SHA256 Extentension, AES, SHA512 Extension, AVX2, AVX512 etc. Da wird dann wie auch bei Aida64 schon eine für SHA3/APX hinzukommen.

 

[DevPandi]

Aber grundschätzlich stimmt es natürlich: Moderne Programmierung versucht kurze Funtion zu schreiben mit entsprechend wenig lokalen Variablen, da helfen zusätzliche Register wenig.

Das was du in deinem Quelltext schreibst ist das einen. Was am Ende als Binary für die CPU raus kommt das andere.

Moderne Compiler können zum Beispiel auch ganze „Aufrufe“ - die du logisch in kleine Häppchen teilst - zusammen führen und als eine große Funktion einbeziehen.

Zudem Handel der Compiler aus, wie er zum Beispiel in der ABI Register vor belegt für einen Sprung, damit man sich teure Operationen um Säubern und neu belegen der Register sparrt. Genau deswegen gibt es ja auch bei „dynamischen“ Bibliotheken eine ABI.

Würde man wegen jedem Funtkions/Methodenaufruf dien Registern säubern, fein säuberlich weg speichern und neu laden, na gute Nacht was die Leistung angeht.

Aber ich bin jetzt raus. Mittagessen und dann was anderes.

 

[WinnieW2]

irgendwie möchte man das ja auch testen bevor die echte hardware da ist, da ist die performance erstmal zweitrangig.

Das ist richtig, wobei ein Test auf CPUs welche APX auch wirklich in Hardware implementiert haben zuverlässiger ist.

Meine Überlegung war ein Rollout an Nutzer... da ergibt das weniger Sinn APX per Software zu emulieren.

Ergänzung (Gestern um 13:29)

... falls die Leistungssteigerung zur jetzigen LGA1700 Plattform gegeben ist, APX wird da in der Überlegung nur eine untergeordnete Rolle spielen.

Ok, für die Nutzung in normalen Desktop-PCs und Notebooks mag das stimmen. Für den Einsatz in Servern könnte APX bereits füher eine Rolle spielen... aber da verlassen wir Windows 11 Gebiet.
Jedenfalls werden die Kerne der nächste Generation an Xeon-CPUs ebenfalls APX unterstützen...
Wird aber die Compilerentwicklung vorantreiben.

 

[SuperHeinz]

Ach, immer diese Neuerungen! Man kann sich ja gar nicht mehr entspannt zurücklehnen. 😏

 

[DKK007]

Hmm da man eben mit 3 Lagen arbeitet und den Cache sandwitch nimmt, seh ich da kein so großes Problem, klar man muss dann gut die Hitze der 3 Layer nach oben bringen, aber das hat ja schon von 1 layer auf 2 gut geklappt.

Also der L3 Cache wandert dann insgesamt in eine neue Ebene, nicht nur der zusätzliche bei den X3D?

 

[stefan92x]

@DKK007 Bis jetzt gibt es dafür bei Zen 6 keinen echten Anhaltspunkt. Das dürfte eher aussehen wie von Zen 5 bekannt, nur einfach mit mehr Kernen pro Chiplet dank (deutlich) besserer Fertigung - N4 statt N2, der N3-Node wird komplett übersprungen für Desktop Ryzen.

 

[foofoobar]

Würde man wegen jedem Funtkions/Methodenaufruf dien Registern säubern, fein säuberlich weg speichern und neu laden, na gute Nacht was die Leistung angeht.

Wie willst du sonst Rekursion und nachfolgendes sich selbst aufrufen implementieren?

 

[stefan92x]

@foofoobar Rekursion ist aus guten Gründen eher ungern gesehen. Falls der Compiler aber einen statischen Fall erkennt (im Sinne von: Es steht fest, dass an einer bestimmten Stelle eine Rekursion nur zweimal passiert), dann kann er bei genug Registern diese einfach nutzen um die Registerwerte der höheren Stufen einfach zu behalten und die inneren Aufrufe in die zusätzlichen Register zu legen.

Mit mehr Registern können da also z.B. die Werte für tiefere Aufrufe komplett in den Registern gehalten werden.

 

[mae]

Hast du konkrete Beispiele parat?

Gforth konnte bis vor wenigen Jahren auf AMD64 nur ein Register fuer den Stack verwenden, auf PowerPC z.B. mindestens 8 (bei 32 Registern in der Architektur). Die Geschwindigkeitsvorteile von mehr Registern auf PowerPC-Prozessoren wurden in Stack Caching in Forth gezeigt. Inzwischen klappt es auf AMD64 mit drei Registern. Jetzt koenntest Du angesichts der Daten in dem Paper meinen, dass mehr als drei Register fuer den Stack eh wenig bringen, aber wenn das liegt daran, dass Gforth da noch sehr wenig mit den Registern anfangen kann, weil sie nur auf straight-line-code verwendet werden, und auch Techniken zum Verlaengern dieser Codestuecke (z.B. Inlining) nicht verwendet werden. Sobald das der Fall ist, bringen mehr Register mehr, aber bei AMD64 kann man nicht mehr verwenden (die anderen 13 Register werden fuer diverse andere Aufgaben eingesetzt). Mit APX faellt diese Einschraenkung.

Und bei vielen anderen Programmen sind 16 Register auch zu wenig. Es hat einen Grund, warum ARM bei ihrem 64-bit-Befehlssatz A64 nicht an den 16 Registern des A32/T32 festgehalten haben, sondern stattdessen auf 32 bit gegangen sind. Genauso wurde RISC-V mit 32 Registern konzipiert.

Ein anderer Vorteil von APX ist, dass "A = B-C" nicht mehr wie bei AMD64 normalerweise in zwei Befehle "A = B; A=A-C" aufgeteilt werden muss; letzteres kostet mehr Resourcen im Front End.

 

[foofoobar]

Gforth konnte bis vor wenigen Jahren auf AMD64 nur ein Register fuer den Stack verwenden, auf PowerPC z.B. mindestens 8 (bei 32 Registern in der Architektur). Die Geschwindigkeitsvorteile von mehr Registern auf PowerPC-Prozessoren wurden in Stack Caching in Forth gezeigt.

Naja Stack-Maschinen halt.

@foofoobar Rekursion ist aus guten Gründen eher ungern gesehen.

Kannst du das aus der Spec streichen lassen?

 

[DevPandi]

Mit mehr Registern können da also z.B. die Werte für tiefere Aufrufe komplett in den Registern gehalten werden.

Mich erinnert das an eine Vorlesung - auch bald 20 Jahre her - zu Algorithmen und Rekursion, und wie man dieses soweit optimiert, dass am Ende selbst tiefste Rekursionen quasi vollständig über register abgehandelt werden, einfach nur dadurch, dass die entsprechenden Parameter in der Funktion mitgeben wurden und im nächsten Aufruf "perfekt". Ja, ein total simples beispiel aber es zeigt gut was ich meine:

addWhile(a, b, c, d) {
    if (c >= d) return a+b;
    
    return addWhile(a+b, b, c+1, d);
}

Ansonsten - wenn ein Compiler eine Bibliothek "fest" einbindet, kann der Compiler noch mal ganz anders arbeiten dabei, ist es eine "gelinkte" Bibliothek, gibt es die ABI (Application-Binary-Interface) und im ABI wird definiert, in welchem Register welche Werte für den Aufruf abgelegt werden und in welchem Zielregister dann der Rückgabewert ist.

Selbst bei deutlich tieferen Rekursionen wird genau damit gearbeitet, "vor dem Sprung" schreibt das Programm die Werte in die passenden Register, nach dem Sprung wird der Code ausgeführt und dann das Ergebnis in den vereinbarten Registern wieder hinterlegt und kann von dort weiter bearbeitet werden.

Wegen einem Methoden/Funktionsaufruf erst mal alle register wegsichert in den RAM, dann den Code laden um die Register zu befüllen? Das ist absolut kontraproduktiv. Solang der Programmcode alles in Registern halten kann, hält er es auch, egal ob da eine Subroutine aufgerufen wird oder nicht. Solang alles im "gleichen" Programmfluss liegt, wird das über Konvntionen gelöst und der Compiler weiß, wo er was hinlegen muss.

Und auch das ist noch stark vereinfacht. Aber sobald man aus den Registern raus geht, wird es langsam und kostet Zyklen und DAS wollen wir alle nicht. Wie geschrieben, solche Tricks wie Register für ne Subroutine vorblegen sind schon Optimierungen, die ich in der Schule - auch über 20 Jahre her - mit Z80 schon gemacht habe, damit man den code schnell bekommt.

 

[mae]

Glaubst du wirklich ein System und Apps mit APX Unterstützung, werden zu 100% mit älterer Software problemlos zusammen laufen?

Ja, natuerlich. An den alten Befehlen aendert sich ja nichts.

 

[Land_Kind]

... dass Intel versucht, sich unlautere Vorteile zu verschaffen, weil sie sonst an AMD dieses Jahrzehnt nicht mehr herankommt.
Die Schublade klemmt ja auch schon seit über 10 Jahren.

Wohl kaum. Intel hat zusammen mit AMD im 2024 extra für die Weiterentwicklung von x86 die Initiative x86 Ecosystem Advisory Group (EAG) gegründet, was ja an sich schon bemerkenswert ist.

Doch die haben dies natürlich nicht aus gegenseitiger Freundschaft getan, sondern um sich im Servergeschäft gegen ARM (und RISC-V) zu wappnen, welche den beiden mehr und mehr Marktanteile wegschnappt.
Intel würde sich schlicht ins eigene Fleisch schneiden, wenn sie AMD verärgern würden. Trotzdem bleiben sie natürlich Konkurrenten. Und das ist auch gut so.

Mit bei der Initiative sind auch viele andere wie Broadcom, Dell, Google, Lenovo, HP, Meta, Microsoft, Oracle und Red Hat sowie prominente Einzelpersonen wie bsp. Linus Torvalds.

 

[mae]

Aber grundschätzlich stimmt es natürlich: Moderne Programmierung versucht kurze Funtion zu schreiben mit entsprechend wenig lokalen Variablen, da helfen zusätzliche Register wenig.

Doch, doch, dank inlining (einfuegen einer aufgerufenen Funktion am Punkt des Aufrufs). Und da helfen dann mehr Register mehr. Einer der Entwickler des Java-JIT-Compilers Hotspot hat mir erzaehlt: Wir inlinen solange, bis es wehtut (bis mehr Register gebraucht werden als vorhanden sind), und dann gehen wir ein bisschen zurueck. Wenn also mehr Register vorhanden sind, kann so ein Compiler mehr inlinen.

JIT-Compiler wie die von Java oder von .NET werden uebrigens sehr schnell von APX profitieren koennen, weil der von ihnen erzeugte Code nur auf einer Maschine laufen muss und nicht auf allen. Wenn die Maschine APX hat, wird eben APX-Code erzeugt, wenn nicht, dann nicht.

Wenn, wie Igor vermutet, Intel's Marketing wieder die klugen Ideen der Entwickler sabotiert, indem sie bei den billigen Prozessoren APX abschalten, dann wird APX noch auf Jahrzehnte hinaus bei vorcompilierter Software nur ein Nischendasein fuehren, so wie AVX und AVX-512.

 

[foofoobar]

Doch, doch, dank inlining (einfuegen einer aufgerufenen Funktion am Punkt des Aufrufs). Und da helfen dann mehr Register mehr. Einer der Entwickler des Java-JIT-Compilers Hotspot hat mir erzaehlt: Wir inlinen solange, bis es wehtut (bis mehr Register gebraucht werden als vorhanden sind), und dann gehen wir ein bisschen zurueck. Wenn also mehr Register vorhanden sind, kann so ein Compiler mehr inlinen.

Oder bis der I-Cache unwirksam wird.

Wenn, wie Igor vermutet, Intel's Marketing wieder die klugen Ideen der Entwickler sabotiert, indem sie bei den billigen Prozessoren APX abschalten, dann wird APX noch auf Jahrzehnte hinaus bei vorcompilierter Software nur ein Nischendasein fuehren, so wie AVX und AVX-512.

Das wird sich Intel in Zukunft nicht mehr leisten können.

 

[Nagilum99]

Na wenn das mal nicht danach klingt, zukünftig wieder gewisse Prozessorgenerationen auszuschließen. Ja, mir ist bekannt, daß es damals um "Sicherheit" ging.

Auf einem 386er bekommst du heute auch nicht mehr viel ans laufen. Was ist dein Punkt?