Zwingt Hintergrundlast einen Quadcore in die Knie? Eine Analyse von gaussmath [Leser-Special]

Hinweis der Redaktion: Der folgende Artikel wurde PCGHX-User Gaussmath, und nicht von der Redaktion geschrieben. Wenn Sie selbst Interesse haben, einen Userartikel zu verfassen, dann empfehlen wir Ihnen unsere Anleitung: So werden Sie Autor auf PCGH.de.

"Moar Cores" ... oder doch nicht?

Anfang Mai hat AMD das Zen-2-Matisse-Portfolio um zwei weitere CPUs erweitert, nämlich den R3 3100 und den etwas potenteren Bruder R3 3300X. Beide Modelle verfügen über 4 Kerne und SMT, also 8 Threads. Aber wie passt das zu der allgemeinen "Moar Cores"-Strategie von AMD? Können die Kernzwerge bezogen auf Spieleleistung wirklich überzeugen, quasi ohne Kernreserve? Einen Launchtest der beiden Ryzen-3-CPUs gab es wie immer auch hier bei PCGH. Die beiden Quadcores haben sich nicht bloß brav in die unteren Ränge eingegliedert, wie der Preis etwa vermuten ließe, sondern im Mittelfeld ordentlich Bambule gemacht. Gerade der 3300X zeigte sich sehr stark in den Benchmarks. Liegt das möglicherweise an den eingangs erwähnten Latenzen? Zunächst schauen wir uns jedoch den Einfluss von Hintergrundlast an.

Realistische Hintergrundlast

Warum versehe ich den Begriff Hintergrundlast explizit mit dem Adjektiv realistisch? Im Vorfeld habe ich einige Diskussionen über das Thema geführt. Dabei wurden mitunter Vorschläge gemacht, die einfach unrealistisch sind in Bezug auf das Nutzungsverhalten eines Quadcores. Muss eine CPU mit 8 Threads wirklich ein Video rendern können, während man spielt? Oder darf sich ein Fullscan eines Virenscanners nicht auf die Frametimes auswirken? Das müssen wir rigoros zurückweisen, weil selbst ein Octacore das nicht unbedingt vermag zu stemmen.

Folgende Anwendungen/Tasks bilden das Hintergrundlastszenario:

• Avast Antivirus (alle Shields aktiv)
• Firefox mit mehreren Tabs + YT Musikvideo
• Discord
• Visual Studio + CapFrameX im Debugmodus
• RTSS
• Taskmanager
• ICUE

Auch das oftmals gescholtene "saubere" Windows ist nicht gegeben. Die Windows-Installation ist etwa ein Jahr alt und hat einiges hinter sich, kann aber andererseits auch nicht als "zugemüllt" bezeichnet werden. Die goldene Mitte haben wir hier also, was letztlich nicht schaden kann.

Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath

Testmethodik und Spieleparcours

Der Parcours beinhaltet Titel, die sehr gut multithreaded optimiert sind, aber auch u. a. DirectX-11-Spiele, deren Thread-Hunger eher genügsam ist.

• Shadow of the Tomb Raider (DX12)
• The Division 2 (DX12)
• Ghost Recon Breakpoint (Vulkan)
• Metro Exodus (DX12)
• Star Wars Jedi: Fallen Order (DX11)
• Far Cry New Dawn (DX11)
• Battlefield V Singleplayer (DX12)

In diesem Test gibt es zu jeder getesteten Custom-Szene ein Video auf meinem YT-Channel, um maximale Transparenz zu bieten.

Damit der tatsächliche Einfluss der Hintergrundlast ermittelt werden kann, muss die reine CPU-Leistung gemessen werden. Dazu wird mit einer Auflösung von 720p ein CPU-Limit erzeugt. Das reicht im Allgemeinen nicht, also müssen Settings her, welche die CPU fordern, aber die GPU entlasten. Da hier eine Budget-CPU getestet wird, habe ich dieses Mal von Ultra-Settings abgesehen. Stattdessen wird jeweils das High Preset verwendet. Zusätzlich werden die anisotrope Filterung, Anti-Aliasing und die Umgebungsverdeckung so weit wie möglich minimiert. Post Processing verursacht in der Regel nur wenige Drawcalls, daher kann es bedenkenlos deaktiviert werden.

Settings auf einen Blick: 720p, High Preset, AA/AF/AO min, Post Processing aus

Die Dauer der Runs beträgt jeweils 20 Sekunden. 3 valide Runs bilden eine valide Session. CapFrameX ist so konfiguriert, dass ein Fehler von 3% akzeptiert wird, anderenfalls verwirft das Tool den Run und dieser muss wiederholt werden. Das Overlay ist aktiviert und zeigt den Status der Run History an.

