» FreeArc (часть 4)

Bulat_Ziganshin
Булат, добрый день. А Вы не планируете добавить Оценку Сжатия, как в HaoZIP и поддержку ASCII-комментов, как в WinRAR?

Добавлено:
Отлично я написал.."Добрый день" в 03:31))

slech

Цитата:

ну распаковать не могу.

arc lt

Как создавать такие ссылки?

Добавлено:
В отдельном окне.

Vladimyr
Цитата:

множество изменений в вызовах FreeArcExtract

Вызов - это вызов. Колбек - это обратный вызов, типа события.

Bulat_Ziganshin

Цитата:

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

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).


Добавлено:
А почему вообще такое происходит - на небольшом объеме данных tor:3 в разы превосходит по скорости, а на больших объемах чуть-чуть (на одном и том же компьютере)?
Что в принципе творится?

Добавлено:
slech

Спасибо, попробую.

Shuld
FAQ ПО ТЕГУ [MORE]

Bulat_Ziganshin
а CLS_DONE точно вызывается?
у меня что то не пишет нечего

я добавил вот эти строки в simple_codec.cpp

Код:     case CLS_INIT:
        {
            printf("\nInit sample cls\n");
            break;
        }
    case CLS_DONE: //printf("Params: %s",param);
        {
            printf("\nDone sample cls\n");
            break;
        }

Приветствую.
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

Shuld
Жмите Редактировать на любом сообщении где есть интересующие вас теги или оформление, увидите как автор это соорудил.

kalpak
Цитата:

а precomp оригинальном системные функции запускались напрямую с kernel32/msvcrt?
или так же с packJPG.dll, если нет, то как ты их перенаправил в dll без модификации precomp.exe ?

напрямую с kernel/msvcrt. Когда загружается моя подставная дллка, она правит ссылки на системные функции в основном ехешнике, и перенаправляет на свои. По идее подобным образом можно сделать универсальный cls фильтр для любого пакера/анпакера, с единственным условием, что он не будет использовать fseek (или SetFilePointer). Или по крайней мере не перемещать указатель вне буфера cls фильтра (~несколько мегабайт). precomp отличается от обычных пакеров, т.к. он может патчить свое распакованное добро парой байт далеко за сотней мегабайт сзади.


Цитата:

я к чему все это, к тому что раз cls-precomp использует объекты синхронизации и packJPG подменный чтобы распаковывать "налету"
может как то можно их и упаковывать,

можно, конечно, но это надо расбираться и с сжимающей частью программы. Для меня эффективность упаковки по времени не интересна.


Цитата:

а CLS_DONE точно вызывается?
у меня что то не пишет нечего

CLS_DONE вызывается в самом конце, перед завершением процесса (по крайней мере в unarc.dll так). Попробуй MessageBox поставить вместо printf, авось покажется.

Bulat_Ziganshin
Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

Спасибо за подсказки

New alpha version:Delta: fixed bug, also available as delta15.zip
I expect that it will be the last revision of Delta 1.5 algorithm, directed toward speed optimization. Delta 1.5 handles about 200 MB/sec on i7-2600 (1GB/sec using all cores), about 1.5x faster than version 1.0.

Today i've started to work on Delta 2.0, with intent to improve compression ratio

Bulat_Ziganshin

1. Понял про разницу во времени маленьких объемов и больших.
При маленьких объемах, похоже, исходные данные хранятся в ОЗУ, и на диск идет только запись. (Я ведь несколько раз подяд прогоняю сжатие).
При больших объемах, данные реально считываются и записываются. Получается две дисковых операции, скоростные методы преимущество теряют.

2. При новом rep-е появляется еще интересный скоростной вариант: rep+xtor:3:4m:h64k
Один из примеров, везде rep от 11.01.2012:

Без rep-а
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using 4x4:tor:3:4mb:h256kb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 527,930,839 bytes. Ratio 69.6% Compression time: cpu 27.11 secs, real 7.44 secs. Speed 101,866 kB/s
FreeArc 0.67 (December 25 2011) Updating archive: proba5.arc using 4x4:tor:3:4mb
Memory for compression 83mb, decompression 88mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 532,685,127 bytes. Ratio 70.3% Compression time: cpu 24.30 secs, real 7.59 secs. Speed 99,825 kB/s

С rep-ом
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb
Memory for compression 1171mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 435,592,914 bytes. Ratio 57.5% Compression time: cpu 24.15 secs, real 6.94 secs. Speed 109,162 kB/s
FreeArc 0.67 (December 25 2011) Creating archive: proba5.arc using rep:1gb+4x4:tor:3:4mb:h64kb
Memory for compression 1170mb, decompression 1112mb, cache 16mb
Compressed 1,731 files, 757,517,055 => 436,406,848 bytes. Ratio 57.6% Compression time: cpu 22.18 secs, real 6.40 secs. Speed 118,429 kB/s

Добавлено:
Внес исправления

kalpak
CLS_DONE вызывается только из UnloadDLL(), выполняемой перед выгрузкой unarc.dll. можно сделать иначе, просто пока не надо было

какие у тебя задачи?

