» FreeArc (часть 4)

что значит щадящий режим ?
каким образом меньше операций i/o ?
он вроде побыстрее работает но вот насчет нагрузки на диск как то не заметил


странно, но среп стал неверно показывать память для упаковки
файл размером в 200мб
пишу srep -l256
(SuperREP 2.98 alpha)
он пишет

Цитата:

D:\free_arc067\bin>srep -l256 "d:\games\portal 2\portal2\portal2.zip"
56 mb, -m3 -l256 -c128 -a4

однако в диспетчере задач пишет 270мб под конец

если писать l128 то память пишется и тратиться корректно
если не писать то также непонятно куда утекает

с файлом около 1.5 гб получается так
с l128 память корректно тратиться
с любыми другими к середине уже больше 600мб память
даже с 1024 !!

для страховки везде прописал a1 все равно
(метод m3f везде, без f тоже проверял)

я разобрался
среп тот был скомпилирован мной вручную с помощью ms vs 2005
srep с ссылки автора работает корректно
кстати а чем srep32 отличается от srep ?
я peid проверил, там gcc компилятор, а в srep скорее всего ms vs 20xx
а разница между ними существенная ?i версия понятно побыстрее на intel-платформах

я все таки все их првоерил
такое же поведение у srep32/srep32i
у srep который в gcc построен все ок

кстати и теперь черtp arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep

Цитата:

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

[External compressor:srep_f]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

это у меня одного такие люки?

Bulat_Ziganshin
что там с новым оформлением вкладки сжатия? когда можно будет опробовать?

WinZip 16.5 Will Support OpenCL for Ultra Fast Compression and Decompression

у меня не распаковываются файлы запакованные srep 2.98 alpha
если файл больше 2 гб то не распаковывается
если меньше то без проблем

во время упаковки никаких ошибок не пишет
а при распаковке

Цитата:

Ratio: 2,172,649,472 -> 2,137,387,555: 98.38%. Cpu 359.301 mb/sec, real 13.863 m
Ratio: 2,181,038,080 -> 2,145,776,191: 98.38%. Cpu 358.834 mb/sec, real 13.899 m
Ratio: 2,189,426,688 -> 2,154,164,827: 98.39%. Cpu 358.372 mb/sec, real 13.924 m
Ratio: 2,197,815,296 -> 2,162,553,463: 98.40%. Cpu 357.914 mb/sec, real 13.960 m
Ratio: 2,206,203,904 -> 2,170,942,099: 98.40%. Cpu 357.461 mb/sec, real 13.996 m
Ratio: 2,214,592,512 -> 2,179,330,735: 98.41%. Cpu 357.012 mb/sec, real 14.014 m
b/sec. Matches 5 4447 14188, I/Os 0, RAM 0/14, VM 0/0, R/W 0/0
ERROR! Decompression problem: broken compressed data

параметры упаковки -l128 -f -a1, файл размером 2.29 ГБ

winxp sp2, 2gb ram, core 2 duo 4300
на работе также только проц и СП другие
core-i5 650
win xp sp3


***
перепроверил, ошибка при распаковке бывает только при файле больше 2 гб если использовался -f, без -f все отлично распаковывается

все же. это нормально что при высоких lz min math память тратится даже больше чем при l32
я упаковываю файл 900 мб, у меня при параметрах -a4 под конец пишет уже более гб выделено, когда как требование к памяти в 10 раз меньше (95мб)
версия 2.0 так не ведет себя
вообще как то странно диспетчер показывает данные, я когад сворачиваю окно срепа то пишет что память 100 мб, тогда как на графике потребления памяти никаких изменений и в графе доступно нечего не меняется, а если сворачивать/разворачивать окно то память скачет то вниз то вверх

Цитата:

говоря кратко, есть предложение включить cls-precomp.dll и cls-srep.dll в комплект программы, и сделать в ней поддержку гибридных кодеков ..., что позволит ускорить распаковку ... что скажете?

