Spekulation zu AMDs "Steamroller" - 3. Modul Generation

Complicated

Grand Admiral Special
Mitglied seit
08.10.2010
Beiträge
4.949
Renomée
441
Mit Einführung der "Bulldozer" basierenden "Zambezi" CPU, hat AMD auch eine weiterführende ehrgeizige Roadmap vorgestellt wie die neue Modulbasierende Architektur sich weiter verbessern soll und jedes Jahr für mehr Performance sorgen soll:

Anhang anzeigen 26013

Auf der heutigen Hotchips Konferenz kamen einige Interessante Details über den Nachfolger des Piledriver durch den neuen CTO Mark Papermaster zur Sprache - hier einige Folien:

Anhang anzeigen 26014 Anhang anzeigen 26015 Anhang anzeigen 26016 Anhang anzeigen 26017

Das wohl gravierendste ist, dass mit Steamroller jeder Integer Kern wieder einen eigenen Decoder erhält, die unabhängig arbeiten und somit das Frontend deutlich verbessert wird.
Dies resultiert natürlich in höherem Stromverbrauch, den AMD offensichtlich mit einer neuen Design Technik in den Griff bekommt, die auf der letzten Folie illustriert wird:

Anhang anzeigen 26018

Durch eine neue Design Methode, die aus der GPU Sparte entliehen wurde, und auch schon bei Bobcat Anwendung fand, wird der Platzbedarf um ca. 30% reduziert und der Strombedarf um ca. 15-30 % - das Bild zeigt einen Teil der FPU des selben Bulldozer Designs. Nachteil dieser hoch automatisierten Lösung sind weniger hohe Spitzen-Taktraten. Man darf gespannt sein was dies in der Praxis bedeutet.

Update:
AMD-Steamroller-vs-Bulldozer.jpg

http://wccftech.com/amd-kaveri-apu-...neration-apu-featuring-steamroller-gcn-cores/
 
Zuletzt bearbeitet:
Ups sorry . ..kannst meine Beitrag dann verschieben wenn du möchtest :)
Allerdings bekomme ich keinen Zugriff auf deinen Beitrag im Forum :(
 
Nene, das passt schon, da können wir ruhig nen extra Thread hier haben, die News-Threads versumpfen ja oft. Ich verlink Dich mal noch in der News :)
 
@Opteron

Kannst du mal deinen Link in Beitrag #2 kontrollieren? Der geht bei mir nicht.

Zum Thema, ich weiss nicht, ob man die "30% Ops per Cycle Improvement" einfach als IPC Verbesserung betrachten kann, unabhängig vom x86-uOp-Verhältnis. Die Folie steht ja unter der Überschrift "Feed the cores faster". Ich interpretiere die 30% erstmal so, dass das Frontend 30% mehr Ops pro Takt ausspuckt. Was das Backend damit anfängt und wie die IPC im Endeffekt damit verbessert wird, ist eine andere Geschichte.



Ansonsten hören sich die Details sehr gut an. Ob ein Trace-Cache im Moment wirklich Sinn macht, sei mal dahingestellt. Der ist schliesslich nicht kostenlos und mit einigem Aufwand verbunden. Ein Loop-Puffer war aber längst überfällig.

Wenn die Decoder-Einheiten 4-way bleiben, sollten auch keine Performancenachteile bei lediglich einem Thread entstehen. Im Gegenteil, dadurch, dass FP von beiden Decoder-Einheiten verarbeitet werden kann, wären dann sogar bis zu 8 x86 Ops bei einem Thread möglich.

Was sich konkret hinter "Floating point rebalance" verbrigt, ist mir noch unklar. Ich hoffe nicht, dass man damit nur die Wegrationalisierung einer MMX Einheit meint. Schön wäre es, wenn man pro FMAC nun FADD und FMUL ausführen könnte und nicht nur FADD oder FMUL.

