» FreeArc: бесплатный open-source архиватор

Новые возможности в GUI, который можно скачать по адресу: http://flashmobile.ru/arc/
Встраиваться в интерфейс ОС
Отображать иконки ассоциированных с расширениями имен файлов
Настраивать параметры Solid-сжатия
Блокировать архив от дальнейших изменений

Цитата:

пределы выше указал для Win64\Win32

это ты с final экспериментировал, а ты порверь с no-http версией. и не только возможность выделения >2gb, но и реальной работы с таким размером выделенной памяти

Bulat_Ziganshin
Да нет, скачать-то ее - скачал. А вот GUI - открывается и сразу закрывается. Ошибок нет, логи чистые.

Bulat_Ziganshin
на скорую руку:

Цитата:

проэкспериментируй с no-http версией

то же самое, толкько lzma немного меньше lzma:143m

Цитата:

далее. в 0.40 всё же остались проблемы, связанные с использованием 3+ гб памяти. Егор, плиз посмотри на http://www.haskell.org/bz/arc-fixed.7z - я там снова отключил large-address. для тебя что-то изменилось?

что есть large-address при сборке, что его нет, после editbin /LARGEADDRESSAWARE
работают одинаково.

Больше интересует:
ppmd\rep цифирки одинаковые...
это лечится?
может и у lzp такая же была бы...

(WinXP Pro SP2 32bit)
ppmd:1562m
rep:1562m

(WinXP Pro SP2 64bit)
ppmd:2047m
rep:2047m

Кстати Win32 /3G не рассматривал в качестве использования,
Win64 + /LARGEADDRESSAWARE - перспективней в использовании.

но в целом свет в конце тоннеля виден. вот какой у меня появился список mem-related проблем:

"-m=ppmd:1538m:" - вылет!
"xxx+tempfile+xxx+tempfile+xxx"
rep:300m - неправильно *выводится* объём используемой памяти
то же для lzma. добавить к lzma регулирование размера хеша и разрешить словарь до 384 мб
виртуальная память может ограничивать нас сильнее чем физическая
суммарный объём памяти цепочки алгоритмов должен быть Integer
"Arc.exe a a -di -lc- -ld- -m9b": "ERROR: runArchiveCreate:results undefined"

добавив к этому ещё замену wininet на curl, мы можем надеяться получить следующую версию, не имеющую проблем на машинах с большим ОЗУ. и главная заслуга в этом - твоя!

Добавлено:

Цитата:

Да нет, скачать-то ее - скачал. А вот GUI - открывается и сразу закрывается. Ошибок нет, логи чистые.

попробуй "arc-gui a a". dlls из arc.arc ты взял, я надеюсь? в качестве альтернативы можешь установить полный gtk2hs: http://sourceforge.net/project/showfiles.php?group_id=49207&package_id=42440

Добавлено:

Цитата:

ppmd:2047m
rep:2047m

гм, похоже это размер куска памятиЮ который выделяется *одним блоком*. поскольку фактически rep приэтом выделяет ещё 512 мег для хеша. и ты всё-таки прверь актуальное сажтие - влзьми файл мег на 100 и прогони его через ppmd:32:2047m

Bulat_Ziganshin

Цитата:

вот какой у меня появился список mem-related проблем

Цитата:

"-m=ppmd:1538m:" - вылет!

надеюсь решение будет ввиде определения доступной виртуальной памяти.

Цитата:

добавить к lzma регулирование размера хеша и разрешить словарь до 384 мб

384 маловато наверно будет для быстрого режима, 512 ладнее наверно.

Цитата:

"Arc.exe a a -di -lc- -ld- -m9b": "ERROR: runArchiveCreate:results undefined"

что эта ошибка означает - это вопрос?
но навели на мысль про внешние архиваторы PPMonstr.exe, DURILCA.exe и т.п. где возможна работа с памятью до 2Гб или более, нужно использовать тоже с /LARGEADDRESSAWARE.

Цитата:

добавив к этому ещё замену wininet на curl, мы можем надеяться получить следующую версию, не имеющую проблем на машинах с большим ОЗУ.

с wininet интересовал вопрос как будет идти распаковка архива того же ppmd по сети при большом размере модели?

Цитата:

и главная заслуга в этом - твоя!

если сейчас не решить эти проблемы, то потом массовый пользователь задолбает Вас, как видите в игрушках народ использует 2-4 Гб памяти.

Цитата:

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

если это так, то должно лечится добавлением ещё физ.памяти.

Цитата:

и ты всё-таки прверь актуальное сажтие

делал ppmd:128:2047m и т.п., сейчас сделаю подробней.

SCINER
на http://flashmobile.ru/arc/ добавьте скриншотов окна выбора степени сжатия и параметров Solid-сжатия. а вот скриншот окна настроек ассоциаций файлов можно убрать, т.к. он абсолютно неинформативен

Цитата:

добавьте скриншотов окна выбора степени сжатия и параметров Solid-сжатия

Done.

Цитата:

надеюсь решение будет ввиде определения доступной виртуальной памяти.

там вообще проблема в двоеточии на конце -m...


Цитата:

384 маловато наверно будет для быстрого режима, 512 ладнее наверно.

я вообще уберу искусственные лимиты


Цитата:

с wininet интересовал вопрос как будет идти распаковка архива того же ppmd по сети при большом размере модели?

я же пишу, что вместо него задейстую curl


Цитата:

что эта ошибка означает - это вопрос?

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


Цитата:

если сейчас не решить эти проблемы, то потом массовый пользователь задолбает Вас, как видите в игрушках народ использует 2-4 Гб памяти.

