AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

Jetzt ist Ihre Meinung zu AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell gefragt.

Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.

Zurück zum Artikel: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

Hallo.

Bitte die Sache mit den Genauigkeiten vielleicht noch einmal nachschlagen.

* SSE ist nicht genauer als MMX oder die x87 FPU. Siehe Arbeitsweise.
* SSE2 kann mit höherer Präzision rechnen als SSE, aber nicht als x87, siehe Arbeitsweise.
* MMX ist kein Genauigkeitsrückschritt ggü. x87, siehe Arbeitsweise.
* AVX(2) rechnet per se nicht genauer als SSE2, schon gar nicht mit 256Bit

Vielleicht wurden hier Präzision eines Datenformats (float, double, double extended), mit der Registerbreite verwechselt.

* Man sollte vielleicht auch erwähnen, warum und dass MMX in aktuellen Microsoft 64Bit Umgebungen nicht mehr vorhanden ist. Es ist damit genau so gestorben wie 3DNow!

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

- stimmt wohl
- ergibt sich
- x87 erlaubt Rechensequenzen mit intern 80 Bit Genauigkeit, MMX erzwingt dagegen nach jedem Rechenschritt eine Rundung aufs 64 Bit Formt. Entweder verstehe ich etwas falsch, oder die Möglichkeiten von MMX waren ein Rückschritt gegenüber der Möglichkeiten einer x87-FPU
- nunja: Bei FMA Nutzung steigt die Präzision schon, wenn auch nicht in der Ausgabe. (wieso führt eigentlich niemand 128/256 Bit Datenformate ein? Braucht man vielleicht nicht wirklich, zugegeben. Aber der Implementierungsaufwand sollte, ausgehend von einem System, dass 4 64 Bit Werte am Stück verarbeitet, minimal sein)
- Was Microsoft so alles aus den 64 Bit Systemen gekickt hat, würde eigene (Hass-)artikel füllen


P.S.:
Das nenn ich mal ein hochwertiges erstes Post

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

Wenn wir schon dabei sind: MMX arbeitet mit Integer-Zahlen in den Float-Registern, nicht mit Kommazahlen. Zum einen kam das daher, dass die damals angedachten Multimedia-Anwendungen eher mit Ganzzahlen arbeiteten, zum anderen musste das OS nicht für den Betrieb von MMX angepasst werden (beim Kontextwechsel muss der Registerinhalt gespeichert und wiederhergestellt werden und die Float-Register gab es damals ja schon). Richtig lustig wurde es eigentlich immer dann, wenn man sowohl mit Float- als auch mit MMX-Befehlen gearbeitet hat

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

Für Bulldozer-Besitzer könnte die Entscheidung Intels dagegen bedeuten, dass die FMA4-Fähigkeit ihrer SIMD-Einheiten nie genutzt werden wird, da Softwareentwickler eine flächendeckende FMA3-Unterstützung erwarten können, während eine FMA4-Fixierung nur das obere Ende von AMDs letztjährigen Neuvorstellungen betrifft.

Zum Vergrößern anklicken....

Das dachte ich mir schon seit Bulldozer mit FMA4 beworben wurde und Intel sich auf FMA3 festlegte.
Aber an sich muss man sich da nicht wundern. Schließlich geht die Entwicklung mit dem Markt und der Verbreitung und da war FMA4 von Beginn an die schlechtere Wahl.

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

* Sorry, das mit MMX war so gemeint, dass dessen Datentypen nur für Integerberechnungen (wenn auch auf den x87 Registern gemapped) ausgelegt waren. Die Genauigkeit von Integer und Gleitkomma sollte man nicht direkt so gleich behandeln. Im Artikel schien es fast so, als wäre MMX ein Nachfolger von x87.

PS: Ich weiss noch, welchen Aufschrei es damals gab, als der Community so langsam klar wurde, dass MMX kein Gleitkomma kann und die x87 Register/FUs blockiert.

* Selbst Quadwords (64Bit) sind relativ selten. Ich bin nicht sicher, ob es genug Anwendungsmöglichkeiten für (2x)4x64Bit Pakete gibt.
Liegt vielleicht auch an den Anforderungen für die Datenpfade und die Decoder. Wer das wirklich so groß braucht kann auch die paar Takte warten, während die Einzelteile davon berechnet werden.

* Windowx x64 bringt ja nicht nur Schlechtes. Das Abschaffen der x87 FPU im Long Modus von x64 und damit auch das Absägen von 3DNow! und MMX ist eigentlich erfreulich.
Theoretisch könnte man 64Bit Anwendungen / Spiele konsequent auf SIMD auslegen (lassen) und richtig profitieren. Praktisch gesehen bleibt aber trotzdem nicht viel übrig.

ruyven_macaran schrieb:

- stimmt wohl
- ergibt sich
- x87 erlaubt Rechensequenzen mit intern 80 Bit Genauigkeit, MMX erzwingt dagegen nach jedem Rechenschritt eine Rundung aufs 64 Bit Formt. Entweder verstehe ich etwas falsch, oder die Möglichkeiten von MMX waren ein Rückschritt gegenüber der Möglichkeiten einer x87-FPU
- nunja: Bei FMA Nutzung steigt die Präzision schon, wenn auch nicht in der Ausgabe. (wieso führt eigentlich niemand 128/256 Bit Datenformate ein? Braucht man vielleicht nicht wirklich, zugegeben. Aber der Implementierungsaufwand sollte, ausgehend von einem System, dass 4 64 Bit Werte am Stück verarbeitet, minimal sein)
- Was Microsoft so alles aus den 64 Bit Systemen gekickt hat, würde eigene (Hass-)artikel füllen


P.S.:
Das nenn ich mal ein hochwertiges erstes Post

Zum Vergrößern anklicken....

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

BlackBirdSR schrieb:

* Windowx x64 bringt ja nicht nur Schlechtes. Das Abschaffen der x87 FPU im Long Modus von x64 und damit auch das Absägen von 3DNow! und MMX ist eigentlich erfreulich.
Theoretisch könnte man 64Bit Anwendungen / Spiele konsequent auf SIMD auslegen (lassen) und richtig profitieren. Praktisch gesehen bleibt aber trotzdem nicht viel übrig.

Zum Vergrößern anklicken....

Eine Auslagerung wäre erfreulich, ja. Aber ein Verbot der alten Formate (die an leistungsrelevanter Stelle afaik eh nicht mehr genutzt werden) durch das Betriebssystem ist, genauso wie die Abschaffung des 16-Bit Moduses und von DirectSound, einfach eine heftige und technisch unnötige Beschneidung der Abwärtskompatibilität. Und Abwärtskompatibilität ist nunmal DER wichtigste Aspekt von x86.

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

ruyven_macaran schrieb:

Und Abwärtskompatibilität ist nunmal DER wichtigste Aspekt von x86.

Zum Vergrößern anklicken....

Und gleichzeitig DER Bremsklotz.

AW: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell

Aber Kompatibilität bleibt ja weiterhin vorhanden. Wer wirklich mmx nötig hätte, kann seine Software für x86 programmieren. Wer mmx braucht wird kaum zwingend 64bit Umgebungen nötig haben. Diese x86 Software läuft ja weiter auf jeder x64 CPU und dem x64 Windows.