Journal Où il est question de BFS, d' x264 et de performance du noyau

Posté par (page perso) .
Tags : aucun
22
22
oct.
2009
Cher journal,
J'avais passé 20minutes à écrire et à bien expliquer en faisant de belles phrases mais cette petite blagueuse de session a décidé de s'interrompre lors d'une prévisualisation, effaçant par la même occasion ma prose.

Tu me contenteras donc, cher journal, d'un résumé léger.

Lors de test de décodage d'une vidéo au format h.264 par la bibliothèque x264 avec un noyau pourvu de l'ordonnanceur BFS [1], quelqu'un s'est rendu compte que l'utilisation de ce dernier permettait d'améliorer les performance de prés de 80%.

L'équipe de x264 en a conclut qu'il devait y avoir un sérieux bug dans CFS [2], l'ordonnanceur standard du noyau Linux. Un cas test à donc était soumis aux développeurs du noyau [3].

Ainsi, le lendemain un patch a été poussé et celui-ci apporte déjà 70% d'amélioration. Par la suite, 10% ont été apporté par un autre patch.

Je laisserais conclure sur cette histoire le développeur à l'origine du rapport de bug, parce qu'il le fait bien mieux que moi et que j'ai un peu la flemme de re-traduire, je le confesse : http://x264dev.multimedia.cx/?p=185

Des améliorations collatérales sont sans doutes à prévoir à la suite de ces patchs, et ma conclusion toute personnelle est que le noyau 2.6.32 s'annonce décidément comme un très bon cru.

