Discussion :

[raoulpetite]

Bonjour,

J'aurais besoin pour des raisons d'efficacité de ne pas compiler des parties de code qui ne sont pas utilisées dans certains cas.
Ma première idée a été d'utiliser la compilation conditionnelle ... Mais j'ai rapidement compris que j'allais perdre beaucoup en lisibilité de mon code en mettant des #if #else #endif un peu partout . Ce qui a été confirmé par mes recherches sur le web.
Du coup, je me demande si la solution ne serait pas de toujours de définir des constantes (comme FLAG dans l’exemple ci-dessous) que je passe avec l'option -D du compilateur g++ et de mettre dans mon code quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
#if FLAG
  const int TOTO = 1;
#else
  const int TOTO = 0;
#endif
 
if (TOTO)
  cout<<"bonjour tonton"<<endl;
else
  cout<<"bonjour tata"<<endl;

Ma question est la suivante :
Si FLAG vaut 1, est-ce que l'exécutable obtenu sera peu ou prou le même que si j'avais programmé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
#if FLAG
  const int TOTO = 1;
#else
  const int TOTO = 0;
#endif
  cout<<"bonjour tonton"<<endl;

Ainsi dans l'exécutable le test sur TOTO n'est plus fait.
Cela fonctionne-t-il ? Si non, y a-t-il un moyen de faire cela ?

Je précise que, mon but est de gagner en temps de calcul par l'absence de test qui, se trouvant dans des boucles, sont répétés de très nombreuses fois alors que je sais dès la compilation s'ils ont lieu d'être ou pas. Je précise aussi que je veux garder un seul et unique code pour ne pas avoir plusieurs codes à maintenir en parallèle.

Merci par avance de vos réponses

[Bousk]

Salut,

si tu utilises un compilateur un minimum récent, tu peux facilement te laisser penser que oui, il optimisera tout ça et croire en lui pour être intelligent.
constexpr et template sont les mot-clés pour ce qui est calculé pendant la compilation. Tout ce qui est opération préprocesseur aussi : #...
Pour en être sur, vérifie le code généré.

[Médinoc]

Le problème, ça va être les avertissements "conditional expression is constant" et "unreachable code"...

[raoulpetite]

@Medinoc : A priori, ça passe quand je compile ....

@Bousk : Vérifiez le code généré ... J'ai jamais trop fait ça moi, mais y'a un début à tout Je suppose qu'il faut aller regarder à quoi ressemble le .o. Je vais voir ce que ça fait avec mon petit exemple

[Bousk]

D'ailleurs en C++17 on a maintenant accès au if constexpr, ce qui simplifiera encore plus ce genre de pirouettes.

[ternel]

Note que si tu écris:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
#if FLAG
  cout<<"bonjour tonton"<<endl;
#else
  cout<<"bonjour tata"<<endl;
#endif

Tu sais que le code ne contiendra pas de if.

Ce n'est pas forcément une bonne idée de procéder ainsi, mais il arrive que ce soit plus clair.

[Bktero]

Pourrais-tu expliquer plus largement ce que tu souhaites faire ? Tu es ici à un niveau assez bas, mais en réfléchissant à plus haut niveau, on peut trouver des solutions plus globales et potentiellement plus intéressantes. Exemple : tu souhaites activer ou des désactiver certaines traces sur stdout, utilise un logger.

[raoulpetite]

