News Bulldozer-Architektur unter der Lupe: Schwachstellen identifiziert

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
<div class="newsfloatleft"><a href=""><img src="http://www.planet3dnow.de/photoplog/images/54308/1_AMD-Logo.png" border="0" alt="AMD-Logo"></a></div>Viele Mikroarchitektur-Interessierte und hardwarenahe x86-Programmierer kennen bereits die x86-Optimierungsleitfäden sowie CPU-Architekturdiagnosen von Dr. Agner Fog von der Universität Kopenhagen. Nun hat er seine PDFs um AMDs Bulldozer-Architektur ergänzt. <p style="clear:left;"></p>

Hier nun die schlimmsten Flaschenhälse im Überblick:

<b>Instruktions-Dekoder 1</b>
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>Instructions with up to three prefixes can be decoded in one clock cycle. There is a very large penalty for instructions with more than three prefixes. Instructions with 4-7 prefixes take 14-15 clock cycles extra to decode. Instructions with 8-11 prefixes take 21-22 clock cycles extra, and instructions with 12-14 prefixes take 28 clock cycles extra. It is therefore not recommended to make NOP instructions longer with more than three prefixes. The prefix count for this rule includes operand size, address size, segment, repeat, wait, REX and XOP prefixes. A three-bytes VEX prefix counts as one, while a two-bytes VEX prefix does not count. Escape codes (0F, 0F38, 0F3A) do not count.</i></td></tr></tbody></table></div>Hier wird eine Schwachstelle beschrieben, bei der (sehr) lange x86-Instruktionen ab drei Präfixen einen starken Anstieg der Verweildauer im Dekoder verzeichnen. Mit mindestens 14 Takten zusätzlich und maximal gar 28 Takten ist in diesen Fällen zu rechnen, was ziemlich viel ist. In dieser Zeit könnte schon das Ergebnis der Berechnung feststehen - wenn der Dekoder eben nicht so langsam arbeiten würde.

<b>Instruktions-Dekoder 2</b>
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The decode unit can handle four instructions per clock cycle. It is alternating between the two threads so that each thread gets up to four instructions every second clock cycle, or two instructions per clock cycle on average. This is a serious bottleneck in my tests because the rest of the pipeline can handle up to four instructions per clock. The situation gets even worse for instructions that generate more than one macro-op each. Instructions that generate two macro-ops are called double instructions.
The decoders can handle one double instruction and two single instructions in one clock cycle, but not two double instructions. Instructions that generate more than two macro-ops are using microcode.
The decoders cannot do anything else while microcode is generated. This means that both cores in a compute unit can stop decoding for several clock cycles after meeting an instruction that generates more than two macro-ops. The number of macro-ops generated by each instruction is listed in manual 4: "Instruction tables". </i></td></tr></tbody></table></div>
Schon früher tauchte die Vermutung auf, dass der - von beiden Kernen gemeinsam benutzte - Dekoder zu wenig Befehle dekodieren kann. Pro Takt und pro Kern schafft er im Schnitt maximal nur zwei x86 Instruktionen. Im schlimmsten Fall, falls externe x86-Instruktionen in mehr als eine CPU-interne Macro-Instruktion (Macro-Op) übersetzt werden müssen, sinkt der Durchsatz aber. Bei Befehlen, die durch die Microcode-Engine dekodiert werden müssen, steht der ganze Dekoder außerdem für ein paar Takte komplett still und blockiert damit den zweiten Kern.

Nun könnte man darauf hoffen, dass vielleicht MacroOp-Fusion, das Intel mit den Conroe-Chips (erste Generation der Core2 Duos) einführte und erstmals nun auch bei AMD im Bulldozer Verwendung findet, Abhilfe schaffen würde. Schließlich werden dabei zwei x86-Instruktionen zu einer Macro-Op dekodiert. Leider ist das aber bei AMD nicht der Fall:

<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>No other ALU instruction can fuse with a conditional jump.<b> The maximum decode rate is not increased by instruction fusion. </b></i></td></tr></tbody></table></div>
Warum das so ist, wird nicht erklärt. Eventuell liegt es daran, dass die Bündelung bei AMD erst nach dem Dekoder passiert, während sie bei Intel davor passieren könnte.


