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

[OBrian]

Falls Zen sowas jedenfalls nicht hat, dann nur, weil es sich als unnötig erwiesen hätte, um die IPC noch weiter zu steigern. Zen ist ja von Grund auf komplett neu gebaut worden, d.h. keine Basis, an die hier und da immer weiter was drangebastelt wird. Kann ja sein, daß so ein µOp-Looping nicht sinnvoll ist, weil die die Abläufe ganz, GANZ anders organisiert haben. Keine Ahnung, man erfährt ja nix. Ich hatte gedacht, da gibt es mal eine fette Präsentation mit wirklich in die Tiefe gehenden technischen Erklärungen. Aber kommt ja vielleicht (hoffentlich) noch.

 

[Opteron]

Ich weiß leider nicht so recht ob man daraus etwas auf die Architektur von Zen ableiten kann aber es gab wohl gestern von AMD zwei Linux Kernel Patches für Zen. Scalable MCA und CLZERO. Falls jemand aus den Patches was heraus lesen kann: http://lkml.iu.edu/hypermail/linux/kernel/1510.3/03420.html

CLZero ist nichts Neues und MCA ist wohl irgendwas zur Diagnose:

Scalable MCA (SMCA) is a new feature in AMD Fam17h
processors which indicates presence of MCA extensions.

MCA extensions expands existing register space for the
MCE banks and also introduces a new MSR range to
accommodate new banks. Future additions to AMD MCE code
will first need to detect if SMCA is enabled before
enabling the new features.

MCA= Machine Check Architecture
MCE= Machine Check Exception

Bei den Vergleichen AMD Kontra Intel wird aber auch immer gerne vernachlässigt dass Intel in Sachen Fertigung meistens einen ganzen Node voraus ist.
Es ist eine Sache große Kerne designen zu wollen, aber sie mit gutem yield gefertigt zu bekommen, auf Takt zu kriegen und dann noch sowohl in Leistung wie bei den Kosten konkurrenzfähig zu sein ist eine ganz andere Geschichte.
Intel kann es sich leisten ein großes Design mit schlechtem yield zu fertigen, weil die Stückzahlen haben dass einem schwindelig wird. Im Klartext, die kleineren, leicht herzustellenden Kerne subventioneren die Monstren.

Ne wird nicht vergessen, im Zusammenhang damit hofft man aber auf die HDlibs, die den Nodevorteil teilweise egalisieren können.

I bezug auf µOp cache bin ich allerdings nicht opterons Meinung. ZEN hat sienen IPC-Vorsprung ja nicht durch Heinzelmännchen. Genau wie Intel sich die Höhere IPC nicht aus den Fingern saugt, ein µOp cache kann genau dazu beitragen. Gerade mit mehreren Threads auf einem Kern. Also her damit, das wäre schon bei BD überfällig gewesen um das Frontend zu entlasten (Und IMHO sinnvoller als die Frontent-Trennung bei Kaveri, aber was solls)

Klar wärs schön, ich bin auch für das Teil, das hatten wir anno dazumal ja ausdiskutiert. Ich meine nur, dass es nicht sinnvoll ist, das gleich einzubauen. Intel hatte SMT auch erstmal im Nehalem implementiert und den µOp-Cache erst bei Sandy gebracht. Man tut gut daran sich die Innovationen aufzuteilen, denn wer zuviel will, fällt ziemlich schnell auf die Nase. Genau das kann sich AMD aber aktuell nicht mmehr leisten, das Tafelsilber ist langsam aber sicher wirklich weg.

Ist auch die Frage, wieviel man von den bisherigen Designs 1:1 wiederverwerten kann. Beim µOp-Cache gehts ums Front-End. Die Kandidaten wären: a) Übernahme des BD-Front-Ends, b) Aufbrezeln des Cat-Frontends, c) Mischung aus beidem.

Bei a) Könnte man auf nen µOp-Cache hoffen, aber bei b)+ c) .. eher nicht.
Wobei bei a) auch noch das Problem aufträte, dass man fürs zweigleisige BD-Frontend wohl auch zwei µloop-Puffer bräuchte, was dann bei einer SMT-Architektur aber wieder Overkill wäre. Von daher geh ich von b oder c aus, und damit wirds wohl auch - vorerst - keinen µloop-Puffer geben

