AMD Zen - 14nm, 8 Kerne, 95W TDP & DDR4?
- Ersteller UNRUHEHERD
- Erstellt am
Das ist schon vor 2 Jahren ausgelaufen mit der Abnahmeverpflichtung, oder alternativen Strafzahlung. In den aktuellen Abkommen gibt es das nach meinem Kenntnisstand nicht mehr.
Ich denke die Kapazitäten bei Samsung sind ziemlich knapp was 14 Finfet angeht. Da läuft ja neben samsung selbst noch apple, bald qualcomm und wohl noch anderes vom band. Mit TSMC hatte AMD jedenfalls bisher keine Probleme. Bei Glofo kam seit 45nm nichts wirklich vollends überzeugendes mehr. vor allem 28nm, also ab umszellung auf Bulk ging ja gar nicht. Da haben sie 3 jahre lang dran rumgewurschtelt.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Quelle? In den ersten Verträgen stand was bis 2022 oder so, glaube kaum, dass sich das geändert hat.
Außerdem müsste man für TSMC erstmal anpassen und danach auch noch ne Maske gießen, d.h. Zen wäre automatisch mind. ein halbes Jahr zu spät. 2016 würde garantiert nicht mehr reichen.
Wäre jetzt höchstens die Frage, wie zeitig AMD das Problem GF auf dem Radar hatte. Wenn das schon vor ca. nem Jahr bekannt war, ok.
@Opteron
Kommt auch darauf an, wie man bei AMD geplant hat. Wenn man clever ist (und aus der Vergangenheit was gelernt hat), hat man frühzeitig auch in eine mögliche Ausweichstrategie investiert, um diesmal nicht wieder auf dem falschen Fuß erwischt zu werden.
Außerdem wäre es schlau, die IP auch für TSMC fertig zu basteln, damit man Kunden für Semicustom werben kann.
Kommt auch darauf an, wie man bei AMD geplant hat. Wenn man clever ist (und aus der Vergangenheit was gelernt hat), hat man frühzeitig auch in eine mögliche Ausweichstrategie investiert, um diesmal nicht wieder auf dem falschen Fuß erwischt zu werden.
Außerdem wäre es schlau, die IP auch für TSMC fertig zu basteln, damit man Kunden für Semicustom werben kann.
Effe
Redaktion
☆☆☆☆☆☆
Vielleicht hat Mr. Read ja doch noch sein Vermächtnis in Form von Doppelplanung bei beiden Chipbäckern. [/Speku]
Samsung wird seine Kapazitäten doch sicherlich ausbauen, da gab es doch eine Folie:
Fab8
Commander
- Mitglied seit
- 15.07.2012
- Beiträge
- 187
- Renomée
- 2
Samsung hat sicherlich bereits viel investiert, aber primaer um die eigenen Produkte mit 14nm chips zu versorgen und dann als Apple Partner noch deren Chips. GF hat wie bereits bekannt den 14nm Prozess von Samsung lizensiert, warum der nun bei GF nebest dem zugekauften IBM KnowHow in der Fab8 nicht gut funktionieren soll ist ein Raetsel.
Golem spekuliert das der A9 auch bei GF gebaut wird: http://www.golem.de/news/auftragsfe...hst-die-14-nm-lpp-produktion-1509-116547.html
Dresdenboy
Redaktion
☆☆☆☆☆☆
Dieses Bild ist unbrauchbar, da man darauf nichts erkennen kann....
Dresdenboy
Redaktion
☆☆☆☆☆☆
bschicht86
Redaktion
☆☆☆☆☆☆
Ob die 4x Decode auf 4-fach SMT hindeuten würden? Wenn ja, wär die FPU ja wieder nach dem Bulli-Prinzip. Je Kern nur 128bit.
Ich vermute mal: Das beste/optimale aus SMT und CMT
Bei Int-lastigen und bis zu 128bit FPU kann sich ein Zen-Kern um 4 Threads kümmern, soll die FPU breiter genutzt werden, sind es eben nur noch 2 Threads.
Oder man mischt 1x 256 FPU mit 2x 128 FPU
--- Update ---
Am interessantesten wird allerdings für mich sein, wie Zen mit der Außenwelt kommuniziert (PCI-E-Lanes, RAM-Kanäle, SATA, USB, etc.)
Ich vermute mal: Das beste/optimale aus SMT und CMT
Bei Int-lastigen und bis zu 128bit FPU kann sich ein Zen-Kern um 4 Threads kümmern, soll die FPU breiter genutzt werden, sind es eben nur noch 2 Threads.Oder man mischt 1x 256 FPU mit 2x 128 FPU
--- Update ---
Am interessantesten wird allerdings für mich sein, wie Zen mit der Außenwelt kommuniziert (PCI-E-Lanes, RAM-Kanäle, SATA, USB, etc.)
Zuletzt bearbeitet:
Das hat aber dann nichts mehr mit den Kernen zu tuen sonder sind das letztendliche Produkt.
Ich tippe mal darauf das man im Desktop Bereich auf einen integrierten, minimalen Chipsatz setzt (siehe Kabini) und den Rest per Zusatzchip zur Verfügung stellt.
Da der integrierte Teil im Multi CPU Part recht Nutzlos wäre tippe ich bei diesen Produkten auf eine klassische Chipsatz Lösung. Beim Arbeitsspeicher tippe ich Zeitpunkt bedingt auf DDR4 Speicher und hoffe im APU Bereich auf eine zusätzliche HBM Lösung.
Ich tippe mal darauf das man im Desktop Bereich auf einen integrierten, minimalen Chipsatz setzt (siehe Kabini) und den Rest per Zusatzchip zur Verfügung stellt.
Da der integrierte Teil im Multi CPU Part recht Nutzlos wäre tippe ich bei diesen Produkten auf eine klassische Chipsatz Lösung. Beim Arbeitsspeicher tippe ich Zeitpunkt bedingt auf DDR4 Speicher und hoffe im APU Bereich auf eine zusätzliche HBM Lösung.
cyrusNGC_224
Grand Admiral Special
Bedeutet das nun, dass ZEN AVX2 nicht so performant wie Haswell pro Thread abarbeiten kann?
Denn da hätte AMD doch Nachholbedarf gehabt.
Denn da hätte AMD doch Nachholbedarf gehabt.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Vollkommen wurst, wieviel AVX256-Programme gibts denn? Der Markt ist im Vergleich zu SSE128-Programmen klein, aber die profitieren - im Gegensatz zu Intel - von dem Design.
Das haben wir uns im Forum so schon gewünscht, mit SMT macht das ziemlich viel Sinn
Bulldozer kann pro Takt:
eine 256bit FMA Instruktion
zwei 128bit FMA Instruktionen
zwei 128 bit FMUL/FMADD Instruktionen
Intel kann pro Takt:
zwei 256bit FMA Instruktion
zwei 128bit FMA Instruktionen
zwei 128 bit FMUL/FMADD Instruktionen
Zen könnte:
ein oder zwei 256bit FMA Instruktion (nicht ganz sicher, müsst ich mal nochmal beim Bridge-Design nachlesen, eventuell bräuchte es für einen 256bit Instruktion eine "Quad-µOp", die es so bisher noch nicht gab)
zwei 128bit FMA Instruktionen
vier 128 bit FMUL/FMADD (je 2) Instruktionen (also alles vor AVX / bis SSE4.2)Für alten Code ist das also besser, da jeder SMT-Thread eine - im Vergleich zu früher - quasi vollwertige FPU exklusiv zur Verfügung hat.
Im nächsten Ausbauschritt (10nm) kann man das Design dann schön auf 4x256bit verdoppeln.
SMT4 könnte man machen, aber die 4 Decoder braucht man eher um 2 Doubles pro Takt generieren zu können. Das ist der Preis für die Flexibilität der FPU, man muss mehr in den Decoder investieren. Aber wenn man SMT2 hat, rentieren sich die Decoder eben auch für die 2 SMT-Threads pro Kern, das passt gut zusammen. BD hatte halt "leider" keine Bridge-FPU sondern richtige FMA-Pipes, d.h. der Maximaldurchsatz waren 2 128bit Instruktionen, egal ob FMA/FMUL/FADD), da rentierte sich ein breiter Decoder nicht so sehr, was dann vielleicht auch schlecht für die INT-Cluster war (die waren ja bei einer IPC von ~0,9 oft unterfordert).
Bisschen wenig wären die 2 Load/Store Units, Intel hat mit Haswell gerade erst ein 3. Store-Unit nachgelegt, aber naja superwichtig ists wohl nicht und AMD kann das später auch noch nachreichen.
Apropos: BDs AGLUs sind damit Geschichte ... das Design orientiert sich damit eher an den Katzenkernen (die hatten je eine Load oder Store Unit) bzw. auch Intel.
Ansonsten: Wenn ich das richtig sehe werden alle x87-Instruktionen nur noch als "Vector" also mit langsamen Microcode ausgeführt .. naja macht sicher nichts, x87 ist nun wirklich uralt. Zen zielt auf den Massenmarkt und dort gibts größtenteils SSE128-Code. Ist schon in Ordnung so.
gruffi
Grand Admiral Special
Eher nicht. Bulldozer hatte auch 4x Decode und es waren trotzdem nur 2 Threads pro Modul. Ich denke auch Zen wird maximal 2 Threads pro Kern unterstützen.
Nein, je Kern 2x 256-bit. Ist ja jetzt nur noch ein Kern, unabhängig von SMT.
Doch, bei 256-bit FADD und FMUL schon. Bei 256-bit FMA wäre es allerdings nur der halbe Durchsatz wie schon bei Bulldozer. Ich persönlich sehe das im Moment allerdings nicht so kritisch, wenn es dabei hilft, dass Zen schön sparsam bleibt. Haswell + Nachfolger sind bei 256-bit Workloads ja ganz schöne Hitzköpfe. Und FP Gefechte werden in Zukunft sowieso mehr und mehr mit GPUs gewonnen, Stichwort OpenCL, HSA, etc.
@Matthias
Danke für die Info. Schaut auf jeden Fall sehr vielversprechend aus und in etwa so, wie ich das erwartet hatte. Finde es auch sehr gut, dass man bei der FPU scheinbar den Fokus wieder mehr auf FADD und FMUL legt. Das hatte mir bei Bulldozers FPU nie so gefallen, dass da quasi immer die Hälfte an Potenzial brach lag.
Zuletzt bearbeitet:
Ich sehe da durchaus den Trend, die FPU ganz langfristig ganz abzuschaffen. Die GPU muß noch mehr Fähigkeiten bekommen, das ist klar, aber schon jetzt ist es ja so, daß die GPU immer vorhanden ist, entweder als APU oder in fetten PCs als Steckkarte. D.h. ein Softwareentwickler kann schon jetzt langfristig darauf bauen, daß er die GPU immer nutzen kann. Und allgemein ist es doch so, daß Workloads, die eine dicke FPU fordern würden, auf einer GPU prinzipiell noch besser laufen könnten.
Bei Zen muß die FPU noch vorhanden sein, aber muß eben keine neuen Wahnsinnsrekorde aufstellen, sondern nur gut genug sein für den vorhandenen Code. In der nächsten großen Architektur (also erst nach diversen Zen-Evolutionsschritten) kann man die FPU wohl weiter marginalisieren und letztlich ganz weglassen. Gibt keinen Grund, warum die GPU bis dahin nicht so flexibel gestaltet werden kann, daß sie die FPU 100%ig ersetzen kann.
Das ist jetzt sicherlich zehn Jahre weitergedacht oder noch mehr, aber würde mich nicht wundern, wenn es so kommt.
Bei Zen muß die FPU noch vorhanden sein, aber muß eben keine neuen Wahnsinnsrekorde aufstellen, sondern nur gut genug sein für den vorhandenen Code. In der nächsten großen Architektur (also erst nach diversen Zen-Evolutionsschritten) kann man die FPU wohl weiter marginalisieren und letztlich ganz weglassen. Gibt keinen Grund, warum die GPU bis dahin nicht so flexibel gestaltet werden kann, daß sie die FPU 100%ig ersetzen kann.
Das ist jetzt sicherlich zehn Jahre weitergedacht oder noch mehr, aber würde mich nicht wundern, wenn es so kommt.
cyrusNGC_224
Grand Admiral Special
Danke für die Erklärung.Vollkommen wurst, wieviel AVX256-Programme gibts denn? Der Markt ist im Vergleich zu SSE128-Programmen klein, aber die profitieren - im Gegensatz zu Intel - von dem Design.
Das haben wir uns im Forum so schon gewünscht, mit SMT macht das ziemlich viel Sinn
Bulldozer kann pro Takt:
eine 256bit FMA Instruktion
zwei 128bit FMA Instruktionen
zwei 128 bit FMUL/FMADD Instruktionen
Intel kann pro Takt:
zwei 256bit FMA Instruktion
zwei 128bit FMA Instruktionen
zwei 128 bit FMUL/FMADD Instruktionen
Zen könnte:
ein oder zwei 256bit FMA Instruktion (nicht ganz sicher, müsst ich mal nochmal beim Bridge-Design nachlesen, eventuell bräuchte es für einen 256bit Instruktion eine "Quad-µOp", die es so bisher noch nicht gab)
zwei 128bit FMA Instruktionen
vier 128 bit FMUL/FMADD (je 2) Instruktionen (also alles vor AVX / bis SSE4.2)Für alten Code ist das also besser, da jeder SMT-Thread eine - im Vergleich zu früher - quasi vollwertige FPU exklusiv zur Verfügung hat.
Im nächsten Ausbauschritt (10nm) kann man das Design dann schön auf 4x256bit verdoppeln.
Klar, für normale Software braucht man das nicht unbedingt.
Für spezielle schon.
Und im Server bzw. professionellen Markt soll ZEN ja auch Boden gut machen.
Das verfolgt AMD besonders bezüglich HSA schon lange, vermute ich.
Allerdings ist eine potente GPU eben nicht immer vorhanden und wenn, dann eben nur eine. Wie will z.B. eine GPU die FPU von 24 CPU Kernen ersetzen, wenn die alle ausgelastet sind (Server, HPC)?
Und was ist mit den Latenzen?
Werden gerade im HPC Bereich die CPUs nicht ohnehin gern mit dicken Grafikkarten kombiniert?
Da sehe ich eher weniger Probleme, im Zweifelsfall könnte man immernoch Cluster bilden und für eine bestimmte Anzahl an Kernen eine entsprechende GPU verbauen.
Da sehe ich eher weniger Probleme, im Zweifelsfall könnte man immernoch Cluster bilden und für eine bestimmte Anzahl an Kernen eine entsprechende GPU verbauen.
Das denke ich eher nicht, denn mit einer dGPU hast du immer die Latenzen des PCIe von ich glaub 1/2us (also im worst case eine FPU mit 2MHz). Wenn der Code jetzt nur eine handvoll FP-Ops braucht dürfte es wohl schon schneller sein, diese zu emulieren.
So wie es aussieht schient AMD bei den APUs auch wieder etwas mehr Abstand zwischen der CPU und GPU zu bringen. Interposer anstelle von single Chip Lösung. Und das dürfte auch wieder etwas mehr Latenzen mit sich bringen, auch wenn es weniger als PCIe sein werden.
Opteron
Redaktion
☆☆☆☆☆☆
- Mitglied seit
- 13.08.2002
- Beiträge
- 23.645
- Renomée
- 2.254
Ja, das war vermutlich dann auch mit ein ausschlaggebender Punkt, um sich beim CPU-Design (immer noch) auf 128bit zu konzentrieren.
Ne ZEN-APU ist dann eine gute Kombination
@OBrian:
Gänzlich überflüssig werden FPUs nie werden, wg. den Latenzen. Für Software, die man gut parallelisieren kann ist da egal, da stimmen Deine Argumente, aber das ist halt nicht immer der Fall. Allerdings sind immer längere Vektoren von anfangs MMX (64) -> SSE (128) und AVX (256 bald 512) ebenfalls von diesem Parallelisierungsgrad abhängig. Von daher machts schon Sinn, dass AMD das Rennen nicht mitmacht, da sie ne gute GPU dafür in der Hinterhand haben.
Lange Vektoren in einer relativ hochtaktenden CPU zu verarbeiten, stell ich mir auch nicht gerade ideal vor, außerdem kostet es auch viel Die-Fläche.
Da freu ich mich eher über ne bessere SMT-Auslastung.
