Jetzt auch mobil Kommentieren!

Benchmarks: So wirkt sich der Meltdown-Patch auf die Leistung aus

Einen Kommentar schreiben
[o1] Memfis am 05.01. 10:02
+2 -2
Was ich noch nicht verstanden habe: Warum verlangsamt der Patch die Lese- / Schreibgeschwindigkeit. Was wird da verändert?
[re:1] SunnyMarx am 05.01. 10:18
+2 -2
@Memfis: Das frage ich mich auch. Schließlich geht es doch um Arbeitsspeicher, der durch die Lücken partiell oder gar gänzlich ausgelesen werden kann. Die Festplatten des Systems haben damit doch eigentlich überhaupt nichts zu tun...
[re:2] moeppel am 05.01. 10:34
+4 -
@Memfis: Die CPU muss mehr Zyklen aufwenden um Operationen ordentlich abzusichern, ganz besonders dann, wenn Context-Switches stattfinden.

Vorher dienten diese Zyklen zur Abarbeitung der Anweisungen, nun werden sie 'verschwendet', um die Anweisungen zu verifizeiren/validieren.

Derzeit sollte man auch noch von einem 'rudimentären Fix' ausgehen, der vermutlich noch Optimierung erfahren wird. Ich würde die Zahlen erst mal alle unter Vorbehalt sehen.
[re:1] Mitsch79 am 05.01. 10:36
+3 -3
@moeppel: Aber die Leseoperation von der SSD im User-Mode sollte keine Switches verursachen, oder sehe ich das falsch?

Und genau genommen, habe ich, doch nur zwei Switches, wenn ich etwas lesen will.

Anwendung: 'Huhu Treiber, lies mal das hier ein,'
Treiber: 'Alles Klar!'
Treiber: 'Hey Kernel, gib mal Zugriff auf das Zeug'
Kernel: 'Hm, okay.' *switch*
Treiber: 'Merci, ich les dann mal das Zeug ein'
Kernel: 'Alles klar, das liegt dann hier ab $Adresse '
Treiber: 'Yo, danke bin fertig'
Kernel: 'Bis die Tage, vergiss die Adresse nicht' *switch*
Treiber: 'Hey, Anwendung, dein Zeug liegt hier $Adresse '
Anwendung: 'Firma, dankt'.

Bei 4K Random Read im Benchmark hat man die Switches dann vermutlich je Lese-Anforderung. Und das haut dann so rein? Kann ich mir irgendwie nicht vorstellen.
Und falls doch, sollte man es beim Compilieren tatsächlich zu spüren bekommen, da der Nutzen des Compilecaches flöten geht und prinzipiell tausende von kleinen Files gelesen und geschrieben werden müssen.

Andersrum, wenn es beim Lesen von der SSD so reinhauen soll, müsste es dann auch bei Games um ein vielfaches stärker zu spüren sein, denn da gibt es viel mehr Zugriffe auf die Hardware...
[re:1] LoD14 am 05.01. 10:58
+2 -1
@Mitsch79: Das Problem ist halt nur, dass ein PC selbst wenn er nicht macht, mehr macht, als nichts. Und nur wenn im User Mode eine Leseoperation stattfindet, heißt das noch lange nicht, dass sonst kein anderer Prozess im Hintergrund abläuft. Sonst stände dein PC ja komplett still, wenn eine Leseoperation durchgeführt wird.
[re:1] Mitsch79 am 05.01. 11:12
+ -2
@LoD14: Dann hättest du aber eine generelle Performanceminderung, wenn ich mal davon ausgehe, dass das was der Rechner an Verwaltung im Hintergrund tut mehr oder weniger (statistisch) immer das gleiche ist.
[re:2] 1ST1 am 05.01. 11:33
+2 -1
@Mitsch79: Deine nette (aber falsche*) Unterhaltung "Anwendung zu Kernel Treiber" zeigt doch schon das Problem... Deine Anwendung läuft in Ring 3, der Treiber als Bestandteil des Kernels in Ring 0. Manche Treiber laufen auch in Ring 1, 2 oder 3. Jedes mal wenn von 1,2,3 nach 0 wird, müssen diese Prozesstabellen jetzt nun aufwändig gerettet und getilgt werden. Beim zurückkehren vielleicht teilweise auch. Und die kommunikation läuft immer vom Anwendung über Kernel zu Treiber und auf dem selben Weg auch wieder zurück. Und manche Treiber kommunizieren über den Kernel wiederum mit anderen Treibern, z.b. der TV-USB-Stick-Treiber über den Kernel mit dem USB-Treiber. An der Stelle tritt dann der Performance-Verlust auf. In deinem Beispiel also an jeder Stelle wenn Anwendung mit Kernel spricht und Kernel mit Treiber spricht.