@bktero : je vois que tu écoutes de la bonne musique (je sais c'est hors sujet)

Bon, mon but est de gagner du temps de calcul dans un code de calcul scientifique. Dans ma jeunesse qui commence à remonter un peu, on m'a appris que les tests étaient un source de perte de temps et que je me souvienne c'était vérifié. Pour info, mes codes font plusieurs milliers de lignes et des temps de calcul typiques de plusieurs jours essentiellement car les mêmes boucles sont répétées de très nombreuses fois avec à chaque fois plusieurs tests du type qui nous intéresse ici.


Bref, depuis hier, je me suis amusé un peu et j'avoue que je comprends pas tout ce qui se passe. Voici 3 versions d'un code :
Version 1 : pas de test du tout :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
#include <iostream>
#include <math.h>
 
int main()
{
 
 //int BB=1;
 long int j=0;
 double a;
 
//#if BONJOUR
//  const int BB=1;
//#else
//  const int BB=0;
//#endif
 
for (long int i=0;i<= 800000000;i++)
{
//if (BB)
   a=exp(1.0/(j++));
//else
//   std::cout<<"NOT"<<std::endl;
}
std::cout<<a<<std::endl;
return 0;
}

version 2 : test mais pas de const

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
#include <iostream>
#include <math.h>
 
int main()
{
 
 int BB=1;
 long int j=0;
 double a;
 
//#if BONJOUR
//  const int BB=1;
//#else
//  const int BB=0;
//#endif
 
for (long int i=0;i<= 800000000;i++)
{
if (BB)
   a=exp(1.0/(j++));
else
   std::cout<<"NOT"<<std::endl;
}
std::cout<<a<<std::endl;
return 0;
}

version 3 : version avec const int (passage à la compilation avec l'option -DBONJOUR=1)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
#include <iostream>
#include <math.h>
 
int main()
{
 
// int BB=1;
 long int j=0;
 double a;
 
#if BONJOUR
  const int BB=1;
#else
  const int BB=0;
#endif
 
for (long int i=0;i<= 800000000;i++)
{
if (BB)
   a=exp(1.0/(j++));
else
   std::cout<<"NOT"<<std::endl;
}
std::cout<<a<<std::endl;
return 0;
}

J'ai compilé ces 3 codes avec l'option -S pour regarder le code généré.
Du point de vue de la taille du .s les versions 1 et 3 ont la même taille et la version 2 est un peu plus grosse (pareil pour les exécutables). De plus, dans le .s de la V2, je devines les traces du test car je vois la chaîne de caractères "NOT".
Un diff sur les .s des v1 et v3 me montre que les différences sont infimes. Il y a juste des références modifiées et un movl en plus dans celui sans test. La V2 comporte évidemment plus de différence.
En revanche, quand j’utilise time sur mon exécutable, j'ai peu ou prou les mêmes temps de calcul (moins de 1% d'écart sur 20 s). Que cela signifie-t-il ? Que les structures conditionnelles ne font pas perdre de temps de manière générale ? Que dans le cas spécifique de ce test, la valeur de BB ne changeant pas, le compilateur optimise même le cas v2 sans const ? Que mon test est inadapté à ce que je veux voir ? Bref, je me demande si je ne me prends pas la tête pour rien ... Pour info, dans ces tests, je n'ai pas fait appel à l'option d'optimisation du compilateur (-O2 ou -O3).

Merci pour vos retours

[ternel]

Il n'y a aucun intérêt à chercher un éventuel gain de performance sur une compilation non optimisée (-O3 , voire -O2).

Si tu veux savoir si un aileron est efficace sur une voiture de course, il faut l'utiliser sur une voiture de course en pleine vitesse, pas au ralenti, ni sur une 4L.

D'une manière générale, l'optimisation se fait par l'algorithmie, puis en observant ce qui pose problème (profiler ou call stack sampling).

La raison pour laquelle l'exécution de la V2 n'est pas plus lente est liée à la prédiction de branchement, un mécanisme de compilation qui permet de commencer à exécuter une branche d'une conditionnelle, plutot que d'attendre que le calcul de la condition soit terminé. Ainsi, si c'est la bonne branche qui a commencé, on a effectivement gagné du temps.

Ton test étant constant, le compilateur peut s'arranger pour tomber bien.

[raoulpetite]

Merci ternel, tu as très certainement raison.

Quand je compile mon code, j'utilise -O3 (sinon, ce ne serait pas quelques jours de calcul que j'aurais). J'essaie aussi d'optimiser le reste avec mes quelques compétences (je ne suis pas un expert de ce domaine) ... Mais dans ce post précis, je me pose des questions sur un point précis et assez simple qu'on peut résumer : est-ce qu'on perd du temps avec les structures conditionnelles. Et si oui, est-ce qu'on peut optimiser en passant des const int dans les tests de manière à faire disparaître les tests dans le code final ?

Je vois que tu as poursuivi ta réponse pendant que j'écrivais
Tu dis

La raison pour laquelle l'exécution de la V2 n'est pas plus lente est liée à la prédiction de branchement, un mécanisme de compilation qui permet de commencer à exécuter une branche d'une conditionnelle, plutot que d'attendre que le calcul de la condition soit terminé. Ainsi, si c'est la bonne branche qui a commencé, on a effectivement gagné du temps.

Donc le temps de calcul dépend de la branche qui commence ... Là, j'ai eu de la chance en gros. Si je veux élimer ce facteur chance, il faut que je passe avec des const, n'est-il pas ? Ainsi, le choix sera fait dès la compilation.

[ternel]

Globalement, on perd un temps non nul mais potentiellement négligeable dans l'exécution d'un if.

Je dis négligeable parce qu'on parle d'un cycle, devant l'exécution d'une expression flottante un peu complexe.

Si jamais le compilateur a assez d'information pour pouvoir prédire que la valeur de la condition, et qu'il est autorisé à optimiser, il ne va pas se priver .

Donc, si ta condition est une valeur constante ou mieux constexpr.

[raoulpetite]

remerci ternel !

faut que je vois si je peux utiliser constexpr que je ne connaissais pas ....

[ternel]

C'est apparu avec la norme C++11, celle d'il y a 6 ans.
A noter que la norme à venir cette année, et disponible en mode expérimental dans la dernière version de gcc prévoit un constexpr if, qui est évalué par le compilateur.

[dalfab]

Il est vrai que si on laisse faire l'optimiseur, les 3 codes reviennent à faire directement std::cout<<1.25e-9<<std::endl; En réalité sur les processeurs CISC les points de prise de décisions ont un coup totalement nul s'ils sont prédits correctement mais deviennent extrêmement coûteux quand le choix est très variable. Pour comparer, il faut donc activer l'optimisation en prenant garde à ce qu'il n'enlève pas la partie itérative; par exemple en utilisant des variables volatile.

