javascript – Le Weblog de Frederic Bezies

La guerre du JavaScript aura bien lieu…

Dans le petit monde des navigateurs, la guerre est désormais passé à celle de la vitesse d’interprétation du Javascript. En plus de la guerre des respects des standards, qui sera surement le sujet d’un autre article.

J’ai donc pris les grands noms des navigateurs multiplateformes à savoir Chromium (coeur de Google Chrome), Mozilla Firefox et Opera.

J’ai testé la dernière version stable et la dernière version de développement disponible.

A savoir : Chromium 6 et 7 pre, Mozilla Firefox 3.6.9 et 4.0 beta6pre, Opera 10.62 et 10.70pre.

Les deux tests utilisés ont été SunSpider 0.9.1 et v8 Benchmark v5.

Continuer la lecture de « La guerre du JavaScript aura bien lieu… »

Compilons la version améliorée de Mozilla Firefox 4.0 pré-beta 6…

Ayant lu un article sur OSNews sur Mozilla qui a annoncé la disponibilité d’une version de test avec le moteur de compilation à la volée de Javascript, j’ai voulu faire compiler la version par moi-même, j’ai récupéré le code source correspondant :

[fred@fredo-arch fox]$ hg clone http://hg.mozilla.org/tracemonkey/ src/

Et ensuite, j’ai utilisé le .mozconfig suivant :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf-2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize
ac_add_options –disable-debug
ac_add_options –disable-tests
ac_add_options –with-ccache

Une fois la version disponible, j’ai comparé la version « classique » compilé ce matin, et la nouvelle version disponible.

Version classique : 1153 points

Version expérimentale : 1723 points soit 49,43% de plus.

Evidemment, on est loin de Google Chrome qui dépasse largement ce score – 5289 points environ – mais il y a du progrès 🙂

La suite au prochain épisode 😉

v8 ou Nitro… Lequel des deux est le plus rapide et le plus respectueux de JavaScript et de ses normes ?

Dans un article récent, je parlais du progrès fait par la pré-beta5 de Mozilla Firefox 4.0, alias Minefield.

J’ai voulu voir où en était les deux autres grands noms des moteurs de rendu du logiciel libre, à savoir Chromium (et son moteur de Javascript v8), et Webkit (et son moteur de Javascript Nitro).

J’ai donc fait compilé les deux via AUR, aussi bien pour chromium-browser-svn et webkitgtk-svn. En sachant que pour le second, je ne l’ai pas installé, histoire d’éviter des conflits avec les logiciels de ma machine.

La compilation du code source de Chromium demande pas mal d’espace… 4,5 Go environ…

[fred@fredo-arch chromium-browser-svn]$ pwd /home/fred/download/chromium-browser-svn [fred@fredo-arch chromium-browser-svn]$ du -sh src/ 4,5G src/

Webkit est quant à lui, largement moins gourmand : à peine 720 Mo.

[fred@fredo-arch webkitgtk-svn]$ pwd /home/fred/download/webkitgtk-svn [fred@fredo-arch webkitgtk-svn]$ du -sh src/ 722M src/

Une fois les deux logiciels compilés, j’ai utilisé v8 benchmark, sputnik (pour vérifier le niveau de compatibilité avec les normes définies du langage javascript), et html5test, pour finir, histoire de voir le niveau d’avancement de ce nouveau standard du langage html.

Chromium, qui se définit comme une version 7.0.501 (7ième version, déjà, en l’espace de quoi, deux ans ?), explose largement le score au niveau du Javascript… 4961 points, soit 4,45 fois plus rapide que Mozilla Firefox 4.0b5pre… Autant dire que la Fondation Mozilla a de la marge.

Coté respect des normes javascript, le score est plutôt bon : 5109/5246, soit un niveau de respect de… 97,38%.

Enfin, en ce qui concerne html5test, Chromium fait mieux que Mozilla Firefox, avec un score de 222 points et 10 points de bonus.

En ce qui concerne Webkit, j’ai utilisé l’outil GtkLauncher, qui offre une interface basique pour Webkit.

[fred@fredo-arch Programs]$ pwd /homefred/download/webkitgtk-svn/src/webkit-build/Programs [fred@fredo-arch Programs]$ ./GtkLauncher &

Le score du moteur de Javascript bien que moindre que celui de v8 reste honorable : 2984 points au benchmark v8, soit 2,67 fois le score de Mozilla Firefox 4.0b5pre. On comprend pourquoi la Fondation Mozilla veut intégrer Nitro dans son code source 😉

Coté sputnik, le score est vraiment bon : 5069/5246, soit un niveau de respect de 96,62%

Enfin, en ce qui concerne html5, le score est inférieur à celui de Mozilla Firefox et de Chromium, avec seulement 195 points et 12 points de bonus.

J’allais oublier, le score de Mozilla Firefox 4.0b5pre pour sputnik : 4978/5246, soit un niveau de respect de 94,89%

Mis à part la vitesse d’exécution, le respect du html5 et des normes javascript sont une marque de fabrique de moteurs de rendu libre. Les moteurs de rendus non-libre ? Je ne saurais dire, je ne les utilise pas 😉

Un coup d’oeil rapide à la pré-alpha5 de Mozilla Firefox Developer Preview

Utilisant quotidiennement les versions de développement de Mozilla Firefox, j’ai voulu montrer un aperçu de ce que donnera l’alpha5 de Mozilla Firefox Developper Preview.

Une nouveauté intéressante : un gestionnaire d’extensions directement dans le navigateur, via l’adresse : about:addons

Le coeur javascript est aussi beaucoup plus rapide que celui de Mozilla Firefox 3.6.x, même si ce n’est pas encore des scores dopés à l’epo… Voici les résultats pour le test v8 de Google.

Bien entendu, il y a des dizaines de modifications au niveau du code source, une implémentation croissante de html5, les greffons qui ne plantent plus le navigateur et d’autres petites joyeusetés. Mais ce qui sera le plus visible, c’est encore un gestionnaire d’extensions de ce style, ou encore un JavaScript à la vitesse améliorée.

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.

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 ? »