AMD Ryzen 9 7950X3D spotted on Geekbench with similar single-core performance as 7950X

Na das sollte wohl ziemlich klar sein, daß das auf dem CCD ohne V-Cache laufen wird, nur der kann analog zum 7950X hochtakten.

Der V-Cache CCD könnte genauso wie der "normale" CCD trotzdem noch ein etwas besseres Bin als ein 7800X3D (bzw. 7800X für den cache-losen) sein, weil das nötig ist, um SoCs mit zwei CCDs in das gemeinsame Hitzebudget zu zwängen. Aber ja, sonst dürften sich die beiden, je nachdem welche Seite man abschaltet, wie der analoge "kleine Bruder" verhalten.

Für die Multithread-Leistung müssen dann beide CCDs eh auf Frequenzen heruntertakten, die unterhalb des Bereiches sind, wo die V-Cache-Variante drosseln müßte und entsprechend sind da ziemlich vergleichbare Werte zu erwarten.

Diese beiden CCDs miteinander zu kombinieren ist schon ein genialer Schachzug, aber irgendwie scheint bei der Presse noch nicht durchgedrungen zu sein, daß man die hohen Turbos und den großen Cache nie gleichzeitig bekommen kann, sondern nur über die Auswahl des entsprechenden CCDs entscheidet, welche der beiden Qualitäten man ausnutzen möchte. Das wird noch einiges Geschrei geben, wenn die Leute das endlich kapieren. Und ziemlich sicher wird es einen "7960X3D" o.ä. mit 2 V-Cache CCDs nicht geben, weil vielleicht 2 Leute auf dem Planeten dafür eine passende Workload besitzen und diese greifen dann wohl eher zum EPYC.

Das größte Problem dürfte die Software dafür sein, denn ein klassischer OS-Scheduler sollte kaum beurteilen können, welche Workload auf welchen CCD gehört. Und je nachdem wie gut das gemacht wurde, dürfte sich das Geschrei dann noch einmal vervielfachen, während Intel massiv mit seinem Thread-Director trommeln wird.

Trotzdem ist gerade der 7950X3D für Leute sehr interessant, die verstehen, was sie da kaufen. Denn er ermöglicht zum einen die hohe Einzelprozessortakte für skalare oder schwach parallele Lasten, kann zum anderen aber auch Spiele mit schwächerer Lokalität über die dicken Caches glätten, jedenfalls solange die noch nicht mehr als 8 Kerne auslasten können. Und wenn dann doch alle 8 Kerne mal voll ausgelastet werden, muß man sich eh mit weit geringeren Taktraten zufriedengeben.

Knapp sechs GHz auf 16 CMOS Kernen kann nichts und niemand mit der aktuellen Technik wegkühlen und kann es entsprechend auch nicht geben. Hier kann man eben quasi alle mögliche Kompromisvarianten mit einem SoC durchspielen und das hat was, selbst wenn es wohl kaum jemals für irgendeinen Anwender wirklich kritisch sein wird.

Antwort 2 Likes

Zunächst einmal: Die CCX gibt es bei Zen 3 nicht mehr, wo Zen 2 noch zwei CCX (2x4 Kerne) in einem CCD (core compute die) hatte, ist bei Zen3 und Zen4 pro CCD nur ein CCX vorhanden: Die einzelnen Chiplets sind quasi monolithische 8-Kerner.

Beim 7950X3D ist einer der CCDs analog zu einem 5800X aufgebaut, also ganz normal 32MB L3-Cache. Der andere ist analog zum 5800X3D, wo der L3-Cache über einen "aufgeklebten" Chip von 32MB um 64MB auf 96MB erweitert wurde. Zusammen mit den 32MB L3 vom ersten CCD gibt das 128MB L3, aber eben 32/96MB auf die beiden CCDs verteilt. Und der CCD mit der aufgeklebten Cache-Erweiterung wird beim Takt gegenüber dem normalen CCD eingebremst, weil der Cache zum eine natürlich selbst Strom braucht (6 oder 8 CMOS Transistoren pro Bit) und zum anderen die Kühlung des darunter liegenden CCD verschlechtert.

