[C++] Visual Studio generiert popcnt-Befehl

[Schrompf]

Moin,

ich habe meine VisualStudio-Projekte konfiguriert, nur SSE2 oder SSE1 zu benutzen. Trotzdem bekomme ich jetzt seit einigen Wochen Crash Reports von verschiedenen Leuten, dass das Spiel mit einer ILLEGAL INSTRUCTION abstürzt. Ich habe jetzt endlich mal MiniDumps für den Absturzfall eingebaut und erblicke nun mit einer Mischung aus Entsetzung und Erleuchtung die illegale Instruktion popcnt. Laut Wikipedia ab SSE4 verfügbar. Die Prozessoren, auf denen es crasht, sind Core2-CPUs, die bis SSE3 können.

Die Frage lautet nun: Weh Teh Eff? Oder genauer: was habe ich an meinen Projektkonfigs falsch konfiguriert, so dass der Compiler eine SSE4-Instruction generiert?

Bin für jeden Hinweis dankbar. Die Zeit drückt heftig.

Bye, Thomas

[Schrompf]

Ok, eventuell bin ich selbst das Problem. Mein Code enthält an der Crashposition die Intrinsic __popcnt(). Ich dachte bisher, dass die Intrinsic die Logik irgendwie emuliert, wenn der spezifizierte Target-Befehlssatz die Instruktion nicht unterstützt. Aber anscheinend lag ich falsch.

[Schrompf]

Abschließend: es gibt wohl keine eingebaute Emulation für Intrinsics, die von der Ziel-Architektur nicht unterstützt werden. Daher habe ich den problematischen Intrinsic hinter einem Präprozessor-Test versteckt und mit den unbezahlbaren Bithacks eine Emulation gebastelt.

Bisher bekannte problematische Instruktion:

- popcnt

Emulation:

Code: Alles auswählen

  /// Ermittelt die Anzahl gesetzter Bits in der gegebenen Zahl
  inline size_t GetBitCount( uint32_t z)
  {
#ifdef NUTZT_ERWEITERTE_BEFEHLE
    return __popcnt( z);
#else
    uint32_t a = z - ((z >> 1) & 0x55555555);
    uint32_t b = (a & 0x33333333) + ((a >> 2) & 0x33333333);
    return ((b + (b >> 4) & 0xF0F0F0F) * 0x1010101) >> 24;
#endif
  }
  /// Ermittelt die Anzahl gesetzter Bits in der gegebenen Zahl
  inline size_t GetBitCount( uint64_t z)
  {
#ifdef NUTZT_ERWEITERTE_BEFEHLE
#  ifdef IS64BIT
    return __popcnt64( z);
#  else
    return __popcnt( uint32_t( z & 0xffffffff)) + __popcnt( uint32_t( z >> 32));
#  endif
#else // NUTZT_ERWEITERTE_BEFEHLE
    uint64_t a = a - ((a >> 1) & 0x5555555555555555);
    uint64_t b = (a & 0x3333333333333333) + ((a >> 2) & 0x3333333333333333);
    uint64_t c = (b + (b >> 4)) & 0x0f0f0f0f0f0f0f0f;
    return (c * 0x0101010101010101) >> 56;
#endif // NUTZT_ERWEITERTE_BEFEHLE
  }
}

[Krishty]

Krasse Scheiße. Tut mir leid, dass dir das passieren musste, aber danke, dass du es hier geschrieben hast. Da wäre ich auch blind reingerannt. Übel übel übel übel :(

[Spiele Programmierer]

Ehrlich gesagt verstehe ich das große (unerwartete) Problem nicht. Zu übersehen das eine Funktion Platform abhänig ist, ist eigentlich nichts im besonderen Maße außergewöhnliches.
Und wie soll der MSVC etwas ersetzen wenn es nichtmal einen "SSE4" Compilerschalter gibt?
Hey, dafür sind es Intrinsic, die sind platformabhänig. Normalerweise würde ich Funktionen > SSE2 auch zur Laufzeit auswählen. Wenn der MSVC das im Hintergrund machen würde, hätte das den Nebeneffekt, das durch die entstandenen Verweigungsoverhead der "Intrinsic" nur knapp doppelt so langsam laufen würde, wie die Bitweise-Implementierung ohne den SSE4 Befehl.

[Krishty]

Ja – Intrinsics sind plattformabhängig. Aber andererseits hat Schrompf mit Setzen des SSE-Schalters sehr genau definiert, was am Befehlssatz erlaubt ist. Eine Warnung, wenn nicht unterstützte Befehle erzwungen werden, wäre da nicht verkehrt.

Und ja – Visual C++ hat keinen /SSE4-Schalter. Das sehe ich aber ganz deutlich als Fehler, schließlich müssen Intrinsics direkt in den Compiler eingebaut werden. Sie haben Funktionalität eingebaut, die via Intrinsic erreichbar ist; aber der GUI-Schalter ist so geblieben wie er war. Das schreit ja geradezu nach Problemen.

Also wie es richtig geht:

• /arch:SSE4 und Konsorten in die GUI einbauen
• dementsprechend _M_IX86_FP auf 10 (oder so – die wievielte Version ist das schon?) setzen
• Intrinsics freischalten
• warnen, wenn ein Intrinsic aufgerufen wird, das von diesem Befehlssatz nicht unterstützt wird

Und was sie gemacht haben:

• Intrinsics freischalten

fick-fack-fantastisch.

P.S.: /arch:AVX haben sie schließlich auch in die GUI gepresst bekommen. Sie haben einfach wieder gespart wo es nur ging.

[Schrompf]

Nuja, ich will ihnen da keinen Vorwurf machen. Ich hatte halt eine falsche Erwartungshaltung. Mich verwunderte halt, dass BitScanForward und BitScanReverse schon seit Anbeginn der Tage (Pentium 1 oder so) drin sind, Popcount aber erst so spät hinzukam. Ich hatte die beiden irgendwie im Kopf zusammengeworfen und bin jetzt relativ grob wachgerüttelt worden, als mir ausgerechnet die Jury eines kleinen Indie-Wettbewerbs das Spiel mit unerklärlichen Crashes um die Ohren gehauen hat. Zum Glück hatte mein Grafiker dann das selbe Problem, so dass ich der Sache auf den Grund gehen konnte.

Bin damit jetzt leider in das nächste Problem getappt: ich kann kein Executable zu einem MiniDump auswählen. Ich krieg den FileOpenDialog zwar angeboten und klick mich bis zur Exe durch, aber der "Open"-Button reagiert nicht. Er ist nicht ausgegraut oder so, sondern reagiert einfach nicht. Doppelklick auf die Exe bewirkt genauso nix. Pff. Für's Disassembly und popcnt hatte es noch gereicht, aber ich hatte schon die Hoffnung, mehr damit anfangen zu können. Und ich bin damit nicht allein.

[Krishty]

Hmmm. Falsches Verb? Geht rechtsklick -> Auswählen?

[Schrompf]

Nope. Es öffnet sich der Standard-Windows-Dateiauswahl-Dialog. Und der lässt sich nicht bestätigen. Kein Doppelklick auf die richtige Datei, keine Verzeichnisauswahl, kein Klick auf "Öffnen". Die Buttons sind anklickbar, tun aber einfach nichts. Man hängt ewig in der Dateiauswahl fest, bis man abbricht.

[Sternmull]

Ähm... man wählt auch nicht wirklich eine "Excutable" zu einem Minidump aus. Statt dessen sagt man dem Debugger wo er die Symbole suchen soll (was normalerweise die zugehörigen Binaries einschließt, denn die liegen üblicherweise daneben). Im WinDbg gibts dafür einen bequemen Eingabedialog. Im VS gibts zumindest die globalen Debug-Einstellungen in denen man die Symbol-Such-Pfade festlegen kann. Weiß grad nicht ob es so was auch noch mal pro Projekt gibt. Im Normalfall nehme ich auch WinDbg zur Analyse von Crashdumps. Der bietet da doch einige Features die ich im VS-integrierten Debugger vermisse. Wobei der von VS natürlich netter ist um ein gerade gebautes Projekt auf dem Entwicklungssystem zu untersuchen.

Kleiner Hinweis am Rande: Wenn man den Microsoft-Symbolserver nicht als Symbolquelle aufgenommen hat, dann kann man Stacktraces die in MS-Modulen enden nicht auf den eigenen Code zurück verfolgen (weil dem Debugger halt die Symbole fehlen um die Stackframes zu verstehen). Allerdings mach ich den MS Symbol-Server nur bei Bearf an, weil sonst bei jeder Debug-Session erneut nach Symbolen gesucht wird... was die Lade-Zeit erheblich verlängern kann.

[Schrompf]

Danke für den Tipp, ich schaue mir mal WinDbg an. Das mit dem MS-Symbol-Server habe ich so auch schon durch: eingetragen, ewige Wartezeiten bei jedem Programmstart erlebt, wieder ausgetragen :-)