Interessant auch die Flächen- und Energieersparnis durch die High-Densitiy Bibliothek. Man dürfte ja anhand der Die Shots erkennen können, ob das bei Steamroller schon zum Einsatz kommt. Wäre sicherlich nicht das schlechteste, um in 28 nm mit den 22 nm Gegnern zu konkurrieren.
 
Zuletzt bearbeitet:
Was sich konkret hinter "Floating point rebalance" verbrigt, ist mir noch unklar. Ich hoffe nicht, dass man damit nur die Wegrationalisierung einer MMX Einheit meint. Schön wäre es, wenn man pro FMAC nun FADD und FMUL ausführen könnte und nicht nur FADD oder FMUL.
Genau das scheint hier gemeint zu sein. Eine MMX Einheit wurde wohl gestrichen, jedoch mit der Möglichkeit eine FMAC Einheit auch MMX ausführen lassen zu können. Anand scheint allerdings der Mennung zu sein, dass die MMX Einheiten sowieso nur schlecht ausgelastet waren und daher kein Tradeoff zu befürchten ist.
http://www.anandtech.com/show/6201/amd-details-its-3rd-gen-steamroller-architecture
The MMX unit now shares some hardware with the 128-bit FMAC pipes. AMD wouldn’t offer too many specifics, just to say that the shared hardware only really applied for mutually exclusive MMX/FMA/FP operations and thus wouldn’t result in a performance penalty.

The reduction of pipeline resources is supposed to deliver the same throughput at lower power and area, basically a smarter implementation of the Bulldozer/Piledriver FPU.

Was die Möglichkeit von 8 x86 Ops angeht durch die beiden 4-way Decoder, schreibt Anand, dass die Decoder weit weg von einer vollen Auslastung sind, so dass es so gut wie überhaupt nicht zu dem theoretischen Idealfall kommt - man solle also keine Verdoppelung erwarten, auch wenn es eine deutliche Steigerung des Durchsatzes gibt.
 
@Opteron

Kannst du mal deinen Link in Beitrag #2 kontrollieren? Der geht bei mir nicht.
Danke, das war noch der falsch, hatte gestern Nacht ausversehen die News im internen Unterforum gepostet ^^

Zum Thema, ich weiss nicht, ob man die "30% Ops per Cycle Improvement" einfach als IPC Verbesserung betrachten kann, unabhängig vom x86-uOp-Verhältnis. Die Folie steht ja unter der Überschrift "Feed the cores faster". Ich interpretiere die 30% erstmal so, dass das Frontend 30% mehr Ops pro Takt ausspuckt. Was das Backend damit anfängt und wie die IPC im Endeffekt damit verbessert wird, ist eine andere Geschichte.
Glaub ich eher nicht, BDs IPC ist aktuell ja wirklich grottig, irgendwas unter 1, sagen wir mal max 1,0. Für ein 2issue-Design ne ziemlich schlechte Auslastung. Das heißt im Umkehrschluss dann aber auch, dass die 2 ALUs mit +30% OPs aus dem Fron-End keine Probleme haben sollten. Gibt bei den Exec. Units ja ebenfalls auch wieder dickere Puffer.

Also da bin ich optimistisch. BDs IPC ist grottig, da muss ein (deutlich) besseres Front-End samt loop-Cache schon einiges reisen.


Wenn die Decoder-Einheiten 4-way bleiben, sollten auch keine Performancenachteile bei lediglich einem Thread entstehen. Im Gegenteil, dadurch, dass FP von beiden Decoder-Einheiten verarbeitet werden kann, wären dann sogar bis zu 8 x86 Ops bei einem Thread möglich.
Ich geh da eher von 2x3way aus. Was will man bitte mit 2x4, also dem doppelten Decoder-Durchsatz, wenn die Dispatch-Rate nur um 25% steigt? Also vermutlich von 4 Mops auf 5 Mops? Das wäre ziemlicher Käse, erst recht, wenn man zusätzlich auch noch den loop-cache hat.

