Du ruby dans vos pages web
Par Laurentj le mardi, avril 8 2008, 18:25 - Technologies Web - Lien permanent
Via John Resig, (Monsieur "jQuery"), j'ai découvert HotRuby qui est un projet permettant d'exécuter du ruby dans une page web.
Voici comment ça fonctionne
- inclure les fichiers js de hotruby
- mettre son code ruby dans une balise
<script type="text/ruby"></script> - Ce code est envoyé sur un serveur via
xmlHttpRequest, et en réponse, le serveur renvoi une structure en javascript qui correspond à du bytecode Ruby - Ce bytecode est alors executé par une VM programmée en javascript (la VM de HotRuby donc)
- Pour les détails, voir le billet de John
Et voila :-) Astucieux non ?
Alors pour l'anecdote, il faut savoir que cette VM en javascript exécute le bytecode de Ruby 5 fois plus vite dans Firefox 3.0 que la VM native de Ruby ! Une VM en javascript qui exécute plus vite qu'une VM codée en C, c'est impressionnant !
Mozilla 2 (Firefox 4), comportera une machine virtuelle pour Javascript 2 (projet Tamarin, à partir de la VM libérée par Adobe). Ainsi, le javascript des pages web sera converti en bytecode pour Tamarin, avant d'être exécute par Tamarin. Supposons maintenant que par l'intermédiaire d'une extension, on puisse installer un compilateur d'un langage X qui génère du bytecode pour Tamarin, et donc qu'on puisse ensuite faire <script type="text/ruby"></script> ou <script type="text/python"></script>. On n'aurait plus besoin de passer par cette étape de xmlHttpRequest, donc par un compilateur exterieur :-)
Bon, je rêve, pas dis que ce sera faisable dans Firefox 4, mais à mon avis, il manquera peu pour que ça puisse exister :-) Quoique, c'est peut-être le but de IronMonkey... Je n'ai pas vraiment compris l'objectif de IronMonkey mais je crois qu'il s'agit de porter IronRuby et IronPython pour qu'ils génèrent du bytecode pour tamarin...
Commentaires
Très sympathique comme approche, on peut imaginer faire plein d'autres choses rigolotes comme un interprêteur de n'importe quel langage...
Par contre le benchmark tire sévèrement parti de la faiblesse du GC de Ruby. Il suffit de tester n'importe quoi qui ne génère pas 50000 objets temporaires pour voir que l'argument "plus rapide que la VM de Ruby !" ne tient pas. Par exemple, en faisant looper leur test de Hash 50000 fois (en remplaçant les puts par des assignations histoire de ne pas avoir 50000 lignes en retour), on trouve que Ruby 1.8 met 0,3s et HotRuby 10 secondes (Firefox 3b5, OSX). Très loin du fanfaron "78% faster"
Laurent, relis bien le post de John Resig, l'exécution dans Firefox 3 est 5 fois plus rapide que Ruby 1.8.2, pas la VM Ruby.
Il s'agit ici de comparer l'interpréteur Ruby 1.8 à Firefox exécutant le bytecode Ruby 1.9 grâce à JS. Ce qui implique que toutes les optimisations de code ont déjà été faite par le compilateur.
Je doute sincèrement que cette couche d'abstraction supplémentaire puisse rivaliser avec la VM Ruby 1.9 puisqu'il s'agit d'une surcouche à cette VM.
Enfin, le test de John Resig ne tient pas compte du temps de communication avec le serveur.
Le but d'IronMonkey est bien là!!! pouvoir ensuite utiliser du Pythonou du ruby dans une page Web!
Alors moi je trouve l'idée vraiment géniale... mais je connais pô le ruby :/ Va falloir que je m'y mette :p
@vincent : tu n'a pas fait attention à un truc. Le temps calculé, il est fait par le script ruby lui même. Ce qui veut dire que ce temps n'inclus pas le temps de compilation de ruby, que ce soit avec hotruby ou par ruby 1.9 en ligne de commande. Bref, c'est bien les performances des VM qui sont comparées, dans tous les cas.
HotRuby n'est pas une surcouche à une VM, c'est une VM.
@reluc : ok, on a compris la même chose alors :-)
Je n'ai pas été assez clair, désolé.
Ruby 1.8.2 n'est pas une VM, c'est un interpréteur. Il n'y a donc pas de phases d'optimisation du code comme il pourrait y avoir dans une compilation en bytecode puis exécution sur une VM.
Une exécution sur Ruby 1.8.2 va donc commencer le profiling avant d'avoir une forme optimisée du script, ce qui explique ce temps d'exécution lent.
Dans le cas de l'exécution sur Firefox, au moment où le script démarre, il est déjà sous une forme optimisée que Ruby 1.9 a compilé en bytecode. Ceci explique pourquoi l'exécution est plus rapide que Ruby 1.8.2, que ce soit sur Firefox 2 ou Firefox 3.
En fait, ça revient à comparer Ruby 1.9 et Ruby 1.8.2. Le fait que la VM soit en JS ou en C ne change rien au fait que c'est une VM et qu'elle sera toujours beaucoup plus rapide qu'un interpréteur.
Une comparaison intéressante aurait été de connaitre le ratio entre HotRuby et Ruby 1.9 pour avoir une vrai comparaison entre une VM en JS et une VM en C.
ok, je ne savais pas que Ruby 1.8 n'était pas une VM.
Cependant, tu noteras que le benchmark affiche bien un résultat avec Ruby 1.9, et pas 1.8.2 comme sur le site de john (je ne sais pas pourquoi il a 1.8.2, peut être que dans le bench ils ont mise à jour ruby)
Donc la comparaison intéressante dont tu parles, existe presque ;-) D'ailleurs, il suffit que tu installes ruby 1.9 sur ta machine, que tu exécute le script, et que tu compares avec ce que tu obtient dans ton firefox.
En tout cas, il y a vraiment de gros progrès en perf entre FF2 et FF3 : ça passe de 8.67 à 3.33 sur ma machine :-)
Pour l'histoire de Tamarin, il aurait été plus intelligent de réutiliser un format de bytecode existant (le truc de GCC, le truc de LLVM, le machin .NET, parrot, ...) plutôt que dans créer un autre (ABC) spécifique à Tamarin... Cela aurait en effet permis de plugguer tout un tas de langages trivialement.
@loufoque : avec Tamarin, ils ne réinventent rien. Le coeur de tamarin est utilisé depuis longtemps dans le plugin flash, c'est à dire sur plus de 90% des ordinateurs desktop reliés à internet. Autant dire qu'il a été largement éprouvé et montré sa stabilité. De plus, c'est pas dit que les bytecodes des autres VM soient "optimisés" pour un langage comme javascript.
Ensuite ces autres VM ne sont peut-être pas aussi légères que Tamarin (plusieurs méga pour LLVM alors bon...). Et puis entre les problèmes de brevets potentiels de CLR (Microsoft oblige), le peu de maturité de parrot etc. finalement Tamarin est certainement le mieux adapté pour l'usage auquel il est déstiné...