Intels Big.Little CPU AlderLake - Sinn oder Unsinn?

Geöffnet als Baustelle! ;) Umbauarbeiten erfolgen noch über einige Bereiche!
Bild von Intel

Big.Little ist ein Konzept, dass ARM 2011 mit den A15 und A7 Cortex-Kernen eingeführt hat um die Vorteile der geringen Energieaufnahme der A7 und der Geschwindigkeit des A15 zu verbinden. Wurde wenig Rechenleistung benötigt, rechneten die A7 Kerne, wird viel Rechenleistung benötigt, rechnen die A15 Kerne. Damals war die Aufteilung noch recht starr und hatte Anfangs auch seine Probleme. Mit DynamIQ hat ARM aber 2017 an den richtigen Stellen gearbeitet, was Big.Little angeht und die Cluster wesentlich flexibler gestaltet und heute entscheidet oft das Betriebssystem, welcher Kern welche Aufgabe übernimmt.


Bei ARM-Kernen geht es dabei bis heute darum, dass man leistungsstarke Kerne mit energiesparenden Kernen kombiniert - effizient sind in dem Fall beide Kerne. Wie in meinem Bericht zum M1-SoC von Apple angesprochen, gibt es bei ARM heute immer breitere Designs bei CPU-Kernen, damit die Geschwindigkeit pro Kern erhöht wird. Beim M1 sprechen wir von 6 ALUs (6-fach Skalar) sowie 4 * 128Bit-SIMD-Alu. All das benötigt in einer CPU Platz und ebenso auch Energie, auch wenn man bestimmte Fähigkeiten einer CPU überhaupt nicht braucht oder nicht ganz ausgelastet bekommt. Während bei ARM-CPUs die Unterschiede nicht nur in der Skalarität der Kerne liegt, sondern auch oft noch in der Ausführungsart - Out-of-Order gegen In-Order - unterscheidet, geht es bei Intel wohl weitgehend um die Komplexität eines Kerns.

Kann man dass den nicht alles per Takt regeln?

Gerade vor einiger Zeit habe ich in einschlägigen Foren oft gelesen, dass das Problem nicht die Breite des Kerns ist, sondern der Takt und dass eine flexible Taktung doch genau das erreichen würde, was ARM mit dem Big.Little-Konzept verfolgt. Auf den ersten Blick ist das durchaus logisch, wenn man beachtet, dass der Energiehunger mit dem Takt steigt und welche Spannung für diesen Takt benötigt wird, vor allem wenn man bedenkt, dass die Spannung hier durchaus quadratisch eingeht.


Gleichzeitig benötigt eine Schaltung aber auch eine gewisse Grundspannung um zu schalten und mit dieser Grundspannung geht auch ein gewisser Grundtakt einher, man kann zwar langsamer Schalten, der nutzen davon ist aber gleich null! In diesem Fall gilt dann, dass die grundlegende Leistungsaufnahme von der Komplexität einer Schaltung abhängt, je mehr Transistoren vorhanden sind, um so mehr Energie benötigt man.


Natürlich gibt es hier weitere Möglichkeiten, in dem man gewisse Gruppen an Schaltungen abschaltet - entsprechende Möglichkeiten gibt es. Das ist nur sehr komplex und führt zudem dazu, dass gewisse Komponenten eines Kerns eine zusätzliche Latenz aufweisen. Zudem blähen solche Schaltungen auch den Kern noch weiter auf, was dazu führt, dass man immer mehr Transistoren braucht.

Energie ist nicht unbedingt das Problem, Komplexität aber schon!

Während bei ARM damals als auch heute eher die Leistungsklasse und damit verbunden der Energiehunger ausschlaggebend ist für das Big.Little-Prinzip, kann man bei Intel als auch AMD eher die steigende Komplexität der Kerne als Ausgangspunkt nehmen. Gut, fast alle modernen x86-Kerne sind nur 4-fach Skalar - Apple M1 ist 6-fach - aber gerade die SIMD-Einheiten werden immer komplexer und bei AMD steht AVX512 an, bei Intel AMX. An der Stelle will ich grob vereinfachen: Eine AVX-512-Einheit benötigt statt 16 Register nun 32 Register und eben 512 Bit, statt 256 Bit pro Datenpfad, man benötigt also wesentlich mehr Platz.


