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

lolz test22c4b

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

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 Просмотры: 55

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 есть украинские буквы (і, ї, є), тогда при распаковке выбивает ошибка (скрина с ошибкой нет, но она выбивает каждый раз в самом начале распаковки)
 

nik1967

Old Men
Проверенный
От ты ж блин, Prof еще и враг Украны :) флуд однозначно
 
Последнее редактирование:

akkush

Новичок
Hi guys !

I would like to ask : how can i decompress using lolz in stdio mode,but without cls-lolz ?!
Is it possible somehow ?
Thanks in advance !
 
Сверху