» FreeArc (часть 4)

2All
Сжимаю последней альфой файлы (~4гб) с такими параметрами:

Код: -m9 -mt0 -ld1600m -t -mc-exe -mc-delta

WildGoblin
первая мысль - моэжет ты обновляешь существующий архив? вообще отсюда можно взять старые portable версии и проверить что действительно архиватор себя иначе ведёт в точно такой же ситуации

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

Bulat_Ziganshin

Цитата:

первая мысль - моэжет ты обновляешь существующий архив?

Нет - новый создаю.

Цитата:

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

Попробовал несколько старых версий ([more=заменял только эти файлы]bin\7z.dll
bin\facompress.dll
bin\facompress_mt.dll
bin\freearc.menu.example
bin\7zG.exe
bin\all2arc.exe
bin\Arc.exe
bin\FreeArc.exe
bin\precomp042.exe
bin\srep.exe
bin\unarc.exe[/more]) - [more=та же самая ошибка]E:\GamesForTest\A New Beginning - Final Cut v2.0>FreeArc a -tarc -m9 -mt0 -ld1600m -t -mc-exe -mc-delta -wG:\ --logfile=freearc.log -dpE:\GamesForTest\A New Beginning - Final Cut v2.0 -- G:\game.arc A New Beginning - Final Cut
FreeArc 0.67 (November 11 2013) Creating archive: G:\game.arc using rep:1600mb+tempfile+lzma:176mb:normal:bt4:128, $obj => rep:1600mb+tempfile+lzma:176mb:normal:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:160mb:92%:145:h23:d1mb+ppmd:16:384mb, $wav => tta, $bmp => mm+grzip:8mb:m1:l2048:h15:a
Memory for compression 1856mb, decompression 1600mb, cache 1mb
ОШИБКА: невозможно выделить память, необходимую для (рас)паковки в rep:1600mb, используйте -lc/-ld чтобы уменьшить требования к памяти[/more]!
Возможно с системой (Win8.1 x64) что-то случилось - раньше ведь нормально создавались архивы!

Потестировал ещё - наборы файлов размером около гигабайта отлично создаются (с теми же параметрами), а если попытаться сжать набор файлов < ~1700mb, то выскакивает ошибка.

WildGoblin
а что тебе мешает целиком старую portable версию распаковать и ею проверить?

когда файлов мало, fa просто обрезает словарь первого метода в цепочке.

посмотри largest memblock в gui/settings/info. в win7 x64 это 2042 mb

Bulat_Ziganshin

Цитата:

а что тебе мешает целиком старую portable версию распаковать и ею проверить?

Были свои соображения... сейчас протестирую все с полной заменой.

Цитата:

посмотри largest memblock в gui/settings/info. в win7 x64 это 2042 mb

У меня показывает 2041mb.

Добавлено:
Bulat_Ziganshin
Протестировал несколько версий - у всех вываливается ошибка на этапе окончания анализа файлов
.
Причём если архивировать из контекстного меню, то в окне показывается сообщение "ОШИБКА: невозможно выделить память, необходимую для (рас)паковки в rep:1600mb, используйте -lc/-ld чтобы уменьшить требования к памяти", а если архивировать из гуи, то выскакивает доп.окно - "user error".

P.S. Проверил сейчас последнюю версию в чистой виртуалке (максимальный блок адресов там тоже 2041mb) - те же самые файлы отлично сжимает!
Что же такое у меня с системой приключилось - как быть и что делать...

WildGoblin
жду ответа как работают старые версии. ну и новую portable на всякий случай проверь

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

Bulat_Ziganshin

Цитата:

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

лог

Скажите pls кто в курсе - а каков статус проекта ?
А то читаю http://freearc.org/ru/FuturePlans.aspx
но последняя версия все таки
Версия 0.666 (20 мая 2010 г.)
Проект вообще жив ?

NeoHunter
http://freearc.org/Download-Alpha.aspx
http://freearc.org/history/changelog_full_ru.htm

Цитата:

Проект вообще жив ?

оригинал давно уже мумифицировался.

Цитата:

http://freearc.org/Download-Alpha.aspx

это мираж, на снимке Марса.

WildGoblin
у меня никаких особых идей нет, чисто для иинтереса только попробовать сжатие одного файла >2гб, -ma- или вручную описать метод сжатия, добавив больше tempfile, в частности перед rep. но проще всего наверно использовать что-то в районе -lc1800m - подберёшь

Bulat_Ziganshin

Цитата:

но проще всего наверно использовать что-то в районе -lc1800m - подберёшь

С -lc1450m заработало.
Спасибо за помощь!

Сразу три вопроса/уточнения
- какой Фар плагин работает с FreeArc? На сайте бы ссылочку указать или здесь, в заголовке темы. В стандартный arclite почему-то не входит.
- можно ли делать архивы в формате сторонних программ (zip/7zip) с соответствующим расширением? Подозреваю, что нельзя, что печально
- многопоточность используется для всех алгоритмов сжатия?

kkuuhhaa
1. где-то в addons есть сабплагин для старого multiarc. для поддержки arclite лучше сделать freearc.dll для 7-zip
2. опять же, arclite не позволяет использовать внешние exe, а multiarc может
3. нет. только 4x4, grzip; rep отчасти

Цитата:

Bulat_Ziganshin

Спасибо.
Существует ли пример работы FreeArc в режиме память-файл?

kkuuhhaa
он в таком режиме не работает. это архиватор а не библиотека

Bulat_Ziganshin

Цитата:

http://freearc.org/Download-Alpha.aspx

не понятно что FreeArc 0.67 alpha вроде как постоянно обновляется с 2010 года и при этом номер даже альфы не меняется - это как вообще ?
sergeo78

Цитата:

оригинал давно уже мумифицировался.

ото ж
В общем если автор читает топик - какова судьба проекта - когда будет релиз ?

NeoHunter

Цитата:

...какова судьба проекта...

Сами же ответили:

Цитата:

...постоянно обновляется с 2010 года

Цитата:

...когда будет релиз ?

Некоторые каждую альфу/бету релизом обзывают и "выпускают" его - вы про это?

Цитата:

Некоторые каждую альфу/бету релизом обзывают и "выпускают" его - вы про это?

Я просто не понимаю вот этого
FreeArc 0.70



FreeArc 0.67 alpha (June 26, 2010)
...
FreeArc 0.67 alpha (September 22, 2010)
...
FreeArc 0.67 alpha (March 8, 2011)
.....
FreeArc 0.67 alpha (November 11, 2012)
Это типа вечная 0.67 alpha ?
Лично я не рискну использовать архиватор в таком статусе

NeoHunter
У нас везде гду FA есть, везде эта версия(FreeArc 0.67 alpha (November 11, 2012) )

Ну, автору продукт интересен, как поле для экспериментов, причём, судя по всему, он уже изрядно потерял к нему интерес. Последние года три сдвиги, конечно есть, но больше теоретические, для гиков. Для простых пользователей - ну нет готового продукта, и всё. У 7z получше, хотя тоже как-то альфы-беты застаиваются. Но готовый продукт уже есть, и весьма неплохо распространён и используется. Здесь же - выпустить бы готовый продукт, пусть даже на основе v. 0.70, ну, чуть интерфейс, может, доработать (хотя и так терпимо), а там и дальше можно лезть в дебри упаковки. Вот только в текущее время, как мне кажется, отдельные проценты и доли процента сжатия уже не так актуальны.

Поддерживаю уважаемого Andarin ! Просто мысли мои прочитал!

NeoHunter

Цитата:

Это типа вечная 0.67 alpha ?

Это типа болида спортивного - постоянно что-то совершенствуется - чтобы быть на острие атаки.

Цитата:

Лично  я не рискну использовать архиватор в таком статусе

Для очень важных бэкапов может и не стоит использовать... (хотя для бэкапов надёжность увеличивается просто - избыточностью...)

Цитата:

Это типа болида спортивного - постоянно что-то совершенствуется - чтобы быть на острие атаки.

Вот я примерно о том и сказал - быть на острие атаки, но не ездить. Тот же Шумахер (и все прочие из Формулы) на болидах только на Формуле и тренировках...
P.S. Кстати, уже не первый год в Формуле искуственные ограничения - на мощность, объём.

