Test AMD Ryzen 2000: Kaum Leistungsverlust durch Patch gegen Spectre V2

[Taxxor]

Du verstehst es wohl nicht. Ganz nach dem Motte, man kann jede Statistik "schönreden" wenn man Informationen weglässt.

Noch mal: Nirgendwo wurde Intel erwähnt. Welche Informationen wurden also weggelassen?
Das Thema ist Ryzen 2000 vor und nach dem Patch. Also sind das auch die einzigen Informationen die das Thema enthalten muss.

Sagen wir es gibt ein Thema zu einer Treiberverbesserung, wo es nur darum geht, wie viel fps man in einem bestimmten Titel jetzt mit einer speziellen Karte, sagen wir Vega64, mehr hat als vorher.

Beschwerst dich jetzt darüber, dass in dem Vergleich aber keine 1080Ti auftaucht, und das Fazit zum Treiberupdate nicht lautet "AMD immer noch mies"?

Überspitzes Beispiel:
Intel: 1000mb/s pre patch
Intel: 300mb/s after patch

Amd: 270mb/s pre patch
Amd: 266mb/s after patch

Somit gilt die Aussage: Kaum Leistungsverlust durch Patch gegen Spectre V2 bei AMD. Dennoch gilt, AMD vorher mies, nacher mies.

NIEMAND hat danach gefragt, wie AMD zu Intel steht, es geht hier einzig und allein darum wie AMD vor dem Patch zu AMD nach dem Patch steht.


Und bei deinem Beispiel muss in beiden Fällen 270mb/s stehen, da es absolut keinen Verlust gab.

Und dann gilt, wenn du unbedingt Intel mit reinnehmen willst:

Vorher Intel durch Sicherheitslücke vor AMD
Nachher Intel durch Beseitigung der Sicherheitslücke gleich mit AMD

 

[boxte30:Goas]

@tic-tac-toe-x-o

Mit „Indirect Branch Predictor Barrier“ (IBPB) setzt AMDs Gegenmaßnahme nur auf einen der drei von Intel bekannten Befehle – „Indirect Branch Restricted Speculation“ (IBRS) und „Single Thread Indirect Branch Predictors“ (STIBP) bleiben außen vor. In einem Whitepaper (PDF) erklärt AMD, die beiden anderen Befehle derzeit nicht als performante Gegenmaßnahme in Windows empfehlen zu können.

Das ist m. E. auch der wichtigste Abschnitt: IBRS und STIBP werden von AMD überhaupt nicht umgesetzt. Nicht weil es nicht nötig wäre, sondern weil es zu viel Leistung kostet.

 

[Taxxor]

Schon mal daran erinnert, dass AMD bei Spectre von Grund auf schon viel weniger anfällig ist als Intel, und daher mit einem Befehl vielleicht auch so schon sicher genug ist?

Bei Intel musste man vermutlich alles nutzen, da man sonst immer noch zu anfällig wäre.
Bei AMD hat man sich dann gegen Leistungseinbußen für das letzte tausendstel Prozent Sicherheit entschieden.

 

[Martinfrost2003]

echt witzig, das jeder AMD und Intel Thread immer zum Schwanzvergleich heran gezogen wird.
Kinders, es ist inzwischen egal was Ihr kauft.
Beide sind auf Augenhöhe. Intel ist in Games etwas besser, AMD bei Anwendungen.
Also wen juckt es.
Bei mir wäre es auch völlig wurscht ob ich nen 8700K oder 2700X kaufe.
Ich könnte es auswürfeln

 

[Skaro]

Eine HDD mit 500 MB/s wäre mal was.

Im RAID natürlich meins schafft um die 800 MB/s R/W - sequentiell.

 

[Ozmog]

Bei mir wäre es auch völlig wurscht ob ich nen 8700K oder 2700X kaufe.
Ich könnte es auswürfeln

Förder lieber mal den kleinen Underdog statt zu würfeln.
AMD braucht Marktanteile und Umsatz um weiter entwickeln und damit auch weiter existieren zu können. Intel hat die letzten paar Jahre genug Geld kassiert, nachdem sie sich freie Bahn verschafft haben (und immer noch nicht die Strafe an die EU-Kommision gezahlt)

 