Das IPC-Plus sehe ich durch Standardkost ermöglicht. Der 14nm Prozess zusammen mit den HDLibs sorgt für ein großes Transistorenbudget. Da kann man alle internen Puffer ganz dick ausbauen, was sich wg. SMT doppelt rentiert. Intel macht seit Sandy fast auch nichts anderes. Halt - extra Pipelines wurden noch dazugeflickt, aber von denen hat Zen ja auch genügend.

@OBrian:
Naja ne, Caches sind im allgemeinen immer gut, kann mir nicht vorstellen, dass es ein x86-Design gäbe, wo man keinen µloop-Cache bräuchte.
Vielleicht bei nem direkt-verdrahtetem Design, dass die x86-Befehle nicht in µOps aufbricht, aber selbst da wärs nicht verkehrt die letzten paar Befehle zwischenzupuffern.
Der µOp-Cache sitzt halt schön zw. Frontend (L1-Cache) und Execution-Pipes (Register-Files), das ist schon ein guter Platz für ne weitere Cachestufe.

 

[Novasun]

Bei den Vergleichen AMD Kontra Intel wird aber auch immer gerne vernachlässigt dass Intel in Sachen Fertigung meistens einen ganzen Node voraus ist.

Im Moment ist das aber nicht der Fall. Skylake ist 14nm - Zen wird auch 14/16 nm. Ich weiß gar nicht, wann es zuletzt diesen Gleichstand in der Fertigung gab...

 

[ONH]

Im Moment ist das aber nicht der Fall. Skylake ist 14nm - Zen wird auch 14/16 nm. Ich weiß gar nicht, wann es zuletzt diesen Gleichstand in der Fertigung gab...

Kabylake sollte das doch heissen, in einem Jahr ist zwar nur ein Refresh, aber das war Richland ja quasi auch. Und im Moment ist es der Fall, voraussichtlich nächtes Jahr nicht mehr.
Wobei ja trotzdem 14nm nicht = 14/16nm ist.

 

[hoschi_tux]

Richtig, ist alles 20+nm.

 

[Dresdenboy]

Ne wird nicht vergessen, im Zusammenhang damit hofft man aber auf die HDlibs, die den Nodevorteil teilweise egalisieren können.

Bei der Dichte ja, Power vermutlich auch, aber Geschwindigkeit eben nicht. Dazu kommen noch die Metal Layers. Wobei Intel hier auch weg von den performanteren in den niedrigeren Lagen zu dichteren überging.

Klar wärs schön, ich bin auch für das Teil, das hatten wir anno dazumal ja ausdiskutiert. Ich meine nur, dass es nicht sinnvoll ist, das gleich einzubauen. Intel hatte SMT auch erstmal im Nehalem implementiert und den µOp-Cache erst bei Sandy gebracht. Man tut gut daran sich die Innovationen aufzuteilen, denn wer zuviel will, fällt ziemlich schnell auf die Nase. Genau das kann sich AMD aber aktuell nicht mmehr leisten, das Tafelsilber ist langsam aber sicher wirklich weg.

Das kann natürlich sein. Für den ersten Wurf kann man da mit einer Entscheidungsmatrix rangehen u. die Features entspr. Aufwand, Fläche, Performance oder Energieeffizienzgewinn sortieren.

Ein kleiner Loop Buffer ist eher drin und schon nützlich. Das lässt sich schon mit einer Queue zwischen den Decodern u. Dispatcher machen.

Ist auch die Frage, wieviel man von den bisherigen Designs 1:1 wiederverwerten kann. Beim µOp-Cache gehts ums Front-End. Die Kandidaten wären: a) Übernahme des BD-Front-Ends, b) Aufbrezeln des Cat-Frontends, c) Mischung aus beidem.

Das ist sicher auch eine Frage der Designmethode. Wieviel wird synthetisch erzeugt u. dabei optimiert, wieviele Blöcke werden noch von Hand gebaut usw.

