PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Zstd : c’est quoi ce format de compression ?

vendredi 6 mars 2020 à 18:30

Certains diront que je débarque, mais le fait est qu’il y a eu une récente actualité autour de ce format relativement récent de compression sans perte, car il commence à être utilisé par défaut sur Arch Linux, et par conséquent, Manjaro. On s’est déjà intéressé à la compression sous plusieurs formes par le passé, ça fait longtemps, voyons pourquoi ce format gagne en popularité.

C’est en effet suite à une note de mise à jour du 20 janvier dernier que j’ai entendu réellement parler de zstd :

Upstream notice

:

 

Arch updated their default compression to zstd 18. We adopted to the same standard. More and more packages will have the zst extension from now on.

Bon, OK, un nouveau format que je ne connaissais pas. C’est pas si choquant, ma veille n’est pas spécialement orientée sur ces sujets, donc on va un peu s’intéresser à ce nouveau venu qui semble avoir beaucoup de succès auprès de différentes distributions Linux comme on va le voir.

Here comes a new challenger

Zstandard, parce que c’est son vrai nom, est tout récent dans l’univers des algorithmes de compression sans perte, car il n’est développé que depuis 2015. Enfin presque, car un de ses principes fondamentaux remonte à… 1977. L’utilisation d’un dictionnaire n’est donc pas nouveau pour la compression, il est même d’ailleurs au cœur du format LZMA qui a gagné en popularité grâce à un outil que vous devez connaître, 7-zip. Autant dire qu’on connaît bien les maths derrière ça; pas moi personnellement hein, je suis pas encore assez bon, mais y’a des furieux qui maîtrisent bien le sujet, et si vous voulez en savoir plus, Wikipedia est votre ami.

Mais alors quel est l’attrait de ce petit nouveau pas si nouveau d’un point de vue conceptuel ? Pourquoi est-il soutenu par Facebook ? Eh bien, sa grande promesse n’est pas lié à sa performance de compression, mais sa rapidité. Rapidité à la fois pour la compression mais aussi la décompression, peut-être encore plus pour la décompression d’ailleurs, car ses performances varient peu quelque soit le niveau de compression choisi au départ. Quant au niveau de compression, il est censé être comparable à gzip, tout en étant plus rapide que celui-ci.

Et si on testait nous-même ?

Pour vérifier ça, j’ai fait deux petits tests afin de mesurer cette promesse. Le premier est sur un unique fichier WAV, qui ne devrait pas donner de très bons résultats sur le taux de compression, l’autre sur un dossier composite à savoir une copie du blog, donc un mix entre fichiers textes et images, plus intéressant. Ce dossier sera « concaténé » dans un fichier tar, même si zstd est capable d’itérer sur un dossier en mode récursif, ce que ne savent pas nécessairement faire ses cousins.

Pour chaque test, j’ai fait une copie distincte du fichier d’origine pour limiter les impacts du cache noyau par une lecture répétée. J’utilise time pour mesurer le temps de traitement, compression et décompression, et les paramètres par défaut pour chaque commande. Voilà, les conditions sont posées, passons aux résultats.

Fichier WAV

$ time gzip Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.gz.wav 

real	0m22,659s
user	0m22,001s
sys	0m0,566s
$ time xz Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.xz.wav 

real	1m16,755s
user	4m40,875s
sys	0m1,676s
$ time zstd Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.zst.wav 
Alestorm - Sunset On The Golden Age.zst.wav : 97.96%   (514968188 => 504438852 bytes, Alestorm - Sunset On The Golden Age.zst.wav.zst) 

real	0m1,096s
user	0m1,169s
sys	0m0,550s

Eh bien le moins qu’on puisse dire, c’est que c’est effectivement très rapide. Et quid de la taille ?

$ l
total 2,8G
drwxr-xr-x 2 seboss666 seboss666 4,0K 02.03.2020 17:34  ./
drwxr-xr-x 8 seboss666 seboss666 4,0K 02.03.2020 17:22  ../
-rw-r--r-- 1 seboss666 seboss666 477M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.gz.wav.gz'
-rw-r--r-- 1 seboss666 seboss666 492M 02.03.2020 17:27 'Alestorm - Sunset On The Golden Age.wav'
-rw-r--r-- 1 seboss666 seboss666 472M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.xz.wav.xz'
-rw-r--r-- 1 seboss666 seboss666 492M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.zst.wav'
-rw-r--r-- 1 seboss666 seboss666 482M 02.03.2020 17:28 'Alestorm - Sunset On The Golden Age.zst.wav.zst'

On voit que le xz est largement au dessus des deux autres concurrents, mais le prix en temps de compression est très élevé. Ici, on voit que le zstd est moins performant par défaut que gzip, mais comme je l’ai dit, ce n’est pas nécessairement représentatif car le format de fichier ne se prête pas vraiment à l’objectif, de ce côté les formats liés à la compression audio ont de meilleurs résultats. Et le temps de compression est vingt fois plus court, donc facile d’être séduit par le petit dernier de la bande.

