Distribution de programmes Signal

Participants : Pascal Aubry, Loïc Besnard

La représentation interne d'un programme SIGNAL sous la forme d'un graphe hiérarchisé, conditionné par les horloges, est centrale pour un grand nombre d'outils : génération de code, optimisation, évaluation quantitative, implémentation parallèle, etc.

Les années précédentes, une méthodologie d'implémentation parallèle de programmes SIGNAL avait été dégagée. Cette année, nous avons concrétisé ces études en proposant une distribution fonctionnelle de programmes SIGNAL , basée essentiellement sur des critères qualitatifs [8,9]. La méthode employée utilise le formalisme des graphes flots de données synchonisés jusqu'à l'étape finale de la répartition et est ainsi totalement intégrée dans le compilateur. Elle s'appuie, classiquement, sur la possibilité offerte en SIGNAL V4 de définir des pragmas.

À l'aide de pragmas, l'utilisateur décrit directement au niveau du source l'architecture cible (nombre de processeurs, systèmes d'exploitation, types de communication...) et place les équations SIGNAL à l'aide d'un mécanisme d'étiquetage très souple. Le compilateur se charge alors de générer:

• pour chaque processeur, en C : un module body d'exécution d'un instant logique de l'application, un module io d'implémentation des entrées/sorties, un module comm implémentant les communications entre processeurs et un module main appelant les autres modules ;
• un script de lancement de l'application qui simplifie au maximum la simulation des applications ;
• un fichier de construction de l'application, rendant transparente la génération des exécutables ;
• des fichiers de trace pour chaque processeur qui permettent à l'utilisateur de vérifier s'il le souhaite les différentes opérations effectuées.

La distribution est décomposée en trois étapes :

• les directives de répartition sont analysées et chaque calcul est affecté à un processeur ;
• des noeuds de communication sont introduits, rendant disponibles les signaux partout où ils sont utilisés ;
• la partie ``contrôle'' est ensuite répartie, minimisant le nombre de communications nécessaires à l'aide d'une série d'optimisations tendant à réduire au maximum les hiérarchies d'horloges sur chaque processeur ;
• le compilateur génère enfin les différents modules pour chaque processeur cible. L'indépendance de la spécification vis-à-vis de l'architecture empêchant de prévoir a priori le meilleur séquencement statique, un séquencement dynamique est utilisé, minimisant les périodes d'attente de chaque processeur.

Dans la première version, les communications entre processeurs sont gérées par la ``Pom'' (Parallel Observable Machine) développée dans le projet Pampa.