Modélisation et programmation d ordinateurs amorphes : de l ordinateur amorphe à la machine Blob

Transcription

1 UNIVERSITÉ PARIS 8 - VINCENNES-SAINT-DENIS U.F.R. MITSIC N attribué par la bibliothèque THÈSE pour obtenir le grade de DOCTEUR DE L UNIVERSITÉ PARIS 8 Spécialité Informatique soutenue le xx mai 2009 par Moïse Valvassori Modélisation et programmation d ordinateurs amorphes : de l ordinateur amorphe à la machine Blob Jury Patrick Greussay Président Université Paris 8 Arab Ali Chérif Directeur Université Paris 8 Hugues Berry Rapporteur Inria Raja Chatila Rapporteur LAAS-CNRS Hermann Akdag Examinateur Université Paris 6 Jacqueline Signorini Examinateur Université Paris 8

2 Résumé Nous présentons des méthodes nouvelles de configurations des ordinateurs dits amorphes qui les doteront de capacités de duplications et d évolutions. Inspirés par leurs aspects auto-organisationnels, notamment lors de leur embryogenèse, nous appliquerons nos méthodes de configurations en fonction de calculs spécialisés. Notre recherche comporte trois contributions : Un simulateur d ordinateurs amorphes. Un ordinateur amorphe est un ensemble de processeurs élémentaires statiques, spatialement distribués et communiquant sur de courtes distances de manière omnidirectionnelle avec leurs voisinages. Les éléments de calcul contiennent tous le même programme et leurs capacités de calculs et de stockages sont supposées faibles. Nous avons réalisé le simulateur d ordinateurs amorphes le plus véloce à l heure actuelle. Nous simulons ainsi des ordinateurs amorphes composés de plus de 10 6 éléments de calcul. Un langage pour la programmation amorphe bas niveau orienté aspect et composant ainsi que son compilateur. Nous appelons Tical ce langage de programmation. La programmation d un ordinateur amorphe consiste à spécialiser les éléments de calcul au début de l exécution du programme afin de distribuer les informations et la puissance de calcul. Notre approche de la programmation amorphe est inspirée de la biologie cellulaire et de la biologie du développement. Nous avons commencé par explorer un modèle multi-agents de P-systems (calcul par membranes) à l aide de la plate-forme de simulation Fungus que nous avons réalisé à cet effet. À partir des enseignements de cette expérience, nous développons Tical, notre langage dédié. Il découpe le programme en une bibliothèque de composants (réutilisables). Les différentes facettes d un programme amorphe y sont représentées par des aspects : initialisation, réaction aux messages, réaction à certains états, programme traditionnel. Le programme ainsi exprimé est compilé vers un programme C équivalent. Les algorithmes de bas niveau implémentés à l aide de ce langage sont : création de gradient, élection de leader, agrégation et propagation d informations. Trois primitives haut niveau de la machine abstraite Blob. Nous proposons une implémentation des trois primitives de la machine abstraite Blob dans notre langage. Une machine abstraite Blob est une machine parallèle abstraite s organisant spatialement pour y effectuer ses calculs. Un blob est alors 1

3 un groupe d éléments de calcul. Les blobs sont organisés hiérarchiquement et peuvent être liés entre eux. Les primitives de haut niveau que nous développons comprennent la constitution d un blob à partir d éléments de calcul dispersés, la création de canaux de communication et la duplication d un blob en deux blobs. Toutes ces implémentations sont inspirées de la biologie du développement : rupture de symétrie par des gradients, chimiotaxie et mitose. La suite du document est organisée en cinq parties. Dans le premier chapitre, nous introduisons nos objectifs ainsi que notre position dans le domaine des ordinateurs amorphes. Dans le chapitre 2, nous exposons un état de l art de la programmation amorphe et du calcul dans l espace. Le chapitre 3 présente Tical, notre langage de bas niveau orienté aspect et composant et les primitives bas niveaux. La première partie de ce chapitre présente le modèle de conception du langage ainsi que le simulateur qui exécute les programmes. Nous présentons la programmation par aspect, puis nous détaillons les aspects standards de notre langage. La présentation du modèle de composant de Tical ainsi que le processus de compilation des programmes Tical vers les simulations sont ensuite largement développés. Nous finissons ce chapitre en présentant des exemples de notre langage et la construction de primitives bas niveau couramment évoqués dans la littérature. Le chapitre 4 présente l implémentation des primitives de haut niveau Blob. Après une présentation de la machine abstraite Blob, nous présentons l implémentation de nos trois primitives : constitution d un blob, liaison de deux blobs, duplication d un blob. Le chapitre 5 présente une conclusion de l ensemble de nos contributions et propose une synthèse des perspectives faisant suite à nos travaux. 2

4 Abstract We present new methods of configurations of computers said amorphous to equip them of capabilities of duplication and developments. Inspired by their selforganizational aspects, especially during their embryonic development, we apply our methods of configurations on specialized calculations. Our research have three contributions : An amorphous computer simulator. An amorphous computer is a set of static elementary processors, spatially distributed and whose omnidirectionally communicate over short distances with their neighborhoods. All the computing elements contain the same program and their computing and storage resources are assumed low. We have build the fastest amorphous computer simulator at the moment. We simulate amorphous computers made of more than 10 6 processing elements. A low level aspect and component oriented language for amorphous programming and its compiler. We call this programming language Tical. Programming a amorphous computer is to specialize their computing elements when the program starts in order to distribute the computing power and the data. Our approach to amorphous programming is inspired by biology and cell biology development. We began by exploring a multi-agent model of P-systems (membrane computing) using the Fungus simulation platform. Learning from this experience, we develop Tical, our domain specific language. It partitions the program in a library of (reusable) components. The concerns of an amorphous program are represented by aspects : initialization, messages handling, reaction to some states, the conventional program. Tical programs compile into a equivalent C program. The low-level algorithms implemented in this language are : gradient generation, leader election, aggregation and data propagation. Three high-level primitives of the Blob abstract machine. We propose an implementation three primitives of the Blob abstract machine in our language. An Blob abstract machine is an abstract parallel machine spatially organized to perform its calculations. A blob is a group of computing elements. The blobs are organized hierarchically and may be linked. The high-level primitives are formation of a blob from dispersed computing elements, the creation of communication channels and duplication of a blob into two blobs. 3

5 All these implementations are inspired from developmental biology : symmetry breaking by gradients, chemotaxis and mitosis. The following document is organized in five parts. In the first chapter, we introduce our goals and our position in the field of amorphous computing. In Chapter 2, we present a state of the art of programming amorphous and spatial computing. Chapter 3 presents Tical, our low-level aspect and component oriented programming language and low level primitives. The first part of this chapter presents the design model of the language and the simulator that runs programs. We present the aspect oriented programming, then we detail the standard aspects of our language. The Tical component model and the process of compiling programs to Tical simulations are widely developed. We finish this chapter with examples of our language and construction of low-level primitives commonly cited in the literature. Chapter 4 presents the implementation of high-level primitives Blob. After a presentation the Blob abstract machine, we present the implementation of our three primitives : blob construction, linking of two blobs, duplication of a blob. Chapter 5 presents a conclusion of all of our contributions and proposes a synthesis of our perspectives. 4

6 Remerciements Je remercie mon directeur Arab Ali Cherif. Je remercie Raja Chatila et Hugues Berry, de m avoir fait l honneur d accepter d être rapporteurs de ma thèse, de participer au jury et de s être interessés à mes travaux. Je remercie Patrick Greussay, Jacqueline Signorini et Hermann Akdag d avoir accepter de participer à mon jury. Je remercie Nicolas Jouandeau, Isis Truck et Youcef Touati pour leurs soutiens et leurs conseils. Je remercie Frédéric Gruau de l Inria Futur de m avoir fait découvrir les Blobs, pour son accueil et son enthousiasme à toute épreuve. Je remercie Daniel Coore de la West Indies University de Kingston de m avoir accepté en postdoc et nos discussions passionnantes sur Ecoli et Tical. Je n oublie pas Jacob Beal et Jonathan Bachrach du MIT pour leurs discussions fines et enrichissantes sur la programmation amorphe. Je remercie Fadhila Drif pour son soutien indéfectible. Je remercie Marie-Solange Touzeaux pour avoir maintenu le matériel et les logiciels du laboratoire en état de marche. Je remercie également tous les 下 忍 et 中 忍 croisés dernièrement à Paris 8 :, Frédéric,, sans oublier 汪, Mira, Daouda, et. Je ne peux qu admirer leur patience infinie face à mes logorrhées. Je n oublie pas de remercier la société Oboo pour son accueil dans ses locaux et tout particulièrement Christophe, Wilfried et Jean-Philippe. 5

7 Table des matières 1 Introduction Approche Contributions Contexte De la biologie aux ordinateurs amorphes Plan de lecture État de l art Systèmes distribués Grilles de calcul Peer to Peer Multi-agents Fungus Informatique inspirée de la nature Automates cellulaires Vie artificielle Swarm intelligence Membranes Calculs dans l espace Reseaux de senseurs MGS Ordinateur à réaction-diffusion Programmation amorphe Réalisation d un ordinateur amorphe Réalisations Bas niveau Haut niveau Conclusion

8 Table des matières 7 3 Langage de programmation amorphe Modèle d ordinateurs amorphes Simulations Comparaison des performances entre notre simulateur Tical et Proto Modèle de conception du langage Tical Aspects Programmation par aspect Tical : Langage de programmation aspect Aspects pour la programmation amorphe Aspect «Gestion de la mémoire» Aspect «Initialisation» Aspect «Comportement» Aspect «Réception des messages» Aspect «Fonction» Aspects Métas Composants Tical : Langage de programmation orienté composant Création et paramétrage des simulations Compilation Exemples de programmes Tical Formalisation des algorithmes Voronoï Composant Propagation Composant Voronoï Système de coordonnées Gradient Coordonnées Conclusion Vers une implémentation d une machine abstraite Blob Machine abstraite Blob Primitives amorphes pour les blobs Structure de composants pour les blobs Déplacement de l état d un élément de calcul Agrégation Liaison Composant densité Composant liaison Duplication Mitose Cellulaire

9 Table des matières Implémentation avec Tical Conclusion Conclusion et perspectives Conclusion Perspectives Pour le simulateur Pour le langage de bas niveau Extension de Tical Langages de bas niveau alternatifs Pour les primitives de bas niveaux Pour les primitives de hauts niveaux Pour l implémentation des Blobs De nouvelles primitives de haut niveau Perspectives générales pour la programmation amorphe Bibliographie 143

10 Chapitre 1 Introduction Nous présentons un environnement de programmation pour les ordinateurs amorphes allant d un simulateur à des primitives de hauts niveaux en passant par un langage de bas niveau orienté aspect et composant. Un ordinateur amorphe 2 [AAC + 00] est un ensemble de processeurs élémentaires (éléments de calcul) statiques, spatialement distribués et communiquant sur de courtes distances de manière omnidirectionnelle avec leur voisinage [Fig. 1.1]. Les éléments de calcul contiennent tous le même programme et leur capacité de calculs et stockages sont supposées faibles 3. La problématique de la programmation amorphe est de construire des programmes pour les éléments de calcul afin que l ensemble réalise des tâches ayant une cohérence globale. Afin d exploiter la masse des éléments, les programmes de chaque élément ont la possibilité de se spécialiser lors de l exécution 4. Des spécialisations statiques existent déjà. Ainsi Daniel Coore [Coo99a] trace des trains d inverseurs sur un ordinateur amorphe en utilisant des points de sécrétions dirigés par des tropismes. Son modèle a été étendu afin d écrire un texte donné [GC06]. De même, Radhika Nagpal [Nag01] propose une méthode de configuration des ordinateurs amorphes utilisant une algèbre de l origami [HS89]. Chacun de ces deux modèles se contente de configurer un ordinateur amorphe mais ce dernier ne calcule pas. Nos travaux ont pour but d ajouter le calcul à des configurations spatiales. 2 Les premiers travaux ont débuté en 1997 par les travaux de Coore, Nagpal et Weiss [CNW97] sur la création de hiérarchies de groupes dans un ordinateur amorphe. 3 De tels éléments de calcul sont déjà sur le marché ou en cours de développement. Ainsi, nous pouvons construire des réseaux de senseurs [Lin05, Xbo02]. Des éléments de calcul de grandes autonomies sont en cours de recherche [uam08] ainsi que des éléments de calcul de tailles microscopiques [Rou01]. 4 La spécialisation des éléments de calcul est matérialisée par un état donné. Le programme exécutant alors un sous-programme en fonction de cet état. Un élément de calcul contient donc toutes les spécialisations prévues par le programmeur. 9

11 Chapitre 1. Introduction Fig. 1.1: Représentation d un ordinateur amorphe et de son réseau de communication. Ce dernier est constitué de 1000 éléments de calcul statiques uniformément répartis 1 dans un espace carré de 100 unités de côté. Chaque élément exécute le même programme de façon asynchrone et communique avec tous ses voisins dans un rayon de 5 unités. Si les éléments de calculs sont des senseurs sans fils, les communications sont assurées par l émetteur/récepteur radio de ce dernier. Nous donnons d autres exemples d éléments de calcul dans le section Approche Notre approche consiste à fournir un environnement de calcul complet et viable pour les ordinateurs amorphes. Notre premier objectif est de trouver un modèle de calcul qui exploite l ordinateur amorphe. L idée est alors de distribuer le calcul dans l espace formé par l ordinateur amorphe. Pour cela, nous avons choisi le modèle blob [GEM08]. Ce dernier décrit une machine abstraite blob distribuant automatiquement un calcul dans un graphe dont les noeuds sont des ensembles d un ou plusieurs éléments de calcul amorphes. Les noeuds sont appelés blobs. Les 4 La répartition uniforme des éléments de calcul est assurée par la fonction rand de la bibliothèque C dont nous utilisons les bits de poids forts [Knu97] pour déterminer séquenciellement les coordonnées de chaque élément de calcul.

12 Chapitre 1. Introduction 11 blobs sont mobiles dans l ordinateur amorphe. Le graphe de calcul distingue trois types d arcs : des arcs verticaux définissant un arbre couvrant sur tous le graphe, des canaux de communications entre les blobs et des ports d entrée/sortie. De plus, la machine abstraite blob offre 4 instructions, dites statiques, gérant l orientation des arcs et 4 instructions, dites dynamiques, permettant de développer le graphe en ajoutant ou enlevant des blobs ou des arcs. C0 <<Interface>> élément de calcul simulateur C1 <<Interface>> langage bas niveau Tical aspect composant... C2 <<Interface>> primitives bas niveau déplacement des états gradient créer un blob C3 <<Interface>> primitives haut niveau primitives Blob créer un canal de communication diviser un blob C4 <<Interface>> langage haut niveau Blob C5 application Fig. 1.2: Diagramme de classes UML décrivant l architecture de Tical, notre projet de simulateur et de langage de programmation d ordinateur amorphe. Nous partons d un simulateur d ordinateurs amorphes (C0) pour aller vers des programmes (C5) écrits dans un langage de haut niveau (C4). Pour parvenir à nos fins, nous introduisons un langage bas niveau (C1) ainsi qu un jeu de primitives (C2 et C3). Les programmes amorphes contenus dans chaque élément de calcul manipulent, comme les programmes impératifs, des variables 5 ainsi que des messages. L envoi et la réception des messages se fait en série et à une vitesse plus lente que 5 Dans la programmation impérative, le nombre de variables est une des métriques dénotant la complexité d un programme. L évolution des langages informatiques tend à faire baisser le nombre de variables manipulables par le programmeur à un endroit donné des programmes en l encourageant : à utiliser des variables locales ; à masquer les variables globales dans la programmation structurée et modulaire ou dans l encapsulation de la programmation orienté

13 Chapitre 1. Introduction 12 le calcul proprement dit. La réception de chaque type de message est traitée par un sous-programme dédié. Ainsi, l envoi d un message peut modifier les calculs des éléments du voisinage le recevant. Dans ce contexte, écrire directement un programme pour un ordinateur amorphe, même simple, peut s avérer être une tâche difficile. Les programmes doivent ainsi tenir compte des éventuels voisins pour effectuer leurs travaux. De plus, la description du comportement souhaité de l ensemble de l ordinateur amorphe est souvent très différente de la description des programmes des éléments de calcul. Par exemple, si nous voulons tracer une ligne entre deux éléments de calcul [Coo99a], nous demandons à un des éléments de calcul situé sur une des extrémités du segment d initier un gradient 6. Lorsque les éléments de calcul situés sur l autre extrémité reçoivent le gradient, ils propagent un signal descendant le gradient en marquant leur passage et traçant ainsi un segment 7. La création du gradient est réalisée en incrémentant de proche en proche une valeur entière et en conservant la valeur minimale reçue. La descente du gradient s effectue en envoyant sa valeur de gradient décrémentée. Les éléments de calcul dont la valeur de gradient est égale à celle reçue se marquent comme étant sur le segment. Comme nous le voyons, le tracé d un segment ne fait intervenir, dans les éléments de calcul, que des émissions de messages et des opérations arithmétiques élémentaires. Cette description locale (messages, additions) est très éloignée de la description globale (tracer une ligne). De telles descriptions existent dans des domaines scientifiques variés [vb93, Moi99]. En particulier le fonctionnement du corps humain est décrit dans un premier temps en termes d organes. Les organes sont décrits en terme de tissus composés de cellules. Ces dernières sont décrites en partie par des réactions chimiques. Cependant la description anatomique ne dit rien de l activité cellulaire présente dans les cellules. Il faut donc faire face à une complexité d échelle. Afin d appréhender cette complexité, nous utilisons la méthode de la compilation du global vers le local [Nag02]. Cette technique implique une description du système en couches d abstractions auquel il faut associer des compilateurs permettant de passer d une couche à l autre. Ainsi notre description en couches d abstractions [Fig. 1.2] est : couche 0 : les éléments de calcul de l ordinateur amorphe. Nous travaillons avec des éléments de calcul simulés. Les communications entre les éléments objet. De plus, les langages de programmation font baisser le nombre de variables en proposant des types complexes comme les structures, unions et objets. 6 Un gradient est une primitive estimant la distance entre un élément de calcul source et les autres éléments de calcul. Le gradient est inspiré de la diffusion d éléments chimiques dans une réaction chimique. 7 Le programme propageant une valeur est donné dans [Fig. 1.3] et est détaillé dans la section

14 Chapitre 1. Introduction 13 sont abstraites via un tableau noir. couche 1 : un langage de programmation bas niveau des éléments de calcul amorphes. Nous créons Tical, un langage orienté aspect et composant spécialisé dans la programmation des éléments de calcul. La programmation orientée aspect favorise la séparation d un programme en problèmes distincts se croisant. La programmation orientée composant nous offre la possibilité de construire des bibliothèques de primitives réutilisables. couche 2 : des primitives de bas niveau implémentées dans le langage de bas niveau. Nous proposons les composants Tical suivant : propagations de valeurs, gradient, estimation du voisinage, élection de leader, déplacement et duplication de l état d un élément de calcul vers un voisin. couche 3 : des primitives de haut niveau utilisant les primitives de bas niveau. Elles préparent l implémentation d un langage de haut niveau. Nous retenons les primitives de la machine abstraite blob. Une machine abstraite blob est une machine de calcul s auto-déployant dans l espace. Son unité de calcul est le blob que nous représentons par un groupe d éléments de calcul amorphes. Nous nous attardons que sur les primitives s intéressant à la programmation amorphe : créer un blob avec des éléments de calcul épars, créer un canal de communication entre deux blobs, scinder un blob en deux blobs. couche 4 : un langage de haut niveau synthétique et reposant sur les primitives précédentes. Cette couche n est actuellement pas opérationnelle. Le langage prévu implémente la machine abstraite blob. Les utilisateurs de cette couche communiquent avec elle via un langage dérivé de BlobML 8. couche 5 : des programmes des utilisateurs exploitant potentiellement toutes les couches précédentes. 1.2 Contributions Cette thèse comporte trois contributions : 1. un simulateur d ordinateurs amorphes, Tical 9. Ce dernier peut travailler avec des ordinateurs amorphes allant jusqu à plusieurs millions 10 d éléments de calcul. Les éléments de calcul simulés sont architecturés comme ceci : 8 BlobML est le langage de programmation de référence pour les machines abstraites blob. Il est conçu comme une extension du langage Caml [Ler07]. 9 Tical est l acronyme de Tical Is a C Amorphous Library. 10 Dans la pratique, nos simulations conservent l état des éléments de calcul dans des tableaux. Ils sont indexés par des entiers codés sur 32 bits. Ceci limite le nombre d éléments de calcul à Si toutefois, nous étions confrontés à cette barrière, nous pouvons ajouter une dimension à ces tableaux dont les indexes sont alors ( i /2 32, i mod 2 32 ). Ceci repousse alors la limite au nombre d éléments de calcul à 2 64.

