Conception de plateforme CBIR basée sur Globus

La plateforme est destinée aux traitements de masse des images, cela concerne la recherche à base de contenu et l’indexation pour de grandes bases d’images. La nature séquentielle des systèmes CBIR rend l’opération de la recherche très lourde et moins utile comme dans le cas des systèmes de traitement des images médicales, où la qualité des résultats et le temps de repense présentent un facteur important, à voire critique. La plateforme à présenter rentre dans le cadre des systèmes CBIR gourmands, ils demandent une grande puissance de calcul afin de clôturer des traitements coûteux sur des images de différents types et de différentes tailles. Partant de l’étape de prétraitement, à l’analyse jusqu’à la reconnaissance et la classification des images, le système a besoin de gérer plusieurs ressources de nature hétérogènes.

La technologie des grilles est largement utilisée dans les Systèmes CBIR pour partager, synchroniser et exécuter les tâches demandées, cela joue un rôle important dans l’augmentation des performances de la plateforme en question.

La plateforme CBIR réalisée dans cette étude porte sur l’utilisation des grilles de calcul avec un middleware largement utilisé Globus, cela est fait dans le but d’améliorer les performances d’un moteur de recherche des images à base de leurs contenues.

L’utilisateur saisit sa requête (image, mots clés), le système analyse cette dernière, il partage et lance les tâches nécessaires, et pour terminer, les résultats sont regroupés, structurés et fournis à l’utilisateur. Afin d’améliorer la qualité des résultats, d’autres fonctions interactives avec l’utilisateur sont disponibles. La plateforme est développée avec des technologies open source, ce qui offre la possiblilier d’ajout de nouveaux modules pour d’autres fonctionnalités.

Interface de passage de message (MPI)

Utilisé pour l’échange de message entre les processus lancés en parallèle, il peut être utilisé dans le développement des applications basées sur les grilles. MPI fournit une librairie pour le transfert de données et la communication entre les programmes en cours d’exécution sur plusieurs processeurs dans les systèmes distribués. Le standard MPI est conçu pour améliorer la portabilité des applications parallèles [86].

La boite à outil Globus, utilise la bibliothèque de communication MPICH-G2, ce dernier implémente MPI pour standardiser la communication via l’échange des messages entres les services des plateformes.

Architecture parallèle

On distingue deux architectures principales, une à mémoire distribuée et l’autre à mémoire partagée. Dans le cas de l’architecture à mémoire distribuée, les ordinateurs aient un accès rapide à leurs mémoires locales, chacun travail à son côté pour résoudre une partie du même problème. Les données sont échangées entre les nœuds (généralement via un réseau haut débit) sous forme de messages. Dans l’architecture à mémoire partagée, les processeurs utilisent un espace de mémoire commun via un bus mémoire à haute vitesse. Cette mémoire partagée permet aux processeurs d’échanger et partager l’accès aux données.

Typiquement le nombre de processeurs utilisés dans cette architectures est limité à seulement (2 - 16) processeurs [87]. C'est parce que la quantité des données qui peuvent être traitées est limitée par la largeur de bande de bus de mémoire.

Types de tâches dans une application parallèle

a) Les tâches séquentielles

Se sont des tâches qui s’exécutent sur un seul processeur. Simple à implémenter, beaucoup d’algorithmes parallèles se basent sur l’exécution séquentielle des tâches, ce qui n’est pas toujours performant [88].

b) Les tâches parallèles

Les tâches parallèles sont des tâches pouvant s’exécuter sur un ou plusieurs processeurs. On peut distinguer trois classes de tâches parallèles :

- Les tâches rigides où le nombre de processeurs qui doivent exécuter la tâche parallèle est fixé à priori.

- Les tâches modelables pour lesquelles le nombre de processeurs n’est pas fixé mais est déterminé avant l’exécution. Cependant, comme dans le cas précédent, ce nombre de processeurs ne change pas jusqu’à la fin de l’exécution.

- Les tâches malléables peuvent voir le nombre de processeurs qui leur est alloué changer au cours de l’exécution (par préemption des tâches ou par redistribution de données).

Décomposition de problème

La conception des algorithmes parallèles repose sur la décomposition du problème en sous problèmes. Ces derniers sont assignés aux CPUs pour les résoudre simultanément. Ils existent deux sortes de décomposition.

Chapitre4 : Systèmes CBIR à base de grilles.

- Décomposition de domaine : (données parallèles), les données sont divisées approximativement de même taille, et fournies ensuite aux différents processeurs, chaque processeur travail sur la partie des données qui y est assignée. Les processus peuvent communiquer périodiquement pour échanger les données. Le parallélisme des données a l’avantage de maintenir un seul contrôle de flux. L’algorithme de données parallèle consiste en une séquence d’instructions élémentaires, une instruction ne peut être exécutée qu’après l’exécution de celle qui la précède. Single-Program-Multiple-Data (SPMD) suit ce modèle lorsque le code est identique sur tous les processeurs.

- Décomposition fonctionnelle : Dans la plupart des temps, la décomposition de domaine n’est pas efficace ou même n’est pas applicable à certains problèmes. Dans les algorithmes de parallélisme fonctionnel, la tâche est divisée en plusieurs sous tâches, ces derniers sont assignées aux processeurs lors leurs disponibilités, et le processeur qui termine le traitement plus vite, aura le maximum de tâches à exécuter.

4.3.2Fonctionnalités de la plateforme

La plateforme est conçu pour la réalisation des tâches gourmandes en imagerie sur des bases d’images locales ou distantes, elle doit rependre aux attentes des utilisateurs, elle fournit les fonctionnalités suivantes :