Discussion :

[Jean-Marc.Bourguet]

S'il y a bien quelque chose que je pensai fonctionnel c'était les fonctions inline puisque ça existe en C++.

gcc a le comportement du C++ (extern inline est une extension), pas celui du C99. Ne me demande pas pourquoi en C99 on n'a pas pris le comportement du C++...

[Jean-Marc.Bourguet]

A propos de l'inlining, j'ai découvert quelque chose de fort surprenant dans le code assembleur engendré par GCC (du moins la version 3.3) ; GCC fait bien plus que recopier bêtement la fonction : il est capable d'en connaître la sémantique et adapter le code assembleur produit au contexte d'utilisation de la fonction.

Les compilateurs essaient l'inliner assez tôt pour permettre ce genre de choses. La propagation des constantes dans du code inline peut avoir des effets époustouflants.

[InOCamlWeTrust]

Excuse-moi, mais je n'ai pas bien saisi ce que tu veux dire par "inliner tôt" et "propagation des constantes".

[Jean-Marc.Bourguet]

Excuse-moi, mais je n'ai pas bien saisi ce que tu veux dire par "inliner tôt" et "propagation des constantes".

Les compilateurs implémentent plusieurs optimisations (Munchnick dans Advanced Compiler Design and Implementation en donne une cinquantaine). De mémoire, on fait l'inlining assez tôt parce que c'est une optimisation qui a tendance à en permettre d'autres.

Propager les constantes, c'est déterminer quelles variables contiennent une valeur constante (même si l'expression n'est pas constante pour le langage) et remplacer la variable par la valeur. Dans le cas de paramètres de fonction, on peut parfois supprimer pas mal de code en faisant ça.

[benhoeil]

De plus, il ne faut pas oublier qu'en termes d'instructions machines quatre ou cinq empilements et un saut à une adresse donnée prennent encore moins de temps qu'une gestion de pile à la main.

mais justement, si j'ai bien compris, on ne gère pas du tout de pile en passant par une macro puisqu'on évite l'appel de fonction et que l'exécution suit son "cours normal". Donc à priori ça serait toujours ça de gagné.

Mais si ce que dis Jean-Marc est vrai (moi j'y crois !), ça ne serait pas grand chose de gagné.

Bon je passais simplement pour un petit merci pour toutes ces réponses !

[Thierry Chappuis]

Donc, pour faire une petite synthèse, actuellement encore, seul C89 assure une portabilité maximale. Microsoft a décidé de ne pas imlémanter la nouvelle norme, tandis que l'implémantation de GCC est incomplète (quelques retours d'expériences sur d'autres compilateurs tels que lcc ou d'autres?):

http://gcc.gnu.org/c99status.html pour le status de C99 dans GCC

En particulier, l'implémantation des fonctions inline par GCC ne respecte pas la norme C99 et possède le status "broken". Ainsi, l'utiliation du pré-processeur reste nécessaire pour optimiser des fonctions de taille raisonnable en économisant le surcoût des appels de fonction.

Médinoc ajoute que le passage par macro ne permet pas de vérification de type, et J-M Bourget ne pense pas que le surcoût engendré par des appels de fonction sont un handicap sur les processeurs actuels, et ne s'en inquiète pas. Supposons donc qu'on se limite à l'utilisation de C89. Compte tenu que les appels de fonctions semblent présenter un surcoût raisonnable en terme de performance, y a-t'il parmi vous des adeptes du "tout fonction" qui préfèrent systématiquement un appel de fonction (même mon inlinée) à l'utilisation d'une macro?

Merci encore pour vos réponses fort intéressantes et meilleures salutations

Thierry

[Jean-Marc.Bourguet]

En particulier, l'implémantation des fonctions inline par GCC ne respecte pas la norme C99 et possède le status "broken".

A noter qu'il est possible d'utiliser les fonctions inline de gcc de maniere compatible avec C99. C'est seulement quand on commence a jouer avec des particularites de la visibilite entre unites de compilation (la meme fonction inline dans un et pas dans l'autre) ou peut-etre des choses comme des variables statiques dans une fonction inline que ca joue un role.

Compte tenu que les appels de fonctions semblent présenter un surcoût raisonnable en terme de performance, y a-t'il parmi vous des adeptes du "tout fonction" qui préfèrent systématiquement un appel de fonction (même mon inlinée) à l'utilisation d'une macro?

Oui. Pour une autre raison: utiliser des fonctions non inline reduit le couplage (modifier l'implementation d'une fonction ne force pas a recompiler toutes les unites qui l'utilise). Passer a des fonctions inlines ou des macros c'est de l'optimisation. Rappel:

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
- W.A. Wulf

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

[Thierry Chappuis]

A noter qu'il est possible d'utiliser les fonctions inline de gcc de maniere compatible avec C99. C'est seulement quand on commence a jouer avec des particularites de la visibilite entre unites de compilation (la meme fonction inline dans un et pas dans l'autre) ou peut-etre des choses comme des variables statiques dans une fonction inline que ca joue un role.

Aurais-tu un exemple de code où la compatibilité est respectée et un autre où des problèmes évidents apparaissent avec GCC. Il faudra que j'étudie ça, car ça m'intéresse! (Au passage, quelqu'un connaît-il un compilateur qui implémente C99 dans sa totalité ...et quelqu'un y a-t'il une idée des raison lesquelles certains compilateurs ont décidé de ne pas implémanter cette norme).

L'usage intempestif de macros, c'est donc de l'optimisation prématurée et déconseillée aux débutants. Il est donc raisonnable de proner l'utilisation systèmatique de fonctions (non inlinées), même pour l'implémentation de fonctions de petite taille auxquelle on fait souvent appel, en tout les cas dans la phase préliminaire du codage.

Meilleures salutations

Thierry

[InOCamlWeTrust]

mais justement, si j'ai bien compris, on ne gère pas du tout de pile en passant par une macro puisqu'on évite l'appel de fonction et que l'exécution suit son "cours normal". Donc à priori ça serait toujours ça de gagné.

Mais si ce que dis Jean-Marc est vrai (moi j'y crois !), ça ne serait pas grand chose de gagné.

Bon je passais simplement pour un petit merci pour toutes ces réponses !

Je parlais de la vraie récursivité VS récursivité "gérée à la main" avec pile logicielle.