News AMD Ryzen 9000 ("Granite Ridge"): Alle Fakten und Spekulationen zu den neuen Zen-5-CPUs

Also alles steht und fällt mit dem Decoder kann man sagen. Die Bulldozer hatten auch mehrere Einheiten gehabt, aber wurden nicht gut ausgelastet und so viel die Leistung am Ende nicht gut aus obwohl die CPU eigentlich zu damals eine gute war. Ich hoffe AMD macht nicht mehr den selben Fehler wie damals, kann man so sagen.
 
Es gibt einfach Aufgaben, die nicht zulassen, dass man sehr viele Dinge gleichzeitig berechnet, weil Berechnungen von den Ergebnissen vorhergehender Berechnungen abhängen.
Ein Workaround dafür ist übrigens, wenn eine Operation verschiedene Ergebnisse liefern kann die darauf folgenden Rechnungen die eigentlich auf das Ergebnis warten müssten einfach alle schon auszuführen - und dann wenn das Ergebnis da ist alle die nicht eingetroffen sind zu verwerfen.

Künstliches Beispiel: Das Ergebnis von Rechnung A könnte 00 oder 01 oder 10 oder 11 sein. Anstatt jetzt mit Rechnung B zu warten bis das Ergebnis da ist berechnet die CPU das Ergebnis C für 00, 01, 10 und 11 - und wenn dann Rechnung A fertig ist werden die drei falschen Endergebnisse verworfen, das richtige ist aber schon fertig.

Diese Art von Prefetch ist schnell(er) als warten und man kann viele ALUs parallel auslasten - aber dann geht das Geschreie wieder los weil das natürlich sehr ineffizient ist wenn 3 von 4 Rechnungen "unnötig" waren, sprich man erhöht die Auslastung der ALUs stark und damit auch die Leistungsaufnahme der CPU stark dafür, dass man am Ende ein bisschen schneller ist.

Diese Tradeoffs sind halt wirklich irre komplex. Deswegen wird ja bei jeder einzelnen Interation von CPU-Architekturen das "Prefetching verbessert" bzw. da ist seit Jahrzehnten bis heute und in Zukunft Performance zu holen. Das reine "MEHR POWER!!" ist sowohl was die wortwörtliche Leistungsaufnahme als auch die Anzahl von gut skalierenden Paralleleinheiten (und Kernen...) einer CPU für übliche Endkundenworkloads ziemlich am Limit angekommen.
 
Ein Workaround dafür ist übrigens, wenn eine Operation verschiedene Ergebnisse liefern kann die darauf folgenden Rechnungen die eigentlich auf das Ergebnis warten müssten einfach alle schon auszuführen - und dann wenn das Ergebnis da ist alle die nicht eingetroffen sind zu verwerfen.
Das geht aber eigentlich nur bei bedingten Sprüngen. Da kann man heuristisch ermitteln, ob es wahrscheinlich ist, dass ein Sprung erfolgt oder nicht und auch die Zieladdresse cachen. Das eliminiert einen Großteil der Verzögerungen bei der Ausführung von Schleifen, weil da oft der gleiche Sprung passiert.
Künstliches Beispiel: Das Ergebnis von Rechnung A könnte 00 oder 01 oder 10 oder 11 sein. Anstatt jetzt mit Rechnung B zu warten bis das Ergebnis da ist berechnet die CPU das Ergebnis C für 00, 01, 10 und 11 - und wenn dann Rechnung A fertig ist werden die drei falschen Endergebnisse verworfen, das richtige ist aber schon fertig.
Das wäre mit viel Aufwand vermutlich möglich, allerdings hat man schon bei einem achtbittigen Datentyp kaum noch eine Chance, das richtige Ergebnis zu treffen, wenn man nicht die Zahl der ALUs deutlich erhöht und es besteht die Chance, dass man Einheiten belegt, die doch noch anderweitig hätten verwendet werden können.
Diese Art von Prefetch ist schnell(er) als warten und man kann viele ALUs parallel auslasten - aber dann geht das Geschreie wieder los weil das natürlich sehr ineffizient ist wenn 3 von 4 Rechnungen "unnötig" waren, sprich man erhöht die Auslastung der ALUs stark und damit auch die Leistungsaufnahme der CPU stark dafür, dass man am Ende ein bisschen schneller ist.
Naja, wenn man wirklich nicht weiß, was man braucht, hat man schlechte Karten. Man kann teilweise natürlich vorher schon wissen, was man braucht, aber das ist ungefähr das, was man in der Regel mit der bisher verfügbaren Parallelität gut bedienen kann und für die Ausnahmen gibt es halt SIMD.
Diese Tradeoffs sind halt wirklich irre komplex. Deswegen wird ja bei jeder einzelnen Interation von CPU-Architekturen das "Prefetching verbessert" bzw. da ist seit Jahrzehnten bis heute und in Zukunft Performance zu holen. Das reine "MEHR POWER!!" ist sowohl was die wortwörtliche Leistungsaufnahme als auch die Anzahl von gut skalierenden Paralleleinheiten (und Kernen...) einer CPU für übliche Endkundenworkloads ziemlich am Limit angekommen.
Um die sequentiellen Flaschenhälse zu weiten, bzw. Behinderungen im Programmfluss zu vermeiden, muss man halt immer mehr Aufwand für immer geringere Ergebnisse betreiben. Kleinere Fertigungsprozesse können helfen, weil man z.B. mehr schnellen Cache in Taktlatenzreichweite unterbringen kann, ansonsten hätte man wieder einen Trade-Off von mehr Cache aber mit höherer Latenz.
 
Na zum reinen zocken eignet der sich ja nicht weil diese cpu nicht optimal ausgelastet wird. Mit so vielen 4,6 oder 8 Kern spielen sieht es halt sehr schlecht für den 24 Kerner aus. Es sei denn man macht 2 Sachen gleichzeitig, wie zocken und was intensives im Hintergrund, dann ja.
 
und wird werden dann sehen was in 5 Jahren noch mehr Reserven hat dein 7800 oder mein 7960
Da reicht ein kurzer Blick in die Vergangenheit. Welche CPU ist heute in Spielen schneller? Ein 2950X oder ein 3700X? Von mir aus kannst auch auch einen 2700X und einen 2950X vergleichen. Das ändert nichts ^^

In Spielen wird eine HEDT CPU auch in weiteren 5 Jahren, wahrscheinlich auch in 10 Jahren, nicht schneller als ein 7800X3D sein.
 
Zurück