Matthew Szulik quitte Red Hat, tests de performance JavaScript et Valgrind 3.3.0

Posté par  (site web personnel) . Modéré par Bruno Michel.
Étiquettes :
0
27
déc.
2007
Communauté
  • Matthew Szulik quitte Red Hat
    Le CEO et président de Red Hat Matthew Szulik a décidé d'abandonner ses fonctions pour des raisons de santé de sa famille. Il reste toutefois à la tête du directoire. Il est remplacé par James Whitehurst (COO de Delta Airlines).

  • Tests de performance JavaScript dans les navigateurs
    Un benchmark JavaScript a été réalisé à l'aide de SunSpider du projet WebKit. Les navigateurs testés sont Opera 9.5, Safari 3, IE7 et Firefox 2. La machine était une dual-core 3.0 GHz Core 2 Duo munie de 4 Gio de RAM et de... argh Windows Vista 32-bit. Firefox 3.0 beta 2 apporte de grandes améliorations.

  • Valgrind 3.3.0
    La célèbre suite d'outils libres de profiling et de débogage est passée en version 3.3.0. Helgrind et Massif ont été revus en profondeur, Cachegrind et Memcheck ont été améliorés, Omega et DRD sont deux outils expérimentaux qui font leur apparition, la documentation a été réorganisée, et on assiste à des gains en terme de mise à l'échelle.
Les petites brèves de LinuxFR : trois nouvelles toutes simples, regroupées, qui n'auraient pas matière à être développées jusqu'à en faire une dépêche à part entière. Vous pouvez contribuer des dépêches sur linuxfr.org/submit.html.

