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

AMD und Intel haben doch ein gegenseitiges Patentabkommen.
 
@OBrian
Ach komm....16 GB HBM für die CPU?? Das glaube ich erst wenn ich es als fertiges Produkt sehe, zumindest im Desktop Bereich.
Mit mehr als 1-2 GB rechne ich da noch nicht einmal ansatzweise, eher weniger.

Zudem ist IPC bekanntlich nicht alles. Was bringt eine Verdoppelung der IPC wenn der Chip dann nur noch die halbe Taktfrequenz schafft? Solche Effekte konnte man ja schon beim Kaveri vs. Richland Vergleich sehen. Die IPC des Kaveris ist besser allerdings taktet er geringer, wodurch es wieder zur 0 mutiert oder der Kaveri zum Teil gar langsamer ist.
Am wichtigsten ist in meinen Augen die Steigerung der singlethread Performance und der Energieeffizienz. Von der Gesammtperformance her sind die bereits heute schnell genug um konkurrenzfähig zu sein. Die Achillesferse ist die Unterforderung durch die Software.

@Onkel_Dithmeyer
Bedeutet aber nicht das sie es für lau bekommen oder es Intel freiwillig freigibt. ;)
 
Zuletzt bearbeitet:
Und es gibt nicht so etwas wie "meilenweit vorne" zu sein bei der IPC. Das könnte man auch problemlos morgen machen mit 3facher IPC des Haswell Kerns. Nur wenn der eben nicht über 500 MHz takten kann deswegen, dann nützt mir die takbereinigte IPC-Vergleicherei herzlich wenig.
Gibt es eben doch. Intel liefert grob 50 Prozent mehr IPC bei Wald- und Wiesen-Code und erreicht auch 4 GHz (4790K vs FX-8370). Genau das ist ja das Problem: AMD kann die viel niedrigere IPC nicht durch Takt oder Kerne ausgleichen, außer in niedrigeren Preisklassen wie FX-63x0 vs Core i3 oder Kaveri vs Pentium.
 
@Onkel_Dithmeyer
Bedeutet aber nicht das sie es für lau bekommen oder es Intel freiwillig freigibt. ;)

Freigegeben ist alles, aber das Problem ist das, dass mans erst einmal nachbauen und ins eigene Design anpassen muss. Sieht man z.B. daran, dass AMD sogar nen Loop Puffer hat, aber halt nur auf Steinzeitniveau, da wird ein Teil des L1I-Caches genutzt und falls die Daten dort sind spart man sich die Abfrage der anderen Cachebänke, was etwas Energie spart.

Verglichen mit Sandys µOp-Cache, der den kompletten Decoder abschaltet natürlich witzlos. Falls AMD beim BD-Cluster-Design bleiben würde, könnte man aufs Energiesparen auch verzichten. Ein µOp-Cache würde in dem Fall einfach das gemeinsame Front-End entlasten und mehr Decoderresourcen für den 2. Thread frei lassen. Bei intel ist das nicht so wichtig da ein SMT-Thread noch alles andere gemeinsam benutzt und es nicht am Decodieren klemmt, aber bei nem CMT-Design könnte das dann der Flaschenhals sein.

Naja, kommt Zeit kommt Zen. Mit den ganzen Energiesparmaßnahmen und den HD-Libs könnte sich AMD vielleicht sogar nen Viel-Hilft-Viel-Ansatz leisten und einfach nen breiten Decoder verbauen.
 
Wenn Zen ein SMT Design wird ist das doch eh wieder hinfällig, oder?
Und muss AMD nicht für solche Technologien nicht auch etwas anbieten? Es ist schließlich ein Patenttauschabkommen. Ich habe leider kein Plan von der Thematik. *suspect*
 
Also wenn sich Fudzilla das alles selbst ausdenkt, dann sind sie auf jeden Fall sehr kreativ:

What we can confirm is that the 32-core processor actually uses 8 cores per die on four die ona MCM (Multi Chip Module) socketed LGA design.

Each MCM module with 8 cores has two memory channels with up to 2 DIMMs per channel. The maximum TDP for the Opteron Zen 2016 series is set at the standard 140W and there will be a 120W TDP SKU, as well as lower TDP parts.