скажу просто: Вам решать. Вы можете сделать это опционально (платно) или не сделать вообще. Что касается меня, то я бы не заморачивался на это ибо сейчас размер жесткого диска (или ssd диска) позволяет делать что и как угодно. Проще говоря человек, говорящий не по нашему делает акцент не на то.

Bulat_Ziganshin

В последней альфе, если ввести пароль неправильно, то фа не просит повторить ввод, а пишет что это битый архив. Еще при распаковке часто появляется ошибка, которая на том же архиве в 0666 не появляется. Что-то про параметры в лямбде, но точно не помню. Как о5 выскочит сделаю скрин.

Posetitel33
надо задавать вопрос разработчику скрипта. или ты используешь скрипт из поставки freearc???

Добавлено:

Цитата:

какое преимущество дает использование  future-lz
я  понял что требование к памяти при распаковке ниже
но ведь память и так при распаковке очень малая (16мб)

почитай, вроде полтемы у нас srep'у посвещено. но если коротко - то обычный алгоритм берёт данные не из этих 16 мег, а считывает из предыдущей части файла. т.е. если LZ-код говорит ему "следующие 10 мб данных точно совпадают с тем что было 100 мб назад", то он просто читает их из уже распакованной части файла. учитывая, что кодируются все повторы от 512 байт - это огромная нагрузка на дисковый кеш, а если в него всё не влезет - то и сам диск

future-lz устроен наоборот - уже после распаковки первый раз этих 10 мб он говорит "они нам ещё понадобятся через 100 мб, давай сохраним их копию в памяти", и таким образом всё что будет повторено хранится в памяти и нагрузки на винт нет. если же даже озу для этих данных не хватит, то они собираются в куски по 8 мб, которые записываются/читаются целиком. по сравнению с первым вариантом, где куски могут быть по 512 байт, нагрузка на диск на 4 порядка меньше так что он не становится узким звеном

Добавлено:

Цитата:

однако в диспетчере задач пишет 270мб под конец

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


Цитата:

у меня не распаковываются файлы запакованные srep 2.98 alpha
если файл больше 2 гб то не распаковывается

да, 32-битные версии srep имеют такую ошибку. спасибо!

раскладку я уже приводил:

srep - gcc
srep32/64 - msvc
srep32i/64i - icl



Добавлено:

Цитата:

однако в диспетчере задач пишет 270мб под конец

а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

Andrey_Verkhoglyadov
подобные вещи я делаю в "фоновом" режиме, просто когда наскучивает заниматься более скучными, но важными, так что речь не об этом. у меня вопрос к спецам по freearc - правильно ли я понял что там нужно сделать

Добавлено:
sabio
мне v5 и v6 не глянулись. положил их тоже на свой сервер:
http://freearc.org/download/image/progress5.png
http://freearc.org/download/image/progress6.png

Добавлено:

Цитата:

насчёт "по окончании" - надо просто не очищать поля слева, и асимметрии не будет
да и видно будет заодно, что все файлы и байты были обработаны
(или наоборот, если по какой-то причине файл обработать не получилось, будет видно, что число слева меньше правого)

там сейчас делается по-другому - если что-то не удалось обработать, то уменьшается сам Total. а столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно

Добавлено:

Цитата:

А еще проценты ratio можно с сотыми долями выводить.

мне кажется что в процессе архивации сотые интересны только конченым гикам. а лишняя информация - это сложность в восприятии нужной


Цитата:

а для консоли удобнее будет строки поменять местами

разумеется


Цитата:

только вот с Compressed и Time неувязка

да, не так там всё просто, но как начальная точка отсчёта подойдёт. что мне нравится - идея разместить totals сверху и несколько чисел под ним. в принципе, все 8 меняющихся полей можно вместить в одну строчку (очень длинную )


Цитата:

единственное что хочется видеть при процессе упаковки - это сколько осталось времени до завершения процесса и на сколько уменьшился объем первоначальной информации.

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

