Efficient programming of RISC-V accelerators using existing HPC languages

The field of High Performance Computing (HPC) has relied upon standard, albeit highend, x86 CPUs and Nvidia GPUs for many years. However, in recent years we have seen a large number of AI accelerators becoming available which are, driven in part, by the demand to run larger, more complex models at reduced energy to solution. Vendors are recently opening up their toolchains beyond AI, enabling the use of these accelerators for a much wider class of high performance workload.

However, high performance software is typically written in languages such as C, C++, and Fortran, with Fortran accounting for around 60% of codes on ARCHER2 which is the UK national supercomputer. This makes a lot of sense, because users are familiar with these languages and HPC applications can be long lived, large code-bases. However, there are no mature compilation technologies for these languages that efficiently target these new class of accelerator.

The problem lies in sacrificing performance for portability. If developers want their software to last for decades, and run on the most modern hardware, they must write it in the common HPC languages. However, if developers want to make the most of a specific architecture, their code must be written using the domain-specific language and/or framework that the vendor provides.

Not only does this require significant work rewriting the code, but furthermore requires knowledge and expertise on behalf of the programmer which is specific to the accelerator in question.

My work aims to tackle this problem through the compiler stack, using the xDSL framework, for RISC-V accelerators. RISC-V is an open standard that is cheap for companies to adopt, and is flexible and extensible enough to be suitable for a broad class of problems.

In the first year I will focus initially on the Tenstorrent Grayskull/Wormhole cards. These cards use RISC-V cores for general computation and data movement, which are paired with matrix and vector accelerators. The data movement cores are especially interesting, as they enable the movement of data whilst compute is running concurrently - potentially being able to undertake local data reordering and caching in a specialised manner that suits the application.

This architecture provides significant opportunity for experimentation with a range of codes, and my initial focus will be on stencil codes because of the previous work undertaken on stencils across a range of architectures and the existing xDSL stencil dialect and integration with a range of frontends. Later work could explore other architectures, abstractions that can be shared between these accelerators, or focus on the Grayskull and Wormhole cards in more depth.