Mit der "Haswell" bringt Intel nach der Refresh-Architektur "Ivy Bridge" zwei Jahre nach "Sandy Bridge" wieder eine neue offizielle Prozessoren-Architektur an den Start. Neben den offensichtlichen Änderungen in Form der neuen CPU-Befehlssatzerweiterung AVX2 und TSX sowie der teilweise deutlich aufgebohrten integrierten Grafiklösung beschränken sich viele Änderungen gerade am CPU-Part eher auf Detailverbesserungen – womit in der Summe auch weit weniger Mehrperformance in heutigen Anwendungen zu erwarten ist als man üblicherweise einer "neuen Architektur" zuspricht. Der eigentliche Zugewinn von Haswell liegt eher denn im Grafik-Part, mittels welchem sich Intel erstmals auf echte Augenhöhe mit den AMD-Lösungen begeben will.

Hieran ergibt sich auch, daß Haswell wieder etwas größer und schwerer als Ivy Bridge ausgefallen ist, wobei beide Prozessoren bekannterweise in der 22nm-Fertigung hergestellt werden: Die mit Ivy Bridge (1,4 Mrd, Transistoren auf 160mm²) vergleichbare GT2-Ausführung von Haswell bringt 1,6 Mrd. Transistoren auf 177mm² Chipfläche auf die Waage – was aber immer noch ein exzellenter Wert ist verglichen mit früheren Performance-Prozessoren von Intel, welche durchaus auch einmal 300mm² Chipfläche und mehr belegten. Interessant ist hierbei, daß Intel mit Haswell als dem 22nm-Refreshchip noch nicht einmal die Chipfläche des 32nm-Refreshchips in Form von Sandy Bridge mit 216mm² Chipfläche erreicht. Und auch gegenüber AMDs Bulldozer (1,2 Mrd. Transistoren auf 315mm²) dürfte Intel erhebliche Kostenvorteile in der CPU-Fertigung aufweisen:

Dies gilt dann aber nicht mehr bei der größten Haswell-Ausführung mit GT3-Grafikeinheit, welche derzeit ausgehend von einem Die-Shot auf immerhin 264mm² Chipfläche geschätzt wird – der eDRAM kommt hierbei mit geschätzten 84mm² Chipfläche noch hinzu. Jene größte Haswell-Variante ist allerdings nur im Mobile-Segment interessant, wo man die integrierten Grafikeinheiten auch wirklich nutzt – für den Desktop-Bereich und damit die Betrachtungen zur CPU-Architektur selber wäre die Haswell-Variante "4C+GT2" der bessere Betrachtungsgegenstand, weil dort auch für die Top-Modelle eingesetzt.

Die nominell bedeutsame Änderung der Haswell-Architektur liegt in den Integer-Ausführungseinheiten, welche Intel erstmals seit der Core-2-Architektur wieder verbreitert hat: Anstatt drei Integer-Einheiten (ALUs) gibt es nunmehr gleich vier Integer-Einheiten samt den dazugehörigen dann auch vier Adressgenerierungs-Einheiten (AGUs). Da der meiste Code, welchen heutige CPUs abarbeiten müssen, wild gemischter Integer-Code ist, sollte dies der eigentlich bedeutsamste Fortschritt von Haswell sein.

Doch CPUs sind keine Grafikchips, wo man durch die platte Erhöhung der Einheitenanzahl beliebig viel mehr Rechenkraft erzeugen kann. Dadurch, daß durch die Pipeline nur eine bestimmte Anzahl an Befehlen hindurchpasst (limitiert zuerst durch die Leistungsfähigkeit der Befehlsdecoder, aber auch durch diverse Registergrößen & viele andere kleine Dinge im Laufe einer CPU-Pipeline), welche dann auf die Rechenwerke aufgeteilt werden, ergibt sich hier primär ein Effizienzproblem – mehr Einheiten sind theoretisch immer besser, aber sie werden immer schlechter ausgelastet, je mehr man von diesen einbaut.

Bei LowCost-Architekturen arbeitet man daher in aller Regel nur mit zwei ALUs, weil jene recht gut ausgelastet werden können – die drei ALUs der bisherigen Intel-CPUs und auch bei AMD gehen dann schon durchaus in die Richtung, mit einer eigentlich nicht mehr besonders effektiven Maßnahme nur noch ein paar Restpunkte an Performance herauszupressen. Die vierte ALU bei Haswell dürfte dagegen schon fast in Richtung Overkill gehen – sprich unter normalen Umständen wird diese Einheit wohl nur selten belastet werden und idelt daher meistens zwecklos vor sich hin.

