Le blog d'un internaute aimant l'informatique libre, la musique et la rétro-informatique !
Article complémentaire du précédent pour les autres navigateurs du marché. Voici que ce que j’ai obtenu :
Continuer la lecture de « Benchmark v8 pour les autres navigateurs. »
Derrière ce titre à rime se base un petit test – qui sert à rien, voila c’est dit pour les ronchons – qui est dérivé d’un propos que j’avais lu il y a environ 2 semaines sur Clubic.
Pour tout dire, l’article qui parlait de la sortie de la 5ième et ultime béta de Mozilla Firefox 3.6 avait un lien vers l’entretien, donc cela m’a rafraîchit un peu la mémoire 😉
C’est surtout ce petit paragraphe qui m’a mis interpellé :
Quels ont été les récent travaux effectués sur le moteur JavaScript TraceMonkey ?
MB : Nous avons opéré deux types de travaux. D’une part la technologie de TraceMonkey a été portée sur mobile. Plusieurs personnes l’ont essayé sur le N900 et ont été très impressionnées par ses capacités. Par ailleurs nous avons affiné TraceMonkey afin qu’il se révèle plus performant pour un usage de tous les jours. Aujourd’hui au travers de plusieurs tests, il apparaît que le moteur JavaScript de Firefox 3.6 est 20% plus rapide qu’au sein de Firefox 3.5. Cependant cela ne reflète pas pour autant les performances réelles observées par les utilisateurs dans leur surf quotidien.
Donc, j’ai pour vérifier cette information récupéré via le site ftp http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/, 3 versions de développement en linux 64 bits :
Une pour Mozilla Firefox pré 3.5.7, la deuxième pour Mozilla Firefox pré 3.6 béta 6, et enfin, une version pour Mozilla Firefox 3.7 pré-alpha1, et je leur ai fait passé ce qui est le test « ultime » des moteurs de Javascript : le « benchmark v8« .
Continuer la lecture de « Pas de langue de bois… Au moins chez Mozilla 😉 »
Dans cet article à la c**, j’ai voulu « comparer » d’une Fedora 11 (installée depuis un live CD) et d’une ArchLinux. Toute deux à jour au moment de la rédaction de cet article.
Pour les deux, j’ai utilisé localepurge, histoire de virer les traductions inutiles. Même si pour la Fedora, l’outil localepurge ne semble pas exister en natif et demande une manipulation un peu ennuyeuse.
Pour les deux, j’ai aussi vidé les caches.
Pour les deux, j’ai utilisé KVM (1 GiO de mémoire vive dédié, disque de 32 GiO pour chacune).
Donc, pour la Fedora 11 :
fred ~/download $ qemu-img create -f qcow2 disk.img 32G
Formatting 'disk.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred ~/download $ qemu-kvm -m 1024 -k fr -localtime -hda disk.img -soundhw all -cdrom Fedora-11-x86_64-Live.iso -boot d &
Et pour la ArchLinux :
fred ~/download $ qemu-img create -f qcow2 disk2.img 32G
Formatting 'disk2.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0
fred ~/download $ qemu-kvm -m 1024 -k fr -localtime -hda disk2.img -soundhw all -cdrom archlinux-2009.08-alpha-core-x86_64.iso -boot d &
Pour reproduire autant que possible à l’identique l’environnement installé par la version live de la Fedora 11, j’ai rajouté sur le Gnome fraichement installé :
Et j’ai enlevé :
Si les deux distributions se ressemblent franchement coté équipement logiciel (noyau 2.6.29.5 pour la Fedora 11, noyau 2.6.30.2 pour la ArchLinux), la Fedora prend le dessus en ce qui concerne l’occupation disque : 2 GiO seulement.
Mais si on regarde la mémoire vive prise, c’est la ArchLinux qui prend le dessus : 190 MiO contre environ 250 MiO pour la Fedora 11…
Fedora a un avantage : elle s’installe rapidement, même si parfois on a plusieurs dizaines de MiO de mise à jour à effectuer.
ArchLinux est plus longue à configurer, mais son empreinte mémoire est moins prononcée…
Et un mélange des deux mondes, c’est possible ? 😉
C’est ce que pourrait faire penser le score « catastrophique » de la future version de Microsoft Internet Explorer, la 8.0.
Or, les technologies testées sont assez vieilles pour l’immense majorité. En effet, sont testés le niveau de compatibilité des technologies suivantes :
Donc, si l’on regarde bien, la grande majorité des technologies testées ont au maximum 8 à 9 ans d’age…
C’est peut-être ici qu’il faut trouver l’explication pour le « si bon » score de Netscape 7.0.2, basé sur Gecko 1.0.2. Tout simplement que depuis le début du développement de Gecko (1999, donc déjà 10 ans), l’accent est mis sur les normes ouvertes édictées par le W3C.
Enfin, je ne prétends pas être un expert dans le domaine des normes du W3C, mais simplement une personne qui observe les résultats obtenus.
Du moins sur le plan du supports des normes définies internationalement par le W3C dont Microsoft est membre.
Dans mon précédent article, j’ai été estomaqué de voir que Netscape 7.0.1 avait un meilleur score que Microsoft Internet Explorer 8.0 alors que les deux logiciels sortent avec 7 années d’écart.
J’ai donc voulu vérifier une nouvelle fois, mais j’ai utilisé la vénérable distribution linux Slackware 9.0 (sortie en 2003) pour valider les résultats précédemment obtenus. J’ai récupéré l’ISO de cette distribution (noyau linux 2.4.20) sur un miroir, puis je l’ai installé dans une machine virtuelle VirtualBox.
Pour des raisons de légèreté, j’ai utilisé WindowMaker comme gestionnaire de fenêtres, puis j’ai lancé Netscape 7.0.2 et demandé l’affichage du test Acid3. Résultat sans appel : 36 / 100.
Que la version 8.0 de Microsoft Internet Explorer soit améliorée, cela ne fait aucun doute. Mais combien de temps faudra-t-il pour que certaines vieilles technologies soient enfin implémenté dans le navigateur majoritairement utilisé sur la toile ?
La première – et unique ? – version RC de Microsoft Internet Explorer 8 est sortie récemment. J’ai voulu voir quel était le degré de support des technologies récentes (en clair, moins de 5 ans) du navigateur phare de Microsoft.
Le test acid3 est donc un bon indicateur même s’il est un peu étrange. Score sans appel : 20 / 100.
En septembre dernier, j’annonçais que Mozilla Firefox (sorti en novembre 2004) obtenait déjà un meilleur score : 35 / 100. Ce qui fait déjà un retard technique de 4 ans et demi environ.
Mais le clou est encore plus enfoncé par le passage du test sous Netscape 7.0.1. Cette version téléchargeable en anglais sur le site http://www.oldversion.com/ fait très mal…
J’avoue en être tombé sur le c** en le lisant : 36 / 100 !!! Oui, 36 tests pour un navigateur basé sur Gecko 1.0.2 (donc en novembre 2002)… Ce qui fait un retard technologique sur certains plans pour Microsoft Internet Explorer 8 de… 6 ans et quelques mois.
Il est certain qu’intégrer un filtre anti-hameçonnage, des onglets, un mode de navigation privé est important. Mais avoir un moteur qui affiche des technologies récentes est tout aussi important.
Si vous croyez que je raconte n’importe quoi ou que j’ai fait du photomontage, libre à vous de vérifier la véracité du test sous Netscape 7.0.1.
N’ayant plus parlé du test acid3 pour les versions de développement de Mozilla Firefox depuis le 15 octobre dernier, j’ai voulu faire un point après l’arrivée du correctif qui introduit le support du langage SMIL.
Bien qu’il faille rajouter la ligne : ac_add_options --enable-smil le temps que le bogue 473705 soit corrigé, le résultat est proche des 100 / 100 tant recherché.
Une nouvelle mode virale court sur les blogs anglophones. Au tour des blogs francophones.
Les 7 « victimes » :
Décidement, le test Acid3 est de plus en plus supporté par Shiretoko. Avec la fermeture du bogue 302775, il ne reste plus que 7 petits points à récolter…
Le test sera-t-il complètement passé avec la version finale de Shiretoko ? Cela serait étonnant, au moins, on ne pourra pas dire qu’entre Mozilla Firefox 3.0 et son successeur Shiretoko, les modifications se seront limitées à la façade…
Et dire qu’il y a moins de 72 heures, j’annonçais 90 / 100 comme niveau de passage du test Acid3…
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 » ? »