Discussion :

[uriotcea]

oui oui je parlais des pointeurs

[uriotcea]

Ok, c'est moi qui faisait faisait pas correctement les choses, j'ai enfin réussi à mettre 'restrick' à mes pointeurs, mais le resultats est le même. Ca ne change pas grand chose.

[SebGR]

Bonjour,

Effectivement, ce n'est pas brillant , comme l'atteste le rapport en attachement (il y a un peu de tout, dont le fameux false sharing évoqué auparavant, mais aussi des problèmes de localité spatiale, temporelle).
Il a été généré par un outil nommé ThreadSpotter (sous licence). Vraiment pratique, quelques secondes pour déterminer là où ça ne va pas et quels sont les remèdes à envisager. Pour info, j'ai fait ça à l'arrache sur Windows 7 x86_64 et MSVS 2010 (4 threads).


-SebGR

[uriotcea]

Bonjour,

Ok je n'y comprend pas grand chose, mais merci de tes indications.
Est ce que cette outil, ThreadSpotter est lié à MSVS.

[SebGR]

Non, ThreadSpotter n'est pas adhérent au compilateur. Il fonctionne sous Windows et Linux.


-SebGR

[uriotcea]

Ok merci, mais il semblerait que ce soit payant !

[Matthieu Brucher]

Oui, c'est payant.

[dybmans]

Bonjour,

est-ce qu'il y a un équivalent à ThreadSpotter sous linux gratuit ?

Merci par avance pour vos réponses

[dybmans]

Le passage suivant de ce tuto peut peut être t'aider :

http://www.unixgarden.com/index.php/...le-avec-openmp

4.3


Répartition des tâches

Sans spécification particulière, les tâches sont réparties de manière égalitaire entre les différents threads. Les threads traitant le centre de la fractale ont plus de calculs à traiter que les threads chargés de l’extérieur de la fractale. Les threads les plus rapides attendent donc les threads les plus lents avant la finalisation du programme. La répartition des tâches est configurable à la fin de la directive omp parallel for avec la clause schedule. Le découpage peut se faire selon quatre manières différentes.

4.3.1


Répartition statique

Si rien n’est spécifié, la répartition statique est utilisée, elle peut être aussi explicitement choisie en utilisant la clause schedule(static). Le nombre d’itérations de la boucle est divisé par le nombre de threads, tous les threads traitent donc la même quantité de données. Il est possible de fixer le nombre de données traité par chaque thread après la déclaration static, par exemple : schedule(static,32).

4.3.2


Répartition dynamique

Chaque thread traite une quantité de données spécifiée par la taille passée après dans la déclaration dynamic. Dès qu’un thread a terminé son lot de données, il peut reprendre un lot de données à traiter. Les threads n’ont pas d’ordre de passage, certains peuvent être plus longs que d’autres.

Par défaut, un seul élément est traité par chaque thread. Le nombre d’éléments traités peut être fixé après la déclaration dynamic. Sauf si les calculs sont très longs, il doit être initialisé pour prendre une valeur supérieure à la valeur par défaut : schedule(dynamic,32).

4.3.3


Répartition guidée

Cette organisation des tâches est basée sur une taille décroissante des blocs traités. Au départ, les threads traitent une grande quantité de données, puis le nombre d’éléments traités décroît pour optimiser le temps de calcul. Le nombre minimal d’éléments à traiter est fixé par la valeur passée en paramètre.

4.3.4


Répartition à l’exécution

Il est possible de choisir la méthode de répartition des tâches lors de l’exécution du programme. Pour obtenir ce comportement, on utilise la clause schedule runtime. La répartition et ses paramètres sont alors configurés par la variable système OMP_SCHEDULE. La répartition à l’exécution n’est utile que pour le développement afin de tester différentes stratégies de répartition.

4.3.5


Considérations générales pour le choix d’une stratégie

Quelle que soit la solution retenue, la taille des blocs doit être fixée en prenant en compte les deux limites suivantes :

● Si les blocs sont trop gros, le temps de calcul des threads est déséquilibré, certains sont plus lents que d’autres.

● Si les blocs sont trop petits, le temps de changement de contexte (chargement des nouvelles valeurs pour un thread) peut être significatif vis-à-vis du temps de calcul des threads.

[uriotcea]

Ok merci pour les explications et l'example.
Pour ma part, j'ai un processeur 6 coeurs hyperthreadé, donc à priori 12 threads. Et un peu comme les examples de ton article, j'atteind aprés optimisation, un speed-up relativement linéaire jusqu'à 6 puis un faible gain jusqu'à un maximum de 8.

[Joel F]

c'est peut etre tout simplement la faute a Amdhal.
Ton algo est il 100% parallelisable ?