When software moves faster than supercomputers

JGH01 — Mon, 17 Aug 2026 15:06:39 GMT

At first glance, that sounds like an impossible idea. Supercomputers continue to get faster with every generation. Yet in many HPC and AI environments, it is the software ecosystem, not the hardware, that is evolving more rapidly. The rise of AI, diverse computing environments, and rapidly changing software frameworks are reshaping how HPC environments are built and maintained. For decades, the programming environment could move in step with the system. Today, that assumption is being tested.

Hardware still matters. But for many organizations, the harder problem is no longer buying more compute, it’s keeping the programming environment aligned as processors, accelerators, compilers, libraries, frameworks, while user requirements change around it. Customers increasingly want access to new capabilities from AMD, NVIDIA, open-source communities, and HPE without waiting for major system release cycles. Validation, support, and reproducibility still matter. The challenge is delivering new software capabilities faster while maintaining the operational consistency production HPC and AI environments require.

Why validated environments still matter

HPE Cray Programming Environment (CPE), helped define an era of supercomputing in which the programming environment, system software, and hardware platform could be delivered as a tightly integrated whole. CPE gave customers a trusted foundation for building, compiling, and running HPC applications across generations of systems.

That foundation mattered because validation mattered. Reproducibility mattered. Customers needed confidence that the environment they used to build and run applications was stable, supported, and understood. Those needs have not gone away. If anything, they’ve become more important.

What really changed is the pace and diversity of the software ecosystem around the system.

Silicon vendors now deliver their own optimized compilers, libraries, runtimes, and tools. Open-source components continue to grow in number and importance. AI frameworks move quickly. Different teams need different versions of software. And more and more, customers are operating across mixed environments instead of a single, uniform platform.

The result is a new kind of operational pressure. Customers need faster access to new capabilities from NVIDIA, AMD, Intel, and the open-source ecosystem. But they also need confidence that those components have been tested, validated, and supported as a cohesive software environment.

Preserving the foundation, modernizing the model

To address that need, HPE introduced the HPE Supercomputing Programming Software (SUPS), a new approach to delivering validated programming environments. SUPS keeps the validation, support, and software expertise customers expect from HPE, but changes how programming environments are built and maintained. By aligning more closely with silicon-vendor toolchains, HPE can deliver validated compiler, library, and performance updates faster. SUPS continues to provide Cray MPI and Slingshot support, while HPE contributes its compiler expertise to LLVM and Flang to advance Fortran support. CCE Fortran remains available during this transition.

Before looking at how SUPS accomplishes this, it’s important to understand the broader transition underway in HPE's programming environment strategy.

CPE is reaching end of life

CPE 26.3 is the final planned release of HPE Cray Programming Environment. Existing CPE customers can continue to use CPE through its support lifecycle, including extended support through June 2027. Future programming environment innovation from HPE will move forward through SUPS.

The timing reflects a broader shift taking place across HPC and AI software ecosystems. As vendor software stacks, frameworks, and development tools evolve more independently, programming environments need a more flexible way to incorporate that change.

Why the model has to change

The shift is easiest to see in vendor software ecosystems.

An AMD-based programming environment may need to bring together ROCm, AOCL, AMD compiler technology, accelerator libraries, debugging tools, profiling tools, and HPE communication software. An NVIDIA-based environment may depend on the NVIDIA HPC SDK, CUDA-X libraries, NCCL, NVSHMEM, Nsight, and related development tools. Customers do not need HPE to replace those ecosystems. They need a way to bring them into a validated programming environment that can be installed, updated, versioned, and supported more predictably.

This is where the legacy model starts to show its limits. Every significant software update can trigger a new round of rebuilds and validation work, turning the programming environment into a bottleneck. Different teams often need different tools, frameworks, or software versions, and supporting all of them can become both costly and time consuming. Some teams wait to adopt new capabilities. Others move ahead on their own, creating environment drift and making support more difficult when problems arise.

SUPS is designed for that reality.

What SUPS changes

SUPS gives customers a validated programming environment they can version and extend, reducing the effort required to maintain software stacks as they evolve.

Different systems, architectures, teams, and applications often require different tools, frameworks, and software versions. SUPS starts from a validated foundation and gives customers a more modular way to manage change through versions, rather than rebuilding every environment from scratch. The goal is not necessarily to force every customer into a single software stack, but to provide a consistent development and operational experience across increasingly diverse HPC and AI environments.

Containers are part of that strategy, but they are only one piece of it. The real challenge is bringing together vendor software, open-source components, communication layers, and HPE integrations in combinations that have been validated and can be supported at scale. SUPS uses container technology to package those environments in a consistent, versioned way, helping dependencies move together and making environments easier to reproduce. As software stacks evolve, customers can create new versions rather than modifying a known-good baseline, reducing the operational effort required to maintain multiple environments over time.