Ça, c’est pour la compression, voyons donc les résultats de décompression :

$ time gzip -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.gz.wav.gz 

real	0m5,306s
user	0m4,822s
sys	0m0,445s
$ time xz -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.xz.wav.xz 

real	0m43,681s
user	0m42,892s
sys	0m0,659s

$ time zstd -d Alestorm\ -\ Sunset\ On\ The\ Golden\ Age.zst.wav.zst 
Alestorm - Sunset On The Golden Age.zst.wav.zst: 514968188 bytes               

real	0m0,797s
user	0m0,339s
sys	0m0,435s

Une fois encore, on voit que xz est loin derrière en termes de rapidité, alors que zstd caracole en tête.  Il semble donc tenir une grande partie de ses promesses.

Dossier du blog

Passons à quelque chose de plus représentatif des pratiques d’archivage. Déjà ce qui est marrant, c’est la différence entre le dossier d’origine, et le fichier tar utilisé pour le test :

$ du -shc blog*
822M	blog
799M	blog.tar

Il y a donc près de 30Mo de perdus en petits fichiers qui prennent plus de place dans le système de fichiers que leur taille réelle. Mais on est pas là pour en faire l’analyse, revenons à nos moutons. Même motif que précédemment, copie du fichier tar pour chaque algorithme, voilà le résultat de compression :

$ time gzip blog.gz.tar 

real	0m38,189s
user	0m36,724s
sys	0m1,170s
$ time xz blog.xz.tar 

real	2m0,761s
user	7m24,399s
sys	0m2,488s
$ time zstd --rm blog.zst.tar 
blog.zst.tar         : 90.08%   (836802560 => 753810165 bytes, blog.zst.tar.zst) 

real	0m5,070s
user	0m4,118s
sys	0m1,317s

Euh, ok, là encore, zstd est loin devant en termes de rapidité, xz est hors concours de par sa lenteur, et ça donne quoi sur les tailles résultantes ?

$ l
-rw-r--r--  1 seboss666 seboss666 720M 02.03.2020 18:02  blog.gz.tar.gz
-rw-r--r--  1 seboss666 seboss666 799M 02.03.2020 17:58  blog.tar
-rw-r--r--  1 seboss666 seboss666 702M 02.03.2020 18:03  blog.xz.tar.xz
-rw-r--r--  1 seboss666 seboss666 719M 02.03.2020 18:03  blog.zst.tar.zst

Ah ! Effectivement, cette fois le résultat est proche de gzip, mais donc pour un traitement huit fois plus rapide. Et ça en compression. Et en décompression ?

$ time gzip -d blog.gz.tar.gz 

real	0m8,573s
user	0m7,003s
sys	0m0,988s
$ time xz -d blog.xz.tar.xz 

real	0m43,338s
user	0m41,663s
sys	0m1,268s
$ time zstd -d --rm blog.zst.tar.zst 
blog.zst.tar.zst    : 836802560 bytes                                          

real	0m3,048s
user	0m0,529s
sys	0m1,146s

Bon, les temps de décompression sont un peu moins impressionnants, mais tout de même, près de trois fois plus rapides. J’arrête là les manipulations, je pense qu’on a nos réponses.

Pas étonnant qu’il soit populaire

À voir les chiffres, on comprend un peu mieux le choix d’abord d’Ubuntu, puis d’Arch Linux et donc de Manjaro, de basculer sur ce format plutôt qu’un autre. Arch Linux utilisait xz jusqu’ici, et on voit que si ça fonctionne bien d’un point de vue stockage, et donc économie en transfert de données via Internet, le coût en termes de performances à la fois en compression et décompression ne vaut finalement pas la chandelle. Autant consommer un peu plus d’espace disque, un peu plus de réseau, pour finalement gagner en temps de travail aussi bien à la création qu’à l’installation. Ça serait intéressant de comparer le coût énergétique entre le transfert additionnel sur le réseau, et les calculs nécessaires pour générer les archives, mais c’est un peu compliqué et hors scope ici.

Reste que le format est soutenu par Facebook, et naturellement ça fait un peu peur, mais vu la finalité, il y a peu à craindre quant à sa pérennité, contrairement au support PHP d’HHVM qui a pris fin il y a un an. Si l’utilitaire zstd n’est pas dispo nativement sur votre système, vous pouvez vous tourner vers le dépôt Github qui regorge d’informations à son sujet, avec d’autres chiffres de performances, effectués sur une machine hors de portée du commun des mortels.

En tout cas, je pense que c’est une bonne décision d’y être passé sur Arch Linux, et pour avoir souffert avec quelques créations de paquets AUR qui prennent beaucoup de temps même avec xz en multiithread, j’espère que la plupart des recettes basculeront sur ce format rapidement.