GCC und MMX-Optimierung

Was hat der von dir verwendete 64bit-Datentyp mit MMX zu tun?

@Simon:
Die Links sind ja alle lila bei mir ... hmm ... ich glaub weil ich da 
schon überall war. Trotzdem danke für den dezenten Hinweis google zu 
verwenden.

@Rolf:
Er ist 64Bit. Ich dachte der GCC sollte so klug sein das zu erkennen.

Immerhin bin ich es als Mensch ja auch, dass ich weiß wie ich per Hand 
MMX optimiere wenn ich ein unsigned long long vor mir habe.

Aber du scheinst ja schon zu wissen was man für einen Datentyp verwenden 
muss. Ein kleiner Hinweis würde mir schon reichen.

Mfg
Gast

> Immerhin bin ich es als Mensch ja auch, dass ich weiß wie ich per Hand
> MMX optimiere wenn ich ein unsigned long long vor mir habe.

Ja? Wie denn? Die MMX bietet keine 64bit-Operationen an. Es werden 
vielmehr mehrere kleinere Operationen (2 mit je 32 bit, 4 mit je 16 bit 
oder 8 mit je 8 bit) parallel ausgeführt.

> Aber du scheinst ja schon zu wissen was man für einen Datentyp
> verwenden muss. Ein kleiner Hinweis würde mir schon reichen.

Alle Integers, die kleiner sind als 64 bit und als Array vorliegen, 
würde ich schätzen.
Du kannst die MMX-Befehle im GCC auch explizit nutzen. Siehe:
http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/X86-Built_002din-Functions.html#X86-Built_002din-Functions

>> Immerhin bin ich es als Mensch ja auch, dass ich weiß wie ich per Hand
>> MMX optimiere wenn ich ein unsigned long long vor mir habe.

> Ja? Wie denn? Die MMX bietet keine 64bit-Operationen an. Es werden
> vielmehr mehrere kleinere Operationen (2 mit je 32 bit, 4 mit je 16 bit
> oder 8 mit je 8 bit) parallel ausgeführt.

Offenbar hast du noch nicht besonders viel mit MMX gemacht.

Es gibt unter anderem pand, por, pxor, psllq, psrlq usw, und das sind 
sehr wohl 64Bit Operationen.

Aber zumindest hat mich dein Link auf die richtige Spur geführt:
> di __builtin_ia32_pand (di, di)

"di" ist wohl der Datentyp nachdem ich gesucht habe. Die Frage ist halt, 
ob GCC dann auch wirklich MMX Optimierungen verwendet oder ob da nur ein 
typedef unsigned long long dahintersteckt. Aber das seh ich ja dann 
gleich ...

Explizit will ich eigentlich die MMX-Befehle nicht verwenden. Ich hatte 
mir schon die Arbeit gemacht und 500 Zeilen Code nach MMX portiert, der 
dann langsamer war, weil der GCC mit -O3 schon echt gut optimiert und 
ich viele unvorhersehbare Speicherzugriffe auf eine Tabelle hatte, die 
nicht in den Cache gepasst hat. Die Speicherzugriffe hat GCC recht gut 
wegoptimiert.

Weil bei mir aber im Großen und Ganzen nur logische 64Bit-Operationen 
(siehe oben) vorkommen hatte ich gehofft der GCC kapiert das und 
verwendet selber MMX.

Wenn Interesse besteht poste ich dann das Ergebnis wenn ich es 
ausprobiert hab.

Mfg
Gast

> bla.cc:230: internal compiler error: in perform_integral_promotions, at 
cp/typeck.c:1448
> Please submit a full bug report,
> with preprocessed source if appropriate.

Hmm ... okay das scheint nicht zu funktionieren.

Man muss explizit dann die MMX-Befehlen verwenden. Dann kann ich aber 
gleich den inline Assembler oder noch besser einen externen mit 
vernünftiger Intel-Syntax verwenden.

Mfg
Gast

@Jörg:
Ich bin da auf einen Bugreport von '2004 gestoßen, der genau das 
Phänomen beschreibt, wenn man einen Vector-Datentyp in ein unsigned long 
long casten versucht.

Ist offenbar nie behoben worden.

Ich glaub daher nicht, dass es einen Sinn hat den Bug aufzuwärmen.

Mfg
Gast