Aller plus loin

  • # JavaScript

    Posté par  . Évalué à 2.

    Vu l'utilisation massive de JavaScript (avec web 2.0, ajax, ...) au lieu d'interpréter le javascript (ce qui doit être fait par la plupart des navigateurs aujourd'hui), ne pourrait ton pas faire du JIT (compilation à la volé du code http://fr.wikipedia.org/wiki/Compilation_%C3%A0_la_vol%C3%A9(...) ).

    On me souffle à l'oreille que tamarin (http://www.mozilla.org/projects/tamarin/) devrait pouvoir faire du JIT.
    Quelqu'un sait il ou tamarin en est ?

    PS : pourquoi faire des bench sur de tel montre au lieu de config moyenne.
    • [^] # Re: JavaScript

      Posté par  (site web personnel) . Évalué à 1.

      > PS : pourquoi faire des bench sur de tel montre au lieu de config moyenne..

      J'ai déjà vu des personnes fâchées avec les "S" mais pas à ce point là :).

      Hop --> [] !
    • [^] # Re: JavaScript

      Posté par  . Évalué à 2.

      > Firefox 3.0 beta 2 apporte de grandes améliorations.

      Au passage, je signale que la consultation des pages de linuxfr rame horriblement avec Firefox 3.0 (beta2).

      La navigation et le scroll des pages est très très lourd et lent, lorsqu'on est loggué (nb : je n'ai aucune extension active, et n'ai pas ce problème avec Firefox 2.0). C'est un bug de Firefox, ou un problème dans le js de dflp ?
      • [^] # Re: JavaScript

        Posté par  . Évalué à 1.

        un probleme chez toi.

        chez moi avec :
        Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9a8) Gecko/2007100619 GranParadiso/3.0a8

        ca tourne nickel
        • [^] # Re: JavaScript

          Posté par  . Évalué à 1.

          Hmm, nous n'utilisons pas les mêmes versions en fait (et visiblement les devs / gros patchs continuent d'aller bon train entre chaque béta de FF 3). Ici :

          Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

          Ce qui n'exclue pas bien entendu la possibilité d'un problème chez moi (mais dans ce cas je ne saurais expliquer pourquoi le FF 2.0 standard d'Ubuntu sur la même machine n'a pas ce problème avec dflp, ni pourquoi les autres sites chargés en js que je fréquente habituellement n'ont pas ce problème avec mon FF 3.0b2).

          Bon de toutes façons, si ce n'est pas un problème avec mon setup particulier, les rapports de bugs ne tarderont pas après la sortie de FF 3.0 : j'y verrai plus clair le moment venu.
          • [^] # Re: JavaScript

            Posté par  . Évalué à 1.

            (complètement OT, mais bon :-)

            Ici avec :

            Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

            tout se passe bien. Peut-être un problème avec la version Linux ?

            C'est bizarre quand même ces dates qui diffèrent. Les dev de Firefox utiliseraient des versions différentes de Gecko dans les builds Linux et Windows ?


            PS: "Windows NT 5.1" => pas taper, je suis au boulot
            • [^] # Re: JavaScript

              Posté par  . Évalué à 1.

              les dates qui different c'est peut-etre normal si c'est des
              "nightly build"
  • # Et en Français ?

    Posté par  . Évalué à 1.

    lire PDG et Directeur opérationnel
  • # une news valgrind!

    Posté par  . Évalué à 0.

    Domage que la breve valgrind ne soit pas une vrai news.
    Ca aurrait été l'ocasion de parler de se formidable outil de débugage et de profilage, qui permet de trouver très rapidement des problèmes dans vos programmes C ou C++.

    Basé sur une technique d'instrumentation just in time (il modifie le code machine pour appeler ses propres routines).

    A la base, valgrind (memcheck) est un outil de détection d'accès illégaux a la mémoire. Il détecte les fuites de mémoire (memory leak), les accès après libération de pointeur, allocation trop courtes et j'en passe.

    La puissance de son outil JIT permet de créer une multitude d'outils de debugages.

    Helgrind permet de détecter les problèmes liés au multithread.

    Massif est un profileur de memoire, il permet de détailler combien de mémoire prends votre programme


    Callgrind est un outil de profilage JIT (a la difference de gprof, pas besoin de compiler avec des options spéciales)

    Cache grind permet de détecter les problemes de performances liés aux caches miss et autres branch prediction.
    Ces deux outils disposent d'un outil tiers appelé kcachegrind, qui permet de visualiser tout ca. La triplette est en fait pour moi le meilleur outil de profiling que je connaisse.

    Valgrind permet aussi de créer relativement facilement ses propres outils d'instrumentations.

    Le seul problème de valgrind est qu'il est fortement lié a l'architecture i386. les ports pour d'autres architectures sont en cours, mais un peu moins actifs, ca marche pas aussi bien.
    • [^] # Re: une news valgrind!

      Posté par  (site web personnel) . Évalué à 3.

      N'hésite pas à proposer une dépêche complète sur valgrind ;-)

      C'est par là : https://linuxfr.org/submit.html
    • [^] # Re: une news valgrind!

      Posté par  . Évalué à 2.

      Le seul problème de valgrind est qu'il est fortement lié a l'architecture i386.
      Il a l'air de tourner pas mal sur ppc.

      Par contre valgrind ralenti les programmes ce qui peut changer le comportement (par exemple dans le cas multi thread).
      Je crois aussi que tout est sérialisé (pas de SMP).

      C'est pas l'outil parfais, mais il reste quand même formidable.
      • [^] # Re: une news valgrind!

        Posté par  . Évalué à 1.

        J'avais vu dans la doc que tout est effectivement sérialisé : valgrind émule un CPU et ne fait tourner qu'un thread/process à la fois, mais il les croise (interleave) beaucoup plus fréquemment qu'un CPU normal, ce qui permet quand même de détecter les bugs de synchronisation.
    • [^] # Re: une news valgrind!

      Posté par  . Évalué à 1.

      Il est aussi et surtout fortement lié à Linux, même si çà semble s'améliorer dans la 3.3 (cf http://valgrind.org/docs/manual/dist.news.html ) :

      Developer-visible changes:
      - Internally, the code base has been further factorised and abstractified, particularly with respect to support for non-Linux OSs.

      Bientôt peut être un port récent et stable sur BSD, valgrind étant le seul outil indisponible sur cette plateforme et la raison pour laquelle j'ai encore Slackware au taf :)

      (oui je sais, j'ai qu'à envoyer des patchs et toussa, surtout maintenant que j'ai fini zelda je vais avoir un peu de temps libre)
  • # Petites brèves

    Posté par  . Évalué à 3.

    J'aime bien les petites brèves. C'est une excellente initiative.

    Matthew Szulik aurait mérité une "vraie" dépêche en première page. Mais le personne est discret et probablement que personne n'a fait cette "vraie" dépêche (en tout cas pas moi :-)).
    C'est tout de même le PDG depuis 10 ans de la distribution la plus importante, souvent la plus innovante (avec de sérieuses prises de risque pour faire avancer le libre), qui a fait Fedora, qui a le plus contribué au libre (au moins au niveau code), qui a acheté plein de boite pour mettre le code en GPL (près et peut-être plus de 200 millions de $), qui a dit "chiche" pour OLPC, qui a systèmatiquement dit non aux accords à la con type MS/Novell, qui a fait que Red Hat est toujours resté commauté friendly (n'est-ce pas Centos et autres clones), etc...

    Il mérite mieux que d'être noyé dans des brèves de seconde page. M'enfin, il ne doit pas s'en plaindre. Le vedettariat n'était pas son truc.

    Espérons que son successeur porte aussi fort le libre que lui.
    • [^] # Re: Petites brèves

      Posté par  (Mastodon) . Évalué à 2.

      +1 pour la dépêche en première page !

      ça me semble intéressant de pouvoir suivre l' évolution des plans de carrières de ces personnels (en général) qui ne sont pas à l' origine des pro-libres, mais qui travaillent et ont travaillés pour un socièté éditrice de LL, et aussi largement contribué à faire avancer le schmilblick.
      (et ne vais pas remettre une couche sur ce que tu dit d' elle, de redhat, étant 100% d' accord)

      A titre informatif ça serait vraiment très intéressant. (c' est clair que c' est peut être pas la vocation de linuxfr de parler de ça. Mais en regrettant aussi que personne d' autres ne le fasse)

      dit IsNotGood, tu te sentirai pour nous faire une dépêche sur ce sujet que tu maitrises ? Merci d' avance.

Suivre le flux des commentaires

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