Dans ce chapitre, nous revenons sur l’utilisation de la technique proposée, son utilité ainsi que ses performances. Nous abordons également quelques contributions additionnelles faites au cours de ce projet de recherche.
5.1 Cas d’utilisation
Dans l’article du chapitre 4, nous avons présenté cinq cas basés sur TensorFlow afin de démontrer l’efficacité de notre technique. Dans chacun d’entre eux, nous avons tracé et profilé une application afin de collecter des événements. Nous avons ensuite analysé les résultats et cherché les visualisations les plus adaptées afin de comprendre l’exécution de l’application et de mettre en avant d’éventuels problèmes de performance. Dans un second temps, nous nous sommes basés sur la documentation de TensorFlow ainsi que des articles de recherche afin de trouver des solutions aux éventuels problèmes de performance ou limitations. Après ce processus d’optimisation, nous avons tracé et profilé à nouveau l’application afin de vérifier les gains et de comprendre l’impact des modifications apportées. Avec ces cinq exemples, nous avons pu démontrer l’utilité des différentes informations que l’on a choisi de collecter, comme la durée des noyaux de calcul sur le processeur graphique, la durée et la taille des copies de mémoires entre les deux processeurs ou encore les traces du noyau Linux.
Finalement, au travers de ces exemples, nous avons principalement visé les utilisateurs de TensorFlow. Il s’agissait de l’objectif prioritaire pour la méthode proposée. Néanmoins, cer- taines de ces informations, comme l’ordonnancement des nœuds du graphe ou encore les traces du noyau du système d’exploitation, seraient également bénéfiques aux développeurs de TensorFlow. Au contraire d’un simple utilisateur, ils ont beaucoup plus de liberté et d’opportunités pour modifier le comportement interne de TensorFlow. Par conséquent, nous estimons que notre technique pourrait également être utile dans un contexte d’optimisation de la bibliothèque logicielle TensorFlow elle-même.
5.2 Utilisation
La technique proposée est liée à un environnement de traçage et de profilage très flexible et libre de sources. Nous avons vu que trois plateformes majeures étaient disponibles afin d’utili- ser TensorFlow, et que le choix dépendait du type de processeur graphique utilisé. L’avantage de notre implémentation est sa compatibilité avec chacune d’entre elles. L’utilisation se fait
simplement à l’aide de scripts afin d’automatiser le processus d’analyse. Il reste néanmoins possible d’utiliser chaque composant de l’analyse de manière individuelle, ce qui pourrait être utile pour d’éventuels cas spéciaux.
5.3 Performance
La performance de la technique proposée a été évoquée dans la section 4.6 de l’article. Nous avons notamment démontré que le surcoût introduit restait raisonnable dans les différents cas d’utilisation. Ce dernier dépend de la plateforme, de la technique utilisée pour profiler le processeur graphique ainsi que de l’application. Nous avons pu noter qu’une application exigeante en termes de calcul proposera un surcoût plus faible. Cela s’explique par le fait que pendant l’exécution, possiblement longue, des noyaux de calcul sur le processeur graphique, le profilage ou le traçage n’interviennent pas. Il est donc intéressant de comparer notre le surcoût en fonction de la plateforme utilisée et des informations collectées, mais uniquement pour une même application.
Nous pouvons remarquer que dans le pire cas, un surcoût de presque 50 % est introduit pour l’application auto-encodeur. Malgré tout, cela n’est pas problématique pour deux raisons principales. Tout d’abord, il s’agit d’un cas extrême, puisque nous avons décidé de collecter l’ensemble des informations disponibles, incluant les traces du noyau du système d’exploi- tation. De plus, la faible durée des applications analysées rend un surcoût de presque 50 % concevable. En effet, seules quelques secondes seraient ajoutées en comparaison d’une exé- cution normale de l’application. Par ailleurs, en imaginant un cas où l’on souhaite conserver un surcoût très faible, il est possible d’activer ou de désactiver précisément chaque point de trace. Ainsi, l’utilisateur pourrait limiter les informations collectées en fonction de ses besoins, afin de conserver un surcoût très faible.
5.4 Contributions additionnelles
Quelques contributions additionnelles ont pu être réalisées au cours de ce projet de recherche. Elles concernent principalement la plateforme ROCm proposée par AMD. Cette dernière comprend une bibliothèque nommée HIP pour programmer le processeur graphique. Notre implémentation est basée sur des mécanismes de profilage existants au sein de cette biblio- thèque. Cependant, quelques éléments marquant la fin de certaines fonctions de l’interface de programmation manquaient et causaient des problèmes significatifs lors de la phase d’analyse et de visualisation des résultats. Nous avons pu soumettre une correction à cela sur Github. Par ailleurs, avant d’utiliser LTTng, une grande partie du travail avait été implémentée à partir
de mécanismes de profilage proposés par AMD, comme leurs marqueurs (AMD markers) pour instrumenter le code source. La visualisation des résultats pouvait s’effectuer dans CodeXL mais restait fixe et n’offrait pas de possibilités d’adaptation. Par ailleurs, en s’appuyant sur l’environnement d’analyse d’AMD, il aurait été compliqué de proposer un support pour la plateforme CUDA. Nous avions alors développé un convertisseur permettant de générer des traces CTF à partir des celles au format ATP obtenues avec les outils d’AMD. Cela nous permettait d’analyser et de visualiser les résultats dans Trace Compass. L’étape additionnelle de conversion constituait néanmoins un inconvénient important, en raison de sa durée et son aspect inefficace. Finalement, l’implémentation proposée utilise une approche différente avec notamment LTTng, mais ce travail pourrait être réutilisé pour un projet différent.