SpeedUp médiocre avec openMP

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour,

Je test ma machine (processeur 6 coeurs+ hyperthreading: donc 12 threads possibles) en programmation openMP et j'ai des speedup plutôt décevant que je ne comprend pas trés bien. Avec l'example ci-dessous mon speedup plafonne entre 3 et 4. J'ai beau augmenter la taille de la boucle,N ,je n'obtient pas mieux. Quelqu'un connaitrait-il des raisons expliquant ces médiocres résultats.
Est-ce du à l'architecture du microprocesseir intel? Ou mes directives openMP ne sont pas obtinmisées.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 double e,*c,*d; int k,N=1e8; c= new double[N]; d= new double[N]; omp_set_num_threads(12); #pragma omp parallel for private(k) reduction(+:e) for (int i=0;i<N;i++) { k=i; d[k]=10.225*(double)i; c[k]=d[k]/1251.5; c[k]+=11.9+d[k]+d[k]/2568+d[k]*0.025; c[k]-=10.36-2.4*d[k]; e=e+cos(c[k]); } delete[] c; delete[] d;
Pour info: ne cherchez pas de sens à ce calcul, c'est just un test.
Je travaille en win64 ou Linux64 ubuntu avec gcc4.5

11/12/2010, 11h27
Matthieu Brucher

Tout dépend de la taille des blocs, il faudrait faire des chunks (surtout que tu as des accès très proches, il est possible que le proc fasse pas mal de défauts de cache).

Ensuite, c'est quoi le k ? Tu devrais plus avoir un i privé qu'un k !
11/12/2010, 11h52
uriotcea

Merci de ta réponse, le k ne sert à rien, c'est juste histoire de compliquer un peu. Peux-tu etre plus explicites à propos des chunks
11/12/2010, 12h05
Matthieu Brucher

OpenMP découpe la boucle en morceaux (taille statique, dynamique, ... ça dépend). Si le morceaux est trop petit, il y a beaucoup d'overhead pour la gestion des morceaux. S'il est assez grand, un morceau va gérer au moins une ligne de cache, et donc très peu de comm et pas de mise à jour à faire entre les coeurs (car ils ne partagent pas les lignes de cahc eL1).

Là aujourd'hui je n'ai qu'une machine 2 processeurs sous la main et visiblement ne pas mettre de schunk semble etre l'optimal, en même temps j'ai bien saisi la doc ci-dessous, mais je ne vois pas diretement le lien avec les performances. A part 'Dynamic' qui semble donner de plus mauvais résultats sur 2 cores, les autres choix ne donnent pas d'amélioreation evidentes. Lundi, je vais faire des testes sur ma machine 12 threads et ainsi peut-etre mettre plus en évidence ce que fait cette directive et peut-etre amméliorer les performances
Code:

1 2 3 4 5 6 La clause SCHEDULE spécifie la manière de partager les itérations entre les threads. Au sein de cette clause, chunk est un entier et type peut être : STATIC : SCHEDULE (STATIC,chunk) impose un découpage du nombre d'itérations en blocs de taille chunk. Ces blocs sont attribués aux différentes threads de manière statique en suivant une distribution de type round-robin dans l'ordre des numéros des threads. En l'absence de chunk, les itérations sont réparties parmi les threads en bloc continu. DYNAMIC : SCHEDULE (DYNAMIC,chunk) impose le découpage du nombre d'itérations en blocs de taille chunk. Lorsque chaque thread a fini son bloc, elle reçoit dynamiquement le prochain groupe. Lorsque chunk est omis, la valeur par défaut est 1. GUIDED : SCHEDULE (GUIDED,chunk) impose une décroissance exponentielle de la taille chunk des paquets d'itérations qui sont distribués. Lorsque chunk est omis, la valeur par défaut est 1. RUNTIME : SCHEDULE (RUNTIME) indique que la distribution (type et chunk) des itérations sera effectuée durant l'exécution et ces paramètres seront fixés à l'aide de la variable d'environnementOMP_SCHEDULE. Le paramètre chunk doit être omis.

14/12/2010, 14h47
Médinoc

Au passage, e n'est pas initialisée.
14/12/2010, 15h21
uriotcea

