AMD K12 -Spekulation

Ich denke das ist so wenig, dass man es in Prozent kaum sinnvoll angeben kann. Bei bedingten Anweisungen brauchst du doch im Grunde immer nur ein Bit zusätzlich mit durchzuschleifen. Von Frontend zu Backend wird das eh über uops gemacht. Und im Backend brauchst du dann lediglich eine Bypass Logik vor den Ausführungseinheiten. Das sollte nicht viel kosten.

Trotzdem sollte man beachten, bedingte Anweisungen machen nur bei kurzen bedingten Sequenzen Sinn. Damit bedingte Anweisungen effektiv sind, sollte der Compiler also gut optimieren. Hat man längere bedingte Sequenzen, sind Sprünge effektiver.

Es gibt mehr als ein Bit im Status register:

Q Saturation
V Overflow
C Carry
Z Zero
N Negative

Und das sind die möglichen "Prefixe":

EQ equal Z
NE not equal z
CS HS carry set/unsigned higher or same C
CC LO carry clear/unsigned lower c
MI minus/negative N
PL plus/positive or zero n
VS overflow V
VC no overflow v
HI unsigned higher zC
LS unsigned lower or same Z or c
GE signed greater than or equal NV or nv
LT signed less than Nv or nV
GT signed greater than NzV or nzv
LE signed less than or equal Z or Nv or nV
AL always (unconditional) ignored

Und haben ARM-CPUs überhaupt uops? Ist ARM risc genug um darauf verzichten zu können?
 
Zuletzt bearbeitet:
Es gibt mehr als ein Bit im Status register
Vorsicht, Bits in uops und Bits in Statusregistern sind zwei verschiedene Paar Schuhe. Ein entsprechendes Bit der Instruktion / entsprechender Opcode gibt ja erst mal an, ob eine Instruktion bedingt ausgeführt werden soll. Die Bits in Statusregistern bestimmen dann, ob die Bedingung erfüllt ist, also die Instruktion auch tatsächlich ausgeführt wird, oder eben nicht.

Übrigens, bei AArch64 wurde die Anzahl der bedingten Instruktionen deutlich reduziert im Vergleich zu AArch32. Es gibt nur noch sehr wenige davon (zB x86 kennt auch nur wenige). Liegt wohl einfach daran, dass die Sprungvorhersage moderner Prozessoren mittlerweile so ausgereift ist, dass der Aufwand nicht lohnt, entsprechenden Platz für Opcodes zu reservieren.

Und haben ARM-CPUs überhaupt uops? Ist ARM risc genug um darauf verzichten zu können?
Klar, auch ARM nutzt Micro-Ops. Bei x86 gibt's halt noch eine Zwischenstufe, Macro-Ops, um die x86 Instruktionen variabler Länge erst mal in Instruktionen fester Länge umzuwandeln. Darauf kann man bei ARM verzichten.
 
Zuletzt bearbeitet:
Vorsicht, Bits in uops und Bits in Statusregistern sind zwei verschiedene Paar Schuhe. Ein entsprechendes Bit der Instruktion / entsprechender Opcode gibt ja erst mal an, ob eine Instruktion bedingt ausgeführt werden soll. Die Bits in Statusregistern bestimmen dann, ob die Bedingung erfüllt ist, also die Instruktion auch tatsächlich ausgeführt wird, oder eben nicht.

Der Instructiondecoder wird keinen Zugriff auf das Statusregister haben, außerdem ist zum Zeitpunkt der dekodierung des Opcodes keinesfall sicher das sich der Inhalt des Statusregisters sich bis zum tatsächlichen ausführen des Opcodes nicht mehr ändert. Tracebuffer oder ähnliche Konstrukte wären dann auch weniger wirkungslos bis unmöglich.

Übrigens, bei AArch64 wurde die Anzahl der bedingten Instruktionen deutlich reduziert im Vergleich zu AArch32. Es gibt nur noch sehr wenige davon (zB x86 kennt auch nur wenige). Liegt wohl einfach daran, dass die Sprungvorhersage moderner Prozessoren mittlerweile so ausgereift ist, dass der Aufwand nicht lohnt, entsprechenden Platz für Opcodes zu reservieren.

