Discussion :

[Mac LAK]

Certains compilateurs (Visual et il me semble aussi gcc) ont des directives de compilation pour forcer l'inlining.

Oui, mais pas tous... Et cela ne change en rien le fait que le mot-clé inline (pas celui spécifique, donc) ne garantit pas l'inlining.

Euh... Il faut arrêter avec le craquage du "on sait pas quand ce sera inliné". Une fonction d'une ligne, elle sera sans doute inliné sans le mot clé inline, mais avec, c'est *certain* que ce sera inliné, avec n'importe quel compilo.

Non. Cela dépend de son contexte d'appel.

Et il faut aussi se rappeler que quand le compilo n'inline pas une fonction marquée inline, c'est qu'il en a de très très bonne raisons. Il faut se souvenir que savoir s'il est intéressant d'inliner une fonction ne dépend pas juste de sa taille.

Non, cela dépend surtout du nombre de registres utilisés/utilisables, et ce nombre est particulièrement faible sur des processeurs CISC. Cela dépend aussi d'autres réglages du compilateurs qui peuvent entrer en conflit avec un inlining.

Bref, les risques pris par l'utilisation d'une macro qui utilise deux fois son argument comparé à l'utilisation d'une fonction inline qui a 99% de chance de se retrouver inliné ne valent vraiment pas le coup.

Les macros, c'est comme le feu : si tu fais n'importe quoi avec, notamment en croyant que c'est une fonction, tu te brûles. Cela ne remet pas en cause l'outil lui-même, mais celui qui l'utilise.

Exactement. Ca fait un bon moment qu'il faut arreter de penser que l'on peut battre un compilo à son propre jeu.

Faut arrêter d'entrer en développement comme on entre en religion. Un compilateur n'est qu'un programme, qui fait ce qu'on lui dit de faire, comme on lui dit de le faire. Il n'a pas d'intelligence, et ne peut en aucun cas connaître à l'avance tous les tenants et aboutissants d'un programme en cours de compilation.

Tu devrais arrêter un peu tes professions de foi, je pense, et te pencher un peu sur des cas concrets d'optimisation réellement poussée... Et non pas laisser faire la machine avec une foi tellement absolue qu'elle en devient risible. Comme le dit François, battre la machine n'est pas très difficile, ne serait-ce que parce qu'elle n'a pas de notion du chemin dynamique du programme.

Mais encore faut-il s'être un jour penché sur le sujet pour le comprendre...

[TropMDR]

Rien en garantit donc que le compilateur prendra, dans ce cas précis, la bonne décision.

Parce que toi oui ? Tu te bases sur quoi pour savoir qu'une fonction doit être inliné, quelque soit l'endroit où elle est appelé, mais surtout quelque soit l'architecture ? Tu connais le rapport entre le coût d'un appel de fonction et le coût d'une augmentation de la taille du code, quelque soit l'archi ? Genre entre un x86 ou quasiment tous les arguments passent forcément par la pile, ou un amd64 ou on peut rester intégralement en registres ?

Non. Cela dépend de son contexte d'appel.

Je veux bien un "contexte d'appel" où la fonction dont on parle n'est pas inliné. Pour qu'on arrête de parler dans le vent sur le mode du "non mais sérieux, c'est trop possible qu'elle soit pas inliné"

Les macros, c'est comme le feu : si tu fais n'importe quoi avec, notamment en croyant que c'est une fonction, tu te brûles. Cela ne remet pas en cause l'outil lui-même, mais celui qui l'utilise.

Je ne remets pas en cause le fait que les macros soient utiles, quand on doit effectivement faire du remplacement textuel. En revanche, programmer avec des macros, c'est mal utiliser ses outils puisqu'on a les fonctions inline qui font pareil, mais en mieux.

Un compilateur n'est qu'un programme, qui fait ce qu'on lui dit de faire, comme on lui dit de le faire.

