U.S. leadership computers today are giant GPU-based machines, whether you’re talking about the pre-exascale Summit supercomputer in operation today at the Oak Ridge National Laboratory Leadership Computing Facility (OLCF) or forthcoming exascale systems including Frontier (OLCF), Aurora (Argonne National Laboratory), and El Capitan (Lawrence Livermore National Laboratory) which are being rolled out over the next couple of years.

These big systems are all about leveraging GPU acceleration.

What’s more, there are numerous and impactful differences among their chip and system architectures that complicate programmer efforts to wring the most from these new supercomputers. In mid-February, Philip Roth a group leader at OLCF, grabbed attention with his talk – Wrong Way: Lessons Learned and Possibilities for Using the “Wrong” Programming Approach on Leadership Computing Facility Systems – presented by the IDEAS-ECP program sponsored by NSF and DOE.

Having “Wrong Way” in the title, conceded Roth, was modest hyperbole intended to stir attention, but his focus was on how to think about choosing programming models for the new leadership class systems. Presented here are 15 of his slides and a few comments (lightly edited).

First, here are Roth’s stage-setting comments about DOE’s computing systems:

“The word that comes to my mind is variety. They epitomize variety,” said Roth. “We have a variety of types of hardware in terms of accelerators and whether a system has them at all, certainly in terms of the vendors, the different ratios of number of CPUs to GPUs, and the connectivity within the node. Similarly, there’s a variety of types of interconnects that we see at DOE facilities. We have the question of non-volatile memory, whether it’s on-node or near-node or not even present at all in a system.

“That hardware, in some ways, drives also variety in software. Summit uses Power9 CPUs and Nvidia GPUs in each of its nodes. Soon we will be fielding Frontier, which uses x86 CPU processors from AMD and AMD GPUs in the nodes. [On] Frontier the NICs will be directly connected to GPU memory. The key point I want to bring out in this slide (below) is that over 90% of the production systems’ computational capability comes from their GPUs. In fact, it’s over 95% for Frontier. I’m going to focus in this talk on GPUs, not as much maybe [on their] performance but about making use of the GPUs.”

Can You Make Wrong Ways Work?

Roth said, “I want to clarify what I mean by the using the word ‘wrong.’ Is it bad? Is it something that’s discouraged or disallowed? Really, for the purposes of this presentation, what wrong means is it’s not the usual or generally accepted way to program a GPU on a system. It’s not necessarily something that’s supported by the system vendors or the computing facility. The real activity here is to try to think about what’s possible, not necessarily what’s recommended. I hope everyone will forgive the hyperbole.”

To make his point, Roth said, “I want to draw out a little bit of analogy to try to clarify this notion of wrong [by talking about] a library that’s called Dyninst dynamic instrumentation.” Dyninst, you may know, is an “API and related library for the dynamic instrumentation of binaries. It allows programs to be modified during execution without recompilation or re-linking. Used by performance measurement and other tools.”

“One of the things that Dyninst can do is it can inject or remove code from a process while it’s running,” said Roth. “For example, for a tool to be able to insert or remove some instrumentation, most tools, like a performance tool, will do that kind of instrumentation at compile time or even in source code before we get to the compiler. Dyninst lets you do it while the program is running. This is really an alternative to the way that most people think about software. In my experience, they think that once it’s compiled and [they] have an executable, that executable code is fixed, and it really doesn’t have to be is this [way]. Does this make Dyninst wrong? No. It’s just that people need to think about compiled code as being a little more malleable than what [they’re used to] may think. But it does require care.”

With that caution, Roth provided a brief tour of a few programming models and their issues as related to specific systems. While not a deep dive, Roth’s talk emphasized what has been shown to work on the new systems, and to a less extent also explored some of less-formally supported programming models.

So, asked Roth, “What is the natural way or a wrong way on various systems?”

“I want to be a little more explicit. So this slide (below) is attempting to do that. What determines whether an approach for programming GPUs is natural or ‘wrong’ is determined mainly by the type of the GPU and the source language. Don’t take this slide as an exhaustive list, but it shows some of the natural ways and some of the ways that are the off the beaten pathways for each system. I list three systems here: Summit and Frontier, those are both OLCF systems, and then Aurora, which will be deployed at Argonne. I know less about the Aurora so I’m going to be very cautious about what I have to say there.”