<b>Execution units </b>
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The integer execution units are poorly distributed between the four pipes. Two of the pipes have all the execution units while the other two pipes are used only for memory read instructions, and on some models for simple register moves. This means that the Bulldozer can execute only two integer ALU instructions per clock cycle, where previous models can execute three. This is a serious bottleneck for pure integer code. The single-core throughput for integer code can actually be doubled by doing half of the instructions in vector registers, even if only one element of each vector is used. </i></td></tr></tbody></table></div>
Hier wird nun auf das altbekannte Dilemma eingegangen, dass es von den - offiziell vier - Pipelines trotz optimistischer Zählweise eigentlich doch nur zwei sind, die die Arbeit verrichten, also eine weniger als bisher bei den letzten Chips der "K"-Generationen. In Zukunft, mit den 20h-Modellen (<a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1328302051">siehe dazu auch unsere frühere Meldung</a>), wird dies zwar etwas besser werden, aber eine Offenbarung ist das ebenfalls noch nicht. Es bleibt die Hoffnung auf Steamroller - falls es sich dabei nicht schon die 20h-Modelle handeln sollte.

<b>L1-Daten Cache [aktualisierte Version]</b>
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The data cache has two 128-bit ports which can be used for either read or write. This means that it can do two reads or one read and one write in the same clock cycle. The measured throughput is two reads or one read and one write per clock cycle when only one core is active. We wouldn't expect the throughput to be less when both cores are active because the two cores in an execution unit have separate load/store units and data cache. But the measurements say otherwise. The measured throughput is typically 1.5 memory operation per core per clock, and the highest value that has been measured is 1.88 memory operation per core per clock when both cores are active. No explanation has been found for this reduced throughput. The decoders, which are shared between cores, should be able to handle two instructions per core per clock cycle.
</i></td></tr></tbody></table></div>Hier wird es nun interessant. Jeder Integer-Kern eines Bulldozer Moduls hat bekanntermaßen seinen eigenen L1-Datencache von 16kB, die unabhängig voneinander sind. Pro Takt können laut AMD-Manual zwei 128-Bit-Lesevorgänge (Load) und eine 128-Bit-Schreiboperation (Store) vorgenommen werden:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The load/store unit completes all memory accesses once address generation has occurred in the execution. The L1 data cache is a 16-Kbyte, way-predicted, write-through cache designed to support up to two 128-byte loads per cycle. In addition, one 128-byte store can be committed to the cache. Load-use latency is four cycles, and loads proceed in a fully out-of-order fashion.</i></td></tr></tbody></table></div><FONT SIZE=-2>Quelle: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5751937&tag=1</FONT>

Dem widerspricht Agner Fog nun. Mit einem aktiven Kern kann er nur maximal 2 Operationen messen, entweder zwei Load oder eine Load-/ und ein Storeoperation. Diese Diskrepantz läßt sich noch einfach auflösen. Da es nur zwei AGUs zur Adressberechnung gibt, kann es wirklich nur zwei unterschiedliche Adressen pro Takt geben. Der Unterschied liegt dann eigentlich nur in der nicht berücksichtigten Bandbreite. Die von AMD angegebenen zwei 128-Bit Loads beziehen sich sicherlich auf zwei 128-Bit-Load-Ports, die zusammen genommen auch einen 256-Bit Ladevorgang bewältigen können. Dafür reicht dann eine Adresse und die zweite Adresse kann für eine Store-Operation verwendet werden. Soweit so gut, merkwürdig wird es dann aber mit zwei gleichzeitig aktiven Kernen eines Moduls. Anstatt theoretisch möglichen zwei Speicheroperationen sind es im Mittel mit zwei aktiven Kernen nur noch 1,5 Speicheroperationen pro Kern, maximal 1,88. Nachdem die beiden Kerne eigentlich unabhängig voneinander sein sollten, erwartet man so einen Fall nicht. Eine Teilerklärung ist vielleicht die Write-Through-Arbeitsweise der L1-Caches. Das bedeutet, dass Store-Speicheroperationen auch unverzüglich in den gemeinsam genutzen L2 geschrieben werden müssen. Allerdings gibt es eben nur einen einzigen L2-Cache und nur einen Write-Combining-Puffer um darauf schreibend zugreifen zu können. Summiert man die max. möglichen Operationen beider Kernen auf und geht deshalb von theoretisch möglichen vier Speicheroperationen pro Modul aus, passen die typisch-gemessenen drei Operationen pro Modul / zwei Threads gut dazu. Es fehlt genau eine Operation - höchstwahrscheinlich eine Store-Operation. Allerdings sollten vier Ladeoperationen ohne Problem möglich sein. Woran es liegen kann, dass es maximal trotzdem nur 1,88 Operationen sind und nicht 2, ist unbekannt und merkwürdig. Der Sinn der beiden Kerne ist schließlich, sich <I>nicht</I> gegenseitig zu behindern bzw. auf die Füße zu treten.

<b>L1-Daten Cache [alte, falsche Version]</b>
[STRIKE]<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The data cache has two 128-bit ports which can be used for either read or write. This means that it can do two reads or one read and one write in the same clock cycle. The measured throughput is two reads or one read and one write per clock cycle when only one core is active. We wouldn't expect the throughput to be less when both cores are active because the two cores in an execution unit have separate load/store units and data cache. But the measurements say otherwise. The measured throughput is typically 1.5 memory operation per core per clock, and the highest value that has been measured is 1.88 memory operation per core per clock when both cores are active. No explanation has been found for this reduced throughput. The decoders, which are shared between cores, should be able to handle two instructions per core per clock cycle.
</i></td></tr></tbody></table></div>Hier wird es nun interessant. Jeder Integer-Kern eines Bulldozer Moduls hat bekanntermaßen seinen eigenen L1-Datencache von 16kB, die unabhängig voneinander sind. Pro Takt können laut AMD-Manual zwei 128-Bit-Lesevorgänge (Load) und eine 128-Bit-Schreiboperation (Store) vorgenommen werden. Dem widerspricht Agner Fog nun. Wer recht hat, ist nicht ganz klar, aber verlassen wir uns einfach auf die Messwerte. Im Mittel kann man demnach mit 1,5 Speicheroperationen rechnen. Nachdem die beiden Kerne unabhängig voneinander sind, erwartet man nichts anderes, als dass sich diese 1,5 Operationen bei zwei Threads auf zwei Kernen zu 3 aufaddieren. Laut Dr. Agner werden allerdings nur 1,88 Speicheroperationen erreicht, also magere ~25% mehr. Damit stellt sich fast schon die Sinnfrage des ganzen Cluster- bzw. Modulkonzepts. Wozu zwei kleine, mickrige Caches, wenn die Bandbreite nicht steigt? Da könnte man dann auch gleich einen einzigen, 32kB großen Cache verbauen. Eine Teilerklärung ist vielleicht die Write-Through-Arbeitsweise der L1-Caches, das bedeutet, dass Store-Speicheroperationen auch gleich in den gemeinsam genutzen L2 geschrieben werden müssen. Deshalb kann man sich an dieser Stelle eventuell ein Nadelöhr vorstellen und seine Erwartungen vielleicht auf ~2,5 Operationen herunterschrauben, aber das ist immer noch weit von 1,88 Operationen entfernt und erklärt nicht die offensichtliche Schwäche auch bei Leseoperationen. Sicherlich ist es möglich, dass es triftige, technische Gründe gibt, die wir nicht kennen. Aber am besten wäre es wohl, wenn sich Dr. Fog vermessen hätte, da die Werte im Vergleich zum erwarteten Durchschnittswert von drei Speicheroperationen für zwei Kerne wirklich schlecht sind. Der Sinn der beiden Kerne ist schließlich, sich nicht gegenseitig zu behindern bzw. auf die Füße zu treten.
[/STRIKE]
Zuletzt wird dann noch von häufig auftretenden L1-Speicherbank-Konflikten berichtet:
<div style="margin: 5px 20px 20px;"><div class="smallfont" style="margin-bottom: 2px;">Zitat:</div><table border="0" cellpadding="6" cellspacing="0" width="100%"><tbody><tr><td class="alt2" style="border: 1px inset;"><i>The data cache is organized as 16 banks of 16 bytes each. The data cache cannot do two memory operations in the same clock cycle if they use banks that are spaced by a multiple of 100h bytes, except for two reads from the same cache line. <b>This kind of cache bank conflict occurs very often</b>:</i></td></tr></tbody></table></div>
Das hört sich wieder nicht gut an, aber immerhin sollte dieser Fall bereits im oben genannten "typical throughput" berücksichtig bzw. gemessen worden sein.

<b>Fazit:</b>
Der Eindruck, dass die Bulldozer-Architektur mit angezogener Handbremse unterwegs ist, kam ja schon relativ früh auf, aber nach den Testergebnissen von Dr. Agner Fog muss man wohl eher von angezogener Handbremse samt Zusatzballast reden. Es bleibt zu hoffen, dass AMD die Schwachstellen in zukünftigen Designs behebt, oder wenigstens weitet. Laut eines c't-Artikels in Ausgabe 23/2011 soll die Steamroller-Generation (<a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">von der wir erst kürzlich berichteten</a>) jeweils einen eigenen x86-Dekoder pro Kern bekommen. Wollen wir hoffen, dass das der Wahrheit entspricht. Zur Diskussion gibt es bereits einen Thread in unserem Forum:
<a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=399188">Zambezi - Fehler, Bugs, mangelnde Performance - Woran liegt es?</a>

<b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1328302051">AMD Analystentag 2012, der Tag danach: Piledriver 10h & 20h; Fragezeichen bei 28nm CPU-Updates</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1330556976">Steamroller (Bulldozer_v3) bekommt eine Radix-8-Dividierer-Einheit </a></li><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=399188">Diskussion im Forum</a></li></ul>
<b>Quellen:</b><ul><li><a href="http://www.agner.org/optimize/microarchitecture.pdf" target="b">The microarchitecture of Intel, AMD and VIA CPUs: An optimization guide for assembly programmers and compiler makers</a></li><li><a href="http://www.agner.org/optimize/" target="b">Komplette Übersicht von Agner Fogs PDFs</a></li></ul>
 
Obwohl ich so gut wie keine Ahnung von CPU internen Funktionen habe, als damals nach dem BD Release und den Problemen gelesen habe dass die Kerne sich im Modul die Sachen Teilen müssen war mir irgentwie als totaler Noob schon klar dass das Der Grund für die schlechte Leistung ist da hilft dann auch Logischerweise kein Softwarepatch viel weiter, was wir ja alle Gesehen haben. Dann wurde Gesagt bei Win 8 wird alles total Super mit zweistelligen Leistungszuwächsen, Win 8 gibt es ja schon eine Weile als Beta sowie jetzt RC, von einer Bulli Leistungsexplosion hab ich nirgendwo bis Heute was Gelesen, war mir klar.

Mein Bauchgefühl vorm BD Launch sagte mir kauf dir den Thuban 1100T und warte nicht Länger, um so mehr Zeit vergeht um so mehr zeigt sich dass diese Denkweise die Richtige war. Bleibt zu hoffen wie im Text steht dass beim Bulli v2 diese Sache auch kommt und jeder Kern auch seine eigene Anbindung bekommt. Das Erinnert doch alles an den Phenom 1, blos dass es dort an der 65nm Bauweise lag, der Phenom 2 in 45nm besonders der X6 ist meiner Meinung nach die beste CPU von AMD aller Zeiten, hätten den lieber als V3 in 32nm Bauen sollen mit ein Paar Modifikationen und den BD zu Ende Gedacht, diese Erkenntnisse lagen AMD doch sicher selber vor.

Kann mir dass nur so Erklären, dass die Geldprobleme hatten und was Bringen mussten egal ob der CPU noch eine Beta war. Dennoch werde ich AMD Treu bleiben und hoffen dass es wieder Bergauf geht ;) Fehler machen wir alle mal und nun wird auch Klar wieso in letzter Zeit so viele Leute Rausgeschmissen wurden, denke der neue CEO hat dass auf Grundlagen aller Interna auch so erkannt.

