Prognose-Board: Wie geht es bei AMD weiter? Entwicklungen / Strategien / Maßnahmen, die AMD betreffen bzw. die AMD treffen könnte

Das Big-Little Prinzip scheint ja beim Alder Lake-S ganz gut zu laufen: https://www.computerbase.de/2021-10...9-12900k-schlaegt-amd-ryzen-9-5950x-deutlich/

Allerdings gibt es ein kleines Detail, was mich direkt zum Lachen brachte:
108°C & 257W Package Power...

So Effizient sieht das noch nicht aus, da reicht das B2 Stepping um zu Kontern. :)

In dem 5-Jahres ZEN Jubiläum Video von AMD hatte Rober Hallock recht ausführlich diese Hybrid-CPU Designs für künftige ZEN ausgeschlossen. Mein Kommentar zur Entsprechenden News...
Keine BigLitte Lösungen mit Zen, KI-Beschleuniger in künftiger Zen-Roadmap, neue PowerSteppings für mehr Power-Domains bei GPU und CPU-Cores sowie Uncore bei APUs mit verschiedenen Algorithmen zum Power-Saving.

Ich glaube auch, die gute Performance von Alder Lake ist stark vom Verbrauch abhängig. Die Frage wird sein ob AMD mit TSMC Fertigung auch mit hohen Takten und hohem Verbrauch kontern wird.
 
Sollen sie CMP wieder einführen. Mit Zen als Basis dürfte das deutlich besser laufen und den Platzbedarf minimieren.
 
Ich glaube auch, die gute Performance von Alder Lake ist stark vom Verbrauch abhängig. Die Frage wird sein ob AMD mit TSMC Fertigung auch mit hohen Takten und hohem Verbrauch kontern wird.

Sollte Alderlakes Energieverbrauch wirklich in solche Regionen gehen, drängt sich mir der Verdacht auf, dass Intel hier mal wieder mit aller Gewalt versucht, das Maximale heraus zu pressen. Alderlake muss von Anfang an einigermaßen gut da stehen, andernfalls wäre es eine Pleite, da ich glaube, dass das Big-Little-Konzept durchaus in machen Bereichen gute Performance zeigen wird, aber eben vermutlich auch - zumindest anfangs - Schwächen haben dürfte.

Sehe ich mir die Specs vom 12900K an, wirken die auf mich etwas nach einer EE-Version: nur der 12900K hat 5,3Ghz/5,0Ghz max. Core-Overclocking für 1C/8C, der nächst-Kleinere, der 12700K, dann nur noch 5,0/4,7Ghz. Das sind satte 300Mhz bzw. über 6% Unterschied!!! Da würde dann die hohe Leistungsaufnahme des 12900K wenig verwundern. Das riecht für mich etwas nach einer Art EE-Version für gute Benchmarks...der Grund könnte sein:

AMD spricht bezüglich dem V-Cache von +15% durchschnittlicher Gamingperformance bei gleichem Takt. Das sieht für mich eher danach aus, dass AMDs Gaming-Krone noch größer werden dürfte. Und vermutlich setzt AMD wenigstens noch +200Mhz Takt mit drauf, sodass dann womöglich sogar +20% Gamingperformance raus springen könnten.

Sicher wird es viele Szenarien geben, in denen sich Alderlake weit von Zen3 abheben dürfte, aber wohl kaum durchwegs. AMD scheint hier ganz cool abzuwarten, wie sie die neuen Zen3D spezifizieren und dann im Markt platzieren. Es scheinen ja nicht mal ES davon unterwegs zu sein, oder hat irgendjemand mal was davon geschrieben?
 
Sollen sie CMP wieder einführen. Mit Zen als Basis dürfte das deutlich besser laufen und den Platzbedarf minimieren.
Meinst Du damit Crossbar/Cellular Multi Processors ala 4 oder 8 Socket Opterons?
Ich denke mit Zen-Chiplets wird AMD noch lange der Multicore-Meister bleiben, wobei jeder Core mit SMT bei entsprechender Software zusätzlich profitieren kann. Für mich ist da eher die Frage ob Intel mit Single Thread und IPC wieder ein Argument für sich gewinnen kann, das AMD mit seiner Strategie nicht übertrumpfen kann. Solch ein Argument hatte man aber auch noch vor Zen3 und dennoch war AMD erfolgreich.
 
