AMD Ryzen 5000: Cinebench-Ergebnisse zu allen vier CPUs aufgetaucht

[lutari]

Alder Lake und Zen4 mit je DDR5 kommen bereits Herbst 2021 ! Intel hat das bereits angekündigt und AMD released immer im Jahresrhythmus.

Zen: 03/17
Zen+: 04/18
Zen2: 07/19
Zen3: 11/20

Ein Release im Herbst 2021 wäre sehr ungewöhnlich und die bisherigen Gerüchte gehen von 2022 aus.

Es gab immer Boards die beides boten. DDR1 + DDR2
DDR2 + DDR3
DDR3 + DDR4 (extrem selten)

Aber der Ram ist heute nicht mehr so auf dem Vormarsch wie früher.

Auch in der Zeit vor DDR-RAM gab es solche Boards. Beispielsweise Asus TX97-XE hat EDO-RAM und SDRAM geboten. Oder danach gab es Boards die SDRAM und DDR-SDRAM unterstützt haben.

 

[ThorsHammer1]

wenn jeder einzelne Kern 10% schneller wird, dann werden auch 4 Kerne insgesamt 10% schneller.

Nein, nur 4 Kerne können zusammen deutlich höher takten als der Grundtakt. Ausserdem sind die meisten Games immer noch aug DX11 das nur einen thread für die Grafik bereit stellt, auch bei Spielen die 4 threads nutzen wird 1 Kern meist besonders stark genutzt!

 

[latiose88]

Reine Logik. Der Allcore-Boost wird mangels Effizienz eher mau sein. Wenn du bereit bist, PPT zu erhöhen, dann greifen die höhere IPC und die höhere Taktbarkeit voll in Allcore-Szenarien.

die Konsequenz ist dann davon bzw hiervon,das dann auch die Temperaturen massiv ansteigen.Wer dann so wie ich dann mit Luftkühlung unterwegs ist,da geht dann nicht mehr allzuviel.Meine CPU heißt 3950x hat 82 Grad und ist bei 4,3 ghz.Allcore ist beim 5950x bei 4,2 ghz im Turbo modus.Das heißt viel geht da ja dann auch nicht mehr.Höherere Takt als 4,3 ghz würde die Temperaturen noch weiter erhöhen.Und das würde dann auf dauer wohl der CPU schaden,vielleicht geht da ja auch noch 4,3 ghz,aber dann ist der vorsprung nicht mehr so weit,weil es vom Takt sich nicht mehr absetzen kann.Das heißt die Multicore Leistung steigt nicht so sehr an,das es sich wirklich lohnen würde.Es bleibt halt bei den 5 % Leistungsunterschiede.
Ich habe auch vom 5950x von der ES Version die Werte gesehen.Da war Cinchebench 26 % schlechter gewesen.AMD scheint also zwischen dem ES und dem Retail Version ordentlich zugelegt.Habe darum bei allen Anwendung die dort getestet worden sind,noch gleich mal 26 % oben drauf gelegt und schwups war der 5950x überall besser als der 3950x gewesen.Kann allerdings nicht wirklich sagen ob man bei allen Anwendung wie Handbrake,Premiere und so 26 % des Ergebnis oben drauf legen kann.Denn als ich da 5 % wieder abgezogen hatte,passte das ergebnis irgendwie nicht mehr zu den regulären Benchmarks.Dann wohl doch nur 5 % oben drauf berechnen.

 

[Bl4ckR4v3n]

Cinebench hin, Cinebench her. Was wir neben optimierter Workstation-Software noch brauchen, ist eine ordentliche Mehrkernoptimierung. PCGH_Dave hat das in der PCGH 10/2020 auch nochmals angesprochen. Ich seh genau so. Die besten CB-Werte bringen uns als Spieler nichts, wenn die Games nicht auf Mehrkernbetrieb optimiert sind. Dank AMD erleben wir gerade eine regelrechte Kernschwemme. Aber bei den Games hakt es mit der Optimierung. Man stelle sich mal ein Supreme Commander, Stellaris, Wargame: Red Dragon, Anno etc. vor, das wirklich ordentlich auf Multicore optimiert wurde. Man kann nur hoffen, das durch die neuen Konsolen die Multicore-Optimierung seitens der Game-Entwickler weiter voran getrieben wird.

