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

[gruffi]

Naja, bei ein paar halt dann aber doch ... da ist ein alter Sandy 6core manchmal schneller als ein 1150-Haswell.

Du meinst vermutlich 6-Kern Ivy Bridge. Der ist im Schnitt vielleicht gerade mal 5% schneller als ein 4-Kern Ivy Bridge in Spielen. Und das meiste davon kommt wohl von den zusätzlichen Kernen als vom L3. Daher, vernachlässigbar. Das ist den Aufwand eines grossen L3 Caches absolut nicht wert. Wie gesagt, da kann das Transistorbudget besser in zusätzliche Ausführungseinheiten investiert werden. Selbst wenn man keine höhere Performance anstrebt, so kann man zumindest dadurch die Taktraten verringern, um die Effizienz zu verbessern.

Wolltest Du nicht gerade 1MB L2?

1 MB L2 ist nicht gross. Erst recht in 14nm.

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.

Nein. Typisch für einen 1 MB L2 Cache wäre, wenn erst oberhalb von 1 MB die Latenz deutlich ansteigen würde. Laut dem Diagramm steigt sie aber schon vorher an. Ich würde in das Diagramm daher nicht zu viel hinein interpretieren. Wer weiss, was und wie da getestet wird. Von L1 zu L2 gibt's da auch so komische Zwischenschritte, was eigentlich nicht sein darf. Fakt ist, dass beim A8 der L2 physisch getrennt ist, während der L2 beim A7 noch einheitlich war. Richtig verrückt wird's beim A8X, wo es zwei 1 MB L2 Caches für drei Kerne gibt. Ob und was da geshared wird und auf wie viel L2 jeder Kern zugreifen kann, ist mir daher noch unklar. Offensichtlich liegt die Kapazität aber irgendwo zwischen 512 KB und 1 MB pro Kern. Und das würde ich auch bei Zen und K12 erwarten.

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

512 KB sollten es trotzdem mindestens sein. Weniger ist einfach zu wenig. An der falschen Stelle sollte man auch nicht sparen.

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.

Das ist aber auch ein Serverdesign. Ob Client-Designs L3 Cache bekommen, ist unklar. Bisher hatten sie jedenfalls keinen L3. Und dann braucht man ausreichend L2. Das spricht eher für einen grösseren L2.

Vielleicht bekommt ZEN deswegen wie die Katzenkerne nur 32kB L1?

Wer sagt das? Und selbst mit einem 32 KB L1D ist ein 512 KB L2 nicht zu viel.

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

Doch, das ändert sehr wohl was. Wenn es keinen L3 Cache gibt, dann kann der L3 auch kein Victim Cache sein. Ist logisch, oder? Cat sollte man aber nicht in einen Topf mit Zen werfen. Cat hatte andere Vorgaben.

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.

Fragt sich nur, ob sich der Aufwand für die paar Prozent im Endeffekt lohnt. Man hat's ja bei Bulldozer's CMT gesehen. Tolles Konzept, aber recht komplex in der Umsetzung und daher sehr risikoreich. Vermutlich macht es heutzutage mehr Sinn, für entsprechende Märkte speziell zugeschnittene aber einfach umzusetzende Designs zu entwickeln. TTM heisst das Zauberwort. Was nützt das tollste Konzept, um vielleicht 20% rauszukitzeln, wenn der Konkurrent schon mit einem Nachfolger am Start ist, der durch Architekturverbesserungen, Prozessverbesserungen und dergleichen mehr zulegt? Schnelle und speziell anzupassende Designs ist ja auch der Gedanke hinter AMDs Semi-Custom Plänen. Und auch ARM geht mit ihren big.LITTLE Kernen schon länger diesen Weg.

 

[Opteron]

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.

Ne, da bist Du auf dem Holzweg. Der Compiler kennt nur die Architekturregister. Die Schattenregister dagegen liegen für ihn im Dunkeln, die sieht er nicht, deswegen heißen die auch so.
Der generierte Code läuft ja sowohl auf InO-Kernen als auch OoO-Maschinen. Schattenregister sind ein typisches Merkmal für OoO. Schlicht und ergreifend weil man die Befehle außerhalb der Compilerreihenfolge ausführt, teilweise auch noch spekulativ - braucht man mehr Register, als die jeweilige Architektur vorsieht. Natürlich könnte man die Registerzustände wieder aus dem Ram /Cache landen, aber das wäre in dem Zusammenhang schnarchlangsam, die Schattenregister sind quasi ne Art Cache, die die Registerzustände konservieren.

Wenn man jetzt SMT auf einem OoO-Kern betreibt, sinkt logischerweise die Anzahl der Schattenregister pro Thread, d.h. es kann auch weniger gut spekulativ gerechnet werden und weniger Befehle können parallel bearbeitet werden, d.h. die IPC sinkt, da der OoO-Vorteil geringer wird. Deswegen finde ich Morphcore ganz praktisch, dass OoO dann gleich ganz abschaltet.

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.

Ja OoO war v.a. auch bei x86 ab dem PentiumPro so erfolgreich, da damit der x86 Nachteil der wenigen Register kaschiert werden konnte. Die acht x86-Register sind ja nix, RISC Maschinen boten meistens 32.

AMD hats mit AMD64 dann wenigstens auf 16 erweitert, eben weil 8 lächerlich wenig sind.

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.

