» FreeArc (часть 4)

Volt_M

Цитата:

(куча мелких файлов zip,exe,rar)

косяк, уберите 7z.dll

egor23

Цитата:

косяк, уберите 7z.dll

а профиль по умолчанию жмёт нормально

Цитата:

косяк, уберите 7z.dll

я ж это в последней альфе поправил. volt_m, у тебя какая версия?


Цитата:

настройки сжатия FreeArcа, чтобы сжимало ОЧЕНЬ хорошо

профиль максимального сжатия. остальное подбирается индивидуально под данные

Добавлено:
Profrager
спасибо, интересная идея

Цитата:

профиль максимального сжатия. остальное подбирается индивидуально под данные

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

Bulat_Ziganshin
666
попробую альфу
--------------------

работает

Цитата:

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

А может, покажете, что сжимаете?
Если что-нибудь несжимаемое, то и не получится.

Может быть воспользоваться сверхплотными архиваторами?
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#2
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=740#5

ZEN369

Цитата:

Я ставлю ультра. Но всё ровно как-то плохо сжимает =( я в этом новичок. Может покажите скрин своих настроек? как образец будет мне =)

Для разных файлов разный подход, нет универсальных настроек. С такими вопросами тебе в эту тему http://forum.ru-board.com/topic.cgi?forum=5&bm=1&topic=30239#1

подскажите как изменить надписи
Press Ok button to start extraction.
Use Browse button to select the destination folder.
If the destination folder does not exist, it will be created automatically before extraction.
в sfx архиве на свои

и второй вопрос - какие оптимальные установки для упаковки ISO файлов

Цитата:

подскажите как изменить надписи

редактором ресурсов или опцией -z подцепить другой комментарий в формате RTF

FreeArc0,67а (18 марта 2011) Метод сжатия –mex7 Особенности Улучшения

Ранее я исследовал метод –mex5
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=280#6
Сейчас предлагаю результаты исследования –mex7.

Метод сжатия –mex7 полностью выглядит так:
rep:512mb+exe+delta+4x4:i0:lzma:16mb:normal:bt4:128, $obj => rep:512mb+delta+4x4:i0:lzma:16mb:normal:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:160mb:92%:145:h23:d1mb+tempfile+4x4:t3:i0:b7mb:ppmd:16:384mb:c7mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 1420mb, decompression 1199mb, cache 256kb
(Требования к памяти зависят от процессора, в данном случае Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-
разрядная, ОЗУ 4 ГБ)

1)    Основной способ сжатия: rep:512mb+exe+delta+4x4:i0:lzma:16mb:normal:bt4:128
При этом параметром по умолчанию для LZMA является :h32mb:
2)    Можно его модифицировать в группах exe и $obj, указав :h64m:
rep:512mb+exe+delta+4x4:i0:lzma:16mb:h64m:normal:bt4:128
В моих тестах степень сжатия оставалась такой же, скорость сжатия увеличивалась примерно на 6%, но требуемая память немного увеличивалась, до 1548 МБ
3)    Альтернативное сжатие всех данных одним методом, без деления на группы:
-m7rep+xlzma:16m:h64m:max (что полностью записывается как
-mrep:512mb+4x4:lzma:16mb:h64m:normal:bt4:128)

Результаты сжатия этих трех вариантов, для одного из тестов, а именно http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=80#13 или http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=720#21
Метод    time: cpu  time: real  Размер архива    Memory Memory
for compression for decompression
1)      628 с    184.8 с    846 822 405    1420 mb    1199 mb
2)      588 c    174.9 c    846 822 238    1548 mb    1199 mb
3)      585 c    149.4 c    845 267 002    1604 mb    732 mb
Альтернативное сжатие без деления на группы получилось самым быстрым и самым сильным. (Памяти использует чуть больше из-за исключения параметра :i0:. При желании его можно добавить в строку.)
В стандартном варианете –mex7 деление на группы при сжатии, видимо уменьшает эффективность использования rep! Мне кажется, что деление на группы эффективно только на очень больших объемах данных?!

