Existe-t-il des fonctionnalités Ruby / Python qui bloquent la mise en œuvre des optimisations (par ex. mise en cache en ligne ) a un moteur V8 ?
Python est co-développé par les gars de Google, il ne devrait donc pas être bloqué par des brevets logiciels.
Ou bien il s'agit plutôt d'une question de ressources mises dans le projet V8 par Google.
Qu'est-ce qui bloque Ruby, Python pour obtenir la vitesse de Javascript V8 ?
Rien.
Bon, d'accord : l'argent. (Et le temps, les gens, les ressources, mais si vous avez de l'argent, vous pouvez les acheter).
Une équipe d'ingénieurs brillants, très spécialisés et très expérimentés (et donc très bien payés) travaille sur V8. Ils ont des dizaines d'années d'expérience (individuellement, collectivement, c'est plutôt des siècles) dans la création de moteurs d'exécution performants pour les langages OO dynamiques. Ce sont essentiellement les mêmes personnes qui ont créé la JVM Sun HotSpot (parmi beaucoup d'autres).
Lars Bak, le principal développeur, travaille littéralement sur les VM depuis 25 ans (et toutes ces VM ont abouti à la V8), ce qui représente pratiquement toute sa vie (professionnelle). Certaines des personnes qui écrivent les VM de Ruby n'ont même pas 25 ans.
Y a-t-il des caractéristiques Ruby/Python qui bloquent la mise en œuvre des optimisations (par exemple, la mise en cache en ligne) du moteur V8 ?
Étant donné qu'au moins IronRuby, JRuby, MagLev, MacRuby et Rubinius ont une mise en cache en ligne monomorphique (IronRuby) ou polymorphique, la réponse est évidemment non.
Les implémentations modernes de Ruby font déjà beaucoup d'optimisations. Par exemple, pour certaines opérations, la méthode de Rubinius Hash est plus rapide que celle de YARV. Cela n'a pas l'air très excitant jusqu'à ce que vous réalisiez que la classe de Rubinius Hash est implémentée en Ruby pur à 100%, tandis que celle de YARV est implémentée en C optimisé à la main à 100%.
Donc, au moins dans certains cas, Rubinius peut générer un meilleur code que GCC !
Ou bien il s'agit plutôt d'une question de ressources mises dans le projet V8 par Google.
Oui. Pas seulement Google. La lignée du code source de V8 a maintenant 25 ans. Les personnes qui travaillent sur V8 ont également créé la VM Self (à ce jour, l'un des moteurs d'exécution de langage OO dynamique les plus rapides jamais créés), la VM Smalltalk Animorphic (à ce jour, l'un des moteurs d'exécution Smalltalk les plus rapides jamais créés), la JVM HotSpot (la JVM la plus rapide jamais créée, probablement la VM la plus rapide de tous les temps) et OOVM (l'une des VM Smalltalk les plus efficaces jamais créées).
En fait, Lars Bak, le principal développeur de V8, a travaillé sur chacun d'entre eux de ceux-là, plus quelques autres.
Il y a beaucoup plus de raisons d'optimiser les interpréteurs JavaScript, c'est pourquoi Mozilla, Google et Microsoft y consacrent tant de ressources. JavaScript doit être téléchargé, analysé, compilé et exécuté en temps réel pendant qu'un être humain (généralement impatient) l'attend, il doit être exécuté PENDANT qu'une personne interagit avec lui, et ce dans un environnement client non contrôlé qui peut être un ordinateur, un téléphone ou un grille-pain. Il DOIT être efficace pour fonctionner efficacement dans ces conditions.
Python et Ruby sont exécutés dans un environnement contrôlé par le développeur/déployeur. Un serveur puissant ou un système de bureau où le facteur limitant sera généralement des choses comme la mémoire ou les E/S de disque et non le temps d'exécution. Ou lorsque des optimisations non liées au moteur, comme la mise en cache, peuvent être utilisées. Pour ces langages, il est probablement plus judicieux de se concentrer sur les fonctionnalités du langage et de la bibliothèque que sur l'optimisation de la vitesse.
L'avantage secondaire de cette situation est que nous disposons de deux excellents moteurs JavaScript open source à haute performance qui peuvent être et sont réaffectés à toutes sortes d'applications telles que Node.js.
Cela tient en grande partie à la communauté. Python et Ruby, pour la plupart, ne bénéficient pas du soutien des entreprises. Personne n'est payé pour travailler sur Python et Ruby à plein temps (et ils ne sont surtout pas payés pour travailler sur CPython ou MRI tout le temps). V8, en revanche, est soutenu par la société informatique la plus puissante du monde.
De plus, V8 peut être plus rapide parce que la seule chose qui compte pour les gens de V8 est l'interpréteur - ils n'ont pas de bibliothèque standard sur laquelle travailler, ni de préoccupations concernant la conception du langage. Ils écrivent juste l'interpréteur. Et c'est tout.
Cela n'a rien à voir avec le droit de la propriété intellectuelle. Python n'est pas non plus codéveloppé par les gars de Google (son créateur y travaille avec quelques autres committers, mais ils ne sont pas payés pour travailler sur Python).
Un autre obstacle à la vitesse de Python est Python 3. Son adoption semble être la principale préoccupation des développeurs du langage, au point qu'ils ont gelé le développement de nouvelles fonctionnalités du langage jusqu'à ce que les autres implémentations rattrapent leur retard.
En ce qui concerne les détails techniques, je ne connais pas bien Ruby, mais Python comporte un certain nombre d'endroits où des optimisations pourraient être utilisées (et Unladen Swallow, un projet de Google, avait commencé à les mettre en œuvre avant de mordre la poussière). Voici quelques-unes des optimisations qu'ils ont prévues . Je pourrais voir Python gagner en vitesse V8 dans le futur si un JIT à la PyPy est implémenté pour CPython, mais cela ne semble pas probable pour les années à venir (l'objectif actuel est l'adoption de Python 3, pas un JIT).
Nombreux sont ceux qui pensent que Ruby et Python auraient tout à gagner à retirer leur logo respectif. verrouillages globaux de l'interprète .
Vous devez également comprendre que Python et Ruby sont tous deux des langages beaucoup plus lourds que JS - ils offrent beaucoup plus de bibliothèque standard, de fonctionnalités de langage et de structure. Le système de classes de l'orientation objet ajoute à lui seul un poids considérable (dans le bon sens, je pense). Je pense presque que Javascript est un langage conçu pour être intégré, comme Lua (et à bien des égards, ils sont similaires). Ruby et Python ont un ensemble de fonctionnalités beaucoup plus riche, et cette expressivité se fait généralement au détriment de la vitesse.
Les performances ne semblent pas être une préoccupation majeure des principaux développeurs de Python, qui semblent estimer que "assez rapide" est suffisant, et que les fonctionnalités qui aident les programmeurs à être plus productifs sont plus importantes que celles qui aident les ordinateurs à exécuter le code plus rapidement.
En effet, il existait un projet Google (aujourd'hui abandonné), unladen-swallow pour produire un interpréteur Python plus rapide et compatible avec l'interpréteur standard. PyPy est un autre projet qui vise à produire un Python plus rapide. Il existe également Psyco le précurseur de PyPy, qui permet d'améliorer les performances de nombreux scripts Python sans modifier l'ensemble de l'interpréteur et Cython qui vous permet d'écrire des bibliothèques C performantes pour Python en utilisant une syntaxe très proche de celle de Python.
Question trompeuse. V8 est une implémentation JIT (un compilateur juste à temps) de JavaScript et dans son implémentation non-browser la plus populaire, Node.js, il est construit autour d'une boucle d'événement. CPython n'est pas un JIT et n'est pas événementiel. Mais ceux-ci existent en Python, le plus souvent dans le projet PyPy - un JIT compatible avec CPython 2.7 (et bientôt 3.0+). Et il existe de nombreuses bibliothèques de serveurs événementiels comme Tornado par exemple. Il existe des tests en conditions réelles entre PyPy et Tornado par rapport à Node.js et les différences de performances sont légères.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
