Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: Shuld
Дата сообщения: 21.01.2012 16:26
Bulat_Ziganshin

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

Удобнее было бы выкладывать данные (xls) не в форуме, а по e-mail.
Мне много что есть написать.

Добавлено:
Bulat_Ziganshin

Взял enwik8 (100 000 000 байт):
Метод Сжатие текста Размер Время, с
Автор: Shuld
Дата сообщения: 26.11.2012 16:30
Не понимаю.
Если архив .7z открывается программой 7zip за 2 сек,
а тот же (!) архив окрывается FreeArc-ом секунд за 10,
то при чем тут фрагментация?
Попробовал сейчас на архиве размером 100 Мб.

Добавлено:
Или сам FreeArc у меня установился в медленную часть винта, или сильно фрагментирован?

Добавлено:
ruduk

У Вас сколько секунд уходит на открытие архива .7z
программой 7zip и сколько - FreeArc-ом?
Автор: kalpak
Дата сообщения: 20.09.2011 12:23
ndch
xtor - это 4x4:tor
xtor/xlzma/xppmd значит это 4x4:method
Автор: Bulat_Ziganshin
Дата сообщения: 21.01.2012 17:28
завтра надеюсь сделать ftp-аплоад на своём сервере

Добавлено:
Shuld
и какие выводы?

Добавлено:
WildGoblin
а ещё можно через uTorrent 3.x передать. там специальный дропбокс есть. у меня белый адрес

нужен точный набор файлов, на котором обнаруживается сбой, и твой каталог "program files\freearc" - чтоб уж точно воспроизвести условия сжатия
Автор: CDK
Дата сообщения: 27.11.2012 19:46

Цитата:
Если архив .7z открывается программой 7zip за 2 сек,
а тот же (!) архив окрывается FreeArc-ом секунд за 10,

антивирь может влиять - фриарк работает же через 7z.dll

У меня фа (и новый и 0.67 от 17.11.2010) 1.5-гиговый рар-архив с доками за 16 сек, а сам рар за 8 сек. НОД32 не влияет.

added: а 7z вообще моментально его открывает

ЗЫ: радует каждый раз при запуске свежего, только скачанного, фа (Portable Windows package) сообщение о том, что есть еще более новая версия
Автор: vishyakov
Дата сообщения: 21.09.2011 15:10
Есть ли в природе DLL, обладающая функциональностью arc.exe или близко к тому? Если нет, то будет?
Автор: vasulpr
Дата сообщения: 21.01.2012 18:08
Bulat_Ziganshin

Цитата:
а над изменениями, которые будут включать в частности и эту фичу, я потихоньку работаю

рад это слышать!
если можно то поделитесь более подробной информацией по этому поводу.
это будет абсолютно новый формат не совместим с предыдущим? в какой версии мы сможем увидеть эти изменения?
также хочется узнать как дела с 0.70 финал, что еще планируется сделать?
Автор: kalpak
Дата сообщения: 21.09.2011 16:00
vishyakov
для упаковки?
если для упаковки то нет
для распаковки unarc.dll
Автор: Shuld
Дата сообщения: 28.11.2012 04:14
CDK
фа 1.5-гиговый рар-архив с доками за 16 сек
added: а 7z вообще моментально его открывает

Так?
Значит не только у меня так?
Автор: WildGoblin
Дата сообщения: 21.01.2012 18:10
Bulat_Ziganshin
Завтра могу всё выложить.

Цитата:
а ещё можно через uTorrent 3.x передать. там специальный дропбокс есть. у меня белый адрес
Можно и так.
Автор: vishyakov
Дата сообщения: 21.09.2011 19:06
kalpak
Жаль. Ну ладно, пусть будет хотя бы декомпрессия.

unarc.dll - это которая из пакета InnoSetup support? Она может распаковать любые архивы FA? А как её использвать-то? Документация на неё и API есть?
Автор: ruduk
Дата сообщения: 28.11.2012 09:06
Shuld

Цитата:
фа 1.5-гиговый рар-архив с доками за 16 сек

сжал игру, и у меня ~10 сек на открытие .rar и меньше 1 сек на открытие тех же файлов, но уже в .arc-архиве. Размер архива ~2 ГБ. Понятное дело .arc все-таки родной формат, а .rar посредством 7z.dll, потому и дольше.