AMD also has something called Combo Links that combines 8-16 bit links (2 per die) and this link can take the form of xGMI, PCIe, SATA, SATA Express, 10Gbase-KR or SGMII. There will be boards with 1P socket configurations and 2P socket configurations for more than one LGA socketed processor.

Dual socket 2P motherboards support four AMD External Global Memory interconnect xGMI links, or one per die. The standard 2P board comes with maximum of 64 PCIe lanes per socket, 16 SATA laners, four 10GigE and four 1GigE per socket.

AMD relies on coherent interconnect for 2-socket configurations that should enable faster inter-socket communication between two CPUs.


http://www.fudzilla.com/news/processors/37599-32-core-opteron-supports-2p-sockets
 
Oder jemand füttert sie ;)
Ist ja ne nette Möglichkeit zu schauen, welche Informationen über welchen Kanal laufen, wenn man viele Details reinpackt, die sich in Kleinigkeiten unterscheiden und dann schaut, wo was veröffentlicht wird.
 
Ein wunderbares Instrument um unliebsame Personen loszuwerden. Info gezielt verteilen intern und extern. Danach das ganze gezielt an falsche Stellen weiterleiten. Faszinierend zum zuschauen, vorallem wenn es dan schief geht.
 
140W für 32 Kerne könnte heißen CPUs mit ~35W bei 8 Kernen, oder ~70W für 16 Kerne, oder sogar weniger. Damit könnte eine ~95W 16-Kern-Desktop-APU nicht unwahrscheinlich sein, oder?
 
Mit wie viel Takt wäre dann die große Frage.Um 3,5GHz sollten es aber schon sein.
 
Wenn Zen ein SMT Design wird ist das doch eh wieder hinfällig, oder?
Deswegen schrieb ich ja, dass das nur gälte WENN sie beim BD-Ansatz blieben. Wenns SMT wird, könnte man Intels Ansatz kopieren - wenn mans kann.
Und muss AMD nicht für solche Technologien nicht auch etwas anbieten? Es ist schließlich ein Patenttauschabkommen. Ich habe leider kein Plan von der Thematik.
Ich sag nur ATi ... seit AMDs Kauf von ATi darf Intel auch die ganzen GPU-Patente benutzen. Ohne die dürften sie ihre IGPs sicher nicht so einfach bauen.

Also wenn sich Fudzilla das alles selbst ausdenkt, dann sind sie auf jeden Fall sehr kreativ:
Hm ok, also so langsam machts Sinn ... ein 8core Die mit nur 2 DDR4-Kanälen .. sowas würde dann sicher auch in den APU-Mainstream-Sockel passen.

Gut für uns - aber eher schlecht für die Serverkunden. Bin mal gespannt, was so ein zusammengebasteltes 4P-System on a chip leisten wird, v.a. wenns dann nur 1 DIMM-Kanal pro 8 Kerne gibt. Vor dem Hintergrund sind die 8MB L3 pro Quadcluster sicher nicht zu klein gewählt.

So gesehen bleibt sich AMD doch treu, keine Dickschiff-Dies, aber Dickschiff-MCMs ;)
Der Vorteil liegt auf der Hand, mit kleineren Dies kann AMD früher als Intel vielkernige Server-CPUs im neuesten Herstellungsprozess rausbringen. Da Intel aber bekanntlich fertigungstechnisch immer etwas voraus ist, reichts ggf. zwar nur zum Gleichstand - aber immer noch besser als ein Nachteil.

Wird spannend, was das für ein Interconnect ist. Der muss es dann rausreißen. Ein verbessertes HT Assist / Directory Cache wär sicherlich auch nicht verkehrt.

Dual socket 2P motherboards support four AMD External Global Memory interconnect xGMI links, or one per die. The standard 2P board comes with maximum of 64 PCIe lanes per socket, 16 SATA laners, four 10GigE and four 1GigE per socket.
Da würde mich noch interessieren, ob das alles gleichzeitig ginge, ich denke eher nicht.
 
140W für 32 Kerne könnte heißen CPUs mit ~35W bei 8 Kernen, oder ~70W für 16 Kerne, oder sogar weniger. Damit könnte eine ~95W 16-Kern-Desktop-APU nicht unwahrscheinlich sein, oder?

Naja, die 63xx-Opterons gibts mit 85 W und 16 Kernen. Trotzdem haben wir keine 8-Kerner mit <45 W. Wären aber mit 1,8 GHz wie Casi030 schreibt auch schlicht uninteressant.
 
