AMDs SSE5 ist tot - lang lebe AVX

Opteron

Redaktion
☆☆☆☆☆☆
Mitglied seit
13.08.2002
Beiträge
23.645
Renomée
2.254
  • SIMAP Race
  • Spinhenge ESL
  • BOINC Pentathlon 2012
Bereits im Jahr 2007 gab es auf Planet 3DNow! zu lesen, dass AMD für seine kommende Prozessor-Architektur Bulldozer an einem neuen, eigenen SIMD-Befehlssatz werkelt: <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1188466382">SSE5</a>. Es sollte der erste Befehlssatz dieser Art in einem x86-Prozessor werden, der 3-Operanden-Instruktionen beherrscht. Doch in den letzten Monaten war es um dieses Thema erstaunlich still geworden.

In diesem Jahr teilte AMD im eigenen Entwicklerforum mit, dass der eigene SSE5-Instruktionssatz zugunsten von Intels AVX aufgegeben wird. Der kleine x86-David verzichtet aber nicht vollständig auf das eigene SSE5, sondern nutzt den eigenen Entwurf, um ab der "Bulldozer-Generation" kompatibel mit Intel zu bleiben. Intel plant AVX mit Sandy Bridge und vermutlich auch mit Larrabee 2010 einzuführen. Doch der Reihe nach...

Mit dem Pentium MMX fing alles an
Die Anfänge der x86/IA32-Erweiterungen reichen in die Pentium 1 Ära (P55C) zurück. Intel führte 1997 mit dem Pentium MMX die SIMD Befehlssatzerweiterung gleichen Namens für Ganzzahlberechnungen ein. Alle damaligen konkurrierenden x86-Produzenten wie AMD mit dem K6, der Cyrix/IBM 6x86MX/ M2 und IDTs/Centaur C6/Winchip übernahmen die Instruktionssatzerweiterung. AMD war bereits damals erfinderisch und bot 1998 in ihren K6-2 Chips zusätzlich eine eigene Erweiterung namens 3DNow! an. Namensähnlichkeiten zum News-Portal - Planet 3DNow! - sind dabei natürlich nicht zufällig...

3DNow! war damals eine Palastrevolution, denn Intels Befehlssatz wurde erstmals von einer Fremdfirmen deutlich ausgebaut und blieb dennoch abwärtskompatibel.

AMDs Achtungserfolg 3DNow!
Während der normale Anwender von MMX nicht viel hatte und die bekannteste Anwendung ein eher unrühmliches Hackerprogramm zur kostenlosen Premiere-Entschlüsselung war, gab es für 3DNow! immerhin gepatchte DLLs für Quake 2 und Quake III Arena, die bis zu 80 Prozent mehr Framerate lieferten. Nachdem sich die Bilder pro Sekunde damals noch nicht in der Größenordnung von ~100 fps abspielten sondern um die 20-30 fps lagen, ein gewichtiger Faktor, der günstige K6-2 CPUs plötzlich auf das Niveau teurer Pentium II hievte [1] und 3DNow! in ein besseres Licht als MMX rückte. Zwar gab es mit MDK ein MMX optimiertes Spiel, jedoch war das Presse-Echo darauf gering, da das Leistungsplus nur im 30 Prozent Bereich lag und die Quake Reihe viel populärer war. Alles in Allem ein kleines PR-Desaster für Intel.

Die Technik: SIMD
Was aber ist eine SIMD überhaupt? Warum gibt es in der PC-Welt alle 2 bis 3 Jahre eine neue, "bessere" Erweiterung? Die englische Abkürzung steht für "Single Instruction Multiple Data". Das bedeutet, dass ein Befehl gleichzeitig auf mehrere Daten verwendet wird. Gängiges Beispiel sind Bild-Operationen. Jedes einzelne Pixel besteht aus einem Farbwertetriple, meistens Rot/Grün/Blau (RGB). Will man z.B. ein Bild nun aufhellen, werden alle drei Parameter gleichwertig manipuliert. Mit SIMD-Instruktionen können mehrere Berechnungen zugleich ausgeführt werden. Der Fachmann nennt derartige Fähigkeiten "Data-Level Parallelism" (DLP). Intels späteres "HyperThreading" ist eine andere Art von Parallelität, diese wird als "Thread Level Parallelism" (TLP). Beides darf aber nicht verwechselt werden, es sind verschiedene Technologien, um den Rechendurchsatz eines Prozessor zu steigern. Mehr zu TLP und SMT gibt's hier.