*falsch in sofern, weil die Anwendung mit dem Kernel spricht und der Kernel mit dem Treiber. Und das nicht nur bei Lesen von Dateien, sondern auch bei jedem Pixel was auf dem Monitor geplottet wird, jedem Byte was per Netzwerk verfunkt wird und von einem USB-Device in die Anwendung reingepumpt wird.
[re:1] Mitsch79 am 05.01. 11:42
+ -2
@1ST1: Merci :) Aber dann verstehe ich nicht, dass die Leistungseinbußen im Gaming-Fall nicht vorhanden sind, denn da ist die Kommunikation Spiel -> Kernel -> Treiber um ein vielfaches ausgeprägter, als im Fall "Lies mal 1000 Files von der SSD". Sprich da müssten viel mehr Switches passieren, da wesentlich mehr I/O-Operationen ausgeführt werden.
[re:2] 1ST1 am 05.01. 11:44
+1 -
@Mitsch79: Es wird ja nicht jedes Pixel einzeln an den Monitor übergeben, sondern der Grafikkarte wird ja eine komplette 3D-Szene mit Lichtquellen, Texturen und so weiter auf einmal übergeben, und den Rest macht die Grafikkarte selbst....
[re:3] Mitsch79 am 05.01. 11:58
+ -1
@1ST1: Ja, aber das passiert mehre hundert mal pro Sekunde. Die Grafikkarte muss Texturen laden und bekommt alle Infos für Vektoren, Shader und Transformationen, aber sie berechnet nicht die dynamischen Anteile der Szenerie. Bewegungspfade, Änderungen der Perspektive (Matrizen) kommen ja aus der Anwendung. Oder anders gesagt, der eigentlich Game-Loop läuft auf der CPU, nicht auf der Graka und die Aufforderung zum Zeichnen auch.
Deswegen sollte die Anzahl der I/O-Ops von Anwendung zu Peripherie mindestens genauso hoch sein, wie ein 4K Random Read Test. Aber zumindest so hoch, dass die Switches spürbar sind.
[re:3] Mitsch79 am 05.01. 10:35
+1 -2
@Memfis: Mir erschließt sich das auch nicht. Es geht doch letztlich um Kontext-Switches von User-Mode, nach Kernel-Mode und zurück und das hier zusätzliche Prüfungen durchgeführt werden, die dann eben Kosten verursachen. Es wäre mir neu, dass ein Benchmark einer SSD im Kernelmode liefe oder überhaupt irgendwas switchen müsste...

Ich halte die Benchmarks ehrlich gesagt erstmal für Unsinn. Bisher ist bei mir auch noch kein Patch angekommen, was auch am Norton liegen könnte. Aber genaues weiß man nicht, da MS nur von "supported 3rd-party anti virus..." spricht, aber nicht auflistet, welche das denn sind.

Wenn der Patch dann da ist, werde ich einfach mal wieder ein Android-Build laufen lassen, dann sehe ich, ob da was passiert oder nicht. Dauert es signifikant länger als 21 Minuten, dann hat der Patch reingehauen, wenn nicht dann nicht. Wobei die Buildmaschine ein Ubuntu VM unter Windows 10 ist, ich also dann doppelt in den Genuss des Patches kommen müsste (Linux Kernel und Windows Kernel) ^^

Edit: Norton hat das notwendige Update bekommen und der Windows-Patch ist nun da, installiert und hat keinerlei Einfluß auf die Performance der SSD (Samsung 960 Evo 1TB M.2).

i7-6700 / Z170

