Многопоточное сжатие в C # - PullRequest
7 голосов
/ 31 июля 2009

Есть ли в .net библиотека, которая выполняет многопоточное сжатие потока? Я думаю о чем-то вроде встроенного System.IO.GZipStream, но использую несколько потоков для выполнения работы (и, следовательно, использую все ядра процессора).

Я знаю, что, например, 7-zip сжимает с использованием нескольких потоков, но выпущенный ими C # SDK, похоже, этого не делает.

Ответы [ 5 ]

7 голосов
/ 31 июля 2009

Я думаю, что вам лучше всего разбить поток данных на равные интервалы самостоятельно и запустить потоки, чтобы сжимать каждую часть отдельно параллельно, если используются непараллельные алгоритмы. (После этого один поток объединяет их в один поток (можно создать класс потока, который продолжает чтение из следующего потока, когда текущий заканчивается)).

Возможно, вы захотите взглянуть на SharpZipLib , который несколько лучше, чем внутренние потоки сжатия в .NET.

РЕДАКТИРОВАТЬ: Вам понадобится заголовок, чтобы сказать, где начинается каждый новый поток, конечно. :)

4 голосов
/ 07 ноября 2012

Недавно я нашел библиотеку сжатия, которая поддерживает многопоточное сжатие bzip: DotNetZip . Приятной особенностью этой библиотеки является то, что класс ParallelBZip2OutputStream является производным от System.IO.Stream и принимает System.IO.Stream в качестве вывода. Это означает, что вы можете создать цепочку классов, полученных из System.IO.Stream, например:

  • ICSharpCode.SharpZipLib.Tar.TarOutputStream
  • Ionic.BZip2.ParallelBZip2OutputStream (из библиотеки DotNetZip)
  • System.Security.Cryptography.CryptoStream (для шифрования)
  • System.IO.FileStream

В этом случае мы создаем файл .tar.bz, шифруем его (возможно, с помощью AES) и напрямую записываем его в файл.

4 голосов
/ 31 июля 2009

Нашел эту библиотеку: http://www.codeplex.com/sevenzipsharp

Похоже, это оборачивает неуправляемый 7z.dll, который поддерживает многопоточность. Очевидно, что не идеально, когда нужно оборачивать неуправляемый код, но похоже, что в настоящее время это единственный доступный вариант

1 голос
/ 31 июля 2009

Формат сжатия (но не обязательно алгоритм) должен учитывать тот факт, что вы можете использовать несколько потоков. Или, скорее, не обязательно, что вы используете несколько потоков, но что вы сжимаете исходные данные в несколько шагов, параллельно или иным образом.

Позвольте мне объяснить.

Большинство алгоритмов сжатия сжимают данные последовательно. Любые данные могут быть сжаты с использованием информации, полученной из уже сжатых данных. Так, например, если вы сжимаете книгу плохим автором, который использует множество одних и тех же слов, клише и предложений несколько раз, к моменту, когда алгоритм сжатия доходит до второго + появления этих вещей, обычно это будет возможность сжать текущее вхождение лучше, чем первое вхождение.

Однако побочным эффектом этого является то, что вы не можете реально соединить два сжатых файла без распаковки обоих и повторного сжатия их в один поток. Знания из одного файла не будут соответствовать другому файлу.

Решение, конечно, состоит в том, чтобы сказать процедуре распаковки, что «Эй, я только что переключился на совершенно новый поток данных, пожалуйста, начните заново наращивать знания о данных».

Если формат сжатия поддерживает такой код, вы можете легко сжать несколько частей одновременно.

Например, файл размером 1 ГБ можно разбить на 4 файла по 256 МБ, сжать каждую часть на отдельном ядре, а затем соединить их вместе в конце.

Если вы создаете свой собственный формат сжатия, вы, конечно, можете создать поддержку для него самостоятельно.

Может ли это поддерживать .ZIP или .RAR или любой из известных форматов сжатия, мне неизвестно, но я знаю, что формат .7Z может.

0 голосов
/ 31 июля 2009

Обычно я бы сказал, попробуем Intel Parallel studio, которая позволяет разрабатывать код, специально предназначенный для многоядерных систем, но пока он работает только на C / C ++. Может быть, создать просто lib в C / C ++ и вызвать это из вашего кода C #?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...