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

Bulat_Ziganshin, а почему бы вам не привлечь в разработку еще энтузиастов?
Было бы легче, когда один занимается развитием одного куска кода, второй другим куском, а третий, например, исправлением ошибок первых двух программистов.
PS: Вы, кстати, пишете, кажется, на Haskell. Не дадите ли вы пару ссылок, где собственно скачать саму среду разработки с этим языком, и хорошие руководства, FAQ'и по программированию на данном языке.

Bulat_Ziganshin

Цитата:

остаётся только догадываться почему так популярен 7-zip

Дык у FreeARC задача зарулить в том числе и его. И не в последнюю очередь за счет богатого функционала, с которым у 7zip, мягко говоря, не очень, да и не предвидится.

Стабильность и надежность - условия необходимые, но не достаточные для популярности.
Например Squeez 5.61 - стабильный, надежный, аккуратно оформленный. Как у него с популярностью ? Никак. Почему ? Потому что это очередной, тыща-триста-двадцать-восьмой аналог WinRAR, который ничем особо не лучше. Примерно такой же и по функционалу, и по сжатию, и по скорости. И когда есть уже один широко используемый оригинал, остальные тыща-триста-двадцать-восемь аналогов мало кому нужны.

Утрирую, конечно, но примерно так


Цитата:

это чертовски приятно. то, что вы вообще рассматриваете как реальную задачу замену *всех* прочих архиваторов - это о чём-то говорит, да?

Дык Причем это не комплимент, это просто констатация факта.

По эффективности (скорость/сжатие) FreeARC *уже* заруливает всех. Только подумай, зарулил *все* архиваторы, созданные за последние 25 лет. Это ведь о чем-то говорит ? Остается лишь добавить в него достаточный функционал (главная слабость 7zip), и остальные станут попросту не нужны.

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


tatuich
я не против этого, но вопрос в том, как собственно создать такую команду. особенно учитывая "популярность" хаскела )

сайт - haskell.org, компилятор - ghc, для удобства изучения можно также взять hugs. дальше смотри на http://haskell.org/haskellwiki/Learning_Haskell раздел Online tutorials (или Textbooks если ты хочешь купить книгу). как освоишь сам язык, я тебе подскажу что изучать дальше

Bulat_Ziganshin

Цитата:

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

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

Другое дело, что о шлифовке стабильности и надежности можно будет говорить лишь тогда, когда будет более-менее завершен функционал. То есть не раньше 0.80, а то и 0.90 И это нормально.


Цитата:

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

Дык я двумя руками "за". Тем более, на данной стадии FA еще не обременен необходимостью обратной совместимости со своими же ранними версиями.

Nick222
а хард не надорвется от такого нашествия файлов?

уже немного даже работает:

Код: -------- May 12 2008 20:41:14, archive H:\a.arc
WARNING: No files, erasing empty archive

-------- May 12 2008 20:43:40, archive a.arc
ERROR: General (de)compression error in lzma:11kb:normal:bt4:32:mc16

GUI действительно является неотъемлемой частью популярности.
Но GUI, который предлагается сейчас и неудобен и не стабилен, да еще и Framework зачем-то нужен. В отличие от 7-Zip и WinRAR, приходится каждый раз самому указывать путь и имя архива, когда в вышеперечисленных имя архива уже вписано, а архив создается в папке с архивируемыми файлами.

PAQer
Можешь что-то предложить или просто поболтать??

tatuich

Цитата:

да еще и Framework зачем-то нужен

это общеизвестное зло, которое $MS$ пытается распространить на весь мир. А потому как программисты в основном люди недалёкие в понимании Бога, то и ведутся. Ещё бы - меньше таланта и труда - больше программ и денег.

tatuich
ты говоришь о warc, а не моём winarc. зайди на freearc.org

Добавлено:

Цитата:

Ещё бы - меньше таланта и труда - больше программ и денег.

точно! а началось всё с изобретения каменного топора

Nick222
хотел предложить тебе не насиловать хард

я обновил http://www.haskell.org/bz/arc1.arc

