Hyper-Q / MPS/fr: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(Updating to match new version of source page)
No edit summary
 
(23 intermediate revisions by 2 users not shown)
Line 2: Line 2:




<div lang="en" dir="ltr" class="mw-content-ltr">
==Aperçu==
==Overview==
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Hyper-Q (ou MPS pour <i>Multi-Process Service</i>) est une fonctionnalité des GPU de NVIDIA qui sont compatibles avec les versions 3.5 et plus récentes de CUDA <ref>Voir le tableau des modèles, architectures et capacités de calcul CUDA dans [https://en.wikipedia.org/wiki/Nvidia_Tesla https://en.wikipedia.org/wiki/Nvidia_Tesla].</ref>
Hyper-Q (or MPS) is a feature of NVIDIA GPUs.
ce qui est le cas pour toutes nos grappes d'usage général (Béluga, Cedar, Graham et Narval).
It is available in GPUs with CUDA compute capability 3.5 and higher,<ref>For a table relating NVIDIA GPU model names, architecture names, and CUDA compute capabilties, see [https://en.wikipedia.org/wiki/Nvidia_Tesla https://en.wikipedia.org/wiki/Nvidia_Tesla]</ref>
which is all GPUs currently deployed on Alliance general-purpose clusters (Béluga, Cedar, Graham, and Narval).
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
[https://docs.nvidia.com/deploy/mps/index.html Selon la documentation de NVIDIA],
[https://docs.nvidia.com/deploy/mps/index.html According to NVIDIA],
::<i>[traduction libre]L'architecture d'exécution MPS est conçue pour permettre de façon transparente l'utilisation d'applications CUDA parallèles et coopératives (comme le sont typiquement les tâches MPI) en tirant avantage des fonctionnalités Hyper-Q des derniers GPU de NVIDIA (Kepler et suivants). Hyper-Q permet aux noyaux CUDA d’être traités en simultané sur un même GPU, ce qui améliore la performance quand la capacité de calcul du GPU est sous-utilisée par un seul processus.</i>
::<i>The MPS runtime architecture is designed to transparently enable co-operative multi-process CUDA applications, typically MPI jobs, to utilize Hyper-Q capabilities on the latest NVIDIA (Kepler and later) GPUs. Hyper-Q allows CUDA kernels to be processed concurrently on the same GPU; this can benefit performance when the GPU compute capacity is underutilized by a single application process.</i>
</div>




<div lang="en" dir="ltr" class="mw-content-ltr">
Nos tests ont démontré que MPS peut augmenter le nombre d'opérations en virgule flottante effectuées par seconde (flops) même quand le GPU est partagé entre des processus CPU qui ne sont pas reliés. Ceci signifie que MPS est la fonctionnalité idéale pour des applications CUDA qui traitent des problèmes dont leur taille relativement petite les rend incapables de bien occuper les GPU modernes dotés de milliers de cœurs.  
In our tests, MPS may increase the total GPU flop rate even when the GPU is being shared by unrelated CPU processes. That means that MPS is great for CUDA applications with relatively small problem sizes, which on their own cannot efficiently saturate modern GPUs with thousands of cores.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
MPS n'est pas activée par défaut, mais il suffit de lancer les commandes suivantes avant de démarrer votre application CUDA.
MPS is not enabled by default, but it is straightforward to do. Execute the following commands before running your CUDA application:
</div>


  <div lang="en" dir="ltr" class="mw-content-ltr">
  {{Commands|export CUDA_MPS_PIPE_DIRECTORY{{=}}/tmp/nvidia-mps
export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
|export CUDA_MPS_LOG_DIRECTORY{{=}}/tmp/nvidia-log
export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-log
|nvidia-cuda-mps-control -d}}
nvidia-cuda-mps-control -d
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Vous pouvez alors utiliser MPS si vous avez plus d'un fil CPU qui a accès au GPU. Ceci se produit quand vous exécutez une application hybride MPI/CUDA, une application hybride OpenMP/CUDA ou plusieurs applications séquentielles CUDA (<i>GPU farming</i>).
Then you can use the MPS feature if you have more than one CPU thread accessing the GPU. This will happen if you run a hybrid MPI/CUDA application, a hybrid OpenMP/CUDA application, or multiple instances of a serial CUDA application (<i>GPU farming</i>).
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Pour plus d'information sur MPS, voir [https://docs.nvidia.com/deploy/mps/index.html la documentation de NVIDIA].
Additional details on MPS can be found here: [https://docs.nvidia.com/deploy/mps/index.html CUDA Multi Process Service (MPS) - NVIDIA Documentation].
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
==<i>Farming</i> avec un GPU==
==GPU farming==
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
La fonctionnalité MPS est très utile pour exécuter plusieurs instances d’une même application CUDA quand celle-ci est trop petite pour occuper entièrement un GPU moderne. MPS vous permet d’exécuter toutes ces instances, pourvu que la mémoire du GPU soit suffisante. Dans plusieurs cas, la production de résultats pourrait être grandement augmentée.
One situation when the MPS feature can be very useful is when you need to run multiple instances of a CUDA application, but the application is too small to saturate a modern GPU. MPS allows you to run multiple instances of the application sharing a single GPU, as long as there is enough of GPU memory for all of the instances of the application. In many cases this should result in a significantly increased throughput from all of your GPU processes.
</div>


<div lang="en" dir="ltr" class="mw-content-ltr">
Le script suivant est un exemple pour configurer le farming avec un GPU.
Here is an example of a job script to set up GPU farming:
</div>


  <div lang="en" dir="ltr" class="mw-content-ltr">
  {{File|name=script.sh
|contents=
#!/bin/bash
#!/bin/bash
#SBATCH --gpus-per-node=v100:1
#SBATCH --gpus-per-node=v100:1
#SBATCH -t 0-10:00
#SBATCH --time=0-10:00
#SBATCH --mem=64G
#SBATCH --mem-per-cpu=8G
#SBATCH -c 8
#SBATCH --cpus-per-task=8
   
   
mkdir -p $HOME/tmp
mkdir -p $HOME/tmp
export CUDA_MPS_LOG_DIRECTORY=$HOME/tmp
export CUDA_MPS_LOG_DIRECTORY=$HOME/tmp
nvidia-cuda-mps-control -d
nvidia-cuda-mps-control -d
   
   
for ((i=0; i<8; i++))
for ((i=0; i<SLURM_CPUS_PER_TASK; i++))
  do
do
  echo $i
echo $i
  ./my_code $i  &
./my_code $i  &
  done
done
   
   
wait
wait
</div>
}}


<div lang="en" dir="ltr" class="mw-content-ltr">
Dans cet exemple, un GPU de type V100 est partagé par 8 instances de <code>my_code</code> qui n’a comme argument que l’indice de boucle <code>$i</code>. Comme nous demandons 8 cœurs CPU (#SBATCH --cpus-per-task=8), il y a un cœur CPU pour chacune des instances de l’application. Les deux éléments importants sont
In the above example, we share a single V100 GPU between 8 instances of <code>my_code</code> (which takes a single argument-- the loop index $i). We request 8 CPU cores (#SBATCH -c 8) so there is one CPU core per application instance. The two important elements are <code>&</code> on the code execution line, which sends the code processes to the background, and the <code>wait</code> command at the end of the script, which ensures that the job runs until all background processes end.
<code>&</code> sur la ligne d’exécution du code qui déplace les processus à l’arrière-plan et
</div>
* la commande <code>wait</code> à la fin du script qui fait en sorte que la ferme de GPU se poursuive jusqu’à ce que tous les processus en arrière-plan soient terminés.


<div lang="en" dir="ltr" class="mw-content-ltr">
[[Category:Software]]
[[Category:Software]]
</div>

Latest revision as of 20:00, 14 December 2023

Other languages:


Aperçu

Hyper-Q (ou MPS pour Multi-Process Service) est une fonctionnalité des GPU de NVIDIA qui sont compatibles avec les versions 3.5 et plus récentes de CUDA [1] ce qui est le cas pour toutes nos grappes d'usage général (Béluga, Cedar, Graham et Narval).

Selon la documentation de NVIDIA,

[traduction libre]L'architecture d'exécution MPS est conçue pour permettre de façon transparente l'utilisation d'applications CUDA parallèles et coopératives (comme le sont typiquement les tâches MPI) en tirant avantage des fonctionnalités Hyper-Q des derniers GPU de NVIDIA (Kepler et suivants). Hyper-Q permet aux noyaux CUDA d’être traités en simultané sur un même GPU, ce qui améliore la performance quand la capacité de calcul du GPU est sous-utilisée par un seul processus.


Nos tests ont démontré que MPS peut augmenter le nombre d'opérations en virgule flottante effectuées par seconde (flops) même quand le GPU est partagé entre des processus CPU qui ne sont pas reliés. Ceci signifie que MPS est la fonctionnalité idéale pour des applications CUDA qui traitent des problèmes dont leur taille relativement petite les rend incapables de bien occuper les GPU modernes dotés de milliers de cœurs.

MPS n'est pas activée par défaut, mais il suffit de lancer les commandes suivantes avant de démarrer votre application CUDA.

[name@server ~]$ export CUDA_MPS_PIPE_DIRECTORY=/tmp/nvidia-mps
[name@server ~]$ export CUDA_MPS_LOG_DIRECTORY=/tmp/nvidia-log
[name@server ~]$ nvidia-cuda-mps-control -d


Vous pouvez alors utiliser MPS si vous avez plus d'un fil CPU qui a accès au GPU. Ceci se produit quand vous exécutez une application hybride MPI/CUDA, une application hybride OpenMP/CUDA ou plusieurs applications séquentielles CUDA (GPU farming).

Pour plus d'information sur MPS, voir la documentation de NVIDIA.

Farming avec un GPU

La fonctionnalité MPS est très utile pour exécuter plusieurs instances d’une même application CUDA quand celle-ci est trop petite pour occuper entièrement un GPU moderne. MPS vous permet d’exécuter toutes ces instances, pourvu que la mémoire du GPU soit suffisante. Dans plusieurs cas, la production de résultats pourrait être grandement augmentée.

Le script suivant est un exemple pour configurer le farming avec un GPU.


File : script.sh

#!/bin/bash
#SBATCH --gpus-per-node=v100:1
#SBATCH --time=0-10:00
#SBATCH --mem-per-cpu=8G
#SBATCH --cpus-per-task=8
 
mkdir -p $HOME/tmp
export CUDA_MPS_LOG_DIRECTORY=$HOME/tmp
nvidia-cuda-mps-control -d
 
for ((i=0; i<SLURM_CPUS_PER_TASK; i++))
 do
 echo $i
 ./my_code $i  &
 done
 
wait


Dans cet exemple, un GPU de type V100 est partagé par 8 instances de my_code qui n’a comme argument que l’indice de boucle $i. Comme nous demandons 8 cœurs CPU (#SBATCH --cpus-per-task=8), il y a un cœur CPU pour chacune des instances de l’application. Les deux éléments importants sont

  • & sur la ligne d’exécution du code qui déplace les processus à l’arrière-plan et
  • la commande wait à la fin du script qui fait en sorte que la ferme de GPU se poursuive jusqu’à ce que tous les processus en arrière-plan soient terminés.
  1. Voir le tableau des modèles, architectures et capacités de calcul CUDA dans https://en.wikipedia.org/wiki/Nvidia_Tesla.