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

Posté par monde_de_merde le 22 octobre 2009 à 13:05.

Étiquettes : aucune

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 Carl Chenet (site web personnel) le 22 octobre 2009 à 13:15. É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 Anonyme le 22 octobre 2009 à 13:20. Évalué à 7.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Fais chier
  
  Posté par Vincent (site web personnel) le 22 octobre 2009 à 13:28. Évalué à 6.
  
  En utilisant Gentoo, Arch ou une distrib source !
  - [^] # Commentaire supprimé
    
    Posté par Anonyme le 22 octobre 2009 à 13:32. Évalué à 2.
    
    Ce commentaire a été supprimé par l’équipe de modération.
  - [^] # Re: Fais chier
    
    Posté par dguihal le 22 octobre 2009 à 14:07. É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 ErusIluvatar le 22 octobre 2009 à 17:39. Évalué à -2.
      
      Et ABS c'est pour les chiens?
      - [^] # Re: Fais chier
        
        Posté par Albert_ le 22 octobre 2009 à 18:04. É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 dguihal le 22 octobre 2009 à 18:12. É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 dguihal le 22 octobre 2009 à 18:05. É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 Corto le 22 octobre 2009 à 13:29. Évalué à 9.
  
  Ca reste toujours un minimum pour voir des vidéos/animations en flash... ;)
# Multi-OS

Posté par Zenitram (site web personnel) le 22 octobre 2009 à 13:32. É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 ʭ ☯ le 22 octobre 2009 à 14:08. É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 dguihal le 22 octobre 2009 à 14:12. É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 Zenitram (site web personnel) le 22 octobre 2009 à 14:23. É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 monde_de_merde le 22 octobre 2009 à 15:05. É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 Vivi (site web personnel) le 23 octobre 2009 à 12:50. É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 ʭ ☯ le 23 octobre 2009 à 15:03. É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 NickNolte le 26 octobre 2009 à 00:01. É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 nomorsad le 22 octobre 2009 à 15:37. É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 kikicnrv le 22 octobre 2009 à 18:31. É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 Dabowl_92 le 22 octobre 2009 à 23:47. É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 nodens le 23 octobre 2009 à 03:54. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.