» FreeArc (часть 4)

Bulat_Ziganshin

Цитата:

глядя на этот флейм я вроде допёр как улучшить сжатие связки (s)rep+lzma

ежики незря, значит, приснились . Правду говорю

Bulat_Ziganshin

Цитата:

правда копирование по 32 байта на больших дистанциях будет тем ещё цирком - даже если хватит памяти для сжатия...

32 еще куда ни шло) а вот 16 или 8 длина поиска - это да) на 4 гб файле у меня часа 2 винт будет мучить)

P.S. на сколько увеличивается скорость обработки подобного большого файла с маленьким размером строки поиска, если hdd сменить на ssd? Стоит ли оно того? Помню ты писал чего-то про ssd, но уже не помню какая разница была.


Цитата:

если мы при запуске srep знаем с каким словарём будет lzma, то надо просто пропускать тело совпадений при дистанции меньше lzma:dict - поскольку точно известно что их и lzma cожмёт, причём куда эффективней

гуд идея, но по-моему ты уже где-то писал пободное)

Цитата:

получается что оптимальным может быть такой вариант:
...

хорошо, если можно было бы все эти параметры условий задавать вручную,а не юзать статичную модель.

подобное есть в моём lzp, но не то. там просто по типу "строки от 32 байт с большой дистанцией, от 512 с маленькой". а вот в таколм виде мне почему-то казалось сложно сделать. и вообще это надо для начала в rep, там проблем с мелкими совпадениями не будет

что касается hdd->ssd, то чтение маленьких блоков данных быстрее примерно на два порядка. но ради одного srep я не вижу смысла на ssd переходить - ибо у тебя-то упакуется быстро, а вот потом как распаковывать? достаточно иметь озу на 2-4 гига больше чем у своих пользователей

Добавлено:
вообще в srep есть что улучшить. я например знаю как увеличить скорость сжатия в несколько раз, но кому и зачем это нужно?

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

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

ещё была идея - сделать LZ наоборот. сейчас precomp, как и положено LZ, записывает откуда из истории надо скопировать данные на текущее место. тут же наоборот - при декодировании данных сразу будут определяться места в выходном файле куда их надо записать. эта идея должна была разрешить проблемы с нагрузкой на кеш диска при распаковке, но тут тоже потенциальные проблемы - во-первых, архиватор при распаковке обычно считает crc распаковываемых файлов для проверки целостности, здесь это придётся делать отдельным проходом. во-вторых, при кусках данных в 512 байт запись такого куска в выходной файл, я боюсь, может потребовать сначала чтения целого кластера (4кб, а на ssd и все 128 кб)

Bulat_Ziganshin

Цитата:

что касается hdd->ssd, то чтение маленьких блоков данных быстрее примерно на два порядка. но ради одного srep я не вижу смысла на ssd переходить - ибо у тебя-то упакуется быстро, а вот потом как распаковывать? достаточно иметь озу на 2-4 гига больше чем у своих пользователей

загрузка винды/основных прог + своп-файл + srep = ssd Оперативки 8 гб. Винда кеширует 4гига где-то) Все равно мало)

По теме топика.
Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз. А то с постоянной его величиной геморно как-то создать задуманное)
З.Ы. мож это все и расписано в исходниках, но я тока мельком реп смотрел, так что сильно не бить!

я не понял твоего вопроса

Цитата:

вообще в srep есть что улучшить. я например знаю как увеличить скорость сжатия в несколько раз, но кому и зачем это нужно?

ну в общем то не особо нужно, но полезно

Цитата:

например, у меня была такая идея - если сделать srep первым алгоритмом в цепочке сжатия, то при распаковке он будет последним. тогда получится что временный файл при распаковке не нужен

Ну сейчас в основном пакуют rep(.arc)->srep->lzma, дабы снизить многократные рандомные обращения к винту в момент распаковки srep убрав излишки rep'ом.
Цитата:

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

тож думал об этом, только проблем таковых не видел) Да и не вижу сейчас 1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все. 2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.
Цитата:

сейчас precomp, как и положено LZ, записывает откуда из истории надо скопировать данные на текущее место

наверное ты имел ввиду srep.
Цитата:

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