Kann man nur zustimmen. Nur sehe ich in diesem Kontext leider nicht so positiv. Optimierungen sind teilweise wohl sehr aufwändig und man muss sicherstellen, dass man die Kerne auch wirklich nutzt und der Overhead einem nicht die komplette Performance ruiniert. Da befürchte ich dass viele sich das Sparen und nur soweit optimieren dass alles Spielbar ist.

 

[Argolo]

Kann man nur zustimmen. Nur sehe ich in diesem Kontext leider nicht so positiv. Optimierungen sind teilweise wohl sehr aufwändig und man muss sicherstellen, dass man die Kerne auch wirklich nutzt und der Overhead einem nicht die komplette Performance ruiniert. Da befürchte ich dass viele sich das Sparen und nur soweit optimieren dass alles Spielbar ist.

Manchmal ist es auch schlichtweg nicht praktikabel. Eine vernünftige Parallelisierung zu konzepieren und zu implementieren kann einem verdammte Kopfschmerzen bereiten. Sobald mehrere Threads auf eine gemeinsame Resource zugreifen müssen und diese entsprechend abgesichert werden muss, kann man die Multicore-Skalierung vergessen.

 

[latiose88]

Also willst du damit sagen,wenn mehrere auf einem selben Cache drauf zugreifen kann das zum teil langsamer sein als wenn jeder Kern seine eigene Cache für sich hat oder was willst du uns damit denn genau sagen ? @Argolo

 

[Argolo]

Also willst du damit sagen,wenn mehrere auf einem selben Cache drauf zugreifen kann das zum teil langsamer sein als wenn jeder Kern seine eigene Cache für sich hat oder was willst du uns damit denn genau sagen ? @Argolo

Nein. Ich spreche von einem kritischen Abschnitt auf Programmebene. Grob gefasst: Du hast ein Programm mit mehreren Threads, die zbs. auf dieselbe Variable zugreifen und ändern dürfen. Ein Beispiel: Eine zwei Variable i und j sollen ausgelesen werden, mit +1 addiert werden und wieder geschrieben werden. Bei zwei Threads (A und B) kann dann sowas passieren:

i = 1, j=1
Thread A ließt i aus
Thread A ließt j aus
Thread A berechnet i+1=2
Thread A berechnet j+1=2
Thread A schreibt i=2
Thread B ließt i=2 aus
Thread B ließt j=1 aus
Thread A schreibt j=2
Thread B addiert i+1=3
Thread B addiert j+1=2
Thread B schreibt i=3
Thread B schreibt j=2

Folglich sind die Variablen am Ende mit i=3 und j=2 belegt, obwohl man eigentlich erwarten würde, dass beide denselben Wert haben sollten. Damit sowas nicht passiert, werden die Threads gezwungen aufeinander zu warten, sodass nur genau einer diesen Teil des Programms ausführen darf. Du kannst dir ja vorstellen, was dann passiert, wenn man 64 Threads spawnt. Da verbringt jeder Thread 99% seiner Lebenszeit mit warten.

 

[latiose88]

@Argolo