Ich habe bei diesem Test einen sehr hohen Wert auf Reproduzierbarkeit und Genauigkeit gelegt. Das hat seinen Preis, denn Spiele wie z.B. Battlefield V können einem schon mal ein paar graue Haare wachsen lassen. Man muss als Tester genauestens auf die Startpostion, den Blickwinkel und die Script-Trigger achten, zusätzlich noch auf das mürrische Speichermanagement. Ein weiteres Beispiel ist Ghost Recon Breakpoint. Um identische Bedingungen bzgl. der Spielewelt zu gewährleisten, muss man den Run jeweils von einem Biwak-Aufenthalt aus starten, aber auch zusätzlich noch eine Fernreise vorab machen. Das kostet Zeit, aber andernfalls lässt sich die 3% Toleranz nicht einhalten. Tag- und Nachtzyklen müssen bei Far Cry 5 oder The Division 2 zwingend eingehalten bzw. abgewartet werden, ansonsten gilt auch hier, dass die Toleranz nicht ausreicht. Moderne Spiele zu testen, ist kein Zuckerschlecken, deshalb hier an der Stelle meine Anerkennung für die Redakteure der PCGH, die sich nahezu täglich damit auseinandersetzen müssen.

Das Testsystem

• CPU 1: AMD R3 3300X @ 1866MHz IF
• CPU 2: AMD R9 3950X SMT aus @ 1866MHz IF
• Kühler: be quiet! Dark Rock PRO 4
• Mainboard: ASRock X470 Taichi
• RAM: 32GB G.Skill 3733MT/s 16-17-16-34 1T
• GPU: RX 5700 Pulse @ OC + 20% PL

Reicht eine RX 5700 wirklich aus, um ein CPU-Limit zu erzeugen oder muss es immer eine RTX 2080 Ti sein? Das kommt natürlich immer auf die CPU selbst drauf an, aber nicht nur. Die 3D-API spielt ebenfalls eine Rolle. War AMD früher, vielleicht sogar heute noch, verschrien für den CPU-Overhead unter DirectX 11, so sehr hat sich das mitunter bei DirectX 12 umgekehrt.

Das sieht weit weniger dramatisch aus, als man vielleicht vermutet hätte. Oder etwa doch? Das Extrembeispiel ist Battlefield V, das einen Leistungsverlust von fast 20% bei P0.2 aufweist. Aber, P0.2 liegt immer noch bei über 100 Fps, was für die verwendete RX 5700 im GPU-Limit völlig ausreichend ist. Die Werte sind zudem weit von dem entfernt, was man als "unflüssig" bezeichnen könnte. Entweder sind die prozentualen Leistungsverluste gering oder das Niveau ist insgesamt immer noch sehr hoch. Ich konnte beim Testen keinen Unterschied feststellen. Es fühlte sich vergleichbar flüssig an. Im Mittel ergibt sich ein Leistungsverlust von unter 10%.

Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath Quelle: PCGHX-Autor gaussmath

CPU FPS vs. GPU FPS

Die interessante Frage ist ja nun, wie sich das ganze im GPU-Limit verhält. Reichen die FPS der CPU für die verwendete Grafikkarte?
Dazu lässt sich eine smarte Matrixdarstellung bemühen. Siehe die Grafik FPS_Coverage_Matrix. Dort lassen sich auch die verwendeten Settings entnehmen. Die P1 Werte des GPU Testes werden gegen die P1 Werte der CPU Tests aufgetragen. P1 ist strenger in Bezug auf die Qualität der Frametimes als Average. Ein Feld ist dann grün, wenn die FPS der CPU größer als die FPS der GPU sind oder die Abweichung marginal ist. Zusätzlich schärfere Bedingungen bekommt man, wenn Überabdeckung gefordert wird, also letztlich Reserven.
Quelle: PCGHX-Autor gaussmath FPS Coverage Matrix Man sieht, dass sich die Verhältnisse kaum ändern, wenn Hintergrundlast in die Gleichung einbezogen wird. Einzig SotTR kommt als rotes Kästchen hinzu. Wie kritisch die Unterabdeckung letztlich ist, muss jeder selbst entscheiden. Streng betrachtet ist der 3300X zu schwach für die RX 5700 in 1080p mit High Settings. Allerdings liegt Far Cry 5 Ryzen-CPUs sowieso nicht sonderlich. Alternativ könnte man die Auflösung erhöhen, um das GPU-Limit weiter zu verlagern. Der 3950X hingegen schafft in allen Worst-Case-Szenen souverän die Abdeckung der GPU Fps. Das liegt fast ausschließlich an den zusätzlichen Threads und ein wenig am höheren Boost-Takt.

Der besondere Clou mit den Latenzen

Wie Dave bereits im oben verlinkten Test ausgeführt hat, unterscheiden sich der 3300X und der 3100 durch die genutzten Einheiten auf dem Chiplet. Der 3300X nutzt insgesamt nur ein CCX, der 3100 hingegen 2, aber mit nur jeweils 2 Kernen. Die Threads sind also rein rechnerisch identisch. Der Unterschied ist dennoch gravierend bezogen auf die Intercore-Latenzen. Ein CCX kann mit einem anderen CCX immer nur über den I/O-Die kommunizieren. Innerhalb des CCX-Moduls werden die schnellen "Direct-Links" genutzt, siehe die folgenden Messungen mit SiSoftware Sandra.

