SquirrelFish extreme, le moteur javascript « dopé à l’EPO » ?

Récemment annoncé sur le blog des développeurs de Webkit, cette nouvelle version du moteur Javascript est encore plus rapide.

Bien qu’officiellement encore limité au 32 bits, je cite « Currently the code is limited to x86 32-bit, but we plan to refactor and add support for more CPU architectures. », « Actuellement le code est limité à du 32 bits en x86, mais nous comptons le refactoriser et ajouter plus d’architectures de microprocesseurs« , les gains sont déjà visibles.

Continuer la lecture de « SquirrelFish extreme, le moteur javascript « dopé à l’EPO » ? »

Concours de vitesse en javascript…

Dans un précédent billet, je parlais de l’impact de TraceMonkey sur les tests concernant la vitesse d’exécution de Javascript. J’ai donc voulu tester les performances de Firefox 3.0.1, Shiretoko pré-bêta1, Opera 9.60 bêta et du dernier Webkit en date sur les tests proposés par Google pour le moteur de javascript V8 qui équipe Google Chrome.

La lecture du résultat est simple. Avoir 100 comme score est la base. Plus le score est important, mieux c’est.

Continuer la lecture de « Concours de vitesse en javascript… »

Quel est l’impact de TraceMonkey ?

Je parlais dans un billet il y a une grosse semaine de l’arrivée du compilateur JIT pour le module javascript de Shiretoko du doux nom de TraceMonkey.

J’ai voulu voir le gain de vitesse pure en terme d’interprétation de javascript. Pour cela j’ai utiliser SunSpider, et différents navigateurs, à savoir Firefox 3.0.1, une pré-béta1 de Shiretoko compilée maison en suivant les options officielles de compilation.

A titre de comparaison, j’ai aussi testé Opera 9.52 et une nouvelle préversion d’Opera 9.60 qui sortira d’ici quelques semaines, et peut-être un peu avant Shiretoko prévu pour le début 2009.

Continuer la lecture de « Quel est l’impact de TraceMonkey ? »

Tracemonkey has landed.

Derrière ce détournement d’une phrase célèbre prononcée en 1969 – wikipedia est votre ami – le compilateur JIT pour le module javascript que j’évoquais hier vient d’arriver sur le code de développement du tronc de Shiretoko, dont la version alpha2 est prévue pour bientôt.

En effet, ce matin, réveillé à 4 h 30 par mon chiot labrador de 9 mois, j’ai allumé l’ordinateur tout en sirotant mon thé. Et après le duo habituel hg --verbose pull ; hg --verbose update pour mettre à jour le code source, j’ai pu lire ceci :


pulling from http://hg.mozilla.org/mozilla-central/
searching for changes
adding changesets
adding manifests
adding file changes
added 1167 changesets with 2340 changes to 146 files

Quoique l’arrivée du code n’est pas encore super bonne. Après une tentative de compilation avortée, j’ai viré le répertoire de compilation, et relancé la dite compilation. Mais il semble y avoir un léger problème au niveau du fichier libxul.so… 🙁


../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): In function `nsCanvasRenderingContext2D::PutImageData()':
nsCanvasRenderingContext2D.cpp:(.text+0x4165): undefined reference to `js_ArrayToJSUint8Buffer'
/usr/bin/ld: ../../staticlib/components/libgklayout.a(nsCanvasRenderingContext2D.o): relocation R_X86_64_PC32 against `js_ArrayToJSUint8Buffer' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld a retourné 1 code d'état d'exécution
make[4]: *** [libxul.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx/toolkit/library »
make[3]: *** [libs_tier_toolkit] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[2]: *** [tier_toolkit] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/src/objdir-fx »
make: *** [build] Erreur 2

Bref, c’est pas encore cela… Je sens que je vais ouvrir un petit bogue malgré la tentative pour que la compilation se fasse en code 64 bits, si j’en crois cette révision rajoutée récemment


author David Anderson
Thu Aug 21 18:07:26 2008 -0700 (at Thu Aug 21 18:07:26 2008 -0700)
changeset 18331 7098e0020929
parent 18330 91fe6b5784bd
Fixed x86_64 build issue (accidentally trying to build 32-bit nanojit).

J’ai rapporté le bogue 451669. On verra bien 😉

Euh, après une petite recherche, il semblerait que le bogue 451242 soit responsable ici… Oups 😉

Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ?

Pour le savoir, il faut utiliser deux tests complémentaires : le test du site CelticKane et le test « SunSpider« .

Les versions testées sont :

  • une compilation nocturne de Shiretoko pré-alpha2 de ce 13 août matin => Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1a2pre) Gecko/20080813050659 Minefield/3.1a2pre
  • Une préversion d’Opera 9.52, cf ce billet du blog des développeurs d’Opera.
  • Webkit révision 35706, compilée ce matin, pour contourner le bogue 20370 qui rendait impossible la compilation de la version gtk.

Continuer la lecture de « Lequel est le plus rapide pour Javascript ? Webkit, Opera ou Gecko ? »