(Crystal Disk Mark)
Sequential Read (Q= 32,T= 1) : 2877.912 MB/s
Sequential Write (Q= 32,T= 1) : 1833.815 MB/s
Random Read 4KiB (Q= 8,T= 8) : 1717.455 MB/s [ 419300.5 IOPS]
Random Write 4KiB (Q= 8,T= 8) : 1574.803 MB/s [ 384473.4 IOPS]
Random Read 4KiB (Q= 32,T= 1) : 547.842 MB/s [ 133750.5 IOPS]
Random Write 4KiB (Q= 32,T= 1) : 417.720 MB/s [ 101982.4 IOPS]
Random Read 4KiB (Q= 1,T= 1) : 54.513 MB/s [ 13308.8 IOPS]
Random Write 4KiB (Q= 1,T= 1) : 147.106 MB/s [ 35914.6 IOPS]

(AS SSD)
Sequentiell:
------------------------------
Lesen: 2471,86 MB/s
Schreiben: 1821,07 MB/s
------------------------------
4K:
------------------------------
Lesen: 41,03 MB/s
Schreiben: 121,22 MB/s
------------------------------
4K-64Threads:
------------------------------
Lesen: 1410,20 MB/s
Schreiben: 1306,55 MB/s
------------------------------
Zugriffszeiten:
------------------------------
Lesen: 0,086 ms
Schreiben: 0,031 ms
------------------------------

Und auch beim Compilieren kann ich keinerlei Effekt erkennen. 21:30 Minuten für das Compilieren von LOS 14.1 für jfltexx ist normal. Auch hier würde eine Leistungsverlust der SSD von 23% beim Lesen und Schreiben kleiner Files entsprechend auffallen. Zumal vieles was an C und C++ Code zu kompilieren wäre aus dem Compile Cache käme. Zum Vergleich, das Kompilieren des gleichen Builds unter Verwendung einer HDD, dauert 55 Minuten. Die Leistung der SSD ist hier also signifikanter Performancetreiber.
[re:1] 1ST1 am 05.01. 11:39
+2 -
@Mitsch79: Der Benchmark selbst läuft im User-Mode (Ring 3), aber der Kernel macht letztendlich über diverse Treiber den Zugriff auf die SSD. Kernel und Treiber sind oft voneinander abgeschottete Prozesse, manche Treiber laufen nicht mal auf Ring 0. Und dann findet jedes Mal so ein Kontextswitch statt.
[re:4] wertzuiop123 am 05.01. 10:40
+3 -
@Memfis: "Potenziell werden Operationen deutlich langsamer, bei denen man viele kleine Dateien öffnet, beispielsweise, wenn man auf der Festplatte nach Daten sucht."

->
"The core problem with both Meltdown and Spectre lies within the CPU's cache. An application can attempt to read memory and, if it reads something in the cache, the operation will complete faster. If it tries to read something not in the cache, it will complete slower. The application can see whether or not something completes fast or slow and, while everything else during speculative execution is cleaned up and erased, the time it took to perform the operation can't be hidden. It can then use this information to build a map of anything in the computer's memory, one bit at a time. The caching speeds things up, but these attacks take advantage of that optimization and turns it into a security flaw."

https://www.howtogeek.com/338269/a-huge-intel-security-hole-could-slow-down-your-pc-soon/
[re:5] LoD14 am 05.01. 10:44
+5 -1
@Memfis: *Wenn* ich es richtig verstanden habe in einfach: Es muss der Adressraum zwischen Kernelmode-Prozessen und Usermode-Prozessen getrennt werden. Dann können die Prozesse im Usermode nicht auf Speicheradressen zugreifen, die sie nichts angehen. Also User-Mode-Prozesse kriegen eigene "virtuelle" Speicheradressen, die Kernel-Mode-Prozesse haben infolge andere Speicheradressen. Dabei passiert viel technischer Kram. Jedenfalls gibt es dann irgendwann einen Buffer, der ein Tabelle hält, wo die virtuellen Adressen der verschiedenen Prozesse (sowohl Kernel wie auch User-Mode Prozesse) auf die realen Adressen im Speicher abbildet.

Ein Prozessor wechselt beim arbeiten ständig zwischen Kernel- und User-Mode Prozessen. Damit die Trennung sauber läuft, muss dieser Buffer, der die Adressen vorhält und die Zugriffe auf Speicherinhalte beschleunigt, bei jedem wechsel zwischen Kernel und User Prozess geleert werden, damit sich kein User-Mode-Prozess die Adresse von anderen Prozessen mehr abgreifen kann.

