Dropbox lance PySton, une nouvelle implémentation de Python, basée sur LLVM, avec comme objectif de tirer partie des capacités JIT (Just-In-Time compiling, compilation à la volée) de l'architecture LLVM. Le but étant à terme d'utiliser Python là où du C++ était encore utilisé pour ses performances.
La suite de la dépêche fait un état des lieux des différentes VM Python et des projets d'améliorations de leur performances.
Sommaire
- CPython
- IronPython
- Jython
- PyPy
- Numba
- Unladen Swallow
- Le dernier né : Pyston
- Commentaire de l'auteur
- Post-scriptum
Avant de vous parler du projet initié par Dropbox, faisons un petit tour des VM disponibles pour Python.
CPython
L'implémentation de référence du langage Python, en C. La syntaxe Python est convertie dans un bytecode Python, qui est exécuté par la VM CPython. On critique régulièrement cette VM, à tort. Elle fonctionne très bien, elle est très portable et a subi de nombreuses optimisations au fil du temps qui en font une VM robuste, rapide et fiable.
On lui reproche régulièrement son GIL, le Global Interpreter Lock, ce gros verrou global qui protège les accès multi-threads. Dans les faits, le problème du GIL ne se pose que pour les programme multi-threads, CPU-bound, exécutés sur des multi-coeurs, qui se prêtent mal à d'autres techniques de parallélisme (tel que les services offerts par le module multiprocessing). Autant dire qu'on est dans des développements très spécifiques qui n'affectent pas la majorité des programmes écrits en Python.
Le GIL introduit par ailleurs des simplifications de code massives qui expliquent sa présence et sa longévité.
IronPython
IronPython une implémentation du langage Python, basée sur le CLR du framework .NET de Microsoft. Elle profite de tout l'écosystème autour de .NET et notamment des capacités JIT du CLR. Sur les derniers benchmarks dont je me rappelle, IronPython était soit au niveau de CPython, soit plus rapide (sans pour autant exploser les compteurs, on était dans le 1.5x ou 3x sur des benchmarks très ciblés). Si le langage est bien supporté, on peut regarder au delà de la communauté Python et se mettre à rêver grâce à IronPython de convertir des programmeurs Visual Basic. Ça, c'est pour la pub.
Quand on regarde de près, on découvre qu'en fait, pour les langages dynamiques comme Python, Ruby et Javascript que Microsoft prend en charge, le CLR brut est mal adapté. Microsoft a donc créé un DLR, un Dynamic Langage Runtime, qui s'interface au dessus du CLR et fournit des services particuliers pour gérer le dynamisme des langages précités. Jusque là, très bien…
Pour faire fonctionner un programme IronPython, il faut donc en plus des dernières versions de .NET installer le DLR dernière version. Moyennant tout ça, un programme Python pourra utiliser facilement n'importe quel composant .NET (écrit en C#, J#, Visual Basic…) mais l'inverse n'est pas vrai : un programme Python ne peut pas produire simplement des objets compatibles CLR et reste cantonné au monde du DLR. Pour accéder à ces objets/bibliothèques depuis un programme CLR, il faut passer par une gymnastique un peu complexe. Du coup, les langages DLR ne sont pas du tout au même niveau que les langages CLR et il y a peu de chance de voir Python remplacer un jour le Visual Basic.
Récemment, Microsoft a décidé de se débarrasser de ce truc donné IronPython à la communauté. Le développeur principal du projet chez Microsoft, après avoir vu son équipe se réduire au fil des mois, est finalement parti chez Google. Cf cet article de ZDNET qui résume bien ce qui se passe.
Autant dire que IronPython n'apportera pas la révolution que certains attendaient. Ca reste un projet très respectable, avec des versions compatibles 2.7 complètement fonctionnelles et une intégration dans Visual Studio.
Jython
Jython est une implémentation de Python pour la JVM de Java, qui permet d'écrire du code Java en Python et d'utiliser tous les bibliothèques Java en Python. Il supporte Python 2.5 et 2.7 .
On en entend peu parler dans le monde de l'Open Source mais le projet continue son bonhomme de chemin depuis plus de 10 ans maintenant (la première version est sortie autour des années 2000). Cette longévité est un signe que le projet est utilisé, très probablement dans le milieu de l'industrie.
Les performances sont à peu près au niveau de CPython (dixit la FAQ), le temps de démarrage d'une appli est assez long (à cause de la JVM, c'est donc peu pratique pour des scripts) ; sur des programmes qui s'exécutent longtemps (comme c'est souvent le cas pour des applis java côté serveur), le compilateur JIT JVM se met en route et fournit des gains intéressants.
À noter l'addition récente du module JyNI qui permet d'utiliser les modules d'extension Python de façon transparente en Java.
L'intérêt principal de ce projet, ce ne sont pas les performances mais l'intégration transparente dans l'écosystème Java. Si la JVM gagne encore en performance, le projet en bénéficiera, mais cela fait longtemps qu'on n'entend plus de nouvelles révolutionnaires sur le sujet…
PyPy
On ne présente plus PyPy, l'interpréteur JIT Python qui déménage. Après plus de 12 années et 5 réécritures, le projet envoie du bois : ça exécute du Python plus vite que CPython et pas qu'un peu si on en croit les benchmarks. Note de l'auteur: sur un programme ordinaire, tout le monde ne voit pas de tels gains, voire voient des dégradations catastrophiques donc à prendre avec du recul.
Le projet génère du code x86, x86-64 et récemment Arm (suite à un effort du projet Rapsberry Pi). Il est compatible Python 2.7, avec un effort en cours pour avoir la compatibilité Python 3. Le projet a maintenant atteint un bon niveau de stabilité et de performance, suffisant pour l'utiliser en production. Il est utilisable notamment avec Django, SQLAlchemy ou Twisted.
Maintenant que les gains sont là, les efforts portent sur l'écosystème ou sur d'autres innovations.
Côté écosystème, le gros problème de PyPy est que tous les modules d'extensions compilés pour CPython ne fonctionnent pas sous PyPy. Et il y en a beaucoup : des GUI (PyQt, PyGtk…), des bibliothèques de jeu (PyGame), etc.
PyPy travaille sur le sujet mais sans espoir pour l'instant de résoudre complètement le problème :
- dans certains cas, une recompilation dudit module pour PyPy avec cpyext permettra de le faire fonctionner.
- sinon, il faut envisager des méthodes alternatives pour faire le lien C/C++ et PyPy. Il y a des projets vraiment sympa comme Reflex, cffi et autres (cf Writing extensions modules for PyPY) mais au final, on est dans une approche qui demande une réécriture partielle dudit module.
Un certain nombre de projets sont compatibles PyPy . En plus de ceux que j'ai cité, on peut consulter la liste sur la page de compatibilité PyPy.
Dans le cas particulier de NumPy, compte-tenu de son importance pour la communauté PyPy (ou en tout cas d'un de ses auteurs qui travaille dans la recherche scientifique), une réécriture spécifique pour PyPy a été démarrée sous le nom de NumPyPy. Celle-ci ne fait pas l'unanimité, les développeurs autour de NumPy arguant d'une part qu'un clone est moins pratique que l'original, d'autre part qu'il y a d'autres modules d'extensions indispensables pour fonctionner dans l'écosystème (matplotlib, SciPy…).
Côté innovations, PyPy expérimente maintenant les Software Transactional Memory, c'est-à-dire gérer les accès mémoire d'un programme multi-threadé avec des transactions, comme dans une base de données. Une transaction pourrait être commencée, mise en œuvre ou annulée.
L'approche est originale, et a pour but de se débarrasser du GIL. Pour l'instant, c'est très lent, il est prévu un ralentissement de 2 à 5 par rapport à du CPython de base, mais cela offre en théorie la possibilité de tenir une forte montée en charge. Pour l'instant, on est vraiment sur un sujet de recherche donc à voir d'ici quelques années.
Il y a aussi un projet PyPy Sandbox qui permet d'isoler proprement un programme Python de son environnement. Les autres projets de ce type ont toujours échoué, Python offrant de multiples mécanismes de contournement de Sandbox. La force de PyPy est de pouvoir faire la Sandbox à un niveau très bas donc ça peut marcher. Pour l'instant, il y a peu de retour sur ce projet.
PyPy est un beau projet, il a su tenir son cap à travers les années - faisait fi des sceptiques - et nous délivrer ses promesses. Aujourd'hui, c'est à la fois une implémentation de Python rapide et un framework de génération d'interpréteurs Python. Il a même été utilisé très sporadiquement pour d'autres langages. Il a plus été pensé pour un usage scientifique au départ (biais de son auteur) mais les modules qui fonctionnent officiellement bien en PyPy (django, SQLAlchemy, Twisted) font penser que c'est sur les serveurs d'application qu'il va finalement faire une différence…
Le problème des modules d'extension est malheureusement rédhibitoire dans beaucoup de situations. Il est rare qu'un programme Python n'aie aucune dépendance vers une bibliothèque compilée et l'approche qui consiste à réécrire ledit module spécifiquement pour PyPy n'est pas toujours possible.
Numba
Numba est un compilateur JIT/LLVM pour Python, qui transforme des morceaux de Python annotés vers la chaîne de compilation LLVM.
Le code doit être annoté explicitement avec des marqueurs du type @jit pour demander une compilation générale vers LLVM, soit en laissant LLVM générer le code à la volée en fonction des types passés à la fonction, soit en spécifiant dans les annotations les types à utiliser.
Le site ne fournit pas de benchmarks explicites mais explique que les performances sont au niveau du C, le code Python étant effectivement traduit en assembleur. L'approche permet par exemple d'appliquer facilement des calculs sur des tableaux NumPy.
C'est un projet spécialisé dans le calcul hautes performances. On ne parle pas ici d'optimisation générale d'un programme en Python, mais d'optimisation explicite d'une ou plusieurs fonctions avec compilation au démarrage du programme (et non à la volée).
Unladen Swallow
Ce projet lancé en 2009 par trois ingénieurs de Google avait l'ambition d'accélérer la VM Python par un facteur 5, en s'appuyant sur l'architecture de compilation JIT du projet LLVM. Une des contraintes était de garder une compatibilité totale avec CPython et notamment avec les modules d'extension Python écrit en C.
Unladen Swallow est parti de la VM de CPython et a modifié la boucle d'exécution principale pour émettre du bytecode LLVM. Un programme Python était d'abord traduit en bytecode Python classique, puis transformé à la volée et selon les besoins dans la chaîne LLVM pour aboutir à du code assembleur.
On avait donc à toutes les étapes du projet un compatibilité 100% avec les programmes Python existants, validée par une grosse suite de test multi-projets.
Le projet a bien débuté, avec des gains intéressants au départ. Une PEP a aussi été acceptée par Guido van Rossum pour intégrer Unladen Swallow dans CPython (alors même que Unladen Swallow n'avait pas encore livré toutes ses promesses—cette décision a été un peu critiquée).
Au bout d'un an, le projet a été arrêté et la PEP annulée. En cause, d'une part un nombre important de bugs dans la compilation à la volée dans la suite LLVM qui ont fortement ralenti la progression attendue. D'autre part, le manque d'adoption interne chez Google, les développeurs étant finalement assez contents de leur CPython de base.
Un post d'un des développeurs résume la situation finale : Unladen Swallow Retrospective.
Le projet a quand même produit 4 versions, chacune plus rapide, ainsi qu'une suite de benchmarks de référence pour Python, assemblant tout en ensemble de suite de tests et benchmarks existants.
Le dernier né : Pyston
Dropbox (chez qui travaille maintenant Guido Van Rossum) nous annonce donc un nouveau de projet de VM : Pyston.
Quelques liens : l'annonce et le code
- https://tech.dropbox.com/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/
- https://github.com/dropbox/pyston
Ce sera une implémentation par dessus LLVM et son JIT d'une VM Python complète. Le projet vise au départ une compatibilité Python 2.7, avec un backend x86 uniquement.
Les développeurs sont partis de l'observation que dans le monde Javascript, les plus gros gains de performances ont été faits avec un compilateur JIT par méthode au lieu d'un tracing JIT qui va se concentrer sur des boucles. PyPy ayant déjà montré les gains qu'on peut avoir avec un tracing JIT, ils ont eu envie d'explorer l'autre versant de la compilation à la volée.
Pyston est une implémentation avec LLVM de l'interpréteur Python. Le langage Python est compilé en byte-code LLVM et la chaîne de compilation LLVM prend le relai pour ce qui concerne les optimisations et la compilation JIT.
C'est une grosse différence par rapport à Unladen Swallow qui se penchait sur l'optimisation de la VM CPython : on est là sur une réécriture complète. L'inconvénient est qu'il faut implémenter toute la logique du langage, un travail considérable : impossible de réutiliser l'infrastructure existante de la VM CPython. Les développeurs perdent aussi tout le savoir-faire qu'il y a déjà dans Python pour l'optimisation de la boucle d'évaluation.
L'avantage plus ou moins théorique est que l'optimisation peut être plus transversale puisqu'on évite un étage de traduction.
Le projet a aussi changé le garbage collector, passant du comptage de référence de CPython à un ramasse-miettes Conservateur. Sur les modules d'extension, le changement de Garbage Collector rendra ceux-ci nécessairement incompatibles et il y a un vague plan pour corriger cela.
Les développeurs ont l'air conscients de l'ampleur du travail à effectuer, notamment pour se rapprocher des performances de PyPy. Pour l'instant, le prototype prend en charge un tout petit sous-ensemble du langage Python. Celui-ci aurait montré d'après les développeurs un bon potentiel en terme de gain de performance.
Depuis le projet Unladen Swallow, LLVM a continué à s'améliorer et la partie qui avait posé tant de problème à Unladen Swallow a été réécrite. Les développeurs Dropbox espèrent donc ne pas subir les problèmes qu'a connu Unladen Swallow avec LLVM, ce qui tend à être confirmé par les résultats du projet Numba.
Il faut être bien conscient que même si LLVM fournit une chaîne de compilation JIT de bonne qualité, il y a beaucoup de travail à fournir en amont : l'interprétation du langage Python, le traçage des types, l'activation sélective du JIT, la gestion de la durée de vie des morceaux compilés. Il y aura beaucoup d'ajustements à trouver sur la consommation mémoire globale et sur les conditions d'activations du JIT.
Par la suite, ils envisageront une compatibilité Python 3, d'autres backends de génération de code, un meilleur Garbage Collector, l'intégration plus ou moins transparente des modules externes et même de se pencher sur le GIL.
Commentaire de l'auteur
Je précise que je n'y connais rien en compilation, LLVM ou JIT, j'ai juste plaisir à suivre de près ces projets très pointus.
La rédaction de la dépêche a fait ressortir que les efforts d'accélérations de Python, même s'ils sont réussis, butent presque tous sur la prise en charge transparente des modules d'extension. C'est vraiment un gros point noir, difficile à résoudre, et pourtant majeur. Les programmes Python qui tournent sans dépendances sont à mon avis minoritaires. Même s'il y a un effort un jour pour recompiler facilement vers PyPy ou autres, on tombera toujours sur le module un peu spécifique à un domaine qui ne fonctionnera pas.
Pyston, en ayant notamment changé le Garbage Collector, se range dans la même catégorie.
Seul le projet Unladen Swallow avait une approche globale sur le sujet avec une compatibilité totale. Ça aurait permis à n'importe quel programme Python de bénéficier des optimisations JIT, et ce à un coût de migration négligeable.
L'autre point qui me frappe au sujet de Pyston, c'est une certaine innocence dans l'approche (on pourrait presque dire naïveté). À leur lancement, les projets PyPy et Unladen Swallow avait une idée très précise et documentée de là où ils voulaient aller, articles de recherche à l'appui. On sentait qu'il y avait eu une analyse en profondeur du sujet.
Pour Pyston, ça ressemble plus à « tiens, pour Chrome, le per-method-JIT a bien marché, on a qu'à faire pareil avec Python et LLVM » . Il y a de très beaux projets qui sont issus d'une telle approche, mais aussi énormément qui se sont plantés parce qu'ils ne savaient pas où ils allaient.
Le choix de réimplémenter toute la VM Python est quand même très costaud, et implique qu'on ne verra pas de résultats utilisables avant au moins un an, voire plusieurs. Souhaitons en tout cas longue vie à ce projet et bon courage à leur développeurs !
Post-scriptum
Il y a plein d'autres efforts pour accélérer Python d'un façon d'un autre, autrement qu'en tapant dans la VM. Allez voir sur le site de Haypo la page qui y est consacrée si vous voulez en savoir plus, ou encore ses notes sur la vitesse de Python.
Aller plus loin
- L'article sur le blog de Dropbox (223 clics)
- Le projet github (100 clics)
- L'annonce sur la liste Python-dev (59 clics)
# ...
Posté par sheldoncooper . Évalué à 2.
+1 pour l'initiave de la depeche. En revanche des que j'ai lu ca:
je me suis dit que c'etait une tentative de noyer le poisson.
In fine, tout tend a etre CPU-bound et dire qu'une alternative au multi-threading sur un processeur multicore (qui est la norme aujourd'hui) est du multi-processus, c'est, comment dire, clairement de la mauvaise foi. Je suis presque sur que 99.9% des scripts python executes sont monothread. Mais ca n'invalide pas les critiques.
[^] # Re: ...
Posté par reno . Évalué à 4.
Peut-tu expliquer pourquoi tu dis ça? Le non partage par défaut du multi-processus me parait plus sain, et si tu peux toujours utiliser la mémoire partagée si tu en as besoin..
[^] # Re: ...
Posté par Firwen (site web personnel) . Évalué à 7.
je vais probablement me faire des ennemis à dire ça mais allons y.
Le dogme du "Evite les threads, fait du multi process : c'est safe" est selon moi, périmé depuis longtemps, et malheureusement pas encore mort et enterré.
Il y a des tas de situation où :
- la création de processus est trop coûteuse comparé aux gains de la parallélisation.
- les données sont larges:
- la copie dans chaque process n'est pas envisageable.
- la gestion de mémoire partagée est à la fois pénible et dangereuse.
- Les sections séquentielles et les sections parallèles sont petites et s'enchainent rapidement
- Je suis dans un serveur, créer X process de plus par requètes reçue est simplement pas acceptable.
Tous les pattern de parallélisation modernes actuels utilisent un système basé sur "Pool threads + dispatch task" bien plus simple à utiliser pour le programmeur et bien plus léger.
C'est le cas de Erlang avec ses "lightThread", de Go de Google avec ses goroutines, des commandes "async" de C++11, OpenMP en C/C++, de "concurrent" en Java, de Rust avec ses GreenThreads, etc.., etc…
[^] # Re: ...
Posté par reno . Évalué à 3.
Les pools de process ça existe aussi, ce n'est pas réservé aux threads..
Et pour qui est de la dangerosité de la mémoire partagée, explique en quoi c'est un argument contre les process??
Et puis franchement ce genre d'argument philosophique n'a pas grande valeur du code ou un benchmark ok, sinon bof
c'est du préjugé, de l'optimisation prématurée..
[^] # Re: ...
Posté par Firwen (site web personnel) . Évalué à 3. Dernière modification le 14 avril 2014 à 11:02.
ça n'a absolument pas la flexibilité et la légerté des threads pour faire du dispatch de taches.
Si le concept de processus Léger a été inventé et est aujourd'hui si utilisé, c'est pas pour les chiens et c'est pas parce que 90% des programmeurs de cette planète sont idiots sauf toi.
Le vieux dogme "une fil d'execution par processus" est à l'heure du multi-core mort.
Le dispatch par process n'offre simplement ni la facilitié d'utilisation des threads, ni leur niveau de granularité.
Si des languages exemplaires dans le domaine du parallelismes comme Erlang redéfinissent leur propre notion de "process" ( qui sont des green threads "safe" … ) c'est pas fait pour les chiens non plus.
Mémoire partagée veut dire mémoire partagée, c'est à dire la "shared memory", le /dev/shm, ou les appels POSIX shm_ .
Et oui c'est un argument contre, car n'importe qui qui a déja utilisé la shm sait à quel point c'est pénible, contraignant et source d'erreurs ( deadlock entre autre ).
Un argument philosophique sans grande valeur c'est de venir affirmer que la programmation concurrente doit se faire entièrement process based, et que ça justifie une implémentation moisie du multi-threading dans certains langages.
C'est en effet un bel exemple d'un pure argument théorique sans aucune expérience pratique.
[^] # Re: ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 7.
Pour MS Windows en fait. La création de processus est tellement coûteuse sous MS Windows qu'il a bien fallut contourner.
Un peu comme pour les threads.
Les threads c'est très dangereux, tout autant que de partager de la mémoire entre processus via un IPC. La différence est qu'en utilisant un IPC, ce n'est pas l'ensemble de la mémoire du processus qui est partagée entre les différents threads.
Bref, les threads sont nécessaires, utiles, mais il ne s'agirait pas de raconter des conneries et de prétendre qu'une approche multi-processus est caduque. Le contre-exemple par excellence est Google Chrome : il allie à la fois l'usage des processus et des threads.
[^] # Re: ...
Posté par Firwen (site web personnel) . Évalué à 8. Dernière modification le 14 avril 2014 à 13:39.
Exactement.
L'approche multi-processur n'est pas caduque, l'approche processus only est caduque.
Tout simplement car chaque approche a un niveau de granularité différent, donc deux applications différentes.
D'où ma rogne d'avant contre le "avoid thread, use process" qui sert d'excuse généralement quand on a honte de son code qui n'est pas thread-safe.
Chrome est un très bon exemple, Chrome utilise un process par onglet pour limiter les problèmes de stabilité. Mais par processus, il utilise un mix de multi threading ( 4-8 threads ) pour le moteur JS, le rendu, etc… et d'event loop (libevent) pour les IO.
[^] # Re: ...
Posté par Tonton Th (Mastodon) . Évalué à 3.
Ah ben zut, moi qui croyait que c'était né avec SunOS…
[^] # Re: ...
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Il semblerait que ce soit même encore plus vieux, mais je ne parviens pas à trouver de références sur le sujet.
De mon point de vue, la culture des threads c'est répandue depuis MS Windows, qui en avait besoin pour contourner des défauts de conception des processus de MS Windows NT.
Maintenant, si tu as une source qui donne une histoire des threads, je suis preneur.
[^] # Re: ...
Posté par reno . Évalué à 3.
Facepalm, mais tu le fait exprès ou quoi?
Avec les threads en C toute tes variables globales sont en mémoire partagée (pas en D ou par défaut toute variable globale est en TLS ce qui est un bon changement) donc la source d'erreur des deadlock, ELLE EST OMNIPRESENTE AVEC LES THREADS!!
Mais pas avec les processus ou tu utilise la mémoire partagée uniquement aux endroits où tu en as besoin pour des raisons de performances..
J'ignore si tu trolle ou si c'est par pure ignorance, mais les processus étant plus sûr que les threads (pas d'état global partagé par défaut), pour privilégier la fiabilité, on devrait utiliser les processus par défauts sans shm, puis s'il y a un problème de perf les processus avec shm et seulement les threads si il y a encore un problème de performance..
Ce n'est pas toujours le cas parce que malheureusement:
- certains langages intègrent les threads mais pas les processus, donc c'est plus lourd pour les dev d'utiliser les processus.
- Windows gère mal les processus.
[^] # Re: ...
Posté par claudex . Évalué à 5.
Un gros avantage des threads, c'est qu'ils terminent tous avec le processus. Par exemple, si ton thread principal crash, ou est killé à la main, les autres thread suivent (vu qu'on kill le processus), si tu fais ça avec plusieurs processus, il faut gérer le cas du père qui est mort et se terminer.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 7.
Je ne pense pas que le multi-process résolve tous les cas, et ce n'est pas ce que j'ai écrit. J'ai juste rappelé que d'une part, que:
il y existait d'autres solutions possibles que le multi-thread pour gérer des programmes CPU-bound . Le module multiprocessing fournit un service transparent pour partager des données et lancer des opérations sur plusieurs processus. Ca peut toutefois poser des limites si la quantité de données à partager est importante, mais c'est un problème pas moins difficile à résoudre que d'écrire de programme multithreads sans bugs.
Beaucoup de programmes qui utilisent les threads sont IO-bound (on gère des opérations bloquantes) et dans ce cas, les threads en Python marchent très bien.
Un autre aspect sur le GIL qu'on peut rappeler, c'est que retirer le GIL sans affecter les performances des programmes mono-threads est extrèmement difficile. Sans verrou global, il y aura une multiplicité de verrous locaux à utiliser, ce qui dégrade le cas mono-thread.
Pour l'instant, à part une solution miracle que nous sortirait PyPy, le GIL est là pour rester
[^] # Re: ...
Posté par sheldoncooper . Évalué à 1.
je suis d'accord.
mon principal reproche est que la formulation dans la depeche est maladroite - ca s'arrete la. Elle laisse croire que les faiblesses de CPython sont des cas particuliers, alors que justement, dans l'absolu, la latence sur les I/O ou une application monothread sont des cas particuliers. Frequents mais particuliers. Python a un gros avantage sur les autre langages de scripting : il profite de tous les trucs "hype" et en plus se paie le luxe d'avoir un scope d'action large. L'analogie avec Linux et les OS peut etre osee.
Donc si CPython souffre de ses lacunes, c'est aussi la rancon du succes du langage (car finalement c'est toujours CPython par defaul).
Il existe des application ou le multithreading est la norme (traitement d'images, calcul scientifiques) pour eviter le gap monothread -> cluster.
Si CPython a une gestion des threads aussi merdique que les OS libres en 2000 (linux-threads et libc_r sous FreeBSD) et bien c'est la vie. Il faut l'admettre, ce n'est pas en faisant croire que ces situation arrivent une fois toute les morts d'eveque que ca fera avancer le schmilblik
[^] # Re: ...
Posté par Philippe F (site web personnel) . Évalué à 3.
Je me relis pour voir:
Bon, ok, j'en ai fait un peu trop. Il est tellement fréquent de lire CPython c'est de la m**** à cause du GIL que j'ai voulu redonner du poids au fait que CPython marche plutôt pas mal. Mea Culpa !
Et il me parait important de rappeler que le problème du GIL n'est pas un problème générique mais un problème qui affecte des cas précis d'utilisation de Python.
J'avoue que je comprends pas ta phrase.
Il y a le cas général qui comprend tous les types d'applications possibles avec les threads où on peut dire que Python va s'en sortir dans certains cas et pas dans d'autres. Donc au final, une non réponse.
Ensuite, on peut partitionner l'ensemble des application des applications utilisant des threads en applications IO-Bound et en CPU-Bound. Dans le premier cas, Python s'en sort bien, dans le deuxième pas.
Difficile de savoir si le premier cas couvre une majorité ou une minorité d’application. Surtout que c'est plus par domaine. Dans le calcul scientifique, traitement de données (image, video, statistiques), on est souvent dans du CPU-bound donc le GIL peut poser problème. Dans le domaine des utilitaires, des langage d'intégration, on est plus souvent dans du IO-Bound voir du rien-du-tout-bound (ça marche déjà à la vitesse qu'il faut).
Si j'avais voulu nier, je l'aurai même pas rappeler dans la dépêche. Tu pourrais m'en dire plus sur la gestion des threads des années 2000, je ne connais pas mais ça m'interesse….
# Commentaire de l'auteur
Posté par barmic . Évalué à 5.
Surprenant d'avoir un paragraphe « Commentaire de l'auteur » alors qu'il y en a déjà tout le long des commentaires. J'aurais AMHA préféré un ton plus objectif et une meilleure séparation entre les faits et le jugement de l'auteur.
C'est une dépêche intéressante.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Commentaire de l'auteur
Posté par Philippe F (site web personnel) . Évalué à 5.
Sur la première partie de la dépêche, j'ai vraiment cherché à rester objectif, rassemblant toutes les informations dont j'ai connaissance, sans y mêler mon opinion.
Sur la conclusion, c'est un choix partisan de fait. L'objectivité m'ennuie en général, je préfère largement le débat d'idées ! Dommage d'ailleurs que ce soit publié un dimanche et pas un vendredi ;-)
Et puis, mieux vaut une dépêche subjective assumée que des points de vues prétendument objectif que essaient d'enfumer tout le monde. La mécanique quantique nous a d'ailleurs largement prouvée s'il en était encore besoin que la notion d'objectivité n'existe pas !
[^] # Re: Commentaire de l'auteur
Posté par barmic . Évalué à 2.
Justement le fait de mettre un paragraphe sensé regrouper les avis du rédacteurs alors que l'on en a déjà un peu tout au long de la dépêche, c'est des paragraphes prétenduement objectif qui essaient d'enfumer tout le monde.
Je ne porte pas de jugement sur l'avis en lui même, il est peut être vrai. Mais dés le départ on voit un parti pris pro-cpython et contre les autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Commentaire de l'auteur
Posté par Philippe F (site web personnel) . Évalué à 6.
Je suis surpris d'avoir fait penser que je suis pro-CPython. C'est tout à fait faux. J'ai beaucoup d'espoir dans des implémentations alternatives qui enrichissent l'écosystème.
Je trouve que PyPy est un super projet, tout comme IronPython. Jython, je connais très peu, ce que j'ai indiqué aussi clairement que possible. Unladen Swallow est un projet extraordinaire. Pyston, aujourd'hui, c'est juste une annonce et trois bouts de code.
Par contre, je n'ai pas cherché à masquer les problèmes des différents projets: PyPy ne gère que moyennement les modules d'extensions, IronPython restera un citoyen de 2nde zone dans un écosystème .NET (par rapport à Visual Basic), CPython souffre toujours de son GIL dans des conditions précises, Unladen Swallow est mort, Jython a l'air de souffrir pas mal.
Aujourd'hui, si tu cherches un substitut complet à CPython, il n'y en a pas. C'est un fait objectif.
Maintenant, si tu cherches un substitut à CPython et que ton projet utilise peu de modules d'extensions, PyPy est un très bon choix. Avec un peu de chance, les modules seront compilés ou compilables avec cpyext ou sera facilement interfaçable avec cffi.
De même côté IronPython, si tu cherches un substitut à Visual Basic, tu peux passer ton chemin.
# Modules d'extension
Posté par barmic . Évalué à 3.
Peut être qu'il faudrait inverser le problème, non ? Si personne n'a réussi à résoudre le problème en 15 ans, peut être que le problème ne vient pas des implémentations alternatives mais de l'implémentation de référence qui a des problèmes de portabilité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Modules d'extension
Posté par manawy (site web personnel) . Évalué à 2.
En générale, les modules d'extension ne sont pas écrits en C juste pour le plaisir mais bien pour contourner les limitations de python (en général pour être plus efficace). Donc la non-portabilité est en général plus une feature qu'un bug. Les extensions exploitent directement les caractéristiques de l'implémentation (comme le comptage de référence à la main). C'est notamment pour simplifier l'écriture de ces extensions que des langages comme cython ont été inventés.
Pour avoir des extensions portables, il faudrait aussi fixer les méchanismes internes de l'implémentation, ce qui a mon avis réduit l'intérêt d'avoir plusieurs implémentation.
Sinon, une autre implémentation non citée par la dépêche : Pynie une implémentation pour Parrot
[^] # Re: Modules d'extension
Posté par barmic . Évalué à 2.
Je ne met pas en cause leur utilité mais j'emets des doutes sur l'implémentation.
Donc CPython ne pourra jamais faire évoluer son gc comme l'ont fait java et javascript (ça a permis de faire passer de gros gap de performance à ce dernier dans son implémentation v8 comme monkey).
Euh… d'après la dépêche il n'y a déjà pas d'inétrêt à avoir plusieurs implémentations parce qu'elles ne sont pas compatibles avec les modules d'extension. Actuellement même si ça n'est peut être pas dans un PEP, l'implémentation interne est fixé. Pour que les implémentations aient un intérêt il faut surtout ne plus l'exposer aux modules (comme c'est fait avec JNI par exemple, si je ne me trompe pas).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Modules d'extension
Posté par Philippe F (site web personnel) . Évalué à 5.
Tu as raison sur le fond pour les modules d'extensions: ils ont été conçus pour s'interfacer avec CPython (dans un temps immémorable où CPython n'était que l'unique implémentation de Python) et pas du tout pour être indépendants de l'implémentation. Notamment, le durée de vie des objets, même dans les modules d'extensions, est gérée par le comptage de référence, c'est à dire par le Garbage Collector de CPython.
Etre compatible avec CPython veut dire fonctionner avec le Garbage Collector de CPython ou gérer ça de façon très astucieuse. C'est ce qu'a fait PyPy, en proposant un modèle mixte pour les modules d'extension. Si je me souviens bien, ils utilisent le encore le ref-counting mais c'est le Garbage Collector classique qui collecte les objets une fois les références épuisées. Donc on y est presque (c'est le module cpyext), mais apparemment, toute l'API CPython n'est pas implémentée.
Pyston veut aussi conserver la compatibilité totale avec les extensions, avec des bidouilles autour du refcounting. Leurs plans sont malheureusement très théoriques et il faudra attendre qu'ils s'y mettent pour savoir si leur approche tient la route.
Pour résoudre ce problème de fond, les auteurs de PyPy ont écrit (bien avant PyPy) deux modules d'interfaçage avec des bibliothèques: ctypes et maintenant cffi. Les deux permettent d'appeler très facilement, sans compilation, des bibliothèques dynamiques. Ca résoud un cas majeur d'utilisation des modules d'extensions, à savoir interfacer des libs existantes écrites en C. Cffi est compatible avec PyPy, et bientôt avec Jython. On peut donc espérer à terme réduire la surface du problème.
Côté CPython, un effort a été fait pour réduire le nombre de symboles CPython exposés, afin de proposer une compatibilité plus simple avec CPython. L'objectif est plus modeste, permettre la compatibilité des modules d'extensions avec plusieurs versions de CPython en même temps.
[^] # Re: Modules d'extension
Posté par Philippe F (site web personnel) . Évalué à 3.
La comparaison avec Javascript n'est pas tout à fait honnête. Dans le cas de javascript, les accès au navigateur se font par des API normalisées. Donc on peut substituer n'importe quelle implémentation à une autre, ça ne perturbe pas le code Javascript.
CPython ne peut pas faire évoluer son GC mais en même temps, il n'a pas vocation à le faire. Une implémentation de référence, c'est bien quand c'est stable. Toutes les autres implémentations ont un GC différent. Elles devront juste trouver des ruses de malade pour rester compatible avec l'API GC de CPython…
[^] # Re: Modules d'extension
Posté par barmic . Évalué à 6.
Ce que je dis c'est que s'enfermer dans un GC particulier c'est dommageable et que les langages à GC qui ont subit le plus d'optimisations ces dernières années ont du changer leur GC.
Est-ce que le gc par comptage de référence est une fonctionnalité du langage ? Est-ce que c'est dans une PEP ? Si oui alors c'est toutes les implémentations alternatives qui sont dans le faux, sinon CPython ne devrait pas exposer d'API non standard.
Une implémentation de référence, c'est bien quand ça suit exactement la norme et quand ça n'expose aucun particularité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Modules d'extension
Posté par manawy (site web personnel) . Évalué à 5.
ben python n'est pas défini par ses extensions… c'est un peu la définition d'une extension
Python est défini par la grammaire et la bibliothèque standard. N'importe quelle implémentation doit juste implémenter ça, et cela peut-être fait indépendamment du GC ou autre choix. (C'est peut-être juste plus facile
Après, ils s'est avéré que la bibliothèque standard n'était pas suffisant pour certains cas. Une des extensions la plus connus est sans doute numpy pour le calcul scientifique. Cela ne fait pas partie de la bibliothèque standard et les auteurs du projet ont choisi une approche implémentation dépendante, pour être efficace. Du coup les autres implémentations se trouvent défavorisés… Mais ce n'est pas la bibliothèque standard, ni la grammaire du langage donc ça ne fait pas partie du langage vraiment, c'est juste extrêmement dommage de ne pas pouvoir l'utiliser.
La solution serait d'inclure ces extensions dans la bibliothèque standard; mais ça risque de faire un énorme travail pour les implémentations alternatives…
L'autre solution étant d'utiliser les couches intermédiaires, comme expliquer dans les commentaires, mais cela suppose de changer la base de code existante… et vu la rapidité du passage à Python 3 (pourquoi Pyston ne commence pas directement par là ?) ben ça ne risque pas d'arriver bientôt…
En gros c'est bien dommage, mais c'est un peu difficile de changer les choses. Néanmoins, c'est un problème que les devs python ont l'air d'avoir bien en-tête et la situation va peut-être se décanter petit à petit.
Cela se passe déjà par un effort d'homogéneisation des extensions (voir les modules cffi et autres ou par exemple la PEP 465 sur un opérateur dédié pour la multiplication de matrix)
[^] # Re: Modules d'extension
Posté par barmic . Évalué à 5.
Ça c'est la théorie, dans les faits, toutes les implémentations alternatives ne décollent pas à cause de ces extensions.
C'est pas une solution. Aujourd'hui on parle beaucoup de numpy mais demain on pourrait parler de nouvelles bibliothèques, c'est l'implémentation des modules d'extension qui pose problème. Il y a quelqu'un qui parlait plus haut d'une bibliothèque python pour charger des bibliothèque partagée et les utiliser directement, ça pourrait faire l'objet d'un PEE et devenir la voie royale pour faire des modules d'extensions.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Modules d'extension
Posté par Philippe F (site web personnel) . Évalué à 3.
Il y a déjà un PEP sur le sujet. Mais ça ne résoud qu'une partie du problème. Cffi va permettre d'interfacer plus facilement des modules en C mais je suis pas sur que ça convienne à NumPy. NumPy est vraiment une addition au langage, pour manipuler des tableaux de données, faire des opérations mathématiques complexes en séries, manipuler d'autres types de nombres. Quid aussi du Garbage Collector, je sais pas trop comment c'est géré.
Je pensais aussi à PyQt, je serai curieux de voir ce que Cffi pourrait faire pour un tel projet.
[^] # Re: Modules d'extension
Posté par djano . Évalué à 3.
Certainement parce que DropBox (sponsor du projet) travaille avec Python 2.7 en production.
Visiblement ils ne prévoient pas de passer bientôt a Python 3.
# Jython
Posté par barmic . Évalué à 3.
De ce que je sais Jython est utilisé comme langage de script pour manipuler des serveurs d'application. C'est en tout cas le cas de weblogic. Le temps de chargement n'est pas vraiment un problème et on accède aux objets JMX du serveur : des objets décrivant la configuration ou le fonctionnement du serveur et dont la manipulation modifie le serveur. Ça permet par exemple de modifier le port d'écoute du serveur ou de configurer les sources de données.
De ce qu'on m'a dit (je crois), jython est arrivé avant groovy et était donc un choix normal pour avoir un langage de script sur JVM.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Jython
Posté par Boa Treize (site web personnel) . Évalué à 4.
Jython est également pas mal utilisé pour administrer WebSphere d'IBM.
Par contre pour ce genre d'affirmation dans la dépêche, il faudrait des sources :
Parce que moi ce que je vois plutôt, c'est que le projet stagne gravement et qu'il n'y a pratiquement plus personne qui travaille dessus. Dans le monde Java, on n'en entend plus parler du tout, les devs sont passés à des langages plus récents.
Par ailleurs :
Quel langage se révolutionne à chaque release ? :) La JVM est globalement améliorée à chaque release. C'est malheureusement difficile de trouver de bons benchmarks à ce sujet, mais l'opinion générale est que Java 7 est plus rapide que Java 6 (plusieurs pourcents). Pour Java 8 c'est encore un peu tôt pour le dire, les premiers avis semblaient plus mitigés.
[^] # Re: Jython
Posté par Philippe F (site web personnel) . Évalué à 3.
Un résumé de l'état de Jython a été posté sur Python-dev, pour ceux qui veulent connaitre des détails sur le projet. Il a pas l'air mort puisque pas mal de projets sont en route, mais on sent pointer le manque de ressources:
https://mail.python.org/pipermail/python-dev/2014-April/133944.html
# Correction
Posté par xcomcmdr . Évalué à 2.
Le DLR est déjà installé si on a le .NET Framework version >= 4.0
Proposition de correction :
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Informations complémentaires
Posté par Philippe F (site web personnel) . Évalué à 6.
Lors de la PyCon 2014, il y a eu quelques mises à jour sur les sujets que j'ai abordé:
Pyston
L'auteur a maintenant publié une FAQ, qui répond à différents aspects un peu flous du projet: http://blog.kevmod.com/2014/04/pyston-faq/
Je maintiens donc mon scepticisme sur l'approche, et l'aspect très expérimental de ce projet. J'attendrai que Pyston fasse ses preuves avant de croire qu'il puisse changer quelque chose au paysage Python actuel.
IronPython
La communauté commence à prendre en main le projet, et de nouveaux contributeurs ont rejoint le projet. Le portage vers Python 3 est en cours, le projet se porte globalement bien.
Jython
Le port vers Python 3 est entamé, ainsi qu'une adapatation de cffi, le module qui permet d'interfacer directement des bibliothèques dynamiques. Des travaux sur l'intégration de PyPi (le dépot officiel de programmes Python facilement installables) ont également commencé. Le projet souffre en général d'un manque de contributeurs.
PyPy
Dernier succès: 1 million de téléchargement pour la dernière version de PyPy, compatible avec Python 2.7.6 . Une version compatible Python 3.2 est presque prête, il reste 3 bugs à corriger. Il va y avoir une nouvelle levée de fond pour les Transactions Mémoires
[^] # Re: Informations complémentaires
Posté par gawel (site web personnel) . Évalué à 1.
Je me suis retrouvé par hasard à une table avec Guido à pycon. Durant la discussion il a clairement avoué avoir tenté de décourager son collègue de créer une nouvelle vm… :)
# À propos de Dropbox
Posté par André Rodier . Évalué à 6.
Je n'ai pas vu passer l'info sur linuxfr, alors je pointe un lien:
http://pro.clubic.com/technologie-et-politique/actualite-695854-dropbox-nomination-condoleezza-rice-debat.html
Pour info, "Dropbox" était marqué comme bientôt opérationnel dans PRISM, à une époque ou cette femme était au gouvernement: http://www.siliconbeat.com/2014/04/11/why-condoleezza-rice-joining-dropbox-board-isnt-a-mozilla-moment/
Pour ma part, je reste avec owncloud…
[^] # Re: À propos de Dropbox
Posté par ZeroHeure . Évalué à 3.
fait un journal
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Et pythran ?
Posté par lolop (site web personnel) . Évalué à 5.
Qui traduit du Python vers C++ qui est ensuite compilé vers un module python en natif.
Cf https://linuxfr.org/recherche?utf8=%E2%9C%93&q=pythran
Et https://github.com/serge-sans-paille/pythran
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Et pythran ?
Posté par Philippe F (site web personnel) . Évalué à 4.
Et Cython, Shedskin, Psyco, etc. J'ai parlé des VM, la page référencée en fin d'article liste de nombreuses autres expérimentations…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.