дык уже. и вообще - если нет 64-битной версии, то надо хотя бы 32-битную добить до полноценной работы с 4 гигами. спасибо тебе за долготерпение и возню со всеми этими версиями программы


Цитата:

если это так, то должно лечится добавлением ещё физ.памяти.

да ну? есть своп. размер макс. свободного блока в в вирт. памяти не должен зависеть от объёма установленного физ. озу

ps: с этим разобрался. лимит в 2гб для rep - это у меня чисто счётная ошибка в алгоритме ограничения размера словаря на уровне солид-блока (т.е. это проявляется только в выводе по -di+$). но для ppmd, например, такого ограничения нет


Добавлено:
я добавил описание wArc в шапку.

народ, кто-нибудь может сообразить nsis-скрипт для инсталляции графического fa? хотя бы заготовку, неохота в этой помеси php с ассемблером разбираться

Цитата:

ссылка в шапке есть edit-bin.7z 25Мб

внутри выковырянный комплект из Visual Studio 2005, возможно не минимизированный.

а за использование словаря в 4Мб - руки б оторвал (автору комплекта - ничего личного)

Цитата:

сейчас сделаю подробней.

подопытный 2.TAR = 2731Мб

Физ.память расходуется примерно столько сколько виртуальной или пока не заканчивается доступная Физ.память, дальше смотреть не интересно как мучается машина.
соответственно для ppmd физ.памяти хватает для работы,
для rep, lzma - не хватает.
для lzp - пока сбрасываемые данные будут помещаться в физической памяти будет всё нормально, далее будет таже история.

(WinXP 64bit)
ppmd:2047m (Вирт.память 2114332кб=2065Мб)
lzp:1647m (Вирт.память 1703788кб=1664Мб\3394648кб=3315Мб) (дальше упираемся в другое ограничение в 3.4Гб или типа того)
rep:2047m (Вирт.память 2639852кб=2578Мб)
lzma:223m (Вирт.память 2450788кб=2393Мб)

Цитата:

я же пишу, что вместо него задейстую curl

я понял, но соравно интересно про wininet.

Цитата:

а за использование словаря в 4Мб - руки б оторвал

это был дефолтный словарь в старых версиях 7-zip. а зачем тебе весь этот комплект? editbin вполне хватает


Цитата:

я понял, но соравно интересно про wininet

думаю, что не работало бы

Large Memory Support: http://msdn2.microsoft.com/en-us/library/aa366718(VS.85).aspx
кстати, там упомянуто что блоки памяти больше 2 гиг выделить не удастся так что lzma/rep/ppmd надо ещё и переделывать чтобы они брали память по частям

Добавлено:
http://www.haskell.org/bz/winarc-inet.PNG - демонстрация работы GUI с архивами в интернете

Цитата:

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

уточненние:
физ.память.макс = маскимальное использование физ.память
Вирт.память, Физ.память - По диспетчеру задач.

подопытный 2207.tar = 2207Мб (2 314 722 816)
данные не сжимаемые.

(WinXP 64bit)

lzp:1647m (Вирт.память 1703788кб=1664Мб\3394648кб=3315Мб) (дальше упираемся в другое ограничение в 3.4Гб или типа того)
физ.память.макс=2253000кб=2200Мб

rep:2047m (Вирт.память 2639852кб=2578Мб)
физ.память.макс=2386000кб=2330Мб

lzma:223m (Вирт.память 2450788кб=2393Мб)
физ.память.макс=2389000кб=2333Мб

[more=лог lzp, rep..][no]
lzp:1647m (Вирт.память 1703788кб=1664Мб\3394648кб=3315Мб) (дальше упираемся в другое ограничение в 3.4Гб или типа того)
физ.память.макс=2253000кб=2200Мб

ARC 0.40 Creating archive: a.arc using lzp:1647mb:64:h18
Memory for compression 3gb, decompression 3gb, cache 1mb
Started: 0.00 secs
Found 1 files, 0 archives: 0.02 secs
Sorted 1 files: 0.02 secs
Joined filelists: 0.02 secs
Compressing 1 file of 2.314.722.816 bytes: 0.02 secs
Using lzp:1647mb:64:h18: 0.02 secs
Memory for compression 3gb, decompression 3gb: 0.0 99.9%
Solid block compression results (268.703 seconds): 529.41 secs
lzp:1647mb:64:h18: 2.294.975.767 bytes in 268.703 seconds: 529.42 secs

Writing directory: 529.42 secs
Found 1 directory names: 529.72 secs
Directory written: 529.7
Compressed 1 file, 2.314.722.816 => 2.294.975.767 bytes. Ratio 99.1%
Compression time 268.70 secs, speed 8.614 kb/s. Total 529.78 secs
All OK


ep:2047m (Вирт.память 2639852кб=2578Мб)
физ.память.макс=2386000кб=2330Мб

ARC 0.40 Creating archive: a.arc using rep:2047mb
Memory for compression 2gb, decompression 2gb, cache 1mb
Started: 0.00 secs
Found 1 files, 0 archives: 0.00 secs
Sorted 1 files: 0.00 secs
Joined filelists: 0.00 secs
Compressing 1 file of 2.314.722.816 bytes: 0.00 secs
Using rep:2047mb: 0.02 secs
Memory for compression 2gb, decompression 2gb: 0.0 99.9%
Solid block compression results (52.078 seconds): 1476.34 secs
rep:2047mb: 2.286.153.809 bytes in 52.078 seconds: 1476.41 secs

