Ru-Board.club
← Вернуться в раздел «Программы»

» FreeArc (часть 4)

Автор: Bulat_Ziganshin
Дата сообщения: 02.01.2011 22:39

Цитата:
compressionLast=-mex7 -ms

дефолтный метрод сжатия. поменяй на другой


Цитата:
compression=-mex7 -ms

строчка в выпадающем списке методов сжатия. сотри


Цитата:
arcname=D:\work 2010 -mex7 -ms.arc

строчка в выпадающем списке имён архива

отсальное вообще не при чём
Автор: Bulat_Ziganshin
Дата сообщения: 09.04.2012 00:15
overGluker
arc v archive.arc
атрибуты в архиве не сохраняются (кроме D)
Автор: Shuld
Дата сообщения: 03.01.2011 08:23

Цитата:
2 там потока, 2!


А сколько может быть потоков у "ультра":
2, 4, больше может?

Добавлено:
pdf тоже относится к $compressed?


Цитата:
сделай так: -mex7 -m$compressed=xtor:c3


Какими параметрами у xtor можно поварьировать? Или нет никаких?
Автор: kalpak
Дата сообщения: 05.08.2011 07:19
Posetitel33
пропиши в скрипте не распаковывать по маске а передавать список файлов (можно через запятую)
и все будет тип топ
он же у тебя по маске ищет все файлы бин и распаковывает
а ты вместо маски сделай чтобы скрипт использовал список файлов

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

Цитата:
А сколько может быть потоков у "ультра":
2, 4, больше может?

у 7z normal/max/ultra - 2 потока. если заказать >=4 потоков, то файл будет разбит на куски по 4*dictsize и каждый из них сжат независимо, что ухудшит сжатие


Цитата:
pdf тоже относится к $compressed?

нет. читай arc.groups


Цитата:
Какими параметрами у xtor можно поварьировать

теми же что и у tor
Автор: overGluker
Дата сообщения: 09.04.2012 12:51
Bulat_Ziganshin
Спасибо, как раз то, что нужно!
я как-то умудрился проглядеть этот ключ...
Автор: Profrager
Дата сообщения: 03.01.2011 22:01
Bulat_Ziganshin
Возникла такая ситуация: необходимо упаковать в zip архив кучу файлов в определённом порядке. Соответственно порядок задаю через -ds, но вот беда - какую последовательность не задавал бы, все равно одинаково пакуется. При этом если создавать .arc архив, то все работает как положено.
Строка создания архива:
Код: arc a --type=zip -dses -mx0 -r -i2 -di -ep1 arc.zip data\*.*
Автор: ndch
Дата сообщения: 10.04.2012 20:28
bugreport:
FreeArc 0.67 (February 5 2012) http://freearc.org February 5 2012
os: windows 7 sp1 rus
при прерывании по crtl+c несовсем корректный вывод:
[more]
Код: arc l msg.arc
--- выкушено ----
2012-03-09 14:42:07 403 1\0899.msg
2012-03-09 14:42:07 1,143 1\0900.msg
2012-03-09 14:42:07 726 1\0901.msg
2012-03-09 14:42:07 2,060 1\0902.msg
2012-03-09 14:42:08 2,491 1\0904.msg
2012-03-09 14:42:08 2,171 1\0905.msg
2012-03-09 14:42:08 518 1\0906.msg
2012-03-09 14:42:08 2,538 1\0907.msg
2012-03-09 14:42:08 22,087 1\0908.msg

2012-03-09 14:42:09 313,602 1\0909.msg
Program terminated by user!2012-03-09 14:42:09 3,025 1\0910.msg


2012-03-09 14:42:09 1,555 1\0911.msg
Автор: Profrager
Дата сообщения: 06.08.2011 21:03
kalpak

Цитата:
какое преимущество дает использование future-lz

скорость и щадащий режим для винта. А для памяти как раз наоборот
Автор: snkreg
Дата сообщения: 10.04.2012 21:33
Уважаемый Булат, подскажите, планируется ли подобие цифровой подписи? А так же, когда ориентировочно планируется работа над юзабилити, поддержка скинов и тд?
С уважением.
Автор: kalpak
Дата сообщения: 06.08.2011 21:45
что значит щадящий режим ?
каким образом меньше операций 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>


это у меня одного такие люки?
Автор: ndch
Дата сообщения: 13.04.2012 09:22
snkreg
В шапке:
Планы дальнейшего развития
Скины для программы, а тем более архиватора ?
"Кого ты лечишь, Рипбургер!"

Само по себе возможность наличия скинов, на данный момент, зависит от gtk.
Таким образом куря мануал от gtk можно изменить скины.
Всё в ваших руках !
"Скины" уже есть.

Может быть кто-нибудь напишет понятное руководство на эту тему, с примерами, на русском ?

