Bobcat, das Bulldözerchen

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
<erster entwurf,="" wird="" noch="" besser="" ;-)="" wer="" will="" kann="" die="" links="" suchen="" &="" einfügen=""></erster><links>

Einleitung​

</links>Viel Pressewirbel und Tamtam wurde am 24. August, dem zweiten Tag der Hot Chips-Konferenz 2010 veranstaltet, denn AMD gab erstmals nähere Details zu Ihren kommenden CPU Architekturen „Bulldozer“ und „Bobcat“ bekannt. P3D berichtete:

Die kompletten, originalen Präsentationensfolien der Hot Chips 22 vom Chip-Olymp der Stanford University sind hier zu finden:
Am meisten Interesse wurde natürlich dem kommenden Hochleistungsprozessor Bulldozer zu Teil. Den P3D Vorbericht von Dresdenboy dazu gibt es hier. Im Schatten dessen ging das kleinere Bobcat-Design leider etwas unter, obwohl mehr Details bekannt gegeben wurden. In diesem Artikel wollen wir jetzt näher auf Bobcat eingehen:

Bobcat - wozu ?​

Laut AMDs Vorgaben aus dem Jahr 2007 sollte ein Bobcat-Kern nur 1-10 Watt verbrauchen:
Slide110.JPG


Damit waren die Zielvorgaben fixiert. Die Frage war nur, wie Intels schärfster x86-Rivale sie umsetzen würde. Dazu später mehr, zuerst noch ein Blick auf den Zielmarkt.
<link uraltfolie=""><uralt folie="">

Zielmarkt​

Der geplante Zielmarkt ist bei 1-10 Watt Strombedarf natürlich einfach zu erraten: Kleine, leichte Net- und Notebooks mit langer Batterielaufzeit oder auch stromsparende Desktop PCs (Nettops). In diesem Segment macht sich seit 2008 Intels Atom breit, der somit in diesen Segmenten als direkter Bobcat-Gegenspieler gesehen werden muss. AMD will mit diesem Leichtprozessorkern allerdings das Segment der Mobiltelefone nicht besetzen, was einige Vorteile bietet. Siehe die Vor-und Nachteile später.

AMDs aktuelle Lage​

Fast schon "traditionell" kann man sagen, dass das Notebook-Segment bei AMD ein eher stiefmütterliches Dasein fristet. Intel ist mit der „Centrino“ Marke schon lange am Markt, und konnte auch mit langen Batterielaufzeiten bei guter Leistung punkten. Seit dem Abschied von Transmeta aus diesem Markt (bis auf AMD) quasi unangefochten, denn VIA ist absolut unbedeutend. Seit der ersten mobilen K10 Kernen in 45nm Fertigungstechnik, konnte AMD aber immerhin einen kleinen Erfolg verbuchen. Laut den Marktforschern von IDC stieg der Marktanteil des kleinen x86-Riesen um 0,2 Prozent auf immerhin 19 Prozent. Das ist nicht gerade viel, aber im gleichen Zeitraum sank AMDs Anteil am Mainstream/Desktop-Segment um 0,7 [Quelle]

Grund dürfte sein, dass die aktuelle Notebook-Plattform Danube, bestehend aus 45nm AMD CPU und IGP-Chipsatz mit ATi Grafik, eine gute Basisleistung zum vernünftigen Preis bietet. Die Texaner konnten deshalb auch relativ viele OEM Designs gewinnen. Mit 109 geplanten Geräten, verdreifachten sich die „Designwins“ gegenüber der Vorgängerplattform mit 65nm Prozessoren <doofen marketingname="" einfügen="">[Quelle].

Diese erfolgreiche Kombination aus ATI-Grafik und AMD-Prozessor wollen die Athlon-Erfinder im nächsten Jahr noch weiter verbessern, indem die beiden Komponenten noch näher zusammenrücken. Das Verschmelzen von Grafikkern und Hauptprozessor auf einem Chip nennt AMD dabei „Fusion“.
</doofen></uralt>
[BREAK=Fusion]
</links>

Fusion​

Über Fusion wurde auf P3D schon ausreichend berichtet:
Deshalb soll hier nur eine Schnellübersicht erfolgen. Aktuell ist dieses Schema eines Fusion-Prozessors:

fusionbobdv07.jpg