15 Chapitre 1. Introduction 14 les éléments de calcul possèdent des états privés étiquetés ; les éléments de calcul possèdent des états publics également étiquetés. Dès qu un état public est modifié, un message est envoyé dynamiquement au voisinage. Les messages reçus sont automagiquement 11 placés dans un tableau noir ; un programme. Il existe deux autres simulateurs d ordinateurs amorphes développés tous les deux par le laboratoire d informatique et d intelligence artificielle (CSAIL) du MIT dont un seul 12 à ce jour fonctionne. 1: (make-component propagation #:params ((init 0)) #:states (value) #:messages (propagate) 5: #:init ((set! s:value p:init)) #:message-handlers ((propagate (when-and ((!= m:propagate p:init) (= s:value p:init)) (set! s:value m:propagate)))) 10: #:behaviours ((set! m:propagate s:value))) Fig. 1.3: Cette figure présente un composant propageant une valeur à tous les éléments de calcul de l ordinateur amorphe. Le composant encapsule six des aspects proposés par le modèle Tical. Nous donnons une version générique de ce composant à la section un langage pour la programmation amorphe, Tical 13, permettant de construire des abstractions via des composants et des aspects. Ce langage nous permet de décrire les programmes pour les éléments de calcul de nos ordinateurs amorphes. L objectif de ce langage est de : (a) pouvoir décrire les différentes parties d un programme comme l initialisation, le traitement des messages, le comportement global d un élément de calcul ; 11 Automagique [Hof98] : automatique mais avec une touche de magie. 12 Ce simulateur se nomme Proto [BB07a]. Il est réalise par Jonathan Bachrach et Jacob Beal au CSAIL du MIT. La première version publique est sortie en octobre Nos comparaisons (voir la section 3.2.1) montre que Tical, notre simulateur, est en moyenne 50 fois plus véloce que Proto. Le premier simulateur d ordinateur amorphe est HLSIM. Il est réalisé par Stephen Adams en 1997 au CSAIL du MIT. Aujourd hui, il n est plus maintenu et ne fonctionne plus sur les systèmes d exploitations actuels. 13 Tical est l acronyme de Tical Is a Component and Aspect Language.

16 Chapitre 1. Introduction 15 (b) pouvoir construire et utiliser des abstractions regroupant toutes les parties d un programme. Le premier objectif est réalisé par la programmation par aspect. Ce paradigme de programmation a pour but de séparer les différents intérêts d un programme. Par exemple, grâce à ce paradigme, nous pouvons aisément séparer le traitement des messages reçus du calcul intrinsèque d un élément de calcul. Un tisseur d aspects 14 construit alors le programme final en agrégeant les aspects fournis par le programmeur. Dans notre langage, nous séparons nos programmes en six aspects : l inclusion des composants, la déclaration des états privés et publics, l initialisation, les traitements des messages, le comportement général et l analyse. Chaque aspect peut être écrit dans un dialecte qui lui est propre [Fig. 1.3]. Le second objectif est achevé par l ajout des composants. Un composant encapsule les différents aspects d un programme effectuant une tâche donnée et peut utiliser d autres composants. Notre tisseur d aspects réduit les aspects contenus dans les composants en aspects uniques avant de les compiler. 3. trois primitives pour l implémentation du modèle de calcul dans l espace blobs. Les trois primitives que nous avons implémenté sont : (a) l agrégation d un blob à partir d un ensemble d éléments de calcul éparpillés dans l ordinateur amorphe [Fig. 1.4 (a) et (b)]. Pour mener à bien cette réalisation, nous commençons par fournir un composant déplaçant l état d un élément de calcul dans un de ses voisins. Ensuite, nous développons notre algorithme d agrégation inspiré de l agrégation des amibes Dictyosteliums Discoideums 15 [GS77]. (b) la liaison de deux blobs, constitués d un agrégat de plusieurs 16 éléments de calcul, où chaque blob se retrouve collé à l autre sans que leurs éléments de calcul ne soient mélangés. Pour aider la construction de cette primitive, nous développons un composant d interrogation de la densité d éléments de calcul satisfaisant une condition donnée. 14 Un tisseur d aspects est un compilateur pour la programmation par aspect. Son rôle, en plus de l acte de compilation proprement dit, est de rassembler automatiquement les différents intérêts séparés par le paradigme aspect. 15 Les Dictyosteliums Discoideums sont des amibes vivants dans la terre. Lorsque leurs conditions de vie sont favorables (la nourriture est suffisante), ces amibes vivent individuellement. Mais si la nourriture vient à manquer alors elles se regroupent afin de former une «limace» de quelques millimètres de long. L agrégation des Dictyosteliums Discoideums est contrôlée par l enzyme AMPc. Les amibes diffusent cette enzyme par vague dans leur environnement et se déplacent dans la direction où la concentration de AMPc est la plus forte. 16 Nous menons nos expériences avec des blobs constitués d environ éléments de calcul.

17 Chapitre 1. Introduction 16 Fig. 1.4: Les trois primitives pour la programmation blobs : l agre gation d un blob (a) et (b) ; la liaison de deux blobs (c) et (d) ; la division de deux blobs (e) et (f). Les e le ments de calcul rouges et verts font partis d un blob alors que les e le ments de calcul bleus (peu visible sur ces pages) sont inutilise s. (c) la duplication d un blob en deux blobs distincts. Ce proble me est de coupe en deux sous-proble mes. Le premier est de dupliquer chaque e le ment de calcul du blob. La duplication est assure e par une modification du composant de de placement des e le ments de calcul. Mais les e le ments de calcul e tant agre ge s, ils n ont pas l espace ne cessaire pour se dupliquer. Un composant contro lant la densite assure alors que tous les e le ments de calcul seront duplique s. Le second sous-proble me est de se parer les e le ments de calcul pour en faire deux blobs distincts. Pour cela, nous brisons la syme trie17 de l espace des e le ments de calcul en combinant des gradients associe s a deux e lections de leader. Ce faisant, nous construisons deux zones d agre gation distinctes qui discriminent nos deux blobs. 17 Un espace est syme trique s il est invariant aux translations, aux rotations, aux re flections, aux inversions et aux homothe ties.

18 Chapitre 1. Introduction Contexte Le calcul spatial est un champs du calcul paralle le. Le proble me peut e tre introduit par les mots de Vita nyi [Vit88] : «... plusieurs proble mes lie s au ca blages commencent a ge ner les concepteurs d ordinateurs et de circuits inte gre s. Formellement, un ca ble avait la proprie te magique de transmettre des donne es instantane ment d un endroit a un autre... Un ca ble ne prenait pas de place, ne dissipait pas de chaleur, et ne cou tait rien au moins, pas assez pour nous inquie ter... Un autre effet qui devient de plus en plus important est que la plupart de l espace d un composant est occupe par les ca bles.». La figure 1.5 illustre ce constat sur un processeur moderne. Dans ce contexte, le calcul spatial vise a exploiter les interactions locales entre les constituants d une unite de calcul, minimisant ainsi la longueur des ca bles. Les changements d e chelles n augmentent que proportionnellement le nombre d interactions entre les unite s de calcul, permettant ainsi de concevoir des machines compose es d un nombre de plus en plus importants d unite s de calcul. Fig. 1.5: Une photographie d un processeur quadruple cœurs Phenom II d AMD. Une grande partie de la surface entre les diffe rents cœurs et les me moires caches est utilise e pour les relier entre eux. (source : AMD). Les machines spatiales peuvent e tre construite sur des me diums re guliers comme les FPGAs18, les automates cellulaires [FS92], sur des me diums irre guliers 18 Les FPGAs (acronyme de field-programmable gate array) sont des re seaux de portes pro-

19 Chapitre 1. Introduction 18 comme les chimies artificielles [Dit05, Ada04, DZB01] ou les ordinateurs amorphes que nous explorons dans cette thèse. La programmation amorphe a débuté dans l équipe de Gerald Sussman en 1996 au MIT [AKS + 96]. Elle est née du développement de la micro-fabrication (MEMS) et de la biologie fondamentale. Elle a pour but de rendre possible la construction ou l auto-construction d ordinateurs amorphes. Les premiers travaux visaient à fournir les premiers paradigmes de programmations amorphes dans le but de configurer l ensemble des éléments de calcul selon un modèle donné. Parmi ces premiers paradigmes, nous retrouvons : les gradients qui estiment la distance entre l élément de calcul à la source du gradient et les autres éléments de calcul ; les groupes et les hiérarchies d éléments de calcul, afin de pouvoir contrôler les éléments de calcul. L algorithme «club» se propose de réaliser cette tâche sans l aide d un leader [CNW97] ; des méthodes de réactions diffusions [CN98, MR99] ; les systèmes de coordonnées permettant d indexer spatialement tous les éléments de calcul [Nag99]. Des techniques de transformations de descriptions globales vers des descriptions locales ont été fournies par Nagpal et Coore dans leurs thèses respectives. Ces transformations du global vers le local prennent à contre pied les travaux menés en vie artificielle. Dans ces derniers, les expérimentateurs fournissent des descriptions locales à des éléments de calcul et ils observent le comportement global qui émerge de ces descriptions De la biologie aux ordinateurs amorphes Les systèmes biologiques sont composés d un grand nombre de constituants en relations les uns avec les autres. Chez les métazoaires 19, l organisation de ces constituants débute par un oeuf fécondé et se termine par la formation des organes. En biologie, un gradient est le ratio entre les concentrations d un élément chimique entre deux régions adjacentes. Les gradients structurent le développement des embryons. Par abus de langage, nous désignons par gradient les variations de concentration d un élément chimique. grammables. Ils sont composés d un grand nombre de blocs logiques connectés entre eux par une matrice de routage configurable. La famille des Spartan-3 de Xilinx propose jusqu à de portes logiques [Xil08]. 19 Les métazoaires sont des organismes eucaryotes 20 multicellulaires hétérotrophes 21. Les insectes et les mammifères appartiennent à la branche les métazoaires. 20 Les eucaryotes regroupent tous les organismes vivants dont les cellules possèdent un noyau. 21 L hétérotrophie est la nécessité pour un organisme vivant de se nourrir de constituants organiques préexistants, d origine animale ou végétale.

20 Chapitre 1. Introduction 19 Fig. 1.6: Gradients inspirés de la biologie. (a) Gradient d ADN messager citron dans un œuf de Drosophile. [SDG + 04] (b) Gradient dans ordinateur amorphe. Ce gradient est obtenu en différenciant deux gradients comme nous le montrons dans la section Par exemple, un gradient de l ADNm citron se forme avant la fécondation dans les ovocytes 22 de Drosophila melanogaster. Le noyau de l ovocyte se déplace vers un des bords de la cellule. Cela modifie la production de l ADNm citron créant le gradient [Fig. 1.6 (a)]. Ce gradient définit l axe antérieur/postérieur de la future Drosophile. Ces gradients inspirent une de nos primitives bas niveaux. Cette primitive estime la distance entre un élément de calcul source et les autres éléments de calcul. En combinant plusieurs gradients, nous calculons des systèmes de coordonnées (voir la section 3.8.3) ou nous séparons l espace en deux bassins d attractions [Fig. 1.6 (b)]. La motilité 23 chimiotaxique 24 est pilotée par des gradients. Ainsi, les amibes Dictyostelium Discoideum [NP92, GS77] sont guidées par un gradient d AMPc 25 [Fig. 1.7 (a)]. Nous nous inspirons de ce phénomène pour réaliser le regroupement d éléments de calcul partageant un état commun [Fig. 1.7 (b)]. La mitose 26 des cellules est découpée en sept phases [ABH + 05] : interphase : Cette phase est séparée en trois sous-phases : + interphase G1 : la taille de la cellule croit en dupliquant son matériel ; + interphase G2 : l ADN est répliqué mais les paires d ADN ne sont pas 22 L ovocyte est la cellule sexuelle femelle chez les métazoaires 23 La motilité est la capacité des cellules à se déplacer dans leur environnement. 24 La chimiotaxie est le phénomène par lequel les cellules dirigent leurs mouvements en fonction de certaines espèces chimiques présentes dans l environnement. 25 L adénosine monophosphate cyclique (AMPc) est un second messager, molécule faisant office de transducteur des signaux venant de l extérieur la cellule vers l intérieur. 26 La mitose désigne d une manière générale le phénomène de la division cellulaire. Il s agit d une duplication «non sexuée» (contrairement à la méiose).

21 Chapitre 1. Introduction 20 Fig. 1.7: Agrégation de cellules. (a) Agrégation d amibes Dictyostelium Discoideum vers une forte concentration de AMPc [GS77]. Sur ce cliché, l AMPc est déposée par l expérimentateur. (b) Agrégation d éléments de calcul guidé par des gradients (voir la section 4.2.3). encore organisées en chromosomes ; + interphase G3 : croissance de la cellule reprend. prophase : l ADN s organise en chromosome. Le centrosome 27 est dupliqué et chaque centrosome s éloigne vers des points diamétralement opposés. Le faisceau mitotique, composé de microtubules 28, s assemble entre les deux centrosomes [Fig. 1.8 (a)]. prométaphase : la membrane nucléaire se rompt et les chromosomes s attachent sur les microtubules. métaphase : les chromosomes sont alignés à mi distance entre les deux centrosomes ; anaphase : les deux jeux de chromosomes se séparent en même temps. Ils sont tirés par les microtubules. télophase : les deux jeux de chromosomes arrivent aux centrosomes et une nouvelle enveloppe nucléaire se forme. Le cytoplasme 29 commence à se diviser [Fig. 1.9 (a)]. cytodiérèse : la cellule est divisée par un anneau contractile constitué de filament d actine et de myosine. Nous pouvons aussi synthétiser la mitoses par osmose [Led12, Tho42] : «Dans une solution saline, si l on place entre deux gouttes teintées, moins ou plus concen- 27 Dans les cellules animales, le centrosome est le centre cellulaire organisateur des microtubules Les microtubules sont des fibres constitutives du cytosquelette (le squelette cellulaire). Ils ont un diamètre d environ 25 nm et une longueur variable. Deux microtubules sont utilisées pendant la mitose. Le temps de vie des microtubules est d environ dix minutes. 29 Le cytoplasme est le contenu d une cellule vivante contenu entre la membrane et le noyau.

22 Chapitre 1. Introduction 21 Fig. 1.8: prophase. (a) Microtubules durant la prophase de la première mitose d un œuf d oursin pourpre Strongylocentrotus droebachiensis [Foe04]. (b) Prophase dans un ordinateur amorphe (voir la section ). Nous marquons deux bassins d attractions afin d y agréger deux groupes d éléments de calcul. trées que la solution et représentant les centrosomes, une goutte très légèrement plus ou moins concentrée que la solution, et représentant un noyau, on voit se dérouler, dans leur ordre successif et régulier, toutes les transformations, tous les mouvements, toutes les figures de la division du noyau». Nous nous inspirons de la mitose pour la division des blobs (voir la section 4.2.5). Notre implémentation des blobs ne possèdent pas d équivalent de l ADN mais sont des agrégats d éléments de calcul dont les états sont mobiles dans l ordinateur amorphe. Nous épurons donc le modèle de la mitose pour ne conserver que trois phases traitant du cytoplasme : l interphase G3 : le blob double son volume en dupliquant chacun de ses éléments de calcul ; la prophase : les deux blobs cassent la symétrie de l ordinateur amorphe en créant chacun l équivalent d un centrosome [Fig. 1.8 (b)] ; la télophase : les éléments de calcul de chacun blobs s agrègent autour de leur «centrosome» respectif [Fig. 1.9 (b)]. Les autres phases ne se préoccupent que de l ADN et ne sont pas reprises dans notre implémentation. 1.4 Plan de lecture La suite du document est organisée en quatre chapitres.

23 Chapitre 1. Introduction 22 Fig. 1.9: Télophase. (a) Microtubules durant la télophase de la première mitose d un œuf d oursin pourpre Strongylocentrotus droebachiensis [Foe04]. (b) Télophase dans un ordinateur amorphe. Nous séparons deux groupes d éléments de calcul (voir la section ). Dans le chapitre 2, nous exposons un état de l art de la programmation amorphe et du calcul dans l espace. Le chapitre 3 présente Tical, notre langage de bas niveau orienté aspect et composant et les primitives bas niveaux. La première partie de ce chapitre présente le modèle de conception du langage et le simulateur qui exécute les programmes. Nous présentons également la programmation par aspect, puis nous détaillons les aspects standards de notre langage. La présentation du modèle de composant de Tical ainsi que le processus de compilation des programmes Tical vers les simulations sont largement exposés. Nous concluons ce chapitre par deux exemples de notre langage : construction de cellules de Voronoï et construction d un système de coordonnées. Ces exemples nous amènent à construire quatre primitives bas niveau : propagation, gradient, gradient doux et estimation du voisinage. Le chapitre 4 présente l implémentation des primitives de haut niveau blob. Après une présentation de la machine abstraite blob, nous décrivons les primitives implémentées en vu de la réalisation de la machine complète. Le chapitre 5 présente une conclusion de l ensemble de nos contributions et quelques perspectives de recherche.

24 Chapitre 2 État de l art Notre travail sur la programmation amorphe s inscrit dans le cadre plus large des systèmes distribués. Plus particulièrement, nous nous intéressons à la programmation spatiale qui exploite l espace 1 occupé par les systèmes distribués pour organiser leurs calculs. Nous étudions aussi l informatique inspiré par la nature. Cette dernière offrant des pistes de recherche pour configurer des systèmes distribués. La figure 2.1 schématise l état de l art que nous passons en revue dans ce chapitre. 2.1 Systèmes distribués Un système informatique distribué est une collection de postes ou calculateurs autonomes qui sont connectés à l aide d un réseau de communication. Chaque poste exécute des composantes, par exemple des séquences de calculs, issues du découpage d un projet de calcul global, et utilise un intergiciel 2, qui s occupe d activer les composantes et de coordonner leurs activités de telle sorte qu un utilisateur perçoive le système comme un unique système intégré. 1 En Mathématique, le terme d espace a des usages très varié allant des espaces topologiques jusqu aux espaces de Fréchet, espaces de Hilbert (en calcul quantique), espaces (et algèbres) d opérateurs (grâce à John von Neumann), et bien d autres. En Physique, un espace est en général conforme à l idée de champ (grammatical, électromagnétique, vectoriel). En réalité, l espace semble vide et (en fait très actif) semble un lieu où des événements se produisent et où des objets de tailles variées coexistent et peuvent apparaître en évolution. En informatique, nous nous plaçons dans le cadre des espaces de processeurs. 2 Intergiciel est la traduction française officielle pour le mot anglais middleware. Le middleware est un logiciel servant d intermédiaire entre deux applications. C est un composant essentiel dans les architectures 3-tiers, faisant le lien entre les applications clientes et les bases de données. 23

25 Chapitre 2. État de l art 24 réseau de senseurs Ecoli OSL reaction diffusion smart dust langage amorphe GPL Calcul Spatial Programmation amorphe jeu de la vie Blob P system automates cellulaires MGS Programmation inspirée par la nature JXTA Calcul distribué Madkit Fungus peer to peer agent swarm grille de calcul Calcul informatique 3APL vie artificielle Boinc SugarScape Biologie synthétique Kerrighed Seti@Home Fig. 2.1: L état de l art vu au travers d un diagramme de classes UML. Nous partons des systèmes distribués pour finir par la programmation amorphe en passant par le calcul spatial et les inspirations biologiques en informatique. Dans ce schémas, une ligne continue symbolise une relation «est un». Une ligne hachée symbolise une relation «réalise».

26 Chapitre 2. État de l art Grilles de calcul Les grilles de calcul [Pri05] sont «des infrastructures matérielles et logicielles faisant communiquer et coopérer, à grande échelle, des matériels distants et hétérogènes dans leurs modes de fonctionnement et leurs performances, de créer les logiciels permettant de gérer et de prendre en compte efficacement la distribution des ressources et des données, de mettre au point des outils de programmation adaptés au caractère diffus et parallèle de l exécution des tâches confiées à la grille, etc». De nombreuses grilles sont en exploitation. Nous en exposons trois dans la suite de la section. Fig. 2.2: Architecture de Boinc. Un client demande une tâche aux serveurs Boinc. Le serveur sélectionne une tâche à effectuer pour le client. Pour accélérer la sélection, un cache d environ 1000 tâches est maintenu par le feeder. (source : [AR09]) Le projet Seti@Home [ACK + 02] est la grille de calcul la plus diffusée. Son objectif est de détecter une vie intelligente extraterrestre en analysant les données collectées par le radiotélescope d Arecibo à Puerto Rico. Cette analyse est confiée aux ordinateurs participant au projet. Ces derniers peuvent appartenir à des personnes morales tout comme ils peuvent appartenir à des particuliers. Un participant demande un ensemble de données à analyser aux serveurs du projet Seti@Home, les traite puis renvoie le résultat aux serveurs. Boinc [And04] réutilise la plate-forme de Seti@Home. Cette plate-forme a été exploité dans d autres applications scientifiques telle que la cryptanalyse ou l étude épidémiologique de la malaria. Le projet Boinc, au delà de la répartition des tâches entre les participants [Fig. 2.2], a dut faire face à des problèmes de validités des réponses renvoyées par les participants. La solution retenue est la réplication des tâches. La même tâche est envoyée à plusieurs participants et leurs réponses sont comparées. Kerrighed [ker08] est une modification du noyaux Linux permettant de percevoir une grappe de machines comme une machine unique. La grappe est exploitée en utilisant MPI ou simplement des threads. Les threads sont créés sur un noeud

27 Chapitre 2. État de l art 26 du cluster de manière transparente. De la même façon, ils peuvent être déplacés d un noeud à l autre. Les processus profitent également d une mémoire partagée distribuée. La plus grosse grappe enregistrée comporte 96 noeuds mais la majorité en possède moins de 5. Ces grappes de calcul Kerrighed cherchent à répartir la charge entre les noeuds. Mais ils ne tiennent pas compte de la topologie des réseaux des grappes pour cette répartition Peer to Peer Le peer-to-peer 3 (P2P) [ATS04] est un modèle de réseau informatique dont le fonctionnement n est pas centralisé dans une relation client-serveur, mais décentralisé entre les différents utilisateurs du réseau, dont les machines sont simultanément clients et serveurs des autres machines (et aussi routeur, en passant les messages de recherche voire les données vers leur destinataire). Le partage de fichier est l utilisation la plus fréquente 4 de ce modèle. Le modèle P2P peut aussi héberger du calcul. Le projet JXTA [Sun03] propose l infrastructure pour y arriver. Les noeuds de calculs sont architecturés autours de services. Ces derniers sont répertoriés dans une table de hachage distribué. L infrastructure se contente de mettre en relation les noeuds de calcul. La différence avec calcul sur grille et le peer-to-peer réside en l absence d infrastructure coordonnant fortement les noeuds de calcul. La gestion de l instabilité des noeuds de calculs est inplicite dans les réseaux peer-to-peer Multi-agents Les systèmes multi-agents ont été développés dans le cadre de l intelligence artificielle distribuée. Minsky [Min86] nous en donne toujours la meilleure définition : «Un agent peut seulement faire des choses simples qui nécessitent pas ou peu de réflexion ou de pensée. Maintenant quand nous rassemblons ces agents en sociétés alors apparaît la véritable intelligence.» Les systèmes multi-agents se divisent en deux grandes familles [Fer95] : les systèmes multi-agents intelligents ou cognitifs [WJ95] ; 3 La traduction française de peer-to-peer est «pair à pair». N étant pas familier avec cette formulation, nous nous en tenons à l écriture anglaise. 4 Les systèmes Peer-to-Peer existent depuis quelques décennies. Ainsi les protocoles SMTP, NNTP, FidoNet ou encore DNS sont P2P. Le courrier SMTP peut transiter via des relais sans contrôle de l émetteur ou du récepteur. Les messages NNTP sont répliqués de proche en proche sur des centaines de serveurs. Fidonet peut transmettre gratuitement des messages en exploitant les boucles locales de certains pays (USA notamment). Le DNS délègue la gestion des noms de domaines à des serveurs locaux. Si un serveur ne connaît pas un domaine, il interroge son serveur parent.

28 Chapitre 2. État de l art 27 les systèmes multi-agent réactifs qui possèdent peu de capacités de calcul et de mémorisation par rapport aux agents intelligents. Cela les oblige à être en prise plus directement avec leurs environnements. Alors que la première catégorie puise son inspiration dans la psychologie, la linguistique et la sociologie, la seconde catégorie s inspire de l éthologie 5, de l écologie et de la psychologie sociale [Kur67]. Les simulations à base d agents (MABS) [Dav00] sont utilisées pour simuler des systèmes ou des individus évoluent dans un environnement. Fig. 2.3: Architecture de Madkit. Les applications sont modélisées par des agents. Ces derniers sont classés en fonction de leurs rôles. (source : [GF00]) De nombreuses plateformes de programmation d agents sont disponibles : 3APL [HdBvdHM99, DvRDM03] pour les agents cognitifs. C est un langage de programmation offrant des constructions implémentant les croyances, les buts et le raisonnement d un agent. Jack Agent Language [Age05] est un langage de programmation orienté agent. Il est bâti comme une extension du langage Java pouvant construire des agents possédant des fonctionnalités, des plans et des bases de connaissances. Madkit [FGM02, FG01, GF00] est bati sur un modèle Agent/Group/Role[MF07]. Dans ce modèle, les agents appartiennent à un groupe et jouent un rôle définis. Cela permet de construire des sociétés d agents hétérogènes [Fig. 2.3]. Swarm [Eva00, MBLA96] est une plate-forme pour développer des modèles à base d agents. L architecture de base de Swarm est la simulation d une collection d agents concurrents et interagissant. logo [Res94] est un langage distribué inspiré de Logo. Il propose des fonctionnalités originales pour construire des structures diffusives. 5 L éthologie est la science de l étude du comportement animal [Des99]. La rencontre entre l éthologie et l informatique est fertile. Cela a donnée naissance entre autre à l algorithme d optimisation avec des fourmis [DCG99] utilisé comme algorithme de routage dynamique ou comme heuristique pour le problème du voyageur de commerce.

29 Chapitre 2. État de l art 28 Breve 3D [Kle03] est une plateforme de simulation d objets mobiles. SugarScape [DLR07] est un framework pour programmer des simulations à base d agents sur des processeurs graphiques. La technique consiste à encoder la mémoire des agents dans des textures. Alors ces textures sont modifiées par des Pixel Shaders. SugarScape simule 2 millions d agents à la vitesse de 50 mises à jour par secondes sur du matériel moderne. L aspect spatial des textures est exploité pour gérer l environnement et les interactions entre les agents. Un projet similaire mais plus généraliste, Cuda, est développé par Nvidia 6. Cuda [Hal08] permet d accéder aux processeurs graphiques de la marque comme des machines systoliques [MMU87] ou directement de faire de la programmation par flux sur les différents coeurs des GPUs Fungus Dans cette section, nous présentons Fungus [Val03] notre plate-forme ouverte multi-agents, distribuée pour la simulation d objets mobiles. Notre plate-forme est composée d un moteur d exécution modulaire, d une bibliothèque de classes permettant de mettre en oeuvre rapidement une simulation, d un langage de création et d assemblage de simulation ainsi qu une interface graphique. La grande complexité des systèmes biologiques, physiques ou sociologiques rend l étude exacte de ces systèmes impossible par les méthodes mathématiques actuelles 7. Fungus 8 utilise un modèle multi-agent pour réaliser ses simulations. Ces agents peuvent communiquer ensemble, sont situés dans un environnement [DM99] et se déplacent dans celui-ci. Ils s échangent des informations en émettant des messages dans des canaux de communication. Ces derniers peuvent simuler les perturbations de l environnement en déformant les messages qu ils transportent. Les environnements où évoluent nos agents sont aussi modélisés par des agents. Ainsi les agents utilisent les mêmes mécanismes pour communiquer avec l environnement que pour communiquer entre eux. Beaucoup de simulateurs séparent l environnement des agents. Nous proposons un langage pour faciliter l écriture des simulations : Mycelium. Notre langage est la combinaison d un schémas XML et d un interprète Scheme. Il 6 Les autres constructeurs de processeurs graphiques réagissent en se ralliant au projet de GPGPU OpenCL [Mun08] 7 Le problème consistant à calculer les interactions gravitationnelles de trois masses n a pas de solution comme l a montré Henri Poincaré en remportant le prix Oscar II en 1887 [Gle91]. Néanmoins, nous pouvons calculer itérativement des solutions approchées en intégrant soit le temps ou soit l espace. 8 Notre logiciel est réalisé en langage Java. Il est constitué de lignes de programme et 285 classes. Le code source est disponible via l outil CVS à l adresse

30 Chapitre 2. État de l art 29 définit de nouvelles classes d agents et lance les simulations. La figure 2.4 présente un exemple de simulation créée avec Mycelium. Cette simulation affiche en boucle le message «Hello World» sur le terminal. <?xml version="1.0"?> <!DOCTYPE mycelium SYSTEM "mycelium.dtd"> <mycelium> <definition> <!-- Defini une nouvelle classe d agent --> <agentclass name="helloagent"> <behavior> (println "Hello World") </behavior> </agentclass> </definition> <!-- Deploiement de la simulation --> <simulation> <!-- Definit un parametre demande a l utilisateur --> <!-- Le parametre vaut 10 par defaut. --> <parameter key="number-agent" name="nombre d agents">10</parameter> <!-- Fabrique le nombre d agents demande par l utilisateur --> <repeat times="(mget! simulation-parameters number-agent)"> <agent type="helloagent"> </agent> </repeat> </simulation> </mycelium> Fig. 2.4: La simulation «Hello World» en langage Mycelium. Un agent helloworld est défini pour afficher «Hello World» sur le terminal. Ensuite, une simulation est créée : le nombre d agents de celle-ci est demandé à l utilisateur. Puis les agents sont déployés. Notre modèle de simulation s appuie sur les simulations à évènements discrets, les simulations orientées objets et les simulations basées sur du multi-agents [Fig. 2.5]. Les simulations à évènements discrets[mis86] voient les systèmes à étudier en termes d états et d évènements. Chaque état de la simulation émet des évènements pour une date donnée. Ces évènements sont traités et modifient l état de la simulation. Il existe deux types de gestions du temps dans les simulations à évènements discrets : les simulations dirigées par le temps et les simulations dirigées par les évènements. Dans le premier type, le temps est divisé en intervalles de longueur fixe. À chaque étape de la simulation, on avance le temps et on traite les évènements programmés. Les simulations à événements discrets dirigées par

31 Chapitre 2. État de l art 30 Infrastructure Simulation agent <<Interface>> Canal 2 Agent AgentGroup 0..* Message Space space Neighborhood Topology MessageHandler LayeredSpace 2DSpace Euclidian 2DLayeredSpace Circular services <<Interface>> Service Scheduler Mycelium CreateAgent Visualization 1..* CreateCanal Monitor TimeModel Scheme Fig. 2.5: Apperçu de l architecture de la plate-forme Fungus. La simulation est définie dans un infrastructure. Celle-ci est un gestionnaire de services. La simulation est composée d agents plongés dans un espace.

32 Chapitre 2. État de l art 31 le temps sont simples à mettre en oeuvre. Mais elles peuvent être lentes à l exécution si peu d évènements sont traités à chaque étape. Dans le second type de simulation, les simulations dirigées par les évènements, le temps n est pas divisé en intervalle fixe. À chaque étape, le temps est incrémenté jusqu au prochain évènement programmé. Cette méthode permet souvent d exécuter les simulations plus efficacement. La mise en oeuvre de ce type de simulation est plus délicat car elle fait appel à des techniques d ordonnancement. L ordonnancement des agents de Fungus est effectué soit par la machine virtuelle Java en utilisant des threads 9, soit par un ordonnanceur à évènements discrets permettant une gestion multi-tâche coopérative. Notre ordonnanceur permet une gestion dirigée par le temps et dirigée par les évènements dans une même simulation. Il s accommode parfaitement avec les threads. Les simulations orientées objets[jr98] apportent plus de robustesse et de maintenabilité aux simulations. Les composants de ces simulations sont décrits avec des objets. L encapsulation de l état d un composant de la simulation assure la robustesse des simulations. En effet, cet état ne peut être modifié que par les méthodes de l objet. L héritage des objets de la simulation apporte une maintenance simplifiée en permettant de réutiliser les objets de la bibliothèque. Les objets de la simulation sont indépendants les uns des autres qui se combinent pour constituer celle-ci. Les simulations à évènements discrets et les simulations orientées objets peuvent cohabiter dans le même simulateur. Dans ce cas, les objets programment et traitent les évènements dans le simulateur. Les simulations basées sur du multi-agents(sba) 10 [Dav00] sont une évolution des simulations orientées objets. Les composants de la simulation sont décrits avec des agents. Les agents sont des objets qui possèdent les propriétés suivantes : les agents sont indépendants des autres agents. ils peuvent être très simples comme les agents réactifs ou à l opposé très complexes comme les agents intelligents ; les agents communiquent à l aide d un langage de communication. Ce langage peut être très simple comme des envois de signaux ou spécialement dédié à la communication entre agents comme le langage KQML[FWW + 93]. les agents peuvent être spatialement situés. Ils sont plongés dans un espace et peuvent repérer d autres agents dans cet espace. les agents peuvent se déplacer dans l espace. dans le cas de simulations distribuées, les agents peuvent être mobiles entre les différents noeuds de calculs. 9 un thread (traduit processus léger) est un flux d instructions dans un contexte d exécution. Plusieurs threads peuvent partager des ressources, notamment leurs segments de code qui ne sont pas dupliqués contrairement aux processus classiques. Le nombre de threads possible en même temps est limité dans les noyaux des systèmes d exploitation. 10 traduit de l anglais : Multi-agents-Based Simulation(MABS)

33 Chapitre 2. État de l art 32 Fungus réalise des simulations basées sur des agents. Les agents de Fungus sont des processus indépendants qui peuvent communiquer avec d autres agents[min86]. Nous illustrons les spécificités de Fungus par un exemple. Nous simulons l agré- Fig. 2.6: Évolution d une agrégation d amibes Dictyostelium Discoideum lors d une simulation avec Fungus. Nous représentons la concentration de l enzyme camp en fonction du temps. Les amibes sont toutes situées dans les pics de concentration. gation d amibes Dictyostellium Discoïdum[Gol90, GS77] en pseudo-plasmode 11. L agrégation n a pas de contrôle centralisé. Au contraire, elle est réalisée par l action conjointe de chacune des amibes. Chaque amibe émet à intervalle régulier une enzyme (camp) dans son environnement. Les amibes la percevant remonte le gradient de concentration. Les amibes finissent ainsi par former des groupes de plusieurs centaines d amibes. Ce phénomène se prête aisément aux SBAs. Pour cela, nous disposons d un agent spatial, composé d un maillage régulier et carré à deux dimensions. Chaque axe de cet espace possède une structure circulaire. Il contient aussi un calque pouvant recevoir des valeurs entières et diffuser ces valeurs au voisinage. Nous modélisons chaque amibe par un agent. Il se déplace aléatoirement en déposant à intervalle régulier une quantité d enzyme dans le calque de l espace. Ce 11 Ce pseudo-plasmode ressemble à une limace de 2mm de long. Il est composé de 10 5 amibes.

34 Chapitre 2. État de l art 33 dernier diffuse l enzyme en appliquant les lois de diffusion de Fick 12 sur le calque. Les agents demandent alors à l espace les concentrations de l enzyme disponibles dans le voisinage. Si un gradient est présent, l agent ne se déplace plus aléatoirement mais remonte ce gradient. Afin d éviter que l agent remonte son propre gradient, celui-ci est insensibilisé à l enzyme pour quelques cycles s il a déposé l enzyme récemment. La figure 2.6 montre une visualisation extraite des concentrations de l enzyme contenue dans l espace. Le rendu de cette visualisation est réalisé avec le logiciel OpenDx[IBM03] qui est interfacé avec Fungus. 2.2 Informatique inspirée de la nature L informatique inspirée de la nature puise dans celle-ci des algorithmes ou des paradigmes pour résoudre des problèmes complexes considérés comme difficiles Automates cellulaires Un automate cellulaire est un ordinateur SIMD composé de cellules organisées régulièrement dans un espace discret. Les automates cellulaires sont des modèles d ordinateurs créés initialement pour modéliser la croissance des cristaux. Chaque cellule d un automate cellulaire contient un nombre donné d états discrets [Sig92]. Le programme d un cellule est une table de transition permettant de passer d un état à un autre en fonction du voisinage. Ces tables peuvent être abstraites par des règles. Un exemple d automate cellulaire est le jeu de la vie [Pou85]. L automate est constitué d une grille de cellules de taille théoriquement infinie 13. Chaque cellule possède huit voisins et deux états nommés mort et vivant. Les règles de cet automate cellulaire sont : 12 Les deux lois de diffusion de Fick sont : 1. le flux de diffusion est proportionnel au gradient de concentration. Cela se traduit par l équation suivante : j = D m C x avec j est la densité de l élément diffusé, D m est le coefficient de diffusion dans le calque m et C la concentration ; 2. nous prédisons l évolution des concentrations dans le temps avec l équation : C t = D 2 C x 2 13 Les techniques d encodage utilisant des matrices creuses permettent aux simulateurs de s approcher de la taille infinie.

35 Chapitre 2. État de l art 34 Fig. 2.7: Cette figure représente un jeux de la vie poussant un bloc de quatre cellules. Le bloc est situé en bas à droite. Cette machine fonctionne en produisant des trains de gliders interagissant entre eux. une cellule morte possédant exactement trois voisines vivantes devient vivante ; une cellule vivante possédant deux ou trois voisines vivantes le reste ; sinon elle devient morte. Ces simples règles peuvent engendrer des structures complexes [Pou85]. Citons le glider. Cette structure a la particularité de se déplacer dans l espace de l automate. Une autre structure, appelée glider gun, produit des trains de gliders. Agencé avec précision, ces trains de gliders peuvent s annihiler construisant ainsi un inverseur logique. Les bits sont ici encodés par la présence ou l absence de gliders. Des machines sont construites sur ce principe comme le montre le pousseur de blocs de la figure Vie artificielle La vie artificielle [Ada98, SAB02] est un domaine de recherche à l intersection de l informatique, la biologie et l écologie. Elle cherche à reproduire informatiquement des systèmes vivants. Une des méthodes de la discipline est de batir une simulation d un phénomène à

36 Chapitre 2. État de l art 35 partir de règles 14 simples et d observer l émergence d un phénomène complexe. Les règles sont extraites de l observation de la nature. L opération inverse consistant à trouver directement les règles générant un phénomène complexe est souvent difficile voire impossible. La biologie synthétique [Syn08] tente de construire de nouveaux éléments biologiques et de reconstruire les systèmes existant dans un but utilitaire. Le projet E-Cell [E-C08] s inscrit dans cette démarche en tentant de construire entièrement une cellule par la simulation. La démarche opposée est alors d utiliser du matériel cellulaire pour faire des calculs. Ainsi nous pouvons stocker de l information dans les cycles de transformations des enzymes Kinase en phosphatase [DBGG07]. Fig. 2.8: Croissance d un organisme artificiel. (source : [Dou08]) René Doursat [Dou08] propose un modèle d auto-organisation d une collection de «cellules» inspiré par l embryologie. Chaque cellule est mobile et contient un «ADN» dont les gènes ne s expriment pas tous en même temps mais suivant les relations topologiques de la cellule avec son voisinage. L ADN exprime alors son phénotype dans la morphogénèse d une configuration spatiale d agents [Fig. 2.8]. Un approche similaire est utilisée pour assister les architectes dans la conception de grattes-ciels [KAJ05]. L approche consiste à encoder les structures des gratte-ciels dans des automates cellulaires à une dimension. L évolution de l automate cellulaire révèle une structure de gratte-ciel. Les auteurs appliquent alors un algorithme génétique pour faire émerger les structures les plus légères et les plus résistantes Les règles peuvent être spécifiées par un programme. 15 Certains des structures trouvées par l algorithme génétique étaient déjà connues et reconnues comme performantes. Par exemple, il a «retrouvé» la technique d exosquellete développée par Hervé Tordjman pour les tours jumelles de Guangzhou et que l on retrouve dans la tour londonienne «30 St Mary Axe» conçus par le cabinet Norman Foster.

37 Chapitre 2. État de l art Swarm intelligence L intelligence en essaims [CDF + 03, BT94] est une branche de l intelligence artificielle étudiant les comportements collectifs d agents dans des systèmes auto organisés. Les agents interagissent localement avec leurs congénères et/ou leur environnement à l aide de règles simples [Fig. 2.9]. Les sources d inspirations de ses algorithmes sont l éthologie et l écologie 16. Fig. 2.9: Fouragement dans une colonie de fourmis informatiques. Les fourmis ramènent de la nourriture (carrés rouges) dans la fourmilière (au centre de l écran mais non dessinée) tout en déposant un phéromone (en bleu) le long de leur trajet. Les fourmis en quête de nourriture suivent la trace de phéromone. (source : Moïse Valvassori d après [NK96]) Parmi les algorithmes produits par l intelligence en essaim, nous pouvons citer entre autres : l optimisation avec des colonies de fourmis [DCG99]. Des fourmis parcourent un graphe en déposant des phéromones et choisissent les arcs ayant la plus forte concentration de phéromones. Cet algorithme est un bon heuristique pour le problème du voyageur de commerce. ; l optimisation par essaim de particules [PV04] permet de détecter de multiples minimas locaux. L intelligence en essaims est applicable à la robotique mobile [Che01]. 16 L écologie est la science étudiant les écosystèmes. Il ne faut pas la confondre avec l écologisme qui est l utopie se réclamant du scientisme proposant de refaire vivre l Homme avec la nature dans un système symbiotique en équilibre stable [Lov93].

38 Chapitre 2. État de l art Membranes Le calcul par membranes (ou P-Système 17 ) [Pau02, P 00] est inspiré de la structure des cellules biologiques. Les cellules vivantes disposent d un grand nombre de compartiments (par exemple : noyau, mitochondries, ribosomes). Chacun a sa propre fonction qui peut transformer son contenu moléculaire ou le déplacer dans un autre compartiment. Ces compartiments sont séparés par des membranes. Les membranes ont trois fonctions principales : séparation des compartiments. Le contenu du compartiment reste dans la limite intérieure du compartiment ; permettre la communication entre les compartiments séparés par la membrane. Selon la molécule et la membrane, certaines molécules peuvent traverser la membrane. Le passage peut être que dans un seul sens ; catalyser ou améliorer les réactions chimiques qui ont lieu dans les compartiments. Un P-Système est formellement définit par un N-uplet : Π = (V, µ, w 1,..., w n, (R 1, ρ 1 ),..., (R n, ρ n ), i 0 ) où V est un alphabet des symboles. Ces symboles seront utilisés dans les membranes ; µ est un ensemble de n membranes organisé d une manière hiérarchique appelée structure de membranes de degré n. Chaque membrane est étiquetée dans un alphabet Λ. La structure de membranes peut être écrite dans une forme complètement crochetée. Par exemple, la structure de membranes de la figure 2.10 s écrit [ A [ B [ C ] C [ D ] D ] B ] A ; w i avec i Λ sont des chaînes de V représentant des multi-ensembles dans V associés à chaque membrane de µ. Un multi-ensemble est un ensemble où une multiplicité est associée à chaque élément ; R i, avec i Λ, est un ensemble fini de règles d évolutions dans V associé à toutes les membranes de µ. ρ i est une relation d ordre partiel dans R i précisant les priorités entre les règles R i. Chaque règle R i est une paire u v où : u est une chaîne de V ; v peut être d une des deux formes suivantes : v = v ou v = v δ. v est une chaîne dans (V {here, out}) (V {in j j Λ}) et δ est un symbole n appartenant pas à V. i 0 est un symbole de Λ déclarant la membrane de sortie de Π. Si dans une règle R i, la chaîne u d une paire u v est une sous-chaîne de w i alors la règle est activée et la chaîne u est consommée. Elle est donc retirée de 17 P-système du nom de Gheorghe Păun qui a conçu et formalisé ce modèle de calcul.

39 Chapitre 2. État de l art 38 A B C D A B (a) Fig. 2.10: (a) La structure de membranes de degré 4 «[ A [ B [ C ] C [ D ] D ] B ] A» représentée par un diagramme de Venn. (b) La même structure de membranes représentée par un arbre. C (b) D la membrane. Lorsque la règle R i est activée, la chaîne v de la paire u v est interprétée de la manière suivante : si v ressemble à (a, here), alors la chaîne a est produite dans la même membrane ; si v est de la forme (a, out), alors la chaîne a est retirée de la structure de membranes ; si v correspond à (a, in i ), la chaîne a est produite dans la membrane i ; si le symbole δ apparaît dans v alors la membrane est dissoute. Les règles de cette membrane sont retirées. Le multi-ensemble est ajouté à la membrane supérieure. Les membranes contenues dans la membrane dissoute ne sont pas affectées. Le modèle des P-Systèmes est conçu pour être exécuter avec des unités de calcul parallèle. Nous proposons un modèle multi-agents pour les systèmes à membranes [Val06]. Nous utilisons notre plate-forme Fungus pour implémenter notre modèle où chaque membrane est un agent Fungus.Ces agents, reliés par des canaux, définissent une structure arborescente (voir figure 2.10 (b)). Un agent contient un multi-ensemble de symboles, un ensemble de règles d évolution et le programme de contrôle (voir la figure 2.11). Le programme de contrôle cherche à faire correspondre une règle avec le multi-ensemble de symbole. Si une règle correspond, alors le mutli-ensemble de l agent est modifié. Les agents liés via les canaux de communication peuvent être modifiés par passage de message ou lorsque l agent est «dissou». Comme une membrane doit pouvoir communiquer avec toutes les autres membranes, elles sont organisées dans un espace de dimension nulle où tous les agents sont voisins. Cet espace est représenté par la classe MembraneStructure. Cette classe maintient un répertoire des étiquettes des membranes du systèmes de membranes. Comme la structure de membranes est une organisation hiérarchique des membranes, cette hiérarchie est donc représentée par un arbre (voir la figure 2.10

40 Chapitre 2. État de l art 39 Space Agent MembraneStructure Membrane RuleSet +select(m : MultiSet) 1 0..* 1 modify 1 RuleAction +dissolve() +getsymbol() : Symbol +destination() : Membrane 1..* 1 1 Rule +match() +activate() 1 Symbol 1..* * MultiSet +add(s : Symbol, m : int) +remove(s : Symbol, m : int) +contain(m : MultiSet) : boolean 1 1 Fig. 2.11: Diagramme de classes UML de la simulation de P-Système multiagents avec Fungus. (b)) de sorte qu une membrane permet d envoyer des objets à sa mère, à l un de ses fils ou à lui-même. Cette organisation en arbre s appelle Tissue P-System [MVPPRP01]. Tous les agents héritent de la classe Agent. Dans notre modèle, chaque membrane est un agent de classe Membrane contenant un nom, un multi-ensemble de symboles et un ensemble de règles. La classe MultiSet représente le multi-ensemble utilisé par une membrane. C est une table de hachage où les clés sont des symboles et les valeurs sont les multiplicités associées. La classe RuleSet est le conteneur des règles. Il maintient les règles ainsi qu une méthode pour choisir la règle qui convient en fonction du multi-ensemble d un membrane. La classe Rule est une simple association d une entrée multiset et des actions. Nous avons besoin de seulement deux opérations sur les règles : match et apply. Lorsque RuleSet essaye de sélectionner une règle, il effectue un test d inclusion de la règle dans le multi-ensemble de la membrane. Les actions sont déléguées à la classe RuleAction. La boucle principale de contrôle des membranes est :

41 Chapitre 2. État de l art 40 Choisir une règle dans l ensemble des règles. L ensemble des règles est itéré Si une règle correspond à l état du multi-ensemble de la membrane alors cette règle est inséré dans une liste de priorité. Enfin, nous choisissons au hasard une règle celles qui ont la priorité la plus basse. Appliquer la règle sélectionnée. Chaque action possédée par la règle est appliquée de façon séquentielle dans l ordre où elles sont définies. Quand une membrane applique une règle, il y a quatre actions possibles : 1. production d un symbole dans la membrane. Les nouveaux symboles sont produits et les symboles qui ont activé cette règle sont supprimés ; 2. production d un symbole dans une autre membrane. L agent actuel recherche l agent de destination dans le répertoire de la structure de membranes alors il transmet les symboles correspondant via le canal de communication. Un message transmis contient le nom du symbole et sa multiplicité. Les symboles qui ont activé la règle sont supprimés ; 3. production d un symbole extérieur à structure de membranes. Les symboles qui ont activé la règle sont supprimés ; 4. dissolution de la membrane. Dans un premier temps, les symboles qui ont activé la règle sont retirés de l agent actuel. Après cela, les règles sont désactivées. Ensuite, l agent actuel recherche ses parents dans la structure de membrane et Tous les symboles sont envoyés dans le parent. Les simulations sont créées et déployées par le service Mycélium. Les P-Systèmes sont décrits avec une extension du schémas du langage XML de Mycélium. Un ensemble de balise XML spécialisés dans les P-Système sont inclus dans un document XML standard de Mycélium. Un espace de nommage [BHLT04] évite la collision de noms dans ces nouveaux documents. Nous présentons une simulation de P-Systèmes qui décide si k divise n [P 00]. Ce P-Système est défini comme suit : Π = (O, µ,, a n c k d, (R 1, ρ 1 ), (R 2, ρ 2 ), 1) où O = {a, c, c, d, yes, no}; µ = [ 1 [ 2 ] 2 ] 1 ; R 1 = {r 1 : dcc no, r 2 : d yes}, ρ 1 = {(r 1 r 2 )}; R 2 = {r 3 : ac c, r 4 : ac c, r5 : d dδ}; ρ 2 = {(r 3 r 5 ), (r 4 r 5 )}. La figure 2.12 montre le document XML représentant ce P-Système. Les règles r 3 et r 4 soustraient k de n jusqu à n < k. Ensuite, la règle r 5 peut être activée et la membrane est dissoute. Les symboles cc restant sont envoyés à la membrane 1.

42 Chapitre 2. État de l art 41 <?xml version="1.0"?> <parameter key="rules" type="xml"> <!DOCTYPE mycelium SYSTEM "mycelium.dtd"> <ps:rulegroup priority="0"> <mycelium <ps:rule priority="0"> xmlns=" <ps:condition> xmlns:ps=" <ps:symbol name="a" multiplicity="1"/> <simulation> <ps:symbol name="c" multiplicity="1"/> <agent type="fungus.pcomputing.membrane"> </ps:condition> <parameter key="name">1</parameter> <ps:action symbol="c "/> <parameter key="rules" type="xml"> </ps:rule> <ps:rule priority="0"> <ps:rule priority="0"> <ps:condition> <ps:condition> <ps:symbol name="d" multiplicity="1"/> <ps:symbol name="a" multiplicity="1"/> <ps:symbol name="c" multiplicity="1"/> <ps:symbol name="c " multiplicity="1"/> <ps:symbol name="c " multiplicity="1"/> </ps:condition> </ps:condition> <ps:action symbol="c"/> <ps:action symbol="yes"/> </ps:rule> </ps:rule> </ps:rulegroup> <ps:rule priority="1"> <ps:rule priority="1"> <ps:condition> <ps:condition> <ps:symbol name="d" multiplicity="1"/> <ps:symbol name="d" multiplicity="1"/> </ps:condition> </ps:condition> <ps:action symbol="no"/> <ps:action symbol="d"/> </ps:rule> <ps:action action="dissolve" to="1"/> </parameter> </ps:rule> </agent> </parameter> </agent> </simulation> </mycelium> <agent type="fungus.pcomputing.membrane"> <parameter key="name">2</parameter> <parameter key="set" type="xml"> <ps:symbol name="a" multiplicity="23"/> <!-- n --> <ps:symbol name="c" multiplicity="17"/> <!-- k --> <ps:symbol name="d" multiplicity="1"/> </parameter> Fig. 2.12: Un document XML pour la plate-forme Fungus décrivant un P- Système. Ce dernier décide si k divise n. Si un symbole cc est trouvé dans la membrane 1 alors le symbole no est produit sinon le symbole yes est produit. Ce P-Système produit n nouveaux symboles dans la membrane 2. Au cours de la dissolution de la membrane 2, n + 1 symboles sont envoyés à la membrane 1. Cet envoi utilise trois messages, un pour chaque symbole. Ce modèle réduit au minimum le nombre de messages. 2.3 Calculs dans l espace Le calcul spatial est un champs du calcul parallèle qui vise à exploiter les interactions locales entre les constituants d une unité de calculs. Les changements d échelles n augmentent que proportionnellement le nombre d interactions entre les unités de calculs, permettant ainsi de concevoir des machines composées d un nombre de plus en plus importants d unités de calcul.

43 Chapitre 2. État de l art 42 Le problème peut être introduit par les mots de Vitányi [Vit88] : «... plusieurs problèmes liés au câblages commencent à gêner les concepteurs d ordinateurs et de circuits intégrés. Formellement, un câble avait la propriété magique de transmettre des données instantanément d un endroit à un autre... Un câble ne prenait pas de place, ne dissipait pas de chaleur, et ne coûtait rien au moins, pas assez pour nous inquiéter... Un autre effet qui devient de plus en plus important est que la plupart de l espace d un composant est occupé par les câbles.» Dans ce cadre, [BVCG04] a conçu un compilateur de C vers Verilog qui deploit le programme dans l espace. Dans la suite de la section, nous présentons trois exemples de calculs dans l espace Reseaux de senseurs Les réseaux de senseurs [CK03, CE04] sont constitués de noeuds indépendants. Les noeuds d un réseau de senseurs sont contraints par leurs ressources : ils sont limités par la vitesse de leurs processeurs, leurs capacités de stockage et leurs bandes passantes. Ces noeuds ont un meilleur potentiel lorsqu ils travaillent en groupe plutôt qu individuellement. Dans la plupart des configurations, le réseaux doit rester opérationnel durant de longues périodes et les noeuds ne sont pas reliés entre eux ou à une source d énergie. Donc l énergie disponible (que ce soit des batteries, en puisant dans l environnement ou les deux) limite l ensemble des opérations. Afin de minimiser la consommation d énergie, beaucoup des composants des noeuds, y compris la radio, sont éteintes la plupart du temps. Les noeuds formant le réseaux sont soumis à de fortes variations dans leur connectivité à cause de leur fort couplage au monde physique et ses changements. Les senseurs embarquent souvent le système d exploitation TinyOS [LMP + 05]. Ce logiciel est constitué sur un assemblage statique de composants logiciel. Il est basé sur la gestion des événements permettant d activer que certains composants et laisser au repos les autres. Le projet Smart Dust [WLP01] décrit un mode de communication optique entre processeurs de taille millimétrique. Chaque particule (mote) consommerait plus d énergie qu elle n en reçoit. Contrairement aux applications distribués classiques l objectif n est pas de faire un calcul le plus rapidement possible mais de consommer le moins d énergie possible. Les particules communiquent par des procédés optiques [Fig. 2.13]. Les composants contenus dans une particule [HKP98] sont : transmetteur actif : laser directionnel. transmetteur passif : miroir qui renvoie la lumière ; La réception des données est optique :

44 Chapitre 2. État de l art 43 Fig. 2.13: Exemple d une poussière smart dust de la taille de 63mm 3. (Source : UC Berkeley) par caméra vidéo ; par receveur «smart pixel» MGS MGS [GM01], pour modèle général de simulation, est un langage dédié à la simulation des processus biologiques, spécialement ceux qui ont besoin de l espace pour être calculé. Dans ce type de situation, la dynamique du système est souvent spécifiées par des transformations locales sur un ensemble organisé d entité plus simple. L organisation de cet ensemble est sujet à de possibles changements drastiques au cours du temps. MGS propose une vue unifiée de plusieurs mécanismes de calcul initialement inspirée par la biologie ou les processus chimiques. MGS travaille avec des collections. Ce sont des ensembles d éléments qui ont une «structure». Nous pouvons naturellement voir une collection comme un ensemble de positions, remplies par des valeurs et organisé par une topologie définissant un voisinage pour chaque élément de la collection. Dans MGS, ces collections sont appelées «collections topologiques». Une étape de calcul typique dans MGS remplace dans une collection d éléments A, une sous-collection B par une autre collection C. La collection C ne dépend seulement de B et de ses éléments adjacents dans A. L ajout de C dans A B dépend de la forme des collections mises en jeux. Cette étape est appelée une transformation. La spécification de la collection à être substituée est réalisée par un langage de motifs basé sur les relations de voisinage induites par la topologie des collections. Un motif définit les chemins topologiques possibles dans les collections. Nous pouvons contrôler les applications des transformations avec des

45 Chapitre 2. État de l art 44 priorités, des gardiens, des gâchettes, etc... MGS inclut l idée des collections topologiques et leurs transformations dans un langage fonctionnel dynamiquement typé. Les collections sont justes de nouvelles sortes de valeurs et les transformations sont des fonctions agissant sur les collections et sont définies par une syntaxe spécifique utilisant des règles Ordinateur à réaction-diffusion Les ordinateur à réaction-diffusion [Ada04] sont des réacteurs chimiques pouvant résoudre des problèmes combinatoires avec un parallélisme naturel. Les données et les résultats des calculs sont encodés par des concentrations de reactants chimiques. Les calculs sont effectués par la diffusion et les réactions entre les fronts d éléments chimiques. Les problèmes pouvant être résolus par un ordinateur à réaction diffusion sont : planification de chemin, géométrie, portes logiques, mémoires. Bien qu il n existe pas encore de langage pour programmer ces ordinateurs, ils peuvent être contrôler en modifiant la température du réacteur, en utilisant un champ électrique, en modifiant le substrat ou son illumination. 2.4 Programmation amorphe La programmation amorphe[aac + 00] est un projet issu du MIT en 1996 définit comme «le développement des principes d organisation et des langages de programmation pour obtenir un comportement cohérent à partir de la coopération de myriades d éléments de calcul indépendantes interconnectées de manières inconnues, irrégulière et instable dans le temps». Le nombre d éléments de calcul peut être très grand (de l ordre de 10 6 à éléments). Les algorithmes développés pour les ordinateurs amorphes devront être le plus indépendant possible du nombre d éléments. L objectif de la programmation amorphe est de construire des programmes pour les éléments de calcul afin que l ensemble réalise des tâches globales. Afin d exploiter la masse des éléments, les programmes de chaque élément ont la possibilité de se spécialiser lors de l exécution. Cela donne une configuration globale pour l ordinateur amorphe. Formellement, un ordinateur amorphe [Teu04] est un couple AC = (V, E) qui représente un graphe dirigé avec : 1. V = {(x 1, y 1, z 1 ),..., (x N, y N, z N )} est un ensemble d éléments de calcul. (x i, y i, z i ) sont les coordonnées physiques dans IR 3 d un élément de calcul i. 2. N = V est le nombre d éléments de calcul ;

46 Chapitre 2. État de l art E = {(i, j) i, j V r c max } est un ensemble d arêtes, r est la distance physique entre deux noeuds i et j ; c max est la portée maximale d un élément de calcul ; 4. n(i) = {j (i, j) E} est le voisinage de l élément de calcul i ; Chaque élément de calcul occupe un espace physique et ils ne peuvent pas se superposer 18. Chaque élément de calcul i est composé d un processeur et d un moyen de communication avec le voisinage n(i). Le programme des processeurs est le même pour tous les éléments de calcul Réalisation d un ordinateur amorphe Des ordinateurs amorphes ont été réalisés ou conçus théoriquement. HC11 Gunk [Fig. 2.14] est le premier ordinateur amorphe physique réalisé en 1997 au CSAIL du MIT. Il est constitué d une ensemble de circuits imprimés reliés entre eux par des câbles. Chaque carte contient un microcontrolleur M68HC11 et est programmée directement en assembleur. Christof Teusher a conçu un ordinateur amorphe sur des FPGAs [Teu04, PT04]. Son modèle repose sur un élément de calcul appelé amorphon. Ce dernier est reproduit à l identique sur la surface du circuit. Puis il est relié à ses voisins. Fig. 2.14: HC11 Gunk, le premier prototype d ordinateur amorphe. Les éléments de calcul sont basé sur les microcontrolleurs Motorola M68HC11. Les éléments de calcul sont reliés entre eux par des câbles. (Source : MIT) 18 Dans nos simulations, nous ne tenons pas compte de cette condition imposée par la construction d un ordinateur amorphe physique.

47 Chapitre 2. État de l art 46 Smart Dust [WLP01] décrit des éléments de calculs de la taille d un grain de sable (1 mm 3 ). Leur système de communication utilise des signaux lumineux. Ce matériel s inscrit dans le cadre plus large des systèmes micro électromécaniques (MEMS) Dans sa thèse, Buterra [But02] a étudié les coûts de production d un ordinateur amorphe basé sur des éléments de calculs similaires au modèle Smart Dust. Le coût d un élément de calcul doit être faible si nous voulons que cette technologie soit adoptée. Le coût de production d un wafer 19 est resté stable au cours des dernières décennies. Le coût d un circuit intégré dépend alors du nombre de circuits fonctionnels présents sur le wafer. Ainsi la complexité d un circuit a un impact direct sur sa taille et donc sur le nombre d unités produites sur le wafer. De plus, la détection des circuits défectueux est très onéreuse et se retrouve pour une large part dans le prix final. Donc si nous permettons qu une partie des circuits produits soit défectueuse alors nous réduisons le prix de revient d un élément de calcul. Buterra propose des éléments de calcul basés sur une technologie Intel 486 cadencée à 50Mhz avec 100Ko de mémoire. Buterra a proposé un ordinateur amorphe dont les éléments de calcul sont des punaises. La tête de ces dernières contient le processeur. Chaque punaise contient deux pointes de longueurs différentes que nous fichons dans un tableau composé de deux couches électriquement conductrices. L une des couches est résistante afin que les signaux émis par un élément de calcul soient reçus que par son voisinage. Les réseaux de senseurs [CK03, ASSC02] sont des processeurs mis en réseaux ad hoc. La problématique des réseaux de senseurs est différentes de celle de programmation amorphe. Un réseau de senseurs doit produire et acheminer une information jusqu à une station de base en dépensant le moins d énergie. Des simulateurs ont été produits. Le premier simulateur d ordinateur amorphe est HLSIM [Ada97]. Réalisé en Scheme [SS75], il n est plus maintenu à l heure actuelle Réalisations L objectif de la programmation amorphe est de concevoir les programmes pour les éléments de calcul afin de réaliser une tâche globale. La complexité de cette programmation est de construire des représentations intermédiaires. Celles proches des éléments de calcul sont dites de bas niveaux et celles proches de la tâche globale sont dites de hauts niveaux. 19 Le wafer désigne une galette de semi-conducteur servant de support à la fabrication des circuits intégrés. Plusieurs circuits intégrés sont produits sur un même wafer.

48 Chapitre 2. État de l art Bas niveau Dans cette section, nous présentons les primitives bas niveaux réalisées sur les ordinateurs amorphes. Rumeur L objectif de la rumeur [DGH + 87] est d obtenir un agrément au sujet de la valeur d un paramètre. Chaque élément de calcul émet son opinion sur le paramètre. Un calcul est effectué par chaque élément en combinant les valeurs reçues de son voisinage, sans considérer l identifiant de la source. Si le calcul change l opinion de l élément alors la valeur est reémise avec la nouvelle opinion. La rumeur a l avantage d émettre dans toutes les directions et est difficilement défaillante. Son principal inconvénient est de pas connaître la source de la rumeur. Il est donc difficile de réviser une décision en cours de diffusion. Choix aléatoire Les choix aléatoires sont utilisés pour casser les symétries. Cela permet à un élément d avoir un comportement différencié par rapport à son voisinage. La manière la plus simple d utiliser le choix aléatoire est d affecter un identifiant à chaque élément. Ces derniers choisissent aléatoirement un nombre pour s identifier. Si l espace des nombres aléatoires est suffisamment grand alors la probabilité pour deux éléments de calcul proches d avoir le même identifiant est proche de zéro. Ce nombre peut donc être utilisé comme identifiant unique. Combiné avec la rumeur, le choix aléatoire peut être utilisé pour élire un leader dans l ordinateur amorphe. Chaque élément choisit une valeur aléatoire puis lance une rumeur afin de trouver la valeur minimale. L élément avec la plus petite valeur devient le leader. Pour élire un leader dans une région [CNW97], nous utilisons la rumeur pour transporter l identité du premier leader dont l élément entend parler. Chaque élément utilise un choix aléatoire pour décider de s auto-déclarer leader. S il ne reçoit pas l identifiant d un leader avant de se déclarer leader alors il propage la rumeur qu il est le nouveau leader. Champ Chaque élément de calcul peut être vu comme un champ dans un espace discret. Si l ordinateur amorphe est suffisamment dense avec nous pouvons approximer ce champs dans un espace discret [BB07b]. Certains champs peuvent être décrits avec des équations différentielles. Des modèles amorphes approximant les équations différentielles partielles ont été proposés [MR99, CN98, Rau03, Kat00]. Les méthodes amorphes sont consistantes, convergentes et stables 20 au prix de cal- 20 Nous avons eu l occasion d implémenter naïvement des équations à dérivés partielles sur un ordinateur amorphes [VC07b]. Les irrégularités du média amorphe, si elles sont pas compensées, rendent le système d équations non conservatifs.

49 Chapitre 2. État de l art 48 culs importants pour compenser le manque d information sur l état du voisinage des éléments de calcul. Gradient Le gradient est une des primitives les plus utilisées du calcul dans les ordinateurs amorphes. Cette primitive estime la distance entre un élément source et les autres éléments. Le gradient est inspiré de la diffusion d éléments chimiques dans une réaction chimique. Les gradients sont cruciaux dans l embryologie. De nombreux modèles de programmation sur les ordinateurs amorphes sont construits sur cette primitive. Nous n utilisons pas de modèles chimiques de diffusion celle-ci étant très gourmande en calcul et communications (voir le paragraphe précédent). L alternative commune est un calcul en temps linéaire faisant participer un calcul actif et relayant l information plutôt qu une diffusion passive. Le calcul d un gradient commence par initialiser tous les éléments sources à zéro. Tous les autres éléments fixent leur estimation de la distance à l infini. Les sources communiquent leurs estimations de la distance à leurs voisinages incrémentées d une unité. Quand un élément de calcul reçoit un message du voisinage, il le compare à sa propre estimation. Si la distance reçue du voisinage est plus petite alors il la choisit pour être son estimation et propage cette nouvelle estimation. Bien que la forme basique du gradient soit simple, il en existe plusieurs variations qui s adaptent mieux à leur contexte d utilisation. Quelques unes de ces variations ont été étudiées : Gradient Actif Un gradient actif [CN03] corrige sa validité en fonction des changements de sources ou des défaillances des éléments de calcul et maintient une estimation de la distance correcte. Par exemple, si la source disparaît, le gradient est déalloué. Un gradient peut aussi porter des informations de version, autorisant sa source à changer plus doucement. Gradient Doux Un gradient doux [Nag99] se corrige en faisant la moyenne des sources du voisinage. Le gradient doux apporte une meilleure estimation de la distance que le gradient normal. Gradient auto-réparateur Un gradient auto-réparateur [BBVT08, BBT07] qui se reconfigure en O(diamètre) afin de rester valide. Les gradients exposés précédemment se réparent soit en réinitialisant tout le gradient, soit en étant actif durant toutes sa durée de vie. La méthode proposée consiste à utiliser un recuit simulé, appelé contrainte et restauration de force, pour forcer la relaxation des éléments de calculs invalides.

50 Chapitre 2. État de l art 49 Polarité Un gradient peut décrémenter à partir d une valeur positive plutôt que de s incrémenter en partant de zéro [VC07b]. Cela limite la portée du gradient et par conséquent réduire les ressources utilisées mais aussi réduire une éventuelle mise à l échelle d un programme. Adaptation Comme décrit précédemment, un gradient relaxe la distance estimée. Si les communications sont chères et la précision pas importante, le gradient peut prendre la première valeur qu il reçoit et ignorer toutes les valeurs suivantes. Si nous voulons que le gradient s adapte aux changements dans la distribution des éléments ou des sources, alors les éléments ont besoin de reémettre leurs estimations à intervalles réguliers [ABS07]. Nous pouvons faire converger les estimations vers une estimation plus précise en ajoutant une force qui agit à l opposée de la relaxation. Transporteur Normalement, la distance calculée par le gradient est l information qui nous intéresse. Un gradient peut aussi être utilisé pour transmettre une valeur arbitraire provenant de la source. Dans ce cas, la valeur de chaque élément est la valeur la plus récente arrivant de la source la plus proche. Mesure de distance La mesure de la distance est dépendante de la quantité d information que nous possédons sur les positions relatives des voisins. Il est parfois avantageux d écarter un bonne information et d utiliser seulement le nombre de hops. De plus, il est plus aisé de faire un gradient adaptatif en comptant le nombre de hops. Il est possible de mettre en œuvre des distances non linéaires par exemple en faisant décroître exponentiellement le gradient. Coordonnées Pour établir un système de coordonnées [Coo99b, But07], nous choisissons deux éléments initiaux connus pour être distants. Ils sont tous deux sources d un gradient. Une paire d axe perpendiculaire est calculée à l aide du plus court chemin entre les deux sources et la médiatrice du segment séparant les sources. Le repère peut être amélioré en le normalisant si nous connaissons la distance entre les deux sources. Nous pouvons augmenter la précision en utilisant un gradient doux [Nag99]. Groupes La formation de groupes peut être accomplie en utilisant des algorithmes différents, par exemple l algorithme Club, LOCI, ou les nœuds persistants [Bea03b]. Les groupes peuvent eux même être groupés afin de former des hiérarchies de groupes [Bea03a]. Ainsi l algorithme «Club»[CNW97, NC98] qui permet de composer des groupes appelés «club».

51 Chapitre 2. État de l art 50 Chaque club possède les propriétés suivantes : 1. tous les processeurs appartiennent au moins à un club ; 2. tous les clubs ont le même diamètre maximum ; 3. un élément de calcul d un club peut communiquer avec tout les éléments de calcul de son groupe en utilisant que des éléments de calcul de son groupe. La construction d un club de la façon suivante : chaque élément de calcul choisit un nombre aléatoire qui est placé dans un compteur. Ce compteur est décrémenté ; quand le compteur arrive à 0, l élément de calcul envoie un message de recrutement au voisinage ; les éléments de calcul recevant un signal de recrutement avant d atteindre zero cessent de décompter et appartiennent au club Haut niveau Dans cette section, nous présentons des langages de haut niveaux réalisés sur les ordinateurs amorphes. Ecoli Ecoli [Coo07] est un langage pour les ordinateurs amorphes associé au simulateur HLSIM 21. Le langage Ecoli est piloté par les messages. Un programme Ecoli est une collection de comportements (behaviour). Un comportement est une collection de dictionnaires (dictionnary). Les dictionnaires associent des types de messages à des traitements. Un comportement peut être vu comme une machine à états finis. Les états sont représentés par les dictionnaires. Chaque instance d un comportement contient en plus des dictionnaires : la référence d un dictionnaire actif. Il ne peut y avoir qu un seul dictionnaire actif à la fois. C est l état courant de la machine à états finis. des variables globales des variables locales La figure 2.15 montre un exemple de déclaration d un comportement avec Ecoli. Growing Point Language Growing Point Language [Coo99a] de Daniel Coore démontre qu un ordinateur amorphe peut être configuré à l aide d un programme commun à tous les éléments afin de générer des motifs complexes. Par exemple, 21 Le simulateur n étant plus maintenu et obsolète, un nouveau simulateur de référence est en cours de réalisation par nos soins dans le cadre d une collaboration avec Daniel Coore. Ce nouveau simulateur permettra de produire une implémentation de référence d Ecoli ainsi que d autres langages pour ordinateurs amorphes.

52 Chapitre 2. État de l art 51 1: (define-behaviour find-dist ((current-dist +MAX+)) (define-dict default (DIST (src-id n) 5: (guard (< n current-dist)) (set current-dist n) (send DIST src-id (+ n 1))) (ACTIVATE () (set current-dist 0) 10: (send DIST my-id 1)))) Fig. 2.15: Déclaration d un comportement avec Ecoli. Ce comportement calcule la distance entre une source et l élément courant. Ce comportement démarre lors de la réception d un message ACTIVATE. La distance est initialisée à 0 puis le message DIST est émis. Lors de la réception d un message DIST, la distance courante est mise à jour et une nouvelle distance est émise. GPL peut générer des motifs représentant les interconnexions d un circuit électrique donné (voir la figure 2.16). GPL s est inspiré d une métaphore botanique basée sur des bourgeons (growing point) et des tropismes 22. Un bourgeon est un point d activité dans un ordinateur amorphe. Un bourgeon propage son activité d un élément de calcul à son voisinage. Les éléments de calcul sécrètent des «signaux chimiques» qui forment des gradients attirant ou repoussant les bourgeons dans la direction des tropismes donnés par le programmeur. Daniel Coore a démontré que ces mécanismes sont suffisants pour permettre à un ordinateur amorphe de générer n importe quelle structure donnée de graphes et a illustré cela en produisant des trains d inverseurs. Mais une fois le pattern construit, GPL n a pas de mécanisme pour le maintenir en place si la structure de l ordinateur amorphe change. Le langage ne possède pas de structure linguistique pour créer des formes arbitraires à partir des bourgeons. Plus récemment, Gayle et Coore ont montré comment étendre GPL pour produire des patterns plus gros comme par exemple des chaînes de texte [GC06]. Auto-assemblage basé sur l origami Nagpal [Nag01] a développé un prototype de modèle inspiré de l origami pour contrôler un ordinateur amorphe. Elle a montré comment organiser un programme pilotant les éléments de calcul d un 22 Tropisme [Wik07b] : En physiologie végétale, un tropisme est une réaction d orientation des organes d une plante (racines, tiges, feuilles, fleurs, etc.) à une anisotropie de milieu. La lumière et la gravité sont les deux principaux facteurs du milieu respectivement responsables des phototropismes et des gravitropismes (aussi appelés géotropismes).

53 Chapitre 2. État de l art 52 Fig. 2.16: Circuit CMOS d une porte ET construit avec GPL. Le modèle est donné sur la figure de gauche. Sur la figure de droite, le même circuit tracé par GPL. (Source : [Coo99a]) ordinateur amorphe pour construire des formes prédéterminées globalement. Sa méthode permet au programmeur de spécifier une séquence de pliages. L ensemble des pliages disponibles [HS89] est suffisant pour reproduire n importe quel origami. Nagpal a montré que ce langage de pliage peut être compiler vers un langage bas niveau qui peut être distribué, comme GPL de Coore, à tous les éléments de calcul. À partir de quelques éléments de calcul initialement différents, les éléments de calcul interagissent avec leurs voisinages et se «plient» pour construire la forme prédéterminée. La technique est plutôt robuste. Nagpal a étudié la sensibilité de son système aux erreurs de communication, à la mort aléatoire d éléments et la densité des éléments. La langage de description des origamis possède plus de structures que la langage GPL, notamment car les constructions de l origami peuvent se combiner. Par contre, une fois qu une forme est construite, il est difficile de maintenir la forme si le médium amorphe bouge. Recrutement Dynamique Dans l «ordinateur que l on peint» [But02] de Butera, des programmes recrutent dynamiquement des éléments de calcul de l ordinateur amorphe. Comme exemple, Butera utilise le recrutement dynamique pour implémenter un stockage robuste d images et de sons. Les fragments d images et de sons circulent librement dans l ordinateur amorphe et sont conduits vers un port de sortie lors d une lecture. Pour augmenter la robustesse, il y a plusieurs copies des fragments d images en basse résolutions et moins de fragments des images en hautes résolutions. Comme cela, les images sont difficiles à détruire. En effet en cas de pertes de segments, les images sont seulement dégradées mais pas détruites.

54 Chapitre 2. État de l art 53 Clément et Nagpal [CN03] utilisent le recrutement dynamique pour la construction des gradients actifs (voir la section ). Croissance et Régénération Kondacs [Kon03] a montré comment synthétiser des formes arbitraires en les faisant croître dans un ordinateur amorphe. Chaque élément de calcul contient le même programme. La croissance est implémentée en autorisant les cellules à se multiplier. Chacune de ces cellules peut créer un fils et le placer aléatoirement sur un anneau autour de sa cellule mère. Les cellules peuvent aussi mourir. L apoptose 23 permet à Kondacs d utiliser temporairement un échafaudage lors de croissance d une forme complexe. Son système est robuste, peut être mis à l échelle et possède des capacités auto-réparatrices. 1: (def gradient (src) (1st (rep (tup d v) (tup (inf) 0) (mux src (tup 0 0) ; source (mux (max-hood+ 5: (<= (+ (nbr d) (nbr-range) (* v (+ (nbr-lag) (dt)))) d)) (tup (min-hood+ (+ (nbr d) (nbr-range))) 0) (let ((v0 (/ (radio-range) (* (dt) 12)))) (tup (+ d (* v0 (dt))) v0))))))) 10: (blue (gradient (sense 1))) Fig. 2.17: Programme Proto calculant un gradient. Abstraction de la continuité de l espace et du temps Les éléments de calcul d un ordinateur amorphe étant distribués dans l espace alors si les éléments de calcul sont suffisamment denses, nous pouvons imaginer que les éléments remplissent l espace. Beal et Bachrach [BB06, BB07a] ont créé une abstraction de programmation qui voit l espace comme un objet à programmer plutôt qu une collection d éléments de calcul. Pour cela, ils ont développé un langage de programmation, Proto, où le programmeur manipule des champs de valeurs s étendant sur tout l espace. Les primitives sont conçues pour simplifier la compilation d opérations globales en opérations locales à chaque point de l espace. Chaque élément de calcul représente une portion de l espace ce qui donne une approximation des opérations sur l espace total. Les programmes sont spécifiés par des unités 23 L apoptose désigne la mort cellulaire programmée. C est un processus important le développement embryonnaire.

55 Chapitre 2. État de l art 54 spatiales et temporelles qui sont indépendantes de la distribution ainsi que des particularités des communications et de l exécutions de celles-ci. Les programmes sont écrits fonctionnellement autorisant une écriture simple de programmes complexes. Proto est porté sur des réseaux de senseurs, essaims de robots et robots modulaires. Le langage Regiment de Newton [NB02, NMW07] travaille également avec un espace vu comme continu. Regiment s articule autour d opérations sur des flux où chaque flux représente les variations temporelles d une quantité dans une partie de l espace. Regiment aussi a un langage fonctionnel. Ce dernier est conçu pour accumuler les flux d une région en un seul point. 2.5 Conclusion Dans ce chapitre, nous avons présenté un état de l art du calcul distribué et de la programmation amorphe. Nous avons également passé en revu des exemples de calculs distribués inspirés de la nature, des exemples de langages et de programmations amorphes s inspirant du calcul spatial et de la nature. De ces exemples, nous construisons notre simulateur d ordinateurs amorphes ainsi que le langage bas niveau pour les programmer.

56 Chapitre 3 Langage de programmation amorphe Dans ce chapitre, nous présentons Tical 1 : notre langage dédié [MHS05] bas niveau à la programmation amorphe et notre simulateur. Nous commencerons par décrire le modèle de nos ordinateurs amorphes ainsi que le simulateur. Puis nous introduisons Tical, notre langage orienté aspect et composant. Nous commençons par introduire la notion d aspect, puis nous détaillons les aspects dans un composant unique. Nous continuons par une description des composants et des nouvelles règles de composition des aspects que ces derniers impliquent. Nous terminons ce chapitre par deux exemples illustrant notre langage. 3.1 Modèle d ordinateurs amorphes Nos ordinateurs amorphes [VC06] sont constitués de plusieurs milliers d éléments de calcul répartis uniformément sur une surface carrée. Nos éléments de calcul contiennent [Fig. 3.1] : un programme p. Ce programme est scindable en plusieurs parties : réception des messages, réaction à certains états de l élément, programme général ; n états privés étiquetés e 1, e 2... e n. Le programme p peut lire et modifier ces états sans restriction. Un de ces états est l identifiant de l élément de calcul. Il est déterminé aléatoirement à la mise en route de l élément de calcul ; 1 Tical est l acronyme de Tical is component and aspect language ou, suivant le contexte, Tical is C amorphous library. Mais Tikal était également une des principales cités Maya située dans l actuel Guatemala. À son apogée, elle comptait plus de habitants. Elle fut abandonnée vers la fin du X ième siècle. 55

57 Chapitre 3. Langage de programmation amorphe 56 n états publics appelés messages et étiquetés m 1, m 2... m n. Ces messages sont transmis aux éléments de calcul voisins à chaque modification de l état public ; un tableau noir [CGJ87] de taille v n contenant les états publics des éléments de calcul voisins avec v la taille maximale du voisinage. Ce tableau noir est mis à jour lors de la réception d un message ; une pile pouvant recevoir des états privés locaux. Element de calcul p : programme pile 0..* état état privé 1 1 tableaux noir voisinage état public Fig. 3.1: Diagramme de classes UML d un élément de calcul. Ce modèle masque les communications entre les éléments de calcul. Ces dernières étant abstraites par les états publics et le tableau noir. L émission d un message m est effectuée en mettant à jour bl état public m. La taille v = c d est estimée lors de la création de l élément de calcul en fonction de la densité d attendue de l ordinateur amorphe. Sur des éléments de calcul ne disposant pas de tableaux noirs, nous pouvons le construire comme ceci : 1. nous allouons l espace mémoire v n dédié au tableau noir ; 2. lors de la réception d un message, nous copions son contenu dans le tableau noir à une adresse fonction de l index de l émetteur du message et de l état public dénoté par ce dernier. 3.2 Simulations Nos simulations simulent des ordinateurs amorphes de plusieurs dizaines de milliers à plusieurs millions 2 d éléments de calcul exécutant le même programme. Il est conçu autour d une architecture simple [Fig. 3.2] devant offrir de bonnes performances : une table contient l état complet de tous les éléments de calcul : les états privés, les états publics et les coordonnées de l élément de calcul. Le tableau noir est obtenu dynamiquement en consultant les états publics des éléments 2 Rappelons que le nombre d éléments de calcul est limité par la taille des tableaux du langage C soit 2 32 sur nos machines 32 bits.

58 Chapitre 3. Langage de programmation amorphe 57 voisins. Les coordonnées ne sont utilisées que par les outils d analyses dynamiques de la simulation (traces des états, visualisation) ; une table contient le voisinage de tous les éléments de calcul. Le voisinage ne conserve que des références sur les voisins et est calculé une seule fois au début de la simulation ; un ensemble de threads 3 de gestion des messages ; un ensemble de threads de gestion du comportement général des éléments de calcul ; un thread d analyse des données ; un thread coordonnant l ensemble des threads de la simulation. Lors de l initialisation de la simulation, les éléments de calcul sont répartis sur une surface plane carrée. Cette surface n est pas cyclique. Par défaut, les éléments de calcul sont répartis uniformément sauf si un masque de densité est fourni (voir la section 3.6). Le masque de densité 4 contrôle la probabilité qu une position contienne un élément de calcul. Alors le voisinage de chaque élément de calcul est construit. Puis pour chaque élément de calcul, nous appliquons la fonction d initialisation. Lors de l exécution, le thread coordinateur distribue aléatoirement les éléments de calcul à traiter aux threads en charge du comportement des éléments de calcul et du traitement des messages. Un des threads traitant les messages se voit alors associé un élément de calcul et parcourt le tableau noir de celui-ci. Si un programme est associé au type du message actuellement traité alors il est immédiatement exécuté. Le tableau noir parcouru, le thread demande un nouvel élément de calcul au coordinateur et le cycle recommence. Les threads traitant le comportement des éléments de calcul fonctionnent selon le même schéma d exécution que les threads traitant les messages. Nous avons évalué expérimentalement les performances de notre simulateur. Pour cette évaluation, nous disposons de deux machines de références : un ordinateur possédant un processeur Intel Pentium 3 cadencé à 800 MHz et disposant de 256 Mo de RAM. Le système d exploitation est GNU/Linux 2.6 ; un ordinateur possédant un processeur Intel Pentium 4 cadencé à 2.8 Ghz et disposant de 1 Go de RAM. Le système d exploitation est GNU/Linux Un thread (processus léger en français) sont des fils d exécution partageant les ressources d un processus. Ce partage de ressources implique qu elles peuvent être manipulées simultanément par plusieurs threads en même temps. Nous pouvons protéger les accès concurrents aux ressources en utilisant des verrous (mutex). 4 Dans la pratique, ce masque est une image à 256 niveaux de gris. Le niveau 0 (noir) indique la densité minimale alors que le niveau 255 (blanc) est la densité maximale. Nous construisons ces masques avec le logiciel GIMP.

59 Chapitre 3. Langage de programmation amorphe 58 Simulation <<tableau>> états <<Thread>> gestionnaire messages <<Thread>> traitement messages <<tableau>> voisinage <<Thread>> gestionnaire comportement <<Thread>> execution comportement <<Thread>> analyse Fig. 3.2: Diagramme UML d objets d une instance du simulateur. La simulation choisie pour cette évaluation est un calcul de 5 gradients. La section décrit le programme utilisé. Nous avons réparti uniformément n éléments de calcul dans un plan de 100 unités 100 unités. Le rayon de communication est de 1 unité. Notre simulation a une complexité spatiale en O ( s 0 + n(n e + nπ S )) = O(n+n 2 ) où s 0 est la taille processus avant l allocation de la mémoire des éléments de calcul et de la table de voisinage, n e le nombre d états privés et publics d un élément de calcul et S la surface couverte par l ordinateur amorphe. Le facteur nπ S représente le nombre moyen d éléments de calcul dans le voisinage, ce qui minimise l importante du facteur en n 2. Nous avons en moyenne 15 voisins dans la simulation de éléments de calcul 5. La table 3.1 nous confirme ces résultats pour les deux machines de références. La complexité temporelle est en O ( n(t 1 + t 2 nπ S )) = O(n + n 2 ) où t 1 est le temps moyen d exécution du comportement d élément et t 2 le temps moyen de traitement d un message dans le tableau noir. Au vue de la table 3.1 et en prenant pour référence le temps de calcul pour éléments, l évolution du temps de calcul s associe par interpolation directe à une fonction : pour le Pentium 3 : x x ; pour le Pentium 4 : x x La consommation mémoire s associe par interpolation directe à une fonction : pour le Pentium 3 : x x pour le Pentium 4 : x x Si les éléments de calcul sont de la taille d un grain de sucre, nous avons besoin de 10 morceaux de taille mm.

60 Chapitre 3. Langage de programmation amorphe 59 machine nombre mémoire temps temps de calcul d évaluation d éléments consommée (Mo) d initialisation (sec) pour 100 cycles (sec) Pentium MHz Mo Pentium GHz Go Hyper Threading Tab. 3.1: Performances de la simulation «gradient» dans un carré de 100 unités 100 unités avec un rayon d émission de 1 unité. Le profil de ces fonctions nous permet de vérifier les complexités en espace et en temps énoncées plus haut Comparaison des performances entre notre simulateur Tical et Proto Nous comparons les temps de calcul entre Proto [BB07a] et notre simulateur. Pour cela, nous mesurons les temps de calcul sur une simulation de calcul de gradient en fonction du nombre d éléments de calcul. Le programme utilisé par Tical est décrit à la section Le programme utilisé par Proto est donné dans la figure Nombre d éléments Temps de calcul Rapport de calcul Tical Proto Proto/Tical Tab. 3.2: Temps de calcul de Tical et Proto pour simuler la couverture d un ordinateur amorphe par un gradient. Nous avons effectué cette expérience sur un ordinateur équipé d un processeur Intel Core2 Duo T7500 et 2Go de mémoire vive. Le système d exploitation est GNU/Linux Le rayon de communication des éléments de calcul est de 5 unités sur un espace à deux dimensions carré de 100 unités de côté.

61 Chapitre 3. Langage de programmation amorphe Tical Proto temps de simulation en secondes nombres d elements de calcul Fig. 3.3: Comparaison des performances de Tical et Proto. La figure 3.3 montre les résultats de cette expérience. Nous remarquons sur la table 3.2 que Tical est en moyenne 50 fois 6 plus rapide que Proto. Nos performances s expliquent ainsi : nous compilons nos simulations en exécutable par l intermédiaire du langage C (voir le compilateur à la section 3.7) et nous n utilisons pas de machine virtuelle ; notre choix de n utiliser que des tableaux noirs pour abstraire les communications et de ne pas chercher à fournir un simulateur général nous permet de faire l économie de la gestion des files d attentes des messages entrant et sortant dans chaque élément de calcul ; notre système d analyse des résultats des simulations est découplé du calcul proprement dit (voir la section 3.6). Cela nous permet de contrôler le temps consommé à collecter les données ou à les afficher. 3.3 Modèle de conception du langage Tical Tical est le langage orienté aspect et composant que nous avons développé afin de programmer les éléments de calcul de nos ordinateurs amorphes. L objectif de ce langage est de : 1. pouvoir décrire les différentes parties d un programme embarqué dans un 6 La moyenne du rapport des temps de calcul sur notre expérience est plus précisément de

62 Chapitre 3. Langage de programmation amorphe 61 élément de calcul comme l initialisation, le traitement des messages, le comportement global d un élément de calcul ; 2. pouvoir construire et utiliser des abstractions regroupant toutes les parties d un programme. Le premier objectif est réalisé à l aide de la programmation par aspect. Ce paradigme de programmation a pour but de séparer les différents intérêts d un programme. Par exemple, grâce à ce paradigme, nous pouvons aisément séparer le traitement des messages reçus du voisinage du calcul intrinsèque d un élément de calcul. Un compilateur, appelé tisseur d aspects construit alors le programme final en agrégeant les aspects fournis par le programmeur. Dans notre langage, nous séparons nos programmes en six aspects : déclaration des composants, déclaration des états privés et publics, initialisation, traitements des messages, comportement général et analyse. Chaque aspect peut être écrit dans un dialecte qui lui est propre [Fig. 1.3]. Le second objectif est achevé par l ajout des composants. Un composant encapsule les différents aspects d un programme effectuant une tâche donnée et peut utiliser d autres composants. Le tisseur d aspects réduit les aspects contenus dans les composants en aspects uniques avant de les compiler. Le système Tical est architecturé en 5 niveaux dont deux définissent le langage Tical à proprement parler [Fig. 3.4] : le premier niveau (ne faisant proprement pas parti du langage) est le système objet proposé par le langage d implémentation. Nous choisissons Scheme [gui06] étendu par GOOPS [goo06] ; le niveau méta-modèle définit les concepts d aspect et de composant du langage. À partir de ce niveau, nous pouvons définir différents langages orientés aspect et composant. Un utilisateur peut y accéder pour implémenter des aspects non prévus. Nous montrons comment procéder dans la section ; le niveau modèle définit les aspects utilisés par le langage pour décrire les programmes des éléments de calcul des ordinateurs amorphes et les méthodes d assemblages des composants ; le niveau utilisateur contient la bibliothèque de composants de l utilisateur ainsi que ses programmes ; le niveau simulation est le programme compilé prêt à être exécuté. Notre modèle de conception est inspiré du modèle en quatre couches de l infrastructure d UML 2 [OMG05a] : méta-méta-modèle, méta-modèle, modèle, instance.

63 Chapitre 3. Langage de programmation amorphe 62 système Classe Tical metamodèle <<metaclass>> Composant 0..* 1..* <<metaclass>> Aspect modèle Composant Aspect * utilisateur Composant 1 0..* <<compilation>> simulation 1..* SimulationExecutable Fig. 3.4: Modèle conceptuel du système Tical. Le langage est construit au dessus d un système objet. Le méta-modèle décrit les concepts d aspect et de composant. Le modèle implémente les aspects et composants du méta-modèle pour la programmation amorphe. Les utilisateurs écrivent leurs programmes en utilisant le modèle. Les programmes des utilisateurs sont compilés en simulation.

64 Chapitre 3. Langage de programmation amorphe Aspects Dans cette section, nous commençons par présenter la programmation par aspect puis exposerons le modèle d aspects utilisé dans Tical. Nous concluons par une description des aspects nous permettant de programmer les éléments de calcul de nos ordinateurs amorphes Programmation par aspect La programmation par aspect [KLM + 97] est une des évolutions de la programmation objets. Elle sépare les différents intérêts d un programme en aspects. Chaque aspect est programmé indépendamment, elle permet alors le mélange de plusieurs paradigmes de programmation dans un même programme. Chacun s exprimant dans le dialecte qui lui est le plus naturel. Ainsi, la programmation par aspect 7 simplifie l expression des problèmes sans en masquer la complexité. 7 Nous pensons que la programmation par aspect peut être appliquée à la construction d agglutinations dans les langages informatiques. Une langue (naturelle) agglutinante est une langue dans laquelle le vocabulaire est formé en assemblant des éléments basiques (souvent) invariables. Les langues Basque, Japonaise, Turques sont agglutinantes. Elles se distinguent des langues isolantes et des langues flexionnelles. Les mots des langues isolantes ont tendances à être invariables alors que dans les mots des langues flexionnelles changent de formes selon leurs rapports grammaticaux. Ainsi le Thaïlandais est une langue isolante où, par exemple, «oui» se dit (tchaï) alors qu une façon de dire «non» est (maïtchaï, littéralement «pas oui»). Les alternatives courantes à sont (haam), (mii, plus formel que ). De même, l Anglais est une langue plus isolante que le Français dont la conjugaison et les accords en nombres et en genres constituent autant de flexions. Si nous cherchons à appliquer la même classification aux langages informatiques, nous nous apercevons qu ils sont en général isolants. Toutefois des flexions existent dans certains d entres eux. Ainsi les variables du langage Perl sont préfixées par un des symboles suivant ou % modifiant la signification de la variable en simple variable, tableau ou table de hachage. Dans le langage Python, les méthodes privées sont préfixées du symbole. Des termes agglutinants sont présents dans les bibliothèques de nos langages. Par exemple, la classe FileCacheImageOutputStream définit dans la langage Java (version 1.4 et plus) se lit comme l agglutination de plusieurs termes. Comment automatiser l utilisation de telles agglutinations sans toutes les définir explicitement? Le parseur détecte l agglutination et la décompose en aspects. Alors le tisseur d aspect les assemble pour former le programme à exécuter. Dans le cas de la classe FileCacheImageOutputStream, nous pourrions avoir : (defclass agglutination (aspect) ()) Nous définissons les agglutinations comme des aspects. Puis nous enrobons la déclaration des agglutinations de sucre syntaxique : (defagglutination File :before (Cache *) :after * (do-file-stuff)) (defagglutination Cache :before * :after * (do-cache-stuff)) (defagglutination Image :before (* stream) :after *

65 Chapitre 3. Langage de programmation amorphe 64 Cette approche est couramment utilisée dans d autres domaines technologiques. Par exemple, le mécanicien travaille avec des schémas statiques, dynamiques ou thermiques d un système mécanique [Che89]. L électronicien utilise plusieurs diagrammes : circuits des composants, chronogrammes, diagrammes de phases. Le langage de description des circuits intégrés VHDL [Ska96] sépare un composant matériel en plusieurs aspects : l entité : l interface attendue avec le monde extérieur ; l architecture : la description réelle du composant, séparée elle même en deux aspects : description structurelle utilisant des portes logiques pour spécifier le comportement attendu ; description logique utilisant un langage de plus haut niveau que l aspect précédant. Plus près de l informatique 8, le langage UML [OMG05b] a la même approche vis à vis de la modélisation des systèmes informatiques en proposant différents diagrammes. Par exemple, si nous concevons un programme de calcul avec des aspects, nous pouvons extraire un aspect calcul, un aspect stabilité numérique, un aspect interface utilisateur, un aspect traitements des erreurs, un aspect débugage. Cette séparation n est pas unique et d autres peuvent être proposées. Chaque aspect est programmé de la manière la plus naturelle. Le compilateur retisse les liens entre les différents aspects pour former l objet proprement dit. Les implémentations des langages de programmation par aspect proposent des points de rencontre (joinpoint) décrivant les positions dans le programme où les aspects pourront intervenir. (do-image-stuff)) (defagglutination Output :before (* stream) :after * (do-output-stuff)) (defagglutination Stream :before (* output) :after * (do-stream-stuff)) Le rôle du tisseur d aspect a alors la charge de reconstituer le programme complet de FileCacheImageOutputStream : (define-aspect-combination FileCacheImageOutputStream (do-file-stuff) (do-cache-stuff) (do-image-stuff) (do-output-stuff) (do-stream-stuff)) ou la variation suivante : (define-aspect-combination FileCacheImageOutputStream (do-file-stuff (do-cache-stuff) (do-image-stuff (do-output-stuff) (do-stream-stuff)))) Nous ne donnons pas les détails de l implémentation du tisseur d aspect. 8 Le langage UML peut modéliser des systèmes non informatique comme le montre très bien [SG05]. Par ailleurs, l UML peut se révéler contre productif si nous cherchons à être trop proche du programme final [Tho03]. Le piétinement des MDAs montre les limites d UML appliqué à l informatique.

66 Chapitre 3. Langage de programmation amorphe 65 aspect 2 pointcut: j (define method (compile (e <environment>) (l <list>)) (if (memq (car l) *known functions*) (compile function call l) (let ((proc (primitive eval (car l))) (args (cdr l))) (if (procedure? proc) (primitive eval (,proc,@(compile all arguments e args))) (apply macro e proc args))))) aspect 3 pointcut: j (define method (compile (e <environment>) (l <list>)) (if (memq (car l) *known functions*) (compile function call l) (let ((proc (primitive eval (car l))) (args (cdr l))) (if (procedure? proc) (primitive eval (,proc,@(compile all arguments e args))) (apply macro e proc args))))) flux de contrôle aspect 1 (define method (compile (e <environment>) (l <list>)) (if (memq (car l) *known functions*) (compile function call l) (let ((proc (primitive eval (car l))) (args (cdr l))) (if (procedure? proc) (primitive eval (,proc,@(compile all arguments e args))) (apply macro e proc args))))) ;; (add know funct) (set! *known functions* (rand printf fabs exit)) (define (compile function call l) (make <compilation unit> #:text (format #f "~a(~{~a~^, ~})" (car l) (map cu text (map compile (cdr l)))))) (define jointpoint (apply macro env proc args) j (let ((macro (assoc proc *primitive macros*))) (if macro (apply (cadr macro) env args) (primitive eval (,proc,env,@args))))) ;;;. 3.2 Compilation des fonctions de base (define (make infix symb a b) (make <compilation unit> #:text (format #f "(~a~a~a)" (cu text a) symb (cu text b)))) Fig. 3.5: Principe de la programmation par aspect. Le flux de contrôle exécute l aspect 1 jusqu à ce qu il arrive au point de rencontre j instrumenté par d autres aspects. Dans ce cas, il exécute tous les aspects dont le point d action est j avant de reprendre son cours normal. De plus, les implémentations permettent au programmeur de préciser les éléments suivants : des points d action (pointcut) décrivant les points de rencontre où l aspect s insérera ; les programmes activés par les points d actions. L implémentation de référence de la programmation par aspect est AspectJ [KHH + 01] développée par le fondateur de cette méthode. AspectJ se présente comme une extension du langage Java ajoutant les aspects au système objet existant. Dans ses premières versions, AspectJ proposait un système de points de rencontre définis par des étiquettes. Les versions récentes proposent des points de rencontre dynamiques tels que : appels de méthodes, appels de constructeurs, retours de méthodes, retours de constructeurs, exécutions de méthodes, exécutions de constructions, lectures d un attribut, écritures d un attribut, levé d une exception, initialisations d un objet. Kiczales nous présente l exemple suivant : soit le modèle objet de figure géométrique présenté dans la figure 3.6. Une figure peut être, soit un point, soit une ligne. Chacune de ces deux classes de figures peut être déplacée. Dans le langage Java [Cor07], ce modèle est classiquement implémenté en capturant les déplacements dans une interface «déplaçable» qui oblige à implémenter, dans toutes les classes, les méthodes de l interface. Une méthode alternative est d utiliser le patron de conception 9 [GHJV95] Délégué [C203]. Ce patron de conception est utilisé 9 Les patrons de conception (traduction de l anglais design pattern) sont des méthodes destinées à résoudre des problèmes récurrents rencontrés dans la conception des logiciels. Ils sont issus à l origine de l architecture des bâtiments. Aujourd hui, ils révèlent l impossibilité des langages objets courants (Java, C++,.net) à capturer linguistiquement les problèmes modernes d architecture logicielle.

67 Chapitre 3. Langage de programmation amorphe 66 pointcut move(): call(void FigureElement.setXY(int,int)) call(void Point.setX(int)) call(void Point.setY(int)) call(void Line.setP1(Point)) call(void Line.setP2(Point)); Fig. 3.6: La description en aspects d un éditeur de figures simples. L aspect Move Tracking est commun aux classes Point et Line. (extrait de [KHH + 01]) pour émuler l héritage multiple en déportant l unique implémentation d une interface dans une classe tierce puis de faire pointer chacune des méthodes à déléguer vers cette dernière classe. Ces deux méthodes nécessitent un effort de programmation conséquent : plusieurs implémentations du même code dans des classes différentes ou des délégations explicites. L approche orienté aspect permet de déporter le problème dans une structure informatique unique : l aspect MoveTracking. Ce dernier spécifiant le point de coupures tout comme le code à exécuter [Fig. 3.6]. Un second exemple d utilisation de l approche par aspect est la suivante : nous souhaitons suivre l utilisation d un ensemble de méthodes et en garder une trace dans un journal. En programmation objet classique, le programmeur doit définir une infrastructure de journalisation et instrumenter, souvent manuellement, les méthodes. Avec la programmation par aspect, le programmeur définit toujours une infrastructure de journalisation mais instrumente automatiquement les méthodes en les spécifiant dans les points de coupure.

68 Chapitre 3. Langage de programmation amorphe Tical : Langage de programmation aspect Le langage Tical est architecturé en deux niveaux [Fig. 3.4] : le méta-modèle et le modèle. Le méta-modèle définit l infrastructure servant à construire les aspects et les composants du modèle. Ce dernier est spécialisé pour la programmation des ordinateurs amorphes. Joinpoint +compile() +add aspect(a : Aspect) LabelJoinpoint +label Fig. 3.7: Diagramme UML de classes des points de rencontre. Les points de rencontre étiquetés (LabelJoinpoint) héritent des points de rencontre génériques (Joinpoint). Le méta-modèle de Tical propose un modèle d aspects utilisant des points de rencontre génériques. Cette approche nous permet d utiliser tous les types de points de rencontre possibles. Ces derniers peuvent alors être construits par héritage. Comme le montre la figure 3.7, un point de rencontre générique doit répondre à deux fonctions : l enregistrement d un nouvel aspect avec add-aspect ; la compilation avec la fonction compile, les aspects enregistrés dans ce point de rencontre sont réunis en une seule séquence de calcul. Le cycle de vie d un aspect et d un point de rencontre [Fig. 3.8] commence par la création d un point de rencontre. Puis, nous créons un aspect en lui précisant quels sont les points de coupure où il peut intervenir. Les points de rencontre correspondant aux points de coupure sont calculés et l aspect est enregistré dans chacun d eux. Pendant la compilation, tous les aspects associés aux points de rencontre sont compilés. L implémentation actuelle des aspects dans le méta-modèle n utilise que des points de rencontre étiquetés [Fig. 3.7]. Ces points de rencontre repèrent des positions dans les programmes par des étiquettes. Nous construisons de telles étiquettes avec la fonction make-label-joinpoint. Les points de rencontre étiquetés sont déclarés dans le corps des aspects avec le fonction label-joinpoint. Le même point de rencontre peut être utilisé à plusieurs endroits différents. Lors de la déclaration d un point de rencontre, deux autres points de rencontre sont implicitement créés. Le premier exécute les aspects qui lui sont associés avant

69 Chapitre 3. Langage de programmation amorphe 68 Programme Meta programme 1: creation j : Joinpoint 2: creation a : Aspect 3: add aspect() 4: compile() 5: compile() Fig. 3.8: Diagramme UML de séquences du cycle de vie d un point de rencontre et d un aspect. le point de rencontre et le second les exécute après. Les noms de ces points de rencontre sont respectivement suffixés par «:before» et «:after». Ce système est inspiré de CLOS [Pit05] où des qualificateurs peuvent être ajoutés aux méthodes afin de les combiner correctement. Un exemple de déclaration d un point de rencontre est donné dans la figure 3.9. Les aspects sont déclarés par la fonction declare-aspect où nous pouvons préciser le point de coupure utilisé. Quand l aspect est compilé, les aspects associés aux points de rencontre sont combinés puis insérés à la place de leur label respectif. La combinaison s effectue en insérant d abord les aspects associés aux points de rencontre «:before», puis ceux associés aux points de rencontre primaires et pour 1: (define pj1 (make-label-joinpoint pj1)) Fig. 3.9: Un exemple de déclaration d un point de rencontre pj1.

70 Chapitre 3. Langage de programmation amorphe 69 1: (define un-aspect (declare-aspect un-aspect #:pointcut pj1)) (define-method (compile (a <aspect-un-aspect>)) (format #f "Compile l aspect un-aspect. ")) (define un-autre-aspect (declare-aspect un-autre-aspect 5: #:pointcut pj1-before)) (define-method (compile (a <aspect-un-autre-aspect>)) (format #f "Compile l aspect un-autre-aspect. ")) (define a-un-joinpoint (declare-aspect a-un-joinpoint)) 10: (define-method (compile (a <aspect-a-un-joinpoint>)) (format #f "Avant le point de jonction. ") (label-joinpoint pj1) (format #f "Apres le point de jonction.")) Fig. 3.10: Un exemple de déclaration de deux aspects. L aspect have-a-joinpoint contient le point de rencontre pj1. Ce dernier est associé à l aspect un-aspect. finir ceux associés aux points de rencontre «:after». La figure 3.10 nous montre un exemple de déclaration de trois aspects. Le premier «un-aspect» est déclaré pour s exécuter au point de coupure pj1. Il se compile pour produire la chaîne de caractères «Compile l aspect un-aspect». Le deuxième «un-autre-aspect» est associé au point de rencontre pj1 mais sera exécuté avant l aspect «un-aspect». Compilé, il affiche la chaîne de caractères «Compile l aspect un-autre-aspect.» Le dernier aspect, «a-un-joinpoint», contient le point de rencontre pj1. Lors de la compilation, l aspect un-aspect sera compilé en un programme produisant ainsi la chaîne de caractères : «Avant le point de rencontre. Compile l aspect un-autre-aspect. Compile l aspect un-aspect. Apres le point de jonction.» Aspects pour la programmation amorphe Après avoir présenté le méta-modèle de Tical dans le section précédente, nous présentons, dans cette section, les aspects du modèle défini par Tical [VC07a] pour programmer les éléments de calcul d un ordinateur amorphe. Cet ensemble d aspects constitue la base du langage et peut être augmenté lors de la construction de langages de plus haut niveau. Cinq catégories d aspects sont déclarées dans le modèle : déclaration d une machine avec les gestions de la mémoire et son état initial ; prise en compte des composants (voir la section 3.5.1) avec leurs inclusions

71 Chapitre 3. Langage de programmation amorphe 70 et leurs paramétrages ; calcul général et calcul lors de la réception d un message ; abstraction fonctionnelle ; évènements extérieurs à l élément de calcul comme l analyse des données et des actions programmées. La grammaire des différents aspects est donnée dans la figure 3.11 et la grammaire des expressions contenues dans les aspects est donnée dans le figure composant (make-component identifiant aspect *) (1) aspect #:uses (( identifiant identifiant clause-paramètre *)+) (2) #:options ( option-composant +) (3) #:documentation chaîne (4) #:parameters (( identifiant type )*) (5) #:states ( description-etat *) (6) #:messages ( description-etat *) (7) #:functions (( nom-fonction ( identifiant *) expr + )+) (8) #:init:before ( expr *) (9) #:init ( expr +) (10) #:init:after ( expr +) (11) #:behaviours:before ( expr +) (12) #:behaviours ( expr +) (13) #:behaviours:after ( expr +) (14) #:message-handlers:before (( identifiant expr )+) (15) #:message-handlers (( identifiant expr *)+) (16) #:message-handlers:after (( identifiant expr )+) (17) #:probes ( expr ) (18) #:divine-action (( condition expr +)+) (19) clause-paramètre #: identifiant expr (20) description-etat identifiant (21) ( identifiant (#:enum ( identifiant +))? (#:array nombre )? ) (22) option-composant static (23) Fig. 3.11: Grammaire d un composant et des aspects de Tical.

72 Chapitre 3. Langage de programmation amorphe 71 expr atome (1) fonction atome nombre (2) identifiant-ns chaîne identifiant-ns identifiant (3) espace-de-nommage : identifiant (4) identifiant symbole (5) espace-de-nommage symbole (6) type <integer> (7) <real> <string> <symbol> fonction ( operateur-binaire expr expr ) (8) ( operateur-unaire expr ) (begin expr *) (set! identifiant-ns expr ) (if expr expr expr?) (cond ( expr expr *)*) (declare ( identifiant type )+) (let (( identifiant type expr? )+) expr *) (for expr expr expr expr *) (while expr expr *) (do-while expr expr *) operateur-amorphe operateur-unaire! not (9) operateur-binaire + - * / modulo mod % (10) equals? ==!= < > <= >= and or max min operateur-amorphe read-state set-state (11) read-message set-message read-my-message draw-state param for-all-neighbours element-num with-n-elements-do with-n-elements-near-do Fig. 3.12: Grammaire d une expression de Tical.

73 Chapitre 3. Langage de programmation amorphe Aspect «Gestion de la mémoire» Tical distingue deux types de mémoires : les états privés et les états publics. Tous les états sont du type flottant double précision tel que défini par la norme IEEE 754 [IEE85]. Les états privés ne sont pas visibles par les éléments du voisinage. La ligne 6 de la figure 3.11 présente la syntaxe de cet aspect. Il suffit de donner un nom pour que l état existe. La figure 3.13 présente un exemple de déclaration de trois états privés. Le premier état déclaré [Fig ligne (1)] utilise cette première forme. La seconde forme permet de paramétrer la déclaration des états [Fig ligne (22)]. Le paramètre #:enum associe une liste de symboles à un état. Le paramètre #:array construit un tableau référencé par cet état. Deux exemples de ces déclarations sont présentés dans la figure 3.13 aux lignes (2) et (3). Tical propose deux fonctions pour accéder et modifier les états privés : read-state et set-state [Fig ligne (11)]. Ces deux fonctions peuvent être remplacées par du sucre syntaxique 10 utilisant l espaces de nommages «s» [Fig ligne (4)]. Dans ce cas, l expression «s:etat» est synonyme de «(read-state etat )» et l expression «(set! s:etat expr )» est synonyme de «(set-state etat expr )». Les éléments d un tableau sont nommés en utilisant la convention suivante : «etat index». 1: #:states (etat1 2: (etat2 #:enum (a b c)) 3: (etat3 #:array 10)) Fig. 3.13: Exemple d une déclaration de trois états privés. etat1 est déclaré en utilisant la forme simple. etat2 est un état pouvant prendre une des trois valeurs symboliques a, b, c. etat3 est un vecteur de 10 éléments. Les états publics sont visibles par le voisinage. La modification d un tel état entraîne l émission d un message. Les messages reçus sont rapportés automatiquement dans le tableau noir [CGJ87]. Ce dernier contient les états publics des voisins connus. Le tableau noir facilite la gestion des états publics. 10 «Sucre syntaxique» est une expression imaginée par Peter J. Landin en 1965 pour désigner les extensions à la syntaxe d un langage de programmation qui ne modifient pas son expressivité et le rendent plus agréable à écrire comme à lire. Par exemple dans la langage C, nous employons communément le sucre syntaxique t[i] pour désigner *(t+i). D un autre côté, nous utilisons très rarement i[t] ( t[i] si t est déclaré int t[]). Les différentes structures de boucles (while, do/while et for) sont aussi du sucre syntaxique car elles peuvent être remplacées par des combinaisons de if et goto. Alan Perlis ironise [Per82] au sujet des langages à accolades : «Syntactic sugar causes cancer of the semi-colons».

74 Chapitre 3. Langage de programmation amorphe 73 La taille du tableau noir est c R d où R est le rayon de communication, d la densité et c un coefficient de multiplication (1.5 pour les simulations 2D). Lorsque le tableau noir est plein, les nouveaux voisins sont ignorés. Cela simule indirectement des imperfections dans la communication. 1: #:messages (message1 2: (message2 #:enum (a b c)) 3: (message3 #:array 10)) Fig. 3.14: Exemple d une déclaration de trois messages. message1 est déclaré en utilisant la forme simple. message2 est un état pouvant prendre une des trois valeurs symboliques a, b, c. message3 est un vecteur de 10 éléments. Tical propose trois fonctions pour accéder et modifier les états publics : read-message, read-my-message et set-message [Fig ligne (11)]. read-message lit les états publics dans le tableau noir alors que read-my-message lit l état public de l élément de calcul. Ces fonctions peuvent être remplacées par du sucre syntaxique utilisant l espace de nommages «m» [Fig ligne (4)]. Dans ce cas, l expression «m:etat» est synonyme de «(read-message etat )» et l expression «(set! m:etat expr )» est synonyme de «(set-message etat expr )». En cas d ambiguïté avec l espace de nommage «m», celui-ci peut être remplacé par l espace de nommage «my» comme synonyme de «read-my-message» Aspect «Initialisation» Cet aspect initialise un élément de calcul. À l issu de cet aspect, la mémoire doit être prête pour l exécution de la simulation. La syntaxe de l initialisation est donnée aux lignes 10 et 11 de la figure Le corps d «init» [Fig. 3.15] est exécuté pour chaque élément de calcul. 1: #:init ((set! s:etat1 0) 2: (set! s:etat2 b)) Fig. 3.15: Exemple de déclaration d une initialisation d un élément de calcul. Les états privés etat1 et etat2 sont initialisés respectivement à 0 et b. Deux étapes de pré- et de post-initialisation sont proposées avec les aspects «init-before» et «init-after». Contrairement à l initialisation précédente qui affecte tous les éléments de calcul, cette étape permet de sélectionner un ensemble d éléments de calcul et d en modifier l état. Trois fonctions de sélection sont proposées :

75 Chapitre 3. Langage de programmation amorphe 74 (with-n-elements-do n. body) Cette fonction choisit n éléments de calcul puis, pour chaque élément de calcul choisi, exécute les instructions contenues dans body [Fig ligne (1)]. (with-n-elements-and-neighbour-do n r. body) Cette fonction choisit n éléments de calcul ainsi que leur voisinage de rayon r de l élément de calcul choisi. Les instructions contenues dans body sont exécutées pour chaque élément de calcul retenu. (with-elements-near-do x y z r. body) Cette fonction sélectionne le voisinage de rayon r autour d un point de coordonnées (x,y,x ) et exécute le programme contenu dans body. 1: #:init-after ((with-n-elements-do 3 2: (set! s:etat2 a))) Fig. 3.16: Exemple de déclaration d une post-initialisation. Trois éléments de calcul sont sélectionnés aléatoirement puis leur état privé etat2 prend la valeur a Aspect «Comportement» Les éléments de calcul ayant un comportement régulier et indépendant des messages reçus doivent implémenter cet aspect. Le corps de l aspect «behaviours» contient la séquence d instruction à exécuter régulièrement [Fig. 3.17]. 1: #:behaviours ((set! s:etat2 (+ s:etat2 1))) Fig. 3.17: Exemple de déclaration d un comportement Aspect «Réception des messages» Cet aspect gère les états publics contenus dans le tableau noir. Les paramètres contenus dans les messages sont automatiquement rapportés dans le tableau noir et par conséquent tous les états publics du voisinage alors sont accessibles via une interrogation de celui-ci. Le cycle complet des traitements des messages dans un élément de calcul est : 1. exécuter les expressions de l aspect pré-traitement des messages ;

76 Chapitre 3. Langage de programmation amorphe 75 1: #:message-handlers ((mg (set s:x (+ m:mg m:y)))) Fig. 3.18: Exemple de déclaration d un traitement de message. Lors de la réception d un message mg, le programme met à jour l état privé x en sommant les états publics mg et y reçu du voisinage. 2. pour tous les messages contenus dans le tableau noir faire (ces messages sont retrouvés en parcourant les éléments de calcul du tableau noir puis en parcourant les états publics de ces éléments) : (a) si une action est associée au type du message, on l exécute ; 3. exécuter les expressions de l aspect post-traitement des messages ; 1: #:message-handlers:before ((set! s:x 0)) Fig. 3.19: Exemple de déclaration d une initialisation d un cycle de traitement des messages. L état privé x est remis à zéro avant de traiter les messages. Syntaxiquement, cet aspect [Fig ligne (16)] est constitué d une liste de clauses. Chaque clause associe un type de message à une action [Fig. 3.18]. La clause débute par un symbole décrivant le type d un message suivi de la séquence d expressions à exécuter lors du traitement d un message de ce type. 1: #:message-handlers:after ((set! my:mg s:x))) Fig. 3.20: Exemple de déclaration d un traitement à effectuer après un cycle de traitement des messages. Le message mg est envoyé avec la valeur de l état privé x une fois les traitements des messages finis. Deux étapes de pré- et post-traitement des messages sont disponibles. L aspect pré-traitement des messages contient les expressions à exécuter au début d un cycle de lecture du tableau noir [Fig. 3.19]. L aspect post-traitement des messages contient les expressions à exécuter après un cycle de lecture du tableau noir [Fig. 3.20] Aspect «Fonction» Cet aspect permet de construire des fonctions opérant sur les états d un élément de calcul. La ligne (8) de la figure 3.11 donne la syntaxe de la déclaration de fonctions.

77 Chapitre 3. Langage de programmation amorphe 76 1: #:functions ((foo (x) (set! x s:y)) (bar () (set! s:y s:x))) Fig. 3.21: Déclaration de deux fonctions. Les fonctions opèrent sur l élément en cours de traitement. Les états accessibles dépendent de l aspect qui appelle la fonction Aspects Métas Les deux aspects suivant n interviennent pas dans le calcul mais sont utiles pour la gestion des simulations. Le premier aspect, divine-action 11, offre la possibilité à l expérimentateur de programmer des actions extérieures à la simulation. Par exemple, il peut fixer l arrêt de la simulation. La variable time contient l heure de la simulation et n est visible que dans cet aspect. Les fonctions space_dump_neightborhood_ieee et space_dump_all_ieee réalisent respectivement une copie des relations de voisinages de tous les éléments de calcul et de tous les états privés comme publics des éléments de calcul. 1: #:divine-action (((= time 100) 2: (with-n-elements-do 3: (set! s:etat2 a))) Fig. 3.22: Exemple de déclaration d une action extérieure à l ordinateur amorphe. L aspect probes permet de collecter des informations sur les noeuds. Nous pouvons déclarer cet aspect lors du paramétrage de la simulation. 1: #:probes ((draw-state st1) 2: (draw-state message)) Fig. 3.23: Exemple de déclaration d une action extérieure à l ordinateur amorphe. 11 Le nom de cet aspect est inspiré des jeux vidéos Populous et Populous II : Trials of the Olympian Gods réalisés par Bullfrog respectivement en 1989 et 1991.

78 Chapitre 3. Langage de programmation amorphe 77 Nous avons exposé, dans cette section, le première forme d abstraction de notre langage : les aspects. Ces derniers séparent les besoins et laissent le tisseur d aspect les réassembler en un programme utilisable. 3.5 Composants En l état, les aspects peuvent s utiliser simplement en les écrivant comme nous écrivons des fonctions dans les langages de programmations courants. Cette écriture ne bouleverse en rien nos habitudes de programmeur. Mais les aspects, utilisés seuls, montrent rapidement des limitations. Alors que les aspects séparent les besoins, nous ne pouvons pas séparer deux procédures utilisant les aspects proposés précédemment. Nous ne pouvons pas constituer de bibliothèque de procédures. Pour illustrer ces limitations, nous allons prendre l exemple suivant : supposons que nous voulions trouver et propager les valeurs maximales de deux états dans un ordinateur amorphe 12. Pour propager la valeur maximale d un état, nous créons un état public m m et un état privé s m. Dans l aspect comportement, nous plaçons les valeurs à propager s m dans l état public m m. À la réception l état public m m, l état privé s m est mis à jour si celui-ci est inférieur à m m. Maintenant, propager une deuxième valeur nous amène à créer explicitement deux nouveaux états et ajouter du code dans les aspects réception des messages et comportement. La lecture du programme s en trouve pénalisée au point qu il nous est presque impossible de lire un programme dépassant une page de code. Pour pallier à ces limitations, nous avons besoin d une abstraction permettant de : séparer puis regrouper les aspects participant à une même procédure dans une seule entité et ainsi se constituer des bibliothèques ; utiliser et combiner simplement ces entités ; paramétrer ses entités afin de ne pas tomber dans l écueil précédent consistant à multiplier les fragments de programmes similaires dans la bibliothèque. L abstraction retenue est le composant [McI68, Fla99]. En génie logiciel, un composant est une entité logicielle répondant à cinq critères [MS03] : un composant doit pouvoir être utiliser plusieurs fois ; un composant ne doit pas être spécifique à un contexte ; un composant peut être la composition d autres composants ; un composant est encapsulé ; un composant peut être déployé. Un composant offre un service réutilisable via une interface de programmation. 12 Nous implémentons cet exemple avec le composant propagation présenté dans la section

79 Chapitre 3. Langage de programmation amorphe 78 Les composants offrent l avantage de pouvoir constituer naturellement des bibliothèques de composants. De plus, leur maintenance est facilitée par l encapsulation. Cette dernière permet également la sous-traitance du code. D un autre côté, l utilisation des composants révèle sa puissance qu à moyen terme et exige un plus gros effort d analyse en amont. Les composants sont différents des classes bien qu ils puissent être implémentés avec un langage objet. Les composants n ont pas de notion d héritage. Ils ne possèdent pas de méthodes mais des interfaces de programmation. Il existe une extension composant au langage C pour programmer les senseurs : NesC [GLvB + 03]. Les différents constituants logiciel et matériel d un senseur sont abstraits par des composants. Ces derniers communiquent par envois de messages. Notre approche privilégie la modification, lors de la compilation, du programme et des composants inclus. <<Component>> a component a state +a message parameter1() <<Component>> main component <<Component>> used component (a) (b) Fig. 3.24: Modèle UML pour les composants. (a) un composant contenant deux états et un paramètre. (b) le composant main-component utilise le composant used-component. Dans ce mémoire, nous représentons les composants du modèle Tical avec des diagrammes UML de classes [Fig (a)]. Nous avons ainsi une vue d ensemble d un programme Tical constitué de composants et de leurs relations. Un composant est alors représenté par une classe dont le stéréotype est component. Les états privés et publics sont représentés par les attributs de la classe. La portée de ses derniers distinguent les états privés des états public. Les paramètres disponibles dans le composant sont représentés par les méthodes de la classe. Nous ne capturons pas les passages de paramètres entre les composants. Les relations d inclusion sont modélisées par les relations de composition des diagrammes de classes [Fig (b)]. Nous n utilisons pas les diagrammes UML de composants. En effet, ces derniers sont conçus pour modéliser des composants possédant des interfaces hétéroclites

80 Chapitre 3. Langage de programmation amorphe 79 et sont apparentés aux diagrammes de paquetages. De plus, ils ne capturent pas le contenu d un composant comme les états ou les paramètres Tical : Langage de programmation orienté composant Dans Tical, nous utilisons les composants pour encapsuler les aspects définissant une tâche donnée. Nos composants ont la possibilité de se combiner entre eux via un mécanisme d inclusion paramétrable. Les composants sont conçus en deux couches méta-modèle et modèle comme le montre la figure 3.4. Le niveau méta-modèle définit un composant générique. Celui-ci peut inclure des aspects et d autres composants. Le méta-modèle ne propose qu une inclusion générique des aspects : la concaténation du code des aspects inclus à celui l aspect courant. En effet, les aspects pouvant avoir des syntaxes différentes, il convient de donner la possibilité au modèle d intervenir sur l agrégation des aspects des composants inclus via la transformation d une partie du programme des aspects. L inclusion définie dans le méta-modèle est également paramétrable. Les paramètres peuvent être de simples valeurs, des variables mais aussi des fragments de programmes. Dans le modèle, les composants contiennent les aspects dédiés à la programmation amorphes exposé dans la section Les règles de composition de ces aspects lors de l inclusion y sont également définies. Nous prenons soin de garantir les conflits de noms entre les différents états tout en permettant aux composants conteneurs de pouvoir accéder aux états des composants inclus. 1: (make-component simple) (make-component component #:un-aspect (corps-de-l-aspect)) Fig. 3.25: Exemple de deux composants. Le premier composant est le composant vide. Le second contient un aspect. Nous déclarons un nouveau composant dans le modèle avec la fonction make-component [Fig ligne (1)]. Cette fonction prend un identifiant en premier argument puis un ensemble d aspects. La figure 3.25 ligne (1), nous montre le composant le plus 13 Le langage universel de modélisation montre à nouveau ses limites pratiques lorsque nous tentons de sortir des modèles objets courants, basés sur des classes statiques et encapsulées. En effet, notre tentative de modéliser le compilateur de Tical, écrit avec un langage objets dynamiques utilisant les multi-méthodes et ne connaissant pas l encapsulation, fut un échec. L approche recommandée par l OMG consiste à construire une extension au modèle UML avec le langage MOF [OMG06] prévu à cet effet. La réelle difficulté est de trouver un outil adoptant ce paradigme en nous autorisant à y introduire notre nouveau modèle.

81 Chapitre 3. Langage de programmation amorphe 80 1: (make-component component #:uses ((a <composant1>)) #:un-aspect (corps-de-l-aspect s:a_state1)) Fig. 3.26: Exemple d un composant contenant un aspect et utilisant un composant connu sous l étiquette a. L état s:a_state1 fait référence à l état s:state1 défini dans le composant a. simple : le composant vide. Le second composant de la figure 3.25 montre un composant contenant un aspect. 1: (make-component composant1 #:parameters ((x 0) (program (when (> x 0) (set! m:message x))))) Fig. 3.27: Un aspect paramètre d un composant. Nous déclarons deux paramètres : une variable x ayant pour valeur initiale 0 et un fragment de programme program envoyant par défaut un message si x > 0. L inclusion d un composant dans un autre est réalisée par l aspect #:uses [Fig. 3.26]. La syntaxe de cet aspect est une liste de déclarations d inclusion constituées d un identifiant i c, du nom du composant inclus suivi de paramètres optionnels. Nous utilisons l identifiant i c afin de faire des références aux états des composants inclus dans le composant courant. Ces références s effectuent en préfixant le nom d un état par «i c _». Avec cette notation, nous avons accès à toute la hiérarchie des composants inclus et ainsi nous pouvons lire et modifier leurs états. 1: (make-component component #:uses ((a <composant1> #:x (s:my_state) #:program (when (> x 0) 5: (set! m:message (+ s:state x)))))) Fig. 3.28: Exemple d un composant utilisant un autre composant paramétrable. Les deux paramètres x, program sont nommées. L inclusion des composants peut être paramétrée. Les paramètres sont déclarés dans l aspect #:parameters [Fig. 3.27]. La syntaxe de cet aspect est une liste de couples (nom du paramètre, description littérale par défaut du paramètre).

82 Chapitre 3. Langage de programmation amorphe 81 Les paramètres peuvent être utilisés à n importe quel endroit dans le composant. La fonction param accède à l espace de nommage des paramètres et renvoie la description littérale du paramètre passé en argument. Nous accédons à l espace de nommage des paramètres en préfixant le nom d un paramètre par «p:». Les descriptions littérales des paramètres sont susceptibles d être récrites en fonctions dans règles en vigueurs dans le composant. Les paramètres sont transmis dans les déclaration d inclusion situées dans l aspect #:uses. La syntaxe d un paramètre est alors #:nom du paramètre suivi de la description littérale du paramètre. Cette syntaxe nous permet de transmettre que les paramètres différant des paramètres par défaut et de modifier le comportement du composant inclus. Nous voyons que l inclusion des composants construit une arborescence. Cette arborescence peut amener à la multiplication d un même composant et de ses ressources. Par exemple, nous utilisons un composant estimant le nombre de voisins des éléments de calcul. Chaque composant ayant besoin de cette information va inclure ce composant. Dans ce cas, le nombre d états et les messages échangés seront proportionnels au nombre d inclusions alors que nous aurions souhaité qu il soit inclus qu une seule fois. Nous résolvons ce problème en introduisant un aspect #:options. Ce dernier contient le symbole static déclarant le composant statique. Un composant statique ne sera crée qu une seule fois par simulation. Tous les composants incluant un composant statique utilisent les mêmes états privées et publics. En plus des règles de nommages des états, nous avons la possibilité de faire référence aux états d un composant statique en les préfixant par le nom du composant. Écrire un programme complet avec Tical consiste donc à écrire des composants qui réutilisent, si besoin est, des composants existants. Le composant principal est préparé en vue d être compilé en un simulateur exécutable. 3.6 Création et paramétrage des simulations Les simulations sont assemblées et paramétrées hors du système de composants de Tical. La grammaire est donnée dans la figure La méthode utilisée est une reinterprétation du patron de conception builder [GHJV95, C206]. Le paramétrage commence par la construction d une instance du composant principal de la simulation [Fig ligne (1)] [Fig ligne (1)]. Une fois en possession de cet objet, nous pouvons le paramétrer avec les fonctions idoines : Le nombre d éléments de calcul composant l ordinateur amorphe est spécifié par la fonction number-of-elements. Le rayon de communication des éléments de calcul est donné par la fonction set-radius.

83 Chapitre 3. Langage de programmation amorphe 82 1: (define g (make-instance <voronoi>)) (define type 3d) (case type ((1d) 5: (set-topology g "1d") (number-of-elementss g 1000) (set-analysis g (dump_all_states_1d 250))) ((2d) (number-of-elements g 50000) 10: (set-analysis g (dump_states 500 (state)()))) (set-mask g "mask.png") ((3d) (number-of-elements g ) (set-topology g "3d") 15: (set-radius g 1.666) (set-analysis g (dump_states_3d 500 (state)())))) (number-of-body-threads g 1) (number-of-message-threads g 2) ;; Le parametrage est termine. 20: (compile g) Fig. 3.29: Exemple de paramétrage et de compilation de la simulation construisant des partitions de Voronoï. Le paramétrage est différent suivant la topologie choisie : le nombre d éléments de calculs augmente avec le nombres de dimension, les méthodes d analyse sont différentes, le rayon de communication est plus large en 3D et nous introduisons un masque contrôlant la densité des éléments de calculs en 2D. Le composant voronoi est détaillé dans la section

84 Chapitre 3. Langage de programmation amorphe 83 identifiant-simulation (make-instance composant ) (1) compilation (compile identifiant-simulation ) (2) paramètre-instance ( fonction-paramètre identifiant-simulation expr ) (3) fonction-paramètre number-of-elements (4) number-of-body-threads number-of-message-threads set-radius set-topology set-analysis set-mask set-preload Fig. 3.30: Grammaire de la déclaration et du paramétrage de la compilation. Nous pouvons choisir le nombre de dimension de l espace avec la fonction set-topology. Cette dernière prend en paramètre une de ces trois chaînes de caractères : 1d, 2d ou 3d. Si l ordinateur amorphe est dans un espace à deux dimensions, alors nous pouvons lui donner un masque de densité via la fonction set-mask. L argument de cette fonction est le nom d une image PNG [Duc03] dont les niveaux de gris indiquent la probabilité qu un élément de calcul soit créé en tout points de l espace. Nous choisissons la méthode d analyse avec la fonction set-analysis. L argument de cette fonction est de la forme (méthode période arguments... ). Le simulateur collecte les données de la simulation toutes les périodes millisecondes. Les méthodes proposées sont : sdl et sdl and save affichent sur l écran une vue de l état courant de l ordinateur amorphe. La vue des éléments de calcul est construite par l aspect #:probe. La seconde méthode exposée ici sauvegarde les vues produites sur le disque ; dump states sauvegarde sur disque une sélection de l état courant de l ordinateur amorphe. La sélection s effectue avec une paire d arguments spécifiant respectivement la liste des états privés à sauvegarder et la liste des états publics à sauvegarder. Le format de sauvegarde est la copie directe de la mémoire du simulateur en excluant les éventuels états que nous ne désirons pas conserver. Nous produisons également des méta-données pour des outils d analyse extérieurs à notre simulateur tel qu OpenDx [DX05].

85 Chapitre 3. Langage de programmation amorphe 84 dump states lisp3d et dump states pov3d sauvegarde sur disque une sélection de l état courant de l ordinateur amorphe. Le format de sauvegarde lisp est un programme décrivant les méta-données, les fonctions de manipulations de données et un tableau stockant les données. Ce programme est lu puis traité par un compilateur Common Lisp. La seconde méthode sauvegarde l état de l ordinateur amorphe dans le format d inclusion du logiciel de lancé de rayon Persistance of Vision [POV07]. Le fonction set-preload charge en mémoire un ordinateur amorphe sauvé sur disque et court-circuite le processus d initialisation classique. En effet, nous pouvons à tout moment d une simulation faire une copie de la mémoire d un ordinateur amorphe en invoquant la fonction save-and-exit. Cette dernière fonction sauvegarde aussi la position des éléments de calculs, leurs relations de voisinage et leurs états complets. Finalement, nous contrôlons le nombre threads affectés au traitement du comportement général des éléments de calcul ainsi qu au traitement des messages avec les fonctions number-of-body-threads et number-of-message-threads. Une fois le paramétrage de la simulation effectué, nous pouvons la compiler vers un simulateur écrit en langage C en invoquant la fonction compile. Cette étape de compilation est détaillée dans la section suivante. 3.7 Compilation Les simulations exécutables sont générées par un compilateur prenant en entrée un programme Tical et produisant en sortie un programme C [ISO07]. Nous préférons écrire notre compilateur plutôt que de réutiliser les compilateurs Scheme vers C existant [Ser94, Ser02, PLT07] pour les raisons suivantes : Tical s exprime dans un sous-ensemble de Scheme favorisant la programmation impérative et reniant les aspects fonctionnels de son langage d implémentation. Notamment, il n implémente pas les formes spéciales lambda et call-with-current-continuation 14. Cela nous obligerait à sous spécifier le compilateur. Tical n exprime pas des programmes généraux mais des programmes amorphes réifiés en simulations. Cela nous obligerait à modifier toute la procédure d amorçage des exécutables produits. 14 L implémentation de call/cc en C s effectue de façon non portable en modifiant la pile d exécution. Pour être portable, il faut transformer (automatiquement) le programme dans un style dit de passage de continuation (CPS) où celle-ci est explicitement transmise lors des appels fonctionnels et reçoit en paramètre le résultat du calcul précédent. Nous pouvons aussi implémenter directement les continuations dynamiques (le couple catch, throws de Common Lisp) à l aide des fonctions setjmp et longjmp.

86 Chapitre 3. Langage de programmation amorphe 85 make instance composant instancier instance instance <<structured>> récursif parametres appliquer parametres Composants make instance compile Instance aspect iterative agregger aspect compiler expression tisser aspects Programme C transformer aspect en expression aspect simulation Fig. 3.31: Diagramme UML d activité de la compilation. Les composants à compiler sont transformés par un double arpentage de code. Après être instanciés et paramétrés, les composants sont transformés en un programme C. Le compilateur est de type (eval exp env) selon la classification de [Que94]. Nous utilisons l interprète Guile 15 [gui06] pour implémenter notre compilateur Tical. La directive de compilation est donnée sur la figure 3.30 ligne (2). Nous n utilisons pas les techniques de compilation utilisant des machines à registres [ASS96]. Notre méthode de compilation repose sur l arpentage de code 16 La figure 3.31 présente les étapes de compilation de nos programmes. La compilation commence par la lecture du programme grâce à la fonction read 17 de l interprète Scheme. Cette lecture se conclut par la création d une hiérarchie d instances de composants. Ces instances sont constituées de composants prêt à être traités par l arpenteur, des valeurs des paramètres [Fig ligne (4)] et des instances de 15 Guile est un interprète Scheme [KCE98] disposant d une extension objet Goop[goo06] ressemblant à CLOS. 16 Un arpenteur de code est traduit en anglais par code walker. C est une technique consistant à modifier un arbre syntaxique pendant que nous le parcourons. 17 Nous profitons pleinement de l homoiconicité des langages Lisp. La fonction read transforme un flux de caractères en S-expressions. Nos composants et aspects étant représentés par des listes Lisp, nous éliminons ainsi le problème de la lecture en une seule fonction.

87 Chapitre 3. Langage de programmation amorphe 86 tous les composants utilisés. Ces instances de composants sont ensuite consommées par l arpenteur afin de produire la simulation. Notre arpenteur commence par recenser récursivement tous les composants utilisés. Durant ce recensement, les paramètres sont expansés dans les aspects concernés. De plus, chaque état est renommé 18 afin d éviter les conflits de nom. Le renommage consiste à préfixer le nom de la variable par le nom de tous les composants qui ont été inclus pour atteindre la variable. Nous sommes alors en possession d une arborescence de composants dont les paramètres sont expansés et les variables sont uniques. La prochaine étape de cette compilation est de linéariser les aspects afin supprimer les composants. Pour cela, l arpenteur effectue un parcours en profondeur postfixé de toutes les instances des composants. Durant ce parcours, nous concaténons les aspects contenus dans les composant en aspects linéarisés qu un dernier arpentage transformera en langage C. Suivant les aspects traités, nous pouvons en profiter pour instrumenter les programmes. Ainsi, le traitement de l aspect message-handlers encapsule le nom du message à traiter dans une condition sur le type de message reçu. La dernière étape de compilation produit le code source en C de chaque aspect. Le tisseur d aspect insère alors ces fragments de code dans le programme C simulant un ordinateur amorphe. Lors de cette étape, nous faisons de nouveau appel à un arpenteur. Il parcourt les s-expressions produites précédemment pour les traduire en chaînes de caractères. Les expressions arithmétiques et logiques ainsi que les affections sont infixées. Les appels de fonctions sont produites par une translation de la parenthèse ouvrante vers la droite et en séparant les arguments par une virgule. Chaque forme spéciale est traitée séparément : les séquences d instructions sont séparées par des points virgules ; les conditionnelles et les boucles sont transformées en leur équivalent C ; les environnement lexicaux créés par la forme spéciale let sont encadrés par des blocs 19 ; 18 Ce renommage correspond à l α-conversion du λ-calcul [AS93, TG95]. Rappelons que le λ-calcul propose deux opérations : l α-conversion qui substitue un argument formel par un autre : λx.m α λy.m[x y] ; la β-réduction qui applique un argument N a un terme λx.m en remplaçant toute les occurrences de x par N : (λx.m N) β M[x N]. 19 Nous implémentons les environnements lexicaux Scheme avec des imbrications blocs C. Mais les compilateurs C limitent la profondeur d imbrication. Ainsi le compilateur que nous utilisons (gcc 4.3.2) ne compile que des programmes imbriquant moins de blocs. Dans le cas contraire, le compilateur nous invite à soumettre un rapport de bugs plutôt que de nous délivrer le programme souhaité. Le méta-programme suivant génère des programmes C exhibant cette faille. (defun teste-nombre-de-blocs-c (nb &optional (f T)) (labels ((block-gen (n) (if (> n 0)

88 Chapitre 3. Langage de programmation amorphe 87 le définition de fonction ne pose pas de problèmes particuliers 20 et se traduit presque littéralement. Le compilateur est volontairement léger : le code produit n est pas optimisé et aucune erreur n est levée en cas de variables ou fonctions inconnues. Nous laissons ces tâches au compilateur C. 3.8 Exemples de programmes Tical Dans cette section, nous présentons deux programmes Tical. Le premier trace un diagramme de Voronoï. Le second établi un système de coordonnées dans l ordinateur amorphe. Nous profitons de cette occasion pour introduire nos primitives de bas niveaux : la propagation de valeur et le gradient. Mais avant d exposer ces exemples, nous précisons la descriptions des algorithmes «amorphes» qui nous utilisons. (format nil "{ int a~a=a~a+1 ;~%~a}" n (1+ n) (block-gen (1- n))) (format nil "a=a1 ;~%")))) (format f "#include <stdio.h>~%int main () {~%int a~a=0 ;~%" (1+ nb)) (format f "~a" (block-gen nb)) (format f "printf(\"%d\\n\",a~a) ;~%return 0 ;~%}" (1+ nb)))) (with-open-file (f "/tmp/test.c" :direction :output :if-exists :supersede) (teste-nombre-de-blocks-c f)) Ainsi l invocation (teste-nombre-de-blocs-c 2) produit le programme C suivant : #include <stdio.h> int main () { int a3=0 ; { int a2=a3+1 ; { int a1=a2+1 ; a3=a1 ; }}printf("%d\n",a3) ; return 0 ; } En commençant notre recherche par blocs, nous déterminons la limite en moins de 15 essais. D un autre côté, nos investigations n ont pas put déterminer le nombre maximal de variables dans un bloc. La compilation d un bloc contenant 2 20 variables locales a échoué après avoir consommé les 4Go de mémoire dont nous disposons actuellement. 20 Nous avons sciemment évité le problème des fonctions anonymes et des fermetures lexicales associées aux fonctions. Traiter ces dernières nous aurait obligé à introduire un arpenteur de plus afin de récupérer toutes les variables libres dans une structure de donnée faisant office de fermeture. Cette structure est renseignée lors de la création de la fonction anonyme à l exécution. Lors de l appel à cette fonction, la fermeture est alors passée en paramètre.

89 Chapitre 3. Langage de programmation amorphe Formalisation des algorithmes Dans cette section, nous décrivons notre formalisme dans lequel nous exprimons nos algorithmes. Ce formalisme est une extension du langage pseudo-code utilisé dans [CLR94]. Ce pseudo-code est conçu pour décrire les algorithmes séquentiels exprimés dans le paradigme impératif avec un langage se voulant proche du Français. Mais celui-ci ne peut pas exprimer simplement 21 nos algorithmes pour les ordinateurs amorphes notamment la réception des messages et l encapsulation dans des composants. La figure 3.1 rassemble, via un exemple, les ajouts que nous apportons à l écriture pseudo-codes. Nous ne cherchons pas à exprimer directement les aspects de Tical dans nos algorithmes. Au contraire, nous les rassemblons afin d augmenter la clarté des algorithmes. Ainsi, les échanges séquentiels entre les éléments de calcul sont aussi exprimés séquentiellement dans nos algorithmes. Requis: c 1, c n : Composant 0 (...) Initialisation: m m 0 1: composant Composant 1 (a) 2: avec message m faire 3: Fonction 1 (, a 2) 4: fin avec message 5: fin composant 6: composant e,f : Composant 2 (b, c) 7: si condition alors 8: avec message m cte faire 9: m new value 10: fin avec message 11: fin si 12: fin composant 13: fonction Fonction 1 (f, p 1,...) 14: fin fonction Algorithme 3.1: Exemple formel d écriture d un algorithme pour Tical. Les composants sont exprimés par des blocs «composant». La syntaxe le début de ces blocs est l une des deux formes suivantes : 21 Le langage Tical est né de l impossibilité d exprimer simplement l idiome «Pour tous les voisins faire» en langage C. Cet idiome s exprime par une boucle où interviennent des variables ayant un niveau d indirections élevé. Cela entraîne une probabilité d erreurs humaines trop élevée pour en confier systématiquement l implémentation à un programmeur. Ainsi, le compilateur Tical masque cette boucle par une macro for-all-neighbours qui projette alors le voisinage dans une variable anaphorique.

90 Chapitre 3. Langage de programmation amorphe 89 composant nom du composant(arguments... ) (ligne 1 de l algorithme 3.1) composant noms d inclusion du composant : nom du composant(arguments... ) (ligne 6 de l algorithme 3.1) La première forme déclare un composant unique dans l algorithme. Les autres composants intervenant font référence à ses états en les nommant directement. Dans la seconde forme, le composant est déclaré plusieurs fois et ses inclusions nommées. Les références à leurs états suivent les mêmes règles que dans Tical. Elles sont préfixées par le nom d inclusion donné au composant. Les blocs composants se terminent par le marqueur suivant : fin composant (lignes 5 et 12 de l algorithme 3.1). Les composants non déclarés dans l algorithme peuvent être utilisés en employant la forme Requis : nom d inclusion du composant : nom du composant(parametres). (ligne 9 de l algorithme 3.1) Les états sont déclarés dans l entête par la forme Initialisation : etat valeur initiale (ligne 0 de l algorithme 3.1). À l intérieur d un composant, nous pouvons réagir à la réception d un message grâce aux blocs «message». Deux formes sont proposées : avec message message faire (ligne 2 de l algorithme 3.1) où le corps du bloc est exécuté lors de la réception d un message message ; avec message condition sur un message faire (ligne 8 de l algorithme 3.1) exécute le corps du bloc lorsque la condition sur les messages est satisfaite. Les blocs messages se terminent par le marqueur : fin avec message. Ces blocs viennent ponctuer une séquence d instructions suggérant au lecteur le protocole de communication entre les éléments de calcul. Dans nos algorithmes comme dans Tical, les messages sont envoyés lorsque nous leur affectons une valeur (ligne 8 de l algorithme 3.1). Nous pouvons rassembler des séquences d instructions dans des fonctions avec la forme fonction Nom de la fonction(composant, parametres) (ligne 13 de l algorithme 3.1). Les fonctions ne sont pas encapsulées dans les composants. Le premier paramètre composant est le nom d inclusion d un composant. Lors de l appel d une fonction le composant courant est exprimé par le symbole «_» Voronoï Dans cette section, nous construisons un programme de deux composants afin de tracer des diagrammes de Voronoï [O R98]. Les diagrammes de Voronoï sont des partitions de l espace telles que pour n sites p i donnés de l espace alors la partition V pi est l ensemble des points de l espaces qui sont les plus proches de p i. Les diagrammes de Voronoï peuvent être utilisés, dans la cadre de la programmation amorphe, pour la formation d un nombre fini de groupes dans un

91 Chapitre 3. Langage de programmation amorphe 90 ordinateur amorphe. Nous choisissons aléatoirement autant de site que nous voulons de groupes puis nous lançons une partition de Voronoï. Le dual du diagramme de Voronoï (la triangulation de Delaunay) servant à établir des relations de communication entre les groupes. Initialisation: etat ligne Initialisation: v v 0 v la valeur de propagation 1: composant Voronoi(site) 2: si site v = v 0 alors Initialisation 3: v random() 4: fin si 5: avec message propagation v propagation v 0 faire 6: etat ligne 7: fin avec message 8: fin composant 9: composant Propagation(propagation) 10: si value = v 0 alors 11: avec message propagation faire 12: v propagation 13: fin avec message 14: fin si 15: propagation v 16: fin composant Algorithme 3.2: Algorithme de génération d un diagramme de Voronoï. L algorithme que nous employons (voir l algorithme 3.2) fait grossir des disques à partir des point p i jusqu à ce qu ils se rencontrent. Les points de rencontre sont sur une frontière du diagramme de Voronoï. Nous construisons les disques en propageant une valeur v i. Si les éléments de calcul de l ordinateur amorphe sont cadencés à la même vitesse alors l inondation se fait à vitesse constante et son front est un cercle. Malgré cela des imperfections apparaissent. Elles sont dues aux irrégularités dans la répartition des éléments de calcul et à l asynchronisme des calculs et des communications. Nous détectons une frontière entre deux cellules de Voronoï lorsqu un élément de calcul reçoit deux valeurs v i différentes. La complexité temporelle de cet algorithme pour un site est O(h) où h est le nombre de sauts nécessaires pour qu un message traverse l ordinateur amorphe. La complexité pour n site est O( h n ). En effet, chaque site propage son signal en parallèle des autres, l ajout d un site diminue la complexité. Cette dernière reste tributaire de la surface de l ordinateur amorphe et du rayon de communication des éléments de calcul. Bien que le tracé soit imparfait, il est plus efficace que

92 Chapitre 3. Langage de programmation amorphe 91 <<Component>> voronoi etat <<Component>> propagation v +propagation default() propagation method() propagation condition() propagation accept after() Fig. 3.32: Diagramme UML des composants du programme de tracé de Voronoï. l algorithme séquentiel de Fortune [For86] dont la complexité est O(n 3 ). Lors de l implémentation, nous utilisons deux composants [Fig. 3.32] : un composant propagation transmettant une valeur au voisinage et un composant voronoi incluant le premier composant en le paramétrant et détectant les frontières entre les cellules Composant Propagation Le composant propagation retransmet une valeur reçue à son voisinage. Il implémente la rumeur décrite à la section Paramétré, il devient un accumulateur et un filtre très puissant. La figure 3.33 nous montre l implémentation de ce composant. Il contient deux états : value qui stocke la valeur à propager ; propagate émet la valeur en écriture et en lecture, reçoit les valeurs du voisinage. Dans sa forme simple, le composant conserve une valeur value et l émet via l état public propage. Lors de la réception de ce message, si la valeur conservée est la valeur par défaut alors elle reçoit l état propage. Nous complexifions ce composant avec quatre paramètres : default modifiant la valeur par défaut par défaut ; propagation-condition est une expression logique qui filtre l adoption d une nouvelle valeur. Ce paramètre construit des filtres ; propagation-accept-after est une séquence d expressions exécutée après l adoption d une nouvelle valeur. Ce paramètre construit des accumulateurs ; propagation-method décrit la transformation que subit la valeur avant d être propagée. Pour commencer une propagation, nous changeons la valeur value.

93 Chapitre 3. Langage de programmation amorphe 92 1: (make-component propagation #:documentation ("Voir le corps du memoire :-p") #:parameters ((default 0) (propagation-method s:value) 5: (propagation-accept-after #f) (propagation-condition (= s:value p:default))) #:states (value) #:messages (propage) #:init ((set! s:value p:default)) 10: #:message-handlers ((propage (when-and ((!= m:propage p:default) p:propagation-condition) (set! s:value m:propage) p:propagation-accept-after))) 15: #:behaviours ((if (!= s:value p:default) (set! m:propage p:propagation-method) (set! m:propage p:default)))) Fig. 3.33: Composant propageant une valeur Composant Voronoï Le composant voronoi [Fig. 3.34] pilote la construction du diagramme de Voronoï. Il délègue toute la gestion des messages au composant propagation. Il ne reste au composant voronoi que trois fonctions : construire les frontières entre les cellules de Voronoï [Fig ligne (7 9)]. Pour cela, nous interceptons la réception du message propage et affectons le symbole line à l état state de l élément de calcul lorsque le message reçu est différent de la valeur conservée ; initialiser les sites sur l ordinateur amorphe [Fig ligne (5 6)]. Elle est réalisée après l initialisation normale des éléments de calcul. Nous choisissons une nombre n de d éléments de calcul dont nous changeons la valeur de propagation par un nombre aléatoire. Cette valeur étant différente de la valeur de propagation par défaut, sa propagation est assurée ; proposer une visualisation [Fig ligne (10 12)]. Nous visualisons la frontière entre les cellules de Voronoï pour les éléments étant sur celle-ci sinon nous visualisons la valeur propagée. Notre implémentation de la partition de Voronoï produit les résultats attendus. Les résultats sont visualisés sur la figure Nous avons calculé des partitions de Voronoï dans un espace 3D [Fig (c)].

94 Chapitre 3. Langage de programmation amorphe 93 1: (make-component voronoi #:uses ((p <propagation>)) #:states ((state (empty line))) #:init ((set! s:state empty)) 5: #:init:after ((with-n-elements-do 5 (set! s:p_value (rand)))) #:message-handlers ((p_propage (if (!= m:p_propage s:p_value) (set! s:state line)))) 10: #:probes ((if (!= s:state line) (draw-state p_value 100) (draw-state state 0)))) Fig. 3.34: Composant calculant un diagramme de Voronoï de cinq sites. Il inclut le composant propagation Système de coordonnées Dans cet exemple, nous établissons un système de coordonnées dans un ordinateur amorphe sur un espace plan. Pour ce faire, nous effectuons une trilatération[wik07a] sur chaque élément de calcul. La trilatération avec trois points se calcule ainsi : Soit un point O de coordonnées (0, 0), un point A donné de coordonnées (x A, 0) et un point B donné de coordonnées (0, y B ). Alors un point P de coordonnées (x, y) se trouve à une distance r O de O et r A de A. Nous calculons les coordonnées de P comme ceci : x a = r2 O r2 A + x2 A 2x A y a = r 2 O (r2 O r2 A + x2 A )2 4x 2 A La racine carré dans le calcul de y a implique une ambiguïté sur le signe de y a. Afin de la lever, nous introduisons le troisième point B. Avec le point B et sa distance r B du point P alors nous obtenons : x b = r2 O r2 B + y2 B 2y B Les coordonnées de P sont alors (x = x a, y = x b ).

95 Chapitre 3. Langage de programmation amorphe 94 Fig. 3.35: Les figures de (a) et (b) montrent deux e tapes de l e tablissement d une partition de Voronoı a partir de cinq sites. La figure (c) est le re sultat du me me algorithme applique dans un espace 3D. Le calcul de la trilate ration ne de pend que de cinq distances : xa, yb, ro, ra et rb. Pour estimer la distance entre deux e le ments de calcul nous utilisons la primitive gradient (voir la section ). Notre algorithme construit trois gradients G O, G A et G B, initie s respectivement par les points O, A et B. Les distances xa et yb sont les valeurs des gradient G A et G B au point O. Afin que tous les e le ments de calcul disposent de ces distances, nous les propageons. Les distances ro, ra et rb sont les valeurs respectives des gradients G O, G A et G B au point P. Notre imple mentation utilise trois composants [Fig. 3.36] que nous de taillons

96 Chapitre 3. Langage de programmation amorphe 95 <<Component>> coordinate 2 <<Component>> propagation 3 3 si lissage <<Component>> smooth gradient sum <<Component>> gradient g init() condition() <<Component>> <<static>> neighbours estimation number +beep Fig. 3.36: Diagramme UML des composants du programme calculant un système de coordonnées. dans la suite de cette section : propagation, que nous avons déjà étudié, diffuse les valeurs x A et y B dans l ordinateur amorphe ; gradient estime la distance de chaque élément de calcul aux trois éléments de calcul O, A et B ; coordinate calcul la trilatération quand les cinq distances sont connues Gradient Un gradient [Wei08] est un champ vectoriel représentant les variations d une fonction. Comme la propagation, le gradient est une primitive bas niveau couramment utilisée en programmation amorphe. Nos gradients sont initiés par une ou plusieurs sources et pointent vers la source la plus proche. Nous ne construisons pas directement les champs vectoriels mais le champs scalaire supportant ce dernier. Le calcul d un gradient [Alg. 3.3] commence par initialiser l élément source à zéro. Tous les autres éléments fixent leur valeur scalaire à l infini. Les sources communiquent leurs valeurs à leur voisinage incrémenté d une unité. Quand un élément de calcul reçoit un message du voisinage, il le compare à sa propre valeur. Si la valeur reçue du voisinage est plus petite alors il la choisit pour être sa valeur scalaire et propage la nouvelle valeur. L implémentation de la figure 3.37 reprend l algorithme précédent. Nous proposons une seconde implémentation réutilisant le composant propagation [Fig. 3.38]. Nagpal [NSB03] a montré que l introduction d un lissage dans lors la construction des gradients améliore la précision du système de coordonnés. Nous effectuons un lissage sur un gradient en calculant, pour chaque élément de calcul, la moyenne des valeurs du gradient dans le voisinage de l élément de

97 Chapitre 3. Langage de programmation amorphe 96 Initialisation: g g 0 Initialisation: mg g 0 1: composant G : Gradient(g 0 +, condition) 2: avec message mg faire 3: si g = g 0 mg < g condition alors 4: g mg 5: fin si 6: fin avec message 7: si g g 0 alors 8: mg g + 1 9: fin si 10: fin composant 11: fonction Initier Gradient(G) 12: g 0 13: fin fonction Algorithme 3.3: Algorithme de génération d un gradient. 1: (make-component gradient #:parameters ((g-init MAXINT) (condition #t)) #:states (g) #:messages (mg) 5: #:init ((set! s:g p:g-init) (set! m:mg p:g-init)) #:message-handlers ((mg (when-and ((!= m:mg p:g-init) 10: p:condition (or (= s:g p:g-init) (< m:mg s:g))) (set! s:g m:mg)))) #:behaviours ((set! my:mg (+ s:g 1)))) Fig. 3.37: Implémentation de la primitive gradient sans inclusion de composant.

98 Chapitre 3. Langage de programmation amorphe 97 1: (make-component gradient #:parameters ((g-init MAXINT) (condition #t)) #:uses ((p <propagation> #:init p:g-init 5: #:propagation-condition (and p:condition (or (= s:value p:g-init) (< m:propage s:value))) #:propagation-method (+ s:value 1)))) Fig. 3.38: Implémentation de la primitive gradient avec l inclusion du composant propagation. calcul. Notre implémentation [Fig. 3.39] introduit un nouveau composant estimant le nombre de voisins pour chaque élément de calcul. Chaque élément de calcul émet un beep qui est accumulé par les voisins dans l état privé number. Nous réalisons alors le lissage en accumulant les valeurs des gradients reçus du voisinage qui nous divisons par l estimation du nombre de voisins Coordonnées Le composant coordinate [Fig. 3.40] implémente l algorithme 3.4. Les trois gradients sont créés par inclusion de composants. Les trois points O, A et B sont choisis lors de l initialisation des gradients dans l aspect #:init:after. Nous montrons sur la figure 3.41 trois systèmes de coordonnées calculés avec notre programme. Le premier [Fig (a)] utilise des gradients sans lissages. Ces derniers n ont que des valeurs entières. Donc plusieurs éléments de calcul possèdent les mêmes coordonnées. Cette discrétisation donne l aspect «irisé» à la figure. Notons que le système de coordonnées est déformé lorsque nous nous éloignons de l origine. Le second système de coordonnées [Fig (b)] utilise des gradients avec lissage. Il est moins déformé que le précédent et n a plus son aspect discret. Les variations locales de la densité des éléments de calcul donnent au système de coordonnées son aspect «spongieux». Nous cherchons à évaluer l influence de la densité sur les coordonnées. Pour cela, nous générons un masque de densité [Fig (d)] que nous appliquons à la simulation précédente. Par la suite, nous constatons [Fig (c)] que la densité des éléments de calcul jouent sur la qualité du système de coordonnées. Nous voyons apparaître des discontinuités dans l espace. Cela nous incite à utiliser

99 Chapitre 3. Langage de programmation amorphe 98 1: (make-component neighbour-estimation #:options (static) #:states (number countp) #:messages (beep) 5: #:init ((set! s:countp 1) ; interrupteur (set! m:beep 1)) #:message-handlers:before ((when (= s:countp 1) (set! s:number 0))) #:message-handlers ((beep (when (= s:countp 1) 10: (set! s:number (+ 1 s:number))))) #:message-handlers:after ((when-and ((= s:countp 1) (> s:number 0)) (set! s:countp 0) 15: (set! m:beep 0)))) (make-component smooth-gradient #:parameters ((g-init MAXINT) (condition #t)) #:uses ((g <gradient> 20: #:init p:g-init #:condition p:condition) (ne <neighbour-estimation>)) #:states (sum g) #:message-handlers:before ((set! s:sum 0)) 25: #:message-handlers ((g_mg (set! s:sum (+ s:sum m:m_mg)))) #:message-handlers:after ((when (> s:ne_number 0) (set! s:g (/ s:sum s:ne_number))))) Fig. 3.39: Implémentation du composant smooth-gradient, calculant un gradient lissé, ainsi que le composant neighbour-estimation estimant le nombre de voisin d un élément de calcul.

100 Chapitre 3. Langage de programmation amorphe 99 Requis: G r0, G ra, G rb : Gradient Requis: x A, y B : Propagation Initialisation: Initier Gradients(G r0, G ra, G rb ) 1: composant Coordonnées(O,A,B) 2: si O alors 3: avec message G ra faire 4: Propager(x A G ra ) 5: fin avec message 6: avec message G rb faire 7: Propager(y B G rb ) 8: fin avec message 9: fin si 10: si x A 0 G ro 0 G ra 0 alors 11: x G2 r 0 G 2 r A +x 2 A 2x A 12: fin si 13: si y B 0 G ro 0 G rb 0 alors 14: y G2 r 0 G 2 r B +y 2 B 2y B 15: fin si 16: fin composant Algorithme 3.4: Algorithme de génération d un système de coordonnées.

101 Chapitre 3. Langage de programmation amorphe 100 1: (make-component coordinate #:uses ((r0 <gradient>) (ra <gradient>) (rb <gradient>) 5: (xa <propagation>) (yb <propagation>)) #:states (x y) #:init:after ((with-n-elements-do 1 (set! s:r0_g 0)) 10: (with-n-elements-do 1 (set! s:ra_g 0)) (with-n-elements-do 1 (set! s:rb_g 0))) #:message-handlers ((ra_mg (when-and ((= s:r0_g 0) 15: (< m:ra_mg MAXINT)) (set! s:xa_value m:ra_mg))) (rb_mg (when-and ((= s:r0_g 0) (< m:rb_mg MAXINT)) (set! s:yb_value m:rb_mg)))) 20: #:behaviours ((when-and ((= s:x 0) (> s:xa_value 0) (> s:r0_g 0) (> s:ra_g 0)) (set! s:x (/ (+ (- (* s:r0_g s:r0_g) 25: (* s:ra_g s:ra_g)) (* s:xa_value s:xa_value)) (* 2 s:xa_value)))) (when-and ((= s:y 0) (> s:yb_value 0) 30: (> s:r0_g 0) (> s:rb_g 0)) (set! s:y (/ (+ (- (* s:r0_g s:r0_g) (* s:rb_g s:rb_g)) (* s:yb_value s:yb_value)) 35: (* 2 s:yb_value)))))) Fig. 3.40: Implémentation du composant coordinate réalisant un système de coordonnées par trilatération avec des gradients sans lissage.

102 Chapitre 3. Langage de programmation amorphe 101 les systèmes de coordonnées avec prudence. 3.9 Conclusion Nous avons commencé ce chapitre par une description de notre modèle d ordinateur amorphe utilisant un tableau noir pour abstraire les messages. Nous en avons ensuite proposé un simulateur, ainsi que la construction de Tical, un langage de programmation orienté aspect et composant pour la programmation des ordinateurs amorphes. Nous avons organisé ce langage en un méta-modèle réifiant les concepts d aspects et de composants et un modèle spécialisant le méta-modèle pour la programmation amorphe. Après avoir exposé le paramétrage des simulations et la méthode de compilation de notre langage, nous avons finis par donner deux exemples d utilisations de Tical. Ces exemples nous ont amené à amorcer la construction d une bibliothèque de composants contenant entre autre la propagation d une valeur et le gradient.

103 Chapitre 3. Langage de programmation amorphe (a) coordonnees sans lissage 140 (b) coordonnees avec lissage (c) coordonnees avec lissage et masque de densite Fig. 3.41: Les éléments de calcul sont projetés dans le système de coordonnés calculé par notre algorithme. La simulation utilise éléments de calcul dans un carré de 100 unités de coté avec un rayon de communication de une unité. La simulation de la figure (a) utilise des gradients sans lissage. La simulation de la figure (b) utilise des gradients avec lissage. Lors de la simulation de la figure (c), nous avons utilisé le masque de densité représenté sur la figure (d). Les zones sombres ont une faible densité alors que les zones claires ont une forte densité.

104 Chapitre 4 Vers une implémentation d une machine abstraite Blob Dans ce chapitre, nous implémentons trois primitives de la machine abstraite Blob dans nos ordinateurs amorphes. Une machine abstraite Blob [GE07, GM02] est une machine abstraite pour le calcul spatial. Son unité de calcul est le blob 1 qui peut se déplacer dans l espace de calcul, communiquer avec d autres blobs, se diviser et se détruire. Nous donnons plus de détails sur cette machine dans la prochaine section. Les primitives blob que nous implémentons sont : la création d un blob à partir des éléments de calcul d un ordinateur amorphe ; 1 Blob est aussi le nom d un courant architectural dans lequel les bâtiments ont une forme organique molle et bombée, comme de grosses amibes. Cette architecture se définirait alors selon trois optiques : 1. philosophique, puisqu elle s inscrit comme l héritière de l architecture organique et poursuit son dialogue entre le bâti et la nature ou cosmos qui est le fondement antique de l harmonie et donc de la codification du beau. 2. structurelle, puisqu elle prend pour modèle dans la nature les organismes mous qui ont des organes dont la forme provient d une enveloppe à tension minimum en tension de surface (tendance fonctionnalisme international) ou la forme que prend le galet usé, le rocher usé, la courbe de la côte usée en abord de rivière (tendance naturaliste anglo-saxonne et tendance culturelle japonaise). 3. formelle, puisque dès qu un bâtiment a une allure informe et sinueuse il est catalogué comme blob, c est à dire mou, situation venant de la nouveauté et de l absence de règles catégorisant consensuellement ce mouvement, certains pouvant par exemple être rangés dans le mouvement postmodernisme par leur esprit de conception. Parmi les bâtiments blob, retenons par exemple la Kunshaus de Graz an Autriche, construite en 2003 par Peter Cook et Colin Fournier. En France, la réalisation la plus marquante est le restaurant Georges situé au dernier étage du Centre Pompidou construit par Jakob et MacFarlane en

105 Chapitre 4. Vers une implémentation d une machine abstraite Blob 104 la liaison de deux blobs afin d établir un canal de communication ; la division d un blob en deux blobs. Seules, ces primitives amorphes ne font pas une machine abstraite Blob. Pour la finaliser, il reste à implémenter : l orientation et la polarisation des arcs ; l envoi effectif de messages dans les arcs. 4.1 Machine abstraite Blob Une machine abstraite Blob est une machine virtuelle s auto-développant dans l espace. Elle est constituée d un graphe orienté de noeuds appelés blobs. Ce graphe Machine abstraite Blob Arc orienté 1..* 1 Blob +flip dir() +set dir() +plus dir() +move() +wrap() +divide() +new channel() +mrg dir() * 2 2 vertical canal port 2 Fig. 4.1: Diagramme de classes UML d une machine abstraite Blob. Elle est constituée d une graphe de blobs. Le graphe distingue trois types d arc : les arcs verticaux, les canaux et les ports. implémente un automate à état fini. Cet automate s auto-développe à partir d un blob initial à l aide des instructions blob. Le graphe de l automate distingue de trois types d arcs : les arcs verticaux définissent un arbre couvrant tous les blobs. Il encode la hiérarchie d encapsulation des blobs et définit un ordre partiel entre les blobs. La racine de l arbre est appelée «racine». Les feuilles sont des blobs vides aussi appelés «blobs atomiques» ou «atomes». Il y a deux motivations pour l utilisation explicite d une structure d arbre : 1. l arbre est une représentation hiérarchique cadrant parfaitement avec la programmation structurée comme l utilisation de fonction, structures

106 Chapitre 4. Vers une implémentation d une machine abstraite Blob 105 de données hiérarchiques, hiérarchies d objets ; 2. l arbre possède une représentation topologique naturelle dans un espace 2D ou 3D. Par exemple, en utilisant un ensemble de membranes encapsulées. les canaux permettent de représenter un graphe arbitraire. Dans la pratique, la seule communication entre les arcs verticaux n est pas suffisamment expressive. Par exemple, si nous souhaitons installer une grille 2D sans les canaux, nous risquons une congestion dans le noeud racine. Cela motive l utilisation des canaux qui installent les liens de communications entre des paires de blobs. les ports permettent de gérer les entrées/sorties dans la machine Blobs. Plusieurs ports peuvent cohabiter dans la même machine. Cela nous permet de faire des entrées/sorties parallèles. Le noeud racine est connecté aux ports. Les extrémités des arcs sont étiquetées comme suit : les arcs verticaux sont polarisés (noté - et +). Cette polarisation est utilisée : pour la communication. Le bit de polarité agit comme une variable partagée entre le blob et ses sous-blobs. La polarité est affectée par une extrémité et testée par l autre. Cela détermine le propriétaire d un arc (possesseur du +). Seul le propriétaire peut utiliser l arc. pour la différentiation entre deux copies distinctes. Lorsqu un arc est dupliqué, l un est polarisé + et l autre -. les arcs verticaux possèdent aussi une orientation statique entre leurs extrémités notée up et down distinguant un blob père d un de ses blobs fils. La machine abstraite Blob dispose de huit instructions qui modifient le graphe. Les modifications ne sont pas globales mais locales aux blobs qui les invoquent. Ces huit instructions sont : flip up/down : inverse la polarité d un arc vertical. La direction spécifie les arcs à traiter. Ainsi le blob propriétaire d un arc peut en donner la propriété à l autre blob. Cette instruction exige de disposer d une exclusion mutuelle entre les blobs. Nous n implémentons 2 pas cette instruction dans ce travail ; set up/down : change la polarité de l extrémité d arc. Cette polarité est transmise à l autre extrémité. Nous n implémentons pas cette instruction ; test up/down : teste la polarité d un arc. Alors que l instruction set écrit sur un arc vertical, l instruction test le lit. Nous n implémentons pas cette instruction ; 2 L implémentation des instructions manquantes fait parti de nos perspectives à court terme. L instruction flip n a besoin que d un bit pour chaque arc dans chaque blob et de l exclusion mutuelle pour garantir la correction de l opération. Nous disposons déjà d une forme d exclusion mutuelle comme nous le montrons dans le section

107 Chapitre 4. Vers une implémentation d une machine abstraite Blob 106 move : le blob destinataire d un canal devient le parent du blob et l ancien parent devient le destinataire du canal. Techniquement, cela revient à déplacer des identifiants de blob dans les tables internes des trois participants. Nous n implémentons pas cette instruction ; wrap : construit un nouveau blob parent autour du blob. L ancien blob parent devient le parent de l actuel parent. Cela revient à re-étiqueter les blobs concernés. Nous n implémentons pas cette instruction ; divide : produit un blob frère qui contiendra tous les éléments négatifs. Durant la duplication les canaux sont préservés. Nous implémentons une variante plus complète 3 de cette instruction à la section ; new channel : construit un nouveau canal entre le blob et un blob frère fraîchement créer. Nous implémentons la création du canal à la section ; mrg +/- : fusionne le blob avec son parent ou avec tous ses frères suivant le signe utilisé. Nous implémentons cette instruction à la section L algorithme du tri rapide est implémenté sur le modèle blob [GLRT04]. Chaque élément à trier est représenté par un blob connecté à un blob «central». Ce blob central envoie à tous ces fils la valeur du premier élément de la liste. Chaque fils se polarise «-» si sa valeur est inférieure à celle du pivot sinon il se polarise «+». Le blob central se divise alors en deux blobs. L un conserve les fils de polarité négative alors que l autre conserve les fils de polarité positive. Les nouveaux deux blobs restent liés par un canal. Ce processus se répète sur chacun des blobs. La complexité moyenne sur cet algorithme est O( n) [GM02] contre O(n log 2 n) pour l implémentation séquentielle. 4.2 Primitives amorphes pour les blobs L objectif de ce travail est de montrer la faisabilité d une implémentation d une machine abstraite Blob sur un ordinateur amorphe. La machine Blob étant universelle et d un plus haut niveau que les ordinateurs amorphes, elle est aussi plus simple à programmer qu un ordinateur amorphe s abstrayant en partie des communications et s inspirant du modèle «fork and wait» 4 et des tubes de Posix. Dans cette section, nous allons présenter les structures permettant d implémenter des blobs sur un ordinateur amorphe. 3 Notre variante est plus complète car elle duplique tout le blob quelque soit la polarité de blob fils. Néanmoins l instruction blob originale est disponible si nous n utilisons pas la duplication des blobs fils. 4 Fork est un appel système définit par Posix dupliquant (presque tout) un processus. Les tubes sont des canaux de communication unidirectionnel permettant à des processus de communiquer entre eux. Ils sont dupliqués par l appel système fork permettant aux deux processus dupliqués de communiquer. L appel système wait permet à un processus de se synchroniser sur l arrêt de ses processus fils.

108 Chapitre 4. Vers une implémentation d une machine abstraite Blob 107 Notre approche pour développer ces primitives est inspirée par la biologie : embryologie et biologie cellulaire [Val07]. Les primitives implémentées sont : la construction d un blob. La technique employée est inspirée de l embryologie. Cette primitive sert de base aux autres primitives. Les deux autres primitives déconstruisent partiellement les blobs sur lesquels elles interviennent avant de les reconstruire avec cette primitive. l établissement d un canal de communication, notre technique est inspirée de l embryologie. pour la division d un blob, nous employons une technique inspirée de la biologie cellulaire. Aucun des mécanismes de gestion des communications (direction, polarité) n est actuellement disponible. Nous ne les avons pas implémenté car ils ne sont pas directement liés à des techniques de programmation amorphe Structure de composants pour les blobs Dans notre implémentation, un blob est contenu dans un ou plusieurs éléments de calcul. Un identifiant marque chacun des blobs. Nos éléments de calcul pouvant recevoir des blobs sont structurés en plusieurs composants. Chaque primitive est prise en main par un composant spécifique appuyé par des composants utilitaires [Fig. 4.2]. Les composants mis en jeux sont les suivants : blob-element est un élément de calcul pouvant héberger des blobs. Un élément de calcul pouvant encore contenir des nouveaux blobs contient un identifiant vide ; blob symbolise un blob contenu dans le blob-element ; motion permet de déplacer un blob dans un élément de calcul reconnu vide. Le déplacement des blobs permet d optimiser leur placement dans l ordinateur amorphe. Toutes les primitives blobs l utilisent directement ou indirectement ; duplication copie un blob en utilisant un déplacement bridé. Ce composant est utilisé au début de la division d un blob ; aggregation construit un blob compact à partir d éléments de calcul dispersés dans l espace. La méthode utilisée est inspirée de la morphogénèse des amibes Dictyostelium discoideum, la stigmergie, ainsi que des mécanismes entrant en jeux lors de la différenciation dans les morulas ; linking lie deux blobs afin de préparer l établissement d un canal de communication entre eux. Ce composant utilise l agrégation ; division encapsule les deux composants de la division d un blob : prophase et télophase :

109 Chapitre 4. Vers une implémentation d une machine abstraite Blob 108 <<Component>> blob element 1 1..* 1 <<Component>> blob id <<Component>> division <<Component>> linking <<Component>> prophase <<Component>> duplication <<Component>> motion movestate +tid <<Component>> telophase +leader substract 2 <<Component>> density <<Component>> gradient leader 1 <<Component>> gradient gradient_value +propagation 2 2 <<Component>> aggregation Fig. 4.2: Diagramme UML des composants d un blob embarqué dans un élément de calcul amorphe. prophase est la première partie de la division d un blob. Le blob se duplique et double de volume ; telophase est la seconde partie de la division. Les deux blobs se séparent en blobs distincts ; gradient construit un gradient. Nous l avons déjà définit à la section ; density contrôle la densité des éléments de calcul des blobs dans l espace ; gradient-leader est un gradient augmenté de l élection d un leader où seul le gradient du leader reste actif. La portée de ce gradient est alors globale contrairement aux gradients normaux qui ont une portée plus locale dut aux collisions entre eux.

110 Chapitre 4. Vers une implémentation d une machine abstraite Blob Déplacement de l état d un élément de calcul Avant de définir l agrégation d un blob à partir d éléments de calcul éparses, nous devons définir le déplacement des états d un élément de calcul dans l ordinateur amorphe. Les blobs se reconfigurant constamment dans l espace, cette première primitive est essentielle mais ne fait pas partie du modèle de blob mais des primitives bas niveaux. Le déplacement d un élément de calcul source vers un élément de calcul cible choisi et vide s effectue en transmettant l état source vers l élément de calcul cible puis l élément de calcul source se déclare vide. Dans le cadre d un ordinateur amorphe plusieurs problèmes surgissent : les communications sont omnidirectionnelles. Par conséquent, tous les éléments de calcul autour de l élément de calcul source reçoivent les messages de déplacement et peuvent, tous en même temps, se considérer comme étant l élément de calcul cible de ce déplacement. Afin qu il n y ait qu un seul élément de calcul cible, nous dotons tous les éléments de calcul d un identifiant numérique choisi aléatoirement 5. Grâce à cet identifiant, nous pouvons adresser les éléments de calcul individuellement. par défaut, l ordinateur amorphe est isotropique. Dans ces conditions, l élément de calcul cible ne peut être sélectionné qu aléatoirement, décrivant ainsi un déplacement brownien. Néanmoins, nous pouvons contrôler les déplacements des éléments de calculs en dotant l ordinateur amorphe de vecteurs de déplacement. Ces vecteurs sont construits avec des gradients. Les éléments de calcul se déplacent alors en remontant ou en descendant le gradient de déplacement. Dans notre implémentation, nous avons généralisé et simplifié le contrôle des déplacements en sélectionnant les éléments de calcul cibles en fonction d une condition donnée. Le premier élément de calcul répondant à cette condition est sélectionné. Nous décrivons le déplacement dans l algorithme 4.1. Nous distinguons deux parties. Dans la première partie, l élément de calcul source transmet son état à l élément de calcul cible. Lors de la seconde partie, l élément de calcul cible prévient l élément de calcul source qu il a bien reçu l état de ce dernier avant de s activer. Il autorise ainsi l élément de calcul source à se déclarer vide. Le composant de déplacement possède deux états : tid est un état public contenant l identifiant de l élément de calcul cible chez 5 Dans nos simulations, l identifiant est codé sur 32 bits. Nous construisons couramment des ordinateurs amorphes où chaque élément de calcul a de 16 à 32 voisins (surface de unités avec à 10 5 éléments de calcul avec un rayon de communication de 1 unité). Ce nous donne une probabilité de collision des identifiants de 1 /2 27 qui nous considérons comme nulle dans ce travail. Nos simulations dans un espace 3D font intervenir plus d éléments de calcul ( à 10 6 ) mais chaque élément de calcul possède moins de voisins que dans nos simulations dans un espace 2D.

111 Chapitre 4. Vers une implémentation d une machine abstraite Blob 110 Initialisation: movestate Initialisation: tid 1: composant Déplacement État(condition) 2: si movestate = actif deplacable alors 3: tid Sélectionne un id dans voisinage(condition) 4: movestate attente 5: Publier état du blob() 6: fin si 7: si movestate = vide alors 8: avec message tid = id faire id est l identifiant de l élément de calcul 9: Recevoir l état du blob() 10: movestate copie 11: tid id 12: fin avec message 13: fin si 14: si movestate = attente alors 15: avec message tid = tid movestate = copie faire 16: movestate vide 17: fin avec message 18: si Timeout() alors 19: movestate actif 20: fin si 21: fin si 22: si movestate = copie alors 23: avec message tid = tid movestate = vide faire 24: movestate actif 25: fin avec message 26: si Timeout() alors 27: movestate vide 28: fin si 29: fin si 30: fin composant 31: fonction Déplacer(element,condition) 32: deplacable vrai 33: fin fonction Algorithme 4.1: Déplacement de l état d un élément de calcul vers un élément de calcul vide.

112 Chapitre 4. Vers une implémentation d une machine abstraite Blob 111 Source Cible movestate == actif movestate == vide 1: tid = choisir_recepteur 2: tid 3: movestate = attente 5: movestate 7: etat du blob 4: tid == id et accepte la copie 6: movestate= copie 8: tid = tid recu 9: movestate 10: tid 11: tid == tid reçu et movestate reçu == copie? 12: movestate= vide 13: movestate 14: tid 15: tid == tid recu et movestate recu == vide? 16: movestate= actif Fig. 4.3: Diagramme UML de séquence du déplacement réussi de l état d un élément de calcul vers un élément de calcul vide.

113 Chapitre 4. Vers une implémentation d une machine abstraite Blob 112 l élément de calcul source et l identifiant de l élément de calcul source chez l élément de calcul cible. movestate est un état privé symbolisant les quatre états des éléments de calcul lors du déplacement : actif : l élément de calcul contient un blob (ou tout autre état transférable) en fonctionnement normal. Un élément de calcul actif peut, si les conditions lui permettent, initier un déplacement vers un élément de calcul vide ; vide : l élément de calcul n est pas actif et est prêt à recevoir l état d un élément de calcul voisin ; copie : un élément de calcul précédemment vide vient de recevoir et d accepter l état d un élément de calcul source ; attente : l élément de calcul précédemment actif vient d envoyer son état et attend que l élément de calcul cible lui renvoie un accusé de bonne réception. Dans cet état, l élément de calcul ne calcule plus. La figure 4.3 nous montre les échanges de messages entre l élément de calcul source et l élément de calcul cible. Ainsi, dans la première partie de l algorithme, un élément de calcul actif commence par choisir l élément de calcul qui l accueillera en évaluant la condition de sélection. Si la condition de sélection est une descente de gradient, l élément de calcul source retiendra l élément de calcul vide émettant la valeur de gradient la plus faible. Si plusieurs candidats répondant à la condition se présentent lors de la sélection, seul le premier est retenu. Une stratégie a été étudiée pour discriminer les bons candidats équivalents : l élément de calcul cible est choisi aléatoirement parmi les bons candidats. Mais cette méthode a l inconvénient de nous obliger à conserver la liste de tous les candidats. Une fois l élément de calcul cible choisi, l élément de calcul source envoie l identifiant de l élément de calcul cible. Puis il change son état de déplacement d actif à attente et le diffuse suivi de son état complet. Tous les voisins reçoivent ces messages mais les ignorent sauf l élément de calcul cible, dont l identifiant est égal à celui envoyé par l élément de calcul source via le message tid. L élément de calcul cible remplace son état par celui qu il a reçu de l élément de calcul source puis il modifie son état de déplacement en copie. La seconde partie a pour but de valider la réception de l état dans l élément de calcul cible. Pour cela, l élément de calcul cible transmet son état de déplacement (copie) et l identifiant de l élément de calcul source. À la réception de ces informations, l élément de calcul source valide l état de l élément de calcul cible en se déclarant vide. Si l accusé de réception n arrive pas avant un délai d expiration donné alors l élément de calcul source considère que le déplacement a échoué et change alors son état de déplacement en actif. Dans le cas où l accusé de réception

114 Chapitre 4. Vers une implémentation d une machine abstraite Blob 113 parvient à l élément de calcul source alors ce dernier envoie également son état de déplacement (vide) et l identifiant de l élément de calcul cible. À la réception de ces informations, l élément de calcul cible valide l état de l élément de calcul source en se déclarant actif. Si l accusé de réception n arrive pas avant un délai d expiration donné alors l élément de calcul cible considère que le déplacement a échoué et change alors son état de déplacement en vide Agrégation Le composant agrégation construit et maintient un blob compact à partir d éléments de calcul appartenant à ce blob [Fig. 4.4]. Cette primitive est nécessaire sur un ordinateur amorphe. En effet, les éléments de calcul d un blob communiquent entre eux via les arcs verticaux et les canaux de communication. De plus, les éléments de calcul d un blob peuvent apparaître dans l ordinateur amorphe dans des positions géographiquement éloignées. Par conséquence pour optimiser les communications à l intérieur d un blob, il est nécessaire de maintenir les éléments de calcul d un blob proche les uns des autres. Par exemple, si un ordinateur amorphe dispose de plusieurs ports d entrée/sortie, des éléments de calcul d un même blob peuvent se former autour de ses ports. Comme le temps de transmission d un message entre deux éléments de calcul est fonction de la distance qui les séparent, il est préférable de chercher à minimiser la distance entre les éléments de calcul d un même blob. Le méthode que nous employons ici est directement inspirée de l agrégation des amibes Dictyostelium Discoideum [GS77]. Lorsque leurs conditions de vie sont favorables (la nourriture est suffisante), ces amibes vivent individuellement dans la terre. Mais si la nourriture vient à manquer alors elles se regroupent afin de former une «limace» de quelques millimètres de long. L agrégation des Dictyostelium Discoideum est contrôlée par l enzyme AMPc. Les amibes diffusent cette enzyme par vague dans leur environnement et se déplacent dans la direction où la concentration de AMPc est la plus forte. Un principe analogue est observé dans le fouragement des fourmis. Les fourmis ramenant de la nourriture marquent leur chemin à l aide d un phéromone 6. Les fourmis croisant cette piste peuvent la remonter pour trouver la source de nourriture. Ce phénomène a été étudié et formalisé par Deneubourg [BHJ94]. Parunak et Brueckner [PB01] ont montré que cette méthode d agrégation fonctionne dans le cadre de la programmation multi-agents. Dans notre implémentation (voir l algorithme 4.2), les éléments de calcul d un 6 Toutes les fourmis ne marquent pas leur environnement avec des phéromones. Il existe une espèce de fourmis saharienne (Cataglyphis bicolor) qui se dirige en utilisant la polarité de lumière du soleil. Dans le désert, les phéromones s évaporent trop vite pour y être efficaces. Ce moyen de navigation a inspiré les roboticiens [Lam03].

115 Chapitre 4. Vers une imple mentation d une machine abstraite Blob 114 Fig. 4.4: Les figures de (a) a (d) montrent quatre e tapes dans l agre gation d un ensemble d e le ments de calcul disperse s d un blob en un blob compact. blob se de placent en descendant un gradient d agre gation. Un e le ment de calcul du blob de termine s il se situe dans un gradient d agre gation de son blob s il rec oit des messages «gradient d agre gation» de son voisinage. S il est dans un gradient d agre gation alors il se de place vers l e le ment de calcul vide dont la valeur du gradient d agre gation est la plus faible avec le composant pre sente a la section Donc l agre gation d un blob ne de pend que de la bonne gestion des gradients d agre gation. Notre algorithme fonctionne sans leader. C est a dire qu il n existe pas d e le ment de calcul privile gie pour initier les gradients d agre gation. Ici, un gradient d agre gation peut e tre initie par n importe quel e le ment de calcul du blob. Les e le ments de calcul du blob non soumis a un gradient d agre gation ont une probabilite p d en initier un7. Deux gradients d agre gation d un me me blob 7 Nous utilisons p = 1/25000 pour toutes nos simulations. Cette probabilite doit permettre

116 Chapitre 4. Vers une implémentation d une machine abstraite Blob 115 peuvent être actifs à un instant donné et plusieurs agrégats apparaissent. Afin que cette situation ne soit pas définitive, les gradients d agrégations ont une durée de vie limitée. Ainsi les éléments de calcul du blob, libérés du gradient d agrégation, peuvent à nouveau initier un gradient d agrégation. Les éléments de calcul ayant commencés de s agréger avec les gradients précédents, les nouveaux gradients ont une plus grande probabilité de s initier dans un ensemble d éléments de calcul déjà agrégé accumulant ainsi de plus en plus d éléments de calcul du blob. Requis: G : Gradient() Requis: Déplacement État() Initialisation: initiateur f aux Initialisation: timeout 0 1: composant Gestion des gradients d agrégation(p) 2: si appartient au blob() alors 3: si G Probalité(p) = vrai alors 4: Initier Gradient(G) 5: initiateur vrai 6: timeout now() + timeout 0 now() renvoie l heure courante. 7: fin si 8: si initiateur now() timeout alors 9: Effacer Gradient(G) 10: initiateur f aux 11: fin si 12: fin si 13: fin composant 14: composant Agrégation( ) 15: si appartient au blob( ) alors 16: si G alors 17: Déplacer(,min(G)) descente du gradient 18: fin si 19: fin si 20: fin composant Algorithme 4.2: Agrégation d un blob à partir d éléments de calcul éparpillés Liaison Le temps de communication entre deux blobs est fonction de la distance les séparant. Le composant de liaison de deux blobs accole ces blobs afin de minimiser d initier des gradients dans un temps raisonnable mais elle ne doit pas en initier trop souvent afin de ne pas favoriser un groupe d éléments de calcul par rapport à un autre.

117 Chapitre 4. Vers une implémentation d une machine abstraite Blob 116 les temps de communication entre eux. L algorithme utilisé par notre composant est inspiré par polarisation lors de la gastrulation des blastocystes [Wol99]. La gastrulation est l étape dans le développement des embrayons des vertébrés où se forme ce que donnera le tube gastrique. Pour ce faire, des cellules se déplacent vers l intérieur du blastocyste. Le mouvement de ces dernières est déclenché et contrôlé par la concentration d un enzyme. Notre algorithme de liaison de deux blobs A et B est contrôlé par deux gradients d agrégations initiés par chacun des deux blobs. Les deux gradients sont gérés avec le même algorithme de gestion que pour l agrégation (voir la section 4.2.3). Chaque élément de calcul de blob descend le gradient de l autre blob. En l état, la liaison mélange les éléments de calcul des deux blobs et les blobs ne sont plus agrégés. Pour éviter cela, nous ajoutons la règle suivante à l agrégation de la section précédente : si un blob perçoit la présence d un élément de calcul de l autre blob dans le voisinage alors il descend le gradient d agrégation de son blob. Nous détectons les éléments de calcul de l autre blob en demandant la densité de cet autre blob dans le voisinage Composant densité Le composant densité renvoie une estimation de la densité des éléments de calcul d un blob présent dans le voisinage de l élément de calcul. Nous utilisons ce composant pour détecter la présence d éléments de calcul de l autre blob dans le voisinage du blob courant. Ce composant est une variation de la propagation présentée à la section Les éléments de calcul émettent leur identifiant de blob [Alg. 4.3]. Un élément de calcul de blob recevant cet identifiant incrémente un compteur compteur e. Le compteur compteur b est incrémenté si l identifiant de blob reçu est le même que l élément de calcul courant. Les compteurs sont remis à zéro régulièrement. Le compteur compteur e contient une estimation du nombre d éléments de calcul du voisinage appartenant à un blob. Le compteur compteur b contient une estimation du nombre d éléments de calcul du voisinage appartenant au même blob que l élément de calcul courant. Le rapport entre les compteurs compteur b et compteur e est alors une estimation de la densité des éléments de calcul appartenant au même blob que l élément de calcul courant Composant liaison Nous décrivons le composant liaison dans l algorithme [Alg. 4.4].

118 Chapitre 4. Vers une implémentation d une machine abstraite Blob 117 Initialisation: timestamp now() Initialisation: blob A 1: composant Densité(A) A est l identifiant du blob courant 2: si appartient au blob(a) alors 3: si now() timestamp alors 4: blob blob l identifiant blob est transmit 5: compteur e 0 6: compteur b 0 7: timestamp now() + time 8: fin si 9: avec message blob faire 10: compteur e compteur e : si blob = A alors 12: compteur b compteur b : fin si 14: fin avec message 15: fin si 16: fin composant 17: fonction Densité(A) 18: renvoyer compteur b compteur e 19: fin fonction Algorithme 4.3: Estimation de la densité locale des éléments de calcul appartenant au blob A parmi tous les éléments de calcul appartenant à un blob. Requis: G A, G B : Gradient() Requis: Gestion des gradients d agrégation(p GA, p GB ) Requis: Déplacement État() Requis: Densité(A) 1: composant Liaison(G A ) 2: si appartient au blob(a) alors 3: si G B densité(a) = 1 alors 4: Déplacer(,min(G B )) Déplacement vers B 5: fin si 6: si G A densité(a) < 1 alors 7: Déplacer(,min(G A )) Déplacement vers A 8: fin si 9: fin si 10: fin composant Algorithme 4.4: Liaison de deux blobs A et B.

119 Chapitre 4. Vers une imple mentation d une machine abstraite Blob 118 Fig. 4.5: Les figures de (a) a (d) montrent quatre e tapes dans la liaison entre deux blobs. Les e le ments de calcul des blobs produisent des gradients d agre gation. Ils se de placent en descendant les gradients de l autre blob sauf s ils de tectent un e le ment de calcul de l autre blob dans leurs voisinages. Cette de tection est assure e si l estimation de densite des e le ments de calcul d un blob est infe rieure a 1. Lors de l estimation de la densite, si un e le ment de calcul e met plusieurs fois son identifiant de blob entre deux remises a ze ro des compteurs, cela n a pas d influence sur l algorithme de liaison. L information de la pre sence d un e le ment de calcul d un autre blob est disponible me me si l estimation n est pas pre cise. La figure 4.5 pre sente quatre e tapes dans la liaison de deux blobs. Les deux blobs commencent par se rapprocher puis une ligne de frontie re s e tablit et reste stable dans le temps

120 Chapitre 4. Vers une implémentation d une machine abstraite Blob Duplication La duplication d un blob permet d obtenir deux copies distinctes de ce dernier. Notre algorithme s inspire de la division des cellules eucaryotes. Dans la section suivante, nous exposons brièvement des mécanismes de divisions cellulaires rencontrés en biologie et nous en extrairons des principes pour concevoir notre algorithme de division Mitose Cellulaire En biologie, la division cellulaire (mitose) est différente selon les espèces de cellules.. Chez la plupart des procaryotes 8, le mécanisme est simple et est contrôlé principalement par l ADN. La division cellulaire s effectue selon le processus de fission binaire suivant : l ADN se duplique ; la cellulaire prend du volume en se nourrissant ; l ADN va se fixer sur la membrane. Puis l ADN migre afin que les deux brins soient dans des positions opposées ; la cellule s allonge le long de l ADN puis se sépare en deux parties. Si nous nous inspirons de la division des procaryotes, nous avons besoin d une membrane afin que l ADN se fixe dessus. Notre modèle actuel ne possède pas de membrane. Les propriétés de la membrane sont : séparer l intérieur du blob de l extérieur. être consistante. La membrane ne doit pas se scinder. La membrane ne doit pas avoir de trou. la membrane fait parti du blob et doit en suivre le contenu. Nous aurions retenu ce modèle si nos blobs possédaient une frontière définie. Cette frontière est alors une courbe de Jordan. Nous aurions la tâche de distinguer l intérieur de l extérieur de cette courbe. Les phases de la mitose chez la plupart des eucaryotes animals sont [ABH + 05] : l interphase est la phase de vie normale de la cellule ; l interphase G3, la cellule prend du volume ; la prophase, destruction du noyau. Création des chromosomes. Duplication des centrosomes au début de la phase. Déplacement des centrosomes ; la métaphase, formation de la plaque équatoriale ; L anaphase, les chromosomes migrent vers les centrosomes ; la télophase, séparation des deux cellules et reformation du noyau. Notre implémentation s inspire de la mitose des eucaryotes. 8 Les procaryotes sont les cellules sans noyau comme les bactéries.

121 Chapitre 4. Vers une implémentation d une machine abstraite Blob 120 interphase G3 duplication densite 50% prophase + teleophase Creation des centosomes deplacement vers les centrosomes Fig. 4.6: Diagramme d activité de la mitose d un blob. Les deux phases sont exprimées : l interphase G3 duplique chaque élément de calcul ; la prophase et la télophase séparent les éléments de calcul.

122 Chapitre 4. Vers une implémentation d une machine abstraite Blob Implémentation avec Tical Comme le montre la figure 4.6, notre implémentation de la division de blob est scindée en deux composants : interphase G3 et prophase + télophase. L interphase G3 duplique tous les éléments de calculs du blob et maintient une densité de 50%. La prophase construit deux zones d attractions privilégiées (centrosomes), une pour chaque blob. La télophase sépare les deux blobs en les agrégeant autour de leur «centrosome» respectif. Ces deux composants sont directement inspirés des deux phases de la mitose des eucaryotes. Les autres phases de la mitose des eucaryotes ne concernent que l ADN et n ont pas lieu d être dans la division des blobs. En effet, les blobs ne possèdent pas de membranes, ni d ADN. Interphase G3 Le composant interphase G3 effectue la duplication du blob initial ainsi que le maintien des deux blobs obtenus à une densité de 0.5. Le duplication des éléments de calcul du blob initial utilise une modification du déplacement de état d un élément de calcul. La duplication (tout comme le déplacement) de l état d un blob nécessitant un élément de calcul vide, seuls les éléments de calcul de la couronne du blob initial se duplique (voir la figure 4.7 (a) et (b)). Les éléments de calcul au centre du blob n ont pas d élément de calcul vide pour s y dupliquer. Afin d avoir l espace nécessaire, nous demandons aux éléments de calcul des blobs de se maintenir dans une densité de 0.5. L utilisation d une densité plus faible accélère également la télophase. Le composant duplication de l état d un élément de calcul est une modification du composant déplacement. Dans ce composant, les états de déplacements attente et copie sont inhibés. Dès que l élément de calcul cible reçoit l état de l élément de calcul source, il change son état de déplacement en actif. Les deux éléments de calcul sont alors actif et possèdent le même état. Le composant interphase G3 (voir l algorithme 4.5) commence par tenter de dupliquer les éléments de calcul du blob A. Puis les éléments de calcul sources deviennent les éléments de calcul du blob B. Le blob A dupliqué, les éléments de calculs des blobs déterminent la densité des éléments de calcul du blob dans leur voisinage (voir l algorithme 4.3). Si cette densité est supérieure à 0.5 alors ils se déplacent en remontant les gradients d agrégation. Si la densité est inférieure à 0.5 alors ils ne se déplacent pas. La gestion des gradients d agrégation est la même que précédemment. Prophase + Télophase Le composant Prophase + Télophase sépare et agrège les deux blobs obtenus après l interphase G3. En effet, à la sortie du composant précédent les éléments de calcul des deux blobs sont mélangés et ayant une densité

123 Chapitre 4. Vers une implémentation d une machine abstraite Blob 122 Requis: G A : Gradient() Requis: Gestion des gradients d agrégation(g A ) Requis: Déplacement état() Requis: Copie état() Copie l état d un blob et copie? vrai Requis: Densité(A B) Initialisation: copie? f aux 1: composant Interphase G3(A B) 2: si copie? blob = blob A alors 3: Copie état(,max(g A )) 4: blob B 5: sinon 6: si Densité(A B) < d 0 alors 7: Déplacer(,max(G A )) 8: fin si 9: fin si 10: fin composant Algorithme 4.5: Algorithme de l interphase G3 d un blob A vers un blob B. Requis: G Al, G Bl : Gradient(condition mlid = lid) Gradients suivant le leader Requis: Gestion des gradients d agrégation(p normaliser(dif)) Requis: Agrégation() Initialisation: lid id Initialisation: mlid lid 1: composant Prophase() 2: avec message mlid > id faire Le leader a le plus grand id 3: lid mlid 4: mlid lid Émission du nouveau leader 5: fin avec message 6: si lid = id alors 7: Initier Gradient(G Al G Bl ) 8: fin si 9: dif G Al G Bl 10: fin composant 11: composant Telophase(A B) 12: Agréger(A B) 13: fin composant Algorithme 4.6: Algorithme de la prophase + télophase lors de la division de deux blobs.

124 Chapitre 4. Vers une implémentation d une machine abstraite Blob 123 de 0.5. Si nous appliquons directement le composant agrégation, nous n obtiendrons pas deux blobs distincts mais un ensemble de groupes d éléments de calcul imbriqués de tailles relativement petites. Ces derniers utilisent respectivement une surface plus grande que les même blobs agrégés distinctement. Donc les communications intra-blobs sont moins optimales. De plus, le risque de collisions de messages avec l autre blob est plus important. Afin d obtenir deux groupes distincts, nous contrôlons le mécanisme de création des gradients d agrégations. Chacun des deux blobs doit initier ses gradients d agrégation loin de l autre blob. Pour cela, nous créons deux zones diamétralement opposées autour des deux blobs. Ces zones ont une forte probabilité d initier des gradients d agrégation, séparant ainsi les deux blobs en deux entités distinctes. Notre algorithme s inspire des deux phases prophase et télophase de la mitose des eucaryotes. Lors de la prophase, le centrosome de la cellule se divise en deux et chacun migre dans une position diamétralement opposée. Ces deux centrosomes guideront le reste de la division, notamment en définissant le plan équatorial selon lequel la cellule se scindera lors de la télophase. Comme le montre l algorithme 4.6, les deux composants prophase et télophase fonctionnent en parallèle. Ainsi le composant prophase, commence par élire un leader. L identifiant du leader est conservé dans l état lid. Dès que l identifiant lid est modifié, celui-ci est reémit via un message mid. À la réception d un message mid, nous comparons l identifiant reçu avec l identifiant de l élément de calcul courant. Si ce dernier est plus grand alors il devient le nouveau leader. Les éléments de calcul des blobs leaders initient un gradient. Ce dernier efface les gradients des éléments de calcul qui ne sont pas leaders. Ainsi, une fois l élection achevé, nous obtenons deux gradients : un pour chaque blob. Pendant l établissement de ces deux gradients, les éléments de calculs maintiennent un état dif qui contient la différence entre les valeurs de G Al et G Bl. La figure 4.10 montre le résultat de cette différence. Nous remarquons que cette différence est bornée entre d AB et d AB où d AB est la distance séparant les deux leaders. Le composant télophase agrège les éléments de calcul des deux blobs. La probabilité pour un élément de calcul d initier une gradient d agrégation est ici modérée par l état privé dif. Ainsi les éléments de calcul des blob s agrègent autour des maximas de leur dif respectifs. 4.3 Conclusion Nous avons exposé le modèle de machine abstraite blob. Nous venons de montrer comment implémenter trois des primitives blob en nous inspirant de la biologie. Nous avons commencé par doter les éléments de calcul des blobs d une capacité de déplacement de leurs états internes guidée par des gradients. Grâce à cela, nous

125 Chapitre 4. Vers une implémentation d une machine abstraite Blob 124 pouvons agréger les éléments de calcul en blob compact et lier deux blobs. La division ajoute au mécanisme précédent la création de deux «centrosomes» grâce à une différence algébrique de deux gradients. Nous retenons le modèle des blob pour implémenter un futur langage de programmation d ordinateur amorphe de haut niveau.

126 Chapitre 4. Vers une imple mentation d une machine abstraite Blob 125 Fig. 4.7: Les figures de (a) a (d) montrent quatre e tapes du processus de mitose lors de l interphase G3. La figure (a) est le blob au de but de l interphase G3. Les figures (b) et (c) montrent le blob «rouge» en cours de duplications et d expansion. Dans la figure (d), la duplication est acheve e mais les deux blobs continuent leurs expansions afin d obtenir une densite de 0.5.

127 Chapitre 4. Vers une imple mentation d une machine abstraite Blob 126 Fig. 4.8: Les figures de (a) a (c) montrent trois e tapes du processus de mitose lors de la prophase + te lophase. La figure (d) montre le gradient diffe rentiel G dab apre s l e lection d un leader par blob.

128 Chapitre 4. Vers une implémentation d une machine abstraite Blob 127 Fig. 4.9: Les figures de (a) et (b) montrent deux étapes de la prophase + télophase lors de la division d un blob dans un espace 3D.