Outils pour utilisateurs

Outils du site


logiciels:mkl:mkl-et-parallelisme

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

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 18:07]
montap01 [Fixer le 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 //multi-threadé//.+Nous avons vu dans l'[[mkl |introduction à la MKL]] que cette librairie est **par défaut** en mode //multi-threadé//.
  
 L'objet de cet article est d'exposer dans les grandes lignes : L'objet de cet article est d'exposer dans les grandes lignes :
Ligne 67: Ligne 67:
  
 ===== Slurm ===== ===== 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.+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 ? ==== ==== Pourquoi y prêter attention ? ====
-Sur le cluster, nous lançons les jobs via //slurm//Les réservations demandées à slurm devront 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.+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'impactera alors que l'utilisateur qui a commis une erreur dans sa demande. Mais ce n'est pas la politique d'ordonnancement choisie sur CALI, car les codes exécutés par nos chercheurs ne s'y prêtent pas toujours, un certains nombre de programme étant purement séquentiels. 
 + 
 +==== 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 "mange" par défaut tous les cœurs d'une machine, la stratégie consistera ici à s'assurer que votre job disposera d'un nœud dans son intégralité. Ici encore, plusieurs solutions sont possibles, nous nous limiterons à vous proposer la plus "souple"
 + 
 +Ajouter dans votre fichier de job : 
 +<file> 
 +#SBATCH --exclusive 
 +</file> 
 + 
 + 
 +==== Réserver le "bon" nombre de cœurs ==== 
 + 
 +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 : 
 + 
 +<file> 
 +#!/bin/bash 
 +
 +#SBATCH --ntasks=1 
 +#SBATCH --cpus-per-task=8 
 +#SBATCH --mem-per-cpu=300 
 +#SBATCH --time 00:01:00
  
-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'impactera alors que l'utilisateur qui a commis une erreur dans sa demande. Mais ce n'est pas la politique d'ordonnancement choisie sur CALI, car le type de code exécutés par nos chercheurs ne s'y prête pas forcément, avec un certains nombre de programme purement séquentiels.+export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK 
 +./mon_programme 
 +</file> 
 +==== 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 :  
 +    * ''-mkl=sequential'' avec les compilateurs Intel 
 +    * ou en choisissant le mode séquentiel dans le //Advisor//  
 +    * ou avec la variable d'environnement ''MKL_THREADING_LAYER=SEQUENTIAL'' si vous utilisez la SDL (''-lmkl_rt''
 +  * ou en limitant le nombre de thread à la valeur 1 via la variable ''MKL_NUM_THREADS=1'' dans votre job
logiciels/mkl/mkl-et-parallelisme.1433347634.txt.gz · Dernière modification: 2015/06/03 18:07 de montap01