Writing directory: 1476.42 secs
Found 1 directory names: 1476.72 secs
Directory written: 1476.7
Compressed 1 file, 2.314.722.816 => 2.286.153.809 bytes. Ratio 98.7%
Compression time 52.08 secs, speed 44.447 kb/s. Total 1476.94 secs
All OK[/no][/more]

Добавлено:

Цитата:

а зачем тебе весь этот комплект? editbin вполне хватает

один editbin работать не будет
видел обрезанный комлект до 3.5Мб но выкдадывался он давно.
а здесь под всё amd64, ia64, x86_amd64, x86_ia64
да и может что потом пригодится, пока что Visual Studio под рукой нету.

Цитата:

есть ещё editbin.exe в masm32

тоже работает, когда проверял был win32 /3g + ppmd, а на нём разницы не видно.
т.е. можно дать линк на офф.сайт, на скачивание - упомянуть в справке.
а на выковырнутые файлы не уверен можно ли на них давать линки.

Добавлено:
Bulat_Ziganshin

Цитата:

надо ещё и переделывать чтобы они брали память по частям

Возникает вопрос, а в чём подвох, почему другие писатели архиваторов этим не занимались? есть ли минусы такого подхода? не будет ли падения скорости принципиального?

уфф... поправил все серьёзные косяки с памятью. грузи http://www.haskell.org/bz/arc050-no-http.7z и тестируй. я кстати поставил там в конфиге для -m9 большие размеры словарей, но вероятно это не будет работать в связи с вышеупомянутым ограничением на размер блока памяти. вообще для тестирования было бы хорошо найти кого-то с 4гб+Vista


Цитата:

т.е. можно дать линк на офф.сайт, на скачивание - упомянуть в справке.

какие линки? если всё будет ок, я просто соберу программу с --large-address-aware. или ты вообще?


Цитата:

Возникает вопрос, а в чём подвох, почему другие писатели архиваторов этим не занимались? есть ли минусы такого подхода? не будет ли падения скорости принципиального?

покажи мне хоть олного автора архиваторов, который озабочен работой с >2gb. разве что Игорь. я и сам пока переделывать не собираюсь, скорее говорюб об этом как поетнциальной возможности. будет ли падение скорости - надо тоже разбираться

Bulat_Ziganshin

Цитата:

какие линки? если всё будет ок, я просто соберу программу с --large-address-aware. или ты вообще?

линк где взять editbin
это для тех кто захочет выдавить из железа всё возможное для 32bit софта.
editbin понадобится для внешних архиваторов использующих до 2Гб памяти.

Цитата:

покажи мне хоть олного автора архиваторов, который озабочен работой с >2gb.

а зачем им сейчас об этом заботится, делай 64-bit и проблем не будет...

если 3.24Гб это верхняя планка (тут надо смотреть может это меня только так),
то lzp, rep - добрались до предела.
lzma, ppmd - не добрались, абыдно, но пережить можно.

Цитата:

грузи http://www.haskell.org/bz/arc050-no-http.7z

чтоб два раза не бегать - сунул вместе версию с wininet и без неё. посмотри ещё раз - если разница в поведении между ними сохраняется, то придётся переходить на curl


Добавлено:
1. потестируй плиз сегодняшнюю версию. по поведению старой выводы делать пока рано - там были свои глюки

2. насчёт использования editbin для внешних компрессоров я не сообразил. с другой стороны, их авторы могут и 64-битные версии выложить - это было бы гораздо лучше. с третьей стороны, получение max-capable версии FA становится уж слишком сложным делом - значит, надо переходить к выкладыванию готовых комплектов на download-сайтах (на SF этого делать нельзя - через него можно распространять только open-source ПО). к примеру, от автора CCM я даже благословление на это получил, с gpl-sourced ПО проблем я думаю тоже не будет, насчт durilca/ppmonstr надо будет перетереть

Добавлено:

Цитата:

А возможно добавить возможность наподобие *.tar.gz
т.е. сначала файлы загоняются в один файл без сжатия, а после пакаются, даже наверно на лету прокатит?

в два шага можно:
arc a a -m0 -dm0
arc a b a.arc


Цитата:

чтоб два раза не бегать

... и запихал всё в http://www.haskell.org/bz/arc.arc - теперь это снова прямая ссылка для скачивания текущих тест-версий FreeArc 0.50
в связи с этим arc2.arc и arc050-no-http.7z удалены
no-http версии - для машин с большим ОЗУ. history.txt описывает все изменения

да, Егор, хотя я сделал ограничение алгоритмов по объёму свободной виртуальной памяти минус 1 мб (причём это ограничение не отключается даже по -lc- -ld-) - это похоже не работает даже у меня самого. система рапортует что такой памяти почти 2 гб, а реально выделяется блок размером до 1700 мегов. вероятно, надо использовать более хитроумный способ проверки - выделять память с помощью VirualAlloc, например

Ghost2004

Цитата:

можно было запустить rep:4gb, да ещё пару раз для верности . А так скорее всего придётся эту штуку разбить на куски rar'ом там или Total Commander'ом и подобрать подходящую последовательность и размер..

опять второпях ключевое слово пропустил подобрать подходящую последовательность зачем же лишнюю работу делать самому, пускай FreeArc делает.

т.е.
Bulat_Ziganshin
Пример
есть 4 файла пусть по 2gb
используем rep:1gb, но обработка идёт не последовательно, а параллельно:
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.
2. или возможность задания участков в файлах и их последовательности в обработке.

Четыре гигабайта памяти - недостижимая цель?
http://www.ixbt.com/soft/windows-4gb.shtml
как раз в начале про 3.25Гб речь идёт

