Python PyPy 1.3 et newthreading

Posté par (page perso) . Modéré par Xavier Teyssier.
Tags :
17
29
juin
2010
Python
PyPy 1.3 est sorti ce 26 juin. Pour mémoire, PyPy est une implémentation de Python, réalisée elle-même en Python.
Il y a deux grandes nouveautés pour cette version :
  • Une amélioration du compilateur JIT, beaucoup de bogues ont été corrigés et la vitesse d'exécution a été augmentée ;
  • Gestion des extensions écrites en C pour l'interpréteur CPython introduite en version alpha. Pour l'utiliser, il suffit d'activer ce support via import cpyext et de recompiler, PyPy n'étant pas binairement compatible avec CPython, avec pypy setup.py build.


Une autre actualité récente est la sortie de newthreading en tant que proof of concept. CPython utilise un verrou global (GIL) qui limite fortement l'utilisation de plusieurs thread avec Python à cause du partage de ressource. newthreading permet de contourner le GIL pour qu'un objet soit bloqué seulement quand une classe s'exécute à l'intérieur. De plus, les objets synchronisés sont accessibles par plusieurs thread séquentiellement.

Les auteurs se sont notamment inspirés du monde Java et espèrent permettre ainsi des restrictions moins fortes pour pouvoir se débarrasser du GIL.
  • # Petit précision

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

    le site du projet PyPy : http://pypy.org/

    L'implémentation de référence pour PyPy est Python 2.5. Je me demande quelle sera la charge de travail nécessaire quand ils tenteront de rejoindre la version courante de la série 3.X.
  • # Petite correction

    Posté par . Évalué à  4 .

    Les auteurs […] espère permettre ainsi des restrictions moins fortes pour pouvoir se débarrasser du GIL.

    Les auteurs ne semblent pas espérer suffisamment d’un point de vue grammatical…
    • [^] # Re: Petite correction

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

      Corrigé.
      • [^] # Re: Petite correction

        Posté par . Évalué à  2 .

        Il y en a d'autres :
        - par deux fois : « plusieurs thread » dont les multiples threads mériteraient un 's'.
        - « partage de ressource », il me semble qu'on parle plus souvent des ressources du système plutôt que d'une ressource indénombrable.
  • # Ca donne envie de faire...

    Posté par . Évalué à  2 .

    ok, désolé, je n'ai pas pu m'en empêcher...
    je sors ->[]
  • # Formulation

    Posté par . Évalué à  2 .

    newthreading permet de contourner le GIL pour qu'un objet soit bloqué seulement quand une classe s'exécute à l'intérieur.
    J'ai beau relire, ca fait pas sens.

    L'idée de newthreading, a ce que j'ai compris, c'est que chaque objet se voit pourvu d'un mutex, et que chaque appel d'une méthode de cet objet est préfixé par un lock() et postfixé par un unlock().

    L'histoire ne dis pas comment on s'en sort quand les attributs sont accédés directement par un code extérieur a la classe de l'objet.
    • [^] # Re: Formulation

      Posté par . Évalué à  3 .

      newthreading ne résoud absolument pas le problème du GIL, il ne fait que suggérer un "modèle de synchronisation" qui impliquerait une remise en cause brutale de la sémantique de Python, bref à peu près inapplicable.

      J'ai donné mon avis ici (en anglais) : http://mail.python.org/pipermail/python-ideas/2010-June/0075(...)
      En résumé, la seule façon de supprimer le GIL, c'est de le supprimer. Pas d'inventer des "modèles de synchronisation".

      Je suis étonné que tant de bruit soit fait autour de cette expérimentation, qui à mon avis est vouée à l'échec. Probablement un effet de l'hystérie due aux effets de mode autour du multicore & co.
      • [^] # Re: Formulation

        Posté par . Évalué à  2 .

        GIL est bien là pour quelque chose. Il faut garder une cohérence des données malgrès le multitâche. Donc le supprimer c'est pas si simple il faut trouver un moyen de garder une cohérence des données et ça ça s'appelle un modèle de synchronisation.

        Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

        • [^] # Re: Formulation

          Posté par . Évalué à  4 .

          GIL est bien là pour quelque chose. Il faut garder une cohérence des données malgrès le multitâche.

          Non, c'est beaucoup plus simple que ça : il faut empêcher l'interpréteur de crasher.
          La question, ce n'est pas les données utilisateur puisque Python propose déjà tout ce qu'il faut comme primitives de synchronisation (verrous, sémaphores, conditions, etc.). C'est comment faire pour que le coeur de l'interpréteur soit thread-safe, tout en enlevant le GIL, et sans tuer les performances mono-thread.

Suivre le flux des commentaires

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