SIMD / DLP spielt sich auf einer Ebene unter TLP ab. Der Nutzen beider Feature ist dabei ähnlich beschränkt. Hat man keine Software, die sich entsprechend auf Thread- bzw. Daten-Ebene parallelisieren lässt, ist der Mehrwert gleich Null. Genauso verhält es sich natürlich mit alter Software, die überhaupt noch nichts von 3DNow!, SSE1,2,3,4 etc. wissen kann. [2]

Von MMX zu SSE4a
Seit alten MMX-Zeiten wird nun regelmäßig nach dem "schneller, weiter, höher Prinzip" nachgerüstet. Waren die MMX und 3DNow! Befehle noch Untermieter in den Registern der Fließkomma-Einheit (FPU), und konnten nur 64 Bit am Stück bearbeiten, machte Intel mit (I)SSE Nägel mit Köpfen. Erstmals überhaupt wurde der altertümliche x86-Registersatz erweitert. AMDs eigenmächtiger 3DNow!-Vorstoß zeigte wohl schon damals seine Wirkung und veranlasste Intel zu diesem revolutionären Schritt. Insgesamt wurden es acht neue SSE-Register, die 128-bittig ausgelegt wurden. Zusätzlich dazu gab es immer weitere Befehlskombinationen. SSE2 bohrte unter anderem die alten MMX-Befehle auf 128 Bit Bearbeitungslänge auf, womit die 128 Bit Register erst umfassend nutzbar wurden. Zusätzlich wurde die Berechnung von double precision (64 Bit) Werten ermöglicht. SSE3 war ein kleineres Update und ergänzte SSE2. Die Neuerungen dienten der Digitalen Signal Bearbeitung (DSP). Bei genauerer Betrachtung der Funktionalität, handelte es sich dabei größtenteils um eine 128 Bit Version von AMDs, mittlerweile leicht angegrauten, 3DNow! Befehlen.

- SSSE3 ist weiter nicht erwähnenswert. AMD64 fügte keine neuen SSE Befehle hinzu, vergrößert aber den Registersatz im 64-Bit-Modus auf je 16 SSE- und General Purpose Register. Richtig interessant wird es erst wieder mit SSE4.1 und SSE 4.2, die beide zusammen die größte x86-Erweiterung seit 2000 darstellen:

- SSE4.1 bringt Vorteile für die Videobearbeitung (z.B. HDTV/DivX) durch den MPSADBW Befehl, der die Summe mehrere 8 Bit Differenzen berechnet. Zusätzlich gibt es noch Befehle für das Skalarprodukt, wovon 3D-Programme und wissenschaftliche Anwendungen mit Vektorberechnungen profitieren. [3]

- SSE4.2 liefert Befehle für Zeichenketten (Strings) nach. Hiervon profitieren u.a. XML Anwendungen sowie unkomprimierte Datenbanken.

Nicht unerwähnt soll auch AMDs SSE4a bleiben. Dabei handelt es sich um eine zu Intels SSE4 inkompatible Erweiterung. Prinzipiell ist es nur eine kleine SSE3-Erweiterung. Mit den neuen Befehlen kann man zum Beispiel einzelne Bits manipulieren.

Die x86-Welt in zwei Lagern
Erwähnenswert ist bei SSE4a der POPCNT (Population Count) Befehl, womit man Einsen in einer Binärzahl/Vektor zählen lassen kann. Angeblich setzt die berühmt-berüchtigte NSA voraus, dass ihr gesamter Rechnerpark diesen Befehl unterstützt.
Intel hat diesen Befehl ebenfalls in SSE4.2 integriert, aber dummerweise ist diese Version inkompatibel zu AMDs Lösung, da sie andere OpCodes benutzt.

Ein OpCode (operation code) ist dabei die binäre Repräsentation eines Befehls. Wie sicherlich jeder Leser von Planet 3DNow! weiß sind Computer Binärrechner - Rechnen im Zweizahlsystem mit der Zahl "0" und "1". Mit der Zeichenfolge "Popcnt" kann eine CPU nichts anfangen, dass ist nur die Bezeichnung für den Programmierer. Der Prozessor bekommt immer eine Binärzahl/-kette vorgelegt. Im Falle von Popcnt gibt es in der x86-Welt nun deren zwei, jeweils eine AMD- und eine Intel-Version.

