News AMD nimmt Stellung zu "Low-Res-Schwäche" von Ryzen

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
Am 2. März stellte AMD seine neuen High-End-Prozessoren der Serie Ryzen offiziell vor. Dabei konnte AMDs neue Prozessor-Architektur Zen die Erwartungen weitestgehend erfüllen und bot jede Menge Leistung zu gegenüber Intels 8‑Kern-Prozessoren deutlich geringeren Preisen. In niedrigen Auflösungen hinkte Ryzen den Intel-Systemen bei einigen Spielen jedoch hinterher, weshalb sofort der Begriff “Low-Res-Schwäche” die Runde machte. Die Spekulationen begannen.
(…)

» Artikel lesen
 
Ich weiß nicht welches Video ihr gesehen habt, aber der Artikel bei pcper sagt was anderes: https://www.pcper.com/image/view/79526?return=node/67315

The Windows scheduler was already keeping those threads within the same CCX. This was repeatable (some runs were on the other CCX) and did not appear to be coincidental. Further, the example shown in the first (bar) chart demonstrated a workload spread across the four cores in CCX 0.

Hätte nicht gedacht, dass ich hier mal Windows verteidigen muss :-)
 
@MacroWelle: Du hast recht, hab ich Aussage etwas entschärft. Was aber nichts daran ändert, dass die Latenzen durch die Decke gehen sobald Kerne über CCX-Grenzen hinweg miteinander kommunzieren müssen.
 
Was mich überrrascht hat ist, dass die Kommunikation zweier logischer Kerne innerhalb eines physischen Zen-Kerns nach diesen Messungen etwa 26 ns dauert, wohingegen bei Intels Haswell-E nur 14 ns vergehen. Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel. *kopfkratz
 
@ Nero24

Wie sieht es denn bei euren Tests aus, seit ihr schon ein paar Geheimnissen auf der Spur?
 
Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel. *kopfkratz

Na ich weiss nicht. SMT lastet ja in erster Linie die Pipelines besser aus. Wie wie lang ist die denn bei Ryzen und by Skylake? Ich glaube nicht das sich das auf die Latenzen runterbricht.

Irgendwo hab ich übrigens gelesen das es eben nicht so sei das der Scheduler CCX aware verteilt, und wenig verwunderlich abhängige Threads die auf einem laufen schneller sind als auf CCX0 und CCX1.

ich such mal....

EDIT: hier

https://www.youtube.com/watch?v=JbryPYcnscA

macht bis 20% aus.... ziemlich eindeutig wie ich finde...Kann ja auch sein das es eine Kombo aus beidem ist. Kann Software dem Scheduler Anweisungen in irgendeiner Form mitteilen?
 
Zuletzt bearbeitet:
Nach einer News auf heise.de soll der Ryzen einen Bug bei hoch optimierten FMA3 Code besitzen. Wird aber wahrscheinlich durch ein Update des Microcodes behoben werden oder zumindest der Systemabsturz umgangen.
 
Was aber nichts daran ändert, dass die Latenzen durch die Decke gehen sobald Kerne über CCX-Grenzen hinweg miteinander kommunzieren müssen.
Das ist der Nachteil der Architektur die auf solche Cluster von Kernen aufbaut und bei Naples dürfte es noch schlimmer werden, wenn die Kerne nicht auf dem gleichen Die sind.
Was mich überrrascht hat ist, dass die Kommunikation zweier logischer Kerne innerhalb eines physischen Zen-Kerns nach diesen Messungen etwa 26 ns dauert, wohingegen bei Intels Haswell-E nur 14 ns vergehen.
Intel hat in dem Bereich signifikant investiert und die TSX Befehle sind nur ein Zeichen dafür, wie intensiv Intel an dem Problem der Kommunikation zwischen den Kernen gearbeitet hat. AMD kommt bei RYZEN mit 10% weniger Fläche aus, obwohl die signifikanten Strukturen bei GFs 14nm Prozess größer als bei Intels 14nm Prozess sind, es gibt also erheblich weniger Transistoren, dies hilft Energie zu sparen und damit der Effizienz, aber es hat eben auch einen Preis, wenn man die Dinge dort einfacher hält.

Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel. *kopfkratz
Wenn SMT effizienter ist, dann ist immer etwas andere ineffizienter, da SMT immer nur ein Lückenbüßer ist und man damit die Rechenwerke auslasten kann, während ein Thread warten muss. In einer optimalen Architektur bei der alle Vorhersagen für die Sprünge und die Daten die als nächsten in den Cache zu laden sind perfekt funktionieren würde, wäre SMT sinnlos, weil es dann keine solche Lücken geben würde in denen man die Rechenwerke mit Abarbeitung der Befehle eines zweiten Threads sinnvoll auslasten kann. Die gute Effizienz von SMT könnte also die Folge der langsamen Kommunikation zwischen den Threads sein, da ist nicht wirklich ein Widerspruch vorhanden.
 
Das überrascht mich deswegen, da in vielen der Tests der SMT-Speedup bei Ryzen höher war, als bei Intel, was darauf hindeutete, das AMDs SMT-Implementierung effizienter arbeiten würde als die von Intel. *kopfkratz
Das ist IMO kein Widerspruch. Man muss hier eine Sache berücksichtigen: Kommunizieren die Threads viel miteinander oder bekommen die nur ihre Arbeit, erledigen diese und melden sich danach mit dem Ergebnis zurück.

Die Verarbeitung mittels SMT kann durchaus effizient sein, aber in dem entsprechenden knapp 30minütigen Videobeitrag von PC Perspective kommt klar raus, dass die Kommunikation von Threads zwischen den beiden CCXs - also über die Inifinity Fabric - zu deutlich mehr Latenz führt. Wenn die Threads aber einfach eine bestimmte Arbeit bekommen und nach Abarbeitung nur das Ergebnis zurückgeben müssen, findet kaum Kommunikation zwischen den Threads statt, die relevant Einfluss auf die Latenz und damit auf die Performance hätten.

Man kann davon ausgehen, dass die Kommunikation zwischen Threads bei Spielen deutlich intensiver ausfällt (Reaktion auf Eingaben des Benutzers, Aktionen der KI im Spiel etc), als das beispielsweise bei Cinebench der Fall ist, das "nur" Workers auf die vorhandenen Kerne verteilt und deren Ergebnisse darstellt.

Grüße
Dalai
 
Ich glaube nicht, dass eine Kommunikation von Threads tatsächlich direkt zwischen Kernen erfolgt.
Dazu sind die Programmiersprachen viel zu weit von der tatsächlichen Hardware entfernt.
Variablen werden befüllt und landen in Caches auf die zugegriffen wird. Kontextswitches finden statt, usw.
Dies ist die maßgebliche Geschwindigkeit.
Es gibt ja nichtmal direkte Maschinenbefehle für eine Interprozessorkommunikation.
Daher denke ich, dass dieses "Problem" keines ist und überbewertet wird.
 
Die Kommunikation zwischen den SW Threads läuft immer auf eine Kommunikation zwischen den Kernen/Threads der CPU hinaus, anderes kann es ja nicht gehen, wenn die SW Threads auf unterschiedlichen Kernen/Threads der CPU laufen.
 
Zurück
Oben Unten