Перейду наверное обратно на 7zip.
Пробовал нескоько часов сжимать и пришел к выводу:
7zip сжимает значительно быстрее при одинаковой степени сжатия, если мощный комп.
У меня 7-64, 2600k, разогнан до 4500, 16 гб. оперативки.
7zip может загружать все ядра(4+4виртуальных) полностью, и за счет этого вырывается далеко вперед.
FreeArc очень слабо загружает физические ядра(виртуальные практчески не загружает), и за счет этого отстает.( В настройках выбирал и 4, и 8 ядер, и т.д, но так и не увидел результата)
Если архивировать несколько одновременно в FreeArc, тогда можно выиграть в 7zip в конечном итоге.
Со временем процесоры стают все мощнее, поэтому хотель бы пожелать FreeArc уметь работать не только со всеми ядрами, но и уметь их загружать при надобности полностью.
Итог:
Если комп слабый то FreeArc выиграет у 7zip, если комп мощный, то шансов у FreeArc нету.

orest1973
Вы бы операционку,винты и параметры freearc указали, а не голословно "круче и всё тут".

Bulat_Ziganshin
Цитата:

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

какая память ?
я смотрю столбик память, есть еще вирт. память, но указанная вам "выделенная память" отсутствует в списке возможных столбцов. (есть еще выгруж и не выгруж. пул, но там малое кол-во памяти пишет)


Цитата:

а, сообразил - это скорей всего из-за mmap. попробуй -nommap; вероятно в gcc-версии mmap просто не срабатывает

большое кол-во памяти потребляют (у меня уж точно, правда зависит от файла) все варианты srep/32/32i, флаг nommap всех их ограничивает в той, которая указана в mem req

я про lzf спросил потому что не сталкивался с теми случаями когда память тратится много, однако только что я запаковал архив (dbf-файлы) с lzf и при распаковке увидел что память он нехило тратит, теперь понятно к чему было написано

Цитата:

- Таким образом, мы можем распаковать 22 ГБ файл с 2 ГБ ОЗУ, или даже с 200 МБ ОЗУ и 2 ГБ VM файле, и скорость остается очень высокой, около 100 МБ/с! Я считаю, что это выдающийся результат.

получается зависит от кол-ва lz math

Bulat_Ziganshin

Цитата:

столюцы справа очищаются именно когда total==current, это между прочим удобней - не надо самому думать, сравнивать их, всё сразу интуитивно ясно

может, тогда, чтобы всё же не появлялось асимметрии по окончании, вместо очистки, например, выключать bold?
хотя, как по мне, и очистка, и выключение жирного в момент окончания архивирования выглядят несколько странно и нелогично, неожиданно - число росло, росло и вдруг пропало
я бы оставлял всё на месте, как есть
а если надо что-то специально выделить (например, в случае ошибки) менял бы цвет на красный что ли?..


Цитата:

мне v5 и v6 не глянулись

я и сам на них посмотрел ещё раз - не то

но всё же, мне кажется, Ratio и Speed не должны быть "вперемешку" со значениями "xxx of yyy"
хотя бы как-нибудь так, может? (v7)

orest1973
а 4x4 для чего был придуман Булатом? Если его юзать в итоге у фриарка получается практически тот же lzma2, только с навороченными прекомпрессорами.

Цитата:

кстати и теперь через arc\freearc не пашет, только вариант без -f пашет потому что я разделил srep

а вот этого я не понял


Добавлено:

Цитата:

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

ах да, у меня win7, поэтому названия другие. но всё равно столбец какой-то другой, может вирт. память. то что он до 100 мб сбрасывается при минимизации - это уже о многом говорит, наверно это физ. память выделенная в данный момент проге


Цитата:

получается зависит от кол-ва lz math

зависит от общего объёма "отложенных на будущее" данных. я на английском форуме помнится даже график приводил для этого 22 гб файла

Подскажите пожалуйста:у меня есть игровые архивы daed space 2.Я пробую их жать -mx9 -ld512m, но получается большой размер.С каким параметром следует их сжимать

Bulat_Ziganshin

Цитата:

для нормального юзера - да, для гика нужно больше

ну так архиватор то вы пишите для нормального юзера, я надеюсь. А для гика, пожалуйста, командная строка ...