“At the top is shown graphically for Summit what would be considered natural ways and in green. So CUDA, since it’s Nvidia GPUs, would be a natural way. OpenMP offload and OpenACC is supported. The ways that I’m going to talk about that are potentially wrong ways to program GPUs on Summit are in gray – HIP, OpenCL and SYCL/DPC++. Frontier has a similar list, but instead of CUDA, we have HIP as being a natural way in. CUDA [isn’t] even an option. It’s not even a wrong way; it’s is one where it’s not even a possibility to my knowledge,” he said.

Roth noted that other portability layer software (such as Kokkos, RAJA and OCCA) can be considered natural methods for getting to a particular system’s GPUs if they have back-end support for one of that system’s natural approaches. It gets a little convoluted, but one example is Frontier’s explicit support for these approaches (see slide – color code is green works well; gray can be made to work; and red isn’t supported).

HIP Shows Strength on Summit

The HIP (heterogeneous-compute interface for portability), developed by AMD, has shown wide promise, according to Roth. The interface is similar to CUDA, Nvidia’s programming tool for its GPUs. HIP has been touted as a lightweight, header-based backend for both AMD and Nvidia GPUs. CUDA, of course, is an extremely well-developed programing platform that is very widely used, having grown steadily with Nvidia, which still dominates the HPC GPU market.

“I showed earlier where you could start from CUDA code and use HIPIFY tools to port the CUDA code to be HIP code. In this case, it was the AMD HIP compiler whether you wanted to target Nvidia GPUs or AMD GPUs. There’s now more than one HIP compiler. AMD is the one that most people think of but HIP CC (Cray Compiler Collection) or Cray compilers has the ability to compile HIP code also,” said Roth.

A frequent question has been: what is the performance hit from using HIP with Nvidia GPUs rather than CUDA? Roth presented favorable benchmark runs for HIP on Summit, which of course uses Nvidia GPUs, not AMD GPUs. “I took a benchmark suite that I’m somewhat familiar with, having helped develop it maybe 10 years ago, called SHOC (the scalable heterogeneous compute benchmark suite) and took the CUDA versions of the benchmarks and HIPified them, and then measured the performance of both. This was done about two years ago,” said Roth.

“I recently went back to revisit those results and that’s what’s showing on this slide (below). In the early days, using HIP on Summit was really, really easy. All you had to do was clone the HIP repository available on GitHub, and then essentially point your compiler at the Include Directories and it would work. The current implementation is only a little bit more difficult to work with because it requires just a little bit of installation; it needs a header that has a version number in it, and it gets that version number as part of the installation. But OLCF is providing a HIP module now — ROCm-HIP is the name of the module. A module is essentially the way that we manage our users’ environments; they can load modules to make changes and get access to particular programs or libraries. The message you should take from this graph is that the HIP versions are essentially at parity with the CUDA versions. And that’s what we would expect because the benchmark, or the HIP versions really are at dealt with at compile time, and you are running a CUDA program,” said Roth.

He emphasized the importance of the full ecosystem in all of these programming efforts.

Exploring OpenCL and SYCL Efforts

There was a good deal more to Roth’s presentation. He looked in some depth at the OpenCL programming model, which he said is undergoing a revival of sorts.

“By some definitions of performance portability, [OpenCL is] one of the better options because there are a number of implementations and they’re by now fairly mature. Originally, it was mostly a C-based kernel language. There have recently been some efforts to bring C++ features to open CL, and this is separate from SYCL,” noted Roth.

“If you’re familiar with OpenCL, and want to use it on Summit, you might be poking around at various locations where you expect OpenCL files to be and get excited, because there are a few of them there. But you will quickly find that it’s an incomplete installation of OpenCL. The device-independent runtime library is where you would expect it to be, but it doesn’t have the necessary support for applications to actually use it. The upshot is on Summit, if you want to use OpenCL, you have to do a little bit of work.”