На тему "Лучший архиватор"
http://pikabu.ru/story/luchshiy_arkhivator_468830

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

просто не нравится смотреть как выходной файл растет а ты должен сидеть и ждать окончания операции (а дома проц/хард медленные еще дольше ждать приходится)

а насчет CLS_DONE, dll не пользовался, только [un]arc.exe

Цитата:

Гипотетически - конечно, да!
То есть это для таких случаев, если они есть?
(для этого нужен какой-нибудь райд, но ведь и проц будет не моего уровня).

достаточно ssd и какого-нибудь ультрабучного процессора


Цитата:

Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?

стандартным, fa сам разберётся


Цитата:

Потестировал я ещё раз свои файлики - к сожалению, при использовании -mx и при отключенных некоторые прекомпрессорах, ошибки всё равно иногда появляются - если же использовать -m9, то архивы создаются без проблем.

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

Bulat_Ziganshin

Цитата:

для l/s - допустимо. степенью 2 должен быть параметр с

Раз допустимы некратные значения, то провел дополнительные эксперименты.
Выслал Вам на e-mail данные. Прошу сообщить, получили ли?
Здесь выкладываю только наиболее интересные результаты.

Провел исследование "некратных" параметров Rep, на версии 2012-11-28.
Метод сжатия - варианты m85 = rep:1g...+xlzma:4mb:h512k:fast:128:mc8

Начну с больших объемов данных, свыше 500 Мб.

Как правило на больших объемах данных степень сжатия небольшая, зависимость от параметров rep тоже небольшая. Достаточно часто оптимум около …24:c8… (…40:c16…)
Странный факт - при чанке c32, на самых больших данных, время работы с параметрами : d4m:s32… несколько меньше, чем без этих параметров.

Данные менее 500 Мб

Объем данных не очень большой, чаще можно найти данные с хорошим сжатием.
При сильном сжатии, зависимость от параметров rep существенная.
Файл 100 000 000 - это enwik8
Папка 359 536 713 (мой архив за 2007 год) - файлы .bmp .mht .xls, есть несколько архивов.
Как уже говорил, метод – mrep :1 g : XX : cYY +… всегда дает примерно то же сжатие, что и метод – mrep :1 g : XX : cYY : d 4 m : sXX +… (параметр s .. повторяет параметр l ..), но не точно такое же. В таблице выделено темно-желтым цветом.

Наблюдения
1. Методы с чанком c32
Метод …40:c32… ВСЕГДА дает лучшие результаты по сжатию, чем …32:c32… Считать ли его лучшим? Не знаю. Интерес могут представлять также …48:c32… и более быстрые (?) варианты с : d4m:s32…
Мне представляется наиболее интересным выбором …64:c32:d4m:s32…

2. Методы с чанком c16
Крайние, для данных таблиц, параметры …80:c16… и …16:c16… всегда неэффективны.
По совокупности параметров интересно выглядит …48:c16:d4m:s24…
Он всегда дает неплохие результаты
Я сделал его основным для m85

Может быть мои эксперименты могут быть полезны для доработки 3rep и 4rep.

Вопрос.
Наблюдал следующее странное явление
При сжатии самой большой папки 2,2 Гб (в таблицах выше отсутствует) интенсивность загрузки винчестера средняя. По окончании архивирования (примерно 40 сек, размер архива 220 Мб), когда архив уже создан, интенсивность работы винчестера резко возрастает и так продолжается около минуты. В течении этого времени работа на компьютере замедляется.
Что это может быть? Копирование временных файлов, индексирование? Может быть это "послезвучие" тоже надо включать во время архивирования?

протестировал сейчас сжатие в zip:

Z:\vhd>Arc.exe -tzip a a.zip -t
Compressed 1 file, 98,420,528,640 => 47,215,067,186 bytes. Ratio 47.9%
Compression time: real 495.72 secs. Speed 198,540 kB/s
Testing time: real 823.18 secs. Speed 119,561 kB/s

т.е. упаковка работает быстрее распаковки

Цитата:

достаточно ssd

Да, я уже так подумал.

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

SREP 3.0 released:-m1f..-m3f: Future-LZ compression; -m3f now is the default mode
-mem: limit amount of RAM used for Future-LZ decompression
-vmfile and -vmblock options fine-tune VM file used in -mem mode
-mBYTES: copy matches longer than BYTES directly from outfile
3x faster compression: I/O and MD5/SHA1 tasks were offloaded into separate thread
unrolled internal loop, unrolling factor controlled by -a option, -a1 is the slowest but requires least memory
-nomd5: don't store/check MD5 checksum of every block
-mmap: use memory-mapped file for match checking by I/O
when necessary, temporary file is created automatically
made stderr always unbuffered (useful for GUIs around srep.exe providing progress indicator)
"srep" and "srep -d" commands now work as a filter if stdin and stdout are redirected
64-bit version now can use >4 GB of RAM
fixed bug when compressing data from pipe (i.e. producer | srep)
Changes since the latest alpha:files compressed with -nomd5 tagged with special flag in the compressed file header, so that -nomd5 is automatically applied on their decompression with appropriate message to user
added date, version, copyright and other exe resources to windows executables
More info at http://freearc.org/research/SREP.aspx


