Discussion :

[epsilon68]

le move est fait avec des rvalue references si j'ai bien compris.
il faut donc le traiter en plus pour pouvoir faire le "move"

[yan]

Le COW ça ne sert qu'à améliorer la performance dans le cas où l'application fait des copies alors qu'elle n'en a pas besoin.
Donc si l'application est bien conçue, elle qu'elle ne fait que des copies quand elle en a besoin, alors ça ne sert à rien, au contraire ça rajoute un coût en performance.

Après ça peut quand même être utile pour faire du partage implicite de parties de structures de données à base de nœuds, mais c'est un cas qui se traite vraiment à part.

justement je ne pense pas que ce soit fait automatiquement comme tu l'ecris-

a mon avis, un déplacement qui sera fait seulement si tu retourne une locale de ta fonction.
sinon ca veut rien dire..

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class A
{
monGrosObjet foo() {return B;}
monGrosObjet foo2() 
{
monGrosObjet  aa;
[...]
return aa;
}
monGrosObjet B;
}

je vois mal l'appel de la fonction foo modifier la variable A::B.
Par contre avec foo2 oui.

[yan]

Pour le cow, je trouve que qt permet de faire cela de manière trés simple
http://qt.developpez.com/doc/4.4/qshareddatapointer/

[loufoque]

a mon avis, un déplacement qui sera fait seulement si tu retourne une locale de ta fonction.

Non, dans tous les cas lors d'un retour par valeur.

sinon ca veut rien dire..

Code :

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

1
2
3
class A
{
monGrosObjet foo() {return B;}

En C++03, ceci fait deux copies.
En C++0x, ceci fait une copie et un déplacement.
Dans les deux cas, on peut optimiser cela en une seule copie et c'est tout si la valeur de retour est utilisée pour initialiser une variable du même type.

Code :

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

1
2
3
4
5
6
7
8
monGrosObjet foo2() 
{
monGrosObjet  aa;
[...]
return aa;
}
monGrosObjet B;
}

Ceci fait deux copies en C++03, et deux déplacement en C++0x.
Dans un cas comme dans l'autre, on peut optimiser cela à zéro copie et zéro déplacement si la valeur retournée est utilisée pour initialiser une variable de même type.

Tu peux constater tout ça en testant avec GCC 4.3 avec le test suivant

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
43
44
45
#include <iostream>
 
struct monGrosObjet
{
	monGrosObjet()
	{
	}
 
	monGrosObjet(const monGrosObjet&)
	{
		std::cout << "copie" << std::endl;
	}
 
#ifdef __GXX_EXPERIMENTAL_CXX0X__	
	monGrosObjet(monGrosObjet&&)
	{
		std::cout << "déplacement" << std::endl;
	}
#endif
};
 
struct A
{
	monGrosObjet foo()
	{
		return B;
	}
 
	monGrosObjet B;
};
 
monGrosObjet foo2() 
{
	monGrosObjet  aa;
	return aa;
}
 
int main()
{
	A a;
	std::cout << "cas 1" << std::endl;
	monGrosObjet bar = a.foo();
	std::cout << "cas 2" << std::endl;
	monGrosObjet baz = foo2();
}

Utilise -std=c++0x pour activer C++0x
Utilise -fno-elide-constructors pour désactiver la NRVO.

[HanLee]

Non, dans tous les cas lors d'un retour par valeur.



En C++03, ceci fait deux copies.
En C++0x, ceci fait une copie et un déplacement.

Utilise -std=c++0x pour activer C++0x
Utilise -fno-elide-constructors pour désactiver la NRVO.

Mais le NRVO, c'est pas du C++03 ? Alors pourquoi pas 1 copie au lieu d'une seule ?

[yan]

Non, dans tous les cas lors d'un retour par valeur.

ha ok.
Dans la cas 1, j'aurais bien vu une copie directement sur l'object qui récupère le return
dans le cas 2, un déplacement de la locale vers l'object receveur.

Il me manquais une étape.

Merci des précisions.

[epsilon68]

merci pour les exemples, c'est très instructif.
Les rvalue references me faisaient un peu peur dans leur complexité de mise en oeuvre, la ca me parait super jouable.

edit: j'ai quand meme l'impression quand je lis certains articles qu'il faut renvoyer monobjet&& ...

[loufoque]

La NRVO s'applique en C++03 comme en C++0x.

[epsilon68]

en bref, les rvalue references, c'est le pied mais ca ne sera pas disponible avant un paquet de temps ... alors le COW ? bonne solution pour maintenant?

[Jean-Marc.Bourguet]

en bref, les rvalue references, c'est le pied mais ca ne sera pas disponible avant un paquet de temps ... alors le COW ? bonne solution pour maintenant?

Il faudrait connaître le problème pour te répondre.

[epsilon68]

je parle en general,
pour simplifier la lecture du code et pour optimiser le programme vu qu'il ne fait pas de recopie.

j'ai tellement lu de critiques sur le COW dans Qt (et je la trouve formidable cette lib) que je me suis reposé mainte fois cette question...
J'ai aussi donc tellement lu de critique sur cette QString, que tout le monde donnait perdante face à une sd:string par valeur et un allocateur optimisé...

... et je reviens avec le benchmark pour voir si les gens sont d'accord avec le benchmark et si ca a fait changer leur point de vue...

et toi?

[Jean-Marc.Bourguet]

je parle en general,

pour simplifier la lecture du code

Il me semble qu'implémenter du COW est plus compliqué d'implémenter de la copie au moment de la copie...

