[C++] Copy-On-Write benchmark

tu en as de la chance toi !!!
moi je l'ai vu dans le code :)

La vid�o de la pr�sentation devrait �tre dispo le mois prochain :D

Si longtemps :aie: ?

Apr�s la conf�rence de San Jose... (c'est la video de Trolltech).

Il faudra que je reregarde comment ils proc�dent dans ACE -- ils ont quantit�s de mutex, locks et gardes diff�rents. Sans parler des diverses polices pour param�trer tout cela.

Sinon, dans ce dernier "th�me" je suis tomb� sur �a aujourd'hui. http://www.artima.com/cppsource/threads_meeting.html (compte rendu de la derni�re r�union du commit� de standardisation au sujet du support du multi-threading dans le C++0x)
Tr�s int�ressant.

En ce qui concerne les critical sections sous Windows:
http://support.microsoft.com/kb/105678/en-us
Il y a aussi les fonctions InterlockedXXX
http://msdn.microsoft.com/library/en...ronization.asp

Citation:

---

Envoy� par Luc Hermitte

http://www.artima.com/cppsource/threads_meeting.html (compte rendu de la derni�re r�union du commit� de standardisation au sujet du support du multi-threading dans le C++0x)

---

Ce n'est pas la derni�re... La derni�re est en cours actuellement.. ;)

A part �a, j'ai d�couvert ce doc, qui a l'air assez sympa aussi http://www.cs.utah.edu/~wilson/compi...04-michael.pdf. Faudra que je le lise au calme.

donc en fait Qt a fait le bon choix ... ?
je dis cela parce que j'observe un revirement assez impressionnant sur le COW ...

mais ca me rassure croyez moi :lol:

C'est pas qu'ils on fait le bon choix, c'est simplement qu'ils ont ajout� un refcounting plus optimis� pour le multi-thread�.
Pas de quoi casser trois pattes � un canard...

Sans cette optimisation, en faisant des copies � chaque fois dans leurs programmes, le CPU grimperait de 50% d'apr�s des tests qu'ils ont fait.

Je crois que c'est le gain m�moire qui est de 50% dans le designer, + un gain visible en terme de vitesse d'ex�cution (difficile � quantifier).

Citation:

---

Envoy� par Aurelien.Regat-Barrel

Je crois que c'est le gain m�moire qui est de 50% dans le designer, + un gain visible en terme de vitesse d'ex�cution (difficile � quantifier).

---

Ah ? JE croyais que c'�tait le temps CPU... De toute mani�re, on verra vite :D

Yep :D Il me semble que c'est les 2 (tant qu'� faire).

Quel revirement de situation quand meme ! ;)

En m�me temps, il y a s�rement moyen d'�viter cette d�gradation en utilisant moisn de copies, ...

Citation:

---

Envoy� par Miles

Sans cette optimisation, en faisant des copies � chaque fois dans leurs programmes, le CPU grimperait de 50% d'apr�s des tests qu'ils ont fait.

---

C'est un cercle vicieux ! Ils ont le COW. Des d�veloppeurs d�cident alors de passer par copie au lieu de passer par r�f�rence. Donc, dans ces programmes, les perfs baissent notablement si on n'utilise plus le COW. Donc on pr�tend que le COW fait gagner du temps.

Si on me dit qu'un programme typique fait par une personne un minimum comp�tente sans COW, puis port� dans un environnement COW se comporte XX% plus vite pourquoi pas. Mais l�, j'ai quelques doutes.

J'ai pas fait trop de tests, mais je n'ai clairement pas l'impression que mes programment passent une partie mesurable de leur temps dans des copies de cha�nes inutiles.

pas seulement de chaines mais de collection, set, map etc...
et sans compter un design clair et une relecture facile.

C'est surtout par rapport � la valeur de retours dans les fonctions je crois. Avec la STL, tu es oblig�s "d'optimiser � la main" en jouant avec swap:

Code:

---

1 2 3 4 5

std::vector<int> get_vect();   std::vector<int> v; v.swap( get_vect() );

---

Avec l'approche de Qt l'�criture est all�g�e. Y'a du pour et y'a du contre...

Citation:

---

Envoy� par JolyLoic

C'est un cercle vicieux ! Ils ont le COW. Des d�veloppeurs d�cident alors de passer par copie au lieu de passer par r�f�rence. Donc, dans ces programmes, les perfs baissent notablement si on n'utilise plus le COW. Donc on pr�tend que le COW fait gagner du temps.

---

Tout � fait d'accord avec toi, un test sur un programme plus neutre serait plus appropri�, sans nul doute.