X86 ist für solche Sachen keine Referenz. (Feature for feature, bug for bug)

Klar, auch ARM nutzt Micro-Ops. Bei x86 gibt's halt noch eine Zwischenstufe, Macro-Ops, um die x86 Instruktionen variabler Länge erst mal in Instruktionen fester Länge umzuwandeln. Darauf kann man bei ARM verzichten.

Gibt es irgendwo Papers dazu? http://www.arm.com/files/pdf/AT-Exploring_the_Design_of_the_Cortex-A15.pdf geht nicht soweit runter.
 
Zuletzt bearbeitet:
Laut diesem Paper nutzen ARM als auch x86 MacroOps. Es untersucht die Instruction Ausführungsgeschwindigkeit.
Cortex A8, A9, Atom und Sandy Bridge wurden untersucht - IMHO das beste Paper zu den beiden ISAs bisher und viele interessante Infos:

Das alles inkls. Verbrauchsmessungen und Bedeutung für High Performance Implementationen:
A Detailed Analysis of Contemporary ARM and x86 Architectures
ARM_x86_20131.JPG ARM_x86_20132.JPG ARM_x86_20133.JPG

Und gute Nachrichten für K12:
Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy. Determining the lowest performance level at which the RISC/CISC ISA effects are irrelevant for all metrics is interesting future work.
 
Der Instructiondecoder wird keinen Zugriff auf das Statusregister haben
Das hat ja auch keiner behauptet. Die Auswertung der Statusregister und Ausführung der bedingten Instruktionen geschieht im Backend. Das schrieb ich schon zuvor.

X86 ist für solche Sachen keine Referenz.
Auch das hat keiner behauptet. Das war lediglich ein zusätzliches Beispiel für ISAs mit wenigen bedingten Instruktionen.

Gibt es irgendwo Papers dazu?
Papers zu was?
 
Our study suggests that at performance levels in the range of A8 and higher, RISC/CISC is irrelevant for performance, power, and energy. Determining the lowest performance level at which the RISC/CISC ISA effects are irrelevant for all metrics is interesting future work.
Daraus läßt sich doch folgern, daß Zen und K12 auf ziemlich gleichem Performanceniveau sein werden, oder? Denn beide sollen ja austauschbar für die gleiche Plattform kommen, dabei kann man also von ähnlicher TDP ausgehen und wohl auch von ähnlicher Schwerpunktsetzung in der Architektur (will sagen, Zen und K12 werden sich bestimmt ähnlicher sein als z.B. Pentium 4 und Core2). Und wenn mit einer bestimmten TDP eine bestimmte Performance erreichbar ist, egal ob ARM oder x86, dann werden die beiden darauf basierenden Architekturen wohl ziemlich gleichauf sein.

Ich weiß nur nicht, ob das was Gutes für Zen bedeutet... K12 wird bestimmt der stärkste ARM, den die Welt gesehen hat, aber Zen ist evtl. auch nur auf Kaveri-Niveau (mit sicherlich besserer Effizienz) und kein Performancefortschritt. Was ihn dann auch unbrauchbar für unsereins machen würde. :(
 
...K12 wird bestimmt der stärkste ARM, den die Welt gesehen hat...

Na hoffen wir mal ;)

...aber Zen ist evtl. auch nur auf Kaveri-Niveau (mit sicherlich besserer Effizienz) und kein Performancefortschritt. Was ihn dann auch unbrauchbar für unsereins machen würde.

Soweit ich AMDs neue Strategie verstanden habe, geht AMD ganz extrem in Richtung Effizienz. Das wird kaum ohne weitere Zugeständnisse an die Maximalperformance gehen. Ich interpretiere das so, dass AMD das Performance-Segment auch in Zukunft nicht mehr als Ziel sieht. Da man nur auf Effizienz oder Maximalperformance optimieren kann, und sich AMD keine halben Sachen mehr leisten kann, gehe ich davon aus, dass man diesmal ohne Kompromiss in die Richtung Effizienz geht. Das heißt für mich, dass man durchaus in Zukunft sogar noch ein bisschen mehr an Maximalperformance opfert.
 
