Bonjour,
alors voila je suis en train de m'arracher les cheveux sur un problème et je cherche toute aide possible. J'ai un programme que je compile avec intel fortran (ifort) d’habitude mais il faudrait que je le compile en gfortran et si possible avoir presque les même performances. Sur un coeur/processeur aucun soucis. Là où ça se corse c'est en openmp...
Sous ifort avec les bibliothèque mkl sur un quad-core le scaling est de presque 4 (ne regardons pas les décimales). Par contre avec gfortran avec les mêmes bibliothèques ça devient proche de 1... Donc autrement dit je passe mon temps dans un seul processeur.
J'ai essayé avec la bibliothèque goto2 mais c'est pareil.
Après moultes recherches/debug je ne trouve rien à part quelques personnes qui ont le même soucis et qui restent sur ifort et ne cherchent pas plus loin.
J'ai fait un profile d'un calcul assez typique et en fait plus de 90% du temps je suis à calculer zgemm. Donc forcément le scaling doit se faire ici ! J'en déduis, à l'heure actuelle, que gfortran ne cherche pas à utiliser les threads lors du call zgemm() alors que ifort le fait.
J'ai essayé les flags: -O2, -O3, -m64, -fopenmp, -frecursive, -floop-parallelize-all, -ftree-loop-distribution, -ftree-parallelize-loops=n, -march=native.
Pour intel fortran je ne mets que le flag -i8 donc tout le reste est par défaut.
J'ai vu un site qui m'a fait penser que les call pouvaient ne pas être parallèles avec des options mais c'est pour pgf. J'ai lu je ne sais combien de fois le man de gcc et gfortran mais rien sur un flag qui permettrait cela à art ceux que j'ai testé.
Je remercie toute personne qui aurait déjà vu/eu ce problème et résolu.
# OMP_NUM_THREADS
Posté par François Trahay (site web personnel) . Évalué à 2.
Si zgemm n'est pas parallélisé, tu peux tenter de forcer le nombre de threads OpenMP:
[^] # Re: OMP_NUM_THREADS
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Ah oui mince j'ai oublié de dire que je lançais le calcul comme ça : export OMP_NUM_THREADS=4 ; ./mon_appli
En fait au départ le calcul charge bien les coeurs puis il arrive dans un zgemm et il passe que dans un coeur. Sachant que zgemm est celui de la bibliothèque mkl il est déjà multithread. De plus, il marche en ifort.
[^] # Re: OMP_NUM_THREADS
Posté par lolop (site web personnel) . Évalué à 4.
Une idée comme ça [*]: si zgemm est celui de la bibliothèque mkl, MKL_NUM_THREADS=4 est peut-être nécessaire...
[*] Je n'ai utilisé OMP+MKL qu'une, fois pour un soft récupéré par ailleurs.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: OMP_NUM_THREADS
Posté par MarbolanGos (site web personnel) . Évalué à 3.
Salut,
cela semble la bonne solution j'avais testé mais sans succès. Mais ce matin j'ai eu une idée et c'était la bonne dans le même style mais avec la libgoto.
Donc en fait j'ai recompilé le tar.gz en allant voir dans le Makefile.rule il y a un NUM_THREADS = 24 qui était commenté.
Ensuite j'ai recompilé le tout et il donne bien : Library Name ... libgoto2_nehalemp-r1.13.a (Multi threaded; Max num-threads is 24)
Puis on recompile le logiciel avec : -L$(PATH) -lgoto2
Et on lance avec : export GOTO_NUM_THREADS=2 ; export OMP_NUM_THREADS=2 ; ./program
J'ai pas essayé avec la lib mkl mais ça doit être la même chose à mon avis. Donc si ça se trouve ifort déclare automatiquement le MKL_NUM_THREADS... C'est un peu pas safe comme comportement quand même !
Merci pour l'aide !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.