Zuletzt bearbeitet:
AMD spricht bezüglich dem V-Cache von +15% durchschnittlicher Gamingperformance bei gleichem Takt. Das sieht für mich eher danach aus, dass AMDs Gaming-Krone noch größer werden dürfte. Und vermutlich setzt AMD wenigstens noch +200Mhz Takt mit drauf, sodass dann womöglich sogar +20% Gamingperformance raus springen könnten.

Sicher wird es viele Szenarien geben, in denen sich Alderlake weit von Zen3 abheben dürfte, aber wohl kaum durchwegs. AMD scheint hier ganz cool abzuwarten, wie sie die neuen Zen3D spezifizieren und dann im Markt platzieren. Es scheinen ja nicht mal ES davon unterwegs zu sein, oder hat irgendjemand mal was davon geschrieben?
Nochmal nachgesehen: V-Cache gemessen am 28. April 21 in 32 Spielen bei FHD in High Image Preset beim 12-Core Prototyen sind 15% im Durchschnitt, aber in den Beispielen zwischen jeweils "up to" 4% und 25%. Das bedeutet die Varianz nimmt da sehr zu. Bei noch mehr Cache könnten wiederum am ehesten die minFPS hoch gehalten werden. Bei hoch optimiertem Code wird man eher weniger Effekte feststellen. Intels höherer Takt und IPC sollte den Peak-FPS zugute kommen. Es kommt dann auf gutes Marketing an, idR hat da Intel einfach mehr Mittel.
Engineering Samples wird es deshalb nicht geben, weil diese CPUs letzlich genau gleich funktionieren sollen wie die aktuellen, nur mit mehr Cache halt, aber für Mainboards wohl transparent. Wenn überhaupt spricht das gegen höhere Taktraten.
 
Zuletzt bearbeitet:
Mit EE meinte er nicht Engineering Samples sondern es gab mal EE Modelle in Intels Core2Duo Lineup die auf hohe Takte geprügelt waren für extra Aufpreis.
 
Bei SMT tut der Kern eben nur so als wären es 2 damit er besser ausgelastet wird.
Bei CMT sind es 2 die den gleichen Durchgang nutzen müssen. Rennen sie abwechselnd durch gibt es keine Probleme, wollen sie zur gleichen Zeit durch müssen sie sich durchquetschen.
 
Ich kann es nicht ganz nachvollziehen was gemeint ist, die Abkürzungen sind oft auch nicht eindeutig.
Bei CMT würde ich den ersten AMD Dual-Core auch als gültiges Beispiel sehen, so wie hier schon angedeutet https://course.ece.cmu.edu/~ece742/f12/lib/exe/fetch.php?media=spracklen05_mt.pdf
Nach dieser (alten) Definition ist CMT als Chip-MT ein Überbegriff zu Verfahren auf dem gleichen Die (Chip), inkludiert also SMT und CMP etc.
Anandtech vermutete nach meinem Verständnis bei 8 Core-CCX ein vorläufiges Maximum. Das würde für bei Steigerung des CMT-Levels entweder mehr Chiplets oder wieder mehrere CCX je Chiplet bedeuten.
 
@E555user
Im Grunde genommen ist es recht einfach.
Jeder Kern hat viele unterschiedliche Teile und auch unterschiedliche Recheneinheiten.

Bei SMT sind lediglich die Register so ausgeführt das es nach außen so aussieht das der Kern (physisch) 2 Kerne wären. (virtuell)
Diese beiden virtuellen Kerne müssen sich also alle Ressourcen des Kerns teilen. Wie hoch die Mehrleistung durch den zweiten Thread ist hängt also erheblich davon ab wie effektiv wie effektiv die Recheneinheiten durch den ersten ausgelastet werden und welche Recheneinheit der zweite Thread fordert. Je besser die Auslastung desto schlechter die Skalierung, daher auch die extrem unterschiedliche Leistungsskalierung.

Bei CMT sind Teile des Kerns mehrfach ausgeführt, andere Teile müssen sie sich wiederum teilen. Im Falle der Bulldozer Architektur waren die Integer Einheiten (Ganzzahl) doppelt ausgeführt, die FPU (Gleichtkommaberechnung) mussten sie sich jedoch teilen. Damit hängt es also erheblich davon ab was berechnet wird was am Ende als Rechenleistung raus kommt. Ist der Code also sehr Integer lastig hat man eine sehr hohe Skalierung, bei FPU Code hält sich die Mehrleistung wiederum sehr in Grenzen.