Добавлено:

Цитата:

в связи с этим arc2.arc и arc050-no-http.7z удалены

ыыы жестоко
пожалуйства выкладывайте Arc.exe и т.п. новое (без страрого) в архиве 7-zip(на всякий случай)

Цитата:

и запихал всё в http://www.haskell.org/bz/arc.arc

при распаковке в TC(Распаковать каждый архив в отдельный каталог (с именем архива)) папка Documentation попадает в корень, т.е.

arc.arc

получаем
arc\
arc\Documentation\ - пустая папка
arc\Sources\
Documentation\History.txt

зайдя в arc.arc\Documentation\ History.txt не извлекается - ошибка чтения диска

=) Прикол конечно. Каталог назвать двумя точками =)
Поэтому и в корень. Кстати History у меня нормально распаковался.

Цитата:

и запихал всё в http://www.haskell.org/bz/arc.arc

непонятно на просто Win32
выставлял 2560m

получил:
lzma:128m
rep:1gb

ppmd:2017m
ERROR: Can't allocate memory required for (de)compression in ppmd:9:2048432kb
lzp:2208m
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18

вообщем косячит

Нельзя добавить пустую папку, и нельзя создать папку в архиве.
Можно ли сделать такой функционал?

Сорри, что торможу - закопался с тестами...

