12.3.4 : Developpement HPC
- No More Porting: GPU Computing with Standard C++ and Fortran [S51043]
- Slides
- C++ / FOrtran : on peut développer d'emblé des applications parallèles, et pas des applications scalaires que l'on parallélise
- NVidia HPC SDK
- Ce n'est pas vrai, il n'y a pas 4 compilateurs dans le HPC SDK, il y en a 35
- Les algos C++ (de C++17 et 20) sont synchrones
- Preview Senders / Recievers sur HPC SDK 22.11
- Le code devient indépendent du hardware : et il peut tourner sur plusieurs GPUs sans changer le code
- Privilégier le transform_reduce plutôt qu'un transform et un reduce pour réduire les communications sur le GPU
- Jamais d'allocation statique, sinon ça foire
- Pour les lambdas : capture by value
- Pas d'exception sur le GPU
- Fortran 2020 : Do Concurent
- Maintenant on peut appeler des fonctions dans un do concurent, mais il faut qu'elles soient pures, et il faut l'expliciter lors de leur définition.
- Wednesday, Mar 22-10:00 PM - 10:25 PM CET Best Practices for Programming GPUs using Fortran, OpenACC, and CUDA [S51857]
- Slides
- Code porting and optimization specialist
- Use NVTX marker to understand your code (available in nvfortran since nvhpc_sdk 21.09)
- Compilation nvfortran driver.f90 -lnvhpcwrapnvtx
- Select Pin memory (about 2x compare to classical allocation)
- Pageable -> pinned -> device
- pinned -> device (one step less)
- Mais l'allocation de la pinned memory est très lente (donc il faut limiter les allocations dans le temps).
- En fortran on utilise pinned dans les attributs de la variable que l'on déclare
- Il est préférable de déclarer la mémoire pinned uniquement au linkage
nvfortran -c -o driver.o Driver.f90 -acc -cuda nvfortran -o a.out driver.o -acc -cuda -gpu:pinned
- Pas de assume shape dans un tableau qui sera utilisé sur le GPU
- Utiliser assumed size et pas assumed shape (~2x speed up)
- Explore With Nsight Systems: nsys profile -o cuda_dummy_vars -t cuda,nvtx,mpi,openacc –cuda ./a.out
- Avoid Fortran derived data types inside GPU code
- Wednesday, Mar 22-9:00 PM - 9:50 PM CET Accelerating Data Movement Between GPUs and Storage or Memory [S51142]
- Slides
- Le son est pourri
- GPU Direct Storage (1.9x to 4.5x speed up)
- GPU Initiated Storage
- MagnumIO
- Ils gèrent le HDF5
- Storage Security
- Tuesday, Mar 21-9:00 PM - 9:50 PM CET Recent Developments in NVIDIA Math Libraries [S51176]
- Slides
- Support de E4M3 et E5M2 (float8) dans CUDA 12.0
- Ajout des DPX (Dynamic Programing Instruction
- cuSparse : Optimisation de la mémoire, samples dense dense matrix
- Block sparse compressed row
- remove legacty implementation which does not suport transposition
- Reduce memory requirements
- Gestion des GEMM mais où l'on ne s'interesse qu'a certain élément (comme en machine learning)
- nvJpeg : jpeg lossless, decoding 1.6x from A100 to H100
- nvPNG arrivera courant 2023
- cuBLASlt : mix precision, pour le moment l'accumulation ne se fait qu'en FP32
- cuBLAS : heuristic results cache, mix FP32, FP64
- cuSOLVERMp : Distributed symetrix eigenvalue solver, 1.35x faster than ELPA1 on 1024
- future : cuFFTMp : Multi-dimentional FFT
- Wednesday, Mar 22-4:00 PM - 4:50 PM CET Asynchronous Acceleration in Standard C++ [S51755]
- Slides
- Bryce Lelbach : Principal Architect NVidia
- https://gitlab.in2p3.fr/CodeursIntensifs/Reprises/-/wikis/uploads//GTC2023/S51755-Asynchronous-Acceleration-in-Standard-C++_1679464320596001FJ4D.pdf
- La plupars des utiliseteurs ne développent pas des programmes qui peuvent facilement être parallélisés
- C++26 : Linear algebra et SIMD types
- about 100 standard Algorithms
- Les calculs ne sont fait (ou les fonctions appelées que quand les éléments du dernier calcul sont appelées
- Senders pour avoir de l'asynchronisme
- La blague du thread pool est géniale
- Schedulers -> Sender -> Reciever
- Cancelation is not an error
- when_all = join
- Les mdspan permettent de faire le lien entre plein de classes de données à plusieurs dimension (Eigen, Armadillo, etc)
- On passe d'une implémentation monothread CPU à un programme qui tourne sur plein de noeuds sur CPU et GPU en changeant une ligne.
- disponible sur https://github.com/nvidia/stdexec
- On fait de la théorie des graphes en C++26
- En C++23 l'opérateur [] peut prendre plusieurs paramètres
- layout_right = row wise (C style)
- layout_left = column wise (Fortran style)
- C'est puissant, mais les noms sont completement piégeux.
- Utilisable en C++23 et C++26 dans nvc++ 22.7
- Le parallelisme doit devenir le standard.
- Wednesday, Mar 22-10:00 PM - 10:50 PM CET Developing Optimal CUDA Kernels on Hopper Tensor Cores [S51413]
- Slides
- CUTLASS : Cuda C++ template library https://github.com/NVIDIA/cutlass
- Les FP26 et FP64 vont arrivés au Q3 2023
- H100 :
- 16b Floating-point Tensor Core operations 16x and 32x faster than F32 CUDA Cores
- 8b Floating-point Tensor Core operations 32x and 64x faster than F32 CUDA Cores
- Improved Integer Tensor Core operations 32x and 64x faster than F32 CUDA Cores
- Improved Tensor Float 32 Tensor Cores 8x and 16x faster than F32 CUDA Cores
- Improved IEEE double-precision Tensor Cores 2x faster than F64 CUDA Cores
- CuTe is for Cuda Tensors, indexing, c'est le Kiwaku de NVidia
- On peut faire des blocs de blocs pour reshape des tensors que l'on ne pourait pas gérer autrement
- Il y a une extention python et on peut l'intégrer à PyTorch
- Thursday, Mar 23-3:00 PM - 3:50 PM CET Advances in NVSHMEM [S51705]
- Slides
- NVSHMEM : GPU Initialised Communication
- Can be used with MPI (or without)
- nvshmem_malloc : collective operation called on all GPU at the same time
- 4th Gen NVLink (32 DGX H100) : 57.6 TB/s Bandwidth
- Synchronisation is not free
- Infiniband GPUDirect Async (IBGDA) Transport
- NVSHMEM passe sur CMake et déprécie les makefiles
- On peut connecter les GPU avec du NVLink ou avec de l'Infiniband