[Atze-Peng]

Bessere Überschrift wäre vermutlich gewesen "Nahezu kein Leistungsverlust" bei dem einen Prozent. Kaum impliziert zumindest etwas im 5% Bereich.

 

[boxte30:Goas]

@DonL_
Der Artikel selbst gibt das PDF an:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Das Zauberwort heißt performant.

AMD is not recommending IBRS currently as a performant mitigation in Windows for Google Project Zero Variant 2 (Spectre).

AMD is not recommending STIBP currently as a performant mitigation in Windows and Linux for Google Project Zero
Variant 2 (Spectre).

_{Manmal hilft lesen und nachdenken, bevor man losschreit.}

 

[Taxxor]

Das Zauberwort heißt performant.

_{Manmal hilft lesen und nachdenken, bevor man losschreit.}

Ja, manchmal hilft lesen wirklich, denn dort steht "performant mitigation" Also eine performante Abschwächung/Milderung(des Risikos).

Für mich liest dich das so:
Die zweite und dritte Möglichkeit ist laut AMD momentan nicht wirksam genug, deswegen verwendet man sie nicht.

 

[kisser]

Das stimmt so nicht. Alle drei sind zwingend nötig für den optimalen Schutz.

 

[BlackVip3r]

Kein Problem, hier direkt von AMD:

https://developer.amd.com/wp-conten...Guidelines_Update_Indirect_Branch_Control.pdf

AMD zeigt in diesem Dokument 3 verschiedene Methoden auf, die gegen Spectre v2 abzielen. Jede der einzelnen Methoden könnte von einem AMD Prozessor verwendet werden, was der Entwickler aber überprüfen muss, siehe die Tabelle. Von den drei Methoden wird seitens AMD empfohlen IBPB zu verwenden, da die anderen 2 Methoden Performance Einbußen mit sich bringen.

Alle Features wurden mitunter seitens AMD, wie auch Intel btw., je nach CPU implementiert!

Ob die Benchmark Suite alle Features nutzt bleibt offen, denn wie AMD schreibt:

Software should check that the base feature exists before interpreting the additional feature bits.

Gleiches dürfte dann auch für Intel gelten.

 

[nudelaug]

echt witzig, das jeder AMD und Intel Thread immer zum Schwanzvergleich heran gezogen wird.
Kinders, es ist inzwischen egal was Ihr kauft.
Beide sind auf Augenhöhe. Intel ist in Games etwas besser, AMD bei Anwendungen.
Also wen juckt es.
Bei mir wäre es auch völlig wurscht ob ich nen 8700K oder 2700X kaufe.
Ich könnte es auswürfeln

das sehe ich nicht so. wenn man rein nach benchmarkbalken geht - von mir aus. aber mit einer derartigen naivität wird man als user ziemlich schnell wo dagegenrennen. wer momentan intel unterstützt spielt performance- sowie security-roulette auf kosten aller. die firma hat dem user übelst mitgespielt: meltdown, spectre, minix, intel me etc. und wird auch weiterhin kaum davon abgehen, wenn man deren aggressive und schädliche zukunftsplanung in betracht zieht. wer aktuell noch intel kauft ist (a) nicht in der lage fakten abseits von benchmarkbalken zu interpretieren (b) wohl besser damit bedient seinen fanboismus so langsam mit medikamenten zu behandeln. und ja, hier & auf der arbeit läuft großteils intel - solange sich die ausrichtung der firma nicht grundlegend ändert wars das aber auch.

 

[boxte30:Goas]

@Taxxor
Für mich liest sich das so:
Frau Dr. Lisa Su ist der Aktienwert der Firma AMD wichtiger als die Sicherheit ihrer Prozessoren.

Und bei dem Thema Sicherheit sollte man auch die Kirche im Dorf lassen. - Schließlich sind Hacker auch nur Menschen. Wenn ich mir raussuchen kann ob die Zielerreichung ein paar Minuten oder einige Wochen dauert, dann nehmen alle die Abkürzung.
IBPB, IBRS und STIBP müssen geschlossen sein, damit Wirksamkeit eintritt. Jedoch gibt es eine Menge (und viel einfachere Lücken) um einen Rechner zu übernehmen.
Meltdown- & Spectre interessieren richtige Profis: Also Dienste bzw. Leute, die Firmendaten abgreifen wollen. - und auch dort arbeiten nur Menschen...

 

