Zstd : c’est quoi ce format de compression ?

Twitter Facebook Google Plus Linkedin email

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

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

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 :

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 :

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 :

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 ?

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 ?

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.

4
Poster un Commentaire

avatar
4 Fils de commentaires
0 Réponses de fil
2 Abonnés
 
Commentaire avec le plus de réactions
Le plus populaire des commentaires
4 Auteurs du commentaire
AMDG2flopFritangeSegusiaves Auteurs de commentaires récents
  S’abonner  
le plus récent le plus ancien
Notifier de
Segusiaves
Invité
Segusiaves

Bonjour ,
C ‘est implemenaté dans 7zip par ce monsieur : —-> https://mcmilk.de/projects/7-Zip-zstd/

Fritange
Invité
Fritange

Ça aurait été sympa de comparer avec des options autres que celles par défaut de gzip (par défaut le « niveau de rédution » est de 6 (ça va de « 1 » rapide mais peu performant à 9, lent mais plus performant), même si zstd doit s’en sortir très bien.

flop
Invité
flop

Un point qui n’est pas mis en évidence ici, c’est que si on joue avec le niveau de compression de zstd (de 1 à 19, + un mode ultra qui permet d’avoir des niveaux supplémentaires avec quelques contreparties, void détails dans zstd -h/le man), c’est qu’on obtient des ratios proche de ce qu’on peut avoir avec les algoritmes les plus performants. Au détriment du temps de compression, bien évidement, mais en conservant les perfs à la décompression (sauf quand la compression a été faite en mode ultra, il y a des variations possibles, selon les cas)

AMDG2
Invité

Bon article, merci ! Concernant la création de paquets AUR il y a un paramètre dans /etc/makepkg.conf qui permet de sélectionner l’algo de compression utilisé. Perso j’ai ça sur mes machines : PKGEXT=".tar", du coup mes paquets ne sont pas compressés, comme c’est toujours pour une utilisation en local c’est mieux comme ça !