EugeneRoshal
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
persicum
Цитата:| Насколько я понимаю, в WinRAR 5.xx дедупликация присутствует только на уровне файлов одинаковой длины? |
+solid в пределах sliding dictionary.
GoblinNN
Цитата:| только я что заметил с этой програмкой. архивы рар4 получаются меньше размером. и в основном на выходе rar4 выходит. может из-за сжатия текста? |
Скорее всего. Степень сжатия у PPMd хорошая. Сложности были со скоростью распаковки и распараллеливанием упаковки.
persicum
Цитата:| Вот для того, чтобы пользоваться одним архиватором на все случаи жизни, нужен новый формат RAR6 - с дедупликацией. |
Лучшие алгоритмы сжатия и дедупликации разрабатываются годами, долго и вдумчиво. Посмотрите на сроки разработки тех же Zstd или SREP. У меня нет возможности выделить столько времени на разработку очередного алгоритма. Это не то, что требуется массовому пользователю архиватора общего назначения типа WinRAR.
Пользователю нужны удобство и набор типовых функций, высокая скорость распаковки, приемлемая скорость упаковки, разумный расход памяти, чтобы можно было распаковать на мобильнике. Если раньше я писал, что с каждым годом важность степени сжатия для массового пользователя снижается, то, пожалуй, уже можно константировать, что этот процесс практически завершен. Если я в 6.0 единственным методом сжатия оставлю "Store", мне кажется, большинство пользователей на это уже не обратит внимания.
Например, в 5.90 алгоритм, используемый в -m1 (fastest), был ускорен на многоядерниках раза в полтора, и размер сжатого enwik9 -m1 изменился с 351 до 303 KB. Я не помню сколько-нибудь заметной реакции на этот счет. Тишина. При этом на тему смены иконок приходили десятки эмоциональных откликов.
Сейчас смена алгоритма скорее вызовет негативную реакцию из-за проблем с совместимостью. Чтобы это скомпенсировать, степень сжатия надо улучшить на большинстве типов данных хотя бы на треть, не потеряв в скорости. Процентов 10 - 15 сжатия мало кто заметит. А ситуация с набором однотипных iso все же редкая. В наши дни, если для скачивания, такие iso выложат упакованными по отдельности или вообще неупакованными. Если для стандартного бэкапа, так для iso скорее надо прописывать упаковку с нулевым сжатием ради скорости. Внутри iso обычно уже пожатые данные, и намного чаще типичный пользователь потеряет время на попытку их сжатия, чем что-то выиграет за счет поиска совпадений в других iso.
На мой взгляд, золотой век архиваторов в смысле сжатия данных остался далеко позади. Многим нынешним пользователям в качестве базового алгоритма хватило бы и tar, но с GUI, шифрованием, восстановлением данных, томами и прочими фичами. А такая ситуация серьезно демотивирует тратить годы на разработку нового алгоритма сжатия. |
Хотя шутку юмора оценил.) Если оставить только Store, юзеры это всё же заметят. Ибо раз уж юзер задействовал архиватор, он всё же ожидает, что размер архива будет меньше, чем размер упаковываемой папки. Даже если всё это хранится на 20 TB диске. Сразу возникнет вопрос: "А зачем нужен архиватор, который не жмет?" 