4x4:mm+lzma
будет работать многопоточно?

Edison007007
mm очень быстрый, так что нет смысла его ставить под 4x4. а в целом ты видимо неправильно интерпретируешь - это означает (4x4:mm)+lzma. т.е. 4x4 - это префикс одного-единственного метода сжатия, а не всей оставшейся цепочки

Цитата:

это означает (4x4:mm)+lzma.

Точно ведь *facepalm*. Но если использовать mm+lzma, то каждый файл будет сжат в отдельный блок, а что если сделать многопоточную упаковку/распаковку, т.е. распаковывать/упаковывать несколько блоков одновременно?
* и с tta такой трюк бы прокатил

Tornado 0.6 - добавлен оптимальный LZ-парсинг

Сжатие:новые режимы -11..-16 используют оптимальный парсер (-p4)
-fb (FAST BYTES), новый параметр используемый только оптимальным парсером
старый режим -10 удалён, старый -11 я настроил получше и переименовал в -10
опция -s1 теперь означает "64kb hash3 + 4kb hash2", что автоматически немного улучшило сжатие в режимах -5/-6
новые алгоритмы LZ-поиска: chash5..7 (-x15..17) и bt4..7 (-x24..27)
все алгоритмы поиска chash/cchash/bt теперь поддерживают значения -l, не являющиеся степенью 2
все параметры сжатия описаны в manual.txt
Командная строка и индикатор прогресса:опции -slp/-rem, по умолчанию используются большие страницы памяти (2МБ/4МБ)
индикатор прогресса в таскбаре Win7 (зелёная полоска) плюс текст в заголовке консольного окна
программа возвращает уод ошибки 2 при любых проблемах, очищает заголовок окна при ^Break
экран помощи описывает диапазон значение и значение по умолчанию для каждого параметра сжатия
проверка корректности значений параметров сжатия
под Windows, предотвращает одновременную запись нескольких процессов в один и тот же файл
печатает размеры с точностью до байта; скорости измеряются в МиБ/с
индикатор прогресса стал более точен и обновляется не чаще раза в 0.2 секунды
Компиляция:под Windows, compile.cmd поддерживает множество версий GCC/MSVC/ICL
под Linux, compile.sh теперь создаёт исполняемый файл, способный обрабатывать файлы размером больше 2 ГБ

---

Tornado 0.6 - added the optimal parsing

Compression:new -11..-16 predefined modes employing the optimal parser (-p4)
-fb (FAST BYTES), new parameter used only by the optimal parser
old -10 mode was removed, old -11 mode was better tuned and renamed to -10
-s1 option meaning changed to "64kb hash3 + 4kb hash2", slightly improving compression in -5/-6 modes
new chash5..7 (-x15..17) and bt4..7 (-x24..27) match finders
all chash/cchash/bt matchfinders support -l values that is not power of 2
new manual.txt explaining all compression parameters

Command line and progress indicator:-slp/-rem options, large pages are allocated by default
Win7 taskbar progress indication (green bar) plus info in the console window title
returns Errcode 2 on any error, clears the window title on ^Break
prints ranges and default values for each option, checks option correctness
on Windows, prohibits simultaneous writing by several compression processes to the same output file
prints byte-exact filesizes; speeds are measured in MiB/s
progress indicator is more accurate and updated only once per 0.2 seconds
Compilation:on Windows, compile.cmd supports many GCC/MSVC/ICL versions
on Linux, compile.sh now produces executables that can process files larger than 2 GB

Цитата:

а что если сделать многопоточную упаковку/распаковку, т.е. распаковывать/упаковывать несколько блоков одновременно?
* и с tta такой трюк бы прокатил

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

WildGoblin

Цитата:

Это типа болида спортивного - постоянно что-то совершенствуется - чтобы быть на острие атаки.

даже спортивный болид, несмотря на постоянное совершенствование в "конюшнях"
на соревнования допускается в вполне себе финал/ритейл варианте
а тут даже альфы под одним номером, что должен думать потенциальный потребитель ?
Правильно, да ну эти эксперименты с моими данными куда подальше - и будет абсолютно прав !