Figure 6.11 – Diagramme de la tâche "zoom sur une image" traitée en plusieurs étapes selon une approche de programmation multi-agents.
6.6
|
Expérimentation de la flexibilité
6.6.1
Évaluation du temps de réponse du SMA
Protocole
En section2.5nous avons présenté les critères de performance du domaine des systèmes embarqués. Du fait de la complexité de relever avec précision la consommation du CPU et de la mémoire, nous choisissons d’évaluer la performance de notre solution au niveau du temps de réponse.
Nous utilisons une fonction d’instrumentation pour déterminer précisément le temps de réponse du programme. Le compteur se déclenche lors de la demande de zoom de l’utilisateur, et se termine à l’affichage de l’image agran- die. Nous nous plaçons en comparaison avec le programme séquentiel à partir duquel nous avons réalisé notre SMA embarqué. Nous récupérons son temps de réponse selon le même procédé.
CHAPITRE 6.Expérimentation de la flexibilité Z Y6.6. Expérimentation de la flexibilité
Cette manipulation est effectuée sur deux images de différentes tailles, une de largeur 128 pixels par une hauteur de 128 pixels (que l’on note 128x128) et une de 512x512 toutes deux d’encodage PNG. Pour chaque image nous créons un nombre d’agents Pixel de deux au départ jusqu’à vingt pour la dernière expérimentation. Ainsi, nous souhaitons observer l’évolution du temps de réponse en fonction du nombre de pixels à traiter et du nombre d’agents Pixel actifs pour effectuer ce traitement. Notre solution multi-agents applique les deux méthodes d’interpolation présentées, le programme séquentiel applique la méthode bi-linéaire. Pour chaque expérience, nous répétons la procédure de zoom afin d’obtenir un temps de réponse moyen.
Pour nous donner une base de comparaison, nous considérons des temps limites à ne pas dépasser correspondant au domaine du traitement d’images. Si le service demandé à l’agent correspond au décodage d’une image pour l’affi- chage d’une vidéo, nous devrions respecter un seuil minimal nécessaire pour éviter un effet de saccade visuel de 18 images par seconde. Cette cadence requise pour un affichage temps réel correspond à un traitement par image d’une durée maximale de 55 ms.
Dans le cadre d’un traitement sur une image seule, la notion de contrainte sur le temps de réponse du traitement dépend du contexte applicatif. Nous nous plaçons dans le cadre du chargement d’une page Internet. Pour ce contexte, le résultat doit apparaître suffisamment rapidement pour ne pas créer de gêne pour l’utilisateur. Une lenteur d’affi- chage sera détectée par l’œil humain à partir de 250 ms. A l’inverse, en dessous de 100 ms, l’œil humain ne fera plus la différence et considérera simplement la réponse comme "instantanée". Nous établissons ainsi des temps de réponse repères avec une limite de 250 ms pour le traitement d’images et une limite de 55 ms pour du temps-réel lié à une vidéo.
Résultats
Les résultats des expériences visant à relever le temps de réponse des approches multi-agents et séquentielle, en fonction de la taille de l’image traitée et du nombre d’agents Pixel générés, sont visibles sur la figure6.12.
Figure 6.12 –Mesure du temps de réponse pour la réalisation d’un zoom sur une image selon une approche multi-agents comparée au temps de réponse du même travail selon une approche séquentielle.
Sur ce graphique, nous constatons que le nombre d’interactions influe grandement sur le temps de réponse. En effet, plus nous créons d’agents, plus le nombre de messages échangés dans notre SMA augmente ce qui impacte
6.6. Expérimentation de la flexibilité Z Y CHAPITRE 6. Expérimentation de la flexibilité
directement le temps de réponse. Par ailleurs, plus la taille de l’image est importante, plus les interactions inter- agents Pixel pour s’échanger des valeurs sont conséquentes. Nous qualifions ce coût en temps de réponse relatif au transfert d’un message de coût administratif de notre système multi-agents. Si ce dernier reste sous notre limite liée à une image pour de petites matrices, il est directement hors champ pour notre image de 512 par 512 pixels. A partir de cette constatation, nous n’avons pas poussé l’expérimentation avec des images de qualité HD (1920x1080) ou supérieure. Par ailleurs, le temps de réponse est toujours au-dessus de notre limite liée au traitement vidéo.
En termes de performance pure, l’approche séquentielle est toujours la plus rapide. Nous considérons cependant que des optimisations peuvent être apportées au système pour diminuer ce coût administratif. Cette éventualité est précisée dans le chapitre8.2traitant des perspectives.
6.6.2
Qualité du rendu de l’image
Protocole
Nous proposons d’apporter de la flexibilité à notre zoom en offrant la possibilité d’appliquer deux méthodes d’interpolation différentes au sein d’une même image. Le choix de la méthode de calcul à appliquer est déterminé par l’agent en fonction de l’écart de valeur entre les pixels considérés et du contexte matériel de l’agent Pixel. Nos agents Pixel ont à leur disposition les deux méthodes d’interpolation présentées en sous-section6.3.2: l’interpolation par plus proche voisin (PPV) et l’interpolation bi-linéaire (BL).
La méthode PPV correspond à une simple affectation de valeur. Si nous considérons qu’elle représente une consom- mation CPU faible équivalent à 2 % de la capacité maximale du composant, alors la méthode BL, représentant une complexité en termes d’instructions processeurs 23 fois plus importante, implique une consommation CPU forte équivalent à 46 % de la capacité maximale du processeur.
Pour déterminer au cas par cas quelle méthode appliquer, chaque agent Pixel considère l’écart entre les deux valeurs voisines du pixel manquant. Nous considérons un seuil équivalent à la moyenne entre les valeurs minimales et maximales possibles. Si cet écart est supérieur au seuil considéré, nous estimons avoir affaire à un contour (sharp edge). L’agent Pixel applique alors la méthode bi-linéaire pour garder un résultat précis sur ces contours. Dans l’autre cas, les valeurs sont suffisamment proches pour utiliser la méthode du plus proche voisin consistant à recopier les pixels existants. Ces zones sont qualifiées d’uniformes (smooth texture).
Nos agents prennent également en compte leur contexte en observant la charge actuelle du processeur sur lequel ils tournent. Dans le cadre d’un CPU déjà utilisé à plus de 60 %, nous augmentons notre valeur de seuil au-dessus de la moyenne. Le résultat est moins précis, mais l’agent s’adapte ainsi à la disponibilité de son environnement matériel en réduisant au maximum l’utilisation de la méthode la plus coûteuse. Nous observons cette adaptation de nos agents en fonction de leur contexte matériel à travers trois expérimentations.
Nous effectuons d’abord une expérience avec un seul agent Pixel pour observer sa décision avec un seuil inchangé sur l’ensemble de la matrice zoomée. Nous réalisons ensuite une deuxième expérimentation avec cette fois-ci trois agents Pixel. Nous simulons une surcharge du CPU pour l’un d’entre eux. Le but est alors d’observer la différence de choix de l’agent Pixel pensant son CPU surchargé. Nous appliquons enfin une troisième évaluation avec dix instances d’agents Pixel, et simulons une surcharge CPU pour trois d’entre eux.
Résultats
Pour illustrer de façon claire les réactions de nos agents Pixel, nous faisons ressortir visuellement la méthode d’interpolation qui aura été utilisée. Pour la méthode du plus proche voisin, nous représentons notre case avec un pixel vert. Nous appliquons un pixel rouge dans le cas d’une interpolation bi-linéaire.
En Figure6.13, nous présentons l’image d’origine sur laquelle nous effectuons nos agrandissements. Il s’agit d’une représentation de "Lena", une des images de référence pour les évaluations dans le domaine du traitement d’images.
CHAPITRE 6.Expérimentation de la flexibilité Z Y6.6. Expérimentation de la flexibilité
Lena, image d’origine Zoom par 1 agent Pixel Encodage : PNG Taille : 512 x 512
Figure 6.13 –Résultats d’un zoom, partagé entre plusieurs agents avec une interpolation effectuée par un agent Pixel, sur l’image standard "Lena".
En effet, l’image regroupe plusieurs types de visuel comme par exemple des détails avec de nombreux contours ou des zones uniformisées. L’image possède également des variations de luminosité. L’ensemble représente donc une illustration particulièrement propice pour éprouver des algorithmes de traitement d’images.
La seconde image représente le résultat du premier test : agrandissement sur l’image d’origine par un agent Pixel sur l’ensemble de la matrice. Nous constatons que l’agent Pixel a effectué le choix d’appliquer l’une ou l’autre méthode d’interpolation selon son seuil de décision. Nous retrouvons ainsi visuellement les contours de notre image d’origine. Nous validons également la possibilité d’utiliser plusieurs méthodes au sein d’une même image. Nous pouvons aug- menter le nombre de méthodes considérées en proposant de nouvelles familles d’agents maîtrisant ces nouvelles méthodes. Au lieu de reprendre le code existant des agents déjà définis nous intégrons ces nouveaux agents au sein du SMA. Ils sont alors reconnus par la plateforme ce qui rend leurs fonctionnalités directement disponibles.
Ces résultats confirment donc l’apport de nos agents en termes de flexibilité de choix d’algorithmes.
En Figure6.14, nous montrons les résultats obtenus à gauche en effectuant le zoom avec trois agents Pixel et à droite avec une répartition de l’agrandissement entre dix agents Pixel. Nous pouvons observer le changement de seuil de décision dans le cadre des agents Pixel travaillant dans un contexte de surcharge du CPU : l’agent n◦3 à
gauche et les agents n◦3, 5 et 8 à droite. La méthode d’interpolation bi-linéaire considérée comme plus coûteuse est
effectivement beaucoup moins utilisée.
Ces résultats démontrent la capacité des agents à s’adapter à leur contexte et ce durant l’exécution. A travers ces résultats qualitatifs, nous montrons donc bien un apport en flexibilité telle qu’elle est spécifiée en Définition 17.