Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec
le mot-clé "inline", ou définies dans le corps d'une classe), et de
leur influence sur la taille et la vitesse d'exécution de
l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper
de ce genre de détails, puisque, de toutes façons, c'est au
compilateur de décider si une fonction doit effectivement être inline,
suivant des considérations (capacités et architecture du processeur)
qui échappent au programmeur.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Marc Boyer
Le 04-09-2007, Fabien LE LEZ a écrit :
Bonjour,
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
Pour faire simple.
-- A.hpp -- class A { public: int foo(); };
-- A.cpp -- A::foo(){ return 47; }
-- main.cpp -- #include "A.hpp" int main(){ A a; return a.foo(); }
Quand le compilo compile main.cpp, il ne 'voit' pas le code de a::foo, et ne peut donc pas faire la substitution.
De plus, même quand le compilo peut faire la substitution, il reste de son ressort de décider ou non de la faire. Donc, en effet, c'est " au compilateur de décider", comme tu le dis.
Après, le programmeur doit il se soucier de performance ? Ben, oui et non... Quand j'écris une moulinette d'entrée à un code prévu pour tourner des heures voire des jours, que la moulinette tourne 0,1s ou 0,3s n'a aucune importance. Mais la routine de base, elle, faudra la regarder de prêt.
Marc Boyer
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Le 04-09-2007, Fabien LE LEZ <gramster@gramster.com> a écrit :
Bonjour,
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec
le mot-clé "inline", ou définies dans le corps d'une classe), et de
leur influence sur la taille et la vitesse d'exécution de
l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper
de ce genre de détails, puisque, de toutes façons, c'est au
compilateur de décider si une fonction doit effectivement être inline,
suivant des considérations (capacités et architecture du processeur)
qui échappent au programmeur.
Qu'en pensez-vous ?
Le compilateur ne peut substituer l'appel à une fonction par
son code que s'il a le code à disposition. Généralement, c'est
le compilateur qui fait la substitution, pas l'éditeur de lien.
Pour faire simple.
-- A.hpp --
class A {
public:
int foo();
};
-- A.cpp --
A::foo(){ return 47; }
-- main.cpp --
#include "A.hpp"
int main(){
A a;
return a.foo();
}
Quand le compilo compile main.cpp, il ne 'voit' pas le code
de a::foo, et ne peut donc pas faire la substitution.
De plus, même quand le compilo peut faire la substitution,
il reste de son ressort de décider ou non de la faire. Donc, en
effet, c'est " au compilateur de décider", comme tu le dis.
Après, le programmeur doit il se soucier de performance ?
Ben, oui et non... Quand j'écris une moulinette d'entrée
à un code prévu pour tourner des heures voire des jours,
que la moulinette tourne 0,1s ou 0,3s n'a aucune importance.
Mais la routine de base, elle, faudra la regarder de prêt.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
Pour faire simple.
-- A.hpp -- class A { public: int foo(); };
-- A.cpp -- A::foo(){ return 47; }
-- main.cpp -- #include "A.hpp" int main(){ A a; return a.foo(); }
Quand le compilo compile main.cpp, il ne 'voit' pas le code de a::foo, et ne peut donc pas faire la substitution.
De plus, même quand le compilo peut faire la substitution, il reste de son ressort de décider ou non de la faire. Donc, en effet, c'est " au compilateur de décider", comme tu le dis.
Après, le programmeur doit il se soucier de performance ? Ben, oui et non... Quand j'écris une moulinette d'entrée à un code prévu pour tourner des heures voire des jours, que la moulinette tourne 0,1s ou 0,3s n'a aucune importance. Mais la routine de base, elle, faudra la regarder de prêt.
Marc Boyer
-- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Sylvain Togni
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font de l'optimisation globale, au moment de l'édition de liens donc et prennent en compte des données de profiling pour, par exemple, décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité. Et c'est une bonne chose, ce genre de détail est dans l'absolue du ressort du compilateur, pas du programmeur.
-- Sylvain Togni
Le compilateur ne peut substituer l'appel à une fonction par
son code que s'il a le code à disposition. Généralement, c'est
le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font
de l'optimisation globale, au moment de l'édition de liens donc
et prennent en compte des données de profiling pour, par exemple,
décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité.
Et c'est une bonne chose, ce genre de détail est dans l'absolue
du ressort du compilateur, pas du programmeur.
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font de l'optimisation globale, au moment de l'édition de liens donc et prennent en compte des données de profiling pour, par exemple, décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité. Et c'est une bonne chose, ce genre de détail est dans l'absolue du ressort du compilateur, pas du programmeur.
-- Sylvain Togni
espie
In article <46dd2a17$0$21148$, Sylvain Togni <"sylvain.togni at visionobjects.com"> wrote:
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font de l'optimisation globale, au moment de l'édition de liens donc et prennent en compte des données de profiling pour, par exemple, décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité. Et c'est une bonne chose, ce genre de détail est dans l'absolue du ressort du compilateur, pas du programmeur.
Pas vraiment d'accord. Pas a 100% en tout cas. Ce qui est clair, c'est qu'il faut une fluidite du code: ca doit etre facile de faire du code inline ou pas. Ce qui est clair aussi, c'est que c'est une optimisation `tardive'. Normalement, on fait d'abord tout ce qui est design, et on rajoute les inline seulement lorsqu'ils deviennent necessaires, ou au moins lorsqu'on a un programme suffisamment `figee' pour qu'on puisse faire les mesures qui vont bien.
Apres, ca depend pas mal du niveau de sophistication du developpeur, et pas mal aussi du type de programme developpe.
Le probleme de determination des inline est un probleme dur. Au moins NP complet, et peut-etre meme exponentiel. Le compilateur pourra juste, dans le meilleur des cas, faire du profile-based, ce qui implique d'avoir des bonnes suites de test. Et meme, ca ne correspond PAs forcement a l'environnement global du systeme: faire tourner un programme le plus vite possible, soit. Mais si on bouffe toute la memoire du systeme, on plombe les perfs lorsqu'on est sur un systeme multitache et qu'on utilise le systeme en production... et comme le cahier des charges d'un compilo inclut souvent `faire aussi bien que les voisins sur les SPECmarks', le mieux peut etre l'ennemi du bien !
Bref, les heuristiques du compilo ne seront jamais aussi bonnes que la personne qui les a pondu, qui doit resoudre le probleme tordu d'optimiser n'importe quoi comme code de facon correcte pour a peu pres tout le monde. Sans compter que les compilo ne comprennent pas forcement certains codes tordus, ou vont faire des optimisations qui marchent bien sur le papier mais s'appliquent mal a un cas donne (je pense a du code tres dynamique contenant des plugin, par exemple). Ou alors, pensez a du code prevu pour tourner sur un systeme embarque, ou la taille memoire est souvent assez serree, et le processeur pas tres puissant: chaque inline compte alors bien plus.
Les choses evoluent, bien sur... mais on peut encore gagner quelques pourcents en qualite sur la totalite des cas, et beaucoup plus sur des cas tordus, en `repassant' par derriere le compilo pour affiner les choses.
Bon, apres, on sait que inline est de toutes facons un indice pour le compilateur, et pas une obligation (difficile d'inliner tout le code sans faire exploser la memoire, par exemple), mais il faut quand meme faire le tri, entre les compilo qui disent choisir pour vous pour de meilleures perfs, et ceux qui choisissent pour eux les quelques cas qu'ils savent gerer...
In article <46dd2a17$0$21148$7a628cd7@news.club-internet.fr>,
Sylvain Togni <"sylvain.togni at visionobjects.com"> wrote:
Le compilateur ne peut substituer l'appel à une fonction par
son code que s'il a le code à disposition. Généralement, c'est
le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font
de l'optimisation globale, au moment de l'édition de liens donc
et prennent en compte des données de profiling pour, par exemple,
décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité.
Et c'est une bonne chose, ce genre de détail est dans l'absolue
du ressort du compilateur, pas du programmeur.
Pas vraiment d'accord. Pas a 100% en tout cas. Ce qui est clair, c'est
qu'il faut une fluidite du code: ca doit etre facile de faire du code
inline ou pas. Ce qui est clair aussi, c'est que c'est une optimisation
`tardive'. Normalement, on fait d'abord tout ce qui est design, et on
rajoute les inline seulement lorsqu'ils deviennent necessaires, ou au
moins lorsqu'on a un programme suffisamment `figee' pour qu'on puisse
faire les mesures qui vont bien.
Apres, ca depend pas mal du niveau de sophistication du developpeur, et
pas mal aussi du type de programme developpe.
Le probleme de determination des inline est un probleme dur. Au moins
NP complet, et peut-etre meme exponentiel. Le compilateur pourra juste,
dans le meilleur des cas, faire du profile-based, ce qui implique d'avoir
des bonnes suites de test. Et meme, ca ne correspond PAs forcement a
l'environnement global du systeme: faire tourner un programme le plus vite
possible, soit. Mais si on bouffe toute la memoire du systeme, on plombe
les perfs lorsqu'on est sur un systeme multitache et qu'on utilise le
systeme en production... et comme le cahier des charges d'un compilo
inclut souvent `faire aussi bien que les voisins sur les SPECmarks', le
mieux peut etre l'ennemi du bien !
Bref, les heuristiques du compilo ne seront jamais aussi bonnes que la
personne qui les a pondu, qui doit resoudre le probleme tordu d'optimiser
n'importe quoi comme code de facon correcte pour a peu pres tout le monde.
Sans compter que les compilo ne comprennent pas forcement certains codes
tordus, ou vont faire des optimisations qui marchent bien sur le papier
mais s'appliquent mal a un cas donne (je pense a du code tres dynamique
contenant des plugin, par exemple). Ou alors, pensez a du code prevu pour
tourner sur un systeme embarque, ou la taille memoire est souvent assez
serree, et le processeur pas tres puissant: chaque inline compte alors
bien plus.
Les choses evoluent, bien sur... mais on peut encore gagner quelques pourcents
en qualite sur la totalite des cas, et beaucoup plus sur des cas tordus,
en `repassant' par derriere le compilo pour affiner les choses.
Bon, apres, on sait que inline est de toutes facons un indice pour le
compilateur, et pas une obligation (difficile d'inliner tout le code
sans faire exploser la memoire, par exemple), mais il faut quand meme
faire le tri, entre les compilo qui disent choisir pour vous pour de
meilleures perfs, et ceux qui choisissent pour eux les quelques cas qu'ils
savent gerer...
In article <46dd2a17$0$21148$, Sylvain Togni <"sylvain.togni at visionobjects.com"> wrote:
Le compilateur ne peut substituer l'appel à une fonction par son code que s'il a le code à disposition. Généralement, c'est le compilateur qui fait la substitution, pas l'éditeur de lien.
À noter quand même que la plupart des compilateurs récents font de l'optimisation globale, au moment de l'édition de liens donc et prennent en compte des données de profiling pour, par exemple, décider ou non de mettre une fonction en-ligne.
Ce qui fait que le mot clé inline à de moins en moins d'utilité. Et c'est une bonne chose, ce genre de détail est dans l'absolue du ressort du compilateur, pas du programmeur.
Pas vraiment d'accord. Pas a 100% en tout cas. Ce qui est clair, c'est qu'il faut une fluidite du code: ca doit etre facile de faire du code inline ou pas. Ce qui est clair aussi, c'est que c'est une optimisation `tardive'. Normalement, on fait d'abord tout ce qui est design, et on rajoute les inline seulement lorsqu'ils deviennent necessaires, ou au moins lorsqu'on a un programme suffisamment `figee' pour qu'on puisse faire les mesures qui vont bien.
Apres, ca depend pas mal du niveau de sophistication du developpeur, et pas mal aussi du type de programme developpe.
Le probleme de determination des inline est un probleme dur. Au moins NP complet, et peut-etre meme exponentiel. Le compilateur pourra juste, dans le meilleur des cas, faire du profile-based, ce qui implique d'avoir des bonnes suites de test. Et meme, ca ne correspond PAs forcement a l'environnement global du systeme: faire tourner un programme le plus vite possible, soit. Mais si on bouffe toute la memoire du systeme, on plombe les perfs lorsqu'on est sur un systeme multitache et qu'on utilise le systeme en production... et comme le cahier des charges d'un compilo inclut souvent `faire aussi bien que les voisins sur les SPECmarks', le mieux peut etre l'ennemi du bien !
Bref, les heuristiques du compilo ne seront jamais aussi bonnes que la personne qui les a pondu, qui doit resoudre le probleme tordu d'optimiser n'importe quoi comme code de facon correcte pour a peu pres tout le monde. Sans compter que les compilo ne comprennent pas forcement certains codes tordus, ou vont faire des optimisations qui marchent bien sur le papier mais s'appliquent mal a un cas donne (je pense a du code tres dynamique contenant des plugin, par exemple). Ou alors, pensez a du code prevu pour tourner sur un systeme embarque, ou la taille memoire est souvent assez serree, et le processeur pas tres puissant: chaque inline compte alors bien plus.
Les choses evoluent, bien sur... mais on peut encore gagner quelques pourcents en qualite sur la totalite des cas, et beaucoup plus sur des cas tordus, en `repassant' par derriere le compilo pour affiner les choses.
Bon, apres, on sait que inline est de toutes facons un indice pour le compilateur, et pas une obligation (difficile d'inliner tout le code sans faire exploser la memoire, par exemple), mais il faut quand meme faire le tri, entre les compilo qui disent choisir pour vous pour de meilleures perfs, et ceux qui choisissent pour eux les quelques cas qu'ils savent gerer...
Jean-Marc Bourguet
Fabien LE LEZ writes:
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
Idealement, on ne devrait pas devoir s'en occuper. En pratique, ce n'est toujours pas le cas. Tous les compilateurs ne font pas de l'inlining global, il y a des gros projets qui ont tendance a mettre a genoux les editeurs de liens qui tentent d'etre trop intelligent, et les heuristiques utilisees ont parfois des resultats qui apparaissent etranges a qui n'en comprend pas le fonctionnement -- dont moi.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec
le mot-clé "inline", ou définies dans le corps d'une classe), et de
leur influence sur la taille et la vitesse d'exécution de
l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper
de ce genre de détails, puisque, de toutes façons, c'est au
compilateur de décider si une fonction doit effectivement être inline,
suivant des considérations (capacités et architecture du processeur)
qui échappent au programmeur.
Qu'en pensez-vous ?
Idealement, on ne devrait pas devoir s'en occuper. En pratique, ce n'est
toujours pas le cas. Tous les compilateurs ne font pas de l'inlining
global, il y a des gros projets qui ont tendance a mettre a genoux les
editeurs de liens qui tentent d'etre trop intelligent, et les heuristiques
utilisees ont parfois des resultats qui apparaissent etranges a qui n'en
comprend pas le fonctionnement -- dont moi.
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
Idealement, on ne devrait pas devoir s'en occuper. En pratique, ce n'est toujours pas le cas. Tous les compilateurs ne font pas de l'inlining global, il y a des gros projets qui ont tendance a mettre a genoux les editeurs de liens qui tentent d'etre trop intelligent, et les heuristiques utilisees ont parfois des resultats qui apparaissent etranges a qui n'en comprend pas le fonctionnement -- dont moi.
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
James Kanze
On Sep 4, 10:38 am, Fabien LE LEZ wrote:
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
J'ai discuté ce point (ou plutôt la question plus général d'adresser les questions de performance dans ce genre de livre) avec Scott lors de la revue de _More_ _Effective_ _C++_. Sa réponse était simple : les gens lui en posaient des questions chaque fois qu'il faisait une présentation ; il donnait donc des réponses aux questions qui seraient de toute façon posée.
Dans la pratique, je trouve la règle de ne rien faire inline avant qu'il y a un problème de performance très bien. Alors, on pourrait bien essayer de rendre inline des fonctions dont le profiler a indiqué que l'appel était critique, et voir ce que ça donne, sans spéculer d'avance.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Sep 4, 10:38 am, Fabien LE LEZ <grams...@gramster.com> wrote:
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec
le mot-clé "inline", ou définies dans le corps d'une classe), et de
leur influence sur la taille et la vitesse d'exécution de
l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper
de ce genre de détails, puisque, de toutes façons, c'est au
compilateur de décider si une fonction doit effectivement être inline,
suivant des considérations (capacités et architecture du processeur)
qui échappent au programmeur.
Qu'en pensez-vous ?
J'ai discuté ce point (ou plutôt la question plus général
d'adresser les questions de performance dans ce genre de livre)
avec Scott lors de la revue de _More_ _Effective_ _C++_. Sa
réponse était simple : les gens lui en posaient des questions
chaque fois qu'il faisait une présentation ; il donnait donc des
réponses aux questions qui seraient de toute façon posée.
Dans la pratique, je trouve la règle de ne rien faire inline
avant qu'il y a un problème de performance très bien. Alors, on
pourrait bien essayer de rendre inline des fonctions dont le
profiler a indiqué que l'appel était critique, et voir ce que ça
donne, sans spéculer d'avance.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline (déclarées avec le mot-clé "inline", ou définies dans le corps d'une classe), et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
Qu'en pensez-vous ?
J'ai discuté ce point (ou plutôt la question plus général d'adresser les questions de performance dans ce genre de livre) avec Scott lors de la revue de _More_ _Effective_ _C++_. Sa réponse était simple : les gens lui en posaient des questions chaque fois qu'il faisait une présentation ; il donnait donc des réponses aux questions qui seraient de toute façon posée.
Dans la pratique, je trouve la règle de ne rien faire inline avant qu'il y a un problème de performance très bien. Alors, on pourrait bien essayer de rendre inline des fonctions dont le profiler a indiqué que l'appel était critique, et voir ce que ça donne, sans spéculer d'avance.
-- James Kanze (GABI Software) email: Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Sylvain
Fabien LE LEZ wrote on 04/09/2007 10:38:
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline [..], et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
si le développeur cherche avant tout à optimiser le rendement de son temps de développement (et pas du tout le temps d'execution), il ne devrait jamais utiliser 'inline' puisqu'il faut (un peu) réfléchir pour cela. (il pourra même ne pas savoir s'il code pour un 8 pattes mono-thread ou un 64-bits quadri-machin.)
si par contre il est en environnement (embarqué, PDA, ...) à mémoire limité (globale et/ou pile), il voudra surement sans soucier; de même si son design objet est important (lire soigné et significatif) car j'adhère à la réponse de Marc E., même si dans de nombreux cas une optimisation tardive sera plus couteuse et/ou moins fine qu'une optimisation amont, l'inline impactera plus encore le design que la taille du code ... inliner une virtuelle serait par exemple une idée douteuse.
Sylvain.
Fabien LE LEZ wrote on 04/09/2007 10:38:
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline [..], et de
leur influence sur la taille et la vitesse d'exécution de
l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper
de ce genre de détails, puisque, de toutes façons, c'est au
compilateur de décider si une fonction doit effectivement être inline,
suivant des considérations (capacités et architecture du processeur)
qui échappent au programmeur.
si le développeur cherche avant tout à optimiser le rendement de son
temps de développement (et pas du tout le temps d'execution), il ne
devrait jamais utiliser 'inline' puisqu'il faut (un peu) réfléchir pour
cela. (il pourra même ne pas savoir s'il code pour un 8 pattes
mono-thread ou un 64-bits quadri-machin.)
si par contre il est en environnement (embarqué, PDA, ...) à mémoire
limité (globale et/ou pile), il voudra surement sans soucier; de même si
son design objet est important (lire soigné et significatif) car
j'adhère à la réponse de Marc E., même si dans de nombreux cas une
optimisation tardive sera plus couteuse et/ou moins fine qu'une
optimisation amont, l'inline impactera plus encore le design que la
taille du code ... inliner une virtuelle serait par exemple une idée
douteuse.
Je suis en train de lire "Effective C++" (3rd edition).
Scott Meyers y parle assez souvent de fonctions inline [..], et de leur influence sur la taille et la vitesse d'exécution de l'exécutable.
Il me semble au contraire que le programmeur n'a pas à se préoccuper de ce genre de détails, puisque, de toutes façons, c'est au compilateur de décider si une fonction doit effectivement être inline, suivant des considérations (capacités et architecture du processeur) qui échappent au programmeur.
si le développeur cherche avant tout à optimiser le rendement de son temps de développement (et pas du tout le temps d'execution), il ne devrait jamais utiliser 'inline' puisqu'il faut (un peu) réfléchir pour cela. (il pourra même ne pas savoir s'il code pour un 8 pattes mono-thread ou un 64-bits quadri-machin.)
si par contre il est en environnement (embarqué, PDA, ...) à mémoire limité (globale et/ou pile), il voudra surement sans soucier; de même si son design objet est important (lire soigné et significatif) car j'adhère à la réponse de Marc E., même si dans de nombreux cas une optimisation tardive sera plus couteuse et/ou moins fine qu'une optimisation amont, l'inline impactera plus encore le design que la taille du code ... inliner une virtuelle serait par exemple une idée douteuse.
