IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C++ Discussion :

Vérifier qu'une fonction "inline" l'a bien été.


Sujet :

C++

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre actif
    Inscrit en
    Septembre 2010
    Messages
    73
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 73
    Par défaut Vérifier qu'une fonction "inline" l'a bien été.
    Lorsqu'on indique qu'une fonction est inline c'est pour placer le code là où on en à besoin à la compilation et ne pas avoir à l'appeler pendant l’exécution (entre autres).
    J'ai lu un peu partout qu'un compilateur pouvait faire ce qu'il voulait d'une fonction inline, l'interpréter comme bon lui semble.

    Donc ma question, comment fait-on pour savoir comment une fonction inline a été interprétée ? Si le programme l'appelle ou pas ?

    Merci.

  2. #2
    Membre Expert
    Homme Profil pro
    Chercheur
    Inscrit en
    Mars 2010
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chercheur

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 218
    Par défaut
    Bonsoir,

    il y a peut être une approche plus fine mais une manière simple de le vérifier est de comparer les temps CPU avec et sans le mot-clé inline.

    Je ne suis pas un grand expert des compilateurs mais il est probable que tous ne prennent pas la même décision en fonction du contenu d'une fonction.

    Dans les environnement de développement, il est parfois proposé des options pour forcer un peu le compilateur; c'est le cas dans Visual Studio par exemple.

  3. #3
    Membre Expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    Août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 1 717
    Par défaut
    Je ne suis pas un grand expert des compilateurs mais il est probable que tous ne prennent pas la même décision en fonction du contenu d'une fonction.
    Ce n'est pas probable, c'est certain, sauf dans certains cas où c'est obligé.

    Visual Studio va par exemple inliner de force tes fonctions inline même en Debug de manière à ce que ce soit plus rapide mais aussi plus dur a débugger si tu passe par ces fonctions. En revanche, que ce soit inline ou pas, une fonction membre déclarée dans un header sera forcément inliné en Release.

    Gcc a un comportement différent. J'en connais d'autres aussi.

    Bref, ce qui est conseillé c'est de ne pas inliner du tout sauf :

    1. on veut écrire une fonction libre qui doit rester dans le header sans être dans un cpp (par exemple n'importe quelle fonction libre template)
    2. on veut que le processeur fasses tout ce qu'il peut pour optimiser la dite fonction à l'appel.

    La seconde raison est valide seulement dans du code assez "bas niveau" comme une classe représentant un type de nombre ou encore un vecteur mathématique(géométrique?). Même en debug, il faut que les manipulations soient rapide, et comme elles sont courtes on a rarement besoin du pas a pas pour voir comment elles marchent.

    Donc le conseil général c'est :
    1. n'utilise pas les inline si tu peux
    2. si tu as de sproblèmes de performance liés a des fonctions qui pourraient être inline, TEST avec inline, voir comment ton compilo va se comporter
    3. si tu envisages d'utiliser inline à cause de résultats de 2., alors fait en sorte de connaitre le comportement spécifique de ton compilateur. Généralement c'est spécifié dans un document, si ça ne l'est pas TEST ENCORE.

    Donc la plupart du temps, ignorer inline.


    Pour répondre à la question, au pas à pas d'un débuggeur (gdb ou Visual Studio) tu peux savoir si le code a été inliné selon si tu as les infos dispo ou pas. Mais c'est moins fiable que de regarder le code assembleur généré.
    Perso, j'hésite de me poser la question, je ne fais que TESTER quand je veux utiliser inline, voir ce que ça donne, sauf quand c'est du template (qui devra être inliné de toutes façons.

  4. #4
    Membre Expert
    Homme Profil pro
    Chercheur
    Inscrit en
    Mars 2010
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chercheur

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 218
    Par défaut
    Bonsoir Klaim,

    je vais rebondir un peu sur tes propos parce que je ne comprends pas tout.

    Citation Envoyé par Klaim Voir le message
    Visual Studio va par exemple inliner de force tes fonctions inline même en Debug de manière à ce que ce soit plus rapide mais aussi plus dur a débugger si tu passe par ces fonctions.
    En quoi est-ce plus dur à deboguer? Je n'ai jamais eu de problème.
    Au fait, tu peux désactiver la prise en compte du mot-clé inline en debug et pas en release si tu veux.

    Citation Envoyé par Klaim Voir le message
    En revanche, que ce soit inline ou pas, une fonction membre déclarée dans un header sera forcément inliné en Release.
    Je me trompe peut-être mais il me semblait que les fonctions membre inline doivent forcément être déclarées et définies dans un header (dans un cpp ça ne compile pas normalement). De plus, dans l'exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    class Foo
    {
    public:
        int fun1() { return _myint;};
        int fun2();
        int fun3();
    private:
        int _myint;
    };
     
    inline int Foo::fun2() 
    { 
        return _myint;
    }
     
    int Foo::fun3() 
    { 
        return _myint;
    }
    il me semble que la fonction fun3 n'est inline.

    Du coup la première raison que tu donnes pour décider d'utiliser inline me paraît discutable mais encore une fois je peux me tromper. Ce qu'on m'a toujours appris c'est qu'il ne faut utiliser inline que pour les fonctions vérifiant ces conditions :
    1. appelées souvent dans le code (inline permet ainsi une augmentation significative des performances),
    2. contenant peu de lignes de code (pour ne pas faire trop grossir la taille du code compilé)

    Je n'ai jamais vérifié mais il me semble également que le mot-clé inline est systématiquement refusé pour les fonctions contenant au moins une boucle (quel que soit le compilateur). Est-ce que quelqu'un en saurait plus là-dessus?

  5. #5
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Salut,
    Citation Envoyé par Aleph69 Voir le message
    Je me trompe peut-être mais il me semblait que les fonctions membre inline doivent forcément être déclarées et définies dans un header (dans un cpp ça ne compile pas normalement).
    Je n'ai pas vérifié dans la norme mais certains compilateurs permettent de définir la fonction inline dans le .cpp. Simplement l'inlining ne se fera que pour les appels après la définition de la fonction inline.

    Citation Envoyé par Aleph69 Voir le message
    De plus, dans l'exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    class Foo
    {
    public:
        int fun1() { return _myint;};
        int fun2();
        int fun3();
    private:
        int _myint;
    };
     
    inline int Foo::fun2() 
    { 
        return _myint;
    }
     
    int Foo::fun3() 
    { 
        return _myint;
    }
    il me semble que la fonction fun3 n'est inline.
    fun3 n'est pas inline et va même provoquer une erreur d'édition de lien si le fichier d'en-tête est inclus par plusieurs unité de compilation (multiple définition).

    Citation Envoyé par Aleph69 Voir le message
    Ce qu'on m'a toujours appris c'est qu'il ne faut utiliser inline que pour les fonctions vérifiant ces conditions :
    1. appelées souvent dans le code (inline permet ainsi une augmentation significative des performances),
    2. contenant peu de lignes de code (pour ne pas faire trop grossir la taille du code compilé)
    Et puis les fonctions définies dans le fichier d'en-tête pour éviter les problèmes de multiple définition.

    Citation Envoyé par Aleph69 Voir le message
    Je n'ai jamais vérifié mais il me semble également que le mot-clé inline est systématiquement refusé pour les fonctions contenant au moins une boucle (quel que soit le compilateur). Est-ce que quelqu'un en saurait plus là-dessus?
    Perso, je ne sais pas. Je n'ai jamais vérifié.

    @PO: comment savoir si les fonctions sont inlinées ? Un indice (pas toujours vrai) : vérifier les symboles de l'exécutable (fichier map). Si la fonction n'y est pas, c'est qu'elle a été inlinée partout où elle était utilisée.

  6. #6
    Membre Expert
    Homme Profil pro
    Chercheur
    Inscrit en
    Mars 2010
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chercheur

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 218
    Par défaut
    Salut,

    Citation Envoyé par 3DArchi Voir le message
    Et puis les fonctions définies dans le fichier d'en-tête pour éviter les problèmes de multiple définition.
    Dans quel cas a-t-on besoin de définir dans un header une fonction qui n'est pas inline? Il y a bien les fonctions template (inline ou non) mais à part ça je ne vois pas.

  7. #7
    Expert éminent
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 644
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 644
    Par défaut
    Salut,

    En fait, je ne suis pas loin de penser que l'intérêt du mot clé inline est bien plus fonctionnel (pour éviter à l'éditeur de liens de s'étonner de trouver plusieurs fois la définition d'une seule et même fonction) que réellement pratique (espoir de gains de performances).

    Je m'explique :

    L'appel d'une fonction (non inline) ne prend malgré tout pas des masses de temps: il s'agit "simplement" de sauvegarder un contexte (adresse courante d'exécution, plus l'une ou l'autre info) avant de sauter à une adresse d'exécution différente, et de revenir au point de départ une fois la fonction achevée.

    Cela ne tourne quand même qu'aux alentours de "quelques" cycles d'horloge, que diable!

    Pour obtenir un gain significatif (susceptible d'être compté ne serait-ce qu'en secondes) uniquement sur ces quelques cycles, il faudrait vraiment que la fonction inlinée soit appelée un très grand nombre de fois (en dessous de 50 000 fois, je ne crois même pas que l'on pourrait atteindre la seconde ! )

    Et il ne faut pas oublier le revers de la médaille qui est l'augmentation du code compilé (même si, dans certains cas, elle peut être considérée comme négligeable )

    Bon, si la fonction en question est simplement sensée renvoyer un entier ou une référence vers un objet quelconque, cela peut se justifier, et nous pouvons estimer qu'elle sera peut etre effectivement inlinée pour autant que nous ayions la certitude qu'il n'y aura pas une copie cachée dans le renvois de l'objet et que les copies cachées éventuelles ne produisent pas un nombre d'instruction processeur trop important

    Je voudrais en profiter pour revenir sur une erreur qui a été commise par aleph:
    contenant peu de lignes de code (pour ne pas faire trop grossir la taille du code compilé)
    Le nombre de lignes de code n'a strictement rien à voir car la notion même de ligne n'apparait pas en C ni en C++ (contrairement au cobol, par exemple) :

    En cobol, tout ce qui dépasse la colonne 80 d'une ligne est considéré comme du commentaire, et il faut expllictement dire que ce qui suit le retour à la ligne fait partie de la même instruction.

    Par contre, pour etre "standard compliant", les compilateurs sont tenu d'accepter au minimum 65 000 caractères sans rencontrer un retour à la ligne, et plusieurs instructions peuvent très bien se retrouver sur une seule et même ligne!

    Nous pouvons par exemple parfaitement envisager d'avoir un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    inline void foo(){for(int i = 0; i< MAXVAL;++i{truc machin; machin.do(); if(machin.bidul()){basard brol; brol.chouette(); /*... */}}}
    qui sera peut etre écrit sur une ligne (même si on le déconseille pour une question de visibilité) et qui sera compris et accepté par le compilateur.

    Cependant, il n'y a vraiment que peu de chances pour qu'il soit effectivement inliné, pour la simple et bonne raison que, une fois converti en instructions processeur, cela représente un nombre d'instructions incitant le compilateur à ne pas l'ininer.

    De même, nous pourrions avoir une seule instruction (complexe) sur plusieurs lignes de code! Il n'est pas rare de rencontrer un code proche de
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
     
    inline int bar()
    {
        int result = foo( truc.getX(),
                          truc.getY(),
                          bidule.isValid());
        return result;
    }
    simpelment pour "aérer le code" et le rendre plus visible.

    Et il se pourrait même que cette fonction (et toutes celles qui sont appelées, si elle sont déclarées inline) soit inlinée, simplement parce que cela ne correspond qu'à un nombre très restreint d'instruction processeur!

    Tout cela pour marteler une fois de plus un point important : le nombre d'instructions ou de ligne de code n'aura strictement aucune incidence sur l'inlining ou non d'une fonction!

    La seule chose qui aura une (éventuelle) incidence sur se point sera le nombre d'instructions processeur nécessaire à traduire les instructions décrites dans le code.

    Je tiens enfin à rappeler encore une fois qu'il est parfaitement inutile de compter sur l'inlining (dont on n'est pas forcément sur qu'il se fera) pour améliorer les performances d'une application : il y a beaucoup à faire pour améliorer les performances avant d'en arriver à ce point, à commencer par le fait d'améliorer l'ensemble des algorithmes!

    Pour te donner un exemple précis, imaginons les fonctions suivantes :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    void fonction()
    {
        for(int i = 0; i < MAXFIRST; ++ i)
            fonction1();
    }
    void fonction1()
    {
        for (int i = 0; i< MAXSECOND; ++i)
            fonction2();
    }
    void fonction2()
    {
        for(int i = 0; i< MAXTHIRD; ++1)
            fonction3();
    }
    void fonction3(){/* ...*/}
    le simple fait de repérer dans fonction que tu ne dois pas appeler, pour un i donné, fonction1 te permettra d'éviter au total:
    • un appel à fonction1 soit
    • MAXSECOND appels à fonction2 soit
    • MAXTHIRD * MAXSECOND appels à fonction3
    Je te laisse évaluer le gain que tu pourrais avoir si, au final, tu en arrive à éviter un appel sur deux à fonction1 dans fonction, même si cela doit passer par un test de complexité relative
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Membre Expert
    Homme Profil pro
    Chercheur
    Inscrit en
    Mars 2010
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chercheur

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 218
    Par défaut
    Salut,

    Citation Envoyé par koala01 Voir le message
    Tout cela pour marteler une fois de plus un point important : le nombre d'instructions ou de ligne de code n'aura strictement aucune incidence sur l'inlining ou non d'une fonction!

    La seule chose qui aura une (éventuelle) incidence sur se point sera le nombre d'instructions processeur nécessaire à traduire les instructions décrites dans le code.
    Merci d'avoir corrigé.

    Citation Envoyé par koala01 Voir le message
    En fait, je ne suis pas loin de penser que l'intérêt du mot clé inline est bien plus fonctionnel (pour éviter à l'éditeur de liens de s'étonner de trouver plusieurs fois la définition d'une seule et même fonction) que réellement pratique (espoir de gains de performances).
    Cela ne tourne quand même qu'aux alentours de "quelques" cycles d'horloge, que diable!

    Pour obtenir un gain significatif (susceptible d'être compté ne serait-ce qu'en secondes) uniquement sur ces quelques cycles, il faudrait vraiment que la fonction inlinée soit appelée un très grand nombre de fois (en dessous de 50 000 fois, je ne crois même pas que l'on pourrait atteindre la seconde ! )

    Je tiens enfin à rappeler encore une fois qu'il est parfaitement inutile de compter sur l'inlining (dont on n'est pas forcément sur qu'il se fera) pour améliorer les performances d'une application : il y a beaucoup à faire pour améliorer les performances avant d'en arriver à ce point, à commencer par le fait d'améliorer l'ensemble des algorithmes!
    En fait ça dépend vraiment des applications. Pour les miennes, je manipule des grosses matrices de plusieurs milliers ou millions de lignes/colonnes, des vecteurs dont la longueur est du même ordre de grandeur, au sein d'algorithmes itératifs qui eux-mêmes nécessitent un nombre d'itérations du même ordre de grandeur. Faire de l'expansion de code dans ce genre de calcul a vraiment un intérêt.

    Les derniers exemples que tu donnes contiennent des boucles : je suppute que l'expansion de ces codes te sera refusée par ton compilateur de toute manière. L'expansion concernant essentiellement des fonctions très simples, typiquement des accesseurs/mutateurs, il n'y a pas grand chose à optimiser d'un point de vue purement algorithmique.

  9. #9
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Citation Envoyé par koala01 Voir le message
    L'appel d'une fonction (non inline) ne prend malgré tout pas des masses de temps: il s'agit "simplement" de sauvegarder un contexte (adresse courante d'exécution, plus l'une ou l'autre info) avant de sauter à une adresse d'exécution différente, et de revenir au point de départ une fois la fonction achevée.
    L'inlining ne gagne pas simplement le coût d'appel d'une fonction, mais aussi les possibilités d'optimisation supplémentaires liées au fait que la fonction soit directement lisible. Exemple bête :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    int f(int i)
    {
      if(i>20)
        // ...
      else
        //...
    }
     
    int g(int i)
    {
      if(i>30) {return f(i);}
      return 0;
    }
    Le fait d'inliner permettra la simplification de f dans ce contexte.

    Citation Envoyé par koala01 Voir le message

    Cela ne tourne quand même qu'aux alentours de "quelques" cycles d'horloge, que diable!

    Pour obtenir un gain significatif (susceptible d'être compté ne serait-ce qu'en secondes) uniquement sur ces quelques cycles, il faudrait vraiment que la fonction inlinée soit appelée un très grand nombre de fois (en dessous de 50 000 fois, je ne crois même pas que l'on pourrait atteindre la seconde ! )
    Si le reste du corps de f ne coûte lui aussi que quelques cycles d'horloge, quelques cycles gagnés, c'est important.
    Citation Envoyé par koala01 Voir le message
    Et il ne faut pas oublier le revers de la médaille qui est l'augmentation du code compilé (même si, dans certains cas, elle peut être considérée comme négligeable )
    Les seules fois où j'ai pu constater de visu une modification de la taille du code compilé liée à l'inlining, c'était une diminution, parfois drastique.
    Ceci est en particulier notable dans le code générique, où l'on a souvent tout un empilement de fonctions qui ne font pas grand'chose. Si cet empilement est précompilé grâce à l'inlining, on gagne pas mal de taille de code. Disons que l'inlining combat le code bloat des templates.
    Citation Envoyé par koala01 Voir le message
    Cependant, il n'y a vraiment que peu de chances pour qu'il soit effectivement inliné, pour la simple et bonne raison que, une fois converti en instructions processeur, cela représente un nombre d'instructions incitant le compilateur à ne pas l'ininer.
    Il peut être intéressant d'inliner des grosses fonctions, comportant une grand nombre d'instructions. L'exemple typique est la fonction qui ne serait appelée que par un seul point dans le code.
    Citation Envoyé par Aleph69 Voir le message
    Les derniers exemples que tu donnes contiennent des boucles : je suppute que l'expansion de ces codes te sera refusée par ton compilateur de toute manière.
    Je ne vois pas pourquoi un compilateur refuserait l'inlining d'une boucle. Il y a certainement des cas où ça peut avoir des gains intéressants. Par exemple, sous réserve qu'il n'y ait pas d'aliasing :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    void fboucle(int n)
    {
      for (int i=0 ; i<n ; ++i) { f(i);}
    }
     
    void gboucle(int n)
    {
      for (int i=0 ; i<n ; ++i) { g(i);}
    }
     
    void h(int n)
    {
      fboucle(n);
      gboucle(n);
    }
    Si les appels à fboucle et gboucle sont inlinés, le code de h pourra ensuite devenir équivalent à :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    void h(int n)
    {
      for (int i=0 ; i<n ; ++i)
      {
        f(i);
        g(i);
      }
    }
    Et on aura gagné du temps non négligeable si f et g sont petits.



    Par contre, même si je me base beaucoup sur l'inlining quand j'écris du code (ce qui se traduit par le fait que je n'hésite pas à écrire des fonctions), j'utilise assez rarement le mot clef inline. Je considère que c'est plus le travail du compilateur que le mien. Bien entendu, si j'ai des problèmes de perfs importants dans du code (suffisamment importants pour qu'on m'alloue du temps pour les régler), que j'ai déjà bien revu mes algorithmes, que le profiling me montre qu'en ajoutant un inline à un endroit, ça s'améliore, je n'hésiterai pas à l'employer. Ça ne m'est tout simplement pas encore arrivé.
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  10. #10
    Membre Expert
    Homme Profil pro
    Chercheur
    Inscrit en
    Mars 2010
    Messages
    1 218
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Chercheur

    Informations forums :
    Inscription : Mars 2010
    Messages : 1 218
    Par défaut
    Bonsoir,

    Citation Envoyé par JolyLoic Voir le message
    Je ne vois pas pourquoi un compilateur refuserait l'inlining d'une boucle.
    Il me semble que c'est ce qui arrive en pratique :
    http://www.daniweb.com/software-deve.../threads/13472

    Si tu connais un compilateur qui accepte l'expansion d'un code contenant une boucle, j'aimerais bien tester.

  11. #11
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Utiliser __forceinline sur MSVC et __attribute__((always_inline)) inline sur GCC-like...

  12. #12
    Membre Expert

    Homme Profil pro
    Développeur informatique
    Inscrit en
    Septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 49
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Septembre 2007
    Messages : 1 895
    Par défaut
    Citation Envoyé par Aleph69 Voir le message
    Bonsoir,



    Il me semble que c'est ce qui arrive en pratique :
    http://www.daniweb.com/software-deve.../threads/13472

    Si tu connais un compilateur qui accepte l'expansion d'un code contenant une boucle, j'aimerais bien tester.
    Il semblerait que ça soit une limitation propre à Borland C++. Je ne vois pas de raison majeure d'éviter l'inlining pour les fonctions avec un boucle. Ca me semble même un peu obligatoire pour les fonctions template (ex: for_each, ...).

    Je pense que g++, Visual C++, Intel C++ inline le code des fonctions courtes même si celle-ci contiennent une boucle. Ils peuvent être assez agressifs au niveau des optimisations.
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  13. #13
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    Juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2008
    Messages : 7 634
    Par défaut
    Salut,
    Citation Envoyé par koala01 Voir le message
    L'appel d'une fonction (non inline) ne prend malgré tout pas des masses de temps: il s'agit "simplement" de sauvegarder un contexte (adresse courante d'exécution, plus l'une ou l'autre info) avant de sauter à une adresse d'exécution différente, et de revenir au point de départ une fois la fonction achevée.

    Cela ne tourne quand même qu'aux alentours de "quelques" cycles d'horloge, que diable!

    Pour obtenir un gain significatif (susceptible d'être compté ne serait-ce qu'en secondes) uniquement sur ces quelques cycles, il faudrait vraiment que la fonction inlinée soit appelée un très grand nombre de fois (en dessous de 50 000 fois, je ne crois même pas que l'on pourrait atteindre la seconde ! )

    Et il ne faut pas oublier le revers de la médaille qui est l'augmentation du code compilé (même si, dans certains cas, elle peut être considérée comme négligeable )
    C'est parfois un peu plus compliqué. Un appel peut coûter chez au regard d'un inlining et le code inliné n'est pas forcément plus gros que le code non inliné. Cela car lorsque le code est inliné à la place de l'appel de la fonction, le compilateur peut réaliser des optimisations supplémentaires aboutissant à un code plus petit et plus rapide au delà du simple coût d'appel.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [PHP 5.3] [POO] : faire une fonction quote
    Par gwendoline-bricout dans le forum Langage
    Réponses: 7
    Dernier message: 20/02/2014, 10h41

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo