12.3.2 : Hardware

• Wednesday, Mar 22-2:00 PM - 2:50 PM CET Programming Model and Applications for the Grace Hopper Superchip [S51120]
  • Slides
  • 600GB Memory
  • 4 TB/s
  • GPU 470x
  • CPU 3x
  • ~2x throughput of Intel CPU
  • NVidia NVLink Switch System : 256 Supership connected
  • CPU partitionning and GPU MIG
  • 2.5x sur OpenFoam (compare x86 + A100)
  • Nsight fonctionne sur Grace Hopper
  • 2.5x sur NAMD (compare x86 + A100)
  • 3.8x sur CP2K (compare x86 + A100)
  • 4.7x sur Hash Joing TPC-H Query 4 (compare x86 + A100)
  • Memory Consistency
  • Sur x86 il y a un page fault qui est géré par le pilote qui déplace les données correctement sur le GPU (avec nvc++ ou nvfortran)
  • Hopper peut accéder au cache de Grace (cudaHostRegister), mais Grace accède directelemeent la la DDR du Hopper
  • Rien besoin de changer si on utilise un modèle de programmation hétérogène
  • cudaMemePrefetchAsync (on dit que l'on va avoir besoin des données sur CPU)
  • Allocator fainéante, le GPU alloue les données si il fait les premiers accès
  • Plus besoin de gérer les transfers de données
• Wednesday, Mar 22-3:00 PM - 3:50 PM CET Optimizing Applications for Hopper Architecture [S51119]
  • Slides
  • A priori il n'y a pas besoin de changer les applications pour avoir une accélération. Mais ça peut aider
  • Les Thread Block Cluster sont Optionels
  • Les blocks dans un même thread block vont être exécutés en même temps.
  • Thread block cluster => CUDA cooperatove_group()
  • On peut appeler une synchronisation que sur un cluster
  • 224kB of shared memory par SMs (A100 164kB, V100 96kB, 64 kB P100, 48kB Kepler)
  • H100 cluster : 3648 kB of shared memory (16 SMs)
  • Des optimisation de cuFTT sont en cours pour utiliser les clusters, mais pas encore intégrées.