над тем, как сделать это оптимально и пришел к такой последовательности действий:
1) берется кол-во доступных ядер, столько будет потоков (допустим 6 ядер)
2) берется размер файла (допустим 6000 мегабайт)
3) файл разбивается на 6 блоков (столько позволяет количество ядер)
4) размер каждого блока определяется в зависимости от оперативной памяти, допустим при 6000 мегабайт оперативы это выйдет по ~800 мб оперативки на блок (400 мб под сам блок и + столько же для хранения результата сжатия), то есть в сумме это займет 4800 оперативки и немножко останется для благополучной работы системы.
5) после чего результаты сжатия в каждом блоке поочередно записываются в файл, тут уже все зависит от HDD и потоками играться наверное не получиться для достижения скорости
верный ли такой подход или есть какие-то ошибки?
Пара моментов: 1. В итоговом файле нужно ещё указать, где начало отдельных частей. 2. А лучше всего погуглить параллелизуемый алгоритм сжатия или самому найти из существующих самый хорошо параллелизующийся. Это для того, чтобы не пришлось делать N разных частей с разными словарями в итоговом файле, да и суммарный размер, подозреваю, будет меньше.
Главное не пытаться параллельно читать/писать с HDD. Кодировать/декодировать в оперативке параллельно вполне можно
Обсуждают сегодня