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]
    • Apparemment annulé
  • 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 noteCe qui fera tiquer pas mal de monde, donc je m'arrête là.
    • 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]
    • Apparemment annulé
  • Wednesday, Mar 22-2:00 PM - 3:30 PM CET Boosting Apps with RDMA [DLIT52053]
    • Apparemment annulé
  • 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]
    • Poster
  • 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]
    • Apparemment annulé
  • 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 notePas les gâteaux.
    • Quantum Sentor : Utiliser les bugs duent à une trop grand sensibilité des QPU à rester cohérent pour faire de la détection
  • 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