IronPython : implémentation pour Mono/.NET

Posté par (page perso) . Modéré par Christophe Guilloux.
Tags :
0
4
août
2004
Python
IronPython est une implémentation libre (sous licence CPL v1.0) de Python pour la machine virtuelle de Mono/.NET (NdM : Common Language Runtime, ou CLR).

Plus rapide que la version officielle et moins gourmande en mémoire, elle permet de réaliser des exécutables et des dll's utilisables par les autres langages compilables pour CLR (type C#, VB, ...).

NdM : l'auteur de IronPython, Jim Hugunin, s'était déjà illustré en créant Jython (une implémentation de Python pour Java), et en participant activement aux développements de Numerical Python et d'AspectJ. Il a récemment rejoint l'équipe CLR de Microsoft, où il compte poursuivre son travail sur IronPython et promouvoir l'utilisation sur cette plate-forme des langages dynamiques en général. Cette implémentation met en avant :

La rapidité :
La version 0.6 est plus de 1.7 fois plus rapide que Python 2.3 (selon le benchmark PyStone)

La réutilisabilité :
Il est possible d'utiliser/dériver les bibliothèques disponibles pour CLR, y compris celles écrites dans d'autres langages que Python.

L'interprétation dynamique :
IronPython supporte l'interprétation du code et sa compilation (transparente) à la volée, tout comme Python lui-même.

La compilation statique :
Il supporte aussi la compilation statique, produisant des exécutables (.exe) ou de librairies (.dll) pouvant être utilisé par des langages supportant CLR comme C#, VB, ...

