« Avec la radioastronomie, nous avons un cas d’usage qui oblige à repenser l’exécution des calculs »
Comment mieux exploiter la puissance des supercalculateurs pour répondre aux défis de la radioastronomie ? Olivier Aumage, chercheur Inria Bordeaux, présente un nouveau projet mené avec ECLAT pour optimiser l’exécution des traitements, réduire les temps morts et préparer les logiciels aux volumes de données attendus avec le SKA.
Entretien avec Olivier Aumage, chercheur Inria Bordeaux, spécialiste du calcul intensif et des supports d’exécution
Vous lancez un nouveau projet pour optimiser le traitement des données en radioastronomie. Quel en est le contexte ?
Je travaille depuis plus de vingt ans sur le calcul intensif et sur ce qu’on appelle les supports d’exécution, c’est-à-dire les logiciels qui s’intercalent entre les applications et le matériel pour piloter l’exécution des programmes. Leur rôle est de répartir les calculs entre CPU, GPU, FPGA et sur différentes machines, avec l’objectif d’avoir le moins de temps mort possible.
Depuis quelques années, je cherche davantage à travailler au contact des applications réelles. J’avais suivi les travaux de Damien Gratadour en radioastronomie et j’ai progressivement vu qu’il y avait des sujets sur lesquels nous pouvions apporter quelque chose, notamment autour de DDFacet, un logiciel utilisé pour le traitement et l’imagerie des données radioastronomiques.
Quel est précisément l’objectif du projet ?
Aujourd’hui, dans DDFacet, le mode de parallélisme est modérément supervisé. Le programme principal génère des travaux à réaliser, les met à disposition, puis différents processus auxiliaires viennent les prendre, les exécuter et retourner les résultats. Cela fonctionne, mais la coordination globale reste du ressort du système d’exploitation qui n’a pas connaissance des intentions, priorités et dépendances de l’application.
Ce que nous voulons tester, c’est si un support d’exécution et une exécution plus planifiée peuvent améliorer les performances. L’image que j’utilise est celle des dominos : plutôt que de poser quelques dominos, les faire tomber, puis préparer la suite, nous voudrions préparer une plus grande partie de la chaîne à l’avance. Une fois le premier domino lancé, tout pourrait s’enchaîner avec le moins de temps mort possible.
Cela permettrait aussi d’anticiper les mouvements de données. Si une donnée doit être utilisée par un GPU, il faut idéalement qu’elle soit déjà présente lorsqu’il est prêt à calculer. Si on commence à la chercher à ce moment-là, c’est déjà trop tard.
« Aujourd’hui, dans DDFacet, le mode de parallélisme est modérément supervisé. Ce que nous voulons tester, c’est si une exécution plus planifiée peuvent améliorer les performances. »
« C’est un projet financé dans le cadre du programme Inria Quadrant consacré à la recherche à risque. »
Comment ce projet va-t-il être organisé ?
C’est un projet financé dans le cadre du programme Inria Quadrant (ANR-24-RRII-0002) consacré à la recherche à risque. Nous ne sommes pas sûr à l’avance que cela va marcher, et c’est justement l’intérêt. Le projet est court : un an, renouvelable une fois. Il faut donc montrer des résultats dès la première année.
Nous recrutons actuellement deux personnes, un post-doctorant et un ingénieur, chacun pour un an renouvelable sous condition. Ils travailleront directement sur l’intégration du support d’exécution dans DDFacet et sur son adaptation aux particularités de la radioastronomie.
Qu’est-ce qui rend justement la radioastronomie particulière du point de vue du calcul ?
La radioastronomie interférométrique est intéressante parce qu’elle combine deux types de comportement. Il y a une partie très répétitive, avec des traitements qui ressemblent à un pipeline, et une partie beaucoup plus adaptative, notamment lors de la déconvolution, où l’on ne sait pas à l’avance combien d’itérations seront nécessaires.
On est donc entre un modèle très régulier et un modèle dynamique. C’est précisément ce qui rend le problème intéressant pour nous. Sur d’autres applications, comme la mécanique des fluides, les calculs peuvent être beaucoup plus réguliers. Ici, il faut arriver à articuler les deux.
Et les volumes sont énormes. Une seule observation peut représenter des gigaoctets de données. Cela justifie l’utilisation des GPU, mais leur bénéfice n’est pas automatique. J’aime comparer le GPU à une Formule 1 et le CPU à une voiture de rallye : la Formule 1 va extrêmement vite si la route est parfaitement préparée. Si le calcul est irrégulier ou si les données ne sont pas au bon endroit au bon moment, on peut perdre une grande partie du bénéfice.
Olivier Aumage au hackathon ODISSEE organisé au LaBRI à Bordeaux en octobre 2026
Pourquoi est-il important pour vous de travailler dans le cadre d’ECLAT ?
Je pense qu’il y a un vrai intérêt, en recherche, à rester en lien avec les applications. Sinon, on a tendance à idéaliser les problèmes : on construit un joli modèle qui fonctionne bien sur le papier, mais lorsque les utilisateurs expliquent qu’ils ont telle contrainte ou telle particularité, le modèle peut s’avérer irréaliste en pratique.
ECLAT nous met directement en contact avec les astronomes, les développeurs de DDFacet et les besoins du SKA. Par exemple, la communauté utilise beaucoup Python. C’est une contrainte que nous devons prendre en compte. Elle peut limiter certaines possibilités de performance, mais si on l’ignore, les outils développés risquent simplement de ne pas être utilisés. C’est ce type de contrainte réelle qui donne du sens au travail.
Le SKA renforce-t-il encore ces enjeux de performance ?
Oui. Avec le SKA, les volumes de données d’observation seront tels qu’on ne pourra pas les stocker pour un traitement différé. Ce qui ne sera pas traité suffisamment vite sera simplement d’être perdu. Notre priorité est donc d’abord le temps d’exécution : essayer d’atteindre le débit nécessaire pour que les traitements puissent suivre le flux de données.
Construire des machines toujours plus puissantes ne suffit pas. Il y a souvent un écart très important entre la puissance théorique d’une machine et celle réellement obtenue sur une application. Les temps d’attente, les transferts de données ou les déséquilibres entre unités de calcul représentent autant de puissance inutilisée. Notre travail consiste à réduire cet écart.
« Il y a un vrai intérêt, en recherche, à rester en lien avec les applications. ECLAT nous met directement en contact avec les astronomes, les développeurs de DDFacet et les besoins du SKA.»
Votre projet peut-il avoir un impact au-delà de la radioastronomie ?
Oui. La radioastronomie est ici un cas d’usage particulièrement exigeant, mais les questions posées sont beaucoup plus générales : comment exploiter efficacement des architectures hétérogènes, comment anticiper les transferts de données, comment réduire les temps morts et, à terme, comment limiter la consommation énergétique.
Le mouvement des données est notamment très coûteux en énergie. Dans certains cas, il peut même être plus intéressant de recalculer une information localement que de la transférer. Ce sont des compromis que l’on retrouve dans de nombreuses applications scientifiques.
L’intérêt de ce projet est donc double : essayer d’apporter une réponse concrète aux besoins de DDFacet et du SKA, mais aussi produire des méthodes qui pourront être utiles à d’autres applications de calcul intensif confrontées aux mêmes défis de performance, de données et d’énergie.
