AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?

[Complicated]

Diese Aussage gibt die verlinkte SK hynix Folie nicht her. Dort ist verglichen mit SRAM oder eDRAM ist von relativ hohen Latenzen die Rede.

Da hast du Recht. Ich hatte mich auf diesen Teil bezogen:

Und kommt mir bitte nicht mit HBM, das hat zwar Bandbreite, aber die ist der CPU ja eh in den meisten Fällen egal, da spielt die Latenz eine viel größere Rolle. Und da HBM immer noch blödes DRAM ist, wird sich hier auch kaum was ändern können...

Tatsächlich relativiert der zweite Satz mit SRAM dies. Sorry @Payne. Hatte ich missverstanden, daher auch meine Referenz zu den Vergleichen mit DRAM.

--- Update ---

Mir kommt es jedenfalls so vor, als wenn hier einer HBM mit DRAM und der andere HBM mit SRAM-Cache vergleicht.
Ich hoffe, der Hinweis räumt ein Missverständnis aus.
MfG

Korrekt. Ging auf mich

 

[gruffi]

Jupp, genau das habe ich getan und auch geschrieben:
Ich gehe von der durchschnittlichen IPC eines cores aus.
Durchschnitt aller (oder zumindest aller getesteten) workloads.

Nun gut, dann zäumst du das Pferd von hinten auf. Ich weiss nicht, ob diese Herangehensweise wirklich sinnvoll ist. Üblicherweise misst man IPC singlethreaded und nicht multithreaded. Aber gut möglich, dass AMD einen Anwendungsmix aus single- und multithreaded Workloads genommen und dann verglichen hat, was bei einem Bulldozer Modul und einem Zen Kern bei gleichem Takt rauskommt. Dann wäre singlethreaded sicherlich auch mehr als 40% möglich, weil SMT die IPC pro Thread mehr drückt als CMT. Multithreaded wäre es entsprechend weniger als 40%. Aber das sollte bei doppelt so vielen Threads verschmerzbar sein. Aber da können wir jetzt noch so viel spekulieren. Ohne konkretere Infos von AMD werden wir nicht wirklich schlauer.

Willst du damit ernsthaft behaupten das für dich nach dem Decoder die Verarbeitung der Informationen abgeschlossen ist?

Habe ich das irgendwo geschrieben? Nein.

Denn graben wir mal alte CPUs aus, 80286, 80386, 80486 und schauen uns die mal an.
Was sehen wir?

Richtig, nur stumpfe Dinge, die Befehle ausführen -> BD hat 2 Cores pro Modul, mit einer geteilten FPU (die eben NICHT Teil eines x86 Cores ist, da das erst beim 80486DX dabei war, SX hatte keine aktive FPU und die davor externe), auch der NX586 hatte keine FPU (nur spätere Versionen als MCM Modul).

Heutzutage IST die FPU aber nun mal Teil der CPU. Du kannst eine x86 CPU mit aktuellen Befehlssätzen gar nicht mehr ohne FPU designen. Zumal die FPU mittlerweile mehr beherrscht als nur reine FP Instruktionen. Diesem Umstand muss man Rechnung tragen und kann sich nicht auf Paradigmen von vor 35 Jahren oder so berufen. Punkt. Ausserdem geht es um mehr als nur die FPU, wie zB (Pre-)Fetch. Auch andere Einheiten sind nur einmal vorhanden. Das Modul ist der eigentliche Kern. Alles andere sind nur Threading Mechanismen.

So und anhand der Fakten haben wir nunmal 8 Cores -> 8 Integer Ausführungseinheiten.

Das sind keine Fakten. Das ist lediglich Marketinggeschwätz für Ahnungslose, um Produkte so anzupreisen, wie man sie gerne verkaufen möchte. Wenn wir neuerdings EUs als Kerne zählen würden, dann hätte ein Bulldozer Modul ja derer drei, 2x Integer + 1x FP. Ist natürlich Quatsch. Echte Fakten liefern nur die Designer und Ingenieure.



