12.3.3 : HPC
Tuesday, Mar 21-6:00 PM - 6:50 PM CET : Unleashing the Potential of Accelerated Computing for Scientific Computing [S52137]
C'est un truc de commerciaux
Tuesday, Mar 21-9:00 PM - 9:50 PM CET Defining the Quantum-Accelerated Supercomputer [S51075]
Slides
Quantum computing : new model of computing
Useful, Fault-Tolerant Qubit Scale Could Be Achieved in 15 to 20 Years
Hybrid Quantum-Classical computing
cuQuantum : multi node, multi GPU qbit simutator (déjà présenté l'année dernière)
32 Qbit problème sur une A100, que l'on peut scaler sur plusieurs.
Selene : 1688 qbit à une precision 97%, 5000 qbit à precision 93%
Cuda QUantum Plateform : plateforme hybride classique (GPU) et quantum computing (simulé par cuQuantum pour le moment)
nvq++ pour compiler
Thursday, Mar 23-3:00 PM - 3:50 PM CET Advances in Data-Parallel Production Rendering at Scale [S52062]
Tout est dans le titre et la présentation est vraiment très grosse.
Thursday, Mar 23-4:00 PM - 4:50 PM CET Modeling and Simulation Meet AI: AI for Science and Art [S51071]
Tout est dans le titre et il n'y a pas de slides
Monday, Mar 20-5:00 PM - 5:50 PM CET How to Write a CUDA Program [S51210]
Slides
15 years of CUDA
Talk about not writing code
CUDA 12
GPU : throughput architecture
cudaMallocHost : transfert 5x compare to malloc from CPU to GPU
Nsight : Development tool for Cuda
Profiler Nsigh Compute
5 cy to compute
5000 to read in memory
Tuesday, Mar 21-8:00 PM - 8:50 PM CET A Deep Dive into the Latest HPC Software [S51074]
Slides
Linear algebra for Future C++
C++ standard plus de portabilité
Senders : Electromagnetic Maxwell equation solver
MultiGPU with C++, multinode
Suite d'exemples qui utilisent le C++ standard sur GPU
Cunumeric pour Python remplace numpy as np (60 percent de l'APIn numpy)
Legate remplace aussi numpy as np => scalalibilité sur multiGPU
cuSparse en CUDA 12 : consomme moins de mémoire
cuSolver : plus rapide
cuBLAS : les tensors cores sont mieux utilisés.
Scalable solver pour multi GPU et noeud et GPU
cuFFTMp : scalable sur plusieurs GPU et noeud
Grace Hopper Supership (avec 72 coeurs)
Pas de mémoire séparer pour CPU et GPU, c'est la même
Low Power DDR5 : LPDDR5 : consomme moins
Intégré au HPC SDK
Wednesday, Mar 22-5:00 AM - 5:50 AM CET How to Design an AI Supercomputer for Fast Distributed Training, and its Use Cases [S51112]
Slides
NEC : Techno, securité, biométrie, Identification, Satelitte, reconnaissance du travail d'un groupe de personnes
L'entrainement est très long,
Super Computer, architecture et OS :
928 A100 => 580 PFlops
200 BgE network, SN3700
DDN's large sorage : 16 PB, ES400NVX
4600x sur l'entrainement
Basé sur Kunernetes
MPI pour les communications entre les processus
Choix des A100 2TB/s Bandwidth pour le TF32
16 servers de 128 A100
Traning is memory band
DDN Storage cluster basé sur LUSTRE, 3 Réseau pour les communications
GPU DIrect RDMA : partage de la mémoire DRAM des GPU (la communication est proche de la limite des 200GbE
Lecture des données asynchrone Par PyTorch et Tensorflow
Switch OS : Cumulus Linux
MDS : process metadata
MSS : manage data
Pas de Bottlenecks avec Lustre, même avec une architecture en arbre pour gérer les accès
Redondance pour éviter les problèmes
Pytorch, Tensorflow, Jax, etc
Prometheus pour les métriques
Grafana pour afficher le tout
Logging system avec Elasticsearch et Kibana
Choix de Kubernetes / Prometheus pour leur scalabilité
Thursday, Mar 23-2:00 PM - 2:50 PM CET Accelerating HPC applications with ISO C++ on Grace Hopper [S51054]
Slides
Plus besoin de gérer la mémoire
Exemple d'utilisation de C++23 pour paralléliser le calcul sur CPU et GPU.
C'est très bien fait, regardez le.
Thursday, Mar 23-4:00 PM - 4:50 PM CET Building HPC Clouds with Accelerated Ethernet Networks [S51343]
Tuesday, Mar 21-12:00 PM - 12:25 PM CET Reducing the Environmental Impact of HPC using Dynamic Frequency Scaling [S51444]
Slides
Jack White
Radio astronomy / Pulsar Astronomy
SKA-Low => 5 ZB/yr => doit être analysé en temps réel car impossible à stocker
Data Centres and transmission network => 1% de la consommation d'énergie mondiale
En vrai, ça fait 10 ans qu'on parle de la fin de la loi de Moore, donc il y a bien un moment ou ça va être juste
Calcul de FFT sur GPU
Relation entre la consommation d'un GPU et la fréquence de son horloge
NVML permet de changer le fréquence d'un GPU
Si on n'a pas assez de données/calcul puor saturer le GPU, on peut réduire sa fréquence sans dégrader les performances
Si l'application n'est pas scalable, ça ne fait pas de miracle
0.9 GHz au lieu de 1.6 Ghz économise 26% d'éclectricité
La précision mixte économise 46% d'éclectricité
Thursday, Mar 23-3:00 PM - 3:50 PM CET A Demonstration of AI and HPC Applications for NVIDIA Grace CPU [S51880]
Slides
Montrer que porter une application sur ARM est simple
Grace : power efficient
Grace CPU SUpership : 960 GB
Toujours le HPC SDK (qui tourne sur ARM, comme Grace et AWS Graviton)
La version ARM du HPC SDK n'est pas encore finalisée, mais c'est pour bientôt
Pas beoins de compilateur propriétaire pour utiliser le HPC SDK, GCC ou CLang suffisent
NVidia NGC : Catalogue d'image docker pour faire du calcul GPU
Télécharge et lance Tensorflow en une commande avec Docker
Pour compiler avec nvhpc sur ARM il faut changer quelques flags :
-march=native devient -fast ou -mcpu=native
-ftree-vectorize devient -fast
La compialtion de OpenFoam sur 80 coeurs prend environ 1h40
BWA-MEM2 : 797 lines of intrinsics
Supprimer l'include emmintrin.h
Supprimer les appels à rdtcs , le remplacer par std::chrono si vraiment on en a besoin
Utliser SIMD Everywhere pour convertir les intrinsics x86 en intrinsics AARCH64 en incluant simde/x86/avx.h
Pas de Hyperthreading sur ARM, à désactiver
Et le binaire est un peu plus rapide sur ARM
En tout cas c'est bien plus utile que la présentation de l'année dernière
Wednesday, Mar 22-3:00 PM - 5:00 PM CET Portable Acceleration of HPC Applications using ISO C++ — Part 1: Fundamentals* [DLIT51169]
Pas de vidéo et pas de slides
Thursday, Mar 23-5:00 PM - 7:00 PM CET Portable Acceleration of HPC Applications using ISO C++ — Part 2: Multi-GPU Applications* [DLIT51170]
Pas de vidéo et pas de slides
Thursday, Mar 23-7:00 PM - 7:50 PM CET Tuning Machine Learning and HPC Workloads Performance in Virtualized Environments using GPUs [S51670]
Slides
MIG et une VM par Instance
Apparemment ils arrivent à 6% des perfs du Bare Metal
Sur un cas FInancer ils ont de meilleures performances que le bare metal
Globalement, il n'y a pas de démonstration et d'explication de pourquoi les VM auraient de meilleures performance que le bare metal et aucune remive en cause des applications testées.
Wednesday, Mar 22-10:00 AM - 10:50 AM CET Destination Earth and Digital Twins: A European Opportunity For HPC [S51708]
Archive
Destination Earth : DestinE
Phase 1 : 2021 2024 : 150 M€
Weather extreme and climate change adaptation
Started in 2008, Extreme Earth in 2018, DestinE end of 2021
Extreme Earth : mode fluid aspect of the Earch (Atmosphere, Ocean, Volcanos) needed breakthrough in term of capabilities
L'utilisateur peut demander différent niveaux d'information
For now Bandwidth is a problem
The first exasclae machine will be in Germany
Mémoire qui augmente automatiquement (simulation des océans)
Machine Learning to interpolate results
As open as possible but secure
Wednesday, Mar 22-11:00 AM - 11:25 AM CET Earthquake Simulations on Heterogeneous Systems with SeisSol [S51167]
Wednesday, Mar 22-2:00 PM - 3:30 PM CET Boosting Apps with RDMA [DLIT52053]
Thursday, Mar 23-5:00 PM - 5:25 PM CET High-Performance and Scalable Data Science using MPI4Dask [S51892]
https://gitlab.in2p3.fr/CodeursIntensifs/Reprises/-/wikis/uploads//GTC2023/S51892-High-Performance-and-Scalable-Data-Science-using-MPI4Dask_1679377846749001dtLC.pdf
Utilisation de MVAPICH-2, MVAPICH-2-X (version avancée de MVAPICH-2)
MPI4DASK + RAPIDS + MVAPICH2 pour faire du Multi Node, Multi-GPU
MVAPICH-3 : unification du support CPU et GPU
Dask-MPI, Dask-Cuda, Dask-Jobqueue (provides Slurm, Kubernetes and other schedulers facilities)
Dask-Array : composé de Numpy-Array
Dask-Dataframe : composé de Panda-DataFrame
MPI4DASK -> mpi4py -> MVAPICH2
MPI4DASK : Point to point communication as Corourines
On peut définir DASK_INTERFACE et DASK_PROTOCOL dans un script Python
Plein d'évaluations dans la version 0.3 de MPI4DASK
Meilleures performances que UCX et TCP
Highly Efficient Alltoall and Alltoallv Communication Algorithms for GPU Systems [PS51918]
Thursday, Mar 23-6:00 PM - 6:50 PM CET NVIDIA’s Earth-2: Interactive digital twins for Weather and Climate Prediction at Ambitious Computational Scale and Scientific fidelity [S51216]
Wednesday, Mar 22-10:00 AM - 10:50 AM CET Accelerated Computing for Giant Optical Telescopes: Past, Present, and Future [S51674]
Slides
Adaptive Optics : AO : control the shape of the incoming waveforms
Typical Rate : 1 kHz => computing below 1ms
MAVIS : Imager and Spectorgraph
Ils utilisent du machine learning à cause de la quantité de calcul dont ils ont besoin
MAVIS on 4 V100 ellapsed time under 200 us
Sparse Matrix
ils jouent avec les seuils pour augmenter les "zeros" dans neur matrices
Compression SVD like sur les tiles (4*6) dans l'exemple => Stack U et V matrices pour la localité des données, pour optimisé la GEMV
Utilisation de cudaGraph pour amortir le fait que les kernels sont très petits
Bandwidth, de 600 GB/s sur V100, 800 GB/s sur A100 40GB à 1200 GB/s sur A100 80GB
Ajustement de la taille des tiles pour optimiser le calcul
Ils stockent les données en FP16 mais font les calcul en FP32
Ils ont un gros gain de performance en augmentant le nombre de cuda streams sur A100
Augmentation de la réutilisabilité des données pour limiter le nombre de transfter
LU based solver sans pivot et pas QR based solver (qui coüte 3x de plus)
Execution asynchrone
Près de 15 TFlops en FP16
Mélange de la compression SVD, avec la mixe precision pour augmenter encore plus les perf
PaRSEC : one of USA computing project
Data Driven Adaptive Optics
Denoising with autoencoders : Supervised learning (with simulations or calibration source on a bench)
Reinforcement learning for predictive control
Les agents fonctionnent mieux si ils ont accès aux info de leur voisins
AI control on SPHERE (curently on VLT) for 2026
Wednesday, Mar 22-7:00 PM - 7:25 PM CET Exploring Industry and Business Use Cases for GPU-Powered Quantum Technologies [S51171]
Slides
AQ = AI + Quantum Tech
Les QPU ne vont jamais remplacer les ordinateurs classiques, et pourront être utiliser à distance
Créer de nouveaux médicament cout cher (1-4 G\$) et prend du temps, 10-15 ans)
Pour le moment ils remplacent les QPU par du machine learning
Créer de nouveau matériaux
L'idée n'est pas de remplacer les tests mais de réduire leur nombre
Risque financier
Quantum Sentor : Utiliser les bugs duent à une trop grand sensibilité des QPU à rester cohérent pour faire de la détection
Quantum navigation (avec le champ magnétique terrestre )
Connect with the Experts: Inter-GPU Communication Techniques and Libraries [CWES52010]
Slides
Le son est pourri (heureusement, c'est le son que d'une personne)
GPU Communication :
NVShmem : Pour commencer mais quelques restrictions (un thread CPU par GPU)
NCCL : Pour commencer mais quelques restrictions (un thread CPU par GPU)
UCX/UCC : pour expert
GPUDirect Peer-Peer P2P
GPU Direct RDMA
Toujours commencer simple
Faire attention à l'ordre des communications (pour ne pas être bloqué comme avec MPI)
GPU-Initated Communication : Le transfer des données est fait au niveau du thread sans attendre que le bloc soit fini.
Cuda Stream et CudaGraph pour ordonner les kernels, et on peut aussi faire des communications asynchrones
Il ne faut pas profiler 100 GPU avec Nsight, car il n'est pas fait pour ça. D'autres outils vont être présentés.
Wednesday, Mar 22-2:00 PM - 2:50 PM CET Advanced Algorithms for Physics-Informed Neural Networks Reconstruction of Complex Flows [S52154]
Slides
PINN : Physics-Informed Neural Networks
Peuvent résoudre des équations différentielles
La majorité est basée sur des FeedForward neural networks
Recontruction of complex flow problems : Turbidity current
Recontruction en density driven gravity flow : Hidden fluid mechanics
PINNs training algorithms : Fixed points or RAR (Residual-based Adaptative Refinement)
Preprocessing simulation data with SVD to remove noise du to discretization
Bubble Dynamic : Two phases flow
Implémentation avec Tensorflow sur plusieurs GPU
Wednesday, Mar 22-4:00 PM - 4:50 PM CET Powering the Next Revolution in Radio Astronomy with GPUs [S51899]
Slides
Radio Camera for radio Telescopes
Déconvolution du telescope avec la PSF pour obtenir l'objet observé
Beaucoup de données en radio astronomie
DSA-2000 : 0.7 ZB/yr (pour 2026)
2048 antènnes > 2 millions de paires
> 9000 fréquences
2 polarisations par antenne
4 polarisations product per baseline
8 bits per sample
7.5 ms per sample
Data Parallelism per channel
10x-200x speed up on GPU (pas de tensor core pour le moment, que les SMs)
Besoin de profiler le code, sur un cas plus petit
Ils font du Kokkos
Connect with the Experts: C++ Standard Parallelism and C++ Core Compute Libraries [CWES52064]
Slides
nvc++, core library thrust, cub, cudac++
C++20/C++23
Dispatch to vendors optimised libraries
Tools to write your own parallel algorithms
Machalism for composing Parallel into tasks graphs
nvbench : benchmarks cudac++
https://github.com/nvidia/stdexec
Différent type de scheduler : Pool the thread ou Appels Cuda
Les atomiques sont disponibles en nvcc mais peut-être pas encore en nvc++
Tout ce qui est dans cuda::std fonctionne sur l'host et le device
Ils développent les fonctionnelités qui les interressent et ils essaient de les intégrer dans le standard. Si Sycl supporte le standard, ça fonctionne.
Le compilateur pourrait ajuster des algos à la volé (comme quicksort) selon la cible de la parallèlisation (quelques coeurs CPU ou tous les coeurs d'un GPU)
Il ne faut jamais perdre de vu le fait qu'il faut évaluer la performance et la scalabilité d'une implémentation parallèle. Et non se contenter d'en avoir une.
Porter des calcul de shader dans le langage C++ n'est pas facile car l'environnement des shader est beaucoup plus contrain que C++.
Le standard C++ n'a pas la notion des autres processus ou de calcul distribué avec communication, et puor le moment il n'y pas de roadmap pour faire des remote read et remote write (RDMA). Mais on peut avoir des scheduler distribués.
Première version de la mémoire unifié : le compilateur appelera un cudaMallocHost à la place d'un malloc pour que la mémoire soit visible du GPU.
Pour l'exemple de l'equation de Maxwell, ne nombre de GPU n'est pas limité par le Sender et le Scheduler, mais il pourrait y avoir des limitations algorithmiques
Pour avoir un tel résultat, le Scheduler doit être basé sur une techno comme MPI ou NVShmem
Probablement que cuBLAS supportera les float16, mais pour le moment ce n'est pas le cas. Dans tous les cas, il faudra attendre que nvcc gère les float16. D'ailleurs, ce n'est pas encore le cas pour nvc++.
Pour le moment il n'y a pas de plan pour intégrer les nouveautés de Cuda 12 dans Thrust
Rust démontre l'utilité de la programmation générique tout en vérifiant que ce qui est généré est valide, ce qui est très intéressant en HPC
Rust sera peut-être le langage prédominant du HPC sur le long terme, mais pour le moment, le C++ est le langage du HPC et au vu de la quantité de projet qui l'utilisent il sera amélioré pendant encore très longtemps.
Thursday, Mar 23-8:00 PM - 8:50 PM CET Robust and Efficient CUDA C++ Concurrency with Stream-Ordered Allocation [S51897]
Slides
Cuda Stream pour transférer des donneés pendant un calcul sur d'autres
Les calculs dans un stream sont ordonnés et ne peuvent pas se marcher dessus
Les calcul entre les stream ne sont pas ordonnés et peuvent se marcher dessus
Il faut éviter les comportements indéterminés
Trop d'allocation tue la performance
Steamed Ordered Memory Allocation cudaMallocAsync, cudaFreeAsync (valide uniquement sur le stream qui est utilisé)
Il y a des cas où le driver peut réutiliser la mémoire libérée.
Dans RAPIDS libcudf, c'est l'appelant qui doit définir si le kernel doit être synchronisé ou pas, pas le kernel, car l'appelant doit savoir ce qu'il fait
Il faut utiliser les Cuda Steams pour gagner en performance mais il faut les utiliser de manière süre.
Connect with the Experts: GPU-Accelerated Data Processing with NVIDIA Libraries [CWES52014]
Slides
Le son est pourri
Image processing
CV-CUDA : supporte zero copy interface
PyTorch / Tensorflow
nvJpeg, nvJpeg200, DALI, NPP : peuvent être utililisés dans de nombreux frameworks
Si il y a des fuites mémoire dans nvJpeg, ça peut être de la faute du driver
DALI a été créé pour être le plus flexible possible
CV-CUDA fonctionne en C++ et en Python
Thursday, Mar 23-8:00 PM - 8:25 PM CET CUDA Implementation and Optimization for Boolean Model of Information Retrieval [S51435]
Slides
Le son est incroyablement pourri
Boolean Information Retrieval (BIR)
Basé que sur des opérations logiques
Data Compression : ratio from 1 to 4
L'algo est très proche de Huffman, avec des chunks
Ils doivent décompresser pour tester les conditions de recherche
Recherche pas très parallèle
Thursday, Mar 23-2:00 PM - 2:50 PM CET Embedded and Large-Scale Signal Data Processing [S51336]
Slides
Vidéo mélangée avec d'autres signaux (vitesse, etc)
Ils sont plus rapide sur une P100 que sur que T1200, mais c'est un peu attendu
Signal data are stored in MDF (Machine Data Format), les constructeurs ont l'air d'être d'accord dessus, mais comme c'est lent, le présentateur commence par les convertir dans un format rapide mais entre 1.1 et 1.2x plus gros
Les différentes channels ne sont pas forcément synchronisées, voir pas du tout.
Ils utilisent un join custom pour leur conversion
Transcoding avec cuMDF (suporte MF4+ format), disponible en C++ et Python
Ils utilisent aussi un temps unix en nanoseconde
Ils ont un problème de scalabilité mais ils ne savent pas encore pourquoi
Ils utilisent DASK pour distribuer le calcul, et slurm pour les jobs