formation:insa2020gpu

Différences

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

--- formation:insa2020gpu [2020/11/30 17:42]
equemene créée
+++ formation:insa2020gpu [2020/12/07 04:54]
equemene [Exploitations de xGEMM]
@@ Ligne 31: / Ligne 31: @@
 De manière à proposer un environnement pleinement fonctionnel, le Centre Blaise Pascal fournit le matériel, les logiciels et un OS correctement intégré. Les personnes qui veulent réaliser cette session sur leur laptop doivent disposer d'un "vrai" système d'exploitation de type Unix, équipé de tout l'environnement adéquat.
-Le contexte sanitaire de cette année 2020 impose d'entreprendre ces travaux pratiques de manière distancielle. Pour se trouver dans de les plus proches de celle de la salle de formation, quelques prérequis sont nécessaires.
+Le contexte sanitaire de cette année 2020 impose d'entreprendre ces travaux pratiques de manière distancielle. Pour se trouver dans des conditions les plus proches de celles de la salle de formation, quelques prérequis sont nécessaires.
 === Prérequis pour le matériel ===
   * Si vous n'utilisez PAS le CBP, une machine relativement récente avec un GPU intégré avec circuit Nvidia
-  * Si vous utilisez le CBP, un laptop disposant d'un écran assez confortable pour afficher une fenêtre de 1024x768
+  * Si vous utilisez le CBP, un laptop disposant d'un écran assez confortable pour afficher une fenêtre de 1024x768, une connexion réseau la plus stable possible et la capacité d'y installer un logiciel adapté.
 === Prérequis pour le logiciel ===
