Zen 2 alias Pinnacle Ridge: Anfang 2018?

Selbst wenn Zen+ "nur" 10% höhere IPC als Zen haben sollte (mehr erwarte ich gar nicht), bleibt ja noch Potenzial, den neuen Prozess durch Optimierungen besser zu nutzen als auch der neue 14nm-LPU-Prozess von Samsung, der ja höhere Performance liefern sollte. AMD hat mit Zen eine tolle Basis auf sehr hohem Niveau gelegt.

Zudem ist Zen mit <200mm² kleiner als Polaris-10. Durch den modularen Aufbau mit vier solcher simpler Dice, erspart sich AMD bei Napels nicht nur das Risiko geringen Yields bei großen Dice, sondern die gesamten zusätzlichen Kosten für ein eigenes Die, welche bei 14nm inzwischen immens sind. Mit Raven-Ridge kommt ein zweites Die für die APU, sodass AMD dann mit nur zwei Dice den gesamten Markt von Mainstream bis Server bedient => lediglich zwei Dice! => das spart nicht nur Kosten bei den Masken. Es müssen nur zwei Dice entwickelt und getestet werden. UND: man ist damit sehr flexibel, weil man nur zwei Dice produziert, die man später einfach nach Bedarf dem Zweck zuordnet. AMD hat aus der Not (Kosten müssen gespart werden!) eine Tugend gemacht, die aufzugehen scheint und die sich jetzt auszahlen sollte.
 
ja, sparen ist immer gut, entweder muß man es oder es bleibt einfach mehr vom Gewinn. Ich kauf auch möglichst viele Handelmarken im Supermarkt, auch wenn ich mir Markenprodukte leisten könnte, aber warum muß man das Geld denn verpulvern? Mal sehen, wie sich AMDs Umsatz und Gewinn in Zukunft entwickeln, kann ja nur besser werden.

Hat schon jemand die Skalierung auf der Grafik auf die IPC von Zen+ gemacht?

serveimage
mach das bloß nicht! Die Wahrscheinlichkeit geht gegen 1, daß der Folienbastler damals einfach nur die Pfeile so angeordnet hat, daß sie schön auf der Seite verteilt waren, der hat GANZ SICHER NICHT die Winkel und Abstände ausgerechnet und mit geheimen Informationen korreliert, damit wir das ausrechnen können (wenn auch mühsam). Aus solchen Grafiken IRGENDWAS ableiten zu wollen, ist noch mehr an den Haaren herbeigezogen als nur Kaffeesatzleserei (denn beim Kaffeesatzlesen kann man zumindest herauslesen, daß hier wohl jemand Kaffee getrunken hat^^).

Ebenso bedeutet "Zen+" ja auch nur "das, was nach Zen kommt", sonst nichts. Analog zu diversen Angaben im amerikanischen Sprachgebrauch, wenn man z.B. sagt "this book has 500+ pages", also schlicht "nach Seite 500 geht es noch weiter". Wenn von Zen 2 oder 3 geredet wird, ist wohl damit die Serie gemeint, also nach 1600-1800X kommt dann 1600-2800X usw.


Also ein paar Dinge, die man an Zen verbessern kann, sind ja schon offensichtlich:

- SMT-Effizienz, möglichst keine Negativwirkung. Auf der Folie, wo man sah, welche Bereiche dynamisch für SMT geshared werden, gabs ja auch noch einige, die erstmal noch fix in der Mitte geteilt waren: ungeschickt, aber einfach. Und der Technikmensch, dazu befragt, meinte ja auch gleich (ich paraphrasiere) "das wird dann beim nächsten Mal auch so gemacht, wie wir das eigentlich vorhatten". Müßte also bei PR oder bei dessen Nachfolger kommen.

- Verbindung der beiden 4-Kern-Blöcke untereinander. Könnte man breiter anbinden oder mit höherer Frequenz, oder irgendwelche Puffer einbauen/vergrößern.

- AVX so wie bei Intel; ich schätze, das ist so ein Patentrechte-Ding. AMD hat die jeweils von Intel eingeführte AVX-Implementation immer so ungefähr ein Jahr später erst gebracht. Hexenwerk ist es ja nicht, alles einfach breiter zu bauen.
 
Zuletzt bearbeitet:
Ich glaube den richtigen Hammer werden wir erst mit Raven Ridge sehen. Da hat AMD dann auch seine besten Pfeile im Köcher mit der iGPU und der besseren Anbindung, die ja schon bei den CCX zum Einsatz kommt. Erstmalig L3 Cache auf einer APU und HSA als AVX-Ersatz. Denn ich denke AMD wird dem AVX-Zug nicht weiter folgen. Es ist ja nicht so als ob kein AVX vorhanden wäre im Ryzen. 2X AVX 128lassen sihc ja zu AV 256 zusammenschalten. Und AVX 512 scheint eine Sackgasse zu sein, die AMD nichtn gehen muss weil diese Workloads direkt auf eine GPU verlegt werden können. Mit einer Server-APU würde auch das ganze AVX 512 Konzept von Intel ins wanken kommen, denn diese breiten SIMD INstruktionen sind ja als Konkurrenz zu den GPUs von Nviia und AMD angedacht - warum sollte AMD hier mit gehen? Vor allem da INtel mit dem Takt runter muss um seine AVX Workloads auszureizen.

Wie gesagt: Eine APU mit mehr Bandbreite+L3 Cache und einen HBCC basierend auf Zen und Vega IP wird wohl auch für die Software-Entwickler eine ganz andere Zielplattform darstellen in Verbindung mit HSA. AMD entgeht dann dem Aufrüstdruck bei Instruktionen. So etwas wie TSX hat AMD auch schon anderweitig gelöst.
 
naja, weil AMD gegen die Softwareinfrastruktur nicht ankommt, die für Intel gebaut wird. Wenn Intel AVX bietet und es genutzt wird, kann AMD es nicht ignorieren. Und wenn AMD was besseres anbietet, wird es nicht genutzt werden. Das übliche Problem.

Also wenn, dann muß die GPU "ganz normales" AVX können, sprich es darf für die Software gar nicht erkennbar sein, daß das gar keine Intel-CPU ist, sondern eine AMD-GPU.
 
Ich glaube den richtigen Hammer werden wir erst mit Raven Ridge sehen. Da hat AMD dann auch seine besten Pfeile im Köcher mit der iGPU und der besseren Anbindung, die ja schon bei den CCX zum Einsatz kommt. Erstmalig L3 Cache auf einer APU und HSA als AVX-Ersatz. Denn ich denke AMD wird dem AVX-Zug nicht weiter folgen. Es ist ja nicht so als ob kein AVX vorhanden wäre im Ryzen. 2X AVX 128lassen sihc ja zu AV 256 zusammenschalten. Und AVX 512 scheint eine Sackgasse zu sein, die AMD nichtn gehen muss weil diese Workloads direkt auf eine GPU verlegt werden können. Mit einer Server-APU würde auch das ganze AVX 512 Konzept von Intel ins wanken kommen, denn diese breiten SIMD INstruktionen sind ja als Konkurrenz zu den GPUs von Nviia und AMD angedacht - warum sollte AMD hier mit gehen? Vor allem da INtel mit dem Takt runter muss um seine AVX Workloads auszureizen.

Doppelt so viele Operanden pro Takt bei 70-90% des ursprünglichen Taktes ist immer noch schneller, und einfacher zu coden. Ob es unbedingt native 512 Bit Register sein müssen lasse ich mal dahin gestellt. Native 256 Bit sollten es für den legacy Kram bei einer der nächsten Iterationen schon werden

So etwas wie TSX hat AMD auch schon anderweitig gelöst.

Was hat AMD den als Alternative zu transactional memory?
 
Wieso Alternative? Intel hat es ja nicht sinnvoll zum Einsatz gebracht;
Haswell: https://www.golem.de/news/transacti...tsx-wegen-bug-bei-haswell-ab-1408-108545.html
Broadwell: http://www.pcworld.com/article/2464...enterprise-bug-on-haswell-broadwell-cpus.html
Skylake: http://stackoverflow.com/questions/...tus-of-the-tsx-related-skylake-errata-skl-105
Bei allen dreien wurde es deaktiviert wegen Bug.

