Bonjour,
Je vais commencer par préciser que je ne suis pas du tout informaticien et que je peux donc faire de grosses bourdes en programmation...
Je cherche à déterminer les objets se situant en différents points d'une QGraphicsScene (afin d'obtenir une matrice).
Au départ, j'ai donc écrit :  

Cela fonctionne très bien mais n'est pas très rapide et un seul coeur est utilisé (alors que j'ai 16 coeurs à disposition).
Premier réflexe : je rajoute un "#pragma omp parallel for" avant le for. Pas de problème de compilation, mais le programme plante irrémédiablement (erreur de segmentation) sauf quand la QGraphicsScene est vide...
Alors je coupe la boucle en deux :

J'obtiens alors la même erreur qu'en utilisant openmp. Je me dis alors que j'utilise les mêmes objets dans les deux threads et que c'est certainement la cause de l'erreur.
Du coup, je copie la QGraphicsScene dans une deuxième QGraphicsScene que j'utilise dans la fonction essai2(). Et là ça fonctionne, je n'ai pas d'erreur, j'ai bien deux coeurs utilisés, mais le calcul est 4 fois plus long... Pourquoi?
Quelqu'un pourrait-il m'aider à optimiser ce calcul?  
Merci d'avance!

Ta copie elle est pas gratuite non plus hein
En outre, QT étant codé avec les pieds, il doit contnir en interne des états static non partagées qui sérialisent les accés ...
Je te conseillerais de ne travailler que sur des données sorties de leurs contextes QT.
Ensuite, quel est le calcul effectué en vrai, car la je vois pas de code de traitement et optimiser sans voir le code, je sais pas faire.
Et enfin, tu parallelise ok, t'as au moins bencher pr savoir si c'etait bien ça qui était limitant ?

Merci pour la réponse.
Oui, j'ai benché et c'est bien ça qui est limitant. La copie du QGraphicsScene ne demande pas beaucoup de ressources car j'ai finalement peu de d'objets à l'intérieur comparativement aux boucles qui sont en réalité beaucoup plus nombreuses.
De toute façon, j'ai benché seulement les boucles (qui me permettent justement de sortir du contexte QT) et pas la copie du QGraphicsScene. Ma Question est surtout de savoir pourquoi lorsque je travaille sur 2 QGraphicsScene différents dans deux threads séparés contenant des boucles deux fois plus petites, les performances sont beaucoup moins bonnes qu'en effectuant une seule boucle ou les deux boucles à la suite et s'il y a une solution pour y remédier ou s'il y a un autre moyen de faire la même chose autrement.  
Après je peux toujours me passer de Qt, mais déterminer si un point est dans une ellipse dont les axes ne sont pas forcément ceux du système de coordonnées et qui peut se trouver en dessous d'une autre forme... Je n'ai pas trop envie de passer du temps à ça, mais s'il le faut (en sachant que je suis obligé de laisser l'interface graphique), je le ferai.

 
QT est pas bien codé ??? argumente please

QT date d'avant le temps ou la STL etait dispo partout, ça recode les deux tiers de la STL avec un modele antédiluvien. Ensuite, y a pas de RAII partout (ou tres peu), du static partout en interne ce qui rend la reentrance complexe etc...
 
Je critique pas la lib pr son coté GUI, elle fait bien son boulot, mais ca sent le renfermé des que tu ouvres le capot.
 
Et je parle pas des MOC :€

tu conseils  d'utiliser std::string/vector plutôt que  QString &co dans un projet qui utilise QT

il faudrait masi le pb c'ets que tu vas devoir passer ta vie à convertir car les fonctiosn Qt sont pas génériques

T'as pas des liens qui parle des carances de qt je trouve pas

http://doc.trolltech.com/4.5/templates.html
 
il parle ici de pourquoi les MOC sont comme ça

C++ with the moc essentially gives us the flexibility of Objective-C or of a Java Runtime Environment, while maintaining C++'s unique performance and scalability advantages

ouasi enfin, on peut faire pareil sans

ok donc QT in finé  c'est moisie, c'est ça qu'il faut retenir ?

non, ca fait sont boulot. Juste que c'est totu sauf du C++ moderne

qu'est ce qui caractérise le C++ moderne ? la liste est trop longue ?

Le jugement que je vois souvent, et qui semble correspondre à ce qu'en pense Joel F, est que Qt fournit pas mal d'APIs vraiment sympas et agréables à utiliser, mais que l'implémentation est plus douloureuse quand tu regardes comment ça fonctionne sous le chrome.

