It is common in the HPC community that the achieved performance with just CPUs is limited for many computational cases. The EuroHPC pre-exascale and the coming exascale systems are mainly focused on accelerators, and some of the largest upcoming supercomputers such as LUMI and Frontier will be powered by AMD Instinct accelerators. However, these new systems create many challenges for developers who are not familiar with the new ecosystem or with the required programming models that can be used to program for heterogeneous architectures. In this paper, we present some of the more well-known programming models to program for current and future GPU systems. We then measure the performance of each approach using a benchmark and a mini-app, test with various compilers, and tune the codes where necessary. Finally, we compare the performance, where possible, between the NVIDIA Volta (V100), Ampere (A100) GPUs, and the AMD MI100 GPU. Presentation of a paper accepted in Supercomputing Frontiers Asia 2022

1. Evaluating GPU Programming Models for the LUMI Supercomputer
Supercomputing Frontiers Asia
March 1st, 2022
George S. Markomanolis, Aksel Alpay, Jeffrey Young, Michael Klemm, Nicholas Malaya, Aniello
Esposito, Jussi Heikonen, Sergei Bastrakov, Alexander Debus, Thomas Kluge, Klaus Steiniger, Jan
Stephan, Rene Widera and Michael Bussmann
Lead HPC Scientist, CSC – IT Center For Science Ltd.

2. Outline
• LUMI
• Programming Models
• PortingWorkflow
• Benchmarks and applications
• Hardware
• Results
2

3. 3

4. AMD GPUs (MI100 example)
4
AMD MI100

5. Programming models - HIP
• HIP: Heterogeneous Interface for Portability is developed by AMD to program on AMD GPUs
• It is a C++ runtime API and it supports both AMD and NVIDIA platforms
• HIP is similar to CUDA and there is no performance overhead on NVIDIA GPUs
• Many well-known libraries have been ported on HIP
• New projects or porting from CUDA, could be developed directly in HIP
• The supported CUDAAPI is called with HIP prefix (cudamalloc -> hipmalloc)
• Hipify tools convert CUDA codes to HIP
5

6. Programming models - OpenMP Offloading
• Well known programming model, long history on CPUs
• GPU support since v4.0
• For AMD GPUs we use AMD OpenMP compiler (AOMP)
• With 120 compute units for MI100, the num_teams should be multiple of 120 and the thread_limits multiple
of 64 (wavefront in AMD)
6

7. Programming models - SYCL
• SYCL is an open standard for heterogeneous programming. It is developed and maintained by the Khronos
Group.
• It expresses heterogeneous data parallelism with pure C++. The latest SYCL version is SYCL 2020, which relies
on C++17.
• Starting with SYCL 2020, a generalized backend architecture was introduced that allows for other backends apart
from OpenCL. Backends used by current SYCL implementations include OpenCL, Level Zero, CUDA, HIP and
others.
• SYCL is using data parallel kernels, the execution is organized by a task graph and there are two memory
management models, the buffer-accessor and unified shared memory (USM) models.
• For this work we use the hipSYCL implementation, it supports NVIDIA/AMD/Intel GPUs among CPUs.
7

8. Programming models - Kokkos
• Kokkos Core implements a programming model in C++ for writing performance portable applications
targeting all major HPC platforms. It provides abstractions for both parallel execution of code and data
management. (ECP/NNSA)
• The Kokkos abstraction layer maps C++ source code to the specific instructions required for the backend
during build time. When compiling the source code, the binary will be built for the declared backends:
oSerial backend, for serial code on a host device.
o Host-parallel backend, which executes in parallel on the host device (OpenMP API, etc.).
o Device-parallel backend, which offloads on a device, such as a GPU.
8

9. Programming models - OpenACC
• GCC will provide OpenACC (Mentor Graphics contract, now called Siemens EDA). Checking functionality
• HPE is supporting OpenACC v2.7 for Fortran. This is quite old OpenACC version. HPE announced that they will
not support OpenACC for C/C++
• Clacc from ORNL: https://github.com/llvm-doe-org/llvm-project/tree/clacc/master OpenACC from LLVM only for
C (Fortran and C++ in the future)
oTranslate OpenACC to OpenMP Offloading
9

