News Mehr FPS in Spielen: Ryzen-Optimierungen per Patch auch für Windows 11 23H2

[Dai6oro]

@Cris-Cros

Wenn du alle updates automatisch instalierst hat er es wohl gestern installiert, kannst ja im Verlauf nachprüfen:

Wenn nicht, dann müsste es dir hier angeboten werden zum installieren:

 

[Prof-Falmer]

3000 er Test wären schick, aber hey alles an plus wird mitgenommen. Aufgerüstet wird, wenn meine gewünschten Spiele mit guten (nicht Ultra) Einstellungen nicht mehr wirklich laufen.

 

[Cavaille]

🙄

AMD und Microsoft arbeiten (sicher nicht nur) bei der XBOX (S/X) bereits zusammen - trotzdem ist es nicht Aufgabe Microsofts, das Betriebssystem für alle 12423634 unterstützten CPUs, Grafikkarten, Chipsätze, unzählige Agesa Updates (und nochmal so viele Kombinationen davon) zu optimieren - hier muss AMD schon mitwirken, was ja auch passiert.

Das Microsoft-Gebashe wird wohl aber trotzdem nie ausbleiben (an die Leute, die sich mit Händen und Füßen an Windows XP/7/10 festklammern, obwohl der Rest der Welt trotz Upgrade nicht untergegangen ist).

Vermutung bedeutet, dass diese auch falsch sein kann. Aber in diesem Fall halte ich es für wahrscheinlich, dass der Grund für Nichtoptimierung schlicht wirtschaftliche Interessen gewesen sind

Und ich finde schon, dass Microsoft dafür sorgen muss, ein Betriebssystem auf allen Architekturen lauffähig zu machen. Sie wollen es ja verkaufen bzw. dafür sorgen, eine Plattform für ihre eigenen Produkte bereitzustellen. Damit das funktioniert, muss es laufen. Außerdem: MS hält so gerne den Umweltschutz hoch und wie ihr OS dazu beiträgt, den zu gewährleisten. Da ist es ein wenig ironisch, wenn sie nicht ausreichend für bestimmte CPUs optimieren, damit Leistung verschenken für die aber (wahrscheinlich) die selbe Menge Strom verbraucht wird wie bei vorhandener Optimierung.

Ich will MS auch überhaupt nicht bashen (benutze es ja selbst - mehrfach). Aber sie sind auch ein Wirtschaftsunternehmen und sie müssen auf ihre Kunden eingehen, ob sie das wollen oder nicht.

 

[Nagilum99]

Das ist eine sehr seltsame Anwendung des Begriffes von IO im Kontext von Software.

Aber wir reden hier doch vom Chip, nicht von Software?
Der Artikel handelt davon, dass die Optimierungen der Sprungvorhersage besser funktionieren. Das ist eine Hardware Funktion. Ich kann mir nicht mal vorstellen, was man inzwischen am Scheduler basteln muss, damit die Funktionseinheit (besser) funktioniert.
Wobei natürlich das ständige rumgehüpfe vieler Tasks über den Windows Scheduler für die Caches der Supergau sind. Den Mist hab ich nie verstanden.

Warum denn nicht? ein Bruteforce Algorithmus passt locker in einen Cache moderner CPUs, dazu hohe Daten- und Instruktionslokalität. Das fliegt dann allemals beim context switch raus ;-)
Und RAM-Bedarf hat man generell egal ob es im Cache läuft oder nicht. Jedes Programm wird vor der Ausführung zuerst mal in den RAM geladen.

Der Algorithmus selber mag rein passen, aber die Daten, auf die permanent zugegriffen werden muss, blähen sich auf. Ich weiß nicht wie die Technik im Speziellen funktioniert, ich weiß nur, dass der Algo so aufgebaut ist, dass die Berechnungen viel RAM benötigen. Deswegen wurde Ethereum ja z.B. lange Zeit nicht auf FPGAs berechnet: Die Hardware war zu teuer.
Es ist z.B. nicht möglich mit einer Quadro P5000 (16 GB Speicher) die Wallet zu bruteforcen. Zu viele CUs, zu wenig Speicher pro CU. IIRC waren pro CU 512 oder mehr MB speicher nötig.
Ich hab das mal auf einem älteren Dual Xeon laufen lassen: Lausige 24 Hashes/s waren drin. (ja, ich hab 'n altes Wallet und kenn das Passwort nicht - wenn die Dinger noch mal richtig steigen lohnt es vielleicht da mehr Arbeit zu investieren).

 

[mscn]

Aber in diesem Fall halte ich es für wahrscheinlich, dass der Grund für Nichtoptimierung schlicht wirtschaftliche Interessen gewesen sind

Und warum hat sich das plötzlich geändert? Hat AMD das Portmonnaie geöffnet oder konnten sie eher etwas Code/Dokumentation beisteuern, damit Microsoft den Kernel/Scheduler anpassen kann?

Und ich finde schon, dass Microsoft dafür sorgen muss, ein Betriebssystem auf allen Architekturen lauffähig zu machen.

Haben sie und tut es. Ich habe dafür mal meinen uralt HP Mini 210 3050SG rausgekramt (Intel Atom N570 2C/4T, 2GB RAM mit einer SanDisk SSD). Auf dem Teil läuft Windows 10 22H2 - vermutlich könnte ich hier noch weiter "hoch", was das System sicher nicht benutzbarer macht.

Der Punkt ist: die Unterstützung der Hardware seitens Microsoft/Windows, denn von HP bekomme ich keine Treiber mehr, schon gar nicht für Betriebsssysteme neuer als Windows 7. Das gleiche OS unterstützt von da an (oder älter) bis auf den heutigen Tag so ziemlich JEDE Hardware. "ouf-of-the-box". Dass sie dann nicht hochoptimiert am Limit läuft, ist doch nicht Microsofts Versagen.

nicht ausreichend für bestimmte CPUs optimieren

Wie sollten sie das tun, wenn AMD das offensichtlich zum Launch selbst nicht hinbekommt? Wozu bräuchte es die 43242 Agesa Updates sonst? Und woher soll Microsoft en détail wissen, wie AMDs Prozessoren zu optimieren sind?

Aber sie sind auch ein Wirtschaftsunternehmen und sie müssen auf ihre Kunden eingehen, ob sie das wollen oder nicht.

Da gibt es keinen Zusammenhang. Beispiel? Apple. Die geben NICHTS auf die Bedürfnisse der Kunden, sei es USB-C, Touchbar, das potenteste Tablet der Welt, kastriert durch iPhone OS - es ist ihnen schlicht egal und die Leute kaufen es (der Erfolg gibt ihnen Recht). Erst wenn die Zahlen nicht mehr so blumig sind, wird gehandelt.

Aber doch nicht, weil sie das Interesse ihrer Kunden im Blick hätten.

Edit: auch NVIDIA hätte hier als Beispiel getaugt - ohne eine einzige Zeile an Erklärung.

 

[mibbio]

Und warum hat sich das plötzlich geändert? Hat AMD das Portmonnaie geöffnet oder konnten sie eher etwas Code/Dokumentation beisteuern, damit Microsoft den Kernel/Scheduler anpassen kann?

Vielleicht auch einfach, weil jetzt bei Zen 5 die Tester auf das Problem gestoßen sind und damit dann auch von der Presse drüber berichtet wurde. Zen 3 und Zen 4 sind ja, wenn auch weniger stark, ebenfalls davon betroffen. Da hat es aber Niemanden interessiert, weil es keinem aufgefallen ist - die Benchmarks haben sich in der Regel mit dem gedeckt, was AMD beworben hat. Bei Zen 5 ist jetzt aber aufgefallen, dass die unabhängigen Benchmarkwerte schlechter sind als die Angaben von AMD und die mit Adminrechten plötzlich wieder halbwegs passen. Also sind die Leute (und auch AMD und Microsoft) dem mal nachgegangen, was bei Adminrechten unter Windows anders ist als ohne Adminrechte.

 

[mscn]

...

Alles schön und gut aber was hat das damit zu tun, Microsoft müsse (proaktiv) irgendwas optimieren?
Wieso sind im Zusammenhang mit Intel solche "Probleme" nicht bekannt?

Bezeichnend ist, dass das jetzt erst auffällt und auch rückwirkend Folgen hat.
Wirklich Vertrauen weckt das in mir nicht, denn das könnte genauso gut in die andere Richtung laufen und die Performance negativ beeinflussen.

die Angaben von AMD und die mit Adminrechten plötzlich wieder halbwegs passen

Darüber lasse ich mich gar nicht erst aus. Man sieht hier ja gut, wie kontrovers das diskutiert wird.
Zwei Seiten - beide beanspruchen für sich Recht zu haben.

Kurz: Ich wollte das Microsoft-Blaming nicht unkommentiert stehen lassen.

 

[Denniss]

es wird ja auch gemunkelt das M$ imRahmen von Meltdown/Spectre Fixes diverse Caches geleert hatte wobei das bei AMD nicht nötig gewesen wäre.

 

[KitKat::new()]

Aber wir reden hier doch vom Chip, nicht von Software?

ne, wir reden von Software:

Wenn ein Programm nur Berechnungen ausführt, ohne dabei Windowsfunktionen zu nutzen (IO, Grafik, Fenster, ...)

Der Algorithmus selber mag rein passen, aber die Daten, auf die permanent zugegriffen werden muss, blähen sich auf. Ich weiß nicht wie die Technik im Speziellen funktioniert, ich weiß nur, dass der Algo so aufgebaut ist, dass die Berechnungen viel RAM benötigen.

Welche Daten sollen das sein?
Der erwartete Hash, der sicher nicht größer ist als 1 KB?
Die Daten mit denen der Hash gebruteforced wird? Die sind i.d.R. <100 Byte, weil darüber brauchst du gar nicht anfgangen mit dem Bruteforcen, weil du dann beim Hitztod des Universums noch nicht fertig wärst ;-)