Da eine CPU nicht zwangsläufig auf eine FPU (mathematischer Coprozessor) angewiesen ist und anfangs ohne auskam (Berechnungen konnten auch deutlich weniger effizient von den Integer Einheiten abgearbeitet werden) wurden aus den 4 Modulen mit 8 Integer Einheiten als 8 Kerner verkauft....Marketing eben.

Unterm Strich geht es einfach nur um die unterschiedlichen Ausführungen des Multithreadings im System. 2 weitere Formen sind SMP (mehrere Prozessoren im System) und eben Multicore Prozessoren.

Die Zen Architektur mit ihrem CCX Design nutzt für ihre Kerne SMT, wodurch sich die beiden Threads die Ressourcen des Kerns teilen müssen.
 
@E555user
Im Grunde genommen ist es recht einfach.
Jeder Kern hat viele unterschiedliche Teile und auch unterschiedliche Recheneinheiten.

*
Bei CMT sind Teile des Kerns mehrfach ausgeführt, andere Teile müssen sie sich wiederum teilen. Im Falle der Bulldozer Architektur waren die Integer Einheiten (Ganzzahl) doppelt ausgeführt, die FPU (Gleichtkommaberechnung) mussten sie sich jedoch teilen. Damit hängt es also erheblich davon ab was berechnet wird was am Ende als Rechenleistung raus kommt. Ist der Code also sehr Integer lastig hat man eine sehr hohe Skalierung, bei FPU Code hält sich die Mehrleistung wiederum sehr in Grenzen.

Noch kurz zum BD:
Klar muss er sich eine 256Bit FPU Teilen bei zwei Threads pro "Cluster" aber der Standard Code wollte nur 128Bit pro Kern.
Im Umkehrschluß kann der BD 4x 256Bit (AVX2) oder 8x 128Bit mit AVX.
Das ist nicht unbedingt eine FPU schwäche gewesen...
 
@WindHund
Soweit ich mich erinnere bestand die FPU aus 2x 128 Bit Teilen welche bei 2 Threads auf dem Modul entsprechend aufgeteilt werden konnte. Die volle Breite von 256 Bit war meines erachtens auch nur für entsprechenden AVX Code erforderlich. Kommt ein entsprechender 256 Bit AVX Code zum Einsatz dürfte es 2 Möglichkeiten geben ihn abzuarbeiten. Die beiden 128 Bit Teile zusammenschalten um den Code in einem Durchgang abzuarbeiten oder durch einen 128 Bit Part in 2 Durchläufen durchzujagen. Welche Version zum Einsatz kommt dürfte stark davon abhängen wie das Modul ausgelastet ist.

Das Bulldozer Design an sich hatte meiner Meinung nach vor allem ein Problem mit der Performance des Cache Systems denn auch angesichts der Anzahl der Recheneinheiten blieb die Performance hinter den Erwartungen zurück. War da nicht etwas mit dem L2 Cache der im nicht allso performanten Write Back Modus lief? Ich habe das von den damaligen Tests nicht mehr ganz so gut in Erinnerung.
Der ursprünglich geteilte Decoder war jedenfalls nicht die große Performancebremse denn bei späteren Ausbaustufen bekam jeder Integer Core seinen eigenen Decoder aber der große Performance Boost blieb leider aus.
 
@WindHund
Soweit ich mich erinnere bestand die FPU aus 2x 128 Bit Teilen welche bei 2 Threads auf dem Modul entsprechend aufgeteilt werden konnte. Die volle Breite von 256 Bit war meines erachtens auch nur für entsprechenden AVX Code erforderlich. Kommt ein entsprechender 256 Bit AVX Code zum Einsatz dürfte es 2 Möglichkeiten geben ihn abzuarbeiten. Die beiden 128 Bit Teile zusammenschalten um den Code in einem Durchgang abzuarbeiten oder durch einen 128 Bit Part in 2 Durchläufen durchzujagen. Welche Version zum Einsatz kommt dürfte stark davon abhängen wie das Modul ausgelastet ist.

