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.
Aucun commentaire:
Enregistrer un commentaire