Ok wie sieht es denn dann mit wenn man zwei mal die gleiche Software startet aus.Beide berechnen das selbe.Zwar mit z.b anderen Aufnahmen zum umwandeln aber schon Paralell.Diese kommen sich doch nicht in die Quere oder und könnte ein Kern der ja aus einem richtigem und einem virtuellen besteht auch aufgeteilt werden,so es am ende auch z.b 7 1/2 Kerne jede Anwendung bekommen könnte.Wenn man z.b den beiden Anwendung die selben Kerne zuteilt.ALso sprich man nehme 4 richtige Kerne Weg und lässt den beiden Software 4 virtuelle Kerne der 4 echten Kerne einfach berechnen.
Darf also ein Kern der ja aus 2 Threads besteht denn die Threads überhaupt aufteilen.Also sprich ein Thread fürs zocken und eines zum anwenden einer Software außerhalb des zockens?
Oder könnte es den Kern ansonsten ausbremsen wenn man es so verteilt dann?

 

[Argolo]

@Argolo

Ok wie sieht es denn dann mit wenn man zwei mal die gleiche Software startet aus.Beide berechnen das selbe.Zwar mit z.b anderen Aufnahmen zum umwandeln aber schon Paralell.Diese kommen sich doch nicht in die Quere oder und könnte ein Kern der ja aus einem richtigem und einem virtuellen besteht auch aufgeteilt werden,so es am ende auch z.b 7 1/2 Kerne jede Anwendung bekommen könnte.Wenn man z.b den beiden Anwendung die selben Kerne zuteilt.ALso sprich man nehme 4 richtige Kerne Weg und lässt den beiden Software 4 virtuelle Kerne der 4 echten Kerne einfach berechnen.
Darf also ein Kern der ja aus 2 Threads besteht denn die Threads überhaupt aufteilen.Also sprich ein Thread fürs zocken und eines zum anwenden einer Software außerhalb des zockens?
Oder könnte es den Kern ansonsten ausbremsen wenn man es so verteilt dann?

Uff... Dafür ist der Prozess-Scheduler deines Betriebssystems zuständig. Auf einem normalen Desktoprechner verwaltet das Betriebssystem etwa mehrere tausend Prozesse zur gleichen Zeit. Der Prozess-Scheduler teilt den Prozessen jeweils Rechenzeit auf der CPU zu. Wenn du einen Prozessor mit 16 Logischen Kernen hast, können somit nur bis zu 16 Prozesse (Wenn Prozesse mehrere Threads haben entsprechend weniger) laufen und alle anderen müssen warten. Ich weiss jetzt nicht genau, worauf du hinaus willst.

Edit: Ich glaube so langsam zu verstehen, wo du hin willst. Wenn du "zwei mal die gleiche Software" startest, dann arbeiten beide oftmals praktisch unabhängig voneinander. Dann hast du natürlich eine echte Parallelisierung. Die skaliert natürlich praktisch linear mit der Anzahl der verfügbaren Kernen. Das ist auch meistens das goldene Ziel, wenn man versucht sein Programm zu parallelisieren. Im schlimmsten Fall berechnet man aber alles nur mehrfach, anstatt vorliegende Zwischenergebnisse zu nutzen.

 

[latiose88]

na wollte von dir wissen ob das ebenso in das fällt was du da so beschrieben hast oder es dann ein anderer Fall ist und somit mit dem was du als beispiel genannt hast nix zu tuen hat.
Wenn nicht dann war es das unwissen gewesen und ich habe das dann miteinander verwechselt.Zuerst dachte ich ja eventuell bremsen sich weil es ja zwei die selbe Anwendung ist,sich gegenseitig ja aus,das ist ja eben nicht der Fall.
Scheint also doch das Problem zu entstehen.
Nun das scheint sich wohl auf nur eine Anwendung zu beziehen von dir,nicht jedoch wenn man mehr als einmal die selbe Anwendung aufmacht.Weil du ja was von das der eine Thread auf den anderen Wartet.
Nun was ich bisher gemacht hatte,einfach 4 echte Threads weggenommen und die restlichen also in dem sinne die am ende übrigen 32 Threads auf die beiden Anwendung verteilen lassen,indem ich einfach nur die haken beim Tasmanager bei beiden die 4 gleichen Threads einfach den haben weggeklickt hatte.Somit können beide wohl beliebig drauf verteilen.
Anders wäre es wohl gewesen wenn ich einfach jedem nur feste 16 Threads zuteilen würde und dann das Game starten würde.Dann würde es wohl zu konflickten kommen da ja die alle schon belastet werden.
Könnte mal ausprobieren was dann passieren wenn beide Anwendung fest zugeteile Threads kriegen und dann das Game starten.Ob dann das Game abstürzt oder einfach nur die beiden Anwendung dann automatisch langsamer umwandeln.

