Уважаемые гости и пользователи форума.
Администрация настоятельно рекомендует не регистрировать несколько аккаунтов для одного пользователя. При выявлении наличия мультиаккаунтов будут заблокированы все учетные записи данного пользователя.
Аккаунты, зарегистрированные на временную почту, будут также заблокированы.
Товарищ @toolame предлагал использовать сборку FreeArc, где Булат поправил этот недостаток - там ищется алгоритм реализующий выполняемую функцию (упаковки или распаковки), а не просто первый подходящий по названию.
Но он так и не объяснил до конца, какие файлы использовал (из lolz22c4b.7z), как обойтись без fazip и не показал параметров из arc.ini. Все что я понял из его сообщения, arc.exe заменить новым (модифицированным, который он предлагал). А CLS.ini скопировать к arc.exe. Он это имел ввиду?
vint56 предложил второй способ (без fazip) подключения lolz-а, при котором все файлы (вместе с CLS.ini) находяться в каталоге "bin", если я правильно понял его.
Предполагаю что товарищ @toolame, знает еще третий способ, подключения lolz-а (без fazip). Но почему-то не хочет о нем рассказывать.
cls.dll и cls.ini что в комплекте с lolz
тот последний arc.exe от Булата
все это в одну папку (bin установленного Freearc)
неужели так сложно понять?
простите
cls.dll и cls.ini что в комплекте с lolz
тот последний arc.exe от Булата
все это в одну папку (bin установленного Freearc)
неужели так сложно понять?
простите
Эта схема по вашей псевдоинструкции, не работает.
lolz_x64.exe (из lolz22c4b.7z) отказывается паковать, находясь в папке bin. Тоже самое, если lolz_x64.exe перенести в другую папку.
А cls.dll не работает без cls-lolz_x64.exe. вы либо что-то, как всегда не договариваете, либо тупо тролите.
Привет всем, может кто поделиться (или написать) аналогичный "перебор" параметров для lolz?
Код:
@Echo Off
SetLocal enabledelayedexpansion
Set folder=out
Set toArch=in
Set size=551693999104
For /L %%p In (0,1,4) Do (
For /L %%c In (0,1,8) Do (
For /L %%b In (0,1,4) Do (
For /L %%f In (0,32,273) Do (
For /L %%m In (0,1000,10000) Do (
arc a -ep1 -dses --dirs -s; -lc- -di -i2 -r -mlzma:a1:mfbt4:d512m:fb%%f:lp%%p:lc%%c:pb%%b:mc%%m "%folder%\fb%%f_lc%%c_lp%%p_pb%%b_mc%%m.arc" "%toArch%" >Nul
Set err=!ErrorLevel!
rem For /L %%a In (0,1,20000) Do set r=%%a
If !err!==0 (
For %%s In ("%folder%\fb%%f_lc%%c_lp%%p_pb%%b_mc%%m.arc") Do (
If %%~zs LSS !size! (
Set size=%%~zs
Echo fb%%f lc%%c lp%%p pb%%b mc%%m !size! Best
) Else Echo fb%%f lc%%c lp%%p pb%%b mc%%m %%~zs
)
) Else Echo fb%%f lc%%c lp%%p pb%%b mc%%m Error
)
)
)
)
)
Pause
Для lolz оно не имеет смысла.
Во-первых, слишком много параметров -> слишком много вариантов перебора.
Во-вторых, все опции выставлены оптимально, и редко, когда их изменения даёт профит
В-третьих, слишком много зависимостей, например при лучшем -blo0 -bll будет 7, а вот при blo1 уже bll2. И такая зависимость для всех параметров, нельзя пройтись отдельно по каждому и выбрать лучший, как в lzma (в lzma вообще на глаз можно параметры ставить и угадывать).
и всё таки..
почему бы не сделать перебор основных параметров (например tt16-32-64-128-256, ldl4-8-12, mc256-512-1023, ldmf0-1 и так далее)
Если есть цель сжать набор определенных игровых данных максимально (спортивный интерес, как у тебя с pc_eng.str), можно конечно вручную прописать в bat и узнать наилучшие параметры для моего набора данных, но озадачился более универсальным решением, которое, возможно, поможет не только мне
tt - чем больше, тем лучше, но и скорость упаковки соответственно падает.
ldmf будет улучшать сжатие там, где работает srep, ldl - чем меньше, тем лучше, но и памяти жрать будет больше.
Тогда уж имело бы смысл перебирать пары -gm - где есть (A)RGB графика, -dm - где есть dxt-данные. На данных, на которых работает ldmf можно пробовать крутить параметр lde, но профит будет минимальный. Вот с mc сложнее, по идее чем больше, тем лучше, но нашлись данные, где максимальное значение оказалось совсем не лучшим.
ИМХО если совсем уж ковырять нужно крутить эти параметры:
Код:
parser hard lim(-oh[8..14]): 12 parser soft lim(-os[0..hard_lim]): 8
...
context mixer o1 ctx (-bc[0..6]): 4
...
literal hi o1 ctx (-blo[0..8]): 8 literal lo o1 ctx (-bll[0..8]): 8
literal hi rep0lit ctx (-blr[0..6]): 4
match flag rep0lit ctx (-bm[0..6]): 4
Но они реально оптимальные и разница минимальная у меня выходила. ХЗ вообще нафиг они оставлены
Доброго здравия ProFragerи огромное спасибо за Ваш труд.
Программа великолепна!
Справка очень важна для новичков.
До сих пор, периодически обращаюсь к ней.
Позволил себе слегка преобразить её.
Если есть такие прекрасные функции как BB-code, ими нужно пользоваться.
ldmf(long distance match finder), который ищет совпадения вне диапазона словаря основного матчфайндера. Разрабатывался как альтернатива srep'у, со своими плюсами и минусами. Выключается/включается опцией -ldmf[0..1]. Важно! ldmf не работает с -mtt1, более того, он крайне бесполезен для -mtt0 с числом тредов больше 1. В этих случаях лучше используйте srep. По умолчанию -ldmf1
Коэффициент зависимости степени сжатия от необходимой памяти для декомпрессии задается опцией -ldc[0..9] при 0 контроль памяти для декомпрессии отключается, максимизируя степень сжатия. По умолчанию -ldc1
Размер минимальной длины для поиска задается опцией -ldl[5..12]. Эта опция влияет на сжатие (чем меньше, тем лучше сжатие), на используемую память для сжатия (чем меньше, тем больше памяти по формуле ldmf_compr_mem = src_size/((2 ^ [ldl]) / 16), т.е. при -ldl5 к уже используемой lolz памяти добавится еще половина от размера входного файла), на использемую память для распаковки (чем меньше, тем больше будет необходимо памяти) и на скорость сжатия (чем меньше, тем медленнее). По умолчанию -ldl8
Добавил опцию -lde[0..2] задающую уровень парсинга ldmf матчей. 2й режим самый медленный, 0 - самый быстрый, но отличий в сжатии минимум. 1й режим по скорости почти как 2й, но сжатие обычно хуже, чем даже 0й режим. Поэтому на данный момент рекомендую использовать либо -lde0, либо -lde2. По умолчанию используется -lde0.
Включает перенесение обсчетов цен кодирования матчей в тред матчфайдера, что ускоряет сжатие с -tt больше 4, при меньшем -tt скорость либо такая же, либо хуже. Сжатие может незначительно отличаться от режима -ac0 как в плюс, так и минус. Так же в этом режиме необходимо немного больше памяти для сжатия, которая зависит от параметра -tt (add_mem = 200k + 450k*tt). По умолчанию -ac0
[0..1] - включает/выключает детект pos_ctx/dxt/raw. никаких заголовков, все детектится на основе анализа статистики данных. По умолчанию: -dt1
[0..1] - включает/выключает передачу последующим блокам в детекте статистику от предыдущих блоков. По умолчанию: -dtp1
Включает/выключает перебор всех вариантов вне зависимости от эвристик. По умолчанию: dtb0.
[0..1] - включает/выключает детект мультимедиа raw графики. По умолчанию: -dtm1
Включает/выключает детект ширины для raw графики и dxt текстур. По умолчанию -dtw1
Включает/выключает детект dxt текстур. По умолчанию -dtd1
[0..1] - при многопоточной обработке указывает используемый режим работы. При 0 размер словаря должен быть как минимум в 2 раза больше размера блока. В этом режиме данные для каждого потока будут загружаться чередуясь размером в блок. В этом режиме в большинстве случаев можно добиться лучшего сжатия, чем во втором, однако для распаковки потребуется такое число потоков, как и при сжатии. При 1 каждый блок сжимается отдельно, без зависимостей от соседних данных, соответственно сжатие тут получается обычно хуже, чем в первом режиме, но количество потоков на распаковку можно указывать любое. Именно для этого режима применяются опции из cls.ini MaxThreadsUsage и MaxMemoryUsage. По умолчанию: -mtt0
[1..16] - задает число потоков для обработки. При -mt1 и -mtt0 получается обычное последовательное сжатие без потерь в сжатии на разделение потока на блоки. По умолчанию: -mt1
[2..512] - задает размер блока в Мб. При -mt1 -mtt0 так же играет значение, но минимальное. И больше - не значит лучше. Обычно для -mtt0 оптимальное значение порядка 32-64мб, соответственно размер словаря должен быть более, чем в 2 раза больше. Для режима mtt1 размер словаря должен быть не более размера блока. По умолчанию: -mtb должен быть в два раза меньше ключа -d(-mtb256 -d512), при параметре ключа -mtt0. При параметре ключа -mtt1, ключ -d не должен превышать ключ -mtb(-d256 -mtb256)
[16..2032] - размер словаря в Мб. По умолчанию: -d64. При параметре ключа -mtt1, ключ -d должен быть не более размера блока -mtb(-d256 -mtb256). При параметре ключа -mtt0, ключ -d должен быть в два раза больше ключа -mtb(-d512 -mtb256).
[1..256] - количество рассматриваемых путей в оптимальном парсере. Очень сильно влияет на скорость и степень сжатия, но не на распаковку. Не стоит задавать больше 16, уверяю, оно того не стоит. По умолчанию: -tt4
[8..14] - задает максимальное количество байт, которое оптимальный парсер обработает за раз (2^X). По умолчанию: -oh12
[0..-oh] - задает минимальное количество байт, которое парсер обработает за раз (2^X). По умолчанию: -os8
[0..4096] - задает размер минимального совпадения, при котором парсер не станет сильно утруждаться в расчетах. Прилично ускоряется сжатие (раза в 2) с небольшой потерей сжатия. При 0 эти упрощения отключаются. По умолчанию: -fba256
[0..4096] - ЭТА ОПЦИЯ НА ДАННЫЙ МОМЕНТ НЕ РАБОТАЕТ. Задавала еще большие упрощения. По умолчанию: -fbb0
[0..1] - включает/выключает просчет цены литерала даже при rep0 совпадении. По умолчанию: -al1
[0..2] - включает медленные режимы работы парсера с просчетом (почти) всех длин найденного матча, а так же вариантов match+lit+rep0match. Очень медленно и беспощадно. А выгода очень небольшая. Проще -tt добавить; По умолчанию: -x0
[0..2] - ЭТА ОПЦИЯ НА ДАННЫЙ МОМЕНТ НЕ РАБОТАЕТ. Задавала тип matchfinder'а - lz, rolz либо гибридный режим, однако rolz не оправдал ожиданий и все изменения я проводил без его учета его, поэтому он сейчас не работает; По умолчанию: -rt0
[2..1023] - Задает максимальное количество обходов бинарного дерева совпадений, после которого совпадения для данного положения больше не ищутся; По умолчанию: -mc128
[0..1] - включает/выключает простой context mixer в некоторых критических местах, который смешивает по паре моделей в каждом месте. При включении улучшает сжатие, но замедляется распаковка. По умолчанию: -cm1
[0..6] - задает уровень влияния предыдущего байта на миксер; По умолчанию: -bc4
[0..4] - ЭТА ОПЦИЯ НА ДАННЫЙ МОМЕНТ НЕ РАБОТАЕТ. Задавала тип "элементарного" литерала. Сложные высоко-порядковые модели с cm показали себя не очень, поэтому их забросил, так же как и rolz. По умолчанию: -lm0
[0..8] - задает степень влияния предыдущего байта на кодирование верхней части литерала. По умолчанию: -blo8
[0..8] - задает степень влияния предыдущего байта на кодирование нижней части литерала. По умолчанию: -bll8
[0..6] - задает степень влияния rep0lit байта на кодирование верхней части литерала. По умолчанию: -blr4
[0..6] - задает степень влияния rep0lit байта на кодирование флага типа совпадения. По умолчанию: -bm4
[0..4] - задает позиционный контекст для всех операций кодирования. Автоматически игнорируется при включенном детекте. По умолчанию: -pc2
(X[0..3], Y[0..4]) - задает модель для кодирования пар цветов (X) и пар альфа-канала(Y). При максимальном значении каждого параметра используется адаптивное переключение между моделями, при чем скорость распаковки уменьшается, но и сжатие в большинстве случаев лучше. По умолчанию: -dm34
(X[0..2], Y[0..1]) - X - задает модель для кодирования raw графики. при максимальном значении включается адаптивное переключение между моделями. Однако в данном случае редко когда можно увидеть выигрыш у адаптивного режима. В основном лидирует 0 режим, но его распаковка в 2 раза медленнее 1го режима. Y - включает обновление статистики моделей когда они не использовались (например было длинное совпадение). Для X0 и X1 обычно дает небольшой выигрыш в сжатии, но скорость падает раза в 2(все зависит от данных). В общем самым оптимальным является -gm00, он же - и режим по умолчанию. По умолчанию: -gm00
Так же есть проблема: на некоторых данных с -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кб). Это и ускоряет сжатие, и как минимум не портит конечный размер сжатых данных. Но это тоже нужно проверить.
MaxThreadsUsage и MaxMemoryUsage регулируют количество потоков на распаковку в режиме -mtt1. Память и потоки можно указывать в %, как и сделано в примере. В зависимости от свободных ресурсов на целевой машине будет запущено определенное количество потоков. Таким же образом можно и жестко указать желаемое число потоков, но по памяти все же правильнее оставить процентное ограничение. Но вообще режим -mtt0 более полезен, но для него число потоков для распаковки автоматически задается жестко тем числом, с которым производилось сжатие и опции MaxThreadsUsage и MaxMemoryUsage cls.ini игнорируются.
P.S. остальные опции cls.ini (Bufsize, transfer_ReadBufSize, transfer_WriteBufSize) лучше не трогать, они влияют на обмен между cls.dll и exe декомпрессора, и подобраны оптимальными для каждого конкретного случая (для srep'а немного другие, нежели для lolz).
P.P.S. хм, похоже я забыл в обновления этот cls.ini закинуть. Вот его содержимое
[Srep]
Bufsize=24m
transfer_ReadBufSize=512k
transfer_WriteBufSize=512k
Memory=80%-512m
TempPath=.\
самое главное - объединить srep с lolz, но чтобы заголовки dds были сохранены. Может быть, просто добавление srep в lolz с дополнительными проверками сделает это, так как srep уже очень хорош. Я могу дать вам источники srep, если вы не можете их найти.
-Не в заголовках дело, а в том, что srep портит структурированность, что очень важно для lolz'а. В lolz детект данных сделан не по заголовкам. Можешь отрезать заголовок от DDS файла, он от этого не перестанет корректно детектироваться. Структурированность - это сохранение постоянного размера структуры данных. В хекс редакторе невооруженным глазом видно различие до srep'а и после него, например на DDS.
ldmf — это попытка устранить недостатки srep, добавив свои недостатки) Я думаю, что главный недостаток srep — это фрагментация структуры данных, что иногда снижает степень сжатия. Если данные таковы, что srep в принципе убирает все совпадения на границах структур, то ldmf вместо srep практически никакого прироста сжатия не даст. Также обратите внимание на память, необходимую для распаковки, которой можно управлять с помощью опции -ldc.
-bc [0..8] - задает уровень влияния предыдущего байта на миксер; По умолчанию: -bc4
на -bc [0..6] - задает уровень влияния предыдущего байта на миксер; По умолчанию: -bc4
-blr [0..8] - задает степень влияния rep0lit байта на кодирование верхней части литерала. По умолчанию: -blr4
на -blr [0..6] - задает степень влияния rep0lit байта на кодирование верхней части литерала. По умолчанию: -blr4
-bm [0..8] - задает степень влияния rep0lit байта на кодирование флага типа совпадения. По умолчанию: -bm4
на -bm [0..6] - задает степень влияния rep0lit байта на кодирование флага типа совпадения. По умолчанию: -bm4
У всех трёх ключей максимальное значении 6.
Если поставить 8, авария не произойдёт, просто программа автоматом снизит значение до 6.
Важное уточнение! В справке серьёзно обращаем внимание на параметры запуска по умолчанию.
Возможно, параметр по умолчанию уже будет вам подходить и его не придётся добавлять в параметры запуска как в примере ниже:
Скажу для новичков, потому как, пока сам новичок.
Да и бывалые, давно уже знают про это)
Не нужно захламлять параметры запуска LOLZ значениями по умолчанию!
Например есть значение параметра по умолчанию, которое равно 1(вкл):
[0..1] - включает/выключает передачу последующим блокам в детекте статистику от предыдущих блоков. По умолчанию: -dtp1
И вот меня чёрт понес взять да и поставить его в параметры запуска, типа:
Зачем, для чего??
Якобы думая подстраховаться, вдруг программа пропустит.
Ну или по незнанке совсем, чего лучше вообще не делать и всё оставлять по умолчанию.
Первое и главное правило, либо ты понимаешь что за что отвечает и тогда ставишь, либо вообще ничего не трогаешь, пока не станешь понимать. Ставить в параметры запуска ключи, которые ты не собираешься изменить, не имеет смысла. Ставить в параметры запуска ключи, которые ты не понимаешь, вредно для результата. Потому как, есть взаимоисключающие ключи, когда включение одного автоматом выключает другой.
::Настройки BAT #1, только один LOLZ:
arc a -m0 -ep1 -dses -lc- --cache=512mb -i2 -r -s; -cfg"arc.ini" -w.\temp_arc -m=lolz output\data.arc "data\*"
::Настройки BAT #2, связка:
arc a -m0 -ep1 -dses -lc- --cache=512mb -i2 -r -s; -cfg"arc.ini" -w.\temp_arc -m=precomp+srep+lolz output\data.arc "data\*"
Каждый ключ в этой связке имеет место быть, а не для красоты.
Если внимательно посмотреть, то нет ни одного ключа несущего параметры по умолчанию.
Все ключи модифицированы под себя.
Если это так, тогда ключ или ключи имеют место быть в связке, если нет, тогда это лишнее.
Разберём для более глубокого понимания.
-mc1023 - по умолчанию равен -mc128, встраиваем.
-fba0 - по умолчанию равен -fba256, встраиваем.
-dtb1 - по умолчанию -dtb0, встраиваем.
-d512m - по умолчанию равен -d64m, встраиваем.
-mtb256 - т.к. ключ -d имеет значение 512, то ключ -mtb, должен быть в половину меньше.
Значение -mtt(многопоточности) у меня по умолчанию равно -mtt0 значит размер словаря(-d) должен быть как минимум в 2 раза больше размера блока(-mtb). Что мы благополучно и сделали.
Т.к. -ldmf по умолчанию включен -ldmf1, значит и ключи регулирующие механику -ldmf, активны.
-ldl5 - по умолчанию -ldl8, встраиваем.
-lde2 - по умолчанию -lde0, встраиваем.
-ldc0 - по умолчанию -ldc1, встраиваем.
Эта схема тестируется у меня с моими данными, вам нужно подбирать свою, или оставлять всё по умолчанию.
Как говорят мастера, профит(выигрыш) не большой будет!
Хотя...)
Также тестировать нужно как только один LOLZ, так и связку.
Только один LOLZ будет запаковывать дольше, чем если перед LOLZ пройдёт Srep.
Почему тестирую только один LOLZ без связки?
elit0101 написал(а):
самое главное - объединить srep с lolz, но чтобы заголовки dds были сохранены. Может быть, просто добавление srep в lolz с дополнительными проверками сделает это, так как srep уже очень хорош. Я могу дать вам источники srep, если вы не можете их найти.
-Не в заголовках дело, а в том, что srep портит структурированность, что очень важно для lolz'а. В lolz детект данных сделан не по заголовкам. Можешь отрезать заголовок от DDS файла, он от этого не перестанет корректно детектироваться. Структурированность - это сохранение постоянного размера структуры данных. В хекс редакторе невооруженным глазом видно различие до srep'а и после него, например на DDS.
ldmf — это попытка устранить недостатки srep, добавив свои недостатки) Я думаю, что главный недостаток srep — это фрагментация структуры данных, что иногда снижает степень сжатия. Если данные таковы, что srep в принципе убирает все совпадения на границах структур, то ldmf вместо srep практически никакого прироста сжатия не даст. Также обратите внимание на память, необходимую для распаковки, которой можно управлять с помощью опции -ldc.
ldmf будет улучшать сжатие там, где работает srep
Если это так, тогда нужно серьёзно отнестись к настройкам Srep связанным с ключами -L и -C:
>srep:mem256mb:l128
по умолчанию l512, он даёт наилучшее сжатие в паре с lzma. при меньшем значении srep отбирает матчи у lzma и сжатие обычно ухудшается
во-первых, и lzma и razor - все используют lz. во-вторых, srep идёт ПЕРЕД lolz/lzma/..., т.е. он находит эти матчи, кодирует их и не даёт lz-пакерам закодировать их более эффективно. ну и дальше есть два соображения - первое, что они в отличие от srep имеют ограниченный "радиус действия", то бишь словарь, и там где есть только далёкий матч - они вовсе ничего не найдут. второе - что даже ближние матчи, если они довольно большие, есть смысл убирать srep'ом, поскольку это сокращает дистанции для всех матчей и тем самым чуть-чуть улучшает сжатие
вообще я проводил тесты с lzma - при мин. размере матча в диапазоне от 500 до 700 байт общий результат менялся очень незначительно и скорее случайно, так что (по крайней мере в моих тестах) разницы какой назначить :l из этого диапазона - вообще нет. если уж улучшать сжатие - то :m3:c64:l512 даёт наилучшие результаты с lzma afair. в новой версии srep это будет метод :m3z, а пока можете так попробовать
а это секретное оружие. я о том что его стоит трогать узнал только от fg, а до этого даже не задумывался. а так она пожаловалась что он в 3.93 сломан, ну я и покрутил для интереса. и выяснил что самое лучшее сжатие - в вышеупомянутом конфиге
смысл такой, что данные разбиваются на куски по 64 байта, но поскольку миним. размер матча 512 байт (т.е. l512), то нужно чтобы 8 таких кусков подряд совпали. по дефолту же для m3 - c512:l512, т.е. берутся только матчи, начинающиеся с кратной 512 позиции. понятно, что немножечко матчей мы по сравнению с c64:l512 при этом таки теряем
впрочем, разница там крошечная
:l задаёт минимальный размер матча
:c задаёт куски, на которые разбиваются данные для поиска таких матчей
скажем при :l8:c8 матчи могут быть только с целым количеством 8-байтовых слов, начинающихся на позициях, кратных 8. с :l8:c4 - с минимум двумя 4-байтными словами, начинающимися на позициях, кратных 4. с l8:c2 - минимум 4 двух-байтных слова, начинающиеся на чётных позициях
меньше :c64 ставить не рекомендую. выигрыша в сжатии уже не будет, а потребление памяти вырастет
по умолчанию c=l для m3, c=l/2 для m5. и кажись округляется вниз поскольку с должен быть степенью 2.
Не обращайте внимание, что речь идёт о LZMA, в уме, замените его на LOLZ)
Всем удачи.
Спасибо. Ошибка действительно есть. Столько опций, конечно, не стоит писать, больше половины из них выставлены по умолчанию. А проблема возникает из-за -gm21 (а именно из-за последней единицы). Позже посмотрю что да как там.
и с отключённым файлом подкачки, тогда получим ошибку:
Ключ -d512m вызывает эту ошибку.
-d[16..2032] - размер словаря в Мб. По умолчанию: -d64;
После того как снизил значение до -d256m, всё заработало.
Видимо элементарно не хватало памяти, хотя расход был небольшой:
Потом опять обратился к справке: Ключи -mtt(0)-mt(1) у меня по умолчанию, но при -mtt0 контроль памяти при распаковке отключен, плюс размер словаря влияет на объём памяти затрачиваемой при упаковке и распаковке.
Хоть и расход памяти был небольшой, но видимо в программе установлена защита от умника)
И программа сразу просчитывает возможности системы, перед началом компрессии, отталкиваясь от значения словаря -d, подходит оно или нет.
Всё это вроде бы и так очевидно, но вдруг новичкам пригодится)
Удачи)
После nnnnnnnnnn-го количества тестов пришёл к логическому завершению подходящих параметров запуска LOLZ.
Оптимальному(скорость) + максимальному(сжатие).
Для меня это идеальная комбинация, которая создаёт максимальное сжатие и нормальную скорость.
Все остальные ключи по умолчанию.
Именно эти два ключа играют максимальную роль в плане сжатия.
Если не рассматривать ключ -tt и -x, которые очень сильно влияют больше на скорость, чем на компрессию.
Но есть один момент с ключами -d и -mtb.
Если будет установлен только ключ -mtb, без ключа -d:
Только тогда LOLZ принимает выставленные значения.
Все вышесказанное справедливо при отключенной многопоточности(-mtt0) и одном потоке(-mt1).
При активной многопоточности(-mtt1) и активации потоков больше одного(-mt4)
Выставленное значение ключа -d64m, автоматически выставит точно такое же значение для ключа -mtb64.
И наоборот, -mtb64 = -d64m
Собственно об этом написано в справке - эти ключи должны быть равны)
И последнее, при многопоточности лучше всего задавать значение количество ядер процессора минус один.
Если ядер четыре, то ставим -mtt1-mt3, для того чтобы процессор не захлёбывался)
И возможно лучше отталкиваться от реальных ядер(4) процессора, а не от потоков(8).
Одна из важнейших характеристик современного процессора — количество ядер и потоков. Это непосредственно влияет на цену и производительность, поэтому нужно четко понимать преимущества и минусы конкретной модели процессора.
hi-tech.mail.ru
Хотя этот момент полностью на ваше усмотрение, для меня так, для вас иначе.
Всё нужно подвергать анализу и тесту для выявления лучшего результата.
На каждом новом конфиге оборудования, всё может поменяться.
Всем удачи!
Можно у вас поинтересоваться.
Я всё пытаюсь более детально осознать механизмы lolz.
Есть объём данных с zlib компрессией, весом 7.47 ГБ.
При сжатии через цепь xtool+lolz с данными ключами:
Первый вариант мне нравится больше, но из-за отсутствия возможности влиять на контроль памяти при распаковке через Inno Setup, от него приходится отказаться.
Правильно ли будет сказать, что если архив создан с ключом (-mtt0), то при распаковке lolz будет потреблять память не бесконтрольно, а отталкиваясь от значения словаря (-d), которое было задано при компрессии.
Например ели словарь был равен (-d208), то расход памяти при распаковке + погрешность, будет отталкиваться от этого значения?
Параметр ldmfMaxMemoryUsage при подсчете памяти включает в себя размер основного словаря и еще копейки на модели (но последнее считается на глаз, от балды), например при -ldmfMaxMemoryUsage=64m, одном потоке и размере словаря 16мб на память под ldmf выделится 16мб, остальное будет скидываться в своп.
Размер словаря 16 мб., который приведён в примере - это параметр (-d), который задаётся при компрессии, ведь так?!
И ещё один вопрос:
В CLS.ini в строке MaxThreadsUsage=50%, возможен ли вот такой вид?: MaxThreadsUsage=50p-1
На данном сайте используются файлы cookie, чтобы персонализировать контент и сохранить Ваш вход в систему, если Вы зарегистрируетесь.
Продолжая использовать этот сайт, Вы соглашаетесь на использование наших файлов cookie.
