Outils de compression multicœurs

61

Quels sont les outils de compression disponibles dans Ubuntu pouvant tirer parti d'un processeur multicœur?

compression multi-core Luis Alvarado
la source
Pour mémoire, une alternative pourrait consister à créer des archives indépendantes en parallèle. Ainsi, au lieu de créer myfiles.8core.xz, vous créez myfiles1.xz sur myfiles8.xz en parallèle. Cela nécessitera un agent d'expédition. Les deux approches ont des avantages et des inconvénients complémentaires.
Acumenus
2
J'ai essayé de décompresser un fichier de 7 Go en utilisant bzip2 uniquement pour découvrir qu'il n'utilisait pas tous mes 8 cœurs. Lire à ce sujet et a décidé d'essayer pbzip2. Toujours en cours d'exécution sur un seul noyau. Ensuite, j'ai remarqué que des commentaires disaient que pbzip2 ne pouvait complètement paralléliser la décompression des fichiers compressés. Les mêmes commentaires suggéraient que lbzip2 puisse pleinement se paralléliser sur n’importe quel fichier bz2 ce qui était en réalité vrai - il faisait presque entièrement usage (80 à 90% de la CPU) de tous mes cœurs et le décompressait beaucoup plus rapidement.
Edi Bice

Réponses:

34

Il y a deux outils principaux. lbzip2et pbzip2. Ce sont essentiellement des implémentations différentes des compresseurs bzip2. Je les ai comparés (la sortie est une version ordonnée mais vous devriez pouvoir exécuter les commandes)

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

lbzip2semble être le gagnant sur des données aléatoires. C'est un peu moins compressé mais beaucoup plus rapide. YMMV.

Oli
la source
5
on dirait qu'il manque un chiffre dans la taille de pbzip2
Wayne Walker
4
/dev/urandomn’est pas un bon choix d’entrée pour l’étalonnage des outils de compression, car les données aléatoires sont, par définition, incompressibles. Cela explique en partie pourquoi, dans les deux cas, le fichier de sortie est environ 450 Mo plus volumineux que l’entrée.
ali_m
1
Désolé, je suis vraiment pédant mais les données vraiment aléatoires peuvent être super compressibles. Vous pouvez demander un RNG parfait pour 32 bits et obtenir 00000000000000000000000000000000. C'est comme ça que ça marche;) Ce dont vous parlez, ce sont des moyennes pratiques. Il est peu probable que vous génériez un fichier de 100 Mo contenant uniquement des zéros. Et je suis d'accord avec l'esprit de ce que vous dites, je ne suis tout simplement pas d'accord avec le terme "par définition" car ce n'est pas la définition (parce que c'est inexact).
Oli
2
Lorsque nous évaluons les performances de différentes méthodes de compression, ce qui nous intéresse vraiment, c'est la taille de sortie attendue pour les exemples futurs du type de données que nous voulons compresser. Si ces données sont réellement aléatoires, elles ne contiennent aucune régularité statistique à exploiter. Par conséquent, pour les séquences de N octets aléatoires, le mieux que nous puissions espérer est une longueur de sortie attendue de N octets. Pour certains exemples, nous pourrions faire un peu mieux, pour d'autres, nous pourrions faire un peu moins bien (en pratique, nous faisons presque toujours moins bien), mais la longueur de sortie attendue reste la même.
ali_m
5
Je veux dire "aléatoire" au sens de Kolmogorov , qui est littéralement défini comme incompressibilité. Il n'y a pas de référence universelle pour la compression, car différents algorithmes fonctionnent mieux pour différents types de données. Un bon début peut être simplement de wget http://mattmahoney.net/dc/enwik8.zipdiriger du texte, par exemple pour récupérer 96 Mo (21 Mo compressés) de texte provenant de Wikipedia. Pour une suite beaucoup plus complète de points de repère, voir ici .
ali_m
72

Eh bien, le mot clé était parallèle . Après avoir recherché tous les outils de compression également parallèles, j'ai trouvé ce qui suit:

PXZ - Parallel XZ est un utilitaire de compression qui tire parti de l’exécution de la compression LZMA de différentes parties d’un fichier d’entrée sur plusieurs cœurs et processeurs simultanément. Son objectif principal est d'utiliser toutes les ressources pour accélérer le temps de compression avec une influence minimale possible sur le taux de compression.

sudo apt-get install pxz

PLZIP - Lzip est un compresseur de données sans perte basé sur l’algorithme LZMA, avec un contrôle d’intégrité très sûr et une interface utilisateur similaire à celle de gzip ou bzip2. Lzip décompresse presque aussi vite que gzip et compresse mieux que bzip2, ce qui le rend bien adapté à la distribution de logiciels et à l'archivage de données.

Plzip est une version massivement parallèle (multi-threadée) de lzip utilisant le format de fichier lzip. les fichiers produits par plzip sont entièrement compatibles avec lzip.

Plzip est conçu pour accélérer la compression / décompression de gros fichiers sur des ordinateurs multiprocesseurs, ce qui le rend particulièrement bien adapté à la distribution de gros fichiers logiciels et à l'archivage de données à grande échelle. Sur des fichiers assez volumineux, plzip peut utiliser des centaines de processeurs.

sudo apt-get install plzip

PIGZ -pigz, abréviation de Parallel Implementation of GZip, est un remplacement entièrement fonctionnel de gzip qui tire parti de plusieurs processeurs et de plusieurs cœurs lors de la compression des données.

sudo apt-get install pigz

PBZIP2 - pbzip2 est une implémentation parallèle du compresseur de fichiers de tri par blocs bzip2 qui utilise des pthreads et permet une accélération quasi linéaire sur les machines SMP. La sortie de cette version est entièrement compatible avec bzip2 v1.0.2 (c.-à-d. Que tout ce qui est compressé avec pbzip2 peut être décompressé avec bzip2).

sudo apt-get install pbzip2

LRZIP - Un programme de compression multithread pouvant atteindre des taux de compression et une vitesse très élevés lorsqu'il est utilisé avec des fichiers volumineux. Il utilise les algorithmes de compression combinés de zpaq et de lzma pour une compression maximale, de lzo pour une vitesse maximale et de la réduction de la redondance à longue portée de rzip. Il est conçu pour évoluer en fonction de l’augmentation de la taille de la RAM, améliorant encore la compression. Un choix d'optimisations de taille ou de vitesse permet d'obtenir une meilleure compression que même celle fournie par lzma, ou une vitesse supérieure à celle de gzip, mais avec des niveaux de compression de taille bzip2.

sudo apt-get install lrzip

Un petit test de compression (utilisant le test créé par Oli):

TAILLE DU FICHIER ORIGINAL - 100 Mo
PBZIP2 - 101 Mo (1% plus grand)
PXZ - 101 Mo (1% plus grand)
PLZIP - 102 Mo (1% plus grand)
LRZIP - 101 Mo (1% plus grand)
PIGZ - 101 Mo (1% plus grand) )

Un petit test de compression (à l'aide d'un fichier texte):

Taille originale du fichier - 70 KB Fichier texte
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
la source
Des exemples seraient géniaux.
earthmeLon
@earthmeLon Lisez la réponse de Oli qui explique comment créer le fichier d'exemple. Continuez ensuite avec les commandes que j'ai utilisées.
Luis Alvarado
J'espère que la sortie de ceux-ci sont inter-compatibles. c'est-à-dire que la sortie de lrzippeut être décompressée en utilisant pbzip2, par exemple.
Vineet Menon
10

En plus du beau résumé ci-dessus (merci Luis), les gens de nos jours pourraient aussi vouloir considérer PIXZ, qui d'après son fichier README (Source: https://github.com/vasi/pixz - je n'ai pas vérifié les déclarations moi-même. ) présente certains avantages par rapport à 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 d'autres termes, PIXZ est censé être plus efficace en termes de mémoire et de disque et dispose d'une fonctionnalité d'indexation facultative qui accélère la décompression de composants individuels de fichiers tar compressés.