Bleibt die Option, dass die Hashfunktion selbst sehr viele Daten produziert und verwertet. Ich war mal so frei das mit der Standardhashfunktion in Rust zu testen:
https://godbolt.org/z/vdodc6h4b
Ergebnis: Keine extra Speicherallokationen auf dem Heap, das heißt als Speicher wird maximal der Stack genutzt, der z.B. auf Windows auf 1 MB begrenzt ist, also wesentlich kleiner als der Cache der CPUs (die Hashfunktion wird die 1MB auch garantiert nicht annähernd ausreizen).

Es ist z.B. nicht möglich mit einer Quadro P5000 (16 GB Speicher) die Wallet zu bruteforcen. Zu viele CUs, zu wenig Speicher pro CU. IIRC waren pro CU 512 oder mehr MB speicher nötig.
Ich hab das mal auf einem älteren Dual Xeon laufen lassen: Lausige 24 Hashes/s waren drin. (ja, ich hab 'n altes Wallet und kenn das Passwort nicht - wenn die Dinger noch mal richtig steigen lohnt es vielleicht da mehr Arbeit zu investieren).

Hashfunktionen, die mindestens 512 MB Speicher benötigen, gibt es wahrscheinlich nur in der Crypto-Coin Welt, in der Versucht wird möglichst viel Ressourcen zu "nutzen" ;-)

 

[DarkSoul]

Wie erwartet hat das Update auf meinen 3900x keinerlei Auswirkungen, die Benchmark-Abweichungen sind in der üblichen Toleranz.

Nach dem Update auf die neuesten AMD-Chipsatz-Treiber (v6.07.22.037, die Version vorher dürfte nur ein paar Wochen/Monate alt gewesen sein) für meine Board komme ich auf Punkte zwischen etwa 2424 und 2451 statt etwa 2390 bis 2409 Punkte bei 3DMark "Steel Nomad". Also doch ein Zuwachs von 10 bis 20 %, allerdings kann ich jetzt im Nachhinein natürlich nicht sagen, ob das vom MS-Update oder doch von AMD kommt. Mein BIOS ist bereits das aktuellste gewesen.

 

[mibbio]

Alles schön und gut aber was hat das damit zu tun, Microsoft müsse (proaktiv) irgendwas optimieren?
Wieso sind im Zusammenhang mit Intel solche "Probleme" nicht bekannt?

Da musste seitens Microsoft doch gar nicht (proaktiv) optimiert werden, sondern im Grunde nur ein "Bug" in Windows behoben werden, nachdem der aufgefallen ist.

Die Ursache für das Problem lag in den Mitigations für Meltdown & Spectre in Windows in Verbindung mit der Branche-Prediction der CPUs. Die Mitigation ist von Microsoft so implementiert, dass das OS regelmäßig viele der Cache-Daten der CPU verwirft. Das betrifft potentiell auch Cache-Daten der Branch-Prediction. Jetzt verwendet AMD im Vergleich zu Intel recht große Caches/Buffer und Instruction Window für die Branch-Predicition. Das hat zwar auf der einen Seite potentiell einen größeren Performancegewinn als bei Intel, auf der anderen Seite geht den Ryzen aber auch deutlich mehr Performance verloren, wenn die Cache-Daten ständig gelöscht werden. Intel-CPUs stören sich dagegen recht wenig an dem ständigen Gelösche, weil die bei der Branch-Prediction ohnehin viel weniger "auf Vorrat" berechnen.

Bei Prozessen mit Admin-Rechten ist die Mitigation gegen Meltdown/Spectre dagegen teilweise deaktiviert, weil die aufgrund der ohnehin höheren Rechte sinnfrei wären. Dadurch werden mit Adminrechten der Branch-Prediction auch nicht mehr laufen Daten weggelöscht und die Ryzen performen, wie sie sollen.

Der Fehler seitens Microsoft bestand jetzt darin, dass dieser Mitigation-Mechanismus einfach pauschal aktiviert war, egal welche CPU überhaupt im System steckt. Nun hat sich rausgestellt, dass die Ryzen-CPUs diese Mitigation eigentlich gar nicht benötigen und per Patch hat Microsoft es so geändert, dass die nur noch aktiv sind, wenn eine Intel-CPU im System steckt.

