6.2.3 Développement des applications
Les bénéfices en termes de complexité et de temps de développement à utiliser le compila-teur sont décrits dans la Table 6.2. Ces résultats sont basés sur l’expérience des développeurs Magali. Le temps nécessaire pour écrire une application est une métrique subjective, car il
6.3. Évaluation des performances
inclut le temps de réflexion, difficile à juger, et qu’il est très dépendant du développeur. Cepen-dant, lorsque les applications sont écrites par des personnes ayant les mêmes compétences techniques et avec les mêmes connaissances de la plateforme matérielle et des protocoles radio, il donne une estimation pertinente des bénéfices à utiliser l’outil fourni. La taille du code pour la plateforme Magali est séparée entre le code C pour le contrôleur central ARM et le code assembleur pour le contrôle distribué. Le nombre de lignes relativement faible par rapport au temps de développement dans l’approche native est dû à la complexité inhérente à la programmation de la plateforme : le contrôle distribué requiert la configuration de différents blocs matériels indépendants avec des valeurs globalement cohérentes qui représentent dans leur ensemble l’application. Sans un outil dédié, assurer — et déboguer — cette cohérence globale est source d’erreurs pour le programmeur.
PaDaF Natif
Applications C++ (#lignes) (heures) C / ASM (#lignes) (semaines)
OFDM 60 1 150 / 200 1
Démodulation 160 4 300 / 600 4
Démod. paramétrique 260 8 500 / 800 12
TABLE6.2 – Comparaison du développement au format PaDaF et natif sur Magali. En conséquence, alors que la taille du code généré par le compilateur est globalement équivalente à celle du code natif, la taille initiale du code PaDaF est divisée par 5 et le temps de développement par environ 40. Un autre avantage est que le code PaDaF est indépendant de la plateforme, et peut être compilé vers d’autres plateformes. Le développement récent d’une évolution de Magali pour l’intégration 3D [Dutoit 13] constitue une bonne illustration. Du point de vue programmation, cette évolution est principalement architecturale, avec le déplacement d’unités de calcul sur le réseau. Cette modification a toutefois rendu les applications développées nativement obsolètes. Le modèle de la plateforme Magali 3D est utilisé pour ces expérimentations de manière transparente pour le compilateur, et souligne l’intérêt de s’abstraire de la plateforme.
6.3 Évaluation des performances
Nous avons vu dans la section précédente le protocole LTE qui sert de référence pour l’évaluation du compilateur. À partir de ce protocole, j’ai défini plusieurs applications pour évaluer l’effet de différentes caractéristiques du protocole sur la compilation et l’exécution. Je présente dans cette section l’évaluation proprement dite. Cette évaluation se fera en deux temps, avec d’une part la compilation des applications et d’autre part l’exécution de celles-ci. Pour évaluer le compilateur, j’ai compilé les applications de test présentées dans la section précédente. Cette évaluation concerne l’ensemble du compilateur, tel que présenté dans les Chapitres 4 et 5. Le temps de compilation pour ces applications est négligeable (moins de 1 s). Le temps de vérification des tailles mémoires est cependant plus important. Je reviendrai sur ce temps de vérification dans la Section 6.3.1.
Une fois l’application compilée, la deuxième évaluation concerne l’exécution sur la ma-chine cible. La plateforme Magali utilise des mécanismes d’accélération matérielle pour le calcul et les communications. Le back end du compilateur spécialise les applications de test
pour tirer parti de ces mécanismes. Le contrôle sur la plateforme Magali est réparti entre le contrôleur centralisé et les contrôleurs distribués. Le choix de cette répartition est laissé au développeur, ce qui rend possible différentes stratégies et influence le niveau de perfor-mances des applications. J’analyserai différents modèles de contrôle utilisés sur Magali dans la Section 6.3.2, et leurs performances temporelles dans la Section 6.3.3.
6.3.1 Évaluation du contrôle des tailles mémoires
La vérification des tailles mémoires s’appuie sur un ensemble de techniques présentées tout au long de cette thèse. J’ai introduit dans la Section 3.4 du Chapitre 3 le formalisme micro-ordonnancement. Ce formalisme vise à représenter les communications entre acteurs dans un graphe flot de données, et à les ordonner. J’ai ensuite appliqué ce formalisme à la vérification des tailles mémoires sur les graphes flot de données paramétriques. Chacune des applications de test a été placée et optimisée pour la plateforme Magali, puis modélisée avec le langage PROMELA selon les contraintes présentées dans la Section 5.4.1. Le model checker SPIN parcourt ce modèle pour assurer l’absence d’interblocage dû aux communications.
Les techniques de model checking peuvent être limitées par des problèmes de complexité lors de l’exploration de larges espaces d’états. Pour évaluer cette complexité, les résultats de simulation utilisant le model checker SPIN sont présentés dans la Table 6.3. Ces simulations ont été exécutées sur la machine hôte avec un processeur Intel Core i5 à 2.4 GHz avec 8 Go de RAM et le système d’exploitation OS X 10.9.2. Les bouclesfordans le code PROMELA sont déroulées pour réduire le nombre d’états d’un facteur 10. Comme attendu, la complexité augmente avec la taille du graphe flot de données ainsi que la présence de paramètres. Toutes les applications sont toutefois explorées dans un temps raisonnable.
Application États Transitions Temps d’exécution (s)
OFDM 1.28 × 104 2.56 × 104 0.1
Démodulation 2.12 × 106 1.07 × 107 9
Démod. paramétrique 6.07 × 107 2.22 × 108 199 TABLE6.3 – Temps d’exécution du contrôle des tailles mémoires.
Sans cette méthode, la programmation sur la plateforme Magali se fait par tests successifs pour résoudre les interblocages. Ce procédé complexe est coûteux en temps, et de plus ne permet pas de trouver tous les interblocages. Cette méthode apporte donc une analyse des tailles mémoires formelle absente du développement sur la plateforme Magali. Elle est cependant limitée, la complexité augmentant de manière exponentielle avec la taille de l’application. En prolongement de ce travail, il serait intéressant d’expérimenter d’autres modélisations pour réduire cette complexité. La programmation linéaire, utilisée par Bodin
et al. [Bodin 14] pour minimiser la taille des mémoires dans un graphe flot de données, serait
une solution à évaluer dans le futur.
6.3.2 Analyse des modèles de contrôle
Le contrôle des applications sur Magali est partagé entre le contrôleur central et les contrô-leurs distribués. Le contrôleur central est nécessaire pour la synchronisation de plusieurs unités de calcul et le démarrage de ces unités. Au delà de cette contrainte, le contrôle est librement réparti par le programmeur.
6.3. Évaluation des performances
Nous avons vu dans la Section 5.2.2 que la programmation native utilise le modèle de contrôle par phase. Dans ce modèle de contrôle, l’application est découpée en plusieurs graphes, chaque graphe étant une phase. Le contrôleur central se charge du démarrage de chaque phase et de la synchronisation entre ces phases. Le code généré par le compilateur utilise quant à lui un modèle de contrôle où chaque unité de calcul est associée à un fil d’exécution sur le contrôleur centralisé. Le contrôleur centralisé se charge de démarrer chaque unité de calcul et de la synchronisation entre ces unités. Chaque modèle de contrôle possède une granularité différente, qui a ses avantages et ses limitations. Je propose de les analyser pour mieux les comprendre et savoir interpréter les résultats de performances temporelles dans la section suivante.
Le chronogramme de la Figure 6.7 illustre le fonctionnement d’une application par phases. Pour chaque unité de calcul, le chronogramme représente les périodes pendant lesquelles une unité est activée, c’est à dire depuis le démarrage de l’unité par le contrôleur central jusqu’à son arrêt. Les temps tsiet teisont respectivement le temps de démarrage et d’arrêt de l’unité i . Pour le contrôleur central (CPU), le chronogramme représente le tempsδside reconfiguration d’une unité de calcul i .
Time unit 0 (src) unit 1 (ofdm) unit 2 (sink) cpu δs0 δs1 δs2 te1 te0 te2 ts0 ts1 ts2 synchronization