mfg
 
Zuletzt bearbeitet:
Decoder, L1D Cache & FPU, das sind 3 große schwächen, deshalb skaliert CMT so schlecht....
 
da fragt man sich, was sich die ingis da bei amd dabei gedacht haben.
das hätte man doch erahnen bzw. wissen müssen.

evtl. waren es auch nur die studenten oder gar nur azubis^^

ich warte dann mal auf den dampfroller...
aber ich denke nicht, das die so schlau sind und diese schwachstellen komplett ausbügeln.

mfg
 
Für die lange Entwicklungszeit konnte man mehr erwarten. Obwohl das hier nur die wichtigsten Schwachstellen sind,. sind es zu viele.

Da wird Piledriver wenig verbessern, man kann frühestens ab Steamroller auf bessere Leistung hoffen. Und dieser muß dann schon gegen Haswell antreten.

Ob AMD bis dahin gerafft hat das man nicht einfach ein Design für andere Anwendungen umlabeln kann?
 
Hätte AMD den K10 im Jahre 2007 bis 2011 weiter entwickelt (4 Jahre Entwicklungszeit), also neue Befehlserweiterungen ua. SSE4.1, AVX, FMA3, IPC+, dann wäre der mit 8 Kernen in 32nm mit optimierten Stepping ohne IGP viel Leistungsstärker als Bulldozer geworden. Der K10 hat pro Thread eine eigene FPU, Decoder & 4x soviel L1D Cache...
Wenn die Leute bei AMD das vorher gewusst hätten, die hätten erst garnicht damit angefangen eine neue Architektur Basis aufzubauen.
 
