As a performance portability engineer at the Argonne Leadership Computing Facility (ALCF), Nevin Liber’s work focuses on optimizing codes to run efficiently on diverse high performance computing (HPC) architectures, including the ALCF’s exascale supercomputer, Aurora. 

Liber, the ALCF’s resident C++ expert, lends his expertise to international programming committees, contributing to advancements in C++, SYCL, and Kokkos—critical tools for enabling researchers to harness the immense computing power of the U.S. Department of Energy’s (DOE) leadership computing resources. In this Q&A, he discusses his contributions to the HPC community, the significance of standardization efforts, and how these innovations impact ALCF users and the broader scientific computing community. The ALCF is a DOE Office of Science user facility at Argonne National Laboratory. 

Can you tell us about your role with the ALCF’s Performance Engineering Team and how it contributes to the facility’s goals?

In my role as a performance portability engineer, I focus on ensuring that codes and software run efficiently across different computing systems. As Argonne and our fellow DOE national laboratories build new supercomputers, we aim to build systems with different vendors and diverse hardware architectures. It is imperative that scientific codes work on these new machines with as little porting as possible, ideally with one code base that works across all the machines without any machine-specific code. General code portability is concerned with correctness across different architectures, while performance portability takes it a step further by ensuring the code runs as efficiently as practical on each system. 

You’re also involved with the C++ committee. How did your journey with C++ begin? What impact does your committee work have on ALCF users and the HPC community?

When I was first starting out, I was working at AT&T Bell Laboratories. I received a phone call from a good friend at Apple, asking me “what do you know about C++? You [folks at Bell Labs] invented it!” That was enough to motivate this shy junior engineer to make inquiries about getting it installed on our local machines so I could learn it.

My committee work ends up helping us in a number of ways. The committee is made up of very smart people who are quite passionate about C++.  To that I bring expertise in using C++ for HPC systems and applications. My role there allows me to express our concerns from the perspective of an HPC user as the various language and library features are being designed.

Committee decisions are rarely arbitrary, so what I bring back to ALCF (besides being our resident C++ expert) are the reasons behind the design decisions (the history and the archeology), which I find helps scientists and engineers gain a deeper understanding. Scientists’ primary role is to do the science, and while C++ is a tool which helps them achieve that, it is not their primary focus, nor should it be.

SYCL is a relatively new programming framework. Can you tell us how you got involved with the SYCL committee, your contributions, and its significance to the ALCF and the broader HPC community?

Because of our need to run on a wide variety of architectures, we need a framework for performance portability that vendors provide and maintain. While OpenMP is also in this space it is more geared towards C than towards C++. Argonne picked SYCL to meet this need for Aurora and it was a natural fit for me to help standardize it given my C++ Committee work. SYCL covers many different heterogeneous computing domains, but many of our HPC concerns are different than, say, the automotive industry. For instance, we need complex number support (while other domains may not), and we are adding it to SYCL. 

My role on that committee has expanded there, as I am also the C++ Compatibility Task Sub Group (TSG) Chair.  This TSG covers integration between C++ and SYCL, and eventually will encompass proposals from SYCL to standard C++.  C++ standardizes features that have longevity and broad appeal, making SYCL a more ideal place to explore the design space before proposing it to C++.

How do the committees’ contributions relate to Aurora?

The SYCL contributions relate directly to Aurora. A lot of things added to SYCL 2020 (along with Intel, our Aurora partner, who is also participating in both SYCL and C++ standardization) were added to facilitate HPC codes for Aurora: Unified Shared Memory (USM) and parallel reductions to name two big features we absolutely needed.

For C++, there have been improvements so we can use standard libraries (such as span, optional and variant) between the host and the device. Other improvements, such as class template argument deduction (CTAD) makes modern C++ programming easier and less error-prone, and is something we extensively use in SYCL 2020. Longer term, there are language and library features in newer versions of C++ that are directly applicable, such as simd support (just approved for C++26).

Why is it important for Argonne to have a presence on committees like these?

Users are underrepresented on these committees, and our HPC users have needs that other domains may not. These are the tools we use day in and day out and will be using for the foreseeable future. It is important to have a voice and a vote in shaping these tools. Designs need to take our requirements into account, and that only happens if we are there to explain our concerns. By being active participants, we have direct influence on the future of C++ and of SYCL.

It is also important that we take leadership roles on these committees. Besides being the SYCL C++ Compatibility TSG Chair, I am also the Vice Chair of the US (INCITS C++) delegation, as well as the Admin Chair and the Library Evolution Working Group Incubator (LEWGI) / Study Group (SG) 18 Co-Chair on the ISO C++ Committee itself.  

Are there any other programming tools or languages you're working with that support performance portability?

I also work on Kokkos, which is a C++ library and ecosystem for performance portability. Initially developed at DOE’s Sandia National Laboratories, it is used across the various national labs. The project joined the High Performance Software Foundation (HPSF) to foster broader development and adoption beyond the national labs.

A primary difference between SYCL and Kokkos is that SYCL is vendor-provided (they do the compiler work) while Kokkos is layered on top of that and provides an abstraction layer over SYCL and other programming models (OpenMP, CUDA, HIP, HPX, etc.).

Besides the direct use of Kokkos in scientific codes, the Kokkos team has been instrumental in getting features added to standard C++, such as atomic_ref (C++20), mdspan (C++23), and linear algebra (in the C++26 Working Draft). It all ties together. In the end, it’s all about providing reliable, efficient tools so that scientists can focus on science, not the nuances involved in running their codes on different machines.