Das IPC-Plus sehe ich durch Standardkost ermöglicht. Der 14nm Prozess zusammen mit den HDLibs sorgt für ein großes Transistorenbudget. Da kann man alle internen Puffer ganz dick ausbauen, was sich wg. SMT doppelt rentiert. Intel macht seit Sandy fast auch nichts anderes. Halt - extra Pipelines wurden noch dazugeflickt, aber von denen hat Zen ja auch genügend.

Interne Puffer bringen mit dem Wachstum aber Zeitprobleme (CAM, Priority Encoder u.ä.).

 

[Ge0rgy]

Okay, beantworten wir doch erstmal die Frage wie hohe IPC eigentlich zustande kommt.
Ich meine, wenn es einen Königsweg gäbe einfach so eine hochperformante CPU zu designen, hätte auch AMD ähnliches längst gemacht.
Eine IPC von um 1 herum scheint nicht allzu unwahrscheinlich / schwer zu sein, aber danach wirds interessant. Das Verhindern von Pipeline Bubbles und max. Auslastung. Da kann SMT zwar helfen aber ein loop buffer o.ä. eben auch, weil er den Decoder entlastet und damit einen potenziellen Flaschenhals aus dem system nimmt.
Es mag auch sein dass ZEN ein ordentliches Transistorbudget zur Verfügung hat, allerdings sollen ja auch ein paar Kernchen in einen Chip rein.
Dass man einen radikal anderen Weg geht bezweifle ich ebenfalls, das wre zu riskant, bewährtes ist angesagt. - Und da gibt es nunmal nicht so unglaublich fundamental andere Verfahren wie intel sie anwendet oder AMD das ind er Vergangenheit auch getan hat. Kurz gesagt, wenn Intel für Sandy Bridge effizient einen Loop buffer brauchte, ist es nicht anzunehmen dass AMD ähnliches "mal eben so" ohne derartige Kniffe stemmt.
Im übrigen, warum willst du 2 caches machen für 2 Threads, wenn du nur ein einzelnes Bit je Befehl speichern musst zur Kennzeichnung ob es ein Befehl für Thread 1 oder Thread 2 ist.

 

[Unbekannter Krieger]

Könnte AMD theoretisch Dr. Agner Fog und ähnliche Kapazitäten zur Unterstützung hinzuziehen? Ersterer nahm ja damals schon die ursprüngliche Bulldozer-Architektur auseinander.

Würde der erneute Einbau von FM4 die Architektur irgendwie negativ beeinflussen? Falls nicht, könnte AMD das Bewährte auch in Zen integrieren.

 

[Novasun]

Kabylake sollte das doch heissen, in einem Jahr ist zwar nur ein Refresh, aber das war Richland ja quasi auch. Und im Moment ist es der Fall, voraussichtlich nächtes Jahr nicht mehr.
Wobei ja trotzdem 14nm nicht = 14/16nm ist.

Doch ist das selbe. Zumindest die 14nm Samsung zu 16nm TMSC scheinen mehr oder minder gleich zu sein. Und ich wüsste nicht dass die 14nm Intel deutlich weiter wären als Samsungs Fertigung... Zumindest was die strukturbreite betrifft.

 

[Atombossler]

Summit Ridge und Raven Ridge in AIDA Changelog
Da müssten doch bald mal MoBos auftauchen.
... und so ein paar Leaks bzgl. Benches wären auch mal schön.

 

[LoRDxRaVeN]

Im Moment ist das aber nicht der Fall. Skylake ist 14nm - Zen wird auch 14/16 nm. Ich weiß gar nicht, wann es zuletzt diesen Gleichstand in der Fertigung gab...

Das ist einfach: Bei Bulldozer bzw. Sandy-Bridge. Beide in 32nm. Zuvor bei Shanghai ("K10.5") bzw. Nehalem in 45nm und zuvor bei Brisbane vs. Prescott, wenn ich es richtig in Erinnerung habe Das war in den letzten Jahren eigentlich immer so, dass AMD einige Quartale nach Intel ebenfalls den gleichen Node hatte - bis eben zu 22nm/Ivy Bridge.

 

