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

lolz test22c4b

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

ProFrager

Знаток
Проверенный
so the best thing to use srep with l8k and lolz ldmf enabled with ldl5 ?
You can do several tests yourself and write result here. I have done only a few tests on small data sets and this is rather theoretically.

У меня включение -ac1 при условии -tt: 4, 8, 16, 32 пока только увеличивает размер сжатия.
Эту опцию разрабатывал как некую оптимизацию по скорости сжатия. Она переносит работу, которая совершается в основном потоке, в поток, где непосредственно идет поиск совпадений. 100% точно перенести не возможно, т.к. в другом потоке отсутствует текущая статистика модели, поэтому результат ожидаемо должен быть хуже. Однако в моих тестах он практически не отличался от оригинального варианта и поэтому я еще сделал пару упрощений, которые не влияли на степень сжатия. А вот в ваших случаях дело обстоит иначе. Видимо, надо докручивать эту опцию.

New Lolz (lolz_x64_22c4) - 67.6 МБ (70 961 171 байт)
У меня включение -ac1 при условии -tt: 4, 8, 16, 32 пока только увеличивает размер сжатия.
скиньте эти наборы на файлообменник, посмотрю, может можно что подправить. Но в любом случае этот режим останется ускорением сжатия при больших -tt жертвуя степенью сжатия.
 

toolame

Пользователь
Проверенный
Sims 4
Код:
xtool09:t3,c160mb:zlib+srep:m5f:l2048:s55gb:a64+lolz_21a7:mtt1:mt1:mtb384:d384:tt8:gm20:fba1024:oh14

o1 model                 : 12'702'262 kb
raw graphic model 8 bit  : 1'151'347 kb
raw graphic model 16 bit : 526'647 kb
raw graphic model 24 bit : 260'608 kb
raw graphic model 32 bit : 5'860'162 kb
dxt1 model               : 47'043 kb
dxt3 model               : 27'895 kb
dxt5 model               : 356'879 kb
o1 model pos mod 2       : 7'102'532 kb
o1 model pos mod 4       : 8'601'757 kb
o1 model pos mod 8       : 1'553'016 kb
o1 model pos mod 16      : 801'051 kb
total size               : 38'991'206 kb

decode mem usage per thread = 769mb
25,996,143,076 > 15,620,917,931
Код:
xtool09:t3,c160mb:zlib+srep:m5f:l2048:s55gb:a64+lolz_22c4:ldmf0:mtt1:mt1:mtb384:d384:tt8:gm20:fba1024:oh14

o1 model                 : 12'591'517 kb
raw graphic model 8 bit  : 1'161'684 kb
raw graphic model 16 bit : 524'624 kb
raw graphic model 24 bit : 261'381 kb
raw graphic model 32 bit : 5'683'810 kb
dxt1 model               : 45'914 kb
dxt3 model               : 27'320 kb
dxt5 model               : 355'107 kb
o1 model pos mod 2       : 7'141'790 kb
o1 model pos mod 4       : 8'838'144 kb
o1 model pos mod 8       : 1'548'793 kb
o1 model pos mod 16      : 811'119 kb
total size               : 38'991'206 kb

decode mem usage per thread = 768mb
25,996,143,076 > 15,603,713,500

буду мучать ldmf..
upd: промучал
 
Последнее редактирование:

Simorq

Пользователь
Dead Island Definitive Collection *.rpack; 9.31 GB

Creating archive: Test.Bin using lolz:d96m:mtb48mb:mt8:ldmf:ldl5:mc1023
Compressed 85 files, 9,998,947,300 => 3,573,858,833 bytes. Ratio 35.74%
Compression time: cpu 49.33 sec/real 6819.44 sec = 1%. Speed 1.47 mB/s
All OK

Creating archive: Test.Bin using srep:m3f:l256+lolz:d96m:mtt1:mt8:mc1023
Compressed 85 files, 9,998,947,300 => 2,428,264,000 bytes. Ratio 24.29%
Compression time: cpu 34.17 sec/real 3551.16 sec = 1%. Speed 2.82 mB/s
All OK
 

L-e-o-N

