Discussion :

[epsilon68]

Bonjour,

J'aimerais comparer la qualité du code generé dans deux cas:

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
class Vector3
{
public:
 
	union {
		struct { double x,y,z; };
		double _array[3];
	};
 
	Vector3() : x(0), y(0), z(0) {
	}
 
	Vector3( double ax, double ay, double az ) : x(ax), y(ay), z(az) {
	}
 
	const Vector3 operator+ ( const Vector3 & rhs ) const {
		return Vector3( x+rhs.x, y+rhs.y, z+rhs.z );
	}
 
	void add ( const Vector3 & rhs ) {
		x+=rhs.x;
                y+=rhs.y;
                z+=rhs.z;
	}
};
 
int main(int argc, char* argv[])
{	
	Vector3 v1( 10, 10, 10 );
	Vector3 v2( 1, 2, 3 );
 
        // vaut-il mieux
        v1 = v1 + v2;
 
        // ou bien
        v1.add( v2 );
}

D'apres le code generé est-il couteux d'utiliser l'operateur + par rapport a la fonction add() ?

et dans le cas ou on veut stoker le resultat dans une autre variable:

Code :

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

Vector3 v = v1 + v2;

ou

Code :

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

1
2
Vector3 v(v1);
v1.add(v2);

Merci d'avance pour votre aide.

[rigobert]

Avant de parler de code généré, on peut déjà voir des choses dans le code C++.

Comme par exemple que le résultat de l'opérateur + est renvoyé par copie alors que le add() fait directement les calculs sur la cible.

Conclusion, le add() est théoriquement plus rapide que l'opérateur +.

[epsilon68]

en fait, j'ai beaucoup lu que le compilateur sait vraiment optimizer quand on fait un return Vector3(...) avec un assignation direct derriere.

donc perso je pense que ca met le meme temps, mais a confirmer avec le code generé ....

a+

[Luc Hermitte]

Dans ce cas très précis, il vaut mieux utiliser +=. Opérateur qui devrait de toutes façons servir de base à l'implémentation de l'opérateur libre +.

Dans l'absolu il vaut mieux utiliser une bibliothèque robuste et optimisée comme boost.ublas ou Blitz++ qui savent éliminer des temporaires grâce à la méta-programmation. (-> tiny array pour les vecteurs non redimensionnables)
Elles requièrent des compilos non anciens -- la norme de 98 a tout de même 8 ansn mine de rien.

Quant au RVO et RNVO, la qualité de leur implémentation dépend de chaque compilateur.

Fais une recherche sur le document n1666 qui est un pdf -> google: "C++ n1666 filetype:pdf"

Et avec un peu de chance, la future norme de 2009 nous offrira la sémantique de déplacement native.

[epsilon68]

J'a trouvé la reponse:


Use the return value optimization to give the compiler a hint that temporary
objects can be eliminated. This technique enables the compiler to use the
ISO/IEC TR 18015:2004(E) Technical Report on C++ Performance
© ISO/IEC 2004 — All rights reserved Page 49 of 192

memory for a function's return value to hold a local object of the same type
that would otherwise have to be copied into the return value location, thus
saving the cost of the copy. This is usually signalled by inserting constructor
arguments into the return statement:
const Rational operator * (Rational const & lhs,
Rational const & rhs)
{
return Rational(lhs.numerator() * rhs.numerator(),
lhs.denominator() * rhs.denominator());
}
Less carefully written code might create a local Rational variable to hold the
result of the calculation, use the assignment operator to copy it to a temporary
variable holding the return value, then copy that into a variable in the calling
function.

// not this way ...
const Rational operator * (Rational const & lhs,
Rational const & rhs)
{
Rational tmp; // calls the default constructor (if any)
tmp.my_numerator = lhs.numerator() * rhs.numerator();
tmp.my_denominator = lhs.denominator() * rhs.denominator();
return tmp; // copies tmp to the return value, which is
// then copied into the receiving variable
}

However, with recent improvements in compiler technology, modern
compilers may optimize this code in a similar manner.

