Discussion :

[ant12oine]

Bonjour,
je suis en train de paralléliser un code Fortran à l'aide d'OpenMP qui calcule un produit de matrices de grandes dimensions: AxB = C.
J'ai donc un certain nombre de boucles pour initialiser les matrices puis pour le calcul du produit matriciel.
Après avoir parallélisé mes boucles principales, j'ai comparé le temps d'exécution de mon programme séquentiel et de mon programme parallélisé en utilisant la fonction time du shell.
J'obtiens que le programme non parallélisé s'execute plus rapidement.
Le but de la parallélisation est de diminuer les temps de calcul.
Les résultats que j'obtiens sont donc incohérents. L'utilisation de la directive
$OMP PARALLEL DO (RUNTIME) peut elle donner de tels résultats?
Merci d'avance

[yogitetradim]

Bonsoir,

la parallélisation a un cout à ne pas négliger ! Donc, des performances moins bonnes avec open-MP ne sont pas forcément incohérentes...
Les points à prendre en compte avant de savoir si oui ou non, le code pose problème sont :
=> Est-ce que ton exemple est taillé pour mettre en évidence l'intérêt d'openMP ?
=> Quels paramètres utilises-tu pour parallèliser (nombre de threads) et est-ce que la variation de ces paramètres entraine une variation de performance ?
=> Es-tu bien sûr que l'exécution du programme se fait sur le bon nombre de thread ?

Comme d'habitude...un ecm pourrait aider à t'aider ;-)

[ant12oine]

Bonsoir,
je te remercie pour ta réponse.
L'exemple que je considère est pertinent puisque c'est un code fortran d'un exercice corrigé fourni en ligne par l'IDRIS(Institut du développement et des ressources en informatique scientifique). Comme je l'ai dit, cette exercice effectue un produit matriciel et donc s'avère propice à l'utilisation d'OpenMP puisqu'il il y a plusieurs boucles imbriquées afin d'initialiser les matrices. J'ai pris des matrices de grandes tailles afin que les temps de calcul soit conséquent.

Pour information, j'utilise le compilateur d'Intel ifort.

J'ai effectivement fait varier le nombre de threads et l'option de la directive OMP DO (static, dynamic et guided) mais les résultats sont tous plus médiocres que le code non parallélisé.

Peut tu me dire ce qu'est un ecm.
merci

[yogitetradim]

pour info : ecm Exemple Complet Minimal (un petit jeu de donnée et/ou un code qui permet à ceux qui veulent comprendre ton problème de reproduire cet exemple).
Ici, tu n'en as pas besoin...puisque j'imagine que tu as fait tourner cet exemple, j'imagine.
Par contre si le nombre de thread qui t'est renvoyé semblent correct...je ne vois pas ce qui peux clocher...

[ant12oine]

C'est exactement sur cet exemple que j'ai travaillé. Après la compilation, je précise le nombre de threads que j'utilise : export OMP_NUM_THREADS=4 et je donne aussi OMP_SCHEDULE ="STATIC,400" par exemple (sachant que je ne sais pas très bien ce qui est le mieux approprié pour le choix de ces options.
Logiquement dans cet exemple, la parallélisation doit accélérer le temps de calcul ce qui n'est pas mon cas.
Le nombre de thread qui m'est renvoyé est correct.
Pour compiler cet exemple, je rajoute uniquement l'option de compilation -openmp.
Je te remercie pour tes explications. Si tu as d'autres remarques, n'hésite pas.

Edit :

Je pense que le compilateur intel ifort est performant. Je pense donc que l'utilisation d'Openmp est remarquable sur des programmes dont le temps d'execution est très conséquent. Qu'en pensez vous?
Merci

[TheOyoStyledMan]

Pour reprendre une des questions de yogitetradim: ton processeur a bien 4 coeurs pour faire tourner 4 threads? En faisant varier la variable OMP_NUM_THREADS de 1 à 8 par exemple, tu vois quel comportement de ton bout de code? Notamment, quand tu mets le OMP_NUM_THREADS=1, tu obtiens bien le même temps que ton code sequentiel?

