Ende der "SSEerities" absehbar ?

[Opteron]

Hallo und vielen Dank fürs Kommen,

mich würde mal interessieren, ob langsam ein Ende der Fahnenstange bei den SSE Befehlen abzusehen ist.

x86 CPUs sind ja CISC CPUs (zwar, mit RISC Kern aber lassen wir das mal ausenvor).

SSE1, und SSE2 fand ich auch noch ganz toll, aber SSE3 .. und jetzt SSE4, 4.1, 4.2 ... wer braucht sowas ? Natürlich gibts sicherlich Spezialfälle, aber macht es für die paar Vorteile Sinn den Befehlssatz immer weiter aufzubohren ?

SSE 4.2 das mit Nehalem kommt, soll z.B. String Befehle bekommen ... da würden mich ein paar Anwendungsbeispiele schon interessieren, es wird doch hoffentlich mehr sein als die Suche und Ersetze Funktion bei Word

So oder so, langsam habe ich das Gefühl, dass man die x64 CPUs VCISC ("V" für very) nennen sollte

Vielen Dank

Alex

 

[Frank Kuypers]

Hallo Opteron,

ich gebe Dir Recht, daß es immer mehr Befehle innerhalb der Architektur gibt und es wahrscheinlich immer weiter darauf hinausläuft, daß nur noch "Spezialfälle" abgedeckt werden.

Nun ist es aber so, daß sich auch die Benutzungsmodelle der Software, die auf diesen Architekturen ausgeführt werden, immer weiter entwickeln.

Wer hätte zu SSE2 Zeiten gedacht, daß wir alle (einige, manche) Videos in HD Auflösung bearbeiten, transkodieren usw. Wenn ich mir die letzten Benchmarks von Divx auf HD Boost (SSE4.1) anschaue, scheint es schon so zu sein, daß diese neuen Befehle durchaus ihre Daseinsberechtigung haben. Vielleicht nur in dem Spezialfall Videoencoding, aber du mußt zugeben, daß dies doch mittlerweile ein durchaus verbreitetes Benutzungsmodell ist.

Außerdem heißt es ja nicht, daß wenn wir neue SSE Instruktionen einführen, die alten nicht verbessern. Wir haben zum Beispiel in der Penryn Architektur den FP durchsatz erheblich verbessert, ohne das das irgendwie nur auf neue Befehle zurückzuführen war.

Ich denke beides hat seine Berechtigung.

Gruß

Frank

 

[Martin Strobel]

ich möchte die Frage etwas erweitern. Was ist notwendig um in der Zukunft weiter Leistungssteigerungen von Prozessoren zu erwarten?

Das man mit dem Anheben der Taktfrequez an Grenzen gestossen ist haben wir in den letzten Jahren gesehen. Eine 20 Prozent schnellere Taktfrequenz führt zu etwa 13 Prozent mehr Leistung treibt aber den Stromverbrauch um ungefähr 70 Prozent in de Höhe. Die Multicore-Technik verspricht effizienter zu sein. Aber auch hier ist es falsch zu behaupten das acht Kerne dopplet so schnell sind wie vier. Am Ende entscheiden bei den x86-Mikroprozessoren mehr als nur Taktfrequenz und mehr Kerne über deren Leistung. Wir glauben das man für zukünftige, noch schnellere Prozessoren neue Befehlssätze und Verbeserungen am Cache benötigt und das das man das Hardware-Thread-Scheduling weiter optimieren muss.

Wird es also neue Befehlssätze geben ja! Wie gesagt haben wir mit Penryn bereits 47 neuen SSE Instruktionen eingeführt. Von diesen sogenannten SSE4 Befehlssätzen profitiert zum Beispiel divx. Hier läuft die Videoumwandlung jetzt schneller ab da das, was bisher mit vielen einzelnen Befehlen realisiert werden musste, kompakt mit Hilfe eines einzigen durchgeführt wird. Für die nächste CPU Genereation arbeiten unsere Entwickler an neuen Befehlssätzen. Mit Nehalem kommen sieben weiter SSE Instruktionen (SSE4.2). Hierzu gehören POPCNT und CRC32. Mit CRC32 lässt sich beispielsweise die zyklische Redundanzprüfung, wichtig bei der Fehlererkennunung bei der Datenübertragung, beschleunigen. Zudem noch Instruktionen die XML-Workloads beschleunigen. Hierin sehen wir die Möglickeit diese Anwendungen um das 3-fache zu beschleunigen. Wenn wir dann so weit sind um die Nehalem Architektur in 32nm zu fertigen werden wir auch hier wieder Verbesserungen an der Architektur durchführen. Mit Westmere dem ersten 32nm Prozessor werden wir spezielle Instruktionen einführen die die Sicherheit erhöhen. Mit den AES New Instruction werden wir den AES als Verschlüsselungsalgorithmus und damit die Ver- und Entschlüsselung deutlich beschleunigen. Details hierzu werden in Zukunft folgen.

 

