Artikel Neuer Artikel: AMDs SSE5 ist tot - lang lebe AVX

Nero24

Administrator
Teammitglied
Mitglied seit
01.07.2000
Beiträge
24.066
Renomée
10.445
  • BOINC Pentathlon 2019
  • BOINC Pentathlon 2020
  • BOINC Pentathlon 2018
  • BOINC Pentathlon 2021
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: SSE5. 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.

Was ist aus SSE5 geworden? Einer unserer versierten Besucher, Nickname sinnigerweise "Opteron", hat aus dieser Frage einen ausführlichen Artikel formuliert, den wir unseren Lesern nicht vorenthalten wollen:<blockquote><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=362353"><b>Neuer Artikel: AMDs SSE5 ist tot - lang lebe AVX</b></a></blockquote>Viel Vergnügen beim Lesen...
 
Also heisst das jetzt sowas wie AMD wird mit AVX endlich schneller als intel sein?
Ich kenn mich nicht aus, wir werden aber selbst sehn wies wirklich ist :)
 
Also heisst das jetzt sowas wie AMD wird mit AVX endlich schneller als intel sein?
Ich kenn mich nicht aus, wir werden aber selbst sehn wies wirklich ist :)

Nein, heißt es nicht. Das hängt sehr stark von der Implementierung der Befehlssätze ab, und welchen Unterschied die Divergenz der Befehlssätze ausmacht.

Aber schöner Artikel. Hat sich jemand doch einige Arbeit gemacht, das auseinander zu klamüsern und dann noch verständlich aufzuschreiben. *great*
 
Ich denke das Chaos ist Absicht von Intel.

Warum ?

Jetzt kann Intel einfach AMD bei der Codegenerierung für AVX mit dem Intelcompiler ausschliessen da AMD nicht 100% kompatibel ist.
 
Warum kann ich Opteron nicht für diesen Artikel danken? :-[
 
Warum kann ich Opteron nicht für diesen Artikel danken?
Keine Ahnung wieso du das nicht kannst. ;D

Ich zeig dir mal eine von vielen Möglichkeiten.:

Danke Opteron, für diesen Artikel.
Sehr informativ.
 
man kann ihn nicht nur danken, man muss sogar.
und man muss eigentl. einen hals auf intel haben ;)

erste sahne. danke. und auch für unfreaks verständlich.

mfg
 
Danke Opteron, für diesen Artikel.
Sehr informativ.

a026.gif
 
Schöner Artikel!

Trotzdem noch eine Anmerkung zu MMX. Dass der normale Anwender von MMX nicht viel hatte, stimmt so nicht. Was die Publicity betrifft, mag es durchaus richtig sein, dass MMX nicht sonderlich wahr genommen wurde. Das Zugpferd sollte seinerzeit ja POD werden, welches als erstes Spiel MMX unterstützte. Dem Spiel blieb allerdings nur ein bescheidener Erfolg vergönnt.

Für Entwickler hingegen war MMX ein regelrechtes Mekka, da man zum ersten mal SIMD ausgiebig unter x86 nutzen konnte. Ich kann mich noch gut an die Assembler Orgien erinnern, wo Funktionen wie memcpy bis zum Erbrechen optimiert wurden. Sowas beherrschen Compiler heutzutage ja idR intrinsic. Und solche Basisroutinen findet man praktisch in allen Anwendungen, mehr oder weniger ausgeprägt. Der Anwender hat also schon ordentlich davon profitiert, wenn auch für den Laien kaum ersichtlich. Ähnliches gilt für Multimedia Anwendungen, die viel auf Vektor und Matrizen Berechnungen setzen.

Man sollte, rein von der technischen Seite her, auch keinen Bezug zwischen MMX und 3dnow suchen. MMX bietet Instruktionen für Ganzzahlen, während sich 3dnow auf FP konzentriert. Interessanter in dem Zusammenhang ist, wie du schon erwähnt hattest, die MMX und 3dnow Register wurden auf die FPU (x87) Register abgebildet. Man konnte die Instruction Sets ohne spezielle Vorkehrungen also nicht so ohne weiteres mischen.
 
Ich finde AMDs Ansatz sehr lobenswert. Sie versuchen weiterhin die Kompatibilität zu halten und nehmen gleichzeitig ihre eigenen Verbesserungen noch mit ins Boot. Man kann nur hoffen, dass dies auch honoriert, sprich unterstützt wird.
 
Die sollten sich wirklich an einen Tisch setzen und den OpCoderaum nicht weiter mit doppelten Auslegungen verschmutzen.
 
Ich hatte POD original und fands Klasse, dass da was mit MMX drin war... hm ka^^

zum Chaos bei den Befehlssätzen: raff isch net (in den Worten vom blöden Ryker)
 