желающие могут потестировать его с гигабайтным словарём:

-mlzma:ht4:1gb:mc64

Цитата:

В отличие от 7-Zip и WinRAR, приходится каждый раз самому указывать путь и имя архива

Скачай Peazip и впридачу к этому архиватору PAQ можешь сравнить без всяких комстрок... Он мощнее, но..
Цитата:

началось всё с изобретения каменного топора

Да, но потом ведь был бронзовый топор! А сейчас попробуй найди его! Прогресс пошёл на попятную и жлобы теперь выпускают для пользователей только дешёвую железку!
Я вот что заметил.. Что-то у меня показатели на высоком и максимальном сжатии (максимум памяти имею в виду) почти не различаются..Это нормально, или играет роль нехватка оперативки и использование виртуалки вместо неё для сжатия?

Bulat_Ziganshin

Цитата:

-mlzma:ht4:1gb:mc64

а про ht4 по-подробней можно.

Никто ещё не взялся за хороший GUI, SFX и т.п.?

Цитата:

Никто ещё не взялся за хороший GUI, SFX и т.п.?

Сформулируйте, плиз, признаки хорошего gui в вашем понимании... Для большинства это просто влом комстроку вспоминать и вбивать..

Цитата:

я обновил http://www.haskell.org/bz/arc1.arc

без файлика arc.custom-log.lua FreeArc вешается.

Цитата:

а про ht4 по-подробней можно

это новый matchfinder (наряду с hc4 и bt4). требования к памяти - 1.75*dictsize. сжатие хуже чем у hc4 с таким же размером словаря, но за счёт впятеро меньших требований к памяти позволяет увеличить словарь и тем самым увеличить общее сжатие

-m3 сейчас вместо rep:32m+lzma:hc4:4m использует lzma:ht4:32m, что улучшило сжатие на 1-10%


Цитата:

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

это нормально. ppmd от увеличения объёма озу не сильно выигрывает; этот режим больше для тестеров


Цитата:

без файлика arc.custom-log.lua FreeArc вешается.

спасибо. исправил, выложил новую версию http://www.haskell.org/bz/arc1.arc