Добавлено:
Специально обновил базы антивируса, почистил временные файлы, продефрагментировал диски, перезагрузил компьютер. После перезагрузки архив .rar открывался 21 сек! Повторное открытие стало меньше (типа ~14 сек), а потом остановилось на 6 сек (наверное кеширование помогает). Для .arc все также меньше 1 сек.
Автор: kalpak
Дата сообщения: 21.09.2011 21:26
vishyakov
да, она самая
а зачем документация? )) там всего 1 функция (ну еще одна, которую вряд ли кто то будет использовать)
и она та в скрипте примера распаковки объявлена
Автор: Shuld
Дата сообщения: 22.01.2012 13:50
Bulat_Ziganshin

Цитата:
и какие выводы?


При сжатии текстовых файлов, при переходе от -m4 к -mex5 наблюдается большой скачек в затрачиваемом времени, и далее до -mex9 одинаковый результат.
Нет плавного изменения времени и сжатия, как для методов -m1...-m4.
Автор: Paramon111
Дата сообщения: 28.11.2012 10:11
Shuld
Исходный размер папки 6.19 Гб, сжатый в FreeArc 5.63 Гб. Время открытия оболочкой FreeArc полторы секунды.
Сжал Winrar, размер 5.59 Гб. Время открытия архива в FreeArc тоже полторы секунды.
Думаю и с 7-zip будет так же. Проблемы не увидел.
Автор: Bulat_Ziganshin
Дата сообщения: 21.09.2011 21:33
vishyakov
дело в том, что dll создавалась как часть проекта InnoSetup support и потому никто её специально не документировал. давай сделаем это прямо сейчас - мне для этого нужен как раз такой свежий человек как ты, который бы мог заметить пропуски в описании

итак: unarc.dll позволяет распаковывать архивы FreeArc. для этого она предоставляет функцию FreeArcExtract, пример использования которой вы можете найти в http://freearc.org/download/testing/unarc2011-09-18.7z

Синтаксис вызова:

errcode = FreeArcExtract(callback, command[1], command[2], command[3], ...);

где errcode - код ошибки (FREEARC_OK=0 при успехе, остальные коды можно найти в Common.h)
command[1]... - команда, которую должен выполнить unarc, список должен завершаться NULL или "". синтаксис поддерживаемых команд можно увидеть, вызвав unarc.exe без параметров
callback - ваша функция, которая будет вызываться из FreeArcExtract, может быть NULL

Пример вызова:

int errcode = FreeArcExtract(callback, "x", "-o+", "--", "a.arc", "*.obj", "*.lib", NULL);

С какими параметрами при этом вызывается callback, можно увидеть, откомпилировав и запустив UnarcDllExample.cpp
Автор: Paramon111
Дата сообщения: 22.01.2012 15:15
Bulat_Ziganshin
у меня при выборе метода -max на папки с большим кол-вом файлов создание архива останавливается и скорость потихоньку снижается до 0. с чем это может быть связано? одиночные файлы упаковывает без проблем.

Добавлено:
а при методе -lc- -max: ОШИБКА: ошибка (рас)паковки в pmm:24:1600mb
Автор: Teemoor
Дата сообщения: 28.11.2012 16:03
Уважаемые форумчане,

не поделитесь версией FreeArc в которой корректно работает сжатие изображений типа jpg, jpeg? На сайте версия 0.666 (20 мая 2010 г.) - она насколько я понял некорректно работает с изображениями. Очень нужно для архивирования огромного объема семейных фотографий.
Автор: slech
Дата сообщения: 23.01.2012 16:35
1. Скачиваем архив - 20 Мб
2. Распаковываем.
3. Выделяем все архивы и выбираем Extract Here.
4. Появляется окошко о подтверждении перезаписи существующего файла, жму Yes to All
5. Окошко продолжает появляться на всех файлах.

Ежели выбрать Extract... и указать Overwrite without prompt то больее никаких подтверждений не требуется.
7z срабатывает коректно.
Автор: vishyakov
Дата сообщения: 22.09.2011 21:24
Спасибо, займусь. Даже мануал напишу :)

