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
merci pour le compliment, en meme temps, au début, je l'avais fait de la meme maniere qu'avec C#. apres je l'ai optimisé pour avoir un temps et un cout memoire inferieurs.Citation:
Envoyé par loufoque
justement je fais beaucoup de copies.Citation:
Envoyé par loufoque
---
Maintenant, c'est tres dure de comparer deux programmes et j'essaie de les comparer avec le meme algo, donc le meme nombre de recopies etc.
c'est vrai je fais beaucoup de copies et c'est en ca que je suis decu de Qt, ca n'ameliore rien.
Ce que je tire de tout ca d'apres tes petites phrases laconiques et un tantinet ironiques, c'est que finalement mieux vaudrait un langage comme Java/C#, meme moyen, on arrive a de bonnes perfs avec un programme plus lisible
:/
... aussi il y avait une question / proposition dans mon post (celui presentant les resultats) :(
Qui te dis que ta STL n'implémente pas aussi le COW sur les strings ?Citation:
Envoyé par epsilon68
j'ai utilisé la stl de Visual studio 2005, je ne sais pas si ca utilise le COW, je ne pense pas mais peut-etre peux-tu me le confirmer.Citation:
Envoyé par JolyLoic
aussi, meme si ca utilise le cow, la version C++ avec map<string,....> etait completement dans les choux. Mais bon l'avantage du C++ c'est qu'il y a toujours moyen d'optimiser....
Je viens de jetter un oeil dans le code, et elle n'a pas l'air de l'utiliser. Ce qui change par rapport à VC6, je crois.Citation:
Envoyé par epsilon68
As-tu moyen de poster le code en question quelquepart, qu'on sa fasse une idée du genre de choses faites, au moins la version non optimisée ?Citation:
Envoyé par epsilon68
il faut que je regarde comment je pourrais le transformer pour le rendre anonyme. Ca va etre difficile... c'est aussi pour ca que je proposais de programmer tous ensemble une appli de ce genre, pas trop importante en temps comme une transformation de fichier ?! et on l'implemente dans plusieurs langages ...Citation:
Envoyé par JolyLoic
Qu'en pensez-vous ?Citation:
Envoyé par epsilon68
une sorte de concours ou il faut etre le plus rapide a l'execution
J'ai peur de ce genre de "concours". Je préfèrerais un concours de ce genre, mais où le but n'est pas d'être rapide, mais de maximiser le ratio "simple à écrire/rapidité" (le premier élément étant difficilement mesurable). Après tout, en rapidité pure, surtout pour un test de petite taille, on aura du mal à battre l'assembleur et les appels directs au système, même si on sait que ce n'est pas scalable.
Ça me rappelle quelque chose... il me semblait qu'on a ouvert un forum pour ce genre de concours mais je ne le retrouve pas.
Si tu donnes une spec, je m'y lancerai peut-être. Mais ma jambe est guérie donc je n'ai plus le temps que j'avais quand j'étais forcé de rester chez moi.
Je crois qu'apres un peu d'optimisation on va remarquer que les differences sont dans les bruits des IO. C'etait ma conclusion sur l'exemple du tri qui avait ete propose.Citation:
Envoyé par JolyLoic
[info]Il a été mis en attente de recentrage.[/info]Citation:
Envoyé par Jean-Marc.Bourguet
je suis d'accord alors il faut un jury et argumenter ses choix.Citation:
Envoyé par JolyLoic
que proposez-vous ?
une transformation de fichier ?
je peux reflechir a un truc comme ca...
Commence par fournir ton code qu'on puisse t'expliquer pourquoi il est lent et utilise trop de mémoire.
le probleme c'est que mon code est utilisé professionnellement et je ne tiens pas a le voir partout .... tu comprends ?
c'est pour ca que j'aimerais le faire sur un truc semblable du meme genre ...