» FreeArc (часть 4)

Shuld
http://webfile.ru/6283830 36.3 Mb => 540 Mb

Bulat_Ziganshin
Смотри, к примеру мне нужно сделать репак - и просчитать какой метод сжатия в FreeArc выгоднее всего. Соответственно я выбираю файлы для упаковки, ставлю опцию "Тест сжатия" и ухожу. В это время он пробегается по файлам всеми возможными комбинациями и записывает это в таблицу сравнения, после чего я делаю вывод и выбираю для себя оптимальный вариант.

Paramon111

Цитата:

загрузка ц.п. 0-1%

А при чем тут загрузка цп?
Я писал, что непрерывно работает винчестер, я не писал про загрузку цп.
(при операциях копирования цп загружен очень слабо)

Добавлено:
Скачал файл.
Распаковалось за 15 сек.
Буду экспериментировать.

Bulat_Ziganshin
Как и обещал, выложил тест с новой линейкой методов –m81…-m89 здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#6
Линейка методов имеет примерно равномерный шаг возрастания времени сжатия от метода к методу и составляет 1,4…1,5.
Расшифровка методов:


Добавлено:
Метод Расшифровка метода Примерное соответствие стандартному методу

типа того есть в UPX ( в precomp вроде то же брут но на определенном потоке) кажется
но там то другая ситуация
там размер не большой файла

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

хотя, тогда надо будет знать какие методы комбинировать и как

введена ли разбивка на тома?

Shuld
1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю - это может зависеть от типа данных. хотя с другой стороны, я сам это вообще не тестировал, скопировал готовые настройки из однопоточных режимов, оптимизацией которых я занимался ещё на старом cpu

2. предлагаемые тобой методы сжатия требуют много памяти для распаковки, что заставляет задуматься о том, как их можно использовать, не создавая проблем. я разные способы передумал, сейчас склонился к тому, чтобы всё же встроить srep в fa, но пока это дело будущего

3. на настоящий же момент я оптимизировал rep, добавил его в -m1 и оптимизировал настройки rep в -m2..m4 что повысило сжатие на 1-2% без потерь скорости


теперь что касается внедрения srep. произойдёт это в лучшем случае в 0.80. в январе я сделал очень важную вещь - реализовал поддержку методов с несколькими выходными потоками (как bcj2 в 7-zip). srep в fa будет сделан на основе нынешнего режима -m1f, но сжатые данные будут записываться в два потока - поток литералов и поток матчей. литералы будут писаться (и сжиматься дальнейшими exe+delta+lzma) сразу, а матчи копиться в памяти, и по окончании данных сортироваться по src и только затем сохраняться в архив. соответственно, при распаковке я смогу читать данные из обоих потоков параллельно и сохранять в памяти/vmfile содержимое будущих матчей

итого - и при сжатии, и при распаковке чтение и запись данных будет осуществляться чисто последовательно, при этом будет использоваться объём памяти, примерно равный 10% от объёма сжимаемых данных. при необходимости его можно дальше сократить - при упаковке за счёт увеличения -l, при распаковке - за счёт сохранения содержимого матчей во временном файле. помимо этого, можно ещё выцыганить несколько процентов сжатия, используя после srep обычный rep сч небольшим словарям и размером матча, к примеру rep:96m:32


кстати, пример распаковки 100 гб файла (со 100 гб словарём!!!) с использованием всего 100 мб памяти:

D:\>srep64i -d -mem100m m1f.srep nul
100%: 55,214,690,844 -> 98,420,528,640: 56.10%. Cpu 112 mb/s, real 84 mb/s
Matches 0 68925 39805211, I/Os 0, RAM 0/60, VM 0/8808, R/W 221352/221352

Добавлено:
Архиватор Размер словаря

kalpak
Ну да, вот я и думаю, что было бы удобно в FreeArc реализовать подобное. Ну ничего, что долго, зато автоматизированно и в итоге оптимальный результат

Shuld
У меня винчестер бывает нагружен при упаковке или распаковке ультра быстрыми методами типа xlz4, rep. Просто запись на диск не успевает за архиватором при скорости допустим 200-300 mb в сек. В этом случае винчестер еще нагружен сек 5-7 после создания архива на такой скорости.

Добавлено:
Shuld
Этот архив у меня распаковывается за 8 сек.

Цитата:

хотя, тогда надо будет знать какие методы комбинировать и как

Когда-то на форуме видел сообщение автора Ultra7z и, по его словам, он хотел сначала написать пограмму типа UltraFA, но остановился на Ultra7z, т.к. ему было проще разобраться с опциями 7-zip, чем с FreeArc.

QSQ
FreeArc — планы на будущее

Bulat_Ziganshin
что-то svn не пашет, или он куда-то переместился?

ruduk
ну так потому как в 7z только lzma,ppmd эффективны да и нету там возможности подкл. внешние архиваторы.
а тут очень гибкий архиватор
ну наверное кроме ppmd для текста и lzma для остального хватит, правда тут еще есть препроцессоры разные так что все равно сложная задача

