Ben non, un bon compilateur optimise d�j� �a tout seulCitation:
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:
Version imprimable
Ben non, un bon compilateur optimise d�j� �a tout seulCitation:
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:
qui se lance dans un benchmark "realiste" ?
et comment le faire surtout ?
Je ne crois pas aux benchmarks, je ne crois qu'aux mesures en contexte. En ce sens, ce qui a �t� fait ici est bien. Ce qu'il faut �viter, c'est d'extrapoler � d'autres contextes.
Je trouve dommage le d�placement de ce fil dans le forum Qt : On n'y parle pas tant de Qt, que de m�canismes g�n�raux (COW, mutex,...) et de leurs avantages respectifs, Qt n'�tant cit� ici que comme une illustration d'une fa�on de faire.
je suis tout a fait d'accord
c'etait avant tout les arguments sur le COW qui m'interessait, et le debat qu'il cr�e parce que Qt l'utilise. C'est aussi pour ca que je l'avais post� dans C++ et non dans Qt :?
vraiment dommage :cry:
C'est r�par� :calin:
Merci 8-)
Aussi si tu veux mon avis, il vaudrait mieux eviter les sous-categories
et rendre les sous-categories des categories a part entiere (previsu dans la page d'accueil ... etc)
Merci
pour en revenir au COW, est-ce que vous avez pu comparer les performances sur les collections ? (vector vs QVector etc...)
Miles ?
Hello,
� votre avis il y aurait des probleme a utiliser openmp avec le implicit sharing de Qt ? De maniere generale j'ai toujours des doutes si on utilise d'autres libs (boost/thread par exemple)
OpenMP, boost/thread posent-ils un probleme a l'implicit sharing ?
Merci a+
Je peux difficilement te r�pondre. A tout hasard, jettes un oeil � boost.MP (ou un nom comme cela) qui a �t� propos�e pour rejoindre le "collectif" de biblioth�ques boost.
Je crois me souvenir qu'il y avait un document assez pouss�. Peut-�tre qu'il y a des infos sur le m�lange "comptage atomique" (*) + openMP.
(*) Car au fond, l'implicit sharing est d�velopp� autour de cela, tout comme les boost::shared_ptr<>.
C'est pas plut�t MPI qui est arriv� dans Boost ?Citation:
Envoy� par Luc Hermitte
Je savais bien qu'il y avait "MP" dans le nom :roll:
haaarg c'est trop compliqu� MPI,
et puis avec les processeurs multi-coeurs d'aujourd'hui il vaut mieux miser sur openMP. il permet aussi de passer en douceur au multi-threading.
Sur la mailing list de Qt, ils m'ont repondu que l'implicit sharing utilisait des primitives systemes et qu'il n'y avait a priori pas de risque avec le melange d'autre biblio. sauf pour les objets dependant de QThread bien entendu.
je ne sais pas ce qui m'arrive ... je deviens pro-boost :D
MPI c'est pour le distribu�, pas pour le multi-proc.
Oui. Des compteurs atomiques.
Chaque syst�me a sa propre fa�on de les impl�m�nter. Certains n'en ont pas.
MPI = processeurs sans m�moire partag�e, que des bus de communications.Citation:
Envoy� par epsilon68
openMP = processeurs � m�moire partag�e.
MPI c'est super lourd.
avec openmp ca me fait penser que Qt copierait la collection si on en modifie un element alors ?
ces derniers temps je me suis amus� a faire en C++/STL, C++/Qt et C#.NET un programme qui transforme un fichier CSV, combine une colonne sur plusieurs lignes, etc.... on utilise beaucoup le split, les map, des map<string,map<string string> > etc
C'est un cas concret, servant pour mon travail.
en programmant sans penser optimization, le .NET est de loin le plus rapide en execution. le C++ etait dans les choux (avec des string et des map<string,string>, map<string, list<vector<string> > >) et C++/Qt pas plus rapide que C++ (ce qui m'a beaucoup decu, j'attendais mieux du COW ...)
non seulement le C++ etait beaucoup plus lent, mais consommait enormement de memoire.
pour un fichier de 22Mo 7771 lignes:
C++ +30s 400 Mo de memoire (C++/Qt etait meme plus lent)
C# 22 s 90 Mo de memoire
il n'y a qu'en revenant au char*, en mappant le fichier en memoire, et a referencer toute les chaines sur ce bloc de memoire que la version c++ fait maintenant:
C++ (char* + fichier en memoire): 14s 30-40 Mo de memoire
en appliquant certaines optimisation au c# (eviter une map dans certains cas, optimisations faites dans le C++)
C# 17 s 90 Mo
bref tout ca pour dire que Qt et l'implicit sharing ..... bof la ca m'a vraiment decu. Par contre les languages avec Machine Virtuelle ... ca se rapproche maintenant beaucoup des languages compil�s .....
moi je serais bien partant pour faire tous ensemble un programme defini par nous tous dans plusieurs languages, dans le but de comparer plusieurs languages / frameworks. tout le monde peut lire et evaluer les programmes...
Qu'en pensez-vous ?
Si t'utilises de la m�moire en trop c'est que tu t'y es mal pris...Citation:
non seulement le C++ etait beaucoup plus lent, mais consommait enormement de memoire.
Le COW n'a d'int�r�t que si tu copies alors que tu devrais pas, ou si tu as une mauvaise structure avec redondance des donn�es.Citation:
ce qui m'a beaucoup decu, j'attendais mieux du COW