Die kleineren Werte mit 11.5 ns sind die Latenzen innerhalb eines Kerns (SMT). Die größeren Werte im Bereich 63 - 67 ns sind die Latenzen über den I/O-Die, die Werte im Bereich 26 ns sind den "Direct-Links" zuzuordnen. Das Verhältnis der Latenzen I/O-Die zu "Direct-Link" liegt bei ca. 2,5. Diesen Unterschied darf man getrost als signifikant bezeichnen.

Noch ein paar Worte zum Begriff "Direct-Link". Man muss hier mit der Interpretation vorsichtig sein. Das bedeutet nicht etwa, dass die Kerne direkt verbunden sind. Eine Cache-Line wird (worst case) über die Kette L1->L2->[L3->L3]->L2->L1 transferiert. Die gesamte Cache-Hierarchie von Kern i und j sind somit an der Kommunikation beteiligt. Das "direkt" bezieht sich ausschließlich auf das Routing innerhalb der Cache Slices [L3->L3] und gilt nur dann, wenn die Netzwerktopologie vollständig verbunden ist, was bei einem Zen-CCX der Fall ist.

Ein Vergleich des 3100 mit dem 3300X bzgl. der Spieleleistung wäre nun interessant, aber bitte so, dass Cache und Takt nicht bremsen. Wie bekommt man das hin? Man konfiguriert einen größeren Ryzen so, dass er sich wie ein 3100 verhält. Ich habe also das zweite Chiplet des 3950X abgeschaltet und dann eine 2 - 2 Konfiguration für die CCX-Module im UEFI ausgewählt. SMT muss natürlich aktiviert werden.

Die Ergebnisse sind teils ziemlich interessant, wie ich finde. Im besten Fall steigt P0.2 in SotTR um über 20%. Far Cry 5 weist hingegen sogar einen Leistungsverlust im Bereich von ca. 10% auf. Im Grunde kann das nur an der geringeren Größe des L3-Caches liegen. Mit der verwendeten Konfiguration verfügt der 3950X über 32 MiB L3-Cache, der 3300X kann dagegen auf 16 MiB Last Level Cache zugreifen.

Eines lässt sich daraus jedoch ableiten. Wenn Zen 3 hinsichtlich der Intercore-Latenzen annähernd vergleichbar aufgebohrt wird, dann kann man dadurch eine ordentliche Performancesteigerung erwarten. Wie groß das letztlich ist, ist schwer zusagen. In diesem Fall sind es im Mittel um die 10%. Mit mehr L3-Cache wären es vielleicht sogar 12-15%. Wenn ich mir die Zahlen so anschaue, dann erscheinen 15-20% mehr Spieleleistung gegenüber Zen 2 gar nicht mal so unrealistisch, sofern weitere Optimierungen hinzukommen. Das ist wohlbemerkt Spekulation. Die tatsächliche Leistungssteigerung muss natürlich später in korrekten Launchtests aufgedeckt werden. Ich bin jedenfalls gespannt.

Fazit

Aus P/L-Sicht ist der 3300X eine ziemlich überzeugende CPU. Die Lasttests haben gezeigt, dass der Quadcore selbst mit Hintergrundlast kaum einbricht. Von fehlender Kernreserve kann man daher im Grunde bezogen auf Hintergrundlast nicht sprechen. Dennoch fehlen letztlich Threads und zwar für die Spiele selbst. Das offenbart ein Blick auf die Coverage-Matrix und sagt einiges über die Multithread-Optimierung von modernen Spielen aus. Mit einer RX 5600XT oder GTX 1660 ließe sich der R3 noch gut kombinieren. In Verbindung mit einer Mittelklassekarte wird's hingegen schon eng. Die Auflösung weiter zu erhöhen, wäre ein probates Mittel, dem zu begegnen. Es kommt drauf an, welche Frameraten man anstrebt. 60 Fps sind auch mit Hintergrundlast bezogen auf den Testparcours immer drin.

Der Latenztest hat einige interessante Erkenntnisse über die Abhängigkeit der Spieleleistung von den Intercore-Latenzen gebracht. Zen 3 ruft quasi schon aus der Ferne. Das Hardware-Jahr wird auf jeden Fall wieder sehr spannend.

Artikel teilen

Eine Analyse von PCGH-Leser gaussmath: In diesem Test schauen wir uns den Ryzen 3 3300X genauer an. Wie schlägt sich der Zwerg bei der Spieleleistung ohne Kernreserven, wenn Hintergrundlast auf die CPU einwirkt? Außerdem wird der Einfluss der Intercore-Latenzen untersucht, denn der R3 3300X verfügt über nur ein CCX-Modul, was sich positiv auf die Latenzen auswirkt. Aber beeinflusst das auch die Spieleleistung?

Per E-Mail versenden

54