Discussion :

[Awakening]

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.

[Aleph69]

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.

[Klaim]

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.

[Aleph69]

Bonsoir Klaim,

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

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.

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?

[3DArchi]

Salut,

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.

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).

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.

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.

[Aleph69]

Salut,

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.

[koala01]

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

[Aleph69]

Salut,

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é.

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.

[JolyLoic]

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.

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.

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.

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.

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é.

[Aleph69]

Bonsoir,

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.

[loufoque]

Utiliser __forceinline sur MSVC et __attribute__((always_inline)) inline sur GCC-like...

[Emmanuel Deloget]

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.

[3DArchi]

Salut,

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.