почему на виндовой версии 7zip степень сжатия лучше?
Это еще что за чушь? Алгоритм - один и тот же, степень сжатия можно регулировать - для этого есть маны. Только лучшее сжатие будет происходить долго, а быстрое даст большой файл. В общем, надо выбирать ту золотую середину, которая и файл более-менее прилично сожмет, и времени не сильно много убьет.
> LZMA2 лучше параллелится, но дает меньшую степенью сжатия.
4.2 - по обеим утверждениям.
Зачехляй обратно свой тролль-комплект. Ну или готовь обескураживающие результаты тестов и цитаты из сорцов.
rinat@ozone:/tmp/lztst$ time bzip2 -d linux-2.6.38.tar.bz2
real 0m23.881s
user 0m19.937s
sys 0m0.784s
rinat@ozone:/tmp/lztst$ ls
linux-2.6.38.tar
rinat@ozone:/tmp/lztst$ ln linux-2.6.38.tar test1
rinat@ozone:/tmp/lztst$ ln linux-2.6.38.tar test2
rinat@ozone:/tmp/lztst$ ls
linux-2.6.38.tar test1 test2
rinat@ozone:/tmp/lztst$ time 7z a -m0=lzma test1.lzma test1
7-Zip 9.04 beta Copyright (c) 1999-2009 Igor Pavlov 2009-05-30
p7zip Version 9.04 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Scanning
Creating archive test1.lzma
Compressing test1
Everything is Ok
real 2m50.248s
user 4m30.993s
sys 0m2.144s
rinat@ozone:/tmp/lztst$ time 7z a -m0=lzma2 test2.lzma test2
7-Zip 9.04 beta Copyright (c) 1999-2009 Igor Pavlov 2009-05-30
p7zip Version 9.04 (locale=ru_RU.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)
Scanning
Creating archive test2.lzma
Compressing test2
Everything is Ok
real 2m49.657s
user 4m30.621s
sys 0m1.940s
rinat@ozone:/tmp/lztst$ ls -l
итого 1416992
-rw-r--r-- 3 rinat rinat 440483840 Май 27 21:46 linux-2.6.38.tar
-rw-r--r-- 3 rinat rinat 440483840 Май 27 21:46 test1
-rw-r--r-- 1 rinat rinat 64750464 Май 27 21:51 test1.lzma
-rw-r--r-- 3 rinat rinat 440483840 Май 27 21:46 test2
-rw-r--r-- 1 rinat rinat 64770549 Май 27 21:55 test2.lzma
Различия в скорости почти не видно, потому как нет у меня четырёхядерника, а различие в степени сжатия есть, и оно ровно такое, о котором я говорил.
Да, и чтобы тебя добить, цитата Павлова:
LZMA2 uses subchunks (64K of compressed / 2 MB of uncompressed). For each subchunk it strores uncompressed / compressed sizes (5 bytes) and restarts RangeCoder (~5 bytes). So there is overhead of 10 bytes per 50-64 KB.
restarts RangeCoder. Обычно рестарт приводит к снижению степени сжатия, зато можно сжимать несколько блоков одновременно. Отсюда и утверждение — лучше параллелится, но хуже сжимает.
Мне показалось, что ты имел ввиду: LZMA2 по сравнению с LZMA1:
1) хуже сжимает
2) лучше параллелится
Если я ошибся в своём предположении, то я беру свои слова обратно.
P.S. То, что при параллелизации сжатия степень сжатия становится немного хуже, я прекрасно знаю (это видно и на pxz, и на pigz - так что это касается не только LZMA2)
> Мне показалось, что ты имел ввиду: LZMA2 по сравнению с LZMA1:
1) хуже сжимает 2) лучше параллелится
Именно это я и имел в виду. Я сжимал исходники ядра и получил разницу в 20 кб, в то время как перерасход на метаданные должен был составить порядка 9900 байт. Наблюдаю худшее сжатие. Касательно скорости проверить проблематично, так как у меня всего два ядра, а на два и первый неплохо параллелился. Чисто теоретически, факт сброса кодировщика означает то, что соседние блоки могут сжиматься параллельно. Отсюда вывод о том, что LZMA2 лучше параллелится. Собственно, где-то Павлов писал, что цель в этом и была.
> P.S. То, что при параллелизации сжатия степень сжатия становится немного хуже, я прекрасно знаю (это видно и на pxz, и на pigz - так что это касается не только LZMA2)
Вроде бы речь в теме была об lzma, как об алгоритме по умолчанию в 7z.
А вообще я просто завёлся из-за обвинения в «4.2».