Ergebnis 1 bis 1 von 1
  1. Beitrag #1
    Themenstarter
    Grand Admiral
    Special
    Grand Admiral
    Avatar von Dresdenboy

    Registriert seit
    28.10.2003
    Ort
    Berlin
    Beiträge
    2.823
    Danke
    27
    Gedankt 68 Mal für 2 Themen

    AMD FX - Top oder Flop? (Teil 1)

    Einleitung


    Der Zeitpunkt, auf den viele unserer Leser bereits lange warteten, ist nun erreicht: der offizielle Launch von AMDs erstem Prozessor auf Basis der neuen Bulldozer-Architektur (zu unserem Bulldozer Benchmark-Artikel). Diesem voraus gingen viele Gerüchte und Spekulationen. Umso näher dieser inoffiziell mehrmals verschobene Tag rückte, umso mehr häuften sich vorab von Dritten veröffentlichte Benchmarkergebnisse. AMD selbst versüßte uns die Zeit mit vielen Architekturdetails und Hintergrundinformationen, welche u. a. auf den letzten beiden „Hot Chips“-Veranstaltungen und der Konferenz ISSCC 2011 bekanntgegeben wurden. Damit konnte man sich zwar schon mehr vom zu erwartenden realen Prozessor vorstellen, aber weiterhin fehlten wichtige Details, wie z. B. die zukünftigen Taktfrequenzen der Modelle sowie Art und Umfang von neuen Turbo-Core-Modi.

    Dank der vielen schon aufgetauchten Informationen sind die meisten dieser Fragen nun auch beantwortet, bis auf die wichtigste: Welche Leistung liefert diese neue Serie von Prozessoren? Das soll im Detail untersucht werden. Aufgrund der knappen Vorbereitungszeit bietet es sich jedoch an, diese Erkenntnisse in mehreren Teilen aufzuarbeiten.

    Um es vorweg zu nehmen: die neue Mikroarchitektur stellt eine grundlegende Änderung gegenüber AMDs anderen Prozessorkernen („Stars“ wie z. B. im Phenom II X6, „Husky“ im Llano oder „Bobcat“ im Zacate oder Ontario) dar. Die Situation ist der bei der Einführung des P4 von Intel vergleichbar. Hierbei ist aber nicht der mit Pentium 4 häufig verbundene hohe Energiebedarf gemeint, sondern der Grad der Änderung in der Architektur, was erst mit Einsatz entsprechend optimierter Software richtig zur Geltung kam. Damals war der Energieverbrauch v. a. für Desktopsysteme oder Server noch nicht so sehr im Fokus wie heute. Darum wurde auch die Bulldozer-Mikroarchitektur u. a. für eine gute Energieeffizienz ausgelegt, was ein Hauptgrund für das Bulldozer-Modulkonzept – der Zusammenlegung zweier Rechenkerne inkl. FPU zu einem optimierten Dual-Core-Modul – war.

    Schaut man etwas in die Vergangenheit, sind die vielen Neuerungen beim Bulldozer gar nicht erst seit der ersten Vorstellung 2009 bekannt. Bereits 2005 gab es Aussagen von AMDs damaligem CTO Fred Weber, welcher über die Richtungen für zukünftige Entwicklungen sprach. Diese Punkte wurden dabei von ihm hervorgehoben:

    • Bevorzugung von Thread Level Parallelism (TLP) statt Instruction Level Parallelism (ILP), also höhere Performance durch mehr Threads anstelle von höherer Single-Thread-Leistung
    • Kombination von Befehlen (wie bei Intels MicroOp-Fusion, von Weber „Instruction Combining“ genannt)
    • Höhere Taktfrequenzen für höhere Single-Thread-Leistung
    • Niedrigere Speicherzugriffslatenzen
    • Niedrigere Sprungvorhersagelatenz und deutlich bessere Sprungvorhersage
    • Geteilte Nutzung von Einheiten wie die FPU durch zwei Kerne zu deren besseren Auslastung und damit erhöhter Energieeffizienz
    • Helper-Threads, welche bald benötigte Daten vorab in die Caches laden

    (siehe Fred Weber Interview)

    Von all diesen Punkten wurde bis auf die Helper-Threads alles so im Bulldozer verwirklicht.

    Schließlich gab es ebenfalls 2005 einen Hinweis von AMDs CTO Charles R. Moore, einem weiteren wichtigen Mann hinter der Bulldozer-Architektur. Dieser lieferte schon damals in einer Folie Argumente für ein entsprechendes Architekturkonzept - dem "Cluster-based Multithreading" oder kurz CMT. Demnach sollte für die Ausführung von zwei Threads - passend zu Fred Webers Aussagen - ein Teil der Einheiten eines Prozessorkerns verdoppelt und der Rest gemeinsam von den Threads genutzt werden:


    Nach diesen ersten eher vagen Andeutungen tauchten erstmals 2008 in Patenten Architekturbilder auf, welche den grundsätzlichen Aufbau eines Bulldozer-Moduls darstellten:


    Interessant hierbei ist die Bezeichnung des Moduls als „Core“, während die jetzigen „Integer Cores“ den in den Patenten beschriebenen „Integer Clustern“ entsprechen. Wie man das aber genau nennt, ist eine Frage der Definition. Aber da hat selbst Fred Weber schon 2005 von zwei Kernen gesprochen, die sich eine FPU teilen. Somit ist diese Darstellung auch nicht erst eine Erfindung des Marketings aus den letzten Jahren.

    In der folgenden Folie ist zu sehen, wie es heutzutage dargestellt wird:


    Ziel des Ganzen war es, die Energieeffizienz zu erhöhen. Da der Entwurf solcher Mikroarchitekturen immer einen Kompromiss darstellt (wie praktisch jede Entwicklung eines massengefertigten Produkts), ist auch die Bulldozer-Architektur ein solcher Kompromiss. Weitere Hintergründe dazu liefert Pollacks „Gesetz“, benannt nach einem Intel-Entwickler. Demnach beeinflussen sich Schaltungskomplexität, Taktfrequenz, Rechenleistung pro Takt, Energieaufnahme und Schaltungsfläche nach bestimmten (Daumen-)Regeln gegenseitig. [1] [2]

    Mit etwas Aufwand kann man diese Faktoren aber zu seinen Gunsten beeinflussen. Eine Möglichkeit ist das moderne Energiemanagement in Prozessoren, welche den Idle- und auch den Last-Verbrauch senken können und sogar leistungsfördernde Maßnahmen wie einen Turbo-Modus ermöglichen.

    Eine weitere Möglichkeit ist, komplexe Schaltungen (mit höherem Verbrauch) durch eine stärkere Auslastung mit Hilfe mehrerer Threads (häufig zwei) effizienter zu nutzen. Da bei neueren Herstellungsprozessen die Leckströme prozentual schon relativ groß werden können (~20% oder mehr), ist es sogar schon „teuer“, eine Schaltung nur zur 50% zu nutzen und es wird eine höhere Nutzungsquote angestrebt. Das erfolgt dann durch Simultaneous Multithreading (SMT bzw. Hyperthreading bei Intel) oder andere Multithreading-Techniken. Der Mehraufwand dafür hält sich in Grenzen. Beim Pentium 4 sprach Intel von etwa 5% zusätzlicher Chip- bzw. Die-Fläche. Bei Nehalem oder Sandy Bridge dürfte dieser Anteil auf Grund von weiteren Komponenten auf den Dies noch kleiner sein. So eine gemeinsame Nutzung hat aber den Nachteil, dass die Leistung der einzelnen Threads im Vergleich zum Single-Threaded-Betrieb deutlich nachlässt. Wenn z. B. ein Programm auf Sandy Bridge mit Hyperthreading 20% mehr Leistung erreicht, bedeutet das auch, dass jeder Thread nur mit 60% der Single-Thread-Leistung läuft.

    Genau dieses Konzept der gemeinsamen Nutzung von komplexen Einheiten hat nun auch AMD für sich entdeckt und setzt es im Bulldozer und den darauf folgenden Architekturgenerationen um. Allerdings ist das Konzept scheinbar der auserkorene Gewinner nach mehreren Entwicklungsanläufen (wenn man viele Patente nach den K7-Entwürfen betrachtet) und verschiedenen Einflüssen (z. B. Mikroarchitekturguru Andy Glew). Die Herangehensweise ist allerdings eine andere als bei Intel. Man begann nicht mit einem großen, leistungsfähigen Core, um festzustellen, dass noch ein zweiter Thread darauf passt. Sondern man wollte von vornherein zwei Kerne nehmen und die komplexen Einheiten gemeinsam nutzen, wo es sinnvoll war. Das ermöglichte dann natürlich auch, diese Einheiten noch etwas leistungsfähiger zu gestalten, da die „Kosten“ in Form höheren Verbrauchs oder Die-Fläche geteilt werden. Folgende Einheiten wurden für eine geteilte Nutzung bestimmt:

    • Instruction Fetch, Instruction Prefetch, Instruction Cache
    • Sprungvorhersage
    • Decoding/Dispatch
    • Floating Point Unit mit Scheduler und Ausführungseinheiten
    • L2-Cache

    Für jeden Thread separat vorhanden sind die Integer-Kerne, welche folgende Einheiten enthalten:

    • Integer Scheduler
    • Integer Ausführungseinheiten
    • Load/Store-Unit
    • L1-Datencache
    • Retirement

    Die genauere Arbeitsweise der Einheiten ist im Spekulationsartikel beschrieben und wird hier gegebenenfalls nur angerissen.

    Da man bei der bisherigen „Family 10h“-Microarchitektur (von Barcelona bis Thuban) einige Flaschenhälse bzw. weniger effiziente Einheiten identifiziert hat, wurden die Integer-Kerne entsprechend überarbeitet. Das führte teilweise zu Einsparungen, aber auch zu Verbesserungen bzw. Optimierungen.

    [BREAK=Untersuchung der Befehlsausführung]

    Untersuchung der Befehlsausführung


    Um zu untersuchen, wie sich die Ausführung von Befehlen zwischen Bulldozer und anderen Architekturen unterscheidet, haben wir die Latenzen und Durchsätze verschiedener Befehle mit Hilfe von AIDA64 gemessen und verglichen. Zum Vergleich wurden noch der Husky-Core im Llano (welcher selbst schon Verbesserungen gegenüber den Stars-Cores mitbringt), der Sandy-Bridge-Core sowie der Bobcat-Core herangezogen.

    Dabei sagt die Befehlslatenz aus, nach wieviel Taktzyklen ein folgender Befehl mit dem Ergebnis des betrachteten Befehls weiterarbeiten kann. Das spielt dann eine Rolle, wenn die Out-of-Order-Ausführung des Prozessors und der Compiler nicht in der Lage sind, diese Latenzen durch geeignete Anordnung der Befehle zu "verstecken". Die Auswirkung auf die durchschnittliche Rechenleistung ist nicht so groß wie beim Durchsatz. Dieser beziffert, wie viele dieser Befehle pro Takt maximal gleichzeitig ausgeführt werden können und stellt das obere Limit dessen dar, was Out-of-Order-Ausführung und der Compiler beim Zusammenstellen des Programmcodes ausnutzen können.

    Im ersten der folgenden zwei Diagramme sind die durchschnittlichen Befehlslatenzen für verschiedene Befehlsgruppen dargestellt. Man kann dort erkennen, dass v. a. die Latenzen der Integer-Befehle (X86, AMD64) beim Bulldozer sichtbar zugenommen haben (deutlicher bei den 64-Bit-Befehlen). Von den Befehlen wurden zur Vermeidung von Verzerrungen sehr selten bzw. in der Praxis gar nicht genutzte Befehle bzw. -kombinationen herausgenommen. Bei den verschiedenen Befehlssatzerweiterungen ergibt sich ein gemischtes Bild. Bei x87-, SSE- und SSE2-Befehlen gibt es sogar eine Verbesserung zum Husky-Core, während SSE3-, MMX(+) und auch die Integer-Divisions-Befehle vermutlich unter Nutzungshäufigkeits- bzw. Energieeffizienz-Kriterien langsamer und damit sparsamer implementiert wurden. Die Division ist dementsprechend fast genau nur halb so schnell wie im Llano.




    Das zweite Diagramm zeigt den durchschnittlichen Durchsatz. Diese können in dieser Form aber auch nur für einen groben Vergleich herhalten, da die Befehle im real auftretenden Befehlsmix mit ganz anderen Häufigkeiten auftreten [3]. Hier wird deutlich, dass selbst Sandy Bridge im Vergleich zu Husky nicht immer besser dasteht. Das liegt daran, dass viele der getesteten Befehle im Husky-Core von allen drei Integer-Einheiten ausgeführt werden können und im Sandy Bridge z. B. nur durch eine oder zwei der vorhandenen Einheiten ausführbar sind. Das verwundert nicht unbedingt, da Sandy Bridge auch auf Energieeffizienz hin optimiert wurde, was auch die Anpassung der vorhandenen Einheiten an die zu erwartenden Anwendungen einschließt.


    Generell ist erkennbar, dass Bulldozer bei Integer-Befehlen etwa 10% weniger Durchsatz erreicht, als Sandy Bridge. Das Bild ist hier aber durch den nicht eingebrachten Befehlsmix verzerrt, denn wenn man sich die am häufigsten verwendeten Integer-Befehle anschaut, sollte der Vorteil zu Gunsten Sandy Bridges größer ausfallen. Zu bedenken ist auch, dass mit SMT (Hyperthreading) auf Sandy Bridge dieser Durchsatz auf 2 Threads aufgeteilt wird, während Bulldozer für den zweiten Thread einen zweiten Core bereitstellt.

    Cache-Latenzen und -Durchsatz wirken sich auch auf diese Werte teilweise aus, da die getesteten Befehle auch Speicherzugriffe enthalten.

    Codeoptimierung


    Die obige Betrachtung bietet schon eine erste Erklärungsmöglichkeit der beobachteten Leistung des Prozessors. Aber das reicht noch nicht. Wie schon erwähnt, ähnelt der Umfang der Änderungen der Bulldozer-Architektur dem der Netburst-Architektur im Pentium 4. Dementsprechend abhängig ist die erzielbare Rechenleistung von Codeoptimierung für die Architektur. Das bedeutet nicht nur optimale Nutzung vorhandener Befehlserweiterungen (wie AVX oder FMA4), sondern auch die entsprechende Anordnung von Befehlen im compilierten Code für eine optimale Dekodierung und Ausführung. Weiterhin bieten die neue Modul- und die Cache-Architektur weitere „Fettnäpfchen“ für ineffizienten Code. So ähnlich hatte der Pentium 4 zu Beginn mit für Pentium 3 optimiertem Code zu kämpfen, ganz zu schweigen von der anfangs fehlenden Nutzung der SSE2-Erweiterung.

    Hier heißt es also Abwarten bis entsprechend optimierte Software bereitsteht. Hier kann man AMD keinen Vorwurf machen, da man dort schon länger intensiv an der Verbesserung von Compilern, v. a. den Open-Source-Projekten GCC und Open64, arbeitet. Auch bei kommerziellen Anbietern wird die Unterstützung vermutlich nicht lange auf sich warten lassen.

    Eine interessante Möglichkeit, früh mit optimiertem Code arbeiten zu können, bieten Managed-Code-Sprachen, welche auf die Just-In-Time-Übersetzung und auch -Optimierung von Byte-Code-bauen (z. B. Java oder .NET). Hier wäre ein Update der entsprechenden VM ausreichend, um existierende Anwendungen auch effizient auf dem Bulldozer laufen zu lassen.
    [BREAK=Vergleichstabelle verschiedener Architekturen]

    Vergleichstabelle verschiedener Architekturen


    Abschließend für diesen ersten Teil sollen hier verschiedene Microarchitekturen in einer Tabelle gegenübergestellt werden:







    K7K8K10LlanoBulldozer-KernBulldozer-ModulSandy Bridge
    Decode3 MacroOps3 MacroOps3 MacroOps3 MacroOps4 mops (+1 mit Branch Fusion)4 mops (+1 mit Branch Fusion)4 µOps (+1 mit Macro Op-Fusion)
    Issue3 MacroOps3 MacroOps3 MacroOps3 MacroOps2 ALU + 2 AGU + 4 FP2x2 ALU + 2x2 AGU + 4 FP4 MacroOps
    ROB727272841282x128168
    FPU-Width (bit)64 (80)64 (80)128128128 - 256256256
    FPU Unitsfadd, fmul, fmisc (64b)fadd, fmul, fmisc (64b)fadd, fmul, fmisc (128b)fadd, fmul, fmisc (128b)2x fmac 128b + 2x Integer SIMD 128b2x fmac 128b + 2x Integer SIMD 128bfadd, fmul, falu (256b)
    L1 Instruction Cache (kB, Ways)64 (2)64 (2)64 (2)64 (2)64 (2)64 (2)32 (8)
    L1 Data Cache (kB, Ways)64 (2)64 (2)64 (2)64 (2)16 (4)2 x 16 (4)32 (8)
    L1D$ Bandbreite Reads/Writes (bit/cycle)2 x 64b reads/writes2 x 64b reads/writes2 x 128/0 x 64 oder

    1 x 128/1 x 64 oder

    0 x 128/2 x 64





    2 x 128/0 x 64 oder

    1 x 128/1 x 64 oder

    0 x 128/2 x 64?





    2 x 128/1 x 1284 x 128/2 x 128384 kombiniert (wahrscheinlich 384/0 oder 256/128)
    L2 (kB)256 - 512512 - 1024512 - 102410242048 (shared)2048 (shared)256
    L3 (kB)--2048 - 6144-819281928192 (shared)
    Anzahl Threads1111122
    Die area per core (mm²)~69 (130 nm)22,5 (65 nm)15,3 (45 nm)9,69 (32 nm)-18 (32 nm, ohne L2)

    30,9 (32 nm, mit 2M L2)



    18,4 (32 nm, 256kB L2)
    Westmere: 17,2 (32 nm, 256kB L2)





    Im nächsten Teil soll genauer auf die Besonderheiten der Architektur eingegangen werden.

    Quellen:

    [1] http://en.wikipedia.org/wiki/Pollack%27s_Rule
    [2] http://citavia.blog.de/2010/09/28/in...n-rwt-9476659/
    [3] http://www.strchr.com/x86_machine_code_statistics

    Geändert von Dresdenboy (16.10.2011 um 16:47 Uhr)

  2. Die folgenden 56 Benutzer sagen Danke zu Dresdenboy für diesen nützlichen Beitrag:

    Athlonscout (12.10.2011), Atlan78 (12.10.2011), Bartfratze (14.10.2011), bbott (12.10.2011), Cashran (12.10.2011), ceVoIX (13.10.2011), Crashtest (12.10.2011), cumulus (12.10.2011), deadohiosky (12.10.2011), DEFENDER (23.10.2011), der2of6 (18.10.2011), Doc2 (12.10.2011), DonGeilo (16.10.2011), Dr@ (14.10.2011), Elandur (12.10.2011), erde-m (12.10.2011), flashbang (12.10.2011), foenfrisur (12.10.2011), gurkenstix (12.10.2011), Hans de Vries (14.10.2011), heiko-soft (09.11.2011), ICEMAN (12.10.2011), isigrim (12.10.2011), KGBerlin (12.10.2011), Locuza (13.01.2013), LoRDxRaVeN (11.07.2012), Makso (12.10.2011), mibo (12.10.2011), Micheck (12.10.2011), MrBad (12.10.2011), MusicIsMyLife (13.10.2011), nazgul99 (12.10.2011), nvb (12.10.2011), ONH (12.10.2011), Opteron (12.10.2011), pokasser (14.10.2011), rasmus (12.10.2011), RedBaron (12.10.2011), S.I. (12.10.2011), Sabroe SMC (12.10.2011), schiggung (13.10.2011), SPawner (12.10.2011), Species_0001 (12.10.2011), tex_ (12.10.2011), TNT (12.10.2011), towatai (12.10.2011), Treverer (20.10.2011), unterstudienrat (15.10.2011), VolkerWpt (12.10.2011), Vollnoob85 (13.10.2011), Windelwinni (16.10.2011), WindHund (12.10.2011), Woerns (12.10.2011), [MTB]JackTheRipper (12.10.2011)

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •  
Single Sign On provided by vBSSO