12.2.3 : Langages de programmation et développement



  • No More Porting: Coding for GPUs with Standard C++, Fortran, and Python [S41496] (41min44s)
    • On peut faire du OpenACC ou du OpenMP en C++17
    • Cunumeric une autre surcouche GPU de Numpy
    • NVC++ : parallelisme et concurence the thread
    • C++23 : range based parallel algorithm (mdspan, mdarray)
    • On peut combiner les différents std::transform et std::reduce dans la même commande.
    • std::range avec g++10
    • NVFortran peut utiliser nvTENSOR
  • How to Develop Performance Portable Codes using the Latest Parallel Programming Standards [S41618](24min39s)
    • Sycl, Kokkos, OPenMP
    • Il peut y avoir des problèmes de taille de blocs avec nvc++ (mais ça a été corrigé)
    • Les performances sont comparables (pour miniBUDE, nvc++ est à $10\%$ des performances CUDA)
    • Ils espèrent que les autres vendeurs vons faire de même
  • Getting started with ARM software development: 86 the x86 dependencies in your code [S41702](22min43s)
    • ARM pour le HPC
    • Programmer explicitement en fonction intrinsèques en C et C++
    • Opérations atomiques
    • BWA-MEM2 : application spécifique pour x86 avec des intrinsèques dépendentes de x86
    • Privilégier les flags -march=native ou -march=host même si il faut un compilateur récent pour que cela fonctionne automatiquement
    • Utiliser l'équivalent de RDTSC pour ARM
    • Il y a même des problème avec time
    • Il y des truc compatible que pour les Unix, mais je me fou des autres
    • Les perfs x86 ne sont pas très convainquantes par rapport à ARM (encore un test fallacieux)
  • Connect with the Experts: Best Practices for Fortran on GPUs [CWE41554] (44min04s)
    • Sur MiniWeather ils obtiennent les même performances en Fortran standard + nvFortran qu'avec OpenACC
    • Sur une simulation en Chimie quantique ils sont plus rapide en Fortran standard
    • Brent Leback : Responsable des intrinsèques Fortran, de Cuda Fortran et des API Cuda
    • Pallavi Mathew : Responssable OpenMP OpenACC pour GPU
    • Guray Ozen : OpenACC et Do Concurent pour GPU
    • Jeff Larkin : OpenMP, OpenACC specifications
    • Jeff Hamond : Application Use case, OpenPMI et Co-Array
    • La réduction en Do Concurent n'est pas encore disponible mais elle sera ajouté
    • Fortran, Cuda Fortran, OpenMP et OpenACC peuvent être utilisées ensembles car elles sont complémentaires
    • Cuda Fortran n'est pas portable
    • La parallélisation GPU en Fortran standard est poentiellement la plus portable mais pour le moment il n'y a que NVidia qui a un compilateur qui peut le faire. Même si Intel et Cray travaillent dessus
    • Il faut toujours démarer sans directive et en ajouter si besoin
    • Les fonctionnalités les plus utilisées sont implémentées en premier dans les compilateurs
    • Il n'y a pas encore les Co array mais c'est en cours
    • Fortran sera toujours supporté par les compilateurs NVidia. Mais préférez le Fortran moderne (F18 ou plus) (faut quand même pas pousser)
    • Fortran n'a pas d'atomique pour Do Concurent mais on peut utiliser OpenMP, car dans le standard c'est pour les Co-Array
    • Il ne faut pas appeler une fonction dans un Do Concurent car le compilateur ne sait pas ce qu'elle fait, donc il ne sait pas comment la paralléliser
    • On peut spécifier si on veut tourner sur le GPU et/ou en multicoeurs à la compilation avec -stdpar=multicore ou -stdpar=gpu. Apparemment on peut aussi le faire à l'exécution, mais ils ne disent pas comment
    • Les tensor cores sont suportés en Fortran
  • How CUDA Programming Works [S41487](41min13s)
    • Ce n'est pas vraiment un cours sur CUDA, mais l'ensemble des trucs les plus importants à savoir quand on programme sur un GPU
    • Notion de SIMT : Single Instruction Multiple Thread (d'ailleurs ils ne parlent pas de warp)
    • Pas de nvc++, juste CUDA
  • Automated Performance Improvement Using CUDA Link Time Optimization [S41595] (21min22s)
    • Link Time Optimization (LTO)
    • Résoudre le problème de la compilation de plusieurs fichiers tout en ayant de bonnes performances
    • Il faut compiler avec -dlto à la compilation et au linkage avec nvcc (depuis Cuda 11.2)
    • Suivant les cas présentés, l'accélération va de $5\%$ à $91\%$ (simulation, mécanique des fluides, etc)
    • LTO peut être utilsé sur des applications industrielles
    • LTO JIT (Just In Time) existe depuis Cuda 11.4 (avec nvrtc, NVidia RunTime Compiler)
    • Attention, la compilation est plus lente (38K LOC sur 300 fichiers, le linkage prend de 1s à 49s avec LTO, mais la compilation est 18s plus rapide). Le tout augmente de $5\%$ (en fait ça va)
    • Attention : il n'y a pas de compatibilité sur les versions mineures de Cuda 11.X, mais ce sera le cas pour Cuda 12.0
    • LTO permet d'éliminer le code mort des kernels qui ne sont pas appelés par le host (ce n'était pas le cas avant)
  • Connect with the Experts: What's in Your CUDA Toolbox? CUDA Profiling, Optimization, and Debugging Tools [CWE41541] (48min30s)
  • Connect with the Experts: NVCC CUDA Compiler Toolchain: Language, Functionality, and Performance Tuning [CWE41902] (50min29s)
    • Experts front End, middle end et back end du compilateur nvcc
    • Meilleures optimisations et déduction du temps de compilation (autant que faire ce peut)
    • nvcc est en train de migrer sur LLVM 7
    • nvcc 11.7 fera du C++20 (avec des modules C++, mais pas d'appel Cuda dans ces modules)
    • Il y a des options pour optimiser le temps de compilation (compilation concurente, multithread -d -thread si on cible des devices (compute capabilities) différents)
    • Ils vont augmenter le nombre de choses que l'on peut compiler en parallèle
    • Il y a aussi un feedback pour dire au développeur quelles lignes de sont code prennent plus de temps à compiler
    • Les templates sont sensés fonctionner dans nvcc
    • LTO : Link Time Optimisation (déjà abordé dans une présentation juste au dessus)
    • À vérifier, mais apparemment il ne faut pas mélanger du C avec du C++ quand on compile avec nvc++, mais c'est louche
    • -d -v pour avoir le détail de l'implémentation faite par le compilateur (pour $a+b$ par exemple)
    • Il y a l'autodétection du GPU que l'on veut cibler (comme dans nvc++)
    • Les entiers 128 bits sont supportés depuis la version 11.6
    • Il y a besoin de plus d'information sur les GPU récents, donc les micro-instructions ont grandis
    • Ils ont un expert CMake pour gérer la compatibilité avec les versions récentes de CMake