-  * Si
+  * Si vous n'utilisez pas le CBP, un OS GNU/Linux correctement configuré pour le GPU embarqué avec tous les composants Nvidia, OpenCL, PyOpenCL, PyCUDA. A cela s'ajoute un navigateur pour voir cette page ainsi qu'un traitement de texte pour rédiger le compte-rendu de ces séances.
-  * Une session graphique sur une station de travail, plusieurs terminaux et votre navigateur favori
+  * Si vous utilisez le CBP, il faut avoir installé le logiciel [[https://wiki.x2go.org/doku.php/download:start|x2goclient]] suivant les recommandations de la [[ressources:x2go4cbp|documentation du CBP]]. Il est recommandé d'exploiter le traitement de texte et le navigateur dans la session distante.
-  * Si vous n'utilisez pas le CBP, un OS GNU/Linux correctement configuré pour le GPU embarqué avec tous les composants Nvidia, OpenCL, PyOpenCL, PyCUDA.
-  * Si vous utilisez le CBP, il faut avoir installé le logiciel [[https://wiki.x2go.org/doku.php/download:start|x2goclient]] suivant les recommandations de la [[ressources:x2go4cbp|documentation du CBP]].
-Pour choisir "judicieusement" une machine parmi la (presque) centaine de machines à disposition, consultez la page [[https://www.cbp.ens-lyon.fr/python/forms/CloudCBP|Cloud@CBP]].
+Pour choisir "judicieusement" une machine parmi la (presque) centaine de machines à disposition, consultez la page [[https://www.cbp.ens-lyon.fr/python/forms/CloudCBP|Cloud@CBP]]. Il est recommandé de prendre une machine disposant d'un GPU de type "Gamer" ou d'un "GPGPU". Les sélecteurs de la page précédente peuvent vous aider dans ce choix. Coordonnez vous entre vous pour être si possible chacun sur la vôtre.
 === Prérequis pour l'humain ===
@@ Ligne 330: / Ligne 328: @@
 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 ====
@@ Ligne 360: / Ligne 375: @@
   * ''Pi'' : implémentation multiples d'un [[https://fr.wikipedia.org/wiki/M%C3%A9thode_de_Monte-Carlo|Pi Monte Carlo]]
   * ''Splutter'' : un modèle de ''postillonneur mémoire'', très utile pour évaluer les //fonctions atomiques//
+  * ''TrouNoir'' : un exemple de portage de code de 1994, porté en C en 1997 puis en Python/OpenCL et Python/CUDA en 2019
 De tous ces programmes, seuls ceux présents dans ''BLAS'', ''NBody'' et ''Pi'' seront exploités dans le cadre de ces travaux pratiques.
@@ Ligne 387: / Ligne 403: @@
 Nous avons alors 12 exécutables de la forme ''xGEMM_SP_<version>'' ou ''xGEMM_DP_<version>'' :
-  * ''fblas'' utilisant la librairie ATLAS, pour CPU
   * ''openblas'' utilisant la librairie OpenBLAS, pour CPU
   * ''gsl'' utilisant la librairie GSL (pour //GNU Scientific Librairies//)
+  * ''fblas'' utilisant la librairie OpenBLAS mais pour des appels fortran, pour CPU
   * ''cublas'' utilisant la librairie cuBLAS avec une gestion externe de la mémoire
   * ''thunking'' utilisant la librairie cuBLAS avec une gestion interne de la mémoire
@@ Ligne 727: / Ligne 743: @@
 </note>
-Le code se compile très simplement uniquement en appliquant la commande ''gcc -o PiOpenCL PiOpenCL.c -lOpenCL''. L'exécutable ''PiOpenCL'' est prêt à être utilisé.
+Le code se compile très simplement uniquement en appliquant la commande ''gcc -o PiOpenCL PiOpenCL.c -lOpenCL -lm''. L'exécutable ''PiOpenCL'' est prêt à être utilisé.
 Son exécution sans paramètre ne fait qu'une "découverte" des périphériques OpenCL disponibles et présente la documentation. Par exemple :<code>
@@ Ligne 913: / Ligne 929: @@
 Dans l'exemple précédent, nous avons exploité un programme en C "pur". Nous avons vu comment s'intégrait la portion de code (le noyau ou le //kernel//) qui était exécutée, soit par les GPU, soit par différentes implémentations pour CPU de OpenCL. Nous avons aussi pu "juger" du côté assez "compliqué" de découvertes des périphériques et des mécanismes d'entrée/sortie.
-Avec le programme ''PiXPU.py'', nous allons pouvoir exploiter les périphériques de calcul plus simplement, et bénéficier de toutes les facilités d'un langage évolué.
+Avec le programme ''PiXPU.py'', situé dans le dossier ''bench4gpu/Pi/XPU'' nous allons pouvoir exploiter les périphériques de calcul plus simplement, et bénéficier de toutes les facilités d'un langage évolué.
 Regardons d'abord sa sortie lorsqu'il est sollicité avec l'option ''-h'' :<code>
-$ python PiXPU.py -h
+$ cd $HOME/bench4gpu/Pi/XPU
+$ python3 PiXPU.py -h
 PiXPU.py -o (Out of Core Metrology) -c (Print Curves) -k (Case On IfThen) -d <DeviceId> -g <CUDA/OpenCL> -i <Iterations> -b <BlocksBegin> -e <BlocksEnd> -s <BlocksStep> -f <ThreadsFirst> -l <ThreadsLast> -t <ThreadssTep> -r <RedoToImproveStats> -m <SHR3/CONG/MWC/KISS> -v <INT32/INT64/FP32/FP64>
@@ Ligne 944: / Ligne 961: @@
 Il est aussi possible de coupler les deux régimes de parallélisme en appelant 16 //work items// avec 16 //threads//.
-Par exemple, pour explorer des régimes de parallélisme de 16 à 128 avec des pas de 16 en //Work items// et 4 à 8 en //Threads// avec des pas unitaires, nous aurons ''-b 16 -e 128 -s 16 -f 4 -l 8 -p 2''.
+Par exemple, pour explorer des régimes de parallélisme de 16 à 128 avec des pas de 16 en //Work items// et 4 à 8 en //Threads// avec des pas unitaires, nous aurons ''-b 16 -e 128 -s 16 -f 4 -l 8 -t 1 -p 2''.
 D'autres options :
@@ Ligne 958: / Ligne 975: @@
 En sortie, lors d'un appel simple ne précisant que le périphérique, ici le premier, ''#0'', nous avons : <code>
-$ python PiXPU.py -d 0
+$ python3 PiXPU.py -d 0
 Devices Identification : [0]
 GpuStyle used : OpenCL
@@ Ligne 1012: / Ligne 1029: @@
 === Exploitation du programme ===
-Ainsi, si nous voulons étudier la scalabilité du CPU en //Work items// de 1 à 16x le nombre de coeurs (ici 8 physiques) en exploitant l'implémentation AMD de OpenCL, nous appelons la commande : <code>python PiXPU.py -d 0 -b 1 -e $((8*16)) -r 10 -i 1000000000 </code>
+Ainsi, si nous voulons étudier la scalabilité du CPU en //Work items// de 1 à 16x le nombre de coeurs (ici 8 physiques) en exploitant l'implémentation AMD de OpenCL, nous appelons la commande : <code>python3 PiXPU.py -d 0 -b 1 -e $((8*16)) -r 10 -i 1000000000 </code>
 Dans notre cas, nous avons les deux fichiers suivants à exploiter :
@@ Ligne 1034: / Ligne 1051: @@
 <note warning>
 Exercice #19 : étude de la scalabilité d'une implémentation CPU
-  * Identifiez avec ''python PiXPU.py -h'' un périphérique CPU
+  * Identifiez avec ''python3 PiXPU.py -h'' un périphérique CPU
   * Exécutez le d'un PR=1 à un PR égal à 8x le nombre de coeurs physiques
   * Tracez les résultats avec GNUplot
@@ Ligne 1040: / Ligne 1057: @@
 Nous pouvons également "explorer" la scalabilité des GPU forts de notre expérience de ''PiOpenCL''. Par exemple, du nombre de //cuda cores// à ce nombre multiplié par 16, par pas de 128. La commande appelée est la suivante :<code>
-python PiXPU.py -d 2 -b 3584 -e $((3584*8)) -s 128 -r 3 -i 100000000000
+python3 PiXPU.py -d 2 -b 3584 -e $((3584*8)) -s 128 -r 3 -i 100000000000
 </code>
@@ Ligne 1050: / Ligne 1067: @@
 <note warning>
 Exercice #20 : étude de la scalabilité d'un GPU
-  * Identifiez avec ''python PiXPU.py -h'' un périphérique GPU
+  * Identifiez avec ''python3 PiXPU.py -h'' un périphérique GPU
   * Exécutez-le d'un PR=<NbCudaCores> à un PR égal à 8x<NbCudaCores> par pas de 128 en OpenCL
   * Tracez les résultats avec GNUplot
@@ Ligne 1056: / Ligne 1073: @@
 </note>
-Comme nous avons également la même implémentation en CUDA, lançons l'exploration avec CUDA pour le PR optimal, ici identifié à 4x le nombre de //cuda cores// :<code>python PiXPU.py -g CUDA -d 0 -b $((3584*4)) -e $((3584*4)) -r 3 -i 10000000000</code>
+Comme nous avons également la même implémentation en CUDA, lançons l'exploration avec CUDA pour le PR optimal, ici identifié à 4x le nombre de //cuda cores// :<code>python3 PiXPU.py -g CUDA -d 0 -b $((3584*4)) -e $((3584*4)) -r 3 -i 10000000000</code>
 Comme résultat de cette implémentation CUDA, nous n'obtenons pas **268 Gitops**, mais seulement **6 Gitops** !
-La seule manière de retrouver une performance comparable en CUDA est de solliciter le second étage de parallélisme des GPU, les //Threads//. Avec la commande suivante, avec 1024 Threads, nous plafonnons à **198 Gitops** :<code>python PiXPU.py -g CUDA -d 0 -b $((3584*4)) -e $((3584*4)) -f 1024 -l 1024 -r 3 -i 1000000000000</code>
+La seule manière de retrouver une performance comparable en CUDA est de solliciter le second étage de parallélisme des GPU, les //Threads//. Avec la commande suivante, avec 1024 Threads, nous plafonnons à **198 Gitops** :<code>python3 PiXPU.py -g CUDA -d 0 -b $((3584*4)) -e $((3584*4)) -f 1024 -l 1024 -r 3 -i 1000000000000</code>
-Et ce n'est pas tout ! La distribution Debian utilisée intègre par défaut un CUDA version 8. Pour l'intégration d'applications de //Deep Learning//, nous avons été obligé d'intégrer un CUDA version 9. Nous pouvons charger l'environnement pour exploiter cette version avec la commande :<code>module load cuda/9.0</code>
 En relançant le calcul précédent, nous parvenons à **271 Gitops** soit plus que l'implémentation OpenCL.
 <note warning>Exercice #21 : étude de l'implémentation CUDA autour du PR optimal
-  * Identifiez avec ''python PiXPU.py -h'' le périphérique GPU déjà utilisé en CUDA
+  * Identifiez avec ''python3 PiXPU.py -h'' le périphérique GPU déjà utilisé en CUDA
   * Exécutez le avec le PR optimal des //Blocks// en CUDA
   * Quel ratio de performance avez-vous entre CUDA et OpenCL ?
@@ Ligne 1077: / Ligne 1092: @@
 En lançant cette exploration suivante, nous obtenons :<code>
-python PiXPU.py -d 2 -b $((3584*4-16)) -e $((3584*4+16)) -r 3 -i 100000000000
+python3 PiXPU.py -d 2 -b $((3584*4-16)) -e $((3584*4+16)) -r 3 -i 100000000000
 </code>
@@ Ligne 1095: / Ligne 1110: @@
 Le code de test **Pi Monte Carlo** avait pour avantage de ne solliciter que très peu la mémoire. La seule mémoire sollicitée sur les périphériques se résumait au nombre de tirages dans le quadrant de cercle. De plus, l'opération de parallélisation divisait un nombre total d'itérations en un nombre équivalent pour chaque //work item//, chaque //block// ou chaque //thread//. Chaque calcul était indépendant des autres : nous avions non seulement un **code ALU** (ne sollicitant que les unités de traitement) mais aussi un **code gros grain** (indépendance des calculs).
-Dans le code ''NBody.py'', le principe est de déterminer dans un modèle newtonien la position et la vitesse de chaque particule en intéraction avec toutes les autres. A chaque itération, chaque position et chaque vitesse de chaque particule vont être modifiées par la proximité de toutes les autres : nous disposons d'un **code grain fin**. De plus, la détermination de la vitesse et la position de chaque particule à chaque instant nécessite un accès à la position de chacune des autres : un accès permanent à la mémoire est donc indispensable.
+Dans le code ''NBody.py'', situé dans ''bench4gpu/NBody'', le principe est de déterminer dans un modèle newtonien la position et la vitesse de chaque particule en intéraction avec toutes les autres. A chaque itération, chaque position et chaque vitesse de chaque particule vont être modifiées par la proximité de toutes les autres : nous disposons d'un **code grain fin**. De plus, la détermination de la vitesse et la position de chaque particule à chaque instant nécessite un accès à la position de chacune des autres : un accès permanent à la mémoire est donc indispensable.
 Le programme ''NBody.py'' n'est disponible qu'en OpenCL. Son invocation avec l'option ''-h'' offre la sortie suivante :
-<code>
+<code>$ cd $HOME/bench4gpu/NBody
-python NBody.py -h
+$ python3 NBody.py -h
 NBody.py -h [Help] -r [InitialRandom] -g [OpenGL] -e [VirielStress] -o [Verbose] -p [Potential] -x <None|NegExp|CorRad> -d <DeviceId> -n <NumberOfParticules> -i <Iterations> -z <SizeOfBoxOrBall> -v <Velocity> -s <Step> -b <Ball|Box> -m <ImplicitEuler|RungeKutta|ExplicitEuler|Heun> -t <FP32|FP64>
@@ Ligne 1131: / Ligne 1146: @@
 Par défaut, une invocation sans option offre la sortie suivante :<code>
- python NBody.py
+ python3 NBody.py
 Device choosed : 0
 Number of particules : 2
@@ Ligne 1187: / Ligne 1202: @@
 </code>
-Les éléments de sortie sont les statistiques de chaque itération, exprimées en **squertz**, contraction de **square** avec **Hertz**. En effet, le nombre de calculs élémentaires évolue suivant une loi en **N(N-1)** (chaque particule parmi **N** intéragit avec les **N-1** autres particules).
+Les éléments de sortie sont les statistiques de chaque itération, exprimées en **squertz**, contraction de **square** (pour "carré") avec **Hertz**. En effet, le nombre de calculs élémentaires évolue suivant une loi en **N(N-1)** (chaque particule parmi **N** intéragit avec les **N-1** autres particules).
 === Analyse du programme ===
@@ Ligne 1433: / Ligne 1448: @@
   * Comparez les résultats
     * Qu'apporte le GPU comme gain de performance par rapport au processeur ?
+</note>
+==== Intégration et exploitation du code GENESIS ====
+Le code [[https://www.r-ccs.riken.jp/labs/cbrt/|GENESIS]] de l'institut [[https://www.r-ccs.riken.jp/en/|RIKEN Center for Computational Science]] est un logiciel de [[https://fr.wikipedia.org/wiki/Dynamique_mol%C3%A9culaire|dynamique moléculaire]].
+Présenté comme exploitant massivement les GPU, il est disponible sur [[https://bitbucket.org/dpotter/pkdgrav3/|bitbucket]].
+C'est un programme //hybride// (exploitant 2 stratégies de parallélisation), et même //trhybride// dans la mesure où il exploite les GPU de type Nvidia avec CUDA, la distribution sur les coeurs via [[https://fr.wikipedia.org/wiki/OpenMP|OpenMP]] et la distribution sur des noeuds différents via [[https://fr.wikipedia.org/wiki/Message_Passing_Interface|passage de messages MPI]].
+Le code source est accessible à l'adresse : https://www.r-ccs.riken.jp/labs/cbrt/download/genesis-version-1-5/
+<note warning>Exercice #27 : Récupérez et compilez le code suivant la documentation fournie
+  * Lisez la [[https://www.r-ccs.riken.jp/labs/cbrt/installation/|documentation]] d'installation
+  * Placez les sources dans le dossier ''/local/$USER/GENESIS'' créé pour l'occasion
+  * Préparez une compilation pour GPU en simple précision dans le dossier ''/local/$USER/GENESIS/gpu-single''
+  * Compilez et installez le programme
+  * Purgez la compilation précédente
+  * Préparez une compilation pour CPU en simple précision dans le dossier ''/local/$USER/GENESIS/cpu-single''
+  * Compilez et installez le programme
+</note>
+L'exécution du programme est évaluée en comparant son exécution dans différentes configurations d'exploitation des CPU et des GPU.
+Pour cela, l'exemple de la base de [[https://www.r-ccs.riken.jp/labs/cbrt/?smd_process_download=1&download_id=14619|tests de régression]]. Le test  ''test_rpath_spdyn/alad_water'' a été modifié pour durer un peu plus longtemps à l'exécution.
+De plus, **GENESIS** étant //trhybride//, il est programmé pour se distribuer sur des machines indépendantes qui communiquent par //échanges de messages//. Le test  [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/alad_water.tgz|''alad_water'']] exige, par construction de la simulation, quatre exécutions concurrentes lesquelles vont communiquer par MPI. Il faudra donc préfixer l'exécutable de ''mpirun -np 4'' pour exécuter ces quatre tâches.
+De plus, ce programme est aussi parallélisé avec OpenMP : il va donc "aussi" exploiter les coeurs disponibles. Le souci, c'est que, par défaut, il va lancer pour chaque tâche MPI autant de sous-tâches OpenMP que de coeurs (même "virtuels") disponibles sur la machine. Ainsi, en exécutant l'exemple ''alad_water'' sur une machine disposant de 8 coeurs Hyperthreadés (donc disposant au total de 16 coeurs logiques), il va lancer 4*16 soit 64 tâches pour seulement 8 "vrais" coeurs : de quoi surcharger la machine.
+Pour finir, dans comme ce programme est "aussi" //gépufié// (porté sur GPU), il risque d'y avoir un goulet d'étranglement pour l'accès au GPU pour les 64 tâches simultanées. Ainsi, les programmes "fortement" parallélisés exigent de choisir judicieusement les différents paramètres de parallélisation tout comme nous avons vue que, pour les GPU, il fallait découper la tâche en un nombre optimal de sous-tâches.
+<note warning>Exercice #28 : Exécutez l'exemple ''alad_water''
+  * Récupérez [[http://www.cbp.ens-lyon.fr/emmanuel.quemener/documents/alad_water.tgz|l'exemple d'exécution]]
+  * Décompressez l'archive dans ''/local/$USER/GENESIS''
+  * Exécutez le programme sur l'exemple avec la version CPU
+    * ''/usr/bin/time mpirun -np 4 /local/$USER/GENESIS/cpu-single/bin/spdyn inp''
+  * Observez pendant l'exécution l'activité des coeurs
+  * Notez le ''Elapsed Time'' et le ''System Time''
+  * Effacez les résultats ''test*'' avec ''rm test*''
+  * Exécutez le programme sur l'exemple avec la version GPU
+    * Exécutez la commande ''/usr/bin/time mpirun -np 4 /local/$USER/GENESIS/gpu-single/bin/spdyn inp''
+  * Observez pendant l'exécution l'activité des coeurs et des GPU
+  * Notez le ''Elapsed Time'' et le ''System Time''
+  * Effacez les résultats ''test*'' avec ''rm test*''
+  * Déterminez, sachant que 4 tâches MPI simultanément, combien de //threads// lancer
+  * Définissez ce nombre pour le système avec la fonction suivante :
+    * ''export OPTIMAL_THREADS=<MonCHoixJudicieux>''
+  * Exécutez la commande ''/usr/bin/time mpirun -np 4 -x OMP_NUM_THREADS=$OPTIMAL_THREADS /local/$USER/GENESIS/cpu-single/bin/spdyn inp''
+  * Notez le ''Elapsed Time'' et le ''System Time''
+  * Effacez les résultats ''test*'' avec ''rm test*''
+  * Exécutez la commande ''/usr/bin/time mpirun -np 4 -x OMP_NUM_THREADS=$OPTIMAL_THREADS /local/$USER/GENESIS/gpu-single/bin/spdyn inp''
+  * Notez le ''Elapsed Time'' et le ''System Time''
+  * Concluez sur la pertinence de l'utilisation de l'option ''-x OMP_NUM_THREADS=$OPTIMAL_THREADS''
 </note>
@@ Ligne 1439: / Ligne 1504: @@
 Nous allons tenter de reproduire une [[https://www.nvidia.com/en-us/data-center/gpu-accelerated-applications/gromacs/|expérience de Nvidia]] vantant l'efficacité des GPGPU pour le logiciel de [[https://fr.wikipedia.org/wiki/Dynamique_mol%C3%A9culaire|dynamique moléculaire]] [[http://www.gromacs.org/|Gromacs]].
-<note warning>Exercice #27 : appliquez la "recette" de Nvidia
+<note warning>Exercice #29 : appliquez la "recette" de Nvidia
   * La documentation offre ceci :
     - récupérez le source
@@ Ligne 1452: / Ligne 1517: @@
 </note>
-En cas de difficultés, appliquez la [[formation:insa2018gpu:insa2018gromacs4stretch|recette de Gromacs pour Debian Stretch]] ;-)
+En cas de difficultés, appliquez la [[formation:insa2020gpu:insa2020gromacs4buster|recette de Gromacs pour Debian Buster]] ;-)
-<note warning>Exercice #28 : Exécutez l'exemple ''1536''
+<note warning>Exercice #30 : Exécutez l'exemple ''1536''
   * Quel ''Elapsed Time'' avez-vous pour l'exécution sur GPU (et CPU) ?
   * Quel ''Elapsed Time'' avez-vous pour l'exécution uniquement sur CPU ?
@@ Ligne 1460: / Ligne 1525: @@
 </note>
-==== Intégration et exploitation du code PKDGRAV3 ====
-Le code PKDGRAV3 est un logiciel de simulation hydrodynamique à la large couverture médiatique en juin 2017. Présenté comme exploitant massivement les GPU, il est disponible sur [[https://bitbucket.org/dpotter/pkdgrav3/|bitbucket]].
-Le code source est accessible par ''git'' à l'adresse : https://bitbucket.org/dpotter/pkdgrav3.git
-<note warning>Exercice #29 : Récupérez et compilez le code suivant la documentation fournie
-  * La documentation offre ceci :
-    - récupérez le source
-    - étendez l'archive
-    - créez un dossier pour la construction
-    - passez dans ce dossier
-    - préparez la compilation
-    - compilez le code
-  * A quelle étape est-ce que cela bloque ? Quel message avez-vous ?
-  * Nouvelle compilation :
-    - nettoyez le dossier de construction
-    - préparez la compilation en précisant un autre compilateur
-    - compilez le code
-</note>
-L'exécution du programme s'effectue en associant l'exécutable ''pkdgrav3'' au fichier de paramètres ''cosmology.par'' dans le dossiers ''examples''.
-<note warning>Exercice #30 : Exécutez l'exemple ''cosmology.par''
-  * Passez dans le dossier ''examples''
-  * Exécutez ''pkdgrav3'' sur ''cosmology.par''
-  * L'exécution se déroule-t-elle correctement ?
-</note>
-En cas de difficultés, appliquez la [[formation:cbp20190606gpu:pkdgrav4stretch|recette d'un PKDGRAV3 pour Debian Stretch]] ;-)
 ===== Conclusion =====
@@ Ligne 1497: / Ligne 1532: @@
 L'exploitation de "codes métier" vous aura aussi permis d'entrevoir la difficulté d'intégrer et d'exécuter des programmes dans des environnements pourtant bien homogènes : toutes les stations exploitées ont exactement le même système d'exploitation, [[developpement:productions:SIDUS|SIDUS]]. Les "astuces" permettant de simplement pouvoir exécuter les programmes illustraient aussi que, sans expérience, difficile de s'en sortir.
- --- //[[emmanuel.quemener@ens-lyon.fr|Emmanuel Quemener]] 2020/01/01 19:44//
+ --- //[[emmanuel.quemener@ens-lyon.fr|Emmanuel Quemener]] 2020/12/05 23:24//

formation/insa2020gpu.txt · Dernière modification: 2020/12/07 11:05 par equemene

Rechercher

Translations

Piste:

Boîte à outils