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

[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.

[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...