» FreeArc (часть 4)

insorg
ты и сам мог распаковать sfx'ы командой upx -d


Цитата:

Я так понимаю все задержки из-за шифрования и комментирования. Попробуйте довести эти функции до нормального состояния, а тогда и будем играть с вкладками и размещенным опций.

давай уточню: в CUI никаких проблем с этими фичами нет. проблема в том, чтобы выработать удобный для их использования GUI. а для этого надо как раз быть "опытным пользователем этих опций"

Bulat_Ziganshin
Та хватит новых фитч! Последняя бета достаточно стабильна чтобы стать финалкой.

На будущее: компилируйте ФА с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE чтобы потом вручную не прикручивать этот флаг.

Bulat_Ziganshin

Это прописано в arc.ini + cls.ini.

Цитата:

проблема в том, чтобы выработать удобный для их использования GUI. а для этого надо как раз быть "опытным пользователем этих опций"

советую вам написать сообщение что "принимаются пожелания по совершенствованию GUI для функций шифрования и комментирование" на этом и обязательно на английском форуме. я думаю что опытные пользователи этих опций откликнуться

vasulpr

Цитата:

На будущее: компилируйте ФА с параметром IMAGE_FILE_LARGE_ADDRESS_AWARE чтобы потом вручную не прикручивать этот флаг.

этот флаг там стоит давно-давнёшеньки, внимательней будьте

spider919191
гм, на этом мысль останавливается. разве что возникает ещё большее желание встроить это внутрь freearc чтобы уж точно знать кого бить по наглой рыжей морде

Сам шифром и комментом не пользуюсь, да и гуи вообще не использую, а только консольку, но предложение дам.
Можно сделать почти аналогичное по расположению как у WinRAR или даже 7Zip.
Думаю, полностью перекопировать интерфейс, конечно же, смысла нет, но логическое расположение можно использовать подобное (если имеющееся не устраивает).

Действительно в последней версии стоит. Извините недосмотрел!Все претензии забираю.
Жду 0.70!

Bulat_Ziganshin
спасибо!
а опция rep d: это может быть одно из двух
- на дистанции до от начала данные пропускаются
- если между двумя любыми повторениями дистанция меньше, то они пропускаются

это вопрос по поводу rep+srep
Добавлено:
- может быть еще: данные кодируются, если встречается одна или более из дистанций больше

Цитата:

 пожалуйста, НЕ нужно жать sfx-модули upx-ом (или чем там ты их жмёшь), ибо это жутко вешает мне систему (антивирь сканит и вешает).

Лучше авиру (да и любой другой лохотрон под названием "антивирус") в трэш отправить, имхо.

Bulat_Ziganshin

Цитата:

а с utf-8 распаковывает?

Отлично распаковывает!

Bulat_Ziganshin
Если при упаковке консольной версии (хотя может с GUI тоже самое), с помощью внешних упаковщиков (precomp, srep, lzma_x64 etc...), прервать упаковку, то не удаляются временные файлы с папки temp, можно это как-то поправить? А то каждый раз руками чистить ни есть гуд)

Приветствую.
Подскажите пожалуйста,каким методом сжатия следует пользоваться при сжатии игры,где все файлы архивы и исполняемый файл игры? Пробовал эксперементировать,вручную настраивал метод сжатия,но больше 10% сжатия не получил.

Цитата:

НЕ нужно жать sfx-модули upx-ом

а я не против оного.
не знаю как это вписывается в концепцию, но хотелось бы дополнительную подстройку для модулей sfx, обжимать или нет. чтобы я сам решал.
в идеале, сам мог добавить чего хочу для обжатия моих самораспаковывающихся архивов. через опции и .ini
не на одном upx'е свет клином сошелся)

но так как не вникаю в общий замысел и трудности реализации, просто пожелание.

Edison007007
нет

folta

Цитата:

но хотелось бы дополнительную подстройку для модулей sfx, обжимать или нет

По-моему, это чисто надуманная проблемма. Необходимый модуль, "обжатый" upx-ом, можно сохранить под другим именем, типа freearc_upx.sfx и при необходимости подключать его вместо стандартного freearc.sfx

Цитата:

P.S. Может заменить в TotalCommander MultiArc plugin ANSI на UTF-8, а то с ANSI не распаковывает архив если в его пути есть русские имена?

ок, внёс твой конфиг в сборку. кто ещё использует TotalCommander, плиз потестируйте с русскими, и каким-нибудь там китайско-арабскими именами файлов внутри архива этот конфиг: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1142&limit=1&m=1#1