А пока у меня еще предложение. Предлагаю встроить препроцессор ZRLE, удаляющий последовательности нулей. Конкретно:

Алгоритм имеет параметр N.
Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

Думаете, RLE бесполезен? А вот и нет.
Например, моя папка C:\windows сжимается таким образом на 4%, в абсолютном исчислении это составило ~1 Гб.
На этих же данных я провёл испытания, взяв N=5, и скармливая выход freearc'у с опциями от -m1 до -m9.
Результат: сжатие улучшилось на 0.6-1.0 процентов.
Мало? Это больше, чем разница между -m8 и -m9. И при этом, как вы понимаете, бесплатно в плане потребляемых ресурсов.

А как изменяется время сжатия данных после их предобработки ZRLE? Трудно оценить, что будет в реальных условиях, но в идеальных, когда данные находятся целиком в системном кэше, время уменьшается на те самые 4%.

Причем в моём случае ZRLE находился в заведомо невыгодном положении - вероятно он сбивал с толку анализатор и exe-процессор.

Что скажете?
Автор: Shuld
Дата сообщения: 28.11.2012 16:36
ruduk

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

Paramon111
Время в случае, если архиватором с момента включения не пользовался? Или после нескольких открытий архивов?
Автор: Shuld
Дата сообщения: 23.01.2012 17:24
Детектив
С ног на голову
В котором принять участие может каждый.

Глава 1. Введение
Ранее я предлагал методы –m81 и –m82 для быстрого сжатия большого объема информации: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1100#10
Можно было продолжить работу и сделать методы –m83 и далее, но мне казалась, что в этом мало смысла. Скорее «для галочки», чем для дела я все-таки довел линейку до –m88. В этой нумерации первая цифра 8 означает использование 8rep или rep:1g, а вторая – примерное соответствие «стандартному» методу с моей поправкой на «оптимизацию». Т.е. метод –m86 является примерным аналогом –mex6. Скачать файл arc.ini с методами –m81…-m88 в архиве можно здесь: Скачать arc2012-01-25.zip с WebFile.RU, и заменить стандартный в папке с arc.exe. (Все методы проверялись на компьютере с 4-поточным процессором, часть – на 2-х ядерном, как поведет себя на 8-ми ядерном – не знаю).

Глава 2. Завязка
Важным моментом является то, что в методах –m81…-m88 нет деления на группы файлов. Казалось, что это должно привести к ухудшению по сравнению со «стандартными» методами, использующими специализированные методы для различных групп файлов. И вот тут-то начинаются чудеса!