Das "aufkleben" geschieht über "TSV" oder through silicon vias die bereits auf allen CCDs seit Zen3 vorhanden sind und aber nur bei den 3D Chips mit den 64MB SRAM Chips zu einem gesamten 96MB L3 Cache verbunden sind. Das ist kein separates Cache Layer, sondern tatsächlich einfach ein entsprechend größerer Cache, der nicht einmal große Timing-Unterschiede haben soll. Wie genau die TSVs miteinander verbunden werden weiß außerhalb von TSMC wohl keiner so ganz genau, aber es ist letztendlich eine Kupfer-zu-Kupfer Verbindung ähnlich wie zwischen verschiedenen Schichten innerhalb des Chips auch, vergleichbar schnell, vergleichbare Ströme und Kapazitanz und mit einer hohen Kontaktdichte.

Zugriffe auf den L3 Cache des anderen CCD sind zwar möglich, genau wie auf die immerhin 8 CCDs von einem EPYC Chip, aber dabei muß über den Infinity Fabric und den IOD gegangen werden, was sicher immer noch deutlich schneller als DRAM sein sollte, aber deutlich langsamer als der lokale L3. Die 16 Kerne in einem Desktop SoC mit 2 CCDs oder die bis zu 64 Kerne in einem EPYC (96 bei Genoa) verhalten sich nicht mehr monolithisch.

Ob der große L3 Cache bei einer Arbeitslast überhaupt einen Vorteil bringt, hängt halt davon ab, was da gerechnet wird. Die Lokalität bei Code ist häufig so groß, daß der die meiste Zeit vollständig aus den Caches heraus laufen kann. Und wenn es bei den Daten nicht viel anders ist, oder diese im Gegenteil eine richtig miese Lokalität haben, wird man kaum einen Unterschied bemerken. Aber manche Workloads im HPC Umfeld profitieren vehement von genau diesen 64MB extra L3, daß sich spezifische EPYC Chips mit nur 3D CCDs lohnen. Und bei Spielen hat AMD offensichtlich ebenfalls genügend Fälle ermittelt, wo der 3D Cache die Leistung mehr glättet als höhere Taktraten. Und in diesen Situationen kann man mit dem 7950X3D sozusagen fliegend zwischen einem 7800X und einem 7800X3D wechseln, da die wenigsten Spiele 8 Kerne voll auslasten. Und selbst bei 8 voll belasteten Kernen dürften die Taktraten bereits so weit sinken, daß der Taktnachteil der 3D Variante eine immer geringere Rolle spielt, wenngleich sie bei Volllast auf allen Kernen möglicherweise immer noch ein kleines bißchen langsamer takten mögen, als die Kerne im normalen CCD: Die zusätzliche Hitzequelle verschwindet ja nicht.

Und ja, die Entscheidung was auf welchem CCD läuft, dürfte schwierig werden, zumal sich der Nutzen des extra Caches ja je nach Anwendung oder auch Spielszene ändern kann. Da sehe ich noch eine riesige Menge schlechter Presse auf uns zurollen, auch wenn der Ansatz eigentlich sehr smart ist.

Antwort 2 Likes

Da kommt es jetzt wohl sehr darauf an, wie gut oder schlecht AMD und Microsoft zusammenarbeiten bzw zusammen vorgearbeitet haben, um die Zuweisung von Arbeitslasten so zu machen, daß die jeweilig besser geeignete CCD (mehr Cache ist besser oder höhere Frequenz bringt mehr) entsprechend gewählt wird.
In Linux bin ich nicht viel unterwegs, aber wenn es jemand hier ist, könnte man uU schon sehen, was AMD hierzu eingebracht hat. Aber, wie gesagt, bei Linux kenn ich mich nicht so aus.

Zum Thema warum Extra Cache nur für eine von zwei CCDs : AMD hatte diese 3D Cache Geschichten ja zunächst und zuerst für Server CPUs (EPYCs) entwickelt und angeboten; denn dort gibt es eben Anwendungen, wo sich das auch für die Kunden sehr lohnen kann, die Gewinnspanne bei Server CPUs ist eben um einiges höher, und die 3D Geschichten kosten ja auch mehr in der Herstellung. Der 5800x (mit einer CCD) kam ja auch erst, nachdem AMD (TSMC Foundry) hier genügend Kapazität frei hatten, CCDs mit 3D Cache auch für Desktop anzubieten ohne Serverkunden warten zu lassen, und sich das so einigermaßen rechnete für AMD. Und bei den 7xxx Ryzens wird das nicht anders sein; Server kriegten (kriegen) zuerst, und dann Desktop, und da zunächst Mal eine CCD mit 3D Cache pro CPU, die andere bleibt "ungekrönt". Eine Desktop CPU bei der beide CCDs 3D Cache haben wird's wohl erst geben, wenn a. die Kapazität dafür frei ist und b. Intel irgendwas neueres rausbringt, das AMD die Gaming Krone wieder wegnimmt. Oder (reine Spekulation!) AMD bringt tatsächlich einen TR Nachfolger für HEDT; da könnte eine CPU mit 3D Cache auf allen CCDs uU sehr interessant sein.