Bei AMD nennt sich das ASF und ist ein 8 Jahre alter Hut:
https://www.velox-project.eu/news/amd-releases-advanced-synchronization-facility-asf-specification
ASF provides a mechanism to update multiple shared memory locations atomically without having to rely on locks for mutual exclusion. It's quite flexible as the semantics of the update are not fixed, but can be provided using standard x86 instructions. The ASF specification includes a new group of instructions to delimiter a speculative region, and another instructions that signify the memory locations that need to be monitored for external modifications and also read/writes the memory operands into registers. The speculative region can be commited or aborted, it means that the memory updates are accepted or discarded, respectively.
http://developer.amd.com/wordpress/media/2013/09/45432-ASF_Spec_2.1.pdf
http://se.inf.tu-dresden.de/pubs/papers/christie2010.pdf
http://www.realworldtech.com/haswell-tm/4/
AMD is continuing to work on ASF, which has several substantive differences from TSX; privileged instructions, forward progress guarantees and an absence of register rollback on abort are just a few examples. AMD and Intel face a choice, fragmenting the x86 ecosystem with incompatible extensions, or harmonizing ASF and TSX. From an industry standpoint, the latter is clearly preferable, and there is a risk that software vendors may be unwilling to tolerate such incompatibilities. However, it could take years for Intel and AMD to align their implementations.

Zumal AMD in einem Heterogenen System mit dem gemeinsamen Speicherzugriffen hier weit voraus ist. HSA beinhaltet all dies ebenfalls und APUs enthalten Teile dieser Technik. Auch der neue HBCC von Vega beinhaltet Technologien davon, damit eben af SSDs/Netwok Storage direkte memory writes/reads möglich werden. Das buggy TSX ist da lediglich am hinterher hecheln und hat nur den Vorteil der großen Marktverbreitung von Intel CPUs.

Hier auch schon thematisiert worden im Kaveri-Thread mit weiteren Ressourcen:
http://www.planet3dnow.de/vbulletin...y-Nachfolger?p=4563576&viewfull=1#post4563576

--- Update ---

naja, weil AMD gegen die Softwareinfrastruktur nicht ankommt, die für Intel gebaut wird. Wenn Intel AVX bietet und es genutzt wird, kann AMD es nicht ignorieren. Und wenn AMD was besseres anbietet, wird es nicht genutzt werden. Das übliche Problem.

Nur dass GPUs von Nvidia hier das ganze etwas aufmischen. In diesem Bereichen ist Nvidia vorgeprescht mit CUDA und sowohl AMD als auch Intel müssen sich daran orientieren. AMD hat mit HIP und ROCm seine GPUs in Stellung gebracht, während Intel hier immer weiter ins Hintertreffen kommt wegen fehlenden GPGPU-Lösungen. GPUs werden aus dem HPC nicht mehr so schnell verdrängt werden und da verlieren dann breite SIMD Instruktionen auf der CPU einfach an Bedeutung. Es gibt einen "break even" für AVX, nämlich da wo man noch auf GPUs verzichten kann. Aber sobald man GPUs mit rein nimmt sind die AVX Instruktionen nur noch Ballast, da man sowieso auf GPUs optimiert. AMDs Vega wird hier auch nochmal die Dinge verändern. Vor allem bei dem derzeitigen Hype rund um 16-bit Instruktionen und den geänderten Wachstumsmärkten für deep learning - da braucht niemand noch breitere SIMDs auf der CPUs.
 
Zuletzt bearbeitet:
Wie soll im Bild die Skalierung korrekt sein, wenn noch kein ZEN+ verfügbar ist?
Das Bild sagt doch nur, dass ZEN+ bessere IPC haben wird als ZEN.
Um die Aussage zu erfüllen, reicht es wenn unter bestimmten Bedingungen ein + erreicht wird. Unter normaler Anwendung könnte sich das dann kaum bemerkbar machen.
Ich denke mal, dass der X86 Bonbon weitestgehend gelutscht ist und keine großartigen IPC Verbesserungen mehr kommen werden.

Die 40% habe auch (fast) alle angezweifelt. Da diese Infos auch wegen bzw. für Aktionäre gemacht werden, sollten darauf keine Juristisch problematischen Aussagen drauf sein ;-)

Das Pro Thread kaum weitere IPC Steigerungen möglich sind ist kein alleiniges x86 Problem, auch ARM leidet schon jetzt darunter. Andernfalls würde man auch her die IPC Steigern statt die Kernanzahl zu erhöhen.