(par contre je pense aussi que la déclaration de Joel F comme quoi Qt est "codé avec les pieds" est spécieuse: le développement de Qt a été lancé en 1991, faut voir la gueule des compilos C++ de l'époque et je doute qu'il y ait eu une réécriture complète depuis donc les principes et bases de l'époque sont toujours là)

Voila
 

tu sais bien que spécieux c'est mon deuxième prénom
Avoir commencé en 1991 ne les dispensaient pas de refactoriser/moderniser de temps en temps non ?

ben faut faire des choix, soit tu supportes plus d'OS, tu proposes plus d'API... soit tu modernises les parties qui fonctionnent (et encore, j'suis pas sur qu'il faille pas se débarasser d'un certain nombre de compilos encore supportés par Qt pour le faire)
 
cela dit, dire que Qt est codé avec les pieds, pour moi ça reste du troll poilu

Ouasi enfin bon, tu peut faire tout en parallele aussi. Ca les tuerais pas d'avoir un branches modern/ dans leur SCV préféré.
 

Le terme est mal choisi mais d'experience il s'interface mal avec pas mal de composants standards et à des comportements inintuitifs aevc d'autres c'ets tout.

Dans le monde réel, t'es toujours limité en ressources et il faut prioriser. Si pour autant que Trolltech soit concerné le code Qt existant fonctionne et fait ce qu'ils demandent sans leur coûter des sommes faramineuses à maintenir et à étendre, ils n'avaient pas de raison de le réécrire (et perdre des années, et probablement tout pêter) juste pour s'amuser et faire plaisir à 3 gars sur un forum et 2 mailing lists

certes, après c'est une question de ressources
cela dit, c'est du LGPL maintenant, donc rien n'empêche quiconque de la faire cette dite branche, si Nokia n'est pas motivé
 

quelle idée d'utiliser d'autres composants, y a tout dans Qt
 

 
'fin c'est peut être par manque d'expérience, mais pour l'instant, j'ai pas trouvé d'autre toolkit aussi agréable à utiliser en C++

A mais, si le tiers des biblio tierces était comme Qt en terme de qualité d'interface, ca serait 'achement bien. Je critique l'impl. c'est tout.

Désolé de m'immiscer dans une discussion dans laquelle je ne connais pas grand chose, mais j'aimerais bien poser une question
 
Joel, tu dis que l'implémentation de Qt est pas terrible, mais n'est-ce pas un peu la même chose pour l'implémentation de tout "gros truc" devenu tellement énorme que plus personne n'a le temps/les ressources/les compétences pour pouvoir décider de lancer une restructuration?
 
ça me vient à l'esprit parce qu'il y a quelques temps je lisait un troll quelque part qui disait que le kernel de Linux est plein de bouts de code cradissimes, genre des boucles "for" pour créer des délais & co

 
Bah je croyais que le libre et le ouvert c'etait fait pour ? Mais quand il faut mettre les mains dans le cambouis, y a plus personne ?
Boost est un gros truc, et je peut te dire qu'on parle plein de fois de reecrire des pans entier à interface constante.  
 
Après pour pas passer pour un yakafokon, je repéte que je donnais juste mon avis d'utilisateur qui a du un jour devoir ouvrir un .cpp de Qt pour comprendre un bug infame dan sune appli mi MPI, mi pthread, mi Qt et d'avoir pleurer.  

 
Tu dis qu'on en parle souvent, mais est-ce que ça se fait à la fin? Parce que justement c'est là qu'on trouve un gros effet "yakafokon" comme tu dis.
 

 
La 1.37 a restructuré toutes les libs systemes (ficheirs, memoire aprtagées, asio) pour les rendre interoperables, la 1.40 a restructuré les ficheirs pr preparer la venue du build par CMake, je bosse sur la fusion lambda/Phoenix pour la 1.42 ...
 

Ouais, façon de parler quoi.

Qt c'est "vraiment" libre et ouvert (dans le sens où n'importe qui peut contribuer sans pb) depuis vraiment pas longtemps (le passage en LGPL et les dépôts publiques), faut laisser le temps que ça se mette en place, mais la politique de Nokia laisse penser que ça pourrait s'améliorer de ce coté là
 
sinon je pense que tu sais que pour mettre les mains dans le cambouis il faut la compétence et le temps, et même si n'importe qui peut contribuer au noyau linux par exemple, tout le monde n'a pas les ressources pour le faire
 
après je suis d'accord que sur certains cas, Qt peut sûrement poser des problèmes, mais dire tel quel que c'est codé avec les pieds comme tu l'as dit, ça pouvait laisser penser à qq1 qui ne s'en serait jamais servi et qui passerait par là qu'il vaudrait mieux éviter Qt, alors que dans 90% des cas ça répond parfaitement aux besoins, c'est pour ça que je me suis permis de dire que tu trollais.

j'ai du oublier le de service alors