Es wird auf effiziente Maximalperformance hin optimiert. Die Performance ist ebenso Teil der Gleichung wie der Verbrauch. Ohne Performance keine Effizienz. Warum das für dich heisst Maximal-Performance zu opfern ist für mich nicht nachvollziehbar - schau dir doch mal Maxwell Benchmarks an und du siehst deine Theorie widerlegt. Du hast die Strategie somit falsch verstanden.
 
schau dir doch mal Maxwell Benchmarks an und du siehst deine Theorie widerlegt.

Finde ich nicht. Maxwell in 970 performt gut und ist Effizient bei den Factory Einstellungen. Sobald die Performance durch drehen an der Taktschraube aber verbessert wird, ist es vorbei mit der Effizienz. Maxwell ist da ein schönes Beispiel, das es maximale Performance eben nicht effizient gibt.
 
Maximale Performance unter dem Schwerpunkt " Effizienz " ...

Allein Hawaii, was die Kühlung betrifft (desto besser), lässt den kleinen Scheißer effizienter erscheinen/werden! ( obwohl er ja genau das Gegenteil ist, so sein " Ruf " )

kommt eben darauf an, welchen Kompromiss man eingeht... (Sweetspot und wie weit man sich von diesem entfernt oder nähert ) das kannst du aus den Worten schlicht nicht beurteilen, vor allem, da das Teil noch nicht existiert.

Meine Vermutung ist, und das kann man derzeit nur(!) Dass eine hohe Effizienz anstreben die mittels Takt gut skaliert. Wie gut, ist ne andere Frage.

Edit:

Da die Roadmap von AMD eh 2014 endet, werden wir Anfang nächsten Jahres auf alle Fälle weitere Informationen erhalten.

Auch finde ich die von AMD und in der Presse getätigten Aussagen ein bisschen verwirrend. AMD sprach selber, das die mit dem Bulli 4 Jahre Leben müssen... ( soweit klar )

Zen kommt also eher 2015 und K12 @Arm kommt 2016.
Also müssten wir ja jetzt kommendes Jahr allerhand Infos erhalten, was Sockel und co betrifft.
Zumindest schon mal eine neue Roadmap, da die jetzige in einem Monat abläuft.
 
Zuletzt bearbeitet:
Finde ich nicht. Maxwell in 970 performt gut und ist Effizient bei den Factory Einstellungen. Sobald die Performance durch drehen an der Taktschraube aber verbessert wird, ist es vorbei mit der Effizienz. Maxwell ist da ein schönes Beispiel, das es maximale Performance eben nicht effizient gibt.

Und findest du die 970 nicht konkurrenzfähig oder zu langsam für die Konkurrenz? Das Argument mit Maxwell soll zeigen, dass trotz Effizienz-Vorteil gegenüber der Konkurrenz kein langsameres Produkt zum Vorgänger oder direkten Konkurrent raus kommen muss, wie das hier für den K12 spekuliert wurde, nur weil man effizient sein will. Jedes effiziente Produkt kann noch schneller gemacht werden über den perfekten Balance-Punkt hinaus, selbstverständlich.
 
Als Gamingkarte ist die schon OK. Mir ging es lediglich um den "perfekten Balance-Punkt" oder auch maximum(Performance/Watt).
Schiebt man den Takt hoch, gewinnt man Performance, braucht aber überproportional mehr Watt, geht man mit dem Takt runter braucht es weniger Watt verliert aber überproportional an Leistung.
Ich bin mehr Fan von Performance, brauch ich im Winter weniger Heizung :) .
Es ging schließlich darum, dass sich AMD wohl mehr auf max(Performance/Watt/$) konzentriert und wir deshalb weniger max(Performance) erwarten können.
Letztendlich wird das aber im wesentlichen von der Prozesstechnologie abhängen. Kommt darauf an, wieviel Takt bei welchem Verbrauch rausgeholt werden kann. Da sind die kleineren Prozesse anscheinend nicht grad Taktfreudig.
 
