SpeedUp médiocre avec openMP

**uriotcea** · 11/12/2010, 11h22

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Matthieu Brucher** · 11/12/2010, 11h27

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 !

**uriotcea** · 11/12/2010, 11h52

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

**Matthieu Brucher** · 11/12/2010, 12h05

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).

**uriotcea** · 11/12/2010, 12h26

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

**Médinoc** · 14/12/2010, 14h47

Au passage, e n'est pas initialisée.

**uriotcea** · 14/12/2010, 15h21

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.

**Matthieu Brucher** · 14/12/2010, 16h12

Faut voir ce que Parallel Studio te dirait, il te fait des courbes de speedup théoriques avant parallélisation très intéressantes.

**uriotcea** · 14/12/2010, 16h52

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

**JolyLoic** · 14/12/2010, 17h40

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.

**Matthieu Brucher** · 14/12/2010, 18h37

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

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).

**JolyLoic** · 14/12/2010, 18h57

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...

**uriotcea** · 14/12/2010, 19h32

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

**JolyLoic** · 14/12/2010, 19h51

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.

**uriotcea** · 15/12/2010, 00h12

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?

**Matthieu Brucher** · 15/12/2010, 07h48

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.

**uriotcea** · 15/12/2010, 09h52

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'

**Matthieu Brucher** · 15/12/2010, 19h44

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

et avec restrict tout court ?