Bisher löste Intel das Problem, wie AMD das Problem, der AVX256-Bit-Befehle bei Zen und Zen+: 2 * 256Bit-SIMD werden zu einer 512Bit-SIMD zusammen geschaltet. Aber auch das macht eine Einheit komplexer. Was nun mit AMX ansteht? Was man bisher so sieht, kommen hier eine durchaus elegante, gleichzeitig aber auch große Schaltung auf uns zu! Mit jeder Erweiterung, jeder Verbesserung werden die x86-Kerne komplexer, ohne dass wir als Otto-Normal-Anwender all diese Möglichkeiten nutzen. Es ist dann oft schön, dass zwar die Möglichkeiten da wären, sie werden nur eben nicht genutzt oder selten genutzt und blähen einen Kern mächtig auf.


Wenn man dann bedenkt, dass auch heute noch die meiste Software, wenn sie denn SIMD einsetzt, eher auf 128-Bit-SIMD-Einheiten optimiert werden und selbst AVX einen 128-Bit-Modus vorsieht und gerade so als Anforderung ankommt und von AVX2 noch nicht viel zusehen ist und an AVX512 quasi nicht genutzt wird*, ist halt die Frage, braucht man einen x86-Kern mit allen Erweiterungen?


Und genau hier setzt eben auch das Bit.Little-Prinzip an: AMD und Intel können auf diese Art und Weise die heutigen, oft sehr fetten Kerne - um bestimmte Erweiterungen berechtigterweise stutzen, sodass man eben 4 - 8 Kerne hat, die wirklich das ganze Programm fahren können und auch mit der passenden Anzahl an ALUs, wenn man es braucht, während man die Little-Kerne so aufbaut, dass sie die alltägliche Software gut abdeckt. Man braucht in diesen kleinen Kernen keine AVX-512-Einheiten oder AMX. AVX und AVX2 reichen. Genau so kann man sich fragen, ob diese Kerne 4-fach-Skalar sind mit einem komplexen Cache-Back- und Frontend (µOPs-Cache, große L1 und L2-Caches) oder nicht ein 3-fach-Skalares Backend zusammen mit einer einfachen Cache-Struktur reicht. Ob es 2 SIMD-Einheiten sein müssen oder eben eine reicht. Alleine aber zum Beispiel das Zurechtstutzen der SIMD-Einheiten hat hier schon einiges an Potenzial.

Es ergibt Sinn!

Geht man immer davon aus - was so manche in den Foren machen - dass die primäre Intention die Energieaufnahme einer CPU ist und die CPU in einem Desktop eingesetzt wird, kann man ein Big.Little-Konzept durchaus hinterfragen und auch kritisch sehen, gerade oder auch weil Intel die Energieaufnahme in den Fokus rückt. Das liegt aber primär daran, dass die Energieaufnahme für die meisten Menschen ein verständlicher und greifbarer Faktor ist.


Geht man aber über die Energieaufnahme hinaus und beschäftigt sich mal mit dem Aufbau von Schaltungen und sieht, was Intel so für die Zukunft geplant hat, rückt halt auch die Komplexität der CPU-Kerne in den Vordergrund und damit auch verbunden die Anzahl der benötigten Transistoren. Natürlich kann man hier wieder sagen, dass das doch am Desktop egal ist - wurde auch so in den Diskussionen gemacht - aber das ist zu kurz gedacht, denn je komplexer ein CPU-Kern ist, um so mehr Transistoren braucht er und um so teurer wird es am Ende für uns Kunden, ohne dass wir daraus wirklich einen Vorteil ziehen.


Die Energieaufnahme ist ein Nebeneffekt, ein Effekt, den man aber gut für das Marketing nutzen kann.