Stimmen wir dennoch überein, dass auch ein effizientes Produkt eine hohe Performance haben kann?
 
tja, wenn man das so allgemein ausdrückt, ohne jeglichen Maßstab, kann man immer zustimmen :] Was ist effizient, was ist hoch?

Ich meinte jedenfalls mit "wird wohl nicht schneller als Kaveri", daß nix dabei rauskommt, was den bescheuerten 5-GHz-Vishera ersetzen kann. Naja gut, wenn sie dessen Performance mit 100 W hinkriegen, wäre es ja schon gut, dann könnte man mit OC noch bißchen was zulegen.

Aber wenn sie sich auf TDPs unter 35 W beschränken, dann reicht auch die geilste Effizienzsteigerung nur für mittelmäßige Performance, und die Plattformen werden dann auch kein OC bis sonstwohin erlauben.
 
Naja, wenn AMD in zukunft den niedrigen TDPs hinterher rennt, wie sie es bei Carrizo (max. 65W) wohl auch machen, wird das mMn. sowie so nichts mehr.

Sie wollen immer mehr auf eine Die Packen, vor allem auch eine Leistungsfähige GPU und dann gehen sie mit der TDP immer weiter runter?
Effizient heist nicht nur mit der TDP immer tiefer stapeln, von mir aus kann so eine APU auch 150W verbrauchen, wenn entsprechend Leistung bei rum kommt (und man nicht in Limits fährt, wie zB. die DDR3 Bandbreite). Effizient kann das ganze mit 150W ja immer noch sein.

So etwas wie Centurio ist natürlich auch nichts ;)
 

Zum Instructiondecoder von ARM CPUs.

--- Update ---

Soweit ich AMDs neue Strategie verstanden habe, geht AMD ganz extrem in Richtung Effizienz. Das wird kaum ohne weitere Zugeständnisse an die Maximalperformance gehen. Ich interpretiere das so, dass AMD das Performance-Segment auch in Zukunft nicht mehr als Ziel sieht. Da man nur auf Effizienz oder Maximalperformance optimieren kann, und sich AMD keine halben Sachen mehr leisten kann, gehe ich davon aus, dass man diesmal ohne Kompromiss in die Richtung Effizienz geht. Das heißt für mich, dass man durchaus in Zukunft sogar noch ein bisschen mehr an Maximalperformance opfert.

Knapp 1/5 weniger Leistungsverbrauch bei Volldampf für Steamroller: http://www.realworldtech.com/steamroller-clocking/
 
Also 150 W finde ich auch langsam zuviel. Aber mit den 100 oder 95 W, die FM2+ aktuell erlaubt, kann man einerseits einiges an Performance mehr erreichen als mit einer 35-W-Grenze, und im Desktop sind diese 95 W auch nicht abartig viel, zumindest diesen Spielraum würde ich durchaus ausnutzen.

Wenn BD durch irgendwas anderes ersetzt wird, kann es ja nur besser werden, d.h. mit gleicher TDP müßte definitiv mehr Performance drin sein, wenn es nicht total schief läuft. Und die spezielle Schwäche von BD bei Spielen könnte mit einer ganz anders gestrickten Architektur auch einfach so wegfallen. Wie schon mal gesagt wäre mir Spieleperformance auch wichtiger als drei Sekunden bei 7zip einzusparen.

RAM-Bandbreite wird wohl kein Problem sein, AMD arbeitet ja feste an HBM, damit gibt es wirklich Bandbreite bis zum Abwinken. Richtig interessant wäre es, wenn die CPU-Architektur voll darauf ausgerichtet wird, einerseits gibt es massig Bandbreite zur Verfügung, andererseits steht ihr eine starke GPU zur Seite. Die CPU sollte also so aufgebaut werden, daß sie von viel Speicherbandbreite gut profitiert, und sie sollte die Fähigkeiten der GPU optimal ergänzen, also speziell das gut machen, was die GPU nicht gut kann, andererseits aber alles, was die GPU besser kann, auf diese abwälzen. BD war ja auf Durchsatz und massives Multithreading ausgelegt, also praktisch dasselbe wie eine GPU, damit keine gute Ergänzung, zuviele Schnittmengen und zuviele Lücken bei den Anwendungsbereichen.

