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

[OBrian]

Ich meine, wenn es einen Königsweg gäbe einfach so eine hochperformante CPU zu designen, hätte auch AMD ähnliches längst gemacht.

Ich denke, so schwer ist das gar nicht, sehr hohe IPC (für einen Thread) zu erreichen, wenn das die einzige Zielvorgabe ist. Z.B. Itanium war ja ein IPC-Monster (zumindest in seiner nativen IA64-Umgebung). Aber der war auch ein gutes Beispiel, warum IPC eben nicht alles ist. Itanium war riesig, hatte viel Abwärme und nur sehr geringen Takt, damit völlig ungeeignet für einen Mainstreamchip (wofür die Architektur ja eigentlich mal längerfristig vorgesehen war). Der muß nämlich geringe Herstellungskosten haben. Und dafür braucht man geringe Diefläche, aus der man trotzdem genug Performance rausholen kann, ohne daß dabei die Abwärme durch die Decke geht. Da Performance = IPC mal Takt, geht es eben immer darum, einen guten Kompromiß zu finden. Und das ist die Kunst.

BD wäre ein guter Kompromiß gewesen, wenn die Software in seiner Produktlebenszeit massiv parallelisiert gewesen wäre. Diesbezüglich hat sich AMD einfach total verschätzt, es ging längst nicht so schnell, und auch in 5 Jahren wird die Softwarewelt noch nicht da sein, wo sie bei BD-Start hätte sein müssen, damit er ein Erfolg geworden wäre. Aber daß BD so eine geringe IPC pro Thread hat, ist keine Unfähigkeit der Designer, sondern volle Absicht gewesen, eben eine Abwägung zuungunsten dieser Thread-IPC und zugunsten anderer Dinge (z.B. gesparter Diefläche durch CMT und hohen Takt statt zusätzlicher Einheiten). Zuviel Optimismus, daß sich die Welt schon so entwickeln wird, daß es paßt.