Wie man sieht ist alles (CPU/GPU/Platform Interfaces) auf einem Stück Silizium („Die“) integriert. Das spart Platz und durch die räumliche Nähe dürften sich auch Performance-Vorteile ergeben. Insgesamt ergeben sich Leistungs-, Verbrauchs-, und Platzvorteile - optimal für kleine, leichte Rechner. Intel nutzt bei seiner Clarkdale CPU z.B. ebenfalls schon CPU und GPU in einem Gehäuse. Allerdings dort mittels zwei getrennten Dies, die auf einem Chipträger mit QuickPath verbunden sind. Für Pineview, die zweite Generation der „Atoms“ nutzt der x86-Gigant sogar noch den klassischen mittlerweile auch recht behäbigen FSB. Dafür ist der neue Atom mit integrierter Grafik auf einem einzigen Stück Silizium eingeätzt. QPI ist zwar das Neueste vom Neuen, aber nicht so sparsam und zudem für Dual Channel-DDR3 schon wieder ein Flaschenhals.
</die></doofen></uralt></links><links><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
</die></doofen></uralt></links>
<links><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">Für 2011 sind drei Fusion Modelle geplant:
</die></doofen></uralt></links>
  • <links><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^=""> Ontario, basierend auf ein-zwei Bobcat CPUs plus einer GPU, 9W TDP
    </die></doofen></uralt></links>
  • Zacate, wie Ontario nur mit 18W TDP
Von beiden gab es gerade auf der IFA 2010 erste Chip Fotos:
bobifa.jpg

Quelle: Computerbase

file.php


Zusätzlich zu den beiden Bobcat Derivaten wird es noch den Llano geben, der auf der altbekannten K10 Architektur basieren wird. Sie ist ausreichend bekannt und muss deshalb nicht eingehend betrachtet werden. Bobcat dagegen ist interessant, wie man schon an obigen TDP Zahlen sehen kann. Dieser genügsame Stromkonsum ist für einen integrierten Chip aus CPU, GPU und kleinem PCIe Kontroller sehr gut. Deswegen wollen wir uns das Design einmal etwas näher anschauen. Zuerst die Architekturübersicht:
<links><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
[BREAK=Die Bobcat Architektur]

Die Bobcat Architektur​

</die></doofen></uralt>
file.php

<schema>
Auf den ersten Blick ist alles vorhanden, was man bei einer state-of-the-art CPU benötigt. Im Vergleich zum K8/K10 fallen die L1 Caches nur halb so groß aus, dafür wurde aber an der Assoziativität geschraubt. Der Datencache ist nun anstatt 2fach, 8fach assoziativ, und entspricht nach einer Daumenregel, somit einem 2fach assoziativen Cache von 128 kbyte. Also ist das eher eine Verbesserung, denn eine Verschlechterung.

Die restlichen Eckpunkte in Stichpunkten:

  • AMD64 Architektur
  • Befehlssatzerweiterungen: SSE2 / SSE3 / SSSE3 und SSE4A (kein SSE4.1 oder SSE 4.2)
  • 2-issue Out-of-Order Architektur, es können gleichzeitig maximal zwei x86 Befehle in veränderter Reihenfolge abgearbeitet werden.
  • 32kB L1I und L1D Caches
  • 512kB L2 Cache
  • 90 Prozent Rechenleistung eines K10 Kerns (bisher wusste man nicht sicher, auf was sich die 90 Prozent bezogen, wobei das bei AMD mehr oder minder klar sein musste ^^).
  • Bobcat benützt physikalische Register Files (PRF), dies ist wichtig fürs Register Umbenennen, später dazu mehr im Detailkapitel.

</schema></links>

Die K8 Pipeline​

Bevor wir uns Bobcats Pipeline anschauen, wollen wir uns erst einmal AMDs altehrwürdige K8 Pipeline anschauen:

attachment.php

Quelle: "Multicore Processors and Systems", Danke an Dresdenboy für den Link.
<links><schema>
Wie man sieht ist alles an seinem Platz. Für INT Berechnungen sehen wir 12 Stufen, AMDs K10 benützt übrigens die gleichen Stufen. Schauen wir uns jetzt dazu Bobcats Pipeline an:

<uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">

Die Bobcat Pipeline​

file.php


Bobcats Pipeline erinnert frappant an die obige K8/K10 Pipeline. Es gibt (ohne Datencachezugriffe mitzuzählen) jetzt 13 Stufen. Die neue Stufe bezieht sich auf das Lesen der Register, möglicherweise eine Folge der neuen physikalischen Register Files (PRF). AMD dürfte somit ziemlich sicher das K8/K10 Design als Ausgangsbasis für Bobcat genommen haben. Typisch für die K8 und K10 Architektur ist unter anderem die "Pack" Stufe. Darin werden x86 Befehle, die in 2 interne MacroOps zerlegt werden müssen, gesammelt und "verpackt". Laut AMD Informationen sind das circa 10 Prozent. Die überwältigende Mehrheit (89 Prozent) der „Feld, Wald und Wiesen“- x86 Befehle können dagegen in einem Rutsch 1:1 in MacroOps umgewandelt werden. Das verbleibende Restprozent bearbeitet die langsame Microcodeengine </die></doofen></uralt></schema></links>[Quelle].
<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
Auffallend beim Bobcat ist die lange L2 Pipeline/Wartezeit im Vergleich zum K8/K10 Design. Das liegt vermutlich daran, dass der L2-Cache, ähnlich wie schon der L3-Zwischenspeicher des K10s, nicht mir vollem Kerntakt betrieben wird. Laut AMD wird er nur mit der Hälfte des Kerntaktes laufen.</die></doofen></uralt></schema></links>

Die K6 Pipeline​

Oft wird wegen der oben genannten Architekturmerkmale ein Vergleich mit AMDs alten K6 Design bemüht, welches ebenfalls 2-issue war. Der Aufbau der K6 Pipeline ist jedoch völlig anders, von Ähnlichkeit kann also nicht die Rede sein:
k6arch1.gif

Quelle: http://www.azillionmonkeys.com/qed/cpuwar.html

Wie man erkennt, hatte der K6 nur 7 Pipeline-Stufen, nicht einmal halb soviel wie das Bobcat-Design (mit Datencachezugriffen). Der interne Aufbau ist aus diesem Grund komplett anders. Die Gemeinsamkeiten beschränken sich nur auf grobe Äußerlichkeiten.

Bobcats Vorfahren sind somit eindeutig in der K8 und K10 Familie zu suchen, nicht beim K6!
<links><schema>
<uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">

Der Floorplan​

file.php


</die></doofen></uralt></schema></links>Am Floorplan sieht man, wie die verschiedenen Einheiten aus der obigen Architekturgrafik genau auf dem endgültigen Siliziumchip verteilt wird. Im Vergleich zu alten K8/K10 Diagrammen fallen erstens die unregelmäßigen, ja fast schon chaotischen Segmentierungen auf. Grund hierfür ist das Verwenden von automatischer Layoutsoftware (Electronic design automation (EDA)), die bisher nur im Embedded/SoC-Bereich gebräuchlich war. Handoptimierte Designs bestehen hingegen aus mehr oder minder aus rechteckigen, regelmäßigen Blöcken. EDA-Software beim Chipentwurf verschwendet zwar etwas Platz, spart aber eine Menge Handarbeit und somit Zeit und Kosten ein. Zweitens fällt bei genauerer Betrachtung die FPU Größe auf. Denn deren Fläche ist verschwindend gering, fast hat man Schwierigkeiten die FPU zu finden. In etwa entspricht sie der Größe des 32kB L1 Caches. Im Vergleich zu alten K8 oder gar K10 Zeiten ein deutlicher Unterschied. In Dresdenboy Blog war einmal eines IEEE Papers zu finden, in dem eine neue FPU beschrieben wird, die in nur 40 Prozent der Fläche der K8 FPU fast die gleiche Leistung bringt und dabei auch noch weit weniger Energie verbraucht. 40 Prozent Fläche käme gut hin. Die Wahrscheinlichkeit ist groß, dass die beschriebene FPU im Bobcat Verwendung findet.
<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^=""> </die></doofen></uralt><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
Schauen wir uns jetzt im Vergleich dazu Intels Konkurrenzprodukt, den Atom Prozessor an.

Vergleich mit Atom​

