2.4 Le parallélisme implicite
2.4.5 Solutions spécifiques à un domaine
Nous avons donc vu que les solutions générales de parallélisme implicite sont unique-ment spécifiques aux types de conteneurs utilisés, ce qui peut limiter les optimisations du programme parallèle. Les solutions à patrons de parallélisme sont, quant à elles, spéci-fiques aux types de conteneurs mais aussi aux types de patrons utilisés, ce qui augmente les possibilités d’optimisations pour le problème posé. Dans cette dernière partie, nous allons voir le niveau d’abstraction et de spécificité le plus haut qui est proposé dans les so-lutions de parallélisme implicite pour le calcul scientifique. Dans ce cas, la solution, qu’elle soit une bibliothèque, un framework ou un langage dédié (noté DSL), est spécifiquement implémentée pour un problème spécifique et propose des optimisations de performances dues à cette spécificité, qu’on ne pourrait donc pas retrouver dans les solutions plus géné-rales. La définition de “spécifique” peut être très variée. Par exemple, STAPL peut être vu comme un langage dédié à la programmation par conteneurs parallèles. Toutefois, nous rattacherons ici, et dans le reste de cette thèse, une solution dite spécifique (de type DSL, bibliothèque etc.) à une solution spécifique au calcul scientifique. Le domaine du calcul scientifique reste un domaine très vaste, même si il est beaucoup plus spécifique que les domaines traités par STAPL, PBGL ou les squelettes algorithmiques. Pour cette raison, de nombreuses solutions spécifiques ont été mises au point pour divers sous-problèmes du calcul scientifique. Certaines solutions sont plus spécifiques que d’autres, tout le pro-blème étant de trouver le niveau d’abstraction idéal pour l’utilisation qui sera faite du langage.
d’abord noter ScaLAPACK [19] qui est une bibliothèque haute performance pour les calculs de l’algèbre linéaire, implémentée pour les architectures parallèles à mémoire distribuée. On peut ensuite noter FFTW [55], pour le calcul parallèle de la transformée de Fourier discrète, et donc notamment pour des problèmes de traitement du signal. Ce DSL est implémenté pour des architectures à mémoire partagée et distribuée. SPIRAL [104] est, quant à lui, un DSL plus récent permettant, de façon plus générale que FFTW, d’effectuer des traitements du signal numérique.
Dans cette thèse, nous nous intéressons plus particulièrement à la résolution des EDP par des méthodes numériques basées sur des maillages, et donnant lieu à des schémas numériques explicites. Nous nous intéressons donc aux problèmes stencils pour tout type de maillages, et nous allons évoquer avec plus d’attention, dans le reste de cette section, les DSL, bibliothèques et frameworks spécifiquement développés pour ce type de calculs que l’on peut appeler plus généralement des DSS pour Domain Specific Solutions. 2.4.5.1 EDP et EDO sur maillages structurés
Commençons par évoquer les solutions de parallélisme implicite spécifiques au calcul de type stencil sur les maillages structurés. Il en existe en très grand nombre, et il ne s’agit pas ici d’une liste exhaustive de ces solutions mais des quelques travaux qui pa-raissent proches des solutions présentées dans cette thèse. Notons tout d’abord l’une des solutions les plus utilisées et les plus connues du monde de la simulation scientifiques, PETSc [10–12]. PETSc est une solution très vaste qui permet d’écrire des applications scientifiques, modélisées par des EDP, en parallèle. Cette solution est composée d’ou-tils permettant d’effectuer des opérations sur des vecteurs et des matrices, de solveurs d’équations linéaires et non linéaires, mais également d’outils graphiques permettant la visualisation des résultats de l’application. PETSc est implémenté pour les architectures à mémoire partagée CPU et GPU grâce aux modèles pthreads, CUDA et OpenCL, pour les architectures à mémoire distribuée, grâce à l’utilisation de MPI, et pour les architectures à mémoire hybrides aux travers des associations MPI-pthreads et MPI-GPU. PETSc est basé sur un ensemble de structures de données distribuées et sur un ensemble de fonctions ou routines spécialisées pour ce type de traitements. PETSc est donc identifiable à une bibliothèque sur conteneurs, tout comme STAPL ou PSTL, mais dont les interfaces et les algorithmes sont spécifiques au traitement des EDP. Nous pouvons également noter la bibliothèque spécifique Trilinos [68] qui est très proche de PETSc.
Nous pouvons également noter des solutions spécifiques plus récentes, comme par exemple le framework développé à Berkeley permettant de générer automatiquement un code parallèle, adapté à l’architecture à mémoire partagée et au matériel utilisé (dit auto-tuned ), uniquement à l’aide de l’expression d’un stencil en Fortran [74]. Dans cette même famille de framework auto-tuned, on peut également noter PATUS [36] qui génère du code parallèle CPU et GPU à partir de l’expression d’un stencil et d’une stratégie de parallélisation. PATUS évalue ensuite la meilleure parallélisation pour le matériel utilisé. Évoquons également Panorama [86] qui utilise des techniques particulières pour minimiser les défauts de cache, et Pochoir [116] qui permet la définition de stencils à n dimensions en C++. Physis [89] ne propose pas de solution auto-tuned mais permet lui aussi de
2.4. Le parallélisme implicite 55
définir une expression stencil à l’aide d’un DSL, et d’en produire automatiquement des applications parallèles MPI et CUDA.
2.4.5.2 EDP sur maillages non-structurés
De nombreuses solutions de parallélisme implicte, spécifiques aux calculs de type stencil, sont donc disponibles pour les maillages structurés. Lorsque le problème des maillages non-structurés est abordé, les outils se font plus rares, mais il en existe égale-ment. Nous pouvons, tout d’abord, évoquer le plus ancien d’entre eux, OP2 [59,60,94]. OP2, développé à l’université d’Oxford, est une révision du framework OPlus [23], initié en 1993, qui permettait d’écrire des applications basées sur un maillage non-structuré et sur la méthode des éléments finis. OPlus a notamment été utilisé pour paralléliser, en 1995, une simulation d’écoulement des fluides non visqueux sur un maillage complexe représentant un avion [45]. OPlus était implémenté pour les architectures à mémoire distribuée et implémenté en MPI. OP2 est une version plus moderne et plus récente de OPlus qui est implémentée pour les architectures à mémoire partagée CPU et GPU. Le framework OP2 charge l’utilisateur de quatre parties : (1) définir des ensembles d’éléments qui vont définir les éléments du maillage, (2) définir des liens entre ces ensembles pour former le maillage, (3) définir des données sur les ensembles, et enfin (4) implémenter des opérations sur les ensembles d’éléments. Il est ainsi possible de définir un maillage non-structuré de toute forme, ainsi que sa topologie. Le framework dispose d’un compilateur permettant de transformer le code OP2 en un code C++, qui pourra à son tour être compilé. Le DSL Liszt [50] permet également de coder des simulations sur maillages non-structurés en parallèle. Toutefois, le niveau d’abstraction proposé à l’utilisateur est légèrement différent. En effet, le niveau d’abstraction de OP2 est plus proche du niveau d’abstraction des squelettes algorithmiques puisque l’utilisateur n’a pas à définir ses boucles, alors que Liszt permet de rester plus proche d’un code séquentiel avec la gestion des boucles par l’utilisateur. Le langage Liszt est une sous-partie du langage de programmation Scala [99], et utilise une version modifiée de son compilateur. Liszt supporte une implémentation MPI, OpenMP et CUDA/OpenCL.
Dans une solution de parallélisme implicite spécifique, comme celles qui ont été évo-quées ici, il est nécessaire de doser convenablement le niveau de spécificité de la solution. D’une part, si le niveau de spécificité est trop important, cela peut nuire au nombre d’utilisateurs. D’autre part, et à l’inverse, si le niveau de spécificité est trop faible, la solution peut s’avérer trop généraliste et risque de ne pas répondre aux attentes des utili-sateurs. Toutefois, en trouvant un niveau de spécificité adéquat, ces solutions sont souvent celles qui procurent les meilleures performances, et la plus grande notoriété auprès des utilisateurs non-informaticiens.