[DonL_]

Das stimmt so nicht. Alle drei sind zwingend nötig für den optimalen Schutz.

Bei Intel aber nicht bei AMD, den Beweis bleibt ihr einfach schuldig und Behauptungen wie deine kann man viel aufstellen, wenn der Tag lang ist!

Für mich liest sich das so:
Frau Dr. Lisa Su ist der Aktienwert der Firma AMD wichtiger als die Sicherheit ihrer Prozessoren.

Was du subjektiv liest, ist doch völlig irrelevant, AMDs Architektur ist keine Intel Architektur, insoweit kann auch nur AMD selbst bestimmen, was für ihre Architektur sicher ist oder nicht!

Und es gibt bis Heute immer noch keinen nachgewiesenen Spectre Angriff auf ein AMD Sytem!

 

[Taxxor]

BlackVip3r hat es doch ganz gut beschrieben wie es gemeint ist.

In dem White Paper steht, dass AMD den Entwicklern von Software momentan nicht empfiehlt die beiden Befehle zu nutzen, das sagt aber mit keinem Wort, dass sie nicht nutzbar sind.

 

[wdx]

Förder lieber mal den kleinen Underdog statt zu würfeln.
AMD braucht Marktanteile und Umsatz um weiter entwickeln und damit auch weiter existieren zu können. Intel hat die letzten paar Jahre genug Geld kassiert, nachdem sie sich freie Bahn verschafft haben (und immer noch nicht die Strafe an die EU-Kommision gezahlt)

👍 genau, werde meinen Sandy Bridge 2500K, nach 7 Jahren gegen einen 2700X ersetzen. Das sollte dann doch 100% Leistungssteigerung geben 😃 ....und nachdem ich kein Gamer bin, ist AMD für mich die bessere Wahl.

 

[emeraldmine]

@wdx

Die "nackte Wahrheit":

ca. 170% Leistungssteigung möglich.

 

[kisser]

AMD zeigt in diesem Dokument 3 verschiedene Methoden auf, die gegen Spectre v2 abzielen. Jede der einzelnen Methoden könnte von einem AMD Prozessor verwendet werden, was der Entwickler aber überprüfen muss, siehe die Tabelle.

Das ist so nicht richtig. Man kann nicht eine der drei Methoden "auswählen". Alle drei Methoden sind gleichzeitig notwendig, um den umfassendsten Schutz gegen Spectre zu bieten. Z.B. braucht man STIBP, um die zwei (SMT-) Tasks auf einem Core gegeneinander zu schützen.

Ergänzung (21. April 2018)

IBPB, IBRS und STIBP müssen geschlossen sein, damit Wirksamkeit eintritt.

Jedoch gibt es eine Menge (und viel einfachere Lücken) um einen Rechner zu übernehmen.

Weshalb ich mir mit meinem vollkommen ungepatchen System auch nicht in die Hosen mache und es nutze wie in den letzten Jahren vor Spectre/Meltdown auch.

 

[foofoobar]

Das stimmt so nicht. Alle drei sind zwingend nötig für den optimalen Schutz.

Eigentlich braucht es das nur für Betriebssysteme die Treiberblobs unterstützen.

 

[werpu]

Sieht das bei HDDs eigentlich ähnlich aus? Auf Reddit habe ich mal ein Thread gelesen wo es von 500 MB/s auf 450 MB/s eingebrochen ist mit Intel Chips und Meltdown/Spectre Patch aber das war auch schon etwas her.

Meltdown ist ein anderes Thema und hat bei den Intel Chips in der Tat 10-20% Verlust in der I/O Leistung verursacht. AMD war davon genau 0 betroffen insofern gabs bei AMD keinen Meltdown fix. Intel hat schlichtweg in der Cache implementierung geschlampt um mehr Leistung rauszuholen. AMD hat den Cache einfach sauberer implementiert.