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.
Aller plus loin
- PyPy 1.3 (6 clics)
- L'annonce de newthreading (5 clics)
- newthreading (4 clics)
- La documentation de newthreading (1 clic)
# Petit précision
Posté par Carl Chenet (site web personnel) . Évalué à 3.
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 Sylvain Sauvage . Évalué à 4.
Les auteurs ne semblent pas espérer suffisamment d’un point de vue grammatical…
[^] # Re: Petite correction
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Petite correction
Posté par Davy Defaud . Évalué à 2.
- 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 macgyvre . Évalué à 2.
je sors ->[]
# Formulation
Posté par Pierre . Évalué à 2.
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 Antoine . Évalué à 3.
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 barmic . Évalué à 2.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Formulation
Posté par Antoine . Évalué à 4.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.