Bibliothèque de compression utilisant CUDA de Nvidia
Quelqu'un connaît-il un projet qui implémente des méthodes de compression standard (comme Zip, GZip, BZip2, LZMA, ...) utilisant NVIDIA bibliothèque CUDA ?
Je me demandais si les algorithmes qui peuvent utiliser beaucoup de tâches parallèles (comme la compression) ne fonctionneraient pas beaucoup plus rapidement sur une carte graphique qu'avec un processeur double ou quadcore.
Que pensez-vous des avantages et des inconvénients d'une telle approche?
Pas au courant de quiconque a fait cela et l'a rendu public. À mon humble avis, cela ne semble pas très prometteur.
Comme le souligne Martinus, certains algorithmes de compression sont hautement série. Les algorithmes de compression de blocs comme LZW peuvent être parallélisés en codant chaque bloc indépendamment. Le zip d'une grande arborescence de fichiers peut être parallélisé au niveau du fichier.
Cependant, rien de tout cela n'est vraiment du parallélisme de type SIMD (Single Instruction Multiple Data), et ils ne sont pas massivement parallèles.
Les GPU sont essentiellement des processeurs vectoriels, où vous pouvez exécuter des centaines ou des milliers d'instructions ADD toutes en étape de verrouillage, et exécuter des programmes où il y a très peu de branches dépendantes des données.
Les algorithmes de compression ressemblent généralement à un modèle de programmation SPMD (Single Program Multiple Data) ou MIMD (Multiple Instruction Multiple Data), qui est mieux adapté aux processeurs multicœurs.
Les algorithmes de compression vidéo peuvent être accélérés par le traitement GPGPU comme CUDA uniquement dans la mesure où il y a un très grand nombre de blocs de pixels qui sont transformés en cosinus ou convolués (pour la détection de mouvement) en parallèle, et les sous-programmes IDCT ou convolution peuvent être exprimés avec code sans branche.
Les GPU aiment aussi les algorithmes qui ont une intensité numérique élevée (le rapport des opérations mathématiques aux accès à la mémoire.) Les algorithmes avec une faible intensité numérique (comme l'ajout de deux vecteurs) peuvent être massivement parallèles et SIMD, mais fonctionnent toujours plus lentement sur le GPU que sur le CPU car ils suis lié à la mémoire.
Nous avons terminé la première phase de recherche pour augmenter les performances des algorithmes de compression de données sans perte. Bzip2 a été choisi pour le prototype, notre équipe n'a optimisé qu'une seule opération - la transformation Burrows – Wheeler, et nous avons obtenu quelques résultats: accélération 2x-4x sur de bons fichiers compressibles. Le code fonctionne plus rapidement sur tous nos tests.
Nous allons terminer bzip2, prendre en charge le dégonflage et LZMA pour certaines tâches réelles comme: le trafic HTTP et la compression des sauvegardes.
lien de blog: http://www.wave-access.com/public_en/blog/2011/april/22/breakthrough-in-cuda-data-compression.aspx
En règle générale, les algorithmes de compression ne peuvent pas utiliser des tâches parallèles, il n'est pas facile de rendre les algorithmes hautement parallélisables. Dans vos exemples, TAR n'est pas un algorithme de compression, et le seul algorithme qui pourrait être hautement parallélisable est BZIP car c'est un algorithme de compression de bloc. Chaque bloc peut être compressé séparément, mais cela nécessiterait beaucoup, beaucoup de mémoire. LZMA ne fonctionne pas en parallèle non plus, lorsque 7Zip utilise plusieurs threads, c'est parce que 7Zip divise le flux de données en 2 flux différents qui sont chacun compressés avec LZMA dans un thread séparé, donc l'algorithme de compression lui-même n'est pas parallèle. Ce fractionnement ne fonctionne que lorsque les données le permettent.
Nous essayons de porter bzip2 sur CUDA. :) Jusqu'à présent (et avec seulement des tests approximatifs effectués), notre transformation Burrows-Wheeler est 30% plus rapide que l'algorithme série. http://bzip2.github.com
Les algorithmes de chiffrement ont été assez efficaces dans ce domaine, vous voudrez donc peut-être vous pencher sur cela. Voici un article relatif au cryptage CUDA et AES: http://www.manavski.com/downloads/PID505889.pdf
30%, c'est bien, mais pour des applications comme les sauvegardes, cela ne suffit pas à long terme.
D'après mon expérience, le flux de données moyen dans de tels cas obtient une compression de 1,2 à 1,7: 1 à l'aide de gzip et finit par se limiter à un taux de sortie de 30 à 60 Mo/s (cela concerne un large éventail de supports modernes (vers 2010-2012) -CPU haut de gamme.
La limitation ici est généralement la vitesse à laquelle les données peuvent être introduites dans le CPU lui-même.
Malheureusement, pour garder un lecteur de bande LTO5 heureux, il a besoin d'un débit de données brut (non compressible) d'environ 160 Mo/s. S'il est alimenté en données compressables, il nécessite des débits de données encore plus rapides.
La compression LTO est clairement beaucoup plus rapide, mais quelque peu inefficace (équivalent à gzip -1 - c'est assez bon pour la plupart des utilisations). Les lecteurs LTO4 et les versions ultérieures ont généralement des moteurs de chiffrement AES-256 intégrés qui peuvent également maintenir ce type de vitesses.
Ce que cela signifie pour mon cas, c'est que j'aurais besoin d'une imprégnation de 400% ou mieux pour la considérer comme valable.
Des considérations similaires s'appliquent aux réseaux locaux. À 30 Mo/s, la compression est un obstacle sur les réseaux de classe Gb et la question est de savoir s'il faut dépenser plus en réseau ou en compression ... :)