Algorithmes de la morphologie mathématique pour - Pastel - HAL

Algorithmes de la morphologie mathématique pour les architectures orientées fluxJaromír BRAMBORNous mentionnons également deux autres implémentations qui ont été écrites dans le langage C, sansavoir exploré les capacités SIMD. La première (mentionnée comme C non-SIMD* dans la tab. 8.1) a suividirectement la définition, utilisait abondamment les structures if-else dans les tests de dépassement desbords, et correspond à une implémentation intuitive qu’un programmeur effectue si la performance del’algorithme n’est pas sa priorité. Nous avons restructuré le code de cette implémentation dans une formeplus propre qui ne fait plus appel aux instructions spécifiques à l’architecture (mentionnée comme C non-SIMD**). Nous avons espéré que le compilateur pourrait, dans un tel code, procéder à la vectorisationde la même manière que nous l’avons exposée dans l’algorithme 8.3, mais malgré le gain que nousavons obtenus et qui est dû à la restructuration de cette implémentation, le temps d’exéctution est plutôtdécevant, surtout si on le compare avec les temps obtenu pour les implémentations C++ template SSE2qui intègrent le travail SIMD dans la structure de l’algorithme.Temps d’exécution en ms des algorithmes de la dilatation par segmentsalgorithme méthode typeTaille du segment symétrique (1 ∼ 3 pixels)1 3 5 15 30 60Itératif assembleur 32 bits HOR 1.486 3.893 5.791 13.00 21.96 36.85Itératif assembleur 32 bits VER 3.256 8.596 10.31 31.18 52.35 91.84HGW C non-SIMD* HOR — — 31 — — —HGW C non-SIMD** HOR — — 6.1 — — —HGW C++ template SSE2 HOR 0.626 0.625 0.622 0.602 0.602 0.592HGW C++ template SSE2 VER 0.334 0.331 0.313 0.276 0.261 0.260Légende : HOR = segment horizontal, VER = segment vertical ; L’implémentation assembleur 32 bits est programméeen assembleur et utilise directement les instructions 32 bits de l’architecture Intel IA-32 ; l’implémentation Cnon-SIMD* selon la définition mathématique, utilise abondamment les constructions if-else ; l’implémentation Cnon-SIMD** est la plus optimisée possible en C et à la main sans utiliser les types vectoriels. L’implémentationC++ template SSE2 utilise les classes fournies avec le compilateur Intel ICL pour le calcul vectoriel. L’imaged’entrée/sortie : 768 × 576 × 8 bits = 432 ko ; processeur Intel Pentium 4 à 2.4 GHz, mémoire cache L2 = 512ko ; système d’exploitation Microsoft Windows XP ; compilateur Intel ICL 7.1 pour Windows.TAB. 8.1 : Résultats expérimentaux de diverses implémentations de la dilatation par segmentsLe graphe présentant les temps d’exécution dépendant de la taille du segment pour l’implémentationitérative, cf. la fig. 8.7(a), a tout-à-fait la forme attendue sachant que la complexité de cet algorithme pourune image donnée est de O(K), où K est le nombre de voisins traités par pixel. Les temps d’exécutiongrandissent avec la taille de l’élément structurant linéairement.Nous présentons cette courbe comme contre-exemple pour démontrer qu’il est possible de calculerles dilatations / érosions beaucoup plus rapidement et surtout, avec un algorithme ayant la complexitéO(1), où le temps du calcul ne dépend pas du nombre des voisins traités par pixel, q.v. la fig. 8.7(b).Il s’agit de l’implémentation SIMD de l’algorithme de van Herk-Gil-Werman, cf. les définitions de lafonction algoHGWFstSIMD (l’algorithme 8.4) et de la fonction algoHGWSndSIMD (l’algorithme 8.4).L’écart entre les deux courbes dans la fig. 8.7(b) qui est d’une valeur constante n’est pas surprenantcar nous savons comment nous avons construit ces deux implémentations. Cet écart correspond, eneffet, à 2 exécutions de la transposition par diagonale de l’image entière. Un phénomène plus intéressantprésenté par les mêmes données est celui de la baisse du temps du calcul avec la taille du segmentgrandissant qui est, au premier regard, paradoxal.Au début, nous avons jugé que cette baisse était due aux optimisations que le compilateur peuteffectuer dans le code de boucles lors de l’exécution de la phase p 1 et p 2 à l’échelle des macro blocs. Maisl’explication est, en fait, plus simple. Il s’agirait d’un phénomène dû à la gestion des boucles car pourles tailles grandissantes des segments, nous obtenons moins de macro blocs et par conséquent, moins deboucles. Ce phénomène est présent également dans les implémentations non-SIMD de l’algorithme devan Herk et même dans d’autres, nous renvoyons le lecteur aux articles DB05 et aux publications DD06 quiprésentent les graphiques avec des tendances similaires.174