Journal Comparons les performances Javascript de Firefox et Chrome

Posté par (page perso) .
Tags : aucun
25
13
sept.
2010
Au moment de la sortie de Firefox 4 beta j'avais eu un peu de temps pour tester les performances javascript de cette nouvelle version et les comparer avec les versions stables de Firefox et de Chrome.
Benoit Jacob avait alors posté une réponse indiquant que tout le travail d'optimisation sur le javascript n'avait pas encore été intégré et qu'un test des performances de la beta n'avait pas beaucoup de sens.

15 jours plus tard (aujourd'hui donc) j'ai encore une petite heure devant moi, je ne suis pas trop motivé pour faire avancer la news du noyau 2.6.36 et j'ai donc décidé de refaire le test.
Évidemment cette fois je vais utiliser la nightly build de Firefox qui intègre les optimisations javascript. Pour les férus de technique ces optimisations sont liées au nouveau moteur JaegerMonkey qui complète le moteur existant TraceMonkey.

Sans plus attendre tournons nous vers les résultats du comparatif.

Hardware:

- ThinkPad T400
- Intel Core 2 Duo 2.26 GHz
- 2 Go de RAM

Versions des logiciels:

- Firefox 3.6.9 (version stable)
- Firefox 4 b6pre (version nightly build)
- Chrome 6.0.472.55 (version stable)
- Chrome 7.0.517 (version de dev)

Benchmarks:

- SunSpider => http://www2.webkit.org/perf/sunspider-0.9/sunspider.html
- V8 Benchmark v5 (attention ce bench est d'origine Google) => http://v8.googlecode.com/svn/data/benchmarks/v5/run.html
- Dromaeo Javascript (attention ce bench est d'origine Mozilla) => http://dromaeo.com/?dromaeo

Résultats:

SunSpider Firefox 3.6.9 (version stable) => 2192.6 ms
SunSpider Firefox 4 b6pre (version nightly build) => 1281.6 ms
SunSpider Chrome 6.0.472.55 (version stable) => 549.1 ms
SunSpider Chrome 7.0.503 (version de dev) => 699.2 ms

V8 Firefox 3.6.9 (version stable) => 496 points
V8 Firefox 4 b6pre (version nightly build) => 2164 points
V8 Chrome 6.0.472.55 (version stable) => 5117 points
V8 Chrome 7.0.503 (version de dev) => 4542 points

Dromaeo Firefox 3.6.9 (version stable) => 91.73 runs/s
Dromaeo Firefox 4 b6pre (version nightly build) => 322.92 runs/s
Dromaeo Chrome 6.0.472.55 (version stable) => 497.27 runs/s
Dromaeo Chrome 7.0.503 (version de dev) => 476.79 runs/s

Interprétation:

- L'écart de performances est considérable entre la version actuelle de Firefox et la future version 4. Joli progrès !
- Cette nighty Build est vraiment plus performante que la beta testée il y a 15 jours sur le bench V8 de Google (sur les 2 autres tests c'est moins probant).
- La version de développement de Chrome a des performances légèrement inférieures à la version stable.
- Chrome reste loin devant Firefox (du moins en ce qui concerne la rapidité de traitement du javascript).
  • # dev

    Posté par (page perso) . Évalué à 10.

    > La version de développement de Chrome a des performances légèrement inférieures à la version stable.
    souvent les versions de dev sont buildés avec des options de debug, qui ralentissent l'exécution
    • [^] # Re: dev

      Posté par . Évalué à 1.

      "defective by design"

      C'est juste qu'ils ont mis quelques boucles dans le vide pour ne pas trop humilier la concurrence.

      Mais on attend Chrome sur le support de l'accélération matérielle
      http://www.pcinpact.com/actu/news/59212-firefox-4-beta-5-nou(...)

      Ouppps pardon !
      • [^] # Re: dev

        Posté par (page perso) . Évalué à 4.

        Oui ... mais pour faire l'avocat du diable.

        Souvent (pour ne pas dire tout le temps), mozilla fait les annonces en premier ... Mais, c'est clairement chrome/chromium qui sort avant, avec le résultat et qui marche.

        C'était le cas pour les premiers gros support html5, la balise video, la synchro des bm/extensions, etc ...

        Je ne serai vraiment pas surpris, qu'on ait un chrome/chromium utilisant l'acceleration hardware avant une première release de FF4 ;-)
        • [^] # Re: dev

          Posté par . Évalué à 9.

          Qui marche ?

          Premier exemple qui me vient en tête, là :
          Essayes d'utiliser Chrome pour valider ta connection à FreeWifi : il n'y arrive pas, se vautre comme une bouse, et n'affiche jamais la page de connection. Supaire. Et au passage, la différence entre Chrome et Chromium, un exemple permettant de dire que Chromium ne sert à rien (si c'est pour avoir le même fonctionnement que Chrome, non merci) bref chromium c'est juste une recompilation de chrome (et moi qui croyais que certaines briques étaient virées, pas seulement celles pas libres éventuellement par rapport à chrome mais aussi celles qui concerne la vie privée). A un expert du code de Chromium de nous expliquer pourquoi le packaging dans les distro fait qu'on se retrouve en fait avec le même truc ...

          Lance Firefox, paf il comprend aussitôt ce qu'il se passe. D'ailleurs il réagit aussi illico à un changement système (genre un truc con d'utilisateur con : j'appuie sur la touche de coupure du wifi, firefox le voit illico quant chromium/chrome va ramer pendant 20 secondes avant de comprendre qu'il est hors ligne)

          Bref en plus des comparatifs purs, il y aussi la qualité d'intégration au système (oula je sens que certains vont hurler, je veux juste parler "à l'utilisation").

          Dommage que Firefox 4 ne soit pas utilisable sur gnu/linux, sinon je l'utiliserai ! (ai vu celui de monde frère sous windows : ouhaou !!) A la question "pourquoi pas utilisable" je répond par une autre question : pourquoi "firefox 4 beta execmemstack ?" moi je veux bien mettre un # devant user - core 0 pour mon utilisateur standard, sûr ça va m'aider à avoir des infos, okok, mais ça ne change rien directement, il me faudrait ensuite mettre en place une règle permissive spécialement pour lui, zut..."
          • [^] # Re: dev

            Posté par (page perso) . Évalué à 2.

            Comment ça Firefox 4 pas utilisable sous Linux ?

            DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: dev

              Posté par . Évalué à 8.

              s/gnu\/linux/fedora par défaut
              Avec SElinux activé, firefox 4 tel qu'il est livré (binaire) se fait envoyer bouler par SElinux pour cause de execmemstack. Alors bien sûr c'est de la faute à mon système, jaikapautilizé2truc2sécurité :)
          • [^] # Re: dev

            Posté par . Évalué à 3.

            >Dommage que Firefox 4 ne soit pas utilisable sur gnu/linux, sinon je l'utiliserai !

            Qu'est-ce que c'est que cette histoire de pas utilisable sous Linux ? Ca marche très bien, la preuve je l'utilise pour te répondre là !! :)
        • [^] # Re: dev

          Posté par . Évalué à 2.

          "moins technique" semble t il que les démos vidéos de la MoFo, mais sacrémanet bien réalisé, et surtout c'est pas une démo vidéo, mais vraiment le navigateur... : çapusaypoalibre, mais ça vaut le coup d'oeil (uniquement avec chrome/chromium) :
          http://www.thewildernessdowntown.com
          • [^] # Re: dev

            Posté par (page perso) . Évalué à 5.

            > mais ça vaut le coup d'oeil (uniquement avec chrome/chromium)

            Je viens de tester (avec firefox 4 beta sous GNU/Linux) sur un MSI pas du tout puissant ... ca fonctionne bien.
            • [^] # Re: dev

              Posté par . Évalué à 2.

              Marche aussi avec Iceweasel/3.5.12. Enfin, marchouille (aucun plantage, mais il me faudrait une demi-douzaine de CPU en plus, et certains chevauchements de fenêtres sont douteux).

              THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: dev

            Posté par (page perso) . Évalué à -1.

            http://www.thewildernessdowntown.com
            For the best viewing experience, we recommend downloading Google Chrome and trying this site again.


            C'est quoi ce truc ? On se croirait revenu à l'époque du "Optimisé pour IE uniquement" !?
            • [^] # Re: dev

              Posté par (page perso) . Évalué à 1.

              Cela dit, ça tourne avec un FF 3.6.9 sur GNU/Linux (Mandriva), très lentement, certes, mais c'est bel et bien impressionnant d'un point de vue créatif :)

              Je me prends à rêver d'un FF4 ou Chrome pour voir ce film interactif en vitesse réelle...
              • [^] # Re: dev

                Posté par . Évalué à 3.

                Cesses d'être pendu au bon vouloir d'un empaqueteur ! Libères toi !

                Et utilises le binaire de la Fondation Mozilla directement, si tu souhaites tester FireFox 4 beta. L'important c'est les Logiciels Libres, non la distribution. En plus tu fera plaisir à la MoFo, vu qu'ils "ralent" après le faible nombre de testeurs. Ils se décacarssent a fabriquer Firefox, et se décarcassent à nous filer un binaire fonctionnel (moyennant une règle en plus pour selinux chez ceux utilisant cette solution) et propre pour le systeme (tu peux le coller dans /opt par exemple, puis le lancer avec un simple " ./firefox -no-remote -ProfileManager " et hop :) :) :)

                Tout comme pour Chrome, ou tu peux prendre le rpm de Google, il fonctionne sans problème sur ta mandriva (moyennant l'install des dépendances, bien sûr)

                /mode trol off/ (tiens ça vaut bien un petit texte sur "l'utilisation des logiciels libres par les distributions, le pouvoir, l'utilisateur, le système" qui pourrait même compléter le fameux howto "comment détruire une communauté en 10 points", peut être, peut être... en fait juste une mise en valeur du point numéro 1 : "Rendez le projet dépendant d’outils complexes" ...
                • [^] # Re: dev

                  Posté par . Évalué à 1.

                  Mais bon, j'vais attendre vendredi avant de pondre une telle connerie :)
  • # performances légèrement inférieures à la version stable

    Posté par . Évalué à 5.

    Peut-être est-ce dû à des symboles de debug ou autre trucs du même genre.

    Est-ce que ce sont des versions de développement pré-compilées ou tu l'as fais toi-même ?
  • # 32 ou 64 bits?

    Posté par . Évalué à 3.

    Tel est la question?
    • [^] # Re: 32 ou 64 bits?

      Posté par (page perso) . Évalué à 2.

      c'est son portable du boulot iirc donc 32 bits ;-)

      non l'important, c'est quelle distribution ? (et là, c'est le drame :D)
      • [^] # Re: 32 ou 64 bits?

        Posté par (page perso) . Évalué à 3.

        >>> non l'important, c'est quelle distribution ? (et là, c'est le drame :D)

        Impossible de tester chez moi sur mon laptop sous Hardy 8.04.....Y'a qu'au boulot que j'ai une heure à perdre ;-)
    • [^] # Re: 32 ou 64 bits?

      Posté par (page perso) . Évalué à 3.

      32 bits (WinXP SP3 du boulot).
      Mais bon ce ne sont pas les perfs absolues qui comptent. Je crois que ce qui est le plus intéressant ce sont les performances relatives entre les 4 navigateurs testés.
      • [^] # Re: 32 ou 64 bits?

        Posté par . Évalué à 8.

        Il serait intéressant d'effectuer ce test sur une même machine avec Linux et Windows pour voir.
        Encore mieux, le faire aussi entre le 32 et le 64 bits.

        T'as pas 15 ou 20 heures à tuer des fois?
  • # Trop cool... Mais quel intérêt ?

    Posté par . Évalué à 7.

    C'est bien mignon de voir les navigateurs se bouffer le nez sur des pouillèmes de secondes sur des benchmarks JavaScript, mais ça change quoi ?
    Ça sert à quoi ?
    Quand on voit les performances graphiques de Firefox ou Chrome, ils feraient mieux d'arrêter de se bagarrer sur le JS et de passer aux autres problèmes. Ça tombe bien, ils commencent à le faire, mais il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
    Il y a quelques temps, j'avais pour rire testé un ou deux benchmarks de microsoft à la fois sur firefox, arora et konqueror (KHTML). Le vainqueur du benchmark fut .... konqueror, pour ses performances graphiques au dessus de celles de firefox et d'arora.
    J'espère que l'utilisation de l'OpenGL dans Firefox fera avancer les choses.
    • [^] # Re: Trop cool... Mais quel intérêt ?

      Posté par (page perso) . Évalué à 10.

      C'est une vraie bonne question. D'ailleurs, même nos devs se la pose.

      Par exemple, pour avoir un meilleur résultat sur SunSpider, on a du se prendre la tete sur la gestion des dates et sa gestion du daylight (rien de critique niveau perf ici).

      Donc la compétition, c'est bien, mais de temps en temps, ça a des conséquences absurdes.

      > il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.

      Oui, on est trop bête :) On avait oublié.

      1. les gens qui font JS ne sont pas les mêmes qui font GFX
      2. utilisé XRender sous Linux, c'est arrivé bien avant la versoin 4 (Fx 2 je crois)
      3. OpenGL c'est juste le compositing, ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer (ou alors on fait comme Chrome, on utilise pas les libs du systems, et on fait tout à la main)
      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par . Évalué à 4.

        Oui, on est trop bête :) On avait oublié.
        C'est pas ce que j'ai dit, c'est juste que c'est "à la mode" que depuis que Microsoft en parle finalement, avant, à part quand y'a eu le support de cairo dans mozilla, j'ai pas souvenir d'avoir entendu parler d'accélération graphique.
        Et si y'a déjà de l'accélération graphique dans Firefox sous Linux actuellement, ça veut dire qu'elle est largement défaillante vu que Konqueror ne fait aucun effort particulier là dessus et a des performances graphiques supérieures...
        (NB: Chrome est pas mieux que Firefox pour les perfs graphiques sous Linux)
      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par . Évalué à 3.

        Bah, tiens, vu qu'on a développeur de Firefox sous la main....
        Peut tu nous dire, si le support de Direct2D sera rétroporté sur la version officielle de Cairo 1.10?
        Est-ce que justement, le nouveau Backend OpenGL de Cairo ne fait pas un peu plus que permettre le compositing, mais aussi d'accélérer le rendu 2D comme pour Direct2D?
        Vu que des drivers Gallium3D sous linux commencent à être utilisables et qu'il y a un support (certes encore incomplet) d'OpenVG, y aura il moyen d'activer ce dernier aussi sous linux? vu que cairo supporte aussi OpenVG...
      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par (page perso) . Évalué à 4.

        Je crois que le vrai truc important pour les utilisateurs de Firefox c'est que l'interface ne se bloque plus en cas de charge CPU massive ou en cas d'opérations I/O intensives sur la machine.
        Je trouve que ça c'est vraiment exaspérant. Je suis connecté à mon disque dur USB, je lance une opération de copie assez lourde de mon laptop à mon disque dur et en attendant je surfe un peu...du moins j'essaye de surfer car en vérité toute l"interface de FF est bloquée.
        Là dessus Chrome/Chromium est bien plus performant.
        • [^] # Re: Trop cool... Mais quel intérêt ?

          Posté par . Évalué à 2.

          Le seul cas qui ressemble à ce que tu dis, c'est une erreur dans l'url qui doit apporter une erreur 404 qui ensuite renvoit sur une page google. La en général, cela bloque le navigateur le temps qu'il trouve l'info.

          Concernant le blocage dû au IOs, je croyais que c'était un problème d'abus de fsync() par SQL lite. Il me semblait que du boulot avait été fait dans ce sens sur Linux, pour que le fsync() passe en priorité sur les autres commandes et sur SQL lite pour diminuer l'usage de cette primitive.

          "La première sécurité est la liberté"

          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par (page perso) . Évalué à 3.

            Sur la version 3.6.8 de FF, j'ai des blocages quand je tappe du texte dans la barre d'url. Ca fait pas tout le temps, mais au moins une fois au démarrage et parfois par intermittence ensuite. Ca doit être le chargement des complétions qui est lent/pas fait en parallèle.
            C'est vrai que c'est le gros truc exaspérant qui me fait lorgner du côté de chromium.
          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par . Évalué à 2.

            Le seul cas qui ressemble à ce que tu dis, c'est une erreur dans l'url qui doit apporter une erreur 404 [...]

            Mouahahaha. Pas du tout. Des réponses DNS trop longues arrivent aussi à bloquer ff. Et j'en souffre régulièrement au boulot. Me souviens plus du bug, mais en gros ya des trucs bloquants qui sont faits dans un thread qui gère l'UI. Et donc c'est pas 1 onglet qui est bloqué, c'est *tout* ff. Genre http://forums.mozillazine.org/viewtopic.php?t=14442 .
        • [^] # Re: Trop cool... Mais quel intérêt ?

          Posté par (page perso) . Évalué à 2.

          Parfois le gain de perf en affichage est spectaculaire. Par exemple sur la page suivante:

          http://www.dannychoo.com/post/en/25789/Malaysian+Food.html

          (et toutes les galeries d'images de ce site), le défilement rame avec Firefox 3 (Linux amd64) alors que les navigateurs Webkit, Konqueror et Firefox 4 sont fluides. Parfois j'utilisais un de ces derniers rien que pour voir ce site.
          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par (page perso) . Évalué à 1.

            Chez moi, j'ai remarqué que la nouvelle recherche d'images chez Google.com (celle qui affiche les résultats sans pagination, rien qu'avec la barre de défilement vertical; je ne l'ai pas sur google.fr) rame chez moi sur mon Firefox 3.6. Avec Chromium out FF4 c'est nickel.
            Scénario parano: Google a fait ces modifs pour donner mauvaise réputation à leur concurrent.
            • [^] # Re: Trop cool... Mais quel intérêt ?

              Posté par . Évalué à 2.

              c'est une horreur ce truc... et j'ai pourtant un pc pas trop vieux. Je n'ose imaginer sur les netbook ou les vieux ordinausaures...

              En tout cas, j'ai été impressionné par la fluidité de FF4 en version beta (avant même l'optimisation js), sur des jeux en lignes qui utilisaient bcp js, pour des sites avec des effets graphiques un peu lourd, ou utilisant les effets d'arrondi et d'ombre html5, c'est bien réactif par rapport à FF 3.6

              Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par . Évalué à 4.

        OpenGL ... ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer.
        Eh ben, on est mort.
        • [^] # Re: Trop cool... Mais quel intérêt ?

          Posté par (page perso) . Évalué à 6.

          En tant qu'utilisateur des drivers libres pour ATI/AMD depuis un moment, je peux dire que ça s'améliore et que les développeurs font un travail formidable.

          DLFP >> PCInpact > Numerama >> LinuxFr.org

          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par . Évalué à 10.

            Oui.
            Nouveau fait tourner les jeux de 97. Encore 2 ans et il fera tourner warsow, encore 2 ans et on pourra activer le compositing. Entre temps, les desktop seront en opengl 3 voire plus donc ça merdera toujours.

            Les drivers ati sont tellement biens qu'on ne sait plus combien il y en a (2 ou 3 à l'heure actuelle? de libres, hein) ni quelles cartes ils supportent, ni de quelle qualité de support on parle puisque c'est variable par carte et par driver.

            Et quant aux drivers de cartes intel (que j'ai eu la couillonerie d'acheter depuis quelques années parce qu'on m'avait dit comme toi "c'est trop bien, c'est libre, ça marche mieux" sans préciser que mieux, ça ne veut pas dire complètement) tous les 2 ans ils décident de changer quelque chose soit dans les drivers soit dans xorg parce que ça va être trop trop mieux et ça pète tout pour une partie de la population captive de ces cartes.
            En ce moment, ben comme d'hab, pour les possesseurs de i8xxx, c'est la roulette russe suite à des changements récents:
            https://lists.ubuntu.com/archives/ubuntu-x/2010-September/00(...)
            et pour des fonctions de base ben pas mieux avec les 945 et autres:
            http://blog.martin-graesslin.com/blog/2010/09/driver-dilemma(...)

            Autant j'ai du respect pour les gens qui disent "moi je veux un système 110% libre, donc je prends une carte qui a des drivers libres" autant je trouve très con de mentir sur l'état réel du support de ces drivers parce qu'après ça se retourne contre les projets libres qui les utilisent.
            On blame déjà KDE4 pour des problèmes qui sont causés par les drivers intel, des fonctionnalités openGL qui sont mal supportées voire pas supportées et le driver rapporte qu'il les supporte.
            Donc si l'accélération GPU est utilisée maintenant par les browser ou d'autres softs, ça veut dire que bientôt on reprochera ce genre de crashs à google (et ça sera probablement un complot pour dominer le monde) ou à mozilla (et ça sera problablement parce que la mofo se débrouille mal).
            • [^] # Re: Trop cool... Mais quel intérêt ?

              Posté par (page perso) . Évalué à 1.

              110% d'accord !

              J'avais failli ne pas résister aux sirènes des cartes/drivers libres quand j'ai changé de config. Mais j'ai tellement tellement de mauvais souvenirs d'ATI et/ou intel (sur eeepc) ... que j'ai bêtement repris une carte nvidia. Drivers proprios, mais rien à redire ...
              • [^] # Re: Trop cool... Mais quel intérêt ?

                Posté par (page perso) . Évalué à 2.

                Il faut préciser que l'accélération 3D chez Intel c'est pas terrible matériellement, donc si ça rame… c'est normal, ça rame sous Windows aussi. Je commence à me répéter, mais ma carte ATI marche très bien avec des drivers libres, c'est sûrement pas aussi rapide que le driver proprio, mais ça marche suffisamment, et c'est stable.

                DLFP >> PCInpact > Numerama >> LinuxFr.org

            • [^] # Re: Trop cool... Mais quel intérêt ?

              Posté par (page perso) . Évalué à 5.

              Les drivers ati sont tellement biens qu'on ne sait plus combien il y en a (2 ou 3 à l'heure actuelle? de libres, hein) ni quelles cartes ils supportent, ni de quelle qualité de support on parle puisque c'est variable par carte et par driver.

              Grmbl. Ça fait un moment que c'est plus le cas. radeonhd est abandonné, tout est unifié par le driver "ati". Le support est détaillé, et ça dépend uniquement de la génération : http://www.x.org/wiki/RadeonFeature

              En gros, tu peux être sûr que toute carte Radeon <5000 aura un support très complet. Je joue à OpenArena, Nexuiz, etc. avec une Radeon HD 4670.

              DLFP >> PCInpact > Numerama >> LinuxFr.org

              • [^] # Re: Trop cool... Mais quel intérêt ?

                Posté par . Évalué à 1.

                Petite question: si on a deux cartes une ATI et une Intel sur un laptop laquelle va consommer le plus?

                sous windows il y a un truc pour swapper de l'une a l'autre a chaud, sous linux cela arrive un peu (redemarrage de xorg obligatoire) mais d'apres ce que j'avais vu niveau consommation la carte conseille pour consommer moins, Intel, consommait autant voir plus que ATI (en fait par consommation je veux dire que l'evaluation de la fin de la batteriene penchait pas en faveur de la carte Intel). Je pourrai faire le test en redemarrant et en activant chaque carte l'une apres l'autre mais bon comme je ne fais pas exactement la meme chose au meme moment je ne pense pas que cela soit valable comme test donc j'aimerai bien un avis plus "theorique" sur le sujet.
                • [^] # Re: Trop cool... Mais quel intérêt ?

                  Posté par (page perso) . Évalué à 2.

                  La carte Intel consomme moins en théorie.

                  Après, si les drivers Intel gèrent mal l'économie d'énergie, ce que tu dis me semble bien possible. Ou alors les deux cartes sont quand même « allumées » quoi que tu fasses.

                  Je savais que nVidia faisait ça, parce que leur cartes sont assez gourmandes, je savais pas pour ATI.

                  DLFP >> PCInpact > Numerama >> LinuxFr.org

      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par . Évalué à 2.

        3. OpenGL c'est juste le compositing, ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer (ou alors on fait comme Chrome, on utilise pas les libs du systems, et on fait tout à la main)

        Peux-tu expliquer plus ? En gros, le problème est d'avoir une sorte de lib vectoriel accéléré ?

        "La première sécurité est la liberté"

    • [^] # Re: Trop cool... Mais quel intérêt ?

      Posté par . Évalué à 3.

      se bouffer le nez sur des pouillèmes de secondes

      Pouillèmes qui peuvent représenter x1.5 ou x2, donc non ce n'est pas négligeable !

      "La première sécurité est la liberté"

      • [^] # Re: Trop cool... Mais quel intérêt ?

        Posté par . Évalué à 5.

        Quel est l'intérêt d'aller 2 fois plus vite sur, mettons, 5% du temps "réel" consommé par la page web ?
        • [^] # Re: Trop cool... Mais quel intérêt ?

          Posté par . Évalué à 2.

          C'est aussi une histoire d'oeufs et de poule. Quel intérêt de faire une application Js qui rame à mort en espérant un jour des performances correctes ?

          Il suffit de voir le comportement des appli google pour voir que cela serait mieux, d'avoir un peu plus de vitesse (le tableur surtout).

          "La première sécurité est la liberté"

          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par . Évalué à 2.

            Et qui t'a dit que le tableur google rame à cause du JS ? Ton petit doigt ?
            Ça peut très bien être un problème au niveau du DOM, au niveau de l'affichage...
            Le JS a atteint, et ce depuis 2 ans facilement sur les navigateurs modernes, un niveau suffisant pour 99% des applications qu'on pourrait en faire. Quel est l'intérêt d'optimiser ça encore ?
          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par (page perso) . Évalué à 3.

            Il suffit de voir le comportement des appli google pour voir que cela serait mieux, d'avoir un peu plus de vitesse (le tableur surtout).

            Ça doit être la principale raison pour laquelle chrome s'est lancé dans la course aux navigateurs.
          • [^] # Re: Trop cool... Mais quel intérêt ?

            Posté par (page perso) . Évalué à 2.

            Il suffit de voir le comportement des appli google pour voir que cela serait mieux, d'avoir un peu plus de vitesse (le tableur surtout).

            Déjà que l'intérêt d'un tableur est plus que discutable, alors un tableur en Javascript qui pue...

            http://devnewton.bci.im

  • # patrick, avec Firebug activé ?

    Posté par . Évalué à 7.

    J'ai à peu près la même configuration matérielle (Core 2 duo 2,40Gz) mais des résultats différents que toi sur Sunspider tant pour 3.6 que pour 4.0trunk, par contre mes résultats Chromium sont à peu près similaires aux tiens:

    Sunspider:
    Firefox 3.6 : 1300ms
    Firefox Trunk : 485ms
    Chromium dev: 333ms

    Comme tu peux le constater, l'écart est bien plus faible sur ma machine que sur la tienne entre Chromium et Firefox que ce soit la version du trunk ou celle de dev. Par ailleurs j'ai presque un facteur 3 entre Fx3.6 et 4 alors que tu n'as quà peine un facteur 2,

    En fait tu as même des perfs nettement plus basses que mon collègue qui a une machine à 1,87Gz et qui a 600ms sur Sunspider!

    Pour avoir des performances dégradées similaires à tes résultats, il faut que le JIT soit désactivé chez moi, ce qui arrive quand on installe Firebug par exemple.

    La question est donc est-ce que tu as Firebug d'installé dans tes profils et est-ce que tout simplement le jit est activé dans about:config ? :)
    • [^] # Re: patrick, avec Firebug activé ?

      Posté par (page perso) . Évalué à 1.

      >>> La question est donc est-ce que tu as Firebug d'installé dans tes profils et est-ce que tout simplement le jit est activé dans about:config ? :)

      Non pas de firebug d'installé. En fait j'ai désactivé toutes mes extensions Firefox avant de lancer le test.
      Mais bon je ne crois pas qu'on puisse comparer les perfs entre ta machine et la mienne. Le comparatif n'a vraiment du sens qu'entre divers navigateurs installés sur la même machine.
      Par exemple quel est ton OS ? Mon test a été effectué sous WinXPSP3 et Dieu seul sait quels sont les process qui tournent en arrière plan (par exemple au boulot on a un antivirus en tâche de fond).
      • [^] # Re: patrick, avec Firebug activé ?

        Posté par . Évalué à 3.

        Le différentiel sur ma propre machine entre Chromium et Firefox n'a rien à voir avec le tien, et on parle là de navigateurs sur la même machine, sous Ubuntu pas sous Windows.

        Pour le fun, j'ai lancé Firefox Trunk dans un XP à l'intérieur d'une VM sur cette même machine et même là, avec des perfs qui sont celles d'une VM c'est à dire très dégradées, j'ai un résultat deux fois meilleurs que les tiens (658ms).

        Je veux bien que l'on ait des configs différentes mais tes résultats sont tout trois fois plus lents que les miens et restent deux fois plus lents quand je passe par une VM donc à mon avis, tu as pas le JIT activé dans tes prefs. Tu peux réessayer avec un profil vierge?
        • [^] # Re: patrick, avec Firebug activé ?

          Posté par . Évalué à 2.

          Il y a pas une histoire de JIT dispo uniquement pour les machines 32 bits ?
        • [^] # Re: patrick, avec Firebug activé ?

          Posté par (page perso) . Évalué à 2.

          c'est quoi le about:config qu'il faut vérifier pour être certain que le JIT est activé ?
          • [^] # Re: patrick, avec Firebug activé ?

            Posté par . Évalué à 2.

            En cherchant jit, je trouve 2 variables :
            javascript.options.jit.chrome
            javascript.options.jit.content

            Je pense que c'est la seconde qui importe ici mais chez moi, les 2 sont à true.
            • [^] # Re: patrick, avec Firebug activé ?

              Posté par (page perso) . Évalué à 2.

              Chez moi aussi....donc le JIT était bien activé dans les tests.
              • [^] # Re: patrick, avec Firebug activé ?

                Posté par . Évalué à 2.

                avec des profils propres et séparés pour 3.6 et trunk?
                • [^] # Re: patrick, avec Firebug activé ?

                  Posté par (page perso) . Évalué à 2.

                  mmm...non c'est vrai que j'ai réutilisé mon profil 3.6 pour la version trunk. Tu crois que ça peut jouer ? On fait comment pour installer la trunk sur un profil séparé ?
                  • [^] # Re: patrick, avec Firebug activé ?

                    Posté par . Évalué à 2.

                    • [^] # Re: patrick, avec Firebug activé ?

                      Posté par (page perso) . Évalué à 3.

                      OK merci pour l'info.
                      Donc j'ai refait le test sunspider avec la version trunk sur un profil vierge.
                      Résultat : 1257 ms
                      Je pense que c'est dans la marge de fluctuation statistique par rapport au score de 1281 ms que j'avais trouvé précédemment.

                      Ensuite je suis allé voir le about:config de la version trunk et là, surprise, il y a des choix en plus par rapport aux choix présents dans la 3.6.
                      On remarque notamment javascript.options.methodjit.chrome qui chez moi était à false (tous les autres sont à true). Je l'ai donc remis lui aussi à true et, bis repetita, j'ai relancé le test sunspider.
                      Résultat 1271 ms.
                      Donc les perfs sur ma machine sont bien de cet ordre là et je reste très loin des 658ms annoncés par pascalc.
                      Sans doute ce salopiot d'antivirus qui me bouffe mes cycles CPU.
                      • [^] # Re: patrick, avec Firebug activé ?

                        Posté par (page perso) . Évalué à 4.

                        Sans doute ce salopiot d'antivirus qui me bouffe mes cycles CPU.

                        La question est alors pourquoi chrome/chromium semble insensible à ce salopiot ? :D
                        • [^] # Re: patrick, avec Firebug activé ?

                          Posté par (page perso) . Évalué à 2.

                          Je pense qu'il est tout aussi sensible et que donc la comparaison est valable sur ma machine. Seules les perfs relatives sont à considérer et pas les scores absolus.
                          Cela explique pourquoi je n'ai pas les mêmes performances que pascalc.
                          • [^] # Re: patrick, avec Firebug activé ?

                            Posté par . Évalué à 3.

                            Euh, désolé mais les perfs relatives entre Chrome et Firefox sur ta machine ne sont pas *du tout* les mêmes que sur ma machine ni les mêmes que celles que je constate sur les machines autour de moi quel que soit le système ou la configuration matérielle.

                            Par ailleurs, tu as présenté ton article comme une comparaison objective et scientifique des performances de Firefox par rapport à Chrome, hors ce n'est clairement pas le cas et ça aurait été bien de le mettre en préambule.

                            Je te rappelle que sur une machine très équivalente à la tienne avec Firefox qui tourne dans un XP virtualisé, j'éxplose les perfs de ta machine sous Firefox.

                            Au passage, chez moi la version de dev de Chrome 7 a les mêmes perfs que les nightlies de Chromium et est nettement plus rapide que la version stable de Chrome (350ms versus 550 pour la stable), donc même pour Chrome tes résultats sont douteux.
                            • [^] # Re: patrick, avec Firebug activé ?

                              Posté par . Évalué à 3.

                              À tout hasard, quelle est la taille de cache de vos processeurs respectifs ?
                              • [^] # Re: patrick, avec Firebug activé ?

                                Posté par (page perso) . Évalué à 2.

                                Core 2 Duo c'est 2 Mo de cache L2 non ?
                                Sinon je ne peux que rester perplexe quand aux résultats que j'ai constaté sur ma machine. Je ne sais pas vraiment ce qu'est "une comparaison objective et scientifique" telle que la réclame pascalc. J'ai indiqué les caractéristiques de mon ordinateur, j'ai effectué les tests sur trois benchs différents, j'ai refait les tests avec un profil propre, j'ai vérifié les options du about:config...que puis-je faire de plus ?
                                On verra bien au moment de la sortie effective de FF4.
                                • [^] # Re: patrick, avec Firebug activé ?s

                                  Posté par . Évalué à 2.

                                  Si on en croit Wikipedia il y a beaucoup de Core 2 Duo — http://en.wikipedia.org/wiki/Intel_Core_2 —, je précise que je n’y connais pas grand chose, mais il m’a semblé qu’il y avait énormément de facteurs qui entraient en compte dans les performances d’un processeur, dont le cache (encore que ne considérer que L2 est réducteur). Pour un code donné on peut avoir des différences de comportement importantes, même pour des processeurs « presque » identiques, parce que l’architecture de ces trucs est un poil compliquée : ce n’est pas une unité de calcul qui fait tout le boulot à la vitesse de cadence, mais une multitude d’unités différentes auxquelles sont assignées des tâches précises, avec du parallélisme, des pipelines, etc. Bref tout ce qui fait que le temps de calcul n’est pas proportionnel au nombre de cycle d’horloges consommés par les opérations atomiques du code.

                                  Du coup, « une comparaison objective et scientifique » n’est pas nécessairement pertinente.

                                  Ou alors c’est bêtement l’antivirus ?! Il est quand même très probable que ça vienne de la partie logicielle. xD
  • # WebGL

    Posté par . Évalué à 1.

    Je sais ça n'a rien à voir avec du benchmark javascript (quoique) mais il faudrait que WebGL puisse enfin fonctionner avec Firefox (4.0b5), sous Linux.

    WebGL fonctionne avec Chromium chez moi, avec des driver open source (i965), supportant OpenGL 2.1 et GLX_SGIX_pbuffer, alors pourquoi pas firefox?

    Promis, après, j'utilise plus Chromium.
    • [^] # Re: WebGL

      Posté par . Évalué à 1.

      ça marche très bien chez moi webGL, tu as mis l'option webgl.enabled_for_all_sites à true?
      • [^] # Re: WebGL

        Posté par . Évalué à 1.

        oui, mais quelle carte graphique et quelle version de firefox (4.0b5 ou 4.0b6pre) utilises-tu?
        • [^] # Re: WebGL

          Posté par . Évalué à 1.

          Nvidia et trunk (4.0b6pre), ceci dit ça fait plusieurs mois que toutes les démos que je vois tourner pour webgl tournent chez moi
    • [^] # Re: WebGL

      Posté par . Évalué à 1.

      Ça marche depuis plusieurs semaines avec les cartes intel également.
  • #

    Posté par . Évalué à -4.

    Oui moi aussi j'voudrais dire un truc sur les navigateurs.
    J'utilise firefox.
    Avec un nokia n95, je m'en sers comme modem, et c'est grâce à lui si vous me lisez.
    C'est pas beau la technologie ?
    Ben si.
  • # Comparatifs benchmarks quotidiens

    Posté par (page perso) . Évalué à 5.

    Pour ceux que ça intéresse, l'équipe de dev javascript de Mozilla a mis en place ce site : http://arewefastyet.com/ , qu'ils mettent à jour tout les 3-4 jours.

    On voit nettement les améliorations par rapport aux autres moteurs JS, surtout ces derniers jours.

    Les tests sont effectués avec les versions "standalone" des moteurs JS (donc hors navigateur). Donc pas de risque de parasitage de performance par d'autres éléments du navigateurs (moteur graphique, thread reseaux ou autre). Ce sont des résultats de perf pures donc.

    Un peu d'explication pour ceux qui ont la flemme de lire la FAQ.

    à l'origine, il y a le moteur SpiderMonkey : c'est un simple interpreteur JS, pas d'optim.

    Il y a eu ensuite TraceMonkey = SpiderMonkey + technique d'optimistation dites "tracing", appliquée principalement sur les boucles, et qui est plus performantes que de la simple compilation JIT. Mais malheureusement, cette technique ne fonctionne pas dans tout les cas, donc il y a du code JS qui reste interprété à la volée. Les perfs de tracemonkey, c'est la courbe orange.

    Il y a eu ensuite JaegerMonkey = SpiderMonkey + technique d'optimisation dites "jit" : le code JS est "compilé". C'est la technique utilisée dans le moteur js de webkit, avec le générateur de code machine Nitro, et celle utilisée dans v8, le moteur de chrome. D'ailleurs, JaegerMonkey utilise Nitro (oui, oui, une brique d'un "concurrent", vive l'open source !). Les perfs de jaeger monkey = courbe orange.

    Et depuis quelques jours, ils ont fusionné les deux techniques (courbe violette) dans le même moteur JS. Il n'y a donc plus de code JS interprété. Utilisation du tracing quand c'est possible (car plus rapide que du simple compilé en theorie), et utilisation du JIT pour le reste du temps.

    Ils arrivent donc maintenant à rattraper les autres moteurs JS. Ils ont encore pas mal d'optimisation à faire, ce qui va arriver dans les prochains jours.

    On espère donc que la courbe violette descende en dessous des autres, et qu'il y ait enfin un "YES" à la place du "NO" :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.