bzip3 comprime todo el código fuente de Perl 5 en 546 MB: 6 veces mejor que bzip2

Recientemente estaba procesando archivos .jsonl comprimidos (formato de líneas JSON). Descubrí que lzma daba una compresión mucho mejor que gzip o bzip2, lo que ayuda con los costos de archivo, pero es difícil trabajar con él porque falta soporte de software. Hago procesamiento con duckdb, que soporta gzip de forma transparente. Hay una extensión para bzip2, pero no para lzma o bzip3.

Terminé usando gzip porque es el mejor soportado por el software que uso y es más probable que tenga soporte en el software que adopte. Pero dio los peores resultados de compresión de las opciones que probé. ¡Estos números de bzip3 ciertamente me dan FOMO...!

Los benchmarks son deshonestos, hasta el punto de parecer seleccionados a dedo. El tamaño de bloque para bzip3 se establece en 512MB, pero el tamaño de ventana para zstd se deja en su valor predeterminado (8MB, creo, para niveles altos). Así que en este corpus, que está compuesto por todas las versiones del código fuente de Perl concatenadas, la ventana es demasiado pequeña para ver todos los archivos idénticos y simplemente emparejarlos.

Además, los corpus hechos de repeticiones muy largas son prácticamente el mejor escenario para los compresores basados en BWT.

Si igualamos el tamaño de ventana de zstd al de bzip3, obtenemos resultados drásticamente diferentes:

% gzcat *.gz | time zstd -T8 -16 | wc -c # línea base

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

Casi 15 veces más pequeño que la línea base, y más de 2 veces más pequeño que bzip3, además el tiempo de CPU se reduce a la mitad (ya que las coincidencias largas se encuentran antes, por lo que hay menos trabajo que hacer).

(El número de la línea base es ligeramente diferente porque no tengo el conjunto exacto de versiones de Perl utilizado por el autor)

Además, en los benchmarks que usan lrzip, que haría que el tamaño de ventana fuera menos relevante, zstd ni siquiera se compara.

Un benchmark interesante no intencional es ir a https://github.com/iczelia/bzip3/releases y ver en qué medida bzip3 comprime sus propios archivos de lanzamiento; y ir a https://github.com/iczelia/bzip3/blob/master/.github/workflo... para ver qué opciones se han elegido para los otros compresores aquí.

Creo que esto debería incluir benchmarks de zstd con ventanas más grandes y modo de largo alcance. No me sorprendería si la ventana que usaron es más pequeña que un archivo tar de una versión individual, lo que impediría una compresión útil.

> Sin embargo, la complejidad de los algoritmos y, en particular, la presencia de varios casos especiales en el código que ocurren con probabilidad muy baja pero no nula hacen imposible descartar la posibilidad de que queden errores en el programa.

Suena como un buen caso de prueba para la formalización + IA.

Creo que los algoritmos de compresión están listos para una mejora significativa con los LLM. Es un problema candidato ideal que se puede tener en una evaluación de circuito cerrado, y simplemente puedes dejar que el agente pruebe cosas.

Es de mal gusto usar un nombre así cuando no fue creado por los autores de bzip. Por alguna razón, los desarrolladores de código abierto aman usar nombres que infringirían marcas registradas en lugar de inventar algo único.