когда все баги будут исправлены (наверное), а мне лень тестить)
ага,ага)))
:x
-
Уважаемые гости и пользователи форума.
Администрация настоятельно рекомендует не регистрировать несколько аккаунтов для одного пользователя. При выявлении наличия мультиаккаунтов будут заблокированы все учетные записи данного пользователя.
Аккаунты, зарегистрированные на временную почту, будут также заблокированы.
:x
HEDT уже столько поддерживают. а новость была в том, что 9-е поколение процов поддерживает 32ГБ модули. учитывая что такой проц + такие модули будут стоить сравнимо с HEDT платформой, ничего особо интересного
dixen18
Ветеран
Вот так..Все пали жертвой лени
тот же xtool \ ztool тестировали все подряд, так гораздо быстрее вышло, раз уж утилита в паблике, почему бы и бета-тест в паблике не сделать
xtool \ ztool это рекомпрессор как бы. там достаточно было кинуть файл.
Потому что абсолютное большинстве не умеет тестить)
как пример - http://krinkels.org/threads/lolz.3649/page-2#post-32542
никто даже файл не залил бажный, пришлось самим искать косяк)
раньше и репаки никто не умел делать, научились же. Так и надо писать - присылайте вообще всё, параметры\файлы\конфигурацию ПК
Вам не надоело писать ахинею свою уже? Чего вы ноете-то? Возьми-те напишите сами что-нибудь, а не клянчите тут. Если люди пали жертвой лени, то чьей жертвой пали вы? Маразма наверное.
L-e-o-N
Старожил
Ага и упакованый Windows
zapsip
Участник
Здравствуйте.
-d[16..2032] - размер словаря в Мб.
Если задать большой размер словаря, например 2032, то это обяжет на компьютере, где происходит распаковка/установка игры , для успешной установки игры надо ТОЖЕ запастись оперативной памяти больше на величину 2032 ?
Или это параметр влияет только на компьютер, где происходит паковка ?
-d[16..2032] - размер словаря в Мб.
Если задать большой размер словаря, например 2032, то это обяжет на компьютере, где происходит распаковка/установка игры , для успешной установки игры надо ТОЖЕ запастись оперативной памяти больше на величину 2032 ?
Или это параметр влияет только на компьютер, где происходит паковка ?
Последнее редактирование:
L-e-o-N
Старожил
Потребление памяти для упаковки ~= размер словаря * 10 + еще несколько мб
Потребление памяти для распаковки ~= размер словаря + еще несколько мб
Формулы не точны, но получается что на распаковку тоже влияет, но в ~10 раз меньше. Например я указываю 256mb и у меня для упаковки используется ~2650mb а для распаковки ~266mb
Пользователь ProFrager обновил ресурс lolz новой записью:
lolz test22c4
Узнать больше об этом обновлении...
lolz test22c4
Узнать больше об этом обновлении...
Более полугода не занимался проектом, ждал когда найдутся все проблемные места. А они точно имеются, т.к. нашлось пару наборов данных, на которых анпакер либо выдавал неверные несколько байт, либо умирал с крэшем. Но проблема в том, что размер данных, на которых найдены эти косяки превышал некий установленный мной моральный предел в 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кб). Это и ускоряет сжатие, и как минимум не портит конечный размер сжатых данных. Но это тоже нужно проверить.
Поэтому вашей задачей будет найти набор данных, на котором проявляются какие-то проблемы и при возможности максимально обрезать его с сохранением данных проблем. Максимальным размером будем считать ~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. С новым годом, работяги!
