Iut paul Sabatier Département Informatique 31400 toulouse
Yüklə 112,79 Kb.
|
- Bu səhifədəki naviqasiya:
- 1 Présentation du contexte professionnel
- Moyens mis à disposition
- 1.3.1 Horaires et conditions de travail
- 2 Description du travail effectué
- 2.1.1 Présentation de la console
- 2.1.2 Préparation de la console
- 2.1.2.1 Choix d’un système d’exploitation
- 2.1.2.2 Installation de YellowDog Linux
- 2.1.2.3 Configuration post-installation
- 2.2 Premiers pas avec le CELL Broadband Engine SDK
- 2.2.1 Structure d’un programme codé pour le CELL
- 2.2.2 Programmation parallèle
- 2.2.3 Programmation vectorielle
- 2.3 Portage du projet Ubicus vers la PlayStation 3 ®
- 2.3.1 Concepts mathématiques
- 2.3.2 Présentation d’Ubicus
- 2.3.3 Analyse de l’existant
- 2.3.4 Portage vers la PlayStation 3 ®
- 2.3.4.3 Architecture du programme
- 3 Résultats obtenus 3.1 Résultats sur Ubicus
- 3.2 Résultats sur la PlayStation 3 ® en tant que calculateur scientifique et perspectives futures
RAPPORT DE STAGEPlaystation 3® et calcul scientifique 
RAPPORT DE STAGEPlaystation 3® et calcul scientifique Encadrants : M. Abdel-Kaddous Taha & M. Pascal Acco LATTIS 135, Avenue de Rangueil 31077 Toulouse Cedex 4
Je tiens à remercier aussi M. Pascal Acco pour son aide sur le développement d’Ubicus, ainsi que toute l’équipe du LATTIS pour son accueil chaleureux au sein de leur équipe de recherche. Enfin, je remercie toute l’équipe pédagogique de l’IUT de Rangueil pour l’enseignement qu’ils m’ont prodigué tout le long de ces deux dernières années.
Table des matièresIntroduction 7 1 Présentation du contexte professionnel 8 1.1 Présentation du LATTIS 8 1.2 Moyens mis à disposition 8 1.3 Emploi du temps 9 1.3.1 Horaires et conditions de travail 9 1.3.2 Découpage des taches – diagramme de Gantt 9 2 Description du travail effectué 10 2.1 Préparation de la console PlayStation 3® 10 2.1.1 Présentation de la console 10 2.1.2 Préparation de la console 12 2.2 Premiers pas avec le CELL Broadband Engine SDK 14 2.2.1 Structure d’un programme codé pour le CELL 15 2.2.2 Programmation parallèle 15 2.2.3 Programmation vectorielle 17 2.3 Portage du projet Ubicus vers la PlayStation 3® 19 2.3.1 Concepts mathématiques 19 21
2.3.2 Présentation d’Ubicus 21 2.3.3 Analyse de l’existant 22 2.3.4 Portage vers la PlayStation 3® 22 3 Résultats obtenus 27 3.1 Résultats sur Ubicus 27 3.2 Résultats sur la PlayStation 3® en tant que calculateur scientifique et perspectives futures 27 Bilan personnel 28 Bibliographie 29 IntroductionL’informatique est un univers qui se caractérise par une évolution constante, et extrêmement rapide. Si l’énoncé de Gordon Moore prédisant que la puissance de calcul des micro-processeurs double tous les 2 ans date de 1965, il semble qu’il soit toujours d’actualité. Aujourd’hui, cette évolution n’est cependant plus propulsée par les mêmes motivations qu’à l’époque de Moore. En effet, les grands industriels du « hardware » n’ont plus pour clients principaux les physiciens et les mathématiciens, mais les adeptes de jeux vidéo. Ainsi, on trouve à l’intérieur de la console de jeux PlayStation 3® de Sony, commercialisée depuis mars 2007 en Europe, un micro-processeur bénéficiant de toutes les dernières technologies : sans aucun doute l’un des plus puissants accessible au grand public à ce jour. Depuis deux ans, plusieurs équipes de physiciens, mathématiciens et bien sur informaticiens travaillent sur différents projets visant à utiliser cette incroyable puissance de calcul. Gaurav Khanna, astrophysicien au MIT, travaille par exemple depuis un peu plus d’un an sur un projet de simulation de trous noirs : en connectant et en faisant travailler ensemble seulement 16 PS3, il développe une puissance de calcul comparable à celle de 400 ordinateurs personnels. Le stage que j’ai effectué au LATTIS a été proposé par M. Abdel-Kaddous Taha. C’est lui qui a eu l’idée de mener un projet similaire au LATTIS, dans les locaux de l’INSA : utiliser la puissance de calcul d’une console de jeux pour effectuer rapidement des calculs qui auraient demandé des jours à des ordinateurs personnels classiques. Parmis tous les secteurs où l’informatique a sa place, c’est la recherche qui m’a toujours le plus attiré. De plus, ayant déjà une expérience personnelle dans les manipulations et utilisations « exotiques » de matériel informatique en tous genres, le sujet m’a immédiatement passionné. Ce rapport expose les différentes étapes de ce projet. Dans une première partie, sont abordés les points concernant la mise en place de l’environnement de travail nécessaire pour l’utilisation d’une PlayStation 3® comme calculateur scientifique. Dans une deuxième partie, sont ensuite exposés les différents logiciels qui ont été produits sur la console, et les résultats obtenus lors de leur exécution.
Le contexte dans lequel s’est déroulé ce stage comporte une particularité essentielle par rapport à la plupart de ceux proposés par l’IUT Informatique de Paul Sabatier. Il n’a pas eu lieu dans une entreprise, mais dans un laboratoire. Il est important de comprendre les implications de cette différence afin de pouvoir comprendre les méthodes et résultats décrits dans la suite de ce rapport. En effet, le but principal du stage n’aura pas été la production de logiciel visant à être commercialisé, et devant donc être fonctionnel, rentable, et productif. Bien que le travail effectué ait bien entendu un intérêt applicatif direct pour les recherches de M. Taha et d’autres membres du LATTIS, l’objectif parallèle d’un tel stage est celui de la recherche et de l’investigation scientifique.
Le LATTIS a été créé en 2007 par regroupement de deux équipes de recherche : l’ICARE de l’Université Toulouse 2 et le LESIA de l’INSA Toulouse. L'objectif était de maintenir des activités de recherche au sein des deux établissements par le biais de l'existence d'équipes d'accueil dans les locaux du DGEI de l'INSA et de l'IUT de Blagnac. Cela a également permis de mettre en place un laboratoire de taille plus conséquente dans le domaine des STIC de l'Université de Toulouse. Le LATTIS est actuellement composé de trois groupes : « Systèmes dynamiques » (SID), « Systèmes embarqués critiques » (SEC), et « Systèmes communication sans fil » (SCSF). Le travail effectué durant ce stage s’ancre dans celui du groupe « Systèmes dynamiques », qui étudie la dynamique complexe des systèmes non linéaires et la commande de ces systèmes. Les applications de la commande sont par exemples les robots à muscles artificiels, les moteurs électriques, etc. Des applications de la dynamique chaotique des systèmes aux télécommunications et aux transmissions sécurisées sont également étudiées. Les besoins conséquents de ce type de recherche en puissance de calcul justifient la nature du stage.
L’INSA a fourni tout le matériel nécessaire à la conduite d’un tel stage : prêt d’un ordinateur personnel qui a servi à la navigation sur internet et à la rédaction de rapports journaliers, et achat d’une console PlayStation 3®, qui m’a été remise en début de stage dans son emballage d’origine. Un clavier et une souris USB, nécessaires à l’utilisation de la PlayStation 3® comme calculateur, ont également été fournis. 1.3 Emploi du temps1.3.1 Horaires et conditions de travailLe stage a été effectué dans les locaux du LATTIS, situés sur le campus de l’INSA Toulouse. Les horaires, 8h30 à 11h45 et 13h30 à 17h30, sont restés fixes tout le long du stage. 1.3.2 Découpage des taches – diagramme de GanttLe travail fourni peut être vu en 2 grandes phases distinctes. La première était de préparer un environnement de travail adéquat : avant de pouvoir utiliser une console de jeux pour du calcul scientifique, il fallait y installer et y configurer un système d’exploitation, ainsi que divers outils et logiciels indispensables dont le descriptif est donné dans la partie 2.1 de ce rapport. La deuxième phase était d’utiliser cet environnement de travail, c'est-à-dire d’y produire du code source et de le faire exécuter par la machine, et d’en tirer des résultats en termes de gains sur la puissance de calcul. 
Figure 1 : Diagramme de gantt global du stage 2 Description du travail effectué2.1 Préparation de la console PlayStation 3®La PS3 est à l’origine conçue et commercialisée pour être une console de jeux. C’est pourquoi, bien qu’il soit possible de l’utiliser à des fins de calcul scientifique et de recherche, une phase de préparation, de « configuration » de la console est nécessaire. 2.1.1 Présentation de la consoleAvant de présenter les détails de cette phase de configuration, voici une présentation succincte des composants de la PS3. Comme dans toutes les consoles de jeux « next gen » (dernière génération), on y retrouve la plupart des composants d’un ordinateur personnel « classique »
Cette quantité relativement faible de mémoire vive se révèle être une limite lors d’un usage de la console à des fins scientifiques.
Malheureusement, il est impossible d’accéder aux ressources de cette carte graphique. On peut cependant utiliser la mémoire vive graphique de plusieurs façons, tel que décrit dans la section 2.1.2.3.
Seuls 70 Go sont réellement utilisables pour exploitation de la console.
Après configuration, permet le branchement de la console sur n’importe quel réseau « classique » où elle est vue comme n’importe quel autre ordinateur.
Ce dernier point est le plus intéressant. C’est ce processeur, conçu en collaboration par IBM, Sony et Toshiba, qui donne à la PlayStation 3® tout son intérêt. Le CELL est un processeur multi-cœur basé sur une nouvelle architecture : un cœur principal, appelé PPE (Power Processing Element), accompagné de 8 cœurs « esclaves », appelés SPE (Synergistic Processing Element). Le PPE se trouve être basé sur l’architecture Power PC, version 64 bits (ppc64). C’est cette particularité qui permet d’utiliser la PS3 autrement que comme simple console de salon. En effet, tout système d’exploitation prévu pour Power PC se trouvera être compatible avec la console. 
Figure 2 : Représentation schématique du processeur cell Une telle architecture présente de nombreux avantages en terme de performances : chaque cœur étant indépendant, il est possible d’exécuter simultanément jusqu’à 9 instructions. De plus, les SPE ne sont pas des processeurs « classiques », scalaires, mais des unités de calcul vectorielles. Ils sont capables d’effectuer l’opération vecteur_A + vecteur_B (vectoriel) au lieu de A + B (scalaire).
Quelques inconvénients accompagnent cependant cette puissance de calcul. En effet, il est de la charge du programmeur de répartir équitablement le travail entre les différents cœurs (on parle de parallélisation), et de modifier son code pour que les opérations scalaires (a+b) deviennent des opérations vectorielles ({A, A, A, A} + {B, B, B, B}) (on parle de vectorisation). 2.1.2 Préparation de la consoleEn sortie d’usine, la console PlayStation 3® est équipée d’un logiciel de base permettant à l’utilisateur de lancer un jeu vidéo, écouter de la musique, surfer sur le web, etc. Ce logiciel, qu’on qualifie de « firmware », n’est rien d’autre qu’un système d’exploitation minimaliste. La première étape de préparation consiste en l’installation d’un système d’exploitation plus conséquent et plus permissif. Cette manipulation est cependant beaucoup plus simple qu’elle n’y parait : Sony a prévu cette éventualité, et dans le menu d’options du firmware standard apparait un choix « Installer un autre OS ». Une fois mise en route, l’installation ressemble donc beaucoup à une installation classique, sur ordinateur personnel. 2.1.2.1 Choix d’un système d’exploitationL’architecture particulière du processeur CELL permet théoriquement l’installation sur la PS3 de tout système compatible PowerPC 64. Or, la plupart des distributions linux, BSD, et même Microsoft Windows, se déclinent en une version optimisée pour cette architecture. Il a donc été important de choisir le système le plus adapté à nos besoins. Il s’est cependant avéré impossible de lancer l’installation de la plupart des distributions essayées (Debian Linux, Gentoo Linux, Ubuntu Linux …), à cause de problèmes sur le chargeur de démarrage, ou « bootloader ». Le détail des différents essais effectués et des problèmes rencontrés est consultable en annexe. Le choix final s’est donc porté sur la distribution YellowDog Linux, dont l’avantage est d’être conçue et totalement optimisée pour une installation sur PlayStation 3®. 2.1.2.2 Installation de YellowDog LinuxTous les détails de l’installation sont joints à ce rapport en annexe. A la fin de la procédure, la PS3 démarre automatiquement sous YellowDog Linux et peut être utilisée comme tout ordinateur personnel équipé de cette distribution.
Après installation de Linux, la PlayStation 3® requiert encore diverses optimisations et configurations avant de pouvoir être utilisée comme calculateur scientifique.
La carte Ethernet de la PS3 se configure comme sur n’importe quel ordinateur personnel (détail en annexe)
Divers programmes inutiles ont été supprimés, afin de libérer de l’espace mémoire (détail en annexe)
Redirection de la mémoire de la carte graphique vers une zone de mémoire SWAP
Activation des Huge TLB Pages (mémoire paginée) et optimisations fines du noyau (détail en annexe)
Ce dernier point est le plus important. Le CELL BE SDK, téléchargeable gratuitement sur le site officiel d’IBM, est composé d’une suite d’outils, dont certains sont indispensables à l’exploitation de la pleine puissance du processeur CELL. On y trouve principalement les compilateurs pour PPE et SPE, les bibliothèques de fonctions permettant d’appeler et d’effectuer des calculs vectoriels sur ces derniers, ainsi qu’une documentation complète. 2.2 Premiers pas avec le CELL Broadband Engine SDKUne fois la PlayStation 3® entièrement transformée en « supercalculateur scientifique », la première étape a été de prendre en main le CELL BE SDK : comprendre l’utilisation des différents compilateurs, le rôle des bibliothèques, mais surtout les principes de base de la programmation parallèle et de la programmation vectorielle. De part son architecture PPE « maître » et SPE « esclaves », le processeur CELL est cependant capable d’exécuter du code « classique », en ne faisant travailler que le PPE, qui est alors utilisé comme un processeur Power PC standard. Bien entendu, ce mode de fonctionnement n’exploite pas la pleine puissance de la console, et ne mène qu’à des résultats médiocres.
Le PPE effectue correctement les opérations d’addition et d’affichage. Les SPE restent cependant inactifs. Il est possible de tirer profit de cette particularité lorsqu’on débute en programmation sur le processeur CELL. Un code scalaire simple peut être utilisé comme support de départ, avant d’être étape par étape découpé, parallélisé, vectorisé, etc … Les différents aspects de la programmation pour processeur CELL sont ainsi abordés les un après les autres, avec des résultats en terme de gains de performance qu’il est possible de visualiser progressivement.
La construction d’un programme exécutable par le processeur CELL est relativement complexe. Sans entrer ici dans les détails de ce processus, il est important d’en citer les éléments majeurs : 
Figure 3 : Schema de compilation pour le processeur cell Le SPE et le PPE ont chacun un compilateur différent. Cela induit que pour un programme doivent être créé au moins 2 fichiers de code source : un fichier ppe.c, et un fichier spe.c. Ces deux fichiers sont compilés séparément, par deux compilateurs différents (« SPE compiler » et « PPE compiler » sur le schéma), avant d’être liés ensembles (par le « PPE linker »). 2.2.2 Programmation parallèleLes programmes conçus pour processeurs multi cœurs ont une structure très différente des programmes conçus pour processeurs classiques. Il est de la charge du programmeur de diviser la charge de travail et de la répartir équitablement entre chaque cœur du processeur. On qualifie ce processus de « parallélisation ». Plusieurs problèmes se posent cependant rapidement au programmeur qui cherche à paralléliser son code. Tout d’abord, il n’est pas toujours possible de diviser la charge de travail. Par exemple, il est impossible d’optimiser la portion de code donnée en exemple 1 : plusieurs cœurs ne peuvent pas travailler ensembles sur la même opération A + B, et la charge de travail n’est pas divisible (on parle d’opération atomique). Le second problème n’est pas inhérent à la programmation parallèle mais à l’architecture particulière du CELL. Si le PPE, comme tout processeur, a accès à la mémoire vive de la machine, les choses sont différentes pour les SPE. Ceux-ci doivent passer par des canaux de communications spécifiques pour récupérer le contenu de variables stockées dans la RAM. Ces canaux étant coûteux en termes de performances, il est préférable de ne les utiliser qu’au minimum. Une fois ces deux objectifs assimilés, on peut reprendre des programmes classiques et les paralléliser pour en optimiser les performances. Pour ce faire, même si il est possible de créer son propre modèle de programmation parallèle, le plus simple est d’utiliser et d’adapter un modèle déjà existant. Il en existe plusieurs (modèle en décharge fonctionnelle, modèle en flux, modèle en extension de matériel …), présentant chacun leurs avantages et leurs inconvénients. Mon choix s’est arrêté sur un modèle de décharge fonctionnelle. Il présente un bon rapport entre simplicité de mise en œuvre et performances à l’exécution.
Le PPE joue ici le rôle de « contrôleur ». En début de programme, il s’assure de la répartition des taches entre les SPE, et leur envoie a chacun les données qui leur sont nécessaires. Les SPE se chargent ensuite d’effectuer les calculs sur les données qu’ils ont reçus, puis ils renvoient leurs résultats au PPE, qui les reçoit et en tire des résultats finaux. Ce modèle permet de minimiser les communications entre PPE et SPE et inter-SPE (il n’y a communication qu’en début et en fin de programme), et de répartir équitablement la charge de travail (il suffit de s’assurer que les SPE reçoivent chacun une quantité équivalente de données à traiter). Le code fourni en annexe a été réalisé afin d’assimiler les concepts de parallélisation, et de m’entrainer à la mise en place de ce modèle. 2.2.3 Programmation vectorielleMême si PPE comme SPE sont capables d’effectuer des opérations scalaires, le seul moyen d’exploiter la pleine puissance des SPE est de les faire travailler sur des opérations vectorielles : on parle de vectorisation. L’objectif de la vectorisation et de rassembler les données judicieusement, puis d’effectuer toutes les opérations nécessaires en utilisant les fonctions de calcul vectoriel fournies par les bibliothèques d’IBM. Parmis ces fonctions, on trouve spu_insert() et spu_extract(), qui permettent d’ajouter ou d’extraire un élément à un vecteur, puis un jeu complet d’instructions arithmétiques (spu_add(), spu_mul(), spu_sub(), permettant respectivement d’effectuer des additions, multiplications et soustractions), de comparaison (isless(), isequal() …), etc. Les opérations d’insertion et d’extraction étant relativement lentes, l’objectif est de ne les utiliser qu’un minimum. Même si cela n’est pas toujours possible, un code vectorisé « proprement » doit dans l’absolu avoir la structure suivante : 1 – création des vecteurs (insertion des éléments) 2 – opérations sur les vecteurs, sans ajouter ou supprimer d’élément (sans « casser » les vecteurs) 3 - récupération et affichage des résultats (extraction des éléments)
On peut voir que le code scalaire a besoin que le processeur effectue 4*4 = 16 additions, tandis que le code vectoriel n’en a besoin que de 4. Le code fourni en annexe a été réalisé afin d’assimiler le concept de vectorisation et de m’entrainer à l’utilisation des bibliothèques de calcul vectoriel. 2.3 Portage du projet Ubicus vers la PlayStation 3®Plusieurs chercheurs du LATTIS travaillent sur l’étude numérique de récurrences non linéaires. Ces études passent par l’analyse de graphiques, qui représentent les plans paramétriques, les plans de phase, etc … Ces concepts ne sont pas abordés dans le cadre de l’IUT informatique. L’une des difficultés du stage a donc été en premier lieu d’en comprendre au moins les principes de base afin de pouvoir travailler sur Ubicus. Il ne s’agit pas ici d’expliquer de manière exhaustive ces principes, mais simplement de comprendre l’utilité du logiciel.
Nous considérons des récurrences d'ordre un ou deux, qui sont de la forme (xn+1=f(xn, yn, Λ), yn+1=g(xn, yn, Λ)), qui peuvent être linéaires ou non linéaires. Nous avons choisi pour exemple la récurrence de Myrberg (récurrence d’ordre 1) : xn+1 = a * xn² + b « a » et « b » sont les paramètres réels de la récurrence. On peut constater qu’au bout d’un certain nombre d’itérations, les valeurs peuvent tendre vers un point fixe : on est en présence d’un cycle d’ordre 1. Il peut aussi y avoir apparition d’une périodicité, le point x retrouvant les mêmes valeurs au bout de n itérations : on parle alors de cycle d’ordre n. Voici représentés ces phénomènes sur le plan de phase, pour une récurrence d’ordre 2 :
On constate cependant que les points construisent une forme géométrique particulière : c’est ce qu’on appelle l’attracteur étrange. Voici maintenant une représentation en plan paramétrique, résultat d’un balayage de valeurs :
Le projet Ubicus est divisé en 2 programmes. Le premier (initialement baptisé « statique ») a pour rôle d’effectuer le balayage proprement dit. A partir d’une récurrence et des paramètres amin, amax, bmin et bmax, « statique » construit un fichier « sortie.bin » contenant pour chaque point (a, b) les informations nécessaires à la représentation du plan paramétrique (nombres de divergences pour le couple (a,b), ordre de ces divergences, etc). Le second programme, « flexouille », est chargé de construire le graphique à partir du fichier sortie.bin. 
Figure 7 ; Schéma de fonctionnement d’ubicus C’est bien entendu le programme « statique » qui nécessite le plus de puissance de calcul. Dans sa version initiale, il était basé sur l’architecture « MPI », qui permet de faire fonctionner plusieurs ordinateurs du même réseau sur un même programme, afin d’en améliorer le temps d’exécution. Ubicus faisait donc un candidat idéal pour un portage vers la PlayStation 3®. Il allait permettre l’obtention de résultats sur les performances réelles de la console, en comparant le temps d’exécution à celui obtenu lorsqu’on l’exécute avec 5, 10 ou 20 ordinateurs personnels, et en cas de gain il ferait gagner beaucoup de temps aux chercheurs du LATTIS en leur permettant d’obtenir leurs représentations plus rapidement. 2.3.3 Analyse de l’existantDans la version qui m’a été fournie comme base de travail, « statique » fonctionne grâce à « MPI », un protocole permettant de faire travailler plusieurs ordinateurs sur un même programme. L’ordinateur sur lequel on lance l’exécution du programme est le « maître ». Il se charge de découper le plan paramétrique en plusieurs parts, et il distribue ensuite ces parts aux ordinateurs « esclaves », qui effectuent les calculs d’itération, complètent les informations nécessaires pour chaque point (a,b), puis renvoient les résultats à l’ordinateur maitre qui se charge de les ordonner dans le fichier sortie.bin.. Le code source de cette version initiale de statique est fourni en annexe.
A cause de l’architecture très particulière du processeur CELL, la seule solution pour porter Ubicus vers la PS3 était de construire une nouvelle version du programme à partir de zéro. 2.3.4.1 ParallélisationComme on l’a vu, l’enjeu majeur de la réalisation d’un programme pour le processeur CELL est l’adoption d’une bonne méthode de parallélisation. Cependant, l’ancienne version de « statique » utilisait déjà un modèle de programmation parallèle pour MPI, similaire à celle d’un programme pour CELL qui utiliserait le modèle de parallélisation par décomposition fonctionnelle. J’ai donc choisi d’utiliser le modèle existant et de simplement le « traduire » en fonctions spécifiques au processeur CELL : le PPE devient l’ordinateur maitre, et les SPE prennent la place des ordinateurs esclaves. Le fichier ubicus.c, qui contient le code à exécuter par le SPE, contient donc les instructions nécessaires pour effectuer le découpage du plan paramétrique, et pour lancer les SPE en leurs fournissant les données nécessaires.
Le rôle de chaque SPE, dont le code source est situé dans le fichier ubicus_spu.c, est le même que celui des ordinateurs esclaves dans la version de « statique » utilisant MPI. Pour chaque couple (a,b) de l’intervalle à traiter, on calcule 1 000 itérations de la récurrence contenue dans le fichier recu.c, puis on recherche des cycles d’ordre 1 à 15 tout en les comptabilisant.
2.3.4.2 VectorisationLe second enjeu dans la programmation pour processeur CELL est une vectorisation efficace : les données doivent être regroupées de manière judicieuse afin de minimiser le nombre d’opérations à effectuer par les SPE. Tous les calculs de récurrence doivent être initialisés, c'est-à-dire qu’une valeur aléatoire dans un intervalle choisi par l’utilisateur doit être donnée à x0 afin de pouvoir calculer par récurrence x1, x2, x3 … x1000 . Afin d’obtenir des résultats plus précis, « statique » n’utilise en réalité pas une seule, mais 20 initialisations aléatoires différentes : il y a 20 x0 différents dont les résultats individuels sont recoupés avant d’obtenir les résultats finaux. J’ai choisi d’utiliser cette donnée comme point de départ pour la vectorisation. Au lieu de 20 x0 différents stockés dans des variables scalaires, on utilisera 5 vecteurs contenant chacun 4 x0 différents. Le nombre total de calculs à effectuer est ainsi divisé par 4. Le détail de la vectorisation est visible dans le fichier ubicus_spu.c. 2.3.4.3 Architecture du programmeComme beaucoup de programmes de calcul scientifique, « statique » est en lui-même un programme relativement « simple ». Tous les paramètres sont définis avant la compilation. Le programme est ensuite exécuté à partir d’une simple commande d’appel linux, il ne demande aucune intervention de l’utilisateur, et le fichier sortie.bin est récupéré dans le répertoire d’appel du programme à la fin de l’exécution. Cependant, afin de pouvoir être utilisé de manière simple par des chercheurs, une architecture précise a été définie.
Un chercheur souhaitant utiliser Ubicus se place dans le répertoire « user ». Il tape ensuite la commande : ./install.sh nom_de_la_recurrence_au_choix Est ensuite créé de manière automatique un répertoire portant le nom de la récurrence choisi, et contenant des copies des fichiers ubicus.c et ubicus_spu.c. Il faut ensuite modifier le fichier « ubicus.h » dans lequel on entre divers paramètres (taille du plan paramétrique, précision voulue, nombre d’itérations voulues avant de rechercher des cycles …), et le fichier « spu/recu.c » dans lequel on entre la récurrence. Il ne reste plus ensuite qu’à taper la commande « make » à partir du répertoire racine de la récurrence, lancer le programme avec la commande « ./ubicus.exe », et récupérer le fichier sortie.bin dans ce même répertoire. Même si cette démarche parait complexe, Ubicus est conçu pour être utilisé par des chercheurs, supposés avoir les connaissances nécessaires pour effectuer ces manipulations (une documentation est bien évidemment fournie avec le logiciel). C’est donc la vitesse d’exécution qui est le souci principal, et cette architecture, avec aucune intervention de l’utilisateur durant l’exécution et une nouvelle compilation à chaque changement de paramètre est celle qui garantit les meilleurs résultats en termes de performances. 3 Résultats obtenus3.1 Résultats sur UbicusMalheureusement, il n’a pas été possible d’obtenir une version finale et fonctionnelle d’Ubicus. Les calculs concernant les points (a,b) sont effectués par les SPE, mais les résultats obtenus ne sont pas renvoyés vers le PPE. Cette opération nécessite en effet la mise en place d’un système de buffer (problèmes de mémoire), ainsi qu’une gestion intelligente du PPE (le PPE ne peut traiter l’arrivée que d’un résultat à la fois, et il ya a 6 SPE qui en renvoient simultanément : problème de temps réels). Les solutions à ces problèmes ont été modélisées (les schémas sont joints à ce rapport en annexe) mais le temps a manqué pour les implémenter. Certains résultats sont cependant déjà visibles. Les calculs les plus longs à effectuer pour l’ancienne version d’Ubicus étaient ceux concernant les 1 000 itérations de récurrence nécessaires sur chaque x0, avec 20 x0 pour chaque couple (a,b). Désormais, les calculs s’effectuent de manière vectorielle, soit une division par 4 du temps de calcul nécessaire. De plus, n’oublions pas que le processeur CELL remplace à lui tout seul 1 ordinateur maitre et 6 ordinateurs esclaves utilisés dans l’ancienne version.
Au-delà des résultats obtenus sur le projet Ubicus, il est important de tirer les conclusions d’un stage dont l’une des lignes directrices principales était l’étude du comportement d’un processeur CELL pour des applications scientifiques. Le premier constat que l’on doit faire est que le contrat passé par IBM, promettant qu’un processeur CELL peut calculer aussi vite que 20 ordinateurs personnels, est respecté. L’architecture proposée est cohérente, et la décomposition entre PPE « maitre » et SPE « esclaves », qui diverge de la norme où les cœurs sont « à égalité » sur les processeurs « Intel Core 2 Duo » ou « AMD X2 » offre de grandes possibilités en terme de programmation. Cependant, il est important de mettre en avant certains défauts inhérents à l’architecture de la PlayStation 3®. Tout d’abord, le fait qu’elle ne soit équipée que de 256 Mo de mémoire vive pose une limite importante pour le calcul de masse. Une seconde limite est induite par la gestion des systèmes d’exploitation par la console. Même après installation, linux, ou tout autre système d’exploitation Power PC compatible qui pourrait être installé, n’est jamais qu’émulé par un système d’exploitation « racine » (le GameOS, « firmware » de la console). Cela provoque une considérable perte de ressources, avec principalement un accès restreint à la carte graphique (restriction désirée par Sony® pour des raisons commerciales). Enfin, les bibliothèques fournies par IBM permettant l’utilisation des SPE est clairement orientée vers une utilisation par des concepteurs de jeux vidéos plus que par des chercheurs en systèmes dynamiques ! Malgré les faiblesses que peut montrer la PlayStation 3®, son utilisation dans le cadre du projet Ubicus reste sans aucun doute une grande avancée. De plus, les possibilités d’évolution sont encore nombreuses : Ubicus pourrait facilement générer des représentations de plans de phases en plus des représentations de plans paramétriques. Certains projets ont déjà été menés dans d’autres facultés où les PlayStation 3® sont connectées en réseau, et utilisées ensembles grâce à MPI : cette technologie pourrait être adoptée pour Ubicus, en divisant simplement une deuxième fois le plan paramétrique pour donner à chaque console une plage de calcul à effectuer, avant d’affecter à chaque SPE une « sous-plage » de calculs. Bilan personnelCe stage aura été pour moi une expérience extrêmement riche, tant sur les plans techniques que professionnels. Concernant l’aspect technique, j’ai acquis énormément de compétences en 3 mois de stage : approfondissement de mes connaissances dans le système d’exploitation linux, dans la programmation en langage C en général, formation à l’utilisation du CELL BE SDK, initiations aux concepts de programmation vectorielle et parallèle … Ce dernier point m’a particulièrement passionné : il est clair que la tendance actuelle dans le monde de l’informatique est à la fabrication de processeurs de plus en plus massivement multi-cœurs, le CELL n’étant que le premier d’une longue série. La programmation parallèle est donc sans aucun doute l’un des enjeux majeurs de l’informatique de demain. Professionnellement, ce stage m’a aussi énormément apporté. Le monde de la recherche m’intéresse depuis longtemps, et j’attendais avec impatience une immersion dans un laboratoire comme celui du LATTIS. Cette expérience a été très positive, et je suis aujourd’hui conforté dans mon projet de poursuite d’étude et de carrière dans cet univers, peut-être différent de celui que l’on trouve en entreprise. J’ai de plus eu la chance d’être encadré de manière irréprochable, par des responsables qui ont su me guider tout en m’aidant a acquérir une autonomie nécessaire à ce type de projet. Ce stage aura donc été pour moi une expérience positive à tous les niveaux, et donne une excellente conclusion à mes deux années passées en IUT informatique. BibliographieSCOP 3 - A Rough Guide to Scientific Computing On the PlayStation 3 Innovative Computing Laboratory University of Tennessee Knoxville May 11, 2007 Cell Broadband Engine - Programming Handbook International Business Machines Corporation, May 12, 2008
International Business Machines Corporation, February 27, 2008
International Business Machines Corporation, Cell Broadband Engine – Programmer’s Guide International Business Machines Corporation, Yüklə 112,79 Kb. Dostları ilə paylaş:
|
