Arrivée de TraceMonkey dans Minefield en 64 bits !

Ce moteur de compilation jit du langage javascript intégré dans Mozilla Firefox depuis sa version 3.5 n’existe pas pour les versions 64 bits (linux et MacOS-X, quand à Windows 64bits, je ne saurais dire) du navigateur.

Cependant, en lisant ce billet dans mon agrégateur de flux j’ai appris que le moteur de compilation est enfin activé. Mais uniquement dans le code du tronc, qui donnera le successeur de Namoroka (alias Mozilla Firefox 3.6) et donc qui ne sortira que d’ici un gros semestre et demi, si on en croit la feuille de route prévisionnelle :

  • Mozilla Firefox 3.6 alias Namoroka : fin 2009
  • Mozilla Firefox 3.7 alias ? : D’ici juin 2010
  • Mozilla Firefox 4.0 alias ? : D’ici fin 2010

Il a d’abord été intégré dans la branche tracemonkey, et un peu plus récemment dans le code même du tronc qui donnera Mozilla Firefox 3.7, si on en croit ce rapport d’ajout de code.

Bref, le moteur de compilation du javascript de Mozilla Firefox pour les versions 64 bits du logiciel (même s’il n’y a pas de version officielle, sauf celle des distributions linux en version 64 bits) profiteront d’une version dopée du rendu javascript comme c’est déjà le cas pour les version 32 bits (Windows, linux, MacOS-X et compagnie).

Ayant mis à jour ma copie du code source du tronc, j’ai lancé une compilation avec le .mozconfig suivant :


export AUTOCONF=autoconf-2.13
. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --disable-tests

Après, il faut attendre 45 minutes après avoir entré la commande « magique » : make -f client.mk build

Pour comparer, j’ai pris une compilation plus ancienne – en 64 bits – de Minefield qui n’a pas TraceMonkey activé. On peut trouver la dite compilation à l’adresse :

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009-09-16-03-mozilla-central/

Adresse qui ne sera surement plus valide d’ici le mois d’octobre 2009, cependant.

Pour voir le gain de vitesse apporté par le moteur de compilation, je me base sur le site de test SunSpider, sur celui de Celtic Kane.

Pour SunSpider :

Sans TraceMonkey : 5944 ms.

Avec TraceMonkey : 2860 ms… Soit environ 51,88% plus rapide… C’est pas si mal 😉

Pour Celtic Kane :

Sans TraceMonkey : 547

Avec TraceMonkey : 488 ; soit environ 10,94% plus rapide.

Je pense faire un prochain test avec le moteur webkit (via Arora) et avec la version 10 d’Opera en 64 bits aussi.

Sortie de Mozilla Firefox 3.5.1.

Suite à la publication d’un code exploitant une faille dans le moteur de compilation du Javascript TraceMonkey, la Fondation Mozilla sort une version corrigé du navigateur internet.

Il suffira d’attendre la mise à jour automatique (ou de la forcer) – sur MacOS-X et MS-Windows ou encore d’attendre la mise à jour des dépots de votre distribution linux.

Notes de publications de cette version corrigée :

http://www.mozilla-europe.org/fr/firefox/3.5.1/releasenotes/

Bon téléchargement.

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 😉