Optimisation : Faire prendre en compte au compilateur qu'une valeur statique externe ne bougera pas ?
3 réponses
Jean-Marc Desperrier
Salut,
Je me posais la question de trouver un moyen d'indiquer au compilateur
que la valeur d'une variable globale externe accédées plusieurs fois
dans une fonction ne peut pas changer au cours de l'exécution de la
fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non,
et l'idée que même en l'absence de log le processeur passera son temps à
tester la valeur dans chaque fonction me gène.
Une astuce qui la recopie au début dans une variable locale ferait
sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir
l'écriture du code, sans devoir rajouter un en-tête au début de chaque
fonction créant la valeur locale. Je me dis qu'il y a peut-être quand
même un mécanisme C++ qui permettrais d'y arriver ?
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus
efficace de faire, mettre la variable const et tricher en la modifiant
en fait une fois au début de l'exécution ?
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
kanze
Jean-Marc Desperrier wrote:
Je me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temps à tester la valeur dans chaque fonction me gène.
Si la variable est de type bool, et qu'il ne fait que de le tester, je vois mal ce que tu pourrais gagner, sauf que le compilateur pourrait le mettre dans un régistre, et l'y garder toute la durée de la fonction. Mais ça, il pourrait le faire de toute façon, si la fonction n'appelle pas d'autres fonctions, et si elle appelle d'autres fonctions, il y a peu de chances que le temps de réchargement de la variable soit signifiant.
Une astuce qui la recopie au début dans une variable locale ferait sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir l'écriture du code, sans devoir rajouter un en-tête au début de chaque fonction créant la valeur locale. Je me dis qu'il y a peut-être quand même un mécanisme C++ qui permettrais d'y arriver ?
A priori, non.
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus efficace de faire, mettre la variable const et tricher en la modifiant en fait une fois au début de l'exécution ?
Ce qui risque de provoquer un core dump. Une variable déclarée const, à durée de vie statique, et avec une initialisation statique se trouvera typiquement dans le segment text, et donc protégé en écriture par le système.
D'où lit-on la valeur initiale ? Est-ce qu'une variable statique initialisée par un appel d'une fonction pourrait faire l'affaire, c-à-d : bool const loggingOn = getLogging() ; ? Note bien que cette fonction serait appelée avant l'entrée dans main. Elle ne pourrait donc pas dépendre des paramètres de la ligne de commande, sauf utilisation des extensions. (Au moins sous Unix, mais je crois aussi sous Windows, tu peux bien appeler getenv() avant l'entrée dans main, si le logging dépend d'une variable d'environement.)
-- 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
Jean-Marc Desperrier wrote:
Je me posais la question de trouver un moyen d'indiquer au
compilateur que la valeur d'une variable globale externe
accédées plusieurs fois dans une fonction ne peut pas changer
au cours de l'exécution de la fonction et qu'il peut effectuer
toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des
log ou non, et l'idée que même en l'absence de log le
processeur passera son temps à tester la valeur dans chaque
fonction me gène.
Si la variable est de type bool, et qu'il ne fait que de le
tester, je vois mal ce que tu pourrais gagner, sauf que le
compilateur pourrait le mettre dans un régistre, et l'y garder
toute la durée de la fonction. Mais ça, il pourrait le faire de
toute façon, si la fonction n'appelle pas d'autres fonctions, et
si elle appelle d'autres fonctions, il y a peu de chances que le
temps de réchargement de la variable soit signifiant.
Une astuce qui la recopie au début dans une variable locale
ferait sûrement l'affaire, mais je ne vois pas comment y
arriver sans alourdir l'écriture du code, sans devoir rajouter
un en-tête au début de chaque fonction créant la valeur
locale. Je me dis qu'il y a peut-être quand même un mécanisme
C++ qui permettrais d'y arriver ?
A priori, non.
Beaucoup plus simple et moins élégant, mais peut-être la
manière la plus efficace de faire, mettre la variable const et
tricher en la modifiant en fait une fois au début de
l'exécution ?
Ce qui risque de provoquer un core dump. Une variable déclarée
const, à durée de vie statique, et avec une initialisation
statique se trouvera typiquement dans le segment text, et donc
protégé en écriture par le système.
D'où lit-on la valeur initiale ? Est-ce qu'une variable
statique initialisée par un appel d'une fonction pourrait faire
l'affaire, c-à-d :
bool const loggingOn = getLogging() ;
? Note bien que cette fonction serait appelée avant l'entrée
dans main. Elle ne pourrait donc pas dépendre des paramètres de
la ligne de commande, sauf utilisation des extensions. (Au moins
sous Unix, mais je crois aussi sous Windows, tu peux bien
appeler getenv() avant l'entrée dans main, si le logging dépend
d'une variable d'environement.)
--
James Kanze (GABI Software) email:james.kanze@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 me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temps à tester la valeur dans chaque fonction me gène.
Si la variable est de type bool, et qu'il ne fait que de le tester, je vois mal ce que tu pourrais gagner, sauf que le compilateur pourrait le mettre dans un régistre, et l'y garder toute la durée de la fonction. Mais ça, il pourrait le faire de toute façon, si la fonction n'appelle pas d'autres fonctions, et si elle appelle d'autres fonctions, il y a peu de chances que le temps de réchargement de la variable soit signifiant.
Une astuce qui la recopie au début dans une variable locale ferait sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir l'écriture du code, sans devoir rajouter un en-tête au début de chaque fonction créant la valeur locale. Je me dis qu'il y a peut-être quand même un mécanisme C++ qui permettrais d'y arriver ?
A priori, non.
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus efficace de faire, mettre la variable const et tricher en la modifiant en fait une fois au début de l'exécution ?
Ce qui risque de provoquer un core dump. Une variable déclarée const, à durée de vie statique, et avec une initialisation statique se trouvera typiquement dans le segment text, et donc protégé en écriture par le système.
D'où lit-on la valeur initiale ? Est-ce qu'une variable statique initialisée par un appel d'une fonction pourrait faire l'affaire, c-à-d : bool const loggingOn = getLogging() ; ? Note bien que cette fonction serait appelée avant l'entrée dans main. Elle ne pourrait donc pas dépendre des paramètres de la ligne de commande, sauf utilisation des extensions. (Au moins sous Unix, mais je crois aussi sous Windows, tu peux bien appeler getenv() avant l'entrée dans main, si le logging dépend d'une variable d'environement.)
-- 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
adebaene
Jean-Marc Desperrier wrote:
Salut,
Je me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temp s à tester la valeur dans chaque fonction me gène.
Ca te "gène" peut-être, mais avant de chercher des solutions tordues et pas forcément cachères, est-ce que tu as *mesuré* que la lecture répétée de cette variable avait un impact non-négligeable (ou même un impact seulement mesurable) sur le temps d'exécution de ton programme?
La règle générale en matière d'optimisation, c'est : ne RIEN optimiser tant qu'on a pas prouvé (par des mesures) que ca valait le coup d'optimiser quelque chose. C'est la meilleure garantie pour avoir du code simple, clair et maintenable.
Très souvent, les micro-optimisations de ce type sur un accès à une variable sont sans effet mesurable. Le 1ère chose à laquelle il faut s'intéresser en cas de problème de performances, c'est l'algorithmie, pas les détails d'accès à une variable (la seule exception étant dans une boucle critique de code, genre un rendu vidéo en temps réel).
Arnaud
Jean-Marc Desperrier wrote:
Salut,
Je me posais la question de trouver un moyen d'indiquer au compilateur
que la valeur d'une variable globale externe accédées plusieurs fois
dans une fonction ne peut pas changer au cours de l'exécution de la
fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non,
et l'idée que même en l'absence de log le processeur passera son temp s à
tester la valeur dans chaque fonction me gène.
Ca te "gène" peut-être, mais avant de chercher des solutions tordues
et pas forcément cachères, est-ce que tu as *mesuré* que la lecture
répétée de cette variable avait un impact non-négligeable (ou même
un impact seulement mesurable) sur le temps d'exécution de ton
programme?
La règle générale en matière d'optimisation, c'est : ne RIEN
optimiser tant qu'on a pas prouvé (par des mesures) que ca valait le
coup d'optimiser quelque chose. C'est la meilleure garantie pour avoir
du code simple, clair et maintenable.
Très souvent, les micro-optimisations de ce type sur un accès à une
variable sont sans effet mesurable. Le 1ère chose à laquelle il faut
s'intéresser en cas de problème de performances, c'est l'algorithmie,
pas les détails d'accès à une variable (la seule exception étant
dans une boucle critique de code, genre un rendu vidéo en temps
réel).
Je me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temp s à tester la valeur dans chaque fonction me gène.
Ca te "gène" peut-être, mais avant de chercher des solutions tordues et pas forcément cachères, est-ce que tu as *mesuré* que la lecture répétée de cette variable avait un impact non-négligeable (ou même un impact seulement mesurable) sur le temps d'exécution de ton programme?
La règle générale en matière d'optimisation, c'est : ne RIEN optimiser tant qu'on a pas prouvé (par des mesures) que ca valait le coup d'optimiser quelque chose. C'est la meilleure garantie pour avoir du code simple, clair et maintenable.
Très souvent, les micro-optimisations de ce type sur un accès à une variable sont sans effet mesurable. Le 1ère chose à laquelle il faut s'intéresser en cas de problème de performances, c'est l'algorithmie, pas les détails d'accès à une variable (la seule exception étant dans une boucle critique de code, genre un rendu vidéo en temps réel).
Arnaud
dieu.tout.puissant
Jean-Marc Desperrier wrote:
Salut,
Je me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temp s à tester la valeur dans chaque fonction me gène.
Une astuce qui la recopie au début dans une variable locale ferait sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir l'écriture du code, sans devoir rajouter un en-tête au début de cha que fonction créant la valeur locale. Je me dis qu'il y a peut-être quand même un mécanisme C++ qui permettrais d'y arriver ?
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus efficace de faire, mettre la variable const et tricher en la modifiant en fait une fois au début de l'exécution ?
Si tu veux éviter ces tests, une solution serait le changement dynamique d'algorithme. Mais ce n'est pas sûr que ton programme puisse l'intégrer.
Dans l'exemple suivant, je change le pointeur d'une fonction suivant la valeur du flag;
if (flag) pf = algo1; else pf = algo2;
....
pf(); // appel algo1() ou algo2() suivant la valeur du flag
Bien lire les autres interventions à ta question avant d'envisager une solution de ce genre.
Jean-Marc Desperrier wrote:
Salut,
Je me posais la question de trouver un moyen d'indiquer au compilateur
que la valeur d'une variable globale externe accédées plusieurs fois
dans une fonction ne peut pas changer au cours de l'exécution de la
fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non,
et l'idée que même en l'absence de log le processeur passera son temp s à
tester la valeur dans chaque fonction me gène.
Une astuce qui la recopie au début dans une variable locale ferait
sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir
l'écriture du code, sans devoir rajouter un en-tête au début de cha que
fonction créant la valeur locale. Je me dis qu'il y a peut-être quand
même un mécanisme C++ qui permettrais d'y arriver ?
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus
efficace de faire, mettre la variable const et tricher en la modifiant
en fait une fois au début de l'exécution ?
Si tu veux éviter ces tests, une solution serait le changement
dynamique d'algorithme. Mais ce n'est pas sûr que ton programme puisse
l'intégrer.
Dans l'exemple suivant, je change le pointeur d'une fonction suivant la
valeur du flag;
if (flag)
pf = algo1;
else
pf = algo2;
....
pf(); // appel algo1() ou algo2() suivant la valeur du flag
Bien lire les autres interventions à ta question avant d'envisager une
solution de ce genre.
Je me posais la question de trouver un moyen d'indiquer au compilateur que la valeur d'une variable globale externe accédées plusieurs fois dans une fonction ne peut pas changer au cours de l'exécution de la fonction et qu'il peut effectuer toutes les optimisations en découlant.
En fait il s'agit d'un flag qui indique s'il faut faire des log ou non, et l'idée que même en l'absence de log le processeur passera son temp s à tester la valeur dans chaque fonction me gène.
Une astuce qui la recopie au début dans une variable locale ferait sûrement l'affaire, mais je ne vois pas comment y arriver sans alourdir l'écriture du code, sans devoir rajouter un en-tête au début de cha que fonction créant la valeur locale. Je me dis qu'il y a peut-être quand même un mécanisme C++ qui permettrais d'y arriver ?
Beaucoup plus simple et moins élégant, mais peut-être la manière la plus efficace de faire, mettre la variable const et tricher en la modifiant en fait une fois au début de l'exécution ?
Si tu veux éviter ces tests, une solution serait le changement dynamique d'algorithme. Mais ce n'est pas sûr que ton programme puisse l'intégrer.
Dans l'exemple suivant, je change le pointeur d'une fonction suivant la valeur du flag;
if (flag) pf = algo1; else pf = algo2;
....
pf(); // appel algo1() ou algo2() suivant la valeur du flag
Bien lire les autres interventions à ta question avant d'envisager une solution de ce genre.