Discussion :

[tnarol]

Salut,

J'ai quelques questions qui me turlupinent � chaque fois que j'�cris du code avec des imp�ratifs de performance :

- est ce qu'une variable d�clar�e localement dans une boucle a un risque d'�tre moins rapide qu'une variable d�clar�e � l'ext�rieur.

- dans une boucle for (i = 0; i < monVecteur.size(); i++) est ce qu'on perd un peu de temps � �valuer la fonction size() par rapport � la mettre dans une variable (si elle ne varie pas) ?

- de mani�re plus g�n�rale si j'utilise plusieurs fois une valeur de variable constante que j'obtiens avec un appel de fonction et/ou une indirection dois-je stocker localement cette variable ?

Merci !

[koala01]

Salut,

La m�thode size() est de toutes mani�res faite pour �tre en temps d'ex�cution constant, ce qui fait que je peux d�j� t'assurer que tu ne prend pas plus de temps � obtenir le r�sultat avec 100 000 �l�ments qu'avec 10.

Et il me semble m�me que la m�thode est d�clar�e inline (bien que je ne puisse en jurer), et, si c'est bel et bien le cas, il n'y aura pas de diff�rences entre le fait de prendre la valeur une fois pour toute en dehors de la boucle et celui de rappeler la m�thode � chaque fois.

Quoi qu'il en soit, faut il rappeler que dans plus de 90% des cas, ce genre d'optimisation arrive trop t�t et qu'il vaut mieux commencer par voir s'il n'y a pas moyen d'optimiser l'algorithme/les structures de mani�re a s'�viter des it�rations inutiles

[tnarol]

Quoi qu'il en soit, faut il rappeler que dans plus de 90% des cas, ce genre d'optimisation arrive trop t�t et qu'il vaut mieux commencer par voir s'il n'y a pas moyen d'optimiser l'algorithme/les structures de mani�re a s'�viter des it�rations inutiles

Certes, mais quitte � �crire quelque chose, autant que ce soit pas trop mal la premi�re fois...

[koala01]

Certes, mais quitte � �crire quelque chose, autant que ce soit pas trop mal la premi�re fois...

Oui, si par "pas trop mal" tu envisages les choses sous l'angle de l'algorithme.

Si tu fais bien ton travail en utilisant des noms de variables non concurrents et explicites, et que tu te rend compte que, malgr� le fait que ton algorithme est "aussi optimis� que faire se peut", il faut encore essayer de grapiller quelques cycles d'horloges, le fait de sortir la fonction de la boucle ne devrait pas poser de probl�me, et tu sera libre de faire les tests de perfs pour t'assurer du fait que cela change quelque chose ou non

[themadmax]

Bonne question, et d'apr�s la litt�rature il est conseill� de d�clarer une variable au plus tard dans le code.

Testons :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <iostream>
#include <windows.h>
 
#define COUNT 100
int tab[COUNT];
 
void func1()
{
	for (int i=0; i<COUNT; i++)
	{
		int b = tab[i];
		if ( b == 0 )
			b++;
	}
}
 
void func2()
{
	int b;
	for (int i=0; i<COUNT; i++)
	{
		b = tab[i];
		if ( b == 0 )
			b++;
	}
}
 
int main()
{
	memset( tab, 0, COUNT );
	__int64 start, stop;
 
	QueryPerformanceCounter((LARGE_INTEGER*)&start);
	func1();
	QueryPerformanceCounter((LARGE_INTEGER*)&stop);
	std::cout << (stop - start) << std::endl;
 
	QueryPerformanceCounter((LARGE_INTEGER*)&start);
	func2();
	QueryPerformanceCounter((LARGE_INTEGER*)&stop);
	std::cout << ( stop - start ) << std::endl;
}

J'ai fait plusieurs tests avec VS2005 (Release) et c'est a peut pr�s pareil, pour les deux fonctions !
Il faudrai jeter un coup d'oeil dans le code ASM g�n�r�.

[Invit�]

J'ai fait le m�me test chez moi :

Code c++ :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
#include <iostream>
#include <time.h>
 
#define COUNT 100000000
int tab[COUNT];
 
void func1()
{
    for (int i=0; i<COUNT; i++)
    {
        int b = tab[i];
        if ( b == 0 )
            b++;
    }
}
 
void func2()
{
    int b;
    for (int i=0; i<COUNT; i++)
    {
        b = tab[i];
        if ( b == 0 )
            b++;
    }
}
 
