Ferramentas de compactação multinúcleo

61

Quais ferramentas de compactação estão disponíveis no Ubuntu que podem se beneficiar de uma CPU com vários núcleos.

compression multi-core

— Luis Alvarado
fonte

Apenas para o registro, uma alternativa pode ser criar arquivos independentes em paralelo. Portanto, em vez de criar myfiles.8core.xz, crie myfiles1.xz para myfiles8.xz em paralelo. Isso exigirá um agente de expedição. Ambas as abordagens têm prós e contras complementares.

— Acumenus

2

Tentei descompactar um arquivo de 7 GB usando o bzip2 apenas para descobrir que ele não está usando todos os meus 8 núcleos. Leia sobre isso e decidiu tentar o pbzip2. Ainda rodando em apenas um núcleo. Então notei comentários dizendo que o pbzip2 só pode paralelizar completamente a descompressão dos arquivos que foram compactados. Os mesmos comentários sugeriram que o lbzip2 pode paralelizar completamente em qualquer arquivo bz2 que de fato era verdade - fez uso quase completo (80-90% da CPU) de todos os meus núcleos e descomprimiu muito mais rapidamente.

— Edi Bice

34

Existem duas ferramentas principais. lbzip2e pbzip2. São implementações essencialmente diferentes de compressores bzip2. Comparei-os (a saída é uma versão arrumada, mas você deve poder executar os 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 o vencedor em dados aleatórios. É um pouco menos compactado, mas muito mais rápido. YMMV.

— Oli
fonte

5

parece um dígito está faltando na pbzip2 Tamanho

— Wayne Walker

4

/dev/urandomnão é uma ótima opção de entrada para ferramentas de compactação de benchmarking, pois dados aleatórios são, por definição, incompressíveis. Isso explica em parte porque nos dois casos o arquivo de saída é ~ 450MiB maior que a entrada.

— 22416 Ali_m 2/16

11

Desculpe, estou sendo muito pedante, mas dados verdadeiramente aleatórios podem ser supercompactáveis. Você pode pedir a um RNG perfeito por 32 bits e obter 00000000000000000000000000000000. É assim que funciona aleatoriamente;) O que você está falando são médias práticas. É improvável que você gere um arquivo de 100 MB apenas com zeros. E eu concordo com o espírito do que você está dizendo, simplesmente não concordo com o "por definição", porque essa não é a definição (porque é imprecisa).

— Oli

2

Quando estamos avaliando o desempenho de diferentes métodos de compactação, o que realmente interessa é o tamanho de saída esperado para exemplos futuros do tipo de dados que queremos compactar. Se esses dados são verdadeiramente aleatórios, eles não contêm regularidade estatística para a compactação explorar; portanto, para seqüências de N bytes aleatórios, o melhor que podemos esperar é um comprimento de saída esperado de N bytes. Para alguns exemplos, podemos melhorar um pouco, para outros, um pouco pior (na prática, quase sempre pioramos), mas o comprimento de saída esperado permanece o mesmo.

— ali_m

5

Quero dizer "aleatório" no sentido de Kolmogorov , que é literalmente definido como incompressibilidade. Não há referência universal para compactação, pois algoritmos diferentes funcionam melhor para diferentes tipos de dados. Um bom começo pode ser apenas canalizar algum texto, por exemplo, wget http://mattmahoney.net/dc/enwik8.zippegar 96 MB (21 MB compactados) de texto da Wikipedia. Para um conjunto de benchmarks muito mais abrangente, consulte aqui .

— ali_m

72

Bem, a palavra-chave era paralela . Depois de procurar todas as ferramentas de compactação que também eram paralelas , encontrei o seguinte:

PXZ - Parallel XZ é um utilitário de compactação que aproveita a execução da compactação LZMA de diferentes partes de um arquivo de entrada em vários núcleos e processadores simultaneamente. Seu objetivo principal é utilizar todos os recursos para acelerar o tempo de compactação com a menor influência possível na taxa de compactação.

sudo apt-get install pxz

PLZIP - Lzip é um compressor de dados sem perdas baseado no algoritmo LZMA, com verificação de integridade muito segura e uma interface de usuário semelhante à do gzip ou bzip2. O Lzip descompacta quase tão rápido quanto o gzip e compacta melhor que o bzip2, o que o torna adequado para distribuição de software e arquivamento de dados.

Plzip é uma versão massivamente paralela (multiencadeada) do lzip usando o formato de arquivo lzip; os arquivos produzidos pelo plzip são totalmente compatíveis com o lzip.

O Plzip é destinado à compactação / descompactação mais rápida de arquivos grandes em máquinas com multiprocessadores, o que o torna especialmente adequado para a distribuição de arquivos de software grandes e arquivamento de dados em grande escala. Em arquivos grandes o suficiente, o plzip pode usar centenas de processadores.

sudo apt-get install plzip

PIGZ - pigz, que significa Implementação Paralela do GZip, é um substituto totalmente funcional para o gzip que tira proveito de vários processadores e múltiplos núcleos ao compactar dados.

sudo apt-get install pigz

PBZIP2 - pbzip2 é uma implementação paralela do compressor de arquivos de classificação de blocos bzip2 que usa pthreads e atinge aceleração quase linear em máquinas SMP. A saída desta versão é totalmente compatível com o bzip2 v1.0.2 (ou seja, qualquer coisa compactada com o pbzip2 pode ser descompactada com o bzip2).

sudo apt-get install pbzip2

