AMD Zen 3 soll neue Architektur darstellen und erhebliche IPC-Verbesserungen besitzen

[pipin]

In einem Gespräch mit TheStreet hat sich Forrest Norrod – Senior Vice President und General Manager, Datacenter and Embedded Solutions Business Group bei AMD – unter anderem zu Zen 3 geäußert, auf dessen Basis erste Serverprozessoren mit dem Codenamen “Milan” für das dritte Quartal 2020 erwartet werden.

(…)

» Artikel lesen

[Opteron]

Liest sich alles ganz gut. Der Aktienkurs ist gleichzeitig auf nen neuen Höhenflug, die Kunden bestellen v.a. die teuren 64Kern Epycs und Zen3 ist ne größere Architekturänderung.
Was etwas komisch klingt ist die Sache, dass Zen3 ne komplett neue Architektur sein soll: "Zen 3 will be based on a completely new architecture".
Na wenn das so wäre, wieso heißt das Ding dann immer noch Zen?

Also die Aussage ist mal Käse. Was man erwarten kann sind halt größere Änderungen, wobei die bei Zen2 auch schon größer waren, als reine "Evolution", z.B: wurde ja auch die L1I-Größe geändert.

Anders gesagt: Wenn das nur ein Tick gewesen sein soll, müsste ein Tock quasi alles auf den Kopf stellen.

[Nero24.]

Interessant! Aber der Vergleich mit der mittlerweile aufgegebenen Tick-Tock-Strategie von Intel hinkt schon allein deswegen, da Zen 2 ja kein reiner Shrink war, sondern massiv auch an der Architektur gefeilt wurde. Man denke nur an die zusätzliche AGU, die auf doppelte Breite vergrößerte FPU sowie die zahlreichen Änderungen an Cache und Puffern. Aber schön, dass es vorwärts geht

[pipin]

https://twitter.com/EricJhonsa/statu...597757955?s=20

Wegen der Unstimmigkeiten hatte ich beim Autor sogar nachgefragt.

Seine Interpretation des Ticks für Zen 4 sehe noch kritischer.

[skelletor]

Ich denke auch, dass es eher falsch ist, das mit einem "tick - tock" in Verbindung zu bringen.

Für einen "Tick" kam in Zen2 einfach zu viel Neues zusätzlich zum Shrink. (Allein die IPC Steigerung ist ja wohl kein Tick mehr, das ist mindestens ein kleiner Tock)
Ich denke, man sollte diese Begriffe einfach nicht verwenden, nur um bekannte Schemas irgendwo drüber zu stülpen, die aktuell einfach nicht mehr passen.

Wenn sie mit Zen3 wirklich noch einmal 15% schaffen, dann sollte ich vielleicht noch ein paar mehr Aktien ins Depot legen.
Mir tut Intel fast ein wenig leid bei den Aussichten.

Gruß
skell.

[Salutos]

Das klingt sehr vielversprechend!

Aber will man sich in Sachen Tick-Tock wirklich mit Intel vergleichen?
-- bis hier war es ernst gemeint ---

Wie wäre es mit Tick-Tock-Tack-Zack-Splash als major Architecture changes
Und die Zwischenschritte Tiick-Toock-Taack-Zaack
ergäbe dann Tick-Tiick-Tock-Toock-Tack-Taack-Zack-Zaack-Splash = Zeitraum von 9 Jahren

[Berniyh]

Was etwas komisch klingt ist die Sache, dass Zen3 ne komplett neue Architektur sein soll: "Zen 3 will be based on a completely new architecture".
Na wenn das so wäre, wieso heißt das Ding dann immer noch Zen?

Ich glaube das zielt einfach nur darauf ab, dass man bei Zen 2 letztendlich das CCD/CCX Design von Zen weitgehend übernommen hatte und sich auf die Auftrennung CCD und IO Die fokussierte.
Bei Zen 3 wird wohl ein neues CCD mit vereinheitlichtem L3 kommen, weshalb man das dann wohl als neue Archtektur (des CCD) bezeichnet.
Im Blick auf das CCD ist letztendlich der Schritt Zen 2 -> Zen 3 wohl tatsächlich größer als Zen 1 -> Zen 2. Bei letzterem hingegen an anderen Stellen.
Das IO Die dürfte sich bei Zen 2 -> Zen 3 wohl nicht so sehr ändern.

[Impergator]

Seine Interpretation des Ticks für Zen 4 sehe noch kritischer.

Ich schätze ja, dass Zen 4 erst gegen Ende 2022 erscheint, was ja im Rahmen der Roadmap ist. Das wären immerhin zwei Jahre Abstand zu Zen 3, in denen man ein "Tick" mit einem Zen 3+ oder einer neuen Plattform hinkriegen kann.

[pipin]

Ich schätze ja, dass Zen 4 erst gegen Ende 2022 erscheint, was ja im Rahmen der Roadmap ist. Das wären immerhin zwei Jahre Abstand zu Zen 3, in denen man ein "Tick" mit einem Zen 3+ oder einer neuen Plattform hinkriegen kann.

Eher Ende 2021, Anfang 2022. Sonst kommt man mit PCIe 5.0 zu spät, bei dem Intel ja ordentlich auf die Tube drückt.

[mmoses]

sollte das stimmen und Zen3 nochmal 15-20% nachziehen, wird es schnell ganz garstig für Intel
Die Anlehnung an das Tick-Tock-Disaster ist nicht gerade vorbildliches Marketing, aber unterirdisches Marketing ist ja schon lange Kernkompetenz bei AMD
Was mich ja mal interessieren würde, vor zwei Jahren taucht auf den Folien auch noch ein Zen2+ auf.... ist der endgültig beerdigt?
Ein Refresh mit gefixter Randomengine und ein wenig Feinschliff hier und da, könnte mich durchaus locken, falls MSi das passende Bios rausrückt

[pipin]

Was mich ja mal interessieren würde, vor zwei Jahren taucht auf den Folien auch noch ein Zen2+ auf.... ist der endgültig beerdigt?

Nen Zen 2+ hab ich nie gesehen, es gab letztens Spekulationen um einen Zen 3+, aber die halte ich für Quatsch.

Zen+ war mal in 14nm vorgesehen und wurde dann in 12nm gefertigt, ansonsten hat sich imo nie was geändert.

[Opteron]

https://twitter.com/EricJhonsa/statu...597757955?s=20

Wegen der Unstimmigkeiten hatte ich beim Autor sogar nachgefragt.

Seine Interpretation des Ticks für Zen 4 sehe noch kritischer.

Ja eigentlich ist es kompletter Unsinn. V.a. gabs auch schon nen ältere Äußerung von Papermaster 2017:

Papermaster also confirmed the four-year target and emphasized that it didn’t mean AMD wouldn’t iterate the core. “We’re not going tick-tock,” Papermaster said. “Zen is going to be tock, tock, tock.”

Möglicherweise will man die User einfach darauf vorbereiten, dass es in Zunkunft bei AMD auch wieder etwas langsamer -eben tick-tock- voran geht, weil z.B. Zen4 möglicherweise nur ein 5nm Zen3+ wird.
Macht auch Sinn, denn die 4 Jahre, von denen Papermaster sprach, sind dann mit Zen4 auch vorbei.

[Opteron]

Ich glaube das zielt einfach nur darauf ab, dass man bei Zen 2 letztendlich das CCD/CCX Design von Zen weitgehend übernommen hatte und sich auf die Auftrennung CCD und IO Die fokussierte.
Bei Zen 3 wird wohl ein neues CCD mit vereinheitlichtem L3 kommen, weshalb man das dann wohl als neue Archtektur (des CCD) bezeichnet.
Im Blick auf das CCD ist letztendlich der Schritt Zen 2 -> Zen 3 wohl tatsächlich größer als Zen 1 -> Zen 2. Bei letzterem hingegen an anderen Stellen.
Das IO Die dürfte sich bei Zen 2 -> Zen 3 wohl nicht so sehr ändern.

Kann sein, aber mit "Architektur" meint man normalerweise nur den Aufbau eines einzelnen Kerns. Der Rest außenherum ist I/O. Wie viele Kerne da nun in nem Cluster stecken, ist eher uninteressant.

Naja wie auch immer, Zen3 wird ein größeres Projekt, da hoff ich mal weiter auf SMT4, auch wenns erst noch deaktiviert sein und erst beim Refresh freigeschalten werden sollte.

Weiteres heißes Eisen dürfte der L1D-Cache werden. Intel legt dort ne Schippe nach und hat 48 kB .. was wird wohl AMD machen? Nachdem man gerade erst den L1I aufgrund des deutlich angewachsenen µOp/L0I-Cache verkleinern konnte, wären die Optionen jetzt auch bei 48, gleich 64 oder AMD bringt auch nen L0D-Cache.
Hmm .. da müsste man eigentlich mal wieder die Patente durchforsten, was letztens alles angemeldet wurde.

[Berniyh]

Kann sein, aber mit "Architektur" meint man normalerweise nur den Aufbau eines einzelnen Kerns. Der Rest außenherum ist I/O. Wie viele Kerne da nun in nem Cluster stecken, ist eher uninteressant.

Kommt darauf an aus wessen Sicht.
Viel Ahnung über Details schien er ja eher nicht zu haben …

[Opteron]

Kommt darauf an aus wessen Sicht.
Viel Ahnung über Details schien er ja eher nicht zu haben …