Jupp gegen Bobcat konnten sie keinen Stich machen, aber SMT brachte bei den Teilen schon +50% Rechenleistung im Multithreadbetrieb, also mehr als bei den OoO-Kernen, wo man meist um die 30% mehr bekommt. SMT und InOrder hat also schon Potential ...

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.

Ja könnten sie, aber dadurch, dass es jetzt 4er-Gruppen werden sollen, scheint AMD die Katzen-XBAR zu verwenden, denn bei den XBox/PS4-APUs ist es genauso gelöst, da gibts 2x4 Kerne.

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.

Hmm das kapier ich nicht, das ist doch viel einfacher. Entweder Du hast ne Applikation, die wenig Threads hat, dann wirst Du einen QuadCore nur mit 4 Threads und OoO befeuern. Oder Du hast ne Menge paralleler Arbeit, z.B. Beim Encoding, Rendern oder sonstwas, also viele Threads, dann nimmt man SMT und lässt 32 Threads auf die 4 Kerne los.

--- Update ---

Du meinst vermutlich 6-Kern Ivy Bridge. Der ist im Schnitt vielleicht gerade mal 5% schneller als ein 4-Kern Ivy Bridge in Spielen. Und das meiste davon kommt wohl von den zusätzlichen Kernen als vom L3. Daher, vernachlässigbar. Das ist den Aufwand eines grossen L3 Caches absolut nicht wert. Wie gesagt, da kann das Transistorbudget besser in zusätzliche Ausführungseinheiten investiert werden. Selbst wenn man keine höhere Performance anstrebt, so kann man zumindest dadurch die Taktraten verringern, um die Effizienz zu verbessern.

Jojo, im Schnitt ist es selbstverständlich nicht viel, sind nur "nette" Ausreißer. Ein Design nur danach auszurichten macht deshalb keinen Sinn, da hast Du schon recht. Wäre aber halt nur "nice to have".

1 MB L2 ist nicht gross. Erst recht in 14nm.

Ich verstehe "groß" im Verhältnis zur Logikfläche, unabhängig vom Herstellungsprozess. Da wurde Cache gerade erst "größer", schau Dir mal die 1MB Cache der K8 im Verhältnis zu den 1MB bei Carrizo an. Durch die HDLibs braucht man für Logik noch weniger Platz, auf Caches dagegen hat das keine Auswirkung.
D.h. bei weniger großen Caches bekommt man noch mehr Kerne unter als in früheren Zeiten.

Nein. Typisch für einen 1 MB L2 Cache wäre, wenn erst oberhalb von 1 MB die Latenz deutlich ansteigen würde. Laut dem Diagramm steigt sie aber schon vorher an. Ich würde in das Diagramm daher nicht zu viel hinein interpretieren. Wer weiss, was und wie da getestet wird.

Ja ab 800 ist etwas früh, lässt sich aber auch einfach durch den L1 des 2. Cores erklären. Wenn der auch im L2 vorliegt, nützt es dem ersten Thread natürlich auch nichts. Wenn ich mich recht erinnere, dann gabs das gleiche Verhalten auch bei den alten S775-Intels, dort stiegen die Latenzen auch schon knapp vor der absoluten Grenze an, halt der Tribut dafür, wenn man einen Cache gemeinsam benutzt.
Eindeutig ist aber, dass die Latenzen noch lange über der 512kB Grenze niedrig bleiben, ergo kanns kein 512 kB Cache sein. Auch Programmierfehler scheiden für Erklärungsfehler aus, denn Allokierungsfehler genau zw. 512 und 1024MB sind arg unwahrscheinlich, das wird sicherlich in ner Schleife laufen, die einen festen Betrag addiert.

Von L1 zu L2 gibt's da auch so komische Zwischenschritte, was eigentlich nicht sein darf.

Was genau meinst Du da?

Fakt ist, dass beim A8 der L2 physisch getrennt ist, während der L2 beim A7 noch einheitlich war.

Wieso ist das Fakt? Hast Du Fakten/Unterlagen? Dann raus damit, dann glaub ichs auch. Einen etwaigen Programmierungsfehler lass ich nicht gelte, solange Du überhaupt nichts vorweisen kannst.

Und das würde ich auch bei Zen und K12 erwarten.

Ok ist notiert, warten wir mal ab, wer am Ende recht hat

Das ist aber auch ein Serverdesign. Ob Client-Designs L3 Cache bekommen, ist unklar. Bisher hatten sie jedenfalls keinen L3. Und dann braucht man ausreichend L2. Das spricht eher für einen grösseren L2.

Tja, aber wir reden doch gerade vom Serverdesign, oder nicht? Du kannst doch jetzt nicht argumentieren, dass das Serverdesign einen größeren L2 bekäme, da dies für ein L3-loses Desktop-Design Sinn machen würde. Das sind 2 Paar Stiefel.

Wer sagt das? Und selbst mit einem 32 KB L1D ist ein 512 KB L2 nicht zu viel.

Reine Spekulation meinerseits, angefangen bei den 4er Gruppen mit L3 und der inclusive Caches bei den Katzen. Wie Du schon sagst wären von 256 L2 mit 64kB inclusiven Caches nicht mehr viel übrig ... deswegen könnte man sich eben mit 32kB begnügen. Ausgleichen könnte man das wieder etwas mit einer steigenden Assoziativität, macht Intel ja auch, mit 32 kB 8fach assoziativ sollte man höhere Hitraten erreichen als mit 64kb 2fach assoziativ, zumindest nach der üblichen Faustformel: Doppelte Assoziativität == Doppelte Cachegröße.