Wie viele Kerne zählen wir? Richtig, 4 und keinen mehr. Wer mehr zählt sollte eventuell einen Besuch beim Optiker in Erwägung ziehen. FIG. 2 zeigt übrigens auch die komplette Pipeline. Und solange diese nicht durchgehend für zwei parallel Befehlsströme ausgelegt ist, was sie definitiv nicht ist, kann man es auch nicht als mehrere Pipelines und damit mehrere Kerne betrachten. Wenn dir das nicht passt, dann bezeichne es halt als "Marketing-Kern". Ich hingegen halte mich an die Sichtweise der Designer und Ingenieure, die mMn auch die richtige ist.

 

[nVoodoo]

Na unganged war abseits von puren Single-thread Anwendungen sowieso schon immer besser
Zum Bild: Hatte ich auch gesehen, bedeutet aber nicht, dass es 2 MC gibt. Möglicherweise 2 Dram-Kontroller ja, aber 2 MC wäre ziemlich besch..eiden, da Cluster1 ans RAM von Cluster2 dann nur über Umwege = höheren Latenzen rankäme.
Andererseits ... ondie machts vielleicht nicht soviel aus und mit 8 MB L3 ... hmmm .. aber ich glaub nicht wirklich daran.

Frage wäre dann auch was man dann bei der Zen-APU machen würde, bekäme die dann nur ein single-Channel Interface?
Was dafür spräche wäre vermutlich wieder der Aufwand+Preis ... so 2 Quadcluster nebeneinander hingeklatscht ohne weiteren Aufwand wäre sicherlich am billigsten. Die Nodestruktur wäre wie bei den NUMA-Opterons, d.h. die OSse darauf vorbereitet ... könnte damit einigermaßen klappen.

Unwahrscheinlich ist es nicht, aber gefallen würde es mir nicht sonderlich ... aber wer weiss, wenn das mit dem Scheduling gut klappt, hat es vielleicht überwiegend (Latenz-)Vorteile.

Könnten das auch 2x128bit sein?! Weil ich mein das wäre schon n fetter DIE mit allein 20MB cache (4MB L2 + 16MB L3) so viel hat auch erst der Haswell-E...
Für die Opterons (extra Sockel) dann 8C/16T + QD-DDR4
Desktop (AM4) 8C/16T + DC-DDR4 begrenzt durch AM4 also nur je MC 1x64bit statt 2x64bit nutzbar?
Und bei teildeaktivierten CPUs dann sowieso nur je MC 1x64bit

Bei diesem "Cluster" Aufbau mit zwei MCs würde man ja auch ne große Auswahl an CPU Variante haben selbst wenn ein MC einen Defekt hätte, könnte man ja immanoch einen voll Funktionsfähigen Cluster mit 4C/8T und DC?-DDR4 verkaufen...

 

[sompe]

Ja das hast du.

Naja, wir wissen doch, dass es in Wirklichkeit nur 4 physische Kerne (4 verarbeitende Pipelines) sind, die jeweils mittels diverser Threading-Mechanismen 2 Threads ausführen können. Insofern halten wir uns an die technischen Grundlagen und kümmern uns nicht darum, wie das Marketing Kerne zählt.

Wie ich bereits schrieb, auch für Integer sind nur 4 Pipelines vorhanden. Wäre ja auch komisch wenn nicht. Zu Beginn der Pipeline steht (Pre-)Fetch und Decoding. Diesen Einheiten ist es erst mal völlig wurscht ob Integer, FP, Sprung oder was auch immer für Instruktionen. Eine EU ist keine Pipeline. Man kann sie vielleicht maximal als Teilpipeline betrachten bzw Teilpipelines, wenn man ALUs und AGUs separat betrachtet. Davon spreche ich aber nicht. Ich spreche von der gesamten Architekturpipeline.

Deinem Verständnis nach richtest du deine Wahrnehmung der Ausführungseinheiten anhand der Decoder aus und demzufolge hat er nur 4 Ausführungseinheiten weil der ur Bulli nur einen Decoder/Prefetch pro Modul hat, welche die Daten lediglich in mundgerechte Häppchen aufarbeiten. Demzufolge siehst du auch lediglich den Decoder/Prefetch Part als Ausführungseinheit an und das ist ganz einfach Bockmist³.

 