Bisher habe ich ja es so gemacht das ich da einfach im Taskmaager oder einem extra Tool namens processlasso da feste kerne der Anwendung egal wie oft diese gestartet wird einfach diese Threadzahl zugeordnet bekommt und dann der rest so frei zur verfügung steht.
Im grunde trifft also so wohl keine überschneidung oder sowas was du erwähnt hast zu.

Es sei denn ich starte das Programm 5 oder 6 x und lasse mit jedem Programm davon was umwandeln,ich denke mal dann wird es mit der Zeit auch da mal zu einer überschneidung kommen,weil irgendwann es dann doch mal zu viel sein könne oder bist du da einer anderen Meinung?

 

[Incredible Alk]

Vorsicht - eine manuelle Kernzuweisung von Programmen/Prozessen bedeutet nicht, dass man auch gespawnte Threads zuweist (falls das gemeint ist).
In aller Regel kann der Scheduler von Windows mit all dem schon sehr gut umgehen. Es gibt aber Situationen wo man manuell eine bessere Ausnutzung der Rechenleistung erreichen kann wenn man gezielt zuweist.
Beispiel: Zwei Instanzen eines Videoencoders starten und jeder Instanz 8 Kerne / 16 Threads zuweisen ist effektiver als beiden Encodern 32 Threads zu gebgen und Windows machen zu lassen. Das liegt aber nicht nur daran dass in letzterem Falle die Wartezyklen die Argolo erklärt häufiger werden sondern auch daran dass ein Encoder der 16 Threads spawnt naturgemäß effizienter ist als einer der 32 spawnt weil der Workload nunmal auch seriellen Code enthält (vgl. Amdahl).

In einer Situation "Spielen + Streamen + Encodieren auf 3950X" als beispiel würde ich persönlich schon die Threads manuell festlegen. Etwa 8 bis 12 Threads fürs Spiel (je nachdem wie viel gut genutzt werden) und die restlichen hälftig für Streamingsoftware und Encoder. Das dürfte effizienter und Latenzärmer sein als "alle dürfen alles" und der Scheduler rödelt sich einen.

Es sei denn ich starte das Programm 5 oder 6 x und lasse mit jedem Programm davon was umwandeln,ich denke mal dann wird es mit der Zeit auch da mal zu einer überschneidung kommen

Da überschneidet sich nix. Denn wenn es das tut kassierste nen BSOD.
Klar, wenn die Ressourcen nicht reichen wenn du etwa auf nem 8-Kerner wirklich 8 Instanzen aufmachst wird die Performance ins bodenlose fallen - aber Überschneidungen von Speicherbereichen sind der sofortige Tod, dann zerschießt die Programm A die Daten von Programm B.

 

[openSUSE]

Man kann seiner Fantasie ja gerne hier und da freien Lauf lassen, aber wie du auf diese Aussage kommst, entzieht sich mir. Die Anwendungs-IPC hat gar nichts mit der Spieleleistung zu tun. IPC ist eine kontextabhängige Größe. Die höhere Spieleleistung wird vom überarbeiteten Cache-Design und ein wenig vom neuen Core-Design kommen.

