1% Lows?
- Ersteller Stevo35
- Erstellt am
Maviapril2
Lt. Commander
- Registriert
- Nov. 2008
- Beiträge
- 1.532
azereus
Rear Admiral
- Registriert
- Okt. 2007
- Beiträge
- 5.747
danyundsahne
Commodore
- Registriert
- Okt. 2007
- Beiträge
- 4.458
Mr. Smith
Commander
- Registriert
- Mai 2010
- Beiträge
- 2.263
In aller Regel immer die grundlegend schnellste Gaming-CPU.Stevo35 schrieb:
In diesem Falle der 9800X3D, gefolgt vom 7800X3D.
Manche Engines mögen den Cache und da folgt dann auf dem dritten Platz dann oft der 7600X3D oder der 5800X3D. Andere Games mögen eher den Takt und da ist auf Platz 3 dann halt ein 14900KS u.ä.
- Registriert
- Apr. 2008
- Beiträge
- 12.612
Die schnellste Spiele CPU bei den FPS bietet meist auch die besten 1% lows.Stevo35 schrieb:
Also der 9800X3D.
Aber es ist ein Trugschluss, zu glauben dass die X3D CPUs mit ihrem Cache die Ruckler stoppen können, die die 1% Lows dominieren.
Der L3 Cache hat fast nur das drin, was schon vorher aus L1 und L2 Cache geflogen ist.
Ein "Nachladeruckler" ist genauso ein Problem wie sonst auch.
Aber die X3D CPUs können mehr zufällige Arbeitsspeicher Zugriffe abfangen, deren Daten aus einem kleineren L3 Cache bereits verdängt worden wären.
Das sorgt für weniger Wartezeiten der CPU Schaltungen und auch weniger "Stau" beim Arbeitsspeicher.
X3D hilft also schon die CPU besser auszunutzen und das kommt auch den 1% Lows zugute...nur eben prozentual und nicht als Lösung für das Problem in der Programierung des Spiels.
Auch dazu gibt es Tests hier auf CB:
https://www.computerbase.de/artikel...08/#abschnitt_leistungsrating_fps__frametimes
Bei den Frametimes ist Intel nur mit den ZEN5 non x3d Chips gleich auf.
https://www.computerbase.de/artikel...08/#abschnitt_leistungsrating_fps__frametimes
Bei den Frametimes ist Intel nur mit den ZEN5 non x3d Chips gleich auf.
Pepsi.Cola
Banned
- Registriert
- Sep. 2023
- Beiträge
- 1.141
Eine X3D-CPU hat grundsätzlich bessere Frametimes als seine "Non-X3D"-Pendants, dies kann man tatsächlich so sagen.Stevo35 schrieb:
Hier fehlen zwar die 9000er, aber ich habe gerade nichts besseres gefunden.
Xes
Admiral
- Registriert
- Nov. 2013
- Beiträge
- 7.645
Eventuell wäre das Thema um die RAM Virtualisierung auch mal ein interessantes Thema für diese Plattform.Baal Netbeck schrieb:
Ich habe das aus der Informatik Vorlesung nicht mehr besonders gut im Kopf aber grob war es, wenn ich mich recht erinnere (und mit einem flüchtigen Blick auf Wikipedia) so:
(Kein Anspruch auf Korrektheit, das ist wirklich schon eine Weile her!)
Jeder Prozess der auf dem Rechner läuft bekommt einen eigenen Speicherbereich.
Um diese Speicherbereiche sauber von denen der anderen Prozesse zu trennen und variabel in der Größe machen zu können, ohne für fortschreitende Schreibzugriffe feste Puffer einplanen zu müssen, wird den Prozessen "vorgegaukelt" sie hätten theoretisch unbegrenzten RAM nur für sich selbst. Sie bekommen also alle einen eigenen virtuellen RAM.
Der gesamte zur Verfügung stehende virtuelle Speicher wird dabei in einzelne Bereiche (Pages) mit fixer Größe (z.B. 4KiB) unterteilt. Benötigt ein Prozess einen mehr/weniger großen Speicher, bekommt er eben mehr/weniger Pages zugeteilt. In diese Pages werden dann die Daten geschrieben.
Diese Pages werden irgendwo auf den physischen RAM, oder wenn da kein Platz ist auf den Datenträger abgelegt (Swap, Auslagerungsdatei).
Um die Pages zu finden (also die Übersetzung virtuelle Adresse zu physischer Adresse im RAM oder auf dem Datenträger) gibt es den "Translation Lookaside Buffer" kurz TLB, der liegt im L1 Cache der CPU und speichert die letzten verwendeten Zugriffe/Übersetzungen, davon aber eben (bedingt durch die kleine Größe) nur eine kleine Menge.
Gibt es einen TLB miss (also die Übersetzung zur gesuchten physischen Adresse liegt nicht im TLB), muss über die Page Tables gesucht werden.
Diese Tabelle, in der alle Übersetzungen gespeichert sind, kann enorm groß werden und passt nicht komplett in den L3 Cache, weshalb Teile davon auch noch in dem RAM müssen.
Im Worst Case kommt es also dazu, dass für die Suche nach der physischen Adresse der gesuchten Page (mit den gerade benötigten Daten), erst noch ein zusätzlicher Aufruf im RAM nach der Adressübersetzung gemacht werden muss.
Da RAM Zugriffe viel langsamer als Cache Zugriffe sind, bremst das natürlich enorm.
Genau hier haben die X3D CPUs den Vorteil, weil sie einen größeren Teil der Übersetzungstabelle (Page Table) im L3 halten können und es so zu weniger RAM Zugriffen kommt.
Das dürfte übrigens auch erklären, warum X3D CPUs weniger von schnellem RAM profitieren, als die CPUs mit kleinerem L3 Cache: Es gibt ganz einfach weniger RAM Zugriffe, also ist letzterer auch weniger oft der Flaschenhals.