[MacroWelle]

Naja, das stand so im Ursprungsartikel bei SA, da sie nur 4 Cores pro "Einheit" entdeckten es dafür offiziell aber nur ne APU gibt. Von daher war es erstmal die Frage, ob das überhaupt SR ist, oder nicht die APU.

Aber gut, wenn man die 2. Hälfte mit einrechnet, wären es 8. Sähe dann zwar erstmal etwas merkwürdig für einen einzigen Chip aus, da die Quad-Cluster soweit auseinanderliegen, aber aus Design-Widerverwertungsgesichtspunkten könnte es wohl doch so sein. Außerdem war ja schon bekannt, dass die 2 Quad-Cluster relativ unabhängig sein werden, z.B: einen eigenen L3-Cache haben. Von daher dann ok, aber die APU-Story war sicher Mist

Es ist offensichtlich SR, zum einen hat AMD von dem schon Fotos und zum anderen sieht man die 8 Kerne je DIE bzw. innerhalb der schwarzen Umrandungen. Außerdem nehmen die Kerne samt L3 ca. die Hälfte der Chipfläche ein - das ist realistisch.

Hm, dann wird es wohl bald einen L4 Cache geben...
Momentan haben wir ja:
L1 + L2 Cache sind Core Exklusiv.
L3 für ein 'Coremodul'
Und dann L4 über den gesamten Chip.

Ich halte es für völlig offen, ob der L3-Cache je Modul (4 Kerne) oder je Chip sichtbar ist, also zwischen den Modulen shared. Zumindest bei IBM kann ich mich daran erinnern, dass shared Caches segmentiert nach Nähe zu bestimmten Kernen angesteuert wurden. AMD müsste halt die Betriebssysteme dazu kriegen ihre Prozesse clever zu platzieren, um den relativ langen Weg zum nächsten L3 zu vermeiden, wenn ein "L3-See" voll läuft.

Weiß jemand wie stark sich ein paar Millimeter mehr oder weniger Distanz zum Kern bzw. L2-Cache auswirken? Weil so ein neu designtes Cache-System wird sicher auch die Distanzen berücksichtigen.

Zum IMC wurde ja auch schon etwas geschrieben. Ich denke auch hier wird jedes 4er-Pack Kerne seinen präferierten Kanal haben, aber nicht exklusiv. Wenn der eine Speicherkanal mehr zu tun hat als der andere, müssen die Prozesse auch hier wieder neu auf die Kerne verteilt werden. Im Vergleich zu einem voll symmetrischen Design wird das höchstens bei sehr heterogenen Prozessen unter hoher Last zum Problem, weil man dann den weiter entfernten Kanal stark in Anspruch nehmen muss.

Wobei erst einmal abzwarten bleibt, ob die APUs überhaupt einen L3 Cache haben werden.
Den hat AMD ja leider auch bei den aktuellen APUs eingespart...

Das ist auch ein Interessantes Thema. Bei einer APU liegt ja der Blick bei der Anbindung eher bei der GPU, weil die so stark an der Bandbreite hängt, während die CPU an sich typischerweise zwangsläufig nicht mehr als Mittelklasse ist.

So gesehen macht entweder ein klassicher LLC für die ganze APU oder eDRAM oder HBM auf den Interposer. Ich glaube das man das bisher nicht gemacht hat war vor allem eine Kostenfrage. Bei Haswell hat man ja gesehen, dass es technisch geht, und das war nur MCP, dafür aber auch 128 MB

näher zusammen geht wohl gar nicht wg. Temperaturproblemen (die dann zum Flaschenhals bei der Taktbarkeit werden). Gerade die FPU wird irre heiß, da sollte man nicht zwei FPUs direkt nebeneinanderbauen, besser irgendwelche anderen Strukturen dazwischen. Dürfte evtl. auch der Grund sein, warum die beiden Blöcke etwas versetzt sind. Zudem wird man sicherlich auch die Funktionsblöcke umgrenzen müssen, um sie komplett abschalten zu können.