tour à tour
la source
Cependant, je crois comprendre que les pixzarchives ne sont pas compatibles avec le xzformat standard pxz.
Mxx
5
@Mxx: Les formats de fichier sont compatibles. pixzpeut décompresser des xzarchives et xzpeut décompresser des pixzarchives. Cependant, les options de ligne de commande sont différentes xzet pixzdifférentes.
Snowball
Les fichiers indexables sont une grande victoire pour pixz.
ostrokach
9

Mise à jour:

XZ Utils prend en charge la compression multithread depuis la version 5.2.0. Elle était à l'origine documentée à tort comme une décompression multithread.

Par exemple: tar -cf - source | xz --threads=0 > destination.tar.xz

Donbradken
la source
Vous pouvez également exécuter export XZ_DEFAULTS="-T 0" et ensuite simplement utiliser votre appel tar habituel, c'est-à-dire tar cJf target.tar.xz source.
scai
4

lzop peut également être une option viable, même s’il est mono-thread.

Il utilise l' algorithme de compression très rapide lempel-ziv-oberhumer qui est 5 à 6 fois plus rapide que gzip dans mon observation.

Remarque: Bien qu'il ne soit pas encore multi-threadé, il sera probablement plus performant que pigz sur les systèmes à 1 ou 4 systèmes. C'est pourquoi j'ai décidé de poster ceci même si cela ne répond pas directement à votre question. Essayez-le, cela pourrait résoudre votre problème de goulot d'étranglement du processeur en utilisant un seul processeur et en compressant un peu moins bien. J'ai souvent trouvé que c'était une meilleure solution que, par exemple, pigz.

ce4
la source
N’est-ce pas mieux de décompresser? Compresser prend environ le même (ou pire) que gzip
Lennart Rolland
Je peux aussi témoigner que lzop est super rapide. Proxmox utilise lzop pour la sauvegarde des machines virtuelles par défaut.
Lonnie Best
1
Lz4 est encore plus rapide (et a une version multithread).
David Balažic
3

Le compresseur LZMA2 de p7zip Installer p7zip utilise les deux cœurs de mon système.

David Foerster
la source
3

Il est pas vraiment une réponse, mais je pense qu'il est suffisamment pertinent pour partager mes points de repère comparant la vitesse de gzipet pigzsur une véritable HW dans un scénario de la vie réelle. De même que pigzl’évolution multithread que j’ai personnellement choisi d’utiliser désormais.

Métadonnées:

  • Matériel utilisé: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz(4c / 8t) + Nvme SSD
  • Distribution GNU / Linux: Xubuntu 17.10 (artful)
  • gzip version: 1.6
  • pigz version: 2.4
  • Le fichier en cours de compression est 9.25 GiB SQL dump

gzip rapide

time gzip -1kN ./db_dump.sql

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

gzip meilleur

time gzip -9kN ./db_dump.sql 

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

pigz rapide

time pigz -1kMN ./db_dump.sql 

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

pigzmeilleur (non zopfli)

time pigz -9kMN ./db_dump.sql 

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

pigz+ zopflialgorithme

time pigz -11kMN ./db_dump.sql 

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

En fin de compte, je ne recommanderais pas l’ zopflialgorithme, car la compression a pris énormément de temps pour une quantité d’espace disque non négligeable.

Taille des fichiers résultants:

  • meilleur s: 1309M
  • s rapide : 1680M
  • zopfli : 1180M
helvete
la source
2

Zstandard prend en charge le multi-threading depuis la version 1.2.0 ¹. C'est un compresseur et un décompresseur très rapide destiné à remplacer gzip et qui peut également compresser aussi efficacement, sinon mieux, que LZMA2 / XZ à ses niveaux les plus élevés.

Vous devez utiliser astucieusement ou une version plus récente, ou compiler la dernière version à partir de la source pour obtenir ces avantages. Heureusement, cela ne génère pas beaucoup de dépendances.

  1. Il y avait aussi un pzstd tiers dans la v1.1.0 de zstd.
LiveWireBT
la source