Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
logiciels:mkl:mkl-et-parallelisme [2015/06/03 17:59] montap01 [MKL et parallélisme] |
logiciels:mkl:mkl-et-parallelisme [2015/06/04 11:49] (Version actuelle) montap01 [Réserver un nœud complet] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== MKL et parallélisme ====== | ||
~~SLIDESHOW yatil~~ | ~~SLIDESHOW yatil~~ | ||
+ | ====== MKL et parallélisme ====== | ||
- | Nous avons vu dans l'[[start |introduction à la MKL]] que cette librairie est **par défaut** en mode // | + | Nous avons vu dans l'[[mkl |introduction à la MKL]] que cette librairie est **par défaut** en mode // |
L' | L' | ||
Ligne 65: | Ligne 65: | ||
* '' | * '' | ||
* '' | * '' | ||
+ | |||
+ | ===== Slurm ===== | ||
+ | A ce stade, nous avons vu que : | ||
+ | * la couche de threading va en général lancer plusieurs threads | ||
+ | * si nous le désirons, nous pouvons explicitement fixer un nombre maximum de threads utilisables | ||
+ | |||
+ | Nous allons maintenant voir comment écrire correctement votre job //slurm//. | ||
+ | ==== Pourquoi y prêter attention ? ==== | ||
+ | Sur le cluster, nous lançons les jobs via //slurm//. La réservation demandée à slurm devra correspondre à la consommation de CPU occasionnée par les threads, **sinon les nœuds de calcul seront en sur-allocation et leur performance se dégradera pour tous les usagers**. | ||
+ | |||
+ | Une alternative courante dans les grands centres de calcul est de ne permettre que un et un seul job sur un nœud à un instant donné. Un problème de sur-allocation n' | ||
+ | |||
+ | ==== Plusieurs approches possibles ==== | ||
+ | Plusieurs manières de créer une demande de réservation correcte sont possibles. | ||
+ | |||
+ | Nous proposons ici deux méthodes. Suivant vos besoins et votre compréhension de la MKL et de slurm, vous pouvez envisager des alternatives. | ||
+ | |||
+ | ==== Réserver un nœud complet ==== | ||
+ | Puisque la MKL " | ||
+ | |||
+ | Ajouter dans votre fichier de job : | ||
+ | < | ||
+ | #SBATCH --exclusive | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Réserver le " | ||
+ | |||
+ | Cette stratégie consiste simplement à réserver N cœurs au niveau de slurm (en vous rappelant que slurm les appelle des CPU), et à indiquer ce nombre à la MKL. Nous construisons simplement ci-après un job de type OpenMP : | ||
+ | |||
+ | < | ||
+ | #!/bin/bash | ||
+ | # | ||
+ | #SBATCH --ntasks=1 | ||
+ | #SBATCH --cpus-per-task=8 | ||
+ | #SBATCH --mem-per-cpu=300 | ||
+ | #SBATCH --time 00:01:00 | ||
+ | |||
+ | export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK | ||
+ | ./ | ||
+ | </ | ||
+ | ==== Passer en séquentiel ==== | ||
+ | Bien entendu, si vous rencontrez des problèmes de sur-allocation ou en cas de doute, vous pouvez aussi passer en mode séquentiel : | ||
+ | * en compilant votre code avec la version séquentielle : | ||
+ | * '' | ||
+ | * ou en choisissant le mode séquentiel dans le // | ||
+ | * ou avec la variable d' | ||
+ | * ou en limitant le nombre de thread à la valeur 1 via la variable '' |