тока пакер будет небось раз в 10 сложнее текущего)
Цитата:

архиватор при распаковке обычно считает crc распаковываемых файлов для проверки целостности, здесь это придётся делать отдельным проходом

нда, реально проверочный проход был бы лишним..
Цитата:

во-вторых, при кусках данных в 512 байт запись такого куска в выходной файл, я боюсь, может потребовать сначала чтения целого кластера (4кб, а на ssd и все 128 кб)

так и вижу анти-рекламу: srep - убийца ssd В текущей реализации lz винда будет кешировать запись, а там уже фигушки на таких расстояниях..)


Цитата:

я не понял твоего вопроса

фильтр=еще один алгоритм, типа delta, rep и т.д. Хочу алгоритм оптимизации dds'ок попробовать вделать.

Цитата:

По теме топика.
Возможно ли реализовать фильтр в ФА с динамически меняющимся размером блока? Т.е. на входе надо детектить необходимый заголовок и соответственно подстраивать текущий блоксайз

да, конечно. на уровне API, предоставляемого FA, есть просто операции "прочитать N байт из входного потока" и "записать N байт в выходной поток". и вообще проще написать прогу, работающую с stdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит


Цитата:

1)как бы не проблема вовсе - не думаю, что кому то понадобится из срепа распаковывать только часть данных, все равно времени это займет не меньше, чем все

ну а как инсталяции, где можно установить то или это?


Цитата:

2) дак никто не мешает сначала все (или пофайлово) в прекомп сунуть, а потом srep+lzma пакануть. Я тут ничего проблемного не вижу.

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

Добавлено:

Цитата:

тока пакер будет небось раз в 10 сложнее текущего)

нет. можно даже сейчас реверсировать файл и сжать его нынешним srep - тогда ссылки на "прошлое" автоматом станут ссылками на будущее ну а затем "реверсировать" выходной файл srep и готово

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

если же буфер переполнился, то из него выкидывается *содержимое* наиболее далёких и длинных LZ строк (в надежде что на практике будут выкидываться только строки с длиной >>4кб), при этом:

- если у нас есть физический выходной файл (не stdout) и строка достаточно велика (N*128kb), то мы её сразу на нужное местои записываем
- если у нас есть физический входной файл, то строку просто выкидываем - потом скопируем из него
- иначе - скидываем строку в temp file

ну и вместо самой строки делаем отметочку как мы с ней поступили. когда дело дойдёт до декодирования этого места - поступаем соответственно этой отметке

что тут действительно имеет нехилую логику - так это декодер. зато реализуется вековая мечта человечества - распаковка с 10 гб словарём с буфером в 500 мб


хотя может всё это и не TRUЪ, а правильно - разбить данные на 128 кб куски, посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

Цитата:

ну а как инсталяции, где можно установить то или это?

Обычно где есть выбор либо то, либо это устанавливать, архив(ы) с этими файлами на выбор не на столько велики, чтобы для них использовать srep, rep'а хватает. Не знаю, мне пока такое не требовалось на больших объемах данных
Цитата:

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

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать
Цитата:

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

и то хорошо
Цитата:

и ссылки на них хранятся в отсортированном по destination offset виде.

представляю сколько времени надо будет декодеру отсортировывать список каждую итерацию..особенно где нить в конце, когда уже записей под несколько десятков тысяч. Тормозить же будет не хило
Цитата:

а распаковку сделать так - в памяти выделяется блок заданного пользователем размера (порядка 500 мб), при распаковке LZ-строк они в него записываются и ссылки на них хранятся в отсортированном по destination offset виде. ну и соответственно используются и удаляются из буфера по мере распаковки файла

подобная идея у меня родилась давно, но даж боюсь браться за такое
Цитата:

а правильно - разбить данные на 1228 кб куски

а почему именно эта цифра?
Цитата:

посчитать между ними корреляции (тем же самым srep в частности), и затем разложить эти куски в правильном порядке чтобы их дальше уже по человечески ужал обычный lzma

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

Добавлено:

Цитата:

и вообще проще написать прогу, работающую сstdin/out, а затем уже думать о фильтре. может тебе и внешнего фильтра хватит