[Spiele Programmierer]

/arch:AVX haben sie schließlich auch in die GUI gepresst bekommen.

Das macht auch Sinn. Und zwar kann der Codegenerator AVX anstelle von SSE nutzen. Insbesondere wenn Autovektorisierung ins Spiel kommt. Ich habe außerdem gelesen, das der Interop zwischen AVX & SSE mit einen Overhead verbunden ist.(Hier warnt er sogar) AVX sollte also wenn dann Applikationsweit vom Compiler als auch vom Nutzer eingesetzt werden.
Bei SSE3, SSSE3 SSE4, ... ist das nicht der Fall. Außerdem handelt es sich um Befehle, von denen der Codegenerator des Compilers vermutlich überwiegend sehr wenig bis gar nicht Gebrauch machen kann.
Und wenn man die Befehle zur Laufzeit auswählt, was meiner Meinung nach auch viel mehr Sinn macht(Wer will 10 verschiedene Versionen warten? Welcher Benutzer mag sich zwischen diesen entscheiden müssen bzw. wer kann es überhaupt?), dann hat man bloß eine gigantische Menge an sinnlose Warnungen am Hals die man alle unterdrücken muss. Wenn ich die WinAPI verwende, warnt mich schließlich auch keiner, obwohl ich die Anwendung auch portabel halten will...

[Schrompf]

Ich habe das Gefühl, Du bist hier gerade auf dem falschen Kriegspfad. Wenn man eine SSE4-Instruktion einsetzt und die konfigurierte Ziel-Architektur kein SSE4 kann, dann crasht die Anwendung. Das ist mindestens eine Warnung wert, eher sogar ein Fehler.