Das Technologien wie VISC zum Einsatz kommen sollen zeigt das es ein generelles Problem ist.




Habe im CB Forum gelesen, dass nach Aussage von Su Zen noch das Potenzial für weitere 17% IPC-Steigerung bot laut den Ingenieuren. Wie viel da dran ist, k. A.

Wenn dem so ist, dürfte Zen+ mit einer Verbesserung der Fertigung und etwas mehr Taktspielraum, etwas händischer Hardwareoptimierung für die nächsten 4 Intel Generationen reichen ;D

Sehr schön, die 17% entsprächen etwa die auf der Folie von mir Überschlagenen knapp 20%. Damit würde man deutlich über Skylake kommen und bei bisherigen IPC-Verbesserungen bei neuen Intel Generationen den nächsten zwei überlegen (vier ist etwas übertrieben ;-) ). WOW, wer hätte das noch vor Zen gedacht bzw. für möglich gehalten :-)
 
Ich kann mich nur wiederholen: Wenn Pinnacle Ridge 2018 raus kommt, wird es mit Sicherheit kein großer Sprung, sondern nur ein nochmal überholter Summit Ridge.

Einen größeren Sprung dürfte man eher mit 7nm in frühestens 2019 erwarten.

Edit: Was ich von der nächsten Version erwarte:

  • IPC praktisch auf Summit Ridge Niveau, höchstens kleine Detailverbesserungen
  • Etwas mehr Takt/etwas weniger Strom
  • Besserer Memory Controller
  • Neue Data Fabric Version für deutlich geringere Latenzen
  • PCIe 4.0 statt PCIe 3.0
 
Zuletzt bearbeitet:
Verbesserungen könnte es auch beim SMT geben. Ein AMD Techniker meinte doch bei der Präsentation, dass bestimmte statische Ressourcenaufteilungen "nur in dieser Version" so implementiert seien. Das genaue Zitat finde ich nicht. Jedenfalls rechne ich hier mit etwas Feintuning.
 
naja, weil AMD gegen die Softwareinfrastruktur nicht ankommt, die für Intel gebaut wird. Wenn Intel AVX bietet und es genutzt wird, kann AMD es nicht ignorieren. Und wenn AMD was besseres anbietet, wird es nicht genutzt werden. Das übliche Problem.

Also wenn, dann muß die GPU "ganz normales" AVX können, sprich es darf für die Software gar nicht erkennbar sein, daß das gar keine Intel-CPU ist, sondern eine AMD-GPU.

Nicht wirklich Schaft man es für 128bit SSEE 4.2 optimierten bestehenden code auf den 128bit AVX Einheiten verarbeiten zu könne und genug von diesen anzubieten, kann das doch genauso effizient sein wir den code für avx 512 bit zu optimieren nur ohne diese Anpassung implementieren zu müssen. Da wirklich Performance benötigter code schon optimiert ist macht der von amd gewählten weg mehr Sinn, da sich wohl nutzer als auch AMD sich den Aufwand sparen können 128bit optimierter code mit 512 bit breiten ausführungseinheiten effizient und ohne unproduktive schaltenden Transistoren.


Dh amd versucht mit Zen eben gerade das Software Ökosystem sogut wie möglich auszunutzen, an den Stellen an welchen Geld für HW weniger wichtig ist als abgehangener code nicht in zu grossem Umfang ändern zu müssen. Ryzen ist da nur ein Abfallprodukt zur Markepflege. Und der Ansatz ist auch nur dazu da da wieder genug Marktanteil zu gewinnen damit die SWHersteller ein Anreiz haben auf AMD CPU genauso gut Performende Anwendungen zu liefern, wie sie es heute bei Intel tun. Damit dürfte AMD auch versuchen zu verhindern das sich viel SW auf AVX 512 anpasst womit sie warscheinlich auch langfristig verhindert werden soll das SW auf die Intels 512bit implementierung optimierten wird, womit HSA abheben nicht durch zu Herstellerspezifische implementierungen verhindert wird. Anwendungen welche heute um jeden Preis auf avx angepasst werden werden darunter weniger leiden denn da wird man auch wenn es vorteilhaft ist diese auf was auch immer von amd bringt angepasst werden, wenn es denn vorteilhaft ist.
 
Zurück
Oben Unten