Intel hat dies schon erkannt und spricht daher auch nur von einem Performance-Effekt der vierten ALU unter HyperThreading – und in der Tat könnte die vierte ALU dort etwas bringen, sofern allerdings die Pipeline nicht zu sehr mit den Befehlen der jeweils zwei logischen Prozessoren verstopft ist. Einen nicht uninteressanten Nebeneffekt gibt es zudem bei Software mit stark gemischtem Code zwischen Integer- und Fließkomma-Operationen: Da die vierte ALU & AGU an eigenen Ports hängen, stehen bei Nutzung der beiden Fließkomma-Einheiten (welche dann die Ports 1-4 für alle Integer-Operationen blockieren) nunmehr noch zwei ALUs für eingeschobene Integer-Operationen zur Verfügung – und nicht mehr nur eine.

Intel Haswell Ausführungseinheiten

Trotzdem dürfte der Performance-Effekt dieser vierten ALU-Einheit vermutlich stark begrenzt sein. Die vierte ALU wurde wahrscheinlich nur verbaut, weil die dafür benötigte Chipfläche verhältnismäßig gering ist und man schlicht kaum noch weitere Ideen hat, wie man (außer über mehr Kerne und mehr Takt) die Performance heutiger x86-Prozessoren wirklich steigern kann.

Die eher auffälligste Änderung am CPU-Part von Haswell ist dagegen sicherlich in der neuen CPU-Befehlssatzerweiterung AVX2 zu sehen, welche u.a. die von AMDs Bulldozer kommenden FMA-Befehle versteht. Hiermit kann Intel die Fließkomma-Performance unter idealen Bedingungen glatt verdoppelt – in der Realität kommt bei angepasster Software unter alleiniger AVX2-Nutzung immer noch eine Mehrformance im Rahmen von +70% an. Diese Performance-Aussage bezieht sich aber wirklich nur auf Software, welche sich allein mit AVX2 bzw. Fließkomma-Berechnungen abarbeiten läßt. Komplexe Anwendungssoftware benutzt Fließkomma-Berechnungen üblicherweise nur zu einem Bruchteil, womit AVX2 allerhöchstens teilweise zur Performancesteigerung eingesetzt werden kann – sofern der Software-Entwickler jene neue CPU-Befehlssatzerweiterung überhaupt einbaut.

Denn dies ist die übliche Crux von neuen CPU-Befehlssatzerweiterungen: In aller Regel benötigen jene einige Jahre, ehe sie sich bei den Software-Entwicklern etablieren. So ein richtig guter AVX2-Softwaresupport wird wohl erst dann existieren, wenn Haswell schon wieder aus dem (dann) aktuellen Intel-Portfolio entschwunden ist. Sicherlich wird es auch Gegenbeispiele von Software geben, welche schnell auf AVX2 umschwenken werden (speziell bei Programmen mit hohem Fließkomma-Anteil) – doch für die Masse der Software wird der Umstieg nur mit der Zeit kommen und demzufolge Jahre benötigen. Ein größerer Performance-Effekt von AVX2 ist derzeit also gar nicht zu erwarten.

Ähnliches kann man grundsätzlich auch zu der neuen CPU-Befehlssatzerweiterung TSX sagen, hinter welcher sich eine Verbesserung der Multithreading-Performance verbirgt: Hierbei werden Threads, welche mit gleichen Datensätzen arbeiten, nicht zwangsweise synchronisiert (was Performance kostet), sondern die Berechnung wird einfach auf Verdacht hin ausgeführt und erst am Schluß überprüft, ob man das ganze verwenden kann oder eben neu berechnen muß. In der Praxis hat sich ergeben, daß viele Threads doch keine durchgehend überprüfte Datensynchronität benötigen, diesen Arbeitsschritt versucht man sich also zu sparen.

Klug seitens der Software-Entwickler eingesetzt, kann sich hiermit die Auslastung der CPU-Rechenwerke deutlich erhöhen lassen, da sowohl die Prüfungen auf Datensynchronität wegfallen als auch sich Threads nicht gegenseitig "locken", sprich von der Weiterverarbeitung ausschließen können. Jenes Feature wird allerdings seitens der Software-Entwickler voraussichtlich nur bei wirklichen Software-Neuentwicklungen eingesetzt werden und kaum bei bestehender Software nachgereicht werden, wie dies im Fall von AVX2 durchaus noch passieren kann. Der Performanceeffekt von TSX ist also noch viel langfristiger angelegt als jener von AVX2.