Doch, das ändert sehr wohl was. Wenn es keinen L3 Cache gibt, dann kann der L3 auch kein Victim Cache sein. Ist logisch, oder?

Natürlich nicht, aber bei den K10 ohne L3 war halt der L2 der VictimCache des L1 .. das meinte ich damit. Funktional macht es keinen Unterschied welchen Cachelevel man nun hat inclusive ist immer was anderes als exclusive. Bisher waren die Katzen inclusive und der L3 mit halben Takt recht langsam, entweder setzt man jetzt auf vollen Takt, oder man führt nen neuen Cachelevel dazwischen ein, der dann aber auch inclusive werden dürfte -- wenn man nicht zuviel am Design verändern wollte.

Fragt sich nur, ob sich der Aufwand für die paar Prozent im Endeffekt lohnt. Man hat's ja bei Bulldozer's CMT gesehen. Tolles Konzept, aber recht komplex in der Umsetzung und daher sehr risikoreich.

Jaein, BD kam ja so wie geplant, größere Bugs gabs keine, der Leistungsgewinn unter Mth war auch beachtlich, sch...lecht war nur die single Thread Leistung (und vielleicht noch der Stromverbrauch).

Vermutlich macht es heutzutage mehr Sinn, für entsprechende Märkte speziell zugeschnittene aber einfach umzusetzende Designs zu entwickeln. TTM heisst das Zauberwort. Was nützt das tollste Konzept, um vielleicht 20% rauszukitzeln, wenn der Konkurrent schon mit einem Nachfolger am Start ist, der durch Architekturverbesserungen, Prozessverbesserungen und dergleichen mehr zulegt? Schnelle und speziell anzupassende Designs ist ja auch der Gedanke hinter AMDs Semi-Custom Plänen. Und auch ARM geht mit ihren big.LITTLE Kernen schon länger diesen Weg.

Das ist richtig -- für semicustom-Kunden, die in der Regel dann auch selbst für Ihre Maschinchen programmieren.
In der großen weiten x86-Welt dagegen gibts das nicht, oder wieviel x86-Code gibts im Vergleich zu HSA-Code?

Verbesserungen und sogar gleich 20%(!) sind im x86-Markt immer gerne gesehen. Wenns anders wäre, hätten wir im Forum ansonsten noch nen Athlon XP unterm Tisch

 

[tex_]

SMT bringt aber bekanntlich nur etwas wenn die Software die vorhandenen ALUs und AGUs nicht auslasten kann. Dann kann man eben wenigstens einen 2. Thread mit den vorhandenen Ressourcen arbeiten lassen.
Wenn man nun OoO abschaltet wird man die Recheneinheiten nicht mehr sehr gut auslasten können, nur um dann mit einen 2. Thread zu versuchen die Auslastung wieder zu erreichen...
Ich glaube auch kaum, dass mit 8 in-order Threads der Kern viel besser ausgelastet werden kann als mit einer OoO Engine. Wenn 8 Threads in-order einen speicherbefehl ausführen wollen limitiert das trotzdem den gesamten Kern, während die OoO Engine jetzt vielleicht 4 Arithmetik Befehle vorziehen würde.
Ein derartiger Core kann nur sinnvoll funktionieren, wenn es mit OoO nicht mehr möglich ist die vielen Pipelines auszulasten, aber dann würde sich mir die Frage Stellen, warum nicht SMT + OoO benutzen?

 

[Opteron]

Ein derartiger Core kann nur sinnvoll funktionieren, wenn es mit OoO nicht mehr möglich ist die vielen Pipelines auszulasten, aber dann würde sich mir die Frage Stellen, warum nicht SMT + OoO benutzen?

Wie oben schon angedeutet verschlechter sich OoO mit jedem weiteren Thread. Erstens werden die Schattenregister knapp, zweitens wird die Sprungvorhersage schlechter. D.h. die Wahrscheinlichkeit auf Fehlspekulationen steigen.
Im Endeffekt ist 8fach InO einfach zum Stromsparen da. Es wird nur das gerechnet, was auch garantiert gebraucht wird und die Speicherlatenzen umgeht man dadurch, dass eben sehr viele Threads gleichzeitig laufen und nicht per OoO.

Kurz: Es kann schon sein, dass 2 OoO SMT-Threads und 8 InO-Threads auf einem Kern gleich schnell sind, aber letzterer Modus wird weniger Energie in Wärme umsetzen.
Eventuell wäre deswegen sogar ein höherer Turbo-Modi möglich, womit man dann doch etwas schneller sein könnte, aber das sind Detailfragen...

 

[gruffi]

Ich verstehe "groß" im Verhältnis zur Logikfläche, unabhängig vom Herstellungsprozess.

Schon klar. Aber deswegen werden die Wafer ja nicht kleiner. Kleinere Nodes ermöglichen halt auch mehr Logik auf gleicher Fläche. Sei es für Kerne, Cache, iGPU, iNB oder was auch immer. Und wenn es das Transistorbudget hergibt und ein 512 KB L2 nicht grundlegend schneller ist, warum soll man nicht 1 MB L2 implementieren?

Durch die HDLibs braucht man für Logik noch weniger Platz, auf Caches dagegen hat das keine Auswirkung.

