« Radio astronomy gives us a use case that forces us to rethink how computations are executed »

Interview with Olivier Aumage, researcher at Inria Bordeaux and specialist in high-performance computing and runtime systems.

You are launching a new project to optimise radio astronomy data processing. What is the context?

I have been working for more than twenty years on high-performance computing and what we call runtime systems, meaning the software layers that sit between applications and hardware to manage program execution. Their role is to distribute computations across CPUs, GPUs, FPGAs, and on different machines, with the aim of minimising idle time.

In recent years, I have increasingly sought to work in direct contact with real applications. I had been following Damien Gratadour’s work in radio astronomy and gradually realised that there were areas where we could contribute, particularly around DDFacet, a software package used for processing and imaging radio astronomy data.

What exactly is the objective of the project?

Today, DDFacet uses a relatively loosely supervised parallel execution model. The main program generates work items, makes them available, and different auxiliary processes then pick them up, execute them and return the results. It works, but the global coordination is left to the operating system which does not know the intent, priorities, and dependencies of the application.

What we want to test is whether a runtime system and a more planned execution model can improve performance. The analogy I use is that of dominoes: instead of placing a few dominoes, knocking them down, then preparing the next ones, we would like to prepare a much larger part of the chain in advance. Once the first domino falls, everything could then proceed with as little idle time as possible.

This would also allow us to anticipate data movements. If a dataset needs to be used by a GPU, ideally it should already be there when the GPU is ready to compute. If we only start fetching it at that point, it is already too late.

« The project is funded through The Inria Quadrant Programme dedicated to high-risk research. »

What makes radio astronomy so specific from a computing perspective?

Radio interferometry is interesting because it combines two types of behaviour. One part is highly repetitive, with processing stages that resemble a pipeline, while another part is much more adaptive, particularly during deconvolution, where we do not know in advance how many iterations will be required.

So we are somewhere between a very regular model and a dynamic one. That is precisely what makes the problem interesting for us. In other applications, such as fluid mechanics, computations can be much more regular. Here, we need to combine both dimensions.

And the volumes are huge. A single observation can already represent gigabytes of data. This makes the use of GPUs relevant, but their benefit is not automatic. I often compare a GPU to a Formula 1 car and a CPU to a rally car: a Formula 1 car can go extremely fast if the road is perfectly prepared. If the computation is irregular or the data is not in the right place at the right time, a large part of that benefit can be lost.

Olivier Aumage at the ODISSEE hackathon organised in Bordeaux, October 2026

Why is it important for you to work within ECLAT?

Why is it important for you to work within ECLAT?
I think there is real value in research in staying closely connected to applications. Otherwise, we tend to idealise problems: we build an elegant model that works well on paper, but when users explain that they have a specific constraint or requirement, that model may prove impractical.

ECLAT puts us directly in contact with astronomers, DDFacet developers and the needs of the SKA. For example, the community uses Python extensively. That is a constraint we need to take into account. It may limit some performance gains, but if we ignore it, the tools we develop may simply not be used. These real-world constraints are what give the work its meaning.

Does the SKA make these performance challenges even more critical?

Yes. With the SKA, observation data volumes will be so large that it will not be possible to store them for deferred processing. Data that cannot be processed fast enough will simply be lost. Our first priority is therefore execution time: trying to reach the throughput required for processing to keep pace with the incoming data stream.

Building ever more powerful machines is not enough. There is often a very large gap between the theoretical performance of a machine and what is actually achieved on a real application. Waiting times, data transfers and load imbalances between computing units all represent unused computing power. Our work is about reducing that gap.

Could your project have an impact beyond radio astronomy?

Yes. Radio astronomy is a particularly demanding use case here, but the questions it raises are much broader: how to make efficient use of heterogeneous architectures, how to anticipate data transfers, how to reduce idle time and, ultimately, how to limit energy consumption.

Moving data is particularly costly in terms of energy. In some cases, it can even be more efficient to recompute information locally than to transfer it. These are trade-offs that can be found in many scientific applications.

The project therefore has a dual ambition: to provide a concrete response to the needs of DDFacet and the SKA, while also developing methods that could be useful for other high-performance computing applications facing similar challenges in performance, data movement and energy efficiency.

« The project therefore has a dual ambition: to provide a concrete response to the needs of DDFacet and the SKA, while also developing methods that could be useful for other high-performance computing applications. »