Zuletzt bearbeitet:
Ist nur die Frage wer bis 2014 warten will um dann vll. eine CPU zu erhalten die evtl. so funktioniert wie es von Anfang an der Fall hätte sein sollen.
Ausserdem ist unklar, wieviel Speedup das Entfernen der Flaschenhälse am Ende bringt.

Irgendwie verstärkt sich immer mehr der Eindruck, dass AMD nicht mehr die Kapazitäten hat um komplexe Designs fehlerfrei zu entwerfen, bzw. dass man vll. einfach zu viel gewollt hat und die Umsetzung des Konzepts dann aus den Fugen geraten ist.
Stellt sich nur die Frage, ob es an der technischen Direktion oder an den Ingenieuren bzw. deren KnowHow liegt oder der Größe generell - Intel kann im Vergleich natürlich aus den Vollen schöpfen.

Im Sinne der Kunden und des Marktes wäre es auf jeden Fall, wenn AMD wieder alles halbwegs auf die Reihe bekommt und den Anschluß nicht endgültig verliert, bzw. vll. wieder etwas näher rankommt.


Was die Sehnsüchte nach der alten K7/8/10-Architektur in aller Ehren, aber ob das wirklich funktioniert hätte kann wohl niemand sagen. Genau so gut kann es sein, dass sich ganz andere neue Probleme ergeben hätten aufgrund von Schwierigkeiten zwischen Design und Fertigungsprozess, z.B. durch heat spots & Co.
Ich denke, dieses Design hat einfach seine Zeit gehabt. Was-wäre-wenns helfen ja auch nicht mehr weiter, die Fakten sind geschaffen.
 
