Reflecting on 30 Years of High-Performance Computing Systems and Programming

In the summer of 2025, I had the honor of delivering the keynote at the 30th International Workshop on High-Level Parallel Programming Models and Supportive Environments (HIPS). This event provided a platform to reflect on three decades of programming in High-Performance Computing (HPC). The evolution of HPC systems is striking, with core counts skyrocketing from thousands in 1995 to millions today, and performance metrics improving by millions of times. This transformation is driven by advancements like vector instructions, multicore CPUs, and GPU computing. However, these hardware improvements have also introduced complexities for programmers, demanding more sophisticated approaches to parallelism and data locality.

In terms of programming languages, the landscape has remained surprisingly static. The dominant languages in 1995—Fortran, C, and C++—still hold sway today. While technologies like MPI and OpenMP have persisted, new entrants like Kokkos have emerged, particularly in response to the rise of GPUs. Despite these changes, the core programming paradigms have not evolved significantly, and no new compiled languages have gained widespread adoption in HPC.

The lack of progress in language development is concerning, especially given the increased complexity of modern hardware. Many of the hardware advancements have made programming more challenging, as they require new styles of parallelism and data management. The programming models have not sufficiently abstracted from the hardware, leading to a reliance on a mix of notations like C++, MPI, and CUDA.

Several reasons might explain this stasis. Language design is not dead; new languages like Java, Python, and Rust have thrived outside HPC, driven by productivity, safety, and performance. However, these languages lack the necessary features for HPC, such as control over data locality and affinity. The HPC community may not feel the need for new languages, believing that existing ones are sufficient. Yet, this view overlooks the benefits of higher-level abstractions, which could simplify programming and enhance productivity.

Efforts to create new HPC languages have not been lacking. Many languages have been developed over the years, but none have achieved broad adoption. Factors contributing to this include the unique needs of the HPC community, the focus on maintaining legacy applications, and the emphasis on hardware over software. Additionally, social challenges and a shift towards a post-programming world, where pre-existing libraries are favored, have hindered language adoption.

To address these issues, we should embrace the ubiquity of parallelism and create funding structures that support the transition of promising software from research to production. Open-source software needs sustainable funding, and we should foster environments that encourage experimentation with new technologies. Chapel, a language I've been involved with, exemplifies how higher-level languages can adapt to hardware changes and abstract data movement, offering a glimpse of what is possible.

In closing, I remain hopeful that the HPC community will eventually adopt a modern language designed for parallelism and scalability. Current and aspiring programmers deserve languages that offer the productivity and safety seen in other fields, and I hope that in the next 30 years, we will see at least one such language gain widespread acceptance.