So etwas ist natürlich unerwünscht, bedeutet es doch eine Aufsplitten des x86-Marktes in zwei Lager. Zwar ist es nur ein einziger Befehl, aber die nächste Erweiterungsrunde steht kurz bevor. Der Trend ist, dass SIMD-Nachlade-Operationen aus den Registern, Cache oder gar Speicher vermieden werden sollen. AMD und Intel setzten verstärkt auf ein Operandenmodell mit 3, oder gar 4 Operatoren.

[BREAK=AMDs SSE5 und Intels AVX]

2007 - AMDs SSE5
Bereits 2007 präsentierte AMD seine neuen Instruktionen und taufte das durchaus umfangreiche Paket SSE5. Neben Permuatationsbefehlen stechen vor allem die FMA- und Mehroperandenbefehle hervor. Bisher werden nur zwei Operanden (also Variablen) pro Befehl abgearbeitet, nicht mehr. FMA steht für Fused Multipy-Add und bedeutet, dass ein einziger Befehl für eine Kombination aus Addition und Multiplikation angeboten wird, womit Funktion wie A * B + C einfach beschrieben werden können. So etwas ist vor allem im wissenschaftlichen Bereich mit vielen Berechnungen praktisch, weshalb FMA-Befehle im High Performance Bereich (HPC) schon länger genutzt werden. Beispiele für Prozessoren mit Mehroperandenbefehle sind der Itanium und einige Prozessoren der Power-Architektur.

Eine Ausnahme der obigen 2 Operanden Aussage sind nur einige wenige SSE4 Befehle, die drei Operanden benutzen können. Dabei ist der dritte Operand aber auf ein bestimmtes Register festgelegt, wodurch nur wenig Flexibilität gewonnen wird.

Wozu Mehrfach-Operanden-Befehle?
Was aber gewinnt man nun mit Mehroperandenbefehlen ?
Schauen wir uns dazu erst einmal die normalen Zweioperandenberechnung (2op) an. Dessen Ergebnis wird dabei automatisch in einem der zwei Quellregister abgespeichert, der ursprüngliche Wert also zerstört. Um also eine einfache Addition im Schema A = B + C durchführen zu können, ohne die ursprünglichen Variablen zu zerstören, benötigt man zuerst einen zusätzlichen Kopierbefehl:

<Anmerkung: alle Buchstaben bezeichnen Variablen bzw. deren Register; Rückgabe- / Ergebnisregister ist immer die erste Variable>

2op Code:
Code:
move A, B // kopiere Wert B in Register A
add A, C // Addiere A + C, das Ergebnis steht in Register A.

3op Code:
Mit drei Operanden geht das Ganze kurz und knapp in einem Aufwasch:
Code:
add A, B, C

Dadurch spart man sich bei vielen Kalkulationen mit den gleichen Variablen das Umherkopieren der Register, oder gar das viel längere Neuladen aus den Caches bzw. RAM.

Wie man nun vielleicht feststellt benötigt man für FMA logischerweise mindestens drei Operanden-Befehle (im Folgenden FMA3). Falls man eines der Quellregister nicht zerstören will, sogar vier (im Folgenden FMA4 genannt). SSE5 bietet FMA3. Wir merken uns diesen Sachverhalt, der später noch wichtig wird, und betrachten erst einmal Intels Reaktion:

Intels AVX
Intel zeigt sich von AMDs Vorschlag eher pikiert. Nach der gezwungenermaßen Adaption von AMDs x86_64 Befehlssatz, der im Hause Intel zuerst versteckt IA32e, dann EM64T, mittlerweile aber stolz Intel 64 heißt, hat man sich wohl nach wie vor noch nicht erholt. [4]

Seitdem könnte man den Eindruck gewinnen, dass Intel aus Prinzip keine AMD-Entwicklung mehr adaptiert. So wurde SSE5, wie schon 3DNow!, diesmal erst recht abgelehnt und an etwas Eigenem gebastelt. Das Ergebnis wurde den anwesenden Entwicklern und Reportern auf Intels Hausmesse IDF im Frühjahr 2008 unter dem Namen AVX präsentiert.[5] Also nachdem AMDs SSE5 längst auf Kiel gelegt war und Intel sich hätte anschließen können.

Neidlos muss man anerkennen, dass dabei von Seite Intels wirklich nicht gekleckert, sondern geklotzt wird. Nicht nur, weil Intel die SSE Registergrößen gleich auf 256 Bit verdoppelt und das flexiblere FMA4 anbietet, sondern auch, weil Intel ein cleveres OpCode Schema vorstellte. Dabei werden Codes alter 8/16bit Befehle als Befehlspräfix, genannt VEX, wiederverwendet, die im AMD64-Modus ungültig sind bzw. gestrichen wurden.
Einziger Nachteil dabei ist, dass im virtuellen 8086 Modus kein AVX funktioniert, was aber zu verschmerzen sein sollte.[6]

Im 64-Bit-Modus sind die benützten OpCodes teilweise kürzer, als entsprechende SSE5 Befehle, wodurch Befehle schneller bzw. im Mittel mehr davon pro Zeiteinheit dekodiert werden können. Außerdem gibt es auch noch mehrere, ungenützte Bits für zukünftige Erweiterungen. Vor allem letzteres ist im chronisch knappen x86 Befehlsraum ein großer Vorteil.

Darüberhinaus gibt es bei AVX 3-Operanden Versionen aller alten, bisher nur 2-Operand SSE-Befehle, sowie Permutationsbefehle wie sie auch AMD vorgesehen hat.

So, nun hat man also den Salat: zwei komplexe, unterschiedliche Befehlssatzerweiterungen für x86, nicht nur ein einzelner, kleiner Befehl!

Aus AMDs SSE5 wird XOP, FMA4 and CVT16
Nachdem nun der Ball wieder im AMD-Lager war, durfte man auf AMDs Entscheidung gespannt sein. Selbige gab es es nun Anfang Mai. Zuerst wurde klamm und heimlich AMDs Programmierleitfaden für SSE5 aktualisiert. Der Titel wechselte dabei von "AMD64 Technology - 128-Bit SSE5 Instruction Set" [7] in "AMD64 Architecture Programmer’s Manual Volume 6: 128-Bit and 256-Bit XOP, FMA4 and CVT16 Instructions". [8]

Schon am Titel fällt auf: SSE5 ist tot. Liest man weiter im Dokument fällt sofort das neue Befehlsformatschema auf, das Intels AVX entspricht. Sieht man allerdings genauer hin, stellt man fest, dass gelegentlich dann aber doch ein paar Bits unterschiedlich sind. Zum Beispiel gibt es kein VEX-Präfix sondern ein XOP Präfix:
<center><a href="http://www.planet3dnow.de/photoplog/index.php?n=6026"><img src="http://www.planet3dnow.de/photoplog/file.php?n=6026&w=l" border="1" alt="kein VEX-Präfix sondern ein XOP Präfix"></a></center>
Quelle: http://pc.watch.impress.co.jp/docs/column/kaigai/20090518_168661.html

AVX mit FMA3 mal mit FMA4
Das ist dann der Punkt, an dem man an seinem Verstand zweifelt und sich denkt, welcher Teufel AMD da geritten hat, das Intel Schema nur zu 99% zu übernehmen, um dann doch inkompatibel zu sein. Nun, der Belzebub steckt wie immer im Detail bzw. genauer gesagt in Intels aktuellstem AVX-Leitfaden [9].

Entgegen der ersten Version in [10] steht dort plötzlich nichts mehr von FMA4. Stattdessen wird ein relativ komplizierter FMA3 Modus beschrieben.

Über Intels Gründe kann dabei nur spekuliert werden. Höchstwahrscheinlich hat Intel im nachhinein irgendwelche implementierungsabhängigen FMA4-Nachteile entdeckt und ist deshalb zurückgerudert. Für AMD war das sicherlich wie eine
Achterbahnfahrt: zuerst SSE5, dann AVX FMA4, dann AVX FMA3 ... Anzunehmen ist auch, dass AVX seinen Anteil an AMDs Verschiebung der Bulldozer-Architektur hat. Mit selbiger sollte SSE5 eingeweiht werden, aber mit AVX wurde wohl eine Anpassung und somit auch eine Verschiebung nötig.

Von AVX und (dessen) Permutationen
Als man nun Ende 2008 mit den ersten (Umbau)Arbeiten fertig war, kommt Intel plötzlich in den Sinn nach einem Dreivierteljahr die Spezifikation zu ändern. In dem Dilemma entschloss sich AMD zur pragmatischen Lösung, die ursprünglich FMA4 Befehle beizubehalten. Freundlicherweise benützt Intel bei den neuen FMA3 Befehlen andere OpCodes, sodass AMD das VEX Präfix, so wie ursprünglich von Intel geplant, verwenden kann.