int main()
{
    memset( tab, 0, COUNT );
 
    clock_t start, stop;
 
    start = clock();
    func1();
    stop = clock();
    std::cout << (unsigned int)(stop - start) << std::endl;
 
    start = clock();
    func2();
    stop = clock();
    std::cout << (unsigned int)( stop - start ) << std::endl;
 
    return 0;
}

Avec g++ 4.2.3, les r�sultats sont les suivants:
func1 -> 1090000
func2 -> 790000

[koala01]

H�h�...

La premi�re r�gle est de ne jamais faire confiance � un benchmark que l'on n'a pas trafiqu� soi m�me...

En plus, la question ici porte pr�cis�ment sur l'�valuation de size() comme condition d'arr�t de la boucle, ce que le code ne met pas en valeur

De plus, il n'est pas bon de se contenter de tester les choses une seule fois, �tant donn� qu'un tas de circonstances externes sont de nature � fausser les r�sultats.

J'ai donc modifi� les deux fonctions pour que elles nous testent exactement ce que le PO demande en:

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
 
void func1(std::vector<size_t>& v)
{
    for (size_t i=0; i<v.size(); i++)
    {
        v[i]=i;
    }
}
 
void func2(std::vector <size_t>& v)
{
    size_t max=v.size();
    size_t i;
    for (i=0; i<max; i++)
    {
       v[i]=i;
    }
}

et j'ai bien sur adapt� un peu la fonction main en

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
 
int main()
{
    std::vector<size_t> t;
    for(size_t i=0;i<10000000;++i)
        t.push_back(i);
 
    clock_t start, stop;
 
    for(size_t i=0;i<10; ++i)
    {
        start = clock();
        func1(t);
        stop = clock();
        std::cout <<i<<" func1 "<< (unsigned int)(stop - start) <<"  ";
 
        start = clock();
        func2(t);
        stop = clock();
        std::cout <<" func2 "<< (unsigned int)( stop - start ) << std::endl;
    }
    return 0;
}

Et l�, apparaissent certaines divergences apparaissent.

En mode Debug, func1 est globalement plus lente que func2 ainsi que le montre la sortie ci-dessous:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
0 func1 218   func2 188
1 func1 219   func2 172
2 func1 218   func2 188
3 func1 219   func2 187
4 func1 219   func2 172
5 func1 218   func2 188
6 func1 234   func2 172
7 func1 219   func2 187
8 func1 219   func2 172
9 func1 234   func2 172

En mode Relase (compil� avec -O2) les r�sultats sont plus nuanc�s...

Allez savoir pourquoi, lors de la premi�re ex�cution, alors que les 5 premiers passages montrent que func2 est plus rapide, les 5 suivants montraient exactement le contraire:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
0 func1 156   func2 141
1 func1 156   func2 141
2 func1 156   func2 141
3 func1 156   func2 140
4 func1 141   func2 140
5 func1 141   func2 156
6 func1 140   func2 156
7 func1 140   func2 157
8 func1 140   func2 157
9 func1 141   func2 156

