Discussion :

[uriotcea]

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]

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]

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]

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]

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]

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