ubuntuusers.de

Hallo,

neuer Wikiartikel zur zstd Komprimierung. Falls jemand schon mal das Training von zstd für kleine Dateien praktisch genutzt hat, kann gerne ein praxinaheres Beispiel als das vorhandene in den Artikel eingebaut werden.

Gruß, noisefloor

... Während andere Verfahren entweder auf hohe Geschwindigkeit oder eine hohe Kompressionsrate optimiert sind, kennt zstd beides. ...

Ist es nicht bei allen Komprimierungsverfahren so, dass desto besser die Kompression, desto größer ist der Zeitaufwand für die Kompression. D. h. über einen etwaigen Schalter Kompressionslevel wird unweigerlich auch immer die Zeit der Kompression beeinflusst. Damit gilt "...hohe Geschwindigkeit oder eine hohe Kompressionsrate..." doch bei allen Programmen oder nicht?

Hallo,

jain. Gemeint ist, dass es Komprimierer gibt, die ootb auf Geschwindigkeit optimiert sind (z.B. lz4) und andere, die auf Packrate gehen (z.B. gzip, bzip etc.), aber dass zstd explizit beides kann. Also es gibt ein Option für schnell und eine andere für stark komprimiert. Die Optionen sind _unabhängig_ voneinander. Bei anderen Packprogrammen ist es i.d.R. so, dass die Geschwindigkeit implizit über den Komprimierungsgrad gegeben ist.

In wie fern sich die (im Artikel auch erklärten) Optione -KOMPRIMIERUNGSGRAD und --fast in die Quere kommen können - keine Ahnung. Ich hatte gestern mit ein paar Komprimiereren rumgespielt und meine (vermeidlich) großen Datensätz komprimiert - das was aber alle so rasend schnell (0,0xx) Sekunden), dass der Unterschied keine Rolle spielte.

Gruß, noisefloor

noisefloor schrieb:

..., aber dass zstd explizit beides kann. Also es gibt ein Option für schnell und eine andere für stark komprimiert. Die Optionen sind _unabhängig_ voneinander. Bei anderen Packprogrammen ist es i.d.R. so, dass die Geschwindigkeit implizit über den Komprimierungsgrad gegeben ist.

Der Komprimierungsgrad wird sich ja mit der Einstellung --fast[=STUFE] ändern ansonsten wäre sie obsolet, denn niemand wartet freiwillig länger auf den gleichen Komprimierungsgrad. Und damit sieht es ja wieder so aus wie bei Programmen, die nur eine Einstellungen eben für den Komprimierungsgrad haben. Es sieht aus wie ein Gimmick mit welchem der Komprimierungsgrad verfeinert oder näher definiert werden kann. Oder habe ich da was falsch verstanden? Ich möchte die Einstellung nicht schlecht reden, ich bin nur über den Satz

... Während andere Verfahren entweder auf hohe Geschwindigkeit oder eine hohe Kompressionsrate optimiert sind, kennt zstd beides. ...

beim Lesen gestolpert.

Gruß sh4711

Hallo,

Oder habe ich da was falsch verstanden?

Ich denke ja. zstd ist wie gesagt der neuste, gängige Komprimierungsalgorithmus und vereint das beste aus allen Welten.

Und damit sieht es ja wieder so aus wie bei Programmen, die nur eine Einstellungen eben für den Komprimierungsgrad haben.

Um es mal bildlicher auszudrücken: während die anderen Komprimierungsprogramme 1-dimensional sind, ist zstd 2-dimensional, d.h. man hat mehr Möglichkeiten bei der Komprimierung. zstd ist wohl in einem (wesentlich) breiteren Fenster konfigurierbar als andere Algorithmen, siehe auch https://github.com/facebook/zstd#benchmarks

Du kannst den Satz aber gerne ändern, dass es klarer wird.

In wie fern das für Desktopnutzer relevant ist - keine Ahnung, wahrscheinlich gar nicht, wenn man gelegentlich komprimiert. Bei Facebook, bei denen die Entwicklung ja gelaufen ist, war es wahrscheinlich nicht egal, weil die Dutzende oder hunderte Male pro Sekunde irgendwie irgendwas komprimieren.

Gruß, noisefloor

Der Satz in der Einleitung

Während andere Verfahren entweder auf hohe Geschwindigkeit oder eine hohe Kompressionsrate optimiert sind, kennt zstd beides.

ist zwar richtig, aber trotzdem unglücklich, weil er beim Leser falsche Erwartungen weckt. Natürlich kann auch dieses Verfahren nicht grundsätzliche Restriktionen außer Kraft setzen, und somit stehen auch bei diesem Programm Geschwindigkeit und Kompressionsergebnis in Konkurrenz zueinander.

Richtig ist, dass der Bediener die Arbeitsweise des Programms wahlweise entweder über Angaben zum gewünschten Kompressionslevel oder durch Angabe der Geschwindigkeit steuern kann, aber nicht gleichzeitig. Wenn man Optionen zu beiden Steuerungsmethoden angibt, gewinnt die zuletzt genannte Option und davorstehende konkurrierende Optionen werden ignoriert. Wie immer ist es hilfreich, die Manpage zum Programm zu lesen.

Wichtig erscheint mir auch der Hinweis, dass man sich höhere Kompressionslevel mit höherem Arbeitsspeicherbedarf bei der Komprimierung und bei der Dekomprimierung erkauft. Bei einem Zielsystem mit wenig Arbeitsspeicher kann das die Dekomprimierung einer Datei mit hohem Kompressionslevel verunmöglichen.

Hallo,

habe die Einleitung mal leicht umgestellt, sollte jetzt klarer sein.

Wichtig erscheint mir auch der Hinweis, dass man sich höhere Kompressionslevel mit höherem Arbeitsspeicherbedarf bei der Komprimierung und bei der Dekomprimierung erkauft.

Ist in die Tabelle aufgenommen. Ebenso steht jetzt drin, das die Option --fast Vorrang vor einer Angabe des Kompressionslevels hat.

Gruß, noisefloor

Der Artikel ist nun online. Vielen Dank für diesen sehr interessanten Artikel, noisefloor!

Zwei Sachen:

zstd ist das jüngste und modernste der gängigen Kompressionsverfahren.

Das ist sub- und spekulativ. Das "modernste" habe ich mal gelöscht, es sei denn Du kannst es mit validen Quellen belegen.

Zweitens, ich weiß, Du magst den Links-Bereich aus irgendwelchen Gründen nicht so gerne mit Leben erfüllen, 😉 aber bitte denke künftig daran, falls irgend möglich, auch interne Links zu platzieren - siehe Wiki/Referenz (Abschnitt „Grundstruktur“).

Hallo,

Das ist sub- und spekulativ.

Jein, so halb. Das "jüngste der gängigen" stimmt schon, siehe 2. Abschnitt. "das modernste" ist sagen wir mal landläufige Meinung, aber absolut harte Fakten gibt es AFAIK nicht. Die zstd Seite hat ja diverse Benchmarks, die die Leistungsfähigkeit von zstd zeigen. Wie representativ die Daten sind - keine Ahnung.

Gruß, noisefloor