Discussion :

[Aurelien.Regat-Barrel]

Bonjour,

En ce moment je passe des entretiens et donc des tests techniques C++, et j'ai eu droit à une question sur "virtual inline". J'en ai profité pour glisser mon avis personnel au sujet de inline qui est en gros : ce n'est plus utile de nos jours. Maintenant, je me demande dans quelle mesure mon affirmation est valide.

Je n'ai jamais été un grand fan de inline (explicite ou implicite), parce que de mon point de vue c'est une entorse aux bonnes pratiques (pas d'implémentation dans un header) du fait que, ben, on en avait besoin. Mais aujourd'hui - sans m'être sérieusement penché sur la question je l'avoue - j'estime que les compilateurs sont suffisamment évolués pour se débrouiller tout seuls, surtout avec l'apparition de l'optimisation guidée par profil (encore que j'ai eu des déceptions à ce sujet). Bref, je considère qu'inline relève de l'optimisation prématurée, pour ne pas dire de la pollution de code, et que c'est à oublier au même titre que register.

Vos avis / retours d'expérience ?

[Matthieu Brucher]

Idem, le compilateur fait très bien son boulot, s'il voit que la fonction a un intérêt en terme de quantité d'instructions à être inlinée, elle le sera, même si elle est en double.
Ce qui est certain, c'est que quand mon code est inliné par le compilateur, je gagne un facteur 10 car tous les appels "simples" sont regroupés (c'était l'objectif au départ du programme).

[Alp]

Bref, je considère qu'inline relève de l'optimisation prématurée, pour ne pas dire de la pollution de code, et que c'est à oublier au même titre que register.

Ca résume très bien mon avis.

Les compilos que j'utilise (celui de VC et gcc), en particulier VC au boulot, gèrent très bien ça. Je ne m'en soucie pas et considère ne pas avoir à m'en soucier. Cela fait partie de ce que l'on est en droit d'exiger d'un compilateur de nos jours.

PS : ils comptaient vraiment t'avoir avec le coup du "virtual inline" ?

[JolyLoic]

J'aurais bien aimé une troisième réponse au sondage : C'est inutile en général, mais on ne sait jamais.

Tout ce que je sais, c'est que ça fait un bout de temps que je n'ai pas fait de micro-optimisations de code en général, car je n'en n'avait pas vraiment besoin. Inline rentre dans la catégorie micro-optimisation. Le jour où j'aurais à micro-optimiser, j'essayerai inline comme d'autre techniques, en mesurant le résultat. Je n'ai pas envie de le rejeter a priori, on ne sait jamais, mais il est clair que je ne l'utiliserais que de façon hyper ponctuelle...

[koala01]

Salut,

à défaut d'une possibilité plus nuancée, j'ai voté que c'est obsolète et à oublier...

Surtout si l'idée est de créer... une fonction virtuelle

Mais même en dehors de ce cas "peau de banane", je trouve que cela fait vraiment partie des optimisations prématurées tant il y a de restrictions au niveau du compilateur qui nous empêchent d'avoir la certitude que tous les appels à une fonction seront bel et bien inlinés

[metagoto]

inline peut servir à ne pas avoir de multiples définitions de templates.

Ca peut être utile aussi pour remplacer ce que l'on pourrait faire avec des macros. MACHIN(++x) --> machin(++x)

OK pour laisser le compilo décider d'inliner ou non, mais OK aussi pour laisser le développeur placer des keywords inline qui vont bien dans certains cas.

[Matthieu Brucher]

Ca peut être utile aussi pour remplacer ce que l'on pourrait faire avec des macros. MACHIN(++x) --> machin(++x)

Le compilateur fait ça bien mieux que toi, je ne vois l'intérêt de lui forcer ça !
Pour les templates, c'est idem, il inline automatiquement quand c'est possible/intéressant pour ton processeur.

[metagoto]

Le compilateur fait ça bien mieux que toi, je ne vois l'intérêt de lui forcer ça !
Pour les templates, c'est idem, il inline automatiquement quand c'est possible/intéressant pour ton processeur.

On est parfois obligé d'inliner des définitions de templates si on les places dans des fichiers headers.