Пользователь
Появилась проблема. Файл пакуется но при распаковке происходит ошибка(программа вылетает)
Ниже загрузил файл обработаный всеми алгоритмами цепочки кроме lolz (в 7z архиве)
Вот параметры lolz(версия последняя):
Код:
[External compressor:lolz]
header = 0
packcmd = lolz_x64.exe -dt -dtp1 -dtb1 -dto1 -dtm1 -dtw1 -dtd1 -mtt0 -mt1 -mtb2 -d256m -tt4 -oh14 -os14 -fba256 -fbb256 -al1 -x0 -ac0 -rt0 -mc1023 -ldmf1 -ldl5 -ldc0 -lde0 -cm1 -bc4 -lm0 -blo8 -bll8 -blr6 -bm6 -dm34 -gm21 $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
 

Вложения

  • 2.8 MB Просмотры: 27

Simorq

Пользователь
Dead Island Definitive Collection *.rpack; 9.31 GB

Creating archive: Test.Bin using lolz:d96m:mtb48mb:mt8:ldmf:ldl5:mc1023
Compressed 85 files, 9,998,947,300 => 3,573,858,833 bytes. Ratio 35.74%
Compression time: cpu 49.33 sec/real 6819.44 sec = 1%. Speed 1.47 mB/s
All OK

Creating archive: Test.Bin using srep:m3f:l256+lolz:d96m:mtt1:mt8:mc1023
Compressed 85 files, 9,998,947,300 => 2,428,264,000 bytes. Ratio 24.29%
Compression time: cpu 34.17 sec/real 3551.16 sec = 1%. Speed 2.82 mB/s
All OK
mt1:facepalm:
Creating archive: Test.Bin using lolz:dtb1:d192:mtb96:ldl5:mc128
Compressed 85 files, 9,998,947,300 => 2,411,589,568 bytes. Ratio 24.12%
Compression time: cpu 46.08 sec/real 20318.99 sec = 0%. Speed 0.49 mB/s
All OK
 

ProFrager

Знаток
Проверенный
Появилась проблема. Файл пакуется но при распаковке происходит ошибка(программа вылетает)
Спасибо. Ошибка действительно есть. Столько опций, конечно, не стоит писать, больше половины из них выставлены по умолчанию. А проблема возникает из-за -gm21 (а именно из-за последней единицы). Позже посмотрю что да как там.
 

L-e-o-N

Пользователь
Спасибо. Ошибка действительно есть. Столько опций, конечно, не стоит писать, больше половины из них выставлены по умолчанию. А проблема возникает из-за -gm21 (а именно из-за последней единицы). Позже посмотрю что да как там.
Спасибо за информацию. В старой версии все работает. А что касается опций то у меня все опции проставляет программа, в которой в окне нужно выбирать настройки, и я просто от туда скопировал все параметры
 

elit0101

Пользователь
Важно! ldmf не работает с -mtt1, более того, он крайне бесполезен для -mtt0 с числом тредов больше 1.
So I understand that with mtt1, ldmf is basically like disabled no matter what you do and with mtt0 effect will be almost negligible if -mt > 1, therefore even worse than srep?
-mt1 -mtt0 are thus the only reasonable options for benefiting ldmf and for everything else srep is better?

EDIT: I made 1 quick test with 3 PS1 iso's -> all together 2gb. I only tried -mt4 and with -mtt0 and -mtt1. It really seem to be not working well with -mt4 in either case and giving pretty much same size as with -ldmf0. I get better result with srep+lolz:ldmf0.

From what it looks like to me lolz do not process all data in 1 sweep aka "srep" and then parse it all to matchfinder\cores, it seems rather to work as "per block" or "dictionary", each separately doing its own ldmf in memory? Something like this perhaps?:

data ->mt1 -> lmdf -> lolz1
->mt2 -> lmdf -> lolz2
->mt3 -> lmdf -> lolz3
->mt4 -> lmdf -> lolz4

If so then it would make sense why -mt1 -mtt0 is needed. But this is not be the best solution because lolz is already slow enough and reverting to single core for a feature is really too much with minimal gain against srep.