Als muss dieser Buffer ständig geleert und neu befüllt werden. Dieser Buffer sorgt aber dafür, dass Speicherzugriffe deutlich schneller ablaufen können. Wenn der Buffer also deutlich ausgebremmst wird, dadurch, dass er ständig neu aufgebaut werden muss (was auch Leistung kostet), können Speicherzugriffe folglich nicht mehr so schnell erfolgen, da der Buffer viel weniger Adressen vorhält, um schnell Daten abrufen zu können.

Natürlich kann das auch alles Unsinn sein, mein Studium ist etwas lang her -.-'
[re:1] Aerith am 05.01. 11:17
+1 -1
@LoD14: Nö, kommt hin. ^^
[re:6] Alexmitter am 05.01. 10:45
+3 -
@Memfis: Es geht um Kernel I/O
[o2] Lecter am 05.01. 10:37
+3 -4
Hier sind echte Benchmarks mit Aussagekraft: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=2

Es sind tatsächlich bis zu 30% weniger Performance!!!
[re:1] AWolf am 06.01. 07:47
+ -1
@Lecter: Ich lese lediglich, daß dir "Linux's x86 Security Changes" das Linux ausbremsen.
Eine Zusammenhang mit Windows kann hier nicht konstruiert werden.
[o3] Mixermachine am 05.01. 11:07
+ -3
Irgendwie seltsam das die Benchmarks steigen obwohl mehr Aufwand gefahren werden muss.
Kann es sein, das da doch einige zusätzliche Updates miteingeflossen sind?
[re:1] departure am 05.01. 11:35
+4 -
@Mixermachine: Vielleicht hat Microsoft die ohnehin seit WIN NT 3.5.1 (1993) eingebaute Bremse in Windows (um Hardwarekäufe anzukurbeln - Vereinbarung mit der PC-Industrie) etwas gelöst/gelockert, um die Performanceeinbuße durch den Patch betriebssystemseitig gleich wieder auszugleichen ;-)

< Verschwörungstheorie Ende >
[re:1] Mixermachine am 05.01. 12:39
+1 -1
@departure:
Der Aluhut betreibt Kernfusion ;)
[re:2] Suchiman am 05.01. 13:28
+ -1
@Mixermachine: Ich glaube ich hatte gelesen gehabt, dass Windows mit dem Update die Fähigkeit hat, den TLB inkrementell zu Flushen anstatt vollständig, was sich positiv auf die Performance auswirken dürfte.
[o4] Lord Laiken am 05.01. 12:48
+1 -1
Leider werden wohl nur die neusten CPUs in den Grafiken aufgenommen. Wie wäre es mit den Auswirkungen auf die vielen älteren Modelle statt CPUs wie Threadripper, die eh keiner hat. Und ist AMD ohnehin garnicht betroffen?
[o5] andi1983 am 05.01. 16:06
+4 -
Naja alle schreiben "nur" vom Leistungseinbruch. Nur wäre da nicht noch ein Punkt? Wird nach dem Patch nicht auch der Stromverbrauch ansteigen, weil die CPU dann länger bei Volllast rechnen muss, um die gleichen Operationen gegenüber früher auszuführen.
[o7] lalalala am 08.01. 10:53
+ -
Schönreden sollte man dieses Fiasko auch nicht. Ich habs schon getestet, nicht überall, aber da und dort sind schon speed Einbußen da. Ich hab aber wieder mein reserve Partition-Image ohne die $MS James Bond Updates ..zurück kopiert und siehe da, Full-Speed überall ist wieder da, so wie ich es gewohnt bin. Ich warte mal ab, bis eine bessere Problem-Lösung gefunden wird die mein Windows Sytem nicht so belasten!
[o8] GSMFAN am 10.01. 13:59
+ -1
HILFE! Bitte wie kann ich die Installation dieses Updates dauerhaft verhindern???? ICH WILL DAS NICHT!!!
[re:1] GSMFAN am 10.01. 14:25
+1 -
@GSMFAN: Es gibt ein Tool von Microsoft, mit dem Installation von Updates zumindest zeitweilig unterbunden werden kann.

http://download.microsoft.com/download/f/2/2/f22d5fdb-59cd-4275-8c95-1be17bf70b21/wushowhide.diagcab
Einen Kommentar schreiben
Hoch © 2000 - 2018 WinFuture Impressum Datenschutz