[y33H@]

Und ich wüsste nicht dass die 14nm Intel deutlich weiter wären als Samsungs Fertigung... Zumindest was die strukturbreite betrifft.

Dann schau dir die Prozesse mal genauer an.

 

[genervt]

Dann schau dir die Prozesse mal genauer an.

Artikel zum Thema:
http://www.fool.com/investing/gener...samsungs-14-nanometer-transistors-compar.aspx

http://www.golem.de/news/fertigungstechnik-der-14-nanometer-schwindel-1502-112524.html

Intel wird Anfang 2017 mit der 10nm Produktion beginnen, dann wird die Konkurrenz gerade mal 14nm voll hochfahren. Von daher ist Intel schon noch ein ganzes Stück voraus. Aber es gibt ein Zeitfenster für einen Angriff.

 

[sompe]

Tausche lieber das "wird" gegen ein "will" aus denn angesichts der derzeitigen Lieferschwierigkeiten scheinen noch nicht einmal die 14 allso rund zu laufen, weshalb ich eher nicht damit rechne.

 

[Unbekannter Krieger]

@Atombossler

Summit Ridge und Raven Ridge in AIDA Changelog

http://www.planet3dnow.de/cms/20183-aida64-v5-50-veroeffentlicht/
30.09. gegen 30.10.

 

[Complicated]

Intel wird Anfang 2017 mit der 10nm Produktion beginnen, dann wird die Konkurrenz gerade mal 14nm voll hochfahren. Von daher ist Intel schon noch ein ganzes Stück voraus. Aber es gibt ein Zeitfenster für einen Angriff.

14nm sind bei Samsung schon längst hoch gefahren. Der A9 nutzt sowohl 14 nm Samsung als auch 16nm TSMC. Hier werden Rückstände postuliert die es so nicht gibt. Der nächste Fertigungsprozess ist nicht erst dran wenn der vorhergehende bewältigt wurde, sondern wird unabhängig vorangetrieben.

 

[tex_]

Einen Loop Buffer gibt es seit Steamroller und Jaguar. In Steamroller sind das bis zu 40 macro-Ops.

Seit Haswell sind das bei Intel auch lat Agner Fog auch ca. 30-40 µOps, vorher waren es maximal 28. Mit SMT halbiert sich das allerdings pro Thread noch mals. Der µOP Cache fasst um die 1000 µOps und kann bis zu 32 Byte Code liefern, während die Decoder nur 16 Byte Code liefern können.

Bei Jaguar konnte Agner Fog allerdings überhaupt keine Performance Verbesserungen bei kleinen Schleifen messen. Das wird denke ich daran liegen, dass der Fetch und die Decoder bei Jaguar überhaupt keinen Flaschenhals darstellen. Daher würde hier auch ein µOP Cache nichts bringen, außer vielleicht etwas Energie zu sparen, aber der Cache ist auch nicht kostenlos.
Wenn Zen jetzt ein verdoppeltes Jaguar Frontend haben sollte, würde das denke ich genauso für ein 4wide Design reichen. Bei Steamroller dagegen hat der Loop Buffer etwas gebracht, aber hier ist auch der Fetch Durchsatz und die Decoder Latenz in manchen Fällen extrem zusammengebrochen. Diese Probleme wurden beim Jaguar nicht festgestellt. Bei Intel kann manchmal auch der Frontend Durchsatz etws einbrechen (mit langen Instruktionen und vielen Prefixes) aber nicht so stark wie bei Bulldozer.

Bevor man also jetzt noch größere Loop Buffer und Caches einbaut, müsste man wohl auch erst mal die Dispatchrate auf mehr als 4 makro ops erhöhen. Und dann stellt sich natürlich noch die Frage ob die Execuation Pipes da mithalten können oder die nicht vorher schon blockieren.

 

[cyrusNGC_224]

@Atombossler

http://www.planet3dnow.de/cms/20183-aida64-v5-50-veroeffentlicht/
30.09. gegen 30.10.

