1. Уважаемые гости и пользователи форума.
    Администрация настоятельно рекомендует не регистрировать несколько аккаунтов для одного пользователя. При выявлении наличия мультиаккаунтов будут заблокированы все учетные записи данного пользователя.
    Аккаунты, зарегистрированные на временную почту будут также заблокированы.

lolz test22c4b

universal compressor

Метки:
  1. Знаток R.G. Revenants

    Регистрация:
    16 июн 2011
    Сообщения:
    358
    Симпатии:
    736
    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.

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

    скиньте эти наборы на файлообменник, посмотрю, может можно что подправить. Но в любом случае этот режим останется ускорением сжатия при больших -tt жертвуя степенью сжатия.
     
    zapsip нравится это.
  2. Ветеран Модератор

    Регистрация:
    15 июн 2011
    Сообщения:
    956
    Симпатии:
    549
    Нормальное же явление, что сжатие хуже. В редких случаях примерно одинаково, еще реже с ac1 лучше)

    Как я понимаю, на новую модель для raw-графики забил?
     
  3. Ветеран

    Регистрация:
    3 фев 2014
    Сообщения:
    206
    Симпатии:
    48
    Sims 4
    Код (Text):
    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
    Код (Text):
    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: промучал
     
    Последнее редактирование: 10 фев 2019
  4. Старожил

    Регистрация:
    21 фев 2015
    Сообщения:
    14
    Симпатии:
    5
    Пол:
    Мужской
    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
     
  5. Ветеран

    Регистрация:
    1 дек 2015
    Сообщения:
    177
    Симпатии:
    56
    Пол:
    Мужской
    Появилась проблема. Файл пакуется но при распаковке происходит ошибка(программа вылетает)
    Ниже загрузил файл обработаный всеми алгоритмами цепочки кроме lolz (в 7z архиве)
    Вот параметры lolz(версия последняя):
    Код (Text):
    [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
     

    Вложения:

    • error.7z
      Размер файла:
      2,8 МБ
      Просмотров:
      17
    ProFrager нравится это.
  6. Пользователь

    Регистрация:
    27 фев 2018
    Сообщения:
    6
    Симпатии:
    0
    the error from oh14 -os14 is the same with lolz ver 21.7
    change to oh12 -os8 it should work...
     
  7. Ветеран Модератор

    Регистрация:
    15 июн 2011
    Сообщения:
    956
    Симпатии:
    549
    писали ведь
     
    Simorq нравится это.
  8. Старожил

    Регистрация:
    21 фев 2015
    Сообщения:
    14
    Симпатии:
    5
    Пол:
    Мужской
    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
     
  9. Знаток R.G. Revenants

    Регистрация:
    16 июн 2011
    Сообщения:
    358
    Симпатии:
    736
    Спасибо. Ошибка действительно есть. Столько опций, конечно, не стоит писать, больше половины из них выставлены по умолчанию. А проблема возникает из-за -gm21 (а именно из-за последней единицы). Позже посмотрю что да как там.
     
    Andrag, dixen18 и Simorq нравится это.
  10. Ветеран

    Регистрация:
    1 дек 2015
    Сообщения:
    177
    Симпатии:
    56
    Пол:
    Мужской
    Спасибо за информацию. В старой версии все работает. А что касается опций то у меня все опции проставляет программа, в которой в окне нужно выбирать настройки, и я просто от туда скопировал все параметры
     
  11. Пользователь

    Регистрация:
    12 янв 2018
    Сообщения:
    16
    Симпатии:
    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
     
    Последнее редактирование: 16 фев 2019
    L-e-o-N нравится это.
  12. Ветеран

    Регистрация:
    3 фев 2014
    Сообщения:
    206
    Симпатии:
    48
    к предыдущему моему посту
    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?
     
  13. Ветеран

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

    Регистрация:
    4 сен 2011
    Сообщения:
    269
    Симпатии:
    49
    zapsip, только что упаковал файл xtool+srep+lolz и все гуд
     
  15. Ветеран

    Регистрация:
    25 дек 2016
    Сообщения:
    150
    Симпатии:
    28
    Потом на другом, причём менее мощном процессоре стало хорошо исполняться метод lolz.
     
  16. Old Men Проверенный

    Регистрация:
    17 июн 2011
    Сообщения:
    461
    Симпатии:
    434
    Пол:
    Мужской
    lolz22c4b. При отключении детект pos_ctx/dxt/raw (-dt0) и -ldmf0 при распаковке ошибка:
    ERROR: general (de)compression error in lolz:d2047:ldmf0:dt0:mc1023:tt4:mtt0:mtb512
    lolz21a7. Все нормально распаковывается.
     

Поделиться этой страницей