Bei den ganzen wirklich dicken Designfehlern fragt man sich ja fast warum die Chips im Server Markt z.b bei Cray doch eigentlich ganz gut verkauft werden können. Die grundlegende Idee hinter dem Design ist wohl schon richtig nur die Umsetzung ist mehr als mies ;) mal schauen ob AMD bis 2014 wieder zu Intel aufholen kann. Immerhin kann Intel solange in aller Ruhe weiterentwickeln und nebenbei gute Gewinne einfahren.
 
da fragt man sich, was sich die ingis da bei amd dabei gedacht haben.
das hätte man doch erahnen bzw. wissen müssen.

evtl. waren es auch nur die studenten oder gar nur azubis^^

mfg

Ich glaube die Techniker bei AMD wussten, dass sie ein schlechtes Produkt entwickelt hatten, aber die BWLer sagten, dass dieses halbfertige Teil JETZT auf den Markt muss.

Vom Prinzip erinnert, dass an die Aussage Maiers vom Oktober letzten Jahres.

http://www.gamestar.de/hardware/prozessoren/amd-fx-8150-bulldozer/amd_bulldozer,346,2561410.html

"Früher hätten Intel und auch AMD die wichtigsten Teile der CPU von Hand entworfen, doch das habe sich geändert. Den Angaben von Maier zufolge hat er die entsprechenden automatischen Tools getestet, bevor er AMD verlassen hatte und dabei festgestellt, dass die so erzeugten Designs 20 Prozent größer und 20 Prozent langsamer waren als die von den Ingenieuren selbst optimierten Chips. "

Es wurde hält zuwenig Geld in die Hand genommen (oder war vorhanden) als, dass ein gutes Produkt hätte entwickelt werden können.

Grüße sendet Dirk
 
Das trifft es aber nicht ganz.

Anscheinend können die CPUs im Server-Bereich Gutes leisten, was also nicht für einen völligen Flop sprechen würde.

Nur in dem Bereich den der Home-User nutzt ist der BD der völlige Flop weil er für so was nicht gut geeignet ist.

Was wieder das alte Thema aufgreift das AMD den BD nie wirklich zielstrebig für uns entworfen hat. Und das möchte ich nicht gutreden, das ist Fakt
 