Interessant auch die Flächen- und Energieersparnis durch die High-Densitiy Bibliothek. Man dürfte ja anhand der Die Shots erkennen können, ob das bei Steamroller schon zum Einsatz kommt. Wäre sicherlich nicht das schlechteste, um in 28 nm mit den 22 nm Gegnern zu konkurrieren.
Siehe das Edit vom heute, laut anadtech erstmal nicht. Aber obs stimmt ... *noahnung*
 
Was sich konkret hinter "Floating point rebalance" verbrigt, ist mir noch unklar. Ich hoffe nicht, dass man damit nur die Wegrationalisierung einer MMX Einheit meint. Schön wäre es, wenn man pro FMAC nun FADD und FMUL ausführen könnte und nicht nur FADD oder FMUL.
Das würde absolut Sinn machen. Auch hält sich der bisherige Code-Anteil von FMA3/4 vermutlich sehr in Grenzen.

Genau das scheint hier gemeint zu sein. Eine MMX Einheit wurde wohl gestrichen, jedoch mit der Möglichkeit eine FMAC Einheit auch MMX ausführen lassen zu können.
Oder der umgekehrte Fall: eine MMX-Einheit auch ein einfaches FADD oder FMUL ausführen zu lassen. Anand schreibt lediglich:
The MMX unit now shares some hardware with the 128-bit FMAC pipes. AMD wouldn’t offer too many specifics, just to say that the shared hardware only really applied for mutually exclusive MMX/FMA/FP operations and thus wouldn’t result in a performance penalty.
In das "mutually exclusive" kann man ja einiges hineininterpretieren.
 
Ich denke jetzt wohl zu quer, aber trotzdem:
Angenommen zu den propagierten +15% Performance/Watt Improvements kommt nichts mehr durch den neuen Prozess hinzu und angenommen es schauen tatsächlich +30% IPC Steigerungen heraus, hieße dass dann, dass den man Takt bei gleicher TDP gegenüber den aktuellen Modellen (unter voller Auslastung) senken müsste?
Irgendetwas passt da nicht zusammen. Bitte klärt mich über meinen Fehler auf :)

LG
 
Welcher neue Prozess? Es ist immer noch 32 nm. ;)

Und wenn ich 15% Performance mehr/Watt angebe, spielt die Frequenz eigentlich eine untergeordnete Rolle. 100 W TDP mit 15% mehr Performance bleibt mehr Performance - das war ja auch erklärtes Ziel der 3. Generation (nicht vergessen Bulldozer->+15% -> Piledriver ->+15% ->Steamroller)

Nur denke ich dass im Mainstream da nochnganz andere Steigerungen stattfinden werden - früher hat man ja immer nur die schnellsten Modelle verglichen und Steigerungen nur an diesen fetsgemacht.

So wie ich das verstehe führt die +30 IPC Steigerung nicht dazu dass Frequenzen niedriger sein müssen - man hat sich lediglich von den sowieso nicht erreichten Hochfrequenz Modellen verabschiedet (waren ja mal über 4 GHz im Raum für das Design)
 
Zuletzt bearbeitet:
Welcher neue Prozess? Es ist immer noch 32 nm. ;)
Das bezweifle ich.
.
EDIT :
.

Er meint wohl, dass es aktuell außer dem 32nm Prozeß noch keinen neueren gibt.
Aber in der Entwicklung wird wohl doch schon mit 28nm gearbeitet.
 
Es bleibt der selbe 32nm SOI Prozess bei Steamroller.
http://www.bit-tech.net/news/hardware/2012/08/29/amd-steamroller/1
Many of these, including a claimed 30 per cent reduction in the layout area of the cores and a corresponding drop in power draw, come from a shift in design methodology at AMD: where previous Bulldozer cores were laid out by hand to maximise performance and density on the 32nm process, the company is now using a high-density cell library for layout - resulting in the same level of improvement normally associated with a drop in process size.
Die High-Density Cell Bibliotheken sorgen lediglich für den selben Umfang an Verbesserung, welche durch einen neuen Prozess entstehen würden. Ohne den Prozess tatsächlich zu wechseln.
 
