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

[stefan92x]

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

Ich denke, das Problem war eher das Wort danach: "darf"

Denn dass AMD APX nutzen darf, das steht völlig außer Frage. Es geht nur darum, zu welcher Generation AMD das will.

 

[xexex]

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?

Konkrete Zahlen kann ich dir da nicht liefern, aber kommt letztlich auf die Leistung drauf an. Arrow Lake ist schlecht im Markt angekommen, also potentiell alle LGA1700 Nutzer mit DDR5 Speicher und alle AM5 Nutzer. APX ist nur ein Schmankerl, auf die Gesamtleistung wir es ankommen und speziell hier im Forum, auf die Spieleleistung.

Der springende Punkt hierbei, gerade weil derzeit RAM, SSDs und GPUs so teuer geworden sind, können durchaus einige einen MB/CPU Upgrade anstreben und sei es nur aus Spaß am Basteln.

 

[0x8100]

Schön, dass Linux da ohne Schalter auskommt. Dumm nur, dass dir das aktuell nichts bringt, weil es die APX CPUs für das hier noch gar nicht zum kaufen gibt.

Kurz gesagt, ohne Intel hätte der Linux-Kernel den Patch nicht.

natürlich hätte linux den patch ohne intel nicht - es ist ja immerhin ein intel-hardware-feature, das daher auch von intel implementiert wurde. und natürlich kann man das erst nutzen, wenn es auch hardware dafür gibt - sowohl unter linux als auch windows. dass neue befehlserweiterungen vom kernel unterstützt werden müssen, bevor userspace-anwendungen sie verwenden können, ist ja nun auch nichts neues - die frage ist, warum windows dafür einen schalter braucht und das nicht transparent geht.

 

[Land_Kind]

Es gab zu diesem Thema ja mal einen ansprechenden (jedenfalls für mich als Laien) Artikel in auf Igors Lab, welcher APX und AVX10 gar als technologischen Befreiungsschlag für x86 bezeichnet hat. Besonders Entwickler sollten in den kommenden Jahren auch davon profitieren können.
Die Profis hier im Forum können jedoch bestimmt besser als ich beurteilen, ob dem tatsächlich so ist.

 

[Nightspider]

Wenn die Register mit APX effizienter genutzt werden können, sich die Register vergrößern und der Cache entlastet wird, dürften doch auch Games (gut?) davon profitieren oder?

Man sieht ja schon an Benchmarks das größerer Cache viel Einfluss auf die CPU Leistung hat. Wenn durch die größeren, effizienteren Register vielleicht 10% (geraten) der Cache Zugriffe abgefangen werden können, dann dürfte man das an den FPS definitiv merken.

Wobei bei Games halt die Kerne auch untereinander schnell kommunizieren müssen und auf die Ergebnisse von anderen Kernen warten, wo die Register innerhalb eines Kernes nichts bringen.

Bin aber kein Programmierer und höre dazu gerne Input von euch.

 

[Yosup]

Der Thread hier könnte als Anschauungsmaterial in der Psychologie dienen, darüber, wie Unwissenheit zu Vorurteilen, Überheblichkeit und Ablehnung führt. Unfassbar, was manche hier so absondern. Sich nicht mal mit den Basics dahinter befasst haben, aber sofort eine stark ausgeprägte Meinung zu absondern.

 

[greg86]

Leider steht auch in diesem Artikel nicht ob das zu bereits optimierte Routinen im Betriebssystem/mitgelieferten Anwendungen führt oder die reine Befähigung des Userlands für APX ist.

 

[ruthi91]

natürlich hätte linux den patch ohne intel nicht - es ist ja immerhin ein intel-hardware-feature, das daher auch von intel implementiert wurde.

Vorallem ist es Teil der x86 ISA und daher nicht nur "Intel Intel Intel".

die frage ist, warum windows dafür einen schalter braucht und das nicht transparent geht.

Wieviel transparenter als mit einem Schalter willst du es denn sonst machen?
Wahrscheinlich stehen bei Microsoft Testgeräte mit Novalake oder Microsoft baut für die Intel Ingenieure gerade diese Option in die Windows Insider ein damit die im eigenen Haus testen können.

 

[Bigfoot29]

@greg86 : Vermutlich, weil das niemand aktuell weiß. Weil, wie gesagt... ohne entsprechende CPU tut das Flag erstmal gar nix.

Regards, Bigfoot29

 

[Fighter1993]

