» FreeArc (часть 4)

Bulat_Ziganshin
Версия FreeArc 0.67 (March 15 2014) имеет неприятный глюк: если архивировать с включенной опцией выключения ПК по завершении операции, то при попытке отменить ахрхивацию, сперва выдет ошибку (вообще ее всегда выдает при отмене операции), а затем все равно выключает комп.

Цитата:

я попробовал и на логах, и худтекстах в utf8 - детектятся как текст. могу предположить что у тебя много строчек одинаковой длины

Да, есть такое, бывает 5-10 строк подряд одинаковой длины.


Цитата:

или классически - один архив с базовой версией, плюс дополнительные для инкрементов

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

Arc.exe умеет сжимать каждый файл в отдельный архив, и при --sync перепаковке менять только те которые изменились ?

Заменили ini из arc 2014-12-27.rar, получили такую картину:
Оригинал: 548,729,751
-m98: 182,249,123 - 33.21% ~2min
-m99: 182,218,881 - 33.21% ~10min
-mx -s: 152,906,960 - 27.87% ~10min

Как так модифицированные опции с легкостью бьет стоковый сетап?

7-zip (lzma2, 192mb): 152,905,373 - 27.87% ~12min

И почему вдруг 7-zip 9.22b побил arc?

Один товарищ разработал библиотеку для распаковки архивов FreeArc в NSIS: http://www.smart-arab.com/2013/04/freearc-for-nsis-plugin/

или на офсайте: http://nsis.sourceforge.net/FreeArc_plug-in

muzf
попробуй - наверно получится

izmerenie
1. время распаковки (точнее тестирования) сравнил? вообще надо lt сразу проверять
2. если сжатие ожинаково то 7z будет чуть меньше ибо у него компактней служеюная инфа

Булат, сейчас в ФА присутствуют компрессоры/препроцессоры: REP, Delta, dispack, exe, tta, mm, dict, lzma, lzp, lz4, tor, ppm, grzip, это все? Или я что-то пропустил?

Bulat_Ziganshin
ладно с 7-zip (результат почти равен режиму -mx -s, что по сжатию, что по времени), но почему "-mx -s" жмет лучше -m99 почти на 6% при таких же временных затратах и при меньшем (на 200мб) использовании памяти?

Edison007007
ppmd,4x4,cls,external + 4 алгоритма шифрования

izmerenie
1. Как можно отвечать на ваш вопрос, когда неясно что сжимали?
2. Идеального варианта на все случаи жизни не бывает. Для каждых данных используйте тот вариант, что больше подходит. Вот и все.

Добавлено:
3. Методы -m9х наиболее эффективны для больших размеров данных, 2 Гб и более. Вы сжимали "всего" 548,729,751 байт.
(Для такого объема Вы могли использовать метод -m89 с тем же размером архива, но ОЗУ потребовалось бы меньше.)

Добавлено:
----
Было бы полезно в виде обратной связи, если бы Вы испытали эти методы на своих (разных) данных, а потом бы подробно осветили результаты. Была бы пища для совершенствования.

странные эти гугловцы..
сделали зачем-то алгоритм, которому нужно в 100 - 1000 раз больше CPU для повышения сжатия на 3-8 % по сравнению с zlib

Compress data more densely with Zopfli - Google Developers Blog
http://googledevelopers.blogspot.nl/2013/02/compress-data-more-densely-with-zopfli.html

при том, что в 7-zip сто лет в обед есть оптимизированный тот же самый Deflate, который даёт такой же выигрыш по сжатию гораздо меньшими усилиями:
"For ZIP and GZIP formats, 7-Zip provides a compression ratio that is 2-10 % better than the ratio provided by PKZip and WinZip"

рассказать им что ли?..

Shuld
Сжималась папка с конфигурацией для 1С 8. На других данных при случае обязательно попробуем.

sabio
да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc

Ну что, когда там будет 64 битная версия ? 2015 уже на дворе. 20% прибавки скорости на дороге не валяются.

Bulat_Ziganshin

Цитата:

да я вообще не понимаю, почему гугл пользуется устаревшим deflate вместо прогрессивного freearc

это, конечно, да - FreeArc рулит!

но, к сожалению, не везде его (сейчас) получится использовать
например, PNG основан на Deflate или, скажем, сжатие HTTP трафика

При установке игры 99% установщик freearc выдает ошибку -7.Что можно сделать с этим и как это исправить?Пожалуйста подскажите или есть какой нибудь патчик для этого!!!