Fragt sich nur, ob HDL bei Zen zum Einsatz kommt. Da habe ich so meine Zweifel. HDL scheint eher geeignet für Low Power. Keller sagte aber unmissverständlich, dass K12 und Zen High-Performance Kerne werden. Dementsprechend sollten da auch High-Performance Bibliotheken zum Einsatz kommen.

Ja ab 800 ist etwas früh, lässt sich aber auch einfach durch den L1 des 2. Cores erklären. Wenn der auch im L2 vorliegt, nützt es dem ersten Thread natürlich auch nichts.

Das erklärt aber nicht das genauso seltsame Verhalten im Diagramm von L1 zu L2. Daher hat das Diagramm für mich wenig Aussagekraft.

Was genau meinst Du da?

Na dass es von 64 auf 128 KB auch kein einzelner Sprung ist, sondern dass es da genauso verschiedene Zwischenlatenzen gibt. Das darf eigentlich nicht sein. Das legt die Vermutung nahe, dass das Tool an der Stelle nicht richtig funktioniert. Oder da wurde irgendwelcher Unsinn ins Diagramm aufgenommen.

Wieso ist das Fakt? Hast Du Fakten/Unterlagen?

Du hattest doch weiter vorne schon einen AT Artikel verlinkt. Da hast du auch den A8 Die Shot. Links oben und unten bei der CPU hast du den L2 Cache. Hier sieht man A7 und A8 auch nochmal im Vergleich.

Tja, aber wir reden doch gerade vom Serverdesign, oder nicht?

Nun ja, eigentlich reden wir von Zen, also dem Kern. Und den wird AMD sicherlich nicht nur für Server entwickeln.

Natürlich nicht, aber bei den K10 ohne L3 war halt der L2 der VictimCache des L1 .. das meinte ich damit. Funktional macht es keinen Unterschied welchen Cachelevel man nun hat inclusive ist immer was anderes als exclusive. Bisher waren die Katzen inclusive und der L3 mit halben Takt recht langsam, entweder setzt man jetzt auf vollen Takt, oder man führt nen neuen Cachelevel dazwischen ein, der dann aber auch inclusive werden dürfte -- wenn man nicht zuviel am Design verändern wollte.

Irgendwie wirfst du mir jetzt zu viel durcheinander. Sprichst du über Jaguar oder K10? Und welcher L3 bei Cat? Klar ist, dass Cat ein Client-Design war. Deshalb hat der auch keinen L3 benötigt. Ursprünglich hatte jeder Cat Kern einen dedizierten 512 KB L2. Scheinbar war das etwas wenig, sodass man daraus einen 2 MB shared L2 gemacht hat. So musste man die Kapazität nicht erhöhen. Bei Bedarf steht einem Kern aber bis zu viermal so viel L2 zur Verfügung. Was sagt uns das nun über Zen? MMn überhaupt nichts. Zum einen wird der L2 von Zen nicht mit Halbtakt laufen. Was alleine schon Auswirkungen auf Latenz und Grösse hat. Zum anderen muss AMD eben auch mit einem weiteren Cache Level für Server planen. Dazu muss der L2 natürlich auch passen. Wie gesagt, anhand der Cat Cache Hierarchie würde ich nichts für Zen ableiten. Da würde ich eher mal zu den Cortex Kernen schauen.

Das ist richtig -- für semicustom-Kunden, die in der Regel dann auch selbst für Ihre Maschinchen programmieren.
In der großen weiten x86-Welt dagegen gibts das nicht, oder wieviel x86-Code gibts im Vergleich zu HSA-Code?

Das gibt's mittlerweile auch in der x86 Welt. PS4 und XBO lassen grüssen. Die Frage ist eher, wie lange gibt's die "alte" x86 Welt noch?

Verbesserungen und sogar gleich 20%(!) sind im x86-Markt immer gerne gesehen.

Naja, 20% war schon der Idealfall. Wenn Skylake durch MorphCore 20% in multithreaded zulegt und 0-5% in single-threaded verliert, dann kannst du dir ja ausrechnen, was im Schnitt bei gleichem Takt über verschiedenste Anwendungen übrig bleib. Vielleicht 5-10%. Der 4M Bulldozer konnte im Idealfall (volle Auslastung, AVX, FMA) auch doppelt so schnell sein wie der 6C Thuban. Bei Wald- und Wiesencode war davon allerdings nicht viel zu sehen.

 

[Ge0rgy]