Eine durchschnittlich 50% höhere IPC als Steamroller wäre vielleicht auf dem Niveau von Sandy Bridge. Das ist auch das, was ich von AMD erwarte, schließlich ist Sandy älter als Bulldozer. Dass AMD in dieser Hinsicht komplett zu Intel (Skylake) aufschließen kann, ist gar nicht realistisch, aber Sandy Bridge-IPC und -Taktraten sollten schon drin sein. Mit 8 Kernen/ 16 Threads und max 125W wäre das ein sehr netter Prozessor.

Um an die Single Thread-Geschwindigkeit eines Sandy Bridge Prozessors zu kommen, müsste AMD wohl den µ-Op-Cache sowie die Erkennung von Schleifen einbauen, um kurze Schleifen aus dem µ-Op-Cache allein unter weitgehender Abschaltung der Dekodiereinheiten von x86 auf µ-Code abwickeln zu können. Diese Feature gibt Sandy Bridge laut c't die IPC und erlaubt aufgrund der Energieeinsparungen den recht hohen Takt. Diese Technologie wird vermutlich patentgeschützt sein und für AMD damit nicht zugänglich.
Soso...also bringt die SSE 4.1 Erweiterung oder AVX für Bulldozer keinen IPC-Sprung? z.B. hier:
http://www.extremetech.com/computing/100583-analyzing-bulldozers-scaling-single-thread-performance/4

Was tust mit HSA Workloads wo Intel hoffnungslos hinterher ist? Reden wir dort nciht von IPC? Wo dürfen wir denn von IPC reden und was ist dann IPC die nichts zählt? Ich sehe einfach nicht diese Notwendigkeit Hardware auf Cinebench zu designen, während die Software-Biotope, gerade durch AMD angestossen, mit HSA, Mantle, Viulkan, DX12 diese "IPC-Werte" gravierend verändern werden, selbst nachträglich für bestehende Produkte. Wieso sollte jetzt, wo all die mühevolle Arbeit aus der Theorie langsam in die Praxis kommt, AMD anfangen für Cinebench zu optimieren?
 
Soso...also bringt die SSE 4.1 Erweiterung oder AVX für Bulldozer keinen IPC-Sprung? z.B. hier:
http://www.extremetech.com/computing/100583-analyzing-bulldozers-scaling-single-thread-performance/4

Was tust mit HSA Workloads wo Intel hoffnungslos hinterher ist? Reden wir dort nciht von IPC? Wo dürfen wir denn von IPC reden und was ist dann IPC die nichts zählt? Ich sehe einfach nicht diese Notwendigkeit Hardware auf Cinebench zu designen, während die Software-Biotope, gerade durch AMD angestossen, mit HSA, Mantle, Viulkan, DX12 diese "IPC-Werte" gravierend verändern werden, selbst nachträglich für bestehende Produkte. Wieso sollte jetzt, wo all die mühevolle Arbeit aus der Theorie langsam in die Praxis kommt, AMD anfangen für Cinebench zu optimieren?

Es war ganz einfach die reine IPC der CPU-Kerne bei diversen Integer- und FP-Sachen gemeint. Die steigt durch Mantle und co übrigens nicht direkt an. Und natürlich verbessern neue Instruktionssätze wie AVX die IPC, aber eben nicht bei "Wald und Wiesen"-Code. Und genau dort braucht AMD einfach mehr Leistung/Takt.
 
Was ist den die "reine" IPC bei "diversen" Integer und FP-Sachen. Sorry doch das ist doch Humbug. Wer verbesert Hardware auf alten und überholten Code? Für Cinbebench wo Intel dann bessere SSE-Pfade nutzen darf als AMD? Was ist der Nutzen wenn plötzlich ander APIs wie Mantle das ganze als anderen Flaschenhals enthüllen?

Schaut man sich SPEC Benchmarks an, sind die Werte der Steamroller nicht so weit hinterher.
Leistung/Takt ist irrelevant. Es zählt nur die Leistung/Watt und in speziellen Fällen die Maximale Leistung. Wer höher takten kann weil er IPC opfert und dabei weniger Strom verbraucht, der hat alle richtig gemacht. Wenn nicht, dann eben nicht. Es ist alle eine Frage der Latenz und Cache-Anbindung, sowie der Anforderungen an Koheränte Speicher und deren Anbindung.
 
