Herramientas de compresión multinúcleo

61

¿Qué herramientas de compresión están disponibles en Ubuntu que pueden beneficiarse de una CPU de múltiples núcleos?

compression multi-core

— Luis Alvarado
fuente

Solo para el registro, una alternativa puede ser crear archivos independientes en paralelo. Entonces, en lugar de crear myfiles.8core.xz, crea myfiles1.xz en myfiles8.xz en paralelo. Esto requerirá un agente de despacho. Ambos enfoques tienen ventajas y desventajas complementarias.

— Acumenus

2

Intenté descomprimir un archivo de 7GB usando bzip2 solo para descubrir que no está usando todos mis 8 núcleos. Lea sobre esto y decidió probar pbzip2. Todavía se ejecuta en un solo núcleo. Luego noté comentarios que decían que pbzip2 solo puede paralelizar completamente la descompresión de los archivos que comprimió. Los mismos comentarios sugirieron que lbzip2 puede paralelizarse completamente en cualquier archivo bz2 que de hecho era cierto: se hizo un uso casi completo (80-90% de la CPU) de todos mis núcleos y se descomprimió mucho más rápido.

— Edi Bice

34

Hay dos herramientas principales. lbzip2y pbzip2. Son implementaciones esencialmente diferentes de los compresores bzip2. Los he comparado (el resultado es una versión ordenada, pero debería poder ejecutar los comandos)

cd /dev/shm  # we do all of this in RAM!
dd if=/dev/urandom of=bigfile bs=1024 count=102400

$ lbzip2 -zk bigfile 
Time: 0m3.596s
Size: 105335428 

$ pbzip2 -zk bigfile
Time: 0m5.738s6
Size: 10532460

lbzip2parece ser el ganador en datos aleatorios. Está un poco menos comprimido pero mucho más rápido. YMMV.

— Oli
fuente

55

parece que falta un dígito en el tamaño de pbzip2

— Wayne Walker

44

/dev/urandomNo es una gran opción de entrada para las herramientas de compresión de evaluación comparativa, ya que los datos aleatorios son, por definición, incompresibles. Eso explica en parte por qué en ambos casos el archivo de salida es ~ 450MiB más grande que la entrada.

— ali_m

1

Lo siento, estoy siendo muy pedante, pero los datos verdaderamente aleatorios pueden ser súper comprimibles. Puedes pedir un RNG perfecto para 32 bits y obtenerlo 00000000000000000000000000000000. Así es como funciona el azar;) De lo que estás hablando es de promedios prácticos. Es poco probable que genere un archivo de 100 MB de ceros. Y estoy de acuerdo con el espíritu de lo que estás diciendo, simplemente no estoy de acuerdo con "por definición" porque esa no es la definición (porque es inexacta).

— Oli

2

Cuando juzgamos el rendimiento de diferentes métodos de compresión, lo que realmente nos interesa es el tamaño de salida esperado para futuros ejemplos del tipo de datos que queremos comprimir. Si estos datos son verdaderamente aleatorios, entonces no contienen regularidad estadística para explotar la compresión, por lo que para secuencias de N bytes aleatorios, lo mejor que podríamos esperar es una longitud de salida esperada de N bytes. Para algunos ejemplos, podríamos hacerlo un poco mejor, para otros podríamos hacerlo un poco peor (en la práctica, casi siempre lo hacemos peor), pero la longitud de salida esperada permanece igual.

— ali_m

55

Me refiero a "aleatorio" en el sentido de Kolmogorov , que se define literalmente como incompresibilidad. No existe un punto de referencia universal para la compresión, ya que diferentes algoritmos funcionan mejor para diferentes tipos de datos. Un buen comienzo podría ser simplemente canalizar algo de texto, por ejemplo, wget http://mattmahoney.net/dc/enwik8.zippara obtener 96MB (21MB comprimido) de texto de Wikipedia. Para obtener un conjunto de puntos de referencia mucho más completo, consulte aquí .

— ali_m

72

Bueno, la palabra clave era paralela . Después de buscar todas las herramientas de compresión que también eran paralelas , encontré lo siguiente:

PXZ : Parallel XZ es una utilidad de compresión que aprovecha la ejecución de la compresión LZMA de diferentes partes de un archivo de entrada en múltiples núcleos y procesadores simultáneamente. Su objetivo principal es utilizar todos los recursos para acelerar el tiempo de compresión con la mínima influencia posible en la relación de compresión.

sudo apt-get install pxz

PLZIP : Lzip es un compresor de datos sin pérdidas basado en el algoritmo LZMA, con una comprobación de integridad muy segura y una interfaz de usuario similar a la de gzip o bzip2. Lzip descomprime casi tan rápido como gzip y comprime mejor que bzip2, lo que lo hace muy adecuado para la distribución de software y el archivo de datos.

Plzip es una versión masivamente paralela (multiproceso) de lzip que utiliza el formato de archivo lzip; los archivos producidos por plzip son totalmente compatibles con lzip.

Plzip está diseñado para una compresión / descompresión más rápida de archivos grandes en máquinas multiprocesador, lo que lo hace especialmente adecuado para la distribución de archivos de software grandes y el archivo de datos a gran escala. En archivos lo suficientemente grandes, plzip puede usar cientos de procesadores.

sudo apt-get install plzip

PIGZ - pigz, que significa Implementación Paralela de GZip, es un reemplazo completamente funcional para gzip que aprovecha múltiples procesadores y múltiples núcleos al comprimir datos.

sudo apt-get install pigz

PBZIP2 - pbzip2 es una implementación paralela del compresor de archivos de clasificación de bloques bzip2 que usa pthreads y logra una aceleración casi lineal en máquinas SMP. El resultado de esta versión es totalmente compatible con bzip2 v1.0.2 (es decir: cualquier cosa comprimida con pbzip2 puede descomprimirse con bzip2).

sudo apt-get install pbzip2

LRZIP : un programa de compresión multiproceso que puede lograr relaciones y velocidades de compresión muy altas cuando se usa con archivos grandes. Utiliza los algoritmos de compresión combinados de zpaq y lzma para una compresión máxima, lzo para la velocidad máxima y la reducción de redundancia de largo alcance de rzip. Está diseñado para escalar con aumentos con el tamaño de RAM, mejorando aún más la compresión. Una opción de optimización de tamaño o velocidad permite una mejor compresión de la que incluso puede proporcionar lzma, o una mejor velocidad que gzip, pero con niveles de compresión de tamaño bzip2.

sudo apt-get install lrzip

Una pequeña referencia de compresión (utilizando la prueba que creó Oli):

TAMAÑO DE ARCHIVO ORIGINAL - 100 MB
PBZIP2 - 101 MB (1% más grande)
PXZ - 101 MB (1% más grande)
PLZIP - 102 MB (1% más grande)
LRZIP - 101 MB (1% más grande)
PIGZ - 101 MB (1% más grande) )

Una pequeña referencia de compresión (usando un archivo de texto):

TAMAÑO DE ARCHIVO ORIGINAL - 70 KB Archivo de texto
PBZIP2 - 16.1 KB (23%)
PXZ - 15.4 KB (22%)
PLZIP - 15.5 KB (22.1%)
LRZIP - 15.3 KB (21.8%)
PIGZ - 17.4 KB (24.8%)

— Luis Alvarado
fuente

Los ejemplos serían geniales.

— earthmeLon

@earthmeLon Lea la respuesta de Oli que menciona cómo crear el archivo de ejemplo. Luego proceda con los comandos que usé.

— Luis Alvarado el

Espero que la salida de estos sean compatibles entre sí. es decir, la salida de lrzipse puede descomprimir usando pbzip2, por ejemplo.

— Vineet Menon

10