LRZIP - Um programa de compactação multithread que pode atingir taxas e velocidades de compactação muito altas quando usado com arquivos grandes. Ele usa os algoritmos de compactação combinados de zpaq e lzma para máxima compactação, lzo para velocidade máxima e a redução de redundância de longo alcance do rzip. Ele foi projetado para aumentar com o tamanho da RAM, melhorando ainda mais a compactação. Uma escolha de otimizações de tamanho ou velocidade permite uma compactação melhor do que o lzma pode fornecer ou uma velocidade melhor que o gzip, mas com níveis de compactação do tamanho do bzip2.

sudo apt-get install lrzip

Um pequeno parâmetro de compactação (usando o teste que Oli criou):

TAMANHO
DO ARQUIVO ORIGINAL - 100 MB PBZIP2 - 101 MB (1% maior)
PXZ - 101 MB (1% maior)
PLZIP - 102 MB (1% maior)
LRZIP - 101 MB (1% maior)
PIGZ - 101 MB (1% maior) )

Uma pequena referência de compactação (usando um arquivo de texto):

TAMANHO
DO ARQUIVO ORIGINAL - 70 KB Arquivo 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
fonte

Exemplos seriam ótimos.

— usar o seguinte código

@earthmeLon Leia a resposta de Oli, que menciona como criar o arquivo de exemplo. Em seguida, prossiga com os comandos que usei.

— Luis Alvarado

Espero que a saída destes seja intercompatível. ou seja, a saída de lrzippode ser descompactada usando pbzip2, por exemplo.

— Vineet Menon

10

Além do belo resumo acima (obrigado Luis), hoje em dia as pessoas também podem querer considerar o PIXZ, que, de acordo com o README (Fonte: https://github.com/vasi/pixz - eu mesmo não verifiquei as reivindicações ) tem algumas vantagens sobre o 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

Em outras palavras, o PIXZ é supostamente mais eficiente em memória e disco e possui um recurso de indexação opcional que acelera a descompactação de componentes individuais de arquivos tar compactados.

— nturner
fonte

No entanto, entendo que os pixzarquivos não são compatíveis com o xzformato padrão , o caminho pxzseria.

— Mxx

5

@Mxx: Os formatos de arquivo são compatíveis. pixzpode descomprimir xzarquivos e xzpode descomprimir pixzarquivos. No entanto, as opções da linha de comando estão ativadas xze pixzdiferem.

— Snowball

Arquivos indexáveis são uma grande vitória para pixz.

— Ostrokach #

9

Atualizar:

O XZ Utils oferece suporte à compactação multithread desde a v5.2.0, ele foi originalmente documentado por engano como descompactação multithread.

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

— donbradken
fonte

Você também pode executar export XZ_DEFAULTS="-T 0" e, em seguida, basta usar sua chamada tar habitual, ou seja tar cJf target.tar.xz source.

— Scai

4

O lzop também pode ser uma opção viável, embora seja de thread único.

Ele usa o algoritmo de compressão lempel-ziv-oberhumer muito rápido, que é 5-6 vezes mais rápido que o gzip na minha observação.

Nota: Embora ainda não seja multiencadeado, provavelmente superará o pigz em 1-4 sistemas principais. Por isso, decidi postar isso, mesmo que não responda diretamente à sua pergunta. Experimente, ele pode resolver o problema de gargalo da CPU ao usar apenas uma CPU e compactar um pouco pior. Eu achei muitas vezes uma solução melhor do que, por exemplo, pigz.

— ce4
fonte

Não é apenas melhor descomprimir? Compressão leva aproximadamente o mesmo (ou pior) do que gzip

— Lennart Rolland

Também posso testemunhar que o lzop é super rápido. O Proxmox usa lzop para backup de máquinas virtuais por padrão.

— Lonnie Melhor

11

O lz4 é ainda mais rápido (e possui uma versão multiencadeada).

— David Balažic

3

O compressor LZMA2 do p7zip usa os dois núcleos no meu sistema.

— David Foerster
fonte

3

Não é realmente uma resposta, mas eu acho que é relevante o suficiente para compartilhar meus benchmarks comparando a velocidade de gzipe pigzem um verdadeiro HW em um cenário da vida real. Como pigzé a evolução multithread que eu pessoalmente escolhi usar a partir de agora.

Metadados:

Hardware usado: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz(4c / 8t) + SSD Nvme
Distribuição GNU / Linux: Xubuntu 17.10 (artful)
gzip versão: 1.6
pigz versão: 2.4
O arquivo que está sendo compactado é despejo SQL de 9,25 GiB

gzip rápido

time gzip -1kN ./db_dump.sql

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

gzip melhor

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

pigzmelhor (não 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 ponto de partida, eu não recomendaria o zopflialgoritmo, já que a compactação levou uma quantidade enorme de tempo para uma quantidade não tão significativa de espaço em disco poupado.

Tamanhos de arquivo resultantes:

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

— helvete
fonte

2

O Zstandard suporta multi-threading desde a v1.2.0 ¹. É um compressor e descompressor muito rápido, destinado a substituir o gzip e também pode comprimir tão eficiente - se não melhor - quanto o LZMA2 / XZ em seus níveis mais altos.

Você precisa usar uma versão artística ou uma versão mais recente ou compilar a versão mais recente da fonte para obter esses benefícios. Felizmente, isso não gera muitas dependências.

Também havia um pzstd de terceiros na v1.1.0 do zstd.

— LiveWireBT
fonte