Profilage d’applications flot de données

Précédemment, nous avons abordé le traçage et le profilage des processeurs traditionnels et graphiques. Ces éléments sont essentiels dans le cadre de notre projet de recherche. Ce- pendant, il nous reste à explorer les travaux antérieurs destinés à l’analyse de performance d’applications et de systèmes flots de données. C’est ce que nous souhaitons faire dans cette dernière section.

Un premier travail par Canale et al. (2014) se base sur les réseaux de Pétri et les graphes de traces d’exécution. Une transformation de ces graphes en un système linéaire dirigé par les événements est proposée. En particulier, le problème de la configuration optimale de la taille des différents tampons d’un modèle flot de données est abordé. Les cas de décodeurs JPEG et MPEG HEVC sont utilisés afin de démontrer l’efficacité de leur approche.

Janneck et al. (2008) proposent un travail permettant d’évaluer les performances d’un modèle flot de données. Les auteurs se basent sur la collecte de traces de causalités, puis d’analyses a posteriori pour présenter des résultats à propos de la consommation des entrées, pour chaque élément de calcul du modèle, ou encore sa latence totale.

Brunet et al. (2012a) introduisent quant à eux, une technique d’optimisation de programmes flot de données basée sur l’analyse a posteriori de traces d’exécution. Les auteurs se concentrent principalement sur le domaine du traitement de signal, en appliquant leur méthode à des dé- codeurs MPEG-4 SP et AVC/H.264.

Hoffmann et al. (2018) ont présenté un travail concernant l’analyse en ligne du chemin critique dans des applications flot de données distribuées. L’outil développé donne des informations et des résumés en temps réel à propos de la performance d’une application.

propos de l’exécution par flot d’applications, pour ensuite analyser ainsi que visualiser les in- teractions entre les différents composants. Pour cela, les auteurs se basent sur un mécanisme de marquage des données, proche de techniques utilisées en médecine qui consistent à injec- ter certains composants radioactifs pour tracer des problèmes cardiovasculaires. Dans leur travail, un mécanisme d’étiquetage au niveau des instructions ISA est implémenté. Cela per- met de collecter des informations à propos du noyau du système d’exploitation, des couches logicielles intermédiaires ainsi que des applications, sans aucune modification du code source. Cependant, ils expliquent que deux limites principales apparaissent. Tout d’abord, le surcoût introduit par leur méthode est assez important. De plus, les vues proposées dans leur travail ne sont pas suffisantes, ni pleinement adaptées. En effet, en raison du très grand nombre d’in- formations collectées, elles ne parviennent pas à mettre suffisamment en avant les problèmes potentiels de performance ou les limitations.

Enfin, un dernier travail vise à améliorer l’analyse de traces d’applications flots de données (Osmari et al., 2014). Les auteurs expliquent que la majorité des outils d’analyse fournissent des résumés statistiques standards, présentant trop d’informations concernant l’exécution d’une application. Ils ajoutent que trop de détails ayant un lien très faible par rapport à l’application analysée sont donnés et que cela n’apporte pas d’information utile pour un uti- lisateur. Dans leur travail, ils proposent une instrumentation du code source pour collecter des données, mais aussi un ensemble de visualisations. Ces dernières ont pour but de souli- gner réellement les caractéristiques importantes d’une application flot de données. Au travers de leurs analyses, les auteurs regroupent les nœuds du graphe flot de données en différents modules. En termes de vues, on retrouve notamment un diagramme de Gantt montrant l’uti- lisation des différents fils d’exécution, présentant la durée de traitement de chaque module. Une visualisation du graphe flot de données avec la circulation des données est aussi dispo- nible. Par ailleurs, des diagrammes de dispersion sont proposés, et montrent l’évolution de la durée de traitement des différents modules ainsi que les délais liés à la communication au sein du graphe. Afin de montrer l’efficacité de leur travail, ils se basent sur HyperFlow, un système parallèle très léger ayant une approche flot de données. Ils démontrent que chacune des vues présentées est utile et permet effectivement de mettre en lumière un problème de performance.

Ces travaux sont très intéressants puisqu’ils soulignent le grand intérêt pour l’analyse de per- formance de modèles flot de données. Cependant, quelques manques apparaissent et laissent place à des améliorations et à d’autres projets de recherche. Beaucoup de travaux présentés se basent sur une analyse du modèle flot de données à un haut niveau d’abstraction, sans tenir compte des différentes bibliothèques logicielles intermédiaires, du système d’exploitation ou encore du matériel utilisé. Cela permet de détecter des problèmes de performance comme des

goulots d’étranglement ou de la congestion. Cependant, certains éléments manquent, comme l’assurance d’un taux utilisation élevé, voire optimal, du matériel disponible. Par ailleurs, lors de la détection d’un problème, les informations disponibles conservent un niveau d’abs- traction élevé et ne sont pas toujours suffisamment détaillées pour comprendre réellement l’origine du problème. Bien souvent, les analyses existantes se basent sur une durée d’exécu- tion trop longue d’un nœud du graphe pour détecter un problème au sein du modèle flot de donnée. Cependant, sans information bas niveau, proche des bibliothèques logicielles utilisées ou du système d’exploitation, il est difficile de solutionner le problème.

D’autres informations comme le suivi de la consommation mémoire, les transferts de données au niveau matériel ou encore les opérations d’entrée/sortie au niveau du système d’exploita- tion pourraient être utiles et permettraient d’améliorer l’analyse de performance du modèle flot de données. De plus, les travaux présentés se concentrent sur des cas d’applications uti- lisant seulement un processeur traditionnel. Au contraire, les modèles flots de données se destinent de plus en plus aux architectures hétérogènes combinant différents types d’unités physiques de calcul. Au cours de notre projet de recherche, nous viserons donc à apporter des solutions à ces limites.