Klar entzieht es sich dir, liegt aber eher an dir.
Es gibt keine Anwendungs-IPC, es gibt schlicht "Singlecore"-IPC. Wenn man AMD nicht unterstellen will auf CB zu optimieren, dann bedeuten über 100 Punkte mehr im CB-"Singlecore"Bench schlicht und einfach eine umso deutlichere Steigerung der "SpieleLeistung". Ist eigentlich eine einfache Korrelation, wirst du am 5.11 sicher auch noch lernen.

 

[Taxxor]

Es gibt keine Anwendungs-IPC, es gibt schlicht "Singlecore"-IPC. Wenn man AMD nicht unterstellen will auf CB zu optimieren, dann bedeuten über 100 Punkte mehr im CB-"Singlecore"Bench schlicht und einfach eine umso deutlichere Steigerung der "SpieleLeistung". Ist eigentlich eine einfache Korrelation, wirst du am 5.11 sicher auch noch lernen.

Natürlich gibt es eine "Anwendungs-IPC" und die ist auch von Anwendung zu Anwendung unterschiedlich.

Wenn man z.B. die FP Units aufbohrt, wird man eine deutliche IPC Steigerung in FP-Lastigen Anwendungen haben, in Anwendungen die mehr nach INT Performance verlangen, wird man dann aber bei gleichem Takt kaum Vorteile haben.

Würdest du den L3-Cache von Zen3 von 32 auf 8MB reduzieren, hättest du immernoch die gleiche Cinebench SC Performance, wärst in Spielen aber deutlich langsamer.
Deshalb hat man ja auch sehr viel mehr als Cinebench SC benutzt, um auf die durchschnittlichen 19% zu kommen.

 

[gaussmath]

Klar entzieht es sich dir, liegt aber eher an dir.
Es gibt keine Anwendungs-IPC, es gibt schlicht "Singlecore"-IPC. Wenn man AMD nicht unterstellen will auf CB zu optimieren, dann bedeuten über 100 Punkte mehr im CB-"Singlecore"Bench schlicht und einfach eine umso deutlichere Steigerung der "SpieleLeistung". Ist eigentlich eine einfache Korrelation, wirst du am 5.11 sicher auch noch lernen.

Ne, du bist da einfach völlig falsch informiert. Spiele sind eher latenz-lastig, Cinebench hingegen compute-lastig. Das hat eine hat mit dem anderen fast überhaupt nichts zu tun.

Nimm Renoir als Beispiel, der L3 Cache ist nur 1/4 so groß, aber der Cinebench Score ist davon unberührt. Die Spieleleistung hingegen bricht stark ein.

 

[latiose88]

Und Videoumwandeln ist Integer Lästig.Cache latenz und so bringt da keine verbesserung.
Man sieht also deutlich wie Unterschiedlich die Anwendung sind.Soweit ich gesehen habe wurde an der Integer noch so viel Optimiert,mehr im Cache Latenz und beim Stromverbrauch.Das ist also nicht so viel.

 

[openSUSE]

Natürlich gibt es eine "Anwendungs-IPC" und die ist auch von Anwendung zu Anwendung unterschiedlich.

Wenn man z.B. die FP Units aufbohrt, wird man eine deutliche IPC Steigerung in FP-Lastigen Anwendungen haben, in Anwendungen die mehr nach INT Performance verlangen, wird man dann aber bei gleichem Takt kaum Vorteile haben.

Würdest du den L3-Cache von Zen3 von 32 auf 8MB reduzieren, hättest du immernoch die gleiche Cinebench SC Performance, wärst in Spielen aber deutlich langsamer.
Deshalb hat man ja auch sehr viel mehr als Cinebench SC benutzt, um auf die durchschnittlichen 19% zu kommen.

Ne, du bist da einfach völlig falsch informiert. Spiele sind eher latenz-lastig, Cinebench hingegen compute-lastig. Das hat eine hat mit dem anderen fast überhaupt nichts zu tun.

Nimm Renoir als Beispiel, der L3 Cache ist nur 1/4 so groß, aber der Cinebench Score ist davon unberührt. Die Spieleleistung hingegen bricht stark ein.