Ich glaube die Techniker bei AMD wussten, dass sie ein schlechtes Produkt entwickelt hatten, aber die BWLer sagten, dass dieses halbfertige Teil JETZT auf den Markt muss.
Naja, Du kannst aber auch nicht nur Techniker vor sich hinpröddeln lassen, bis alles 100%ig optimal ist, dann werden die nie fertig. Man muß eben einen brauchbaren Kompromiss finden.
Was wieder das alte Thema aufgreift das AMD den BD nie wirklich zielstrebig für uns entworfen hat. Und das möchte ich nicht gutreden, das ist Fakt
Natürlich. Ist ja auch sichbar daran, daß BD im Serverbereich gut läuft, obwohl die IPC für einen einzelnen Thread mies ist. Aber ich nehme an, der Gedanke war, eine Architektur zu entwerfen, die im Serverbereich gut abgeht, aber im Desktopbereich auch mithalten kann und eben nicht so untergeht. Wenn sie mit Piledriver und Steamroller langsam dahin kommen, ist es doch ok.
 
Leider wurden die Aussagen teilweise sehr holprig interpretiert...

Eventuell liegt es daran, dass die Bündelung bei AMD erst nach dem Dekoder passiert, während sie bei Intel davor passieren könnte.

Der Decoder erzeugt aus x86-Instruktionen Macro-Ops - wie sollen diese zusammengefasst werden, bevor sie überhaupt erzeugt wurden? ;)

lg
 
Irgendwie liest es sich als das ganze eine unfertige fehlkonstruktion ist und man quasi eine Beta CPU auf den Markt gebracht hat mit diversen Fehlern. Was Serverberreich angeht sollte man ihm auch nicht gut reden egal ob er da gefragter ist. Immerhin sind es jene Fehler sicher auch dort einiges an möglicher Leistung ins nirvana schicken.
 
Der Decoder erzeugt aus x86-Instruktionen Macro-Ops - wie sollen diese zusammengefasst werden, bevor sie überhaupt erzeugt wurden? ;)
Wo soll da das Problem sein? Vor dem Decoder gibts noch nen Predecoder, den kann man aufs cmp/jmp Suchen ansetzen.
Bei AMD wird eine CMP / JMP Instruktion dagegen wohl erst jeweils getrennt in eine MacroOp übersetzt und dann gebündelt.

Dass das so ist, sieht man auch am Namen, Macro-Op bezeichnet nicht wie bei AMD die übersetzten x86-Instruktionen, sondern ist bei Intel der allgemeine Begriff für x86-Instruktionen.
Before delving further into decoding, it is useful to discuss some terminology. Intel refers to the variable length x86 instructions as macro-operations. These can be quite complex, with multiple memory and arithmetic operations. Intel refers to their own simpler internal, fixed length operations as micro-ops or uops. AMD’s terminology is subtly (and confusingly) different. In AMD parlance, x86 instructions are referred to as AMD64 instructions – again, variable length and potentially quite complex. An AMD macro-operation is an internal, fixed length operation that may include both an arithmetic operation and a memory operation (e.g. a single macro-op may be a read-modify-write). In some cases, AMD also refers to these macro-ops as complex ops or cops. An AMD uop is an even simpler, fixed length operation that performs a single operation: arithmetic, load or store – but only one, and not a combination. So in theory, an AMD macro-op could translate into 3 AMD uops. The best way to think about AMD’s arrangement is that macro-ops are how the out-of-order microarchitecture tracks work, while uops are executed in execution units. For the rest of this article, we will endeavor to use AMD’s terminology.
http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=5
Wenn etwas bei Intel also MacroOp-Fusion heißt, dann heißt das nichts anderes als x86-Instruktionsbündelung, und das kanns logischerweise dann nur vor dem Dekoder geben. Also für mich - auch wenn ich es nicht 100% beweisen kann - ist das relativ klar .. . "holprig" ist aus meiner Sicht nichts *noahnung*
 
Aber ich nehme an, der Gedanke war, eine Architektur zu entwerfen, die im Serverbereich gut abgeht, aber im Desktopbereich auch mithalten kann und eben nicht so untergeht. Wenn sie mit Piledriver und Steamroller langsam dahin kommen, ist es doch ok.

Ersteres ja, zweites Nein. Man hat klar den Fokus auf ersteres gelegt, ob das zweite beachtet wurde bezweifle ich.

Ich hätte gern bald was Neues, aber der Piledriver wird mich wahrscheinlich nicht überzeugen, alles andere wäre ein Wunder. Und auf den Steamroller zu warten dauert mir zu lange, zumal dann Intel auch wieder weiter ist und der Steamroller da wiederum nicht mithalten wird.
 
