Les projets génériques

Nous allons maintenant parler de deux projets : les Telescoping Language et le projet Amphion qui se placent dans des domaines d’application restreints mais quelconques.

1.3.2.1 Telescoping Languages

Les «Telescoping Languages»³⁸ [KBC⁺05] ont été développés pour engendrer des compilateurs haute performance pour des langages de programmation de domaines scienti-fiques. L’idée est de faire un traitement sur une librairie de composants d’un domaine cible (par exemple une boîte à outils MATLAB), pour produire un compilateur pour ce domaine qui comprend et optimise les briques de base du langage. Il construit une nouvelle librairie en décomposant et recomposant les procédures.

Un des objectifs du projet est d’engendrer du code C ou FORTRAN de haute per-formance. Pour cela, les composants ne doivent pas être traités comme des boîtes noires.

Un des points clés des optimisations réalisées (au niveau des procédures MATLAB ou de S

36http://instancestore.man.ac.uk/

37http://www.racer-systems.com/

38http://telescoping.cs.rice.edu/

(langage d’analyse statistique [BCW88])) est de gagner en précision sur les types réels et les tailles des variables.

Au sein de ce processus, l’outil Palomar joue un rôle particulier. Il prend en entrée un ensemble de procédures exprimées en langage de base qui définissent les primitives du langage du domaine et les composants de la boîte à outils. En sortie, Palomar va engendrer une librairie qui contient les primitives du domaine et des versions particulières des routines définies pour exploiter le contexte dans lequel elles vont être exécutées. La meilleure version du composant sera alors utilisée une fois le contexte connu.

Pour pouvoir optimiser le code, Palomar se base sur des annotations de l’utilisateur au niveau de la librairie. Ces annotations permettent de remplacer des séquences d’invocations de composants par des séquences plus efficaces. Ces annotations peuvent être vues comme définissant une algèbre de relations sur les composants, avec la complexité des services comme base pour les décisions d’optimisation. Les transformations de séquences se font à l’aide de règles qui sont soit engendrées par Palomar, soit fournies par le créateur de la librairie. Ces transformations peuvent être accompagnées de pré- et post-conditions.

Dans l’article [KBC⁺01], les auteurs présentent un exemple d’axiomes possibles ex-primés en langage Z³⁹. Ils donnent les exemples de l’associativité, de l’addition de matrices et de la distributivité de la multiplication de matrices par rapport à la multiplication matrice - vecteur.

⊢ ∀m1, m₂, m₃ : M atrix•

mmadd(m₁, mmadd(m₂, m₃)) =mmadd(mmadd(m₁, m₂), m₃) Cet axiome permet de changer l’ordre d’évaluation de l’opération.

⊢ ∀m1, m₂ : M atrix; v₁:V ector•

mvmul(mmmul(m₁, m₂), v₁) =mvmul(m₁, mvmul(m₂, v₁))

Cette opération permet de gagner en complexité quand elle est appliquée dans le « bon » sens.

Ces identités sont utilisées de deux façons :

– pour appliquer le meilleur composant dans un contexte donné ;

– pour remplacer des séquences identiques d’appels de fonctions par une autre fonc-tion qui réalise cette séquence de façon optimisée.

Les « Telescoping Languages » présentent une approche intéressante, mais plus dans une optique d’optimisation de code que dans celle de courtage. Le but est de transformer du code en vue de l’optimiser et non de comparer deux spécifications. Les règles qui permettent de transformer le code ne sont appliquées que dans le sens qui permet de réduire le coup d’exécution, donc uniquement des algorithmes moins coûteux sont engendrés.

De plus, seul un prototype très préliminaire du système de génération de compilateur Palomar a été réalisé. Ces travaux ne sont donc pas assez avancés pour pouvoir nous servir de base de travail.

1.3.2.2 Amphion

Ce projet [SWL⁺94] réalisé au sein de la NASA a pour objectif d’engendrer du code source à partir d’une spécification de haut niveau. Il est indépendant du domaine, mais, comme dans notre cas, s’applique à un domaine particulier. Amphion a été validé sur trois domaines de la NASA : la géométrie du système solaire, la mécanique des fluides et la navigation des navettes spatiales.

39http://vl.zuser.org/

La partie du projet qui nous intéresse plus particulièrement est le démonstrateur au-tomatique de théorème Snark. Celui-ci sert à prouver que la spécification est un théorème du domaine. Pour cela, il engendre des substitutions obtenues par unification et application d’équations. Snark⁴⁰utilise la réécriture et la règle de para-modulation [R69] pour raison-ner sur les égalités du domaine. L’utilisateur doit fournir un ordre strict sur les constantes et les fonctions du domaine. Cet ordre est utilisé pour contrôler la règle de para-modulation.

Il est très important et a une grande influence sur le temps d’obtention d’une preuve. Cela implique donc qu’un spécialiste de la réécriture construise cet ordre. Ceci est contraire à une de nos contraintes de travail (R2).

Snark prend en compte les types et les sous-types et permet de définir des théo-ries. Ces théories définissent du vocabulaire, des fonctions et des prédicats. Les symboles peuvent être déclarés comme commutatifs et/ou associatifs. Snark intègre un mécanisme de réécriture qui permet de traiter certaines égalités sous forme de règles de réécriture. Il pro-pose aussi une instruction « closure » qui permet d’obtenir plusieurs solutions pour un même problème. Il permet également de raisonner sur des égalités. Cependant, il peut boucler.

Voici deux exemples simples qui montrent pourquoi Snark n’était pas adapté à nos besoins.

(load "snark-system.lisp") (make-snark-system)

(initialize)

(use-resolution t)

(assert ’(= (* 1 ?x) ?x ) :name ’1-neutre) (assert ’(= (* (* ?x ?y) ?z) (* ?x (* ?y ?z)))

:name ’*-assoc) (prove

’(= (* (* ?x ?y) ?z) (* a b )) :answer ’(ans ?x ?y ?z))

; rechercher x, y et z tels que ((x*y)*z) = (a*b) (closure)

Snark répond : [...]

; All agendas are empty.

:AGENDA-EMPTY

Ce qui signifie qu’il ne peut pas faire la preuve.

Si nous ajoutons l’utilisation de la règle de para-modulation : (use-paramodulation)

Snark répond : [...]

(Row 15 false

(resolve 4 :code-for-=) Answer (ans 1 a b))

40http://www.ai.sri.com/snark/tutorial/tutorial.html

) [...]

:PROOF-FOUND

Ce qui signifie qu’il trouve bien la solution et qu’il serait donc nécessaire d’utiliser la règle de para-modulation.

Néanmoins, dans le même contexte mais avec une autre requête : (prove

’(= (* ?x (+ ?y 1)) (* a b) ) :answer ’(ans ?x ?y))

Snark va boucler et construire une suite infinie de 1*1*1*1*1*1*1*1*1*. . .

Ce projet est intéressant mais l’approche pose deux problèmes majeurs : l’importance de l’ordre qui nécessite un expert (ce qui viole le besoin R3) et le fait que Snark puisse boucler dans certains cas (ce qui viole le besoin R1). Nous aurions pu envisager de reprendre les sources de Snark pour les adapter à notre problème, mais la nécessité de l’ordre était une contrainte trop importante.