AMDs Bulldozer-Architektur - ein Puzzle zusammengesetzt

Dresdenboy

Redaktion
☆☆☆☆☆☆
Mitglied seit
28.10.2003
Beiträge
3.090
Renomée
203
Standort
Berlin
0b52664e099645c896122d33ef5f3a9c


<center></center>
Vorwort des Herausgebers
Um Missverständnisse vor vorne herein auszuschließen, möchten wir gleich zu Beginn vorweg schicken: die Informationen, die dieser Artikel enthält, sind aus hunderten von Einzelquellen verschiedenen Alters zusammen getragen. Der Artikel enthält keine durch uns geleakten, unter NDA stehenden Informationen, sondern ausschließlich Daten, die bereits irgendwo veröffentlicht wurden, sowie Meinungen und Interpretationen unseres Gast-Autors "Dresdenboy", den wir für diesen Artikel gewinnen konnten. Dresdenboy hat sich in seinem Blog bereits vor geraumer Zeit zum Hobby gemacht, durch "patent based research" wie er es nennt Rückschlüsse zu ziehen darauf, welche Techniken AMD in seinen kommenden Prozessoren einsetzen könnte. Der Artikel ist also eine Mischung aus gesicherten Fakten, die AMD bereits veröffentlicht hat und Interpretationen von Technologien, die AMD hat patentieren lassen und Gerüchten und Spekulationen anderer Hardware-Webseiten aus deren inoffiziellen Quellen. Daher sind wir gespannt, wie genau der Autor den finalen Bulldozer dann letztendlich getroffen haben wird, wenn AMD offiziell damit herausrückt.


Einleitung​

Schon seit Jahren sind viele Hardware-Fans gespannt, wie der nächste große Wurf einer Mikroarchitektur von AMD aussehen und was er leisten wird. Mittlerweile sind es sogar zwei Mikroarchitekturen, die mit Interesse erwartet werden. Einige Details wurden von AMD bereits bekannt gegeben und ein recht großer Umfang an Spekulationen begleitete den Weg dieser Neuentwicklungen. In Kürze wird AMD weitere Details auf der Hot Chips Conference veröffentlichen, welche sicherlich einige Antworten geben, aber laut AMD noch verschiedene Punkte offen lassen werden. In diesem Artikel soll nun eine Art Vorschau der Bulldozer-Architektur auf Basis von verfügbaren Informationen und Spekulationen erfolgen. Sie soll möglichst nah an die reale Architektur heranreichen und um viele Gedanken erweitert eine genauere Basis für eigene Überlegungen bilden.

Situation AMD - Ein kleiner Rückblick
AMD lebt seit der Einführung der K7-Microarchitektur (im "Athlon") 1999 bis heute von Varianten und evolutionären Schritten einer einzigen Basisarchitektur. Diese wurde unter Einfluss der mit K5 und K6 gemachten Erfahrungen und durch Zuwanderung von Wissen in Form von ehemaligen Mitarbeitern der Firma Digital Equipment Corporation (DEC), welchen u.a. der heutige CEO Dirk Meyer angehörte, entwickelt. Bekanntermaßen stießen sowohl K6-2 als auch K6-III bei Taktfrequenzen um 500 MHz an ihre Grenzen. Der neu entwickelte K7 ermöglichte neue Frequenzbereiche und auch einen höheren Befehlsdurchsatz pro Taktzyklus (IPC = Instructions Per Cycle), vor allem durch die deutlich breitere und vor allem mit Pipelining ausgestattete FPU. Seine Rechenleistung war hoch genug, um auch den damals auf dem Markt befindlichen Konkurrenten Pentium-III zu überholen. Selbst der Ende 2000 auf den Markt geworfene Pentium 4 mit Willamette-Kern hatte von Beginn an einen schweren Stand, da AMD in der gleichen Zeit beim Herstellungsprozess von 0,25 µm auf 0,18 µm mit Kupferleitungen umstieg und damit neue Taktfrequenzbereiche erschloß.
Das K7-Design erfuhr weitere Neuerungen, wie z.B. die Integration des L2-Caches (bis dahin als externer Chip auf dem Package) oder die Unterstützung von SSE. Intel schaffte es in dieser Zeit mit SMT ("Hyperthreading"), größeren Caches, neuen Produktionsprozessen, höheren Takten und auch dank zunehmender Nutzung von SSE2, den Vormarsch der K7-Microarchitektur zu stoppen, sodass AMD vermehrt auf Preissenkungen zur Ankurbelung des Umsatzes zurückgreifen musste.

Basierend auf dem K7-Design wurde der K8 ("Opteron", "Athlon 64") mit der "Hammer"-Microarchitektur entwickelt und im Jahr 2003 auf den Markt gebracht. Obwohl damals verschiedene Patente auf andere Microarchitekturen hinwiesen, die wahrscheinlich intern in Entwicklung waren und keine Ähnlichkeiten mit der K7-Microarchitektur aufwiesen, wurde eine Microarchitektur vorgestellt, welche den Eindruck eines aufgebohrten K7 erweckte. Der Grund dafür kann wirtschaftlichen Ursprungs gewesen sein, da die Entwicklung eines Designs bis zur Marktreife hohe Kosten und Zeitaufwand verursacht und die Einführung einer neuen Microarchitektur wichtig für den wirtschaftlichen Erfolg sein kann. Der erste "Hammer"-Prozessor, der Opteron, war bei seinem Erscheinen schon deutlich verspätet. Ein Grund dafür war wahrscheinlich die anfangs schlechte Chip-Ausbeute bei der Herstellung der Prozessoren im neuen 130nm-SOI-Prozess.

Im Jahr 2007 kam AMD's letzte Microarchitektur mit deutlichen Änderungen gegenüber der Vorgängerarchitektur auf den Markt in Form des Barcelona-Prozessors. Dessen Kern wird meist mit „K10-Kern“ und der des ersten 45nm Prozessors Shanghai mit „K10.5-Kern“ bezeichnet. In den Foren wird teilweise die Bezeichnung K15 für den Bulldozer verwendet, was sich mit der schon bekannten Family-Nummer der Bulldozer-Prozessoren (15h bzw. 21) deckt, wie auch schon Barcelona (Family 10h) sich mit K10 decken würde. Diese Bezeichnung ist zwar inoffiziell und von AMD nicht zur Verwendung vorgesehen, dafür aber kurz und eindeutig. Im Netz veröffentlichte Lebensläufe von AMD-Mitarbeitern und einige frühe Gerüchte ordnen bzw. ordneten den Begriff „K10“ dem Bulldozer-Kern zu, während die K10- und K10.5-Kerne mit 128-bit FPU unter den Flaggen „Stars“ und „Hound“ liefen. Aus Verständlichkeitsgründen sollen hier ebenfalls die Bezeichnungen „K10“ und „K10.5“ für Barcelona- bzw. Shanghai-Kerne verwendet werden. Aber nun zurück zum Rückblick: Dieser neue Kern brachte wieder viele Änderungen mit, die hier beispielhaft aufgelistet sind:

* Comprehensive Upgrades for SSE
- Dual 128-bit SSE dataflow
- Up to 4 dual precision FP OPS/cycle
- Dual 128-bit loads per cycle
- Can perform SSE MOVs in the FP “store” pipe
- Execute two generic SSE ops + SSE MOV each cycle (+ two 128-bit SSE loads)
- FP Scheduler can hold 36 Dedicated x 128-bit ops
- SSE Unaligned Load-Execute mode
[...]
(siehe Originalzusammenstellung und vervollständigte Fassung)

Erweiterungen des K10-Cores
Die wesentlichsten Änderungen des K10 (mit der größten Wirkung auf die IPC) waren die Erweiterung der FPU auf 128 bit und die entsprechende Erweiterung der Datenpfade vom Cache zur FPU auf ebenfalls 128 bit. Damit konnten nun endlich SSE- und SSE2-Befehle in voller Breite bearbeitet werden, was den Durchsatz für die meisten wichtigen Befehle verdoppelte. Um diesen höheren Befehlsdurchsatz auch sicherzustellen, wurde die Instruction-Fetch-Bandwidth auf 32B erhöht. Weiterhin konnten nun die Befehle für die 128 bit breite Verarbeitung von SSE-Registern effizienter dekodiert werden und benötigten in den meisten Fällen nicht mehr 2 µOps sondern nur noch 1. Damit konnten effektiv mehr SSE-Befehle im Scheduler der FPU gehalten werden, was die verfügbare Auswahl für die anstehende Ausführung in den FP-Einheiten deutlich erhöhte.

Eine letzte Welle an Verbesserungen am K10-Kern bringt der erst kürzlich vorgestellte überarbeitete K10-Kern im Llano-Prozessor mit sich (siehe Meldung oder entsprechende Blogbeiträge mit Anmerkungen zum Die). Dazu gehören Erweiterungen des Reorder-Buffers, der Integer-Scheduler, der Translation Lookaside Buffer (TLB) und Verbesserungen bei einigen FP-Befehlen, der Integer Division. Weiterhin bringt er ein neues Energiemanagement (Digital APM), welches neben Taktfrequenzanhebungen und Core-Abschaltungen sicherlich auch Maßnahmen für die integrierte GPU beinhaltet. Spätestens seit dem Turbo-Boost-Feature des Nehalem war deutlich, dass Power Management nicht nur zum Energiesparen gut ist. Wie bereits bekannt, enthält auch schon der Thuban-Prozessor (Phenom II X6) ein ähnliches Feature (siehe News und Hintergründe).

[BREAK=Erste offizielle Ankündigung des Bulldozers]
0b52664e099645c896122d33ef5f3a9c

Erste offizielle Ankündigung des Bulldozers​

Ebenfalls 2007 kündigte AMD für 2009 zwei neue Microarchitekturen mit den Namen "Bulldozer" und "Bobcat" an, welche für unterschiedliche Anwendungsbereiche entwickelt sein sollten und damit eine deutlichere Spezialisierung aufweisen würden, als es bis dahin auf Basis von Derivaten der "Hammer"- und später „Stars“- und "Hound"-Kernen stattfand.




Entsprechend diesen Ankündigungen sollte "Bulldozer" die neue Microarchitektur für den Einsatz im mittleren bis hohen Leistungsspektrum werden. Das reicht von leistungsfähigen Notebooks über Desktopsysteme bis zu Servern. Wie in der gezeigten Folie zu den geplanten Leistungssteigerungen zu sehen ist, sollten diese je nach Anwendungsfall moderat (single threaded) bis hoch (multi-threaded, HPC) sein.

Der "Bobcat"-Core sollte dagegen AMD's wirklich erste selbst entwickelte Architektur für den Low-Power-Markt werden. Bisher konnte man da mit zugekauften Designs (Alchemy, Geode) oder im Rahmen der Möglichkeiten mit angepassten Designs der eigenen x86-Reihen mitmischen. Da diese Lösungen verschiedene Einschränkungen aufwiesen, alle Marktsegmente von Low-Power bis High-Performance abgedeckt werden sollten und der neue High-Performance-Core "Bulldozer" ohne Einschränkungen durch einen geplanten Einsatz im Low-Power-Markt entwickelt werden sollte, entschied man sich, zwei unabhängige Designs zu entwickeln.
Intel hat schon länger durch dedizierte Designs für den High-Performance- und den Low-Power-Markt bewiesen, dass sich diese Strategie auszahlt. (z.B. Northwood/Prescott und Banias/Dothan - oder Conroe und Silverthorne).
[BREAK=Modulkonzept]
0b52664e099645c896122d33ef5f3a9c

Modulkonzept​

Zu der Zeit wurde auch die modulare Designphilosophie "M-SPACE" vorgestellt. Diese vorgestellte Modularität sollte die Entwicklung verschiedener Prozessor-Designs für unterschiedliche Märkte flexibler darstellen und den Zeit- und Kostenaufwand für die Entwicklung eines neuen Designs, wie z.B. eines Quad-Cores für den Mobilmarkt, verringern. Dabei sollten u.a. Cores, Hypertransport-Links, L3-Cache, Memory Controller und auch GPU Cores in Bausteinform miteinander kombiniert werden. Wie weit diese Philosophie Früchte trägt, wird sich an der Vielfalt zukünftiger Prozessordesigns ablesen lassen.


Diese neuen Architekturen sollten AMD für die Zukunft rüsten, um im stetigen Konkurrenzkampf mit Intel wieder in eine bessere Lage zu kommen. Zwar zahlte sich die neue Fokussierung auf ganze Plattformen und natürlich auch ein gutes Preis/Leistungs-Verhältnis bisher dahingehend aus, dass trotz der überlegenen Conroe- und Nehalem-Architekturen von Intel keine zu großen Marktanteilsverluste erlitten wurden, aber es fehlten die passenden Architekturen, um sich deutlicher behaupten zu können.

Die entsprechenden Ankündigungen waren teils vielversprechend. Nebenbei wurden von AMD verschiedene Befehlssatzerweiterungen vorgeschlagen, wie SSE5, Lightweight Profiling (LWP) und Advanced Synchronization Facility (ASF, zur Optimierung von parallelisierten Anwedungen). Umso enttäuschender war für viele sicherlich die Verschiebung des Erscheinungstermins für die neuen Architekturen auf das Jahr 2011. Die möglichen Gründe dafür wurden vielfach diskutiert. Einen Grund dafür hat nun John Fruehe verlauten lassen:
Bulldozer in 2009 would have been a DDR-2 based processor. There were changes made to the processor that also allowed it to get more performance and scalability. The Bulldozer that was defined for 2009 is not what you will be seeing in 2011. We made the changes and realigned the schedule to make it more compeititive.
Ein anderer möglicher Grund war die Ankündigung von AVX durch Intel, was AMD schließlich veranlasste, die 128-bittige SSE5-Befehlssatzerweiterung auf 256-bit zu verbreitern und AVX-Kompatibilität zu integrieren. Die etwas genaueren Hintergründe und Auswirkungen sind in Opterons AVX-Artikel nachzulesen.

Weitere Gründe könnten Verzögerungen aufgrund der Komplexität, weitere eingebrachte Anpassungen im Design oder einfach die Fokussierung auf den 32nm-Prozess gewesen sein, da der 45nm-Prozess noch nicht die gewünschten Verbrauchswerte oder Die-Größe ermöglichte. Andererseits könnten eventuell noch vorgesehene Anpassungen des Bulldozer-Designs Verschiebungen bewirkt haben, dass das 45nm-Zeitfenster zu klein geworden wäre und neben dem 45nm-Design in Kürze auch noch der Aufwand für den 32nm-Shrink angefallen wäre. Charlie Demerjian erwähnte in einem Forenbeitrag, dass zu der Zeit auch wesentliche personelle Änderungen im Gange gewesen sein sollen, welche schließlich zu einer besseren Außenwirkung des Unternehmens, z. B. durch vorgezogene Produktstarts der Shanghai- und Istanbul-Prozessoren, führten.

So mancher Leser wird sich auch daran erinnern, dass AMD sowohl einen Prozessor namens "Hydra" auf den Markt bringen wollte - mit dem G3-Sockel, seriell angebundenem Speicher (wie FB-DIMM) und 8 Kernen. Heutige 6-Kern-Prozessoren mit der Stepping-Kennung "HY-" könnten ein Hinweis auf das Design sein. Aber da auch der Bulldozer vorerst als 8-Kerner geplant war, wie auf der folgenden Folie zu sehen ist, gab es vermutlich produktstrategische Anpassungen, die zu einem 6-Kern-Design (Istanbul, Lisbon, Thuban), einem 12-Kern-Design als MCM (Magny-Cours) und einem 16-Kern-Design als MCM mit dem Bulldozer-Kern führten.

Für ergänzende Informationen zur Geschichte sei auf diesen Planet 3DNow-Artikel verwiesen.

[BREAK=Mikroprozessorentwicklung im markttechnischen Umfeld]
0b52664e099645c896122d33ef5f3a9c

Mikroprozessorentwicklung im markttechnischen Umfeld​

Betrachtet man sich die wirtschaftliche Entwicklung von AMD über die letzten Jahre, die Entwicklung des Marktanteils in den Segmenten Desktop, Server und Mobil, die Übernahme von ATI, die großen Pläne der Fusion-Initiative sowie die Entwicklungen bei den Wettbewerbern, ist die Notwendigkeit einer neuen, diversifizierten Microarchitekturpalette für AMD deutlich. Aber auch ein solches Vorhaben muss finanzierbar sein und sollte schließlich zum Erfolg führen.

