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:35] montap01 [Nombre de threads] |
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 10: | Ligne 10: | ||
* le **bon usage sous l' | * le **bon usage sous l' | ||
+ | ==== Limites ==== | ||
+ | Nous ne traiterons pas spécifiquement dans cet article les interactions avec un programme utilisant MPI. | ||
+ | |||
+ | Dans ce cas, vous devez comprendre le contenu de cette page, et introduire en plus le fait que MPI génère des processus distincts. Suivant la façon dont vous ferez votre demande de réservation sous slurm, ces processus seront répartis sur des nœuds différents ou pourront être localisés sur le même nœud. | ||
===== Fonctions threadées ===== | ===== Fonctions threadées ===== | ||
* Toute les fonctions de la MKL ne se prêtent pas à du // | * Toute les fonctions de la MKL ne se prêtent pas à du // | ||
Ligne 21: | Ligne 25: | ||
* La liste exhaustive des méthodes est donnée dans le User's Guide, section [[https:// | * La liste exhaustive des méthodes est donnée dans le User's Guide, section [[https:// | ||
- | ===== Utilisation avec un programme threadé ===== | + | ===== Avec un programme threadé ===== |
==== Thread-safe ==== | ==== Thread-safe ==== | ||
Nous rappelons que la MKL est // | Nous rappelons que la MKL est // | ||
Ligne 46: | Ligne 50: | ||
Il est donc très important de prendre cela en compte quand vous lancerez un job sous slurm : il faudra dans ce cas **réserver un nœud complet pour votre job**, sinon le nœud sera en sur-allocation. | Il est donc très important de prendre cela en compte quand vous lancerez un job sous slurm : il faudra dans ce cas **réserver un nœud complet pour votre job**, sinon le nœud sera en sur-allocation. | ||
+ | |||
+ | ==== Dans une zone threadée ==== | ||
+ | Si l' | ||
+ | |||
+ | Autrement dit, elle se comportera en mode séquentiel. | ||
+ | |||
+ | ==== Fixer le nombre de threads ==== | ||
+ | |||
+ | Plusieurs techniques sont possibles pour fixer explicitement le nombre de threads : | ||
+ | * via des appels à des fonctions OpenMP ou MKL dans le code | ||
+ | * via des variables d' | ||
+ | |||
+ | Le plus simple consiste à utiliser une des deux variables suivantes : | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | ===== 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 '' |