Además del bonito resumen anterior (gracias Luis), en estos días la gente también podría querer considerar PIXZ, que según README (Fuente: https://github.com/vasi/pixz , no he verificado las afirmaciones por mí mismo ) tiene algunas ventajas sobre PXZ.

[Compared to PIXZ, PXZ has these advantages and disadvantages:]

    * Simpler code
    * Uses OpenMP instead of pthreads
    * Uses streams instead of blocks, not indexable
    * Uses temp files and doesn't combine them until the whole file is compressed, high disk/memory usage

En otras palabras, PIXZ supuestamente es más eficiente en memoria y disco, y tiene una función de indexación opcional que acelera la descompresión de componentes individuales de archivos tar comprimidos.

— nturner
fuente

Sin embargo, tengo entendido que los pixzarchivos no son compatibles con el xzformato estándar , como pxzsería.

— Mxx

55

@Mxx: los formatos de archivo son compatibles. pixzpuede descomprimir xzarchivos y xzpuede descomprimir pixzarchivos. Sin embargo, las opciones de línea de comando en xzy pixzdifieren.

— Bola de nieve

Los archivos indexables son una gran victoria para pixz.

— ostrokach

9

Actualizar:

XZ Utils admite la compresión multiproceso desde la versión 5.2.0, originalmente se documentó erróneamente como descompresión multiproceso.

Por ejemplo: tar -cf - source | xz --threads=0 > destination.tar.xz

— donbradken
fuente

También puede ejecutar export XZ_DEFAULTS="-T 0" y luego simplemente usar su llamada tar habitual, es decir tar cJf target.tar.xz source.

— scai

4

lzop también puede ser una opción viable, aunque es de un solo subproceso.

Utiliza el muy rápido algoritmo de compresión lempel-ziv-oberhumer que es 5-6 veces más rápido que gzip en mi observación.

Nota: Aunque todavía no es multiproceso, probablemente superará a pigz en sistemas de 1-4 núcleos. Es por eso que decidí publicar esto incluso si no responde directamente a su pregunta. Pruébelo, puede resolver su problema de cuello de botella de CPU mientras usa solo una CPU y comprime un poco peor. A menudo me pareció una mejor solución que, por ejemplo, pigz.

— ce4
fuente

¿No es simplemente mejor descomprimir? Comprimir toma casi lo mismo (o peor) que gzip

— Lennart Rolland

También puedo testificar que lzop es súper rápido. Proxmox usa lzop para la copia de seguridad de máquinas virtuales de forma predeterminada.

— Lonnie Best

1

lz4 es aún más rápido (y tiene una versión multiproceso).

— David Balažic

3

El compresor LZMA2 de p7zip usa ambos núcleos en mi sistema.

— David Foerster
fuente

3

En realidad no es una respuesta, pero creo que es lo suficientemente relevante para compartir mis puntos de referencia que comparan la velocidad de gzipy pigzen una verdadera HW en un escenario de la vida real. Como pigzes la evolución multiproceso que personalmente he elegido usar de ahora en adelante.

Metadatos

Hardware utilizado: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz(4c / 8t) + SSD Nvme
Distribución GNU / Linux: Xubuntu 17.10 (artful)
gzip versión: 1.6
pigz versión: 2.4
El archivo comprimido es 9.25 GiB SQL dump

gzip rápido

time gzip -1kN ./db_dump.sql

real    1m22,271s
user    1m17,738s
sys     0m3,330s

gzip mejor

time gzip -9kN ./db_dump.sql 

real    10m6,709s
user    10m2,710s
sys     0m3,828s

pigz rápido

time pigz -1kMN ./db_dump.sql 

real    0m26,610s
user    1m55,389s
sys     0m6,175s

pigzmejor (no zopfli)

time pigz -9kMN ./db_dump.sql 

real    1m54,383s
user    14m30,435s
sys     0m5,562s

pigz+ zopflialgoritmo

time pigz -11kMN ./db_dump.sql 

real    171m33,501s
user    1321m36,144s
sys     0m29,780s

Como resultado final, no recomendaría el zopflialgoritmo ya que la compresión tomó una gran cantidad de tiempo para ahorrar una cantidad no significativa de espacio en disco.

Tamaños de archivo resultantes:

mejor s: 1309M
s rápido : 1680M
zopfli : 1180M

— helvete
fuente

2

Zstandard admite subprocesos múltiples desde v1.2.0 ¹. Es un compresor y descompresor muy rápido destinado a reemplazar gzip y también puede comprimir de manera tan eficiente, si no mejor, como LZMA2 / XZ en sus niveles más altos.

Debe utilizar una versión ingeniosa o más reciente, o compilar la última versión de la fuente para obtener estos beneficios. Afortunadamente, no atrae muchas dependencias.

También hubo un pzstd de terceros en v1.1.0 de zstd.

— LiveWireBT
fuente