Oui enfin... Il faut surtout ce que lui disent de faire ses concepteurs, qui ne sont généralement pas de complets gignols et ont quelques notions de... compilation justement ! Et d'optimisation.

Il n'a pas d'intelligence, et ne peut en aucun cas connaître à l'avance tous les tenants et aboutissants d'un programme en cours de compilation.

Ca veut dire quoi "pas d'intelligence" ? Pour quelqu'un qui se dit programmeur chevronné, nous dire qu'on programme ne fait rien de bien parce qu'il n'a "pas d'intelligence", c'est quand même assez incroyable ! Tu vas nous dire qu'un programme ne peux pas reconnaitre un visage parce qu'il n'a "pas d'intelligence", qu'un programme ne peux pas résoudre une système linéaire parce qu'il n'a "pas d'intelligence", qu'un programme ne peut pas prédire le temps qu'il fera demain, parce qu'il n'a "pas d'intelligence" ? C'est n'importe quoi...

Tu devrais arrêter un peu tes professions de foi, je pense, et te pencher un peu sur des cas concrets d'optimisation réellement poussée...

Genre quoi ? la fusion de nid de boucles ? La propagation des constantes ? Le découpage en tuiles ? La réductions de force ? Celle des variables d'inductions ? Le pipeline logiciel ? Le lazy code motion ? L'élimination des sous expression communes ?

Et non pas laisser faire la machine avec une foi tellement absolue qu'elle en devient risible. Comme le dit François, battre la machine n'est pas très difficile, ne serait-ce que parce qu'elle n'a pas de notion du chemin dynamique du programme.

Les compilos itératif, ça existe, surtout pour l'embarqué aux perfs critiques que tu sembles tant chérir

Mais encore faut-il s'être un jour penché sur le sujet pour le comprendre...

Hihi

[Mac LAK]

Je ne remets pas en cause le fait que les macros soient utiles, quand on doit effectivement faire du remplacement textuel. En revanche, programmer avec des macros, c'est mal utiliser ses outils puisqu'on a les fonctions inline qui font pareil, mais en mieux.