What is in the SUPS environment

At a high level, SUPS brings together the major categories customers expect in a modern HPC and AI programming environment: compilers, libraries, communication software, debuggers, profilers, vendor software stacks, open-source tools, and HPE system integrations.

_supsDiagram.png

For AMD environments, the SUPS planning material references categories such as Fortran and C/C++ compiler options, AOCL, ROCm, ROCm tools, RCCL, debugging and profiling tools, Cray MPI, HPE Slingshot SHMEM, and HPC I/O libraries.

Screenshot 2026-08-17 100349.png

For NVIDIA environments, the material references categories such as the NVIDIA HPC SDK, CUDA-X libraries, NVFORTRAN, NVC++, NCCL, NVSHMEM, Open MPI, CUDA-GDB, NVIDIA Compute Sanitizer, CUPTI, Nsight, Cray MPI, HPE Slingshot SHMEM, and HPC I/O libraries.

Screenshot 2026-08-17 100455.png

The point is not that every customer uses every component. The point is that SUPS gives HPE a way to curate, validate, and support programming environments that reflect the real mix of vendor tools, open-source software, and HPE components used in today’s systems.

What HPE continues to own

SUPS also makes clear where HPE continues to provide differentiated value.

Cray MPI and Cray SHMEM continue as the message-passing tools for HPE Slingshot. HPE also continues to contribute to the MPICH community. That matters because the communication layer is not just another package in the stack. It’s part of how HPE systems deliver performance at scale.

For Fortran users, the transition is also being managed carefully. HPE plans to continue offering Cray Fortran while the next generation of Fortran support matures, including work with AMD, Berkeley Lab, and the LLVM community around Flang. SUPS planning materials also point to Flang contribution work and a transition from Cray Compiling Environment (CCE) to Flang over time.

HPE is taking advantage of innovation from vendors and open-source communities while continuing to invest in the technologies and support that customers rely on.

What this means for customers

For customers, the transition from the HPE Cray Programming environment (CPE) to HPE Supercomputing Programming Software (SUPS) is not simply a product name change. It is a shift from a monolithic programming environment model to a more modular, versioned model designed for continuous change.

That means customers can start from a validated foundation, create new environment versions when changes are needed, and add their own tools, libraries, frameworks, and applications without modifying the original validated baseline. HPE validates and supports the foundation, while customers own and validate any custom layers they add on top of it.

Validation does not disappear. What changes is where customers spend their effort. Instead of repeatedly rebuilding and revalidating the foundation, they can focus on the software, applications, and workflows that differentiate their environment and support their users.

Looking ahead

CPE helped HPC organizations manage the complexity of one era of supercomputing. It gave customers a stable, trusted programming environment when systems were more tightly coupled, when hardware and software release models could move together.

Today’s environment is different. AI frameworks are moving faster. Silicon vendors are innovating independently. Mixed architecture systems are becoming more common. And customers need programming environments that can keep up without giving up the validation and support they still rely on.

The move from CPE to SUPS does not have to happen all at once. SUPS environments can run alongside existing CPE environments, giving teams time to evaluate new software stacks and transition workloads at their own pace. Customers can continue using what works today while adopting newer technologies when they are ready.

Over time, SUPS provides a simpler way to bring together validated software, faster access to ecosystem innovation, and the flexibility to build and maintain programming environments for HPC and AI.

Re: When software moves faster than supercomputers

jmellorcrummey — Fri, 14 Aug 2026 14:35:36 GMT

HPC-ToolKit should be spelled HPCToolkit. I know this because it is my group's software. (Note: HPCToolkit can also be used on systems with NVIDIA GPUs, whether HPE promotes that or not.)

Re: When software moves faster than supercomputers

bcumming — Fri, 14 Aug 2026 14:44:27 GMT

How will the software packages be distributed? I would like to see tar balls that can be easily unpacked and wired into packaging workflows preferred by sites (and supported by tools like Spack and EasyBuild). RPMs are a pain in the neck to work with.

And what container runtime will you be sugesting sites that use the containers use?

Re: When software moves faster than supercomputers

JGH01 — Mon, 17 Aug 2026 15:07:26 GMT

Thank you for catching that! It's been updated.

Re: When software moves faster than supercomputers

AndyAdams — Mon, 17 Aug 2026 15:11:54 GMT

SUPS will be delivered as RPMs through the HPE Software Delivery Repository (SDR). We do not currently have plans to deliver tarballs.

SUPS also supports both Apptainer and Podman.

topic Re: When software moves faster than supercomputers in High Performance Computing

When software moves faster than supercomputers

Re: When software moves faster than supercomputers

Re: When software moves faster than supercomputers

Re: When software moves faster than supercomputers

Re: When software moves faster than supercomputers