Es geht nicht darum, Hardware für "überholten" Code zu designen, sondern darum, dass die Kerne einfach eine höhere Grundperformance liefern. Leider sind reale Anwendungen nicht perfekt optimiert und ziehen auch noch keinen Großen nutzen aus HSA. Zumal man mit Mantle und co Dinge wie Rendering (ich meine keine Spiele) auch nicht wirklich beschleunigen kann. Und natürlich ist Leistung/Takt relevant, weil man seine Kerne nicht endlos hoch takten kann und einfach eine hohe grundsätzliche Performance benötigt. Zwar braucht eine hohe IPC mehr Strom, aber für Takt gilt das sogar noch mehr, weil die Stromaufnahme im Quadrat zu Spannung und Takt steigt. Intel fährt sehr gut mit seinen starken Kernen. Sonst könnte man auch einfach Jaguar/Puma weiterbenutzen und gut is'.
 
Liste mal die Spiele auf, die SSE 4.1 oder AVX nutzen. Dürfte relativ kurz sein. Und dann liste mal die Spiele auf, die mit mehr als vier Kernen noch skalieren. Gibt es auch wenig, denn üblicherweise kann der Workload nicht wie bei Videoencoding o.ä. in fast beliebig viele gleichgroße Teile geteilt werden, sondern es gibt letztlich einen Thread, der einen Kern voll auslastet, und das Dutzend andere Threads verteilt sich auf die anderen Kerne, wo dann egal ist, ob 2 oder 3 auf einem Kern sind, weil der Kern eh noch nicht voll ausgelastet ist. D.h. der eine fette Thread limitiert. Da nützen dann keine 12 weiteren SMT-fähigen Kerne was, sondern der Core #0 muß schneller arbeiten, entweder durch mehr Takt oder durch mehr IPC oder beides.

D.h. es muß erstmal ein Kern her, der mit altem Code richtig gut performt. Wenn man das hat, kann man an AVX, SMT und so weiter denken. Klar, man könnte auch darauf warten, daß die Softwarelandschaft die Hardware ausnutzt. Nur passiert das so langsam, daß man bis dahin pleite ist. Wir haben JETZT Spieleengines, die 4-Kerner erfordern und auf Zweikernern zu viel verlieren. Aber Quadcores gibt es jetzt schon über acht Jahre, und einen Q6600 hat heute keiner mehr.
 
Und natürlich verbessern neue Instruktionssätze wie AVX die IPC
Normalerweise nicht. Ganz im Gegenteil, sie können die IPC oft sogar verringern. Neue Befehlssätze verbessern vielmehr IOPS und FLOPS oder verringern den Instruktionsaufwand. Deshalb sollte man auch immer vorsichtig sein, einfach zu behaupten, CPU A hat mehr IPC als CPU B, nur weil in einer bestimmten Anwendungen CPU A entsprechend schneller ist. Diese IPC Rechnung funktioniert eben nur, wenn beide CPUs den exakt gleichen Code verarbeiten.


Um an die Single Thread-Geschwindigkeit eines Sandy Bridge Prozessors zu kommen, müsste AMD wohl den µ-Op-Cache sowie die Erkennung von Schleifen einbauen, um kurze Schleifen aus dem µ-Op-Cache allein unter weitgehender Abschaltung der Dekodiereinheiten von x86 auf µ-Code abwickeln zu können.
Einen Loop Detector gibt's bei AMD seit Steamroller / Jaguar. Der alleine reicht aber nicht, um 30-40% IPC gutzumachen. Da braucht es schon grundlegende Änderungen an der Pipeline.


Ich sag nur ATi ... seit AMDs Kauf von ATi darf Intel auch die ganzen GPU-Patente benutzen.
Sagt wer? Das halte ich ehrlich gesagt für ein Gerücht. Ich glaube nicht, dass Intel irgendwelche GPU Patente von AMD nutzen kann. Intel hat sicherlich nicht grundlos ein Patentabkommen mit Nvidia.
 
Zuletzt bearbeitet:
Normalerweise nicht. Ganz im Gegenteil, sie können die IPC oft sogar verringern. Neue Befehlssätze verbessern vielmehr IOPS und FLOPS oder verringern den Instruktionsaufwand. Deshalb sollte man auch immer vorsichtig sein, einfach zu behaupten, CPU A hat mehr IPC als CPU B, nur weil in einer bestimmten Anwendungen CPU A entsprechend schneller ist. Diese IPC Rechnung funktioniert eben nur, wenn beide CPUs den exakt gleichen Code verarbeiten.

