Google propose en open source Grumpy, un runtime Python expérimental en Go
Qui vise à aider YouTube à surmonter les limitations de Python

Le , par Stéphane le calme, Chroniqueur Actualités
Le serveur front-end sur lequel s’appuie YouTube.com ainsi que les API YouTube sont principalement écrits en Python et servent des millions de requêtes par seconde. « Le front-end de YouTube tourne sur CPython 2.7, nous avons donc mis beaucoup d'efforts à améliorer l'exécution et à adapter notre application pour qu'elle fonctionne de façon optimale. Ces efforts ont porté beaucoup de fruits au fil des ans, mais nous nous heurtons toujours au même problème : il est très difficile de faire en sorte que les charges de travail simultanées aient un bon rendement sur CPython », a expliqué l'ingénieur YouTube Dylan Trotter dans un billet de blog.

Bien entendu, pour y remédier, les ingénieurs ont cherché une alternative du côté d’autres environnements d’exécution Python. « Après quoi nous nous sommes posé cette question folle : et si nous implémentions un runtime alternatif optimisé pour le service en temps réel ? ». À ce moment là, Go semblait être le meilleur choix de plateforme « étant donné que ses caractéristiques opérationnelles cadrent avec notre cas d’utilisation (par exemple des threads légers) ». « Python dans Go semblait naturel et c’est ainsi que Grumpy est né », a-t-il continué.

Trotter a décrit Grumpy comme étant un runtime Python expérimental pour Go. « Il traduit le code Python en programmes Go et ces programmes transpilés s'exécutent de façon transparente dans le runtime de Go. Nous avions besoin de prendre en charge une grande base de code Python existante, il était donc important d'avoir un haut degré de compatibilité avec CPython (quirks et le reste) ». L’objectif est de faire de Grumpy une alternative de runtime de remplacement pour tout projet purement Python.

Deux choix de conception, qui ont eu un impact non négligeable, ont été fait :
  • tout d’abord, les ingénieurs ont renoncé au support des modules d’extension de C : cela signifie que Grumpy ne peut pas exploiter la richesse des extensions Python C existantes, « mais il nous a donné beaucoup de flexibilité pour concevoir une API et une représentation d'objet qui évoluerait pour les charges de travail parallèles. En particulier, Grumpy n'a pas de verrou d'interpréteur global et il tire parti du recyclage de la mémoire de Go pour la gestion de la durée de vie des objets au lieu de compter les références » ;

  • ensuite, Grumpy n’est pas un interpréteur : les programmes Grumpy sont compilés et liés comme n’importe quel autre programme Go. « L'inconvénient est une perte dans la flexibilité de développement et de déploiement, mais en contrepartie il offre plusieurs avantages. S’il crée des opportunités d'optimisation au moment de la compilation via une analyse de programme statique, le plus grand avantage est que l'interopérabilité avec le code Go devient très puissante et simple: Les programmes Grumpy peuvent importer des paquets Go comme les modules Python ! ».

Trotter a averti que, bien que Grumpy vient d’être publié en open source, il en est encore au stade alpha : « la plupart des constructions de langage et de nombreux types intégrés de base fonctionnent comme on s'y attend [mais] il y a encore des trous à combler - de nombreux types intégrés manquent à l’appel, des méthodes et des attributs, des fonctions intégrées sont eux aussi absents et la bibliothèque standard est pratiquement vide ».

Dans une réponse a une requête qui demandait si un support de Python 3 était prévu tandis que le projet gagne en maturité, Trotter a avancé sur GitHub que « nous avons une vaste codebase Python 2.7, raison pour laquelle nous nous sommes concentrés dessus. J’aimerais bien qu’il y ait un support de Python 3, c’est juste une entreprise fastidieuse », avant de suggérer à ceux qui sont intéressés par un support de Python 3 de faire un fork de Grumpy.

L’une des raisons qui peut également avoir motivé au développement de Grumpy est la date de vie de Python 2.7 qui est prévue pour 2020. Au lieu de faire une mise à jour de son codebase Python 2.7 vers Python 3, Google semble planifier de convertir au moins une partie de son code Python en Go au cours des prochaines années.

se rendre sur le dépôt GitHub de Grumpy

Source : blog Google, date de fin de vie Python 2.7


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de Traroth2 Traroth2 - Expert éminent sénior https://www.developpez.com
le 06/01/2017 à 10:15
Ca veut dire quoi, un "runtime Python pour Go" ? C'est runtime Python écrit en Go, c'est ça ?
Avatar de defZero defZero - Membre à l'essai https://www.developpez.com
le 06/01/2017 à 22:19
Est ce que l'on peut parler de runtime Python écrit en go, si ce que fait réellement Grumpy est de prendre un code Python 2.7 (uniquement) pour le convertir, puis le compiler comme une source Go classic ?
Pour moi sa ressemblerait plus à ce que fait un transpileur en travaillant sur une conversion Source à Source.
Mais sa c'est si j'ai bien compris l'article ...
Avatar de hl037 hl037 - Membre du Club https://www.developpez.com
le 14/01/2017 à 2:07
1) J'aimerais bien voir un benchmark contre du python 3.6 (le GIL a été retravaillé de mémoire et c'est plus rapide maintenant)
2) J'aimerais aussi beaucoup voir un autre contre pypy (on sait tous que CPython est gourmand et que pypy est plus rapide au long terme)
3) J'aimerais enfin aussi beaucoup voir un benchmark contre Cython qui offre aussi de l'optimisation...

Bref, je pense que google a déjà fait tous ces tests (ce serait con de réinventer la roue non ? )... Mais je trouve un peu facile de faire un comparatif sur une version de python obsolète... ok, encore de vieux module pas encore porté en python 3 (comme google-apputils ? tient donc...)
http://py3readiness.org/

Bref... Rappelons que le go a été développé par google, donc le choix de la solution n'est évidemment pas objectif...

Ensuite, effectivement, si ça compile en Go, ce n'est pas vraiment un runtime, c'est plutôt un transpileur comme mentionné dans un autre commentaire... Et ça se rapproche beaucoup de cython du coup.

Néanmoins, python a besoin d'un certain niveau d'introspection, et ce n'est pas faisable dans tous les langage donc j'imagine que ça doit quand même embarquer un interpréteur à la volée, donc certainement qu'il y a aussi un runtime.

Bref... Quoi qu'il en soit, tant que ça exécute du python, ça me dérange pas trop, ça fait juste un autre concurrent pour pousser à booster les performances
Offres d'emploi IT
Ingénieur H/F
Safran - Ile de France - Moissy-Cramayel (77550)
Spécialiste systèmes informatiques qualité et référent procédure H/F
Safran - Ile de France - Colombes (92700)
Architecte technique des systèmes d'information H/F
Safran - Ile de France - Évry (91090)

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil