Comparatif, la compression parallélisée

L’idée de ce test m’a été soufflé par WillyOz, comparer le temps de compression en utilisant un seul cœur du processeur, face à tous les cœurs du processeur. Ici il n’est pas question de taille, pour ceux qui souhaite en savoir plus sur le taux de compression direction ce test.

Avant de commencer

  • Le temps de compression est mesuré avec la commande time, la réponse real est utilisée.
  • Le taux de compression qui est utilisé est celui par défaut.
  • La mesure de temps est faite sur la compression des fichiers source de l’émulateur Dolphin, soit 7208 fichiers, pour une taille de totale de  115.206.838 octets.
  • Les compresseurs ayant comme première lettre “p”, sont optimiser multi-cœurs.
  • La machine test est composé de :
    • AMD FX-6350 (6 cœurs)
    • 16 GB de RAM
    • SSD Samsung 850 EVO 250GB
    • Debian Testing amd64
    • Kernel 4.9.0-2

Résultats

Temps M:S
.tar.bz2 bzip2 00:12.852
pbzip2 00:02.884
.tar.gz gzip 00:04.786
pigz 00:00.978
.tar.lrz lzip 00:43.114
plzip 00:12.442
.tar.xz xz 00:40.022
pxz 00:11.613

Conclusion, l’utilisation du multithreading lors de la compression offre un gain de vitesse monumental, environ quatre fois la vitesse simple coeur avec mon processeur (6 coeurs).

2 Commentaires

  1. Tokapix
    2 messages

    Bonjour,

    C’est une très bonne idée effectivement, ces versions parallèles pour accélérer le traitement des gros fichiers. J’ai jeté un œil au détail des gains en performances apportée par la parallélisation à partir de tes résultats; je me suis dit que ce pourrait être intéressant :
    – gzip : ×4.893
    – bzip2 : ×4.456
    – lzip : ×3.465
    – xz : ×3.446

    Sur ton archive, on voit par exemple que la compression gzip se parallèlise mieux (presque ×5 en performances sur tes six cœurs de processeur) que la compression basée sur LZMA (lzip et xz gain de performance, sommes toutes respectable, de ×3.5 environs). Le gain un chouïa plus faible est probablement lié à la compression plus aggressive de l’algo LZMA : les blocs sont plus difficile à traiter indépendament en parallèle.

    Avec le compresseur type xz, si tu as entre quatre et six archives de tailles équivalentes à traiter dans un même batch (ça fait beaucoup de conditions), lancer simultanément un processus simple thread par archive peut aller plus vite que de séquencer les six archives avec des process parallèles. Mais là, on entre dans le domaine du fine tuning et on passe plus de temps à réfléchir aux commandes qu’a les exécuter. :-)

    Ça confirme donc ta conclusion : parallel is the way to go !

    À plus

      Répondre

  2. Jocker Papi
    304 messages

    Tokapix:

    Bonjour,
    C’est une très bonne idée effectivement, ces versions parallèles pour accélérer le traitement des gros fichiers.J’ai jeté un œil au détail des gains en performances apportée par la parallélisation à partir de tes résultats; je me suis dit que ce pourrait être intéressant : – gzip :×4.893 – bzip2 : ×4.456 – lzip :×3.465 – xz :×3.446
    Sur ton archive, on voit par exemple que la compression gzip se parallèlise mieux (presque ×5 en performances sur tes six cœurs de processeur) que la compression basée sur LZMA (lzip et xz gain de performance, sommes toutes respectable, de ×3.5 environs).Le gain un chouïa plus faible est probablement lié à la compression plus aggressive de l’algo LZMA : les blocs sont plus difficile à traiter indépendament en parallèle.
    Avec le compresseur type xz, si tu as entre quatre et six archives de tailles équivalentes à traiter dans un même batch (ça fait beaucoup de conditions), lancer simultanément un processus simple thread par archive peut aller plus vite que de séquencer les six archives avec des process parallèles.Mais là, on entre dans le domaine du fine tuning et on passe plus de temps à réfléchir aux commandes qu’a les exécuter.:-)
    Ça confirme donc ta conclusion : parallel is the way to go !
    À plus

    Merci pour ton analyse, qui complète ce post à merveille :)

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser les balises de mise en forme