Da stand aber noch nichts von Summit- und Raven Ridge!

 

[Novasun]

Das ist einfach: Bei Bulldozer bzw. Sandy-Bridge. Beide in 32nm. Zuvor bei Shanghai ("K10.5") bzw. Nehalem in 45nm und zuvor bei Brisbane vs. Prescott, wenn ich es richtig in Erinnerung habe Das war in den letzten Jahren eigentlich immer so, dass AMD einige Quartale nach Intel ebenfalls den gleichen Node hatte - bis eben zu 22nm/Ivy Bridge.

Dein Vergleich hinkt. Bulldozer kam 1 Jahr später in 32 nm.
Da hatte Intel bereits ein Jahr zwei Produkte (Arrandale/Clarkdale seit Januar 2010!) in 32nm am laufen. Sandy war bereits die neu Itteration.

P.S.: eigentlich waren es zwei Jahre - erste FX Prozzi in 32 nm wurden vorgestellt im Oktober 2011.

Wenn AMD nun Ende dieses Jahres nachzieht wäre man kein Jahr mehr entfernt. Aber dazu muss AMD erst mal zeigen das Sie wirklich soweit sind.
Ich wünschen den grünen Jungs alles, dass es klappt. Bin aber inzwischen sehr skeptisch und kritisch [ich kann z. B. noch immer nicht ab, dass Furry als Overclockerdream bezeichnet wurde - ich hatte ja gehofft, dass die den VCore lock irgendwann lösen und dann das Teil wirklich mehr hergibt - aber inzwischen bin ich mir sicher das kommt nicht - da geht einfach nicht mehr].

 

[Unbekannter Krieger]

Da stand aber noch nichts von Summit- und Raven Ridge!

Verzeihung! Da ließ ich mich von den vermeintlich bedeutenden Ziffern der Versionsnummer blenden.

Ich wünschen den grünen Jungs alles, dass es klappt.

Die dürften mittlerweile komplett auf Rot (plus Schwarz und Weiß) umgestellt haben. Kennst du noch irgendein grünes Logo/Kennzeichen/... von AMD?

ich kann z. B. noch immer nicht ab, dass Furry als Overclockerdream bezeichnet wurde

Ernst gemeinte Frage: War der Wortlaut "Fury is" oder "Fiji is"? Es könnte von Bedeutung sein.

 

[sompe]

P.S.: eigentlich waren es zwei Jahre - erste FX Prozzi in 32 nm wurden vorgestellt im Oktober 2011.

Und der Llano kam bereits im Juni...

 

[OBrian]

naja, je länger die Intervalle werden, sprich je länger man mit einem Fertigungsprozeß auskommen muß, desto eher überlappen sich die nominellen Nodes von Intel und den anderen. Aber da sowieso jeder seinen eigenen Fertigungsprozeß immer weiter individualisiert, ist so ein Vergleich auch zunehmend unwichtig bis gar irreführend. Früher war eben z.B. 0.35 µm bei allen praktisch gleich, außer der Strukturgröße gab es ja keine anderen Kriterien.

 

[Opteron]

Bei der Dichte ja, Power vermutlich auch, aber Geschwindigkeit eben nicht. Dazu kommen noch die Metal Layers. Wobei Intel hier auch weg von den performanteren in den niedrigeren Lagen zu dichteren überging.

Geschwindigkeit=Takt? Ja, der würde natürlich etwas leiden, allerdings wird der in der letzten Zeit sowieso nicht voll ausgefahren. Oder wieviel mehr takteten die 22nm CPUs ggü. den 32nm? Bei 14 <> 22nm auch nicht viel anders. Statt den Takt zu erhöhen, verkleinert man die TDP.

Das kann natürlich sein. Für den ersten Wurf kann man da mit einer Entscheidungsmatrix rangehen u. die Features entspr. Aufwand, Fläche, Performance oder Energieeffizienzgewinn sortieren.

Ja wird man sicher gemacht haben. Mal schauen, was dabei rauskam, irgendwann werden wirs sicher wissen

