bzip3: Der schnellere und stärkere Nachfolger von BZip2 mit besserer Kompression

Ich habe kürzlich komprimierte .jsonl-Dateien verarbeitet (JSON-Lines-Format). Ich habe festgestellt, dass lzma eine viel bessere Kompression als gzip oder bzip2 bietet, was für Archivierungskosten hilfreich ist, aber es ist schwierig, damit zu arbeiten, da die Softwareunterstützung mangelhaft ist. Ich verarbeite mit duckdb, das gzip transparent unterstützt. Es gibt eine Erweiterung für bzip2, aber nicht für lzma oder bzip3.

Ich habe mich letztendlich für gzip entschieden, weil es von der Software, die ich verwende, am besten unterstützt wird und am wahrscheinlichsten Unterstützung in Software bietet, die ich übernehme. Aber es lieferte die schlechtesten Kompressionsergebnisse der Optionen, die ich ausprobiert habe. Diese bzip3-Zahlen lösen bei mir definitiv FOMO aus ...

Die Benchmarks sind unehrlich, bis hin zu dem Punkt, dass sie wie ausgesucht wirken. Die Blockgröße für bzip3 ist auf 512 MB gesetzt, aber die Fenstergröße für zstd bleibt auf ihrem Standardwert (ich glaube 8 MB für hohe Stufen). In diesem Korpus, der aus allen Versionen des Perl-Quellcodes besteht, die aneinandergereiht sind, ist das Fenster zu klein, um alle identischen Dateien zu sehen und sie einfach abzugleichen.

Auch Korpora, die aus sehr langen Wiederholungen bestehen, sind so ziemlich der beste Fall für BWT-basierte Kompressoren.

Wenn wir die Fenstergröße von zstd an die von bzip3 angleichen, erhalten wir dramatisch andere Ergebnisse:

% gzcat *.gz | time zstd -T8 -16 | wc -c # Basislinie

2819113884

zstd -T8 -16 2054.50s user 3.47s system 783% cpu 4:22.80 total

% gzcat *.gz | time zstd -T8 -16 --long=29 | wc -c

196405076

zstd -T8 -16 --long=29 1083.06s user 2.41s system 783% cpu 2:18.55 total

Fast 15x kleiner als die Basislinie und mehr als 2x kleiner als bzip3, auch die CPU-Zeit halbiert sich (da lange Übereinstimmungen früher gefunden werden, gibt es weniger Arbeit zu tun).

(Die Basiszahl ist etwas anders, weil ich nicht die genaue Perl-Versionsmenge habe, die der Autor verwendet hat)

Auch in den Benchmarks mit lrzip, die die Fenstergröße weniger relevant machen würden, wird zstd nicht einmal verglichen.

Ein interessanter unbeabsichtigter Benchmark ist, zu https://github.com/iczelia/bzip3/releases zu gehen und zu sehen, in welchem Maße bzip3 seine eigenen Release-Archive komprimiert; und zu https://github.com/iczelia/bzip3/blob/master/.github/workflo... zu gehen, um zu sehen, welche Optionen für die anderen Kompressoren hier gewählt wurden.

Ich denke, dies sollte Benchmarks mit zstd mit größeren Fenstern und Long-Range-Modus enthalten. Ich wäre nicht überrascht, wenn das verwendete Fenster kleiner als eine einzelne Versionstar-Datei wäre, was eine nützliche Kompression verhindern würde.

> Die Komplexität der Algorithmen und insbesondere das Vorhandensein verschiedener Sonderfälle im Code, die mit sehr geringer, aber nicht null Wahrscheinlichkeit auftreten, machen es jedoch unmöglich, die Möglichkeit von im Programm verbleibenden Fehlern auszuschließen.

Klingt nach einem netten Testfall für Formalisierung + KI?

Ich denke, Kompressionsalgorithmen sind reif für signifikante Verbesserungen mit LLMs. Es ist ein ideales Kandidatenproblem, das man in einer geschlossenen Evaluierungsschleife haben kann, und man kann Agenten einfach Dinge ausprobieren lassen.

Es ist geschmacklos, einen solchen Namen zu verwenden, wenn er nicht von den bzip-Autoren erstellt wurde. Aus irgendeinem Grund lieben es Open-Source-Entwickler, markenrechtsverletzende Namen zu verwenden, anstatt sich etwas Einzigartiges auszudenken.