Bonjour à tous!
 
Voilà j'ai essayé de paralléliser un petit bout de code tout bête :
 

 
Donc il s'agit principalement de remplir un vecteur à partir d'un autre avec un traitement extrêmement simple entre les 2.
Pour paralléliser ça, j'ai fait ça (attention les yeux, je suis pas expert de code parallèles   ):
 

 
Et donc là il s'avère que c'est plus lent que la bête boucle à la ***    
Donc je voulais savoir si c'est que j'ai une connerie quelque part ou bien juste qu'ici, comme il s'agit principalement d'accès mémoire, au final ça marche mieux en séquentiel?
 
Merci  

quelle qté de donnée par thread, cb de thread ? gaffe au false sharing et au acces cache foiruex

franchement plus simple en openmp ce cas la.
et sinon un petit tour coté wikipedia pour chercher 'protocole MESI'

 
Pour l'instant chaque vecteur contient environ 5000 a 10000 doubles mais ensuite il y en aura dans les 100000. Le tout réparti sur 8 threads.
Qu'entends-tu par false sharing et au acces cache foireux?
 

 
Disons que comme j'utilise déjà Boost pour d'autres choses, je me suis dit autant continuer avec. Et il me semble que mon code ressemble à la version Static d'une boucle OpenMP non ?
Et pour MESI j'ai moyennement compris le rapport avec le schmilblick.  

Je viens de regarder un peu le false sharing (du coup je vois mieux le rapport avec MESI) et donc en fait faire des copies locales pour chaque thread pourrait résoudre le problème apparemment ... mais je trouve que la parallélisation perd de son intérêt dans ce cas. Il n'y a pas de méthode un peu plus jolie pour contourner ca ? Et est ce que OpenMP gère ca tout seul ?

 
Il me semble que tu ne donnes pas grand chose à faire à tes threads.  Mesure une fois le temps qu'il faut pour lancer 8 threads qui retournent immédiatement et puis faire un join dessus...

oui le tout est de juger l'overhead. tu peux aussi faire l'essai en charge pleine (avec 100000) et mesurer le temps pris avec une boucle sans thread, par rapport a ta version 8 threads.
aussi, openmp ne fera pas de copies automatiques pour eviter les synchro de lignes de cache. tu ne gagnes rien par rapport a ton code, et oui, tu as raison ce que tu as fait correspond a un parrallel for a schedule static.
je le préconisait juste parce que ca réduit quand même de moitié le nombre de lignes

Bon je viens de tester quelques trucs (copie locale, utilisation d'itérateurs, ordre de parcours des vecteurs, ...) mais rien y fait : je pers toujours du temps quand j'augmente le nb de threads ...
J'imagine qu'il n'est pas possible de paralléliser un traitement aussi simple qui se résume essentiellement à des accès mémoire. Dommage
 
Merci pour votre aide en tout cas
A+!

Tu as combien de core? Avoir plus d'une thread par core n'a aucune chance d'etre interessant.

sachant qu'il a aussi raison, a partir du moment où le jeu de donnée dépasse le cache L2 des coeurs, il faut aussi que le bus soit accessible en parallele. ce qui n'est pas le cas sur les quad core Qxxxx par exemple. mais seulement sur les Xeon et les core i7. chez AMD ca l'a toujours été par contre, c'est la raison de la grande adoption des opterons sur les serveurs.
 
si je ne dis pas de bêtises.

Désolé je n'avais pas vu les réponses
 
J'ai 8 cores disponibles avec 16Go de RAM partagée. Donc j'ai déjà parallélisé pas mal de choses dans mon code et ça va beaucoup plus vite. Je me demandai juste s'il était aussi possible de gagner quelque chose sur ce genre d'opération très simple mais apparemment non.
 
Et le type de processeur est Intel Xeon X5472. Donc les Xeon n'ont pas l'air d'avoir l'accès parallèle non plus (ou alors ca ne suffit pas pour ce que je veux faire )

En fait comment est ce que tu mesures que c'est plus lent ?

Avec time. Les tests que j'ai fait duraient une 12-aine de minutes et j'avais environ 35 - 40s d'écart (tout à fait reproductible, à 5s près) quand je faisais avec ou sans thread.

gaffe à ne pas créer tes threads et les détruire àchaque fois que tu en as besoin. Si ca entre dans ta mesure, tu dois pouvoir te débrouiller avec un pool de threads.
 
Ca peut être pas mal de considérer que tu as un pool de jobs à faire, tous ayant le même code, ,mais des datas différentes à faire
et d'utiliser un nombre de thread correspondant à ce que ton matériel te propose.
 
Surcharger une machine de threads n'est pas une bonne idée. Les créer à chaque utilisation non plus. Ce sont les deux grosses guidelines que je peux donner à ce sujet.
 
edit : pour clarifier : si tu as une machine avec 8 threads hardware, ca peut être une bonne idée de créer 8 threads et de leur faire traiter tes 200 jobs au fur et à mesure qu'ils achèvent le boulot plutôt que de créer en frontal 200 jobs et laisser l'OS se démerder.

oui j'ai fait attention à ça. Ailleurs dans mon code j'ai imposé la condition :
 

Je ne l'avais pas mis dans le code que j'ai posté car c'est ailleurs dans mon code mais c'est bien présent
Et dans le oute j'avai essayé d'imposer plusieurs nombres, de 1 à 32 (alors que je n'ai que 8 cores) et dés qu'il y en a plus de 1 je pers du temps. Et plus j'ajoute des threads plus je pers du temps...

mmh, c'est sympa de te plaindre de la lenteur de tes threads dans un contexte différent de celui que tu nous présente. Dans ma boule de cristal, je ne vois pas plus de choses que ce que j'ai dit plus haut.
 
Si tu ne veux pas donner le code qui te pose vraiment problème, fais du profiling.
Mesure en terme de proporition le temps que tu passes dans des appels systèmes pour créer les threads et le temps que tu passes à exécuter chaque thread. regarde si les ordres de grandeurs sont proches, parce que je soupçonne que ce sera le cas.