(C'est des questions bêtes mais on ôte les doutes ainsi ^^)

Dernière précision: tu prends bien le "real time" de la commande "time" et non le "cpu time" quand tu dis que ce n'est pas bon?

[ant12oine]

Tout d'abord merci pour vos réponses.
J'ai résolu mon problème. En fait plusieurs personnes travaillaient sur la même station ce qui ralentissait mon programme parallélisé. Maintenant j'obtiens de bons résultats.
J'ai tout de même d'autres questions.
Est ce qu l'on obtient toujours le même résultat en terme de temps avec le programme non parallélisé et le programme parallélisé avec un thread? J'ai fait des tests qui vont dans ce sens mais je voudrais savoir si c'est toujours vrai.
Mon processeur a 2 coeurs. Dois je donc utiliser toujours 2 threads? J'ai fait des tests avec plusieurs threads (entre 1 et 6). Cela me donne de bons résultats par exemple avec 4 threads. On peut avoir plusieurs threads pour un processeur, non?
merci d'avance

[genteur slayer]

on peut parfaitement avoir un grand nombre de thread sur un même coeur, cependant l'intéret est limité: chaque thread va prendre un peu de puissance... de plus quel proc as-tu? parce que beaucoup de processeur intel récent ont le "hyperthreading" en gros c'est un doublage du registre d'entrée de chaque coeur: le coeur bascule en permanance de l'un à l'autre. et cette techno te fait apparaitre 4 graphiques de processeur dans le taskmanager de windows alors que physiquement tu n'as que deux coeurs... d'où les bonne perf avec 4 thread...

De plus, il faut savoir que ifort vectorise les boucles: en gros il choisi un ordre de parcours legèrement modifier pour aller plus vite en mémoire. il ne le fait pas lorsque la boucle est parallèlisée avec openMP... si ta boucle ne fait pas suffisament d'opérations, la version parallèle sera plus lente.

Enfin, il est rare d'avoir deux fois le même temps d'éxécution (que ce soit en version parallèle ou directe) tout simplement parce que ta machine fait d'autres choses en même temps et donc cela parasite un peu ton calcul... cependant, j'imagine que tu dois avoir un calcul légèrement plus lent avec OpenMP sur un seul thread, mais que cette différence dois être constante lorsque tu fais varier la taille du système: le calcul en lui-même prend le même temps, mais l'initialisation d'openmp se fait en plus.... genre quelques milisecondes...

un autre bon moyen d'accélérer un programme, outre la parallèlisation, c'est une gestion mémoiore intélligente, mais ça, c'est une autre histoire!

[ant12oine]

Bonjour,
mon processeur est un intel core 2 duo E6850. J'ai regardé les caractéristiques sur le site d'Intel. Apparemment, la technologie hyper-threading n'est pas pris en compte par ce processeur.
Comment peut on alors expliquer les bonnes performances avec 4 threads alors qu'avec 3 threads les resultats sont moins bons.

[Matthieu Brucher]

Est ce qu l'on obtient toujours le même résultat en terme de temps avec le programme non parallélisé et le programme parallélisé avec un thread? J'ai fait des tests qui vont dans ce sens mais je voudrais savoir si c'est toujours vrai.

Ca dépend. Tu seras toujours plus lent que le programme sériel car tu as des actions supplémentaires : démarrage du pool de threads, calcul du découpage, ...

Mon processeur a 2 coeurs. Dois je donc utiliser toujours 2 threads? J'ai fait des tests avec plusieurs threads (entre 1 et 6). Cela me donne de bons résultats par exemple avec 4 threads. On peut avoir plusieurs threads pour un processeur, non?
merci d'avance

2 threads est l'optimum. Avec 3 threads, tu vas avoir des switchs de threads importants qui vont te bouffer le pipeline, le cache, ...

[SebGR]

Bonjour,

Difficile de conclure sans cas-test. Il serait intéressant de regarder si tu ne consommes pas du cache inutilement.

Je viens justement de traduire 2 présentations sur le sujet : Parallélisme ou Performances ? et ThreadSpotter.

-SebGR