Bei der Entwicklung von Mikroprozessoren spielen viele Faktoren eine Rolle. Dabei gilt es immer, einen Kompromiss zu finden, welcher eine hohe Profitabilität sowohl auf kurze als auch auf lange Sicht bietet. Zu diesen Faktoren zählen z.B. Entwicklungskosten, Entwicklungszeit und der Zeitpunkt der Verfügbarkeit. Die Entwicklungskosten beinhalten zum Beispiel Kosten für Personal, Hardware, Entwicklungswerkzeuge. Die Größenordnung liegt für heutige komplexe Microprozessordesigns im Bereich von mehreren Hundert Millionen Dollar. Eng verwoben mit den Entwicklungskosten ist die Entwicklungszeit. Da der Gesamtentwicklungsaufwand grob konstant ist (gemessen in Mannjahren), aber ähnlich den Parallelisierungsgrenzen bei der Softwareentwicklung durch serielle Anteile die Entwicklungszeit nicht beliebig verkürzt werden kann, muss hier auch ein Kompromiss aus Zeit, Kosten, Aufwand durch Aufstockung von Personal und unternehmerischem Risiko gefunden werden. Große Entwicklungsteams sollten schließlich auch in Zukunft durch geplante Produkte gut ausgelastet sein und entsprechend ihrer Fähigkeiten eingesetzt werden können.

Der Faktor Verfügbarkeit („Time to Market“) spielt eine große Rolle dabei, ein Produkt zu entwicklen, mit dem ein Gewinn erwirtschaftet werden soll. Da AMD mit den Mikroprozessoren nicht allein am Markt ist, besteht ein ständiger Konkurrenzdruck, fast ausschließlich verursacht durch Intel. Da durch diese Marktsituation ein potenzieller Käufer sich zwischen Produkten mehrerer Hersteller entscheiden kann, spielt es eine große Rolle, wann ein Produkt mit besseren Eigenschaften (z.B. Rechenleistung, Preis, Energieverbrauch, Stabilität) auf den Markt kommt. Man kann diesen Zeitraum, in dem mit dem entwickelten Produkt unter Einbeziehung aller Kosten und der erwarteten Umsatzentwicklung ein Gewinn erwirtschaftet werden kann, auch Profitabilitätsfenster nennen. Die Größe dieses Fensters kann sich über die Zeit durch äußere und innere Einflüsse ändern. Zu äußeren Einflüssen gehören z.B. Konkurrenzprodukte oder Marktentwicklungen. Innere Einflüsse sind vor allem Änderungen der Produkteigenschaften, wie z.B. die Entscheidung für einen neueren Herstellungsprozess (von 45 nm zu 32 nm HKMG) und eine andere Speicherplattform (von DDR2 zu DDR3) beim Bulldozer. Demnach hätte das Profitabilitätsfenster für den Bulldozer, wie er für 2007 geplant war, anders ausgesehen, als es jetzt der Fall ist. Analog verhält es sich für den Bobcat-Kern.

Es gibt Gerüchte, dass Intel den Sandy-Bridge-Kern als Reaktion auf Bulldozer derzeit überarbeitet. Dieser neue Kern soll Version 1.1 darstellen und neue Fähigkeiten aufweisen, die ihn konkurrenzfähiger machen sollen. Wenn er nicht bis zum geplanten Erscheinungstermin produktionsreif sein sollte, würde die jetzige Version auf den Markt kommen. Solche Entscheidungen würden natürlich das Profitabilitätsfenster sowohl von Sandy Bridge als auch Bulldozer beeinflussen. So wie es aktuell ausschaut wird aber Sandy Bridge vorgezogen. Dadurch betrüge der Vorsprung vor AMDs Bulldozer ca. ein halbes Jahr, was ein gutes Profitabilitätsfenster ergäbe.

Angesichts solcher Begleitumstände stehen die Hersteller von leistungsfähigen Prozessoren häufig vor großen Entscheidungen. Die Weiterentwicklung einer vorhandenen Prozessorarchitektur (also nicht nur bezogen auf Einzelkerne) kostet weniger, birgt weniger Risiken, kann dafür aber nur ein weniger attraktives Profitabilitätsfenster bieten, da es oft nur ausreicht, um am Markt Schritt zu halten. Eine Neuentwicklung z.B. eines Rechenkerns oder einer I/O-Architektur (z.B. der Front Side Bus oder HyperTransport) verursacht mit einem höheren Risiko verbundene höhere Entwicklungskosten und –zeitaufwände, eröffnet dafür aber auch ein deutlich attraktiveres Profitabilitätsfenster. Und da neu entwickelte Prozessorkomponenten häufig noch in Folgeprodukten weiterverwendet und –entwickelt werden, beeinflussen sie sogar noch die Profitabilitätsfenster dieser Produkte.
Beispiele:

<table summary="Grobe Entwicklung der AMD-Prozessorarchitekturen" style="text-align: center;" border="1" cellpadding="3" cellspacing="0"><tbody><tr><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">CPU</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">Kern</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">I/O-Arch</th></tr><tr><td> K6</td><td>neu</td><td>alt</td></tr><tr><td> K6-2</td><td>erweitert</td><td>alt</td></tr><tr><td> K6-III</td><td>alt + L2</td><td>alt</td></tr><tr><td> K7 Pluto</td><td>neu</td><td>neu</td></tr><tr><td> K7 Thunderbird</td><td>alt + schnellerer L2</td><td>alt</td></tr><tr><td> K8</td><td>erweitert</td><td>neu</td></tr><tr><td>Dual Core K8</td><td>2 x alt</td><td>alt</td></tr><tr><td> <st1:city w:st="on"><st1:place w:st="on">Barcelona</st1:place></st1:city></td><td>2 x erweitert + L3</td><td>alt</td></tr><tr><td> <st1:city w:st="on"><st1:place w:st="on">Shanghai</st1:place></st1:city></td><td>modifiziert, L3*3</td><td>alt</td></tr><tr><td> Istanbul</td><td>alt + 2</td><td>verbessert</td></tr><tr><td> Magny Cours</td><td>2 x alt</td><td>2 x alt</td></tr><tr><td> Bulldozer</td><td>1,33 x neu</td><td>alt</td></tr></tbody></table>​

Der Einfachheit halber nicht dargestellt sind hier die Einflüsse paralleler Weiterentwicklungen wie Speichertechnologie oder Prozesstechnologie.

Strukturelle Änderungen im Unternehmen
In den letzten Jahren scheint sich bei AMD intern etwas verändert zu haben. Aussagen verschiedener außenstehender Personen (z.B. Charlie Demerjian) erwecken den Eindruck, dass die internen Geschäftsprozesse verbessert wurden und in letzter Zeit allgemein zu einer besseren Ausführung und Außenwirkung des Unternehmens führten. Vorgezogene Produktstarts und weniger Probleme mit in Endprodukten auftretenden Fehlern stellen hier eine auffällige positive Entwicklung dar.

[BREAK=Erste Hinweise und Gerüchte zum Bulldozer-Architektur]
0b52664e099645c896122d33ef5f3a9c

Erste Hinweise und Gerüchte zum Bulldozer-Architektur​

Wie schon im Rückblick zu lesen war, gab es im Jahr 2007 die Ankündigung für die Bulldozer- und Bobcat-Cores. Diese enthielten aber wenig Information über die Architekturen und deren Leistungsfähigkeit.

Der erste IT-Journalist, welcher etwas über Bulldozer schrieb, war Charlie Demerjian, welcher zu der Zeit beim britischen „Inquirer“ arbeitete und in einem kurzen Artikel den Codenamen der neuen Architektur verlauten ließ. Auch wenn diesem Autor in manchen Kreisen eine persönliche Fehde mit Nvidia unterstellt wird, scheint er doch einen etwas tieferen Einblick in die Bulldozer-Entwicklung gehabt zu haben.

In späteren Artikeln äußerte er sich noch etwas genauer zur Architektur, aber durfte scheinbar nicht mehr erzählen (ohne seine Kontakte zu verärgern?), da er erst kürzlich in dem Forum von SemiAccurate schrieb, dass er schon seit Jahren auf der Architektur „saß“ und nichts dazu sagen durfte.

Weitere Gerüchte über einen „K9“ (zu einer Zeit, als dieser Codename noch nicht mit einem K8-Derivat assoziert wurde) tauchten auf, die interessanterweise doch einige Parallelen zur nun angekündigten Bulldozer-Architektur aufwiesen. Wo auch immer diese Gerüchte herkamen – sie können natürlich auch auf Basis der damals bekannten Patente u. Forschungsthemen entstanden sein.

In dieser Zeit wurde ein Gerücht besonders stark kolportiert: Es wurde gemunkelt, dass AMDs neuer Prozessor eine Technologie besitzen könnte, die ermöglichen sollte, mehrere Kerne zur Ausführung eines Threads zusammenzuschalten. Diese Technologie wurde in Anlehnung an Intel’s SMT-Technologie meistens „Reverse Hyperthreading“ (rHT) genannt. Dadurch sollte die größere Anzahl an Ausführungseinheiten helfen, den single threaded Code schneller auszuführen. Dabei war die durch die Ausführungseinheiten bereitgestellte Parallelität in den seltensten Fällen ein Flaschenhals. Es gab sowohl entsprechende Forschungsarbeiten zu diesem Thema (spekulatives Mutlithreading) als auch einige AMD-Patente, welche das hardwareseitige Erzeugen kleiner Threads für die Ausführung auf einem zweiten Core beschrieben.

Ein weiteres Gerücht sprach von einer sehr breit ausgelegten Architektur (8-wide!). In einem späteren Gerücht wurde dagegen berichtet, dass dieses Design verworfen wurde. Ähnliches höhrte man kürzlich über den Bobcat. Man kann das nun negativ werten, da es natürlich eine Verzögerung verursacht, aber betrachtet man die schon im Kapitel über Profitabilitätsfenster beschriebenen Argumente, sind solche Entscheidungen (sofern die Gerüchte zutreffen) nicht zwingend falsch. Wichtig ist, dass diese Entscheidungen relativ früh im Entwicklungsprozess (z.B. während der Architekturdefinition) getroffen werden, um sowohl früh eine andere Richtung einschlagen zu können als auch noch keine zu großen Entwicklungskosten zu haben.

Aber es gab nicht nur diese Quellen für weniger sichere Informationen. Eine der besten Quellen ist und bleibt natürlich der Hersteller des in Entwicklung befindlichen Produktes.

Da gab es bereits früh die Aussagen von dem damaligen CTO Fred Weber, welcher über die Richtungen für zukünftige Entwicklungen sprach. Diese Punkte wurden dabei von ihm hervorgehoben:
  • Kombination von Befehlen (wie bei Intels MicroOp-Fusion, von Weber „Instruction Combining“ genannt)
  • Höhere Taktfrequenzen
  • Niedrigere Speicherzugriffslatenzen
  • Niedrigere Sprungvorhersagelatenz (hier ist wohl die Branch Misprediction Penalty gemeint)
  • Thread Level Parallelism (TLP)
  • Geteilte Nutzung von Einheiten wie die FPU durch zwei Kerne zu deren besseren Auslastung und damit erhöhter Energieeffizienz
(siehe Fred Weber Interview)
Wie wir sehen werden, gibt es Anhaltspunkte, dass diese Designziele größtenteils umgesetzt wurden.

Schließlich gab es auch schon 2005 einen Hinweis von Chuck Moore, einem weiteren wichtigen Mann hinter der Bulldozer-Architektur, welcher schon damals in einer Folie Argumente für ein Architekturkonzept lieferte - 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:


[BREAK=Patente]
0b52664e099645c896122d33ef5f3a9c

Patente​

Eine weitere Quelle für mögliche verwirklichte Ideen im Bulldozer waren die patentbasierten Spekulationen von Hans de Vries, welche er auf seiner Webseite veröffentlicht hat. Vor diesen Patenten, auf die sich Hans de Vries bezog, wurde von AMD noch während der Zeit, in der der K7 auf dem Markt war, ein Design in einigen Patenten beschrieben, welches als 6-issue ausgelegt war und vermutlich eine Weiterentwicklung des K7 darstellte. Offenbar wurde es auch nicht weiterverfolgt. Sich abzeichnende Markttrends und technische Schwierigkeiten könnten der Grund dafür gewesen sein.

Hans de Vries war aber auf der Suche nach Hinweisen auf die Architektur des kommenden K8. Anhand der in den Patenten verwendeten Beispielarchitekturen (die nicht zwangsweise hypothetisch sind), konnte Hans zwei wesentliche Architekturen identifizieren, die in Frage kamen. In einem Artikel beschrieb er dann eine Architektur, welche er für die kommende „Hammer“-Architektur hielt. Diese in den Patenten gezeigte Architektur kann auch der Hintergrund für das Inquirer-Gerücht über die sehr breite Architektur gewesen sein.

Wenn man sich diese Architektur aber genauer ansieht, kann man doch einige auffällige Ähnlichkeiten zum Bulldozer-Design feststellen, wie z.B. die Aufteilung in zwei Gruppen von Ausführungseinheiten. Vielleicht waren diese frühen Entwicklungen ein Grundstein für die Bulldozer-Entwicklung, welche parallel zu der stetigen Weiterentwicklung der Hammer-Architektur in einem mittlerweile doch sehr langen evolutionären Prozess stattgefunden haben könnte. Hier wäre es aber die Weiterentwicklung eines bereits neuen Designs.

In den Jahren, während der K8 schon auf dem Markt war, hat AMD viele Erfindungen zu Elementen von Prozessorarchitekturen patentiert. Die dabei immer wieder gezeigte Beispielarchitektur war die des K8. Erst gegen Ende des Jahres 2008 wurden Patentanträge veröffentlicht (eingereicht 2007), die eine neue "Beispielarchitektur" zeigten. Diese sah folgendermaßen aus:


Hier wurde ein Core dargestellt, welcher aus Architekturkomponenten aufgebaut war, wie wir sie von bisherigen Architekturen kennen. Auch die grobe Struktur vom Front End (Instruction Cache, Instruction Fetch, Branch Prediction, Decode, Dispatch) über die Ausführung (Scheduler, Register File Read, Execution) bis zum Back End (Write Back, Data Cache, I/O) liegt vor. Allerdings gibt es auch einen großen Unterschied: Die Ausführungseinheiten für Integer Code wurden verdoppelt (Integer Cluster 1 und 2) und die FPU wird gemeinsam von beiden Clustern verwendet. Laut dem Patent sollte auf jedem Cluster ein Thread ausgeführt werden. Damit wäre dieser Core in der Lage, zwei Threads mit Hilfe von teilweise der gleichen, teilweise aber separater Hardware, auszuführen.

Da dieses Design in weiteren Patenten auftauchte, schien es sehr wahrscheinlich das einer kommenden Prozessorarchitektur zu sein, wofür bei AMD nur die Bulldozer-Architektur in Frage kam. Später gab es in weiteren veröffentlichten Patenten etwas detailliertere Darstellungen. Zusammen mit den Informationen aus vielen anderen Patenten, deren Bezug oft durch die beteiligten Personen, den Zeitrahmen oder auch Architekturdetails und Wahrscheinlichkeitsbetrachtungen mit mehr oder weniger großer Sicherheit hergestellt werden kann, konnte schon ein etwas genaueres Bild der Architektur gezeichnet werden, wie hier berichtet.

Dank der Diskussionen in verschiedenen Foren und den Kommentaren auf meinem Blog, konnten Vermutungen und Ideen zu der Bulldozer-Architektur (und teilweise auch der Bobcat-Architektur) entwickelt, gefestigt oder verworfen werden. Auf diese möchte ich hier nicht im Detail eingehen, sondern werde sie bei der Beschreibung der Architektur gegebenenfalls erwähnen.

Wie sich schließlich im November 2009 auf AMD’s Financial Analyst Day (siehe nächste Seite) herausstellte, entsprach die in den Patenten gezeigte Architektur tatsächlich der neuen Bulldozer-Architektur und daher könnten sich darauf basierende Spekulationen mit größerer Wahrscheinlichkeit als zutreffend erweisen.

[BREAK=Offizielle Informationen]
0b52664e099645c896122d33ef5f3a9c

AMD Präsentation zur Leistungsentwicklung zukünftiger Prozessorgenerationen​

Schon in der ersten Hälfte des Jahres 2009 hat AMD eine Grafik veröffentlicht, welche die projizierte Leistungssteigerung von AMD-Prozessoren bis in die Zukunft darstellte (angegeben als Integer- und Floating-Point-Performance pro Watt, vermutlich bezogen auf SPECrate CPU2006):

Dabei wurden nicht nur die Leistungssprünge der Istanbul- und Magny-Cours-Prozessoren gezeigt, sondern auch schon der des Interlagos-Prozessors, welcher auf Bulldozer basieren wird. Allerdings waren die Enden der Balken beim Interlagos nach oben offen, da AMD dazu sehr wahrscheinlich noch keine gemessenen Daten besaß und natürlich auch nicht zuviel preisgeben wollte. Obwohl die Einheit der Darstellung die gemessene Performanz pro Watt ist, kann man die Werte gut auf die reine Prozessor-Rechenleistung übertragen, da der angegebene Energieverbrauch (ACP) der letzten Prozessorgenerationen relativ konstant geblieben ist und sich laut AMD auch beim Bulldozer nicht deutlich ändern sollte.