Релиз SREP 3.0:-m1f..-m3f: Future-LZ сжатие; -m3f теперь - режим по умолчанию
-mem: ограничивает объём ОЗУ, используемый для Future-LZ распаковки
-vmfile и -vmblock: опции, настраивающие файл подкачки, используемый при ограничении ОЗУ опцией -mem
-mBYTES: копировать матчи длиннее BYTES байт напрямую из выходного файла
3-кратно ускорена упаковка: I/O и вычисление MD5/SHA1 вынесены в отдельный тред
развёрнут внутренний цикл упаковки, коэф. разворачивания настраивается опцией -a, -a1 - самый медленный режим, но использует чуть меньше памяти
-nomd5: не запоминать/проверять MD5 хеши блоков
-mmap: использовать отображение файлов в память для проверки матчей через I/O
при необходимости временный файл создаётся автоматически (если не указано -temp= без параметра)
stderr никогда не буферизуется (полезно для GUI-программ, выводящих индикатор прогресса для srep.exe)
"srep" и "srep -d": эти команды теперь работают как фильтр, если stdin и stdout перенаправлены
64-битная версия теперь может использовать >4ГБ ОЗУ
исправлена ошибка при сжатии данных, полученных по конвейеру (например, producer | srep)
Изменения с последней альфы:файлы, сжатые с -nomd5, помечаются спецфлагом в заголовке сжатого файла, так что -nomd5 автоматически используется и при их распаковке с выводом соответствующего сообщения пользователю
добавлены дата, версия, копирайт и прочие exe-ресурсы в виндовые exe-файлы
Хотите узнать больше? http://freearc.org/research/SREP.aspx

Bulat_Ziganshin
Булат, а как на счет предварительного теста всех методов сжатия, который я описывал выше? Это совсем не актуально?

Bulat_Ziganshin

Цитата:

Delta: fixed bug, also available as delta15.zip

Отправлено: 01:25 11-12-2012
На новой альфе моя ошибка не повторяется.

Цитата:

kalpak
Слушай, а как думаешь, можно ли сделать тест всех вариантов? Ну прям к примеру сжимаешь 20Гб, ставишь на ночь - он у тебя проходится всеми возможными комбинациями, после каждой проходки архив удаляется, чтобы не засорять хард - потом выдается отчет - время, размер на выходе и выигрыш.
Bulat_Ziganshin
Булат, как ты на это смотришь?

а я тут причём? делай

Shuld
Попробуй тогда после rep добавить exe, хуже точно не будет, а на исполняемых файлах получим улучшение сжатия.

Добавлено:
Shuld

Цитата:

Наблюдал следующее странное явление   При сжатии самой большой папки 2,2 Гб (в таблицах выше отсутствует) интенсивность загрузки винчестера средняя. По окончании архивирования (примерно 40 сек, размер архива 220 Мб), когда архив уже создан, интенсивность работы винчестера резко возрастает и так продолжается около минуты. В течении этого времени работа на компьютере замедляется.

Архивировал папку 7.75 Гб, сразу после создания архива загрузка ц.п. 0-1%, тормозов нет. Метод rep:22m:64:c16:d4m:s32+exe+xtor:4:4m:h1m:l8 Видимо причина в твоем компе.

Bulat_Ziganshin
Ахаха, я же не кодер. Был бы программистом - сделал бы для себя. Я имею в виду - опционально встроить это в архиватор.

Eagle1726
Подскажите пожалуйта,какой алгоритм сжатия лучше подойдет для сжатия файлов мультимедиа?
Если эти файлы уже упакованные, то, по идее, от дополнительной компрессии архиватором будет мало пользы. Другое дело — форматы вроде WAV, которые можно сжимать как с потерями данных (англ. "lossy"; например, в формат MP3), так и без потерь (англ. "lossless"; например, в формат FLAC). Без конкретики это, в общем-то, праздный разговор.

Paramon111
Тормоза наблюдал явственно в случае архивирования сильносжимаемых данных. Там было 2,2 Гб, стало 220 Мб. Время сжатия 40 сек.
На другой папке, приведенной в таблице, чуть меньше 2,2 Гб, где размер архива 1,6 Гб, время 160 сек, такого явного эффекта нет.

Если есть желание и возможность, скиньте мне наиболее интересную свою папку (или часть) для экспериментов. Потестирую и сравню.
Размер несжатых данных желательно 500...700 Мб. Если больше - увеличивается время на полномоштабные эксперименты (50..100 тестов). Если меньше, то это не совсем то, что нужно для rep:1g.

snkreg
а для чего это встраивать в архиватор? как это будет использоваться?

Bulat_Ziganshin

Цитата:

-mx определяется как -m9, так что вопрос просто в везении.

Действительно, в везении - вчера упаковывал одну игрушку (я не "репакер" - просто файлики у себя в порядок привожу...) и вылетела ошибка уже с -m9.


Цитата:

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

7z и рар архивы создают без проблем.
P.S. Если надо что-то протестировать для решения проблемы, то я всегда готов!