WinRar
Switch -AG[format] - generate archive name using the current date and time

Цитата:

N archive number. WinRAR searches for already existing archive with generated name and if found, increments the archive number until generating a unique name.

FreeArc
-ag --autogenerate

Цитата:

Автоматическая генерация имени архива. К имени, указанному в командной строке, добавляется информация о текущей дате и времени. Например, “backup.arc” -> “backup20050302114328.arc”. Можно также явно указать формат добавляемой к имени архива строки в формате Си-шной функции strftime()

Bulat_Ziganshin
Есть ли возможность создавать архивы с добавлением возрастающего уникального номера в имени архива ?
Если нет, можно ли такое добавить ?

Спасибо.

Добавлено:
Я в шапку добавлял в FAQ


Цитата:

Q: (консольная версия) Как использовать параметр -ag для автогенерации имени архива?
A: Пример: arc a -ag%Y%m%d MyArc_.arc *.txt --> MyArc_20091020.arc

Теперь же я получаю:
MyArc_md.arc

Что-то менялось ?

В справке: Список опций ничего не указанно.

Добавлено:
Мой пост был составлен - 02:50 22-10-2009
Я скачивал версии за 2009 год и получю то же самое.


Что может быть не так ?

Добавлено:
Разобрался:

Код:
Arc.exe a -ag%Y-%m-%d ef--.arc *.txt

Bulat_Ziganshin, смените на сайте

Цитата:

FreeArc — планы на будущее
Трекер: список планируемых улучшений по версиям
Версия 0.70 (декабрь 2011)
•полная поддержка zip, rar, 7z и других архивных форматов

А то время потерял пытаясь найти 0.70 для скачивания. и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

Цитата:

Версия 0.75
•алгоритм сжатия SREP
•поддержка LZMA со словарём до 1 гб

В версии 0.67 в виде экспериментальных опций включены (работают)?

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..
p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом, лунаскейпом (браузеры) и другими безплатными программами.

-x@excluded_files.txt

Цитата:

*\_svn\* #test
*\.svn\*
*\webui\aspnet_client\*
*\webui\*.config //test
*\webui\Web.config.model
*\webui\robots.txt
*\webui\obj\*
*\webui\Views\Web.config
*.mp3
*.cs
*.resx
*.webinfo
*.csproj
*.xsd
*.xsx
*.user
*.Publish.xml

Т.е. если добавить коментарии в файл excluded_files.txt, то он перестаёт верно отрабатывать.
Можно ли добавить поддержку комментариев в excluded_files как это есть в WinRar ?

kalpak
У меня была идея чтобы (перед сжатием) анализировать какие у сжимаемых файлов расширения и, на основе этого анализа, составлять "свой" arc.groups, в котором были бы только расширения файлов, которые сжимаются, и методом перекидывания определенных расширений файлов между группами $text, $binary, $default, ... каждый раз сжимать FreeArc'ом методом [-max] и с отключенной опцией "Авто-определение типов файлов".
Сжимать сразу файлы всех расширений не нужно, сжимать сначала только файлы какого-то одного расширения.
Наименьший архив даст "правильный" arc.group -файл, в котором можно будет увидеть в какой группе были те или иные расширения файлов, что поможет выбрать наиболее эфективные цепочки методов.
Потом переходить к другому расширению... вроде того как работает Ultra7z.
Конечно никакого анализатора я не писал (ибо незнаю как), я просто сжимал пару раз одни и те же файлы, но расширения сам вписывал в разные группы. Выигрыш в размере архива получался в лучшем случае от 2 до 3 % меньше по сравнению с сжатием, когда опция "Авто-определение типов файлов" была включена. А в остальных случаях даже 20% увеличение размера.
Т.е. то, как сжимать файл, пускай выбирает сам FreeArc.

Bulat_Ziganshin

Цитата:

1. твоим результатам по настройке параметров fb и т.п. я не очень доверяю

Для lzma:fast и lzma:normal поведение существенно отличается. В последнем fb заметно влияет на скорость.

Цитата:

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

их можно использовать и с другими размерами rep. Правда, эффективность упадет...

Я вообще хочу сказать вот что.
Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая (в последнем тесте 2%), они по-существу выполняют роль дожатия. Очень много зависит именно от rep-а.
1. Поэтому для быстрых методов (-m1) нужен именно быстрый rep.
2. Для более сильного сжатия нужен rep с оптимизацией не на скорость, а на сжатие (если такое возможно), как полноправный метод
3. Для ультра сжатия возможно вот что.
У меня часто бывает так: скопировал из интернета прорамму/книгу/музыку, распаковал и оставил вместе с архивом. Или, допустим файл word-а запаковал, отправил по e-mail, да и оставил оба экземляра.
Короче: у меня на компьютере часто хранятся архивы и они же, но распакованные. Возможно, у других пользователей то же самое.
Зачем сжимать 2 раза одно и то же?
Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.
Время займет немало, но, возможно увеличит степень сжатия.
Кто-нибудь такое уже реализовывал?

