Anon-525334
Banned
- Registriert
- Dez. 2010
- Beiträge
- 1.478
Mcr-King schrieb:
Ich verstehe nur Bahnhof
Test Meltdown & Spectre: Benchmarks mit AMD und Intel unter Windows 7 und 10
- Ersteller Jan
- Erstellt am
- Zum Test: Meltdown & Spectre: Benchmarks mit AMD und Intel unter Windows 7 und 10
Ich verstehe nur Bahnhof
Ich war immer der Meinung das die Arma Reihe ein CPU Fresser ist und gerade deshalb auf AMD nicht besonders gut läuft.Kdax schrieb:
Naja, da diverse Einfallsvektoren auf isolierten Systemen wegfallen hält sich das ganze in Grenzen.yummycandy schrieb:
Da ist die Whatsapp/Facebook Familie mit nicht administrierten Email Account deutlich größeren Risiken ausgesetzt.
Ja, wenn es den sein muss. Oder nach der Installation die Dlls umbenennen, soll auch funktionieren.BmwM3Michi schrieb:
Risiko liegt bei dir.
D.h. nach einem Update (z.B. BIOS) kann das OS direkt das nächste drüber bügeln? Wundert mich eigentlich das es dafür keine Sperrmöglichkeit gibt. So wie bei der 'ATA Passwort setzen/verriegeln' Funktion.xexex schrieb:
yummycandy
Commodore
- Registriert
- März 2005
- Beiträge
- 4.370
vander schrieb:
Das eine besondere Sicherheit in diesem Bereich herrscht, ist mir klar. Ich denke aber, die Frage zielte auf die eingesetzte Hardware ab. Und die ist natürlich die gleiche, wie im zivilen Bereich.
aldaric
Admiral
- Registriert
- Juli 2010
- Beiträge
- 8.119
vander schrieb:
Arma 3 läuft auf Ryzen nicht merklich schlechter als auf Intel. Bohemia wollte eigentlich die Engine nach dem Ryzen Release noch anpassen für Ryzen. (ist das bisher geschehen?)
Aber ein CPU Fresser ist das nur bedingt, da Arma mit seiner URALT Engine nur einen Kern wirklich "fressen" kann. Und bei Arma3 spielen soviele andere Faktoren in die Performance mit rein...als Benchmark einfach ungeeignet.
Hier gibt es eine schöne Übersicht welche Exploits bislang auf welchen CPUS "erfolgreich" gestestet worden sind:
https://github.com/marcan/speculation-bugs/blob/master/README.md
PoCs
[Mispredict] = Spectre1 (hiervon gibt es effektiv unzählige denkbare Varianten
[BTI] = Spectre2
[PRIV-LOAD] = Meltdown
[MISPREDICT] Google Project Zero: basic same-process PoC
Platforms:
Intel Haswell Xeon
AMD FX CPU
AMD PRO CPU
ARM Cortex A57
[MISPREDICT] Google Project Zero: arbitrary kernel reads with eBPF JIT
Platforms:
Intel Haswell Xeon CPU
AMD PRO CPU
A process running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory.
This is an interpreter/JIT attack in the kernel. On Haswell, it works in both JIT and interpreter mode, as the speculation seems to be deep enough to reach even in interpreter mode. On AMD, JIT is required.
Mitigation: AMD: disable eBPF JIT (net.core.bpf_jit_enable sysctl). Intel: disable BPF entirely?
[BTI] Google Project Zero: HV guest root process can read host physical memory
Platforms:
Intel Haswell Xeon CPU
A process running with root privileges inside a KVM guest created using virt-manager, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization.
Mitigation: None yet. Kernel/compiler patches in the works.
---------------------------------
=> Hier setzen die Benchmarks von Phoronix weiter unten an !
---------------------------------
[PRIV-LOAD] Google Project Zero: Partial kernel memory read from userspace
Platforms:
Intel Haswell Xeon CPU
A process running with normal user privileges can read kernel memory under some precondition, presumed to be that the targeted kernel memory is present in the L1D cache.
Mitigation: KPTI
Performance impact von KPTI:
https://lwn.net/Articles/742702/
So oder so wird es interessant werden die vermutlich teils sehr unterschiedlich ausfallende Performance Impacts der Spectre Mitigations zu betrachten.
Erste Hinweise auf "optimierte" Spectre 2 Patches und deren Performance Auswirkungen:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
Hier tut sich nicht allzuviel scheinbar mit verschiedenen AMD-Setups. Einzig der Threadripper hat hier ein starken Impact. Ich vermute mal dass hier irgendetwas am Patch noch nicht richtig ist...denn Ryzen und Epyc sehen komplett anders aus und Threadripper ist "fast" baugleich mit Epyc (bis auf die 2 deaktiverten/Dummy CPUs im Sockel).
Mehr infos über die Details wie diese optimierten Mitigations arbeiten gibt es hier:
https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
aber auch hier (Stichwort Retpoline):
https://github.com/marcan/speculation-bugs/blob/master/README.md#pocs
Siehe hier auch ein bisschen weiter unterhalb: https://github.com/marcan/speculation-bugs/blob/master/README.md
Möglicher Performance Hit wegen der Verwendung der IBRS Mitigation laut https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
Und als Nebenaspekt hat Matt Klein auch noch ein paar Gedanken zu Meltdown:
Das Windows Update KB4056892 besteht aus 2 Teilen einem KPTI analogen Patch und dem IBRS Spectre Patch (letzterer Teil sorgte für die Probleme bei manchen AMD/Intel CPUs:
Bin also wirklich gespannt auf die weiteren Benchmarks in der Sache - das kann ja nochmal lustig werden wenn die Auswirkungen so derart CPU-Typ abhängig ausfallen !
https://github.com/marcan/speculation-bugs/blob/master/README.md
PoCs
[Mispredict] = Spectre1 (hiervon gibt es effektiv unzählige denkbare Varianten
[BTI] = Spectre2
[PRIV-LOAD] = Meltdown
[MISPREDICT] Google Project Zero: basic same-process PoC
Platforms:
Intel Haswell Xeon
AMD FX CPU
AMD PRO CPU
ARM Cortex A57
[MISPREDICT] Google Project Zero: arbitrary kernel reads with eBPF JIT
Platforms:
Intel Haswell Xeon CPU
AMD PRO CPU
A process running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory.
This is an interpreter/JIT attack in the kernel. On Haswell, it works in both JIT and interpreter mode, as the speculation seems to be deep enough to reach even in interpreter mode. On AMD, JIT is required.
Mitigation: AMD: disable eBPF JIT (net.core.bpf_jit_enable sysctl). Intel: disable BPF entirely?
[BTI] Google Project Zero: HV guest root process can read host physical memory
Platforms:
Intel Haswell Xeon CPU
A process running with root privileges inside a KVM guest created using virt-manager, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization.
Mitigation: None yet. Kernel/compiler patches in the works.
---------------------------------
=> Hier setzen die Benchmarks von Phoronix weiter unten an !
---------------------------------
[PRIV-LOAD] Google Project Zero: Partial kernel memory read from userspace
Platforms:
Intel Haswell Xeon CPU
A process running with normal user privileges can read kernel memory under some precondition, presumed to be that the targeted kernel memory is present in the L1D cache.
Mitigation: KPTI
Performance impact von KPTI:
https://lwn.net/Articles/742702/
----------------------------------------------------------------------------------------------
So oder so wird es interessant werden die vermutlich teils sehr unterschiedlich ausfallende Performance Impacts der Spectre Mitigations zu betrachten.
Erste Hinweise auf "optimierte" Spectre 2 Patches und deren Performance Auswirkungen:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
Hier tut sich nicht allzuviel scheinbar mit verschiedenen AMD-Setups. Einzig der Threadripper hat hier ein starken Impact. Ich vermute mal dass hier irgendetwas am Patch noch nicht richtig ist...denn Ryzen und Epyc sehen komplett anders aus und Threadripper ist "fast" baugleich mit Epyc (bis auf die 2 deaktiverten/Dummy CPUs im Sockel).
Mehr infos über die Details wie diese optimierten Mitigations arbeiten gibt es hier:
https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
aber auch hier (Stichwort Retpoline):
https://github.com/marcan/speculation-bugs/blob/master/README.md#pocs
Dummerweise siehts für die neuere CPUs ab Skylake hier schlecht aus - da sie offenbar eine Architekturielle Änderung haben die die Retpolines umgehen kann so das man zusätzlich IBRS-Mitigation aktivieren muss. Was relative viel Performance kosten dürfte.
Siehe hier auch ein bisschen weiter unterhalb: https://github.com/marcan/speculation-bugs/blob/master/README.md
Möglicher Performance Hit wegen der Verwendung der IBRS Mitigation laut https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
Und als Nebenaspekt hat Matt Klein auch noch ein paar Gedanken zu Meltdown:
Das Windows Update KB4056892 besteht aus 2 Teilen einem KPTI analogen Patch und dem IBRS Spectre Patch (letzterer Teil sorgte für die Probleme bei manchen AMD/Intel CPUs:
Bin also wirklich gespannt auf die weiteren Benchmarks in der Sache - das kann ja nochmal lustig werden wenn die Auswirkungen so derart CPU-Typ abhängig ausfallen !
Zuletzt bearbeitet:
Siegfriedphirit
Lt. Junior Grade
- Registriert
- Apr. 2009
- Beiträge
- 508
Müsste Intel nicht für die nun entstandenen Schäden haften? Hoffentlich finden sich genügend Leute die klagen. Ein Autohersteller muss doch auch für Schäden haften auch wenn dafür Zulieferer verantwortlich sind und kostenfrei nachbessern bzw durch neue und fehlerfreie Teile nachbessern.
Dieser Poster hier beschreibt eine Interessante Idee die sich meines erachtens nach mit dem Ars-Technica Artikel zur "Resistenz" der AMD Architekturen vs. Spectre 2 deckt:
https://lwn.net/Articles/742904/
"To be vulnerable to branch predictor abuse, you need to be able to train the predictor. If you (correctly) index your predictor using all of the bits of the VA, as opposed to the low order bits, you remove the most obvious route of attack."
Wenn ich das richtig übersetzte sagt er dass man den predictor nicht (effektiv) trainieren kann wenn man vollständige Adresspräzision verwendet ?
Weiter schreibt er dann:https://lwn.net/Articles/743093/
"Nah, it's VA+ASID/PCID. It's actually very simple to have a branch predictor that is safe against variant 2. You just need to have your index completely disambiguate against other live contexts. The only problem with this is it's more bits to compare, but as compared to not having any branch prediction within one of the contexts, or flushing the predictor."
Und weiter https://lwn.net/Articles/742968/
"Indeed, but as I said elsewhere in the thread, you can mitigate branch predictor abuse if you correctly index your predictor based upon the full address space (including ASID/PCID/etc.). The hardware fix for variant 2 isn't actually as bad as people claim."
Übrigens seine Qualifikation beschreibt er so: https://lwn.net/Articles/743094/
"I co-lead the mitigation team within Red Hat for some time on this issue."
Bezugnehmend auf den Ars-Technica Artikel: https://arstechnica.com/gadgets/201...e-and-meltdown-patches-will-hurt-performance/
"Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address."
Haben wir also schon 2 Quellen (+ AMD selbst) die technisch versierter sind und erklären warum AMD sich hier "relativ" sicher fühlt bzw. fühlen kann.
Man kann auf AMD-Systemen den Branch Predictor eben nur sehr eingeschränkt bzw. gar nicht trainieren - weshalb ein Spectre 2 Exploit viel schwerer umzusetzen ist.
Möglich - wahrscheinlich - aber bei Intel ist es eben so "leicht" den Predictor zu trainen weil die Sprungvorhersagen jeweils riesige Adressbereiche zulassen (wegen der unvollständigen Adresslokalisation (dem sogenannten "flattening") bei Intel (aus dem Ars-Technica Artikel):
"Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB."
Bei AMD wird immer 1:1 gemapped (siehe lwn.net) - da der Exploit genau darauf basiert diese Mapping imprecision auszunutzen um eine misprediction zu mappen um dort dann einen branch zu injizieren ist es halt auf AMD wohl schwierig mispredictions für die injektion zu erhalten.Dazu kommt vermutlich noch der Privilege Check für Spekulative Befehle den AMD CPUs machen, der gegen Meltdown schützt. AMD CPUs führen spekulativ deshalb keine Befehle aus die nicht den Privilegien des Prozessess der gerade ausgeführt wird entsprechen. Dieser Check wird bei AMD vor bzw. während dem Adresssprung ausgeführt. Hat die Zieladresse ein anderes Privileg wird die Speculative Execution nicht ausgeführt und die ganze Branch wird angehalten.
Daher kann es auch gut sein dass der Performance-Impact mit Spectre 2 Mitigation @AMD niedriger ausfällt.
Mal sehen was die Benches zeigen...
https://lwn.net/Articles/742904/
"To be vulnerable to branch predictor abuse, you need to be able to train the predictor. If you (correctly) index your predictor using all of the bits of the VA, as opposed to the low order bits, you remove the most obvious route of attack."
Wenn ich das richtig übersetzte sagt er dass man den predictor nicht (effektiv) trainieren kann wenn man vollständige Adresspräzision verwendet ?
Weiter schreibt er dann:https://lwn.net/Articles/743093/
"Nah, it's VA+ASID/PCID. It's actually very simple to have a branch predictor that is safe against variant 2. You just need to have your index completely disambiguate against other live contexts. The only problem with this is it's more bits to compare, but as compared to not having any branch prediction within one of the contexts, or flushing the predictor."
Und weiter https://lwn.net/Articles/742968/
"Indeed, but as I said elsewhere in the thread, you can mitigate branch predictor abuse if you correctly index your predictor based upon the full address space (including ASID/PCID/etc.). The hardware fix for variant 2 isn't actually as bad as people claim."
Übrigens seine Qualifikation beschreibt er so: https://lwn.net/Articles/743094/
"I co-lead the mitigation team within Red Hat for some time on this issue."
Bezugnehmend auf den Ars-Technica Artikel: https://arstechnica.com/gadgets/201...e-and-meltdown-patches-will-hurt-performance/
"Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address."
Haben wir also schon 2 Quellen (+ AMD selbst) die technisch versierter sind und erklären warum AMD sich hier "relativ" sicher fühlt bzw. fühlen kann.
Man kann auf AMD-Systemen den Branch Predictor eben nur sehr eingeschränkt bzw. gar nicht trainieren - weshalb ein Spectre 2 Exploit viel schwerer umzusetzen ist.
Möglich - wahrscheinlich - aber bei Intel ist es eben so "leicht" den Predictor zu trainen weil die Sprungvorhersagen jeweils riesige Adressbereiche zulassen (wegen der unvollständigen Adresslokalisation (dem sogenannten "flattening") bei Intel (aus dem Ars-Technica Artikel):
"Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB."
Bei AMD wird immer 1:1 gemapped (siehe lwn.net) - da der Exploit genau darauf basiert diese Mapping imprecision auszunutzen um eine misprediction zu mappen um dort dann einen branch zu injizieren ist es halt auf AMD wohl schwierig mispredictions für die injektion zu erhalten.Dazu kommt vermutlich noch der Privilege Check für Spekulative Befehle den AMD CPUs machen, der gegen Meltdown schützt. AMD CPUs führen spekulativ deshalb keine Befehle aus die nicht den Privilegien des Prozessess der gerade ausgeführt wird entsprechen. Dieser Check wird bei AMD vor bzw. während dem Adresssprung ausgeführt. Hat die Zieladresse ein anderes Privileg wird die Speculative Execution nicht ausgeführt und die ganze Branch wird angehalten.
Daher kann es auch gut sein dass der Performance-Impact mit Spectre 2 Mitigation @AMD niedriger ausfällt.
Mal sehen was die Benches zeigen...
Zuletzt bearbeitet:
@Benji:
Ja. AMD hat angekündigt ebenfalls microcode updates rauzubringen (gegen Spectre 2). Auf Linux Basis laufen dazu auch schon tests und Benchmarks auf Phoronix.
Nichts genaues über die Änderungen hab ich aber noch nirgends lesen können. Ich vermute dass man mit kleinen Änderungen am Branch Predictor bzw.an der Privileg-Prüfung für Spekulative Ausführung ansetzt und da noch ein paar kleinere Hürden ein bauen kann (Stichwort IBRS und Co.)
Diese "Features" bewirken ja dass man bestimmte Prüfungen vornimmt bzw. bestimmte Befehlsmuster von Speculativer Ausführung ausnimmt) und dann ggf. Speculative Execution verwirft bevor sie ausgeführt wird.
So oder so in den Phoronix-Tests sind die bisherigen Leistungsverluste @Spectre 2 eher überschaubar (für AMD):
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
"With the latest Linux 4.15 kernel there is not only the original Retpoline code but also an AMD-specific minimal thunk that is optimized for AMD's processor and should perform better for this Sepctre Variant Two mitigation."
Nur auf Threadripper scheint hier noch ein Bug vorzuliegen....da es eigentlich keinen Grund gibt warum TR so deutlich in einem der Benchmarks von Epyc bzw. Ryzen abweichen sollte.
Witzigerweise gewinnt Ryzen hier beim IO Test sogar Performance mit dem Patch
- da sieht man mal was so ein wenig optimierung im Compiler manchmal für sonst eher vernachlässigte Architekturen bringen kann.
Redis ist evtl. das markanteste da "real-world" benchmark.
Sieht so ca nach ~0% Verlust aus@Zen. -10% @TR und -5%@Epyc. Wobei unklar ist wie groß hier evtl. Benchmarkschwankungen sind.
Für Intel gibt es hier auch schon erste Tests und zwar betreffs des Problems dass die einfache IBRS-Lösung bei den neueren Architekturen ab Skylake nicht mehr ausreichen schützt, weshalb man den Retpoline_Underflow noch nachschiebt:
https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
"Beyond the Retpoline support already found in the mainline Linux kernel, developers are working on Retpoline Underflow support that would be used for Intel Skylake and Kabylake CPUs. RETPOLINE_UNDERFLOW protects against falling back to a potentially poisoned indirect branch predictor when a return buffer underflows and this additional protection is needed for Intel Skylake/Kabylake processors."
sieht so nach 1-20% Einbruch aus (in Redis).
Ja. AMD hat angekündigt ebenfalls microcode updates rauzubringen (gegen Spectre 2). Auf Linux Basis laufen dazu auch schon tests und Benchmarks auf Phoronix.
Nichts genaues über die Änderungen hab ich aber noch nirgends lesen können. Ich vermute dass man mit kleinen Änderungen am Branch Predictor bzw.an der Privileg-Prüfung für Spekulative Ausführung ansetzt und da noch ein paar kleinere Hürden ein bauen kann (Stichwort IBRS und Co.)
Diese "Features" bewirken ja dass man bestimmte Prüfungen vornimmt bzw. bestimmte Befehlsmuster von Speculativer Ausführung ausnimmt) und dann ggf. Speculative Execution verwirft bevor sie ausgeführt wird.
So oder so in den Phoronix-Tests sind die bisherigen Leistungsverluste @Spectre 2 eher überschaubar (für AMD):
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
"With the latest Linux 4.15 kernel there is not only the original Retpoline code but also an AMD-specific minimal thunk that is optimized for AMD's processor and should perform better for this Sepctre Variant Two mitigation."
Nur auf Threadripper scheint hier noch ein Bug vorzuliegen....da es eigentlich keinen Grund gibt warum TR so deutlich in einem der Benchmarks von Epyc bzw. Ryzen abweichen sollte.
Witzigerweise gewinnt Ryzen hier beim IO Test sogar Performance mit dem Patch
- da sieht man mal was so ein wenig optimierung im Compiler manchmal für sonst eher vernachlässigte Architekturen bringen kann.Redis ist evtl. das markanteste da "real-world" benchmark.
Sieht so ca nach ~0% Verlust aus@Zen. -10% @TR und -5%@Epyc. Wobei unklar ist wie groß hier evtl. Benchmarkschwankungen sind.
Für Intel gibt es hier auch schon erste Tests und zwar betreffs des Problems dass die einfache IBRS-Lösung bei den neueren Architekturen ab Skylake nicht mehr ausreichen schützt, weshalb man den Retpoline_Underflow noch nachschiebt:
https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
"Beyond the Retpoline support already found in the mainline Linux kernel, developers are working on Retpoline Underflow support that would be used for Intel Skylake and Kabylake CPUs. RETPOLINE_UNDERFLOW protects against falling back to a potentially poisoned indirect branch predictor when a return buffer underflows and this additional protection is needed for Intel Skylake/Kabylake processors."
sieht so nach 1-20% Einbruch aus (in Redis).
Bolko
Commander
- Registriert
- Sep. 2012
- Beiträge
- 2.082
Durch das Update KB4056897 ist die GPU-3D-DX10-Leistung deutlich gestiegen (die DX9-Leistung ist unverändert).
i5-750, GTX 950, Win7
Passmark PerformanceTest 7.0 build 1024:
http://www.guru3d.com/files-get/passmark-performancetest-7-build-1024,1.html
ohne Patch:
GPU 2D DX10: 443,4
GPU 3D DX10: 2143,3
mit Patch:
GPU 2D DX10: 504,6 (+ 13,8 %)
GPU 3D DX10: 4688,8 (+ 118,76 %)
"PC UserBenchmark":
http://www.userbenchmark.com/Software
ohne Patch:
MRender DX10: 62.4
Gravity DX10: 68.8
Splatting DX10: 52.7
fps DX10: 61.3
mit Patch:
MRender DX10: 77.5 (+ 24,19 %)
Gravity DX10: 94 (+ 36,6 %)
Splatting DX10: 75 (+ 42,3 %)
fps DX10: 82.2 (+ 66,77 %)
Wie ist denn dieser krasse Anstieg der GPU-DX10-Leistung zu erklären?
Warum wirkt sich das bei DX9 nicht aus?
Benchmark wurde jeweils 2 mal durchgeführt.
Die SSD-Leistung ist unverändert (SATA2, Crystal DiskMark v5.1.0).
Edit:
Nach einem Neustart und erneutem Test mit Patch sind die Werte leider wieder auf den niedrigeren Wert gesunken. Wie kann es denn da solche Unterschiede bei den DX10-Messungen geben?
Taugt der Benchmark (Passmark PerformanceTest) evtl. nichts?
i5-750, GTX 950, Win7
Passmark PerformanceTest 7.0 build 1024:
http://www.guru3d.com/files-get/passmark-performancetest-7-build-1024,1.html
ohne Patch:
GPU 2D DX10: 443,4
GPU 3D DX10: 2143,3
mit Patch:
GPU 2D DX10: 504,6 (+ 13,8 %)
GPU 3D DX10: 4688,8 (+ 118,76 %)
"PC UserBenchmark":
http://www.userbenchmark.com/Software
ohne Patch:
MRender DX10: 62.4
Gravity DX10: 68.8
Splatting DX10: 52.7
fps DX10: 61.3
mit Patch:
MRender DX10: 77.5 (+ 24,19 %)
Gravity DX10: 94 (+ 36,6 %)
Splatting DX10: 75 (+ 42,3 %)
fps DX10: 82.2 (+ 66,77 %)
Wie ist denn dieser krasse Anstieg der GPU-DX10-Leistung zu erklären?
Warum wirkt sich das bei DX9 nicht aus?
Benchmark wurde jeweils 2 mal durchgeführt.
Die SSD-Leistung ist unverändert (SATA2, Crystal DiskMark v5.1.0).
Edit:
Nach einem Neustart und erneutem Test mit Patch sind die Werte leider wieder auf den niedrigeren Wert gesunken. Wie kann es denn da solche Unterschiede bei den DX10-Messungen geben?
Taugt der Benchmark (Passmark PerformanceTest) evtl. nichts?
Zuletzt bearbeitet:
Bolko
Commander
- Registriert
- Sep. 2012
- Beiträge
- 2.082
Klar habe ich den Rechner neu gestartet.
2 mal gebencht mit Patch. Hohe 3D DX10 Werte gemessen.
Danach Patch deinstalliert und neu gestartet.
2 mal gebencht. Niedrige 3D DX10 Werte gemessen.
Patch installiert und neu gestartet.
Gebencht und niedrige Werte gemessen.
Ist offenbar nicht reproduzierbar.
Vielleicht schummelt auch einfach nur der NVidia Grafik-Treiber, wenn er das Benchmarkprogramm erkennt?
2 mal gebencht mit Patch. Hohe 3D DX10 Werte gemessen.
Danach Patch deinstalliert und neu gestartet.
2 mal gebencht. Niedrige 3D DX10 Werte gemessen.
Patch installiert und neu gestartet.
Gebencht und niedrige Werte gemessen.
Ist offenbar nicht reproduzierbar.
Vielleicht schummelt auch einfach nur der NVidia Grafik-Treiber, wenn er das Benchmarkprogramm erkennt?
Die Meltdown-Patch relevanten I/O Einbrüche gibt es NICHT auf AMD.
(EDIT: siehe https://www.computerbase.de/2018-01...-benchmarks/#abschnitt_ryzen_unter_windows_10
Die Spectre-Patch(es) verursachten aber je nachdem mehr oder meist weniger auch auf AMD.
Auf CB noch nicht getestet.
Aber z.B. @Linux:
Intel: https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
AMD: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
Man erwartet aber dass die Performance @Intel noch "etwas" besser wird evtl.:
https://www.phoronix.com/scan.php?page=news_item&px=RETPOLINE_UNDERFLOW
(EDIT: siehe https://www.computerbase.de/2018-01...-benchmarks/#abschnitt_ryzen_unter_windows_10
Die Spectre-Patch(es) verursachten aber je nachdem mehr oder meist weniger auch auf AMD.
Auf CB noch nicht getestet.
Aber z.B. @Linux:
Intel: https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
AMD: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
Man erwartet aber dass die Performance @Intel noch "etwas" besser wird evtl.:
https://www.phoronix.com/scan.php?page=news_item&px=RETPOLINE_UNDERFLOW
etoo schrieb:
In der Tat gibt es nun langsam erste Hinweise unter Linux wie der Performance Hit mit Spectre V1/V2 und ohne ausfällt auf AMD:
https://www.phoronix.com/scan.php?page=article&item=linux-416-epyc&num=1
Es wurden auf Phoronix insgesamt mehrere Linux-Varianten mit mehreren Mitigation-Level Varianten getestet:
Also 1x 4.16 mit Mitigation gegen Spectre V1 UND V2 und 1x 4.16 mit NUR Spectre V1 Schutz aktiv !
Das Linux 4.15. enthält also KEINEN Spectre V1 Schutz, wohl aber den Retpoline V2 Schutz
Für den I/O Tester ist der Performancehit meist sehr klein und wesentlich kleiner als alleine der KPTI-Fix für Meltdown auf Intel-Systemen.
Im Allgemeinen ist die I/O Performance auf AMD nahezu unverändert. Allerdings hat gerade Linux v4.16 hier noch luft nach oben da es generell noch etwas schlechter performed als Linux v4.14.
Auch AMD Compilerperformance ist quasi gleich.
Und in PostGreSQL (auf 1 Thread) ist der Einbruch ebenfalls eher unsichtbar.
Deutlicher im Vorteil ist AMD wohl bei GIMP...das auf Intels wohl schon messbar langsamer läuft. AMD quasi unverändert.
Und bei Redis sieht man auch nichts@Epyc
Stress-NG fällt auch nur auf weil 4.16 schlechter als .15, bzw .14 läuft...Spectre ist egal.
Einzig mit Apache sieht man dass Spectre-Patch via Retpoline etwas Leistung frisst. Aber auch ist anzumerken dass selbst 4.15 (und wohl auch 4.16) noch nicht voll optimiert sind da 4.14 immer noch schneller. Aber auch 4.14 mit Spectre-Schutz zeigt einen kleinen Performance Hit @4.14 von ca. 600 Punkten ca. 3% bei +-1.2% statistischer Unsicherheit. Also gerade mal leicht über dem kleinsten Signifikanzniveau (2-Sigma) der Messung.
Also der Retpoline Schutz würde wirklich sau-gut funktionieren...mal abwarten was die Geschichte unter RS5 und dem vermeintlichen SpectreSchutz @Ryzen ist.
@Iscaran
Danke für deine Mühe, aber ich glaube der Leistungsverlust unter Windows ist (entsprechend der Nutzerzahl) von weitaus größerem Interesse. Insbesondere, da es von AMD keine Meldungen zu µCode Updates für ältere CPUs (FX) gibt.
Ich glaube immer noch sie werden es, mit fortwährendem Verweis auf das 'near Zero risk', einfach aussitzen und dabei fleißig weiter neue CPUs mit der gleichen Argumentation verkaufen.
Danke für deine Mühe, aber ich glaube der Leistungsverlust unter Windows ist (entsprechend der Nutzerzahl) von weitaus größerem Interesse. Insbesondere, da es von AMD keine Meldungen zu µCode Updates für ältere CPUs (FX) gibt.
Ich glaube immer noch sie werden es, mit fortwährendem Verweis auf das 'near Zero risk', einfach aussitzen und dabei fleißig weiter neue CPUs mit der gleichen Argumentation verkaufen.
Ähnliche Themen