Ein kleiner Loop Buffer ist eher drin und schon nützlich. Das lässt sich schon mit einer Queue zwischen den Decodern u. Dispatcher machen.

Ja anscheinend hat Steamroller ja schon sowas, wenn auch nur ausreichend für vier x86 Instruktionen in einem Takt, laut Agner Fog. Dachte bisher nur, dass das ne Queue sei, ohne caching Funktion, aber naja, sicher besser als nix. Von daher würde sich dann auch die Wahrscheinlichkeit für Zen erhöhen, wenn mans schon bei Steamroller hatte.
Vielleicht als Alternative zu Intel µOp-Cache+loop-buffer einen mittelgroßen Loop-Buffer? So nen µOp-Cache einzubauen stell ich wir immer noch zu kompliziert vor.

Interne Puffer bringen mit dem Wachstum aber Zeitprobleme (CAM, Priority Encoder u.ä.).

Ja, aber die Zeitprobleme werden mit jedem Shrink ja kleiner und meine ursprüngliche Argumentation war, dass man sich wg. 14nm Einiges mehr leisten können wird
Im Vergleich zu den 28nmm Cats wird der Sprung sicher noch größer, da die eher spartanische Puffer hatten, nicht die maximal Möglichen.

Okay, beantworten wir doch erstmal die Frage wie hohe IPC eigentlich zustande kommt.
Ich meine, wenn es einen Königsweg gäbe einfach so eine hochperformante CPU zu designen, hätte auch AMD ähnliches längst gemacht.

Wenn sies könnten --- ja
Wobei: Mit vielen Threads, FMA-Code und bei 5 GHz war Bulldozer ja durchaus performant
Aber das ist blöderweise halt nicht immer der Fall

Eine IPC von um 1 herum scheint nicht allzu unwahrscheinlich / schwer zu sein, aber danach wirds interessant. Das Verhindern von Pipeline Bubbles und max. Auslastung. Da kann SMT zwar helfen aber ein loop buffer o.ä. eben auch, weil er den Decoder entlastet und damit einen potenziellen Flaschenhals aus dem system nimmt.
Es mag auch sein dass ZEN ein ordentliches Transistorbudget zur Verfügung hat, allerdings sollen ja auch ein paar Kernchen in einen Chip rein.

Na da stimm ich überall überein, Frage ist halt nur, ob man sich in nem ersten Schritt damit begnügt, die vielen Transistoren nur mit 2 Threads max. auszulasten, oder ob man auf Risiko geht und per µOp-Cache auch noch die IPC steigern will. Bei nem komplett neuem Design würd ich als Designer eher auf Nummer Sicher gehen, gibt ja so schon genug Bugmöglichkeiten.

Dass man einen radikal anderen Weg geht bezweifle ich ebenfalls, das wre zu riskant, bewährtes ist angesagt. - Und da gibt es nunmal nicht so unglaublich fundamental andere Verfahren wie intel sie anwendet oder AMD das ind er Vergangenheit auch getan hat. Kurz gesagt, wenn Intel für Sandy Bridge effizient einen Loop buffer brauchte, ist es nicht anzunehmen dass AMD ähnliches "mal eben so" ohne derartige Kniffe stemmt.

Naja, AMD hat halt das deutlich breitere Design und alle wichtigen Pipes gibts Doppelt. Ab 3fach superskalar nimmt der Gewinn zwar stark ab, aber schaden wird ein breites 4fach Design der single-thread Leistung sicher nicht
Gegenüber Intel könnte AMD noch an den L1 oder L2-Größen drehen. Hatte auf 64+512 gehofft, aber jetzt werden es halt dann 32+512. Immerhin besser als nichts, solange die 512 kB schön schnell angebunden sind und die Assoziativität passte, wärs immerhin schon mal doppelt soviel wie bei Intel.

Im übrigen, warum willst du 2 caches machen für 2 Threads, wenn du nur ein einzelnes Bit je Befehl speichern musst zur Kennzeichnung ob es ein Befehl für Thread 1 oder Thread 2 ist.

