Ghost2004
Junior Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Сорри, что торможу - закопался с тестами...
Могу предоставить текущие результаты.
Исходные данные: Rogue Galaxy, DVD-Split (т.е. DVD9 для PS2 разбитый на 2 DVD5 – у PS2 формат DVD9 настандартный, так что записнная двуслойная болванка не прочтётся приставкой – не говоря уж о том, что две DVD5 раз этак в 4-5 дешевле одной DVD9). Два варианта – первый просто RG_compression methods.arc, второй – RG_ExIm_compression methods.arc, - т.е. извлечённые из .iso данные (но не просто так – на втором диски для совместимости два файла по 1 Gb и 1.5 Gb соответственно пропросту дублируются под разными именами, т.е. что-то вроде hard-link'ов в NTFS – так вот я удалил 100% совпадающие файлы – это к вопросу о трудностях при реализации варианта, где iso файл воспринимается как просто каталог + данные файловой системы – впрочем подозреваю, что оно лечится включением сортировки в первую очередь по размеру (или, скажем, введением дополнительной сортировки максимального приоритета для файлов одинакового объёма)).
Результаты следующие (подчёркивание в имени файла можно воспринимать как двоеточие в настройках, ++ - «tempfile в ручную», т.е. сжатие файла .arc до ++, методом указанным после ++)
исходный релиз сжатый rar'ом: 5 430 917 128 (5.05 Gb)
исходный размер:
RG – 7 906 369 994 (7.36 Gb),
RG_ExIm – 7 904 307 412 (7.36 Gb).
RG_delta+lzma_158mb_max_273.arc - 5 163 801 775 (4.80 Gb) – короче, от 158 mb-словаря выигрыш лишь 5%... Сжимала 3 часа – правда скорее всего, мешали другие приложения.
RG_rep1266mb_h27_a99_32.arc – 5 795 086 471 (5,39 Gb) – от rar'а не сильно отстаёт... Хотя длина 32 тут не самая лучшая настройка... Потому как дальнейшие rep:1512mb:h26:32:a99 дают выигрыш лишь в 20.95 Мб – а l32 чаще всего именно для этого и нужно – чтобы уменьшить дистанцию между совпадающими данными для следующего rep'а, который смог бы преодолеть барьер между совпадающими данными.
Оно и видно:
RG_rep1522mb_h26_a99_32++delta+lzma_158mb_max_273.arc - 5.163.393.612 (4.80 Gb) – фактически то же, что и без rep (разница между 1522mb:h26 и 1266mb:mb минимальна – примерно 2 mb).
А вот с ExIm совсем другая картина:
RG_ExIm_delta+lzma_158mb_max_273.arc – 4 482 809 972 (4,17 Gb) – уже серьёзный выигрыш в 15% только засчёт распаковки iso и сортировки их содержмого (только с hard-link'ами в iso разобраться бы – иначе эти самые 2.5 Гб встали бы lzma поперёк горла).
RG_ExIm_rep1200mb_h27_a99_32.arc – 4 168 528 006 (3.88 Gb) – даже лучше просто lzma...
RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32.arc – 3 660 071 213 (3.40 Gb) – вот тут-то выигрыш от второго rep'а налицо.
RG_ExIm_rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc – 3 616 747 587 (3.36 Gb) – результат очень близок к предыдущему.
Ну и наконец:
RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc
даёт 3 322 267 047 (3.09 Gb) – на данный момент это максимум сжатия, который удалось получить... Впрочем, rep:l32 не самый лучший вариант – вполне вероятно, что rep:4096/512/128 дадут лучшие результаты (не говоря уж о варианте l4096/512/128:s32:d158mb).
Speaking of which,
RG_ExIm_rep1512mb_h26_4096.arc – 4 339 992 792 (4.04 Gb) (угу, тоже лучше простого lzma)
RG_ExIm_rep1512mb_h26_4096++delta+lzma_158_273.arc – 3 304 231 764 (3.07 Gb) – таки с максимумом я погорячился, всё же rep:4096 тут оказалась даже лучше двух rep:32...
В общем, буду дальше тестировать – теперь 4096 (с 32 вместо 512 я начал чтобы охватить более широкий набор настроек), затем наверное 512, а потом 128... Ну а ещё попробую поиграться с d158mb:s32/64/128...
Кстати, может имеет смысл выделять один блок памяти для хранения данных, а другой – для хеш-таблицы? А то у меня в win32 (с /3GB /USERVA=2800) avalible physical memory выдаёт в районе 2500 Mb (впрочем, это я ещё не все жадные до памяти приложения повырубал), а ram speed test застревает на 1909 Mb (есть варианты как с этим побороться?)...
Насчёт варианта rep с более усточивым хэшем – c удовольствием постестирую, даже без распаковки, тем более что на RG она бы улучшила сжатие в раза в 1.5, судя по отсортированному ExIm варианту. И думаю что для всех подобных случаев вышло бы примерно то же самое (на 25 Гб SO 3 – так вообще из 18 Гб сжатых rar'ом стало бы наверняка 5-8 Гб  ... Надеюсь только, что она не будет мучить те 8 Гб слишком долго, более 6 часов... И ещё – если будешь реализовывать этот вариант, такое вот пожелание - можно ли без особых трудностей добавить в отладную информацию следующую меру эффективности: сколько сопадений на дистанциях меньше 128 Мб и какой их суммарный размер (т.е. по сути выигрыш), затем то же, но на дистанциях от 128 до 256Мб, 256-512, 512-1024 и т.д (или даже 128-256, 256-512, 512-768, 768-1024 и т.д)? Ведь альтернатива этому лишь возможность воспринимать образы дисков как простые каталоги, а там много подводных камней, вроде тех же hard-link'ов... Да и вообще в смысле распаковки это могло бы устранить проблему прожорливости rep'а – ведь rep:1gb распакуется без тормозов лишь на компе с 2 gb... Другое дело, что для этого варианта (назовём его lrep – (long rep)) придётся исхитряться с распаковкой, используя доступную RAM в качестве кэша и придумывая разнообразные оптимизации... Впрочем, если эта штука будет достаточно быстрой, то можно просто на основании той статистики провести перестановку блоков по 128-1024 Мб и прошерстить их простым rep'ом... Да, и ещё, какие размеры слова там имеют смысл – 128 (ограничив дистанцию до 4-8 Гб) можно испробовать как экстремальный вариант, наподобие 32 для rep?
egor23
Цитата: опять второпях ключевое слово пропустил подобрать подходящую последовательность зачем же лишнюю работу делать самому, пускай FreeArc делает.
т.е.
Пример
есть 4 файла пусть по 2gb
используем rep:1gb, но обработка идёт не последовательно, а параллельно:
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.
2. или возможность задания участков в файлах и их последовательности в обработке.
|
Ну, 1 вариант скорее всего не пройдёт, можно коненчо потестировать вариант с разбиванием iso'шек на куски по 256 mb - но вряд ли будет заметный выигрыш, уж очень это ограниченная штука, данные ведь запросто могут лежать не последовательно, плюс её и без freearc элементарно реализовать... А вот подбор и задание участков и их последовательности увеличит время сжатия в n-1 раз (в неоптимизированном варианте), где n - отношение полного размера данных к размеру куска - надо же провести rep для каждого куска с каждым, а в случае простейшего метода оно будет n(n-1)/2, тогда как для простого rep выходит всего лишь порядка n/2 таких сравнений (плюс n-1 раз придётся создавать tempfile )... Может лучше подобные вещи делать с умом - т.е. используя статистику полученную из lrep...
Впрочем, всё равно потестирую RG с этим, разбив её, скажем, на куски по 512 mb...
З.Ы.
Да, а насчёт памяти – даже в win32 /3G /USERVA=2800 rep:1779mb:h27:a99 проходит в 0.40 версии пропатченой editbin, виртуальная (а также физическая) память при этом достигает 2 368 048 kb  ... А вот lzma по прежнему не пашет выше 159 mb . В 0.50 (и 0.50-no-http) указанная rep:1779mb:h27:a99 не хочет идти – работает только с h24 вместо h27 – если её не пропатчить editbin (если пропатичть, то ведёт себя также как и в пропатченой 0.40). |