et pour optimiser le programme vu qu'il ne fait pas de recopie.

La seule réponse est "mesure!", et mesure toi-même de préférence sur le programme déjà bien finalisé, au moins sur des exemples que tu sais être caractéristiques de ton utilisation.

[epsilon68]

Il me semble qu'implémenter du COW est plus compliqué d'implémenter de la copie au moment de la copie...

Qt propose une classe de base QSharedDataPointer qui fait le COW

La seule réponse est "mesure!", et mesure toi-même de préférence sur le programme déjà bien finalisé, au moins sur des exemples que tu sais être caractéristiques de ton utilisation.

ca me semble hyper long comme tache ... pas toi?
et toi tu as eu l'occasion d'essayer?

[Jean-Marc.Bourguet]

ca me semble hyper long comme tache ... pas toi?
et toi tu as eu l'occasion d'essayer?

Implémenter la version COW une fois qu'on a identifié que les copies prenaient du temps, ca devrait être relativement rapide... surtout si tu as une classe qui est destinée à aider à faire cela.

Faire de l'optimisation une fois que les approches algorithmiques évidentes ont été épuisées et gratter 2% par ici, 3% par là? Oui, j'ai déjà fait et c'est long, et ça demande des données vraisemblables -- le mieux c'est des données qui viennent de production -- parce que c'est sensible... tellement sensible qu'on se demande si ça a du sens de faire cela.

J'ai déjà aussi gagné des facteurs 1000 en faisant à moitié rien... une fois qu'on à trouvé que le cas qui semblait ne jamais devoir arriver arrivait bien ou qu'on vient de remarquer que l'opération qui semblait élémentaire ne l'est pas.

Pour revenir à ton sujet, le COW retarde un coût unique supposé important au prix d'un coût distribué supposé faible en espérant que le coût unique n'arrivera pas. Pour savoir si c'est gagnant ou non, il faut connaître la valeur de ces coûts, le nombre de fois où on évite le coût important et le nombre de fois qu'on paye le coût faible. Ça me semble très difficile à prévoir.

[yan]

en bref, les rvalue references, c'est le pied mais ca ne sera pas disponible avant un paquet de temps ... alors le COW ? bonne solution pour maintenant?

mais l'intêret de COW ce n'est pas que les rvalue

Pour revenir à ton sujet, le COW retarde un coût unique supposé important au prix d'un coût distribué supposé faible en espérant que le coût unique n'arrivera pas. Pour savoir si c'est gagnant ou non, il faut connaître la valeur de ces coûts, le nombre de fois où on évite le coût important et le nombre de fois qu'on paye le coût faible. Ça me semble très difficile à prévoir.

En quoi le COW suppose un cout important?????
Ce n'est qu'un pointeur avec un compteur de reference????
comparer à une creation + copie de mémoire???

[loufoque]

en bref, les rvalue references, c'est le pied mais ca ne sera pas disponible avant un paquet de temps ...

C'est déjà disponible dans un certain nombre de compilateurs.

Le COW, ça sert à optimiser les cas où on copie mais où en fait on ne veut pas copier mais simplement déplacer.
Si on dispose des sémantiques de déplacement, il suffit de déplacer quand on veut déplacer et copier quand on veut copier. Pas besoin de comptage de référence et de copie paresseuse lors d'une écriture.
C'est donc une solution bien plus élégante, mais aussi plus performante.

Après, les sémantiques de mouvement ont tout de même un certain nombre de problèmes, qui n'en font pas une solution parfaite non plus.
Le principal problème est qu'il faut laisser l'objet déplacé dans un état vide valide pour certains opérations (qui ne sont pas encore bien définies à mon goût), ce qui peut briser des invariants ou nécessiter de faire des cas particuliers pour l'implémentation de certaines primitives.
L'idéal ça aurait été des sémantiques de déplacement destructices, mais c'est trop tard pour ça maintenant.

[Luc Hermitte]

a- mais l'intêret de COW ce n'est pas que les rvalue


b- En quoi le COW suppose un cout important?????
Ce n'est qu'un pointeur avec un compteur de reference????
comparer à une creation + copie de mémoire???

b- Un compteur atomique n'est pas exactement gratuit, même si négligeable face à un lock.

a- Et hormis les retours de fonctions, si tu as besoin du COW, très bien, sert-en -- j'ai du mal à évaluer, cela n'a jamais été mon cas.
Et concernant les retours de fonctions, les rvalue references devraient enterrer le COW... si on oublie que c'est une nouvelle syntaxe, et que beaucoup persistent toujours à passer leurs chaines par copie. (en plus des problèmes signalés par Loufoque)

[Jean-Marc.Bourguet]

En quoi le COW suppose un cout important?????

COW suppose que la copie a un coût important puisqu'on cherche à l'éviter.

Le coût faible et distribué, c'est de le coût de maintenir un compte des références et de décider à chaque accès en écriture s'il faut faire maintenant une copie qu'on n'a pas faite dans le passé.

[Jean-Marc.Bourguet]

C'est déjà disponible dans un certain nombre de compilateurs.

Tant que ce n'est pas disponible dans tous les compilateurs cibles et ceux vraisemblablement utilisé dans un proche avenir, ça ne sert pas à grand chose.

Le COW, ça sert à optimiser les cas où on copie mais où en fait on ne veut pas copier mais simplement déplacer.

Aussi -- surtout -- les cas où on ne modifie pas et donc où toutes les occurrences peuvent référencer la même zone mémoire.

[epsilon68]

... mais alors c'est bien ou pas bien ?