кстати заметил такую штуку: lzma_x64 (или как его там) в виде внешнего фильтра один раз из 10 вешает упаковку на 0%. При чем он как бы чего то ждет, не отъедая % от проца. Закрываешь, запускаешь заново - норм отрабатывает.

Цитата:

в любом случае и в цепочке srep->precomp->lzma будут временные файлы...если ты, конечно, прекомп не хочешь в ФА встраивать

precomp вполне может распаковывать stdin->stdout, просто его автор не чешется


Цитата:

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

почитай какую-нибудь книгу про алгоритмы и структуры данных. вставка в упорядоченное дерево/B-дерево/пирамиду - log N


Цитата:

а почему именно эта цифра?

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


Цитата:

это типа xdelta будет с автоматической разбивкой файла на нужные куски и сравнением их друг с другом?

наверно да

Не обращаем внимания

Bulat_Ziganshin
По GUI улучшения не придвидятся ?
Показ иконок, поддержка перетаскивания мышью и прочие радости.
Я пока немогу мотивировать всех в компании перейти на FA

это как раз те две вещи, которые в gtk2hs очень сложно реализовать

мдя, жаль ... будем ждать.
сдаётся мне неизбежать перехода на 7z, а затем на FA - как он подоспеет.

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

Добрый вечер!
Хотел спросить, нельзя ли с делать следующее:
1. чтобы srep сам паковал все файлы в один целый файл, а то просто цепочка, например, 7z (не сжатый) => srep, не всегда удобна для ее распаковки. и можно сделать так, чтобы он был наточен на srep
2. объединить srep + delta, просто как бы цепочка srep => delta, опять таки не всегда удобна

И еще, если кто знает подскажите пожалуйста, здесь.

slech

Цитата:

Я пока немогу мотивировать всех в компании перейти на FA

А оно надо ?
Зачем менеджеру по экологической обстановке комп ?
Прошло время архиваторов для масс.

ndch
надо, разработчики используют WinRar.

ну и пусть используют, что за горе ?
Удобство интерфейса (gui, интеграция) и достаточное количество поддерживаемых архивов (zip rar 7z) - вот главное преимущество WinRAR.

Прошу прощения, возможно вопрос уже поднимался, я не нашел. Мой пример: файл 12Гб (игра с установщиком на IS, дефолтная распаковка происходит при помощи IsDone). 2 .arc архива упакованы в 1 srep и снова в arc. При установке возникает ошибка в CRC и всё отменяется. Разархивировал .arc, попробовал напрямую srep -d, то же самое - ошибка, прекращение распаковки. Открыть файл упакованный srep в архиваторе нечем, FreeArc не берет (возможно есть способ подключить srep, чтобы брал?). Есть ли способ при распаковке не останавливаться при ошибке, а пропустить и продолжить разархивацию?

Aroyl

Цитата:

возможно есть способ подключить srep

смотри "How to set up FreeArc to use new SREP in filter mode" на этой странице последний вариант подключения

Aroyl

Цитата:

Есть ли способ при распаковке не останавливаться при ошибке, а пропустить и продолжить разархивацию?

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

SREP 2.0 was released:

* -m3: new default compression mode that finds byte-exact matches; so srep:m3 outperforms rep+srep:m2
* -temp=FILENAME option that allows to use stdin-to-stdout mode without any restrictions (all external data required for compression/decompression are stored in this file)
* -c option to explicitly specify hash chunk size
* -s option to specify size of input data
* "srep file" and "srep file.srep" syntax now supported for compression and decompression respectively, simplifying program usage and allowing to just drag-n-drop file to executable's icon in order to compress or decompress it
* on disk overflow (or other write error), program displays message, deletes outfiles and returns dos error code
* compression memory usage was reduced by 8 mb

The only change after 1.91 is -s option - it allows to compress from stdin by specifying maximum possible input data size:
cat file | srep -s100m - file.srep

By default, -s25gb is assumed (and 1 gb of memory is allocated for hashing!)


Добавлено:
Aroyl
непонятно, кто ты в этом сценарии? tсли автор репака, то зачем тебе как-то извращаться - просто не используй srep