Das Potenzial ist also durchaus da, dort hinzukommen, wo Intel CPUs für 300 $ verkauft. Die Frage ist, besteht der Wille oder glaubt AMD nicht mehr an sich selbst?
 
Es wird auf effiziente Maximalperformance hin optimiert. Die Performance ist ebenso Teil der Gleichung wie der Verbrauch. Ohne Performance keine Effizienz. Warum das für dich heisst Maximal-Performance zu opfern ist für mich nicht nachvollziehbar - schau dir doch mal Maxwell Benchmarks an und du siehst deine Theorie widerlegt. Du hast die Strategie somit falsch verstanden.

Zwischen maximaler Performance und Effizienz besteht ein gewisser Trade-off: Gehst du von einem fixen Design aus, und willst es auf Effizienz trimmen, dann wird der maximal mögliche Takt (=Maximalperformance) geringer ausfallen, als wenn ich das Design auf Maximalperformance (=möglichst hohe Takte) optimiere. Im zweiten Falle wird das Ding bei gleichem Takt weniger effizient arbeiten, als die auf Effizienz optimierte Variante.
 
Naja, wenn AMD in zukunft den niedrigen TDPs hinterher rennt, wie sie es bei Carrizo (max. 65W) wohl auch machen, wird das mMn. sowie so nichts mehr.

