Quelle est la difference entre sjlj vs dwarf vs seh?

147

Je ne trouve pas assez d'informations pour décider quel compilateur dois-je utiliser pour compiler mon projet. Il existe plusieurs programmes sur différents ordinateurs simulant un processus. Sous Linux, j'utilise GCC. Tout est bon. Je peux optimiser le code, il se compile rapidement et n'utilise pas tellement de mémoire.

Je fais mon propre benchmark avec les compilateurs MSVC et GCC. Plus tard, on produit des binaires légèrement plus rapides (pour chaque sous-architecture). Bien que le temps de compilation soit bien plus que MSVC.

J'ai donc décidé d'utiliser MinGW. Mais je ne trouve aucune explication sur les méthodes de gestion des exceptions et leurs implémentations dans MinGW. Je peux utiliser différentes distributions pour différents systèmes d'exploitation et architectures.

Considérations:

Le temps de compilation et la mémoire ne sont pas importants pour mon utilisation. La seule chose importante est l'optimisation de l'exécution. J'ai besoin que mes programmes soient assez rapides. Un compilateur lent est acceptable.
Système d'exploitation: Microsoft Windows XP / 7/8 / Linux
Architecture: Intel Core i7 / Core2 / et un très ancien i686 sous XP: P

— sorush-r
source

Je suis surpris que gcc produise un code plus rapide que MSVC; les choses ont dû changer ces dernières années ...

— trojanfoe

@trojanfoe On m'a dit tant de fois d'utiliser MSVC au lieu de MinGW. Tout le monde pense que msvc est plus rapide! J'ai testé MinGW 7.2 et MSVC 2010. avec un simple programme cpu-burst. Sur corei7 avec -O3 -mtune=corei7GCC est 45% plus rapide que

— MSVC

D'après ma propre expérience, avec un générateur de mouvements d'échecs (qui utilisait des bitboards), MSVC et Intel C ++ étaient 10% plus rapides que gcc, mais c'était il y a 2 ans ...

— trojanfoe

@Wolf Pendant ce temps, 45% plus rapide signifiait 45% moins de temps à exécuter pour moi. Si je me souviens bien, le temps d'exécution de notre logiciel de modélisation de la géométrie moléculaire était de 134s (gcc) et 194s (msvc) pour un test spécifique. Néanmoins maintenant je considère que ma méthode de mesure est incorrecte et insuffisante (:

— sorush-r

@ sorush-r Je vois, vous avez calculé (194-134) / 134 qui est proche de 45%, merci.

— Wolf

Réponses:

109

Il y a un bref aperçu sur MinGW-w64 Wiki :

Pourquoi mingw-w64 gcc ne prend-il pas en charge la gestion des exceptions Dwarf-2?

L' implémentation Dwarf-2 EH pour Windows n'est pas du tout conçue pour fonctionner sous des applications Windows 64 bits. En mode win32, le gestionnaire de déroulement d'exceptions ne peut pas se propager via un code non compatible DW2, cela signifie que toute exception passant par un code "trames étrangères" non compatible DW2 échouera, y compris les DLL système Windows et les DLL générées avec Visual Studio. Le code de déroulement de Dwarf-2 dans gcc inspecte l'assemblage de déroulement x86 et ne peut pas continuer sans d'autres informations de déroulement de Dwarf-2.

La méthode SetJump LongJump de gestion des exceptions fonctionne dans la plupart des cas sur win32 et win64, à l'exception des défauts de protection généraux. La prise en charge structurée de la gestion des exceptions dans gcc est en cours de développement pour surmonter les faiblesses de dw2 et sjlj. Sur win64, les informations de déroulement sont placées dans la section xdata et il y a le .pdata (table des descripteurs de fonctions) au lieu de la pile. Pour win32, la chaîne de gestionnaires est sur la pile et doit être sauvegardée / restaurée par du vrai code exécuté.

GCC GNU à propos de la gestion des exceptions :

GCC prend en charge deux méthodes de gestion des exceptions (EH):

DWARF-2 (DW2) EH , qui nécessite l'utilisation des informations de débogage DWARF-2 (ou DWARF-3). DW-2 EH peut entraîner une légère surcharge des exécutables car de grandes tables de déroulement de pile d'appels doivent être incluses dans les exécutables.

Une méthode basée sur setjmp / longjmp (SJLJ) . EH basé sur SJLJ est beaucoup plus lent que DW2 EH (pénalisant même l'exécution normale lorsqu'aucune exception n'est levée), mais peut fonctionner sur du code qui n'a pas été compilé avec GCC ou qui n'a pas d'informations de déroulement de pile d'appels.

[...]

Gestion structurée des exceptions (SEH)

Windows utilise son propre mécanisme de gestion des exceptions appelé SEH (Structured Exception Handling). [...] Malheureusement, GCC ne prend pas encore en charge SEH. [...]

Voir également:

— ollo
source

Merci pour les liens. Je vais utiliser DW2 pour 32 bits et SEH pour 64. SEH est disponible dans mingwbuilds (4.8). Dois-je attendre la version stable de 4.8 ou c'est ok? Il compile ici. Je crée actuellement des dépendances de mon projet en utilisant 4.8 avec SEH. Pas encore de problèmes ...

— sorush-r

Toutes les dépendances (y compris la bibliothèque Boost, OpenSSL, ICU, freeGLUT) compilées mais Qt se retrouvent avec de nombreuses erreurs internes du compilateur. Je pense que j'attendrai la sortie stable de 4.8

— sorush-r

Avez-vous utilisé des binaires de qt ou avez-vous compilé vous-même?

@woreos J'utilise ma propre compilation Qt. J'ai trouvé qu'il n'y avait aucun problème avec ni Qt ni GCC 4.8. C'était ma RAM à moitié brûlée! 1 Maintenant, tout fonctionne bien

— sorush-r

SJLJ (setjmp / longjmp): - disponible pour 32 bits et 64 bits - pas «à coût nul»: même si une exception n'est pas levée, elle encourt une légère pénalité de performance (~ 15% en code lourd d'exception) - autorise les exceptions pour parcourir par exemple les rappels Windows

DWARF (DW2, dwarf-2) - disponible pour 32 bits uniquement - pas de surcharge d'exécution permanente - nécessite que toute la pile d'appels soit activée en nain, ce qui signifie que les exceptions ne peuvent pas être levées par exemple sur les DLL du système Windows.

SEH (exception de surdébit nul) - sera disponible pour GCC 4.8 64 bits.

source: http://qt-project.org/wiki/MinGW-64-bit

Désolé, le lien source a été ajouté.

Merci pour votre réponse;)

— sorush-r

Alors maintenant, en 2016, nous pouvons mettre cette question au repos et simplement toujours utiliser SEH.

— rustyx

@RustyX Uniquement si votre cible est x86_64

— sohnryang

Alors Dwarf pour x86?

— banguru