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

[gruffi]

bei File größen bis 8M ist das Verhalten der Maschine mit L4 identisch zu denen ohne L4
ab Filegrößen von 8M bis 256M wirkt sich der L4 in einer Verdoppelung der Performance aus

Nein. Cache-Latenz und tatsächliche Performance sind zwei völlig verschiedene Paar Schuhe. Normalerweise bringen niedrigere Cache-Latenzen innerhalb der gleichen Architektur im Schnitt nur ein paar Prozent mehr Performance. Und je grösser der Cache wird, umso seltener werden die Fälle, wo die Cache-Stufe auch wirklich ausschlaggebend ist.

aber wie geht AMD denn die Bandbreitenfrage bei APUs an?

Vermutlich mit HBM. Und dann gibt's für Grafikanwendungen auch brauchbare Grössen von mehreren GB. Mit 128 MB kommst du da nicht weit.

Und AMD scheint ja immer noch auf der Suche zu sein nach einer sinnvollen Anwendung für die iGPU Leistung seiner Desktop-APUs

Die gibt's schon. Da muss keiner mehr suchen.

 

[clearlake]

Ich weiss ja nicht was du aus deinen Quellen liest. Doch bei Anandtech steht: Iris Pro 5200 hat 832 GFlops und die HD 5000 ohne EDRAM 704 GFlops. Wo verdoppelt sich da irgendetwas? ...

die Vorgängergeneration ist gemeint, also hd4000 Derivate

...Vermutlich mit HBM. Und dann gibt's für Grafikanwendungen auch brauchbare Grössen von mehreren GB. Mit 128 MB kommst du da nicht weit.
Die gibt's schon. Da muss keiner mehr suchen.

HBM, das sehe ich auch so

intel hat für seine schnelleren gpu-lösungen aber in 2014 seriöse anwendungsvorschläge vorgelegt: http://www.anandtech.com/show/7851/intel-xeon-to-get-crystal-well-e31284l-v3
und die reine compute-leistung der intel-lösung ist auch ansehnlich: http://www.3dcenter.org/artikel/intel-iris-pro-5200-review/intel-iris-pro-5200-review-seite-7
siehe auch die "theoretischen" Tests

aber mit HBM lassen sich vermutlich nicht die Nachteile einer schwächeren CPU marginalisieren, drum wird, trotz HSA, Zen auch eine weitaus stärkere CPU werden, vermute ich

 

[Complicated]

Das hast du hier aber nirgends erwähnt - es geht um die Verdoppelung der Performance bei Verwendung des EDRAMS.

