Intégration optimisée

Si l’on souhaite intégrer les activités en un point de l’espace, il suffit de centrer le domaine de recherche autour de celui-ci. Reste à fixer un rayon dans lequel prendre en compte les inter-actions, afin de négliger celles qui sont trop lointaines et ne peuvent suffisamment propager leur activité jusqu’au centre. Un problème subsiste : la structure étant générique et les interactions pouvant être réparties de manière totalement arbitraire, comment fixer les dimensions du do-maine de recherche ? Dans d’autres termes, que signifie ce "trop lointain" et "suffisamment" dans un espace d’interaction ou seule les distances et activités relatives comptent ? Quelle que soit la distance limite fixée, une interaction juste au delà de la frontière sera négligée alors qu’une interaction légèrement plus proche sera prise en compte.

Dans l’application du pendule/chariot qui a vu le développement de ces optimisations, une interpolation d’anticipations (différente de celle des actions dans la dernière version du modèle) était réalisée en chaque point de l’espace. La figure 2.7 reprend les performances dans la re-cherche et l’interpolation obtenues après optimisation. Le cas le pire était évidemment celui où deux anticipations contradictoires se retrouvaient séparées par la frontière. Dans les dernières versions du modèle néanmoins, un problème similaire se pose pour l’intégration de l’activité des anticipations. On doit s’assurer que les interactions à l’extérieur d’un domaine de recherche donné ne pourront jamais propager une activité supérieure au maximum des activités intégrées à l’intérieur de celui-ci. De manière formelle, pour un point d’intégration C et un rayon de recherche r (en utilisant la norme ∞), on doit avoir :

∀I ∈ I tel que kI − Ck∞> r, ∀I⁰∈ I tel que kI⁰− Ck∞≤ r, p(I, C) ≤ p(I⁰, C) (2.1) en utilisant les notations du chapitre Structure du modèle mathématique, soit I l’ensemble des interactions de l’espace et p(I, C) l’activité de I propagée en C. Un cas de mauvais choix de rayon et donc de frontière est représenté sur la figure2.6a.

La solution choisie est de rechercher itérativement une frontière correcte. Pour cela, on com-mence par choisir arbitrairement un rayon minimal. Celui-ci doit simplement permettre à la première recherche de se faire rapidement, par exemple sur un domaine réduit de rayon r₁ in-versement proportionnel à la densité moyenne des interactions (densité facilement calculable à la racine de l’arbre). On évalue ainsi le maximum local p(I, C) des activités propagées dans le domaine de recherche. On peut alors déterminer un rayon r₂ tel qu’aucune interaction I⁰ en de-hors du domaine de rayon r₂ ne pourra jamais propager une activité telle que p(I⁰, C) > p(I, C)

quel que soit son niveau d’activité propre (figure2.6b).

Un dernier raffinement non détaillé ici consiste à considérer les feuilles et nœuds les plus dis-tants par leurs moyennes plutôt que par la liste exhaustive des activités qu’ils contiennent. On économise ainsi de nombreuses opérations et les calculs de moyennes effectués lors de l’insertion des interactions dans leur branche fournissent une approximation acceptable. Cette améliora-tion a également le mérite de limiter les discontinuités du champ d’activité générées par les optimisations précédentes.

I' I C activité Y X X X X Y _(a) activité C I I' p(I,C)<p(I',C) r p(I,C)>p(I',C) (b) 1 r 2 r

Figure 2.6 – (a) Avec un choix arbitraire de domaine de recherche (disque de rayon r ), il est probable qu’une interaction non prise en compte (I’ ) propage une activité supérieure au maximum des activités propagées dans le domaine (p(I,C)). (b) En augmentant itérativement le rayon de recherche (r₂), on peut s’assurer qu’aucune interaction non prise en compte n’est prédominante. nombre de points Recherche et ( s)µ temps ³⁰⁰ 40 20 0 Insertion interpolation 10000 0 2500

Figure 2.7 – Temps d’accès et d’insertion de nouveaux points dans le graphe BSP de l’applica-tion du pendule/chariot (bleu) et temps nécessaire à la sélecl’applica-tion des feuilles et à l’interpolal’applica-tion en un point de l’espace (rouge). Les deux sont représentés ici en fonction du nombre d’anti-cipations dans l’espace. La variabilité de distribution des points dans l’espace provoquent des variations, mais les régressions linéaires montrent que le coût d’insertion de nouveaux points devient quasi-constant (les partages de feuilles sont de moins en moins fréquents) alors que le temps d’interpolation croît avec un facteur de proportionnalité très faible.

Parallélisation

Sommaire

3.1 Cadre général . . . 167

3.1.1 Contexte et architectures existantes . . . 167

3.1.2 Domaines d’application . . . 169

3.1.3 Avantages additionnels . . . 171

3.2 Librairie de traitements visuels sur GPU. . . 171

3.2.1 État de l’art . . . 171

3.2.2 Contraintes théoriques . . . 173

3.3 Implémentation des processus visuels . . . 174

3.3.1 Filtre/processus individuel . . . 174

3.3.2 Multitude de processus . . . 176

3.3.3 Ordonnancement PERT . . . 178

3.4 Performances . . . 179

3.4.1 Comparaison des implémentations. . . 180

3.4.2 Complexité. . . 180

3.1 Cadre général

