rseng-gpu-computinglisted

# GPU programming for research software Accelerators dominate modern research computing, but the ecosystem is fragmented: vendor-native models, portability layers and language bindings each trade performance against maintainability. This skill turns that landscape into decision support. ## Choosing a programming model - CUDA: NVIDIA-native; largest ecosystem and learning material; locks the code to one vendor. - HIP: AMD's near-CUDA model; a pragmatic path when AMD hardware is in scope, with source-to-source translation available from CUDA. - SYCL: single-source C++ across vendors; growing research adoption. - OpenACC / OpenMP offloading: directive-based; the gentlest port for existing Fortran/C code, at some control cost. Decide by: target machines (which vendors, for how long), the team's languages, and how much low-level control the kernels genuinely need. Prefer libraries over hand-written kernels wherever an existing GPU library covers the computation. ## Calling GPUs from high-level languages Research code rarely starts in C++: CuPy and PyCUDA (Python) and CUDA.jl (Julia) expose GPU arrays and kernels with far less ceremony. Reach for them before rewriting a pipeline in a systems language, and keep the array-API boundary clean so kernels stay swappable. ## Portability layers Kokkos and Raja abstract over backends for C++ codebases that must outlive any single vendor; they suit infrastructure-tier software with long horizons more than one-off analysis kerne