Also, zum ersten, es ist richtig dass ich eher selten Assembler Programmiere, das habe ich zuletzt während der Ausbuldung konkret an einem 80535 - Microcontroller getan, das spielt aber auch keine Rolle.
Zum zweiten, ist mir sehr wohl klar, dass man nie genug register haben kann, das bedeutet aber nicht dass fertig kompilierte Software auf einmal mehr register anspricht und mit ihnen rechnet, nur weil ich grade zufälligerweise eine CPU im System habe, der mehr Register zur Verfügung stellt. Das ist das was ich hinterfrage.
Einfach ausgedrückt, wenn der Compiler von Hause aus Code erzeugt der mit 5 Registern arbeitet, weil er davon ausgeht dass nicht mehr als 8 max. vorhanden sind, dann hilft es dir garnichts wenn dein konkreter Chip nun plötzlich 20 Register hat, davon wird die Software auch nicht anders. Wenn wir natürlich von speziell auf diese Architektur kompilierter SW reden, sieht das schon anders aus, aber das Problem dass kein Mensch auf AMDsche architekturen kompiliert hatten wir bzw. hatte AMD auch bisher schon.
Kurz gesagt, ich bezweifle nicht dass viele Register praktisch sind und auch dass sich Assembler-Programmierer mehr wünschen würden. Ebenfalls ist mir bekannt dass x86-64 das "Problem" etwas gelockert hat mit der Einführung neuer Register. Dennoch bezweifle ich dass das vorhandensein von 10 weiteren Registern bei Bestandssoftware, deren Compiler beim generen der Anweisungen nichts von den weiteren Registern wusste, irgend einen Vorteil bringt. - Natürlich auf Architekturregister bezogen. Schattenregister sind wieder ein anderes Thema. Darum glaube ich aber auch wenig dass das "umdeklarieren" von Schattenregistern zu Architekturregistern irgend einen nennenswerten Vorteil hat.
Das war meine Frage. Es geht also nicht um die konkrete Anzahl von Registern sondern darum dass sich die Registernutzung zur Kompilier-Zeit entscheidet, nicht zur Laufzeit. - Und damit ein "Ausreißer" einer bestimmten Architektur bei Bestandssoftware nicht wirklich was bringen sollte, meiner Logik nach.
Konkret heißt das, als wir damals Akku und R1 - R4 in der Assemblerprogrammierung des 80535 nutzten, taten wir das weil wir davon ausgingen dass der Chip auch nicht mehr hat. Das selbe Programm hätte auch nicht mehr Register genutzt wenn wir kurz danach einen solchen Chip mit 20 Registern bekommen hätten. Eben weil man beim Programmieren das Register vorgibt. - Und wenn man zur Entwicklungszeit nicht weiß dass es mehr gibt, werden die weiteren auch nicht genutzt.
Und genau hier stehe ich auf dem Schlauch was Opterons Spekulation betrifft. Also entweder habe ich da was falsch verstanden oder wir reden aneinander vorbei.

 

[drSeehas]

... das bedeutet aber nicht dass fertig kompilierte Software auf einmal mehr register anspricht und mit ihnen rechnet, nur weil ich grade zufälligerweise eine CPU im System habe, der mehr Register zur Verfügung stellt. usw. ...

Sowas erwartet ja auch niemand.

 

[Opteron]

Und genau hier stehe ich auf dem Schlauch was Opterons Spekulation betrifft. Also entweder habe ich da was falsch verstanden oder wir reden aneinander vorbei.

Hmm stimmt schon alles was Du schreibst. Weiss jetzt auch nicht genau, wo der Schlauch ist. Liegts vielleicht daran, dass Du nicht weisst, dass man bei SMT für jeden zusätzlichen Thread eigene Architekturregister vorhalten muss (bzw. sollte)?

Das ist der Löwenanteil der zusätzlichen ~5% Die-Fläche, die SMT benötigt. Jedem Thread soll ja vorgegaukelt werden, dass er auf nem eigenen Kern läuft, das Minimum, um das (performant) zu können, sind eigene Architektur-Register für jeden Thread. Wenn man so will ist CMT damit eine weitere Ausbaustufe von SMT, anstatt dem 2. Thread nur eigene Arch-Register anzubieten gibts bei CMT auch noch eigene ALUs und L1-Caches.

Beim Morphcore werden dann aus den 16 AMD64-Architektur- und z.B: 140 Schattenregistern des OoO-Betriebs im InO-Betrieb 8x16 Architekturregister (der Rest bliebe in dem Beispiel dann ungenutzt übrig).

 

[gruffi]

Wenn man jetzt SMT auf einem OoO-Kern betreibt, sinkt logischerweise die Anzahl der Schattenregister pro Thread

Normalerweise hat jeder SMT Thread sein eigenes Register-Set. Ich weiss nicht, wie das bei gängigen SMT Architekturen gehandhabt wird. Aber ich würde eher vermuten, dass dann auch jeder SMT Thread sein eigenes Schattenregister-Set hat. Falls es hingegen nur ein Schattenregister-Set für alle SMT Threads gibt, dann hast du natürlich Recht. Dann könnte man dies ausreichend für einen Thread dimensionieren. Im Multithread-Betrieb ist es dann wurscht, da man auf In-Order umschaltet und Schattenregister eh nichts bringen. Ob das in der Praxis allerdings viel ausmacht, wage ich zu bezweifeln. Für 2 bis 4 SMT Threads sollte heutzutage mehr als genügend Energie- und Transistorbudget vorhanden sein. Und so viele Register hat x86 ja auch nicht. Meines Wissens haben OoO Architekturen meist weniger Schattenregister als GPRs.

 

[Opteron]

Normalerweise hat jeder SMT Thread sein eigenes Register-Set. Ich weiss nicht, wie das bei gängigen SMT Architekturen gehandhabt wird. Aber ich würde eher vermuten, dass dann auch jeder SMT Thread sein eigenes Schattenregister-Set hat.

Natürlich wird das so sein, sind ja 2 unterschiedliche Threads, wobei man sich aber auch ne dynamische Zuordnung vorstellen könnte.

Falls es hingegen nur ein Schattenregister-Set für alle SMT Threads gibt, dann hast du natürlich Recht. Dann könnte man dies ausreichend für einen Thread dimensionieren.