Добавлено:
Eagle1726
тебе сюда - http://forum.ru-board.com/topic.cgi?forum=5&topic=30239&glp

SREP 3.9 beta released:English release notes
Russian release notes
Download

Bulat_Ziganshin
Про адресное пространство (нехватку памяти)

Ранее уже говорили
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=2240#13

Провел эксперименты с GUI, двухъядерный процессор, кое-что непонятно.
Привожу методы, возникает ли проблема, размер использованной памяти (уже из консольной версии)
rep:1gb:96:c16:d4m:s32+4x4:tor:6:4mb:h8mb - проблема - tempfile 1232 mb rep:1gb:96:c16:d4m:s32+4x4:i0:tor:6:4mb:h8mb - норм - 1282 mb,
rep:1gb:96:c16:d4m:s32:h25+4x4:tor:6:4mb:h8mb - норм - 1218 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:i0:tor:6:4mb:h8mb - норм - 1202 mb

rep:1gb:96:c16:d4m:s32+4x4:i0:tor:6:8mb:h8mb - проблема - tempfile 1232 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:tor:6:8mb:h8mb - проблема - 1268 mb
rep:1gb:96:c16:d4m:s32:h25+4x4:i0:tor:6:8mb:h8mb - норм - 1236 mb

Где вижу противоречие?
Во второй строчке требуется память 1282 mb - и все нормально
Во второй строчке от конца требуется память 1268 mb - и проблема
(в этом случае в GUI места не хватило, в консоли - хватило, такое не первый раз)

Раз на раз не приходится, и чисто случайная нехватка памяти?
Или дело еще и в используемых методах?
(Могу по этим двум методам повторить)

Добавлено:
Или есть неточности в информации, которую выдает консольная версия?

new alpha version:fixed bug with using synonyms in -mc (i.e. precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep)
-mm/-mm+ definition was simplified - now it's always equal to -mm=max



Новая альфа-версия:исправлена ошибка с использованием синонимов в -mc (в частности precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep)
определение -mm/-mm+ упрощено - теперь они всегда эквивалентны -mm=max

Bulat_Ziganshin, паковал архив с такими параметрами -lc- -msrep:l32+lzma:a1:mfbt4:d250m:fb273:mc1000000:lc8:lp4 и возник вопрос:

фриарк при попытке установи значения d400m выбивает ошибку "невозможно выделить память, необходимую для распаковки...." и параметр сжатия.

У меня 8 гигов оперативки, я так понимаю что эта ошибка возникает из-за неспособности архиватора задействовать полностью всю свободную оперативку. Когда можно ожидать x64 версию?

СНИМАЮ ВОПРОС - УВИДЕЛ ВЫШЕ)))
----------------------------------------------------------------------------------------------------------------------------------
И ещё одно пожелание, профрагер, когда создал SrepInside, модифицировал arc.ini, и таким образом нужно паковать через батник. Если паковать через контекстное меню - архив в итоге не распакуется))

попытался заменить ваш arc.ini на его - архиватор ругается. Пожалуйста, в следующей версии (я сижу на 0,666) добавьте в секции arc.ini
[External compressor:srep] и [External compressor:precomp] строку header = 0

таким образом можно будет паковать из контекстного меню - так имхо удобнее)))

Bulat_Ziganshin спасибо!

Shuld
1. неточности есть в tor, я их пока не правлю поскольку с ним обычно память не добивают под завязку
2. в данном случае дело наверно не в этом, поскольку freearc решение принимает о создании временного файла ориентируясь на ту же информацию от tor

Цитата:

-msrep:l32

без l32 сжатие будет лучше

Цитата:

Когда можно ожидать x64 версию?

когда выйдет ghc/win64. пока используй LZMA-x64

Цитата:

Пожалуйста, в следующей версии (я сижу на 0,666) добавьте в секции arc.ini  
[External compressor:srep] и [External compressor:precomp] строку header = 0

давай наоборот, попросим профрагера убрать header = 0? ведь не просто так по умолчанию 1


Добавлено:

Цитата:

Действительно в последней версии стоит

он там стоит уже 4 года

сорри, я залил эту альфу заново, поскольку в ней была серьёзная ошибка - FreeArc.exe был скомпилирован без оптимизации. заодно я улучшил описание:


new alpha version:fixed bug with using synonyms in -mc (i.e. precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep)
-mm/-mm+ definition was simplified - now it's always equal to -mm=max
unarc.dll: info about 'l' command added to the readme-rus.txt
please note that -max (-m9p) compression mode provides maximum compression with precomp+srep+dispack, while -m9j mode does the same plus jpeg recompression
Using synonyms added in the last versions, now FreeArc implements "Exprerimental compressor" checkboxes in the following way:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/exe2
srep: -mc:rep/maxsrep
precomp: -mc$default,$obj:+precomp
intense: -mc$default,$obj:+maxprecomp
jpeg: -mc$default,$obj:+precompj
intense+jpeg: -mc$default,$obj:+maxprecompj


Новая альфа-версия:исправлена ошибка с использованием синонимов в -mc (в частности precomp, precompj, maxprecomp, maxprecompj, exe2, maxsrep)
определение -mm/-mm+ упрощено - теперь они всегда эквивалентны -mm=max
unarc.dll: в readme-rus.txt добавлена информация о команде 'l'
обратите внимание: режим сжатия -max (-m9p) реализует максимальное сжатие с precomp+srep+dispack, а -m9j делает то же самое плюс пережатие jpeg

Добавленные в последней альфе синонимы используются для реализации чекбоксов "Экспериментальных алгоритмов" следующим образом:

lzma:1gb: -mc:lzma/lzma:max:512mb
exe2: -mc:exe/exe2
srep: -mc:rep/maxsrep
precomp: -mc$default,$obj:+precomp
intense: -mc$default,$obj:+maxprecomp
jpeg: -mc$default,$obj:+precompj
intense+jpeg: -mc$default,$obj:+maxprecompj

сделал многопоточную дедупликацию. к сожалению, 5 ГБ/с (пока?) не получилось, всё упёрлось в скорость чтения из дискового кеша (!!!):

Код: SREP 3.91 (multi-threaded)> for %a in (1 2) do @srep64g.exe -m%a -v -nomd5 -l4k i:\4g nul
3,600,625,251: 79.47%. Cpu 667 mb/s ( 6.474 sec), real 2878 mb/s ( 1.502 sec) = 431%
3,520,842,851: 77.70%. Cpu 359 mb/s (12.028 sec), real 2153 mb/s ( 2.007 sec) = 599%

SREP 3.9 (single-threaded)> for %a in (1 2 3) do @srep64g.exe -m%a -v -nomd5 -l4k i:\4g nul
3,600,352,085: 79.46%. Cpu 1135 mb/s ( 3.806 sec), real 1095 mb/s ( 3.946 sec) = 96%
3,531,948,453: 77.95%. Cpu 576 mb/s ( 7.504 sec), real 549 mb/s ( 7.875 sec) = 95%
3,419,303,639: 75.46%. Cpu 135 mb/s (31.933 sec), real 206 mb/s (21.010 sec) = 152%

Shuld
занялся я этим rep. вот первые результаты:

сжатие с rep:1g

старый REP: 4,531,060,447 -> 3,046,406,598: 67.23% Cpu 364 mb/s (11.872 sec), real 333 mb/s (12.989 sec) = 91%
новый REP: 4,531,060,447 -> 3,064,484,898: 67.63% Cpu 529 mb/s (8.174 sec), real 1341 mb/s (3.221 sec) = 254%


сжатие с rep:1g+xtor:3

старый REP: 4,531,060,447 -> 1,283,663,780: 28.33% Cpu 105 mb/s (41.137 sec), real 270 mb/s (16.026 sec) = 257%
новый REP: 4,531,060,447 -> 1,286,102,352: 28.38% Cpu 87 mb/s (49.671 sec), real 581 mb/s (7.443 sec) = 667%


Для сравнения чистый xtor:3

4,531,060,447 -> 1,698,510,452: 37.49% Cpu 83 mb/s (52.260 sec), real 586 mb/s (7.380 sec) = 708%


Т.е. теперь даже на моей машине нет потерь в скорости -m1 от добавления REP, при этом сжатие с REP выше в 1.32 раза

Подскажите, делаю распаковку так unarc.exe x files.arc -pPass -o+ -dpC:\path1
видна консоль, её можно скрыть?
Спасибо!

Не смог найти информацию, подскажите плиз:

С какими максимальными размерами файлов работает этот архиватор? До 2 Гб или больше?
А если 5 Гб - чем архивировать?
Какое максимальное число файлов в архиве при архивации (сжатии)?

Выложил новый REP для тестов на http://freearc.org/download/testing/newrep.7z

может найдёте ошибку какую или ещё что интересное прежде чем я выпущу альфу

кстати, у REP появился новый параметр - :c, размер чанка, аналогично SREP. например, rep:c64==rep:l512:c64 разбивает файл на куски по 64 байта, чтобы найти больше совпадений длиной от 512 байт. параметр :a пока не работает