Das Bulldozer Design an sich hatte meiner Meinung nach vor allem ein Problem mit der Performance des Cache Systems denn auch angesichts der Anzahl der Recheneinheiten blieb die Performance hinter den Erwartungen zurück. War da nicht etwas mit dem L2 Cache der im nicht allso performanten Write Back Modus lief? Ich habe das von den damaligen Tests nicht mehr ganz so gut in Erinnerung.
Der ursprünglich geteilte Decoder war jedenfalls nicht die große Performancebremse denn bei späteren Ausbaustufen bekam jeder Integer Core seinen eigenen Decoder aber der große Performance Boost blieb leider aus.
Selbst wenn die FPU 256Bit hat, muß es etwas Sortieren.
Ohne Schweinereien, läuft nichts mehr inzwischen.

Der L2 war beim BD 2MByte groß pro Cluster oder 1MByte pro Thread.... AVX2 konnte er nicht, aber FMA4.0
 
@WindHund
Die Excavator Ausbaustufe (Carrizo, Bristol Ridge) hatte auch AVX2 Support. ;)
Ich bin mir nur nicht sicher ob die Breite der FPU auch mal erhöht wurde. *kopfkratz
 
Sehr schöner Artikel zum Threadripper 3995WX : https://www.notebookcheck.com/Warum...ln-fuer-Visualisierung-schaffen.577369.0.html

Das ist noch die 3000 Generation, ohne V-Cache.
Die Studios haben ein neues Werkzeug entdeckt, das sie so zuvor noch nicht hatten. ;)
Doppelposting wurde automatisch zusammengeführt:

Die FPU-Breite wurde nicht erhöht, blieb immer bei 2mal 128b.
Ja, aber Pro Modul immer 2x 128Bit.
Das wären dann bei Auslastung aller Kerne 8x 128Bit.
 
Zuletzt bearbeitet:
@Zen4 (Genova) und Zen4c (Bergamo):

Könnte es am Ende gar so sein, dass sich Genova und Bergamo nicht nur im Prozess (Genova: N5P und Bergamo N4?) unterscheiden, sondern einfach auch in der Größe aller Caches, also L1, L2 und L3? Wichtig ist ja, dass die beiden Cores im Server völlig kompatibel sind, d.h. sie werden an sich die gleichen Cores verwenden und sich hardware-mäßig nur so unterscheiden, dass diese 100%-ige Kompatibilität gewährleistet ist.

Dass auch die nahen Caches wie L1 und L2 wachsen müssen, wenn man die IPC steigern will, zeigt ja auch Alderlake. Und hier dürfte es am einfachsten sein, Diesize und Verlustleistung zu sparen, wenn ich statt hoher IPC eher hohen Datendruchsatz brauche.
 
Wenn da 2 verschiedene Prozesse und damit 2 verschiedene Designs verwendet werden, dann wird man doch auch die Vorteile der jeweiligen Prozesse nicht links liegen lassen, sondern auch nutzen. Also ich denke nicht, dass man bei verschiedenen Prozessen nur die Cachegrößen ändert.
 
Bin mal gespannt wie groß der L3 noch werden wird. Den meisten Platz wird die Logik brauchen.

Wenn man bedenkt das es micro SD Karten gibt die 1 TB an Speicher fassen. Wir bei AMD bestimmt Überlegungen und machbarkeits Studien geben. Wenn man die Technik schon mal hat da gibt es viele Möglichkeiten.
 
@Peet007
Der Cache nimmt schon seit Jahren sehr viel Platz weg und die Die Größe (Fertigungskosten) begrenzt damit recht deutlich dessen Größe. Wegen der ganzen Logik Anteile des Prozessors kann man vermutlich auch nicht mit Layern arbeiten wie bei dem Flash Speicher und damit müßte man den L3 in einen separaten Chip auslagern oder wie angedacht die Chips stapeln, was aber für den viel Hitze erzeugenden Logik Part wegen des Wärmetransferes ein echtes Problem werden kann.
 
SRAM skaliert leider im Moment nicht besonders gut mit neuer Fertigung. SD Karten setzen auf flash der als Cache absolut ungeeignet ist. Am ehesten noch vorstellbar wäre ein DRAM auf der CPU oder im package. Da ist aber dann die Frage in welchen use cases das überhaupt einen großen Vorteil hätte.

Der 3d Cache von AMD ist da schon ein riesiger Sprung und bringt mehr schnellen Cache als es ein full Node Shrink könnte.
In Zukunft könnte man natürlich noch mehr Cache dies stacken, ob der Markt das bezahlen möchte wird sich zeigen.
 
Zurück
Oben Unten