Il est toutefois important de noter que c'est une version 0.6 (alpha) à ne pas utiliser en production.
  • # comparaisons...

    Posté par . Évalué à 2.

    La version 0.6 est plus de 1.7 fois plus rapide que Python 2.3 (selon le benchmark PyStone)

    donc de 1 à plus de 10 fois moins rapide que Python+Psyco?
    (vu qu'un code Python important Psyco est en général 3 à 10 fois plus rapide qu'un code Python 'Nu')
    • [^] # Re: comparaisons...

      Posté par . Évalué à 3.

      Oui. Par contre Psyco est x86-only, et je ne crois pas qu'il y ait de portage ne serait-ce qu'entamé pour d'autres architectures. CLR au contraire est potentiellement multi-architecture (le portage PPC de Mono est bien avancé li me semble), et logiquement IronPython en profitera automatiquement.
      • [^] # Re: comparaisons...

        Posté par . Évalué à -1.

        A priori Psyco est aussi potentiellement multi-architecture ;-) -à part si il y a une subtilité dans son design qui ne peut etre porté sur d'autres archs...
        bon par contre ("Sorry, no other processor is supported yet."), ce n'est pas du tout avancé.

        mais cela ouvre une nouvelle question: quid des perfs IronPython+Psyco? :-)
        • [^] # Re: comparaisons...

          Posté par . Évalué à 4.

          tu n'as rien compris. Dans IronPython, c'est .Net/Mono qui fait le JIT par dessous. Donc Psyco+IronPython est un non-sens.
          • [^] # Re: comparaisons...

            Posté par . Évalué à -1.

            merci mais j'avais bien compris, c'est en effet un non-sens, mais cela m'interresserait de savoir si cela est possible, et quelles en serait les performances... juste pour la beauté/folie de la chose!
        • [^] # Re: comparaisons...

          Posté par . Évalué à 4.

          bon par contre ("Sorry, no other processor is supported yet."), ce n'est pas du tout avancé.

          Oui, c'est ce que je dis. Y'a rien d'entamé, ni de sérieusement prévu à ma connaissance. Évidemment que dans l'absolu on peut faire la même chose sur d'autres archis, mais ça n'est pas près d'arriver.

          Alors que pour CLR, c'est d'une part beaucoup plus intéressant de le faire (tu fais d'une pierre 36 coups, enfin autant qu'il y a de langages compilables en bytecode CLR), et d'autre part déjà largement entamé (je parlais de "bien entamé sur PPC", mais c'est en fait carrément bel et bien fait, et sur Sparc aussi).

          quid des perfs IronPython+Psyco? :-)

          Ouf, il y a un smiley.
    • [^] # Re: comparaisons...

      Posté par . Évalué à 10.

      je vais pas me répéter

      http://advogato.org/person/TazForEver/diary.html?start=7(...)

      en gros c'est inimaginablement lent, les types de bases du langage sont défaillants (mon benchmark échoue, {}.copy() n'est pas implémenté, etc, etc, très peu de fonctions intégrées sont implémentées (open/file sont absents/défaillants, etc ...)

      bref beaucoup de bruit pour rien, ça sert à rien de faire une annonce publique pour un projet qui balbutie. Ce n'est pas qu'IronPython ne soit pas stable et donc pas destiné à un environnement de production : c'est qu'il est creux, vide.
      • [^] # Re: comparaisons...

        Posté par . Évalué à 4.

        L'auteur précise bien sur son site qu'il est en pré-alpha.

        Y'a beaucoups de niouzes pour les pré alpha sur linuxfr 8-)
  • # Pas de bibliothèques

    Posté par (page perso) . Évalué à 0.

    Notons que IronPython est packagé sans les bibliothèques python. In fine, on ne peut donc pas espérer prendre un programme python qui tourne et le compiler dans IronPython.

    M'enfin ce n'est qu'une 0.6, ça devrait avancer plus vite maintenant que Jim Hugunin va bosser chez microsoft.
    • [^] # Re: Pas de bibliothèques

      Posté par . Évalué à 8.

      moi ce qui me gave, c'est que pygtk existait déjà comme wrapper à gtk. le gtk de IronPython est une api complètement différente. Bref je vois de moins en moins l'intérêt : on a nos cher langages non compilés avec des bindings GTK d'un certain age et qui ont fait leur preuve. Maintenant on nous explique que .Net, c'est formidable, tous est interopérable entre langage, sauf qu'il faut tout recoder en GTK# et ses différents bindings ... c'est naze et sans intérêt, faudrait il encore faire des interpréteurs performants, complets et testés de la valeur de python, perl et ruby. On a un bonne abstraction et portabilité avec les solutions existentes, dans l'histoire, c'est .Net qui est compatible avec rien.

      La conclusion constructive, c'est qu'il est temps de définir une API indépendante pour GTK (ou autre) pour python, perl, ruby, sinon ça ne sert strictement à rien. Ils faut que les développeurs se mettent d'accord.
      • [^] # Re: Pas de bibliothèques

        Posté par . Évalué à 2.

        C'est justement le principe de .NET / mono. Il n'existe plus qu'un seul binding (GTK#) que tu peux utiliser à partir de n'importe quel langage.
  • # Branlette, FUD, ...

    Posté par . Évalué à 7.

    « Plus rapide que la version officielle et moins gourmande en mémoire »

    on va faire au ressenti.
    lancer l'interpréteur python, taper 'dir()'

    faites le avec IronPython ou CPython, c'est quoi votre impression ?

    Perso, je vois PyStone, c'est bidon. Je m'en fiche bien que l'invocation de méthode soit plus rapide si le corps de ma méthode si simple soit il, s'exécute 10 plus lentement. Le benchmark que je donne est simplissime, IronPython prends une raclé. C'est simple au début je le tuais, voyant Pyso mettre 6s, au bout de 30s je croyais qu'IronPython avait planté ...
    • [^] # Re: Branlette, FUD, ...

      Posté par . Évalué à 1.

      Bon, je ne connais pas grand chose à Python si ce n'est que c'est un langage interprété, mais comment un simple dir peut-il prendre 6 secondes ?
      À moins que ce soit sur /var/log/ksymoops, je ne vois pas... ou que dir() ne fasse pas du tout ce qu'intuitivement je pense qu'il fait... ou encore que la machine de test soit un veau
      • [^] # Re: Branlette, FUD, ...

        Posté par . Évalué à 2.

        attends, je parle 2 choses.

        - du premier contact avec le shell interactif,dir() étant une fonction de base de python, un truc souvent utilisé. un truc aussi bateau que ls. imagine, on te dis 'oua ce shell est vachement rapide et bouffe moins de ram que bash', toi, pépère, tu le lances, tu tapes ls machinalement ...grrrrrrrrr (grattement disque) ... 1 bonne seconde plus tard, tu ton liste de fichiers

        - d'un benchmark (travail sur des chaines de caractères, jouons avec les séquence d'ADN). (je continue pas le parallèle là)

        Que ce soit au ressenti ou avec un benchmark, IronPython est affreusement long.
      • [^] # Re: Branlette, FUD, ...

        Posté par . Évalué à 2.

        Effectivement, c'est totalement différent.

        En python, dir() te permet d'afficher une liste de toutes les méthodes et arguments de l'objet* sur lequel tu l'appelles

        * : qui peut être un type, une variable, une classe, une instance, un module...

        c'est super pratique en mode interactif si tu ne sais plus comment s'appelle telle méthode, ou quelles sont les possibilités de tel autre type que te retourne une fonction, mais ca sert pas à grand chose dans un script, je pense...

        et je vois surtout pas sur quoi tu peux bien faire un dir() pour qu'il mette 6 secondes à t'afficher la liste...
  • # Peut-être aurait-il été utile de préciser que...

    Posté par (page perso) . Évalué à 1.

    IronPython est une implentation du langage Python, et non de l'ensemble des packages Python, il ne faut pas s'attendre à utiliser les même bibliothèques, mais l'ensemble des bibliothèques .NET.
    Le but n'est donc pas de concurrencer Python lui-même, le but est d'offrir une syntaxe supplémentaire et une possibilité d'interprétation dynamique au dessus de Mono/.NET.

    Pour ce qui est de la rapidité, il faut relativiser : certaines fonctions vont tourner 10 fois plus rapidement (ceux qui sont fan de IronPython les utiliseront dans leurs tests) d'autres c'est l'inverse (et évidemment les détracteur s'empresseront de les montrer comme exemple). Ensuite sous Linux ce n'est utilisable que sous Mono, et de l'aveu même du concepteur c'est nettement plus lent que sur la machine .NET de Microsoft.

    En tout cas ce projet a atteint son but : montrer qu'il était possible d'utiliser un langage dynamique sous .NET malgrès ce que de petits malin ont affirmé en faisant une implentation bidon de Python. Le fait que son auteur soit embauché dans l'équipe du CLR de Microsoft peut laisser présager des modifications dans le code intermédiaire IL de la VM .NET pour faciliter l'intégration de ces langages.
    • [^] # Re: Peut-être aurait-il été utile de préciser que...

      Posté par (page perso) . Évalué à 4.

      > ce que de petits malin ont affirmé en faisant une implentation bidon de Python

      Tu parles peut-etre de l'implementation realisee par Mark Hammond un des gourou de la communaute python, implementation financee par Microsoft ?

      Dans ce cas, je remballerai l'experssion "petits malins". Mark Hammond est extremement respecte dans la communaute python et il y a des raisons pour lesquelles son implementaiton n 'etait pas optimale, que Guido van Rossum detaille dans mon interview (http://www.freehackers.org/fosdem2002/guido.html(...)):

      <<
      Anyway, they did a Python port to .NET very early on, with some funding from Microsoft. I think the issue was mostly for Microsoft to show that Common Language Runtime really was a suitable target for multiple languages because they did the same thing with lot of language groups. [...] It's true that the Python .NET interpreter is very slow. I think part of that is just that they didn't have enough time to make it faster, there is always optimisations. The other thing was beacuase they did it so early on that they had to sign very strict Non Disclosure Agreements and Mark Hammond couldn't ask anyone for help because he was on NDA. He couldn't tell anybody even that he was working on this project until it was finished. So if he didn't know the compiler techniques, he was basically on his own. And there was also not much documentation about .NET available at that point, because .NET was basically still a Microsoft internal project. So I think now, this is based on a few things that Miguel told me actually. There are number of approaches to make it much faster.
      >>
      • [^] # Re: Peut-être aurait-il été utile de préciser que...

        Posté par (page perso) . Évalué à 2.

        u parles peut-etre de l'implementation realisee par Mark Hammond un des gourou de la communaute python, implementation financee par Microsoft ?
        Euh, je parlais de l'implentation de ActiveState, peut-être est-ce la même ? En tout leur conclusion montrait que .NET n'était pas fait pour un langage dynamique.
        Ton interview tend effectivement à montrer les véritables causes de cette leuteur dans certains prototypes.

        Sinon j'ai trouvé un point positif dans IronPython, qui n'a pas grand chose à voir avec le langage en soit : son créateur n'a pas testé son interpréteur sous Linux, et pour avoir essayé celà marche très bien, sans rien recompiler, sans rien installer (à part Mono bien sûr) : un bon exemple d'interopérabilité et d'abstraction de l'OS/distri, un peu comme en Java.
        • [^] # Re: Peut-être aurait-il été utile de préciser que...

          Posté par (page perso) . Évalué à 2.

          > un bon exemple d'interopérabilité et d'abstraction de l'OS/distri, un peu comme
          > en Java.

          trop cool !!

          moi qui me faisait chier à écrire deux versions de mes prog Python, une pour *nix et une pour *indows !

          Putain, faut arrêter de fumer la moquette, java ou machin# ne révolutionnent rien
          • [^] # Re: Peut-être aurait-il été utile de préciser que...

            Posté par (page perso) . Évalué à 2.

            arrête de prendre des rails de coke, j'ai jamais dis que c'était une révolution, j'ai juste constater que c'était cool que certains programmeurs faisait en sorte que leur prog tournent sur plusieurs plateformes, et surtout sans soucis à l'installation dues au différentes version de distri Linux.
            Et puis la portabilité de Python est quand même en grosse partie due au fait que tu te balade avec les sources, pas avec un code machine ;)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.