Interessanter Punkt, dass fällt ja auch beim Uncore-Bereich auf.


<offtopic>

Langsam muss es mal raus: mich erinnert diese 4-Kern-Modulbauweise irgendwie an die SAW-Filme - 4 cores build a zen-house!

 

[Dresdenboy]

<offtopic>

Langsam muss es mal raus: mich erinnert diese 4-Kern-Modulbauweise irgendwie an die SAW-Filme - 4 cores build a zen-house!

Und der Schlusskurs in Amerika: $4.04 ...

 

[mulle]

Und der Schlusskurs in Amerika: $4.04 ...

Tatsächlich... Bin ich mit meinen AMD Aktien doch tatsächlich wieder im Plus.

 

[Meckel]

Schau mal die IBM-Prozessoren an. Da gibt es noch einige spannende Ideen. Auch in der Forschung - sogar ohne Quantencomputer. Z.B. asynchrone Einheiten (besser als bei Armulet u.ä.).

Nix mehr für dieses Jahrzehnt, und die IBM-Dinger habe ich als fett und teuer gesehen.

Ein Stack-Cache wäre auch neu.

Der Stackframe wird ja über die "normale" Cache-Hierarchie abgefackelt.

 

[Dresdenboy]

Nix mehr für dieses Jahrzehnt, und die IBM-Dinger habe ich als fett und teuer gesehen.



Der Stackframe wird ja über die "normale" Cache-Hierarchie abgefackelt.

Fett und teuer war auch mal der L1 Cache, die FPU, eine 2. ALU, usw. Allerdings sind die IBM-CPUs sicher nicht mit knappen TDPs im Hinterkopf entwickelt worden. Andersherum bei Intel, AMD, Nvidia: Manche Ideen dienen keiner Performancesteigerung mehr, sondern nur dem Energiesparen. Dazu gehört z.B. auch der µOp-Cache oder ein Loop-Buffer.

Diese von dir erwähnte alte Standardbehandlung des Stackframes nutzt leider nicht die Lokalität u. das leichtere Offset-Tracking sowie mögliche Vereinfachungen mit virtuellen Addressen.

 

[gruffi]

Deinem Verständnis nach richtest du deine Wahrnehmung der Ausführungseinheiten anhand der Decoder aus

Nein. Habe ich auch nie geschrieben. Ich kann's nur nochmal deutlich sagen, lies was dasteht und erfinde nicht irgendwas.

 

[Meckel]

Fett und teuer war auch mal der L1 Cache, die FPU, eine 2. ALU, usw. Allerdings sind die IBM-CPUs sicher nicht mit knappen TDPs im Hinterkopf entwickelt worden. Andersherum bei Intel, AMD, Nvidia: Manche Ideen dienen keiner Performancesteigerung mehr, sondern nur dem Energiesparen. Dazu gehört z.B. auch der µOp-Cache oder ein Loop-Buffer.

Diese von dir erwähnte alte Standardbehandlung des Stackframes nutzt leider nicht die Lokalität u. das leichtere Offset-Tracking sowie mögliche Vereinfachungen mit virtuellen Addressen.

Der Compiler zieht die Sachen wenn es sich lohnt in die Register und berechnet auch Adressen vor die dann in Registern liegen. Sparc hatte mal sowas, IMHO aber nicht mehr.

Ohne Trace/µOp Buffer/Cache wird Zen sicherlich nicht die von AMD angesagte Leistung erzielen.

 

[sompe]

Tatsächlich... Bin ich mit meinen AMD Aktien doch tatsächlich wieder im Plus.

Und ich ärgere mich um so mehr das ich meinen 2€ Kauf vor den Quatalszahlen wieder verkauft hatte.

@gruffi
Doch, exakt das schreibst du in Beitrag #1812.
Es geht um Ausführungseinheiten und du hängst dich am Sheduler/Decoder auf und ignorierst dabe das diese auch 2 integer Einheiten füttern könnten da es nunmal seine Zeit benötigt die Daten durch zu schicken. Ein Decoder könnte also 2 Ausführungseinheiten (EUs) mit genug Arbeit versorgen das sich diese nicht zu sehr langweilen und diese parallel abgearbeitet werden. Genau das ist der Unterschied zu Intels SMT Ansatz bei dem die Arbeit von 2 virtuellen Kernen seriell bearbeitet werden da es lediglich Lücken in der Pipeline füllt und genau daher kommt auch der hohe Skalierungsfaktor der CMT Module.

 