Подробности.
Справедливы только для метода сжатия lzma:…:bt4 (может задаваться в виде lzma:…:max)
Сокращенная запись lzma:16m означает lzma:16mb:h32mb
Зависимость от параметра «:h» (размер хеша)
для сжатия по методу вида –m7rep+exe+delta+4x4:lzma:16mb:h32m:max
Метод time: cpu  time: real  Размер архива Memory Memory
for compression for decompression
16m:h128m:max    599 с    179 с    845 250 025    1220 mb    740 mb
…:h64m:…     599 с    153 c    845 250 044    1612 mb    740 mb
…:h32m:…     641 c    163 c    845 250 196    1484 mb    740 mb
…:h16m:…     718 c    182 с    845 251 214    1420 mb    740 mb
…:h8m:…     831 c    211 с    845 250 912    1388 mb    740 mb
Отмечу, что при параметре :h128m: (и более) создавался tempfile, что приводило к заметному увеличению реального времени сжатия, при уменьшении требований к памяти. С точки зрения оптимального соотношения время/степень сжатия такие режимы я исследую отдельно, и выложу позже.
Отмечу так же, что строка 2 отличается от метода 3) в первой таблице наличием exe+delta. Это привело к увеличению времени 149 -> 153, но улучшению сжатия на 16 кб.

Общая характеристика метода –mex7
Метод отличается эффективностью, в основных режимах сжатия использует практически всю память и 4 потока, и если только позволяет объем ОЗУ, предпочтительней, чем методы –mex5, –mex6.

Булат
Просьба оценить мои результаты для использования в FreeArc.

Каким параметром включить использование в ФА срепа вместо репа?

Цитата:

m7rep

на этот параметр ругается чего-то арк...

-m7rep
?

alexseb2007
читай внимательно:

Цитата:

-m7rep+xlzma:16m:h64m:max (что полностью записывается как
-mrep:512mb+4x4:lzma:16mb:h64m:normal:bt4:128)

да и в любом случае, я тебе не советую в этом копаться без понимания...



Цитата:

В стандартном варианете –mex7 деление на группы при сжатии, видимо уменьшает эффективность использования rep! Мне кажется, что деление на группы эффективно только на очень больших объемах данных?!

деление на группы позволяет назначить каждой группе наилучший алгоритм сжатия но с другой стороны не даёт использовать первую группу как словарь для второй. результат - будет лучше или хуже - зависит от везения (т.е. от данных). идеально было бы заменить bcj на алгоритм, который применяет преобразование поблочно по мере необходимости и выдаёт все данные в один выходной поток

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Добавлено:
vasulpr
только ручными настройками. после чего тебе для распаковки нужен будет srep в путях и достаточное место под временные файлы

а как фриарк включить в скрипт?

xanloz
На шапку взгляните:
Цитата:

Inno Setup плюс внешние упаковщики - использование архивов FreeArc в инсталяторах

juvaforza
я уже пробовал, у меня чёт не выходит, может поможете включить в скрипт?

Bulat_Ziganshin

Цитата:

методы -mex5..9 сделаны как раз для разных объёмов памяти. т.е. если тебе не нравится mex7 - используй mex8 и т.д.

Хотел выяснить Ваше отношение к возникающей здесь проблеме.

Во времена 32-разрядных ОС и одноядерных процессоров все было просто - больше словарь - лучше сжатие.
Но сейчас времена изменились - широко используются многоядерные процессоры.
А доступный объем памяти в 32-разрядных ОС остался на уровне 2 ГБ (Ну 3 ГБ, в специфических случаях).
Поэтому эффективное использование, скажем 4-х ядерных (поточных) процессоров возможно только до предела, когда каждый поток занимает 400 МБ (=2 ГБ - нужды системы/4). При дальнейшем увеличении словаря, для потока нужно больше памяти и приходится уменьшать число потоков до 2 (или 1).

Вот она дилемма:
Или многопоточность (эффективность) <-> или сильное сжатие, но при слабом использовании процессора!!!
В том же -mex9 идет уже только 2 потока! И время резко увеличивается.