Et même si l'optimiseur fait mal son boulot, le processeur pourra malgré tout anticiper sur la réussite d'un test. Sans aucune info, le processeur CISC anticipe :
* dans un test if/else, c'est le cas if qui est prédit (mais l'optimiseur le sachant à pu inverser le test!)
* dans une boucle do while(), c'est le fait de reboucler qui est prédit (ici aussi l'optimiseur a pu inverser le test)
* pour les boucle for, while et les switch, cela dépend de la structure utilisé par le compilateur et l'optimiseur devrait faire au mieux.

Mais n'importe quel optimiseur saura traiter un test sur une constante comme une suppression totale du test.

[Bktero]

Tes codes sont sans doute trop simples pour être représentatifs pour comparer les vitesses d'exécution. Il faut un cas représentatif et ces bouts de code ne le sont sans doute pas. Ils peuvent juste de servir à voir un peu le code généré.

Si tu as beaucoup de code à modifier et que tu souhaites aller vite, la solution des #if #endif est sans doute la plus simple et la plus efficace. Si tu as un peu de temps devant toi, il faudrait sans doute revoir ton algo et tes structures pour trouver où tu peux gagner. Citons ternel, elle est toujours de bon conseil :

D'une manière générale, l'optimisation se fait par l'algorithmie, puis en observant ce qui pose problème (profiler ou call stack sampling).

Exemples:
- Si dans une boucle, tu fais un if à chaque tour de boucle, essaye de sortir les if.
- Si tu fais des calculs avec des matrices et que ton opérateur [] vérifie que l'index est correct (façon Java et IndexOutOfBoundsException), fais une variante sans les tests. Ainsi, quand ton code sera validé avec la version sécurisée, passe à la version non-sécurisée (mais utilisée dans un contexte que tu sais sûr).

PS (hors sujet) : t'as vu ça cette musique de qualité

[raoulpetite]

Merci pour vos réponses qui me permettent d'apprendre pas mal de choses ....

Je me doutais un peu que mes exemples sont trop simples pour être représentatifs, mais déjà ils m'ont permis d'avoir des réponses qui font sens par rapport à mes préoccupations. Le soucis est que je reprends des codes dans lesquels ce type de problèmes n'a pas été traité en amont et j'en aurai probablement d'autres du même ordre . Du coup, j'essaie de trouver des solutions viables sans faire trop de modif ...
J'ai commencé par les #if ... mais j'ai vite vu que rien que le fait de perdre les correspondances entre les { et } allait mettre un gros bazar dans le code du point de vue de son intelligibilité.

Effectivement, alors que ça fait partie des choses que j'ai apprises, je n'avais pas penser à sortir les if des boucles, mais si je fais ça, il faudra que je répète des boucles quasi-identiques avec le risque de faire des corrections dans l'une sans les reportées dans les autres ou alors faut faire des fonctions .... Vu le code, ça risque d'être pas mal de taf ... alors que les mêmes optimisations peuvent être faites lors de la compilation...

D'ailleurs au passage si vous avez des conseils d'ouvrage ou de site (en français ou en anglais) expliquant comment générer des codes efficaces avec des algo bien pensés, je suis preneur (plutôt dans le domaine du calcul scientifique)

Bref, merci beaucoup, je sais ce qu'il me reste à faire.

[koala01]

Salut,

- Si tu fais des calculs avec des matrices et que ton opérateur [] vérifie que l'index est correct (façon Java et IndexOutOfBoundsException), fais une variante sans les tests. Ainsi, quand ton code sera validé avec la version sécurisée, passe à la version non-sécurisée (mais utilisée dans un contexte que tu sais sûr).

Et ca, ca se fait très simplement à l'aide des assertions... Par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
/* on utilisera plutot l'opérateur () que l'opérateur [] */
double DoubleMatix::operator()(size_t line, size_t row) const{
        /* une matrice de LINEMAX lignes et de ROWMAX colonnes peut être linéarisée en un tableau de LINEMAX * ROWMAX éléments 
         * et on peut donc accéder aux éléments choisis avec la formule element = line*ROWMAX + row.
         * 
         * mais les indices vont de 0 à (LINEMAX*ROWMAX)-1 inclus.  Tout indice hors de cette intervalle est du à une erreur de programmation
         * et devra être corrigée avant la mise en production.
         * 
         * Cela implique que, une fois l'application mise en production, le test de validité n'a plus de raison d'être.  
         *
         * La macro assert (accessible depuis le fichier d'en-tête <cassert>) s'assure que le test ne sera 
         * effectué (et provoquera un plantage de l'application) qu'en mode "debug"
         */
        assert(line  < LINEMAX && "line out of bound");
        assert(row  < ROWMAX && "row out of bound");
        /* appliqueons la formule */
        return m_elements[line * ROWMAX + row]