et les ex�cutions suivantes donnaient, parfois, un avantage � func2 (de l'ordre de 156 contre 148 pour les 10 passages), parfois un avantage � func1 (avec une diff�rence du m�me ordre pour les 10 passages), et parfois un avantage � func1 (ou � func2) pour les (quelques) premier passages, un avantage exactement invers� pour les suivants.

Bref, je crois sinc�rement qu'il est - � tout prendre - plus int�ressant:

1. de d�clarer la variable servant compteur pour la boucle dans la boucle (afin d'�viter les conflits de noms de variables)
2. d'utiliser la m�thode size() dans la boucle, afin que le lecteur puisse se faire une id�e de la condition de sortie � la seule lecture de la boucle

Et ce, sous r�serve d'un benchmark qui montre une r�elle constance dans les diff�rences.

Maintenant, c'est peut �tre du � ma situation personnelle, et donc, voici avec quoi j'ai travaill�:

• Athlon 1700XP, 512Mb RAM (SD-RAM)
• Code::Blocks, SVN Build Rev 5010
• Gcc-4.3.0

[three minute hero]

� mon avis, c'est tout simplement le compilateur qui optimise (O2) pour donner un binaire �quivalent � celui r�sultant d'un code o� la variable aurait �t� d�clar�e en dehors de la boucle.

[koala01]

� mon avis, c'est tout simplement le compilateur qui optimise (O2) pour donner un binaire �quivalent � celui r�sultant d'un code o� la variable aurait �t� d�clar�e en dehors de la boucle.

Ce n'est pas impossible, et c'est m�me fort vraisemblable...

Cependant, cela confirme ce que je dit bien haut depuis toujours: attendez d'avoir la preuve qu'un "sucre syntaxique" quelconque ait effectivement en phase de distribution un impact sur le r�sultat, commencez par optimiser votre algorithme, et remettez vous en au compilateur pour savoir comment cr�er au mieux le binaire.

Si, par la suite, il apparait � coup de benchmarks qu'une optimisation est n�cessaire et utile, elle ne devrait �tre tent�e que dans les circonstances qui seront celle de la compilation avant distribution.

[three minute hero]

Le mieux serait de sortir les codes assembleurs g�n�r�s.

De toute fa�on, tout ceci n'est que de la masturbation intellectuelle. C'est bien de comprendre ce qui se passe, mais en pratique perdre du temps � � optimiser � le code de cette fa�on est antiproductif. Il vaut mieux s'int�resser � la complexit� algorithmique et privil�gier avant tout la lisibilit� du code.

[koala01]

Le mieux serait de sortir les codes assembleurs g�n�r�s.

De toute fa�on, tout ceci n'est que de la masturbation intellectuelle. C'est bien de comprendre ce qui se passe, mais en pratique perdre du temps � � optimiser � le code de cette fa�on est antiproductif. Il vaut mieux s'int�resser � la complexit� algorithmique et privil�gier avant tout la lisibilit� du code.

Heuuu... As tu remarqu� que c'�tait le sens de ma toute premi�re intervention

Si, par la suite, je me suis amus� � faire quelques mesures, c'�tait pour:

1. D�montrer que l'optimisation de l'algorithme importe plus que celle du code
2. D�montrer qu'il ne faut pas se fier � un bench que l'on n'a pas truqu� soi-m�me
3. D�montrer que, si sur certains points, il faut prendre le compilateur pour un c, on peut par contre lui faire parfaitement confiance pour optimiser le binaire
4. D�montrer enfin que le r�sultat sera fortement d�pendant des options de compilation pass�es

[Emmanuel Deloget]

Bonne question, et d'apr�s la litt�rature il est conseill� de d�clarer une variable au plus tard dans le code.

Ca n'a pas grand chose � voir avec un probl�me de rapidit� d'ex�cution du cycle normal.

Par contre, si tu fais:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
void f1(params..)
{
  MaClasseQuiPrendsDuTempsALaConstruction c(params..)
  if (test_sur_une_valeur_indep_de_c) return;
  ...
}
 
void f2(params..)
{
  if (test_sur_une_valeur_indep_de_c) return;
  MaClasseQuiPrendsDuTempsALaConstruction c(params..)
  ...
}

Alors f2 est plus rapide que f1, qui ex�cute un constructeur et un destructeur en plus. Par contre, si c est un int, le temps d'ex�cution sera probablement identique (car un int est simplement r�serv� sur la pile - il n'y a ni constructeur ni destructeur � appeler).

De mani�re g�n�rale, plus tu attends pour d�clarer une variable, plus tu a de chance que cette d�claration ne soit pas n�cessaire - d'o� la recommandation de la d�clarer le plus tard possible.

[Emmanuel Deloget]

Allez savoir pourquoi, lors de la premi�re ex�cution, alors que les 5 premiers passages montrent que func2 est plus rapide, les 5 suivants montraient

et les ex�cutions suivantes donnaient, parfois, un avantage � func2 (de l'ordre de 156 contre 148 pour les 10 passages), parfois un avantage � func1 (avec une diff�rence du m�me ordre pour les 10 passages), et parfois un avantage � func1 (ou � func2) pour les (quelques) premier passages, un avantage exactement invers� pour les suivants.

Scheduler, task switch sont les premiers mots qui me viennent � l'esprit. Sous Windows, une diff�rence de 10/20ms n'est pas significative, surtout sur un test qui dure 150ms (parce que ce sont bien des ms, n'est-ce pas?)

Tu sais que un v.resize() au d�but te permet de gagner un peu de temps au setup ? puisque tu te moques des valeurs pr�sentes dans le vecteur, les initialiser ne sert pas � grand chose

[three minute hero]

Heuuu... As tu remarqu� que c'�tait le sens de ma toute premi�re intervention

Oui oui, j'appuyais tes propos

[themadmax]

J'ai essay� de regarder le code ASM g�n�r� par VS2005, mais celui-ci a bien voulu me le g�n�rer juste pour le mode Debug (voir pi�ce jointe).
Pour conclure, j'aimerai conseiller au d�veloppeur C++ ayant un pass� C, de ne plus d�clarer leur variable en d�but de fonction.
Et d'utiliser les fonctions "size()", mise � part pour une recherche profonde d'optimisation ( pas encore prouv� plus rapide ).

J'aime bien ce genre de poste qui traite de la "beaut�" du d�veloppement, et h�las tr�s difficile � trouver sur le net/cours. Peut-�tre serai-t-il int�ressant d'avoir un petit coin o� l'on r�f�rence tous ces conseils, avec surtout leurs argumentations.

[Emmanuel Deloget]

J'ai essay� de regarder le code ASM g�n�r� par VS2005, mais celui-ci a bien voulu me le g�n�rer juste pour le mode Debug (voir pi�ce jointe).

Pour *voir* le code asm g�n�r� en mode release, tu peux mettre un point d'arr�t en d�but de fonction (si si, �a marche), debugger le programme et visualiser la fen�tre assembleur. Ce n'est pas tr�s pratique, je te l'accorde.

Pour *g�n�rer* du code asm directement, il faut passer par les options de compilation. Dans les propri�t�s de ton projet,
[C++ -> Output Files --> Assembler Output]: choisir l'option qui te conviens le mieux (presonnellement, c'est le listing assembleur simple).
[C++ -> Output Files --> ASM List Location]: mettre le path ou tu va stocker les fichiers ASM

Pour conclure, j'aimerai conseiller au d�veloppeur C++ ayant un pass� C, de ne plus d�clarer leur variable en d�but de fonction.
Et d'utiliser les fonctions "size()", mise � part pour une recherche profonde d'optimisation ( pas encore prouv� plus rapide ).

La fonction size() est plus que probablement inlin�e, donc elle est �quivalente � une soustraction dans la plupart des cas (l'�quivalent de end() - begin(), mais en plus intelligent). Si le compilateur n'est pas capable de d�tecter que le vecteur n'a aucune chance d'avoir �t� modifi� entre deux appels successifs � size(), il effectuera syst�matiquement la soustraction. Autant ne la faire qu'une seule fois

J'aime bien ce genre de poste qui traite de la "beaut�" du d�veloppement, et h�las tr�s difficile � trouver sur le net/cours. Peut-�tre serai-t-il int�ressant d'avoir un petit coin o� l'on r�f�rence tous ces conseils, avec surtout leurs argumentations.

Ah, et sur l'optimisation, en voici des bons: The Fallacy of Premature Optimization, par Randall Hyde.

Un extrait:

As you can probably tell, this article is not "yet another article warning beginning programmers to avoid premature optimization." The purpose of this article is to examine how software engineers have (incorrectly) applied Hoare's statement as a way of avoiding the effort necessary to produce a well-performing application. Hopefully, this article can encourage many software engineers to change their views on application performance.

(PS: c'est Hoare et non Knuth qui a lanc� la c�l�bre phrase "premature optimization is the root of all evil").

[loufoque]

Un bon compilateur pourrait optimiser votre code pour qu'il ne fasse rien du tout.
En effet, il ne fait rien de visible.

[Charlemagne]

J'apporte mon petit grain de sel:

- est ce qu'une variable d�clar�e localement dans une boucle a un risque d'�tre moins rapide qu'une variable d�clar�e � l'ext�rieur.

Je ne pense pas. En tout cas, c'est tellement plus pratique et �l�gant de d�clarer une variable locale � l'int�rieur.
Exception plus que probable: si cette variable locale est une classe avec un constructeur...

- dans une boucle for (i = 0; i < monVecteur.size(); i++) est ce qu'on perd un peu de temps � �valuer la fonction size() par rapport � la mettre dans une variable (si elle ne varie pas) ?

J'avais fait des essais du genre y'a quelques ann�es (principalement avec le compilateur Intel sous Windows, plus rapide que GCC ou Visual d'apr�s mes benchs).
J'en �tais venu � la conclusion, qu'il valait mieux stocker le r�sultat dans une variable. J'aurais pens� le contraire, car j'estimais que l'inline jouerait � plein pour des fonctions du genre de size ou une simple addition, et pourtant...
Depuis j'ai pris l'habitude d'�crire les boucles dans le genre

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
for (int i=0, imax=vec.size(); i<imax; ++i) ...
for (int i=0, imax=n+10;       i<imax; ++i) ...

[koala01]

J'apporte mon petit grain de sel:

Tant qu'il ne fait pas gripper la machine...

Je ne pense pas. En tout cas, c'est tellement plus pratique et �l�gant de d�clarer une variable locale � l'int�rieur.
Exception plus que probable: si cette variable locale est une classe avec un constructeur...

Et encore...

Il est peut �tre alors utile de savoir si la variable "temporaire" utilise tout le temps les m�mes valeurs ou non, et, dans la n�gative, il faut alors comparer les performances des constructions/destructions successives avec celles des (r�)initialisations � envisager pour permettre � cette variable de fonctionner avec les bonnes valeurs...

Et je parle ici de performances uniquement, car, en ce qui concerne le code � utiliser pour la r�initialisation, je pr�f�rerais me contenter d'un appel au constructeur et de la destruction automatique de la variable

Quand on dit que rien n'est blanc ou noir

J'avais fait des essais du genre y'a quelques ann�es (principalement avec le compilateur Intel sous Windows, plus rapide que GCC ou Visual d'apr�s mes benchs).
J'en �tais venu � la conclusion, qu'il valait mieux stocker le r�sultat dans une variable. J'aurais pens� le contraire, car j'estimais que l'inline jouerait � plein pour des fonctions du genre de size ou une simple addition, et pourtant...
Depuis j'ai pris l'habitude d'�crire les boucles dans le genre

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
for (int i=0, imax=vec.size(); i<imax; ++i) ...
for (int i=0, imax=n+10;       i<imax; ++i) ...

Cela implique de se poser quelques questions de base (du fait qu'il ne faut jamais se fier � un bench que l'on n'a pas truqu� soi-m�me )

• Pourrais-tu, ne serait-ce qu'approximativement, nous dire il y a combien de temps
• Quelle �tait la version du compilateur intel
• As tu r�effectu� les tests avec la version actuelle
• Etait-ce suffisemment significatif que pour justifier l'utilisation en dehors de situations o� les temps d'ex�cutions sont r�ellement critiques (AKA ou le moindre cycle d'horloge compte)
• sans doute une ou l'autre � laquelle je n'ai pas pens�...

EDIT par contre, j'ai toujours eu horreur de rencontrer deux instructions diff�rentes dans l'une des parties des boucles...

[Charlemagne]

Cela implique de se poser quelques questions de base (du fait qu'il ne faut jamais se fier � un bench que l'on n'a pas truqu� soi-m�me )

• Pourrais-tu, ne serait-ce qu'approximativement, nous dire il y a combien de temps
• Quelle �tait la version du compilateur intel
• As tu r�effectu� les tests avec la version actuelle
• Etait-ce suffisemment significatif que pour justifier l'utilisation en dehors de situations o� les temps d'ex�cutions sont r�ellement critiques (AKA ou le moindre cycle d'horloge compte)
• sans doute une ou l'autre � laquelle je n'ai pas pens�...

Y'a peut-�tre environ 3-4 ans, plus que probablement avec la version 8.0.X ou 8.1.X du compilateur d'Intel (ICL).
Intel a certes sorti les version 9 et 10 depuis, mais �a ne fait probablement aucune diff�rence. Je pr�f�re a propos la version 8.1 aux r�centes, car la version 8.1 ob�it au doigt et � l'oeil aux consignes inline, alors que depuis les autres versions ne font que ce qu'elles veulent.
Dans mes tests, c'�tait pas n�gligeable pour des boucles � petit contenu. C'est clair qu'il y'a d'autres moyens autrement plus efficaces pour optimiser les boucles (d�roulement bien pens�, calculs SIMD...)

EDIT par contre, j'ai toujours eu horreur de rencontrer deux instructions diff�rentes dans l'une des parties des boucles...

Faut pas en abuser de la double instruction, mais je trouve �a sympa dans certains cas pour pas surcharger le contenu de la boucle, du genre:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
 
for (iterator it=X.begin(), end=X.end(); it!=end; ++it) ...
 
for (int i=0, j=n-1; i<n; ++i, --j) ...//double balayage avant-arrière
 
//copie
for (float *p=&X[0], *q=&Y[0], *end=X[n]; p!=end; ++p, ++q)
  *q=*p;

D�clarer une variable imax comme dans l'exemple de mon message pr�c�dent, ne mange pas de pain, alors dans le doute sur la performance, autant aider le ou les compilateurs.
Car on est s�rement d'accord pour dire qu'au moins �a ne nuira pas aux performances...