XZ en version 5.0

Posté par  (site web personnel) . Modéré par Xavier Teyssier.
Étiquettes :
32
4
nov.
2010
Ligne de commande
Après plusieurs années de développement, XZ est sorti en version 5.0.0. La première alpha de cette version a été publiée en septembre 2008, mais les versions bêta étaient largement utilisables depuis.

Pour rappel, XZ est un format de compression de données, dont la spécification est ouverte, et qui génère des fichiers plus petits : en moyenne 30% par rapport à gzip et 15% par rapport à bzip2, au prix d'un temps de compression plus élevé. Il utilise l'algorithme LZMA2.

Le format XZ est fourni avec :
  • Une bibliothèque de compression dont l'interface est similaire à celle de zlib (liblzma) ;
  • Un utilitaire en ligne de commande ressemblant à gzip (xz) ;
  • Un utilitaire de décompression seule (xzdec) ;
  • Un ensemble de scripts shell adaptés de gzip (xzgrep, xzdiff, etc.).

Aller plus loin

  • # Archlinux - paquetages logiciel (package)

    Posté par  . Évalué à 4.

    Pour info.
    XZ est déjà utilisé sur la distribution Archlinux pour les différents paquetages logiciel (package).

    http://www.archlinux.org/news/switching-to-xz-compression-fo(...)

  • # Quelques détails

    Posté par  . Évalué à 10.

    Le point important avec ce format est surtout, que même si la compression est lente, voire extrêmement lente, sa décompression elle est extrême rapide et bat allégrement bzip2. Ce qui en fait un format de compression de choix pour les livecd.

    De plus si on regarde les benchmarks. Le gain de place est certes énorme, mais au prix d’un énorme sacrifice de temps pour de la compression d’archives au quotidien.

    Néanmoins analysons quelques lignes savamment choisies :
    (Extrait de http://tukaani.org/lzma/benchmarks.html)

    Compressed file size in bytes
    gzip bzip2 lzmash
    1 86322815 76147880 67456213
    2 84858575 74320824 62085798
    X …………………………………………..
    9 78768334 72223858 54068819

    Compression time
    gzip bzip2 lzmash
    1 11.5s 1m 26s 0m 58s
    2 12.0s 1m 40s 2m 7s
    X ………………………………………...
    9 66.9s 2m 37s 12m 20s

    On peut constater que certes en -9 sa compresse à l’extrême, mais 12 minutes sur la machine de test pour 200 mo. Pour de la compression de livecd pas de soucis, pour du backup, c’est plus tendu, surtout si les archives pèsent leur poids en gigas.

    Par contre si on compresse en lzmash -1 on est plus rapide que du gzip -9 de quelques secondes. (moins d’une minute pour le total). Mais surtout en lzmash -1 l’archive est plus légère que du gzip ou bzip2 compressé à l’extrême.

    Si on compresse en lzmash -2 (gain de 2,5% de compression par rapport à -1) on est plus rapide que du bzip2 -9 de 30 sec. tout en compressant toujours mieux que du gzip ou du bzip à l’extrême.

    Bref, moi j’adopte ^^

    • [^] # Re: Quelques détails

      Posté par  . Évalué à 2.

      Pour de la compression de livecd pas de soucis, pour du backup, c’est plus tendu, surtout si les archives pèsent leur poids en gigas.

      Tu peux faire tes backups la nuit.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Quelques détails

      Posté par  . Évalué à 5.

      Avec ces chiffres, bzip2 n'a plus aucun intérêt : lzmash -1 est plus rapide et compresse mieux dans tous les cas. Par contre gzip conserve un avantage de rapidité en cas de compression légère.

      Un format excellent pour tout ce qui doit être mis à disposition et téléchargé sur le net. (on rattrape une partie du temps de compression avec nos uploads pourris)

      Par contre je n'ai pas le même chiffre pour l'écart entre -1 et -2, j'arrive à un écart de 8% (620/674 = 0,92)

    • [^] # Re: Quelques détails

      Posté par  . Évalué à 1.

      Par contre si on compresse en lzmash -1 on est plus rapide que du gzip -9 de quelques secondes. (moins d’une minute pour le total). Mais surtout en lzmash -1 l’archive est plus légère que du gzip ou bzip2 compressé à l’extrême

      Ça dépend vraiment de la nature des données compressées, il faut vérifier pour chaque cas. J'avais fait des tests sur certains de mes backups et le gain n'était pas systématique en taille. Par exemple en compressant les 600 M de ma boîte mail, qui contient pas mal de pièces jointes (images souvent), lzma -1 et -2 se situait entre gzip et bzip2 pour la taille, avec un temps de compression supérieur. En lzma -3 ça battait bzip2 mais en prenant le double de temps.

      • [^] # Re: Quelques détails

        Posté par  . Évalué à 5.

        Si je ne m'abuse et pour info, "xz -7" est le taux de compression le plus élevé « efficace », dans le sens où dans les options supérieurs, seul le dico utilisé et la mémoire allouée est plus importante pour un résultat similaire. Autrement dit, "xz" seul, correspondant à "xz -6" est idéal. "xz -7" pour taper dans la compression maximale, mais surtout pas "xz -9", beaucoup trop lent.

        Tiré du manuel :

        « Unless you want to maximize the compression ratio, you probably don't want a higher preset level than -7 due to speed and memory usage. »

  • # multithreadé ?

    Posté par  . Évalué à 10.

    Hello,

    Est-ce que les outils de compression sont multithreadés ?,
    vu le nombre de coeurs aujourd'hui, marre de voir 1 proc à 100% et le reste rien faire ...

    Nicolas

    • [^] # Re: multithreadé ?

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

      Pour bzip2, il existe pbzip2. Pour xz, je ne sais pas...

      • [^] # Re: multithreadé ?

        Posté par  . Évalué à 3.

        La page Wikipedia pour LZMA indique que "les outils 7-Zip, lzma et xz permettent d'utiliser plusieurs threads pour compresser".
        Mais je n'ai pas vérifié.

    • [^] # Re: multithreadé ?

      Posté par  . Évalué à 2.

      Si j'ai bien le lu le manuel (de la version 9.04 de 7zip, sachant qu'on en est à la 9.17 aujourd'hui), avec LZMA c'est 2 threads maximum. Je ne sais pas si ça inclus LZMA2 aussi.

      • [^] # Re: multithreadé ?

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

        Bien vu, effectivement comme on va avoir pleins de coeurs bientot ca serait bien
        d'en profiter pour ce genre de taches.

        Pour info pour gzip en version parallele, c'est pigz le nom du package
        (pbzip2 comme cite plus haut pour une version parallele de bzip2).

        Bonne compression en parallele! ;)

    • [^] # Re: multithreadé ?

      Posté par  . Évalué à 3.

      Les options pour le faire sont dans xz, mais comme le dit le man… elles sont ignorées pour l'instant.

      DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Comparaison avec 7z ?

    Posté par  . Évalué à 2.

    Sachant que bzip2 se fait allègrement exploser par 7z, il me semblerait plus pertinent de comparer avec 7z qu'avec des outils obsolètes...

    Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0

    • [^] # Mais non

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

      Non, comparer XZ avec 7Z n'a aucun intérêt : c'est exactement le même algorithme de compression : LZMA.

      • [^] # Re: Mais non

        Posté par  . Évalué à 8.

        En soit, c'est une information importante qu'il eût été pertinent de mentionner, alors :-p, vu que les lecteurs connaissent 7zip.

        Mais... LZMA et LZMA2, est-ce vraiment la même chose?
        (réponse: oui, LZMA2 étant une évolution du format pour ajouter des fonctionalités liées à la vérification d'intrégrité)

        • [^] # Re: Mais non

          Posté par  . Évalué à 3.

          Tiré du manuel :
          LZMA2 is modified version of LZMA. it provides the following advantages over LZMA:

          * Better compression ratio for data than can't be compressed. LZMA2 can store such blocks of data in uncompressed form. Also it decompresses such data faster.
          * Better multithreading support. If you compress big file, LZMA2 can split that file to chunks and compress these chunks in multiple threads.

          • [^] # Re: Mais non

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

            >> Better compression ratio for data than can't be compressed.

            Quand on peut pas compresser, on compresse mieux !

            >> LZMA2 can store such blocks of data in uncompressed form.

            En fait, on compresse pas

            >> Also it decompresses such data faster.

            Mais on décompresse quand même.


            Eh ben… Je suis le seul à trouver que cette doc est bordélique ?

            • [^] # Re: Mais non

              Posté par  . Évalué à 5.

              C'est très simple : dans le cas où une donnée se compresse mal, la compresser la rend souvent plus grosse, sans compter la décompression inutile. Dans ce cas précis, il va stocker la donnée *particulière* non compressée, rendant la décompression *globale* plus rapide.

              DLFP >> PCInpact > Numerama >> LinuxFr.org

  • # Benchmark plus récent

    Posté par  . Évalué à 2.

    Etant donné que le benchmark donné date de 2005, en voici un plus récent : [http://stephane.lesimple.fr/wiki/blog/lzop_vs_compress_vs_gz(...)] avec un petit graphe de comparaison de vitesse par rapport au taux de compression [http://www.valleyhold.org/~gordons/CompressionBenchmarks.png] Il semble effectivement que le xz -1 s'en sorte très bien dans ce test.

Suivre le flux des commentaires

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