</die></doofen></uralt></schema></links>Zuallererst muss man beim Atom erwähnen, dass Intel nicht nur den klassischen PC-Markt im Visier hat, sondern von Anfang an auch den der Mobiltelefonen im Blick hatte. Aus diesem Grunde ist die Atom Architektur konsequent auf Stromsparen ausgelegt. Eine InOrder-Architektur sollte, dank einfachen Aufbaus, nochmals Transistoren einsparen. AMD hingegen wollte nicht ganz so radikal geizen beim Bobcat und setzt, wie bereits oben erwähnt, auf eine „Out of Order“-Architekur. Genaueres folgt nun in den nächsten Absätzen:
<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">

Die Atom Architektur​

blockdiag.jpg


</die></doofen></uralt></schema></links>
Vergleicht man erst einmal nur die bloße Architektur, stellt man auf den ersten Blick nicht viel Unterschiede fest. Genauso wie AMD bei Bobcat setzte auch Intel bereits vor zwei Jahren auf ein 2-issue Design. Der Grund dafür ist, dass bei einem schlanken Leichtkerner ein optimales Verhältnis aus Aufwand und Nutzen besteht. Circa 95 Prozent des x86 Codes lässt sich mit einem 2-issue ohne Datenstau abarbeiten. Der Mehraufwand für komplexe parallele 3-issue (K8/K10 / Core2/Nehalem) lohnt nicht im Low-Power Bereich. AMD ist sogar beim großen Bruder Bulldozer auf eine zweifache Parallelität der Pipelines zurückgekommen. Das ergibt auch bei Hochleistungsdesigns Sinn. Ein ehemaliger AMD Entwickler erklärte dazu, dass der Verzicht auf die dritte Pipeline nur ~5 Prozent Leistung kostet. Belohnt wird die neue Sparsamkeit dafür mit etwas, wonach sich Prozessor-Enthusiasten seit Jahren sehnen – mehr Takt. Konkret spricht die gleiche Quelle von 20 bis 30 Prozent höheren Taktraten <links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">[Quelle]. Aber das sei hier nur am Rande bemerkt.

Schauen wir uns nun die Atom Pipeline genauer an:

Die Atom Pipeline​

pipeline.jpg


Wie man sieht hat der Atom die gleiche Pipeline-Länge wie Bobcat, denn Intel zählt die Stufen für den Daten - Cachezugriff in der obigen Illustration fest dazu. Falls aber nur Daten in den Registern manipuliert werden, fallen die drei Stufen aber natürlich weg. Demnach kann man also wie auch schon im vorherigen Fall eine Übereinstimmung vermelden, beide Designs sind 2-issue mit einer 13 (16) Stufen langen Integer Pipeline (je nach Zählweise). Aber wie so oft, liegt der Teufel im Detail. Ein paar Punkte wurden bereits angedeutet, schauen wir sie uns im nächsten Kapitel nun einmal ganz genau an:
[BREAK=Der Teufel steckt im Detail]
</die></doofen></uralt></schema></links>

Der Teufel steckt im Detail​

Trotz aller Gemeinsamkeiten gibt es fundamentale Unterschiede zw. den beiden Ansätzen.

Die In-Order und Out-of-Order Entscheidung​

Zuallererst muss man Atoms schon angesprochene In-Order Basis gegen Bobcats Out-of-Order (OoO) vergleichen.

Was ist denn nun besser? Tja, das kommt darauf an, welche Ziele man sich setzt. Hier sieht man nun die Auswirkungen des kleinen aber feinen Unterschied in den Anwendungsprofilen beziehungsweise den Designzielen. Während Atom laut Intel irgendwann auch einmal in einem Mobiltelefon auftauchen soll, lässt AMD diesen Markt links liegen. Das hat zur Folge, dass der Atom wirklich knallhart und kompromisslos auf Energiesparen getrimmt wurde, wogegen das Bobcat-Designteam einige leistungssteigernde Kompromisse eingehen durfte.
Der auffälligste und tiefgreifendste dieser Punkte ist eindeutig InOrder gegen Out of Order (OoO).

Bei InOrder-Designs werden die Befehle so abgearbeitet wie sie kommen. Muss auf einen Cache oder gar RAM Zugriff gewartet werden, dann stehen die Rechenräder still. Eine OoO CPU dagegen kann nachfolgende Befehle vorziehen, beziehungsweise Befehle auf gut Glück spekulativ berechnen lassen. Manchmal klappt das nicht und die Spekulation war umsonst, aber die Trefferrate liegt bei modernen OoO Designs oberhalb der 90 Prozent Marke. Insgesamt gibt das Ganze einen gutes Leistungsplus von ca. 20-30 Prozent. Nicht umsonst waren bis Atom alle Intel CPUs seit Pentium1 Zeiten OoO basierend.

