Umfrage: Befehlssatz-Erweiterungen

Treue Seele

Beruf: Weltherrscher

17.02.2013, 17:40

Umfrage: Befehlssatz-Erweiterungen

Unterstützte Befehlssätze

Insgesamt 14 Stimmen

29%

[x86] (4)

93%

[x86_64] (13)

71%

MMX (10)

71%

SSE (10)

71%

SSE2 (10)

71%

SSE3 (10)

71%

SSSE3 (10)

64%

SSE4.1 (9)

64%

SSE4.2 (9)

43%

AVX (6)

AVX2

FMA

57%

AES (8)

3DNow!

29%

IVT/VT-x (4)

29%

EM64T (4)

[ITANIUM]

[SPARC]

[POWER PC]

[ARM] (1)

93%

<Windows> (13)

50%

<Linux> (7)

Ave!
Da ich bereits eine ganze Weile lang an dies und jenes programmiere und speziell bei der Spieleprogrammierung gern SSE&Co. nutze, Cross-Platform-Code schreibe, usw., wollte ich mal in Erfahrung bringen, wie viele Leute eigentlich welche Befehlssätze unterstützen, bzw. welche Prozessoren nutzen. Zweck ist, eine Übersicht für Programmierer ähnlicher Neigungen zu schaffen, für welche Erweiterungen und Architekturen es sich lohnt, spezialisierten Code zu schreiben. Die Regeln für die Abstimmung sind einfach:

Stimmen können geändert werden (um neu erworbene Hardware des Wählers zu berücksichtigen).
In [eckigen Klammern] stehen Prozessor-Architekturen (die Meisten dürften x86, bzw. x86_64 bei 64bit-Betrieb haben).
Wenn ihr ein 64bit- oder 32bit-System auf x86_64 laufen habt, so wählt [x86_64]. Es zählt nicht als [x86]!
Es wird nicht nach Pentium, Core i, AMD/Intel, usw. unterschieden.
Die übrigen Einträge sind Befehlssatz-Erweiterungen, die die Prozessoren unterstützen.
Wählt alle Prozessor-Architekturen, die ihr besitzt und auch regelmäßig für private Zwecke nutzt (also kein SPARC-basierter Superrechner an der Uni ;3 ).
Da ich kaum Erweiterungen über x86 und x86_64 hinaus kenne, wäre es freundlich, würdet ihr die Erweiterungen eurer ggf. anderen Prozessoren nennen.
Playstation 3 und andere Konsolen wie Handhelds zählen nicht mit.
In <Spitzklammern> stehen die wahrscheinlich gängigsten Betriebssysteme. Setzt hier einen Haken bei allen Systemen, die ihr regelmäßig privat nutzt.
Tablets und ähnliche Geräte, auf denen ihr arbeitet und/oder Spiele spielt zählen mit dazu.

Solltet ihr nicht um eure Erweiterungen für x86 und x86_64 wissen, oder wollt ihr euch ganz sicher sein, könnt ihr sie mit dem Intel Intrinsics Guide herausfinden, indem ihr einen Haken bei "Supported" setzt, oder indem ihr CPU-Z startet und im Tab "CPU" ein Auge auf die Zeile "Instructions" wirft.

So, das war's eigentlich schon. Bin mal gespannt, wie viele hier so ankreuzen.
Gruß und Segen,
Evrey

	C-/C++-Quelltext
1 2 3 4	int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main

