Soutenance mémoire
Intérêt des systèmes multiprocesseurs hétérogènes
Même si les plateformes matérielles multiprocesseurs hétérogènes ne bénéficient pas encore du support logiciel qu’elles méritent, elles trouvent aujourd’hui leur place dans le domaine de l’embarqué et plus récemment également dans le domaine des ordinateurs classiques.
Processeurs spécialisés et processeurs généralistes
On peut distinguer les processeurs généralistes qui exécutent des programmes classiques, généralement écrits de manière portable dans un langage de programmation de haut niveau, et les processeurs partiellement ou complètement spécialisés qui exécutent du code écrit dans un langage spécifique. Ce développement, souvent effectué en assembleur, permet cependant d’accélérer l’exécution d’une certaine classe d’algorithmes pour lesquels ces processeurs sont conçus. Parmi les processeurs généralistes, on peut citer les principales architectures suivantes : x86, ARM, Mips, PowerPC et Sparc.
Les processeurs spécialisés peuvent être de différents types ; ils possèdent généralement un jeu d’instructions orienté traitement de données, comportant des instructions SIMD qui opèrent le même traitement sur plusieurs données en parallèle, des instructions effectuant des opérations arithmétiques complexes en virgule fixe ou en virgule flottante, ou des instructions plus spécialisées encore. C’est le cas des processeurs de signal numérique (DSP) comme ceux de la famille ST200 proposés par STMicroelectronics ou ceux de la famille TMS320 proposés par Texas Instruments. La frontière entre ces deux classes de processeurs devient parfois floue avec l’apparition des extensions du jeu d’instructions des processeurs généralistes. Les opérations en virgule flottante sont aujourd’hui intégrées à part entière dans les processeurs haute performance et des extensions diverses se développent également ; ainsi à titre d’exemples pour les architectures citées :
– x86 : la série d’extensions MMX fournit des opérations SIMD entières sur des mots de 64 bits et la série SSE, des opérations SIMD flottantes sur des mots de 128 bits.
– ARM : l’extension NEON[7] apporte également des opérations SIMD entières et flottantes sur des mots de 128 bits.
– Mips : MDMX complète le jeu d’instructions entières, MIPS-3d accélère quelques opérations courantes des moteurs 3d, et plus récemment l’extension MIPS DSP[6] propose des opérations SIMD.
– PowerPC : l’extension Altivec[2] apporte des opérations SIMD entières et flottantes sur des mots de 128 bits.
– Sparc v9 : l’extension VIS permet de réaliser des opérations SIMD entières dans les registres généraux de 64 bits.
Si ces extensions sont monnaie courante dans les processeurs haute performance des PC, les processeurs généralistes destinés à l’embarqué n’intègrent pas nécessairement ces instructions complexes qui ont un coût important en surface de silicium et donc, en consommation. Il est important de souligner également que ces jeux d’instructions spécialisés doivent souvent être utilisés de manière explicite par les développeurs. Même si certains compilateurs peuvent, dans certains cas, générer quelques instructions SIMD à partir de langages de haut niveau, il reste difficile d’exploiter le parallélisme d’un algorithme s’il n’est pas explicitement décrit par l’implémentation.
Cas des systèmes embarqués
Les processeurs spécialisés étant capables d’exécuter certains algorithmes plus efficacement que les processeurs généralistes, les contraintes de consommation électrique dans les systèmes embarqués poussent souvent à leur utilisation, notamment pour exécuter les algorithmes coûteux de traitement du signal, multimedia ou encore cryptographiques. Le processeur généraliste étant par ailleurs souvent incontournable pour l’exécution du système de base, c’est dans l’embarqué que l’on rencontre le plus souvent des plateformes hétérogènes encore aujourd’hui.
Cas des plateformes haute performance
La recherche de performances maximales, dans les ordinateurs de bureaux et dans les serveurs de calcul, pousse également à l’utilisation de processeurs spécialisés en complément du processeur principal généraliste. On constate que les cartes graphiques des PC actuels, destinées aux applications 3d, intègrent des processeurs capables d’exécuter du code. C’est le cas des cartes graphiques à base de GPUs Nvidia ou de GPUs Ati lesquels sont programmables en C pour réaliser des opérations de calcul sur des données flottantes qui ne sont pas en rapport avec les fonctions d’affichage de la machine. Ces fonctionnalités sont aujourd’hui utilisées pour réaliser des calculs scientifiques avec un gain en performances d’un facteur de l’ordre de la dizaine par rapport au processeur central. On peut considérer que les applications qui utilisent les technologies CUDA[3] de Nvidia ou Close to Metal[9] de AMD/Ati s’exécutent sur une plateforme hétérogène constituée par le processeur principal et le processeur graphique du PC.
Processeurs simples et processeurs haute performance
Les contraintes technologiques limitant une montée en fréquence des processeurs, la tendance est à l’intégration de plusieurs processeurs sur une même puce pour répondre au besoin croissant de puissance de calcul. Cette nouvelle tendance technologique a un impact important sur le développement des applications logicielles qui doivent être programmées de manière parallèle pour tirer pleinement parti de ces nouvelles architectures. Ceci implique un effort de développement incontournable de réécriture des algorithmes implémentés de manière non parallèle, dans les applications déjà existantes. Cependant cette adaptation n’est pas toujours possible ; en effet, on constate, qu’il existe deux classes d’algorithmes :
– Les algorithmes intrinsèquement parallélisables qui peuvent être implémentés en utilisant plusieurs processus ou threads du système d’exploitation pour tirer parti des multiples processeurs.
– Les algorithmes intrinsèquement séquentiels qui ne sont parallélisables en aucun cas. Dans un système embarqué dédié à une application particulière, il est possible d’exploiter à coup sûr le parallélisme de la plateforme matérielle par des mécanismes conjoints de l’architecture matérielle et de l’application logicielle.
Sur une station de travail ou un serveur, la situation est différente :
– les algorithmes séquentiels doivent s’exécuter avec un niveau de performances correct, équivalant à celui des systèmes monoprocesseurs haute performance que l’on utilise couramment
– Les algorithmes parallélisables doivent être distribués sur un grand nombre de processeurs pour réduire les temps de calcul.
– La consommation électrique des processeurs haute performance limite leur nombre au sein d’une même plateforme ou d’une même puce.
Ce constat devrait mener à l’apparition de plateformes many-core hétérogènes où coexistent, dans la même puce, un petit nombre de processeurs haute performance et une multitude de processeurs simples généralistes ou partiellement spécialisés. L’architecture Cell[4] d’IBM, qui embarque un processeur PowerPC généraliste et 8 processeurs simples destinés au calcul et dotés d’instructions SIMD, peut être considérée comme précurseur de cette famille de systèmes.
D’autres projets de recherche s’intéressent aujourd’hui aux architectures many-core et proposent des puces intégrant des processeurs simples en nombre beaucoup plus important. C’est le cas par exemple de l’architecture TSAR [1], qui vise à intégrer un grand nombre de processeurs regroupés en clusters interconnectés par un réseau sur puce (NoC). On peut concevoir deux types de plateformes hétérogènes :
– Les architectures multiprocesseurs hétérogènes où les processeurs disposent de jeux d’instructions différents et ne peuvent en aucun cas partager le même code binaire exécutable.
– Les architectures multiprocesseurs hétérogènes où les processeurs disposent du même jeu d’instructions mais n’ont pas les mêmes architectures et complexités internes. Ces processeurs peuvent éventuellement partager le même code binaire mais cette approche n’est pas toujours retenue.
Le rôle du système d’exploitation
Le système d’exploitation joue un rôle primordial dans les architectures multi-core hétérogènes car, en plus de gérer l’attribution des ressources classiques telle la mémoire, les périphériques ou le temps processeur, il doit répartir et placer les différentes tâches logicielles sur les différents processeurs. Pour bien comprendre les enjeux du développement d’un système d’exploitation capable de s’exécuter nativement sur une plateforme multiprocesseur hétérogène, il convient d’établir la liste des services indispensables au fonctionnement d’une application parallèle sur un système multiprocesseur.
Abstraction du matériel
Les noyaux portables des systèmes d’exploitation modernes possèdent généralement une couche d’abstraction du matériel. Il s’agit d’une API interne qui propose des services d’accès spécifiques au matériel de la plateforme et du processeur. Il s’agit de la gestion des interruptions ou des accès atomiques à la mémoire par exemple. Différentes implémentations de cette API sont réalisées pour supporter les différentes plateformes et architectures de processeurs visées par le système d’exploitation. Ceci permet en principe d’éviter les modifications dans les couches hautes du système lors du portage vers une nouvelle architecture. La gestion des périphériques est en général exclue de cette API et reste réservée aux pilotes de périphériques.
|
Table des matières
Introduction
1 Problématique
1.1 Intérêt des systèmes multiprocesseurs hétérogènes
1.1.1 Processeurs spécialisés et processeurs généralistes
1.1.2 Processeurs simples et processeurs haute performance
1.2 Le rôle du système d’exploitation
1.2.1 Abstraction du matériel
1.2.2 Parallélisation des applications
1.2.3 Communication entre tâches
1.3 Les contraintes liées à l’hétérogénéité
1.3.1 Différences des mécanismes système
1.3.2 Harmonisation des structures de données
1.3.3 Incompatibilité des codes binaires
1.4 Conclusion
2 Etat de l’art
2.1 Gestion de l’hétérogénéité
2.1.1 Canaux de communication spécifiques
2.1.2 Zones de mémoire partagée contrôlées par l’OS
2.1.3 Communication par messages
2.1.4 Machines virtuelles hétérogènes
2.1.5 Langages dédiés à la parallélisation
2.1.6 Conclusion sur les solutions hétérogènes
2.2 Les différents types de noyaux d’OS
2.2.1 Séparation et modularité
2.2.2 Approche monolithique
2.2.3 Les micronoyaux
2.2.4 Les noyaux hybrides
2.2.5 Les exo-noyaux
2.2.6 Conclusion sur les architectures noyaux
3 Solutions de principe
3.1 Architecture du noyau
3.2 Les contraintes réalistes
3.2.1 Le problème de l’endianness
3.2.2 Largeur de mot
3.2.3 Différences de jeux d’instructions
3.2.4 Virtualisation de la mémoire de code
3.3 Plates-formes matérielles cibles
3.3.1 Accès atomiques
3.4 Couche d’abstraction matérielle
3.4.1 Séparation processeur et plateforme
3.4.2 Démarrage et initialisation du système
3.4.3 Accès atomiques et verrous
3.4.4 Accès aux périphériques
3.4.5 Variables globales contextuelles
3.4.6 Les types entiers
3.4.7 Les événements
3.5 Génération des fichiers binaires
3.5.1 Configuration des sources
3.5.2 Compilation
3.5.3 Edition des liens
3.6 Conclusion
Conclusion
Télécharger le rapport complet