Warum kann ich Opteron nicht für diesen Artikel danken?
ja, hätt ich auch gerne getan, insbesondere wg. der vielen Mühe, gepaart mit geballtem Fachwissen
Dann eben so: ***** Danke;);D*****
 
Schöner Artikel. Danke!

Ich werde irgendwie zwanghaft bei Begriffen wie 'FMA' und XOP an klassisches, nein altertümliches CISC erinnert. Schleichend fährt mir eine kalte Schauder die Wirbelsäule hinauf, wenn ich daran denke, wie Intel demnächst AVX als __die__ Erfindung präsentieren wird. Ic hwerde zwangsläufig an PPC und Altivec und diverse bereits ausgestorbene 64Bit RISC Architekturen erinnert, bei denen ich nicht nur 16 oder gar 32 universell einseztbare Register zur Verfügung hatte, sondern auch 3-Wege-Operanden in den Rechenwerken. Und weiter erinnere ich mich an das Jahr 1995, als ein großes Softwareunternehmen 'Fenster'-95 vorstellte und den 'Papierkorb' auf der Arbeitsoberfläche mit Sektkorkengeknalle als Novum feierte - geflissentlich mißachtend, daß die beapfelte Konkurrenz mit Ende der 70iger Jahre dieses 'Konzept' zur Anwendung brachte.

Was einen schnelleren 'Bulldozer' anbelangt: vor einigen jahren meine ich in der c't einen Vergleich gelesen zu haben in dem deutlich wurde, daß AMDs SSE-Implementation bei gleichem Takt genauso schnell wie das Intelsche Original war und Intel Dank höherer Taktfrequenzen in der SSE-Disziplin demgemäß schneller war. AMD konnte das durch sehr viel geschicktere, andere Implementationen bei weitem kompensieren, aber wäre es nicht denkbar, daß bei AMD letztlich aufgrund der Adaption des AVX eine ähnliche, taktgebundene Situation entsteht? Intel schafft es immerhin mit SMT die CPU-Kerne etwas effizienter auszulasten, es bleibt also abzuwarten, ob AVX-gestützte CPUs gleich mit 2- oder 4-fach SMT erscheinen werden oder ob Intel wie bei der Einführung des C2D ersteinmal die neue Technologie 'sezten' läßt, bevor neues implementiert wird. Es wird Zeit, daß auch AMD SMT in seine Kerne packt, am besten gleich 4-fach - würde sich ja bei zweifach vorhandener ALU per Kern anbieten?
 
Zuletzt bearbeitet:
Ich werde irgendwie zwanghaft bei Begriffen wie 'FMA' und XOP an klassisches, nein altertümliches CISC erinnert. Schleichend fährt mir eine kalte Schauder die Wirbelsäule hinauf, wenn ich daran denke, wie Intel demnächst AVX als __die__ Erfindung präsentieren wird. Ic hwerde zwangsläufig an PPC und Altivec und diverse bereits ausgestorbene 64Bit RISC Architekturen erinnert, bei denen ich nicht nur 16 oder gar 32 universell einseztbare Register zur Verfügung hatte, sondern auch 3-Wege-Operanden in den Rechenwerken.

Dafür müssen die die Operanden aber auch jedesmal erst in die Register laden. Hat halt alles seine Vor- und Nachteile. ;)
 
Sehr schöner Artikel! Im Spekulationsthreat hatte ich bei der Diskussion zwischen Opteron und Dresdenboy lange die Übersicht verloren was denn Sache ist. Dickes danke an Opteron fürs zusammenfassen.

Eine Frage hätte ich dann aber noch.
Was genau ist dieses XOP bzw VEX Präfix? Heißen die einfach so ist das irgend ne Abkürzung oder hat es gar irgendwas mit XOR aus meiner Logischer Entwurf Vorlesung zu tun?

Grüße
Cres
 
Eine Frage hätte ich dann aber noch.
Was genau ist dieses XOP bzw VEX Präfix? Heißen die einfach so ist das irgend ne Abkürzung oder hat es gar irgendwas mit XOR aus meiner Logischer Entwurf Vorlesung zu tun?

Stell es dir wie eine Vorwahl vor. Du hast z.B. eine sechsstellige Zahl für die Telefonnummern in einem Ort. Damit du aber nicht nur einen Ort, sondern sehr viele Orte abdecken kannst, unterteilst du mittels Vorwahl. Das heißt, insgesamt hast du vielleicht 11 Zahlen, wovon aber die ersten fünf den Ort angeben.
Ähnlich ist es bei diesem Präfix. Die einzelnen Befehle für den Prozessor werden in Opcodes, das heißt Binärzahlen codiert. Der Prozessor nimmt nun diese Zahlen, dekodiert sie und erfährt so, was er machen muss. Im Opcode ist die Operation und die Operanden festgelegt. Mit dem Präfix lässt sich nun verzweigen.

