Ich suche nach einem Algorithmus zum Dekomprimieren von Datenstücken (1k-30k) in Echtzeit mit minimalem Overhead. Die Kompression sollte vorzugsweise schnell sein, ist aber nicht so wichtig wie die Dekompressionsgeschwindigkeit.Schnellster Echtzeit-Dekompressionsalgorithmus
Von was ich sammeln könnte LZO1X wäre der schnellste. Habe ich etwas verpasst? Idealerweise ist der Algorithmus nicht unter GPL.
Wenn Sie GPL lizenzierten Code nicht verwenden können, ist Ihre Wahl klar - zlib. Sehr freizügige Lizenz, schnelle Komprimierung, faire Kompressionsrate, sehr schnelle Dekompression, funktioniert überall und portiert in jede vernünftige Sprache.
Dieses Papier: http://www.kkant.net/papers/lzo_results.pdf behauptet 20x Dekompressionsgeschwindigkeitsvorteil von LZO gegen zlib (natürlich mit verschlechterter Kompressibilitätsleistung). – MaR
Ja, Zlib ist in vielen Dingen gut, aber bei Dekompressionsgeschwindigkeiten ist es nicht das Beste. Ich hatte etwas wie QuickLZ im Hinterkopf. –
Als Zlib-Co-Autor und Zlib-Betreuer kann ich sagen, dass dies keine gute Antwort auf diese Frage ist. Es gibt viel schnellere Dekompressoren, wenn Sie eine weniger effektive Komprimierung zulassen. –
Versuchen Sie Googles Snappy.
Snappy ist eine Komprimierungs-/Dekomprimierungsbibliothek. Es zielt nicht auf maximale Komprimierung oder Kompatibilität mit anderen Komprimierungsbibliotheken ab. Stattdessen zielt es auf sehr hohe Geschwindigkeiten und angemessene Kompression. Im Vergleich zum schnellsten Modus von zlib ist Snappy beispielsweise bei den meisten Eingaben um eine Größenordnung schneller, aber die resultierenden komprimierten Dateien sind zwischen 20% und 100% größer. Auf einem einzelnen Kern eines Core i7-Prozessors im 64-Bit-Modus komprimiert Snappy ungefähr 250 MB/s oder mehr und dekomprimiert mit ungefähr 500 MB/s oder mehr.
Yuku, beobachten wir Dekompressionsgeschwindigkeit von 10-12Mb/sec (vs 500Mb/s beansprucht im Wiki) mit 'hadoop -text $ {snappy_compressed_file}'. Hadoop native libs sind installiert (einschließlich snappy nativ). Irgendwelche Gedanken? Unsere CPU-Info (Amazon EMR) Intel (R) Xeon (R) CPU E5645 @ 2,40 GHz –
Meine eigene App läuft auf 1,2 Ghz ARMv7 Prozessor dekomprimiert 5MB Daten in 100ms. Haben Sie aus dem Speicher dekomprimiert oder gibt es I/O-Overhead? – yuku
Danke für das Teilen, Yuku. Es gibt I/O-Vorgänge, der Overhead ist jedoch im Vergleich zum Dekompressionshit eher vernachlässigbar. Hier ist die gleiche Frage mit ein bisschen mehr Details auf snappy google group: http://goo.gl/LBapFc –
lz4 ist, was Sie hier suchen.
LZ4 ist ein verlustfreier Komprimierungsalgorithmus, der eine Komprimierungsgeschwindigkeit von 400 MB/s pro Kern bietet und mit Multi-Core-CPU skalierbar ist. Es verfügt über einen extrem schnellen Decoder, mit Geschwindigkeit in mehreren GB/s pro Kern, erreicht in der Regel RAM-Geschwindigkeitsbegrenzungen auf Multi-Core-Systemen.
Dekompression von was? Dateien? Streams? IP-Pakete? Video? Welche Kodierung? –
Wäre keine Komprimierung die schnellste Komprimierung? –
@JensSchauder: Definitiv nein, Wenn die Dekomprimierung die RAM-Geschwindigkeit überschreitet (z. B. Dekomprimierung in L2/L3-Cache), können Sie mehr Geschwindigkeit durch Komprimierung erzielen als ohne sie. Wenn Sie eine Festplatte oder ein Netzwerk verwenden, kann der Komprimierungsvorteil noch größer sein. –