[gull] Truc et astuces: Compression: Gagnez du temps avec Zstandard (zstd)
Frédéric Dumas
f.dumas at ellis.siteparc.fr
Fri Nov 27 13:12:25 CET 2020
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.
> - https://fr.wikipedia.org/wiki/Zstandard
> Zstandard (ou Zstd) est un algorithme de compression de données sans
> perte développé à partir de 2015 par Yann Collet (également connu sous
> le pseudonyme « Cyan ») et supporté par Facebook. Il s'agit aussi de
> l'implémentation de référence en C de cet algorithme.
Le problème de tout algorithme, c’est sa reconnaissance par une base large d’utilisateurs, en dehors de nous-mêmes. Compte tenu de la chute régulière du prix du Go, le taux de compression est aujourd’hui moins critique (sauf masses de données absolument considérables à archiver).
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.
> 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.
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 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 », n’est-ce pas ?
Merci pour ton mail, mais restons conscients que Zstd n’intéresse vraisemblablement à grande échelle que les datacenters.
Bye,
Frédéric.
--
Frédéric Dumas
f.dumas at ellis.siteparc.fr
> Le 15 nov. 2020 à 15:07, felix <felix at f-hauri.ch> a écrit :
>
> Bonjour,
>
> Je voulais vous parler d'un outils de (de)compression qui m'a impressionné.
>
> - https://fr.wikipedia.org/wiki/Zstandard
> Zstandard (ou Zstd) est un algorithme de compression de données sans
> perte développé à partir de 2015 par Yann Collet (également connu sous
> le pseudonyme « Cyan ») et supporté par Facebook. Il s'agit aussi de
> l'implémentation de référence en C de cet algorithme.
>
> Pour ce que j'ai testé, entre 3 et 8 fois plus rapide (moins gourmand) que
> gzip, avec un résultat comparable voir meilleur!
>
> Voici un petit bench, sur une poignée de fichiers ``représentatifs'':
> le pus gros: 4Gb: gzip: 138" -> 2.51G, zstd: 17" -> 2.44G (sans multithread).
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> 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"
>
> (l'option -T n'est pas utile pour la décompression)
>
> Cependant, le ``multithread ne divise pas le temps par le nombre de procs:''
>
> somesources.tar 372.65M -> 81.61M
> T1 1.809713" T2 1.043093" T3 0.858810" T4 0.823303"
>
> windowusers.tar 4.09G -> 2.44G
> T1 16.674683" T2 9.901385" T3 8.516600" T4 8.307437"
>
> Il semble que le rapport de gain est meilleur pour -T3, que pour -T2 ou -T4,
> mais -T1 conserve le meilleur rapport temps/coeur.
>
> Je n'ai que 4 coeurs à dispo et c'est pas du xeon...
> 'faudrait tester sur un xeon 24 coeurs!
>
> Voilà. Bon dimanche!
>
> --
> Félix Hauri - <felix at f-hauri.ch> - http://www.f-hauri.ch
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull
More information about the gull
mailing list