Die Notwendigkeit dieser Präfixe ist in der CISC-Architektur von x86 zu finden. x86 lässt verschieden lange Opcodes zu. Um diese korrekt zu dekodieren, braucht es ein paar Kunstgriffe, eben diese Präfixe. Ich nehme mal ein fiktives Beispiel, da ich die realen Opcodes jetzt nicht im Kopf habe:
Nehmen wir an, wir habe zwei Byte und vier Byte lange Opcodes. Zu ersteren gehören 00-ff (hexadezimal geschrieben), zu letzteren 0000-ffff. Das gibt natürlich Überschneidungen. Um das zu trennen, sagt man schlicht, alle Opcodes, die mit 01 anfangen, sind vier Bytes, der Rest ist zwei Bytes.

Im Detail ist das noch etwas komplizierter, weil die Opcodes sich aus verschiedenen Teilen zusammen setzen. Ich habe hier sehr abgekürzt. Wenn es interessiert, kann ich auch nochmal weiter ausholen. Nur soviel, Opcodes haben fakultative und obligatorische Bestandteile, die sich unterschiedlich bedingen. Das ist ein ziemlicher Nachteil der CISC-Architektur, weil es die Dekodierung erschwert.
Das ist auch ein Fall, den ich im Artikel etwas komisch fand. Meines Wissens nach ist der Opcode-Raum gar nicht so beschränkt. Man müsste ihn nur erweitern, was aber kontraproduktiv wäre. Längere Opcodes == längere Dekodierung, was heißt zeitaufwändiger. Möglich wäre es aber.
 
Auch mal von mir danke für den Artikel!

Ich könnte Kotzen um es mal drastisch auszudrücken. (Entschuldigt)

Vorweg noch was: Ich hoffe ich habe das alles mit dem etwas anders richtig verstanden.
Bitte berichtigt mich, wenn ich etwas daneben liege.

Was bringt es denn bitte AMD oder Intel, wenn sie was bauen was nicht ganz gleich zu Programmieren ist und oder gar nicht beim anderen Anbieter gibt und man dann wieder 100 und Pfade bauen muss nur damit alle die schönen Zusätze dann auch richtig nutzen können?
Es ist ja gut, wenn der Compiler das alles kann und man es einfach ohne viel drumherum ansprechen kann, aber so was bläht mal wieder die Programme übermäßig auf. Auch ist nicht gesagt, dass der Compiler das Optimal anspricht oder besser den Code dann am Ende so baut, dass es auf jeden der beiden CPUs der Hersteller optimal läuft.
Auch muss man eine Erkennungsroutine mit einbauen die Sagt was das ist und was man machen kann mit der CPU und diese muss wieder etwas größer/umfangreicher werden.

Daraus resultiert viel Mehraufwand für die Programmiere auch wenn ein Teil der Compiler macht, aber Optimal compiliert wird es dann sicher wieder nur für einen der beiden Hersteller, wenn man die DLLs mit den Besonderheiten nicht extra mit einem speziellen Compiler behandelt oder sonst was macht.

Wenn man sich viel Extraaufwand ersparen will und auf die Packung schreibt man braucht min CPU der Klasse XY mit der Funktion so, wird es viel Verwirrung stiften an statt allen zu helfen.
Wie wird das erst wenn CPUGPU unter einem Dach sind.
Ich hoffe der Marktanteil von AMD Steigt auf min 30 % und auf min 10 % + bei den Spielern, weil dann können die Macher der Spiel das bisschen anders bei AMD nicht mehr ignorieren.

Am Ende tun mir die Programmiere für Multiplatformspiele langsam echt leit.
Nun haben nicht nur 2 ähnliche PC Plattformen die man etwas getrennt betrachten muss, sondern noch 2 - 3 Konsolen die man extra betrachten mus, wenn man die Sachen dafür umsetzen will. Die Konsolen alleine unterscheiden sich vom Aufbau der CPUs und GPUs teilweise erheblich, auch wenn der CPU Kern bei allen 3 Konsolen ein PowePC ist.

Mal davon ab: Woher weiß ich ob meine AMD CPU auch gut ausgenutzt wird oder ob nur mal wieder für Intel optimiert wurde und die vielen schönen Dinge die meine CPU kann nicht genutzt werden?
 
Zuletzt bearbeitet:
Ich könnte Kotzen um es mal drastisch auszudrücken. (Entschuldigt)

Vorweg noch was: Ich hoffe ich habe das alles mit dem etwas anders richtig verstanden.
Bitte berichtigt mich, wenn ich etwas daneben liege.