[Crunch3r]

...Wir haben zum Beispiel in der Penryn Architektur den FP durchsatz erheblich verbessert, ohne das das irgendwie nur auf neue Befehle zurückzuführen war.

Supershuffle sei dank

Wie sieht es den mit lizensabkommen für SSE5 aus ?

 

[Nightshift]

Danke für die Ausführung, und ich schließe mich Crunch3rs Frage an und erweitere diese noch etwas:

Wäre es nicht vielleicht in Zukunft denkbar, dass die beiden großen CPU-Hersteller in diesem Punkt ihre Differenzen begraben um ein einheitlicheres System erschaffen zu können?

Natürlich ist mir auch klar, dass man als Hersteller die schnellste CPU haben möchte und den Vorteil auf seiner Seite.
Und sicherlich bekommt unterschiedlichen Architekturen auch nicht jeder Befehl gleich gut.
Allerdings gibt es so doch eine sehr starke Fragmentierung an unterschiedlichen Befehlssätzen und ich kann mir sehr gut vorstellen, dass das in der Softwareentwicklung auch ein Stolperstein sein kann und die Verbreitung der Befehle veringert.

Insofern wäre es für den Kunden wünschenswert hier ein einheitlicheres System vorzufinden, und für Entwickler sicher auch.
Das richtet sich natürlich auch an die "grüne" Adresse, falls hier jemand von dort mitlesen sollte ...

 

[Opteron]

Wie sieht es den mit lizensabkommen für SSE5 aus ?

So:
http://www.chiplist.com/Intel_Will_Not_Support_SSE5_Instruction_Extensions/tree3f-article--80-/

@Martin Strobel:
Ahh ok, die Stringbefehle für XML, ok leuchtet ein, wobei mir im Hinterkopf da wieder ein paar Sachen zur XML Komprimierung einfallen .. naja egal ^^

Danke für die (gleich doppelte ^^) Antwort

Zur Verschlüsselung:
Könnte man eventuell da gleich auf die VIA Befehle zurückgreifen ? Dort gibts ja schon seit Jahren eine x86 Crypto Engine, und eventuell bestehen ja Patentaustauschabkommen. Aber irgendwie hab ich das Gefühl, dass Intel das nicht machen wird

ciao

Alex

 

[Lykos]

Da ich gerade über die geplante Beschleunigung des AES Verschlüsselungsalgorithmus und des divx Codecs gelesen habe, würde mich interessieren, ob diese Beschleunigungen auch Algorithmen wie Blowfish, ogg Theora, dirac und anderen open source Algorithmen zugute kommen oder eine generelle hardwarebeschleunigung derartiger Algorithmen geplant ist.

 

[TiKu]

Zudem noch Instruktionen die XML-Workloads beschleunigen.

Ich kenne mich mit den Befehlssätzen nicht so gut aus, deshalb verzeihe man mir wenn meine Frage mglw. Blödsinn ist.
Steht dieses XML für Extensible Markup Language? Also sind spezielle Befehle geplant, die XML-Parser beschleunigen können?

 

[Opteron]

Steht dieses XML für Extensible Markup Language? Also sind spezielle Befehle geplant, die XML-Parser beschleunigen können?

Jo, hat er ja gesagt .. die speziellen Befehle sind die SSE 4.2 das sind string Befehle, stringcompare etc. pp. Da XML (noch keine) Kompression hat, bzw. die nie einer benützt, werden da strings im Klartext hin und her geschoben, d.h. strng Befehle im Befehlssatz machen sich da schon gut.

Fürn Heimanwender ist das aber natürlich nichts ...

ciao

Alex

 

[TiKu]

Das nenne ich mal interessante neue Befehle. *g*
Mir und ein paar anderen erschien das doch irgendwo zu abwegig, deshalb die Nachfrage.