Journal Les optimisations de GCC

Posté par .
Tags : aucun
0
11
jan.
2006
Beaucoup de linuxiens se demandent quelles sont les différentes options d'optimisation GCC [1], leurs significations et comment on peut les utiliser, si c'est une bonne idée d'utiliser celle-ci ou celle-là, ... D'ailleurs il existe probablement divers documents plus ou moins complet sur le sujet. Pour ma part, je cherchais un tel document pour faire un test et j'en ai trouvé un qui est assez concis [2]. Il explique assez simplement les options d'optimisations "les plus utiles" (c'est assez subjectif) et celles qui sont activées selon le niveau d'optimisation désiré. Bonne lecture !

[1] GCC Home Page: http://gcc.gnu.org/
[2] Optimization in GCC : http://www.linuxjournal.com/article/7269
  • # Qques adresses chez gentoo

    Posté par (page perso) . Évalué à 8.

    Les CFLAGS de base : http://gentoo-wiki.com/CFLAGS
    Les CFLAGS "Safe" selon les proc : http://gentoo-wiki.com/Safe_Cflags
  • # gcc

    Posté par (page perso) . Évalué à 2.

    j'en profite pour poser une question:
    Quelqu'un sait coment on compile une application en 32bits sous une distrib 64bits ?
    • [^] # Re: gcc

      Posté par . Évalué à 3.

      Moi aussi ça m'interresse, est ce que l'on peut compiler une appli sous un OS/archi pour un autre OS/archi ?

      Au passage si quelqu'un à un lien qui explique clairement les bases de la compilation pour des néophites comme moi, ça m'interresserai :-)

      Merci à tous ceux qui éclaireront ma lanterne.
      • [^] # Re: gcc

        Posté par . Évalué à 4.

        compiler une appli sous un OS/archi pour un autre OS/archi c'est de la cross compilation. j'avais vu une doc il ya quelques temps (1 an) sur le site de gentoo. ca doit etre applicable ailleurs. en gros ca consiste a avoir les librairie de la cible sur ton poste ayant le compilo et d'indiquer à celui-ci d'utiliser ces librairies et non pas les librairies habituelles.
    • [^] # Re: gcc

      Posté par (page perso) . Évalué à 5.

      Je viens de tomber sur la réponse par hasard sur le site de gcc ( http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Option(...) )


      -m32
      -m64
      Generate code for a 32-bit or 64-bit environment. The 32-bit environment sets int, long and pointer to 32 bits and generates code that runs on any i386 system. The 64-bit environment sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture.
    • [^] # Re: gcc

      Posté par (page perso) . Évalué à 1.

      D'ailleurs tu peux aussi installer les bibliotheques d'emulation 32 bits, cela marche vraiment tres bien sous gentoo pour les quelques applications qui ne fonctionnent pas pleinement en 64 bits.

      Steph
  • # Re

    Posté par (page perso) . Évalué à 2.

    Un tuto sur la compilation en static et ses subtilité serait la bienvenue. Car chez moi le flag static ne change pas grand chose à l'executable généré...
    • [^] # Re: Re

      Posté par (page perso) . Évalué à 2.

      pour compiler statiquement, tu dois avoir les lib statiques. Généralement ce sont les .a qui sont en fait des archives ar (man ar) avec dedans des fichiers objets.

      Ensuite, au lieu de mettre -lmalib sur la ligne de l'éditeur de liens, il faut mettre monchemin/vers/malib.a

      Ca devrait marcher
      • [^] # Re: Re

        Posté par . Évalué à 2.

        Plus simple, il suffit de compiler le programme par :

        export LDFLAGS="-static"
        ./configure [options] --enable-static --disable-shared
        ...


        Ça génère des exécutables liés en statique dans la plupart des cas pourvu que chaque bibliothèque nécessaire existe sur le système en version statique (les fameuses archives d'objets en .a).

        « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Re

        Posté par (page perso) . Évalué à 2.

        Il y a aussi le "ELF Statifier" qui permet de générer un binaire statique sur base d'un binaire dynamique et de ses libs. Ca évite de devoir recompiler mais ça combine les inconvénients des binaires statiques "normaux" (gros) et des binaires dynamiques (lent).
        http://statifier.sourceforge.net/

        pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Petit rappel élémentaire

    Posté par (page perso) . Évalué à 4.

    Pour gagner 100% de performance ou plus, il faut revoir la conception d'un programme, pas jouer avec de l'assembleur ou les options du compilateur.

    Méthodologie :
    a) Bien isoler les parties qui prennent du temps
    b) Les réécrire différement :-)

    J'ai réussi à passer de 30 seconde à moins d'un seconde de traitement avec cette méthode.

    Exemple 1:

    Problème : la création des objets prend trop de temps.

    Solution : Bon, outil "suppression". Hop, on arrête de créer 30.000 objets et on crée juste ceux qui sont affichés.

    Exemple 2:

    Problème : en activant la surveillance des allocations mémoires (avec un bout de code perso), les performances s'écrasent lamentablement.

    Solution : J'utilisais une liste simplement chaînée, très grosse erreur. Le passage à une liste double chaînée a supprimé le problème (je passe de 10 secondes à moins d'une seconde de calcul pour une expression complexe).

    (exemples sortis de deux programmes différents, l'un en Python, l'autre en C++ ;-))

    Pour isoler "les parties qui prennent du temps", j'ai tenté gprof (le profiler gnu), mais je ne comprend *rien* à ses résultats. gprof donne trop d'informations et je n'ai jamais compris s'il faut lire le temps total, temps cumulé, nombre d'appels, etc. Je préfère mes outils persos : j'ajoute des StatStart("nom"); et StatStop("nom"); dans le code. Ca me génère un fichier XML que j'affiche avec un p'tit script Python qui me trie ça comme il faut et calcule les pourcentages. Je dois avoir des bouts de code en PHP, C++ et Python si ça vous intéresse.

    Haypo
    • [^] # Re: Petit rappel élémentaire

      Posté par . Évalué à 3.

      Je te rassure, il ne s'agit d'over-optimiser un logiciel, il s'agit de lancer un traitement lourd (une grosse compilaton bien optimisée pour la endre plus "lourde" en terme de ressources) pour faire un test : ce qui m'intéresse, ce n'est pas directement le résultat des binaires optimisés, c'est la compilation, sa solicitation sur le système et le temps de traitement.

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Petit rappel élémentaire

      Posté par (page perso) . Évalué à 2.

      À ce sujet, le "Graphics Programming Black Book" est assez intéressant (bon j'ai pas encore dépassé le chapitre 4) même si ça parle beaucoup ASM, il est bien expliqué que ça sert à rien de micro optimiser sans y avoir bien réfléchi avant ("The Best Optimizer is between Your Ears").
      http://www.gamedev.net/reference/articles/article1698.asp

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.