Bzip3 – der geistige Nachfolger von BZip2

• BZip3 ist der Nachfolger von BZip2 und bietet eine höhere Kompressionsrate und bessere Leistung.
• Es verwendet einen Order-0-Kontextmischungs-Entropie-Coder, schnellen Burrows-Wheeler-Transform-Code, RLE auf Basis von LZ77-artigem String-Matching sowie Lempel-Ziv+Prediction-Durchläufe auf Basis von PPM-artiger Kontextmodellierung.
• Besonders stark bei der Komprimierung von Text oder Code.
• Benchmark mit Perl-Quellcode
  • Nach dem Herunterladen und Entpacken aller Versionen von Perl5 wurden die .tar-Dateien mit verschiedenen Komprimierern getestet.
  • BZip3 zeigte bei verschiedenen Einstellungen im Vergleich zu anderen Komprimierern eine bessere Kompressionsleistung.
  • Auch bei der Dekomprimierungszeit zeigte BZip3 dank Parallelverarbeitung eine hervorragende Leistung.
• Haftungsausschluss
  • Es wird keine Verantwortung für Datenverluste durch die Verwendung von BZip3 übernommen.
  • Die Leistung von BZip3 hängt stark vom Compiler ab; der x64-Linux-clang13-Build kann bis zu 17MiB/s Kompression und 23MiB/s Dekomprimierung pro Thread erreichen.
  • Getestet auf verschiedenen Architekturen: x86, x86_64, armv6, armv7, aarch64, mips, sparc usw.
• Lizenz
  • BZip3 ist unter LGPLv3 lizenziert.
  • Der Burrows-Wheeler-Transform- und der LZP-Code stehen unter der Apache-2.0-Lizenz.
  • Andere Komponenten zur Konfiguration bei Compile-Zeit und zur Laufzeit folgen ihren jeweiligen Lizenzen.

[GN⁺]

Hacker-News-Kommentare

• Burrows-Wheeler Transform wurde schon mehrfach implementiert, aber eine intuitive Vorstellung davon, warum es funktioniert, ist immer noch schwer zu fassen
  • Dieser Algorithmus ist immer wieder beeindruckend
• Es werden Benchmark-Ergebnisse zur Kompression von Perl-Quellcode geteilt
  • Verglichen werden Kompressions- und Dekompressionszeiten sowie der Speicherverbrauch von xz, bzip2, bzip3 und zstd
  • Der Unterschied beim Speicherverbrauch ist bemerkenswert: 8M gegenüber 18301M
• Der Autor, der ein Programm in der schwierigen Programmiersprache Malbolge geschrieben hat, ist wirklich beeindruckend
• Früher wurden Daten mit bzip erneut komprimiert, später stellte sich jedoch heraus, dass dieses Format veraltet war und die Dekompression schwierig wurde
  • Jetzt wird ein ineffizientes Format verwendet, das voraussichtlich lange bestehen bleibt
• Verbesserungen an BWT sind großartig
  • Es wird angenommen, dass großes Potenzial für Verbesserungen bei der „Long-Range“-Kompression besteht
  • Es ist nötig, Ähnlichkeiten in Datensätzen mit mehreren GB effizient zu finden
• Es gibt eine kleine Bitte, einen Header- oder Tail-Block zu schreiben, der die Kompressionseffizienz festhält
  • bzip2 macht das nicht, gzip hingegen schon
• Es ist merkwürdig, dass bzip3 noch nicht in großen Benchmarks zur Textkompression aufgeführt ist
• Es gibt eine Frage zum Vergleich mit BWT-basierten Kompressoren
• Es wird die Idee vorgeschlagen, zunächst lange Wiederholungen in der Eingabe zu komprimieren und nur Literal-Blöcke per BWT zu verarbeiten
  • Diese Methode könnte schlechter sein als das grundlegende Kontextmodellierung von PPM oder Brotli
• Hochkompressionsalgorithmen sind ein sehr spezialisiertes Gebiet
  • Die Verwendung von zstd oder brotli mit niedrigen Einstellungen kann durch geringere Netzwerk- oder Speicherübertragungen die Geschwindigkeit erhöhen
  • Dank der heutigen RAM-Mengen können zstd und brotli Long-Range-Matches nutzen