1. #1
    Membre éclairé

    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    septembre 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2007
    Messages : 200
    Points : 714
    Points
    714

    Par défaut Compilateur ou interpréteur ?

    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

  2. #2
    Membre à l'essai
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2013
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Service public

    Informations forums :
    Inscription : août 2013
    Messages : 10
    Points : 13
    Points
    13

    Par défaut Compilateur ou interpréteur

    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, ...).

  3. #3
    Inactif
    Inscrit en
    août 2013
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : août 2013
    Messages : 27
    Points : 52
    Points
    52

    Par défaut

    Citation Envoyé par Christophe Genolini Voir le message
    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.

  4. #4
    Membre à l'essai
    Homme Profil pro
    IE collecte et analyse de données
    Inscrit en
    septembre 2013
    Messages
    6
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : IE collecte et analyse de données

    Informations forums :
    Inscription : septembre 2013
    Messages : 6
    Points : 14
    Points
    14

    Par défaut

    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

  5. #5
    Membre éclairé

    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    septembre 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2007
    Messages : 200
    Points : 714
    Points
    714

    Par défaut

    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.

  6. #6
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 380
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 380
    Points : 12 679
    Points
    12 679

    Par défaut

    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..
    Ne dites pas : "chercher la petite bête" mais plutôt "effectuer un travail d'entomologiste."
    Pour corriger des bugs c'est pareil

  7. #7
    Membre éclairé

    Homme Profil pro
    Enseignant Chercheur
    Inscrit en
    septembre 2007
    Messages
    200
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Enseignant Chercheur
    Secteur : Santé

    Informations forums :
    Inscription : septembre 2007
    Messages : 200
    Points : 714
    Points
    714

    Par défaut

    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...

Discussions similaires

  1. TIPE : Réalisation d'un interpréteur/compilateur d'expressions arithmétiques
    Par Fractal LLG dans le forum Langages fonctionnels
    Réponses: 32
    Dernier message: 17/03/2008, 16h52
  2. compilateur, interpréteur, bytecode, MSIL et code natif
    Par cyrano_de_bergerac dans le forum C#
    Réponses: 11
    Dernier message: 29/10/2007, 16h43
  3. Réponses: 2
    Dernier message: 19/05/2007, 11h53
  4. Compilateur natif ??? Kesako ???
    Par Riko dans le forum Langages de programmation
    Réponses: 4
    Dernier message: 06/08/2002, 09h54
  5. Créer un interpréteur de langage inspiré du Basic
    Par Picasso dans le forum Général Algorithmique
    Réponses: 4
    Dernier message: 11/05/2002, 18h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo