Avis sur "Unladen Swallow" ?

Question

Quelles sont vos opinions et vos attentes concernant L'hirondelle à vide de Google ? De leur plan de projet :

Nous voulons rendre Python plus rapide, mais nous voulons aussi voulons également faciliter l'utilisation de grandes applications bien établies de de passer à Unladen Swallow.

1. Produire une version de Python au moins 5 fois plus rapide que CPython.
2. Les performances de l'application Python doivent être stables.
3. Maintenir la compatibilité au niveau des sources avec les applications pour les applications.
4. Maintenir la compatibilité au niveau des sources avec les modules d'extension de CPython modules.
5. Nous ne voulons pas maintenir une implémentation de Python pour toujours ; nous considérons notre travail comme une branche, et non une fourche.

Et encore plus doux :

En outre, nous avons l'intention de supprimer les GIL et de corriger l'état du multithreading en Python. Nous pensons que que cela est possible grâce à la l'implémentation d'une GC

Cela semble presque trop beau pour être vrai, comme le meilleur de PyPy et de Stackless combinés.

Plus d'informations :

• Jesse Noller : "Pycon : Unladen-Swallow"
• ArsTechnica : "Google cherche le saint graal des performances de Python"

Mise à jour : comme DNS l'a signalé, il y avait une question connexe : http://stackoverflow.com/questions/695370/what-is-llvm-and-how-is-replacing-python-vm-with-llvm-increasing-speeds-5x

Answer 1

J'ai de grands espoirs pour elle.

1. Plusieurs personnes de Google y travaillent actuellement. Étant donné que le BDFL y est également employé, c'est un point positif.

2. D'emblée, ils déclarent qu'il s'agit d'une branche, et non d'une fourche. En tant que tel, il est tout à fait possible qu'il soit finalement intégré au tronc.

3. Le plus important, ils ont une version fonctionnelle . Ils utilisent une version de l'hirondelle non chargée à l'heure actuelle pour les trucs de Youtube.

Ils ont l'air de bien s'entendre. Ils ont un plan relativement détaillé pour un projet à ce stade, et ils ont une liste de tests qu'ils utilisent pour évaluer les améliorations et les régressions de performance.

Je ne retiens pas mon souffle sur la suppression du GIL, mais même s'ils n'y parviennent jamais, l'augmentation de la vitesse suffit à la rendre géniale.

Answer 2

Je suis désolé de te décevoir, mais quand tu lis PEP 3146 les choses se présentent mal.

L'amélioration est maintenant minime et par conséquent le code du compilateur devient plus compliqué. La suppression des GIL présente également de nombreux inconvénients.

Au fait, PyPy semble être plus rapide que Unladen Swallow dans quelques tests .

Answer 3

Je pense que le projet a des objectifs nobles et qu'avec suffisamment de temps (2-3 ans), ils atteindront probablement la plupart d'entre eux.

Il se peut qu'ils ne puissent pas fusionner leur branche dans le tronc car le point de vue actuel de Guido est que cpython doit être une implémentation de référence (c'est-à-dire qu'il ne doit pas faire des choses qui sont impossibles à copier pour IronPython et jython). J'ai vu des rapports selon lesquels c'est ce qui a empêché les parties cool de stackless d'être fusionnées dans cpython.

Answer 4

Cette question ont discuté de plusieurs des mêmes choses. Mon opinion est que ça a l'air génial, mais j'attends de voir à quoi ça ressemble, et combien de temps ça prend pour devenir stable.

Je suis particulièrement préoccupé par la compatibilité avec le code et les bibliothèques existants, et par la réaction de la communauté des auteurs de bibliothèques. En fin de compte, en dehors des projets de loisirs personnels, il n'a aucune valeur pour moi tant qu'il ne peut pas exécuter toutes mes bibliothèques tierces.

Answer 5

Guido vient de poster un article sur son compte twitter qui est une mise à jour de l'article de Jesse Noller posté plus tôt. http://jessenoller.com/2010/01/06/unladen-swallow-python-3s-best-feature/ . On dirait qu'ils vont de l'avant comme mentionné précédemment avec python 3.