" Zstd verspricht eine ähnlich hohe Kompressionsrate wie das bislang gängige Zlib"

[windbeutel]

" Zstd verspricht eine ähnlich hohe Kompressionsrate wie das bislang gängige Zlib"

Aha, und dadurch spart AWS 30% Speicherplatz ein. Genial.

[Watson]

windbeutel schrieb:
--------------------------------------------------------------------------------
> " Zstd verspricht eine ähnlich hohe Kompressionsrate wie das bislang
> gängige Zlib"
>
> Aha, und dadurch spart AWS 30% Speicherplatz ein. Genial.

"(...), soll aber eine deutlich schnellere Kompression und Dekompression ermöglichen."

"Mit dem Wechsel des Kompressionsalgorithmus von Defalte in Gzip auf Zstd habe der Cloud-Hoster AWS eine Reduktion des Speicherplatzbedarfs für komprimierte S3-Speicher um 30 Prozent senken können."

Genau, da sie ja bisher deflate verwendet haben, weil zlib zu langsam ist.

[Ollinase]

Muss man den Energiebedarf, der durch Komprimierung/De-Komprimierung entsteht, noch dagegenrechnen?
Oder ist der schon berücksichtigt?
Dürfte nicht unerheblich sein bei der Menge an Daten.

[Pirke]

Ja der Artikel ist ziemlich wirr geschrieben.
Durch Zstd sparen sie 30% zum vorher verwendeten Deflate in Gzip, dann wird völlig ohne Kontext Zlib und LZO in den Raum geworfen ohne dass erläutert wird ob und wie das mit defaltedeflate zusammen hängt. Kann man sich alles selbst zusammen suchen, aber wäre für dne Artikel insgesammt aufschlussreicher wenn es in 2-3 Sätzen erläutert würde. Schade.

[Valdyn]

Meines Wissens nach ist zlib doch auch Deflate, und Wikipedia bestätigt das auch:

"Die zlib ist eine freie Programmbibliothek zum Komprimieren und Dekomprimieren von Daten mit dem Deflate-Algorithmus."

[berritorre]

Wir haben doch keine Zeit!

[PrinzessinArabella]

berritorre schrieb:
--------------------------------------------------------------------------------
> Wir haben doch keine Zeit!


Und denkt auch mal an die Kinder!

[Gaius Baltar]

Der Energiebedarf kann vermutlich mit dem Zeitaufwand der Komprimierung gleichgesetzt werden. Wäre Zeit (Rechenleistung) kein Thema, wären ja auch zlib in höheren Kompressionsstufen oder LZMA denkbar gewesen (einfach mehr CPUs draufwerfen) aber genau das soll ja gespart werden. Also um vergleichbar zu sein, verwendet man natürlich die gleiche Rechenleistung, die zur Verfügung steht.
Ausnahmen wären denkbar, wenn ein Verfahren schlecht mit Multiprozessoren skaliert (soweit ich das sehe, skaliert Zstd bei der Kompression, während multithreaded-Dekompression noch in der Entwicklung ist – aber Dekompression ist sowieso deutlich schneller als bei zlib/deflate).

Ein paar Vergleichsdaten lassen sich hier finden: http://facebook.github.io/zstd/

ZStd komprimiert einiges schneller als zlib/Deflate (bei vergleichbarer Kompressionsrate), auch schneller als Brotli, und die Dekompression ist deutlich verbessert (wichtig für Datenabruf). Die Werte lassen sich jeweils erhöhen mit nur leicht schlechterer Kompressionsrate.
Zlib mit vergleichbarer Geschwindigkeit (oben nicht aufgeführt) würde zu deutlich schlechterer Kompression führen. Im Graphen darunter (Compression Speed vs. Ratio) sieht man, dass zlibs maximale Kompression nach oben begrenzt ist. Bei gleicher Geschwindigkeit wäre Zstd schonmal 15% besser in der Kompressionsrate.

Nach unten hin konkurriert Zstd dann mit Echtzeit- oder Maxspeed-Kompressionsverfahren wie LZO und LZ4 (letzteres dekomprimiert deutlich schneller). Hier ist zu erkennen, dass Zstd mindestens eine vergleichbare Rate bei gleicher Geschwindigkeit erreicht. Lediglich die Dekompression ist Faktor 2 langsamer (wenn auch immer noch sehr gut).