[Complicated]

Heutzutage IST die FPU aber nun mal Teil der CPU. Du kannst eine x86 CPU mit aktuellen Befehlssätzen gar nicht mehr ohne FPU designen. Zumal die FPU mittlerweile mehr beherrscht als nur reine FP Instruktionen.

Was nichts daran ändert, dass die FPU kein Teil des CPU-Kerns ist. 8 Integer-Cores sind vorhanden und sollten auch so gezählt werden. Alte Paradigmen hin oder her, Cache, FPU oder GPU werden nie Teil des CPU-Kerns sein, nur weil sie mit auf das CPU-Die wandern. Da kann man Prefetcher, Decoder oder sonst was zählen wie man will.

 

[miriquidi]

Könnt ihr nicht einfach solche sinnlosen Grundsatzdiskussionen sein lassen? Bringt doch nix.

 

[BavarianRealist]

Interessant finde ich die längliche Form des Dies. Einerseits schränkt das die maximale Größe des Dies ein (wie lang kann ein Die heute maximal sein?). Und zum zweiten stelle ich mir die Frage, ob das alles schon in etwa so arrangiert ist, sodass man zwei davon leicht zusammen rücken kann um dann ein 16-Core-Die zu erhalten, von dem man ja wieder zwei für die 32-Core-Server-CPUs bräuchte.

 

[Complicated]

Und vor allem kann man sie mittig auch noch leicht halbieren bei Teildefekten um 4 Core Salvage zu erhalten. Ich könnte mir vorstellen die würden gut auf einen Interposer passen mit 4-8 GB HBM und einer P11 GPU. Das wäre mal ein SoC für mobile der trotz Interposer günstig wäre.

Edit:
Passend dazu heute das 3Dcenter:

Zudem gibt es eine Schätzung zur Zen-Chipfläche von grob 160mm² – für einen Achtkerner wäre das spartanisch, Intel kommt bei einem Skylake-Vierkerner (mit GT2-Grafiklösung allerdings) in derselben 14nm-Fertigung auch schon auf ~122mm². Gemessen an dem, wie bisher bei Intel die Differenen zwischen Vierkerner mit iGPU und Achtkerner ohne iGPU lagen, sollte ein Intel-Achtkerner ohne iGPU in der 14nm-Fertigung bei ~230-250mm² herauskommen, wäre also sogar größer als AMDs in diesem Punkt (beiderseits keine iGPU) gleichen Ansatz. Damit kann AMD bei Zen letztlich günstigere Preise bieten, ohne deswegen zu sehr in die Gewinnmarge eingreifen zu müssen – zum Verkaufserfolg könnte somit auch endlich einmal wieder ein finanzieller Erfolg kommen.

 

[OBrian]

(wie lang kann ein Die heute maximal sein?)

das wurde doch im Laufe der Diskussion um Fiji und andere Interposergeschichten geklärt: Diegröße ist technisch begrenzt auf die maximale Belichtungsgröße, das sind irgendwas bei 3 cm Kantenlänge. Also ein ziemlicher Klopper. Wobei man glaube ich auch notfalls zweimal belichten könnte, also aneinandergesetzt, aber wohl nicht sinnvoll bei komplizierten 14-nm-Strukturen. Jedenfalls dürfte die maximal technisch erreichbare Diegröße nicht das Hindernis sein, was solche Dies verhindert. Ausbeute wird eben total unterirdisch.

 

[BavarianRealist]

Zudem gibt es eine Schätzung zur Zen-Chipfläche von grob 160mm²

Wow, das wäre echt ziemlich klein! Ein Quadcore wäre dann kaum 100mm². Das wäre ja schon fast zu gut, wenn ZEN auch noch gute Performance hätte. Leistungsfähig und auch noch billig in der Produktion? Klingt jedenfalls mal sehr gut.

 

