[gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
felix
felix at f-hauri.ch
Sat Nov 28 08:50:46 CET 2020
On Fri, Nov 27, 2020 at 01:12:25PM +0100, Frédéric Dumas wrote:
> Bonjour Félix,
>
> J’aimerai répondre à ton mail, parce que personne ne le fait, alors
> qu’il est détaillé et que tu as fait l’effort de partager avec nous
> des infos intéressantes.
C'est gentil!
> Le problème de tout algorithme, c’est sa reconnaissance par une base
> large d’utilisateurs, en dehors de nous-mêmes.
Ce n'est pas si confidentiel: c'est un produit de facebook!
D'ailleurs, je ne serais pas étonné de voir ces librairies implémentées
en javascript, voire directement dans des prochaines versions de
navigateurs.
> Si ton application est l’archivage froid, transparent pour les clients
> finaux, où tes machines compressent/décompressent en interne, et ne
> présentent à l’extérieur que des données décompressées, cet algorithme
> à une valeur d’usage élevée, d’après tes tests.
Aussi.
> > Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que
> > gzip, avec un résultat comparable voir meilleur!
>
> Ce que je retiens surtout, c’est la faible charge CPU. Je serai
> curieux de savoir si les mêmes résultats s’observent sur AMD, comme
> sur Intel.
> L’optimisation de l’algorithme pourrait être très lié à une
> implémentation du jeu d’instructions plutôt qu’à une autre. Simple
> hypothèse.
Je viens de refaire le test sur mon vieux ``Raspberry Pi Model B Rev 2''
(BCM2835 ARMv6-compatible gpu_mem=128 -> MemTotal: 377'860 kB)
Une configuration suffisament éloignée d'Intel!?
Avec un tarball ``vite-fait'' de ~60M:
Filename Size gzip bzip2 xz zstd
tarball.tar 59.78M 27.09M 24.20M 19.00M 24.04M
45.31% 40.48% 31.77% 40.21%
2'49.7818" 5'33.8700" 13'13.9549" 1'10.9800"
decompr. 12.2794" 1'31.1238" 18.2540" 7.8507"
Compression: 2.4x gzip, 4.7x bzip2 et 11.2x xz. (ratio comparable à bzip2)
Decompr: 1.6x 11.6x 2.3x.
Allez, pour enfoncer le clou, j'y ai créé (sur mon raspberry-pi), un fichier
hautement compressible de 120Mo, de la manière suivante:
$ man info > info.txt; cat info.txt{,,}{,,}... >info_big.txt
J'ai concatené 39'366x info.txt > info_big.txt. Donc limité à des caractère
alphanumériques sans accent, fabriqué par répetitions.
C'est **hautement** compressible!
Well, mon raspberry-pi à bossé durant 3h24'40" pour produire:
Filename Size gzip bzip2 xz zstd
info_big.txt 121.45M 742.40K 491.98K 19.57K 12.82K
0.60% 0.40% 0.01% 0.01%
42.5624" 1h17'9.7551" 8'52.6467" 9.7620"
decompr. 10.2850" 1'31.7102" 6.1586" 5.8106"
Donc gzip 40", bzip2 1h1/4, xz ~9' et zstd: 9"!!
Je ne résiste pas à l'envie de vous montrer la liste des fichiers:
-rw-r--r-- 1 user user 127349010 nov 27 16:19 info_big.txt
-rw-r--r-- 1 user user 760222 nov 27 19:44 info_big.txt.gz
-rw-r--r-- 1 user user 503789 nov 27 19:44 info_big.txt.bz2
-rw-r--r-- 1 user user 20036 nov 27 19:44 info_big.txt.xz
-rw-r--r-- 1 user user 13127 nov 27 19:44 info_big.txt.zst
triée par taille décroissante...
Ok, il s'agit de cas (très) particuliers, mais bon, dans l'ensemble...
Pour plus d'info, n'hésitez pas à tester vous-même et rapporter ici, si vos
résultat présentent un intéret ou suscitent une interrogation!
https://f-hauri.ch/vrac/ziptest.sh
ou https://f-hauri.ch/vrac/ziptest.sh.txt
(Attention, ce script compresse 2x avec chaque outil: une première fois pour
mesurer le temps, donc l'un après l'autre, sans écrire la sortie et une
seconde fois (tous les algos à la fois**) pour avoir quelque-chose à décom-
presser afin de mesurer le temps de décompression... Ces test sur mon
raspi ont donc pris près de 5h! **Attention à l'espace disponible!!! )
> Si l’application consiste au contraire à distribuer des fichiers à
> l’extérieur, la valeur d’usage de tout nouvel algorithme de
> compression me paraît très faible. A cause de la difficulté à le faire
> adopter par une nouvelle masse critique d’utilisateurs.
A voir...
> A contrario, combien de fois voit-on des archives distribuées sous forme
> de .zip, « parce que ça peut-être ouvert sur n’importe quel ordinateur »,
l'alternative à .zip serait .tar.?z voire .cpio.?z... mais bon, c'est plus
compliqué, il faut utiliser 2 programmes...
> Merci pour ton mail, mais restons conscients que Zstd n’intéresse
> vraisemblablement à grande échelle que les datacenters.
Il me semble opportun de s'interesser à cette librairies pour les applications
de backups, ( type ``partclone'' ) et d'archivage (tarball.tzst)!
Voilà.
Par ailleur, je profite de cette réponse pour apporter des petites précisions
sur les fichier utilisés pour mon premier test.
> > Le 15 nov. 2020 à 15:07, felix <felix at f-hauri.ch> a écrit :
> > Filename Size gzip bzip2 xz zstd zstd-T4
> > wavfile.wav 48.72K 35.02K 33.91K 32.77K 34.55K 34.55K
> > 71.89% 69.60% 67.27% 70.91% 70.91%
> > .0060" .0116" .0293" .0028" .0026"
> > decompr. .0015" .0051" .0053" .0015"
Fichier audio .wav
> > test.svg 296.14K 43.65K 40.01K 36.03K 45.69K 45.69K
> > 14.74% 13.51% 12.16% 15.43% 15.43%
> > .0107" .0323" .0741" .0039" .0039"
> > decompr. .0049" .0107" .0070" .0021"
Fichier XML
> > script.tm 1.34M 244.04K 178.05K 183.69K 272.71K 272.71K
> > 17.76% 12.96% 13.37% 19.85% 19.85%
> > .0538" .1392" .7947" .0123" .0126"
> > decompr. .0131" .0374" .0234" .0055"
Fichier timing script (lignes: 'float<spc>int' $'0.146317 36\n6.970966 28\n...'
> > screenshot.png 1.86M 1.86M 1.84M 1.85M 1.86M 1.86M
> > 99.93% 98.95% 99.39% 100.00% 100.00%
> > .0727" .2767" .4964" .0088" .0089"
> > decompr. .0195" .1381" .1031" .0034"
Image PNG (~ incompressible)
> > script.log 11.20M 287.64K 200.62K 165.01K 217.67K 217.67K
> > 2.51% 1.75% 1.44% 1.90% 1.90%
> > .1061" 1.3140" 1.0747" .0236" .0188"
> > decompr. .0448" .1186" .0432" .0104"
Fichier log de console script (relatif à script.tm)
> > somesources.tar 372.65M 91.52M 71.53M 57.02M 81.61M 81.61M
> > 24.56% 19.19% 15.30% 21.90% 21.90%
> > 11.1434" 37.0908" 2'9.7232" 1.8509" .8362"
> > decompr. 2.0741" 10.1793" 3.8732" .5316"
Sources "clean": apache2-2.4.38, bash-5.0, ghostscript-9.27~dfsg et gimp-2.10.8
> > win10rescu.ntfs 408.52M 384.73M 385.64M 380.21M 382.04M 382.04M
> > 94.18% 94.40% 93.07% 93.52% 93.52%
> > 13.2750" 1'2.3206" 2'32.0821" .6944" .4324"
> > decompr. 2.1684" 27.1485" 1.9638" .1726"
Partclone d'une partition NTFS Win 10 rescue
> > asteriskLxc.tar 862.93M 359.65M 327.50M 260.45M 344.98M 344.98M
> > 41.68% 37.95% 30.18% 39.98% 39.98%
> > 36.6076" 1'30.2886" 5'50.4520" 5.3150" 2.5338"
> > decompr. 6.1810" 34.1689" 17.3148" 1.5118"
Je ne me souviens plus de comment j'ai fait ce tarball de 863G. :-/
> > windowusers.tar 4.09G 2.51G 2.47G 2.28G 2.44G 2.44G
> > 61.40% 60.30% 55.70% 59.72% 59.72%
> > 2'17.8952" 8'29.0160" 21'48.6027" 17.3199" 8.8711"
> > decompr. 26.6442" 3'18.4641" 1'26.5552" 4.7437"
Tarball d'un /media/user/WINDOW_C:/Users
--
Félix Hauri - <felix at f-hauri.ch> - http://www.f-hauri.ch
More information about the gull
mailing list