[1] : http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler
[2] : http://en.wikipedia.org/wiki/Completely_Fair_Scheduler
[3] : http://thread.gmane.org/gmane.linux.kernel/889444
  • # Ça tombe bien !

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

    En effet ça tombe plutôt bien vu qu'on vient d'apprendre que le 2.6.32 sera le noyau qui sera dans la prochaine Debian stable (Squeeze) et dans la prochaine Ubuntu LTS 10.04 (Lucid Lynx) :)
  • # Commentaire supprimé

    Posté par . Évalué à 7.

    Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Fais chier

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

      En utilisant Gentoo, Arch ou une distrib source !
      • [^] # Commentaire supprimé

        Posté par . Évalué à 2.

        Ce commentaire a été supprimé par l'équipe de modération.

      • [^] # Re: Fais chier

        Posté par . Évalué à 7.

        Arch n'est pas une distrib source !
        Perso je dois avoir moins de 5% de mes paquets compilés via AUR, tout le reste c'est du binaire normal.

        C'est pas parce qu'Arch te facilite la personnalisation des paquets qu'elle en devient une Gentoo (Note pour les gentooistes : Je n'ai rien contre la Gentoo)
        • [^] # Re: Fais chier

          Posté par . Évalué à -2.

          Et ABS c'est pour les chiens?
          • [^] # Re: Fais chier

            Posté par . Évalué à 6.

            non pour les voitures. D'autre question?

            ps: pour les non familiarise de Gentoo et Arch c'est quoi ABS?
            • [^] # Re: Fais chier

              Posté par . Évalué à 2.

              Arch utilise son propre format de paquet (des .pkg.tar.gz), et pour construire les paquets utilise un fichier nommé PKGBUILD (l'équivalent d'un fichier SPEC dans le monde rpm).

              ABS en gros te permet de récupérer les PKGBUILD utilisés pour construire la version binaire de la distribution, de les modifier pour ensuite substituer les nouveaux paquets à ceux provenant des miroirs.

              Lien : http://wiki.archlinux.fr/howto/archlinux/abs
          • [^] # Re: Fais chier

            Posté par . Évalué à 2.

            Non, mais si tu utilise une Arch, donne moi, sur ton installation, le rapport entre les paquets précompilés et les autres (AUR et ABS).

            A mon avis il sera très en défaveur des paquets sources.

            Note : C'est pas parce que RH fourni ses src.rpm que ça en fait une distrib sources, mêmes si ABS c'est plus que ça l'idée est la même.
    • [^] # Re: Fais chier

      Posté par . Évalué à 9.

      Ca reste toujours un minimum pour voir des vidéos/animations en flash... ;)
  • # Multi-OS

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

    Une question me vient...
    x264 est multi OS.
    Donc x264 est déjà regardable sur au moins 3 schudelers différents (CFS, celui de Windows, celui d'Apple)

    Comment se fait-il que la différence de perf n'est pas été vue avant?
    Est-ce que ça veut dire que Linux était 80% plus lent que Windows pour x264 ou que Linux est maintenant 2x plus rapide que Windows pour x264?
    • [^] # Re: Multi-OS

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

      Le scheduler a beaucoup évolué dans la série 2.6.x . Donc il fallait tester avec un noyau assez récent, sur un système Quad Core, pour trouver le bug. De ce que j'en ai compris, il n'affecte absolument pas les Mono core.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Multi-OS

      Posté par . Évalué à 3.

      Peut-être parce que la plupart des gens l'utilisent sur Linux/CFS ?

      Et que les autres ne sont en grande partie pas conscients que le moyen par lequel leur player joue du H264 c'est x264, quand ils se posent la question.

      Si tu enlèves les possesseurs de CPU de folie et qui n'ont pas de pb de ressources, ceux qui décodent via la CG, et ceux qui cherchent pas plus que loin que le bout de leur nez (Ca marche pas, bon ben je vais changer la machine), il ne te reste pas grand monde pour trouver un bug pareil.
      • [^] # Re: Multi-OS

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

        VLC utilise x264, et VLC est pas mal utilisé sous Windows avec des mutli-CPU.

        Ce que j'aimerai donc savoir c'est si VLC était 80% plus rapide sous Windows que sous Linux et que maintenant ça redevient ex-aequo, ou si VLC est maintenant 2x plus rapide sous Linux que sous Windows.

        Bref, les chiffres sont très gros, trop gros pour ne pas se poser des questions sur les perfs de chaque OS avec du x264 (ou autre) ou sur les chiffres avancés.

        (et non, je n'ai pas de machine avec dual boot avec le dernier noyau Linux pour tester, c'est juste une question sur le principe)
        • [^] # Re: Multi-OS

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

          Dans les commentaires de l'article du développeur d'x264 on peut lire :

          # Mathias Says:

          [...] And I also wonder, if there was that high penalty, how did Windows compare to encoding on Linux and how does it compare now? And this is all coming with 2.6.32?

          # Dark Shikari Says:
          [...]
          @Mathias

          Yes, it was probably slower than Windows. This explains a number of benchmarks I’ve seen recently where Windows trashes Linux at the same applications (when there’s really no good reason for it to do so).

          And yes, it’s all coming in 2.6.32.


          La régression était connue mais son origine n'avait pas était éclaircie semble-t-il
      • [^] # Re: Multi-OS

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

        leur player joue du H264 c'est x264

        euh x264, c'est un encodeur de H264. Le bench dont il est question concerne la conversion en ligne de commande d'un fichier en H264, rien à voir avec les players ..
    • [^] # Re: Multi-OS

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

      Le bug était visible si tu encodes avec x264 avec un système de fichiers ext4. 3 raisons qu'aucun utilisateur final ne l'aie encore remarqué.

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Multi-OS

      Posté par . Évalué à 1.

      Linux n'était pas lent par rapport à windows, il était plutôt incorrectement exploité, d'où le patch.

      Il n'a pas été dit atteind le niveau d'Windows (lequel?) et OS X (lequel?), il dit juste qu'avec ce patch, on va 80% plus vite :)

      Donc si ça se trouve, Linux met l'amende encore plus violement à ces OS :p
  • # pub

    Posté par . Évalué à 6.

    Bon ca suffit la pub pour 20minutes, ça fait déjà 2 fois aujourd'hui !

    ok blaguounette, toussa...
  • # performance du 2.6.32

    Posté par . Évalué à 2.

    et ma conclusion toute personnelle est que le noyau 2.6.32 s'annonce décidément comme un très bon cru.

    Un petit lien, lui aussi sur le sujet des performances du 2.6.32 :
    http://www.phoronix.com/scan.php?page=article&item=linux(...)

    Une regression a été trouvée avec postgresql.
    • [^] # Re: performance du 2.6.32

      Posté par . Évalué à 5.

      tu voudrais dire que Linux est enfin prêt pour le desktop ?

      En voilà une bonne nouvelle !
    • [^] # Re: performance du 2.6.32

      Posté par . Évalué à 3.

      régression, régression... En terme de performances, oui. En terme de sécurité des données en cas de crash, il y a un fameux progrès (oui, il faut lire l'article jusqu'au bout).

      D'ailleurs, si on a un controleur disque avec une batterie pour assurer le commit des données en cache (les controleur raid de serveur par exemple), on peut passer outre la protection supplémentaire avec une simple option de montage (nobarrier). Enfin, on parle d'ext4 uniquement.

Suivre le flux des commentaires

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