Y a-t-il une bibliothèque dans .NET qui fait la compression multithread d'un flux? Je pense à quelque chose comme l'intégré Je sais que, par exemple 7-Compresses zip à l'aide de plusieurs threads, mais le C # SDK qu'ils ont libérés ne semblent pas le faire. system.io.gzipipipstream , mais en utilisant plusieurs threads pour effectuer le travail (et utiliser ainsi tous les cœurs de la CPU).
5 Réponses :
Je pense que votre meilleur pari est de diviser le flux de données à intervalles égaux vous-même et de lancer des threads pour compresser chaque partie séparément en parallèle, si vous utilisez des algorithmes non parallèles. (Après quoi un seul fil les concaténe dans un seul flux (vous pouvez créer une classe de flux qui continue à lire dans le flux suivant lorsque l'actuel se termine)).
Vous voudrez peut-être jeter un coup d'œil à SharpziPlib qui est un peu mieux que l'intrinsèque Compression flux dans .NET.
Edit: Vous aurez besoin d'un en-tête pour indiquer où chaque nouveau flux commence, bien sûr. :)
Oui, je suis d'accord avec cela, je ne peux penser à aucune bibliothèque de compression spécifiquement parallèle. Si quelqu'un devait en écrire un, je ne peux pas penser à la manière dont il fonctionnerait en dehors de la division des données brutes en morceaux et de compresser chacun sur un fil. Sachez que si vous le divisez dans des morceaux trop petits, vous réduirez l'efficacité de la compression (heure et taille).
Bonne mention de Sharpziplib, je l'utilise déjà. En ce qui concerne la scission du flux, oui, je suis au courant de cette solution, malheureusement, l'exigence est de compresser un seul flux qui se nourrit à mon code et d'écrire dans un seul flux compressé, alors chunking les données entrantes n'est pas vraiment une option.
On dirait que vous recherchez un filetage très fin à grain, ou une "micro-parallélisation" si vous le souhaitez. Si vous avez le temps de trouver un moyen de modifier les sous-routines de #ZIPLIB pour utiliser des boucles parallèles, telles que celles trouvées dans Parallel.net (ou quoi que ce soit que cela s'appelle).
Un format de compression (mais pas nécessairement l'algorithme) doit être conscient du fait que vous pouvez utiliser plusieurs threads. Ou plutôt, pas nécessairement que vous utilisez plusieurs threads, mais que vous comprimez les données d'origine en plusieurs étapes, parallèles ou non.
Permettez-moi d'expliquer.
La plupart des algorithmes de compression compressent des données de manière séquentielle. Toute données peut être compressée à l'aide des informations tirées des données déjà compressées. Donc, par exemple, si vous comprimez un livre par un mauvais auteur, qui utilise beaucoup de mêmes mots, clichés et phrases à plusieurs reprises, au moment où l'algorithme de compression passe à la seconde occurrence de ces choses, elle sera généralement capable de compresser l'occurrence actuelle mieux que la première occurrence.
Cependant, un effet secondaire est que vous ne pouvez pas vraiment rassembler deux fichiers compressés sans décompresser les deux et les recompresser comme un seul flux. Les connaissances d'un fichier ne correspondraient pas à l'autre fichier.
La solution bien sûr consiste à raconter la routine de décompression qui "hey, je viens de passer à un nouveau flux de données tout à fait, veuillez commencer à construire de nouvelles connaissances sur les données".
Si le format de compression est pris en charge pour un tel code, vous pouvez facilement compresser plusieurs parties en même temps.
Par exemple, un fichier de 1 Go pourrait être divisé en 4 fichiers de 256 Mo, compresser chaque partie sur un noyau séparé, puis les épisser ensemble à la fin.
Si vous construisez votre propre format de compression, vous pouvez bien sûr renforcer la prise en charge de cette option.
Si .zip ou .RAR ou n'importe lequel des formats de compression connus peut supporter cela est inconnu de moi, mais je connais le format .7z peut.
a trouvé cette bibliothèque: http://www.codeplex.com/sevenzipshaparpe
On dirait que cela enveloppe le 7z.dll non géré qui prend en charge la multithreading. Évidemment, pas idéal d'avoir à envelopper du code non géré, mais il semble que ceci est actuellement la seule option qui existe là-bas.
Normalement, je dirais que j'essaye Essayer Intel Parallel Studio, ce qui vous permet de développer un code spécifiquement ciblé sur des systèmes multicœurs, mais pour l'instant, il ne suffit que C / C ++. Peut-être créer juste liber en C / C ++ et appelez cela à partir de votre code C #?
Je ne vois pas comment cela aiderait. S'il appelle une bibliothèque de compression qui n'est pas multi-fileté, appelez-la d'une LIB C ++ qui a été écrite avec Intel Parallel Studio ne va pas le rendre multi-fileté. Est-ce? (Peut-être que c'est, je ne l'ai jamais utilisé)
J'ai récemment trouvé une bibliothèque de compression prenant en charge la compression de bzip multithreaded: dotnetzip . La bonne chose à propos de cette bibliothèque est que la classe Parallelbzip2OutPutStream est dérivée de System.IO.Stream et prend un système.IO.IO.IO.IO. Cela signifie que vous pouvez créer une chaîne de classes dérivées de System.IO.IO.IO.IO.IO comme:
Dans ce cas, nous créons un fichier .tar.bz, le chiffrer (peut-être avec AES) et l'écrire directement dans un fichier.