Добавлено:
по просьбам прогрессивной общественности
* -di+% для вывода на экран статистики по памяти (соотв-но, -di+$# её больше не выводят)

http://www.haskell.org/bz/arc1.arc

кстати, Егор, ты как-то спрашивал насчёт lzma: так вот, при нехватке памяти словарь lzma уменьшается, но не плавно, а скачками 256m->192m->128m и т.д.

Цитата:

это новый matchfinder (наряду с hc4 и bt4). требования к памяти - 1.75*dictsize. сжатие хуже чем у hc4 с таким же размером словаря, но за счёт впятеро меньших требований к памяти позволяет увеличить словарь и тем самым увеличить общее сжатие

А на сколько хуже? И как я понимаю, при распаковке такого архива, понадобится памяти 1*dictsize.

Цитата:

А на сколько хуже?

it depends. типично это скажем 1%


Цитата:

И как я понимаю, при распаковке такого архива, понадобится памяти 1*dictsize

ес-но. lzma - очень асимметричный по памяти алгоритм, например для упаковки с 1гб словарём нужно порядка 8 гб озу. ht4 позволяет сделать это на 2 гб озу, но при этом не все потеницальные матчи можно найти. поэтому сжатие получается чуть хуже. с другой стороны, по сравнению с 256мб словарём, который тебе доступен на 2гб озу с обычным lzma, сжатие улучшается на 10-20%. выкинь отсюда выигрыш от использования rep совместно с lzma и получится та самая разница в 1-10%

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

Добавлено:
вот кстати результаты одного из тестов:

>arc a a dll700.dll -mexe+delta+lzma:48m:max
Compressed 1 file, 690.514.620 => 177.168.679 bytes. Ratio 25.6%
Compression time 2528.37 secs, speed 273 kb/s. Total 2882.80 secs

>arc a a dll700.dll -mexe+rep:256m+delta+lzma:48m:max
Compressed 1 file, 690.514.620 => 170.323.820 bytes. Ratio 24.6%
Compression time 2356.71 secs, speed 293 kb/s. Total 2683.61 secs

>arc a a dll700.dll -mexe+delta+lzma:256m:max:ht4:mc64
Compressed 1 file, 690.514.620 => 168.503.951 bytes. Ratio 24.4%
Compression time 6319.67 secs, speed 109 kb/s. Total 7032.06 secs


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

Добавлено:
а вот самый большой выигрыш, который я видел от нового -m3 (хотя я ошибся, тут всего 5%, а не 10):

C:\Base\Compiler\ghc>Arc.exe create d:\a -m3 -r
Compressed 3.010 files, 349.981.012 => 35.966.361 bytes. Ratio 10.2%
Compression time 176.64 secs, speed 1.981 kb/s. Total 228.73 secs

C:\Base\Compiler\ghc>C:\!\FreeArchiver\Tests\Arc.exe create d:\a -m3 -r
Compressed 3.010 files, 349.981.012 => 34.243.936 bytes. Ratio 9.7%
Compression time 167.84 secs, speed 2.085 kb/s. Total 208.77 secs

и для сравнения - lzma:4mb без rep, т.е. решение уровня rar/7-zip:

C:\Base\Compiler\ghc>Arc.exe create d:\a -m3 -r -mcr-
Compressed 3.010 files, 349.981.012 => 37.845.141 bytes. Ratio 10.8%
Compression time 176.78 secs, speed 1.980 kb/s. Total 213.61 secs

вот по сравнению с ним и достигается выигрыш в 10%

вот результат ещё одного теста: 25.5mb 25.1mb 24.7mb (результаты -m4, -m4 с использованием ht4 и словарём 48mb, и 48мб словаря с обычным поиском, требующим 500 мб озу). т.е. из 3% выигрыша, которые можно получить за счёт 6-кратного увеличения размера словаря, 1.5% забираются без увеличения расхода памяти

ну и надеюсь, последняя на сегодня версия http://www.haskell.org/bz/arc1.arc

я уменьшил расход памяти при словаре в 1gb до 1.5гб озу. плиз, кто-нибудь у кого хватает памяти протестируйте это на файле в 1.5гб+ и отпишите сюда - работает чи ни?

быстрый режим: -mlzma:1gb:fast:ht4:mc4
медленный режим: -mlzma:1gb:ht4:mc64

Bulat_Ziganshin

Цитата:

я уменьшил расход памяти при словаре в 1gb до 1.5гб озу. плиз, кто-нибудь у кого хватает памяти протестируйте это на файле в 1.5гб+ и отпишите сюда - работает чи ни?

быстрый режим: -mlzma:1gb:fast:ht4:mc4
медленный режим: -mlzma:1gb:ht4:mc64

Упаковка доконца не проводилась.

(WinXP 32bit)2.5Гб
Allocated 1562 mb, addr=10010000
Allocated 234 mb, addr=015D0000

(WinXP 64bit)2.5Гб
Allocated 2047 mb, addr=7FFF0000
Allocated 1666 mb, addr=02DF0000

(WinXP 32bit)2.5Гб\(WinXP 64bit)2.5Гб

ARC.EXE a a -mlzma:1gb:fast:ht4:mc4
Compressing 1 file of 2.199.871.488 bytes: 0.03 secs
Using lzma:1gb:fast:ht4:32:mc4
Memory for compression 1536mb,

ARC.EXE a a -mlzma:1gb:ht4:mc64
Compressing 1 file of 2.199.871.488 bytes: 0.03 secs
Using lzma:1gb:normal:ht4:32:mc64
Memory for compression 1536mb,

При размере словаря более 1Гб - некорректные значения\поведение

ARC.EXE a a -mlzma:1025mb:ht4:mc64 -lc- -ld-
Using lzma:1025mb:normal:ht4:32:mc64
Memory for compression 2049mb, decompression 1025mb
ERROR: General (de)compression error in lzma:1025mb:normal:ht4:32:mc64

Если выделение памяти 1.5xdict и она выделяется 1xdict+0.5xdict, то предел использования словаря будет как и у rep - 2047m.

Цитата:

Сформулируйте, плиз, признаки хорошего gui в вашем понимании...

winrar. Но я и без gui пользовать буду, если будет sfx. Ещё нет?

Цитата:

При размере словаря более 1Гб - некорректные значения\поведение

это потому, что старшие 2 бита используются для ускорения поиска. обычный lzma ограничен словарём в 1 гб, я не стал это менять


Цитата:

Упаковка доконца не проводилась

так и я могу. мне нужно именно чтоб упаковать и протестировать

Добавлено:

Цитата:

sfx. Ещё нет?

увы

WinXPSP2; P4 3,6 ГГц; 2 Гб озу
файл образ диска с игрушкой

быстрый режим: -mlzma:1gb:fast:ht4:mc4
FreeArc 0.50 alpha (May 13 2008) creating archive: 12.arc
Compressed 1 file, 2.292.084.736 => 2.059.298.572 bytes. Ratio 89.8%
Compression time 1917.34 secs, speed 1.195 kb/s. Total 1172.03 secs
All OK



Добавлено:
WinVistaSP1 32bit; Q6800 2,93 ГГц; 4 Гб озу
файл образ диска с игрушкой

быстрый режим: -mlzma:1gb:fast:ht4:mc4
FreeArc 0.50 alpha (May 13 2008) creating archive: 12.arc
Compressed 1 file, 2.267.578.368 processed 47,3% прекращена работа arc. exe
было 2 попытки краш происходит на одном и том же месте

Добавлено:
WinVistaSP1 32bit; Q6800 2,93 ГГц; 4 Гб озу
файл 7z без сжатия

быстрый режим: -mlzma:1gb:fast:ht4:mc4
FreeArc 0.50 alpha (May 13 2008) creating archive: 12.arc
Compressed 1 file, 5.774.447.978 processed 18,6% прекращена работа arc. exe
было 2 попытки краш происходит на одном и том же месте

спасибо. будем искать

Добавлено:
да, и попробуй плиз 1023 мб и т.д. с распаковкой если успешно упакуется

WinVistaSP1 32bit; Q6800 2,93 ГГц; 4 Гб озу

медленный режим: -mlzma:1gb:ht4:mc64
то же самое что и при быстром режиме, только занимает больше времени


WinXPSP2; P4 3,6 ГГц; 2 Гб озу
файл образ диска с игрушкой

медленный режим: -mlzma:1gb:ht4:mc64
FreeArc 0.50 alpha (May 13 2008) creating archive: 14.arc
Compressed 1 file, 2.292.084.736 => 2.004.957.972 bytes. Ratio 87.4%
Compression time 6691.27 secs, speed 343 kb/s. Total 6099.20 secs
All OK


Добавлено:
WinVistaSP1 32bit; Q6800 2,93 ГГц; 4 Гб озу
Compressed 1 file, 2.292.084.736
-mlzma:1023mb:ht4:mc64 те же 47,3%




Добавлено:
Успех
WinVistaSP1 32bit; Q6800 2,93 ГГц; 4 Гб озу
-mlzma:1000mb:fast:ht4:mc4
FreeArc 0.50 alpha (May 13 2008) creating archive: 12.arc
Compressed 1 file, 2.267.578.368 => 2.150.945.233 bytes. Ratio 94.8%
Compression time 1045.97 secs, speed 2.168 kb/s. Total 708.74 secs
All OK

Процесс распаковки запустил arc.exe x 12.arc
Прогресс распаковки показывает с шагом 46,2 %
Extraction time 165.88 secs, speed 13.670 kb/s. Total 207.95 secs

Проверка по md5 - ОК
Bulat_Ziganshin
Если надо более точно подобрать значение - скажи, но сделать смогу не раньше, чем завтра

Обратил внимание на одну мелочь в логах.
Правильное сокращение для обозначения килобайта - kB, а мегабайта - MB
(это при условии, конечно, что делителем в расчетах является 1000, а не 1024 - иначе должно быть KiB и MiB, соответственно - см. Википедию)