3.1.1 Contexte et architectures existantes Comme précisé dans l’introduction du chapitre précédent, on a tout intérêt à gagner du temps d’exécution en s’attaquant à différents maillons de la chaîne de développement. En plus de l’optimisation des algorithmes précédemment considérée, on s’intéresse ici à la parallélisa-tion du code. L’idée même d’architecture parallèle n’est pas nouvelle et depuis longtemps sont conçues des architectures dédiées. Néanmoins, que ce soit à cause des limites physiques au cœur des processeurs standards, d’une volonté de profiter de la puissance inexploitée des processeurs du monde entier ou de toute autre raison qui ne nous concerne pas ici, le parallélisme connaît un engouement récent. On peut citer aujourd’hui les grilles de calculs, les processeurs multi-cœurs, les FPGA (Field-Programmable Gate Arrays), les GPU (processeurs de cartes graphiques), ou les processeurs de consoles de salon (triple cœur PowerPC pour la XBox360 ou Cell Broadband Engine pour la Playstation3 par exemple). L’invasion du marché par de telles architectures les rend désormais accessibles à n’importe quel utilisateur. Encore faut-il pouvoir exploiter leur potentiel...

Certains algorithmes sont fondamentalement séquentiels et donc difficiles à paralléliser, au-quel cas l’intervention de spécialistes capables de transformer les problèmes et les algorithmes est nécessaire. D’autres algorithmes, tels que ceux présentés dans ce manuscrit, sont clairement conçus pour fonctionner en parallèle. Exploiter le matériel disponible relève alors du domaine technique. C’est sur ces aspects techniques que l’évolution et la diffusion des architectures paral-lèles a eu le plus grand impact. Alors qu’il fallait se débrouiller aussi bien en électronique qu’en informatique, parfois apprendre un langage d’assemblage et maîtriser des commandes complexes pour utiliser des architectures parallèles dédiées à une classe de problèmes, les supports matériels et les suites/bibliothèques logicielles qui les accompagnent sont désormais bien plus flexibles et pratiques.

Ce chapitre va s’intéresser plus particulièrement à trois architectures parallèles (GPU, Cell BE et grille de calcul) dont les caractéristiques sont synthétisées dans le tableau ci-dessous. Celles-ci ont été sélectionnées pour leur coût réduit, leur facilité d’accès et l’utilisation de langages et environnement standards pour les manipuler. Une grille peut en effet reposer sur un ensemble de machines au sein d’un réseau quelconque, les GPU sont présents dans tout ordinateur moderne et le Cell Broadband Engine des derniers serveurs Blade d’IBM est disponible à prix réduit car également intégré à la PS3. De plus, il existe aujourd’hui des librairies pour communiquer avec les GPU (en C ou en Java par exemple via OpenGL) et il est possible d’installer sur la PS3 un système d’exploitation Linux spécifiquement adapté à son architecture.

Architecture GPU Cell BE Grille

Type de composants Pipeline prog. PowerPC/SPE Calculateur

Nombre maximal de composants Élevé Faible Élevé

Puissance des composants Faible Moyenne Variable

Bande passante avec la mémoire Élevée Élevée Réduite Bande passante entre composants Nulle Élevée Réduite Quantité de mémoire locale Quasi-nulle Réduite Élevée

Figure 3.1 – Comparaison d’architectures parallèles variées : processeur graphique (GPU), Cell Broadband Engine, Grille de calcul.

En observant ce tableau, on remarque que les trois architectures couvrent un large spectre de possibilités. Le GPU et la grille de calcul constituent les extrêmes en termes de souplesse et de capacités computationnelles, alors que le Cell BE se positionne comme intermédiaire (figure3.2). Même si la grille de calcul est plus souple, potentiellement bien plus puissante et plus robuste, la communication entre ses composants passe par un réseau de type Ethernet ou pire, Internet. Ce réseau est sujet à des ralentissements et son débit est loin de valoir celui des bus internes aux ordinateurs. Ces défauts s’effacent lorsqu’on considère les derniers supercalculateurs tels que le RoadRunner d’IBM, premier à avoir passé la barrière du pétaflop, constitué de 12960 IBM PowerXCell 8i (version améliorée du Cell BE) et 6480 AMD Opteron double cœur reliés sur de courtes distances par un réseau très haut débit et privé. Ces chiffres sont donnés pour montrer que les limites décrites plus haut n’existent pas en théorie, mais qu’en pratique, peu de laboratoires peuvent se payer une telle infrastructure.

L’utilisation de FPGA, combinée avec des techniques de co-design permettant de spécifier simultanément les aspects matériels et logiciels, peut sembler plus attractive. De plus, quantité de travaux se focalisent sur la parallélisation automatique du code et son implémentation matérielle,

il ne serait donc pas étonnant que ces approches deviennent dominantes à l’avenir, même si pas encore suffisamment accessibles pour être étudiées dans cette thèse.

centrale Sorties Entrées PowerPC cache L2 ^LS SPE SPE LS SPE LS LS SPE SPE LS LS SPE SPE LS LS SPE Mémoire Bus

Figure 3.2 – Architecture du Cell Broadband Engine développé par STI (Sony/Toshiba/IBM). Cette représentation reflète l’organisation spatiale du circuit où un bus d’interconnexion permet à tous les éléments de communiquer entre eux. On est ainsi proche d’une architecture réseau où chaque SPE (Synergistic Processing Element = processeur vectoriel) et le PPE (PowerPC) peuvent échanger des messages. Néanmoins, seul le PPE a accès à la mémoire centrale via son cache L2 alors que les SPE doivent se contenter d’un Local Store de faible capacité.

Dans le document Coordination implicite d'interactions sensorimotrices comme fondement de la cognition (Page 184-188)