Hallo, mein GCC denkt nicht daran MMX zu optimieren. Selbstverständlich hab ich -mmmx aktiviert. Als 64Bit Datentyp verwende ich unsigned long long. Das scheint er aber nicht zu kapieren, dass er da optimieren soll. Muss man einen anderen Datentyp dafür verwenden? Mfg Gast
@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
> Please submit a full bug report,
Dann tu das doch. Allerdings solltest du u. U. zuvor nochmal gucken,
ob das in der aktuellen Compilerversion (also wenigstens 4.1.x)
auch noch so auftritt.
@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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.