Oui, merci c'est uniquement une erreur de recopie.
Bon j'ai fini par faire des tests avec une machine 12 threads, et je n'ai remarqué qu'un certain mieu en utilisant le mode "guided" et pour les petit nombre d'itérations. Sinon le mode "dynamic" agrave les choses. Et quand la boucle devient grande "Guided" devient similaire à "Auto". Je trouve surprenant que quand ma boucle devient trés longue "plusieurs minutes", je n'arrive pas à m'apporcher du speed-up théorique maximum.
14/12/2010, 16h12
Matthieu Brucher

Faut voir ce que Parallel Studio te dirait, il te fait des courbes de speedup théoriques avant parallélisation très intéressantes.
14/12/2010, 16h52
uriotcea

Parallele studio est payant et nécessite l'installation de visual que je ne posséde pas. Je travaille uniquement avec GNU gcc
14/12/2010, 17h40
JolyLoic

Regarde "false sharing" sur le web (en particulier les articles de Herb Sutter), j'ai l'impression en parcourant rapidement ton code que tu es pile poil dans cette situation.
14/12/2010, 18h37
Matthieu Brucher

Citation:

Envoyé par uriotcea

Parallele studio est payant et nécessite l'installation de visual que je ne posséde pas. Je travaille uniquement avec GNU gcc

Il y a des versions d'évaluation ;) Mais c'est vrai que si tu n'as pas Visual, la version Linux sous Eclipse n'a pas Advisor :(

Citation:

Envoyé par JolyLoic

Regarde "false sharing" sur le web (en particulier les articles de Herb Sutter), j'ai l'impression en parcourant rapidement ton code que tu es pile poil dans cette situation.

C'est pour ça que je lui avais indiqué de modifier la taille des chunks pour éviter le false sharing (entre autres).
14/12/2010, 18h57
JolyLoic

Pour faire ça proprement, il vaudrait mieux changer le mode de stockage des données...Parce qu'autrement, les chunks devraient être plus gros que le cache du processeur pour que ça ait de l'effet, ce qui risque de réduire les possibilités de parallélisation...
14/12/2010, 19h32
uriotcea

Ok, j'ai lu un peu sur le false sharing, je comprend bien le probléme, mais je ne vois pas bien comment mettre ca en evidence dans mon example
14/12/2010, 19h51
JolyLoic

Fait un tableau 100* plus gros, et modifie ta boucle pour ne lire qu'une valeur sur 100, et regarde si ça change quelque chose...
Ce n'est certainement pas une solution très propre, mais ça devrait donner une bonne idée si c'est bien le problème.

Une autre façon, mais moins sure (car le compilo optimise peut-être déjà...), serait de remplacer tes c[k] par des variables locales, et ne les écrire que tout à la fin pour minimiser les accès au tableau.
15/12/2010, 00h12
uriotcea

Ok j'ai essayé de multiplier par 100 la taille des tableau comme tu me le suggerais. J'ai essayé 2 types calculs similaires à mon example avec à chaque fois une dégradation légére (Mais présentement, je n'ai qu'un bicore..)

L'explication en viendrait pas du fait que l'hperthreading n'est pas vraiment équiavent à un vrai bi-pro?
15/12/2010, 07h48
Matthieu Brucher

Comme tu fais pas mal d'opérations pour les quelques accès mémoire, ça ne devriat pas.

Essaie d'ajouter le mot-clé __restrict sur tes tableaux.
15/12/2010, 09h52
uriotcea

Je ne vois pas à quoi sert ce mot clef. Cela dit, il me génére un message d'erreur à la compilation

error: '__restrict__' qualifiers cannot be applied to 'double'
15/12/2010, 19h44
Matthieu Brucher

Le mot clé permet d'indiquer qu'aucun autre pointeur n'accède à la même zone mémoire, donc pas la peine de recharger la donnée à chaque fois, de peur qu'un autre processeur/opération ait modifié l'emplacement.
En revanche, c'est bizarre que ça ne marche pas pour les double :koi: et avec restrict tout court ?
15/12/2010, 20h30
uriotcea

Visiblement ne marche pas non plus avec les int
15/12/2010, 20h32
Médinoc

C'est pour les pointeurs, restrict.

Voir 40 message(s) de cette discussion en une page