Die Überlegung dahinter war, so nah wie möglich am Steamroller-Front-End zu bleiben, um die Bugwahrscheinlichkeit gering zu halten.
Natürlich kann man das sicher auch anders lösen, aber je mehr man verändert, desto höher ist das Risiko. Immerhin - loop-Puffer gibts ja schon, vielleicht würds reichen die zu vergrößern/verbessern. Mit nem großen µOp-Cache wie bei Intel ab SandyB rechne ich nicht.

Einen Loop Buffer gibt es seit Steamroller und Jaguar. In Steamroller sind das bis zu 40 macro-Ops.

...pro INT-Cluster, die gibts 2x laut Agners OptimierungsPDF. Danke auch für den Hinweis, da müssen wir aufpassen, dass wir µOp-Cache und Loop-Puffer nicht in einen Topf werfen, und dann gibts da auch noch unterschiedliche Implementierungen ..

Bei Jaguar konnte Agner Fog allerdings überhaupt keine Performance Verbesserungen bei kleinen Schleifen messen. Das wird denke ich daran liegen, dass der Fetch und die Decoder bei Jaguar überhaupt keinen Flaschenhals darstellen. Daher würde hier auch ein µOP Cache nichts bringen, außer vielleicht etwas Energie zu sparen, aber der Cache ist auch nicht kostenlos.

Ne das liegt daran, dass der Loop-Cache bei Jaguar ein Witz ist. Das ist nur ein besonderer Teil im L1I-Cache. Wenn eine Schleife erkannt wird, dann spart man sich die Abfrage der anderen Bänke im L1I-Cache und spart dammit auch ein paar Microwatt Energieverbrauch. Da der "Puffer" aber eben nichts Neues ist, sonder wie alle andere Daten auch aus dem L1I-Cache kommen, kann man da keine Leuistungsunterschiede messen.

Wenn Zen jetzt ein verdoppeltes Jaguar Frontend haben sollte, würde das denke ich genauso für ein 4wide Design reichen. Bei Steamroller dagegen hat der Loop Buffer etwas gebracht, aber hier ist auch der Fetch Durchsatz und die Decoder Latenz in manchen Fällen extrem zusammengebrochen. Diese Probleme wurden beim Jaguar nicht festgestellt. Bei Intel kann manchmal auch der Frontend Durchsatz etws einbrechen (mit langen Instruktionen und vielen Prefixes) aber nicht so stark wie bei Bulldozer.

Hmmm da ist dann die Preisfrage, an was diese Einbrüche lagen. Vermutlich gabs da Taktoptimierungen beim BD, die sich in Spezialfällen rächen. Macht ja auch nen Unterscheid, ob ein Decoder noch bei 5 GHz arbeiten können soll oder nur bei ~2 GHz. Mal schauen wies dann bei Zen aussieht, aber generell gibts imer wenig Infos zu den Decodern das ist ne ziemliche Geheimniskrämerei.

Bevor man also jetzt noch größere Loop Buffer und Caches einbaut, müsste man wohl auch erst mal die Dispatchrate auf mehr als 4 makro ops erhöhen. Und dann stellt sich natürlich noch die Frage ob die Execuation Pipes da mithalten können oder die nicht vorher schon blockieren.

Siehe oben, nachdem AMD da einen breiten Mittelbau mit doppelter Anzahl von Standardpipes hat, könnte die Exec. Unit schon mehr als 4 (Standard)MacroOps verarbeiten.

 

[miriquidi]

...pro INT-Cluster, die gibts 2x laut Agners OptimierungsPDF. Danke auch für den Hinweis, da müssen wir aufpassen, dass wir µOp-Cache und Loop-Puffer nicht in einen Topf werfen, und dann gibts da auch noch unterschiedliche Implementierungen ..

Wo ist da der Unterschied?

 

[tex_]

Geschwindigkeit=Takt? Ja, der würde natürlich etwas leiden, allerdings wird der in der letzten Zeit sowieso nicht voll ausgefahren. Oder wieviel mehr takteten die 22nm CPUs ggü. den 32nm? Bei 14 <> 22nm auch nicht viel anders. Statt den Takt zu erhöhen, verkleinert man die TDP.