Manche Foren-Nutzer u.a. auf AMDZone begannen, die (manuell gesetzten) Balkenlängen zu vermessen und entsprechende Leistungssprünge abzuleiten. Auch ich versuchte damals zumindest, grobe Abschätzungen zu erhalten. Aber dank John Fruehe’s Aussagen (siehe Sammlung von Dr@ und aktuelle News) können die Leistungssteigerungen des Interlagos schon etwas genauer eingeschätzt werden und eine entsprechende absolute Leistung des Prozessors sowie der Module oder Kerne abgeleitet werden, wie später noch gezeigt werden wird.

AMD Financial Analyst Day 2009​


Am 11. November 2009 hielt AMD seinen Financial Analyst Day und nutzte diesen, um weitere Details ihrer Strategie und die groben Architekturen von Bulldozer und Bobcat vorzustellen. Dabei wurde auch erstmals von einem Bulldozer-Modul (statt -Kern) als Baustein für Prozessoren gesprochen. So ein dargestelltes Modul enthielt z.B. die gemeinsam benutzten Einheiten, wie Front End, FPU oder L2 Cache. Die bis dato aus den Patenten bekannten Integer-Cluster trugen hier den Namen „Integer Core“. Das Bulldozer-Modul ist demnach ein optimiertes Dual-Core-Design und bildet die kleinste Einheit für darauf basierende Prozessoren.


Nicht nur in den Präsentationen sondern auch in der Q&A-Session wurden weitere Informationen zum Bulldozer bekanntgegeben. Hier eine kleine Zusammenfassung (basierend auf den Folien, Notizen des Users abinstein auf AMDZone und eigenen Notizen):

  • 4 instructions per cycle
  • 4 integer pipelines are instruction pipelines
  • 4 inst dispatch
  • 4 inst issue per scheduler
  • about retiring: fetch 4, complete 1, balance of 3
  • schedulers actually work as decouplers, allowing instruction prefetching
  • optimized dual core

Dank dieser Informationen konnten bisherige Spekulationen verifiziert werden, und die Öffentlichkeit erhielt ein Schema der Bulldozer-Architektur, welches von da an zu deutlich mehr Diskussionen im Internet führte. AMD – immer auf der Hut vor der frühen Herausgabe zu vieler Intormationen, um Intel keinen Vorteil zu verschaffen – hat damit einen vagen Blick auf das erlaubt, was der Markt 2011 zu sehen bekommen soll. Und obwohl nun schon einige offizielle Informationen über die Architektur vorliegen, fehlen noch viele Details, die helfen könnten, ein wirklich genaues Bild der Bulldozer-Architektur zu erhalten – einer der Gründe für die vielen Diskussionen und neuen Spekulationen. Neben den bisher von AMD veröffentlichten Architekturinformationen und erwarteten Leistungswerten konnten durch Nachfragen von Journalisten noch weitere Details herausgefundenen werden. Folgende Informationen wurden von Johan de Gelas zusammengetragen:

• Two integer clusters share fetch and decode logic but have their own dedicated Instruction and Data cache
• Integer clusters can not be shared between threads: integer cores act like a Chip Multi Processing (CMP) CPU.
• The extra integer core (schedulers, D-cache and pipelines) adds only 5% die space
• L1-caches are similar to Barcelona/Shanghai (64 KB 2-way? Not confirmed)
• Up to 4 modules share a L3-cache and Northbridge
• Two times 4 Bulldozer modules (2 x 8 "cores" or 16 cores) are about 60 to 80% faster than the twelve core Opteron 6100 CPU in SPECInt_rate.
Hierzu wurde aber auch schon angemerkt, dass es widersprüchliche Aussagen zum Instruction Cache gibt. Viele gehen von einem gemeinsamen L1 I$ in einem Bulldozer-Modul aus. Im bisher gezeigten Architekturbild war er nicht einmal dargestellt:

Neben den offiziellen Informationen und Gerüchten gab es auch verschiedene Spekulationen, wie hier auch schon vor einem Jahr berichtet wurde.

[BREAK=Architekturüberblick]
0b52664e099645c896122d33ef5f3a9c

Überblick über die wahrscheinliche Bulldozer-Architektur​

Aber diese Eckdaten einer Architektur reichen bei weitem nicht, um sich ein genaueres Bild der Leistungsfähigkeit machen zu können. Deshalb folgt ein kurzer Ausflug in Techniken der Ausführung von Programmcode, welche für Bulldozer durchaus denkbar sind.

Verbesserungen der spekulativen Ausführung
Zur weiteren Steigerung der Rechenleistung eines Kerns gibt es mehrere Methoden, um der dem Programmcode inneliegenden Parallelität auf Befehlsebene (Instruction Level Parallelism oder ILP), Threadebene (Thread Level Parallelism oder TLP) und Speicherebene (Memory Level Parallelism oder MLP) noch mehr Leistung herauszuholen. Hierbei ist eine wesentliche Methode zur Steigerung der ILP die Out-of-Order-Execution, welche die Ausführung von Befehlen außerhalb ihrer Programmreihenfolge erlaubt, wenn die dafür notwendigen Eingabedaten bereitstehen. Auf die TLP zielen Verfahren wie SMT (Simultaneous Multithreading) und CMT (Clustered Multithreading) ab. Zur Steigerung der Leistung im Bereich MLP wird z.B. die parallele, teilweise umgeordnete Verarbeitung von Speicherzugriffen eingesetzt.

Die letzten Generationen von Kernen bis zur heutigen arbeiten bereits insofern spekulativ, dass die abgearbeiteten Befehle erst Gültigkeit erlangen („to retire“ im CPU-Jargon), wenn die bis dahin prädizierten Sprünge korrekt vorausgesagt wurden und keine Exceptions auftraten. Bis dahin gilt ihre Ausführung als spekulativ. Das sind die Out-of-Order-Architekturen. Bei Intel ist das seit dem Pentium Pro und bei AMD seit dem K5 der Fall. Hinzu kamen in der Zwischenzeit Verfeinerungen wie:

  • Store-to-Load-Forwarding: Weitergabe von Store-Daten an ausstehende Loads bevor sie in den Cache geschrieben wurden (z. B. im K7)
  • Out-of-Order Loads: Aufhebung der Load-Reihenfolge sofern keine Konflikte bestehen (z. B. im K10)
  • Memory Disambiguation: noch stärkere Auflockerung der Ordnung von Loads und Stores für eine effizientere Abarbeitung (z. B. im Conroe)
  • erste Formen der Datenspekulation: z.B. Annahme eines Treffers im Cache und darauf basierende Weiterverarbeitung der Befehle bis zum evtl. Eintreffen der Cache-Daten – und Wiederholung der Befehle („Replay“) im Falle einer Misspekulation (z. B. im Willamette)

Für die Bulldozer-Architektur könnte sich AMD weiterer Entwicklungen in diesen Bereichen bedienen. Eine dieser Entwicklungen ist sogar schon bekannt: das bereits erwähnte CMT. Zu den interessantesten weiteren Kandidaten gehören Datenspekulation, spekulative Ausführung und verschiedene Techniken zur Ausnutzung von MLP. Dafür gibt es verschiedene Hinweise, wie z. B. in Patenten, Publikationen oder Vorträgen, welche auf verschiedenen Veranstaltungen gehalten wurden. Folgende Erwähnungen sind u. a. interessant:
  • Verbesserte spekulative Ausführung
    • Replay-Fähigkeit und Checkpointing, d.h.:
    • Scheduler oder andere Einheiten, die eine Gruppe von Befehlen wiederholt bearbeiten können, je nach Status
    • Register Files oder Map Units, welche Zwischenstände speichern können (Checkpoints) – was ähnliche Fähigkeiten in anderen Einheiten nicht ausschließt – um so nach Misspekulation oder anderen Wiederholungsgründen Befehle schnell erneut auszuführen
    • Eager Execution, der 2. Core eines Bulldozer-Moduls wird dazu verwendet, z. B. den alternativen Pfad nach einem Sprungbefehl auszuführen und nach Bekanntwerden des richtigen Pfades den falschen zu verwerfen
  • Datenspekulation
    • Way Speculation, eine spekulative Annahme des zu verwendenden Weges (Way) im Cache und dadurch möglicher früherer Datenbereitstellung (niedrigere effektive Cachelatenz)
    • Load Speculation, wo anhand gleicher Adressierungsmuster der gleiche Variableninhalt angenommen wird
    • Value Prediction, wo versucht wird, anhand von Mustern die zukünftigen Werte von Registern oder gar Speichervariablen vorherzusagen
  • Höhere Speicherparallelität (Memory Level Parallelism)
    • Überlappung und Out-of-Order Handling von Speicherzugriffen
    • Hit-under-Miss-Processing bei Caches (während ein Cache Miss noch bearbeitet wird, werden schon weitere Anfragen abgearbeitet und nicht geblockt)
    • Verbessertes Prefetching, z.B. durch Run Ahead Execution (Scout Threads) von Speicheroperationen

Solcherlei Hinweise gibt es viele. Aber diese lassen sich nur selten mit hoher Wahrscheinlichkeit einer Microarchitektur, in unserem Fall der Bulldozer-Architektur, zuordnen. Deshalb soll es bei diesen Erwähnungen und der Annahme von deren Einsatz im Bulldozer bleiben. Sollten sich Hinweise verdichten, werde ich mein Blog (http://citavia.blog.de/) entsprechend aktualisieren. Die Wahrscheinlichkeit für den Einsatz vieler dieser Techniken ist allerdings hoch.

Auch die Auswirkung aller dieser Techniken lässt sich leicht benennen: Erhöhung der IPC. Diese ist allein schon dank der bekanntgegebenen Leistungsprojektionen und Annahmen über die Skalierbarkeit der Architektur sehr wahrscheinlich.

Auf das Potenzial einer dieser Techniken, der Runahead Execution als ein Beispiel spekulativer Ausführung, möchte ich im Folgenden genauer eingehen.

[BREAK=Runahead Execution (Vorauslaufende Ausführung)]
0b52664e099645c896122d33ef5f3a9c

Runahead Execution (Vorauslaufende Ausführung)​

Eine Ausführungsmethode, über welche in Bezug auf Bulldozer teilweise schon spekuliert wurde, ist die sogenannte “Runahead Execution”. Das bedeutet, dass der Prozessor den Code eines Threads spekulativ noch deutlich weiter ausführt, als es die Grenzen der bisher angewendeten Out-of-Order-Execution erlauben würden.

Eine Variante des Verfahrens nennt sich “Scout Threads” und wären beinahe mit dem “Rock” Prozessor von Sun (jetzt Teil von Oracle) auf den Markt gekommen. Dabei wird neben dem eigentlichen Thread automatisch noch ein weiterer Thread erzeugt, welcher z.B. nur die Speicheroperationen und Sprungbefehle des Ursprungsthreads enthält. Dieser weitere Thread besitzt einen spekulativen Charakter und die von ihm durchgeführten Operationen werden entsprechend behandelt. Vorrangiges Ziel dieses Verfahrens ist es, Daten in die Caches zu laden, welche möglicherweise bald gebraucht werden könnten. Die Ausführung dieser zusätzlichen Threads erfordert Synchronisation, Management und Ressourcen (Ausführungseinheiten, Register, Cache-Ports). Dennoch gibt es Hinweise, dass diese Technik dennoch erfolgreich sein kann, wie es von Sun bekanntgegeben und in einer Dissertation von Onur Mutlu erwähnt wurde:

An efficient runahead execution processor employing these techniques executes
only 6.2% more instructions than a conventional out-of-order execution processor
but achieves 22.1% higher Instructions Per Cycle (IPC) performance.
(aus Efficient Runahead Execution Processors)

In dieser Arbeit wird vielen Menschen für ihre Unterstützung gedankt. Darunter sind auch einige Computerarchitekten von AMD, wie z.B. Chuck Moore. Das lässt eine gewisse Relevanz der Arbeit bzw. des Themas für die Bulldozer-Entwicklung vermuten. Sie erwähnt auch einen höheren MLP (Memory Level Parallelism), was ebenfalls schon auf einer Bulldozer-Folie von der Hot Chips 21 erwähnt wurde.

Das Problem bei Sun's Rock muss nicht unbedingt der Einsatz der Scout Threads gewesen sein. Sein Design unterscheidet sich in vielen Punkten von vorherigen. Und es gibt auch viele Möglichkeiten, den Erfolg eines Designs zu verhindern, nicht nur technische.

[BREAK=Überblick über die spekulierte Bulldozer-Architektur]
0b52664e099645c896122d33ef5f3a9c

Überblick über die spekulierte Bulldozer-Architektur​

Nun soll auf die Architektur selbst eingegangen werden. Schritt für Schritt war es anhand der veröffentlichten Patente möglich, diese recht detailreich zu rekonstruieren. Aber auch hier gibt es noch keine endgültige Sicherheit, und deshalb ist alles mit einer gewissen Skepsis zu betrachten.

In folgendem Diagramm ist eine Architektur abgebildet, die zum Einen aus vielen bereits bekanntgegebenen, zum Anderen auch auf einigen aus Patenten oder anderen Quellen abgeleiteten Elementen besteht.


Da vermutlich auch interessierte englischsprachige Leser diesen Artikel (per automatischer Übersetzung) lesen werden und die englischen Begriffe auch im deutschen Sprachraum sehr verbreitet sind, habe ich die Komponenten in Englisch beschriftet.

Allgemeines zur Architektur
Bulldozer wird die erste Inkarnation der schon bekannten CMT-Architektur sein. CMT steht für Clustered/Cluster-based Multithreading, wie von Chuck Moore schon 2005 angesprochen. Dieses hat als Ziel, im Bereich der von beiden Threads gemeinsam benutzten Komponenten eine hohe Effizienz bzw. Auslastung zu erreichen. Beispielsweise wird im Fall eines Stalls (Stillstand) eines Threads (z.B. wegen fehlender Daten im Cache) zumindest für die gemeinsam genutzten Einheiten häufig möglich sein, solange die Befehle des anderen Threads zu verarbeiten. Das ist ein Vorteil, den auch die SMT-Technologie mit sich bringt. Aber im Unterschied zu SMT-Architekturen wurden in dieser CMT-Architektur viele der für die Ausführung wichtigen Einheiten und Speicher in Form des zweiten Integer Cores dupliziert, um Engpässe und Konkurrenzsituationen, wie sie bei SMT auftreten können, zu vermeiden.

Die wahrscheinlichen Wurzeln der Architektur
Möglicher geistiger Vater dieser Architektur ist Andy Glew, welcher bei Intel am Design des P6 mitgewirkt hat und später auch einige Jahre bei AMD arbeitete. Schon in den Neunziger Jahren entwickelte er an der University of Wisconsin-Madison die Multiclustered-Multithreading-Architektur (MCMT), welche der des Bulldozer-Moduls sehr ähnlich ist. Aber er beschrieb auch in einem Dokument aus der Zeit zwischen zwei Beschäftigungsphasen bei AMD und Intel (genauer: 2004) eine Architektur mit dem Namen „Multi-Star“ (oder „M*“). Diese weist ebenfalls viele Ähnlichkeiten zum Bulldozer-Design auf. Laut seinen Aussagen hat er dieses Design in mindestens einer Form auch bei AMD sehr genau beschrieben. Das öffentliche Dokument ist seine private, herstellerunabhängige Ideensammlung zu der Architektur. Wer also Interesse an weiteren Ideen und Varianten zu diesem Design hat, sollte zumindest einen Blick in Glew’s Multistar-Dokument werfen, welches neben anderen Dokumenten (u.a. mit Bezug zu MCMT) hier gefunden werden kann.

Auch sein Kommentar in der Usenet-Newsgroup comp.arch ist recht aufschlussreich. Dort kommentiert er das Design und die vielen Übereinstimmungen mit seinen Ideen. Im Vergleich mit der Bulldozer-Architektur lässt sich eine große Ähnlichkeit erkennen:


(siehe Blogeintrag zu Multi-Star)

Eine weitere Quelle zumindest für Teilkomponenten könnte ein früherer Entwurf einer Architektur von AMD sein, wie sie Hans de Vries anhand von Patenten rekonstruierte.

[BREAK=Details der Architektur]
0b52664e099645c896122d33ef5f3a9c

Details der Architektur​

Nun zurück zum Bulldozer. Der Aufbau lässt sich in das Front End für die Vorverarbeitung, das Back End (Ausführungsblöcke Integer Core 1 und 2 sowie Floating Point Unit) und Interface-Komponenten unterteilen. Auf die einzelnen Bestandteile gehe ich im Folgenden ein.


Front End
Das Front End ist der obere, in Dunkelblau gehaltene Teil der Architektur. Es besteht im Wesentlichen aus den Blöcken (oder Einheiten bzw. Units) L1 Instruction Cache (Befehlscache), Instruction Fetch (Laden der Befehle), Branch Prediction (Sprungvorhersage), Predecode/Pick (Vordekodierung und Auswahl), viermal Decode (Befehlsdekodierung) und Dispatch (Verteilung). Diese Komponenten werden durch beide Threads, welche von einem Bulldozer-Modul ausgeführt werden können, genutzt – ähnlich zu einem SMT-Design.

L1 Instruction Cache
Zu diesem sind derzeit mehrere Gerüchte unterwegs. Während in den Patenten mit dieser Architektur immer nur ein solcher Cache pro Modul (im Patent „Core“) erwähnt wird, gab es bei Anandtech das bereits erwähnte Gerücht, dieser wäre zweimal pro Modul, also je einmal pro Thread, vorhanden. Allerdings wurde schon von Seiten AMDs darauf hingewiesen, dass keine solche Information an Anandtech gegeben wurde, sondern nur, dass dem AMD-Vertreter nichts Genaueres bekannt war. Mittlerweile gibt es auch Hinweise, dass sich weder Größe noch Assoziativität ändern. Abhängig von den vorgesehenen (und noch nicht bekannten) Taktfrequenzen könnte sich allerdings die Latenz ändern. Angesichts der zwei Threads, welche ein Bulldozer-Modul verarbeiten kann, ist ein gemeinsamer Cache durchaus sinnvoll, da verschiedene Threads einer Applikation durchaus den gleichen Code ausführen könnten und sich nur in den bearbeiteten Daten unterscheiden.

Instruction Fetch
Angesichts des eben beschriebenen Caches ist es möglich, dass wie schon beim K10 auch hier 32 Bytes pro Takt übertragen und gepuffert werden (sogenannte Fetch Packets). Da diese Bandbreite beim K10 bereits eine Verdopplung gegenüber dem K8 darstellt, und die durchschnittliche Befehlslänge (auch bei SSE/AVX) noch nicht so nah an 8 Bytes liegt, sollten die 32 Bytes keinen Flaschenhals darstellen.

Die Verarbeitung der beiden möglichen Threads wird sehr wahrscheinlich alternierend stattfinden, könnte sich aber durch z. B. volle Warteschlangen oder Buffer bzw. ausstehende Befehlsdaten (von höheren Stufen der Speicherhierarchie) verzögern und solange nur den unbetroffenen Thread verarbeiten.

Branch Prediction
Die Sprungvorhersage könnte sich entsprechend einiger Patente gegenüber dem K10 deutlich verbessert haben (z. B. Vorhersage von mehr als einem Sprungziel pro Sprungbefehl und Takt) und beim Bulldozer auch in der Lage sein, entsprechende Prefetches zu initiieren, um die möglicherweise bald benötigten Code-Bytes schon in den L1 Instruction Cache zu laden und dort vorzuhalten.

Ähnlich zum Instruction Fetch könnten volle Warteschlangen oder Buffer dazu führen, dass die Branch Prediction Unit die Zeit nutzt, um entsprechend vorhergesagter Sprungziele schon Befehlscode zu prefetchen oder Sprünge des noch folgenden Codes bereits vorherzusagen.

Predecode/Pick
Hier werden die Positionen der Befehle in einem Fetch Packet identifiziert und deren Opcode (Befehlscode), enthaltene Konstanten oder Sprungadressen herausgelesen und an die entsprechenden weiteren Einheiten weitergeleitet. Eine dieser Zieleinheiten könnte eine Immediate/Displacement-Steering-Einheit sein, welche zahlenwerte (Immediates) und Adresskonstanten (Displacements), die in einem Befehlscode enthalten sein können, getrennt von den Befehlscodes selbst zu behandeln (siehe Pat. App. No. 20090019263).

[BREAK=Decode Units]
0b52664e099645c896122d33ef5f3a9c

Decode Units
Diese vier Blöcke könnten zu mehr in der Lage sein, als die 3+1 Decoder, welche vom K10 bekannt sind. Dessen Decode Units bestehen aus drei Decodern für schnell dekodierbare Befehle (Fast Path Decode, FP) und einem einzigen Decoder für langsam dekodierbare Befehle (Microcode Decode), welcher 3 MacroOps pro Takt ausgeben kann. Diese beiden Decodertypen können nicht gleichzeitig arbeiten. In verschiedenen Dokumenten wie Patenten und Source Codes wird auch der Begriff MicroOp oder Micro Operation für einen Befehlscode verwendet, welcher dem bisherigen Verständnis der MacroOps entspricht (u.a. Kombination aus FPU/ALU- und AGU-Operation). Zur besseren Lesbarkeit wird hier weiter der Begriff "MacroOp" verwendet mit dem Hinweis, dass dieser Begriff mittlerweile falsch sein kann bzw. einfach nicht mehr so verwendet wird.

Eine deutliche Anzahl an Patenten zeigte bereits die vier Decode Units des Bulldozers, bevor auf dem Financial Analyst Day von der Möglichkeit des Dekodierens von vier Befehlen pro Takt gesprochen wurde.

Neben der Erhöhung der Anzahl könnten entsprechend der Patente folgende Verbesserungen beim Decoding im Bulldozer kommen:

  • eine flexiblere Zuordnung von Befehlen zu den vier „Befehlsbahnen“, was einige Lücken im dekodierten Befehlsstrom sparen würde
  • besseres Dekodieren kompexer Befehle, die per Microcode übersetzt werden: Jeder einzelne der vier Blöcke besteht aus je einem Fast Path und einem Microcode Decoder und Microcode und Fast Path Decoding schließen sich möglicherweise nicht mehr aus
  • entsprechend einiger Patente könnten die verschiedenen Decode-Pfade für Microcode und schnell dekodierbare Befehle parallel genutzt werden, um einfach dekodierbare Befehle eines Threads parallel zu microdekodierbaren Befehlen des anderen Threads zu verarbeiten (würde allerdings die Verdoppelung der letzten Decoder-Stufe (Format Decode) bedeuten
  • X86-Befehle, die in zwei statt eine MacroOp umgewandelt werden müssen (sogenannte "Doubles"), wie vermutlich z.B. die 256-bit-AVX-Befehle (siehe unten), können jetzt parallel durch 2 Decoderblöcke in einem Takt dekodiert werden. Bisher oblag diese Aufgabe einem einzelnen Fast Path Decoder, der dafür zwei Takte beschäftigt war.

Zusammenfassend kann man sagen, dass Bulldozers Decoderblöcke auf verschiedenen Ebenen eine deutlich höhere Flexibilität als die bisherigen Decoder bieten.

Die Ausgaben der Decoderblöcke sind gruppierte Befehlscodes ähnlich den MacroOps, wo je Gruppe eine Micro-Operation (oder µOp) für eine Integer-ALU oder FP-Einheit und eine µOp für mögliche zugehörige Speicheroperationen (für die AGU) enthalten sind.

Diese Befehlscodes werden in einer weiteren Stufe (Format Decode) dann fertig bearbeitet und für das Dispatching vorbereitet. Dabei kann z. B. auch das Register Renaming erfolgen. Es würden dann die erzeugten MacroOps in Gruppen zu je vier zusammengefasst und als ein solches Paket pro Takt in den Dispatch-Buffer geschrieben. Obwohl der Prozess hier der Einfachheit halber mit den wahrscheinlicheren MacroOps (bestehend aus einer ALU/FPU-µOp und ggf. einer AGU-µOp) beschrieben wurde, ist es natürlich möglich, dass eine andere Gruppierungsform verwendet wird.

In mehreren Patenten steht auch etwas zu den Einschränkungen geschrieben, die ein solches Paket betreffen. So darf es höchstens einen Sprungbefehl, zwei Load/Store-Befehle und höchstens einen Integer-Multiplikations oder –Divisionsbefehl enthalten.

Ausgehend von der verfügbaren Zeit für die Anpassung des Designs an AVX (nach der Entwicklung von SSE5) sowie der bekannten Breite der FMAC-Einheiten von 128 bit, gehe ich davon aus, dass AVX/XOP-Befehle, die mit 256 bit breiten Daten arbeiten, nicht als ein MacroOp sondern als zwei MacroOps repräsentiert werden, ähnlich zur Verarbeitung von SSEn-Befehlen auf AMDs Architekturen vor dem K10. Nur 128 bit breite AVX/XOP-Befehle könnten dagegen meist auf nur ein MacroOp abgebildet werden. Komplexere Befehle, welche nicht direkt von den Recheneinheiten bearbeitet werden können, müssen natürlich in mehrere MacroOps dekodiert werden.

Nach derzeitigen Hinweisen werden die erzeugten MacroOps in Gruppen zu je vier zusammengefasst und als ein solches Paket pro Takt an die Dispatch-Einheit übergeben.

Ein kürzlich in einer GCC-Mailinglist erschienenes Posting beschrieb scheinbar schon genauer, wie sich solche Befehlsgruppen (dort „Instruction Windows“ genannt) zusammensetzen sollen. Zwar wurden einige Werte nur als Variablen genannt, können aber schonmal – auch dank Informationen aus dem Open64-Sourcecode und einem weiteren GCC-Mailinglist-Posting – mit recht wahrscheinlichen Größen besetzt werden. Demnach kann eine solche Dispatch Group pro Window (max. 16 Bytes und max. 4 x86-Befehle) bis zu 4 ALU-Ops, 3 AGU-Ops (2 Loads, 1 Store) und 4 FP-Ops enthalten. Die Befehlsgruppe endet mit dem Auftreten eines Sprungbefehls. Unklar ist noch, wie genau der erwähnte "Accelerate Mode" arbeitet und wie die bis zu 8 x86-Befehle pro Takt, die so gruppiert wurden, weiter verarbeitet werden. Zumindest passt diese Menge zum maximalen Durchsatz der Integer Cores alle 2 Takte, was die durchschnittliche Rate der Übergabe eines solchen Fensters an einen Integer Core wäre. Siehe dazu auch einen entsprechenden Blogeintrag.

Obwohl es sich hier noch um x86-Befehle handelt, ist es wahrscheinlich, dass diese Gruppierung bei den dekodierten Befehlen beibehalten wird und in starkem Bezug zu den vorhandenen Ausführungseinheiten steht.

[BREAK=Dispatch]
0b52664e099645c896122d33ef5f3a9c

Dispatch
Diese Einheit erhält die dekodierten Befehle in Form von Paketen (Dispatch Group) und puffert sie im Dispatch Buffer, um sie den entsprechenden Einheiten zu übergeben. Das wären laut AMD-Darstellung die beiden Integer Scheduler und sehr wahrscheinlich auch der Floating Point Scheduler. In Patenten zur Dispatch-Einheit wird der Floating Point Scheduler explizit als ein Empfänger genannt. Hierbei könnten neben einfachen Verteilungsmustern, wie das abwechselnde oder reihum erfolgende Verteilen, auch ressourcenabhängige Verfahren, wie z.B. die Verteilung abhängig vom jeweiligen Scheduler-Füllstand umgesetzt werden, um eine möglichst effiziente Funktion zu gewährleisten.

Da in einigen Patenten explizit zwei Empfänger genannt werden (welche sich aus Integer und Floating Point Scheduler zusammensetzen), obwohl wir nun drei Empfänger kennen, könnten noch andere Muster angewendet werden. Beispielsweise könnten je nach Füllstand der Scheduler pro Takt bis zu zwei Dispatch Groups an zwei der drei möglichen Empfänger übertragen werden. Werden Befehle an den FP-Scheduler übertragen, könnten zusätzlich entsprechende Tags an den dem Thread zugehörigen Integer Core übergeben werden, um den Status der Befehle im FP-Scheduler zu verfolgen.

Trace Cache bzw. Redirect Recovery Cache
Möglicherweise wird im Bulldozer schon ein Trace Cache implementiert. Dieser würde z.B. bei Schleifen die Decoder entlasten und könnte im Falle von falsch vorhergesagten Sprüngen schnell mit den (teil-)dekodierten Befehlen des richtigen Pfades dienen. Der Trace Cache wurde schon oft in vielen der etwas älteren AMD-Patente (meist von vor 2005) erwähnt. Da war er dem Retirement und einer "Fill Unit" nachgelagert und speicherte bereits einmal ausgeführte Befehle in Gruppen von 8 Operationen (könnte 2 Dispatch Groups entsprechen) ab, welche von der Fill Unit aufbereitet wurden.

Der Redirect Recovery Cache wurde dagegen erst in einem der neueren Patente beschrieben. Er soll nach dem Decoding plaziert sein und könnte laut Patent z.B. 64 bis 128 Einträge (Dispatch Groups) umfassen, also ca. 256 bis 512 Befehle falls obige Annahmen stimmen. In älteren Veröffentlichungen wurden ähnliche Caches erwähnt (z. B. ein „Misprediction Recovery Cache“ bei IBM), welche auch eine ähnliche Größe aufwiesen. Aus energetischer Sicht wäre so ein Cache auch sehr gut geeignet, um Code von Schleifen (Loops) zu speichern und die Scheduler dann unter Umgehung des Front Ends direkt zu befüllen.

Instruction Combining (Micro- oder MacroOp-Fusion)
Ein schon von Fred Weber vor vielen Jahren angesprochenes Thema ist das Instruction Combining (Befehlskombination bzw. –verknüpfung). Hierbei kann der Durchsatz an Befehlen erhöht werden, indem man für typische Kombinationen von Befehlen eine kompaktere interne Repräsentation verwendet. Das macht Intel z.B. bei der Macro-Op-Fusion, wo Vergleichs- und Sprungbefehle kombiniert werden. Wie erst kürzlich bekannt wurde, wird auch der Bulldozer-Kern diese Technik unterstützen. Aber es existieren noch deutlich mehr Möglichkeiten zur Kombination und teilweise auch zur Ersetzung bzw. Löschung von Befehlen. Beispiele können den Patenten 7694110 und 7003629 in den Abbildungen entnommen werden. Als eine aktuellere Anwendung wurde schon über die Fusion von Floating Point Multiplikationen und Additionen zu FMAC-Befehlen (D = A + B * C), wie sie von den FMAC-Einheiten verarbeitet werden können, spekuliert. Der Aufwand hierfür wäre aber deutlich höher als bei der erstgenannten Fusionsmöglichkeit. Ein Grund wäre, dass die zu fusionierenden Befehle mit Abhängigkeiten untereinander durch den Compiler eher weiter auseinandergesetzt worden sein könnten um eine effizientere Ausführung zu erreichen. Ein weiterer Grund wäre die Bedingung, dass das Zwischenergebnis (B * C) von kommenden Befehlen nicht verwendet wird, was Aufwand erfordert. Schließlich wird auch die wegfallende Rundung des Produkts im ursprünglichen Code bei der Ausführung als FMAC-Befehl nicht mehr durchgeführt, was das Ergebnis verändert.

Eine Befehlsfusion kann in der Pipeline sowohl vor als auch nach der (ersten) Ausführung angewendet werden. Die erste Variante würde entsprechende Logik im Decoder oder einer späteren Stufe (aber immer noch vor dem Integer Scheduler) erfordern, was aber auch zeitkritisch werden und damit eine energetisch aufwändigere Lösung erfordern kann. Die zweite Variante könnte mit höherer Latenz und damit weniger zeitkritisch auf Befehle angewendet werden, die nach der Ausführung in einen Trace Cache geschrieben werden sollen. Laut einer wissenschaftlichen Veröffentlichung zu dem Thema würde sich sogar eine Latenz von vielen Zyklen kaum auf den Performanzgewinn durch eine solche Optimierung auswirken.

Der Vorteil wäre hier, dass sich effektiv der Durchsatz von x86-Befehlen erhöht, da sie intern durch weniger Befehle (µOps bzw. MacroOps) repräsentiert würden. Dadurch können sich mehr der ursprünglichen x86-Befehle gleichzeitig in Bearbeitung befinden und in weniger Verarbeitungsschritten ausgeführt werden. Dadurch, dass ein Großteil des ausgeführten Codes mehrfach abgearbeitet wird (im Wesentlichen in Schleifen), ergäbe sich ein großer Nutzen eines solchen Verfahrens. Schließlich würde neben einer höheren Performanz auch Energie bei der Verarbeitung gespart.

[BREAK=Integer Cores]
0b52664e099645c896122d33ef5f3a9c

Integer Cores​

Die beiden Integer Cores enthalten alle wesentlichen Komponenten nach dem Front End, welche zur Ausführung eines Threads notwendig sind. Dazu könnten beim Bulldozer die folgenden gehören: Instruction Control Unit, Integer Scheduler, Integer Register File, die Ausführungseinheiten, Load/Store Unit und L1 Data Cache.



Instruction Control Unit
Bei Out-of-Order-Prozessoren ist es wichtig, Buch zu führen über die Ausführung der Befehle, um die korrekte Reihenfolge der Verarbeitung von Daten oder Ereignissen wie Interrupts oder Exceptions sicherzustellen. Das erfolgt z. B. mit Hilfe eines Reorder Buffers (ROB) oder einer Retirement Queue. Der ROB des K10 war in einer Instruction Control Unit (ICU) lokalisiert. Weiterhin könnten Operanden und spekulative Registerinhalte, Bearbeitungszustände und vieles mehr in so einer Einheit verwaltet werden. Da hier zum Bulldozer kaum etwas bekannt ist, habe ich eine ICU entsprechend eingefügt, um erst einmal das Verständnis zu erleichtern. Die reale Umsetzung kann natürlich davon abweichen, z. B. könnte die ICU in den beschriebenen Varianten gar nicht existieren oder (doppelt vorhandener) Bestandteil der Dispatch Unit sein.

Die ICU im Bulldozer würde nach diesem Modell je einmal pro Thread existieren und die Befehle des jeweils ausgeführten Threads verwalten. Da die FPU zwischen den Threads geteilt ist, kann man vermuten, dass die jeweiligen ICUs auch Zugriff auf den FPU-Scheduler haben (analog zum K10, wo die ICU Zugriff auf die Integer Reservation Stations und den FPU-Scheduler hat), um dortige Befehle des jeweiligen Threads zu verfolgen.

Vermutlich werden die Befehle in der gleichen Gruppierungsform verwaltet, in der sie von der Dispatch Unit übergeben wurden. Und in dieser Form könnten die Befehle auch „retired“ (beendet) werden, d. h. wenn die Bedingungen zum Retirement aller Befehle einer Gruppe dann erfüllt sind (z. B. kein spekulativer Zustand mehr, keine aufgetretenen Interrupts oder Exceptions), kann diese als korrekt ausgeführt und abgeschlossen betrachtet werden.

Weitere Aufgaben einer ICU wären die Auflösung von Register- und Flagabhängigkeiten und das Renaming bzw. Mapping, sofern letztere nicht schon im Decoder umgesetzt sind (Format Decode Units).

Integer Scheduler
Neben der allgemeinen Verwaltung der Befehle ist auch die Steuerung der Ausführung wichtig. Dafür ist der Scheduler in einem Integer Core (hier auch als „Integer Scheduler“ bezeichnet) zuständig. Dieser empfängt von der Dispatch Unit (oder über eine ICU-Zwischenstufe) Befehle, welche innerhalb des Integer Cores ausgeführt werden sollen. Die Aufgabe besteht einfach gesagt darin, die im Scheduler bereitstehenden Befehle unter Beachtung von Abhängigkeiten und Verfügbarkeit von Operanden auszuführen.

Gegenüber den drei Reservation Stations im Integer Scheduler des K10s kann sich beim Bulldozer Einiges verändert haben. Da auch hierfür nur wenige Hinweise aus Patenten existieren, sollen nur einige mögliche Neuerungen oder Verbesserungen angesprochen werden.

Unified Scheduler (Tag Based)
Bis zum K10 werden die Befehle in einer Gruppe von max. drei MacroOps entsprechend ihrer Position in dieser Gruppe fest der Reservation Station (RS) einer Integer-Pipeline zugeordnet (Tomasulo-Scheduling-Algorithmus). Dadurch kann es passieren, dass in einem Taktzyklus keiner der Befehle in einer RS wegen Abhängigkeiten (z.B. Warten auf Cache-Daten) ausgeführt werden kann, aber die in dieser Pipeline nicht genutzten Ausführungseinheiten (ALU oder AGU) nicht für Befehle aus den anderen RS verfügbar sind. Beispielsweise stehen in einer Reservation Station RS0 die Befehle ADD und MOV (beide im nächsten Zyklus ausführbar) und in RS1 stehen XOR und ADD (beide auf Daten/Ergebnisse wartend). Nun kann RS1 im nächsten Zyklus nichts ausführen, da kein Befehl „bereit“ ist. Aber auch kein Befehl von RS0 (obwohl „bereit“) kann ausgeführt werden.

Eine andere Beschränkung ist, dass einige Befehle einer bestimmten Pipeline (Pipe) zugeordnet werden müssen, wie z.B. die Integer Multiplikation zu Pipeline 0 oder Befehle der Advanced Bit Manipulation Extension (wie POPCNT oder LZCNT) zu Pipeline 2. Dafür können die Befehle aber nicht einfach umverteilt werden, sondern sie werden schon beim Decoding innerhalb einer Gruppe so verschoben, dass die Zuordnung eintritt. Beispielsweise sind als nächstes zu dekodieren (ohne Operanden): LEA, IMUL, MOV, IMUL, ADD, MOV, XOR. Davon muss IMUL der Pipe 0 zugeordnet werden. Da entsprechend geschoben werden muss, werden folgende Gruppen (man denke sich anstelle der x86-Opcodes die internen µOps) erzeugt:

Code:
 RS0  RS1  RS2
 LEA  nop  nop
IMUL  MOV  nop
IMUL  MOV  XOR
Die „nop“-Befehle stehen für leere Positionen und durchwandern die Pipeline ohne Effekt. Es ist erkennbar, dass sowohl Plätze in den RS, als auch Taktzyklen für die Ausführung ungenutzt bleiben. Am Ende hat die Retirement Unit beim K10 bei der LEA-Gruppe nur einen Durchsatz von einem x86-Befehl in einem Takt.

Ein Unified Scheduler wäre in der Lage, diese Ineffizienzen zu umgehen, indem er die auszuführenden Befehle flexibel auf die Ausführungseinheiten verteilen kann. Das erfordert aber eine höhere Komplexität und erhöht die Zeit, die der Scheduler braucht, was dazu führen könnte, dass das Scheduling in mehr als einem Takt erfolgt und damit die Kritische Schedule-Execution-Schleife verlängert.

Reservation Stations
Falls die Komplexität des Bulldozer-Schedulers aufgrund vieler Ausführungseinheiten doch noch höher ist, könnte hier weiterhin mit getrennten RS gearbeitet werden. Dann würde pro Instruction Pipeline eine RS die auszuführenden Befehle aufnehmen. Eine Verbesserung gegenüber dem K10 könnte z. B. so aussehen, dass die MacroOps flexibler den RS zugeteilt werden, um sie besser auszulasten und Lücken, wie sie oben beschrieben sind, zu vermeiden. Dann müsste die Programmreihenfolge der Befehle anders verfolgt werden als über eine feste Zuordnung zu „Lanes“ wie bei den letzten Microarchitekturen von AMD. Das Retirement wäre dann auch ein wenig komplexer.

Wie viele und welche Befehle pro Takt der Integer Scheduler nun von den Ausführungseinheiten bearbeiten lässt, wird im folgenden Abschnitt diskutiert.

Second Level Scheduler
Andy Glew beschrieb in seiner Multi-Star-Architektur den Ansatz von Schedulern auf zwei Ebenen, um effektiv ein größeres Fenster an Befehlen bearbeiten zu können. Das schliesst einen schnellen Scheduler wie oben beschrieben ein. Zusätzlich existiert ein weiterer Scheduler, welcher die Befehle in größeren Blöcken verwaltet (ein Kandidat wären die Dispatch Groups) und deren Ausführbarkeit verfolgt. Dieser Scheduler kann aufgrund seiner größeren Arbeitseinheit (bspw. eine Dispatch Group mit 8 Befehlen) mehr Befehle verwalten als einer der o.g. Scheduler, welche mit zunehmender Größe mehr Zeit brauchen, was die Taktfrequenz einschränken würde.

[BREAK=Integer-Ausführungseinheiten]
0b52664e099645c896122d33ef5f3a9c

Die Integer-Ausführungseinheiten
Zu diesem Aspekt der Architektur gibt es mehrere Interpretationsmöglichkeiten, im Wesentlichen verursacht durch eine in diesem Bereich „unscharfe“ Vorstellung der Architektur am Financial Analyst Day. Aus dieser ist derzeit nur bekannt geworden, dass jeder Integer Core vier „Instruction Pipelines“ haben wird. Eine weitere Aussage aus dem Q&A-Talk des Tages war, dass jeder der Scheduler (Integer oder FP) in der Lage ist, 4 Befehle (instructions) pro Takt an die Ausführungseinheiten zu geben. Aber auf welcher Basis diese gezählt werden (x86-äquivalente Befehle oder auch „micro instructions“ entsprechend mancher Patente), ist noch nicht klar. Deshalb sollen im Folgenden die zwei gängigsten Interpretationen beschrieben werden.

Variante mit vier ALUs und vier AGUs
Dafür hat aber Hans de Vries festgestellt, dass AMD’s Chekib Akrout auf dem angesprochenen Financial Analyst Day zum Bobcat-Kern sagte, dass dieser ein Issue-Rate von 2 Befehlen pro Takt hat. Wie auf dem veröffentlichten Bobcat-Architekturbild erkennbar ist, besitzt dieser zwei Integer-Pipelines und je eine Load- und eine Store-Pipeline. Deshalb kann angenommen werden, dass pro Integer Core des Bulldozer-Moduls bis zu vier dekodierte x86-Befehle verarbeitet werden könnten.

Das kann dann ähnlich zu einer Erweiterung der K10-Integer-Ausführungseinheiten um eine weitere Pipeline mit ALU+AGU sein. Aber geht man mit dem Gedanken im Hinterkopf an die Sache heran, dass fast nichts mehr so sein wird, wie es mal war (freie Interpretation von John Fruehe’s Aussage), dann ist es auch nicht so schwer, sich eine heterogene Gruppe von ALUs und AGUs oder gar hybriden Einheiten vorzustellen. Diese hybriden Einheiten werden durch einen Passus in Patenten wie App. No. 20090172370, Sektion [0022] gestützt:
In one embodiment, the ALU 220 and the AGU 222 are implemented as the same unit.
Weiterhin ist in einigen Patenten zu lesen, dass pro Dispatch Group maximal zwei Loads, ein Store und ein Branch erlaubt sind. Einen Bezug zum Durchsatz pro Takt kann man sich leicht vorstellen. Aber drei Speicheroperationen pro Takt (und in dieser Kombination sind sie auch sinnvoll) würden mindestens schon 3 AGUs erfordern.

Ein Hinweis für diese Konfiguration fand sich (wie schon erwähnt) im Sourcecode des Open64-Compilers, an dessen Entwicklung sich AMD aktiv beteiligt und auch schon nachvollziehbare Änderungen für Orochi (Codename für das Bulldozer-Die, worauf wohl Zambezi, Interlagos und Valencia basieren werden) einbrachte. Dort sind in einem Dokument die Anzahl der in einem Zyklus verfügbaren Einheiten genannt:
4 AGUs
3 ALUs
4 FP-Befehle
Weiterhin werden die 2 Loads und 1 Store pro Takt explizit genannt.

Somit könnten bis zu drei Speicheroperationen pro Takt ausgeführt werden. Für ein einfacheres Scheduling sind vermutlich 4 AGUs vorhanden, welche ähnlich zum K10 mit den ALUs in Paaren (als „Integer Pipelines“) zusammengefasst sind.

Variante mit zwei ALUs und zwei AGUs
Viele Patente von 2007, welche bereits die Bulldozer-Architektur zeigten, sowie etwas früher eingereichte Patente (um 2005) erwähnen entweder zwei ALUs und zwei AGUs für die Bulldozer-Beispielarchitektur oder beschäftigen sich eingehend mit einer solchen Konfiguration von Ausführungseinheiten. Als Gründe für eine solche Konfiguration werden die höhere Effizienz des Designs durch verringerte Komplexität und oft auch ein daraus resultierender hoher Zieltakt genannt. Patente wie Pat. App. No. 20070011432 (Recycling ALU) und Pat. No. 7315935 (Apparatus and method for port arbitration in a register file on the basis of functional unit issue slots) deuten in eine solche Richtung.

Viele bisher veröffentlichte Artikel zur Bulldozer-Architektur (z.B. von Hiroshige Goto) gehen von dieser Konfiguration aus. Und ein weiterer japanischer Autor (siehe Bericht auf Citavia) schrieb sogar, dass (sofern die automatische Übersetzung so interpretierbar ist) sogar AMD Japan über AMD US diese Konfiguration bestätigt habe. Aber das sind wiederum Interpretationen, die teilweise auf den gleichen Patenten basieren, welche in meinem Blog angesprochen wurden. Die zeitliche Reihenfolge lässt sogar vermuten, dass Hiroshige Goto diesen Hinweis im Blog oder davon abgeleiteten Diskussionen fand.

Andy Glew’s Multi-Star-Architektur, die mit dem Bulldozer-Design durchaus verwandt sein kann, verwendet ebenfalls zwei ALUs und zwei AGUs pro Execution Cluster.

Komplexere Einheiten wie Integer Multiplier oder Integer Division sind hier nicht genauer betrachtet. Man kann annehmen, dass sie wie bisher einer Integer Pipeline fest zugeordnet sind.

Schließlich gibt es auch weitere Argumente und Entdeckungen, um diese Sicht zu stützen. Aber es handelt sich eher noch um die Theorie, dass Bulldozer ein Hochfrequenzdesign werden könnte. Das ist Thema eines späteren Abschnitts.

Eine revolutionäre Idee im x86-Markt wäre die von kombinierbaren ALUs. Im US Patent 6944744 wurde eine solche Idee bereits beschrieben und verleitete auch zu einer entsprechenden Spekulation bzgl. der Ausführung von 256-bit AVX/XOP-Integer-Befehlen auf den Integer-ALUs. So ähnlich könnten auch schmalere ALUs (z.B. 32-bit breit) für viele 64-bit-Operationen kombiniert werden. Dadurch könnten ansonsten ungenutzte Teile von 64 bit breiten ALUs bei 32-bit-Code für einen weiteren 32-bit-Befehl genutzt werden. So eine Technik erhöht zwar die Komplexität der Schaltungen und Datenpfade, könnte aber auch energieeffizienter sein, da Leckströme mit neueren Herstellungsprozessen für Hochleistungsschaltungen oft einen immer größeren Anteil am Gesamtverbrauch einnehmen. Diese könnten durch "Recycling" von Transistoren für andere Funktionen sinnvoll eingesetzt werden. Ein ähnliches Konzept verfolgt schon die "recycling AGU".

[BREAK=Load/Store Unit und L1 Data Cache]
0b52664e099645c896122d33ef5f3a9c

Load/Store Unit und L1 Data Cache
Die Load/Store-Unit wird ebenfalls deutlichen Änderungen unterzogen worden sein.

Vom L1 Data Cache (kurz: L1D$, wo „$“ als Synonym für „Cash“ von Rechnerarchitekten gern verwendet wird) sind schon mehr Daten bekannt geworden, wie z.B. die Größe und Assoziativität (siehe Blog). Demnach soll Bulldozer pro Integer Core einen 16 kB großen L1D$ mit 4-Wege Assoziativität haben. Dieser hätte etwa die Trefferquote (Hit Rate) eines halbierten und somit 32 kB großen L1D$ (2-way) des K10.

Sowohl einige Patente als auch von Chuck Moore dargestellte Designgrundsätze (z.B. in dieser Präsentation (PDF) dargestellt), welche im Wesentlichen auf Erfahrungen der Entwicklung der Power-4-Prozessoren basieren, nennen mehr oder weniger deutlich zwei Lese- und einen Schreibport für den L1D$ als Optimum. Dahinter steckt die Annahme, dass bei der Datenverarbeitung zwei Werte gelesen werden, darauf eine Berechnung durchgeführt wird und ein Ergebniswert geschrieben wird. Entsprechend der ursprünglichen Entwicklungsausrichtung auf SSE5 kann man von 128-bit breiten Pfaden ausgehen. Das entspräche einer Bandbreite pro Takt von 32 Byte beim Lesen und 16 Byte beim Schreiben. Kürzlich entdeckte Änderungen im Open64-Compiler-Sourcecode bestätigen diese Vermutung.

Pat. App. 20090138662 von Gary Lauterbach beschreibt eine Möglichkeit, wie Cachezugriffe, welche auf einen vorangegangenen L1 Cache Miss (Daten sind also nicht im L1D$) folgen, dennoch ausgeführt werden können, ohne dass auf die Daten für den ersten Cachezugriff (der zum Miss führte) warten zu müssen.

Dann wird es recht schnell unübersichtlich mit den Möglichkeiten, über die Cache-Architektur zu spekulieren. Dazu mehr im Abschnitt zum L2 Cache.

Retirement Unit
Zu dieser Einheit ist für Bulldozer nichts Spezifisches bekannt. Es kann angenommen werden, dass sie die typischen Aufgaben einer Retirement Unit ausführt. Demnach würden nach Prüfung des Ausführungsstatus der abgearbeiteten Befehle und Speicherzugriffe sowie Behandlung von aufgetretenen Exceptions und Interrupts die Befehle gruppenweise (vermutlich in Form der Dispatch Groups) als abgearbeitet markiert.

Resource Monitors
Für das verbesserte Energiemanagement könnten laut Patenten weitere Techniken als die schon für Llano angekündigten genauen Messmethoden für Temperaturen und Stromverbräuche innerhalb des Chips eingesetzt werden. In einem separaten Kapitel wird noch genauer darauf eingegangen. Hier sei nur genannt, dass dafür eine genaue Beobachtung der Auslastung der verschiedenen Einheiten notwendig wäre. Dafür kämen die Resource Monitors zum Einsatz, welche exemplarisch im Architekturdiagramm als Blöcke mit der Beschriftung „RM“ dargestellt sind. Deren Aufgabe ist die Beobachtung z.B. von Füllständen von Buffern oder Durchsatzraten.

[BREAK=Hochfrequenzdesign]
0b52664e099645c896122d33ef5f3a9c

Hochfrequenzdesign
Eine Erklärungsmöglichkeit für eine favorisierte schlanke ALU/AGU-Konfiguration (2 ALUs, 2 AGUs) wäre die, dass es sich beim Bulldozer zumindestens teilweise um ein Hochfrequenzdesign handeln könnte. Es gibt dafür Hinweise aus verschiedenen Richtungen.

Bevor hier weiter darauf eingegangen wird, soll kurz gezeigt werden, was bei der Netburst-Architektur bezüglich des hohen Taktes so problematisch war. Dazu erinnern wir uns, dass die maximale auf dem Markt erhältliche Taktfrequenz des Prozessors 3.73 GHz betrug (hergestellt im 65nm-Prozess). Dabei waren Teile des Prozessors (die schnellen ALUs) sogar noch mit dem doppelten Takt betrieben (also bereits mit über 7 GHz!). Für dieses Design wurde eine Zykluszeit von 8 FO4 angegeben und wäre für die schnellen ALUs sogar nur 4. Dabei steht „FO4“ für eine verbreitete Maßeinheit beim Schaltungsdesign und entspricht der Latenzzeit einer bestimmten Standardschaltung. Je kleiner dieser Wert, desto schneller arbeitet die Schaltung. Es gab bisher Veröffentlichungen, die für typische OOO-Designs eine optimale Zykluszeit von 8 FO4 angaben. Andere Veröffentlichungen favorisierten für Designs unter gewissen Voraussetzungen längere Pipelines von 20 und mehr Stufen.

Diese Werte befürworten natürlich ein Hochfrequenzdesign mit langer Pipeline. In dieser Zeit wurde auch der Begriff „Superpipelining“ populär. Aber für Teile des Designs wurde es notwendig, auf eine schnellere Logik zurückzugreifen, um die gewünschten Arbeitsschritte der Pipeline auch in der geforderten Zeit zu erledigen. Das galt v.a. für die schnellen ALUs. Die verwendete Logik war in den früheren Netburst-Designs noch Domino-Logik und wurde später auf Dual-Voltage-Swing-Logik umgestellt. Beide Typen bewirken durch zusätzlichen Schaltungsaufwand zur Erreichung der Geschwindigkeit auch einen erhöhten Energieverbrauch. Ein weiterer Faktor ist natürlich das Taktsignal selbst, welches sauber bereitgestellt werden muss. Das erfordert bei höheren Taktfrequenzen einfach mehr Aufwand. In der heutigen Zeit könnte dagegen ein Pentium 4 mit diesem Takt dank aktuellem Herstellungsprozess (dadurch werden die FO4-Zeiten immer kleiner), aggresivem Clock- oder Power-Gating, Clock Generatoren und Taktdomänen recht sparsam designt werden.

Das Thema Hochfrequenzdesign wurde mit einer gefundenen wissenschaftlichen Veröffentlichung von AMD aktuell, welche energieeffiziente, aber schnelle 64-Bit-Addierer-Schaltungen untersuchte. Die angepeilte Latenzzeit von knapp 10 FO4 des Addierers scheint selbst für eine angepeilte Verwendung innerhalb einer 64-Bit-Standard-ALU doch etwas niedrig zu sein. Wird nun eine Pipeline für eine bestimmte FO4-Zahl entwickelt, drückt man damit indirekt die Taktbarkeit des Designs aus. Nun muss man hier noch bedenken, dass zu der Latenz für den Adder selbst auch noch Latenzen für weitere Komponenten, die innerhalb der Pipelinestufe notwendig sind, hinzukommen. Schließlich sollte auch noch etwas Spielraum für kleine Ungenauigkeiten beim Taktsignal oder die realen Latenzen der Schaltung in der Produktion vorgesehen werden. Grob geschätzt spräche der genannte Wert für eine Pipeline mit 12-15 FO4. Für die Pipeline des K10 wurde in einem Artikel eine Zahl von ~23 FO4 genannt. Andere bekannte Designs haben z.B. 21 FO4 (Core 2), 13 FO4 (IBM Power 6), 16 FO4 (Intel Pentium 4, schnelle ALUs: 8 FO4). (http://www.realworldtech.com/page.cfm?ArticleID=RWT081502231107).
Der von der Playstation 3 bekannte Cell-Prozessor wurde teilweise als 22 und als 11 FO4-Pipeline-Design entwickelt. Dabei besitzt der Prozessor Abschnitte mit dem hohen Takt (11 FO4) und andere mit dem halben Takt (22 FO4). (http://www.realworldtech.com/page.cfm?ArticleID=RWT072405191325&p=6)

Neben solchen Veröffentlichungen gibt es auch noch Aussagen von Chuck Moore (dem auch der Hinweis auf das cluster-based Multithreading von 2005 zu verdanken ist), welche in verschiedenen Präsentationen zu finden sind. Dazu gehört die schon erwähnte Präsentation mit Erfahrungen aus der Entwicklung des Power 4 von IBM. Eine wesentliche Aussage darin ist, dass der größte Durchsatz mit Pipelines von 5 FO4 (Floating Point) bzw. 8 FO4 (Integer) erzielbar ist. Hier nur kurz die Anmerkung: Bulldozer wurde schon lange als „Throughput Architecture“ angepriesen.

Es ist also durchaus möglich, dass ein Bulldozer-Modul oder zumindest Teile davon mit einer vergleichsweise hohen Taktfrequenz betrieben werden.
[BREAK=Floating Point Unit]
0b52664e099645c896122d33ef5f3a9c

Floating Point Unit​

Die FPU wird ebenfalls ein gänzlich neues Design aufweisen. Was anhand von Patenten und offiziellen Informationen erfahren werden konnte, ist im Folgenden dargestellt, kombiniert mit Spekulationen über den genaueren Aufbau. Leider reicht auch dies nicht für eine vollständig exakte Darstellung. Es fehlen z.B. Hinweise auf die Verarbeitung von Integer-SIMD-Befehlen oder z.B. die Division.



Floating Point Scheduler

Floating Point Scheduler
Für die Floating-Point-Befehle, welche in der gemeinsam genutzten Floating Point Unit (FPU) ausgeführt werden, existiert ein eigener Scheduler, welcher die Ausführung koordiniert. Schon bei früheren Designs (K7, K8, K10) existierte ein solcher Scheduler. Dieser nahm die Befehlscodes für Floating-Point-Befehle auf, um sie entsprechend der Verfügbarkeit der Eingabedaten und Ausführungseinheiten an diese zu übergeben.

Vom Analyst Day ist von Chuck Moore aus der Fragenrunde bekannt, dass die FPU ein 4-Issue-Design ist, wonach also pro Takt bis zu vier Befehle ausgeführt werden können. Da die FPU von beiden Integer Cores gemeinsam genutzt wird, enthält der Scheduler auch die Befehle der maximal zwei ausgeführten Threads. Aus diesen werden pro Takt die ausführbaren Befehle ähnlich wie beim Integer Scheduler ausgewählt. Die Floating-Point-Register der beiden Threads könnten in einem gemeinsamen Registerfile liegen, während threadspezifische Informationen wie das Mapping vermutlich in getrennten Speichern gehalten werden. Insgesamt ist die Ausführung von Floating Point Code mit SMT in anderen Prozessorarchitekturen (z.B. Nehalem) vergleichbar. Während AMD für Integer Code Probleme bei der Doppelbelastung der Einheiten und Caches sah, bietet eine FPU viel mehr Potenzial für die Ausführung eines zweiten Threads, da allein schon durch die Latenzen von mehreren Takten der FP-Befehle diese oft genug auf Ergebnisse der vorhergehenden Befehle warten müssen. Dadurch gibt es viele Taktzyklen, wo in einer oder mehreren der FP-Einheiten kein Befehl ausgeführt wird. Dank eines zweiten Threads mit explizit unabhängigen Befehlen können diese Lücken effizient genutzt werden. Durch eine Erhöhung der vorhandenen Ressourcen beim Bulldozer gegenüber dem K10 wurden nicht nur mögliche leichte Einschränkungen durch die Parallelausführung reduziert, sondern noch Spielraum nach oben geschaffen.

Die Steuerung der Ausführung und Koordination mit der Ausführung des Codes auf den Integer Cores erfolgt wahrscheinlich über Tags und Signale zwischen den Integer Schedulern bzw. der angenommenen ICU.

FMAC-Einheiten
Die FPU enthält laut den offiziellen Informatoinen zwei 128-bit-FMAC-Einheiten. FMAC-Befehle (Fused-Multiply-Accumulate) ermöglichen die Berechnung von Gleichungen der Grundform D=A+B*C mit einem einzigen Befehl. Da viele Berechnungen auf dieses Muster abgebildet werden können, wurden solche Befehle schon früh in nicht x86-kompatiblen Prozessorarchitekturen für die Erhöhung des Durchsatzes eingeführt. Diesen hohen Durchsatz erreicht man aber auch nur mit den FMAC-Befehlen.

Die oft genutzten Standardoperationen FADD (Floating Point Addition) und FMUL (Floating Point Multiplikatoin) wurden in einer FMAC-Einheit als D=A+B*1 bzw. D=0+B*C ausgeführt. Das bedeutete auch, dass diese Befehle nicht mehr ganz so schnell und energieeffizient ausgeführt wurden wie in dedizierten FADD- bzw. FMUL-Einheiten. Solche wären aber besser für die gesamte vorhandene x86-Codebasis ohne FMA-Befehle geeignet. Eine Möglichkeit, diese verschiedenen Implementationen miteinander zu verheiraten, entwickelte ein Doktorand an der University of Texas in Austin mit Unterstützung durch AMD. Sein Ergebnis ist eine Bridged-Fused-Multiply-Add-Unit, welche bisherige FMUL- und FADD-Einheiten miteinander über ein einigermaßen komplexes Brückenelement verbindet, um sowohl einzelne FMA-Operationen oder FADD- und FMUL-Operationen (sogar gleichzeitig) durchzuführen. Der grobe Aufbau der Einheit ist in folgender Abbildung dargestellt:


Diese Einheit böte eine bessere Energieeffizienz bei den häufigen FADD- und FMUL-Befehlen und gleichzeitig die gewünschte FMA-Funktionalität. Damit ließe sich auch die 4-Issue-Fähigkeit der FPU erklären, indem dann je ein FADD- und ein FMUL-Befehl pro FMAC-Einheit gezählt werden. Ob so eine Einheit wirklich im Bulldozer eingesetzt wird, ist noch fraglich.

Eine alternative Erklärung ist ein flexibles Ausführen von Befehlen, die entweder nur skalare Zahlenwerte (z.B. ein 32-bit-Floating-Point-Wert) oder Zahlenvektoren (z.B. 128-bit SSE-Register mit zwei 64-bit-Floating-Point-Werten) bearbeiten. Laut einem schon älteren US-Patent mit der Nummer 6944744 könnte es auf Bulldozer angewendet pro 128-bit-FMAC-Einheit zwei 80-bit (wegen x87-Kompatibilität) breite Untereinheiten geben, die unabhängig voneinander Befehle ausführen können. Das würde eine hohe Flexibilität bei der Ausführung erlauben, da somit Floating-Point-Code relativ unabhängig von seiner Zusammensetzung (mehr FADD, mehr FMUL oder mehr FMAC-Befehle – natürlich neben weiteren von anderem Typ) mit maximalem Durchsatz bearbeitet werden könnte. Einen solchen Aufbau suggerieren auch zwei neuere Patente zu FMAC-Einheiten. Auf weitere Details zu dem Thema geht ein Citavia-Blogeintrag ein.

Ähnlich, wie es Spekulationen zu einer möglichen „double pumped“ FPU im Sandy Bridge Prozessor gibt, kann man auf Grund der Argumente pro niedrigeren Energieverbrauch (hier speziell Leckströme) beim Bulldozer ein entsprechendes Design vermuten. „Double pumped“ bedeutet, dass die FPU-Pipelines deutlich verlängert wurden, um sie mit einer höheren – vorzugsweise doppelten – Taktfrequenz im Vergleich zum Rest der CPU zu betreiben. Das würde erlauben, 256-bit-Operationen schnell als zwei 128-bit-Operationen hintereinander (back to back) auszuführen. Sofern es sich nicht um horizontale oder andere hälftenübergreifende Operationen handelt, ist das auch kein Problem. So wurde u.a. SSEn-Code auf dem K8 ausgeführt – allerdings mit einer normal getakteten FPU. Für weitere Hintergründe und Spekulationen verweise ich auch hier auf folgende Links:
http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538-150.html
http://aceshardware.freeforums.org/the-first-sandy-bridge-tape-out-revealed-t860-60.html

Speicheroperationen der FP-Befehle werden in den entsprechenden Integer Cores ausgeführt. Dazu werden die jeweiligen AGUs und LSUs genutzt. Vermutlich kann die FPU pro Thread bis auf die volle Load/Store-Bandbreite des jeweiligen Integer Cores zurückgreifen (natürlich in Konkurrenz zu Speicheroperationen im Integer Code). Das hieße entsprechend der bei der LSU genannten Daten, dass die FPU kombiniert bis zu vier Loads (je 128 bit) und zwei Stores (je 128 bit) für den Datentransfer nutzen könnte. Aber hier könnte auch eine Limitierung existieren, da nach derzeitigem Stand die zwei 128-bit FMACs zusammen pro Takt nur zwei Loads ausnutzen könnten. Falls aber doch die getrennte parallele Ausführung von FADDs und FMULs in den FMAC-Einheiten möglich ist, dann könnten die vier Loads pro Takt öfters ausgereizt werden.

Falls in der ersten Version der Bulldozer-Architektur die Bridged-FMA-Unit zum Einsatz kommt, könnte später dennoch auf normale FMA-Einheiten umgestiegen werden, da zukünftig der neuere Code vermehrt schon FMA-Befehle nutzen wird. Das ermöglicht wiederum einen reduzierten Energieverbrauch bei FMAC-Operationen (aber erhöhten bei FADD und FMUL) und auch kleinere FMAC-Einheiten. Natürlich könnte man sich aus diesen Gründen auch schon im ersten Bulldozer entsprechend entschieden haben. Die Auswahlmöglichkeiten standen auf jeden Fall zur Verfügung.

Das Retirement der FP-Operationen erfolgt schließlich ebenfalls über die Integer Cores.

[BREAK=Level 2 Cache, Core Interface Unit, Uncore, Befehlssatzerweiterungen]
0b52664e099645c896122d33ef5f3a9c

Level 2 Cache
Vom Analyst Day ist bekannt, dass ein Bulldozer Modul einen Level 2 Cache (L2$) besitzt, welcher von beiden Integer Cores gemeinsam genutzt wird. Das bietet im Wesentlichen einige Vorteile. Zum Beispiel kann der Cache entsprechend der Nutzungscharakteristik der Cores unterschiedlich stark durch die ausgeführten Programmthreads belegt werden. Ein weiterer Vorteil ist der, dass bei Bearbeitung gemeinsamer Daten durch die zwei auf den Cores ausführbaren Threads diese Daten nur einmal geladen und abgelegt werden müssen. Ein gemeinsamer Cache erspart auch etwas Aufwand beim Sicherstellen der Datenkohärenz.

Aus der gleichen Quelle wie beim L1D$ war zu entnehmen, dass der L2$ des Bulldozer eine Größe von 2 MB und eine 16-fache Assoziativität besitzen könnte. Aus einer weiteren, inoffiziellen Quelle war noch zu erfahren, dass auch mit 1 MB großen L2 Caches gerechnet werden kann.

Betrachtet man die Cachegrößenverhältnisse zwischen den L1 und L2 Caches beim K10 und beim Bulldozer, sollte auch das exklusive Cachedesign hinterfragt werden. Wo bei früheren Prozessorgenerationen mit zusammen 128 kB großen L1 Caches pro Kern das exklusive Cachedesign u.a. dazu diente, die wirksame Cachegröße merklich zu erhöhen, würde das beim anzunehmenden Größenunterschied der Bulldozer-Caches kaum einen Effekt haben. Hier ist ein inklusives Cachedesign recht wahrscheinlich. Ebenso werden Schreibzugriffe als Write-Through durchgeführt, d.h. Daten werden gleichzeitig in den L1D$ sowie den L2$ geschrieben. Ein deutlicher Hinweis darauf ist in Pat. App. No. 20090138659 von Gary Lauterbach, einem der Bulldozer-Designer, zu finden. Darin werden Store Queues, Cachezugriffe und ein Write Coalescing Cache zwischen den LSUs der beiden Cores beschrieben.

Core Interface Unit
Um den Datenaustausch zwischen den Cores (vermutlich auch untereinander) und dem Uncore-Bereich sicherzustellen existiert eine Core Interface Unit, die auch für Datenkohärenz, Priorisierung und Zugriffe auf den gemeinsamen Level 2 Cache zuständig ist.

Der Uncore-Bereich​

Unter dem Uncore-Begriff wird alles zusammengefasst, was nicht direkt den Prozessorcores zuzuordnen ist. Dazu zählen beim Bulldozer der L3-Cache, die Interconnection-Logik zwischen den Cores, der integrierte Memory Controller und I/O-Interfaces wie Hypertransport oder PCIe.

Level 3-Cache
Zum Level 3 Cache (L3$) ist im Wesentlichen bekannt, dass er gemeinsam von allen Modulen eines Dies genutzt wird. Größenangaben fanden sich schon auf einigen Folien, wie z.B. zum Zambezi, der Desktop-Variante. Die Gesamtgröße des Caches im Vergleich zu den L2$ der Module lässt ein ähnliches Cache-Prinzip wie beim K10 vermuten. Demnach könnten Daten exklusiv im L3 oder L2 gehalten werden, wenn sie nur von einem Modul benötigt wurden oder werden bzw. sie könnten inklusiv behandelt werden, wenn mehr als ein Modul die Daten nutzt. Dann können diese gleichzeitig in mehreren L2$ und im L3$ liegen.

Der schon bekannte Probe Filter ("HT-Assist"), welcher mit Hilfe eines im L3$ abgelegten Verzeichnisses (Directory) unnötige Snoop-Zugriffe auf andere Prozessoren verhindert und gezielte Zugriffe ermöglicht, wird weiterhin vorhanden sein und sich entsprechend der darunterliegenden Cache-Levels (1 und 2) möglicherweise in der Größe ändern.

Integrated Memory Controller
Patente und andere Quellen deuten dahin, dass der Integrated Memory Controller (IMC) deutlich flexibler als bei den Vorgängerprozessoren sein wird. Leider liegen hier noch keine genaueren Informationen vor. Natürlich sind Verbesserungen beim Prefetching sowie ein effizienteres Energiemanagement denkbar. Die Patente suggerieren weiterhin, dass es Optimierungen bei den Zugriffen geben könnte mit Priorisierung der Zugriffe, Gruppierung entsprechend offener Speicherseiten und größeren Buffern. Und natürlich wird der neue IMC auf kommende Speicherstandards eingestellt sein. Also auch hier besteht Potenzial zu einer messbaren Leistungssteigerung gegenüber dem bisherigen IMC.

HyperTransport-Links und PCIe-Lanes
Je nach Prozessormodell wird es eine verschiedene Anzahl dieser Interfaces geben. Die HyperTransport-Links sind bereits bekannt und werden weiterhin die Basis der Direct Connect Architecture 2.0 bilden. Da sowohl Server- als auch Desktop-Prozessoren mit Bulldozer-Kernen zu bestehenden Sockeln (G34, C32 und AM3) kompatibel sein werden, steht ihnen entsprechend auch die gleiche Infrastruktur zur Verfügung. Verbesserungsmöglichkeiten bestehen aber auch hier durch Erhöhung von Taktfrequenzen und Optimierung von Zugriffen wie schon beim IMC erwähnt. Zur Reduktion des Energieverbrauchs könnten die HT-Links dynamisch in der Breite reduziert werden (z.B. von 16 auf 8 bit).

Neu dagegen werden die PCIe-Lanes sein, die z.B. von Fusion-Prozessoren bereitgestellt werden könnten. Da die Bulldozer-Kerne noch nicht zu Beginn in einem Fusion-Design verwendet werden sollen, wird das Thema da etwas später eine Rolle spielen.

Befehlssatzerweiterungen​

Da höhere Leistung von Prozessoren - auch pro Watt - nicht nur mit Verbesserungen bei der Ausführung von Programmcode, sondern auch mit verbessertem Energiemanagement (siehe nächste Seite) und Erweiterungen des Befehlssatzes erzielt werden kann, sollen letztere hier natürlich auch erwähnt werden. Im Gegensatz zu den anderen Verbesserungen sind softwareseitige Änderungen wieder von den verwendeten Compilern abhängig. Aber da ist AMD v.a. mit der Unterstützung durch Microsoft und eigener Beteiligung an der Weiterentwicklung von GCC und Open64 gut positioniert. Letzterer wird sogar für AMD's SPEC-Messungen verwendet. Beide Open Source Compiler werden bereits seit längerer Zeit für Bulldozer angepasst, was sogar einige Architektur-Details verriet. Microsoft wird vermutlich ebenfalls schon länger mit AMD zusammenarbeiten, wie auch weitere Compilerbauer.

Laut den Informationen im GCC- und im Open64-Compiler wird Bulldozer neben den älteren folgende aktuelle Erweiterungen unterstützen:
  • SSE
  • SSE2
  • SSE3
  • SSE4a
  • SSSE3
  • SSE4.1
  • SSE4.2
  • AES
  • PCLMUL
  • AVX
  • XOP
  • FMA4
  • LWP (Lightweight Profiling)

Lightweight Profiling
Diese Erweiterung wurde in Form eines White Papers von AMD 2007 als Vorschlag der Öffentlichkeit vorgestellt und wurde 2009 als überarbeitete Fassung veröffentlicht. Mit ein paar zusätzlichen Befehlen soll dadurch Anwendungen, vorzugsweise aus dem Bereich virtueller Maschinen (Java, .NET), eine einfache Möglichkeit der Anwendungsanalyse gegeben werden, um auszuführenden Code entsprechend des festgestellten Verhaltens anpassen bzw. optimieren zu können.

Advanced Synchronization Facility
Diese wie LWP schon am Anfang des Artikels erwähnte Erweiterung wurde ebenfalls von AMD schon 2007 vorgeschlagen und 2009 auch in einer neuen Fassung veröffentlicht. Sie ermöglicht durch hardwareseitige Unterstützung von Software Transactional Memory eine effizientere Umsetzung von atomaren Speicherzugriffen in multithreaded Applikationen. Durch ihre Hilfe können solche Anwendungen mit geringeren Performanceverlusten durch die Ausführung auf vielen Kernen weiter beschleunigt werden. Es gibt auch erste Patente dazu und auch veröffentlichte Forschungsergebnisse. Bei betroffenen Anwendungen sind entsprechend dieser Ergebnisse Beschleunigungen von 10-20% vorstellbar.

Der Grund für die Erwähnung von ASF an dieser Stelle ist die Möglichkeit, dass schon die erste Version der Bulldozer-Architektur ASF beinhaltet. Das wäre mit der vermuteten Fähigkeit, Checkpoints anzulegen, sowie kleineren Anpassungen in der Architektur (z.B. die in den ASF-Patenten beschriebenen zusätzlichen Cache-States) schon umsetzbar. Es deuten allerdings nur vage Hinweise auf eine schon kommende Implementation. Wesentlich wahrscheinlicher ist das Erscheinen in einer überarbeiteten bzw. erweiterten Version der Bulldozer-Architektur, möglicherweise schon 2 Jahre später.
[Break=Energiemanagement]
0b52664e099645c896122d33ef5f3a9c

Energiemanagement​

Wie vielen sicherlich bekannt ist, wurde der Turbo-Modus einiger von AMDs jetzigen CPU-Modellen heuristisch umgesetzt. Dabei wurden einfache Bedingungen ermittelt, welche das Hochtakten einer begrenzten Anzahl von Kernen erlauben. Diese nehmen jedoch keine Rücksicht auf den realen Energiekonsum, sondern arbeiten stattdessen mit den P-States und dem daraus abgeleitetem Spielraum für die gezielte Übertaktung.

Für Llano wurde bereits ein verbessertes Energiemanagement angekündigt. Dieses beinhaltet u.a. eine genaue digitale Messung von Strombedarf und Temperaturen. Das ermöglicht schließlich eine optimierte Einstellung von Taktfrequenzen und Spannungen der Kerne, was den real verbleibenden thermischen Spielraum besser ausnutzen kann.

Es kann angenommen werden, das beim Bulldozer einige der Techniken von Llano zum Einsatz kommen, aber ergänzt um Energiesparmöglichkeiten, die bis in die Mikroarchitektur hineinreichen. Dadurch verliert diese für das Energiemanagement den Black-Box-Charakter und existierende Potenziale können besser genutzt werden.

Es sind beispielsweise folgende Möglichkeiten denkbar, die u.a. auch in Patenten beschrieben wurden:

  • Schätzung des Bedarfs anhand der auszuführenden Befehle für Umverteilung
  • Beobachtung der Auslastung von Einheiten (Resource Monitors)
  • Clock/Power Gating von Einheiten und selbst Teileinheiten
  • Aktivierung benötigter Einheiten nur bei Bedarf (z.B. einer FMAC-Einheit, wenn ein entsprechender Befehl demnächst ausgeführt werden soll)
  • Umverteilung des nicht genutzen Spielraums beim Energieverbrauch zur Nutzung durch andere Einheiten oder Kerne
  • Umfassende Adaption von Architekturmerkmalen (z.B. Änderung von Cachegrößen, TLB-Größen, Anzahl aktiver Decoder, Anzahl aktiver Ausführungseinheiten, Taktfrequenzen, Arbeitsweisen)

Man konnte bereits von einem Feature namens „APM Boost“ (APM steht für „Application Power Management“) hören, was man sich als applikationsspezifischen Turbo-Modus mit Einflussnahme auf die Architektur selbst vorstellen könnte (z.B. Abschaltung einer halben FPU oder Heruntertakten des zweiten Cores sowie weitere adaptive Maßnahmen).

Im hier gezeigten Diagramm soll das Potenzial solcher Methoden gezeigt werden, wobei modellhaft eine Umverteilung des Energiebudgets angenommen wurde. Ein Bulldozer-Modul nutzt nach der Umverteilung die Energie des Budgets besser aus, überschreitet wie z.B. im Fall des Integer Schedulers 1 sogar das Energiebudget der Einheit.


Aber wie kann ein so zur Verfügung gestelltes zusätzliches Budget überhaupt genutzt werden? Hier könnte z.B. mit veränderten Einheitentaktfrequenzen durch teilweise maskierte Taktzyklen (Clock Cycle Stealing) oder Ab-/Anschaltung von Teileinheiten gearbeitet werden.

Zusätzlich zu dieser Modul-internen Leistungssteigerung besteht natürlich die Möglichkeit, nicht genutzte Energiebudgets zwischen den Modulen und dem Uncore-Bereich zu verteilen, was den bekannten Turbo-Modi einiger CPUs von Intel bzw. AMD ähnlich ist. Darüber hinaus ist auch ein Ansatz wie bei Sandy Bridge denkbar, wo der Prozessor soweit mit höherer Taktfrequenz und evtl. Spannung versorgt wird, bis er sogar die TDP überschreitet. Weiterhin ist eine kurzfristige Energieverbrauchsverteilung über die Zeit denkbar, wonach in Phasen niedrigerer Auslastung ein Energiebudget angesammelt würde, welches in aktiveren Phasen in Form von Überschreitung der TDP aufgebraucht wird. Das hängt dann ganz von der Energiemanagementstrategie ab.

[BREAK=Die-Size-Schätzung]
0b52664e099645c896122d33ef5f3a9c

Die-Size-Schätzung​

Ein bei CPUs und auch GPUs oft erwähntes Thema ist neben dem Herstellungsprozess die Größe des hergestellten Siliziumchips ("Die"), um daraus wirtschaftliche Auswirkungen (Herstellungskosten) und die eventuellen Preisgestaltungsspielräume einzuschätzen.

Zur Schätzung der Fläche sowohl der Bulldozer-Module auf dem Die als auch des gesamten Prozessor-Dies habe ich ausgehend von den Flächen der Einheiten beim Llano-Core (welcher im selben Prozess hergestellt wird) und geschätzten Annahmen über die Änderungen beim Bulldozer eine Berechnung durchgeführt. Die Eingangsdaten und das Ergebnis für ein Bulldozer-Modul sind in der folgenden Tabelle zu sehen.

<table summary="Bulldozer Die Size Schätzung" style="text-align: center;" border="1" cellpadding="3" cellspacing="0"><tbody><tr><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">Llano-Teileinheit</th><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">Fläche (mm²)</th><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">BD-Teileinheit</th><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">Faktor BD/Llano</th><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">Faktor für 2. Int Core</th><th style="background: none repeat scroll 0% 0% rgb(0, 140, 88); font-weight: bold; color: rgb(255, 255, 255); -moz-background-inline-policy: continuous;">Fläche BD-Modul (geschätzt in mm²)</th></tr><tr><td>64k L1D+LSU</td><td>2,44</td><td>16k L1D+LSU</td><td>1</td><td>2</td><td>4,88</td></tr><tr><td>L1I, BP, PD</td><td>2,17</td><td>L1I, BP, PD</td><td>1,3</td><td>1</td><td>2,82</td></tr><tr><td>DEC</td><td>0,86</td><td>DEC</td><td>1,4</td><td>1</td><td>1,2</td></tr><tr><td>Core Interface</td><td>0,44</td><td>Core Interface</td><td>1,3</td><td>1</td><td>0,57</td></tr><tr><td>IEU, ROB, RF</td><td>0,57</td><td>IEU, ROB, RF</td><td>0,9</td><td>2</td><td>1,02</td></tr><tr><td>FPU (128 bit)</td><td>1,74</td><td>FPU (2xFMAC)</td><td>2,4</td><td>1</td><td>4,17</td></tr><tr><td>L2 (1 M)</td><td>6,23</td><td>L2 cache (2M)</td><td>2</td><td>1</td><td>12,47</td></tr><tr><td>Gesamtfläche</td><td>14,45 (~16 mit ungenutzten Bereichen)</td><td>
</td><td>
</td><td>
</td><td>27,13</td></tr></tbody></table>

Von dieser Größe (~27 mm²) ausgehend würde ein Bulldozer-Prozessor mit 8 Kernen bzw. 4 Modulen und angenommenen 8 MB L3-Cache (z.B. Zambezi) ca. 214 mm² Fläche benötigen. Diese setzt sich aus 108 mm² für die Bulldozer-Module, 55 mm² für den L3-Cache und geschätzten 50 mm² für I/O und IMC zusammen. Die Zahl der Transistoren könnte im Bereich von 1-1,2 Milliarden liegen. Die Herstellungskosten sind auf Grund der Herstellung bei Globalfoundries und damit einhergehender nicht öffentlicher Verträge auch nicht einfach zu ermitteln. Mit einer Größe von ca. 214 mm² würden rund 300 Dies auf einen 300 mm Wafer passen. Bei Die Yields von 70% würden knapp über 200 verkäufliche Dies verbleiben. Mit Harvesting, also der Verwendung von teildeaktivierten Dies für kleinere Modelle, entsprechend mehr. Würde AMD grob geschätzte 6000$ für einen 32nm HKMG Production Wafer mit 70% Yield zahlen, ergäbe dies etwa 30$ pro produziertem Die (für Zambezi). Zusammen mit Test, Packaging (Aufbringen auf das Träger-Substrat) und Transport sind 40$-45$ Herstellkosten vorstellbar. Wie sie in der Realität aussehen werden, bleibt abzuwarten.

Eine kleinere Bulldozer-Variante mit 4 Kernen (54 mm²) und 4 MB L3-Cache (28 mm²) sowie I/O+IMC (~30 mm²) käme auf eine Fläche von 112 mm² und wäre damit recht günstig herzustellen. So ein Prozessor hätte etwa halb soviel Transistoren wie die große Variante und könnte der Fläche entsprechend ca. 20$ in der Herstellung kosten.
[BREAK=Ausblick]
0b52664e099645c896122d33ef5f3a9c

Ausblick​

Ein sehr spannendes Thema ist natürlich ein Vergleich der im Jahre 2011 vermutlich miteinander konkurrierenden Architekturen. Im Serverbereich wären das von Intel die Nehalem-Architektur in Form von Nehalem EX (schon auf dem Markt) und Westmere EX und von AMD die Bulldozer-Architektur in Form von Valencia und Interlagos. Im Desktopbereich sehen wir dann ebenfalls von AMD die Bulldozer-Architektur im Zambezi und von Intel die Sandy Bridge-Architektur, sowie von AMD einen nochmals verbesserten Kern aus der K10-Reihe im Llano (“K10.6”). Neben diesen werden in dem Jahr oder eventuell später auch weitere, mehr oder weniger performante, aber sehr effiziente Architekturen für mobile Geräte auf den Markt kommen, wie z.B. AMDs Ontario mit Bobcat-Kernen oder der Moorestown-Prozessor von Intel.

Desktop: “Sie werden bereits erwartet!”
Im Versuch den für die meisten Leser spannendsten Vergleich (high end Desktopsysteme) herauszufischen, soll hier versucht werden, auf Basis der vorhandenen, meist spärlichen Informationen, Sandy Bridge mit Zambezi zu vergleichen.

Ein wenig erleichtert wird dies durch bereits aufgetauchte erste Benchmarks von Sandy Bridge. Obwohl ich deren Echtheit nicht anzweifle, haben sie dennoch Beta-Charakter, da Prozessor, Chipsatz und BIOS sehr wahrscheinlich noch keine Endkunden-Versionen sind. Aber es sind schon moderate Verbesserungen der IPC gegenüber Nehalem (geschätzt ca. 10%) zu erkennen sowie einige deutliche Optimierungen wie bei Speicheroperationen (speziell Stores). Das kann im Wesentlichen durch die Erhöhung der L1-Cache-Bandbreite, Verbesserung des Durchsatzes von Speicheroperationen und einen vermuteten deutlich größeren Loop Cache, vielleicht sogar durch einen Trace Cache erfolgen. Weitere Designverbesserungen, z.B. beim L3-Cache, tragen natürlich auch dazu bei. Kürzlich sind weitere Benchmarkergebnisse aufgetaucht, die v. a. einen deutlichen Leistungsanstieg bei multithreaded Code zeigen.

Der Effekt der AVX-Befehlserweiterung konnte sich bei diesen Tests auch noch nicht zeigen. Intel selbst erwähnte schon Leistungssteigerungen bis über 40% in den Intel Entwickler Foren bei manchen AVX-Test-Codes. In den meisten Anwendungen, die heute SSE benutzen, könnte AVX nochmal 20% bringen. Das muss sich erst noch zeigen. Hierbei wird es ein Problem sein, dass dadurch der Energieverbrauch der Kerne steigt und somit den Handlungsspielraum des Turbo-Boost-Modus einschränkt.

Da Hans de Vries bereits anhand des Sandy-Bridge-Die-Fotos im Vergleich zu Westmere keine wesentliche Vergrößerung der FPU feststellen konnte, vermutet er eine double pumped bzw. staggered (gestaffelte) Ausführung von 256-bit-Befehlen auf 128-bit-Einheiten. Da es sich um Vektordaten handelt, die mehrere prinzipiell unabhängige Elemente enthalten, kann eine versetzte Bearbeitung der beiden 128-bit-Hälften erfolgen. Befehle mit Abhängigkeiten zwischen den Hälften gibt es in der AVX-Erweiterung praktischerweise nicht. Diese gestaffelte Ausführung kann mit dem Standardtakt erfolgen (wie z.B. bei SSE2-Befehlen auf dem K8) oder mit einem erhöhten FPU-Takt. Durch Hyperpipelining kann die Arbeit der FPU-Einheiten weiter unterteilt werden. Das ermöglicht eine höhere Taktfrequenz der FPU - z.B. den doppelten Takt des restlichen Kerns. Es könnten die fixen Bedingungen der Ausführung von AVX-Befehlen genutzt werden, um die oberen und unteren Hälften der beteiligten YMM-Register (256-bit breite SIMD-Register der AVX/XOP-Befehlserweiterungen) in schneller Folge zu bearbeiten. Das erfordert überschaubare Anpassungen an Scheduler, Register Files und anderen Einheiten. Dadurch könnten 128-bit-Befehle aber noch nicht in schneller Folge ausgeführt werden. Eine ähnliche Argumentation kann auf den Bulldozer angewendet werden.

Sollen die Prozessoren auf der Basis der reinen Rechenleistung verglichen werden, ist eine Möglichkeit, aus bekannten Relationen zu schließen. Für Sandy Bridge kann mit den schon genannten 10% IPC-Steigerung begonnen werden. Für die Rechenleistung wird aber auch der Taktfrequenzbereich benötigt, mit der dieser Prozessor später in Desktopsystemen betrieben werden wird. Da gibt es als Anhaltspunkt den Wikipedia-Artikel zu Sandy Bridge, welcher ähnliche Taktfrequenzen wie die des Nehalem im Core i7 nennt. Diese könnten aufgrund der energieeffizienzorientierten Designoptimierungen bei Sandy Bridge in einem System mit diskreter GPU bei Turbo Boost höher ausfallen, als z.B. beim Nehalem mit gleicher Kernanzahl. Die externe GPU würde den Einsatz und damit das Energiebudget der integrierten GPU ersparen. Allerdings käme mit externer GPU zum Energiebudget der CPU ohne interne GPU das der externen GPU hinzu. Kurz: man kann bei Sandy Bridge einen deutlich größeren Spielraum für den Turbo Boost vermuten. Intel hat Entsprechendes auch schon verkündet.

Zusammengefasst kann man bei bisherigem Code mit Sandy Bridge eine Steigerung von 10-25% bei gleicher Basisfrequenz und Kernzahl erwarten. Das hängt im Wesentlichen von den Verbesserung der Effektivität des Power Managements ab. Kürzlich wurden Taktfrequenzen von "Sandy Bridge"-Modellen bekannt, welche eher auf weniger starke Leistungssteigerungen hindeuten.

Zambezi wird dagegen nicht mit integrierter GPU bzw. als APU erscheinen und soll laut AMD-Roadmap mit zwei bis vier Modulen, also vier bis acht Kernen, ausgestattet sein. Hinzu käme ein L3-Cache und entsprechend der Möglichkeiten des AM3-Sockels ein Dual Channel DDR3-Interface. Als Ausgangsbasis für die Schätzung sollen möglichst nur schon bekannte Daten herangezogen werden. AMD gab zwar bisher keine Hinweise auf die Leistung der Desktop-Prozessoren auf Bulldozer-Basis, aber man hat schon Kennzahlen vom Interlagos veröffentlicht, welche aussagen, dass bei verschiedenen parallelisierten Anwednungen (vermutlich SPECrate CPU) im Durchschnitt etwa 50% mehr Leistung als beim Magny Cours zu erwarten ist. Daraufhin gab es verschiedentlich schon negative Reaktionen, die besagten, dass dies nur einer Steigerung von ~13% (1,5/1,33) pro Kern entspräche. Hier muss aber auch bedacht werden, dass sich in dieser Situation schon sowohl Memory Wall als auch Power Wall auswirken. Weiterhin stehen den Bulldozer Cores bei einer niedrigeren Threadanzahl sowohl mehr Energie (für höhere Taktfrequenz nutzbar) als auch mehr Speicherbandbreite pro Core und oft auch die sonst von zwei Cores gemeinsam genutzten Einheiten im Modul vollständig für einen Core zur Verfügung. All diese Effekte müssen in die Überlegungen einbezogen werden.

Demnach dürfte die per Core-Leistung bei gleicher Kernanzahl wie beim K10 sehr deutlich zunehmen (v. a. dank des Energiebudgets) und bei höherer Kernzahl entsprechend höher ausfallen. Sollte sich das auch in der Realität so zeigen, wäre AMD mit der hier unabhängig von einer realen Taktfrequenz betrachteten relativen Kernrechenleistung gegenüber Sandy Bridge sehr gut aufgestellt. Durch Einsatz effizienter Energiemanagement-Techniken (ähnlich zum Llano oder nochmals effizienter) könnte auch hier deutlich Rechenleistung aus dem zur Verfügung stehenden Energiebudget herausgeholt werden. Es tauchte gerüchteweise schon der Begriff “APM Boost” und damit einhergehend “Application Power Management” auf wie auch entsprechende Patente.

Auf jeden Fall wird die Konkurrenzsituation in Zukunft im Desktop-Bereich wie auch den anderen Marktsegmenten wieder stärker.

Server: Es wird spannend
Hier werden neben der Rechenleistung, welche zweifellos sehr konkurrenzfähig sein wird, auch das Energiemanagement, Virtualisierung, Sicherheit und vor allem RAS-Features entscheidend sein. Beim Energiemanagement sind Neuerungen bereits angekündigt worden. Im Bereich der Virtualization gibt es noch keine Anzeichen für neue Features. Dafür dürften einige wichtige Komponenten, wie z.B. der IMC, für ein effizienteres Handling vieler VMs optimiert worden sein, da der Anteil solcher Anwendungen im Serverbereich groß ist. Womit außerdem gerechnet werden sollte, sind Neuerungen bei Sicherheit und den RAS-Fähigkeiten der Prozessoren. Hier besteht auch Aufholbedarf gegenüber Intels Nehalem-EX- und Tukwila-Prozessoren (IA-64-Architektur) und etablierten Serverprozessorreihen anderer Hersteller.

Was da schon mit Bulldozer kommen wird, lässt sich zum jetzigen Zeitpunkt noch nicht genau sagen. Es wird aber zum Beispiel bereits an sicherer Codeausführung (z.B. auf parallelen Pfaden mit Vergleich aller erzeugten Ergebnisse), dezimalen Floating-Point-Operationen (wird stark von IBM getrieben für den Einsatz im Finanzsektor), Codesicherheit (Ausführung verschlüsselter Programmcodes) gearbeitet.

Mobile: Leistung zum kleinen Energiepreis
Während hier kaum etwas über den geplanten Einsatz von Bulldozer-Kernen bekannt ist – außer vage Hinweise auf kommende Fusion-Architekturen – kann man sich von den zu erwartenden Fähigkeiten des Prozessors auch ein Bild über die Eignung im Mobilbereich machen. Zwar wird der untere Teil des Energieverbrauchsspektrums durch Bobcat abgedeckt, aber auch für leistungsfähigere Notebooks und andere Mobilgeräte wird ein Kern mit einer hohen Energieeffizienz benötigt. Noch existiert der Llano-Kern, welcher ein weiter optimiertes und mit neuen Energiesparfähigkeiten ausgestattetes K10-Derivat ist. Aufgrund seiner zur Bulldozer-Architektur wahrscheinlich deutlich niedrigeren Energieeffizienz wird er vermutlich nach etwa 1 Jahr Existenz durch Bulldozer-Module ersetzt werden. Denn das Ziel, eine effiziente Mikroarchitektur für vielkernige Serverprozessoren zu entwickeln, verlangt mittlerweile häufig ähnliche Maßnahmen wie das gleichgeartete Ziel für die Entwicklung von Mobilprozessoren.

[BREAK=Vergleichstabelle verschiedener Architekturen und Bulldozer]
0b52664e099645c896122d33ef5f3a9c

Abschließend ist in einer Tabelle gegenübergestellt, wie sich die verschiedenen aktuellen und zukünftigen Kernarchitekturen in einigen wichtigen Kenngrößen unterscheiden:

<table summary="Bulldozer im Vergleich mit anderen Mikroarchitekturen" style="text-align: center;" border="1" cellpadding="3" cellspacing="0"><tbody><tr><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">
</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">K7</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">K8</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">K10</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">Llano</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">Bulldozer-Kern</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">Bulldozer-Modul</th><th style="font-weight: bold; color: rgb(255, 255, 255); background: none repeat scroll 0% 0% rgb(0, 140, 88);">Sandy Bridge</th></tr><tr><td>Decode</td><td>3 MacroOps</td><td>3 MacroOps</td><td>3 MacroOps</td><td>3 MacroOps</td><td>~4 x86 Ops?</td><td><=8 x86 Ops?</td><td>4 µOps (+1 mit Macro Op-Fusion)</td></tr><tr><td>Issue</td><td>3 MacroOps</td><td>3 MacroOps</td><td>3 MacroOps</td><td>3 MacroOps</td><td>4 ALU + 3 AGU + 4 FP</td><td>2 x 4 ALU + 2 x 3 AGU + 4 FP</td><td>4 MacroOps</td></tr><tr><td>ROB</td><td>72</td><td>72</td><td>72</td><td>84</td><td>?</td><td>?</td><td>>128?</td></tr><tr><td>FPU-Width (bit)</td><td>64 (80)</td><td>64 (80)</td><td>128</td><td>128</td><td>128 - 256</td><td>256</td><td>256</td></tr><tr><td>FPU Units</td><td>fadd, fmul, fmisc (64b)</td><td>fadd, fmul, fmisc (64b)</td><td>fadd, fmul, fmisc (128b)</td><td>fadd, fmul, fmisc (128b)</td><td><= 2 x fmac (+ fmisc? 128b)</td><td>2 x fmac (+ fmisc? 128b)</td><td>fadd, fmul, falu (256b)</td></tr><tr><td>L1 Instruction Cache (kB, Ways)</td><td>64 (2)</td><td>64 (2)</td><td>64 (2)</td><td>64 (2)</td><td>64 (4)?</td><td>64 (4)?</td><td>32 (4?)</td></tr><tr><td>L1 Data Cache (kB, Ways)</td><td>64 (2)</td><td>64 (2)</td><td>64 (2)</td><td>64 (2)</td><td>16 (4)</td><td>2 x 16 (4)</td><td>32 (8?)</td></tr><tr><td>L1D$ Bandbreite Reads/Writes (bit/cycle)</td><td>2 x 64b reads/writes</td><td>2 x 64b reads/writes</td><td>2 x 128/0 x 64 oder
1 x 128/1 x 64 oder
0 x 128/2 x 64</td><td>2 x 128/0 x 64 oder
1 x 128/1 x 64 oder
0 x 128/2 x 64?</td><td>2 x 128/1 x 128</td><td>4 x 128/2 x 128</td><td>384 kombiniert (wahrscheinlich 384/0 oder 256/128)</td></tr><tr><td>L2 (kB, Ways)</td><td>256 - 512</td><td>512 - 1024</td><td>512 - 1024</td><td>1024</td><td>2048 (shared)</td><td>2048 (shared)</td><td>256</td></tr><tr><td>L3</td><td>-</td><td>-</td><td>2048 - 6144</td><td><=8192?</td><td><=8192?</td><td>?</td><td>8192 (shared)</td></tr><tr><td>Anzahl Threads</td><td>1</td><td>1</td><td>1</td><td>1</td><td>1</td><td>2</td><td>2</td></tr><tr><td>Die area per core (mm²)</td><td>~69 (130 nm)</td><td>22,5 (65 nm)</td><td>15,3 (45 nm)</td><td>9,69 (32 nm)</td><td>~7 (32 nm, ohne L2)
~14 (32 nm, mit 1M L2)</td><td>~13 (32 nm, ohne L2)
~27 (32 nm, mit 2M L2)</td><td>18,4 (32 nm, 256kB L2)
Westmere: 17,2 (32 nm, 256kB L2)</td></tr></tbody></table>​

Anmerkung: Die Tabelle erhebt keinen Anspruch auf 100%ige Richtigkeit, wurde aber mit dem Ziel hoher Genauigkeit erstellt. Auf manche Daten wie Taktfrequenzen oder Leistungsaufnahme wurde hier bewusst verzichtet.

[BREAK=Zusammenfassung]
0b52664e099645c896122d33ef5f3a9c

Zusammenfassung​

In diesem Artikel sollte ein recht umfassendes Bild der aktuellen Interpretationen der kommenden Bulldozer-Architektur vermittelt werden. Aufgrund der Art der Quellen ist es natürlich möglich, dass Einiges davon so nicht zutreffen wird. Dennoch sollte die dadurch vermittelte Vorstellung von der Bulldozer-Architektur näher am Original liegen, als es die offiziellen Informationen erlauben. Der Zeitpunkt des Bekanntwerdens neuer Details zum Bulldozer ist diesmal wieder festgesetzt (im Gegensatz zu den vielen eher zufälligen Entdeckungen) auf den 24. August 2010. An diesem Tag wird auf der “Hot Chips”-Konferenz ein Vortrag über die Bulldozer-Architektur gehalten. Es bleibt also weiterhin spannend. Natürlich konnten aufgrund des Umfangs an möglichen Interpretationen auch die spekulativen Inhalte dieses Artikels nicht vollständig dargestellt werden. Die weiter interessierten Leser sollten mit den bereitgestellten Links oder geeigneten Suchwörtern für die gängigen Suchmaschinen in der Lage sein, ihren Wissensdurst zu stillen.

Danksagung​

Da dieser fast gänzlich auf Spekulationen und Puzzleteilen aufbauende Artikel nicht allein auf den Gedanken eines einzelnen Autors aufbauen kann, möchte ich einigen Personen bzw. Personengruppen danken. Da wäre zuerst Nero24 zu nennen, der mich vor etwa einem halben Jahr fragte und ermutigte, einen solchen Artikel zu verfassen. Als nächstes danke ich Hans de Vries, welcher mit seiner Webseite als erster die Idee hatte, öffentlich anhand von Patenten oder auch Die-Fotos über zukünftige Mikroarchitekturen zu spekulieren, und mich damit positiv beeinflusste. Er war auch oft mit guten Interpretationsideen an der Bulldozer-Spekulation beteiligt. Aus demselben Grund danke ich Alex (“Opteron”) und auch für seine Unterstützung bei der Erstellung dieses Artikels. Weiterhin danke ich den vielen Teilnehmern im Planet 3DNow! Forum, welche seit mehreren Jahren über viele Threads verteilt die Bulldozer-Spekulation vorantrieben. Ebenso gab es viele gute Beiträge von Autoren in vielen anderen Foren sowie in Kommentaren zu meinem Bulldozer-Blog, welche manchen Gedanken kritisch hinterfragten, andere unterstützten und neue einbrachten.

<center>Artikel im Forum kommentieren...
Weitere Artikel...</center>
 
Zuletzt bearbeitet:
Zurück
Oben Unten