Добавлено:
Или другими словами, все архивы распаковываются, и используются как словарь.

Bulat_Ziganshin
Насколько я понял ФА определяет тип файлов по их расширению, но часто расширение файла не совпадает с его содержанием.
Но есть такая утилитка которая независимо от расширения правильно определяет тип файла, если ее интегрировать в ФА то можно просто получить халявный прирост сжатия.

Очень хотелось бы увидеть ее в ФА, хотя бы опционально. Что скажите?

Bulat_Ziganshin
Нужно окошко в конце тестирования, а сейчас просто происходит закрытие

Код: START /wait FreeArc a -ag%%Y-%%m-%%d--%%H-%%M-%%S -t7z -ep1 -ed -t -r update-- ..\..\PrecompiledWeb\* -x@excluded_files.txt

Цитата:

А то время потерял пытаясь найти 0.70 для скачивания.

спасибо, исправил


Цитата:

и версия 0.67 после установки пишет что появилась что-то новое, но по факту скачать можно её-же..

считай, издержки альфы


Цитата:

В версии 0.67 в виде экспериментальных опций включены (работают)?  

нет, я это буду делать после выпуска 0.70


Цитата:

Что-то не могу сохранить настройки через GUI, при повторном заходе чекбоксы и все остальное по дефолту..

в диалоге settings всё сохраняется


Цитата:

p.s. В идиале было бы приятно видеть автоматическое обновление сабжа как это происходит с лисой, хромом,

согласен но тут и так много недовольных задержкой с выходом 0.70

Добавлено:

Цитата:

что-то svn не пашет, или он куда-то переместился?

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


Добавлено:

Цитата:

Тестируя с одним размером rep-а, разница по сжатию между последущими tor и lzma очень небольшая

ты на чём-нибудь кроме своего бэкапа тестировал? вот на первом же нормальном файле:

D:\Testing>fazip 4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 31,546,433: 31.55% Cpu 7 mb/s (13.868 sec), real 36 mb/s (2.647 sec) = 524%

D:\Testing>fazip 4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 36,668,388: 36.67% Cpu 28 mb/s (3.354 sec), real 142 mb/s (0.671 sec) = 500%


Цитата:

Можно модифицировать rep так: он распаковывает в доплнительную область ОЗУ (tempfile) все архивы rar, zip, exe (которые попадают в область сжатия), а "простые" файлы в другую область и сравнивает. Если находятся совпадения, данные в "архивном" ОЗУ не трогаются, а в "простом файловом" дается ссылка на соответствующий архив.

блестящая идея, я лично её раньше не встречал

vasulpr
ФА использует файле групп
а то что с расширением xxx имеет тип не подходящий для группы - это разве проблема архиватора
это хитрость и проблема пользователя, хотя я не знаю когда бы это расширение не совпадало с его содержимым
даже если .dat файл это фильм или не фильм то для него используется lzma
откуда такой пессимизм ?можно примеры, которые часто встречаются, потому как для редких случаев это не реентабельно

тем более можно самому предложить свой файл групп или изменить существующий
а ФА делает анализ но только кажется на проверку мультимедия

или же не надеется на архиватор и самому прописать метод сжатия

похоже, что архиватор сдох, не доделавшись. планы на октябрь даже в 2012 году не реализованы. а бетккам уже четыре года будет.

QSQ гуляй

vasulpr
Булат знает что такое TrID - http://forum.compression.ru/viewtopic.php?p=3799#p3799

Цитата:

ты на чём-нибудь кроме своего бэкапа тестировал?

Я не о том.
Я о
rep +tor
rep+lzma
!!!
В том то и дело, что отдельно взятый tor сильно уступает lma, а в связке с rep эта разница становится почти символической.

Чем-же будем жать? Nanozip-ом?

Цитата:

Но есть такая утилитка которая независимо от расширения правильно определяет тип файла

К сожалению она не может идентифицировать даже FA SFX архивы, ибо нет сигнатур для них в базе.

Shuld
D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:tor:8m dll100.dll nul
100%: 100,000,000 -> 32,368,300: 32.37% Cpu 28 mb/s (3.448 sec), real 129 mb/s (0.738 sec) = 467%

D:\Testing>C:\Testing\rep\017\fazip rep:64+4x4:lzma:8m:fast dll100.dll nul
100%: 100,000,000 -> 29,434,451: 29.43% Cpu 7 mb/s (14.492 sec), real 43 mb/s (2.236 sec) = 648%

ещё раз - у тебя в бекапах половина уже сжатые данные, их и не сожмёшь ничем после ловли повторов

Evgenii66
Нет, всё тем же FreeArc-ом.
Удивлён? =)