» FreeArc (часть 4)

romano007
Нужно прописать "Каталог для временных файлов" в Настройках на другой (не системный) диск. По-умолчанию там пусто, и нужно указать папку на диске, где есть достаточно свободного места.

Paramon111
я тебе советую ещё и power pack поставить - без него -max аналогичен -mx. кстати, он будет нужен и при распаковке

Bulat_Ziganshin

Цитата:

теперь srep выглядит как тестилка компьютера

наводил порядок на HDD: копирование на другой HDD, подсчёт\проверка контр.сумм. и получил "пару раз" сбои:
при копировании (отличие в файле в одной байтике)
подсчиталась неправильно контр.сумма у файла

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

PS: так что даже не знаю проблема у меня в железе, или всё таки система настолько засрана, что полный П.

Цитата:

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

мой комментарий не корректен, я сходу не понял что тестируется, думал srep с дожатием.

Добавлено:
Bulat_Ziganshin
Возможно мои сбои с srep-ом из той же оперы

Цитата:

да, несовместимый. возможно, 0.80. я собираюсь интегрировать exe или даже dispack+bcj2 в rep

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

Будете ли вы интегрировать в основной алгоритм PackJPG и TTA 2.0? И будет ли возможность создавать многотомные архивы?

также хочется узнать как дела с 0.70 финал, что еще планируется сделать, в чем задержка?

Как заставить ФА упорядочивать все файлы сразу, а не по 20000???

Bulat_Ziganshin

Цитата:

я тебе советую ещё и power pack поставить

где его скачать и как правильно установить?

vasulpr
-s;

Bulat_Ziganshin

Цитата:

нужен точный набор файлов, на котором обнаруживается сбой, и твой каталог "program files\freearc" - чтоб уж точно воспроизвести условия сжатия

Файлы ещё нужны? Они у меня висят на раздаче.
Скачались? Убираю раздачу?

Вроде как, при упаковке с -mc-exe, ошибка больше не появляется, так что если нет особого желания с ней возится, то и ладно - до лучших времён...

Цитата:

наводил порядок на HDD: копирование на другой HDD, подсчёт\проверка контр.сумм. и получил "пару раз" сбои:
при копировании (отличие в файле в одной байтике)
подсчиталась неправильно контр.сумма у файла

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

Цитата:

3. Выделяем все архивы и выбираем Extract Here.
4. Появляется окошко о подтверждении перезаписи существующего файла, жму Yes to  All
5. Окошко продолжает появляться на всех файлах.

при этом выполняется команда "arc x 1.zip ; x 2.zip ...", а fa "yes to all" трактует All только до конца текущей подкоманды. согласен, что здесь это неправильно. вопрос в том, как это лучше поправить

Bulat_Ziganshin
не помог параметр! все как было так и осталось!
до -mx -se -mcr-
после -mx -s -mcr-
Сначала анализирует 20К файлов, упорядочивает их и архивирует, затем анализирует 13К файлов, упорядочивает их и архивирует.
В чем проблема? Как сделать так чтобы все фийлы сразу анализировались, упорядочивались и архивировались? Нужно чтобы -se обрабатывала 33К файлов!

Bulat_Ziganshin
поторопился я. версия 0.666 упаковывакт с параметром -max, а версия 0.67 не хочет по прежнему. ну на нет и суда нет, буду паковать -mx.

vasulpr

Цитата:

-s;

Paramon111

Цитата:

где его скачать и как правильно установить?

http://freearc.org/ru/Download.aspx
Последний в табличке.
-max пакует, используя этот ПауэрПак.

Добавлено:
Bulat_Ziganshin

Цитата:

и для бинарных та же фигня. у тебя есть идеи как сделать лучше?

Вариантов много. Смотря какие цели ставить.
Например:
Метод Основной Текст

Новый [more=анекдот]Hamster Free ZIP Archiver is the first archiver in the world to take full advantage of multi-core processors when creating zip-archives.[/more]

Bulat_Ziganshin
На svn путь "/tr***/Un***/7z-***/" требует авторизации. А если не из клиента, а из веба, то нормально заходит.

juvaforza
на самом деле:

power archiver - первый в мире
hamster - первый бесплатный
freearc - третий

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


Добавлено:

Цитата:

На svn путь "/tr***/Un***/7z-***/"

исправлю. это проект суб-dll к 7z.dll для поддержки .arc в 7-zip и других основанных на 7z.dll продуктах

Shuld
я понял в чем дело. если упаковка архива останавливается, заходим в диспетчер задач и завершаем процесс precomp04.exe после этого архив сдвигается с мертвой точки и упаковка возобновляется. вот видеоскрин: http://upwap.ru/1984357

Цитата:

Скачались? Убираю раздачу?

убирай


Цитата:

также хочется узнать как дела с 0.70 финал, что еще планируется сделать, в чем задержка?

xlzma requires 2.5 gb on 2gb box: let limit_memory num method = return method -- ограничение памяти для метода используется только при сжатии
не установлена галка "ассоциировать с другими архивами", он все равно ассоциирует (при установке с нуля отключены оба ассоциирования!)
zipx compression
rep+tor => Decompression error -9! (fix in multi_de_compress?) - может проявиться в unarc.exe/sfxes!
"a a.zip" и "a a -tzip" должны работать как "a a.zip -tzip"
при прерывании сжатия в zip остаётся временный архив
при открытии zip с 250 тысячами файлов тормозит 10 минут
lzma.exe - проверить что решены проблемы с неполным чтением/записью буфера
external compressors stdin+stdout: http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=500#7
fread/fwrite => FullRead/Write (в lzma и Example-C)
CreateProcess with STARTUPINFO with hStdInput, hStdOutput and hStdError handles set to file handles you opened (either real files or memory mapped files should work).
stdinout.cpp
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682499(v=VS.85).aspx
4x4:lzma-x64: может, проблема в compress_all_at_once?
английский unarc-dll\readme.txt
improved tooltips 1125, 1227, 1176
* "Open .tar.gz and similar archives in one step" is broken (tested on .tar.bz2 and .tar.gz).
* "Up" button in filelist could have some icon (something like: )
выбираем несколько архивов - Extract Here - Overwrite? - Yes to All



