В моём посте чётко указано что лучший показатель - у 7zip
что там и как оно в 7zip я не в курсе, если честно. Тоже не использую, и по тем же причинам.
А вот теперь на сцену должны выйти пруфы от тебя. Потому что pigz (многопоточный gzip) обрабатывает архивы в разы быстрее gzip.
ну мы ваще-то с того и начали, но ты зачем-то перевёл стрелки на молотки, WinRAR, и 7zip.
Наверное, это какая-то избирательная слепота, потому что WinRAR показал результат близкий к 7zip
повторяю - что 7zip, что WinRAR - для меня не пруф ни разу.
Поставь да посмотри. Ты же всё равно на любой мой тест будешь изворачиваться лишь бы не признать свою ошибку.
хорошо. только позже. Сейчас у меня времени нет.
При том, что вера в то что т.н. свободные архиваторы при том же количестве потоков покажут кардинально лучшие результаты - это именно фанатизм.
согласен. фанатизм. Но у меня несколько другой подход - я оцениваю архиваторы вовсе не потому, свободный он, или не свободный, нет. WinRAR не свободный, но вот алгоритмы, которые он использует, мне известны. Вопрос в том, что ты будешь им жать. Если киношку, так это изначально бредовый тест, ибо она не жмётся по любому (уже сжата), а если дерево портежей, то тут всё зависит от опций компиляций, которые ты не привёл. Можно сделать несолидный архив, толку от него никакого, за то можно жать хоть по 256 файлов одновременно, ибо в несолидном каждый файл жмётся отдельно от других. Что получается в итоге - меня волнует мало, ибо прямое копирование даёт примерно такое же "сжатие", да ещё и работает вообще независимо от CPU, благодаря DMA (потому такое "сжатие" хоть в 256 потоков не имеет вообще никакого смысла). А вот если у тебя таки солидное сжатие, то сжать N+1 файл ты сможешь только после сжатия Nного. Такой вот странный алгоритм. Он принципиально однопоточный. Конечно ты можешь что-то с этим сделать, но степень сжатия катастрофически упадёт. NoWay. Это просто математика, причём выводы известны очень давно, и сделаны они конечно не мной. В принципе, ты можешь распараллелить блочный алгоритм типа BWT (как в bzip2), но тут тоже проблема - каждому потоку нужна будет своя память, и не мало (сотни мегабайт, а лучше гигабайты), естественно это возможно только на многопроцессорных серверных мамках, где каждый процессор имеет свою память. Многоядерный будет просто ждать, когда дойдёт очередь к единственной в системе памяти. Опять-таки, это вовсе не кривизна ПО, а "кривизна" алгоритмов. К сожалению, математики пока других не придумали. Во всяком случае, в открытых источниках их нет. Я не математик, я быдлокодер, потому затрудняюсь сказать, что этому мешает. Учи матчасть, если тебе это интересно.
ЗЫЖ ладно, мне тут одну НЁХ надо вылечить, т.ч. самозабаниваюсь :)