Daneben hat Intel an vielen Details die Stellschrauben etwas verstellt bzw. angezogen: So gibt es überall größere Puffer, um die Pipeline nicht an einer einzelnen Stelle stocken zu lassen, eine deutliche Beschleunigung mehrerer Verschlüsselungsverfahren, eine erneut etwas verbesserte Sprungvorhersage sowie eine teilweise verdoppelte Bandbreite zu einigen der Caches. Alle diese Maßnahmen dienen allein dem Zweck, mögliche Flaschenhälse bei früheren Prozessoren-Designs aufzuheben bzw. für einen höheren Datendurchfluß zugunsten der Ausführungseinheiten zu sorgen, auf daß sich diese noch besser auslasten lassen. Wie üblich dürfte sich der Performanceeffekt dieser Maßnahmen einzeln kaum ausmessen lassen, nur in der Summe erbringen jene zusammen eine vielleicht um ein paar Prozentpunkte höhere Pro-MHz-Performance.

Wie schon genannt liegt der größere Fortschritt von Haswell dagegen ganz eindeutig in der integrierten Grafiklösung, welche erstmals bei Intel DirectX 11.1 unterstützt (und damit ironischerweise sogar mehr als die aktuellen HighEnd-Grafikkarten von nVidia). Die höhere Performance wird dabei generell aus der weit höheren Anzahl an Ausführungseinheiten gezogen: Gab es bei Ivy Bridge Modelle mit 6 oder 16 Ausführungseinheiten, sind bei Haswell nun 10, 20 oder gar 40 Ausführungseinheiten aktiv. Zusammen mit den grob gleichen Taktraten wie bei der integrierten Ivy-Bridge-Grafik ist damit durchaus eine Performance-Steigerung auf das Doppelte möglich, was zweifelsfrei in den Bereich der schnellsten Trinity/Richland-Grafiklösungen hineingeht.

Bei der größten Haswell-Grafiklösung GT3 mit gleich 40 Ausführungseinheiten und deren vermutlich hoher Performance ergibt sich allerdings automatisch das Problem, wie eine solche (für die Verhältnisse von integrierter Grafik) mächtige Grafiklösung ausreichend mit Speicherbandbreite gefüttert werden soll, um nicht ansonsten hoffnunglos an eben einer unzureichenden Speicherbandbreite zu verhungern. Erschwerend kommt hierbei der offizielle Speichersupport von Haswell von nur DDR3/1600 hinzu, womit in dieser Frage wirklich kein Staat zu machen ist (AMDs Richland bietet wenigstens offiziellen Support von DDR3/2133 an).

Zur Auflösung dieses Problems kann die GT3-Grafiklösung zusätzlich mit 128 MB eingebetteter Speicher (eDRAM) ausgestattet werden, welcher als extra Chip (~84mm² Chipfläche) neben dem eigentlichen Haswell-Prozessor auf dasselbe Trägermaterial gepresst wird. Angebunden ist jener eDRAM mit einer Bandbreite von 50 GB/sec, was immerhin das Doppelte des DDR3/1600-Arbeitsspeichers (25,6 sec) darstellt – was allerdings weit weniger berauschend ist, als man sich dies von eingebettetem Speicher vorstellen kann. Angesichts der geringen Größe und der kleinen Bandbreite ist von einem gewissen, aber eben doch nicht wirklich durchschlagendem Performance-Effekt des eDRAMs auszugehen.

Interessant ist, daß der eDRAM technologisch nicht explizit der integrierten Grafiklösung zugeordnet ist, sondern vielmehr im normalen Ringbus von Haswell auftaucht und daher auch bei reinen CPU-Berechnungen als Level4-Cache verwendet werden kann. Da die Bandbreite wie gesagt nicht wirklich gut ist, kommt hierbei allerdings kein durchgehender Performance-Effekt bei allen CPU-Berechnungen heraus – vielmehr ist nur dann etwas zu sehen, wenn der Datensatz exakt in die 128 MB eDRAM hereinpasst (und zu groß für den Level3-Cache von 8 MB ist), was in der Praxis eher selten anzutreffen sein wird. Die Konzeption ist nichtsdestotrotz interessant und könnte bei entsprechend angepasster Programmierung sogar für eine durchgehende Mehrperformance sorgen.