Может ли эта проблема быть решена в 64-разрядных ОС? Там для одной задачи все равно ограничение памяти 2 ГБ.
Слышал, что в 64-разрядной 7zip размер словаря увеличен по сравнению с 32-х разрядной.

я не знаю как фриарк включить в скрипт мож кто-нибудь поможет?

Bulat_Ziganshin

Цитата:

деление на группы позволяет назначить каждой группе наилучший алгоритм сжатия но с другой стороны не даёт использовать первую группу как словарь для второй. результат - будет лучше или хуже - зависит от везения (т.е. от данных)

Идея понятна.
Но у меня, что на работе, что дома, ВСЕГДА без деления на группы получается лучше. И пока ни разу - наоборот! Что меня очень удивляет!
Вы не пробовали проверить и сравнить мой альтернативный вариант на своих данных?

А может быть, кто из пользователей сравнит и напишет, как получается?

проверил данный алгоритм... на игровых данных кризиса проверял... на 10-15% хуже оказался чем нормальные алгоритмы... так что не стоет его включать его в общую схему.....

Какой исходный объем и сжатый?

Извиняюсь, помогите решить проблему, надо распаковать архив bin 1.2 гигабайт. Но FreeArc его не распаковывает, жалуясь что то там can't allocate память и распаковку прекращает. Он требует вроде 1gb свободной памяти, но столько свободной нету. Я пробовал распаковывать с ключом -lc, но всё равно так же жалуется. А по одному файлу он всё таки распаковывает, файлов только много, так не удобно. help

Цитата:

у меня, что на работе, что дома, ВСЕГДА без деления на группы получается лучше.

ну например возьми группу obj-файлов сожми. вообще, какие у тебя файлы в группу obj попадают?


Цитата:

надо распаковать архив bin 1.2 гигабайт. Но FreeArc его не распаковывает, жалуясь что то там can't allocate память и распаковку прекращает. Он требует вроде 1gb свободной памяти,

распакуй на другой машине, желательно с 64-битной ОС. какое значение на последней закладке в Settings? что даёт arc lt на этом файле?

Цитата:

ну например возьми группу obj-файлов сожми. вообще, какие у тебя файлы в группу obj попадают?

Поясняю.
Те папки, которые я беру для тестирования - все мои реальные, для которых мне как раз и нужна резервная копия, и собственно архиватор.
Мне не интересно экспериментировать на фильмах, музыке и т.п. что мне не нужно.
А мои реальные папки, как ни странно (!) содержат файлы из Excel, Word, Компаса и Корела, PDF, rar, zip, и т.п.
И это не должно быть удивительно. (в группе obj наверное ничего нет)

Цитата:

Bulat_Ziganshin распакуй на другой машине, желательно с 64-битной ОС. какое значение на последней закладке в Settings? что даёт arc lt на этом файле?

На другом компьютере можно было бы тоже попробовать, но пока надо на этом распаковать. На последней вкладке значится 1298mb. arc lt не знаю, попробую.

FreeArc 67a всё тки распаковал с ключом -lc300m

Bulat_Ziganshin
Не знаю, но вроде баг:
Метод rep неправильно пакует cab архивы, если использовать его без дополнительных методов. На выходе получается архив с содержимым cab архива (первого обрабатываемого, если их несколько).
Как ни странно, такой архив даже открывается 7-zip'ом. В свойствах 7-zip и FA показывают, что это cab архив.

Тестировал на версии 0.67a (18.03.2011)

byExit

Цитата:

Не знаю, но вроде баг:
Метод rep неправильно пакует cab архивы, если использовать его без дополнительных методов. На выходе получается архив с содержимым cab архива (первого обрабатываемого, если их несколько).

Распаковывается нормально? Значит это не баг, а фича.

byExit
1. создаваемый архив содержит в себе куски исходных данных, скопированные без изменений - это особенность REP
2. 7-zip распознаёт такой архив как имеющий тип .cab, поскольку он видит cab-заголовок, и не способен распознать структуру .arc
3. старый freearc тоже распознавал это как cab-архив. эта оишбка была исправлена как раз в марте. если маротовсrbq fa неправильно распознаёт архив - пришли его мне. я посмотрю