Формат сжатия (но не обязательно алгоритм) должен учитывать тот факт, что вы можете использовать несколько потоков. Или, скорее, не обязательно, что вы используете несколько потоков, но что вы сжимаете исходные данные в несколько шагов, параллельно или иным образом.
Позвольте мне объяснить.
Большинство алгоритмов сжатия сжимают данные последовательно. Любые данные могут быть сжаты с использованием информации, полученной из уже сжатых данных. Так, например, если вы сжимаете книгу плохим автором, который использует множество одних и тех же слов, клише и предложений несколько раз, к моменту, когда алгоритм сжатия доходит до второго + появления этих вещей, обычно это будет возможность сжать текущее вхождение лучше, чем первое вхождение.
Однако побочным эффектом этого является то, что вы не можете реально соединить два сжатых файла без распаковки обоих и повторного сжатия их в один поток. Знания из одного файла не будут соответствовать другому файлу.
Решение, конечно, состоит в том, чтобы сказать процедуре распаковки, что «Эй, я только что переключился на совершенно новый поток данных, пожалуйста, начните заново наращивать знания о данных».
Если формат сжатия поддерживает такой код, вы можете легко сжать несколько частей одновременно.
Например, файл размером 1 ГБ можно разбить на 4 файла по 256 МБ, сжать каждую часть на отдельном ядре, а затем соединить их вместе в конце.
Если вы создаете свой собственный формат сжатия, вы, конечно, можете создать поддержку для него самостоятельно.
Может ли это поддерживать .ZIP или .RAR или любой из известных форматов сжатия, мне неизвестно, но я знаю, что формат .7Z может.