Ordonnancement de graphes de tâches récursives

Scheduling recursive task graphs

• Auteur / Autrice : Thomas Morin
• Direction : Samuel Thibault, Abdou Guermouche
• Type : Projet de thèse
• Discipline(s) : Informatique
• Date : Inscription en doctorat le 21/09/2023
• Etablissement(s) : Bordeaux
• Ecole(s) doctorale(s) : École doctorale de mathématiques et informatique
• Partenaire(s) de recherche : Laboratoire : Laboratoire bordelais de recherche en informatique
• Partenaire(s) de recherche : Equipe de recherche : Supports et Algorithmes pour les applications numériques hautes performances (SATANAS)

Mots clés

Mots clés libres

Support d'exécution

Graphe de tâches

Tâche récursive

Ordonnancement

Runtime system

Task graph

Scheduling

Recursive task

Résumé

Les besoins croissants en calcul scientifique ont amené la communauté du Calcul Hautes Performances (HPC) à concentrer toujours plus les moyens de calcul, et notamment en employant des accélérateurs graphiques (GPU). La plupart des plus grandes machines de calcul du monde, recensées sur https://top500.org/, intègrent ainsi de nombreux GPU qui renforcent grandement la capacité de calcul des CPUs classiques, et améliorent considérablement l'efficacité énergétique obtenue. Cette juxtaposition de CPUs et GPUs introduit cependant une hétérogénéité des capacités de calcul, et il devient nécessaire de transférer les données entre ces unités. Depuis une quinzaine d'années, la communauté du HPC adopte de plus en plus une approche de programmation par graphe de tâches, dont il est alors possible d'optimiser automatiquement l'exécution sur ces machines devenus complexes. Le département SATANAS a contribué grandement à cet essor, sous la forme du support d'exécution StarPU (https://hal.inria.fr/inria-00550877 , https://hal.inria.fr/tel-01959127). Une question essentielle s'impose cependant: quelle granularité doit-on choisir pour la taille des tâches ? Pour être efficaces, les GPUs nécessitent de choisir de grandes tailles de tâches, alors qu'à l'inverse il vaut mieux générer de nombreuses tâches de petite taille pour nourrir en parallèle les différents cœurs des CPUs. Dans sa thèse (https://hal.inria.fr/hal-03789625v1), Gwénolé Lucas a introduit la notion de tâche récursive, que l'on peut découper en un sous-graphe de sous-tâches, et ce récursivement à volonté. On peut alors, à partir d'un graphe de tâches produit par l'application, à la fois maintenir un ensemble de grandes tâches pour les GPUs, et découper certaines grandes tâches en petites tâches pour les CPUs. Le défi est cependant de déterminer automatiquement quand, comment, combien, et quelles tâches devraient être découpées. Idéalement l'application ne soumettrait qu'une seule tâche représentant l'ensemble du calcul souhaité, et le support d'exécution s'occuperait alors de la découper récursivement automatiquement au fur et à mesure de l'exécution, selon les resources de calcul disponibles sur la machine et le comportement observé. Différents compromis entrent alors en jeu. Il n'est a priori pas opportun d'opérer le découpage entièrement dès le début de l'exécution, il est préférable d'observer à mesure le comportement obtenu. Par ailleurs, une tâche peut se découper de différentes manières, qui exposent différentes formes de parallisme. D'autre part, le découpage des tâches permet un entrelacement des différents sous-graphes de sous-tâches générés, mais le découpage peut diminuer l'efficacité du calcul. Inversement cela peut rester utile de découper tout de même les tâches du chemin critique pour en améliorer la latence d'exécution. Mais pour transférer efficacement les données sur le réseau de la machine il est souhaitable de conserver une grande granularité. Enfin, l'importances de ces différents compromis évolue selon les phases de calcul de l'application. L'objectif de cette thèse est donc en premier lieu de faciliter l'expression de graphes de tâches récursives par les applications, pour favoriser leur utilisation effective par la communauté du HPC. Il s'agira alors d'étudier les différents critères et informations précalculées par un compilateur, ou observées durant l'exécution, qui permettront de déterminer automatiquement des compromis de découpage de tâches. Les expérimentations pourront être menées avec les solveurs Chameleon et PaStiX développés au sein du département SATANAS, mais aussi avec d'autres applications déjà portées sur le support d'exécution StarPU, telles que les solveurs hiérarchiques développés par Airbus Group, ou les solveurs en algèbre linéaire compressée et avec précision hybride développés à l'université de KAUST.

The growing scientific computing needs have led the High-Performance Computing (HPC) community to keep concentrating computation power, notably by employing graphical accelerators (GPU). Most of the largest computation systems in the world, recorded on https://top5000.org/, now integrate many GPUs, which amply reinforces the computation power of classical CPUs, and considerably improve the obtained energy efficiency. This juxtaposition of CPUs and GPUs however introduces heterogeneity in the computation capabilities, and it becomes necessary to transfer data between these units. For a dozen years, the HPC community has been more and more adopting a programming approach based on task graphs, whose execution can then be optimized automatically on these complex machines. The SATANAS department amply contributed to this breakthrough, by designing the StarPU runtime system (https://hal.inria.fr/inria-00550877 , https://hal.inria.fr/tel-01959127). An essential question however emerges: which granularity should we choose for the task size? To be efficient, GPUs impose to choose large tasks sizes, while on the contrary it is preferrable to generate many smaller tasks to feed in parallel the different cores of CPUs. In his thesis (https://hal.inria.fr/hal-03789625v1), Gwénolé Lucas introduced the notion of recursive task, which one can split into a sub-graph of sub-tasks, and again recursively at will. One can then, from a task graph produced by the application, both maintain a set of large tasks for GPUs, and split some of the large tasks into smaller tasks for the CPUs. The challenge is however to automatically determine when, how, how much, and which tasks should be split. Ideally the application would just submit one task that represents the whole desired computation set, and the runtime system would then manage splitting it recursively automatically during execution, according to computation resources available on the machine, and the observed behavior. Different compromises then come into play. It is a priori not interesting to perform the whole splitting entirely at the beginning of the execution, it is preferrable to progressively observe the obtained behavior. Moreover, a task can be split in several ways which expose different forms of parallelism. Furthermore, splitting tasks allows to interleave the various generated sub-graphs of sub-tasks, but the splitting may reduce the computation efficiency. Conversely it may remain interesting to anyway split the tasks that belong to the critical path, to improve their execution latency. However, to efficiently transfer data on the machine network, it is preferrable to keep a large granularity. Eventually, the importance of these compromises evolves along the computation phases of the application. The goal of this thesis is thus first to help applications express recursive task graphs, to favor their actual use by the HPC community. It will then consist in studying the different criteria and information precomputed by a compiler, or observed during execution, which will allow to automatically determine task splitting compromises. Experiments can be conducted on the Chameleon and PaStiX solvers, developped in the SATANAS department, but also with other applications already ported to the StarPU runtime system, such as the hierarchical solvers developed by Airbus Group, or the compressed linear algebra solvers (possibly with hybrid precision) developed at the University of KAUST.