Non, pas "en mieux". Les fonctions inline résolvent un des problèmes des macros (les paramètres modifiés par répétition), et introduisent un problème à la place (le fait que l'inlining ne soit pas toujours possible).

Oui enfin... Il faut surtout ce que lui disent de faire ses concepteurs, qui ne sont généralement pas de complets gignols et ont quelques notions de... compilation justement ! Et d'optimisation.

Ils ne peuvent pas prévoir tous les cas de figure, ne serait-ce que par ce qu'ils ne peuvent pas estimer la criticité d'un code ou son profil d'exécution.

S'ils le pouvaient, des systèmes comme PolySpace ou autres Coverity ne serviraient à rien. Or, ils sont très utiles (et très utilisés).

Ca veut dire quoi "pas d'intelligence" ?

Qu'un ordinateur n'est pas intelligent, même avec un programme d'IA. Il calcule vite, c'est tout. Prends un dictionnaire pour regarder la définition du mot "intelligence".

Genre quoi ?

Genre prendre un programme et lui faire gagner 10% de perfs sans changer ni le matériel, ni les algos sous-jacents, ni le compilateur, ni les réglages dudit compilateur.

Les compilos itératif, ça existe, surtout pour l'embarqué aux perfs critiques que tu sembles tant chérir

En dix ans d'embarqué, c'est amusant, mais je n'en ai pas vu un seul... On en parle, bien sûr, mais comme toute technologie, elle devra auparavant être validée et éprouvée avant d'être utilisée dans l'industrie. En attendant, on profile le code et on sait aussi ce que l'on écrit.

Et je pense que ça rassure pas mal de gens de savoir que les avions, les trains ou les voitures ne sont pas validés avec des softs en version alpha et/ou en cours de stabilisation. Si l'on n'utilise pas les dernières technos à la mode, il y a une bonne raison : nos clients nous l'interdisent formellement. Seules les technologies pouvant justifier de plusieurs millions (voire milliards...) d'heures de bon fonctionnement peuvent être utilisées.

[Invité]

Parce que toi oui ? Tu te bases sur quoi pour savoir qu'une fonction doit être inliné, quelque soit l'endroit où elle est appelé, mais surtout quelque soit l'architecture ? Tu connais le rapport entre le coût d'un appel de fonction et le coût d'une augmentation de la taille du code, quelque soit l'archi ? Genre entre un x86 ou quasiment tous les arguments passent forcément par la pile, ou un amd64 ou on peut rester intégralement en registres ?

Moi? Je teste, j'utilise un profileur, je fais mon boulot d'ingénieur...
Il n'y a rien de magique, tout se mesure, tout se teste.

"Quelle que soit l'architecture", c'est atrocement prétentieux. Je teste sur les architectures qu'utilisent mes clients, point barre... La portabilité sur une machine qui n'existe pas dans mon monde, je m'en bats un peu l'oeil...

Mais l'approche fonctionne, et ce qui la cautionne, c'est qu'on vend nos programmes

Francois

[TropMDR]

Moi? Je teste, j'utilise un profileur, je fais mon boulot d'ingénieur...
Il n'y a rien de magique, tout se mesure, tout se teste.

Donc l'approche que tu suggères, c'est d'écrire une fonction non inline, et d'écrire une macro (donc certaine d'être "inlinée"), et de tester les deux à chaque fois ?

[Invité]

Donc l'approche que tu suggères, c'est d'écrire une fonction non inline, et d'écrire une macro (donc certaine d'être "inlinée"), et de tester les deux à chaque fois ?

Non. Ce que je dis c'est que *quand* il faut optimiser le code, on regarde souvent la possibilité d'inliner, ou de refondre certaines boucles appelées très souvent. On le fait parce que, bien souvent, ca marche.

Du coup, dans des modules relativement simples et isolés, et qui n'ont pas vocation à évoluer, écrire des macros dès le départ (en sachant que cela comporte des risques) est souvent un gain de temps, car cela évite de se poser la question un peu plus tard.

Maintenant, mettre des macros n'importe où, c'est idiot, parce que ca rend le code difficile à lire et à maintenir. Mais ce n'est pas une raison pour les interdire entièrement (au passage, je pense la même chose des goto, des constantes magiques, des casts, de plein de choses)

Comme souvent, c'est une affaire de jugement, qu'on laisse au programmeur, réputé intelligent.

Francois

[TropMDR]

Non. Ce que je dis c'est que *quand* il faut optimiser le code, on regarde souvent la possibilité d'inliner, ou de refondre certaines boucles appelées très souvent. On le fait parce que, bien souvent, ca marche.

Justement ! L'intérêt du mot clé inline, c'est bien ça : pour passer d'une fonction "normale" à une fonction "inlinée", il suffit d'un mot clé. Pour les macros, c'est bien plus lourd (il faut entre autre changer la casse )

Mais pour arrêter de parler dans le vent, j'aimerais *un* exemple d'une fonction et d'un contexte d'appel avec les propriété suivante :

1. La fonction est marquée inline
2. elle est suffisamment "petite" pour qu'on puisse l'écrire comme une macro
3. mais même avec une option d'optimisation raisonnable du compilo (c'est à dire qui active l'inlining), elle n'est pas inliné alors qu'elle devrait l'être

Parce que l'argument pour les macros/contre les fonctions inline, c'est qu'il se pourrait que ce ne soit pas inliné. Mais n'est ce pas un risque purement théorique ?

[3DArchi]

au passage, je pense la même chose des goto, des constantes magiques, des casts, de plein de choses

des goto, ça doit quand même faire plus de 20 ans que je ne vois personne les prôner ou même les avouer. Tu vas un peu fort, non ?
Sinon, je ne suis jamais intervenu dans une petite structure avec peu de développeurs internes et pérennes. La problématique de la maintenance et l'évolution par d'autres intervenants a toujours été une composante forte : le genre de projet où il n'y a pas de transmission de l'"intelligence" du tabou qu'on peut violer. Par conséquent, introduire des goto (je prends exprès car c'est celui qui m'a le + interpellé), même intelligemment, même bien documenté, itou, itou, c'est prendre le risque d'une diffusion de mauvaises pratiques par effet de mimétisme (puisque ça existe déjà, pourquoi s'en priver ?). Peut-être ces différentes pratiques sont elles liées aussi à des contextes projets trop différents ?

[Invité]

Je me souviens qu'il y a eu un fil sur les goto il y a quelques mois, où finalement, pas mal de monde en avouait un ou deux...

Juste pour préciser... Dans ma carrière, des goto (en C ou C++), j'ai dû en écrire trois ou quatre, donc oui, c'est complètement exceptionnel. Mais j'ai utilisé pas mal de code où il y en avait. Globalement, je peux imaginer des cas où ils sont pratiques, parce qu'ils améliorent la lisibilité du code, mais ils sont très rares. Je ne crois pas non plus à l'idée que cela pourrait "contaminer" notre belle jeunesse : les goto, c'est un peu le croquemitaine des programmeurs, tout le monde en a peur, le risque est donc très faible.

Ce que j'essaie de dire, c'est que j'ai tendance à privilégier la lisibilité du code sur son côté "défensif" (vis à vis d'autres programmeurs). Quand on écrit des choses complexes (dans du code "bateau", cela n'a aucune importance) un code simple, même "casse gueule" me parait toujours préférable à quelque chose de plus correct, mais bavard et moins lisible.

Inversement, je suis extrèmement méfiant vis à vis des constructions "correctes" qui se traduisent par des choses lourdes à lire ou à débuguer. La lourdeur se caractérisant pour moi par la longueur des phrases ou des idiomes (je n'ai aucun mal avec les notations abstraites et compactes, façon APL). C'est probablement mon principal problème avec des bouts du C++ moderne et des design pattern. Et je trouve ces approches (qui souvent complexifient gratuitement des concepts simples, en essayant de les rattacher à des 'abstractions connues') bien plus contaminantes que les goto.

Je conviens volontiers que c'est une approche de PME, et typique de milieux où l'on travaille avec de petites équipes, et souvent des programmeurs ayant un bagage scientifique. Je crois qu'on essaye, en fait, de retrouver la concision du langage mathématique, parce que c'est le mode d'abstraction qui nous convient.

Francois

[Joel F]

@fcharton: si je profile mais je profile dans les cas ou le code généré ne respecte pas ma spec (ou celle du client). Je bosse aussi sur des outils d'aide à la parallélisation automatique et souvent, je m'aperçois que une idée d'optimisation poussé qui me semblait bonne est faite toute seul par de gros compilo genre icc récent etc. Je ne dis pas qu'il faut jamais le faire, tout comme je n'entre pas en profession de foi. Mais encore une fois, ce que certains ne comrpennent pas, c'est que ce cas de figure est celui de la majorité des gens, et non d'une minorité. Pour faire comme certain, je vais aussi m'étaler. J'ai fait une thése sur de la vision par ordinateur parallèle temps réelle sur cluster et multi-coeur, j'ai 2 outils de parallèlisation automatique qui cible ces archis et plus (genre processeur cell et gpu) et qui sont utilisés par de vrais gens (genre on a eu des contrats de recherche avec Thales et le CEA la dessu), j'ai fait du MMX/SSE2+ et de l'AltiVec depuis mon DEA. Alors oui je sais de quoi je parle ...

Maintenant, pour faire avancer le débat, il serait de bon aloi de prendre ce fait pour acquis (comme la montré je ne sais qui dans le topic fils sur la STL). Aprés, oui je suis d'accord avec vous: sur des archis exotiques avec des compilateurs middle (et dieu sait que j'en ai chié à faire du C++ avancée avec g++ 2.95.2) voir atroces (icc 6 ou -), oui il faut se palucher ce genre de truc, et je le fait. Sauf que c'est 1% de mon temps voire moins.
C'est tout ce que j'aimerais que vous compreniez

[Invité]

Alors oui je sais de quoi je parle ...

Je n'en ai jamais douté, j'espère que je ne vous ai pas donné cette impression (je vous rassure, je ne déballererai pas mon CV...).

C'est tout ce que j'aimerais que vous compreniez

Je pense que tout le monde s'est compris, et au fond je crois qu'on est tous d'accord. En fait, je crois que la plupart des défenseurs des macros, sur ce fil, n'en écrivent pas tant que cela, et que la plupart de leurs opposants s'en sont déjà rendu coupables.

On est plus dans le domaine des réactions épidermiques aux "fais pas ca" qu'on nous assène parfois un peu beaucoup en informatique...

Francois, sans rancune.

[Joel F]

Francois, sans rancune.

Y a pas de soucis :o

[TropMDR]

Bon, vous arrêtez de vous faire des papouilles les deux là ? :-p

Plus sérieusement, la question plus haut n'était pas là juste pour mettre les gens en difficulté, c'est que j'aimerais *vraiment* savoir à quel point c'est un mythe le coup du "le compilo peut ne pas inliner" (je sais pertinemment que tous les compilos s'autorisent à le faire, je voudrais juste être sûr que ça arrive vraiment, dans la vraie vie.)

[Invité]

Plus sérieusement, la question plus haut n'était pas là juste pour mettre les gens en difficulté, c'est que j'aimerais *vraiment* savoir à quel point c'est un mythe le coup du "le compilo peut ne pas inliner" (je sais pertinemment que tous les compilos s'autorisent à le faire, je voudrais juste être sûr que ça arrive vraiment, dans la vraie vie.)

Je l'ai vu faire sur des compilateurs Borland (en mode release et tout ça), pour des fonctions assez longues, ou ayant un appel de fonction à l'intérieur, ou parfois des paramètres d'appels un peu nombreux. Dans l'exemple ci dessus, on le verrait peut être si les opérateurs [] de la matrice sont surchargés, ou si le type matrice passé en paramètre est un peu plus complexe qu'un tableau.

Ma conclusion, à l'époque, avait été que la décision d'inliner dépendait à la fois de la taille, mais aussi de la "linéarité" du code concerné. Un truc avec une boucle, un appel de fonction, ou des sauts pouvait n'être pas inliné.

En général, ca partait d'un bon sentiment de la part du compilateur, mais qui pouvait s'avérer faux dans des cas critiques (qui sont un peu les seuls qu'on regarde quand on profile : on ne parle pas des trains qui arrivent à l'heure...).

Francois

[Joel F]

la seule experience concluante (ie répétable et mesurable) c'est que souvent les fonctions avec du controle complexe (while, if imbriqués) ne passent pas l'inlining au dela d'un certain seuil de nombre de saut (certainement à cause de forward jump que le compilo à du mal à intégrer au site d'appel).

Par contre, le coup de l'operator[] j'ai du mal à y croire (ou alors à coir la tete du []). Y avait un PDF qui trainait sur le net ou un gars de chez Metrowerks comparait justement les sorties assembleurs de qqs compilateurs récents à ce qu'on pouvait écrire à la main et démontait justement pas mal de préjugés. Je poste le lien des que je le retrouve.

[Invité]

Par contre, le coup de l'operator[] j'ai du mal à y croire (ou alors à coir la tete du []).

Si la surcharge de [] est une indirection (on a une structure contenant un conteneur, et [] est surchargé pour renvoyer le "bon élément" du conteneur), ce qui doit être le cas le plus courant, il est certain que ce sera inliné. Le problème peut se poser quand on assigne à [] des missions plus complexes. Deux cas relativement fréquents :

- le conteneur a une implémentation complexe, que l'interface cache, et [] effectue en fait une recherche
- les éléments du conteneur sont initialisés lors de leur première utilisation, par []. Ce dernier cas est le cas typique du "piège à compilateur" : la fonction se compose d'une boucle d'initialisation, un peu complexe, mais très rarement appelée, et d'un code "de base" (un test une indirection) très simple et presque toujours appelé.

Il n'y a rien de mystérieux avec []. La seule chose "piégeuse", c'est qu'on a souvent tendance à considérer qu'un opérateur simple fait forcément un calcul simple...

Francois

[TropMDR]

Je l'ai vu faire sur des compilateurs Borland (en mode release et tout ça), pour des fonctions assez longues, ou ayant un appel de fonction à l'intérieur, ou parfois des paramètres d'appels un peu nombreux.

Et tu as testé ? Tu l'as mis en macro, et c'était vraiment plus rapide ? Parce qu'on peut clairement *perdre* des perfs à inliner des fonctions trop longues (les explications qui suivent ne sont pas pour les intervenants de cette discussions mais pour les lecteurs potentiels ).

Si on inline plusieurs fois une fonction, on duplique le code. On augmente donc la taille du code total, et on risque par exemple de sortir du cache instruction. Si j'ai une boucle serrée qui appelle une fois et à chaque tours une toute petite fonction, il sera sans doute rentable de l'inliner. Si la même boucle appelle 3 ou 4 fois une petite fonction, il est parfois rentable de faire les appels (qui sont cher, mais pas forcément tant que ça, surtout si on a peu d'arguments, qu'ils passent en registres parce qu'on en a plus que 8 (des registres) ), en restant dans le cache (on peut même imaginer que le prédicteur de branchement du proc profite de la réutilisation du même code). Donc la "bonne" décision n'est pas forcément purement locale, et les euristiques de l'inliner peuvent en tenir compte, alors qu'une fois que c'est une macro, c'est inliné, point barre. Plus de décision possible suivant le site d'appel.

Mais même si on n'appelle la fonction qu'une seule fois, ce n'est pas forcément une bonne idée de l'inliner ! J'ai eu le problème il y a peu avec GCC en écrivant une machine virtuelle (en C). J'avais plein de fonctions marquées inline qu'il inlinait bien, mais aussi une fonction assez grosse, mais appelé en un seul point du code, qu'il avait donc inliné de force (la fonction n'étant pas exporté, ça n'augmentait pas la taille totale du code). Sauf que cette fonction n'était appelé que rarement, et le fait de l'avoir inliné faisait sortir le corps de ma boucle du cache instruction. Après avoir réussi à convaincre GCC de ne PAS l'inliner, j'ai eu un gain de perf de presque 10%. Donc l'inlining peut vraiment avoir des effets très négatifs !

Bref, la version "fonction marquée inline" garde nettement plus de souplesse que la macro puisque la décision d'inliner ou non peut être prise (ok, par le compilo) suivant le site d'appel.

[Invité]

Et tu as testé ? Tu l'as mis en macro, et c'était vraiment plus rapide ? Parce qu'on peut clairement *perdre* des perfs à inliner des fonctions trop longues

Ben oui... En l'occurrence j'avais copié le code dans la boucle, mais tu conviendras que c'est rigoureusement égal à la macro. Et oui, le gain était réel.

Sur le fait que l'inlining n'est pas toujours bon, c'est une certitude. Une boucle centrale courte avec appels externes gagne très souvent contre une boucle longue avec appels inlinés, pour les raisons que tu cites. J'ai remarqué néanmoins que quand on allait dans le détail, ca devenait vite très compliqué, surtout quand on est en mode release, où la structure du code final peut dépendre assez fortement de l'ordre des instructions en entrée...

En fin de course, une fois qu'on a déterminé les points où le temps est passé, et qu'on n'a plus d'idées pour des améliorations algorithmiques (c'est généralement là que sont les vrais gains de performance), ca finit souvent par une séance d'essais et erreurs avec un profileur...

Ce que fait le compilateur, et qu'il fait bien, c'est de réduire le nombre d'endroits où il est nécessaire de profiler.

Francois