Ähnliches gilt auch für die Permutationsbefehle, welche Intel in der aktuellen AVX Instruktionsübersicht ebenfalls gestrichen hat. AMD "übernimmt" diese trotzdem und streicht stattdessen seine eigenen SSE5 Permutationsbefehle. [11]
Alle restlichen SSE5 Befehle, wie z.B. auch die CVT16 Befehle bleiben ebenfalls an Bord. Sie bekommen neben der Verbreiterung auf 256 Bit, allerdings kein VEX-Präfix, sondern das bereits oben erwähnte, neue XOP Präfix, verpasst. Dadurch werden Intels aktuelle und zukünftige AVX Befehle weiträumigst umschifft und Überschneidungen ausgeschlossen.

Soweit, so kompatibel! Was aber ist mit den FMA3-Befehlen? Auch dazu gibt es Positives zu berichten: AMDs Entwickler Dave Christie hat im AMD Entwickler Blog angekündigt, in einer späteren CPU-Iteration auch Intels FMA3 unterstützen zu wollen, "so sich Intel denn einmal definitiv auf ein FMA(3) Schema festgelegt hat." [11]

Das ist nun aber noch nicht das Ende der frohen Kunde. Nein, frei nach dem Motto "ist denn heute schon Weihnachten" garantiert Christie im selben Beitrag auch noch, dass Bulldozer-Kerne alle weiteren sonstigen Erweiterungen unterstützen werden, also auch SSSE3, SSE4.1, SSE4.2 und AES. Letzteres wird erst mit Intels 32nm CPUs erstmals auf dem Markt erscheinen.

OpCode-Chaos
Für die Zukunft wäre zu wünschen, dass sich die drei verbliebenen x86-Hersteller an einen runden Tisch setzten, um dort zukünftige Erweiterungen, Präfixe und OpCodes in Ruhe aushandeln zu können. Der aktuelle Zustand erscheint dem Betrachter chaotisch und gleicht der Ordnung eines "aufgeschreckten Hühnerhaufens": Intel setzt zwar auf AVX, nutzt aber nun doch vorerst kein FMA4, sondern FMA3, welches in Form von SSE5 zuvor noch abgelehnt wurde. AMD dagegen unterstützt zwar Intels FMA4-Befehle, die es dummerweise aber nicht mehr gibt und ist somit trotzdem nicht 100% kompatibel, da noch die neuen AVX-FMA3-Instruktionen fehlen.

Das nächste Problemfeld in Form von speziellen GPGPU Befehlen (Larrabee New Instruction (LRBni)) sowie 16 zusätzlichen Registern und die Verbreiterung aller SSE Register auf diesmal 512 Bit, taucht ebenfalls bereits am Horizont auf [12].

Fazit
Als Fazit bleibt festzustellen, dass AMD den Umständen entsprechend die beste Lösung gefunden hat. Aufgrund Intels 256 Bit Entscheidung könnte Bulldozer dabei vielleicht gar noch "bulliger" ausfallen, als ursprünglich geplant. "Könnte" - weil das nicht notwendigerweise so sein muss.

Special Thanks gehen an Martin Bobowsky für die Textüberarbeitung sowie Andreas Przystawik und Patrick Schwarz für das fachliche Korrekturlesen.

Quellenverzeichnis:
[1] http://www.realworldtech.com/altcpu/subpages/k6faq2/k6faq24of7.htm
[2] http://hpc.serc.iisc.ernet.in/papers/2007/hipc07-sree.pdf
[3] http://softwaredispatch.intel.com/?lid=T9PfncSwnNU=&ch=w
[4] http://www.heise.de/newsticker/EM64T-heisst-jetzt-Intel-64--/meldung/78786
[5] http://www.cse.scitech.ac.uk/disco/mew19/Presentations/Intel_BillHoran.pdf
[6] http://software.intel.com/en-us/forums/intel-avx-and-cpu-instructions/topic/65141/
[7] http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/43479.pdf
[8] http://support.amd.com/us/Processor_TechDocs/43479.pdf
[9] http://software.intel.com/file/10069
[10] http://softwarecommunity.intel.com/.../Intel-AVX-Programming-Reference-31943302.pdf
[11] http://forums.amd.com/devblog/blogpost.cfm?threadid=112934&catid=208
[12] http://www.ddj.com/hpc-high-performance-computing/216402188
--------------

Forenlink:
Weiteres im K10 Thread ab:
http://www.planet3dnow.de/vbulletin/showthread.php?p=3931750#post3931750

-> Kommentare
 
Zurück
Oben Unten