Цитата:

Будете ли вы интегрировать в основной алгоритм PackJPG и TTA 2.0? И будет ли возможность создавать многотомные архивы?

tta уже есть. PackJPG пока особо не стремлюсь, может кто другой сделает. многотомные - в 0.80 запланированы


Цитата:

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

дело в том, что srep имеет недостатки в сравнении с rep, поэтому я хочу оставить текущее положение дел, когда он цепляется только как внешний алгоритм для nt[> кому очень нужно, а внутри fa заменить rep на его продвинутый вариант, имеющий некоторые преимущества srep, но ни одного из его недостатков

почему при удалении файла из архива происходит перепаковка всего архива?

Skaara
потому что это solid архив

Bulat_Ziganshin
спасибо за ответ!
судя по запланированному 0.70 мы до конца зимы не увидим.

не нашел в опциях галочки непрерывный архив. он автоматом уже пакует так?

http://freearc.org/download/testing/fazip02.zip

FAZip 0.2:


исправлена ошибка: программа возвращала код ошибки -9 при распаковке цепочек методов, например rep+tor
значительно ускорен REP благодаря идее Жени Шелвина
REP получил новый параметр :c, означающий размер хешируемых блоков. Для
:l512 по умолчанию :c128, для :l511..257 по умолчанию :c256 и т.д.
по умолчанию размер хеш-таблицы для REP равен min(:b/:c*4,:b/4)


Бенчмарки:

1. Сжатие с 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%

2. Сжатие с 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%

Для сравнения чистый 4x4:tor: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 раза





fixed bug: error -9 was reported when decompressing files with methods like rep+tor
improved speed of REP using Eugene Shelwien's idea
REP has new parameter :c denoting hashed chunk size. For :l512 default is :c128, for :l511..257 default is :c256 and so on
Default hash size for REP is min(:b/:c*4,:b/4)


Some benchmarks:

1. Compression with rep:1g:513
old 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%
new 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%

2. Compression with rep:1g:513+4x4:tor:3
old 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%
new 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%

For comparison, pure 4x4:tor: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%

It means that now REP may be added to the FreeArc -m1 compression method without losing even bit of speed, while compression becomes (in this case) 1.38x tighter

Skaara
в закладке Сжатие есть настройка размера solid-блока, выбери там 1 файл


Цитата:

до -mx -se -mcr-

кстати тебе наверно лучше "-se;"

Цитата:

это проект суб-dll к 7z.dll для поддержки .arc в 7-zip и других основанных на 7z.dll продуктах

Bulat_Ziganshin, не совсем понял Вас...
7-Zip теперь будет поддерживать .arc архивы?
Только распаковку или упаковку тоже?
Эта "суб-dll" будет распространятся в составе 7-Zip или ее нужно будет отслеживать и скачивать у Вас?

Bulat_Ziganshin

Обращаю внимание на 2 вещи, связанные с новым rep-ом и сжатием Rep+tor:3

На маленьких объемах данных типична такая ситуация:
Метод Размер Время, с

Bulat_Ziganshin
Извините пожалуйста чайника, но не могли бы Вы привести пример созжания *.zip при помощи КОНСОЛьной версии freearc.

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

когда будет готово - можно будет кинуть dll в инсталяцию 7-zip и получить поддержку .arc. если немного попинать разрабов winrar, power archiver, winzip и пр. - то поддержка появится и в них

насчёт включения в 7-zip - Игорь когда-то говорил, что для этого нужно иметь порядка полумиллиона пользователей, сейчас их на порядок меньше



Цитата:

пример созжания *.zip при помощи КОНСОЛьной версии freearc.

arc a a.zip -tzip

тип создаваемого/обновляемого архзива определяется опцией -t и только ей - есть пока такая недоработка

Добавлено:

Цитата:

это проект суб-dll к 7z.dll для поддержки .arc в 7-zip и других основанных на 7z.dll продуктах

кстати, если есть желающие помочь freearc - можете заняться этим проектом. он требует знания только C++

Bulat_Ziganshin

Цитата:

FAZip 0.2:

в rep были изменения относительно rep новый2 от 14.01.12?

Цитата:

Чего я не понимаю?

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

Добавлено:
egor23
я только исправил одну ошибку. как ни странно, это даже чуть ухудшило характеристики программы

Добавлено:

Цитата:

На разных компьютерах, при разном соотношении скорости процессора и устройств ввода/вывода (винт) различие межу методами rep:1g+xtor:3:4m:h128k и rep:1g+xtor:6:4m:h1m:l2 во времени сжатия может быть больше или, наоборот, отсутствовать! Но смысл останется - на больших объемах нет смысла применять  rep:1g+xtor:3:4m:h128k!

C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:6:4m:h1m:l2 D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,161,045,257: 25.62% Cpu 39 mb/s (109.981 sec), real 292 mb/s (14.821 sec) = 742%

C:\Testing\rep\017>fazip rep:1g:c256:256+4x4:tor:3:4m:h128k D:\Testing\dll4g.dll nul
100%: 4,531,060,447 -> 1,278,123,155: 28.21% Cpu 90 mb/s (48.204 sec), real 608 mb/s (7.103 sec) = 679%