nova Lake? Hatten wir nicht schon früher ein Nova Lake oder täuschen mich da diese ganzen Lakes einfach nur?

Bei Intel blickt man doch schon lange nicht mehr durch…evt liegt es auch daran das Nova Lake gefühlt vor 3 Jahren angekündigt wurde.

 

[nomika]

Also eine Funktion in einer Hardware, die es noch nicht wirklich gibt. Und wenn es sie gäbe, wäre sie die nächsten Jahre für viele zu teuer. Also warten wir, bis es die Hardware gibt zu einem Preis, der bezahlbar ist. Obs dann noch Win11 gibt?

 

[DevPandi]

Besonders Entwickler sollten in den kommenden Jahren auch davon profitieren können.

Ich will dazu mal anmerken, dass der Artikel auf Igorslab an der Stelle teilweise doch ein etwas "zu klassisches" Bild von Software-Entwicklung zeichnet und daher auch etwas verfälschend ist.

In der Regel kann man in LLVM und GCC am Ende gerade solche Erweiterungen durch ein gesetztes Flag aktivieren und muss sich um eigentlich nichts mehr kümmern. Wirklich mit AVX10 sowie APX befassen muss man sich erst, wenn man entweder Compiler-Entwickler ist, oder wirklich spezielle Bibliotheken entwickelt und dort dann auch gezielt Mikro-Optimierungen vornehmen muss. Im großen Alltag interessiert das allerdings nicht.

Die Profis hier im Forum können jedoch bestimmt besser als ich beurteilen, ob dem tatsächlich so ist.

Kommt an der Stelle darauf an, was du mit profitieren meinst. In den meisten Fällen befasst man sich als Entwickler mit solchen Erweiterungen auf CPU-Ebene überhaupt nicht, weil diese Erweiterungen überhaupt keine Relevanz haben.

In einem Programm schreibe ich let var1 = var2 * var3 + var4. Vollkommen unabhängig davon, ob die CPU nun klassisches "x86" ist, oder dann APX kann. Der Compiler übersetzt das. Wenn ich sowas noch in Schleifen oder an andere Stelle mache, baut ein Compiler ggf. auch noch eine Vektorisierung ein, und entscheidet dann, ob per SSE, AVX1, AVX2, AVX512 oder dann AVX10.1/10.2.

Als Entwickler ist man in der Regel bemüht passende Bibliothekn zu nutzen - wie z.B. bei Apple die Vector-API in Swift: https://developer.apple.com/documentation/accelerate/working-with-vectors

Das geht dann sogar soweit, dass hier der Compiler ZUSAMMEN mit dem OS entscheiden, ob hier nun CPU oder gar ne GPU besser wäre.

Sobald du quasi die Betriebssystem/Kernel-Ebene verlässt - und das machen quasi 99 % der Entwickler, nimmst du sowas wie APX und AVX10 "nickend" hin, arbeitest aber wie gehabt weiter. Profitieren am Ende tut das Programm, man selbst aber weniger,

Man sieht ja schon an Benchmarks das größerer Cache viel Einfluss auf die CPU Leistung hat. Wenn durch die größeren, effizienteren Register vielleicht 10% (geraten) der Cache Zugriffe abgefangen werden können, dann dürfte man das an den FPS definitiv merken.

Das Thema ist an der Stelle etwas komplexer und kann so genau nicht beantwortet werden, weil bei Spielen ein paar Sachen zusammen kommen - zum Beispiel auch die Datensynchronistation zwischen mehreren Threads, die wiederum stark vom Cache profitiert, weil Daten schneller zwischen CPU-Kernen getauscht werden.

Die CPU hat zwar am Ende weniger Load, Store, Mov Befehle, allerdings ist das keine Synchronistation über Threads hinweg. In wie weit sich das dann auf die FPS auswirkt? Keine Ahnung. Es könnte auch sein, dass die FPS kaum bis garnicht steigen, dafür aber die Effizienz besser wird.

 

[xexex]

die frage ist, warum windows dafür einen schalter braucht und das nicht transparent geht.

Du verwechselst an dieser Stelle nun mal zwei Dinge, "Linux" ist nur der Kernel dort hat man die APX Unterstützung für Apps im Usermode implementiert, damit ist noch gar nichts schneller. Bei Windows aktivierst du die APK Nutzung für Windows und damit ist nicht der Kernel, sondern das gesamte System gemeint.