Aber auch das stimmt, denn absolut wird es schlicht und einfach eine simple Obergrenze geben. Eine Architektur Y hat einfach nicht mehr als X Register. Wenn die dann aufgeteilt werden, hat jeder Thread nur X/2 Register zur Verfügung. Mit 4fach SMT dementsprechend nur X/4 usw.. deswegen bringt OoO mit zunehmender Threadzahl nicht wirklich viel, am Ende bleibt nur das Ausnutzen der Speicherlatenz, aber das kann man dann auch mit entsprechend vielen InOrder-Threads.

Im Multithread-Betrieb ist es dann wurscht, da man auf In-Order umschaltet und Schattenregister eh nichts bringen. Ob das in der Praxis allerdings viel ausmacht, wage ich zu bezweifeln.

Naja, man verliert a) Keine Mth-Leistung und spart b) Energie daraus folgt die Perf/Watt steigt. Wer will kann das eingesparte Energiebudget auch für nen höheren Takt re-investieren. Find ich unterm Strich schon sehr praktisch.

Für 2 bis 4 SMT Threads sollte heutzutage mehr als genügend Energie- und Transistorbudget vorhanden sein.

Klar, aber wenn Du die gleiche Leistung mit geringerem Energieverbrauch bekommen kannst? User sind gierig, die wollen immer das Beste

Und so viele Register hat x86 ja auch nicht. Meines Wissens haben OoO Architekturen meist weniger Schattenregister als GPRs.

Dann hast Du da irgendwo was Falsches aufgeschnappt, selbst ein kleiner Jaguar hat 64 Register:

The integer PRFs for Jaguar and Bobcat are 64 entries and hold the architectural and speculative versions of the 64-bit integer registers. Of the 64 physical registers, 20-31 are used to hold architectural and microarchitectural state, while the other 33-44 registers can hold speculative data.

http://www.realworldtech.com/jaguar/4/

Und das ist bekanntlich ne low-end Arch. Haswell hat dementsprechend etwas mehr, nämlich 168:

The physical register files hold the actual input and output operands for uops. The integer PRF added a modest 8 registers, bringing the total to 168.

http://www.realworldtech.com/haswell-cpu/3/

Das werden mit jedem Shrink immer mehr. Je mehr Register, desto besseres/tieferes OoO und damit auch eine höhere IPC.

Bulldozer liegt dazwischen:

Within each dispatch group, any integer and memory macro-ops are renamed into the 96-entry physical register file (which contains both architectural and speculative registers).

http://www.realworldtech.com/bulldozer/6/
Halt auch wieder der CMT-Effekt ... wie beim L1 muss man bei CMT fest aufsplitten. Mit ner SMT-Arch. hätte man zum gleichen Preis 192 Register bekommen und die dynamisch aufsplitten können ... das wär mal ne Ansage gewesen. Aber tja .. wurden halt nur 2x96 Regs und 2x16kB L1

Spannend wär jetzt die Frage, ob es irgendwann mal eine Obergrenze für L1 und Register gäbe, nach der weiteres Erhöhen nichts mehr bringt. Falls ja wäre ab dem Zeitpunkt wo man sich dass dann auch für einen CMT-Kern/INT-Cluster leisten kann, CMT besser als SMT.

So ein aufgemotzer BD-INT-Cluster mit 32kb L1, wenigstens 3issue, großen Registern und üppigen Puffern wär schon interessant gewesen. Den L2 hätte man schon keinen Nachteil mehr ggü. SMT, den könnte man schon gemeinsam benutzen lassen. So schwierig ists eigentlich gar nicht .. zumindest sub 20nm

Eigentlich könnte AMD bei CMT bleiben, mit der HDLib haben sie ja Platz für dicke INT-Cluster. Man müsste das Back-End nur noch auf niedrigerem Takt anpassen, z.B. ADD in einem statt 2 Takten. Nicht ganz trivial, aber es soll ja sowieso ne neue Architektur werden.

 

[BoMbY]

Die physikalischen Register haben nur nicht direkt etwas mit den Registern auf der Assembler-Seite zu tun. Die sind nur für interne Verwaltung und Optimierung, oder eventuell für erweiterte Sprachbefehle. So verstehe ich das jedenfalls.

 

[gruffi]

Aber auch das stimmt, denn absolut wird es schlicht und einfach eine simple Obergrenze geben. Eine Architektur Y hat einfach nicht mehr als X Register. Wenn die dann aufgeteilt werden, hat jeder Thread nur X/2 Register zur Verfügung. Mit 4fach SMT dementsprechend nur X/4 usw..

Redest du jetzt von Register-Sets oder vom PRF? Das Register-Set ist für jeden Thread gleich gross. Und das PRF sollte üblicherweise ausreichend für alle Threads dimensioniert sein. Wenn nicht, dann hat man bei der Konzeption was falsch gemacht.

Naja, man verliert a) Keine Mth-Leistung und spart b) Energie daraus folgt die Perf/Watt steigt.

Naja, ob dadurch die Effizienz steigt, wage ich zu bezweifelt. Das bisschen, was da eingespart werden kann, geht vermutlich für die Abschaltlogik im In-Order Betrieb wieder drauf.

Dann hast Du da irgendwo was Falsches aufgeschnappt, selbst ein kleiner Jaguar hat 64 Register:

Da wirfst du aber was durcheinander. Wo steht denn in dem zitierten Text was von Schattenregistern? PRF und Schattenregister sind zwei verschiedene Sachen. Das PRF enthält sämtliche Register. Schattenregister sind nur ein Teil davon. Die meisten Register im PRF gehen vermutlich fürs Renaming drauf. Solange du keine konkreten Zahlen zu den Schattenregistern bringen kannst, macht das Argument an der Stelle wenig Sinn.

Und das ist bekanntlich ne low-end Arch. Haswell hat dementsprechend etwas mehr, nämlich 168

Ja, der muss aber auch 2 Register-Sets halten. Rechne mal die 168 durch 2 und du liegst gar nicht mehr so viel über Jaguar.

 

[Opteron]

Die physikalischen Register haben nur nicht direkt etwas mit den Registern auf der Assembler-Seite zu tun. Die sind nur für interne Verwaltung und Optimierung, oder eventuell für erweiterte Sprachbefehle. So verstehe ich das jedenfalls.

Das verstehst Du schon richtig, steht doch auch im zitierten Teil:

Of the 64 physical registers, 20-31 are used to hold architectural and microarchitectural state, while the other 33-44 registers can hold speculative data.

Von den 64 vorhandenen (physical) Registern werden 20-31 für die Architektur und Mikroarchitekturstates benutzt. Die Architekturstates sind genau die 16 Register, die man beim (AMD64)-Assembler sieht, dazu dann halt noch ein paar für Internes. Dann der Nebensatz: ".. während die anderen 33-44 Register speculative Daten halten. Dass sind die angesprochenen Schattenregister, die sieht man im Assembler nicht, die werden nur wegen OoO, Stichwort "Register-Renaming" benutzt. Dazu gibts nen Wikiartikel, sogar auf Deutsch, wer weiterlesen will:
https://de.wikipedia.org/wiki/Registerumbenennung

Redest du jetzt von Register-Sets oder vom PRF? Das Register-Set ist für jeden Thread gleich gross. Und das PRF sollte üblicherweise ausreichend für alle Threads dimensioniert sein. Wenn nicht, dann hat man bei der Konzeption was falsch gemacht.

Na von beidem, sowohl als auch, Architektur- und Schattenregister, also von der Gesamtanzahl, sprich dem PRF. Natürlich ist das PRF für alle Fälle groß genug. Ansonsten hätte man in der Tat ein dickes Problem.

Naja, ob dadurch die Effizienz steigt, wage ich zu bezweifelt. Das bisschen, was da eingespart werden kann, geht vermutlich für die Abschaltlogik im In-Order Betrieb wieder drauf.

Sehe ich nicht so, denn mit jedem weiteren Thread werden ja die Spekulationen pro Thread ebenfalls schlechter. Da würde dann am Ende ziemlich viel Mist für umsonst gerechnet und dabei kostet jedes (Aus)rechen kostet Energie. Schaltet man auf InO um, spart man sich also erstens das massenhafte nutzlose Herumrechnen, zweitens auch die Energie für die OoO-Logik, die neben den Decodern auch einen Großteil der Transistoren im Front-End ausmacht.

Da wirfst du aber was durcheinander. Wo steht denn in dem zitierten Text was von Schattenregistern? PRF und Schattenregister sind zwei verschiedene Sachen. Das PRF enthält sämtliche Register. Schattenregister sind nur ein Teil davon. Die meisten Register im PRF gehen vermutlich fürs Renaming drauf. Solange du keine konkreten Zahlen zu den Schattenregistern bringen kannst, macht das Argument an der Stelle wenig Sinn.

Huh? Das steht doch da, die Schattenregister sind die die die spekulativen Daten halten: "registers can hold speculative data".
In obigen Wikipedia Artikel steht "unsichtbar":

In der x86-Familie kam Registerumbenennung erstmals im Pentium Pro zum Einsatz, in dem acht für den Programmierer sichtbare Register des Befehlscodes (EAX, EBX, …, ESP) auf 96 unsichtbare (aber physisch vorhandene) Register umgelegt wurden.

..falls Dir der Begriff geläufiger sein sollte können wir auch den nehmen, mir egal, ändert nichts am grundlegenden Konzept.
Nebenbei frag ich mich, aber was Du bisher unter Schattenregister verstanden hast, wenn nicht das.

Ja, der muss aber auch 2 Register-Sets halten. Rechne mal die 168 durch 2 und du liegst gar nicht mehr so viel über Jaguar.

Im SMT-Betrieb ja, im single-thread Betrieb: Nein
Aber ansich ist das auch egal, Deine ursprüngliche Aussage, dass es weniger Schattenregister als Architekturregister geben würde, war in jedem Fall falsch. Davon gibts ne Menge, siehe auch beim PPro, der auch schon 96 Register insgesamt hatte, obwohl der damals noch kein AMD64 konnte, das Ganze also nur für die mickrigen acht x86-Register geplant war.

 

[gruffi]

Sehe ich nicht so, denn mit jedem weiteren Thread werden ja die Spekulationen pro Thread ebenfalls schlechter.

Wir sprachen doch nur von den Schattenregistern, nicht von Spekulationslogik. Die Schattenregister selbst dürften kaum was brauchen. Da macht das Abschalten einfach keinen Sinn. Spekulationslogik kann man auch abschalten, ohne die Schattenregister abzuschalten.

Huh? Das steht doch da, die Schattenregister sind die die die spekulativen Daten halten: "registers can hold speculative data".