1. При попытки заменить при распаковке существующий файл с атрибутом "Скрытый" / "Только чтение" получаем ошибки:
GUI: "FileName": open: permission denied (Permission denied).
Uharc.exe: ERROR: can't open file "FileName" | с атрибутом "Только чтение" - распаковывается нормально.
Arc.exe:"FileName": open: permission denied (Permission denied).

2. Если начать распаковывать архив, нажать "отмена", то можно получить следующиe ошибки:
2.1: Распаковываем частично (через GUI папка/файл(ы)): ArcExtract.hs:152:56-126-Non-exhaustive patterns in lambda. Повторное нажатие "отмена": User error.
2.2: Распаковываем весь архив, через меню: wclose: invalid argument (Bad file description).
2.3: Распаковываем весь архив через GUI: User error - два раза. Повторное нажатие "отмена": User error -> CompressionLib_dbHm: interrupted.
После пунктов 2.1 и 2.3, FreeArc закрывается.
Было бы неплохо если распаковку можно было прерывать без ошибок

muzf
в конце февраля первая альфа

Более быстрый LZMA.

just one screenshot of my current work

C:\>timer exdupe.exe -o -x0 -t12 -v5 i:\4g nul
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 3,675,346,418 bytes

Kernel Time = 1.388 = 00:00:01.388 = 17%
User Time = 48.953 = 00:00:48.953 = 604%
Process Time = 50.341 = 00:00:50.341 = 621%
Global Time = 8.096 = 00:00:08.096 = 100%


C:\>srep64g.exe -m0 -l4k -nomd5 -mmap -s22. I:\4g nul
100%: 4,531,060,447 -> 3,603,337,912: 79.53%. Cpu 597 mb/s (7.238 sec), real 591 mb/s (7.315 sec) = 99%

Kernel Time = 0.936 = 00:00:00.936 = 12%
User Time = 7.238 = 00:00:07.238 = 98%
Process Time = 8.174 = 00:00:08.174 = 111%
Global Time = 7.347 = 00:00:07.347 = 100%

Добавлено:
Edison007007
1. посмотрю
2. да, там большие проблемы с обработкой ошибок. к сожалению, надо основательно код переписать чтобы их решить. планируется в следующей версии

Resursator
если хочешь, можешь его постестировать на реальных данных и нам рассказать. пока что я знаю - что сжатие хуже, распаковка быстрее. упаковка может распараллеливаться на много яджер, а не только два как у lzma

Bulat_Ziganshin

Цитата:

пока что я знаю - что сжатие хуже

А насколько хуже ?


Цитата:

распаковка быстрее

Это большой плюс.


Цитата:

упаковка может распараллеливаться на много яджер, а не только два как у lzma

Т.е. на современных 4-х, 6-, 8- и более ядерных CPU он будет заруливать по скорости обычный LZMA в глубокие минуса.


Цитата:

в конце февраля первая альфа

Ждем. Главное, чтобы она в дальнейшем не осталась вечной альфой.

извините, если уже было, но всё же:

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

всегда стоит по умолчанию т.е. в папку откуда запускается ехе-шник... а можно прописать например "%MyDocuments%/Soft/" ? если ДА , то где это можно сделать?

Цитата:

А насколько хуже ?

не знаю. я и предлагаю потестировать и сказать наколько он вам интересен для добавления в fa. я со своей стороны могу предварительно глянуть чтобы оценить сложность добавления

Добавлено:
Nail441
обратись к автору репака или - проще - скачай другой репак. мы тут не поможем

LieToMe
нет, таких возможностей нет. если нужен нестандартный функционал - надо nsis/inno installer делать, пока что это единственный вариант, благо что автоматом .iss сгенерить несложно

Лучше бы Игорь развивал свой LZMH вместо LZMA2.

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

возможно такой вопрос уже был, но все же спрошу: сколько ядер использует freearc для компрессии и декомпрессии, так же как и LZMA - 2? или все?
если не все, то планируется ли поддержка многоядерных процессоров?

AftarJjet
мдаааааа.... кому что... 666 - число Сатаны, а версия 0.666 и уже есть 0.67... нет никакого скрытого намека с мусульманством и христианством...
хотя ждем ответа от разработчика

csf22
максимальное сжатие (а также high/ultra) - два ядра для сжатия, одно при распаковке, собственно как и в lzma. более слабые методы сжатия - многопоточные в обе стороны