Was bringt es denn bitte AMD oder Intel, wenn sie was bauen was nicht ganz gleich zu Programmieren ist und oder gar nicht beim anderen Anbieter gibt und man dann wieder 100 und Pfade bauen muss nur damit alle die schönen Zusätze dann auch richtig nutzen können?
Es ist ja gut, wenn der Compiler das alles kann und man es einfach ohne viel drumherum ansprechen kann, aber so was bläht mal wieder die Programme übermäßig auf. Auch ist nicht gesagt, dass der Compiler das Optimal anspricht oder besser den Code dann am Ende so baut, dass es auf jeden der beiden CPUs der Hersteller optimal läuft.
Auch muss man eine Erkennungsroutine mit einbauen die Sagt was das ist und was man machen kann mit der CPU und diese muss wieder etwas größer/umfangreicher werden.

Daraus resultiert viel Mehraufwand für die Programmiere auch wenn ein Teil der Compiler macht, aber Optimal compiliert wird es dann sicher wieder nur für einen der beiden Hersteller, wenn man die DLLs mit den Besonderheiten nicht extra mit einem speziellen Compiler behandelt oder sonst was macht.

Wenn man sich viel Extraaufwand ersparen will und auf die Packung schreibt man braucht min CPU der Klasse XY mit der Funktion so, wird es viel Verwirrung stiften an statt allen zu helfen.
Wie wird das erst wenn CPUGPU unter einem Dach sind.
Ich hoffe der Marktanteil von AMD Steigt auf min 30 % und auf min 10 % + bei den Spielern, weil dann können die Macher der Spiel das bisschen anders bei AMD nicht mehr ignorieren.

Am Ende tun mir die Programmiere für Multiplatformspiele langsam echt leit.
Nun haben nicht nur 2 ähnliche PC Plattformen die man etwas getrennt betrachten muss, sondern noch 2 - 3 Konsolen die man extra betrachten mus, wenn man die Sachen dafür umsetzen will. Die Konsolen alleine unterscheiden sich vom Aufbau der CPUs und GPUs teilweise erheblich, auch wenn der CPU Kern bei allen 3 Konsolen ein PowePC ist.
Ich kann dich beruhigen, ein Großteil der Arbeit ist unabhängig von diesen Grabenkämpfen. Ganz so dreckig geht es den armen Programmieren also nicht mehr. ;)

Mal davon ab: Woher weiß ich ob meine AMD CPU auch gut ausgenutzt wird oder ob nur mal wieder für Intel optimiert wurde und die vielen schönen Dinge die meine CPU kann nicht genutzt werden?
Letztendlich nur, in dem du das entsprechende Programm disassemblierst und nach den Befehlen suchst. Das gibt dir zumindest ein paar Hinweise.
 
@PuckPoltergeist
Danke.
Das heißt ich muss mich auf die Aussagen der Hersteller verlassen. MM nicht erfreulich.
 
@PuckPoltergeist
Danke.
Das heißt ich muss mich auf die Aussagen der Hersteller verlassen. MM nicht erfreulich.

Im Prinzip ja. Du kannst zwar selber debuggen und tracen, aber das lohnt eigentlich nicht. Im Endeffekt ist es auch egal, ob eine Software deine Hardware bis zum Ende ausreizt. Wenn du nichts besseres findest, musst du eh nehmen, was du hast. ;D
 
Man sollte, rein von der technischen Seite her, auch keinen Bezug zwischen MMX und 3dnow suchen. MMX bietet Instruktionen für Ganzzahlen, während sich 3dnow auf FP konzentriert. Interessanter in dem Zusammenhang ist, wie du schon erwähnt hattest, die MMX und 3dnow Register wurden auf die FPU (x87) Register abgebildet. Man konnte die Instruction Sets ohne spezielle Vorkehrungen also nicht so ohne weiteres mischen.
Also 3DNow! und MMX mußte man sogar mischen, anders ging es gar nicht (da 3DNow! nicht eigenständig sondern auf MMX-Befehle angewiesen war, z.B. was Datenbewegungen anging [MOVQ], oder dem Aufräumen nach einer 3DNow! Befehlssequenz [EMMS bzw. FEMMS, {Fast} Empty MMx State, der Name ist schon bezeichnend ;)], nur um mal zwei Beispiele zu nennen). Insofern ist da sehr wohl ein starker Bezug da.
Und durch den Mix mit FPU-Code (x87) konnte man wirklich ganz interessante Möglichkeiten eröffnen *lol* Aber das war zugegebenermaßen eher speziell.
 
Also erstmal danke für die Info, ist sehr interessant.

Letzteres wird erst mit Intels 32nm CPUs erstmals auf dem Markt erscheinen.
Stimmt nicht, VIA hat schon, zumindest als FFU. Außerhalb der x86-Welt sowieso. Intel und AMD sind so ziemlich die letzten.
 
Zurück
Oben Unten