Ja möglicherweise.
Hab mal nach Patenten geschaut, da gibts eines über ein "Hybrid-Cache-System":

Systems, apparatuses, and methods for implementing a hybrid cache. A processor may include a hybrid L2/L3 cache which allows the processor to dynamically adjust a size of the L2 cache and a size of the L3 cache. In some embodiments, the processor may be a multi-core processor and there may be a single cache partitioned into a logical L2 cache and a logical L3 cache for use by the cores. In one embodiment, the processor may track the cache hit rates of the logical L2 and L3 caches and adjust the sizes of the logical L2 and L3 cache based on the cache hit rates. In another embodiment, the processor may adjust the sizes of the logical L2 and L3 caches based on which application is currently being executed by the processor.

Klingt ja erstmal gut, wenn man L2 und L3 dynamisch anpassen könnte, aber physisch muss der Cache immer noch kleiner und schneller oder größer und langsamer aufgebaut sein. Da seh ich jetzt keinen Vorteil, wenn man z.B. Teile des L3s zum L2 umdeklariert. Die Latenzen wären immer noch auf schlechtem L3-Niveau. Aber so genau hab ich das Patent noch nicht gelesen.

[Species_0001]

sagt doch nicht sowas... hab doch gerade erst den 3900x eingebaut, der idled so vor sich hin... und jetzt schreibt ihr vom nächsten "shut up and take my Money" Produkt. Das ist nicht lustig

[Salutos]

sagt doch nicht sowas... hab doch gerade erst den 3900x eingebaut, der idled so vor sich hin... und jetzt schreibt ihr vom nächsten "shut up and take my Money" Produkt. Das ist nicht lustig

Wenn man das so sieht, dann darfst du dir nur alle 5 Jahre etwas Neues "leisten".
Und im Gegensatz zu Intels aktueller Produktpolitik bekommst du bei AMD etwas wirklich neues und leistungsfähigeres

--- Update ---

Ja möglicherweise.
Hab mal nach Patenten geschaut, da gibts eines über ein "Hybrid-Cache-System":


Klingt ja erstmal gut, wenn man L2 und L3 dynamisch anpassen könnte, aber physisch muss der Cache immer noch kleiner und schneller oder größer und langsamer aufgebaut sein. Da seh ich jetzt keinen Vorteil, wenn man z.B. Teile des L3s zum L2 umdeklariert. Die Latenzen wären immer noch auf schlechtem L3-Niveau. Aber so genau hab ich das Patent noch nicht gelesen.

Denke das hat weniger etwas damit zu tun, dass L2 und L3 wechselseitig größer bzw. kleiner werden, sondern eher damit was sich bei Milan (32+MB L3) bereits andeutet. Bei Milan sieht es nach einem von mehreren Kernen dynamisch geteilten L3-Cache aus. Das Prinzip wird AMD vermutlich zukünftig auch auf den L2-Cache anwenden.


und so könnte das dann in Folge aussehen


Wobei gerade auf einer Multicore CPU eben die Anwendung, die gerade am aktivsten ist, auch den meisten Cache nutzen kann.
Wie AMD es hinbekommt sowas effizient zu verwalten ist deren Geheimnis. Sinn würde das für mich machen.
Schätze mit Milan fällt hier der Vorhang.

Gruß
Salutos

[pipin]

sagt doch nicht sowas... hab doch gerade erst den 3900x eingebaut, der idled so vor sich hin... und jetzt schreibt ihr vom nächsten "shut up and take my Money" Produkt. Das ist nicht lustig

Wir reden doch bislang nur von Serverprozessoren.

[Berniyh]

Ja möglicherweise.
Hab mal nach Patenten geschaut, da gibts eines über ein "Hybrid-Cache-System":


Klingt ja erstmal gut, wenn man L2 und L3 dynamisch anpassen könnte, aber physisch muss der Cache immer noch kleiner und schneller oder größer und langsamer aufgebaut sein. Da seh ich jetzt keinen Vorteil, wenn man z.B. Teile des L3s zum L2 umdeklariert. Die Latenzen wären immer noch auf schlechtem L3-Niveau. Aber so genau hab ich das Patent noch nicht gelesen.

Also aus der Beschreibung klingt das jetzt erst mal recht nichtssagend. Könnte alles mögliche bedeuten.
Das müsste man sich im Detail anschauen um zu sehen ob und wie das funktioniert.

Was ich mir vorstellen könnte wäre, dass eine Möglichkeit geschaffen wird Teile des L3 zeitweise mit einem Core zu assoziieren um so zum einen zu verhindern, dass sich die Cores gegenseitig im Cache rumpfuschen und um dem Core eine schnellere/höhere hit rate (wie übersetzt man das?) zu ermöglichen.
Das könnte bei verschiedenen Lasten auf dem CCD durchaus helfen, oder?