Ich weiß nicht, wie es in Amerika gelaufen ist, aber hier gab es kein Briefing zu den Folien. Dass Steamroller in 28nm gefertigt wird, steht aber mit an Sicherheit grenzender Wahrscheinlichkeit fest - nicht aber bei welchem Foundry-Partner. Das steht so auf den öffentlichen Roadmaps.
Ich gehe daher von ein Fehlinterpretation aus.

file.php
 
Ok ich denke das war mein Fehler - Steamroller in APUs wird mit Sicherheit in 28nm kommen. Ich dachte eher an den Zambezi Nachfolger mit Steamroller Kernen. Zumindest habe ich das so interpretiert aus den Berichten, dass dieser weiter in 32nm kommen wird.

(nun bin ich mal selber in die Codenamensfalle getappt :) )

Edit: Wobei bei genauer Betrachtung es wohl auch heissen könnte, dass der Übergang von 32nm auf 28nm nicht als echte Prozessverkleinerung gewertet wird. Ein Fullnode ist es ja sowieso nicht.
 
Der Nachfolger von Zambezi ist Vishera und der setzt auf Piledriver-Kerne.

Zudem basiert ja Vischera bekanntlich auf der Rev C vom Orochi-Die.

Beide werden in 32nm bei GF gefertigt.

Der Nachfolger von Vishera wird sicherlich auf den angekündigten 28nm Server-Prozessoren basieren.

file.php



In diesem Video macht er keine genaueren Angaben zu den Randbedingungen. Es ist halt der (rein theoretische?) Vergleich zwischen den Handoptimierungen und dieser neuen, optimierten Bibliothek:

 
Nochmal zu meiner Frage - anders formuliert:

Wenn ich die IPC um 30% steigere, komme ich bei gleichem Takt auf "130% Performance."
Wenn ich die Performance/Watt um 15% steigere, komme ich bei gleicher Leistungsaufnahme(grenze) auf "115% Performance".
Dass hieße, ich bekomme die Performancesteigerung durch die höhere IPC in meinem "Watt-Budget" nicht unter.
Wo ist denn hier mein Denkfehler? Nachtrag nach gruffis Post: Oder gibts keinen Denkfehler?

LG
 
Zuletzt bearbeitet:
Was die Möglichkeit von 8 x86 Ops angeht durch die beiden 4-way Decoder, schreibt Anand, dass die Decoder weit weg von einer vollen Auslastung sind, so dass es so gut wie überhaupt nicht zu dem theoretischen Idealfall kommt - man solle also keine Verdoppelung erwarten, auch wenn es eine deutliche Steigerung des Durchsatzes gibt.
Schon klar, dass keine Verdoppelung zu erwarten ist. Die Menge von Nicht-FP x86 Instruktionen ist bei einem normalen Codemix ja immer noch klar grösser.
Meine Befürchtung war nur, dass man aus einem 4-fach Decoder zB zwei 3-fach Decoder macht, was eben bei singlethreaded nachteilig gewesen wäre. Wenn vielleicht auch nicht allzu viel. Durch die Arbeitsweise der Steamroller Decoder sollten im Vergleich zum jetzigen Decoder aber eher noch ein paar Prozent mehr drin sein bei singlethreaded. Fragt sich halt nur, was der zusätzliche Decoder letztendlich an Energie kostet.


Ich geh da eher von 2x3way aus. Was will man bitte mit 2x4, also dem doppelten Decoder-Durchsatz, wenn die Dispatch-Rate nur um 25% steigt? Also vermutlich von 4 Mops auf 5 Mops? Das wäre ziemlicher Käse, erst recht, wenn man zusätzlich auch noch den loop-cache hat.
Da steht allerdings 25% pro Thread. Es ist zwar nicht explizit auf den Folien zu sehen, aber eigentlich müssten auch zwei Dispatcher Einheiten vorhanden sein. Warum sollte man also den Dispatcher um 25% aufbohren, wenn man den Decoder abspeckt? Macht für mich wenig Sinn. Da müsste vorher schon eine extreme Imbalance vorhanden gewesen sein. Glaube ich eher weniger. Also ich gehe erstmal davon aus, dass es bei 4-fach bleibt. Auch wenn 3-fach sicherlich eine weitere realistische Möglichkeit ist.

