Version imprimable
Je me demandais : pourquoi ne pas mettre toutes les methodes d'une classe systematiquement en "inline" (si elle peuvent l'etre)pour gagner en perfs? puisque si je comprends bien, le compilateur choisit lui meme de vraiment remplacer le contenu de la methode a chaque endroit ou celle ci est appelée, ou non.
Bien evidemment il doit y avoir une raison (temps de compilation ? taille du code generé ?) mais je ne suis pas sur.
Une idée?
Parce que, entre autres, l'inlining peut devenir couteux en perfs si la fonction qui utilise la fonction inlinée devient trop grosse pour tenir dans le cache : D'ou, l'effet inverse de celui espéré...
Effectivement ça peut allonger considérablement le temps de compilation.
Mais surtout on n'a pas forcément envie de dévoiler le code source, ce qui serait le cas si on le mettait intégralement dans les en-têtes.
Je n'ai personnellement encore jamais rencontrer ce phénomène et pourtant je force beaucoup d'inlines pour des fonctions vraiment grosses (parfois appelées qu'à un seul endroit dans le code, mais néanmoins appelées fréquemment dans un calcul). Et justement si je laisse faire le compilo à sa guise, il ne les inline pas et ça s'en ressent sérieusement sur les perfs de parties critiques.Citation:
Envoyé par Médinoc
Perso, j'indique toujours explicitement comme inlinable les fonctions désirées (même quand quand la fonction est entièrement définie dans la classe, ce qui peut paraître à première vue inutile). Ca me permet de moduler la signification du mot clé avec des '#define'.
Exemple:
Ceci dit, je suis toujours à la recherche du moyen pour forcer l'inline sur GCC qui n'en fait décidément qu'à sa tête (la version 3.4 en tout cas, je ne peux pas encore tester la version 4 sous Windows...), et refuse fréquemment de suivre mes consignes.Code:#define inline __forceinline //pour ICL et VC
'__inline' ou '__attribute__((__always_inline__))' n'y changent rien.
Alors je profite de ce topic pour demander si quelqu'un connaît le moyen de forcer GCC à inliner les fonctions désirées. (je ne parle pas de fonctions récursives ou virtuelles ou que sais-je encore..)
Salut,
Il ne faut pas non plus oublier que, dans le cadre d'un arbre d'héritage impliquant une classe abstraite, le compilateur va rechercher la premiere fonction virtuelle non inline de chaque classe lors de l'édition de liens...
Si, d'une manière ou d'une autre, toutes les fonctions membres sont virtuelles et inline (car rien n'empeche d'inliner une fonction virtuelle :P), tu va te retrouver avec une référence sur la vtable de la classe indéfinie à l'édition de liens :P
Je vous livre donc cette réflexion pour ce qu'elle vaut mais, en prenant en compte que
- Le gain de temps théorique d'une fonction inlinée est relativement faible ( largement > 0.0000001 sec/exécution sur les processeurs actuels)
- certaines fonctions ne peuvent pas etre valablement inlinée ( les fonctions récursives, par exemple)
- le compilateur reste libre d'effectivement inliner ou non une fonction qu'on a définie inline, et peut tres bien "selon l'humeur du moment" décider, pour une meme fonction, d'inliner certains de ses appels et pas d'autres
- on peut, si on n'y prend pas garde, en arriver à avoir des références indéfinies sur la vtable
j'aurais principalement plutot tendance à partir du principe qu'il est préférable, hormis pour les applications devant réellement fonctionner en temps réel, de partir d'une version de code dans lequel aucune fonction n'est inlinée et de ne décider d'inliner que celles pour lesquelles un benchmark correct et vérifié (plutot deux fois qu'une) prouve incontestablement qu'il y a gain de performances :P
J'ajouterai même que:
Trop de inline implique plus de code, et donc plus de place prise dans le cache, et donc plus de chargement de cache. Si A est une grossse fonction, et qu'elle appelle 4x B (pas dans une boucle) et que B est suffisemment gros, alors A ne tient plus entierement dans le cache (d'instruction), alors que A+B (non inline) aurait pu l'être.
De toute maniere, le compilo peut très bien ne pas tenir compte du "inline" (par exemple si la fonction est récursive, ou virtuelle), et donc le code généré identique à celui sans inline.
Dans l'autre sens, avec les options d'optimisation ad-hoc, le compilo peut très bien "inliner" une function qui n'est pourtant pas déclarée inline.
Personnellement, je n'ai jamais de fonction inline, à part les setters/getters, les fonctions de calcul direct (genre la surface d'une rectangle), ou les délégations. En bref, rien que ne tienne sur une ligne ! :D
Personnellement je n'utilise pas inline en dehors de templates spécifiques, je préfère laisser mon optimiseur s'en charger à l'édition de liens. (malheureusement, mon compilateur n'optimise pas à l'édition de liens)
Bonjour, j'apporte ma petite pierre à l'édifice:
j'ai programmé un moteur de jeu d'échec, et bien entendu, il doit calculer très vite la génération de coups possibles, si l'on veut qu'il soit performant.
Je suis tombé dans le panneau du 'beaucoup de lignes de programme en inline'. En effet le code extrait de la RAM était toujours différent ( puisque issu de lignes mémoire différentes ), ce qui fait que la mémoire cache ne pouvait pas rendre service.
De plus, comme le code contenait des tests, la prédiction de branchement ne fonctionnait pas puisqu'elle découvrait à chaque fois de nouvelle adresses de branchement.
En résumé le programme était moins performant qu'une fonction appelée plusieurs fois, mais située au même emplacement mémoire.
Donc en ce qui me concerne, l'inline n'est utilisé qu'avec des fonctions de quelques lignes, et si possible sans test.
Evidemment, je vous parle d'une époque où le processeur possédait 4kO de cache pour le code, et 4 kO de cache pour les données, et où la carte mère possédait au maximum, 256kO de cache de second niveau.
Aujourd'hui la technologie à bien changé...
Merci pour toutes ces contributions, c'est tres interessant.
En revanche, je ne comprends pas bien la phrase ci-dessous : en quoi consiste la prédiction de branchement (un test n'est-il pas évalué entierement?) et quel rapport avec l'inlining ?
Citation:
Envoyé par rtg57