Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
TestWindows 11 24H2 & 23H2 Update: Wie groß ist das Leistungsplus für AMD Ryzen 9000 in Spielen?
Rein vom Bauchgefühl her interessiert es auch 90% der Spieler nicht. Bei der nicht Spieler Population sind's wahrscheinlich 99,99...%
Mich interessiert es übrigens auch nur die technischen Hintergründe, aber nicht ob's mir beim Spielen was bringt. So wie ich mich kenne würde ich selbst 10% mehr fps nicht merken
Mein Bauchgefühl spricht etwa von der Hälfte, aber was soll man über Bäuche streiten n
Miuwa schrieb:
Mich interessiert es übrigens auch nur die technischen Hintergründe, aber nicht ob's mir beim Spielen was bringt. So wie ich mich kenne würde ich selbst 10% mehr fps nicht merken
Dito. 60fps cap, also gehts bei mir nur um 60fps oder nicht. 5, 10 oder gar 20% mehr fps wären daher immer nur unter 60fps interessant, da sinds dann aber selbst im Best Case 59fps und 20%, also laut Adam Riese 11,8fps. Allerdings verpuffts in dem Fall. Und hab ich 40fps fehlen mir utopische 50%, das erreicht kein Tweak. Insofern ists für mich auch nur aus technischem Interesse spannend.
Bis ja bis ein Kauf ansteht. Dann will ich natürlich das beste P/L, und auch wenn ich 5% nicht merke, sagt der gesunde Menschenverstand, damit reicht die Leistung auch etwa 5% länger .
Leider hat Heise du nur eine Vermutung wie ich sie auch aufgestellt habe. Aber sie haben keinerlei Begründung wieso sie diese Vermutung für richtig halten. Und sie beschreiben Branch Prediction falsch. Muss man sehen wie glaubwürdig das also ist, wenn sie nicht auf einen Experten verweisen können und es nur falsch wiedergeben. Und ihre "Indizien" nicht benennen wollen.
Edit: Ach und Thread-Wechsel scheint der Heise Autor auch nicht zu verstehen. Oder den Begriff leicht zu missbrauchen.
Ok…
Hab mir das Video inzwischen angeschaut.
Ich lass mich jetzt nicht darüber aus, dass immer mehr Leute halblebige Parcours laufen lassen. Aber…
Wenn ich zwei mal das selbe mache und zwei mal was anderes bei raus kommt, dann gebe ich keine Tipps, wenn ich selbst nicht verstehe was da gerade passiert.
Es könnte auch bedeuten, das der PC und das OS inzwischen eine kaum noch verstandene, immer weniger beherrschbare Blackbox bilden, bei der man solange herumfrickeln muß, bis man durch Ausdauer und/oder Glück einen guten/besseren Output bekommt.
Das liebe DRM... Da HVIC an/aus auch jeweils ein "Prozessorwechsel ist", waren die letzten Benchmarks erst vor 5 Minuten im Kasten. Daher erst morgen gegen Mittag.
Och, tatsächlich sind Leute, die zuviel Fachkenntnis haben, oft garrnicht so hilfreich, weil die sich nicht in die typische Nutzerrolle hineindenken können und dann kommt die Botschaft nicht an, oder wird gar nicht erst gesendet.
Level1Techs hat sogar berichtet, das andere Windows Features den gleichen/ähnlichen Overhead hinzufügen können. Und deshalb im BIOS den Hardwaresupport dafür ausschalten zuverlässiger ist als nur in Defender.
Wobei das soweit ich weiß alles Optionen waren (Hyper-V, WSL etc.) die ab Werk nicht installiert sind. Also weniger ein Problem für den schlichten Tester der frisch aufgesetzt hat. Aber durchaus für normal genutzte PCs.
So wie ich das verstehe kann man ja VBS selbst nicht explizit Ausschalten mit den Optionen. Sondern nur eines der Features die darauf aufbauen, dass den größten Overhead erzwingt (HVCI). Und VBS kann dann trotzdem an bleiben und andere Systeme die die Virtualisierung nutzen können dann vllt ähnliche Overhead Effekte verursachen. Vllt sogar der gleiche Code, nur halt aus anderen Gründen als HVCI oder so.
So wie ich das verstehe kann man ja VBS selbst nicht explizit Ausschalten mit den Optionen. Sondern nur eines der Features die darauf aufbauen, dass den größten Overhead erzwingt (HVCI). Und VBS kann dann trotzdem an bleiben und andere Systeme die die Virtualisierung nutzen können dann vllt ähnliche Overhead Effekte verursachen. Vllt sogar der gleiche Code, nur halt aus anderen Gründen als HVCI oder so.
So weit ich das verstehe ist VBS der Überbegriff. Dass du Virtualisierung und den Hypervisor für Sicherheit nutzen kannst. Erfordert, dass die CPU gewisse Virtualisierungs-Features hat.
Was du jetzt aber für Sicherheitsdinge in diesen verschiedenen virtualisierten und damit isolierten Containern machst ist eine andere Sache. Und eine davon ist HVCI. Du brauchst VBS Support also damit HVCI eine Option ist. "VBS" selbst heißt du hast die Möglichkeit Teile in virtuelle Container auszulagern, was einen kleinen Virtualisierungs-Overhead mit sich bringt, wenn du diese Teile dann von wo anders aus aufrufst / nutzt. Aber wenn du nichts nutzt, dass ausgelagert wird, gibt es auch keinen erhöhten Overhead durch die Virtualisierung.
Und der Overhead kommt in erster Linie bei jedem Übergang in und aus dem virtuellen Container. Und dann kommt noch dazu wenn du zusätzliche Checks machst, die sonst gar nicht gemacht wurden, weil sie ohne die Isolierung gar keinen Sinn gemacht haben zu tun.
Aber ich habe mich noch nicht damit beschäftigt, welche Funktionen Windows automatisch mit VBS nutzt sobald es verfügbar ist und wofür es keine Schalter gibt.
Und wenn du im BIOS die Virtualisierungs-Features komplett abschaltest, geht halt gar nichts das Virtualisierung nutzt. Und dann kann es keinen Overhead geben weil gewisse Dinge in virtuelle Container ausgelagert werden.
Wenn 24H2 mal offiziell ausgerollt ist, wäre es super, wenn es ein CB-Tutorial gibt, wie man Win11 als Spielerechner optimal einrichtet. Wann wie was aktiviert/deaktiviert wird, wann Treiber (Reihenfolge), wann Updates etc.
Dann wird man endlich seine Penis-Selfies schneller wiederfinden:
Geht es nach Informationen von The Verge, möglicherweise gar nicht. Denn auch wenn die aktuelle 24H2-Version von Windows 11 noch nahelegt, dass sich Recall künftig einfach deaktivieren lässt, scheint es sich Microsoft anders zu überlegen. Auf Nachfrage bei Microsoft heißt es nämlich: "Wir sind uns bewusst, dass Recall fälschlicherweise als Option unter dem Dialog 'Windows-Funktionen ein- oder ausschalten' in der Systemsteuerung aufgelistet ist." Und: "Dies wird in einem kommenden Update behoben werden."
Und wenn du im BIOS die Virtualisierungs-Features komplett abschaltest, geht halt gar nichts das Virtualisierung nutzt. Und dann kann es keinen Overhead geben weil gewisse Dinge in virtuelle Container ausgelagert werden.
Context-Switches waren schon immer teuer, Spectre und Meltdown haben die noch teurer gemacht.
Ergänzung ()
Ray519 schrieb:
Leider hat Heise du nur eine Vermutung wie ich sie auch aufgestellt habe. Aber sie haben keinerlei Begründung wieso sie diese Vermutung für richtig halten. Und sie beschreiben Branch Prediction falsch. Muss man sehen wie glaubwürdig das also ist, wenn sie nicht auf einen Experten verweisen können und es nur falsch wiedergeben. Und ihre "Indizien" nicht benennen wollen.
Edit: Ach und Thread-Wechsel scheint der Heise Autor auch nicht zu verstehen. Oder den Begriff leicht zu missbrauchen.
Ich finde die Thesen aus dem Heise Artikel ziemlich schlüssig, den auch ein Thread-Wechsel innerhalb eines Prozesses zieht Context-Switches nach sich.
Falls man die Contextswitches/Zeit unter Windows messen kann könnte man mal schauen ob das mit den Gewinnen einzelner Anwendungen bei dem Windows-Patch korreliert.
Ergänzung ()
Jan schrieb:
Das liebe DRM... Da HVIC an/aus auch jeweils ein "Prozessorwechsel ist", waren die letzten Benchmarks erst vor 5 Minuten im Kasten. Daher erst morgen gegen Mittag.
Nein. Spectre und Meltdown Mitigations, für Hardware die nicht grundlegend sicher dagegen war waren teuer. Gibt auch in Laufzeit günstigere Lösungen für das meiste davon.
foofoobar schrieb:
Ich finde die Thesen aus dem Heise Artikel ziemlich schlüssig, den auch ein Thread-Wechsel innerhalb eines Prozesses zieht Context-Switches nach sich.
Kontext-Wechsel ist der allgemeine Begriff. Wenn du den im selben Prozess machst, musst du nur ISA Register auswechseln. Da es im Prozess keine Isolierung der verschiedenen Threads voneinander gibt. Das ist also der leichtegewichtigste Kontext-Wechsel den du machen kannst. Nicht viel mehr Arbeit als ein Call mit sehr vielen, zu sichernden Registern.
Zwischen Prozessen zu wechseln erfordert auch den Wechsel von anderen Dingen, wie zB der Konfiguration vom Virtual Memory. Und hier ist es wo du evtl Caches invalidieren musst, wenn die nicht in Hardware zwischen verschiedenen Prozessen unterscheiden um nichts zu leaken.
Außerdem sage ich doch in meinem Text wo das Problem bei Heise ist. Nicht in der Idee an sich. So etwas ähnliches hatte ich vorher hier auch schon als Idee erwähnt. Nur geht Heise viel weiter und versucht einiges an Hintergründen zu erklären. Wie als hätte es einen wichtigen Grund das zu erklären. Aber sie begründen an keiner Stelle wie sie auf die Idee kommen. Abgesehen von "das wäre eine Möglichkeit die uns einfällt". Und das Problem daran ist eben, dass sie in den Hintergründen einiges falsch beschreiben. Und dann kann man eben nicht mehr glauben, dass der Autor einen guten Grund hatte für was er schreibt.
Wenn der Autor schon nicht versteht was exakt einen "Thread-Wechsel" unterscheidet zwischen einem Kontextwechsel zwischen Kernelspace und Userspace und Branchprediction auch völlig falsch definiert wird, wie will er dann einen "educated guess" begründen? Und noch dazu ganz ohne Begründung, wenn alles was du hast ein "der wird schon genügend Ahnung haben und wissen was er tut" ist.
Aber ja, grundsätzlich ist es möglich dass bei Kontext-Wechseln zwischen Privilegienstufen bisher zu aggressiv vorgegangen wird und entweder unnötige Sicherheitschecks oder Cache-Invalidierungen durchgeführt wurden, die man sich auch sparen kann auf der passenden Hardware.
Wie haben halt null Indizien dass das die richtige Erklärung ist. Es passt zu den meisten Fakten die wir wissen, aber das war es auch schon. Passt zum Beispiel nur halb dazu dass AMD von Code-Optimierungen für ihren Branchpredictor spricht. Wenn das OS zur Sicherheit alle Branch-Analysen invalidieren würde, bei jedem Context-Wechsel, und nur nicht berücksichtigt, ob die Hardware das eh schon Prozess/Priv-Spezifisch verwaltet und damit so eine Invalidierung gar nicht mehr nötig hat, würde ich nicht akzeptieren, dass als "AMD-spezifische Code-Optimierung für Branch-Prediction" zu beschreiben.
Was hat das mit Betriebssystem zu tun? Es geht doch im Artikel genau darum das OS zu vermessen. Das Problem ist DRM, das Software blockiert. Und noch schlimmer, DRM das auf eine Einstellungsänderung anspricht, wie als hätte es die Hardware geändert, also überreagiert.
Nein. Spectre und Meltdown Mitigations, für Hardware die nicht grundlegend sicher dagegen war waren teuer. Gibt auch in Laufzeit günstigere Lösungen für das meiste davon.
Kontext-Wechsel ist der allgemeine Begriff. Wenn du den im selben Prozess machst, musst du nur ISA Register auswechseln. Da es im Prozess keine Isolierung der verschiedenen Threads voneinander gibt. Das ist also der leichtegewichtigste Kontext-Wechsel den du machen kannst. Nicht viel mehr Arbeit als ein Call mit sehr vielen, zu sichernden Registern.
Zwischen Prozessen zu wechseln erfordert auch den Wechsel von anderen Dingen, wie zB der Konfiguration vom Virtual Memory. Und hier ist es wo du evtl Caches invalidieren musst, wenn die nicht in Hardware zwischen verschiedenen Prozessen unterscheiden um nichts zu leaken.
Du musst trotzdem einmal in dem Kernel und wieder zurück, solange du Kernel-Threads nutzt was das gängige Modell ist. Thread-Wechsel fallen nicht wundersam vom Himmel.
Wenn du definierst, dass wir nur von Kernel-verwalteten Threads in Userprozessen sprechen und damit per Definition jeder der "Thread-Wechsel" immer auch einen Wechsel vom Userspace in den Kernelspace und zurück beinhaltet, ja.
Aber warum sollte man es sich so schwer machen mit so viel nicht ausgesprochenen Definition, wenn man auch einfach die passenden Begriffe nutzen kann? Es gibt auch Threads im Kernel. Und für diese Thread-Wechsel passt das eben auch nicht.
Es wäre also wesentlich treffender gewesen entweder einfach nur von Kontextwechseln zu sprechen oder wenn man es genau haben will, von Kontextwechseln vom Kernelspace in den Userspace. Weil das ist ja genau die Grenze wo man keine Informationen leaken will und sanitizen muss, was die Hardware nicht schon schützt. Und man will auch am besten nur Daten vom Kernel schützen. Daten vom selben Prozess vorher brauchen keinen Schutz.
Wenn du aber zwischen verschiedenen Prozessen wechselst, willst du quasi alles sanitizen, damit du nicht Daten vom einen Prozess in den anderen leakst. Wenn die Hardware also Zwischenstufen hat und nicht immer alles auf einmal invalidieren muss, dann spielt das sogar unter allen Annahmen von dir noch eine Rolle ob auch zwischen Prozessen gewechselt oder nicht.
Wenn du definierst, dass wir nur von Kernel-verwalteten Threads in Userprozessen sprechen und damit per Definition jeder der "Thread-Wechsel" immer auch einen Wechsel vom Userspace in den Kernelspace und zurück beinhaltet, ja.
Was ich in dem Teil geschrieben habe den du nicht zitierst hast.
Aber egal, ich habe ja Vorschläge gemacht was man messen kann um diese These zu stützen.
Einer der Windows-Menschen hier kann ja mal entsprechende Messungen machen.
.
n
