Philippe Marion 3500ce6b1d Update 'OAR_array/pi_input.txt' | il y a 8 mois | |
---|---|---|
.. | ||
Makefile | il y a 6 ans | |
README.md | il y a 3 ans | |
gc_input.txt | il y a 6 ans | |
gc_matlab_array.oar | il y a 3 ans | |
gc_postraitement.sh | il y a 6 ans | |
gradientconj.m | il y a 6 ans | |
hello-openmp.c | il y a 6 ans | |
hello-openmp.oar | il y a 6 ans | |
pi.c | il y a 6 ans | |
pi_array.oar | il y a 6 ans | |
pi_input.txt | il y a 8 mois |
La «bonne pratique» pour lancer massivement, en parallèle, le même
programme avec des paramètres différents : **utiliser l'option
--array-param-file parametres.txt
d'OAR **. Cette option lance un
«tableau de tâches» chacune indépendantes les unes des autres
Note: ce fichier peut contenir des centaines, des milliers de lignes
#OAR --array-param-file parametres.txt
Rappel: en besteffort, les ressources sont illimitées mais les jobs sont non prioritaires (ils peuvent être supprimés sans préavis si des jobs de priorité supérieure sont lancés). À noter dans ce cas que le strict nécessaire aux jobs prioritaires est «libéré»: ce n'est pas le tableau de tâches qui est intégralement supprimé. De plus, l'option idempotent permet de relancer automatiquement toutes les expériences (qui auraient été tuées par des jobs prioritaires)
le programme pi.exe calcule une approximation de pi par l'intégration de f(x)=4/(1+x^2) sur [0;1]. Le nombre d'intervalles est passé en argument (regroupé dans le fichier pi_input.txt)
Le programme résout un système linéaire par la méthode itérative du gradient conjugué. Le script matlab a été tranformé en fonction: gradientconj(n,tolerance,maxiter)
Les fichiers sont dans le sous-répertoire "ex3". l'exemple, pour la démo, est sans grand intérêt (20 fois la même multiplication de deux matrice A(n,n) x B(n,n) remplies de 1 ...).
Néanmoins, l'usage d'OpenMP est extrêmement performant pour effectuer ces opérations (tester le programme fortran sur votre poste de travail en fixant successivment différentes valeurs de la variable d'environnement OMP_NUM_THREADS pour vous en convaincre: export OMP_NUM_THREADS=x (x=1,2,4...))
L'exemple est donné ici pour illustrer comment adapter un script OAR pour une campagne de test ( donc usage d'un OAR_ARRAY ) avec un programme multithreadé, en utilisant de façon optimale un nœud de calculco:
Pour cela:
-l /cpu=1/core=4
.
Ainsi, quelque soit le nombre de tests à effectuer (donc le nombre de ligne dans le fichier matmul_input.txt), il y a garantie qu'ils seront lancés par lot et que la totalité du nœud orval06 sera utilisé (cpu n°1 : 2 jobs de 4 threads; cpu n°2 : 2 jobs de 4 threads, soit 4 jobs de 4 threads exécutés simultanément sur les 16 coœurs d'orval06, jusqu'à épuisement du fichier paramètres matmul_input.txt)
Rq: compte tenu de «l'efficacité» d'OpenMP pour l'exécution de ce programme fortran, on obtient un temps global du test tout à fait équivalent en les lançant par lot de 2. il suffit de modifier le script matmul_array.oar:
#OAR -l /cpu=1/core=8,walltime=20:00
export OMP_NUM_THREADS=8