[epsilon68]

Dans ce cas très précis, il vaut mieux utiliser +=. Opérateur qui devrait de toutes façons servir de base à l'implémentation de l'opérateur libre +.

Dans l'absolu il vaut mieux utiliser une bibliothèque robuste et optimisée comme boost.ublas ou Blitz++ qui savent éliminer des temporaires grâce à la méta-programmation. (-> tiny array pour les vecteurs non redimensionnables)
Elles requièrent des compilos non anciens -- la norme de 98 a tout de même 8 ansn mine de rien.

Quant au RVO et RNVO, la qualité de leur implémentation dépend de chaque compilateur.

Fais une recherche sur le document n1666 qui est un pdf -> google: "C++ n1666 filetype:pdf"

Et avec un peu de chance, la future norme de 2009 nous offrira la sémantique de déplacement native.

Merci Luc pour ton pdf, il apporte la reponse que je me souvenais bien avoir lu quelque part.

Par contre je ne sais pas ce que veut dire RVO et RNVO ?

sinon je ne veux pas utiliser d'autres libs, et sinon blitz++ est GPL
et je ne sais pas l'avenir de mon code....

a+ et merci

[loufoque]

Par contre je ne sais pas ce que veut dire RVO et RNVO ?

"Return Value Optimization" et "Named Return Value Optimization" (en fait c'est NRVO).

[epsilon68]

merci
je continue donc dans cette maniere de faire...

a+

[Luc Hermitte]

Merci Luc pour ton pdf, il apporte la reponse que je me souvenais bien avoir lu quelque part.

C'est un peu le meilleur document que je connaisse sur la question.

sinon je ne veux pas utiliser d'autres libs, et sinon blitz++ est GPL
et je ne sais pas l'avenir de mon code....

Même pas QT ? ;P
La licence de Blitz++ peut effectivement être problématique -- je n'y avais jamais prété attention. Pour boost.ublas, honnêtement, tu vas redévelopper des trucs "classiques" qui ne seront jamais aussi efficaces avant plusieurs années.
NB: C'est au demeurant un excellant exercice pour tous niveaux.

"Named Return Value Optimization" (en fait c'est NRVO).

Ah! Au temps pour moi. Je me disais bien que je n'arrivais pas à trouver d'expression en anglais correct qui colle pour RNVO. :blush:

je continue donc dans cette maniere de faire...

Tu paies toujours le prix d'une affectation. Le RVO économise juste le prix de la copie qui aurait été due au retour par valeur.
Donc. Solution simple -> +=
Solution bidouille:

Code :

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

1
2
3
4
5
6
T x(.....); ....
{
   T u = x + y; // RVO
   x . swap(u); // pseudo déplacement des responsabilités
   // On paie tout de même une allocation et une libération (sauf si pool d'objets)
}

Solution évoluée. Mettre en place une dualité type final, types intermédiaires mémorisant les opérations pour économiser les temporaires. Ce que font Blitz++ et les bibliothèques qui ont utilisé la technique d'Expressions Templates. Je lis que NewMat serait la première qui aurait été capable de distinguer "x = A*x" et "y = A * x".

[epsilon68]

Même pas QT ? ;P
La licence de Blitz++ peut effectivement être problématique -- je n'y avais jamais prété attention. Pour boost.ublas, honnêtement, tu vas redévelopper des trucs "classiques" qui ne seront jamais aussi efficaces avant plusieurs années.
NB: C'est au demeurant un excellant exercice pour tous niveaux.

He He He ...
et si Qt et libxml sont des libraries qui ne peuvent etre remise en cause par moi, ca fait tres longtemps que j'explore toutes les solutions, et ces deux libs sont des theoremes pour moi.

l'interet est aussi de refaire des choses qui existent, sinon pourquoi continuer Linux alors qu'il y a windows qui marche bien ? je m'egare peut etre un peu (mais jsuis l'auteur de cette discussion ;-)

comme tu l'as dis c'est un bon exercice, mais aussi c'est construire la lib qui nous ressemble.

a+ et merci pour vos reponses