Machen wir doch mal eine vereinfachte Rechnung. Aktuell kann der Dispatcher 4 uOps pro Takt verarbeiten. 25% mehr wären also 5 uOps.
Ein 3-fach Decoder kann pro Takt 3 x86 Instruktionen verarbeiten, die normalerweise je 1-2 uOps ergeben, also 3-6 uOps insgesamt. Das müsste also ein Mix von 1/3 1 uOps x86 Instruktionen und 2/3 2 uOps x86 Instruktionen sein, um den Dispatcher optimal auszulasten. 2 uOps x86 Instruktionen sind idR jene, die Speicheroperationen erfordern. Bei einem gängigen Codemix erscheinen mir 2/3 zu viel. Wir hatten hier schon mal eine Diskussion, wie viele Speicherinstruktionen gängig sind. Das war aber bezogen auf die IBM Architektur, IIRC, und lag irgendwo bei um die 50%. Also für einen 3-fach Decoder scheint mir ein 5 uOps Dispatcher eher überdimensioniert. Zumal zu bedenken ist, dass eh nicht in jedem Takt die maximale Anzahl an x86 Instruktionen dekodiert werden können.

Siehe das Edit vom heute, laut anadtech erstmal nicht. Aber obs stimmt ... *noahnung*
Eben. Ich sehe das jetzt nicht als offizielle Bestätigung, sondern als Spekulatius.


Nochmal zu meiner Frage - anders formuliert:

Wenn ich die IPC um 30% steigere, komme ich bei gleichem Takt auf "130% Performance."
Wenn ich die Performance/Watt um 15% steigere, komme ich bei gleicher Leistungsaufnahme(grenze) auf "115% Performance".
Dass hieße, ich bekomme die Performancesteigerung durch die höhere IPC in meinem "Watt-Budget" nicht unter.
Wo ist denn hier mein Denkfehler?
IPC Steigerungen gibt's nicht umsonst. Die kosten natürlich auch Transistoren und Energie. Die 15% mehr Performance/Watt beziehen sich aber wohl auf den gleichen Prozess. Mit einem besseren Prozess kann man natürlich das Powerbudget erweitern.
 
Eine IPC Steigerung von 30% bedeutet doch nicht automatisch, dass auch der Verbrauch um 30% steigt.
Zudem hat man einen neuen 28nm Prozeß, der hoffentlich auch was zur Leistungssteigerung beiträgt.
 
AMD hat meiner Interpretation und der von Volker nach den Prozess bei den "up to" 15 Prozent bereits eingerechnet, was auch gut passt. Denn CPUs basierend auf Steamroller werden im Desktop wie Server höchstwahrscheinlich bei 125W bzw 95W (ohne MCM) sowie 115W (MCM) stagnieren und das bessere Perf/Watt ergibt sich schlicht aus mehr Leistung bei gleicher TDP. Die Leistung soll ja laut AMD um 10 bis 15 Prozent.

Davon ab sind die 30 Prozent ja auf das Frontend bezogen, dass das 1:1 durchschlägt, ist sehr optimistisch - denn dann hätte AMD drei Chips (BDv1, BDv2 und Trinity) mit einem völlig unbrauchbaren Frontend ins Rennen geschickt.
 
Da steht allerdings 25% pro Thread.
Ja aber das ist in dem Zusammenhang unsinn, da es ja bisher keine Thread-Unterschiede im Front-End gab. Wenn man das Mittel nimmt, als quasi 2 MOps, dann kommt man auf 2,5 Mops, kA was die halbe Mop sein soll. Macht eigentlich nur Sinn, wenn mans auf die 4 bezieht. Aber mit etwas verquerer Logik könnte man maximal von nem 6er Dispatch ausgehen. Würde auch prima zu 2x3way Decodern passen.