[MIWA]

8 Kerne 160mm das ist extrem klein ich dachte das zen Parallelen zu cyclom hat der iPhone 6s) ist schon 100mm groß und das ist ein Dual Core

Edit wobei da ja noch ne Igpu drin ist aber 160mm ist immer noch extrem klein für 8kerne

 

[sompe]

Interessant finde ich die längliche Form des Dies. Einerseits schränkt das die maximale Größe des Dies ein (wie lang kann ein Die heute maximal sein?). Und zum zweiten stelle ich mir die Frage, ob das alles schon in etwa so arrangiert ist, sodass man zwei davon leicht zusammen rücken kann um dann ein 16-Core-Die zu erhalten, von dem man ja wieder zwei für die 32-Core-Server-CPUs bräuchte.

Im Hinblick auf die APUs und möglichen Multichip/Interposer Designs dürfte es durchaus sinnvoll sein. So bleibt genug Platz um einen weiteren Chip daneben zu setzen.
Mich würde nur interessieren ob man für ein Doppelchip Modell die beiden DIE aus einander sägt oder sie gleich zusammen läßt.

 

[bschicht86]

Mich würde nur interessieren ob man für ein Doppelchip Modell die beiden DIE aus einander sägt oder sie gleich zusammen läßt.

Beides würde gehen, wobei beim zusammenlassen das Positionieren des DIE auf einen MCM/Interposer nur einmal erfolgen muss.

 

[sompe]

Ja es wäre definitiv die sauberste Lösung denn so gibt es auch keine Höhenunterschiede für die Kühlung. Wenn ich mich recht erinnere hatte das seinerzeit auch Intel beim Pentium D gemacht.
Ein Nachteil wäre allerdings das man nur 2 nebeneinander liegende DIE nutzen kann und dies auch beim Zersägen des Wafers berücksichtigen muss.

 

[amdfanuwe]

Denke eher mal, dass man 2 einzelne, geprüfte Chips verwendet. 2 nebeneinanderliegende Chips auf einem Wafer können immer noch unterschiedliche Anforderungen an Spannung haben um bei gegebener TDP einen bestimmten Takt zu erreichen. Gibt immer wieder kleinste Abweichungen, die den einen Chip besser, schlechter oder eben ganz unbrauchbar machen.
Und nachträglich von den unbrauchbaren Pärchen den brauchbaren Chip noch abzusägen, halte ich für zu aufwändig.

 

[gruffi]

8 Integer-Cores sind vorhanden und sollten auch so gezählt werden.

Kannst du ja auch gerne machen. Habe ich nichts dagegen. Wobei ich sie eher Integer-Einheiten bzw Integer-Cluster nennen würde. Aber es sind definitiv keine 8 vollwertigen Kerne. Und zu denen gehört heutzutage auch die FPU, wenn sie vorhanden ist. Und bei Bulldozer ist sie nun mal vorhanden.


@topic

160 mm² für 8 Kerne wäre in der Tat nicht allzu gross. Ich komme da auf ~6 mm² für einen Zen Kern inklusive L2. Da 14nm FinFET allerdings deutlich teurer als 32/28nm Bulk ist, werden die Produktionskosten vermutlich kaum geringer als bei Orochi ausfallen. Bei guter Performance wird man aber sicherlich einiges mehr als die etwa $200 der aktuell grössten FX verlangen können.

 

[Atombossler]

160 mm² für 8 Kerne wäre in der Tat nicht allzu gross. Ich komme da auf ~6 mm² für einen Zen Kern inklusive L2. Da 14nm FinFET allerdings deutlich teurer als 32/28nm Bulk ist, werden die Produktionskosten vermutlich kaum geringer als bei Orochi ausfallen. Bei guter Performance wird man aber sicherlich einiges mehr als die etwa $200 der aktuell grössten FX verlangen können.

Zumal wenn er wirklich wie gerüchtet dem 5960X ans Bein pinkelt, kannste das glatt mehr als verdoppeln und es wär noch nicht zuviel.