Discussion :

[Christophe Genolini]

Bonjour

Un compilateur permet de produire des codes efficaces et rapides. Un interpréteur est plus simple d'utilisation (n'oubliez pas que R++ est a destination de médecin, de psychologues habitués à du press bouton).

Question : partir du moment ou l'on a définit un langage et une grammaire, est-il couteux de faire les deux ?

Christophe

[haddad_malek]

Un langage de type java-like serait une bonne chose, mais peut-être compliqué à élaborer : machine virtuelle, run-time ...
Python (ou perl) nécessitent "seulement" un interpréteur (exécution si pas d'erreurs). Autre avantage de ces 2 langages : leurs aspects objets plus souples
que java.
Quelques points qui me semblent importants dès maintenant : l'import et l'export de bibliothèques (packages), l'intégration avec le système d'exploitation, l'interfaçage (autre langage, sgbd, ...).

[Caramorgar]

Question : partir du moment ou l'on a définit un langage et une grammaire, est-il couteux de faire les deux ?

Même s'il y a une base commune (si c'est conçu dès le départ correctement), il faudra plus de boulot (forcement) pour créer les 2 qu'un seul.
Mais c'est possible. Voir par exemple en C++ l'interpréteur Cling basé sur le compilateur Clang

Pour les stats, il y a quand même une phase importante (après la création du code) de tests pour choisir les paramètres optimaux. Cela nécessite de relancer souvent les scipts en modifiant quelques valeurs. Ou relancer qu'une partie des scripts.
Avec un compilateur, cette phase est plus lourde. Donc à mon sens : en premier l'interpréteur. Puis un compilateur (ou un JIT) pour les performances.

[spalovac-mrtvol]

My two bucks.

Tout d'abord, Perl et Python sont des langages compilés en bytecode exécuté par une VM. La v6 de Perl a même conduit à la création d'un projet de création de VM pour langage dynamiques appelée Parrot.

La réalisation d'une VM semble effectivement une tâche complexe, surtout dans une perspective de parallélisation de l’exécution. Mais, comme cela a été noté, il existe déjà de différentes machines open sources qui pourraient soit servir de cible au code compilé ou, pour le moins, servir d'inspiration.
Par exemple, Clojure est une version de LISP pensé pour être exécuté par une JVM.

De plus, la parallélisation compliquera la solution adoptée quelle qu'elle soit (interpréteur ou compilateur). Ce qui, à mon avis, rend la solution de l’interpréteur tout de suite moins intéressante. La conception et l’implémentation d'un interpréteur parallèle retardera d'autant la mise en place d'une VM parallèle (car je ne suis pas sûr que le code puisse être directement recyclable de l'un à l'autre). J'ai un peu l'impression que ça reviendrait à doubler le travail pour obtenir un résultat dont on sait qu'il sera moins performant pour un gain de simplicité assez limité.

Ce qui fait écho à mon message de ce matin. La question est de savoir si les efforts doivent plutôt se concentrer sur le langage ou son environnement d'exécution. Or, la présentation du projet insiste beaucoup sur les performances de R comme motivation du projet. Dans ce cas de figure, j'irai dans le sens de Jérôme Collet dans son post sur le package compiler en privilégiant l'option VM ab initio.
D'un autre côté, un interpréteur minimal serait sans doute nécessaire pour tester les modifications apportées au langage. La question est donc de savoir dans quelle mesure les développements réalisés pour l'interpréteur peuvent être recyclés pour la VM.

Bonne soirée,

Thomas

[Christophe Genolini]

Après de nombreuses discussions, ici, par téléphone et sur la liste de diffusion, il semblerait que nous convergions lentement :

1. Il semble difficile de mener les deux de front.
2. R est déjà un interpréteur.
3. L'interpréteur est un outil indispensable mais surtout pour faire du "quick and durty". Pour les projets plus lourds, lorsque les performances sont vraiment décisives, alors on peut prendre le temps d'aller vers du compilé.

Donc, tous ces éléments me font pencher vers le compilateur.

[Mat.M]

bonjour je n'arrive pas trop bien à comprendre ce que fait l'outil en interne : est-ce qu'il produit des pseudo-instructions avec un "pseudo assembleur" ou bien des pseudos-codes ?
Est-ce qu'il est interprété avec une espèce de Virtual Machine comme avec .NET ou Java ?
Ensuite pour paralléliser le code produit ça risque d'être ardu parce qu'évidemment il faut que le temps de traitement de chaque instruction soit le même par tout
Je suis en train de développer un interpréteur BASIC ( avec Visual C++) et j'ai réfléchi un peu au problème du parallèlisme et c'est pas évident à réaliser..

[Christophe Genolini]

Bonsoir,

Nous allons faire un compilateur qui transformera du R++ vers du C++ optimisé pour tirer parti du parallélisme.

Quant à la question du "temps de code qui doit être le même partout", non, ca n'est pas le cas. Il y a de nombreuses autres manières de synchroniser les processeurs...