Es ist zwar nicht explizit auf den Folien zu sehen, aber eigentlich müssten auch zwei Dispatcher Einheiten vorhanden sein.
Das ist ne Preisfrage, ich glaube eher nicht, z.B. wegen der gemeinsam benützten FPU. Wenn man zu der jetzt von 2 Dispatchern jeweils 2Paar Leitungen legen würde, wär das wohl ne ziemliche Verschwendung. Was spräche denn für nen gemeinsamen Dispatch Buffer nach den getrennten Decodern? Ich seh da eigentlich keine Nachteile.

Warum sollte man also den Dispatcher um 25% aufbohren, wenn man den Decoder abspeckt?
Was meinst Du mit "abspecken"? 2x3 > 1x4. Mißverständnis? Genau das ist ja mein Argument, wieso ich 2x4 nicht glaube, dafür wäre eine 25% Dispatchsteigerung (5 Mops) oder sogar auch eine 50%ige Steigerung (6MOPs) zu wenig. Wenn der µOp-Puffer anspringt erst recht.

Machen wir doch mal eine vereinfachte Rechnung. Aktuell kann der Dispatcher 4 uOps pro Takt verarbeiten. 25% mehr wären also 5 uOps.
Ein 3-fach Decoder kann pro Takt 3 x86 Instruktionen verarbeiten, die normalerweise je 1-2 uOps ergeben, also 3-6 uOps insgesamt. Das müsste also ein Mix von 1/3 1 uOps x86 Instruktionen und 2/3 2 uOps x86 Instruktionen sein, um den Dispatcher optimal auszulasten.
Hmm, da hast Du nen Rechenfehler drin, denn die 2er Ops (Doubles) brauchen auch 2 Takte. Gibt ein Patent, in dem steht, dass ne Double durch 2 Decoder in einem Takt abgearbeitet werden könnte, aber selbst dann werden es pro Takt nicht mehr als 3 MOps


2 uOps x86 Instruktionen sind idR jene, die Speicheroperationen erfordern.
Stimmt leider auch nicht. Doubles sind recht selten. Darunter fallen nur 256er AVX Befehle und ein paar Exoteninstruktionen für XOP, AES oder was das genau war. Speicheroperationen werden doch schon seit K7-Ewigkeiten bei AMD mit der Rechenoperation in eine MOp gepackt, deswegen nennt AMD die ja MacroOp, eben weil noch mehr dabei ist. Intel macht das seit dem seligen MicroOp-Fusion (nicht MacroOp-Fusion) ebenfalls so. Wenn ich mich recht erinnere, dann wurde das schon vor Conroe eingeführt. Ausgepackt werden die dann später im oder kurz vorm Scheduler in den Exec. Units.

IPC Steigerungen gibt's nicht umsonst. Die kosten natürlich auch Transistoren und Energie. Die 15% mehr Performance/Watt beziehen sich aber wohl auf den gleichen Prozess. Mit einem besseren Prozess kann man natürlich das Powerbudget erweitern.
Stimmt, aber mit dem µOp-Puffer gibts immerhin auch noch ne Energieeinsparung bei höheren Leistung. Das Ding ist echt ne gute Erfindung, auch wenns noch Transistoren kostet.

@y33@:
Davon ab sind die 30 Prozent ja auf das Frontend bezogen, dass das 1:1 durchschlägt, ist sehr optimistisch - denn dann hätte AMD drei Chips (BDv1, BDv2 und Trinity) mit einem völlig unbrauchbaren Frontend ins Rennen geschickt.
Hast Du bessere Erklärungen, wieso der BD so schlecht ist? Machst Du alles am kleinen L1-WT fest?
Abgesehen davon haben die Exec. Units bei aktueller ca. 50%iger (oder schlechter) Auslastung mit 30% mehr Instruktionen pro Takt leichtes Spiel. Die FPU im SMT Betrieb oder bei 256bit Befehlen (die ja 2 Ops verbrauchen) natürlich ausgenommen. Aber insbesondere die INT-Leistung war bisher ja schlecht. Also grenzen wirs mal näher ein: Bei INT hoffe ich schon auf maximal +30% IPC. Bei FPU weniger und wenn AMD dann FPU und INT bei der Perf/Watt zusammenrechnet kommen im Mittel dann vielleicht die 15% raus ^^
 