was man erreicht hat mit dem L4 zeigt ja die Grafik (http://images.anandtech.com/doci/6993/latency.png)
bei File größen bis 8M ist das Verhalten der Maschine mit L4 identisch zu denen ohne L4
ab Filegrößen von 8M bis 256M wirkt sich der L4 in einer Verdoppelung der Performance aus
ab 256M ergeben sich leichte Nachteile

Meine Frage war: Welche Performance verdoppelt sich da?

Also aus allen von dir verlinkten Quellen kann ich das lesen was ich auch vorher wusste. Dass es keine Verdoppelung zur Vorgänger GPU gibt. HD4000 Derivate haben eine so grosse Streuung, so dass man doch den schnellsten HD4xxx vergleichen sollte um eine solche Aussage zu verifizieren.

 

[gruffi]

intel hat für seine schnelleren gpu-lösungen aber in 2014 seriöse anwendungsvorschläge vorgelegt

Die haben was wofür vorgelegt?

und die reine compute-leistung der intel-lösung ist auch ansehnlich

Das ist ja schön. Aber Nvidia ist nicht die Referenz beim Computing. Und erst recht nicht mit einer GT 640M.

aber mit HBM lassen sich vermutlich nicht die Nachteile einer schwächeren CPU marginalisieren

Für die Leistungsfähigkeit der iGPU ist das irrelevant. Und nur dort gibt es im Moment eine sichtbare Bandbreitenlimitierung der APUs.

 

[clearlake]

das nächste AMD-Design wird eine weitaus stärkere CPU hervorbringen und AMD jedenfalls wird wissen warum (bzw. wozu), nicht wahr?

 

[derDruide]

Hallo clearlake,

da du jetzt doch mal wieder aufgetaucht bist, könntest du noch meine Fragen zu deinem Marketing-Thread beantworten, zu finden hier: http://www.planet3dnow.de/vbulletin/showthread.php/420878-Core-m?p=4967628&viewfull=1#post4967628

Das ist unter dem Stichtwort "verdecktes Marketing" sicher auch für andere Leser interessant.

 

[Complicated]

Ja der Thread war mir auch noch im Hinterkopf.

 

[Casi030]

das nächste AMD-Design wird eine weitaus stärkere CPU hervorbringen und AMD jedenfalls wird wissen warum (bzw. wozu), nicht wahr?

Nicht nur AMD,wenn AMD CPUs in Zukunft wie Intel arbeiten,dann kann Intel diese nicht wie jetzt ausbremsen ohne sich selber aus zu bremsen und somit werden die AMD deutlich an Leistung zulegen.

 

[unl34shed]

Wo soll da was wie bei Intel arbeiten?
Meinst du nur weil irgendwer behauptet, dass es ein SMT Design wird und kein CMT oder CMP, wird es ähnlich einem Intel Skylake? Was ich übrigens nicht erwarte, dafür skaliert CMT zu gut.

Aber selbst wenn dem so wäre, ist eine CPU ein zu komplexes Konstrukt, mit zig verschiedenen Stellschrauben, die gedreht werden können um Produkt A besser dastehen zu lassen als B. Und zur Not gibt es immer noch die Vendor ID, mit der man "ausschließen" kann, dass es sich um eine Intel CPU handelt.

 

[gruffi]

Gerüchte von Fudzilla zu einer Zen APU. 16 Kerne, 4 Module mit je 4 Kernen, L2 pro Kern, shared L3 pro Modul, Quad-Channel DDR4, PCIe 3, HBM. Was immer man von solchen Gerüchten halten mag. Hört sich auf jeden Fall eher nach einer Server APU an. Im Desktop braucht man sicherlich nicht so viele Kerne und auch keine Quad-Channel Speicheranbindung. Dank einer solchen Modulbauweise könnte man aber sicherlich auch problemlos 4 oder 8 Kerne im Desktop anbieten. Siehe die Jaguar CU, die schon ähnlich konzipiert war. Nur dass bei Zen scheinbar ein dedizierter L2 hinzugekommen ist und aus dem shared Cache L3 wurde. Sicherlich sinnvoll, um die Cache Performance zu erhöhen. Bei Jaguar lief der L2 ja nur mit Halbtakt. Fragt sich nur, ob AMD das CMT Konzept weiterentwickelt und auf 4 Threads erweitert hat. Oder ob die Module wie bei Jaguars CU aus vollwertigen Kernen bestehen.

 

[y33H@]

APU für HPC, siehe Roadmaps.

 

[BoMbY]

Derzeit braucht man so viele Kerne nicht auf einem Desktop. Wenn die Next-Gen-APIs aktiv genutzt werden, dürfte sich das ändern - wenigstens 8 Kerne sollte man dann für Gaming schon haben. Aber auch für Video-Bearbeitung/Darstellung könnte sich das lohnen.

 

[Opteron]

.. L2 pro Kern, shared L3 pro Modul,

Um genauer zu sein L3 pro 4-Kern-Gruppe, d.h. auf die Caches der anderen 4 Module hat man keinen Zugriff?
Ich hoffe mal das stimmt nicht, dann müsste man wieder wie in K8-Zeiten Daten übers RAM austauschen

Außerdem:
L2 pro Kern klingt nach nem kleinen L2 nach Intelrezept.

Wenn man wirklich ne Katzen-XBar als Ausgangsbasis genommen hat, kann man damit den L3 wohl auf halber Kraft lassen.
Stellt sich dann die Frage, wie ähnlich Zen den Katzenkernen wird. Die Frage ist aber offen, nur weil man die XBar wiederverwertet muss das nichts heißen. Ist halt ne Sparmaßnahme, die Xbar gibts schon, also wirds genommen. Verbreitert wird sie aber hoffentlich noch...

Nachdem Keller bisher 1MB L2 bevorzugte, geh ich mal von 4 MB L3 aus. Für den L2 blieben dann wie bei Intel um die 256 kB übrig, vielleicht auch nur 128, 512 könnte man in dem Fall sicherlich ausschließen.

Ein 4er CMT schließe ich eher aus, der neue Kern sollte ja ne gute IPC bekommen, dafür braucht man breite ALUs und viel L1-Cache. Das ist aber nicht wirklich drin, wenn man 4 Cluster anstatt eines fetten Kerns haben will.

Außer man triebe es auf die Spitze und würde auch noch die L1-Caches sharen, was dann aber der Zugriffzeit zuwider liefe - erst recht bei 4 CUs.

Immerhin kann man aber schon eins sagen: Nach der Nomenklatur gäbs kein SMT, es wird ja immer von Cores gesprochen.

Naja warten wir mal weiter ...

APU für HPC, siehe Roadmaps.

Jupp, genauer gesagt die geleakten japanischen.

 

[isigrim]

Wenn da HBM drauf ist, dann müsste man für den Austausch zwischen den 4-Kern-Gruppen eher über den L4 gehen. Also zumindest wäre der signifikant schneller als der normale SystemRam.

 

[gruffi]

Um genauer zu sein L3 pro 4-Kern-Gruppe, d.h. auf die Caches der anderen 4 Module hat man keinen Zugriff?
Ich hoffe mal das stimmt nicht, dann müsste man wieder wie in K8-Zeiten Daten übers RAM austauschen

Ich sehe darin absolut kein Problem. Lieber für den Grossteil der Workloads einen schnellen L3 als für ein paar wenige Workloads den Umweg RAM nicht gehen zu müssen. So eine Modulbauweise hat eben den Vorteil, dass es das Design sehr flexibel macht. Für AMDs Semi-Custom Pläne sicherlich nicht die schlechteste Basis. Und je mehr Parallelität ins Spiel kommt, umso mehr rückt die Speicherlatenz sowieso in den Hintergrund. Mit steigender Anzahl an Kernen wird es auch immer schwieriger und komplexer, einen shared Cache für alle Kerne zu implementieren. Intel zB muss Abstriche beim L3 ihrer Core Prozessoren machen. Nur das L3 Segment, welches direkt am Kern hängt, kann mit der niedrigsten Latenz angesprochen werden. Für andere Kerne ist die Latenz höher. Dann lieber einen kompakten und einheitlichen L3 für wenige Kerne und HBM als LLC für alle Kerne nutzen. Ist mMn deutlich sinnvoller aufgrund der weitaus höheren Kapazität von HBM.

L2 pro Kern klingt nach nem kleinen L2 nach Intelrezept.

Wieso? Apple hat beim A8 neben einem 4 MB L3 einen 1 MB L2 für einen Kern. 1 MB L2 pro Kern hatten auch schon die alten K8. Und bei Carrizo (Excavator) ist dies ja auch der Fall, zumindest pro Modul. 256 KB ist mMn einfach zu winzig für einen L2. 1 MB sollte im Moment ein guter Kompromiss aus Grösse und Latenz sein.

Ein 4er CMT schließe ich eher aus, der neue Kern sollte ja ne gute IPC bekommen, dafür braucht man breite ALUs und viel L1-Cache. Das ist aber nicht wirklich drin, wenn man 4 Cluster anstatt eines fetten Kerns haben will.

Wer spricht von 4 Clustern? 2 Cluster mit je 2-fach SMT wären ein guter Kompromiss aus hoher singlethreaded und multithreaded IPC. Zwei Cluster hat man ja bereits bei Bulldozer. Man müsste im Grunde die Integer Cluster einfach nur verbreitern, auf 6 oder 8 ALUs/AGUs, und ähnlich wie bei der FPU SMT implementieren. Ausschliessen würde ich es daher nicht. Auch wenn ich im Moment eher zu klassischen Einzelkernen tendiere. Cyclone lässt grüssen.

 

[y33H@]

Jupp, genauer gesagt die geleakten japanischen.

Die sind recht alt, im Original von der HPC China von November 2014.

 

[miriquidi]

Wieso? Apple hat beim A8 neben einem 4 MB L3 einen 1 MB L2 für einen Kern. 1 MB L2 pro Kern hatten auch schon die alten K8. Und bei Carrizo (Excavator) ist dies ja auch der Fall, zumindest pro Modul. 256 KB ist mMn einfach zu winzig für einen L2. 1 MB sollte im Moment ein guter Kompromiss aus Grösse und Latenz sein.

Carrizo und der K8 haben keinen L3-Cache. Da ergibt es evtl. mehr Sinn den L2-Cache etwas größer auszuführen.
Wobei man beim K8 bei vielen Anwendungen auch keinen großen Unterschiede zwischen 512 kiB L2-Cache und 1024 kiB L2-Cache bemerkt.

Als Gedankenspiel könnte man bei einem 16 Kerner noch weiter gehen. Single-Threaded nutzt man den vollen L2-Cache sowie L3-Cache, welche beide mit ihrer maximalen Frequenz betrieben werden (=Turbo-Modus). Sofern "viele" Kerne ausgelastet werden, senkt man die Cache-Taktraten ab und kann evtl. sogar Teile der L2-Caches abschalten. Sofern man damit z.B. 15 % Energie spart, nur 5 % IPC verliert und mit den 15 % Energieeinsparung den Takt um 10 % anheben kann, lohnt sich das. Wobei natürlich einiges an Aufwand dahinter steckt.

 

[Complicated]

Ob hier auch schon der Cache ähnlich wie HBM als stacked Module auf einem Interposer Platz finden? Irgendwie erscheint mir DDR4-Quadchannel UND HBM auf der selben APU nicht sinnvoll.

 

[bschicht86]

Irgendwie erscheint mir DDR4-Quadchannel UND HBM auf der selben APU nicht sinnvoll.

Gerade für die Serverumgebung würde ich das Sinnvoll finden. Schneller, großer L4-Cache im Form von HBM und zusätzlich 4 DDR4-Kanäle für höchstmöglichen Speicherausbau.

Für den "einfachen" Desktop-Betrieb kann man ja dann 2 DDR4-kanäle wegschalten, dafür mit HBM als APU oder 4 Kanäle DDR4 ohne iGPU/HBM für den Gamer-Bereich.

 

[Opteron]

Ich sehe darin absolut kein Problem. Lieber für den Grossteil der Workloads einen schnellen L3 als für ein paar wenige Workloads den Umweg RAM nicht gehen zu müssen. So eine Modulbauweise hat eben den Vorteil, dass es das Design sehr flexibel macht. Für AMDs Semi-Custom Pläne sicherlich nicht die schlechteste Basis. Und je mehr Parallelität ins Spiel kommt, umso mehr rückt die Speicherlatenz sowieso in den Hintergrund.

Ok ist ein Punkt, je paralleler desto unabhängiger werden die Threads sein, ansonsten würde sich die Parallelität nicht rentieren.

Intel zB muss Abstriche beim L3 ihrer Core Prozessoren machen. Nur das L3 Segment, welches direkt am Kern hängt, kann mit der niedrigsten Latenz angesprochen werden. Für andere Kerne ist die Latenz höher. Dann lieber einen kompakten und einheitlichen L3 für wenige Kerne und HBM als LLC für alle Kerne nutzen. Ist mMn deutlich sinnvoller aufgrund der weitaus höheren Kapazität von HBM.

Jein ... auch wenn das schon richtig ist was Du sagst, wärs bei nem 4x4=16core schon ganz nett, wenn ein Thread dann nen Riesen-L3-Cache vorfände. Zumindest aus Enthusiasten/Spielersicht, denn Spiele mögen bekanntlich große Caches. Sah man auch beim Übertakten der NB beim K10/BD.

HBM als LLC ..weiss nicht, das sind dann doch gleich 8 GB oder mehr, da würd ich fast nicht mehr von Cache reden. Aber gut, wenn das RAM infolgedessen eine deutlich bessere Latenz bekommt ists wohl auch wieder egal.

Wieso? Apple hat beim A8 neben einem 4 MB L3 einen 1 MB L2 für einen Kern.

Ne für 2 Kerne. Apple hat quasi Dual-Cluster, wie Intel früher zu S775-Zeiten.

256 KB ist mMn einfach zu winzig für einen L2. 1 MB sollte im Moment ein guter Kompromiss aus Grösse und Latenz sein.

Nichts gegen 1MB L2, aber das ist mMn zuviel, AMD will ja eher kleine Kerne produzieren, da seh ich keinen Spielraum für einen einzigen Kern/Thread 1 MB zu verbauen. Insbesondere auch, wenns dann noch 4MB L3 gibt. Als AMD mit dem K10 den L3 einführte, schrumpfte der L2 ja auch auf 512 kB. Außerdem ist der aktuelle L2 der Katzenkerne inklusive der L1-Daten. Wenn man dann dessen XBar-Design übernimmt, würde ich darauf schließen, dass man das mitnehmen würde. Damit müsste es dann eher ein kleiner L2 werden, 4x1MB würden ansonsten die 4MB L3 total nutzlos machen.

Ist jetzt nur die Frage, ob sie sich den Aufwand gemacht haben könnten von inclusive auf exclusive gewechselt zu sein ... wie schätzt Du das sein?
Ich sehs eher gering, ich denke man wird sich auf die Cores konzentrieren und keine 2. Baustelle mit potentiellen Bugs aufreißen.

Bei der Cache-Wahl spielt auch die Speicherkohärenz bei größeren Setups mit rein. Wenn man mehrere Quad-Cluster hat, wäre ein Speicherabgleich nur über die L3s wohl auch einfacher zu realisieren, als wenn man auch noch x-mal vier L1+L2 abfragen müsste. Je mehr Cluster, desto komplexer wirds.

Wer spricht von 4 Clustern? 2 Cluster mit je 2-fach SMT wären ein guter Kompromiss aus hoher singlethreaded und multithreaded IPC.

Wäre es ja, aber im Ursprungsartikel steht nur "Cores". Das kann man bestenfalls mit einen BD-INT-Cluster übersetzten, aber nicht mit SMT. Es sei denn, man wäre auf den Marketingbegriff "virtual cores" reingefallen, fände ich bei ner Architekturbeschreibung überraschend, aber sicher weiss mans nie.

Zwei Cluster hat man ja bereits bei Bulldozer. Man müsste im Grunde die Integer Cluster einfach nur verbreitern, auf 6 oder 8 ALUs/AGUs, und ähnlich wie bei der FPU SMT implementieren. Ausschliessen würde ich es daher nicht. Auch wenn ich im Moment eher zu klassischen Einzelkernen tendiere. Cyclone lässt grüssen.

Hast Du die Gerüchte um In-Order-SMT mitbekommen? Fänd ich eigentlich auch recht spannend. Gibt zwar dazu nur ein INTEL-Paper, aber so kompliziert sollte das auch für AMD nicht zu implementieren sein. Hat den charmanten Vorteil, dass man die vielen Schatten-OoO-Register im InO-Betrieb fest als Architekturregister einem Thread zur Verfügung stellen kann.
Finde den Ansatz relativ clever. IPC interessiert im ultraparallelen Mth-Betrieb schließlich auch keinen mehr und man spart sich die Energie für die ganzen OoO-Logik, die mangels Schattenregistern sowieso immer ineffektiver werden würde.

 

[gruffi]

Jein ... auch wenn das schon richtig ist was Du sagst, wärs bei nem 4x4=16core schon ganz nett, wenn ein Thread dann nen Riesen-L3-Cache vorfände. Zumindest aus Enthusiasten/Spielersicht, denn Spiele mögen bekanntlich große Caches. Sah man auch beim Übertakten der NB beim K10/BD.

Auch Spiele profitieren nicht endlos von Cache. Man sieht ja bei den 6- und 8-Kern i7, dass sie trotz der grossen Caches in Spielen kaum schneller als die kleineren 4-Kern i5/i7 sind. Zu grosse Caches sind mMn einfach Verschwendung. Dann lieber mehr Kerne/Shader implementieren. Bringt einfach mehr Performance. Erst recht mit Mantle/Vulkan/DX12. Und wie gesagt, im Vergleich zu HBM sind die bisherigen Caches eh ziemlich mickrig. Warum also Transistorbudget mit grossen Caches verschwenden, wenn HBM wesentlich mehr Kapazität bietet?

Ne für 2 Kerne.

Das war beim A7 so. Beim A8 sind die Caches physisch getrennt. Ob sie wirklich shared sind, ist daher fraglich. Die Reviews dazu sind etwas unklar. Könnten demnach 512 KB pro Kern sein.

Nichts gegen 1MB L2, aber das ist mMn zuviel, AMD will ja eher kleine Kerne produzieren, da seh ich keinen Spielraum für einen einzigen Kern/Thread 1 MB zu verbauen.

Zen und K12 werden mit Sicherheit nicht klein, also im Vergleich zu anderen Kernen in gleicher Strukturbreite. Da sollten 1 MB L2 nicht das Problem sein. Selbst Intel setzt beim Xeon Phi auf 512 KB pro Kern. Allerdings haben die auch nur 32 KB L1D. So oder so, 512 KB L2 pro Kern sollten es mindestens sein. 256 KB sind einfach zu wenig. Das hat man schon bei den alten Semprons gesehen, die ja teilweise auch nur 256 KB hatten. Und dass AMD nun Geschwindigkeitsrekorde beim L3 aufstellt, ist auch nicht zu erwarten. Daher brauchen sie einfach eine gewisse Kapazität an L2.

Als AMD mit dem K10 den L3 einführte, schrumpfte der L2 ja auch auf 512 kB.

Nein, der schrumpfte da nicht. Brisbane zuvor hatte ja auch nur 512 KB L2. Wenn dann schrumpfte der L2 von 90nm auf 65nm. Letztendlich ist es wohl eine Kosten-Nutzen-Frage und was an Transistorbudget verfügbar ist. Barcelona hatte ja auch nur 2 MB L3, weil einfach nicht mehr drin war, ohne das Die aufzublähen. Propus in 45nm hatte auch nur 512 KB K2, Llano in 32nm wiederum hatte 1 MB L2.

Außerdem ist der aktuelle L2 der Katzenkerne inklusive der L1-Daten.

Umso mehr ein Grund, den L2 ausreichend gross zu machen. Bei 64 KB L1D und 256 KB L2 ist praktisch bereits ein Viertel der L2 Kapazität aufgrund der Inklusivität reserviert. Blieben effektiv noch 192 KB übrig. Einfach zu wenig.

Wenn man dann dessen XBar-Design übernimmt, würde ich darauf schließen, dass man das mitnehmen würde. Damit müsste es dann eher ein kleiner L2 werden, 4x1MB würden ansonsten die 4MB L3 total nutzlos machen.

Wieso? Der L3 war bei AMD bisher nicht inklusive, sondern ein Victim Cache. Und ich denke das wird sich auch nicht ändern. Womöglich ist auch das der Grund, warum Intel bei der Core Architektur den L2 bei 256 KB belässt. Dort ist der L3 inklusive. Bei mehr L2 würde zu viel an L3 verlorengehen.

Bei der Cache-Wahl spielt auch die Speicherkohärenz bei größeren Setups mit rein. Wenn man mehrere Quad-Cluster hat, wäre ein Speicherabgleich nur über die L3s wohl auch einfacher zu realisieren, als wenn man auch noch x-mal vier L1+L2 abfragen müsste. Je mehr Cluster, desto komplexer wirds.

Den L1 musst du nicht abfragen, der ist ja bereits im L2. Aber deshalb bin ich auch kein Freund von zu vielen Cache Levels. Speicherkohärenz ist da nur ein Argument. Ich könnte mir vorstellen, das man in Zukunft nur noch L1 und L2 pro Kern und HBM als shared LLC hat. HBM bietet genügend Kapazität, um sämtlichen L2 Cache zu halten, auch bei grösseren L2 Caches. Speicherkohärenz könnte man dann darüber sicherstellen. Aber dafür ist die Integration von HBM vermutlich nächstes Jahr noch nicht so weit. Also wird man es erst mal über den L3 machen. Aber da dies bei den K10/BD MCM Designs auch schon mit getrennten L3 Caches gemacht wurde, wird man auch bei Zen eine Lösung finden.

Wäre es ja, aber im Ursprungsartikel steht nur "Cores".

Darauf sollte man nicht viel geben. Spätestens seit BD wissen wir, wie irreführend solche Bezeichnungen sein können. Vorstellbar wäre auch ein Cluster bestehend aus 4 Integer Einheiten und 2-fach SMT pro Integer Einheit. Aber wie gesagt, vermutlich zu komplex und risikoreich in der Umsetzung. Die FPU müsste man dann auch verbreitern oder gar 2 FPU Cluster bereitstellen. Daher glaube ich, dass wir eher klassische single-threaded Kerne sehen.

Hast Du die Gerüchte um In-Order-SMT mitbekommen?

Du meinst die Spekulationen um MorphCore? Bin da eher etwas skeptisch. Letztendlich verfolgt man damit das gleiche Ziel wie HSA. Allerdings erscheinen mir dedizierte LCUs und TCUs für das Vorhaben effizienter und einfacher in der Umsetzung. LCUs und TCUs sind einfach zu verschieden, um sie effektiv innerhalb ein und derselben Architektur unterzubringen. Laut Intel kann MorphCore die single-threaded Performance leicht verringern und die multithreaded Performance um gut 20% erhöhen bei knapp 10% weniger Energiebedarf. Wunder sollte man also keine erwarten. Wenn man ersten geleakten Benchmarks (Geekbench 3) zu Skylake glauben darf, dann scheint sich die Performance auch in etwa zu bestätigen. Bei vergleichbarem Takt knapp hinter Haswell in single-threaded und etwa 15% vor Haswell in multithreaded. Bin da ehrlich gesagt eher auf VISC gespannt, die nochmals einen wesentlich radikaleren Ansatz verfolgen als MorphCore.

 

[Opteron]

Auch Spiele profitieren nicht endlos von Cache. Man sieht ja bei den 6- und 8-Kern i7, dass sie trotz der grossen Caches in Spielen kaum schneller als die kleineren 4-Kern i5/i7 sind.

Naja, bei ein paar halt dann aber doch ... da ist ein alter Sandy 6core manchmal schneller als ein 1150-Haswell.
Klar ist das nicht bei jedem Spiel so, aber wär halt "nett" soetwas mitnehmen zu können..

Zu grosse Caches sind mMn einfach Verschwendung. Dann lieber mehr Kerne/Shader implementieren. Bringt einfach mehr Performance.

Wolltest Du nicht gerade 1MB L2?

Erst recht mit Mantle/Vulkan/DX12. Und wie gesagt, im Vergleich zu HBM sind die bisherigen Caches eh ziemlich mickrig. Warum also Transistorbudget mit grossen Caches verschwenden, wenn HBM wesentlich mehr Kapazität bietet?

Jojo HBM wird schon gut (hoffentlich ^^), wird man halt austesten müssen. AMDs L3 war bei BD im Vergleich zu Intels L3 auch kein Vergleich. Wenn Zen nicht schneller werden würde, könnte man stattdessen wohl auch HBM nehmen.

Das war beim A7 so. Beim A8 sind die Caches physisch getrennt. Ob sie wirklich shared sind, ist daher fraglich. Die Reviews dazu sind etwas unklar. Könnten demnach 512 KB pro Kern sein.

Bis Du Dir da sicher? Die Memory-Latenz bei Anandtech zeigt um die 512 kB keine Anomalitäten, erst ab ~800 kB steigen die Latenzen an, typisch für einen 1MB L2. Der L2 ist demnach sicher größer als 512 kB:
http://www.anandtech.com/show/8554/the-iphone-6-review/2

Zen und K12 werden mit Sicherheit nicht klein, also im Vergleich zu anderen Kernen in gleicher Strukturbreite. Da sollten 1 MB L2 nicht das Problem sein.

Naja, hoffen kann man, aber ich denke statt den 1MB würde AMD die Transistoren anderweitig verbauen.

Selbst Intel setzt beim Xeon Phi auf 512 KB pro Kern. Allerdings haben die auch nur 32 KB L1D.

Na die 32kb L1 haben alle Intels, das erklärts nicht. Vielmehr erklärt der nicht vorhandene L3 den größeren L2.
Nachdem der Zen aber laut der aktuellen Quelle L3 bekommen soll, spräche das für einen kleineren L2.

So oder so, 512 KB L2 pro Kern sollten es mindestens sein. 256 KB sind einfach zu wenig. Das hat man schon bei den alten Semprons gesehen, die ja teilweise auch nur 256 KB hatten.

Die hatten auch keine 4 MB L3

Umso mehr ein Grund, den L2 ausreichend gross zu machen. Bei 64 KB L1D und 256 KB L2 ist praktisch bereits ein Viertel der L2 Kapazität aufgrund der Inklusivität reserviert. Blieben effektiv noch 192 KB übrig. Einfach zu wenig.

Vielleicht bekommt ZEN deswegen wie die Katzenkerne nur 32kB L1?
Du hast schon recht, bei 64kB L1 würden sich die 256 L2 nicht rentieren .. aber bei 32 scheint das ein gutes Mittel zu sein, da 32 kB selbst schon ne gute Hit-Rate liefern und zusammen mit (sehr schnellen) 256 kB L2 und L3 dann besser als 64kB L1 + langsamen 1MB L2 + noch langsameren L3 abschneiden.

Wieso? Der L3 war bei AMD bisher nicht inklusive, sondern ein Victim Cache. Und ich denke das wird sich auch nicht ändern.

Naja, das Victimcache-Konzept hatte man bei den Katzen ja schon aufgegeben. Da gabs zwar keinen L3, aber das ändert nichts am unterschiedlichen Konzept.

Womöglich ist auch das der Grund, warum Intel bei der Core Architektur den L2 bei 256 KB belässt. Dort ist der L3 inklusive. Bei mehr L2 würde zu viel an L3 verlorengehen.

Das ist definitiv der Grund

Darauf sollte man nicht viel geben. Spätestens seit BD wissen wir, wie irreführend solche Bezeichnungen sein können. Vorstellbar wäre auch ein Cluster bestehend aus 4 Integer Einheiten und 2-fach SMT pro Integer Einheit. Aber wie gesagt, vermutlich zu komplex und risikoreich in der Umsetzung. Die FPU müsste man dann auch verbreitern oder gar 2 FPU Cluster bereitstellen. Daher glaube ich, dass wir eher klassische single-threaded Kerne sehen.

Hmm ja stimmt schon. Gerade gabs wieder nen Artikel mit Ursprungslink auf ne japanische Seite, dort stand im Orginal nur "many core / many threads".
Also alles offen.

Du meinst die Spekulationen um MorphCore? Bin da eher etwas skeptisch. Letztendlich verfolgt man damit das gleiche Ziel wie HSA. Allerdings erscheinen mir dedizierte LCUs und TCUs für das Vorhaben effizienter und einfacher in der Umsetzung. LCUs und TCUs sind einfach zu verschieden, um sie effektiv innerhalb ein und derselben Architektur unterzubringen. Laut Intel kann MorphCore die single-threaded Performance leicht verringern und die multithreaded Performance um gut 20% erhöhen bei knapp 10% weniger Energiebedarf. Wunder sollte man also keine erwarten. Wenn man ersten geleakten Benchmarks (Geekbench 3) zu Skylake glauben darf, dann scheint sich die Performance auch in etwa zu bestätigen. Bei vergleichbarem Takt knapp hinter Haswell in single-threaded und etwa 15% vor Haswell in multithreaded. Bin da ehrlich gesagt eher auf VISC gespannt, die nochmals einen wesentlich radikaleren Ansatz verfolgen als MorphCore.

Ja Morphcore wars. Hmm .. dass das ein HSA-Konkurrent sein sollte erkannte ich nicht, eben aus dem von Dir genannten Unterschieden von LCU<>TCU. Gegen die vielen kleinen GPU-Shader hat man doch keine Chance. Ne ich fands nur deshalb interessant den Throughput bei x86 Wald und Wiesencodes zu steigern, z.B. für unsere Boincfraktion. VISC ... ja sicherlich interessant, hört sich aber irgendwie viel zu fantastisch an, als dass ich das glauben kann ... naja warten wirs mal ab.

 

[Ge0rgy]

Also ohne mich in eure Diskussion einmischen zu wollen, dazu habe ich zuwenig Einblick in ZEN und die aktuellen Architekturglanzleistungen...
@Opteron, also du darauf angesprochen hast dass man Schattenregister zu Architekturregistern umdeklarieren könnte, hatte ich ein großes "WTF?" im Gesicht.
Wie viele Register benutzt bzw. befüllt werden entscheidet doch der Compiler bzw. Assembler wenn der die Load bzw. MOV-Befehle generiert.
D.h. Ohne dass das Register direkt angesprochen wird, und mit Daten befüllt die man verrechnen will, hilft die Schiere Anzahl an Registern erstmal garnichts.
Wenn das ein allgemeines Architekturmerkmal ist, in Ordnung, dann werden die Compiler bzw. Assembler für die Architektur eben so ausgelegt dass sie das entsprechend nutzen.
Aber nur weil ein einziges Exemplar von x86er zig Register bietet, tun das die übrigen noch lange nicht und daher wird das auch kaum genutzt werden.
Oder bin ich da auf dem hölzernen Pfad?
Nebenbei bemerkt, helfen viele Register überhaupt was? - ich meine, die mesiten x86-Befehle arbeiten mit 2 oder 3 Operanden. Das Gros der Instruktionen ist auch noch destruktiv, das heißt eines der Operanden-Register wird vom Ergebnis überschrieben. Dann haben wir eine Handvoll Register für Schleifenzähler und dergleichen Kram aber das wars dann auch.
Nungut, man kann theoretisch schon die ganzen Operanden für 3 oder 4 Befehle im Voraus laden, aber ob das wiederum was bringt. Geladen werden müssen sie ja sowieso, also auch nicht weniger MOVs oder Speicherzugriffe.

Theoretisch kann man natürlich auch IN-ORDER-Kerne bauen und dann versuchen die LAtenzen durch SMT zu verstecken, haben nicht die ATOMs der ersten oder zweiten Generation sowas gemacht? - Gebracht hats ihnen aber auch eher wenig, die bobcats waren auch nicht größer und schon durchaus effiziente OoO-Kernchen.
Ob ZEN nun ein Katzen-Verwandter ist oder doch was anderes, werden wir ja wohl spätestens an den ersten DIE Shots erkennen können. Aber die Geschichte mit den Inklusiven Caches ist ja nun auch nicht so als Könnte AMD nichts anderes bauen. Man kann auch die XBAR von Bulldozer nehmen und statt dem L3 dann HBM anflanschen.
Die ganze Diskussion um caches deutet zumidnest an dass auch AMD erkannt hat, dass eine anständige Cache-Pipeline mindestens so wichtig ist wie die Rechenpipeline an sich.
Die Effizientesten ALUs nutzen nichts wenn sie auf Daten warten müssen.
Und wisst ihr was das hervorstechendste Charakteristikum unserer CPUs heute ist? - Mit jeder Generation lernen sie schneller zu warten.

 

[tex_]

Das einzige was ich mir bei den Registern vorstellen könnte ist, dass man die OoO Register, als Architekturregister für einen weiteren SMT Thread nutzt. Das bedeutet dann aber, dass man im OoO Modus eben kein SMT nutzen kann. Wirklich viel Sinn macht das für mich aber auch nicht.
Entweder kann man mit dem Code die ALUs nicht perfekt auslasten, dann bringt OoO deutlich mehr Leistung als in-order, oder man kann es und nutzt den sparsamen in-order Modus, aber dann sollte der Theorie nach auch mit SMT nichts mehr rauszuholen sein.
Letztlich wird man das Kerndesign auf eine möglichst gute Out-of-Order Leistung gegebenenfalls gepaart mit SMT auslegen, das Abschalten der OoO Engine wäre dann höchstens noch zum Energiesparen gut.

Und da sind wir dann wieder beim "schneller warten". Eigentlich sollte eine neuere Generation gerade hier ansetzen und anstatt zu warten sich einfach schlafen legen.
Schnell laufen braucht die CPU ja nur, wenn sie auch etwas zum abarbeiten bekommt.

 

[drSeehas]

... D.h. Ohne dass das Register direkt angesprochen wird, und mit Daten befüllt die man verrechnen will, hilft die Schiere Anzahl an Registern erstmal garnichts.

x86 ist aber keine Zwei-Adress-Maschine, wie es z. B. die 68000er waren oder gar die NS32x32 mit zwei Quell- und einer Zieladresse (voll orthogonal, wurde meines Wissens nie wieder erreicht).

... Nebenbei bemerkt, helfen viele Register überhaupt was? - ich meine, die mesiten x86-Befehle arbeiten mit 2 oder 3 Operanden. Das Gros der Instruktionen ist auch noch destruktiv, das heißt eines der Operanden-Register wird vom Ergebnis überschrieben. Dann haben wir eine Handvoll Register für Schleifenzähler und dergleichen Kram aber das wars dann auch. ...

Du hast nie in Assembler programmiert?
Dann wüsstest du nämlich, dass man eigentlich nie genug Register haben kann:

Wenn eines der Operanden-Register vom Ergebnis überschrieben wird und man die ursprünglichen Daten aber später wieder braucht, ist es doch viel schneller, wenn man die Daten in ein anderes Register rettet, als dass man es auf den Stack schreibt und später wieder davon lädt (Push Pop).

Die Situation hat sich durch die Verdoppelung mit x86-64 schon gebessert.