новая альфа:страница Сжатие: новые настройки; скорости перемеряны на i7-2600
Descript.ion: добавлены описания для всех файлов в каталоге bin\
Исправлена ошибка в индикаторе прогресса (иногда он перескакивал назад)
Улучшены тултипы 1125, 1227, 1176: если вы поддерживаете одну из трансляций, пожалуйста переведите их заново из arc.english.txt

new alpha version:Compression page: added more settings; speeds measured on i7-2600
Descript.ion: added description for all files in the bin\ directory
Fixed bug in displaying progress indicator (it was jumped lower sometimes)
Improved tooltips 1125, 1227, 1176: if you manage any translation, please update it to match arc.english.txt text

да точно вирт память это

Цитата:

а вот этого я не понял

Цитата:

[External compressor:srep]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} $$arcdatafile$$.tmp - <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

[External compressor:srep_f]
;options = l%d (minimal match length, default=512)
packcmd = srep {options} -f - - <stdin> <stdout>
unpackcmd = srep -d - - <stdin> <stdout>

кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

sabio
в случае ошибок сообщения о них выводятся под прогрессбаром

Andrey_Verkhoglyadov
а зачем нормальному пользователю использовать freearc, а не rar/zip? вот вам например?

in order to implement "experimental methods" in the Compression dialog, i plan to implement the following new options:

-mc[GROUPS][:]OPERATION

where GROUPS may be empty or list of compression groups, $default means the default group. Examples are:$obj
$default
$default,$obj
Optional ':' is just a syntax sugar

And OPERATION may be one of the following:'-$group' or '$group-' means "remove $group from compression definition". Already implemented, f.e. -mc-$bmp
'-method' or 'method-' means "remove method from compression definition". Already implemented, f.e. -mc-rep
'+method' or 'method+' means "add method at the head of every compression chain", f.e. -mc+precomp042:t-j
'method1->method2' means "replace method1 with method2", f.e. -mc:rep->srep:mem256mb
GROUPS may be used to limit OPERATION to the specified groups, f.e. -mc$default,$obj:+precomp042:t-j

---

Using these options, FreeArc will implement "exprerimental compressor" checkboxes in the following way:

lzma:1gb: -mc:lzma->lzma:max:512mb
exe2: -mc:exe->dispack070
srep: -mc:rep->srep:mem256mb
precomp: -mc$default,$obj:+precomp042:t-j
intense: -mc$default,$obj:+precomp042:intense:t-j
jpeg: -mc$default,$obj:+precomp042

(of course, intense+jpeg will give us precomp042:intense)

---

Looking for your critique for the option itself and "exprerimental compressors" deciphering

Bulat_Ziganshin

Возможно некоторые строки поменять местами,
А также добавить под кнопкой "+" раздел типа "Estimated end of Operation" где вычислялось бы примерное время окончания, путем суммирования текущего системного времени и остатка времени операции.

kalpak

Цитата:

кстати кажется в распаковку лучше добавить {options} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке

последние рекомендации тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=620#2

Добавлено:

Цитата:

я на английском форуме помнится даже график приводил для этого 22 гб файла

картинки тут http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=240#11

Bulat_Ziganshin

Цитата:

а зачем нормальному пользователю использовать freearc, а не rar/zip? вот вам например?

мне он нравится тем, что лучше пакует мои данные чем тот же rar или 7-zip для моего домашнего архива - кратковременного. (для длительного хранения я использую zip и только его). Но, извините, для каждодневного использования я выбираю winrar для того, чтобы архивировать данные в rar или zip и отправить их по почте.

Цитата:

оказывается что по умолчанию в normal preset match finder - ht4 ?

да. попробуй поищи в топике по "ht4", это апрель 2009-го afair


Цитата:

для tor в исходниках вроде написано что  он принимает параметры многие, например  p(parser ),

из help'a:

-p# -- parser (1-greedy,2-lazy), default 2

другие парсеры планировались, но так и не были реализованы. вообще tor интересен только для быстрого сжатия, иначе lzma круче



Цитата:

а нельзя сделать чтобы архиватор при распаковке архива с методом 4x4 (например lzma:128mb:fast:96:mc20) учитывал параметр t (кол-во потоков), для данного файла ставил t2
а то получается смешная ситуация, запаковать смог, а распаковать нет ))
(использовался архиватор 0.666 build)
можно даже не указывать кол-во потоков, он все равно сможет запаковать, получается опция lc75p по-умолчанию работает, а опция ld75p - нет
 
кстати unarc успешно его распаковывает
(067 alpha 2011-03-18, 0.666 зависала [ошибки не было, просто нечего не делала])

запутался я в твоих показаниях...

Bulat_Ziganshin
Как включить показ вкладки "Сжатие", ато отображаются только 4 вкладки: основное, архив, файлы, комментарий?

Цитата:

говоря кратко, есть предложение включить cls-precomp.dll и cls-srep.dll в комплект программы, и сделать в ней поддержку гибридных кодеков (например в данном случае CLS должен обеспечивать только распаковку, а упаковка - внешними прогами), что позволит ускорить распаковку стандартного набора precomp+srep+lzma и не создавать при этом монстроидальные временные файлы. короче, как это уже делается в инсталяторах. что скажете?

Вообще идея хороша, но зачем srep? Ведь есть метод распаковки stdin stdout, который по сути не отличается от того же фильтра. Ну и насколько я помню была обещана поддержка srep как внутреннего алгоритма, вместо rep. Вот прекомп конечно бы неплохо было добавить. Так же как и сжатие PCM аудио алгоритмами frog и tak, как это сделано в msc у профрагера (распаковка так же идет с cls фильтром).

vasulpr

Цитата:

страница Сжатие: новые настройки

Цитата:

ато отображаются только 4 вкладки: основное, архив, файлы, комментарий?

На вкладке "Основное" наведи курсор мыши на слово "Сжатие" и немного подожди

Цитата:

запутался я в твоих показаниях...

был файл 8гб, я его запаковал с 4x4:t2:lzma:128mb:128:mc10 (если т2 не указать, то памяти не хватит и ошибка выйдет)
но сохраняет он информацию что сделан архив 4x4:lzma:128mb:128:mc10
и пишет что для распаковки надо больше 2гб памяти ( у меня лог. 4 потока)
т.е. получается что указать сколько потоков нужно для упаковки можно, а какое кол-во было указано не сохраняется в методе сжатия и он просто пытается задействовать все потоки
unarc успешно его распаковывает (067 версия), а FA жалуется что памяти не хватает
кстати а кол-во блоков в методе 4х4 чем то ограничено? у меня разница между xlzma и lzma около 50 мб (тот же файл 8гб), как я не пытался сделать блок большим

Цитата:

На вкладке "Основное" наведи курсор мыши на слово "Сжатие" и немного подожди

Спасибо! нашел! Кстати классно придумали скрыть розшеренни настройки под кнопку.

После активации опции "общая очередь для всех копий ФА" была запушено распаковка архива и запущена упаковки в архив которая стала в очередь после распаковки. так вот распаковка прошла нормально, а окно упаковки зависло.

Цитата:

..............Files ....... Bytes . => ... Compressed ...... Time
Processed ....... 8 .. 16,188,368 ......... 6,229,876 ... 0:00:02
Total .......... 35 . 134,844,601 ...... ~ 51,893,133 . ~ 0:00:17
 
Ratio .......... 38 %
Speed ....... 7,970 kB/s

v8 - http://freearc.org/download/testing/progress/FreeArc8.exe:

kalpak
это всё без lc/ld? пиши чётко - команда (проще даже лог с экрана), конфиг компа, и что по твоему не так работает

пока я могу ответить только на один вопрос - t2 в архиве не запоминается именно потому, что архив может распаковываться на другой машине где озу будет меньше или больше. да и ни о чём это t2 не говорит, кроме скорости с какой у тебя прошла упаковка (в отличие от других опций, по которым можно понять степень сжатия)

Добавлено:
кстати, пришёл в голову трюк, который возможно способен на порядок ускорить распаковку обычного srep (без -f) когда идёт трешинг диска - считывать матчи параллельно в нескольких десятках потоков. тогда есть надёжда что сработает ncq и мы будем иметь qd=32 or so