Ich hätte gern bald was Neues, aber der Piledriver wird mich wahrscheinlich nicht überzeugen, alles andere wäre ein Wunder. Und auf den Steamroller zu warten dauert mir zu lange, zumal dann Intel auch wieder weiter ist und der Steamroller da wiederum nicht mithalten wird.
Sicher richtig, aber v.a. der IPC-Vorsprung sollte da ausreichend geschrumpft sein, so dass man wohl keine allzu großen Nachteile hat, wenn man zu nem - wohl wieder zwangsweise billigeren - AMD-Chip greifen würde. Garniert mit nem freien Multiplier, könnte das schon was Interessantes werden.

Es sei denn Haswell wird die IPC-Bombe schlechthin *buck* Aber technisch gibts dafür eigentlich keinen Hinweis. Sandy dürfte schon recht gut auf ne Durchschnitts-IPC von 2++ kommen, recht viel mehr geht eigentlich nicht. Außerdem geht Intel auch deutlich Richtung Energiesparen, sieht man schon bei Ivy. Anstatt ner 4 GHz Version wird die TDP auf 77W begrenzt.
 
Beziehst du dich auf Piledriver oder Steamroller?

Vielleicht weißt du mehr als ich, aber ich habe keine Ahnung warum die IPC in den Nachfolgern so deutlich besser sein sollten; ist letztlich immer noch eine sehr ähnliche Architektur.

Wenn AMD da wirklich deutlich besser wäre, wäre das zusammen mit der Taktung ein Hammer-CPU
 
Beziehst du dich auf Piledriver oder Steamroller?

Vielleicht weißt du mehr als ich, aber ich habe keine Ahnung warum die IPC in den Nachfolgern so deutlich besser sein sollten; ist letztlich immer noch eine sehr ähnliche Architektur.

Wenn AMD da wirklich deutlich besser wäre, wäre das zusammen mit der Taktung ein Hammer-CPU
Steamroller, von Piledriver erwarte ich auch keinen starke Sprung sondern nur eher nur Feintuning und in Verbindung mit dem neuen Clock-Grid entsprechend mehr Takt.
 
Also werden wir das in über einem Jahr vielleicht sehen ;)
 
also dafür, dass Bulldozer komplett neu entwickelt wurde, läuft er in der ersten verkauten Version doch ganz brauchbar, gerade in dem hauptsächlich dafür entwickelten Servermarkt, wo viele Integer-Kerne und Mehrsockelfähigkeit (2 Bulldozer = 16 Kerne, und es gibt 4-Sockel-Boards dafür!) zählen.
Der Vergleich zum PIV wurde schon oft gebracht, und der ist auch irgendwie typisch dafür, wie so ein CPU-Lebenszyklus abläuft. Die erste PIV-Version (Williamatte 256kB L2, Anfangs 1,4 GHz) wollte eigentlich niemand so recht, da der letzte PIII noch schneller war, aber schon die nächste PIV-Version (Northwood 512kB L2, zuletzt 3,4 GHz) bekam entscheidene Verbesserungen (Hyperthreading) und das Design konnte über die Jahre sogar immer weiter wachsen (zum Dualcore und 2MB L2 Cache) und ganz gehörig an Geschwindigkeit zulegen. Der letzte PIV EE Dualcore war dann wohl schließlich ca. 8x so schnell als das erste PIV-Exemplar.
http://www.cpu-world.com/CPUs/Penti... Edition 965 HH80553PH1094M (BX80553965).html
Wichtig ist, dass AMD jetzt auf dem Design basierend wieder ein paar Jahre stetig verbesserte CPUs nachschieben kann, also optimal wäre, wenn in 2 Jahren dann der Bulldozer doppelt so leistungsfähig ist, und in 4 Jahren dann vielleicht gar 4x. Also mehr Kerne, mehr Takt, und interne Verbesserungen an den Funktionseinheiten, dort wo in dem Artikel schon Schwachstellen aufgezeigt wurden.
 
Zuletzt bearbeitet:
Ein Wunder das AMDs FX 8150 Bulldozer doch noch recht gut mit dem 2500K mithalten kann, hätte AMD sich hier mehr Mühe gegeben hätte er wohl leicht und locker den 2600K
in die Tasche gesteckt vermutlich wäre sogar noch mehr drin gewesen.
Hört sich leider nach leicht vermeidbaren Fehlern an, hoffe auf recht schnelle Optinierung,

Das einzig gute für AMD Bulldorer2/3 können "leicht" auf 20 bis 30% mehr Leistung gebracht werden (ohne Takterhöhung) schätze ich mal. mfg:)
 
Zuletzt bearbeitet:
Der Abschnitt zum "L1-Daten Cache" wurde falsch übersetzt.

Richtige übersetzung wäre:

Solange nur ein Kern aktiv ist, kann dieser 2 Reads oder ein read und ein write durchführen. Insgesammt hätte man bei zwei aktiven Kernen also 4 Reads erwartet, nicht 3 wie im in der Übersetzung hingeschrieben wurde

Sind jedoch beide Kerne aktiv, kann ein Kern nicht mehr 2 reads durchführen, sondern durchschnittlich 1,5, maximal jedoch 1,88. Addiert auf beide Kerne sind es also im Durchschnitt 3 bis maximal 3,76, das sind nur 75 Prozent (1,5 vs. 2) des Durchschnittoutputs, also 25 Prozent an Kernleistung geht verloren, wennn man beide Kerne arbeiten lässt. Insgesammt schaffen zwei Kerne aber wie gesagt immer noch mehr als ein Kern: 2 vs. 3 outputs. Ein Integercluster kann damit 66,6 Prozent der Leistung erreichen, die zwei Kerne generieren können. Wenn man also ein Kern bei 100 Prozent ansetzt, dann ist der Durchsatz mit zwei Kernen bei 150 Prozent, also nur 50 Prozent mehr, keine 80 Prozent, wie AMD für CMT propagiert hat und das ist nur das was den L1-Cache-Durchsatz betrifft, hinzu kommen noch die ganzen Flaschenhälse bei den Decodern.....
 
Zuletzt bearbeitet:
Der Abschnitt zum "L1-Daten Cache" wurde falsch übersetzt.

Richtige übersetzung wäre:

Solange nur ein Kern aktiv ist, kann dieser 2 Reads oder ein read und ein write durchführen. Insgesammt hätte man bei zwei aktiven Kernen also 4 Reads erwartet, nicht 3 wie im in der Übersetzung hingeschrieben wurde

Sind jedoch beide Kerne aktiv, kann ein Kern nicht mehr 2 reads durchführen, sondern durchschnittlich 1,5, maximal jedoch 1,88. Addiert auf beide Kerne sind es also im Durchschnitt 3 bis maximal 3,76, das sind nur 75 Prozent (1,5 vs. 2) des Durchschnittoutputs, also 25 Prozent an Kernleistung geht verloren, wennn man beide Kerne arbeiten lässt. Insgesammt schaffen zwei Kerne aber wie gesagt immer noch mehr als ein Kern: 2 vs. 3 outputs. Ein Integercluster kann damit 66,6 Prozent der Leistung erreichen, die zwei Kerne generieren können. Wenn man also ein Kern bei 100 Prozent ansetzt, dann ist der Durchsatz mit zwei Kernen bei 150 Prozent, also nur 50 Prozent mehr, keine 80 Prozent, wie AMD für CMT propagiert hat und das ist nur das was den L1-Cache-Durchsatz betrifft, hinzu kommen noch die ganzen Flaschenhälse bei den Decodern.....

Ahh noch besser - anstatt das Agner sich vermessen hat, hab ich den Teil falsch verstanden *lol*
Mein Problem war der Satz hier:
The measured throughput is typically 1.5 memory operation per core per clock,
Ich dachte, damit meint er einen Kern im single Betrieb und die Werte zuvor (2 Operationen) waren nur die Maxima. Aber vom Kontext her (er spricht ja im Satzteil zuvor schon von "when both cores are active", meint er da wohl da auch schon den Durchsatz zweier Kerne, und das Satzende "when both cores are active", muss sich eigentlich auch schon auf die 1,5, nicht nur auf die 1,88 beziehen. Denke also Du hast recht und werde das mal demnächst überarbeiten.

Danke fürs Korrigieren und extra Anmelden dafür !

Willkommen auf P3D :)

Alex
 
Na ja, der Bulldozer wird immer mit den Sandy Bridge Modellen verglichen die bekantlich eine geringere TDP vorweisen können. (IGP inklusive)


Wenn man wissen will wo AMD z. Z. steht muss man ihn schon mit dem Core i7 3960X vergleichen. Da die TDP fast gleich ist.

http://ht4u.net/reviews/2011/intel_.../index40.php?dummy=&advancedFilter=false&prod[]=AMD+FX-8150+[3%2C6+GHz%2C+4+Module%2C+CMT%2C+Turbo]&prod[]=Intel+Core+i7+3960X+[3%2C3+GHz%2C+6+Kerne%2C+HTT%2C+Turbo]

Insgesamt gesehen fehlen da mindestens 45%.

Da muss schon ein Wunder geschen wenn sie in zwei Jahren aufschliessen wollen.
 
Zurück
Oben Unten