не распаковывается на твоей собственной машине, как я понимаю?

ruduk

Спасибо большое за информацию, srep подключил.

Profrager

Тогда уж билд не srep'а, а IsDone.dll - как я писал, она ответственна в данном случае )
В моем случае было бы удобно, если бы при установке (распаковке) выводился запрос на пропуск найденной ошибки и продолжение.

Bulat_Ziganshin

В сценарии я - конечный пользователь репака, устанавливаю на своей машине. Установка игры длится больше часа, требует 41Гб места и прерывается на 75%. После чего все временно распакованные архивы удаляются и установка отменяется. Я вытащил таки из srep'а конечный .arc c файлами вручную, распаковал его Freearc'ом, просто неудобно, что часть файлов распаковалась, всё остановилось из-за одного файлика, остальные пришлось опять же вручную частями извлекать. В связи с этим я и задал вопрос - вдруг есть ключ, позволяющий arc.exe при распаковке игнорировать ошибки или хотя бы не прерывать распаковку (скажем генерировать сообщение об ошибках уже после распаковки). Как я понял, такого ключа нет.

Bulat_Ziganshin

Цитата:

SREP 2.0 was released

увидел, обрадовался, думал увижу -m4, а нет, еще рано для него)

Цитата:

The only change after 1.91 is -s option - it allows to compress from stdin by specifying maximum possible input data size

теперь для комплекта осталось включить в freearc поддержку подобной переменной для arc.ini, чтобы корректно через stdin+stdout отрабатывало.

И как обычно большое спасибо за релиз)

Aroyl
а не проще на другой машине распаковать? у меня самого srep сбоит, я грешу на разгон

Bulat_Ziganshin

Вопрос с установкой решился. Вроде бы помогло увеличение объема файла подкачки (Win7x86, родные 4Гб, своп поставил "рекомендовано системой"). Ещё возможная проблема (подсмотрел на сайте где брал) - кеширование антивирусом распаковываемого файла, но это надо тестить. Распаковать на другой машине можно, только долго опять же. Всё к лучшему: пока мучался с игрой - познакомился с классным архиватором) Надеюсь, когда-нибудь и мою просьбу прикрутишь. Удачи

Aroyl

Цитата:

В сценарии я - конечный пользователь репака,

что этого за репак (название, размер, где лежит)?

Добавлено:

Цитата:

конечный .arc c файлами вручную, распаковал его Freearc'ом

дайте результат с этого фала
arc lt file.arc

SREP 2.91 alpha:

* -f: future-LZ compression; -m1f..-m3f as shortcuts
* -mBYTES for future-LZ decompression
* -nomd5: don't store/check MD5 checksum of every block

"srep -f infile" performs 2-pass compression, storing in the compressed file references to forthcoming LZ matches
"srep infile.srep" decompress such file without additional I/O - all matches are stored in dictionary. Thus, it may decompress from stdin to stdout w/o tempfiles

Unlike ordinal LZ compressors, decompressor's dictionary saves only data that will be really used at some future moment. This significantly reduces RAM needs. Examples:

1) 22 gb file from LostPlanet2 compressed down to 7 gb and require 2 gb of RAM for decompression. For comparison, REP:2gb compressed the same file only to 8.7 gb - i.e. 20% more

2) dll700.dll from my testset:
184 mb: compressed with lzma:64m
177 mb: compressed with rep:256m+lzma:64m
171 mb: compressed with lzma:256m
121 mb: compressed with srep+lzma:64m, while only 200+64 mb RAM required for decompression

The only way to limit memory usage at decompression is -mBYTES option - it will store in RAM only matches less than BYTES long. Other matches will be copied, as usual, directly from output file (therefore you can't decompress to stdout with -m). Example:
Код: srep -f infile
srep -m128kb infile.srep

я создаю репак игры добавляю все файлы в архив FreeArc создаю скрипт после того как я создал скрипт начинаю устанавливать репак а он устанавливает только файл FreeArcа arc [more=скрин]Скачать sshot-1.png с WebFile.RU [/more]

Bulat_Ziganshin
SREP 2.91 alpha

Цитата:

-l: minimum LZ match length, default 0