10. Programming models - Alpaka
• Abstraction Library for Parallel Kernel Acceleration (Alpaka) library is a header-only C++14 abstraction library for
accelerator development.
• Alpaka enables an accelerator-agnostic implementation of hierarchical redundant parallelism, a user can specify data
and task parallelism at multiple levels of compute and memory for a particular platform.
• In addition to grids, blocks, and threads, alpaka also provides an element construct that represents an n-dimensional
set of inputs that is amenable to vectorization by the compiler.
• Platform decided at the compile time, single source interface
• C++ User interface for the Platform independent Library Alpaka (CUPLA) makes it easy to port CUDA codes
• Supports: HIP, CUDA, TBB, OpenMP (CPU and GPU), SYCL etc.
10

11. Porting non-GPU codes to LUMI
11

12. Porting GPU codes to LUMI
12

13. Benchmarks and Applications (I)
• BabelStream
A memory bound benchmark with many programming models implemented and five kernels
oadd (a[i]=b[i]+c[i])
omult (a[i]=b * c[i])
ocopy (a[i]=b[i])
otriad (a[i]=b[i]+d*c[i])
odot (sum=sum+a[i]*b[i])
oThe default problem size is $2^{25}$ FP64 operations and 100 iterations. We are evaluating
BabelStream v3.4 (6fe81e1). We present also the first results of BabelStream with the Alpaka
backend
13

14. Benchmarks and Applications (II)
• miniBUDE
We use also the mini-app called miniBUDE for the Bristol University Docking Engine (BUDE), a kernel of a
drug discovery application that is compute bound.
BUDE predicts the binding energy of the ligand with the target, however, there are many ways this bonding could
happen, and a variety of positions and rotations of the ligand relative to protein, known as poses, are explored.
For each pose, a number of properties are evaluated.
oIt supports various programming models but we do evaluate mainly CUDA and HIP.
oWe use the version with commit 1af5b39
• Both BabelStream and miniBUDE support many programming models such as HIP, CUDA, OpenMP
Offloading, SYCL, OpenACC, Kokkos.
14

15. Methodology and Hardware
• Compiling based on the available instructions from benchmark/application
• Execute 10 times and plot boxplots
• Tune where necessary based on the number of compute units on the GPU, wavefront/warp.
15

16. Compilers/Software
16

17. Results - BabelStream
17
Copy kernel
• AOMP lower performance compared to the
other programming models
• The default Kokkos implementation in
BabelStream does not provide tuning
options.
• Finally, hipSYCL has a variation on A100
which is less than 2%, and Alpaka achieves
a performance similar to HIP for the
MI100
• MI100 is 26-34% slower than A100 and
15-37% faster than V100
• While MI100 achieves 97.8-99.99% of the
peak performance except the OpenMP
results, the NVIDIAA100 achieves 96.3-
98.5% and V100 89-98.2%

18. Results - BabelStream
18
Multiply kernel
• For MI100, most of the programming
models achieve 96.63% and above, except
OpenMP, while for A100 all the
programming models perform close to the
peak, however, for V100, the not tuned
Kokkos underperforms.
• For MI100, most programming models
perform 17.8-37.8% faster than V100, and
similarly, MI100 is 25-31% slower than
A100.

19. Results - BabelStream
19
Add kernel
• The performance of Alpaka programming
model is quite close to HIP/CUDA for all
the devices with hipSYCL following
• The OpenMP is less efficient on the MI100
compared to the rest GPUs. Finally,
Kokkos’ performance, seems to be between
Alpaka and hipSYCL.
• MI100 is 14.74-21.60% faster than V100
and 28.55-32.86 slower than A100
• MI100 achieves 94.52-99.99% of its peak
while the rest GPUs 97.6-99.99%.

20. Results - BabelStream
20
Triad kernel
• For this kernel Alpaka performs equally to
HIP/CUDA, with following Kokkos, and
then hipSYCL and OpenMP.
• MI100 is 28.93-32.81% slower than A100
and 18.63-21.61% faster than V100
• MI100 achieves 94.62-99.94% of the peak
while the NVIDIA GPUs achieve at least
98%.

21. Results - BabelStream
21
Dot kernel
• In the first segment of V100, we have also a plot of
MI100 for hipSYCL as they were too close these
values.
• MI100 GPU is around 2.69-14.62% faster than NVIDIA
V100 except for OpenMP, and 28.00-69.69% slower
than A100.
• For HIP/CUDA; We define 216 blocks of threads for
the A100, as it has 108 streaming multiprocessors, and
improved the dot kernel performance by 8-10%.
• For hipSYCL; we utilize 960 blocks of threads and 256
threads per block for MI100 to achieve around 8%
faster than the default values.
• For Alpaka; we are able to tune also the dot kernel with
720 blocks of threads for MI100 and improve its
performance by 28% comparing to the default settings.
• OpenMP underperforms for AOMP, almost 50% slower
than V100

22. BabelStream Summary
• The peak bandwidth percentage for the OpenMP programming model is 42.16% - 94.68% for MI100
while it is at least 96% for the NVIDIA GPUs which demonstrates that AOMP needs further
development.
• For Kokkos, the range is 74-99% for MI100, 72.87-99% for the NVIDIA GPUs, where the non-
optimized version has lower performance mainly on MI100 and V100.
• hipSYCL achieves at least 96% of the HIP/CUDA performance except for MI100 and dot kernel that
achieves 89.53%.
• Finally, Alpaka achieves at least 97.2% for all the cases and demonstrates its performance.
• The OpenMP compiler performs better for NVIDIA GPUs regarding dot kernel, however, the version
that we used for AMD GPUs, is not the final product yet.
• Overall, the Alpaka performance is quite close to HIP, followed by hipSYCL and Kokkos, while
OpenMP can perform slower depending on the kernel.
22

23. Results - MiniBUDE
23
• Large problem sizes for miniBUDE are required to be
able to saturate the GPUs.
• For every experiment, we execute 8 iterations with
983040 poses, we calculate this number by tuning for
AMD MI100
• The miniBUDE provides in the output the single
precision GFLOP/s, and we observe that the AMD
MI100 GPU achieves a performance close to A100 by
2% and around 26% over V100.
• Regarding single precision, we tested also the mixbench
benchmark and the MI100 was 1.16 times faster than
A100, achieving both close to their peak performance.

24. Conclusion
• We presented a workflow for porting applications to LUMI supercomputer, an AMD GPU-based system
• We utilize a benchmark and a mini-app, which are memory and compute-bound respectively. We illustrate how
various programming models perform on these GPUs and what techniques can improve the performance for specific
cases.
• We presented the first results of BabelStream with Alpaka backend
• We discuss the lack of performance on some aspects of OpenMP
• HIP/CUDA perform quite good and most of the programming models are quite close, depending on the kernel
pattern. However, the users should be aware about other programming models either ones that underperform in
some cases like OpenMP for some patterns or the learning curve of Kokkos tuning
• Finally, programming models such as Alpaka and SYCL could be utilized as they support many backends, are
portable and for many kernels they provide similar performance to HIP.
• Support reproducibility, find how to reproduce experiments on NVIDIA V100/100, and AMD MI100:
https://zenodo.org/record/6307447
24

25. Future work
• We investigate to identify what the issue with some programming models and miniBUDE is.
• We want to analyze the OpenACC performance from the GCC and Cray Fortran compiler
• Test the new functionalities from the ROCm platform such as Heterogeneous Memory Management (HMM)
• We envision evaluating multi-GPU benchmarks and their scalability across multiple nodes
• By using LUMI we will be able to use the MI250X GPU and compare it with the current GPU generation, among
testing the packed FP32
• Finally, we are interested in benchmarking I/O from the GPUs memory as we have already hipified Elbencho
benchmark
25

26. facebook.com/CSCfi
twitter.com/CSCfi
youtube.com/CSCfi
linkedin.com/company/csc---it-center-for-science
Kuvat CSC:n arkisto, Adobe Stock ja Thinkstock
github.com/CSCfi
George S. Markomanolis
CSC – IT Center for Science Ltd.
Lead HPC Scientist
georgios.markomanolis@csc.fi
26