So weit ist man mit etwa 65W TDP aber gar nicht weg. Wenn man sich Intels Quadcores ansieht, spielt sich die reale Leistungsaufnahme gar nicht so weit entfernt davon ab bzw. bieten sie Quadcores mit ~3GHz mit 65W TDP an, also (bis vor wenigen Monaten, also vor Devil's Canyon, von denen gibts aber keine 65W TDP Versionen soweit ich weiß) nur ~500MHz (bzw. unter 20% weniger Takt) unter den (Quadcore) Topmodellen. Also wenn AMD mit der Energieeffizienz in ähnliche Bereiche vordringt (primär auf die CPU bezogen), sind ~65W TDP schon halbwegs ausreichend, um wieder den mMn so wichtigen 200 bis 300 Euro Bereich (u.A. auch aus Imagegründen) bedienen zu können (Ich stimme aber zu, dass die ~100W TDP auch kein Fehler wären).
Für das "richtige" High-End, also wo aktuell Intels Sechskerner aufwärts verkauft werden, reicht das natürlich nicht, aber diesen Preisbereich sehe ich auch nicht als so essentliell an, wie das "Consumer-High-End" (i7-4770 & Co. bzw. 200 bis 300 Euro Bereich) - das ist aber natürlich nur meine persönliche Meinung.

LG
 
Zwischen maximaler Performance und Effizienz besteht ein gewisser Trade-off: Gehst du von einem fixen Design aus, und willst es auf Effizienz trimmen, dann wird der maximal mögliche Takt (=Maximalperformance) geringer ausfallen, als wenn ich das Design auf Maximalperformance (=möglichst hohe Takte) optimiere. Im zweiten Falle wird das Ding bei gleichem Takt weniger effizient arbeiten, als die auf Effizienz optimierte Variante.
Doch dafür hat AMD ja zwei Desinglinien. Also muss man nicht davon ausgehen, dass der Kaveri Nachfolger im Low-Powerbereich effizienter wird und keine Performance Steigerung angestrebt wird.

Ich denke was das Powerbudget und den derzeitigen Effizienz-Wahn angeht gibt es einen einfach Grund dafür. Denn betroffen sind wirklich alle CPU/GPU Hersteller von diesem Trend, der ja nicht plötzlich eingesetzt hat, sondern Jahre zuvor die Designentscheidung in die Richtung getroffen wurde. Derzeit limitiert einfach das I/O und Bandbreiten wenn Transfers innerhalb des Systems gemacht werden. Deshalb rückt alles näher zusammen um noch mehr Performance raus holen zu können.

Die Entwicklungen bei HBM und HSA lassen auf sich warten und brauchen ihre Zeit. Derzeit bringt man höhere CPU Performance einfach nicht "auf die Strasse" im Desktop - man kann aber auch nicht aufhören zu entwickeln. So verbessert man eben die Effizienz so weit wie irgend möglich, um dann wenn man die Flaschenhälse mit marktreifen Lösungen beheben kann (z.B. HBM ist für die APU wohl eine Schlüsseltechnik im Desktop und mobile Markt) ein möglichst hohes Powerbudget hat um dann die Leistung hoch zu schrauben - es wirkt wie ein positionieren derzeit.
 
Ich weiß nur nicht, ob das was Gutes für Zen bedeutet... K12 wird bestimmt der stärkste ARM, den die Welt gesehen hat, aber Zen ist evtl. auch nur auf Kaveri-Niveau (mit sicherlich besserer Effizienz) und kein Performancefortschritt. Was ihn dann auch unbrauchbar für unsereins machen würde. :(

Warum kein Performancefortschritt gegenüber Kaveri? Kaveri ist doch schwach mit seinen 4 Threads, nur wenig schneller als eines der letzten K10 mit 4 Threads...
Sind wir mal ehrlich, nach der großen BD Pleite will AMD laut Gerüchten 2016 eine neue Architektur vorstellen die das ganze besser machen soll, wenn diese neue Architektur nicht zwischen 30-50% schneller ist, (wir reden hier von 2016, also 5 Jahre nach dem BD Start), dann hat AMD erneut ein Fiasko zu verantworten!!!
Nicht vergessen, wenn diese Kerne auf Max. Performance ausgelegt sind, dann wäre man auch im Server Bereich damit konkurrenzfähig, sowas hatte mal AMD mit BD geplant, jetzt wäre doch mit ZEN vielleicht mal wieder ein Versuch wert diesen Schritt Erfolgreich abzuschließen, damit die Marktanzteile von 5% auf 20% steigen, hier ist die Marge viel höher als bei den APUs. Ich denke Zen wird ein 4 ALU+4 AGU Design mit SMT & 512 Bit FPU werden. Alles andere hätte wegen der Software zuwenig Chancen, hohe Singlethread Performance ist das beste.
 
Zuletzt bearbeitet:
Zum Instructiondecoder von ARM CPUs.
Papers zum Decoder selbst gibt es vermutlich nicht. Was die Codierung der Instruktion betrifft, da ist schon eher was verfügbar, zB hier.


Kaveri ist doch schwach mit seinen 4 Threads
Nein, ist er nicht. Wenn es so wäre, dann ist ein i3 mit seinen 4 Threads auch schwach.

hohe Singlethread Performance ist das beste.
Nein. Wie kann etwas das beste sein, was >95% des Marktes nicht brauchen? Ergibt keinen Sinn.
 
Zuletzt bearbeitet:
Hohe Singlethread Performance bedeutet auch hohe Multithread Performance, das ist genau das was Intel macht.
Warte mal auf die neuen Intel Core M mit Broadwell Architektur.
 
Hohe Singlethread-Performance heisst in vielen Fällen aber auch weniger Kerne im selben Powerbudget, was dann in einer schlechteren Gesamtperformance resultieren kann. (Siehe Server-SKUs)
 
Hohe Singlethread Performance bedeutet auch hohe Multithread Performance, das ist genau das was Intel macht.
Intel hat alles andere als hohe multithreaded Performance. Deren multithreaded Performance ist aufgrund von HTT ziemlich grottig. Auf multithreaded Performance kommen die nur dank vieler Kerne und nicht wegen hoher singlethreaded Performance. Du kannst auch Unmengen an A53 Kernen auf ein Die klatschen um auf multithreaded Performance zu kommen. Das wäre im Moment eventuell sogar effizienter als alles was Intel zu bieten hat.
 
Zurück
Oben Unten