So zumindest der bisherige Kenntnissstand zu dem Problem und der Ursache.

 

[Nagilum99]

ne, wir reden von Software:

Aber was hat das mit den Optimierungen für die Sprungvorhersage (in Hardware) zu tun?

Hashfunktionen, die mindestens 512 MB Speicher benötigen, gibt es wahrscheinlich nur in der Crypto-Coin Welt, in der Versucht wird möglichst viel Ressourcen zu "nutzen" ;-)

Tatsächlich liegst du hart daneben. Es ist durchaus nicht unclever bestimmte dinge bewusst ressourcenlastiger zu machen, damit ein solcher Angriff deutlich erschwert wird.
In diesem Fall ist es nicht das erzeugen der coins, sondern das knacken der Verschlüsselung der Wallet.
AFAIK findet sowas auch bei anderen Verschlüsselungen statt.
RAM ist heute zwar erheblich günstiger, aber die Kosten für solche Angriffe steigen dennoch massiv.

 

[KitKat::new()]

Aber was hat das mit den Optimierungen für die Sprungvorhersage (in Hardware) zu tun?

gute Frage

Tatsächlich liegst du hart daneben.

Ich warte auf Beispiele

Es ist durchaus nicht unclever bestimmte dinge bewusst ressourcenlastiger zu machen, damit ein solcher Angriff deutlich erschwert wird.

Allenfalls wenn man weiß, dass der Schlüssel schon unsicher ist -> Band aid statt echte Lösung
In dem Fall ist es eher sinnvoller den Schlüssel länger zu machen (verbessert die Sicherheit exponentiell mit der Schlüssellänge) als die Zugänglichkeit zu Verschlüsselung zu erschweren indem man fürs Hashen 512 MB an Ressourcenverbrauch fordert.

AFAIK findet sowas auch bei anderen Verschlüsselungen statt.

bcrypt ist dort der defakto Standard und benötigt insgesamt 4KB. Da liegen 5 Größenordnungen dazwischen.

Anyways, es sollte widerlegt sein, dass man beim Bruteforcen von hashes zwangsweise mehr Daten zu nutzen muss als in einen CPU Cache passen.

 

[Northstar2710]

wird keines vorgeschlagen

schau doch einfach in deinen update verlauf ob da ein entsprechendes update mit der bekannten NR durchgeführt wurde.

 

[Miuwa]

Und warum hat sich das plötzlich geändert? Hat AMD das Portmonnaie geöffnet oder konnten sie eher etwas Code/Dokumentation beisteuern, damit Microsoft den Kernel/Scheduler anpassen kann?

Frag MS, aber der größere Marktanteil von AMD im Vergleich zu vor 5 Jahren wäre auch ne mögliche Erklärung.

Ergänzung (29. August 2024)

Die Ursache für das Problem lag in den Mitigations für Meltdown & Spectre in Windows in Verbindung mit der Branche-Prediction der CPUs. Die Mitigation ist von Microsoft so implementiert, dass das OS regelmäßig viele der Cache-Daten der CPU verwirft. Das betrifft potentiell auch Cache-Daten der Branch-Prediction.

Ist das inzwischen Fakt oder immer noch Vermutung? Falls ersteres: Gibt's dazu ne Quelle?

 

[mibbio]

Gibt's dazu ne Quelle?

Einmal das von mir in Beitrag #198 verlinkte Video und dann noch etwas detailiert ein Link im Beitrag #245 von Taxxor.

Hab das beides oben nur noch nochmal auf Deutsch zusammengefasst.

 

[Debian User]

Lohnt sich dieser Performancegewinn genug um von Win10 auf Win11 zu wechseln?

Ich würde auch ohne Performancegewinn auf Windows 11 wechseln.
Es ist immer noch scheiße, aber weniger als Windows 10.

 

[Mensch_lein]

Windows-Bashing... schallend lachen muss.

Sorry, aber man merkt Fehler an und dann ist das plötzlich Bashing? Man kann es auch übertreiben!

 

[Araska]

Es ist immer noch scheiße, aber weniger als Windows 10.

Okay... ich halte Win11 eher für ganz anders scheiße als Win10, aber jedem das Seine.

Der stetige Wandel zu noch mehr Telemetrie, noch mehr Werbung im OS, noch mehr Zwang zur Cloud (wo MS dann nach US-Recht mit deinen Daten macht, was sie wollen)... ist ganz viel nicht meins.

Die fortwährenden Änderungen am UI und den Einstellungen, die oft genug zwar nicht besser, aber dafür schon einmal um ihrer selbst Willen anders sind - sagte ich bereits 'ganz anders scheiße'?

 

[Blende Up]

Ein wahres Wort gelassen ausgesprochen
Und (wahrscheinlich wieder) ab ins Aquarium..