Hyperthreading macht müde In-Order CPUs munter !?​

Wie wir seit dem letzten Punkt wissen kann eine OoO CPU Cache und RAM Wartezeiten besser überbrücken, während eine InOrder CPU stillsteht. Dass das Verschwendung wäre hat auch Intel bemerkt und ATOM deshalb mit Hyperthreading ausgestattet. Damit laufen 2 Threads auf einem Kern. Falls jetzt das Rechenwerk wg. der Wartezeit eines Threads still steht, hat Thread 2 deshalb freie Fahrt. Logischerweise bringt Hyperthreading auf einer InOrder CPU deutlich mehr als auf einer OoO CPU. Gewinnt ein Nehalem mit OoO maximal 20-30 Prozent durch Hyperthreading, so können es bei ATOM schon mal bis zu 70 Prozent sein [P3DTest]. Zumindest bei Multithreaded-Anwendungen. Genau da liegt aber jetzt der Hase im Pfeffer. Die Single-Thread Leistung von ATOM ist schon schlecht und wird durch die zusätzliche Belastung eines 2ten Threads nicht besser. Vereinfacht ausgedrückt:
Anstatt eines 2-issue Kerns hat man mit Hyperthreading quasi zwei 1-issue Kerne. Das lastet zwar die Rechenwerke gut aus, steigert aber nicht die Single-Thread Rechenleistung - eher im Gegenteil.

Berichte in den Foren darüber, dass ATOM CPUs nur zäh reagieren würden, oder aber Flash Spielereien nur ruckelnd liefen sind nicht selten zu finden. Bei Multithread Anwendungen wie Packer, Renderer oder Konvertierungen lässt Hyperthreading zwar die Muskeln spielen, aber solche Anwendungsszenarien sind - außer den Packern - auf so leistungsschwachen Rechnern eher unwahrscheinlich.

Zusätzlich gibt es im Hyperthreadingbetrieb noch eine Menge Einschränkungen. Der parallele Betrieb ist nicht so einfach zu handhaben wie man meinen könnte. Genaueres ist im Optimierungsmanual von Agner Fog in Erfahrung zu bringen.

<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
</die></doofen></uralt></schema></links>

Das physikalische Registerfile​

Im Register stehen Daten, die unmittelbar zum Rechnen benötigt werden. Um sie dort hinzubekommen, werden sie aus dem Cache oder RAM geladen. InOrder CPUs haben den normalen Registersatz, den die ISA zur Verfügung stellt. Im x86 Falle sind das 8 INT und 8 SSE/FP Register, für den 64 Bit Modus stehen je 16 zur Verfügung. OoO CPUs gehen die Sache jetzt etwas kreativer an. CPUs dieser Art beherrschen das Register Renaming. Das ist ein Trick, um mehr schnelle Register zu benutzen, als die x86 ISA zur Verfügung stellt. Für Bulldozer stehen z.B. 160 SSE/FP und 96 INT Register im Raum [Quelle]. Diese vielen Register braucht man v.a. für das spekulative Ausführen von Befehlen. Logischerweise kann man spekulative Berechnungen nicht auf den Orginalregistern herumschreiben lassen, das gäbe ein Datenchaos. Stattdessen bekommen diese ihren eigenen Satz der 16 Registern vorgespielt.

Im K8/K10 sowie allen Intel OoO CPUs gibt es nun einen sogenannten ReOrderBuffer (ROB). Wie der Name schon nahe liegt, ist er das Endstück einer OoO Berechung. Seine Aufgabe ist es, die ursprüngliche Befehlsreihenfolge wiederherzustellen. Dazu schreiben Instruktionen, deren Berechnungen in spekulativen Registern abgeschlossen ist, Ihr Endresultat, d.h. den Registerinhalt in den ROB. Der ROB wiederum sortiert alle Instruktionen richtig ein, und schreibt die Ergebnisse danach in ein "offizielles" der 8 bzw.16 Architekturregister zurück. Wie man nun leicht festellen kann, wird hier oft kopiert. Das kostet Zeit, vor allem aber auch Strom. Prozessoren mit physikalischen Registern setzen dieser Verschwendung nun einen Riegel vor. Die Daten bleiben immer nur in einem Register, es wird nichts kopiert. Was sich ändert sind nur Verweise darauf.