Letztlich ist es ähnlich wie mit HAGS, potentiell soll es mehr Leistung bringen. Wenn es aber an einer anderen Stelle Probleme bringt, kannst du es mit einem Schalter deaktivieren. Wie die Funktion dann realisiert wird und ob es unterschiedliche Binaries geben wird, erfahren wir spätestens dann wenn die CPUs verfügbar sind.

Unter Linux wirst du dann vermutlich speziell mit APX Unterstützung kompilierte Distros brauchen, damit du die Vorteile nutzen kannst. Die Unterstützung im Kernel ist nur die Basis dafür, damit solche Binaries überhaupt ausgeführt werden können.

 

[DKK007]

Muss dafür der Entwickler wie bei AVX auf bestimmte Dinge achten, oder reicht es da ein Compiler-Flag zu setzen?

Ergänzung (Gestern um 11:51)

Aber genauso wie damals wird sich zeigen: Software, die APX verwenden kann, wird es tun, die die es nicht kann, wird es lassen. Linux wird den Vorteil haben, dass man große Teile des Software-Parks durch die neuen Compiler jagen kann und ähnlich wie bei aktuell CachyOS modernisierte Binärpakete auf die neuen CPUs zugeschnitten liefern zu können. (Aktuell läuft sämtlicher Linux-Code auch auf Rechnern mit klassischer AMD64-Erweiterung. Ich bin mir nicht sicher, ob AVX2 auch Pflicht ist...)

Gibt es einen Fallback für ältere CPUs, oder braucht es dann getrennte Pakete wie bei 32/64 Bit?

 

[Land_Kind]

Also eine Funktion in einer Hardware, die es noch nicht wirklich gibt. Und wenn es sie gäbe, wäre sie die nächsten Jahre für viele zu teuer. Also warten wir, bis es die Hardware gibt zu einem Preis, der bezahlbar ist. Obs dann noch Win11 gibt?

Neues braucht immer seine Zeit (hier wird das noch ein paar Jahre hin sein), bis jemand davon profitieren kann.
Und hier braucht es eben erst mal passende Hardware, ein dafür angepasstes OS und evtl. auch dafür geschriebene Software. Irgendwer muss halt anfangen. Linux und MS tragen ihren Teil dazu bei und das ist gut so...

 

[DKK007]

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.

Wenn man Dinge in den Registern halten kann, spart man sich eben den Zugriff auf den deutlich langsameren RAM.

 

[0x8100]

Wieviel transparenter als mit einem Schalter willst du es denn sonst machen?

mit "transparent" war hier gemeint, dass das system auch selbst feststellen kann, ob apx unterstützt wird - warum muss der user das über einen schalter machen?

Bei Windows aktivierst du die APK Nutzung für Windows und damit ist nicht der Kernel, sondern das gesamte System gemeint.

wahrscheinlich - noch macht der schalter ja gar nichts. aber auch hier die frage: warum braucht es dafür einen schalter? kann das system bei vorhandensein der erweiterungen auch selbst machen.

 

[xexex]

aber auch hier die frage: warum braucht es dafür einen schalter?

Letztlich ist es ähnlich wie mit HAGS, potentiell soll es mehr Leistung bringen. Wenn es aber an einer anderen Stelle Probleme bringt, kannst du es mit einem Schalter deaktivieren.

Glaubst du wirklich ein System und Apps mit APX Unterstützung, werden zu 100% mit älterer Software problemlos zusammen laufen? Wird vielleicht für 99% der Software zutreffen, für das eine 1% hast du einen Schalter.

 

[DevPandi]

Muss dafür der Entwickler wie bei AVX auf bestimmte Dinge achten, oder reicht es da ein Compiler-Flag zu setzen?

In der Regel setzt du das als Flag.

Gibt es einen Fallback für ältere CPUs, oder braucht es dann getrennte Pakete wie bei 32/64 Bit?

Du kannst passende Binaries in LLVM, GCC und co erstellen, die entsprechend zum Start abfragen, was die CPU kann und dann entsprechend entweder den einen oder anderen Tree nutzen. Im Endeffekt ist im Binary dann ein "Switch", der an den passenden Stellen entscheidet, ob nun der "neue Code" genutzt wird, oder der Alte.

 

[foofoobar]

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.

Das ist die Ebene auf der ein Compiler Register allokiert und nutzt.
Ein Linker hat keine Kenntnis von Registern.

Funktionen sind eine Grenze für den State im Prozessor. Wäre das anders könnte man den Code nicht linken.