Nein, der L1-WT alleine kann's nicht sein. Ich halte es nur für fraglich, dass AMD einen Chip fertigt, dessen Frontend so schwach ist, dass 30 Prozent mit Ops/Cycle eins zu eins die Leistung steigern. 15 Prozent mehr IPC - glaub ich auch eher nicht dran, dann waren AMDs Prognosen bisher sehr optimistisch.
 
Nein, der L1-WT alleine kann's nicht sein.
Eben, dann die nächste Frage: Was kanns dann sein? Da bleibt man zwangsläufig beim FrontEnd hängen.
Ich halte es nur für fraglich, dass AMD einen Chip fertigt, dessen Frontend so schwach ist, dass 30 Prozent mit Ops/Cycle eins zu eins die Leistung steigern. 15 Prozent mehr IPC - glaub ich auch eher nicht dran, dann waren AMDs Prognosen bisher sehr optimistisch.
Wie besagt, bei INT hab ich mit der Prognose max +30% keine Probleme. FPU weniger, schon aus dem Grund, da die 256bit Instruktionen 2 Ops brauchen. In dem Fall bleiben dann von 30% mehr Ops also nur +15% übrig. Aber eigentlich sollte die FPU durch den SMT-Betrieb auch aktuell schon gut ausgelastet sein. Immerhin hält sie auch ohne FMA-Code gut mit nem X6 mit, der 6 FPUs hat.
 
AMD hat meiner Interpretation und der von Volker nach den Prozess bei den "up to" 15 Prozent bereits eingerechnet, was auch gut passt. Denn CPUs basierend auf Steamroller werden im Desktop wie Server höchstwahrscheinlich bei 125W bzw 95W (ohne MCM) sowie 115W (MCM) stagnieren und das bessere Perf/Watt ergibt sich schlicht aus mehr Leistung bei gleicher TDP. Die Leistung soll ja laut AMD um 10 bis 15 Prozent.

Davon ab sind die 30 Prozent ja auf das Frontend bezogen, dass das 1:1 durchschlägt, ist sehr optimistisch - denn dann hätte AMD drei Chips (BDv1, BDv2 und Trinity) mit einem völlig unbrauchbaren Frontend ins Rennen geschickt.
Du bzw. dieser Volker vergesst (an dieser Stelle, ausnahmsweise), dass AMD mit Bulldozer in mancherlei Hinsicht im Ergebnis einen beträchtlichen Rückschritt gemacht hat. Ein Ruck von 30% Mehr-Performance nach Beseitigung der gröbsten Flaschenhälse ist da durchaus im Rahmen des Möglichen (und würde höchstwahrscheinlich bei weitem nicht dazu ausreichen, zu den Kontrahenten aus dem Hause Intel aufzuschließen). Man bedenke, dass seit K10 zahlreiche technologische Neuerungen, z.B. Instuktionssets, verbesserter Turbo-Modus, verbesserte Sprungvorhersage, etc. hinzgekommen sind, die bisher nur kaum bis wenig dazu beigetragen haben, die BD-Performance von K10-Abkömmlingen abzuheben.
Insofern liegen euere "Interpretationen", wenn auch sehr konservativ angesetzt, genauso im luftleeren Raum wie so mancherlei Schrieb über die +15% Performance des Haswell.
 
Es wäre schön, wenn es DIE Bremse gab und AMD sie bei der dritten BD-Stufe dann doch gelöst hat. Bis dahin halte ich mich an AMDs eigene Aussage und die lautet 10 bis 15 Prozent mehr Leistung und damit einhergehend "up to" 15 Prozent mehr Perf/Watt, was ich beides auch für realistisch halte.
 
Zurück
Oben Unten