Глава 3. Что лучше?
Наиболее корректно проводить сравнение на методах –m88 и –mex8, поскольку у них одинаковый rep и одинаковый основной метод сжатия lzma:32m. Разница именно в отсутствии/наличии деления на группы файлов.
Я протестировал многие папки на своем компьютере и результаты (без купюр!) выкладываю далее, в порядке увеличения размера испытуемой папки. Все папки не какие-то условные, а мои рабочие, для которых я делаю резервные копии.
Метод Размер, байт Время, с
Автор: Paramon111
Дата сообщения: 28.11.2012 16:44
Shuld
Просто создал архив .arc, открыл его, удалил. Потом создал архив .rar, открыл FreeArc`ом и снова удалил.
После включения ПК архивы создавал перед этой проверкой.
Автор: Profrager
Дата сообщения: 23.09.2011 21:09

Цитата:
Пусть встретилась последовательности нулей длинной k штук. Если k<N, то оставляем её как есть. Иначе заменяем её на k нулей плюс один байт равный k-N.

во-первых ты не так описал алгоритм, а во-вторых имхо ты накосячил в своей реализации его) Т.к. lzma (+ rep, входящий в алгоритмы фриарка) гораздо эффективней справятся с любыми последовательностями одинаковых байт, а zrle только добавит лишнюю избыточность. Ты делал анпакер своего ZRLE?
Автор: Bulat_Ziganshin
Дата сообщения: 28.11.2012 23:35
Новая альфа-версия:LZ4: импортирована ревизия от 5-го ноября; lz4:hc:b256k:90% - использовать HC matchfinder, блоки 256кб, оставлять несжатыми блоки с коэф. сжатия >90%
LZMA: в xlzma сохраняет однажды выделенные буфера (для предотвращения фрагментации памяти при сжатии многогигабайтных данных)
-m1/-m2/-m3: изменены настройки для улучшения соотношения скорость/сжатие
Tornado: исправлена ошибка в предыдущей альфе, иногда приводившая к созданию нераспаковываемых архивов в режимах -m1/-m2

New alpha version:LZ4: imported Nov5 revision; lz4:hc:b256k:90% - use HC matchfinder, 256kb blocks, store blocks with compression ratio >90%
LZMA: keep allocated buffers in xlzma (in order to prevent memory fragmenation when compressing multigigabyte data)
-m1/-m2/-m3: tuned params in order to improve speed/compression ratio
Tornado: fixed bug in previous alpha sometimes leading to bad compressed data in -m1/-m2 mode
Автор: snkreg
Дата сообщения: 23.09.2011 22:31

Цитата:
lzma (+ rep, входящий в алгоритмы фриарка) гораздо эффективней справятся с любыми последовательностями одинаковых байт

Полностью поддерживаю, а когда Булат встроит SREP - мне кажется степень сжатия улучшится в разы.
vishyakov
Опиши детальнее, если есть наработки - выложи. Пока не могу судить и делать выводы, ибо не вижу + по сравнению в имеющимися алко во FA
Автор: Bulat_Ziganshin
Дата сообщения: 25.01.2012 03:15

Цитата:
а при методе -lc- -max: ОШИБКА: ошибка (рас)паковки в pmm:24:1600mb

а что означает опция -lc-?


Цитата:
у меня при выборе метода -max на папки с большим кол-вом файлов создание архива останавливается и скорость потихоньку снижается до 0. с чем это может быть связано? одиночные файлы упаковывает без проблем.

так он в конце концов их пакует?


Цитата:
При сжатии текстовых файлов, при переходе от -m4 к -mex5 наблюдается большой скачек в затрачиваемом времени, и далее до -mex9  одинаковый результат.

и для бинарных та же фигня. у тебя есть идеи как сделать лучше?


Цитата:
это будет абсолютно новый формат не совместим с предыдущим? в какой версии мы сможем увидеть эти изменения?

да, несовместимый. возможно, 0.80. я собираюсь интегрировать exe или даже dispack+bcj2 в rep
Автор: Shuld
Дата сообщения: 02.12.2012 05:49
Провел новый тест с архиваторами, в том числе FreeArc от 28 ноября 2012
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=780#19

Метод -m1 показал заметное улучшение по времени и степени сжатия. Причем сжатие на этом (и некоторых других) данных даже лучше, чем у методов -m2/m3. Причина, по-моему, в том, что на больших объемах данных деление на группы скорее вредит, чем помогает. А в методе -m1 групп мало.
(Разумеется, немало данных, на которых метод -m1 показывает результаты по сжатию хуже других методов).


Добавлено:
В тесте приведены обновленные варианты методов -m81...-m89 и добавлен метод -m80
Расшифровка методов:

Добавлено:
Метод Расшифровка метода Примерное соответствие стандартному методу
Автор: kalpak
Дата сообщения: 24.09.2011 10:01
snkreg
я не думаю что в разы
в различных ММ-файлах или еще где-то может даст хороший выигрыш
иногда помогает, а иногда даже ухудшает ситуацию (хотя больше чем на 10% не должен вырасти размер)
вот вчера я сжимал например папку с 50-60 файлами PDF размером общим в 700МБ (все сформированы из одного отчета разные данные только отображены)

precomp+srep+rep+lzma оказался почти такой же как
precomp+rep+lzma

единственное не запомнил сколько время ушло
Автор: Paramon111
Дата сообщения: 25.01.2012 09:33
Bulat_Ziganshin

Цитата:
а что означает опция -lc-?

использовать всю оперативку при упаковке.

Цитата:
так он в конце концов их пакует?

нет. специально ждал минут 40. остановился на 2.3%, скорость 0.
ради интереса попробовал упаковать 2 текстовых файла 1 и 5 мб параметром -max, снова скорость 0. по одиночке упаковываются сразу.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.