Discussion :

[lorenzaccio91]

Bonjour,

Je débute en programmation parallèle de type OpenMP dans du code C. J'ai écrit des petits programmes (doubles et triples boucles imbriquées avec manipulation concurrente de tableau : les différents threads peuvent avoir besoin d'écrire dans les mêmes éléments du tableau) pour tester la protection des variables (avec les pragma private,critical,...) et tout marche bien. Sur mon MacBookPro, les 8 threads font le boulot et accélèrent le code, sous Linux, le même code est pareillement accéléré (machine ancienne mais avec 48 coeurs, je double mon MBP dans la côte!) et les résultats sont les mêmes avec ou sans parallélisation.

MBP :
time essai_par > ! thread_8.dat
489.991u 9.919s 1:11.32 700.9% 0+0k 1+5io 0pf+0w

Linux :
time essai_par > thread_48.dat
3372.099u 1.047s 1:10.29 4798.8% 0+0k 0+0io 0pf+0w

Après les choses sérieuses : j'ai un programme en C un peu complexe mais il y a principalement une routine qui a besoin d'être accélérée (2 boucles imbriquées, même besoin d'accès concurrent au tableau des résultats que dans mes tests ci-dessus). J'ai parallélisé la routine. Sur le MBP, tout va bien : les 8 threads bossent j'accélère le calcul d'un facteur 4 sur l'ensemble du programme. Sur la machine Linux, c'est la catastrophe : TOP indique que seulement 1 à 5 coeurs travaillent (au lieu des 48) tout en affichant en %CPU pour le job particulier des taux de 4000% et au final, il met plus de temps à faire le calcul que si je le limite à 1 seul thread (2 à 3 fois plus longtemps !). Et time montre que le système a utilisé un temps monstrueux.

Typiquement ceci :

$setenv OMP_NUM_THREADS 48
$time sizedust var_nH_1E7_0.5My.dat > prov.dat
18630.506u 48752.147s 28:32.28 3935.2% 0+0k 0+0io 0pf+0w
$setenv OMP_NUM_THREADS 1
$ time sizedust var_nH_1E7_0.5My.dat > ! prov_1thread.dat
670.060u 0.014s 11:10.21 99.9% 0+0k 0+0io 0pf+0w

alors que sur le MBP le temps système ne sera qu'une petite fraction du temps total.
Les résultats sont tous identiques, il n'y a pas de souci de ce côté-là mais pourquoi le programme passe sur MBP et pas sous Linux en mode parallèle ?
J'ai essayé deux versions de gcc (5 et 7), ça ne change rien. J'ai essayé 3 machines Linux différentes, toutes ont le même problème.

1) est-ce que quelqu'un a déjà rencontré ce problème (et a-t-il/elle trouvé la cause voire même la solution) ?
2) quels tests faire pour essayer de comprendre ?

Merci

[sambia39]


Bonjour,
Personnellement, le comportement dans le cas actuel est difficile à expliquer précisément, car il peut être dû tout simplement à de nombreux facteurs comme une architecture et processeurs différents, mais aussi la fréquence des processeurs utilisés n’est pas cadencée de la même façon, sans compter la façon dont vous avez écrit les instructions compilées et exécutées. Il nous manque un ensemble d’informations qui ne nous permet pas de tester ou de faire une simulation. Il faudrait donc fournir plus de détails, mais aussi de votre côté, effectuer plus d’investigations, exemple : sous Linux, utilisez 8 coeurs au lieu de 48 cœurs et faites la comparaison avec votre Mac OS ou inversement ; sous Mac OS utilisez UPC et faites la comparaison avec les précédentes valeurs Mac OS (OpenMP) et Linux (OpenMP avec 8 cœurs) et Linux(OpenMP + 48 cœurs).

Présentement, tout cela reste des pistes et hypothèses et n’oubliez pas que vous effectuer des tests sur des systèmes d’exploitation voisins, mais bien différents: un BSD(Unix) n’est pas un Linux(Minix), mais aussi que vous exécutez probablement votre programme sur des coeurs/processeurs qui sont probablement cadencés à des fréquences différentes. Le Mac peut être cadencé sous 2 GHz contrairement à 48 cœurs cadencés à un gigahertz sous Linux par exemple. Sans compter qu'OpenMP est limité en partage mémoires et que celui-ci utilise des parallèles blocs par boucles. En d’autres termes, chaque parallèle bloc est parallélisé.


Aussi, la version de Linux avec laquelle vous faites vos comparaisons n’est pas optimisée. J’entends par là que des Linux dédiés à des calculs scientifiques poussés, donc des Compute Node Kernel (CNK) ou des Compute Node Linux (CNL), bref et donc, si vous sollicitez les 48 cœurs celui-ci a dû faire face au problème de l'évolutivité du partage de mémoire sous OpenMP donc le fameux problème scalabilité et d’un autre côté est-ce nécessaire d’utiliser un les 48 coeurs pour un programme qui pourrait en solidité que très peut de ressources, c’est un peut du gâchis


À bientôt.