Могу предоставить текущие результаты.
Исходные данные: Rogue Galaxy, DVD-Split (т.е. DVD9 для PS2 разбитый на 2 DVD5 – у PS2 формат DVD9 настандартный, так что записнная двуслойная болванка не прочтётся приставкой – не говоря уж о том, что две DVD5 раз этак в 4-5 дешевле одной DVD9). Два варианта – первый просто RG_compression methods.arc, второй – RG_ExIm_compression methods.arc, - т.е. извлечённые из .iso данные (но не просто так – на втором диски для совместимости два файла по 1 Gb и 1.5 Gb соответственно пропросту дублируются под разными именами, т.е. что-то вроде hard-link'ов в NTFS – так вот я удалил 100% совпадающие файлы – это к вопросу о трудностях при реализации варианта, где iso файл воспринимается как просто каталог + данные файловой системы – впрочем подозреваю, что оно лечится включением сортировки в первую очередь по размеру (или, скажем, введением дополнительной сортировки максимального приоритета для файлов одинакового объёма)).

Результаты следующие (подчёркивание в имени файла можно воспринимать как двоеточие в настройках, ++ - «tempfile в ручную», т.е. сжатие файла .arc до ++, методом указанным после ++)
исходный релиз сжатый rar'ом: 5 430 917 128 (5.05 Gb)
исходный размер:
RG – 7 906 369 994 (7.36 Gb),
RG_ExIm – 7 904 307 412 (7.36 Gb).

RG_delta+lzma_158mb_max_273.arc - 5 163 801 775 (4.80 Gb) – короче, от 158 mb-словаря выигрыш лишь 5%... Сжимала 3 часа – правда скорее всего, мешали другие приложения.

RG_rep1266mb_h27_a99_32.arc – 5 795 086 471 (5,39 Gb) – от rar'а не сильно отстаёт... Хотя длина 32 тут не самая лучшая настройка... Потому как дальнейшие rep:1512mb:h26:32:a99 дают выигрыш лишь в 20.95 Мб – а l32 чаще всего именно для этого и нужно – чтобы уменьшить дистанцию между совпадающими данными для следующего rep'а, который смог бы преодолеть барьер между совпадающими данными.

Оно и видно:
RG_rep1522mb_h26_a99_32++delta+lzma_158mb_max_273.arc - 5.163.393.612 (4.80 Gb) – фактически то же, что и без rep (разница между 1522mb:h26 и 1266mb:mb минимальна – примерно 2 mb).

А вот с ExIm совсем другая картина:
RG_ExIm_delta+lzma_158mb_max_273.arc – 4 482 809 972 (4,17 Gb) – уже серьёзный выигрыш в 15% только засчёт распаковки iso и сортировки их содержмого (только с hard-link'ами в iso разобраться бы – иначе эти самые 2.5 Гб встали бы lzma поперёк горла).

RG_ExIm_rep1200mb_h27_a99_32.arc – 4 168 528 006 (3.88 Gb) – даже лучше просто lzma...

RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32.arc – 3 660 071 213 (3.40 Gb) – вот тут-то выигрыш от второго rep'а налицо.

RG_ExIm_rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc – 3 616 747 587 (3.36 Gb) – результат очень близок к предыдущему.

Ну и наконец:
RG_ExIm_rep1200mb_h27_a99_32++rep1200mb_h27_a99_32++delta+lzma158mb_max_273.arc
даёт 3 322 267 047 (3.09 Gb) – на данный момент это максимум сжатия, который удалось получить... Впрочем, rep:l32 не самый лучший вариант – вполне вероятно, что rep:4096/512/128 дадут лучшие результаты (не говоря уж о варианте l4096/512/128:s32:d158mb).

Speaking of which,

RG_ExIm_rep1512mb_h26_4096.arc – 4 339 992 792 (4.04 Gb) (угу, тоже лучше простого lzma)

RG_ExIm_rep1512mb_h26_4096++delta+lzma_158_273.arc – 3 304 231 764 (3.07 Gb) – таки с максимумом я погорячился, всё же rep:4096 тут оказалась даже лучше двух rep:32...

В общем, буду дальше тестировать – теперь 4096 (с 32 вместо 512 я начал чтобы охватить более широкий набор настроек), затем наверное 512, а потом 128... Ну а ещё попробую поиграться с d158mb:s32/64/128...

Кстати, может имеет смысл выделять один блок памяти для хранения данных, а другой – для хеш-таблицы? А то у меня в win32 (с /3GB /USERVA=2800) avalible physical memory выдаёт в районе 2500 Mb (впрочем, это я ещё не все жадные до памяти приложения повырубал), а ram speed test застревает на 1909 Mb (есть варианты как с этим побороться?)...

Насчёт варианта rep с более усточивым хэшем – c удовольствием постестирую, даже без распаковки, тем более что на RG она бы улучшила сжатие в раза в 1.5, судя по отсортированному ExIm варианту. И думаю что для всех подобных случаев вышло бы примерно то же самое (на 25 Гб SO 3 – так вообще из 18 Гб сжатых rar'ом стало бы наверняка 5-8 Гб ... Надеюсь только, что она не будет мучить те 8 Гб слишком долго, более 6 часов... И ещё – если будешь реализовывать этот вариант, такое вот пожелание - можно ли без особых трудностей добавить в отладную информацию следующую меру эффективности: сколько сопадений на дистанциях меньше 128 Мб и какой их суммарный размер (т.е. по сути выигрыш), затем то же, но на дистанциях от 128 до 256Мб, 256-512, 512-1024 и т.д (или даже 128-256, 256-512, 512-768, 768-1024 и т.д)? Ведь альтернатива этому лишь возможность воспринимать образы дисков как простые каталоги, а там много подводных камней, вроде тех же hard-link'ов... Да и вообще в смысле распаковки это могло бы устранить проблему прожорливости rep'а – ведь rep:1gb распакуется без тормозов лишь на компе с 2 gb... Другое дело, что для этого варианта (назовём его lrep – (long rep)) придётся исхитряться с распаковкой, используя доступную RAM в качестве кэша и придумывая разнообразные оптимизации... Впрочем, если эта штука будет достаточно быстрой, то можно просто на основании той статистики провести перестановку блоков по 128-1024 Мб и прошерстить их простым rep'ом... Да, и ещё, какие размеры слова там имеют смысл – 128 (ограничив дистанцию до 4-8 Гб) можно испробовать как экстремальный вариант, наподобие 32 для rep?




egor23

Цитата:

опять второпях ключевое слово пропустил подобрать подходящую последовательность зачем же лишнюю работу делать самому, пускай FreeArc делает.

т.е.
Пример
есть 4 файла пусть по 2gb
используем rep:1gb, но обработка идёт не последовательно, а параллельно:
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.
2. или возможность задания участков в файлах и их последовательности в обработке.

Ну, 1 вариант скорее всего не пройдёт, можно коненчо потестировать вариант с разбиванием iso'шек на куски по 256 mb - но вряд ли будет заметный выигрыш, уж очень это ограниченная штука, данные ведь запросто могут лежать не последовательно, плюс её и без freearc элементарно реализовать... А вот подбор и задание участков и их последовательности увеличит время сжатия в n-1 раз (в неоптимизированном варианте), где n - отношение полного размера данных к размеру куска - надо же провести rep для каждого куска с каждым, а в случае простейшего метода оно будет n(n-1)/2, тогда как для простого rep выходит всего лишь порядка n/2 таких сравнений (плюс n-1 раз придётся создавать tempfile )... Может лучше подобные вещи делать с умом - т.е. используя статистику полученную из lrep...

Впрочем, всё равно потестирую RG с этим, разбив её, скажем, на куски по 512 mb...

З.Ы.
Да, а насчёт памяти – даже в win32 /3G /USERVA=2800 rep:1779mb:h27:a99 проходит в 0.40 версии пропатченой editbin, виртуальная (а также физическая) память при этом достигает 2 368 048 kb ... А вот lzma по прежнему не пашет выше 159 mb . В 0.50 (и 0.50-no-http) указанная rep:1779mb:h27:a99 не хочет идти – работает только с h24 вместо h27 – если её не пропатчить editbin (если пропатичть, то ведёт себя также как и в пропатченой 0.40).

Цитата:

Нельзя добавить пустую папку, и нельзя создать папку в архиве.
Можно ли сделать такой функционал?

в общем, я сейчас подчищаю проблемы, выявленные в 0.40, и собираюсь сделать всё как в rar - "arc a archive dir" будет паковать и сам каталог dir, и всё его содержимое рекурсивно


Цитата:

=) Прикол конечно. Каталог назвать двумя точками =)

ещё одна бага. fa должен был обрезать ".." в начале пути


Цитата:

ыыы жестоко
пожалуйства выкладывайте Arc.exe и т.п. новое (без страрого) в архиве 7-zip(на всякий случай)

а какие это может вызвать проблемы? есть стабильная 0.40, которая всё это распаковывает; даже если что будет не так - вы это сразу заметите


Цитата:

получил:
lzma:128m
rep:1gb

ты хочешь сказть, что lzma:192m, lzma:fast:256m, rep:1536m не работают, даже с /3g? ну тогда потестируй на висте, плиз

и ещё посмотри -m8/-m9 без всяких -lc/ld - смогут они автоматом вписаться в твою машину (под xp, xp/3g, vista) или автодетект по объёму доступной вирт. памяти пока что не работает?


Цитата:

ppmd:2017m
ERROR: Can't allocate memory required for (de)compression in ppmd:9:2048432kb
lzp:2208m
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18

ну вот, насчёт ppmd - это как раз пример неработоспособности автоопределения объёма свобожной вирт. памяти. lzp - просто ошибка, надо запретить словари больше 2 гиг


Цитата:

Пример
есть 4 файла пусть по 2gb
используем rep:1gb, но обработка идёт не последовательно, а параллельно:
1. или пропорционально - 1gb\4 = 250mb - берутся по 250Мб из каждого файла и обрабатываются, потом следующие 250Мб и т.д.
2. или возможность задания участков в файлах и их последовательности в обработке.

лучше это делать внешней утилитой


Цитата:

А вот подбор и задание участков и их последовательности увеличит время сжатия в n-1 раз (в неоптимизированном варианте),

учитывая ввысокую скорость работы REP, фактчисеки это будет время n-кратного чтения с диска всех наших 18 гиг


Цитата:

можно ли без особых трудностей добавить в отладную информацию следующую меру эффективности

можно, но только в standalone rep.exe


Цитата:

Ведь альтернатива этому лишь возможность воспринимать образы дисков как простые каталоги, а там много подводных камней, вроде тех же hard-link'ов...

знаешь, была какая-то утилита, которая сжимала не то jpg, не то bmp, но не bit-to-bit - что-то она портила в заголовке. и вот один чел просто написаол батник, которая сравнивала заголовки исходного и восстановленного файла обычной командой fc, и запоминала сжатый файл плюс выведенные fc изменения

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


Цитата:

Кстати, может имеет смысл выделять один блок памяти для хранения данных, а другой – для хеш-таблицы?

и в rep, и в lzma так и делается. поэтому теоретичсеки ограничения на рахзмер окна - 2гига в rep и 256мег в lzma (поскольку один блок памяти ограничен в win32 2 гигами)


Цитата:

Да, и ещё, какие размеры слова там имеют смысл – 128 (ограничив дистанцию до 4-8 Гб) можно испробовать как экстремальный вариант, наподобие 32 для rep?

считай сам - при слове 10000 скорость должна быть 1 мб/с (исходя из seek time 10 мс), при 128 - 12.8 кб/c. при этом всё время распаковки он будет нещадно молотить винтом. я думаю, что это будет достаточно реально при использовании в качестве кэша флешки - там и объёмы в 8-16 гиг доступны, и seek time в 1мс - реален


Цитата:

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

такое в fa есть (буква r в опции -ds), но сейчас оно "подтаскивает ближе" только файлы с одним расширением. надо будет переделать

и ещё - 273 по моим тестам не лучшая настройка для lzma. 128 лучше

и плиз потестируй no-http версии из http://www.haskell.org/bz/arc.arc - они могут быть лучше в плане максим. размера словаря для lzma/rep

Bulat_Ziganshin

Цитата:

ты хочешь сказть, что lzma:192m, lzma:fast:256m, rep:1536m не работают, даже с /3g? ну тогда потестируй на висте, плиз

только смотрел как идёт ограничение если выствить большой словарь на Win32 без 3g.
выставлял размер словаря 2560m(первое число которое пришло на ум).

букву m забыл:
Arc050.exe a a.arc -mppmd:2560 -di -di+$ 2207.tar
ppmd:2560:48mb
Вываливается:
Инструкция по адресу "0x0050788e" обратилась к памяти по адресу "0x01010002". Память не может быть "written".

Цитата:

и ещё посмотри -m8/-m9 без всяких -lc/ld - смогут они автоматом вписаться в твою машину (под xp, xp/3g, vista) или автодетект по объёму доступной вирт. памяти пока что не работает?

Впишутся, а куды они денутся, без -lc/ld - они и раньше вписывались, хотя ещё включу опцию Установить поддержку языков с письмом иероглифами, тогда это будет наглядней в Win32.

Цитата:

а какие это может вызвать проблемы?

мне 4Мб выкачивать тяжело "каждый раз", а извлечением по сети не пользуюсь, у меня не постаянный доступ Inet.

linux-версия - http://www.haskell.org/bz/arc-linux-gui.arc

Ghost2004

Цитата:

RG_ExIm_rep1512mb_h26_4096++delta+lzma_158_273.arc – 3 304 231 764 (3.07 Gb) – таки с максимумом я погорячился, всё же rep:4096 тут оказалась даже лучше двух rep:32...

у lzma размер слова max 273, так что перед тем как отдать ему проганите rep-ом с l256
т.е. rep1512mb_h26_4096 + rep1512mb_h26_256 или типа того, т.е. если повторы большие, то ставить большой l потом уменьшать его.
Но, универсальных настроек быть не может, для этого данные нужно предварительно подвергать анализу, после корректировать настройки алгоритмов сжатия.

ну вот, благодаря Ghost2004 мы наконец выяснили, что моя компиляция просто не включает largemem - похоже, это ошибка в компиляторе!

теперь вопрос звучит так - если все эти 4 exe-шника пропатчить editbin, то есть ли разница в работе http/no-http и gui/console версий хотя бы на одной из 3 ОС - xp, xp/3g, vista-64bit. в зависимости от этого я и буду принимать решение. очень не хотелось бы с curl возиться - времени и так в обрез, да к тому же это лишняя головная боль для тех, кто будет собирать fa из исходников

разумеется, теперь в компиляцию включен шаг editbin, а в инструкцию по самостоятельной компиляции - ссылка на его загрузку


Цитата:

мне 4Мб выкачивать тяжело "каждый раз", а извлечением по сети не пользуюсь, у меня не постаянный доступ Inet.

понял. буду выкладывать для тебя отдельно exe-шники


Цитата:

без -lc/ld - они и раньше вписывались

вот почему я не хотел этим заниматься. те, кто использует -lc- должны сами разбираться сколько им памяти использовать. меня взволновало только то, что -mx не работает при наличии 3-4 гиг ОЗУ


Цитата:

ppmd:2560:48mb

поправлю

Available Physical Memory.exe использует
ExitProcess
GlobalMemoryStatus

RAM Speed Test.exe использует
ExitProcess
GetCurrentProcess
GetCurrentThread
GetSystemInfo
GlobalMemoryStatus
QueryPerformanceCounter
QueryPerformanceFrequency
SetPriorityClass
SetThreadAffinityMask
SetThreadPriority
VirtualAlloc
VirtualFree

(WinXP 32bit) 2.5Гб+2Гб(файл подкачки)+иероглифы
RAM Speed Test.exe 1325Мб
Available Physical Memory.exe 2035Мб

ppmd

Arc050.exe a a.arc -mppmd:2560m -di -di+$ 2207.tar
ERROR: Can't allocate memory required for (de)compression in ppmd:8:1536mb

Arc050.exe a a.arc -mppmd:1326m -di -di+$ 2207.tar (далее Can't allocate memory required)
Memory for compression 1326mb, decompression 1326mb, cache 1mb
ppmd:10:1326mb
Вирт.память - 1371724кб=1340Мб

rep

Arc050.exe a a.arc -mrep:2560m -di -di+$ 2207.tar
rep:1gb
Memory for compression 1280mb, decompression 1gb, cache 1mb
Вирт.память - 1324784кб=1294Мб

Arc050.exe a a.arc -mrep:1070m -di -di+$ 2207.tar (далее Can't allocate memory required, начиная с 1281m(подсчёт нужной памяти переваливает за 1536m) скидывает до rep:1gb)
Memory for compression 1326mb, decompression 1070mb, cache 1mb

Вирт.память - 1371932кб=1340Мб

lzp

Arc050.exe a a.arc -mlzp:2560m -di -di+$ 2207.tar
ERROR: Can't allocate memory required for (de)compression in lzp:2208mb:64:h18

Arc050.exe a a.arc -mlzp:663m -di -di+$ 2207.tar (далее Can't allocate memory required на втором этапе, начиная с 768m(подсчёт нужной памяти переваливает за 1536m) скидывает до lzp:785920kb:64:h18, на втором этапе Can't allocate memory required)
Memory for compression 1327mb, decompression 1327mb, cache 1mb
Вирт.память - 1372616кб=1340Мб

lzma

Arc050.exe a a.arc -mlzma:2560m -di -di+$ 2207.tar
Using lzma:128mb:normal:bt4:32
Memory for compression 1476mb, decompression 128mb, cache 1mb
Вирт.память - 1390612кб=1358Мб

Arc050.exe a a.arc -mlzma:133m -di -di+$ 2207.tar (далее скидывает до 128m, т.е. подсчёт нужной памяти переваливает за 1536m)
Memory for compression 1534mb, decompression 133mb, cache 1mb
Вирт.память - 1570500кб=1534Мб

Как у lzma размер хэша считается? и вообще как выделение памяти считается?

Добавлено:

Цитата:

теперь вопрос звучит так - если все эти 4 exe-шника пропатчить editbin, то есть ли разница в работе http/no-http и gui/console версий хотя бы на одной из 3 ОС - xp, xp/3g, vista-64bit.

было без разницы, 050 пока ещё не проверял
http://forum.ru-board.com/topic.cgi?forum=5&topic=24319&start=600#6


Цитата:

вот почему я не хотел этим заниматься.

вписывались потому что лимит 1536m катит, с +иероглифы уже не катит.


Добавлено:

Цитата:

-mx не работает

не работал в gui - т.к. лимит 1536m не прокатывал в отличии от cli

С памятью обратите внимание на RAM Speed Test.exe
находит самый большой непрерывнй блок в памяти.

В http://www.haskell.org/bz/arc.arc всё, как я понимаю, запихано в 1 блок.
Что не есть гуд.[more=листинг]ARC 0.40 listing archive: http://www.haskell.org/bz/arc.arc
Date/time Attr Size Packed CRC Filename
-----------------------------------------------------------------------------
2007-12-25 00:51:35 ....... 12299 0 c60b5aff Sources/Arc.hs
2007-12-24 17:39:38 ....... 20368 0 7ab468d6 Sources/ArcCreate.hs
2007-12-24 17:39:49 ....... 12658 0 571b8d5f Sources/ArcExtract.hs
2007-11-04 14:11:54 ....... 275 0 9f732b2a Sources/archive_my_work.cmd
2007-12-24 17:39:54 ....... 27207 0 f95809c5 Sources/ArcRecover.hs
2007-12-24 17:40:00 ....... 7789 0 fe2905c0 Sources/ArcvProcessCompress.hs
2007-12-24 17:40:14 ....... 13549 0 6e214db9 Sources/ArcvProcessExtract.hs
2007-12-24 17:40:20 ....... 15613 0 1fcbd0dd Sources/ArcvProcessRead.hs
2007-12-25 00:45:42 ....... 22052 0 70e3ab62 Sources/ArhiveDirectory.hs
2007-12-25 11:39:03 ....... 32256 0 e5ae3eec Sources/ArhiveFileList.hs
2007-12-16 16:25:11 ....... 21298 0 93699783 Sources/ArhiveStructure.hs
2007-02-18 16:20:43 ....... 34709 0 f5425df8 Sources/ByteStream.hs
2007-12-25 04:15:59 ....... 73405 0 08a42e7c Sources/Cmdline.hs
2007-10-14 22:56:33 ....... 266 0 5e8ad1d8 Sources/common.mak
2007-12-13 19:45:21 ....... 1195 0 41a7fa92 Sources/compile
2007-09-25 18:43:13 ....... 13 0 dbb45b04 Sources/compile-O2
2007-12-23 00:40:24 ....... 21 0 9ce4724c Sources/compile-O2.cmd
2007-12-23 12:57:53 ....... 1565 0 a1ab098c Sources/compile.cmd
2007-12-21 00:23:09 ....... 25161 0 c8a5442a Sources/Compression.hs
2007-12-24 19:59:48 ....... 6774 0 52878762 Sources/CUI.hs
2007-10-11 13:15:40 ....... 7916 0 a28b538e Sources/Encryption.hs
2007-12-12 21:06:21 ....... 12991 0 5a88bc01 Sources/Environment.cpp
2007-12-11 23:37:50 ....... 1766 0 e80147d4 Sources/Environment.h
2007-12-23 00:38:47 ....... 12972 0 057bc04e Sources/Errors.hs
2007-12-25 00:58:54 ....... 19468 0 a5c46a8f Sources/FileInfo.hs
2007-11-04 18:07:45 ....... 25168 0 01b70491 Sources/FilePath.hs
2007-12-13 19:58:41 ....... 28454 0 2c63d8a5 Sources/Files.hs
2007-12-24 20:11:57 ....... 11679 0 fdcfa956 Sources/GUI.hs
2007-12-11 23:40:12 ....... 926 0 758c64d7 Sources/makefile
2007-12-21 00:23:20 ....... 11673 0 7d445672 Sources/Process.hs
2007-12-13 19:48:18 ....... 1106 0 a1aca42b Sources/readme.txt
2007-12-24 17:42:52 ....... 20342 0 6daa1e1c Sources/UI.hs
2007-12-24 17:42:27 ....... 12028 0 94828cac Sources/UIBase.hs
2007-09-29 20:23:02 ....... 98 0 ebd9b722 Sources/unix-common.mak
2007-12-15 17:10:05 ....... 10866 0 e525506e Sources/URL.cpp
2007-12-11 23:37:27 ....... 747 0 5d054b12 Sources/URL.h
2007-09-25 20:42:44 ....... 7657 0 7e455627 Sources/UTF8Z.hs
2007-12-21 01:44:35 ....... 34870 0 8d5c9101 Sources/Utils.hs
2005-11-21 23:27:52 ....... 1287 0 49204899 Sources/Win32Files.h
2007-01-19 20:19:29 ....... 10008 0 34bf97d9 Sources/Win32Files.hs
2003-05-23 17:45:06 ....... 24576 0 594a2314 charset.dll
2003-05-23 17:45:12 ....... 892928 0 ca67730c iconv.dll
2005-10-02 19:18:30 ....... 45056 0 a1ecee95 intl.dll
2005-05-15 12:08:50 ....... 127488 0 f7467902 jpeg62.dll
2007-03-28 01:17:26 ....... 101732 0 9ba2f690 libatk-1.0-0.dll
2007-06-12 09:10:04 ....... 536171 0 31e2dad0 libcairo-2.dll
2007-06-13 20:50:38 ....... 638439 0 9db7ce12 libgdk-win32-2.0-0.dll
2007-06-13 20:50:38 ....... 92183 0 76cdaa2a libgdk_pixbuf-2.0-0.dll
2004-03-10 09:17:08 ....... 1705621 0 67f8a141 libgdkglext-win32-1.0-0.dll
2006-08-11 18:49:32 ....... 106777 0 7441fde2 libglade-2.0-0.dll
2007-05-09 23:00:30 ....... 629016 0 ff7518f8 libglib-2.0-0.dll
2007-05-09 23:00:30 ....... 17126 0 a3736f7d libgmodule-2.0-0.dll
2007-05-09 23:00:30 ....... 226818 0 2e849933 libgobject-2.0-0.dll
2007-05-09 23:00:30 ....... 22353 0 ffb79af6 libgthread-2.0-0.dll
2007-06-13 20:50:38 ....... 3562726 0 81944e6a libgtk-win32-2.0-0.dll
2004-03-10 09:17:58 ....... 154544 0 68d311f1 libgtkglext-win32-1.0-0.dll
2007-05-10 15:25:12 ....... 198366 0 8c385ad0 libgtksourceview-1.0-0.dll
2007-04-29 21:59:48 ....... 236568 0 ae21504c libpango-1.0-0.dll
2007-04-29 21:59:48 ....... 38135 0 9f3e892b libpangocairo-1.0-0.dll
2007-04-29 21:59:48 ....... 232767 0 7ab6ec0e libpangoft2-1.0-0.dll
2007-04-29 21:59:48 ....... 59011 0 9cca63f3 libpangowin32-1.0-0.dll
2004-12-03 23:09:32 ....... 203264 0 6129718d libpng13.dll
2006-11-06 21:18:50 ....... 963584 0 a4402b73 libxml2.dll
2004-10-05 00:08:00 ....... 55808 0 8af98e19 zlib1.dll
2008-01-10 20:38:54 ....... 2244608 0 b8a15dee Arc050-no-http.exe
2008-01-10 21:23:50 ....... 2247168 0 335b4fdc Arc050.exe
2008-01-10 22:34:07 ....... 2417664 0 e33122f9 WinArc050-no-http.exe
2008-01-10 22:03:08 ....... 2420736 0 a2fd78ff WinArc050.exe
2008-01-10 22:40:52 ....... 30324 0 fcbc513e ../Documentation/History.txt
-----------------------------------------------------------------------------
69 files, 20.792.052 bytes
All OK
[/more]

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