Sowas hatte AMD ja schon mal gemacht und Erfolg damit gehabt. Der originale Ur-Athlon K7 hatte eine deutlich schlechtere IPC als der K6-3, zumindest bei Integer (http://www.planet3dnow.de/vbulletin/showthread.php?t=352912), aber eben auch wesentlich mehr Takt (und eine FPU mit mehr IPC), so daß sich das mehr als ausgeglichen hat. Und er hatte auch eine wesentlich schlechtere Energieeffizienz als der K6-3 oder die damals aktuellen P3. Hat nur noch keinen interessiert, aber damit ging's doch los mit den Kühlproblemen im PC. Bei BD hat es leider nicht funktioniert, weil die für den ausreichend hohen Takt nötige Abwärmeklasse (220W) sich nicht mehr verkaufen läßt und die zusätzlich möglichen Kerne keinen dies ausgleichenden Zusatznutzen haben.

Bei Zen wird von relativ großer Diefläche für einen Kern geredet, da wird also wieder die Gewichtung in die andere Richtung verschoben. Diefläche des Kerns scheint in Zukunft weniger wichtig zu sein. Aber auch das, was wir bisher von Zen gehört haben, sieht für mich weiterhin nach Kompromiß aus und nicht nach einem rein und ausschließlich auf maximale IPC ausgelegten Kern. Was ja auch so richtig ist, denn er muß ja nicht mit 500 MHz auskommen, ein paar GHz sind sicherlich machbar, und zu riesig darf er nicht werden, da er ja auch in kleinen billigen Mainstreamchips finanziell funktionieren muß.

Kurz gesagt, die +40% sind nicht das, was AMD maximal schafft, sondern das, was sie sich als Randbedingung gesetzt haben, um das Gesamtziel zu erreichen. Was schlicht darin besteht, die Firmenangestellten und ihre Familien über mehrere Jahre ausreichend zu ernähren.

 

[sompe]

Ach komm....das der Athlon so erfolgreich gewesen ist lag vor allem daran das der mit Abstand größte Kritikpunkt der K6 Architektur angegangen wurde, die schwache FPU Leistung. Zudem kann man ihn kaum als Nachfolger des K6-2/3 bezeichnen da beide die meiste Zeit parallel liefen und der Athlon deutlich mehr Strom fraß. Angesichts damaliger OC Ergebnisse kann man wohl eher sagen das die K6 Architektur einfach keine höheren Taktfrequenzen packte.
Von der Integer Leistung her sah der Bulli auch nicht allso schlecht aus.

Ich würde eher sagen das der Bulli zu großen Teilen an den gleichen Problemen wie die K6 Serie leidet.
Er hat zwar genug Integer Leistung, ist aber von der FPU her etwas schwach auf der Brust und leistungsfähigere Befehlssätze bleiben softwareseitig praktisch nungenutzt. Man erinnere sich an der Stelle mal an den Performanceboost durch das 3Dnow! Patch für Quake 2. Die Multicore Geschichte kam dann beim Bulli da noch hinzu.

 

[Bobo_Oberon]

... Diesbezüglich hat sich AMD einfach total verschätzt, es ging längst nicht so schnell, und auch in 5 Jahren wird die Softwarewelt noch nicht da sein, wo sie bei BD-Start hätte sein müssen, damit er ein Erfolg geworden wäre. Aber daß BD so eine geringe IPC pro Thread hat, ist keine Unfähigkeit der Designer, sondern volle Absicht gewesen, eben eine Abwägung zuungunsten dieser Thread-IPC und zugunsten anderer Dinge ...

So weit stimme ich zu ...

... Sowas hatte AMD ja schon mal gemacht und Erfolg damit gehabt. Der originale Ur-Athlon K7 hatte eine deutlich schlechtere IPC als der K6-3, zumindest bei Integer (http://www.planet3dnow.de/vbulletin/showthread.php?t=352912), aber eben auch wesentlich mehr Takt (und eine FPU mit mehr IPC), so daß sich das mehr als ausgeglichen hat. Und er hatte auch eine wesentlich schlechtere Energieeffizienz als der K6-3 oder die damals aktuellen P3. Hat nur noch keinen interessiert, aber damit ging's doch los mit den Kühlproblemen im PC. ...

Na ja, schlechtere Energieeffizienz ... bei doppelt, dreifacher FPU-Leistung, war der Strombedarf des K7 womöglich in der Relation doch nicht so schlecht.

Die Integerbenchmarks von Nero empfinde ich im Nachhinein zwar als interessant - aber bezogen auf die praktische Relevanz zog der Athlon auch hier dem K6-3 die Wurst vom Teller - nur dass der Integer-Abstand nicht mehr so extrem war, wie bei FPU-Anwendungen. Ich kann das sagen, weil ich den K6 233, K6-2 300, K6-2 400 (+ Übertaktung), K6-III 400 und dann den K7 700 (die seltenen mit integriertem L2-Cache im Slot A), K7 800 Slot A, K7 800 Sockel nutzte.

Mir flogen damals die Socken weg mit dem K6-III, als ich damit erstmals PDFs öffnete und meine Office-Dokumente damit bearbeitete - mit dem K7 (heruntergetaktet bei Standardanwendungen!) war die Leistung ansprechend ... jedenfalls immer noch Welten besser, als mit den K6-2-CPUs.

Bei BD hat es leider nicht funktioniert, weil die für den ausreichend hohen Takt nötige Abwärmeklasse (220W) sich nicht mehr verkaufen läßt und die zusätzlich möglichen Kerne keinen dies ausgleichenden Zusatznutzen haben

Schon der Bulldozer mit 125 W TDP war unzeitgemäß, in Anbetracht der Intelprozessoren, die eher schon in die 65 Watt Klasse rutschten ...

Was AMD geradezu aber halsbrecherisch veranlasste ein ausgesprochenes Hochtakt-Design zu entwerfen - gegen den anerkannten Halbleiter-Fertigungsweltmeister Intel, das lässt mich immer noch den Kopf schütteln - als hätte es nie Intels blutige Nase mit dem Pentium IV gegeben ... und die waren damals schon in der Regel führend im Halbleiterbereich ... auch wenn AMD immer wieder mal interessante Fertigungsneuerungen einführten (Cu-Layer, SOI).

Kurz gesagt, die +40% sind nicht das, was AMD maximal schafft, sondern das, was sie sich als Randbedingung gesetzt haben, um das Gesamtziel zu erreichen. Was schlicht darin besteht, die Firmenangestellten und ihre Familien über mehrere Jahre ausreichend zu ernähren.

Das wiederum sehe ich derzeit auch so!

MFG Bobo(2015)

 

[sompe]

Welche blutige Nase beim P4?
Sie blieben trotz des schlechteren und teureren Produkts unangefochtener Marktführer.
Sie verloren ein paar Prozentpunkte bei den Marktanteile aber das war es auch schon.
Sie haben sich schon viele grobe Schnitzer geleistet (RDRAM Ausrichtung, MTH Debakel, diverse Chipsatz und CPU Bugs) ohne das es ernsthafte Konsequenzen für die Marktstellung hatte.

 

[Atombossler]

AMD Zen CPU Core Testing “Met All Expectation” – No “Significant Bottlenecks” Found.

According to some of the whispers we’ve heard as of late, AMD design engineers have maintained a goal for Zen to be competitive with Intel’s future offerings from the very beginning.

Na dann AMD, mein Interesse ist euch sicher, war es aber auch bei BD1.
Gekauft hab ich Ihn dann aber logischerweise nicht, erst den Vishera.
Der ist für mein Anwendungsszenario perfekt, wenn ZEN Ihn signifikant toppt -> gekauft.

 

[Cappuandy]

AMD Zen CPU Core Testing “Met All Expectation” – No “Significant Bottlenecks” Found.

Na dann AMD, mein Interesse ist euch sicher, war es aber auch bei BD1.
Gekauft hab ich Ihn dann aber logischerweise nicht, erst den Vishera.
Der ist für mein Anwendungsszenario perfekt, wenn ZEN Ihn signifikant toppt -> gekauft.

Me2.. *Vorfreude steigt weiterhin*
Vorallem wenn die TDP unter 100W bleibt u. nicht wie beim Phenom 140+..

Gruß at all..

 

[Bobo_Oberon]

Welche blutige Nase beim P4? ...

Anstatt, dass AMD auf dem Sockel 7 versauerte und aus dem Markt ausschied, wurden diese sogar stärker, als jemals zuvor. Zwar war der Athlon MP kein großer Erfolg, aber es war der Fuß in der Tür im professionellen Servermarkt.

Und in Anbetracht der Spottpreise vom K6-2 und K6-III, konnte der kleine x86-Riese mal wirklich beim Prozessorpreis zuschlagen, während Intel nicht mehr unangefochten von ganz oben beim Xeon bis zur Celeron-Klasse die Preise diktieren konnte.

Zugegeben, der P4 blieb Marktführer - aber zog Spuren in der Erfolgsbilanz im Produktkorb der Pentium-Erfinder - und wie anfangs schon geschrieben - anstatt zu verschwinden, konnte AMD mit dem K7 den Weg vorbereiten für den K8, der zeitweilig 20 - 30 Prozent des x86-Marktes mit guten Margen (Stichwort Opteron) ergattern konnte.

MFG Bobo(2015)

 

[TNT]

...
Schon der Bulldozer mit 125 W TDP war unzeitgemäß, in Anbetracht der Intelprozessoren, die eher schon in die 65 Watt Klasse rutschten ...

Was AMD geradezu aber halsbrecherisch veranlasste ein ausgesprochenes Hochtakt-Design zu entwerfen - gegen den anerkannten Halbleiter-Fertigungsweltmeister Intel, das lässt mich immer noch den Kopf schütteln - als hätte es nie Intels blutige Nase mit dem Pentium IV gegeben ...

MFG Bobo(2015)

Dem kann ich nur voll zustimmen. Mit BD ging man einfach zu viel Risiko ein - es musste- in der Rueckschau - einfach scheitern.

 

[genervt]

AMD Zen CPU Core Testing “Met All Expectation” – No “Significant Bottlenecks” Found.

Na dann AMD, mein Interesse ist euch sicher, war es aber auch bei BD1.
Gekauft hab ich Ihn dann aber logischerweise nicht, erst den Vishera.
Der ist für mein Anwendungsszenario perfekt, wenn ZEN Ihn signifikant toppt -> gekauft.

Dann werde ich mal damit beginnen mtl. Geld beiseite zu legen für das nächste Prozessor-Upgrade.
Würde mich aber wirklich freuen, wenn es bei AMD auch mal rund läuft und eine neue Architektur nicht mit mehreren Quartalen Verspätung aufschlägt. *figners crossed

 

[Opteron]

Dem kann ich nur voll zustimmen. Mit BD ging man einfach zu viel Risiko ein - es musste- in der Rueckschau - einfach scheitern.

Es war halt einfach zu chaotisch bei AMD, neue Chefs und Strategien allenthalben.
Das einzig gute an BD war die FMA-FPU, die war auf HPC ausgelegt. Aber was macht der neue Chef? Streicht die neuen Serverplattformen zusammen und kauft dafür ein Dense-Serverstartup, weil man sein Geld mit kleinen Billigchips verdienen wollte.

Carrizo zeigt ja, was man aus BD noch so alles rausquetschen hätte können. Mit 14nm wär auch mehr drin gewesen, aber ich bin auch froh, dass ein neues Design kommt, das alte hatte dann doch zuviel Pferdefüße.

 

[sompe]

Anstatt, dass AMD auf dem Sockel 7 versauerte und aus dem Markt ausschied, wurden diese sogar stärker, als jemals zuvor. Zwar war der Athlon MP kein großer Erfolg, aber es war der Fuß in der Tür im professionellen Servermarkt.

Und in Anbetracht der Spottpreise vom K6-2 und K6-III, konnte der kleine x86-Riese mal wirklich beim Prozessorpreis zuschlagen, während Intel nicht mehr unangefochten von ganz oben beim Xeon bis zur Celeron-Klasse die Preise diktieren konnte.

Zugegeben, der P4 blieb Marktführer - aber zog Spuren in der Erfolgsbilanz im Produktkorb der Pentium-Erfinder - und wie anfangs schon geschrieben - anstatt zu verschwinden, konnte AMD mit dem K7 den Weg vorbereiten für den K8, der zeitweilig 20 - 30 Prozent des x86-Marktes mit guten Margen (Stichwort Opteron) ergattern konnte.

MFG Bobo(2015)

Auch hier habe ich zum Teil etwas andere Erinnerungen.
Der K6-2 war vergleichsweise billig, der K6 III hingegen weniger.
Dazu noch die etwas "eigenartige" Situation beim Marktstart des Athlon wo es zwar die Prozessoren aber keine Mainboards gab und die Mainboards die anfangs angeboten wurden existierten meist nicht auf den Websites der Hersteller. Die 20-30% Marktanteile hatten sie aber auch nur für eine sehr begrenzte Zeit und die fielen nach Erscheinen des Core 2 und fielen spätestens mit dem Scheitern des ersten Phenom dank des aufgebauschten TLB Bugs drastisch. In dem gesammten Zeitraum hatte sich allerdings recht deutlich gezeigt wie sie schon damals die OEMs in der Hand hatten denn selbst zu ihrer Glanzzeit konnte man AMD Systeme bei den absatzstarken Händlern und OEMs mit der Lupe suchen und genau da kamen die Marktanteile her. Dabei geht es schließlich nicht um den Verkaufspreis sondern nur um die Stückzahlen und die werden vor allem bei den OEMs gemacht.

 

[TNT]

Es war halt einfach zu chaotisch bei AMD, neue Chefs und Strategien allenthalben.
Das einzig gute an BD war die FMA-FPU, die war auf HPC ausgelegt. Aber was macht der neue Chef? Streicht die neuen Serverplattformen zusammen und kauft dafür ein Dense-Serverstartup, weil man sein Geld mit kleinen Billigchips verdienen wollte.
...

Da meinst Du R.Rory !? - the 'volume guy' !? Oder war das noch vor ihm?
Auch R.Rory hat sicherlich alles richtig gemacht - vielleicht so gar mehr falsch als richtig - aber das muss sich noch zeigen.

--- Update ---

Dann werde ich mal damit beginnen mtl. Geld beiseite zu legen für das nächste Prozessor-Upgrade.
Würde mich aber wirklich freuen, wenn es bei AMD auch mal rund läuft und eine neue Architektur nicht mit mehreren Quartalen Verspätung aufschlägt. *figners crossed

Ja, es waere schon toll - ein nicht verbuggtest Design und gleich werden alle Erwartungen erfuellt - prima.
Aber irgendwie klingt es doch unwahrscheinlich, dass man nun schon so weit ist.. oder hat das erste Stepping gleich eingeschlagen?

 

[Complicated]

Warum klingt das unwahrscheinlich?
Plausible Gründe dafür?

 

[Dresdenboy]

Ja, es waere schon toll - ein nicht verbuggtest Design und gleich werden alle Erwartungen erfuellt - prima.
Aber irgendwie klingt es doch unwahrscheinlich, dass man nun schon so weit ist.. oder hat das erste Stepping gleich eingeschlagen?

Falls Fotti mit seinen Quellen richtig lag, soll der Zen-Tapeout schon im Juni stattgefunden haben.
https://semiaccurate.com/forums/showpost.php?p=241136&postcount=99

 

[Atombossler]

Klingt plausibel und da damit scheinbar alles ok war hat Keller die Klinke in die Hand genommen.
Passt.

Jetzt kanns dann "NUR" noch die Fertigung versauen...

 

[OBrian]

ja, da müßte aber schon herb was daneben gehen. Denn Zen kommt ja zuerst als CPU für den oberen Preisbereich (und nicht als 50-$-APU), da ist schlechte Ausbeute anfangs gar nicht so schlimm, weil da einerseits die Margen hoch sind und andererseits auch nicht so irre viel abgesetzt wird. Der Imageschaden durch Verzögerung wäre schlimmer.

Dann werde ich mal damit beginnen mtl. Geld beiseite zu legen für das nächste Prozessor-Upgrade.

das mache ich schon seit vielen Jahren Von mir aus kann Zen richtig teuer werden, solange er das Geld auch wert ist.

 

[Nakai]

Kurze Frage, was ihr denkt?
Wird ZEN eher 128Bit oder 256Bit R/W-Ports besitzen. Selbst BD hatte bereits 2x128Bit(R) und 1x 128Bit(W) und das bei deutlich weniger Ausführungsressourcen. Ich tendiere dahingehend schon stark zu 2x256Bit(R) und 1x128Bit(W). Kombiniert mit den 4 ALU-Ports und 4 FPU-Ports, ist eine höhere Bandbreite schon nicht unwichtig. Vor allem mit Packed SSE Read und Write, wäre eine höhere Bandbreite sehr sinnvoll. Ein hoher SSE-Durchsatz wär ziemlich beeindruckend.

 

[Atombossler]

ja, da müßte aber schon herb was daneben gehen. Denn Zen kommt ja zuerst als CPU für den oberen Preisbereich (und nicht als 50-$-APU), da ist schlechte Ausbeute anfangs gar nicht so schlimm, weil da einerseits die Margen hoch sind und andererseits auch nicht so irre viel abgesetzt wird. Der Imageschaden durch Verzögerung wäre schlimmer.

Nun ja, man ist da ja vorsichtig geworden ...
Scheint nichts zu geben, was GF nicht versaut bekommt.

Ich hab schon direkt nach dem 8350 Speck angesetzt, aber es kam ja nichts. Von mir aus kann der OctaZen auch € 500,- EUR oder mehr kosten.
Wenn er was reisst, ist er gekauft, fast egal für wie viel.

 

[Dresdenboy]

Kurze Frage, was ihr denkt?
Wird ZEN eher 128Bit oder 256Bit R/W-Ports besitzen. Selbst BD hatte bereits 2x128Bit(R) und 1x 128Bit(W) und das bei deutlich weniger Ausführungsressourcen. Ich tendiere dahingehend schon stark zu 2x256Bit(R) und 1x128Bit(W). Kombiniert mit den 4 ALU-Ports und 4 FPU-Ports, ist eine höhere Bandbreite schon nicht unwichtig. Vor allem mit Packed SSE Read und Write, wäre eine höhere Bandbreite sehr sinnvoll. Ein hoher SSE-Durchsatz wär ziemlich beeindruckend.

Es sieht eher nach 2R/1W in 128 Bit aus. Die 4 ALUs (64b max) haben nichts von 256 Bit. Die FPUs scheinen 256 Bit weiterhin als 2x128 Bit zu verarbeiten und hätten da nur für YMM-Register einen Vorteil, bei gleichzeitiger Beschränkung auf z.B. 1x256b FMAC pro Takt (also nur 1x256b R benötigt).
Immerhin gibt es seit AMD64 je 16 Register, wodurch einige Speicherzugriffe gespart werden können.

Und die 2 AGUs limitieren den Spaß ja auch etwas.

 

[miriquidi]

Ein Loop Buffer ist ist ein Art Queue in der man mit zusätzlichen Bits eine Schleife markiert und dann anstatt Einträge zu verwerfen diese mehrmals hintereinander ausgibt. In einem Cache werden aktiv die dekodierten Befehle gespeichert, falls man diese später noch mal brauchen sollte. Diese müssen dann aber auch mit einem Lesezugriff der keinem µOp oder makroOp entspricht wieder geladen werden. Also man lädt z.b. immer 32Byte was dann maximal bis zu 4 dekodierten Instruktionen entsprechen kann. In der Queue werden stattdessen die makro(µ)Ops direkt gespeichert.

Ich habe das immer noch nicht verstanden und muss nochmal nachfragen: Sitzt der Loop Buffer im x86-Befehls-Dekoder, setzt dort die Schleifenmarkierungsbits und gibt (bei Schleifenerkennung) einfach die bereits berechneten µOps, die irgendwo gespeichert werden, an die dahinter liegenden Ausführungseinheiten aus?
Der µOp-Cache seit Intels Sandy Brigde würde dem nach die Schleife in den Ausführungseinheiten anhand der bereits dekodierten µOPs erkennen und braucht die Dekoder-Einheiten bis zum Schleifenende gar nicht mehr.
Stimmt das so?

 

[Opteron]

Es sieht eher nach 2R/1W in 128 Bit aus. Die 4 ALUs (64b max) haben nichts von 256 Bit. Die FPUs scheinen 256 Bit weiterhin als 2x128 Bit zu verarbeiten und hätten da nur für YMM-Register einen Vorteil,

Jupp, oder anders gesagt: Zwei 128bit Pipelines können nicht durch einen 256bit R/W-Port versorgt werden. Stattdessen bräuchte man 4x128bit Ports. Das gabs aber wiederum bisher noch nie, vermutlich gibts da mit jedem weiteren Port mehr Latenz, die bei nem L1 aber ja nicht soo unwichtig sind.
Alternativ könnte man CMT wieder aus der Versenkung holen, zwei L1-Caches haben auch 4 Ports .. aber wenn dafür die L1-Größe halbiert wird .. naja ..

 

[tex_]

Ich habe das immer noch nicht verstanden und muss nochmal nachfragen: Sitzt der Loop Buffer im x86-Befehls-Dekoder, setzt dort die Schleifenmarkierungsbits und gibt (bei Schleifenerkennung) einfach die bereits berechneten µOps, die irgendwo gespeichert werden, an die dahinter liegenden Ausführungseinheiten aus?
Der µOp-Cache seit Intels Sandy Brigde würde dem nach die Schleife in den Ausführungseinheiten anhand der bereits dekodierten µOPs erkennen und braucht die Dekoder-Einheiten bis zum Schleifenende gar nicht mehr.
Stimmt das so?

Der Loop Buffer ist ein Speicher nach dem Dekoder (abgesehen von Jaguar da ist er in der tat vor dem Dekoder). Woher nun die Information kommt ob eine Schleife gefunden wurde ist natürlich von der Implementierung abhängig, vermutlich wird aber ein Sprung auf eine bekannte bereits dekodierte Adresse im Dekoder erkannt und entsprechend das Frontend samt Dekoder abgeschaltet.
Bei Haswell und Steamroller ist der Loop Buffer soweit mir bekannt, teil der Instruction Queue nach dem Decoder, dass muss aber auch nicht so sein. Bei Sandy und Ivy war das ein eigenständiger Buffer, dort kann der LoopBuffer seine Daten entweder von den Decodern oder dem µOp Cache bekommen.

 

[Nakai]

Es sieht eher nach 2R/1W in 128 Bit aus. Die 4 ALUs (64b max) haben nichts von 256 Bit. Die FPUs scheinen 256 Bit weiterhin als 2x128 Bit zu verarbeiten und hätten da nur für YMM-Register einen Vorteil, bei gleichzeitiger Beschränkung auf z.B. 1x256b FMAC pro Takt (also nur 1x256b R benötigt).
Immerhin gibt es seit AMD64 je 16 Register, wodurch einige Speicherzugriffe gespart werden können.

Und die 2 AGUs limitieren den Spaß ja auch etwas.

Ja, du hast recht. Wenn AMD bei ZEN auch keine übergroßen FPUs einbaut, wie bei Intel, dann ist eine höhere Bandbreite zu L1-Cache nicht so wichtig. Intel hat ja von Ivy Bridge auf Haswell nicht nur den AVX-Durchsatz, sondern auch die L1-Bandbreite verdoppelt. Die 2x128Bit Ports Read harmonieren mit der ALU-Anzahl. Wenn die ALUs LEAs können, von dem man ausgehen sollte, dann wird noch etwas Druck von den AGUs genommen. Dass es trotzdem nur Zwei sind für LD/STs ist etwas schade.

Nur so nebenbei, mich würde es nicht wirklich wundern, wenn ein ZEN-Core mit L2-Cache unter 10mm² groß ist. Ergo ein Octa-Core mit L3-Cache (8~16MB?) sollte um die 150mm² liegen. Man sollte den ganzen IO-Kram nicht unterschätzen. AM4 wird wohl einen Dual Channel DDR4 unterstützen. Eventuell wird man noch einen anderen IO-Port für HSA-Module mit einer GPU unterstützen.

Ahja, wenn ZEN um Juni~Juli rum seinen TapeOut hatte, wird man ein Jahr später evtl den Release anstreben. AMDs finanzielle Lage wird natürlich Verzögerungen mit sich bringen.

 

[MR2]

Immerhin haben sie jetzt 370 Millionen Dollar mehr in der Kasse durch den Verkauf ihrer Fertigungsstätten in China und Malaysia und irgendwann soll ja die neue Nintendo-konsole anlaufen.
Hoffentlich geht alles gut und pünktlich zum Herbst nächsten Jahres ersetzt ein 8Kerner Zen den in die Jahre gekommenen X6 1100T, der für meine Fury wohl etwas zu schwach ist
BD hab ich somit zumindest im Desktop komplett übersprungen.

Ich freu mich auf Kellers Baby! Endlich wirds wieder spannend im CPU Bereich.
Wenn dann der Name noch passt....

 

[bschicht86]

Ich hoffe nur, dass sich die Fachpresse nicht über das zerreißt, was Zen gegenüber Intel nicht hat (überbreites AVX etc.), sondern was Zen gut macht. Ich sehs jetzt schon, dass viele dass dann als "Kontra Zen" anführen werden.