Et pour le "remplacement de macro", même si le compilo fait ce qu'il veut, je trouve personnellement que de mettre inline exprime mieux l'intention du développeur

[koala01]

inline peut servir à ne pas avoir de multiples définitions de templates.

Ca peut être utile aussi pour remplacer ce que l'on pourrait faire avec des macros. MACHIN(++x) --> machin(++x)

OK pour laisser le compilo décider d'inliner ou non, mais OK aussi pour laisser le développeur placer des keywords inline qui vont bien dans certains cas.

Le compilateur fait ça bien mieux que toi, je ne vois l'intérêt de lui forcer ça !
Pour les templates, c'est idem, il inline automatiquement quand c'est possible/intéressant pour ton processeur.

D'autant plus que la seule restriction à l'utilisation des template est... que le compilateur dispose de l'implémentation des fonctions afin de pouvoir créer le code binaire correspondant une fois qu'il a déterminé le type de donnée manipulée...

Il est ainsi tout à fait possible d'envisager la création de fonctions virtuelles au sein de classes template alors que les fonctions virtuelles ne sont, par définition, jamais inlinées

[CedricMocquillon]

On est parfois obligé d'inliner des définitions de templates si on les places dans des fichiers headers.

Et pour le "remplacement de macro", même si le compilo fait ce qu'il veut, je trouve personnellement que de mettre inline exprime mieux l'intention du développeur

C'est exactement le problème que j'avais eu dans ce post: http://www.developpez.net/forums/d58...tion-template/
Donc pour moi le mot clef inline est encore totalement d'actualité!

[Matthieu Brucher]

Je viens de répondre sur l'autre thread, inline ne fait que corriger des définitions multiples.

[Médinoc]

Ce qui pour moi, est suffisant pour continuer à l'utiliser.

[Mac LAK]

Je n'ai pas voté, il manque l'option "il est important de savoir ce que c'est mais de ne l'utiliser qu'à bon escient".

L'inlining n'est jamais garanti, même avec le "inline" explicite. Par conséquent, côté optimisations au quart de poil, il vaut souvent mieux une bonne vieille macro qu'un mot-clé "inline".
Côté performances globales, il vaut souvent mieux laisser le compilateur inliner à sa guise : toutefois, déclarer les fonctions "inline" peut l'aider à faire des choix peut-être plus judicieux.

Je pense donc que c'est intéressant d'ajouter un "inline" sur les fonctions qui en profiteraient le plus (accesseurs par exemple), afin d'aiguiller les choix du compilateur et/ou d'être à peu près certain que les fonctions en question seront en tête de liste d'inlining.
Par contre, il est stupide de ne se fier qu'à un mot-clé "inline" pour optimiser une boucle critique.

[LittleWhite]

Ça me fait plaisir d'entendre que le compilateur sait très bien inliner pour moi :p

Je n'ai pas du tout votre niveau, je connais ce que fais inline, mais je serai incapable de dire où il est judicieux d'en placer un.
La règle que j'utiliserai si je voulais en placer un, serait, j'en place un, car ma fonction est petite ( 5 lignes ... une sorte de raccourci )( ? ) ...
Tout ça, à cause d'un prof, qui avait dit d'inliner une fonction qui génère des nombres aléatoires entre un min et un max en float ( avec la fonction rand ).
La fonction est petite, prend deux valeurs, ne fait que trois 4 calcul + l'appel à rand.
Retourne le résultat.

Qu'en pensez vous ?

[JolyLoic]

J'en pense que le mieux s'il y a vraiment des problèmes de perfs dans ce programme est de tenter les deux version et de voir (=mesurer) s'il y a un écart notable. S'il n'y en a pas (et il y a des chances qu'il n'y en ait pas), garder la version non inline.

[Aurelien.Regat-Barrel]

Je n'ai pas voté, il manque l'option "il est important de savoir ce que c'est mais de ne l'utiliser qu'à bon escient".

Yes, mais je n'arrive pas à éditer mon sondage


Bon, aujourd'hui j'ai passé un autre entretien où j'ai mis le nez dans le code de leur logiciel etc... et en voyant un header de classe chargée d'effectuer des operations mathématiques (du type vecteurs etc...), y'avait du inline partout, et quelque part, j'ai trouvé ça... rassurant. En fait, je pense qu'au niveau technique l'utilité de ce mot-clé est réellement contestable (je suis d'accord avec Matthieu au sujet du problème de template, pour moi cette utilisation de inline est une pirouette qui sert à masquer un autre problème en fait).

Mais c'est vrai qu'on est habitué à ce mot-clé, qu'on est conditionné quelque part à l'utiliser sur des classes un peu sensibles (au même titre qu'on est conditionné à ne pas utiliser goto), et alors, ne pas lire "inline" peut faire germer le petit doute "et si le compilo n'optimisait pas ma petite classe sensible ?

Je reste convaincu que d'un point de vue purement technique, c'est du bidon et que les vrais problèmes d'optimisation sont ailleurs que dans l'inlining de quelques getters, mais je reconnais maintenant que ça permet de se donner une bonne conscience (ça va un peu dans le sens de la remarque de metagoto sur l'intention du programmeur), de se rassurer en n'ayant pas à profiler le code en question pour être sûr que le compilo fait bien son boulot. A moins que, au contraire, ce soit l'occasion de tester et vérifier par soi même que le compilo sait très bien gérer ça et que inline est véritablement devenu inutile... je testerai si je suis embauché !

Ce qui me gêne toujours avec ce mot-clé, c'est que selon moi il procure une fausse bonne conscience et détourne des véritables sujets d'optimisation en encourageant le développeur à se focaliser sur des setter / getter au lieu de se pencher sur sa gestion mémoire par exemple. Car concrètement, au même titre que l'on ne prend pas le temps d'évaluer l'auto-inlining du compilateur, on ne le prend pas de mesurer le véritable gain de tous ces inline que l'on met partout. Peut-être que ça ne produit aucun résultat visible alors que ça alourdit le code source. C'est grosso-modo ce que j'ai voulu exprimer dans mon premier message.

[koala01]

En fait, le compilateur va principalement regarder le nombre de pseudo instructions lorsqu'il doit décider s'il inline une fonction ou non...

Tu ne peux donc pas réellement te baser sur le fait qu'une fonction n'utilise que deux valeurs et trois calcul pour voir s'il est oui ou non intéressant de le faire, à moins de savoir pertinemment la manière dont le calcul sera transformer en instruction assembleur

Mais, ceci dit, il faut savoir que de nombreux outils de profiling éprouvent des problèmes avec les fonctions inline et que, de toutes manières, la perte de temps due à l'empilement des appels tient en définitive à quelques cycles d'horloges...

Et comme il y a malgré tout certaines restrictions à l'inlining comme les fonctions membres virtuelles ou certaines fonctions récursives et que même un simpel accesseur peut en faire plus que ce que l'on pourrait croire (parfois par simple distraction du programmeur), je pense sincèrement qu'il est préférable d'attendre d'être en mesure de constater "sur pièce" qu'une fonction présente un réel goulot d'étranglement et de commencer par retravailler l'algorithme (qui peut remonter bien haut ) avant de décider d'inliner une fonction

En effet, si tu te trouve dans une situation proche de

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 fonctionA()
{
    /* très petite fonction qui pourrait être inlinée */
}
void fonctionB()
{
    for(int i=0;i<1000;++i)
        fonctionA();
}
void fonctionC()
{
    for(int i=0;i<1000;++i)
        fonctionB();
}
/* on pourrait continuer ainsi longtemps :D */

Le gain occasionné par le fait de simplement pouvoir éviter 100 fois d'appeler fonctionB dans la boucle de fonctionC sera autrement plus important que celui occasionné par l'inlining de fonctionA() et le fera passer pour superflu, ou peu s'en faut

car, si l'inlining de fonctionA te permet effectivement de gagner un million de fois quelques cycles d'horloges, le seul fait de n'invoquer que 900 fois fonctionB (et donc 900 000 fois fonctionA) t'en fera gagner bien plus... surtout si la boucle n'est qu'une partie de la logique
Pour la petite histoire,gcc par exemple permet de définir le nombre de pseudo instructions en dessous duquel il doit garder une fonction inline

[koala01]

Mais c'est vrai qu'on est habitué à ce mot-clé, qu'on est conditionné quelque part à l'utiliser sur des classes un peu sensibles (au même titre qu'on est conditionné à ne pas utiliser goto), et alors, ne pas lire "inline" peut faire germer le petit doute "et si le compilo n'optimisait pas ma petite classe sensible ?

Je reste convaincu que d'un point de vue purement technique, c'est du bidon et que les vrais problèmes d'optimisation sont ailleurs que dans l'inlining de quelques getters,

Moi aussi

mais je reconnais maintenant que ça permet de se donner une bonne conscience (ça va un peu dans le sens de la remarque de metagoto sur l'intention du programmeur),

J'aurais presqu'envie de dire "pourquoi devoir se donner bonne conscience", mais je dirai plutôt:

Ca permet d'indiquer l'intention du programmeur... Mais est-ce suffisant pour rassurer sur ce que le compilateur fait effectivement

Après tout, c'est quand même lui qui a le dernier mot

de se rassurer en n'ayant pas à profiler le code en question pour être sûr que le compilo fait bien son boulot.

Je dirais plutôt que cela devrait nous obliger à vérifier que le compilo fait bien son boulot...

Une fonction sensée être inlinée et qui ne l'est en réalité pas posera sans doute beaucoup plus de problèmes de performances que l'inverse (à moins que la taille de l'exécutable ne soit le problème principal du projet )

A moins que, au contraire, ce soit l'occasion de tester et vérifier par soi même que le compilo sait très bien gérer ça et que inline est véritablement devenu inutile... je testerai si je suis embauché !

Tiens nous au courent

Ce qui me gêne toujours avec ce mot-clé, c'est que selon moi il procure une fausse bonne conscience et détourne des véritables sujets d'optimisation en encourageant le développeur à se focaliser sur des setter / getter au lieu de se pencher sur sa gestion mémoire par exemple. Car concrètement, au même titre que l'on ne prend pas le temps d'évaluer l'auto-inlining du compilateur, on ne le prend pas de mesurer le véritable gain de tous ces inline que l'on met partout. Peut-être que ça ne produit aucun résultat visible alors que ça alourdit le code source. C'est grosso-modo ce que j'ai voulu exprimer dans mon premier message.

+1...

Le mot clé inline ne fait que demander au compilateur de remplacer l'appel de la fonction par son implémentation, alors qu'il reste (à peu près) libre de décider de le faire ou non.

Je ne nie absolument pas qu'il ait pu être intéressant aux temps des pionniers ou le moindre cylce comptait, mais j'ai la conviction qu'il est largement préférable de pouvoir mesurer l'impact réel de l'inlining d'une fonction plutôt que d'en mettre partout.

Dans quelques cas particuliers, ce sera effectivement la "seule" chose à faire, dans tous les autres, cela généralement à vouloir faire ce qui se trouve au numéro 97 d'une liste de priorités alors que l'on en est qu'au numéro 5

[loufoque]

C'est toujours d'actualité, si la fonction n'est pas inline et se situe dans un fichier d'entête, on aura des problèmes à l'édition de liens.

[metagoto]

C'est toujours d'actualité, si la fonction n'est pas inline et se situe dans un fichier d'entête, on aura des problèmes à l'édition de liens.

+1

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grep -r ^inline boost_1_39_0/boost | wc -l

+6187

Ca a son utilité, surtout pour les librairies headers-only. Et oui, je suis globalement d'accord avec ceux qui pensent que le compilo sait et fait mieux son job que le programmeur. Mais ça n'est qu'une facette de l'utilité du mot-clé inline. Matthieu Brucher a fait cependant une judicieuse remarque, le fait qu'une spécialisation complète (de function template) puisse être définie dans sa propre translation unit avec un linkage externe. Mais pour du header-only, ou du partial specialization, on n'a guère le choix.

En résumé (selon moi):
+1 pour controller le linker
+0 pour controller le compiler
---
+1