If I may suggest few ideas:

- much better approach would be to first parse all data at once just like srep does and then compress it. This would make ldmf much more useful regardless of rest of lolz settings. Its basically same behavior as: srep - - <stdin><stdout>.

- rather than using arbitrary numbers for ldc(and maybe ldl), better way would be to directly specify size in b/mb/gb, for both compression and decompression, including chunk size - again similarly to srep. Because user then knows exactly what he get and what data and limits is (s)he working with. Something like -ldl512b(ytes) -ldc4gb(cmp max mem usage) -ldd4gb(decmp. max mem usage) {with ldc and ldd rest would go to swap if limit crossed, for example...}.

-in terms of gaining best speed and maximum possible ratio, ldmf should work exactly like srep with one important exception:
during the "srep" sweep process it would be gentle toward specific data patterns that are known to be better processed by lolz only(aka textures), thus skipping such chunks for example or rearranging them as needed. That is the main thing missing in srep and what was ldmf trying to accomplish in the first place.

In any case, thank you ProFrager. You clearly worked hard during Christmas instead of wasting time drinking and for than you deserve praise. Btw new lolz is still useful contribution, I found it slightly quicker while also consuming less memory on same settings, so thank you again.

EDIT: I have to apologize to ProFrager, I made some tests yesterday and came to better understanding of lolz inner working especially regarding MT/ldmf, at this point I think its current implementation is not so bad at all(You can read about it here: https://fileforums.com/showthread.php?t=102617 ). Only some questions I have left:
- could you describe more in details how different -lde implementations work?
- if -ldc is specified as "ratio", does it literally mean that ldc1 := mem=file_size(1:1), ldc2:=mem=file_size/2, ldc5:=1/5 of mem usage vs file size etc..?
- ldl8 = 256bytes according to specified calculation correct? Thus ~equal to srep -l256, yet memory usage from the mentioned math (src_size/((2 ^ [ldl]) / 16)) mean that 100gb file and ldl8 would only consume ~6.25gb for ldmf? That would be significantly less than srep, is the reason because of tight implementation with compressor?
- if used srep instead of ldmf, would be better to set -dm00 instead of leaving auto detection?
- how is the math "simplified" in fbb vs fba? Also do I understand that they trigger on values > than specified? Example would fba=256, fbb=1024 mean hardest calculations up to 256, simpler between 256-1024 and simplest above >1024?

Thank you
 
Последнее редактирование:

toolame

Пользователь
Проверенный
к предыдущему моему посту
xtool09:t3,c160mb:zlib+srep:m5f:l16384:s55gb:a64+lolz_22c4:ldmf1:ldl7:ldc0:mtt0:mt1:mtb96:d192:tt8:gm20:fba1024:oh14

thread 0 : w/o manager mem_usage = 1793486 kb, manager mem_usage = 624622 kb
alloc mem = 671744 kb, stat compr_size = 10967138
matches num = 3250100, additional mem overhead = 85486 kb

o1 model : 12'336'904 kb
raw graphic model 8 bit : 1'319'418 kb
raw graphic model 16 bit : 605'634 kb
raw graphic model 24 bit : 317'460 kb
raw graphic model 32 bit : 6'531'961 kb
dxt1 model : 11'116 kb
dxt3 model : 562 kb
dxt5 model : 18'750 kb
o1 model pos mod 2 : 8'440'984 kb
o1 model pos mod 4 : 9'777'970 kb
o1 model pos mod 8 : 1'909'749 kb
o1 model pos mod 16 : 632'848 kb
total size : 41'903'362 kb

total decode mem usage = 296mb
25,996,143,076 > 15,216,537,213

xtool09:t3,c160mb:zlib+srep:m5f:l16384:s55gb:a64+lolz_22c4:ldmf1:ldl7:ldc0:mtt0:mt1:mtb96:d192:tt8:ac1:gm20:fba1024:oh14

thread 0 : w/o manager mem_usage = 1786905 kb, manager mem_usage = 624430 kb
alloc mem = 671744 kb, stat compr_size = 11410411
matches num = 3325197, additional mem overhead = 86430 kb

o1 model : 12'336'904 kb
raw graphic model 8 bit : 1'319'418 kb
raw graphic model 16 bit : 605'634 kb
raw graphic model 24 bit : 317'460 kb
raw graphic model 32 bit : 6'531'961 kb
dxt1 model : 11'116 kb
dxt3 model : 562 kb
dxt5 model : 18'750 kb
o1 model pos mod 2 : 8'440'984 kb
o1 model pos mod 4 : 9'777'970 kb
o1 model pos mod 8 : 1'909'749 kb
o1 model pos mod 16 : 632'848 kb
total size : 41'903'362 kb

total decode mem usage = 296mb
25,996,143,076 > 15,922,296,338

xtool09:t3,c160mb:zlib+lolz_22c4:ldmf1:ldl7:ldc0:mtt0:mt1:mtb96:d192:tt8:gm20:fba1024:oh14

thread 0 : w/o manager mem_usage = 6611022 kb, manager mem_usage = 2444049 kb
alloc mem = 2596864 kb, stat compr_size = 13337623
matches num = 3820461, additional mem overhead = 93433 kb

o1 model : 14'397'494 kb
raw graphic model 8 bit : 1'979'176 kb
raw graphic model 16 bit : 974'306 kb
raw graphic model 24 bit : 545'733 kb
raw graphic model 32 bit : 9'948'468 kb
dxt1 model : 15'487 kb
dxt3 model : 1'339 kb
dxt5 model : 25'114 kb
o1 model pos mod 2 : 11'168'757 kb
o1 model pos mod 4 : 13'334'081 kb
o1 model pos mod 8 : 2'466'505 kb
o1 model pos mod 16 : 685'546 kb
total size : 55'542'010 kb

total decode mem usage = 295mb
25,996,143,076 > 15,241,279,121

т.е. если дата разношерстная - то лучше с srep?
или же нужно ldl5 и немерено RAM?
 

zapsip

Пользователь
Здравствуйте.
При компрессии самого большого файла в игре Mutant.Year.Zero.Road.to.Eden.Stalker.Trials с использованием лолз на экране высвечивается
Errorlevel=-1073741819
100.0%
ERROR: general (de)compression error in lolz
Это получается и когда сжимается только этот один файл, так и сразу несколько.
Это получается и когда применяется только метод лолз, так и при комбинации с прекомпом, срепом, икстулзом.
 

zapsip

Пользователь
Потом на другом, причём менее мощном процессоре стало хорошо исполняться метод lolz.
 

nik1967

Old Men
Проверенный
lolz22c4b. При отключении детект pos_ctx/dxt/raw (-dt0) и -ldmf0 при распаковке ошибка:
ERROR: general (de)compression error in lolz:d2047:ldmf0:dt0:mc1023:tt4:mtt0:mtb512
lolz21a7. Все нормально распаковывается.
 

Cortland

Пользователь
input size> 64,016,343,489
output size> 16,292,137,872
Elapsed Time: 37:04:38
Unpack Time: ~ 24 minutes

22c4b
 
Последнее редактирование:

bunti_o4u

Пользователь
First it compress data to $$arcpackedfile$$.tmp.tmp then copy the compressed file to $$arcpackedfile$$.tmp and then copy the compressed file again to output file.
can you pl add - - <stdin> <stdout> support?!!!
 

toolame

Пользователь
Проверенный
First it compress data to $$arcpackedfile$$.tmp.tmp then copy the compressed file to $$arcpackedfile$$.tmp and then copy the compressed file again to output file.
потому что для последовательного доступа к данным при декодировании требуется, чтобы при кодировании некая информации, которая получается после окончания процесса сжатия была в начале архива.
stdin was be cool, but it probably incompatible with ldmf mode (for example: srep write all input data to srep.tmp when compressing from stdin)
 

L-e-o-N

Пользователь
Заметил баг в cls. Если в имени пользователя Windows есть украинские буквы (і, ї, є), тогда при распаковке выбивает ошибка (скрина с ошибкой нет, но она выбивает каждый раз в самом начале распаковки)
 
Сверху