Пока что посоветую почитать
http://baihu.tom.ru/2010/03/pidgin.html
http://sourceforge.net/userapps/mediawiki/alex-sh/index.php?title=Downloads#GTK.2B_Preference_Tool

К сожалению :) мне этот совет не подходит - я использую freearc с командно-строчным интерфейсом (cli).
Автор: kalpak
Дата сообщения: 09.08.2011 07:39
у меня не распаковываются файлы запакованные 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 мб, тогда как на графике потребления памяти никаких изменений и в графе доступно нечего не меняется, а если сворачивать/разворачивать окно то память скачет то вниз то вверх
Автор: ormadillo
Дата сообщения: 17.04.2012 10:36
Всем привет!
Как с помощью консольной версии добавить все файлы в папке к примеру DATA - каждый файл в отдельный архив?
Ну сжатие просто lzma
Спасибо!
Автор: Bulat_Ziganshin
Дата сообщения: 10.08.2011 10:16
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 просто не срабатывает
Автор: ormadillo
Дата сообщения: 19.04.2012 19:19
Никто не знает??
Автор: ruduk
Дата сообщения: 19.04.2012 22:24
ormadillo
Скорее всего нужен батник для сжатия всех файлов в каталоге рекурсивно. Ранее на форуме выкладывали готовый (и работающий, насколько я помню).
Автор: kalpak
Дата сообщения: 10.08.2011 11:52
Bulat_Ziganshin
Цитата:

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

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


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

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

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

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

получается зависит от кол-ва lz math
Автор: ormadillo
Дата сообщения: 19.04.2012 22:48
ruduk что-то не нашел(
Автор: ruduk
Дата сообщения: 20.04.2012 11:14
ormadillo
Это было в "Части 3" форума здесь.
Спасибо пользователю под ником sabio.
Батник еще нужно подкорректировать, чтобы не распаковывать архивы, а поставить необходимые расширения файлов и сразу переходить на стадию сжатия.
Автор: Shuld
Дата сообщения: 04.01.2011 17:44

Цитата:
ну это проблемы в многопоточном zip-упаковщике. можно заменить 7z.dll на нормальную от 7-zip - тогда долджно всё работать

Заменил, ошибки паковки в zip исчезли.
Но процесс-бар все равно несколько раз "прыгает" чуть назад.
При архивировании в zip на 7z, процесс-бар точно так же прыгает.

Как попробовать метод CCM на FreeArc 0.67а?
Через установку FreeArc-PowerPack-0.666?
Автор: Bulat_Ziganshin
Дата сообщения: 10.08.2011 11:59

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


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


Добавлено:

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

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


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

зависит от общего объёма "отложенных на будущее" данных. я на английском форуме помнится даже график приводил для этого 22 гб файла
Автор: ormadillo
Дата сообщения: 21.04.2012 04:26
ruduk

Цитата:
ormadillo
Это было в "Части 3" форума здесь.
Спасибо пользователю под ником sabio.
Батник еще нужно подкорректировать, чтобы не распаковывать архивы, а поставить необходимые расширения файлов и сразу переходить на стадию сжатия.

Взял первый скрипт, но не выходит его приручить...
У меня файлы все в одной папке, подпапок нет!
Автор: Bulat_Ziganshin
Дата сообщения: 04.01.2011 18:26

Цитата:
Как попробовать метод CCM на FreeArc 0.67а?
Через установку FreeArc-PowerPack-0.666?

да
Автор: kalpak
Дата сообщения: 10.08.2011 12:23
да точно вирт память это

Цитата:
а вот этого я не понял


Цитата:

[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} чтобы ограничить память или еще какие нибудь параметрыы исп-лись при распаковке
Автор: LonerDergunov
Дата сообщения: 04.01.2011 20:12
---
Автор: BaaaSr
Дата сообщения: 22.04.2012 17:46
Всем привет!
Киньте ссылку с инструкцией для использования прекомпа.
Автор: PAQer
Дата сообщения: 05.01.2011 23:37
New TTA multiplatform library, ANSI-C version 2.0 has been released, with simple console frontend included in package. Main changes: Code include ARM/SSE2/SSE4 optimizations; added capability of real-time data encryption (password protection).

Changes:

Code optimization. Decoder runs faster;
ARM/SSE2/SSE4 optimization has been added;
Added real time data encryption feature;
The set_position function accepts new position and returns new time in seconds in unsigned int32;
Added binary_version function for checking the library for SSE instructions compatibility;
Added set_password function for possibility to set the password;
Added get_rate function, returns the dynamic stats of the process;
Autoconf support;
README file updated.

Черпануть оптимизацию не помешалоб.
Автор: egor23
Дата сообщения: 10.08.2011 12:34
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
Автор: xBoo
Дата сообщения: 06.01.2011 08:39
Bulat_Ziganshin, пожалуйста, обновите страничку FreeArc — планы на будущее. Чтоб соответствовала текущему положению вещей.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275

Предыдущая тема: Punto Switcher (часть 3)


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.