Meiner Meinung nach ist euer "scharfes Trennen" der IPC zwischen Spiele und Anwendungen ein wenig zu kurz gegriffen. Dafür ist Software heute schlicht zu vielseitig. Klar kann man unterscheiden welche Software eher Latzen, Cache, prediction,FP, ... Lastig ist, aber eine generelle Trennung zwischen Spiele und Anwendungen auf IPC ebene halte ich schlicht für falsch, auch kann man aufgrund der verwendeten Algorithmen heute kaum noch zwischen Game oder Anwendung unterscheiden. Und wieder hängt genau dies natürlich vom dem(?) Spiel, aber auch von der(?) Anwendung ab.

Und nochmal: Ryzen 3000 bring xyz Punkte in CB "Singlecore", wenn man nun AMD nicht unterstellen will für den CB optimiert zu haben sondern das System "Ryzen" optimiert hat, dann bedeuten ÜBER 100 Punkte mehr im CB "Singlecore" eindeutig eine noch deutlichere Steigerung bei der "SpieleLeistung".

 

[gaussmath]

Und nochmal: Ryzen 3000 bring xyz Punkte in CB "Singlecore", wenn man nun AMD nicht unterstellen will für den CB optimiert zu haben sondern das System "Ryzen" optimiert hat, dann bedeuten ÜBER 100 Punkte mehr im CB "Singlecore" eindeutig eine noch deutlichere Steigerung bei der SpieleLeistung.

Nein, bedeutet es nicht, weil sich die Workloads grundlegend unterschieden.

 

[Taxxor]

eine generelle Trennung zwischen Spiele und Anwendungen auf IPC ebene halte ich schlicht für falsch

Wir trennen ja auch nicht nur zwischen Spielen und Anwendungen(Spiele sind ja im Grunde auch Anwendungen), sondern generell zwischen allen Anwendungen.
Eine Cinebench Singlecore Steigerung sagt dir noch nichts über die 7-zip Leistung oder andere Anwendungen aus.

Alleine die Unterschiede in den 4 gezeigten Anwendungen zeigen doch, dass zwischen 5 und 27% alles an Steigerung dabei ist. Und für jede dieser Anwendungen würde eine unterschiedliche IPC rauskommen.
Genau wie bei den Spielen auch, hier sieht man jetzt nur 4, in der großen Folie beim 3900X/5900X mit den 10 Spielen war da aber auch wieder von 5% bis 50% alles dabei.

 

[openSUSE]

Nein, bedeutet es nicht, weil sich die Workloads grundlegend unterschieden.

Deren Korelation für Ryzen 3000 aber schon bekannt ist.

Wir trennen ja auch nicht nur zwischen Spielen und Anwendungen(Spiele sind ja im Grunde auch Anwendungen), sondern generell zwischen allen Anwendungen.
Eine Cinebench Singlecore Steigerung sagt dir noch nichts über die 7-zip Leistung oder andere Anwendungen aus.

Anhang anzeigen 1337440

Alleine die Unterschiede in den 4 gezeigten Anwendungen zeigen doch, dass zwischen 5 und 27% alles an Steigerung dabei ist. Und für jede dieser Anwendungen würde eine unterschiedliche IPC rauskommen.

Das zeigt es doch, eine Unterscheidung in "Anwendungs-IPC" und "Spiele-IPC" ist überholt.
Es geht hier ja weniger um den Ryzen 5000 CB "Singlecore" Score ansich, es geht um die steigerung gegenüber dem Ryzen 3000. Und, wenn AMD nicht nur auf CB optimiert hat, kann man sehr wohl sagen, dass die "SpieleLeistung" dann überproportional zu dem "Singlecore" Score zulegen wird.

 

[gaussmath]

Deren Korelation für Ryzen 3000 aber schon bekannt ist.

Inwiefern bekannt? Gibt's einen Link mit entsprechenden Tests dazu?