Antwort 2 Likes

Ich glaube nicht, daß AMD unter Linux durch spezifische Änderungen am Scheduler zwischen beiden CCDs differenzieren wird. Und dann erfordert die Auswahl tatsächlich Anwendungswissen, welches sich vielleicht ein Profiler aber kein Scheduler generisch erarbeiten kann: Das sind keine Expertensysteme!

Mittels numactl kann man unter Linux als Anwender die Zuweisung von Prozessen auf Kerne kontrollieren und hat damit schon mal mehr Kontrolle als unter Windows ohne Hilfsmittel (z.B. Lasso) möglich ist. Für eine von AMD gelieferte Spieleoptimierungssoftware, wie sie unter Windows ggf. kommen wird, ist Linux noch zu weit davon entfernt, eine primäre Gaming-Plattform für diese Chips zu werden.
Noch gibt es ja keine Angaben darüber, wo die 3D CCDs der 7950X3D bei den Taktraten landen könnten. Wegen der besseren BINs der dual-CCDs SoCs könnte das durchaus etwas jenseits der 5GHz der 7800X3D landen und nicht jeder ist auf die letzten 400MHz oder so angewiesen.

Bei einem meiner Systeme habe ich mich bewußt für einen 5800X3D entschieden, obwohl in vielen Szenarien vielleicht ein 5800X schneller gewesen wäre, bei einem anderen hatte ich von einem 5800X auf einen 5950X gewechselt. Das Hauptmotiv für den 3D war, daß der Preisunterschied derart geschrumpft war, daß kein Schicksalsthema mehr war. Und dann ist es ein 24x7 Dauerläufer mit ECC RAM und diversen VMs, wo ich mir dank großer Caches ebenfalls weniger Ruckler vorstellen konnte, während der 5800 in jeder Variante den Haswell Xeon E3 Vorgänger um 2-4x übertrumpfen würde.

Beim EPYC hat man ein paar Anwendungen gefunden, die vom zusätzlichen 3D Cache erheblich profitiert haben, meiner Erinnnerung nach waren das z.B. Chip-Design Verification Tools, die dann auf einmal keinen Hauptspeicher mehr brauchten. Ob das beim nächsten Chip dann immer noch klappt, dürfte eher Zufall sein.

Und wenn man tatsächlich bei einer solchen Anwendung richtig was herausholen möchte, könnte es sinnvoller sein, sie auf SoCs mit HBM anzupassen, wenn diese mal in ausreichender Stückzahl und Kapazität vorliegen.

Ich bin mir ziemlich sicher, daß AMD gründlich durchgerechnet hat, ob eine Desktop CPU mit zwei V-Cache CCDs genügend kritische Käufermasse hat, um ihre SKU Kosten zu rechtfertigen. Auf Halde möchten die nach ihrem Trauma mit den LLano APUs sicher nicht wieder produzieren! Daß es sie nicht gibt, ist wohl die Antwort. Produktionskapazitäten oder -probleme sollten sie dank der vielen EPYCs inzwischen im Griff haben, die CCDs sind bis zum Einbau auf den Die Carriers ja zwischen Ryzen und EPYC nicht differenziert.

Ja, je mehr SoC Varianten man da mittel Chiplets zusammenstellen kann, desto mehr wünscht man sich wie bei einem Autohersteller eine ganz eigene Kombination zusammenstellen zu können, ohne mehr als echte Aufwände und einem minimalen Anpassungsaufschlag zu bezahlen. Aber nur Großkunden werden da bedient werden können, möglicherweise immer weniger, weil die inzwischen ihre eigenen Chip entwerfen.

Bezüglich TR steht AMD etwas unter Zugzwang, aber entsprechende SKUs sollten relativ einfach sein, sofern man den Markt als groß genug erachtet oder Intel die Parade verhageln möchte. Letzteres war bisher keine AMD Strategie, aber mit den Custom Designs der Hyperscaler wird der x86 Endkampf nur rauer werden können.

Antwort 2 Likes