Von Schattenregistern steht da aber trotzdem nichts. Wie gesagt, meines Wissens werden normalerweise weniger Schattenregister als GPRs implementiert. Man braucht diese Schattenregister ja immer nur für ein vergleichsweise kleines OoO Fenster und auch nur bei bestimmten Abhängigkeiten. Wenn RWT schreibt, Jaguar hat 64 Integer Register, dann müssten eigentlich nur bis zu 16 als Schattenregister verwendet werden. Warum das bis zu 44 sein sollen, musst du mir erst mal erklären. Vielleicht haben wir hier aber auch nur ein Verständnisproblem. Schattenregister haben für mich eine spezielle Bedeutung. Nämlich dass sie den aktuellen Zustand eines GPRs enthalten, um ihn bei Bedarf zurückzuschreiben. Dafür braucht man wie gesagt nicht viele. Renaming ist dann nochmal eine andere Baustelle. Wenn du mit Schattenregister hingegen alle Register im PRF ausser den Architekturregistern meinst, dann stimmt das schon. Da sollten es bei Jaguar 40 sein, 64 - 16 (GPRs) - 6 (Segment Register) - 1 (IP) - 1 (Flags).

Im SMT-Betrieb ja, im single-thread Betrieb

Single-thread interessiert uns aber nicht. Der Kern ist nun mal für SMT ausgelegt. Also müssen wir es auch pro Thread betrachten.

 

[mariahellwig]

Hatten wir die schon?
http://www.fudzilla.com/news/processors/37494-amd-x86-16-core-zen-apu-detailed

 

[BoMbY]

Na, wenn die generelle Leistung stimmt, könnte das ein echter Gewinn werden. Insgesamt alles was man sich erhoffen kann. Sofern die Informationen der Realität entsprechend, und auch umgesetzt werden können.

 

[Gast11062015]

Es weis ja bis heute keiner ob SMT genutzt wird,
Offizielle Aussagen zu dem Thema gibt's ja nach wie vor nicht.

Die einen Schreien SMT, die anderen CMT und noch weitere CMT+SMT was ich für am wahrscheinlichsten halte

 

[Raspo]

Zu schön um wahr zu sein.

 

[Complicated]

Damit würde sich mit Zen schon das Interposer-Konzept bewahrheiten, wie hier im Prognose-Thread geschrieben:
http://www.planet3dnow.de/vbulletin...ffen-koennte?p=4994712&viewfull=1#post4994712

Demnach sind die Kosten in der Fertigung durch die steigende Anzahl an Masken deutlich teurer und zudem müssen immer mehr unterschiedliche Schaltungen in dem selben Prozess hergestellt werden. Offensichtlich sind die Experimente mit den gemeinsamen Transistoren für CPU und GPU da schon länger an ein Limit gelangt, das durch die Verwendung von Interposern überwunden werden soll. damit würde AMD seine IP noch leichter zugänglich machen und die Yieldraten für die einzelnen Element verbessern. Also Fusion ist out und lang lebe HSA? Scheint es hatte doch tiefere Gründe für die Umbenennung.

"Die Partitioning" nennen sie es.

 

[miriquidi]

Die einen Schreien SMT, die anderen CMT und noch weitere CMT+SMT was ich für am wahrscheinlichsten halte

CMT+SMT wäre für den Mobilmarkt ein Klotz am Bein, weil immer ein ganzes Modul anstatt eines Einzelkerns im Betrieb sein muss.

 

[OBrian]

Zu schön um wahr zu sein.

vielleicht erhoffen wir uns auch nur zuviel dabei. 16 Kerne für 32 Threads, die dann auch noch einen Großteil der TDP für die GPU abgeben müssen, da bleibt nicht viel pro Kern übrig. Sicherlich ist das hier ein HPC-Chip, wo die Kerne wohl längst nicht so hoch getaktet sind wie sie eigentlich könnten. Aber es kann auch einfach sein, daß so ein Zen-Kern relativ schwach ist und dann eine 4-Kern-8-Thread-APU für den Consumermarkt leistungsmäßig nicht viel berauschender ausfällt als das, was AMD aktuell ins Feld führt. Ich hoffe es nicht, aber möglich ist es durchaus.

 

[cyrusNGC_224]

1/2 DP Rate der GPU nicht schlecht.
Klingt gesamt ziemlich stark aber auch nötig.

 

[mariahellwig]

Zu schön um wahr zu sein.

Das habe ich auch gedacht. Mal abwarten wie später konkrete Produkte aussehen.
Alles in einem Chip wird es vermutlich nicht geben.

 

[drSeehas]

... http://www.fudzilla.com/news/processors/37494-amd-x86-16-core-zen-apu-detailed

32 MB shared L3 Cache. mnmnmnmnmn
Hoffen wir, dass wenigstens das auch so kommt.
Aber auf dem Bild (und im Artikeltext) sieht es eher nach 4 * 8 MB L3 Cache aus.

 

[mariahellwig]

Aber es kann auch einfach sein, daß so ein Zen-Kern relativ schwach ist und dann eine 4-Kern-8-Thread-APU für den Consumermarkt leistungsmäßig nicht viel berauschender ausfällt als das, was AMD aktuell ins Feld führt. Ich hoffe es nicht, aber möglich ist es durchaus.

Man könnte damit gut leben wenn sie wenigstens effizient wären. Die Bedeutung von ST-Leistung wird abnehmen.