Différences
Ci-dessous, les différences entre deux révisions de la page.
| Prochaine révision | Révision précédente | ||
|
formation:insa2021gpu [2021/11/29 17:53] equemene créée |
formation:insa2021gpu [2022/01/03 14:05] (Version actuelle) equemene |
||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| ====== TP INSA 2021-2022 : le GPU par la pratique ====== | ====== TP INSA 2021-2022 : le GPU par la pratique ====== | ||
| - | Cette session pratique accompagne le [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/PresentationGPU_20211203_EQ.pdf|cours]] du 3 décembre au matin réalisé par Emmanuel Quémener. | + | Cette session pratique accompagne les cours des [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/INSA2021-CPU-211129.pdf|29 novembre]] et [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/INSA2021-GPU_211203.pdf|3 décembre]] au matin réalisé par Emmanuel Quémener. |
| ===== CQQCOQP : Comment ? Qui ? Quand ? Combien ? Où ? Quoi ? Pourquoi ? ===== | ===== CQQCOQP : Comment ? Qui ? Quand ? Combien ? Où ? Quoi ? Pourquoi ? ===== | ||
| Ligne 327: | Ligne 327: | ||
| En effet, la méthode par //shadering// exploitait de nombreuses multiplications matricielles pour générer une image numérique (CGI ou //Compute Generated Image//). Il n'est donc pas étonnant que les GPU soient, historiquement, plutôt "efficaces" pour ce type de tâches : nous allons l'évaluer. | En effet, la méthode par //shadering// exploitait de nombreuses multiplications matricielles pour générer une image numérique (CGI ou //Compute Generated Image//). Il n'est donc pas étonnant que les GPU soient, historiquement, plutôt "efficaces" pour ce type de tâches : nous allons l'évaluer. | ||
| - | ==== Chargement de l'environnement de programmation ==== | ||
| - | Le point traité dans l'exercice #2 a montré comment le système représentait les périphériques de type GPU dans le dossier ''/dev''. | ||
| - | |||
| - | De manière à exploiter ces GPU, d'autres composants sont nécessaires : les **librairies**. De plus, si un programme exploitant ces librairies doit être compilé, il est nécessaire de lui fournir les //prototypes// (d'extension ''.h''). | ||
| - | |||
| - | Ces librairies, prototypes voire programmes forment un //environnement de programmation// et plusieurs peuvent cohabiter sur un même système. | ||
| - | |||
| - | Par défaut, sur les machines du CBP, l'environnement **CUDA** est celui de la distribution, la **9.2**. Pour exploiter les GPU récents (RTX 3070, RTX 3090, A100), il est indispensable d'utiliser un CUDA récent, le **11.1** associé au driver **455** minimum. | ||
| - | |||
| - | Le gros souci de ces environnements, c'est que chaque application //métier// va exploiter une version de CUDA et pas un autre. Dans la majorité des cas, cela ne fonctionne pas : c'est, soit trop récent, soit trop ancien. | ||
| - | |||
| - | La définitin de l'environnement CUDA version 11.1 s'effectue avec le chargement du module ''cuda/11.1'' | ||
| - | <code> | ||
| - | . /usr/share/modules/init/bash | ||
| - | module load cuda/11.1 | ||
| - | </code> | ||
| ==== De BLAS aux xGEMM : les différentes implémentations ==== | ==== De BLAS aux xGEMM : les différentes implémentations ==== | ||
| Ligne 732: | Ligne 716: | ||
| ==== Implémentation C/OpenCL ==== | ==== Implémentation C/OpenCL ==== | ||
| - | Le programme ''bench4gpu/Pi/OpenCL/PiOpenCL.c'' est une implémentation en C "pur" : il permet de juger de la difficulté d'appropriation de OpenCL. En effet, une grande partie du code est destinée à définir quelle plateforme et quel périphérique utiliser, placer les données à traîter. | + | Le programme ''bench4gpu/Pi/C/OpenCL/PiOpenCL.c'' est une implémentation en C "pur" : il permet de juger de la difficulté d'appropriation de OpenCL. En effet, une grande partie du code est destinée à définir quelle plateforme et quel périphérique utiliser, placer les données à traîter. |
| <note warning> | <note warning> | ||
| Ligne 1299: | Ligne 1283: | ||
| Au CBP, un environnement Conda a été installé pour permettre l'exploitation de la majorité des outils construits autour de TensorFlow. Le chargement de l'environnement se réalise en "sourçant" l'environnement CONDA avec la commande suivante : | Au CBP, un environnement Conda a été installé pour permettre l'exploitation de la majorité des outils construits autour de TensorFlow. Le chargement de l'environnement se réalise en "sourçant" l'environnement CONDA avec la commande suivante : | ||
| - | <code>source /etc/tensorflow.init </code> | + | <code>module load conda3/4.9.2 </code> |
| - | La commande précédente "paramètre" les variables d'environnement nécessaires l'exploitation de l'environnement complet CONDA installé pour vous dans ''/opt/anaconda3/'' | + | La commande précédente "paramètre" les variables d'environnement nécessaires l'exploitation de l'environnement complet CONDA installé pour vous dans ''/opt/conda3-4.9.2/'' |
| L'objectif de la session est de lancer un apprentissage sur une base de 60000 mini-images [[https://www.cs.toronto.edu/~kriz/cifar.html|CIFAR-10]]. Là se pose une contrainte dont il faut **impérativement** prendre conscience quand ces outils de *-Learning sont exploités : les bases d'apprentissage, leur stockage et leur exploitation. Ces bases ont souvent des tailles de plusieurs GigaBytes à plusieurs dizaines de GB et le nombre de fichiers atteint facilement plusieurs centaines de milliers de fichiers. Leur téléchargement et leur exploitation non maîtrisés peuvent entraîner de graves dysfonctionnements sur des dossiers partagés. Pour cette raison, nous allons exécuté cet apprentissage sur un espace "local", c'est à dire stocké localement sur la machine. Par défaut, le profil utilisateur et ses données de base reposent sur un espace distant pour être retrouvé lors d'un changement de machine. Mais dans ce cas particulier d'exploitation, si 50 personnes chargent et exploitent simultanément de gros volumes de dizaines de milliers de fichiers simultanément, des problèmes apparaissent. Voici la procédure pour l'éviter dans notre cas : | L'objectif de la session est de lancer un apprentissage sur une base de 60000 mini-images [[https://www.cs.toronto.edu/~kriz/cifar.html|CIFAR-10]]. Là se pose une contrainte dont il faut **impérativement** prendre conscience quand ces outils de *-Learning sont exploités : les bases d'apprentissage, leur stockage et leur exploitation. Ces bases ont souvent des tailles de plusieurs GigaBytes à plusieurs dizaines de GB et le nombre de fichiers atteint facilement plusieurs centaines de milliers de fichiers. Leur téléchargement et leur exploitation non maîtrisés peuvent entraîner de graves dysfonctionnements sur des dossiers partagés. Pour cette raison, nous allons exécuté cet apprentissage sur un espace "local", c'est à dire stocké localement sur la machine. Par défaut, le profil utilisateur et ses données de base reposent sur un espace distant pour être retrouvé lors d'un changement de machine. Mais dans ce cas particulier d'exploitation, si 50 personnes chargent et exploitent simultanément de gros volumes de dizaines de milliers de fichiers simultanément, des problèmes apparaissent. Voici la procédure pour l'éviter dans notre cas : | ||