Nicht unbedingt. Beim Maximaltakt läuft man irgendwann in Grenzen, aber durch niedrigere Pfadlaufzeiten kann man auch deutlich mehr komplexere Logik bei gleichem resultierenden Takt verbauen.

Ne das liegt daran, dass der Loop-Cache bei Jaguar ein Witz ist. Das ist nur ein besonderer Teil im L1I-Cache. Wenn eine Schleife erkannt wird, dann spart man sich die Abfrage der anderen Bänke im L1I-Cache und spart dammit auch ein paar Microwatt Energieverbrauch. Da der "Puffer" aber eben nichts Neues ist, sonder wie alle andere Daten auch aus dem L1I-Cache kommen, kann man da keine Leuistungsunterschiede messen.

Ok das, dass unterschiedliche Implementierung sind war mir nicht bewusst. Laut Realworldtech ist der Loopbuffer bei Jaguar zwischen Fetch und Decoder auf Instruction Buffer Ebene. Da Jaguar aus dem L1I sogar noch 32B fetched ist auch klar warum das keine Performance bringt. Aus dem Instruction Buffer werden dann aber nur noch 16B geholt (+6B des nächsten um schlechtes alignmend auszugleichen). Da die Decoder in Jaguar ihren Durchsatz gut halten können, würde ein Loop Cache mit 2 Makro Ops vermutlich aber auch wieder nichts außer den Decoder abschalten zu können. Ist die Frage was dann mehr verbraucht.

Hmmm da ist dann die Preisfrage, an was diese Einbrüche lagen. Vermutlich gabs da Taktoptimierungen beim BD, die sich in Spezialfällen rächen. Macht ja auch nen Unterscheid, ob ein Decoder noch bei 5 GHz arbeiten können soll oder nur bei ~2 GHz. Mal schauen wies dann bei Zen aussieht, aber generell gibts imer wenig Infos zu den Decodern das ist ne ziemliche Geheimniskrämerei.

Taktoptimierung werden sicher der ursprüngliche Grund sein. Wenn Jaguar aber alles in einem Takt dekodiert und bei Steamroller manche Präfixes zu 20 Takten Wartezeit führen, dann scheint sich das nicht wirklich zu lohnen. Da würde ich fast eher zu tendieren die Dekoder nur mit halben Takt laufen zu lassen und da die Dekoder im Jaguar deutlich kleiner sein dürften könnte man wahrscheinlich auch gleich doppelt so viele benutzen. Ein anderes Problem bei Steamroller ist immer noch, dass die Instruktionen im 32B window immer sehr gut aligned sein müssen, sonst bekommt man wenns doof läuft aus dem fetch nur eine einzige Instruktion raus.
Sowas findet man eben leider erst durch genaue Tests wie die von Agner Fog heraus...

Siehe oben, nachdem AMD da einen breiten Mittelbau mit doppelter Anzahl von Standardpipes hat, könnte die Exec. Unit schon mehr als 4 (Standard)MacroOps verarbeiten.

Theoretisch könnte man mehr Macro Ops auf die Pipes verteilen (wenn die Dispatch Rate höher wäre), aber wenn die Macro Ops alle voneinander abhängen kann man trotzdem immer nur eine Pipe füllen bevor es in der Execution weiter geht. Und wenn z.b. mehrere IMUL kommen müssen die auch nacheinander auf einer einzigen Pipe verarbeitet werden. Da sind aber schon durch die serielle Software eben gewisse Grenzen gesetzt die man nicht durch mehr Hardware parallele überwinden kann.

Auch interessant ist folgender Kommentar von Agner Fog.

An alternative to caching ?ops is to mark instruction boundaries in the instruction cache.
This relieves the critical bottleneck of instruction length decoding. Most AMD processors use this method, and it was also used in Intel's Pentium MMX processor.

Seit dem Pentium MMX macht das Intel allerdings nicht mehr und auch Bobcat und Jaguar verzichten darauf und führen stattdessen wie Intel eine PreDecode Stufe vor dem eigentlich Decode durch.

Wo ist da der Unterschied?

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.