Fragen? Antworten! Siehe auch: Alternativlos
Die Idee bei zstd ist, ähnlich wie beim Audio-Codec Opus eine skalierbare Lösung für das volle Spektrum anzubieten. Von "muss schnell gehen, Kompressionsrate ist nicht so wichtig" (und da erreicht zstd ungefähr die Kompressionsdichte von zlib, ist aber viel schneller) bis hin zu "kann länger dauern, Hauptsache die Kompressionsdichte ist hoch" decken die alles ab. Hier mal ein kurzer Test auf meinem Laptop:
-rw-r--r-- 1 leitner users 646983680 Oct 3 18:26 gcc-6.2.0.tarDer Vorsprung an Kompressionsdichte gegenüber xz ist nicht trivial an der Stelle! Um das Ergebnis zu kriegen, muss man allerdings auch --ultra -22 nehmen.
-rw-r--r-- 1 leitner users 128367167 Oct 3 18:26 gcc-6.2.0.tar.gz
-rw-r--r-- 1 leitner users 100157953 Oct 3 18:26 gcc-6.2.0.tar.bz2
-rw-r--r-- 1 leitner users 89697012 Oct 3 18:26 gcc-6.2.0.tar.xz
-rw-r--r-- 1 leitner users 92177927 Oct 3 20:03 gcc-6.2.0.tar.bro.9
-rw-r--r-- 1 leitner users 84647896 Oct 3 20:03 gcc-6.2.0.tar.bro.10
-rw-r--r-- 1 leitner users 82500389 Oct 3 20:03 gcc-6.2.0.tar.bro
-rw-r--r-- 1 leitner users 77330934 Oct 3 18:36 gcc-6.2.0.tar.zst
Hier die Timings:
pigz -9k gcc-6.2.0.tar 48.93s user 0.31s system 765% cpu 6.434 totalbro ist brotli, das gibt es m.W. leider nicht mit Multithreading-Support. Wenn man bei zstd ohne Multithreading komprimiert, kommt eine noch ein bisschen kleinere Datei raus:
pbzip2 -9k gcc-6.2.0.tar 109.63s user 1.33s system 763% cpu 14.533 total
xz -9 -T8 gcc-6.2.0.tar 287.42s user 0.48s system 742% cpu 38.787 total
bro --quality 9 --input gcc-6.2.0.tar --output gcc-6.2.0.tar.bro.9 57.62s user 0.14s system 99% cpu 57.761 total
bro --quality 10 --input gcc-6.2.0.tar --output gcc-6.2.0.tar.bro.10 515.99s user 0.19s system 99% cpu 8:36.20 total
bro --quality 11 --input gcc-6.2.0.tar --output gcc-6.2.0.tar.bro 1122.13s user 0.17s system 99% cpu 18:42.39 total
pzstd --ultra -22 gcc-6.2.0.tar 581.63s user 4.99s system 637% cpu 1:32.08 total
-rw-r--r-- 1 leitner users 75405797 Oct 3 18:34 gcc-6.2.0.tar.zstGucken wir uns mal die Dekompressions-Geschwindigkeiten an:
md5sum gcc-6.2.0.tar 0.99s user 0.09s system 99% cpu 1.086 totalWir können hier also sehen, dass zstd stärker komprimiert als xz und dabei ungefähr so schnell dekomprimiert, wie ein md5sum über die Daten braucht. Dabei hat es brotli, die diese Nische vorher abzudecken versucht hat, vollständig überholt. Die Kompression in dem Ultra-Modus ist zwar deutlich langsamer als xz, aber nicht so unpraktikabel viel langsamer wie brotli. Das Ende der Skala mit der starken Kompression ist für mich besonders interessant, denn meine Haupt-Anwendungen für Kompression sind Archivieren von großen Datenmengen und Index-Kompression, wo die Kompressionszeit im Wesentlichen egal ist, aber Kompressionsdichte und Dekompressionsgeschwindigkeit sind die wichtigen Eckwerte. Und in diesem beiden Bereichen ist zstd geradezu revolutionär.
zcat gcc-6.2.0.tar.gz 2.60s user 0.09s system 99% cpu 2.694 total
bzip2 -dc gcc-6.2.0.tar.bz2 14.35s user 0.19s system 99% cpu 14.545 total
xz -dc gcc-6.2.0.tar.xz 6.16s user 0.12s system 99% cpu 6.280 total
bro --decompress --input gcc-6.2.0.tar.bro 1.16s user 0.12s system 59% cpu 2.166 total
bro --decompress --input gcc-6.2.0.tar.bro.10 1.23s user 0.12s system 60% cpu 2.230 total
bro --decompress --input gcc-6.2.0.tar.bro.9 0.96s user 0.12s system 54% cpu 1.973 total
zstd -dc gcc-6.2.0.tar.zst 0.94s user 0.11s system 62% cpu 1.680 total
zstd ist aber auch auf Echtzeit-Kompression ausgelegt, beispielsweise für Netzwerk-Tunneling oder transparente Dateisystem-Kompression. Ich hörte heute, dass die ZFS-Leute gerade prüfen, ob sie nicht zstd als Kompressionsverfahren unterstützen sollen.