Vereinfacht ausgedrückt: Anstatt die Daten mit Sack und Pack von einem Haus (=Register) ins nächste zu jagen, wechselt man einfach das Hausnummernschild bzw. den Wegweiser zum Haus aus und protokolliert die Namensvergaben in einem zentralen Adressverzeichnis.

Eine simple Idee die Strom einspart und auch schon in vielen CPU Designs verwendet wurde, u.a. in einigen DEC ALPHA CPUs sowie in IBMs POWER4, 5 und 7 CPUs [Quelle]. Falls jemand nun das Power6 Design vermisst: Das war ein InOrder Design. In der x86 Familie war bisher nur der unrühmliche Pentium4 damit ausgestattet. AMD verwendet die Technik nun sowohl bei Bulldozer als auch bei Bobcat, also bei allen neuen Architekturdesigns - sicher keine schlechte Entscheidung.

Die Fetch-Breite​

<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^=""> AMDs Bobcat holt sich pro Takt beachtliche 32byte Daten aus dem Instruktionscache. Dies scheint - zusammen mit den SSE4A Befehlen - ein Erbe des K10 zu sein und überrascht etwas bei einem Mobil-Design. Intel nützt selbst bei den aktuellen High-End CPUs den üblichen 16 Byte Fetch, den es seit seligen PentiumPro Zeiten gibt. AMD setzte beim K8 ebenfalls auf "nur" 16 Byte. Aber nun ja, über zuviel Leistung wird sich niemand beschweren wollen. Vermutlich hat AMD Simulationen gefahren und berechnet, dass die Fetch-Breite nicht viel Energie kostet beziehungsweise sich insgesamt positiv bemerkbar macht.

Im Vergleich dazu ist Atoms Fetch-Breite nur mickrig zu nennen. Die offiziellen PDFs und Berichte schweigen sich dazu "zufällig" aus. Prof. Dr. Agner Fog nennt dann auch in seinem bereits erwähnten x86 Optimierungsleitfaden enttäuschende um die 8 Byte. Also nur ein Viertel von Bobcat. Das hat dann negative Auswirkungen, wenn zwei Befehle decodiert werden müssen, die zusammen diese 8 Byte Grenze überschreiten. Vor allem. 64 Bit Befehle und praktisch alle SSE2++ Befehle fallen darunter. Das erklärt dann auch Intels Zögern den Atom CPUs die 64 Bit Erweiterung freizuschalten. Die Auswirkungen sind deutlich. Solange das Front-End keine Daten liefert, können die Rechenpipelines auch nichts berechnen; die Rechenleistung sinkt damit auf 1-issue. Das erklärt dann auch das starke Plus durch Hyperthreading. Wegen Hyperthreading ist auch die Fetch-Einheit verdoppelt, so dass dann für zwei Threads 2x8 Byte eingelesen werden können. Das resultiert dann in mindestens zwei SSE Befehlen pro Takt, was ausreichend ist, um die 2-issue Recheneinheiten gut auslasten zu können. Nur leider hat man davon nichts im Single-Thread-Betrieb.

</die></doofen></uralt></schema></links>

Zusammenfassung​

Zusammenfassend muss man leider sagen, dass es für Atom nicht gut ausschaut. Das Design ist deutlich für absolutes Stromsparen ausgelegt, um auch im Mobiltelefonmarkt bestehen zu können. Leider gibt es aber noch kein einziges x86 Handy. Eventuell wird sich das ändern, nachdem Intel vor kurzem Infineons Mobiltelefonsparte übernommen hat [Quelle]. Aber trotzdem wird sich Atom den Mitbewerbern in anderen Segmenten stellen müssen, solange man CPUs im Net- und Notebooks bzw. Nettopbereich absetzen will. Die Vor- und Nachteile sind dabei klar verteilt:

Bobcat wird die deutlich bessere Single-Thread Leistung aufweisen. Atom könnte durch Hyperthreading zumindest bei Spezialfällen aufholen. Allerdings ist Bobcat kein fertiger Chip, sondern nur ein Designbaustein. Erstmals werden zwei Bobcat Kerne im bereits erwähnten Ontario/Zacate Fusion Chip Verwendung finden. Setzt man dem nun zwei Atom Prozessoren eines Pineview Atoms mit Hyperthreading gegenüber, ist die Rechnung quasi 2 x 2-issue gegen 4 x 1-issue. 2x2 dürfte dabei das deutlich komfortablere User Erlebnis bieten.

AMD könnte somit durch den Verzicht aufs Handygeschäft und großzügigeren Verbrauchsbudget einen deutlichen Vorteil gegenüber Intel haben. Dieser könnte sogar größer ausfallen als vermutet. Geht man normalerweise davon aus, dass ein OoO Kern größer als ein InOrder Design sein müsste, weist die neueste Vergleichsgrafik von Hans de Vries einen Flächenvorteil von Bobcat gegenüber Atom aus:

AMD_Ontario_Bobcat_vs_Intel_Pineview_Atom.jpg


Zwar hat AMD auch einen leichten Fertigungsvorteil von 40nm gegenüber 45nm, dennoch ist es beachtlich, dass ein einzelner Bobcat-Kern kleiner ist.
<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^="">
[BREAK=Ausblick]

Ausblick​

</die></doofen></uralt></schema></links>Nachdem nun bekannt ist, dass nicht nur Bobcats Rechenleistung sondern auch Ontarios Die-Flächenverbrauch konkurrenzfähig ist, kann man vom Bobcat das erwarten, wofür eher der Name des größeren Bruders Bulldozer stehen würde – den Gegner wegschieben - so wie amerikanische Pioniere im zweiten Weltkrieg feindliche Bunkerfestungen mit Planierraupen einfach überrollten: Das untere Marktsegment wird mit den vollintegrierten Bobcat-Kernen neu definiert. Selbst der aktuelle integrierte Pineview-Atom ist in allen Belangen unterlegen. Wenn man den Vergleich auf den ganzen Chip, inklusive ATI-Grafikteil ausweitet, wird der AMD Vorteil eher noch größer ausfallen. Selbst beim Verbrauch liegt Atom nicht vorne. Intel gibt für einen Einzelkern-Pineview mindestens 7 Watt an. Für den Zweikerner fallen schon 15 Watt an [Quelle]. Ontario und Zacata werden sich dagegen zwischen 9 und 18 Watt eingruppieren. Angesichts der deutlich höheren Rechen- und Grafikleistung absolut akzeptabel.

Einzige Unbekannte der obigen Spekulation wären deutlich geringere Taktfrequenzen von Ontario im Vergleich zum Atom. Zwar sollte auch in diesem Fall der Fertigungsvorteil eine positive Rolle für Bobcat spielen, dennoch bleibt eine gewisse Unsicherheit, die es zu beobachten gilt. Außerdem könnte sich AMD den Leistungsvorteil natürlich auch gut bezahlen lassen, in diesem Fall bliebe für Atom die Lücke der Lowest-Cost-Netbooks.

Wenn wir mit dieser Spekulation nun in der Gerüchteküche angelangt sind, soll auch nicht verschwiegen werden, dass vielleicht sogar Apple Ontario verwenden wird. Als OpenCL Verfechter der ersten Stunde setzt Apple auf leistungsfähige GPUs. Somit ist es nicht verwunderlich dass Apple Interesse am Ontario nachgesagt wurde [Quelle].<links><schema><uralt folie=""><doofen marketingname="" einfügen=""><die zahlen="" gibts="" hoffentlich="" irgendwo="" auf="" der="" marketingfolie="" ^^=""><bla>

</bla></die></doofen></uralt></schema></links>Richtig interessant wird Intel vermutlich erst wieder werden, wenn im zweiten Halbjahr 2011 die 32nm Atom Chips auf den Markt kommen. Bis dahin aber wird das Bulldözerchen alias Bobcat im Markt für größere Bewegungen sorgen.

Danksagungen​

  • Mitglied jcworks für das Korrekturlesen
  • Mitglied Martin Bobowsky für die Textüberarbeitung
  • Hans de Vries für seine Ontario <> Pineview Vergleichsgrafik
  • Dresdenboy für den Link auf die K8 Pipeline
  • Computerbase für die Ontario Bilder von der IFA

 
Zurück
Oben Unten