» FreeArc (часть 4)

Bulat_Ziganshin
ты ПМ читаешь ?

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

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

Кто-нибудь сравнивал степень сжатия и скорость распаковки больших файлов (скорость упаковки не важна) с архиватором 7-zip?

vasulpr

Цитата:

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

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

Mercedes_Benz
Да.

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

КТО НИБУДЬ ПОМОЖЕТ СДЕЛАТЬ ТАКУЮ ФИЧУ, ЗА ОТДЕЛЬНУЮ ПЛАТУ?

а ты БУЛАТ не пойму че так игноришься, я че не так спращиваю?

оставьте плиз контакты тут или ПМ для связи!

Bulat_Ziganshin

Цитата:

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

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

andhunt

Цитата:

оставьте плиз контакты тут или ПМ для связи!

контакты написаны в "О программе", пишите письма.

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

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

http://freearc.org/download/unarc.arc

там два вариант - hide_console вообще не создаёт консольного окна из gui-программы, думаю это именно то что многие давно хотели и для unarc.dll, и для gui sfx, и для самого freearc.exe

Цитата:

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

dll работает. Но было бы не лишним реализовать поиск консольных декомпрессоров рядом с самой дллкой или arc.ini, а не в WINDOWS\System32, как сейчас происходит.

Bulat_Ziganshin

Цитата:

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

unarc.exe x a1.arc
FreeArc 0.67 unpacker. Extracting archive: a1.arc
Extracting pdf.TAR.pcf (249562113 bytes)

ERROR: unsupported compression method srep:m3f:s250m

unarc.exe x a2.arc
FreeArc 0.67 unpacker. Extracting archive: a2.arc
Extracting pdf.TAR11.pcf (249562113 bytes)

ERROR: unsupported compression method srep

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

Цитата:

и ещё распаковку 32-битным srep

хотел добавить ещё проверку для
srep.exe
srep32.exe
так при проверке на подпорченном файле крашаться (неизвестно что будет, во время тестов), srep32i.exe отрабатывает нормально.

srep.exe
Инструкция по адресу "0x77c37000" обратилась к памяти по адресу "0x029e1000". Память не может быть "written".

srep32.exe
Инструкция по адресу "0x0040eb94" обратилась к памяти по адресу "0x02151000". Память не может быть "written".

Цитата:

-msrep:l32

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

Цитата:

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

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

Цитата:

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

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


Добавлено:

Цитата:

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

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

egor23
кстати, напиши свой тестовый скрипт. оставил на ночь вот такой:

@%*
@if errorlevel 1 time <nul >>u:\tester.log
@tester.cmd %*

tester.cmd srep -d 5g.srep-r nul

3 тыщи проверок по 5 гб = 15 тб данных не выявили проблем. однако, при распаковке этого файла используется всего 63 мб озу. и у меня возникло ещё одно интересное предположение - а что если сбой в srep происходит из-за необычно высокой нагрузки на блок трансляции адресов? обычные приложения используют озу довольно локально, а тут идут постоянно скачки по адресам. правда, тогда обычный rep с большим словарём точно также бы сбоил. вот, Егор, ещё один кандидат для тестов - его алгоритм мало чем отличается от srep, в конце концов



Цитата:

ERROR: unsupported compression method srep:m3f:s250m

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

Добавлено:

Цитата:

при проверке на подпорченном файле крашаться

так в decompress нет никаких проверок, это у меня в to-do записано

и ещё - проверь распаковку в 2.91, там алгоритм был попроще, вдруг я наворотил что-то идеологически невыдержанное

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 раза

Bulat_Ziganshin
ты и в правду странно себя ведёшь. я уверен, что ты получаешь уведомления об ПМ.
Если тебе начхать или ты считаешь это неважным, то может кто другой сможет помочь.

Цитата:

Булат, привет.
Я всё же насчёт иконок.
Откликнулся знакомый и попросил тз.
Я хотел попросить тебя его оформить - хотя бы что нужно, каких размеров, в каком количестве и в каком формате.
Мои мысли:
1. логотип - давай плясать от существующего - может он его глянет и что-нибудь подредактирует.
2. иконки - я думаю дать ему как наводку сравнение 3-ёх архиваторов как на форуме и темы для WinRar (http://www.rarlab.com/themes.htm) и 7zip (http://www.7-zip.org/logos.html).

От тебя нужно тз и может предложения или мысли если есть какие.

Спасибо.

или это тоже тролинг ?

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

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

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

Bulat_Ziganshin

Цитата:

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

так лежит, более того ещё и пробывал прописывать путь к нему, не работает.

Цитата:

3 тыщи проверок по 5 гб = 15 тб данных не выявили проблем.

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

Цитата:

Запустил тест примерно в 7:00, поставил на паузу в 13:30, т.е. прошло 6.5часов, 1300 проходов.
В итоге получилось два сбойных прохода:
772_xcmd_split.TAR.pcf в 10:56
804_xcmd_split.TAR.pcf в 11:06

Цитата:

а на ночь поставить memtest гонять

memtest ничего плохо мне не сказал

Цитата:

я сделал вариант unarc.dll/sfx, который корректно работает с stdin-to-stdout фильтрами. у меня с srep работает. проверяйте:

кстати 2.95 в связке с arc.exe фигня получается, должен получится архив 74МБ, а получается 40МБ.

Добавлено:

Цитата:

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

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

Добавлено:

Цитата:

arc.ini с описанием srep должен лежать в одном каталоге с unarc.exe

нашёл причину, стоял пробел перед секцией:
пробел[External compressor:srep]
какой нежный unarc оказался

Цитата:

кстати 2.95 в связке с arc.exe фигня получается, должен получится архив 74МБ, а получается 40МБ.

причём в temp как раз создаётся файлик 74МБ, но на выходе получае 40МБ

Добавлено:

Цитата:

и ещё - проверь распаковку в 2.91, там алгоритм был попроще, вдруг я наворотил что-то идеологически невыдержанное

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

Посмотрим.
А что, rep стал хуже сжимать?
Это не нужно!
По-моему он и так быстрый, ему бы сильнее сжимать.

Shuld
лучше уж среп дорабатывать и прикручивать в алгоритм, чем тратить время на рэп!

Bulat_Ziganshin
Зачем вы его дорабатываете? Какой смысл в этом, если есть лучшая альтернатива?

Bulat_Ziganshin

Цитата:

добавил, но тесты завтра утром планирую запустить

1000 проходов (распаковка srep и rar) ничего не дали

Цитата:

кстати, напиши свой тестовый скрипт. оставил на ночь вот такой:

[more=Читать дальше..]
[no]
cls
@echo off
color
setlocal enabledelayedexpansion
set /a nn=0
set /a DD=7
set bad_dir=c:\temp\bad\
set file_original=c:\temp\xcmd_split.TAR.pcf
set file=xcmd_split.TAR.pcf
set file_srep=xcmd_split.TAR.pcf.srep295_l64_a4
set srep32i=srep295_32i.exe
set srep32=srep295_32.exe
set srep=srep295.exe
:m1
set /a nn=%nn%+1
echo parts nn=%nn%
srep\%srep32i% -d -nomd5 %file_srep% %file% >>nul 2>&1
(md5sum\md5sum.exe -c md5\%file%.md5 >>nul 2>&1) & (IF ERRORLEVEL 1 (GOTO m2) else (del /F /Q %file% >>nul 2>&1) & GOTO m1)
:m2
set PP=SREP32i
set logs=%bad_dir%%DD%_logs_%nn%_%PP%
echo bad md5 PP=%PP% nn=%nn%
echo bad md5 PP=%PP% nn=%nn% >%logs% 2>&1
md5sum\md5sum.exe -b %file% >>%logs% 2>&1
(fc /b %file_original% %file% >>%logs% 2>&1)
xdelta\xdelta3.exe -0 -B 134217728 -W 16777216 -P 16777216 -I 0 -v -e -s %file_original% %file% %bad_dir%%DD%_diff_%nn%_%PP%_%file% >>%logs% 2>&1
del /F /Q %file% >>nul 2>&1
GOTO m1
[/no]
[/more]

Shuld
окончательное сжатие (с учётом tor/lzma) изменилось несильно, и то в основном в быстрых режимах. а скорости rep, как я уже говорил, было недостаточно для -m1 на многоядерных машинах. в моих результатах это хорошо видно - у меня rep+xtor:3 стал вдвое быстрее

как существенно улучшить результаты rep - я не знаю

vasulpr
у srep есть свои недостатки, в первую очередь неспособность обрабатывать данные чисто последовательно. поэтому я его не прикручиваю к fa. впрочем, методика ускорения там одинакова - я её сейчас опробовал на rep, затем прикручу к srep тоже

Прошу прощения, вопрос (автору). Как автор одного из архивных плагинов под Far Manager (newarc) интересуюсь наличием исходного кода freearc.fmt. А поскольку newarc умеет несколько больше, интересуюсь также "где почесать" для извлечения файлов и их добавления во freearc архивы. Будет прекрасно, если средствами "чистого" кода или с помощью некой dll от freearc. Ну, если простые методы существуют. Или объяснят сложные.

Спасибо.

Bulat_Ziganshin
Покрутил новый реп.
Везде есть небольшое ускорение.

1. На быстрых методах (tor) ускорение сопровождается небольшим ухудшением сжатия, настолько небольшим, что вполне оправдано!
2. На методах lzma я как правило наблюдаю улучшение сжатия(?!) Приятный сюрприз.
Но непонятный.

Как я понял по умолчанию сделали h26->h24?
У меня на работе есть одна папка, которая при h24 сжимается намного хуже, завтра посмотрю.

:c, размер чанка - мне непонятно, где посмотреть?

Добавлено:
ps я имел ввиду, что Вы уменьшили размер хэша по умолчанию?

Shuld
:c по умолчанию = :l-1, округлённое вниз до ближайшей степени 2. т.е. :l512 -> :c256, :l511 -> :c256, :l513 -> :c512. весь файл разбивается на куски длины :c, и индексируются и ищутся совпадения именно среди них

2. дело в том, что новый REP находит меньше совпадений длины, близкой к 512 байтам (т.е. :l). но поскольку такие совпадения находятся "на грани" и частенько дают даже проигрыш, на результате rep+lzma эти проблемы REP почти не сказываются. а в связке rep+tor важнее скорость

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



Цитата:

Как я понял по умолчанию сделали h26->h24?

да. сейчас по умолчанию размер хеш-таблицы равен учетверённому размеру таблицы, достаточной для сохранения всех хешей чанков. чанк по умолчанию - 256 байт, соответственно при 1 гб словаре у нас 4 миллиона чанков, а хеш-таблица заводится на 16 миллионов (2^24) записей, т.е. 64 мб. при меньшем размере чанка размер хеш-таблицы по умолчанию увеличивается, но не превышает четверти размера буфера. вручную конечно можно поставить больше

а тебе заранее могу сказать, что выигрыша от h26 не будет, поскольку хеш-таблица индексируется хешем, имеющим максимальное значение из 256 (:c) подряд расположенных хешей. поэтому среднестатистически все хеши попадают в диапазон размером 2^32/256==2^24 варианта и больший размер хеш-таблицы при rep:1g:c256 просто почти бесполезен

WARP_ItSelf
1. скачиваешь исходники 0.67 а ещё лучше берёшь с svn
2. читаешь readme.txt и настраиваешь среду компиляции

исходники fmt в каталоге Unarc, и для их компиляции достаточно c++, компилятор хаскела не нужен. там же есть код распаковки, можно поколдовать над исходниками чтобы добавить в fmt FreeArcExtract либо вызывать его снаружи из unarc.dll

для сжатия тебе понадобится freearc.dll. обращаться к ней несложно, но это 3 мб. такое устроит?

Добавлено:

Цитата:

1000 проходов (распаковка srep и rar) ничего не дали

это старый srep???

итак, мои результаты: дважды оставлял на пару часов srep 2.95. оба раза на первом часу было 1-3 сбоя, на втором портился дисковый кеш после чего естественно начинало сбоить на каждой распаковке

на ночь оставил srep 2.91, и он отработал без ошибок, за ночь разжав порядка 7->22 терабайта!!

в общем, пока похоже на проблему в моём memory manager, при этом он исправен но стиль его работы возбуждает какое-то брожение в глупой винде