[Opteron]

Was ich mir vorstellen könnte wäre, dass eine Möglichkeit geschaffen wird Teile des L3 zeitweise mit einem Core zu assoziieren um so zum einen zu verhindern, dass sich die Cores gegenseitig im Cache rumpfuschen und um dem Core eine schnellere/höhere hit rate (wie übersetzt man das?) zu ermöglichen.
Das könnte bei verschiedenen Lasten auf dem CCD durchaus helfen, oder?

Stimmt, wenn man es nur für den L3 betrachtet macht es Sinn, v.a. da wir wissen, dass der Zen3 L3 mehr Kerne versorgen muss. Da braucht man dann halt etwas mehr Logik, wo man jedem Kern seinen L3-Anteil fest zuordnen kann. Damit verhindert man dann das berüchtigte Cache-Trashing, d.h. Daten anderer Kerne schmeißen wichtige Daten für den einen Kern aus dem Cache. Wenn das dann auch noch programmierbar ist, man also je nach App und Thread den L3 aufteilen kann, freut das die HPC-Leute sicher ungemein.

[Species_0001]

Wir reden doch bislang nur von Serverprozessoren.

Schon klar, aber dass es auf Basis des Zen3 Kerns dann auch ein Consumer Produkt geben wird darf man ja sicher annehmen.

[cyrusNGC_224]

"Wir haben bei ZEN2 ausversehen mehr IPC erreicht als wir geplant hatten. Kann schon Mal passieren, Shit happens."
AMD ist echt lustig.
Ja, da wird wohl unbedachtes Marketing ursächlich für sein. Denn ein Tock-Tock-Tock ist viel naheliegender.
Wenn ZEN3 also so richtig aufgebaut sein werden soll, was könnte denn alles anstehen? Vielleicht schon die FPU für AV512 bringen, SMT4 vorbereiten,...?

War schon ein Tapeout durch?

AMD hat zudem R/D erhöht.

[Firenze]

Was ich mir vorstellen könnte wäre, dass eine Möglichkeit geschaffen wird Teile des L3 zeitweise mit einem Core zu assoziieren um so zum einen zu verhindern, dass sich die Cores gegenseitig im Cache rumpfuschen und um dem Core eine schnellere/höhere hit rate (wie übersetzt man das?) zu ermöglichen.
Das könnte bei verschiedenen Lasten auf dem CCD durchaus helfen, oder?

Das gibt es bereits, ist hier dokumentiert: AMD64 Technology Platform Quality of Service (bitte Google zu bemühen, ich darf als Neuling keine Links posten). Im Prinzip definiert man verschiedene QoS Klassen und weist jedem Prozess eine Klasse zu. Für jede Klasse kann man festlegen welchen Teil des L3 Cache der Core, der einen Prozess dieser Klasse ausführt, nutzen kann. Man hat z.B. einen 16-Way Set Associative L3 Victim Cache und normalerweise kann eine Cachezeile die aus dem L2 Cache rausfliegt in jeden beliebigen L3 Way geschrieben werden. Mit QuS kann man einem Echtzeitprozess z.B. exklusiv Way 0-1 zuweisen, während normale Prozesse auf Way 2-15 beschränkt werden, und ein Prozess mit niedriger Priorität davon wiederum nur Way 14-15 zumüllen darf, oder sogar überhaupt keinen. Der L3 Cache wird aber weiterhin von mehreren Cores gemeinsam genutzt, d.h. Daten von einer bestimmten Speicheradresse können nur einmal im Cache liegen.

[pipin]

Das gibt es bereits, ist hier dokumentiert: AMD64 Technology Platform Quality of Service (bitte Google zu bemühen, ich darf als Neuling keine Links posten). Im Prinzip definiert man verschiedene QoS Klassen und weist jedem Prozess eine Klasse zu. Für jede Klasse kann man festlegen welchen Teil des L3 Cache der Core, der einen Prozess dieser Klasse ausführt, nutzen kann. Man hat z.B. einen 16-Way Set Associative L3 Victim Cache und normalerweise kann eine Cachezeile die aus dem L2 Cache rausfliegt in jeden beliebigen L3 Way geschrieben werden. Mit QuS kann man einem Echtzeitprozess z.B. exklusiv Way 0-1 zuweisen, während normale Prozesse auf Way 2-15 beschränkt werden, und ein Prozess mit niedriger Priorität davon wiederum nur Way 14-15 zumüllen darf, oder sogar überhaupt keinen. Der L3 Cache wird aber weiterhin von mehreren Cores gemeinsam genutzt, d.h. Daten von einer bestimmten Speicheradresse können nur einmal im Cache liegen.

https://developer.amd.com/wp-content...rces/56375.pdf