Laut meinem Verständnis spricht es eigentlich
für den Code, dass er bereits mit wenig Cache flutscht wie Butter in der Sonne.
.gif "sm_B-) :-)")
Ständiges Überladen des Caches und somit viele Speicherzugriffe bremsen massiv. Die Cache-Giganten sind nur so gut, weil nicht effizient programmiert wird.
MfG
Raff
Man kann den Spieß auch umdrehen: Bei Doom ist einfach der CPU-Code so kacke optimiert, dass die Kerne gar nicht erst in die Verlegenheit kommen, auf den RAM warten zu müssen. In Anbetracht dessen, dass es da eigentlich keinen Spielinhalt gibt, der 16 Kerne erfordert, würde ich die Interpretation sogar vorziehen, aber im Großen und Ganzen werden hier Äpfel mit Birnen verglichen:
Es gibt Aufgabenstellungen, die sind (wenn die GPU ausreicht) eher CPU-limitiert und es gibt solche, die eher RAM-Latenz oder RAM-Transferraten-limitiert sind. (Und natürlich noch ein paar mehr.)
Vcache löst respektive lindert Latenz- und, bei regelmäßigen Zugriffen, Transferratenprobleme. Sonst nichts. Doom wird, wie man meinem Wissen nach auch am Stromverbrauch sehen kann, eher durch die Recheneinheiten denn durch die Datenversorgung limitiert. Das ist auch naheliegend bei einem Titel, der mit extrem hohen Frameraten läuft, denn da wiederholen sich Inhalte natürlich häufiger.
Klar - der Hauptverbraucher ist da aber der I/O der immer noch keine P-States kennt. Ich hatte ja gehofft dass AMD dem Ding irgendwnn auch beibringt Spannung und Takt zu senken wenn er nix zu tun hat aber das ist bisher nicht passiert. Ich vermute, dass der Vorteil ~10W weniger im Idle abzuliefern da einfach nicht den Aufwand rechtfertigt es technisch hinzukriegen... denn im laufenden Betrieb beispielsweise den IF absenken und alles was da dranhängt dürfte ziemlich komplex sein.
Mal sehen ob/wie Intel das löst wenn die auch auf Chiplets gehen mit ArrowLake.
Monolith oder Chiplets respektive Tiles macht da keinen großen Unterschied. Je indirekter Verbindung, desto größer ist der Verbrauch der Interconnects und desto wichtiger wären Stromsparzustände für diese, aber einführen kann man sie auch bei Monolithen – und das hat Intel schon vor Ewigkeiten gemacht. Ich glaube 800 MHz ist weiterhin das Idle-Default für den Ring-Bus. Für Sapphire Rapids (sowohl den XCC mit Tiles auch den monolithischen MMC) gibt es jetzt zusätzlich einen "Optimized Power Mode", der den Takt aggressiver sent beziehungsweise bei sich anbahnender Last weniger aggressiv/proaktiv wieder hochfährt. Soll laut Intel bei Server-Workloads mit hohem Teillastanteil 25 Prozent Stromeinsparungen bei 5 Prozent weniger Rechenleistung bieten. Für Desktop-PCs, bei denen schnelle Reaktionen des Systems die User-Experience dominieren, muss man damit aber vorsichtig sein.
Die Frage, warum AMD das umgekehrt nicht (so gut) hinbekommt, kann ich aber nicht beantworten. Motivation hätten sie eigentlich genug, schon in der ersten Epyc-Generation ging teilweise die Hälfte der Package Power für den Uncore-Bereich drauf.
Vielleicht müssen wirklich mal Prozessoren her, die die ganzen ultra-ollen 8086-Schwänze abschneiden. Da schleppen wir immer noch unsäglich viel alten Müll mit rum, das ist teils noch Pröll aus den späten 1970ern...
"Aber die Kompatiblität..."
Gruß,
Phil
Kauf dir einen Apple M1 und werde glücklich mit den Spielen, die darauf laufen.
Der Trend in den letzten Jahrzehnten ging aber eher in Gegenrichtung: x86 MIPS und PowerPC aus den Konsolen gekegelt, IA64, Sparc und Power aus den meisten Großrechnern, ARM aus den Low-End-Notebooks und im teureren Bereich der Tablets konnten auch Marktanteile zurückerobert und gehalten werden. Eine Zeit lang wurde sogar CUDA zurückgedrängt und Intel hat für das letzte Event sogar eine ganze Reihe von namenhaften Industriesprechern zusammen gekarrt, die deutliche Vorteile im Bereich KI-Einsatz sowie einigen bislang von ASICs dominierten Edge-Anwendungen sehen. Und diese Sprecher durften nicht einmal Zen 4 berücksichtigen.
Abgesehen von geringen Verlusten in einigen speziellen Server-Anwendungen war Apple die einzige Schlecht, die x86 in den letzten Jahren verloren hat, trotz allen "Mülls". Der wird nämlich eigentlich nicht mitgeschleppt, sondern besteht aus ein paar Byte Microcode, die niemanden stören, solange sie nicht abgerufen werden – und die richtig viel wert sind, wenn doch mal kompatibel sein möchte.
Warum? Vor der Ryzen-Ära war es normal, dass Intel für CPUs mit >4 Kernen >1'000€ verlangte
16 (?) Kerner für >20'000€ und solche Geschichten. Es gab dabei oft Enthusiasten, die jedes eine oder zweite Jahr Hunderte € aus dem Fenster warfen, um vielleicht 5% mehr Performancepotenzial zu bekommen.
Noch früher in der Athlon 64-Ära verlangte AMD auch mindestens hohe 3-stellige Beträge für den FX-60 als schnellste Dual-Core-CPU auf dem Markt, als Single-Core noch normal war.
Für die meisten Gamer:innen, die ein neues System aufbauen wollen wird eh der 7800X3D die als Gesamtpaket interessanteste CPU sein. Moderaterer Preis und voraussichtlich unschlagbare Effizienz bei gleichzeitig einer der höchsten Performancelevels auf dem Markt im Gamingbereich.
Das für Server-CPUs teils fünfstellige Summen verlangt werden, ist bis heute normal. Umgekehrt war zum Beispiel der i7-5820K Jahre vor Ryzen ein sehr beliebter Sechskerner für unter 400 Euro, von Phenom II ganz zu schweigen. Das hat aber nichts damit zu tun, dass Preise um den vierstelligen Bereich herum für die jeweilige Top-Desktop-CPU relativ normal sind. Das war schon so, als dahinter noch "DM" stand und hat sich nach dem Währungswechsel sehr schnell wieder etabliert, als Ende 2003 der P4EE und eine Woche Später der FX-51 (mit einem Kern) für 999 Euro erschienen. (Straßenpreis bei AMD tendenziell höher da schneller.)