(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Evrey« (20.02.2013, 22:35)

Zum Seitenanfang

Supermoderator

Wohnort: Graz

17.02.2013, 18:19

SSE und SSE2 kannst du heutzutage wohl praktisch als gegeben voraussetzen (auf x64 CPUs sowieso). Was dich auf jeden Fall interessieren dürfte: http://store.steampowered.com/hwsurvey

Zum Seitenanfang

Treue Seele

Beruf: Weltherrscher

17.02.2013, 22:14

Gibt auch keine x86_64 ohne SSE und SSE2, glaub ich, und gar ein EEE PC hat solch einen drin, wohl wahr. Für MMX dürfte dies auch gelten, denk ich. Die Umfrage ist durchaus interessant! Dir sei gedankt. °^°

	C-/C++-Quelltext
1 2 3 4	int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main

(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Zum Seitenanfang

Supermoderator

Wohnort: Graz

17.02.2013, 22:17

Zitat von »Evrey«

Gibt auch keine x86_64 ohne SSE und SSE2, glaub ich [...]

Korrekt, darum verwenden Compiler unter x64 z.B. SSE auch per Default...

Zitat von »Evrey«

Für MMX dürfte dies auch gelten, denk ich.

Ja, aber MMX ist heutzutage imo sowieso uninteressant...

Zum Seitenanfang

Treue Seele

Beruf: Weltherrscher

17.02.2013, 22:25

MMX könnte man höchstens noch da brauchen, wo man rohe Texturen/Pixel-Arrays additiv/subtraktiv mischen und so eine neue Textur erhalten möchte.
Edit:
Gut, das kann SSE auch... ;< MMX ist somit tatsächlich kaum mehr mit einer Existenzberechtigung versehen.

Da fällt mir ein, dass MSC Flags für SSE und SSE2 bei 'nem 32bit-Build setzen kann, nicht aber für Weiteres. Wie macht MSC das für z.B. AVX? Schaut es nur nach, ob ich entsprechende Intrinsics oder Assembly verwende? Arbeite eher mit GCC und Clang.
Edit:
Die Frage zielt hierbei auf Mechanismen wie automatische Vektorisierung ab.

	C-/C++-Quelltext
1 2 3 4	int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main

(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Evrey« (17.02.2013, 22:54)

Zum Seitenanfang

Supermoderator

Wohnort: Graz

17.02.2013, 22:56

Zitat von »Evrey«

MMX könnte man höchstens noch da brauchen, wo man rohe Texturen/Pixel-Arrays additiv/subtraktiv mischen und so eine neue Textur erhalten möchte.

Auch da bezweifle ich, dass man davon was hat. Auch wenn ich mir vermutlich mehr oder weniger komplizierte Szenarien konstruieren könnte, wo einige konkrete CPUs vielleicht tatsächlich ein bisschen was davon haben, überwiegen wohl die Nachteile wie z.B. dass MMX sich die Register mit der FPU teilt und auch nur die halbe Registerbreite von SSE bietet.

Zitat von »Evrey«

Da fällt mir ein, dass MSC Flags für SSE und SSE2 bei 'nem 32bit-Build setzen kann, nicht aber für Weiteres. Wie macht MSC das für z.B. AVX? Schaut es nur nach, ob ich entsprechende Intrinsics oder Assembly verwende? Arbeite eher mit GCC und Clang.

Die aktuelle Version von MSVC hat Flags für SSE, SSE2 und AVX, sowie einen Auto Vectorizer und einen Auto Parallelizer. Diese Flags steuern die Codegenerierung durch den Compiler, Intrinsics sind davon völlig unabhängig; inline Assembly wird nur für 32 Bit x86 unterstützt.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »dot« (17.02.2013, 23:16)

Zum Seitenanfang

Delop

Alter Hase

Beiträge: 610

18.02.2013, 17:36

In der Umfrage fehlen noch EM64T und VT-x.

Zum Seitenanfang

Treue Seele

Beruf: Weltherrscher

18.02.2013, 20:13

Gut, da gäbe es noch Zeugs wie 3DNow!, aber ich bin mir grad' nicht sicher, in wie fern IVT einem Spieleprogrammierer nutzen kann. Auch für Sprachdesigner fällt mir spontan kein Nutzen ein. IA-64 wäre durchaus noch praktisch. Ist bloß so 'ne Sache bei AMD-Nutzern, wenn ich mich recht entsinne. Ich trage die drei mal ein.

Zitat

inline Assembly wird nur für 32 Bit x86 unterstützt.

Ist mir bekannt, wenn gleich ich die Gründe nicht kenne. Für die Info sei gedankt. °^°

	C-/C++-Quelltext
1 2 3 4	int main(int _argc, char** _argv) noexcept { asm volatile("lock cmpxchg8b %eax"); return 0; } // ::main

(Dieses kleine Biest vermochte einst x86-Prozessoren lahm zu legen.)

=> Und er blogt unter Hackish.Codes D:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Evrey« (18.02.2013, 20:19)

Zum Seitenanfang

Supermoderator

Wohnort: Graz

18.02.2013, 20:52

Zitat von »Evrey«

Gut, da gäbe es noch Zeugs wie 3DNow!, aber ich bin mir grad' nicht sicher, in wie fern IVT einem Spieleprogrammierer nutzen kann. Auch für Sprachdesigner fällt mir spontan kein Nutzen ein. IA-64 wäre durchaus noch praktisch. Ist bloß so 'ne Sache bei AMD-Nutzern, wenn ich mich recht entsinne.

3DNow! ist vergleichbar mit MMX, EMT64 ist bei Intel das was AMD64 ist (es gibt im Detail afaik minimale Unterschiede), also die 64-Bit Erweiterung für x86 (aka IA-32), der offizielle Name ist Intel 64, nicht zu verwechseln mit IA-64, was eine völlig andere Architektur (Itanium) ist.

Zitat von »Evrey«

Zitat

inline Assembly wird nur für 32 Bit x86 unterstützt.

Ist mir bekannt, wenn gleich ich die Gründe nicht kenne. Für die Info sei gedankt. °^°

Ich weiß auch nicht, was genau der Grund dafür ist, aber ich vermute mal, dass der Aufwand es zu supporten im Vergleich zum Nutzen als für zu groß befunden wurde. Den überwiegenden Teil der poteniellen Anwendungsfälle für Inline Assembler hat man ja mittlerweile mit Intrinsics abgedeckt...