Roth said OpenCL was likely to work well on Aurora which, of course, will use Intel CPUs (Sapphire Rapids) and GPUs (Ponte Vecchio). (See HPCwire‘s coverage.)

“OpenCL on Aurora is promising, at least to me. Intel’s traditionally had good support for OpenCL and they’ve been a champion of the use of SPIR-V. Their oneAPI programming — I don’t know exactly what to call it, it’s a collection of programming technologies that includes support for interoperability between SYCL code and OpenCL. This is understandable in that SYCL is really a spiritual successor to OpenCL. It’s also the case that the Argonne is including OpenCL on the public lists of the programming models that they plan to have available on Aurora. So, again, OpenCL should be a well-supported option on that system,” he said.

Looking at SYCL, Roth said, “[The] last programming model that I want to hit on is a combination actually, SYCL and DPC++. So SYCL, like OpenCL, is a Khronos standard. It’s C++ based, I think, reflecting kind of the community’s direction or shift towards C++. Originally, it had a really strong connection to SPIR, and now this SPIR-V as an intermediate language. I don’t know that that’s the case for every single implementation, but this was the way it was for the Intel SYCL implementation. So DPC++ is essentially SYCL version 1.2, but some added extensions that are designed to improve productivity [and] make it a little bit easier to use.”

“What do you do if you’d like to try SYCL on Summit?” asked Roth.  “There are some options. hipSYCL is definitely a useful option. And I’ve demonstrated simple examples there like a large matrix ax+y operation. Essentially, it can live on top of the CUDA runtime for programming the GPUs in Summit and OpenMP for running on the CPU cores. Another option for investigating SYCL on Summit would be to take the Intel LLVM staging repository, which has DPC++ implementation.”

“I’ve tried this a while ago. I found at the time that there was a reliance on an x86 instruction called CPU ID that gets information about the processor that it’s running on. That’s an x86-specific instruction, so it wasn’t something that the Power9 could use. But others have reported making some success in getting around that for other non-x86-64 platforms. In that case, it was Arm. So, still not Power9, but it was a non-x86 platform. So it may be possible, if not already done, that the code base has been updated to work on Summit,” he said.

“What about Frontier? I’ve really done less with this. But for an implementation that is reliant on OpenCL as a runtime, which is the case for some, the fact that AMD supports OpenCL is promising. It’s something that’s going to make it more likely that this would be an approach that would work. But it may also not be. There’s another option in the works, that we are funding Codeplay to implement a basic SYCL and DPC++ functionality for the AMD GPUs. And as I mentioned, there’s the Intel LLVM repository, so those are two potential options.”

Wrap-up Advice: Take Care on the Road Less Travelled

Roth’s ambitious talk (around an hour long) is best seen in full, and IDEAS-ECP has posted the full video and the slides (linked below). On balance, he suggested programmers use care when taking not explicitly supported tools to program for the emerging GPU-dominated leadership class machines.

“What I do recommend is: really be careful about thinking, what you and your project are willing to devote over time to adopt one of these off the beaten track approaches [to programming GPU-based leadership systems],” said Roth. “Several of the factors that I think you should consider are the performance impact, the portability of the approach, thinking about what systems you want to target now and at least in the known future. Maintainability — how difficult will it be if you have to be the one that’s providing support for a particular tool or tool chain or library on a system?”

“Here’s, you know, probably the most controversial thing I’m going to say today. I think, in general, our community doesn’t yet have the tools or the discipline to do a real quantitative, cost-benefit comparison to answer these questions [to choosing or adapting best programming models]. So that’s something I’d like to hear other people’s opinions on too,” he said. “Finally, I’m involved in a project where a person right now is very hesitant to adopt GPUs because they’re expecting that there should be something like MPI that’s a near-ubiquitous standard approach that is well supported, and everyone should be using that. As much as that would be nice, it’s not the world that we’re in right now, and won’t be for at least the near-term future. So don’t let the lack of something ubiquitous be the thing that keeps you from trying to target GPUs.”

Link to video: https://www.youtube.com/watch?v=AsUAXkw4q88

Link to slides: http://ideas-productivity.org/wordpress/wp-content/uploads/2022/02/hpcbp060-wrongway.pdf