Ob der Compiler das neue Instruction Set dann sinnvoll einsetzen kann, ist die andere Frage. Ist alles aber eh hypothetisch, da Microsoft den C++-Teil anscheinend einen langsamen Tod durch Pflegemangel sterben lässt. Ich will immernoch Edit&Continue wieder :(

[Krishty]

/arch:AVX haben sie schließlich auch in die GUI gepresst bekommen.

Das macht auch Sinn. Und zwar kann der Codegenerator AVX anstelle von SSE nutzen.

Ja – du teilst ihm damit mit, dass die Laufzeitumgebung mindestens AVX voraussetzt, und dass das Erzeugen von AVX-Befehlen legitim ist.

Außerdem handelt es sich um Befehle, von denen der Codegenerator des Compilers vermutlich überwiegend sehr wenig bis gar nicht Gebrauch machen kann.

Im Grunde war das auch das Argument gegen SSE2 – „ich rechne kaum mit floats, dann brauche ich es nicht“. Bis der Code Generator dann um CMOV und MOVDQA erweitert wurde und Branching-Last / Kopierlast überall reduziert wurden.
SSE3 bringt schnelle float-zu-int-Konvertierung. Alle zusammen bringen einen Haufen SIMD-Befehle, die der Auto Vectorizer mit Freude einsetzen würde; oder zumindest Blockverschiebungen, die dem Compiler Kopien in weniger Takten ermöglichen. Es spricht nichts dagegen, dass der Code Generator damit fröhlich um sich spritzen kann.

Und wenn man die Befehle zur Laufzeit auswählt, was meiner Meinung nach auch viel mehr Sinn macht(Wer will 10 verschiedene Versionen warten? Welcher Benutzer mag sich zwischen diesen entscheiden müssen bzw. wer kann es überhaupt?), dann hat man bloß eine gigantische Menge an sinnlose Warnungen am Hals die man alle unterdrücken muss. Wenn ich die WinAPI verwende, warnt mich schließlich auch keiner, obwohl ich die Anwendung auch portabel halten will...

Wenn du VC auf WinAPI stellst und anfängst, MFC-Sachen zu benutzen, kriegst du sehr wohl Warnungen. Der „Vertrau mir; ich weiß, was ich tue!“-Modus lautet immernoch #pragma warning(disable. Und wenn du 10 Intrinsic-Versionen mit Laufzeitauswahl haben willst, benutz Intels Compiler, dann musst du sie nicht einmal selber schreiben und musst auch nicht gewarnt werden ;)

[Spiele Programmierer]

SSE3 bringt schnelle float-zu-int-Konvertierung

Das ist doch Teil von SSE2, oder nicht? Zumindest kann ich auf Intels Intrinsic-Seite keine ähnlichen Funktionen in SSE3 finden.
Zum Beispiel "_mm_cvtps_epi32" oder "_mm_cvtpd_epi32" scheint Teil von SSE2 zu sein.
Ich sag ja auch gar nicht, dass SSE3 oder SSSE3 keine guten Funktionen enthält, aber eben im Vergleich zu SSE2 eben sehr wenige, auf die man nicht leicht verzichten kann oder die der Autovektorisierer wahrscheinlich leider eh nie wirklich richtig einsetzen können wird(zb. _mm_shuffle_epi8). Auf tausend mal "#pragma warning disable" die den Code aufblähen und andere Compiler natürlich wieder nicht verstehen, hätte ich eben keine Lust.

[Krishty]

Ups ja; die Konvertierung ist ein FPU-Intrinsic :(

Das mit den anderen Compilern ist Unsinn, weil die Intrinsics eh nur auf VC und Intel funktionieren, und beide unterstützen die warning-Syntax. Zumal ich die Warnung gerechtfertigt finde: Du musst in deinem Quelltext sicherstellen, dass du deine SSE4-Intrinsics nur aufrufst, wenn du vorher die CPUID geprüft hast (und im Fall von AVX auch die Betriebssystemversion), sonst rauscht das Programm beim Benutzer auf undankbarste Art und Weise weg. Und du musst diesen Test testen – ich hatte mal auf das falsche Bit geprüft, und es nicht gemerkt weil ich keine geeignete CPU zur Verfügung hatte um das zu testen; zum Glück hatte ein Mitentwickler einen alten Athlon XP rumstehen.

Das sind gewaltige Risiken; siehe Schrompf – ich für würde lieber Warnungen abschalten als da unwissentlich reinzustolpern. Wenn du weißt, was du tust, schalt die Warnungen ab. Oder, besser noch, lass den /arch:-Schalter ganz weg damit Visual C++ keine Annahmen über die Zielarchitektur trifft und so etwas dir überlässt. So wäre es jedenfalls, wenn es mein Compiler wäre.

[Spiele Programmierer]

Ohne "/arch:" nutzt der MSVC halt auch SSE2 nicht, was eigentlich überall verfügbar sein sollte.
Sowohl Clang als auch der GCC unterstützen übrigens von sich aus SSE und AVX Intrinsics.

[Krishty]

Aber andere als VC, oder? VC & Intel nutzen _mm_XXX(); Clang & GCC nutzen __builtin_XXX() … VC & Intel haben ein struct __m128(i/f); Clang & GCC ein __builtin_vector_schlagmichtot(4) float oder sowas …

[Spiele Programmierer]

Es sind die gleichen. Du solltest da nicht die Compiler spezifischen Erweiterungen (zb. "_BitScanForward", "__builtin_*") mit den von Intel vorgegebenen verwechseln. Es gibt soweit ich weiß, zusätzlich auch noch einen GCC/Clang spezifischen anderen platformunabhänigen-Syntax.

[kimmi]

Danke für den Tipp, ich schaue mir mal WinDbg an. Das mit dem MS-Symbol-Server habe ich so auch schon durch: eingetragen, ewige Wartezeiten bei jedem Programmstart erlebt, wieder ausgetragen :-)

Man kann sich igentlich auch die PDB's runterladen und die zum Debuggen benutzen bzw. einen lokalen Symbol-Servcer betreiben.

Gruß Kimmi

[Krishty]

Hmm. Ich pausiere das Programm mittendrin -- gehe dann in die Optionen -- aktiviere den MS Symbol Server -- Lade alle Symbole -- deaktiviere den Server wieder -- fertig. Dann habe ich bei jedem weiteren Start die PDBs ohne Wartezeit. Falls ich mal auf eine Stelle stoße, wo der Call Stack fehlt, wiederhole ich.

[kimmi]

Wenn du die Symbole händisch einmal nachlädst, ersparst du dir das Nachladen. Dafür bekommst du bei irgendwelchen Updates dann Probleme, weil pdb nicht zur Dll passt. Deine Variante klingt also irgendwie sinniger :).

Kimmi

[Sternmull]

Ich mach das auch seit Jahren so wie Krishty. Sobald einem der Stack fehlt, denkt man von ganz allein dran den Server rein zu nehmen damit der Cache aktualisiert wird. Und wenn dann alles ewig braucht denkt man auch automatisch wieder dran das wieder abzuschalten :) So lässt es sich eigentlich ganz gut leben.