Ich meinte eher, dass es "die IPC" an sich ja gar nicht gibt und man immer spezielle Fälle berücksichtigen muss. Für Anwendungen, die AVX nutzen, wird die Anzahl der Instruktionen pro Takt eben erhöht, deswegen "höhere IPC".
 
Es zählt nur die Leistung/Watt [...]
Und da hat sich im letzten Jahrzehnt bis auf wenige Ausnahmen gezeigt, dass eine hohe Leistung/Takt für die Effizienz wichtig ist. Intel hat Netburst vom Markt genommen, AMD ist mit Bulldozer auf die Nase gefallen und IBM hat erkannt, dass der Power7 nicht der Bringer war.

Liste mal die Spiele auf, die SSE 4.1 oder AVX nutzen.
AVX haste AFAIK nur bei Codemasters' Titeln wie Dirt Showdown und Race Driver Grid 2.

Und dann liste mal die Spiele auf, die mit mehr als vier Kernen noch skalieren.
Mittlerweile klappt das recht gut - spricht mindestens mal 15 bis 20 Prozent Plus, zB Cryengine (Ryse & Crysis 3), Frostbite (Battlefield 4 und Dragon Age Inquisition) und RAGE (GTA 5).
 
Für Anwendungen, die AVX nutzen, wird die Anzahl der Instruktionen pro Takt eben erhöht, deswegen "höhere IPC".
Nochmal, die Anzahl der Instruktionen wird auch mit AVX(2) nicht erhöht. Die Anzahl der Operationen kann sich erhöhen, speziell eben bei SIMD/MIMD Erweiterungen.

Zur Veranschaulichung etwas Assemblercode:
Code:
; legacy
add rax, rbx
; avx2
vpaddq ymm0, ymm1

Es macht keinen Unterschied, ob Legacy oder AVX2 Code. In beiden Fällen muss die Pipeline eine Instruktion dekodieren und ausführen. Während bei der Legacy Instruktion aber nur eine 64-bit Operation ausgeführt wird, sind es bei der AVX2 Instruktion 4 parallele 64-bit Operationen.

Das schaut dann als Pseudocode wie folgt aus:
Code:
; legacy
rax = rax + rbx
; avx2
ymm0[63:0]    = ymm0[63:0]    + ymm1[63:0]
ymm0[127:64]  = ymm0[127:64]  + ymm1[127:64]
ymm0[191:128] = ymm0[191:128] + ymm1[191:128]
ymm0[255:192] = ymm0[255:192] + ymm1[255:192]

Haswell hat 4 ALUs für Legacy Instruktionen, kann also bis zu 4 davon in einem Takt ausführen. Für AVX2 Instruktionen sind hingegen nur 2 Einheiten vorhanden. Unterm Strich bedeutet das, die IPC sinkt um 50% (2 statt 4 Instruktionen pro Takt), die IOPS hingegen steigen um 100% (8 statt 4 64-bit Operationen pro Takt).
 
Es ist schon lustig, dass gerade Cinebench für die CPU-Tests herangezogen wird, weil es eben die Rendersysteme sind, die derzeit massiv auf GPUs setzen und von HSA massiv profitieren könnten. (Momentan ist allerdings Nvidia in dieser Disziplin führend). Man schaue sich nur OTOYs Octane, Vray RT, Luxrender, Cycles an.
Eigentlich gibt es doch kaum noch wichtige Anwendungen im Desktop-Bereich abseits von DX11- und OpenGL-Spielen, die sich nicht parallelisieren lassen und gleichzeitig wirklich fordernd für die CPU sind. (Bitte nennt mir Beispiele aus dem Alltag, ich möchte dazulernen!)
 
Zuletzt bearbeitet:
@isigrim
Packen, entpacken, verschlüsseln, entschlüsseln, Foto+Video Bearbeitung es gibt für jeden, den richtigen Algorithmus.
DX12 spricht von 6 Kernen, auch wenn die Anwendung nur ein Super Thread braucht...

nvidia-748354.jpeg
 
Zurück
Oben Unten