Иконка ресурса

lolz test22c4b

Нет прав для скачивания

ProFrager

Знаток
Проверенный
Пользователь ProFrager обновил ресурс lolz новой записью:

lolz test22c4

  • реализовал ldmf(long distance match finder), который ищет совпадения вне диапазона словаря основного матчфайндера. Разрабатывался как альтернатива srep'у, со своими плюсами и минусами. Выключается/включается опцией -ldmf[0..1]. Коэффициент зависимости степени сжатия от необходимой памяти для декомпрессии задается опцией -ldc[0..9] при 0 контроль памяти для декомпрессии отключается, максимизируя степень сжатия. Размер минимальной длины для поиска задается опцией -ldl[5..12]. Эта...
Узнать больше об этом обновлении...
 

ProFrager

Знаток
Проверенный
Более полугода не занимался проектом, ждал когда найдутся все проблемные места. А они точно имеются, т.к. нашлось пару наборов данных, на которых анпакер либо выдавал неверные несколько байт, либо умирал с крэшем. Но проблема в том, что размер данных, на которых найдены эти косяки превышал некий установленный мной моральный предел в 1 Гб, при превышении которого время на отладку могло затянуться на недели. Все потому, что компрессор асимметричен и нескольких прогонов анпакера недостаточно, мне необходимо так же сжимать эти данные с теми же параметрами в дебаг режиме, который в 10-20 раз медленнее релизного варианта, при этом, как показывает практика, это необходимо сделать далеко не один раз, что и увеличивает время дебага до ужасных значений. Я к такому не готов.
Поэтому вашей задачей будет найти набор данных, на котором проявляются какие-то проблемы и при возможности максимально обрезать его с сохранением данных проблем. Максимальным размером будем считать ~1ГБ, а вообще еще лучше если бы пара сотен МБ. Обязательным условием является включенный ldmf режим. Так же скорее всего опцию распаковки ldmfMaxMemoryUsage необходимо установить в минимальное значение (и надо указывать в МБ, а не %, чтобы на моей машине все было как у вас), чтобы увеличить объем работы ldmf части кода при распаковке, что в теории увеличивает шанс найти баг.
Все новые опции указаны в информации к последнему обновлению. В шапке пока ничего не обновляю.
Так же есть проблема: на некоторых данных с -lde0, не говоря уж о -lde1/2, наблюдаются приличные просадки скорости сжатия относительно режима без использования ldmf. Чтобы сделать использование ldmf более прозрачное мне нужно упростить без особого вреда сжатию место, где происходит затык, для этого вам необходимо отловить подобный кусочек данных до 1 Гб (тут так же - чем меньше, тем лучше).
Итого: если нашелся баг, либо сильное замедление при ldmf1 попытайтесь максимально обрезать данные с сохранением проблемы. Если в цепочке алгоритмов есть что-то кроме lolz'а, то желательно сначала подготовить данные, обработав всей цепочкой до lolz'а, получив один файл, на котором при скармливании консольному lolz_x64.exe должна проявляться проблема. Так же либо в батнике со всеми необходимыми параметрами и командами для упаковки/распаковки, либо в своем посте укажите все, что нужно будет сделать на моей машине, чтобы получить тот же результат, что вышел у вас. Исходные данные+батники и т.д. закидывайте на какой-нить файлообменник, типа mega.nz, предварительно сжав в 7z. Т.е. созданный "нерабочий" архив lolz'а кидать не нужно, нужны инструкции по его созданию!
Важно! ldmf не работает с -mtt1, более того, он крайне бесполезен для -mtt0 с числом тредов больше 1. В этих случаях лучше используйте srep. В cls.ini, идущим в комплекте, опции, отвечающие за распаковку ldmf специально выставлены как для тестирования, не для реального использования!
Еще момент. Как показала практика перед lolz с ldmf выгодно использовать srep с большой минимальной длиной совпадения, типа -l8k/16k (т.к. минимальное окно в детекте lolz'а равняется как раз таки 8кб). Это и ускоряет сжатие, и как минимум не портит конечный размер сжатых данных. Но это тоже нужно проверить.

P.S. С новым годом, работяги!:drinks:
 

vint56

Ветеран
Проверенный
ProFrager, большое спасибо тебе за такой подарок и тебя с наступающим новым годом :drinks:
 

zapsip

Пользователь
Каков порядок нумерации версий этой программы ?
Что означают цифры 22, 4 и буква с ?
(файл .cmd я использую, но там про это нет ничего)

И можно ли с этой версией программы lolz22c4 вместо предлагаемого способа :
[External compressor:srep]
header = 0
packcmd = srep {options} - $$arcpackedfile$$.tmp <stdin>

использовать свой :
[External compressor:srep]
header = 0
packcmd = srep {options} - $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
?
 
Последнее редактирование:

ProFrager

Знаток
Проверенный
no. AFAIR latest version in which these options worked is 19j.
Каков порядок нумерации версий этой программы ?
Что означают цифры 22, 4 и буква с ?
это что-то типа major, minor version, просто чередую цифровую и буквенную нумерацию. При незначительных изменениях я могу еще букву добавить в конце к lolz22c4 :)
 

Вложения

toolame

Пользователь
Проверенный
ProFrager, спасибо за работу!
врпрос: для ldmf нельзя реализовать swap при упаковке? годный SSD диск должен справится, нет?
а то как то.. 60GB на входе, при -ldl5 надо 30GB только на ldmf, а еще плюс обычный словарь...
вообще по тестам, сильна ли разница при -ldl меньше 8ми?
 

sdsdssd

Пользователь
so to see ldmf benefit in improving ratio is to use without srep ?
i tried it on game just cause 2 lolz with ldmf0 and ldmf1 with -ldl5 along side srep and xtool no difference in final size 1.03gb...

the setting for lolz that is use

[External compressor:lolz]
header = 0
packcmd = lolz.exe -dtb1 -ac1 -x2 -mc1023 -fba4096 -bc6 -blr6 -bm6 -gm20 -d96 -mtb48 -ldmf1 -ldc0 -ldl5 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
 

dixen18

Пользователь
А вот интересно как справится ldmf на тестах игры Crash Bandicoot? Ведь там приличное сжатие достигалось благодаря именно srep..
 

Mickey1s

Старожил
Модератор
набор файлов с Unity движка - 207 МБ (217 521 493 байт)

OLD Lolz
- 65.0 МБ (68 187 354 байт)
New Lolz (lolz_x64_22c4) - 67.6 МБ (70 961 171 байт)
lolz_x64_19j - 66.0 МБ (69 285 079 байт)

везде одинаковые параметры - srep:l256:a1:m3f+lolz:d512:mtb64:mc1023:lm0:dtb0:x0:al1:tt16:rt0:mtt0:dt1:ac1

чяднт?
 

ProFrager

Знаток
Проверенный
so to see ldmf benefit in improving ratio is to use without srep ?
i tried it on game just cause 2 lolz with ldmf0 and ldmf1 with -ldl5 along side srep and xtool no difference in final size 1.03gb...
ldmf is attempt to eliminate disadvantages of srep, adding its own disadvantages) I think main drawback of srep is fragmentation of the data structure, which sometimes reduces compression level. If the data is such that srep basically removes all matches at boundaries of the structures, then ldmf instead of srep practically will not give any gain of compression. Also pay attention to memory needed for unpacking, which can be managed with the -ldc option.

везде одинаковые параметры - srep:l256:a1:m3f+lolz:d512:mtb64:mc1023:lm0:dtb0:x0:al1:tt16:rt0:mtt0:dt1:ac1
чяднт?
Даж не знаю, вроде не должно было ничего поломаться по пути. Может это -ac1 все портит? Или ldmf после srep'а?
 

zapsip

Пользователь
Здравствуйте.
У меня включение -ac1 при условии -tt: 4, 8, 16, 32 пока только увеличивает размер сжатия.
Но это же не вердикт, потому-что на наборе файлов несколько сот мегабайт результат не виден.
Раньше бывало такое, что только на сборке файлов много гигабайт результат виден.

А вообще настройки по умолчанию являются оптимальными в большинстве случаев.
Преимущество появляется только при индивидуальном подходе к файлам.
Знайте об этом, кто не знал !
 

Mickey1s

Старожил
Модератор
Или ldmf после srep'а?
не посмотрел что это параметр автоматически включается и нужно прописывать ldmf0
выключил ldmf и ac1 и пережал всё, получились такие результаты:

OLD Lolz - 65.0 МБ (68 252 790 байт)
New Lolz (lolz_x64_22c4) - 65.0 МБ (68 204 825 байт)
lolz_x64_19j - 66.1 МБ (69 406 435 байт)
 
Сверху