» FreeArc (часть 4)

muzf
Очень наглядные таблички и графики. Жаль tor и xtor отсутствуют.

Bulat_Ziganshin
1. Архивируем файл test.txt в архив test.arc.
2. Создаём архив из файла test2.txt и именем архива указываем test.arc.
3. В результате есть архив test.arc где присутсвуют два фйла: test.txt и test2.txt.

Цитата:

-m8* превосходны, хочу их из коробки.

а что мешает самому в arc.ini вставить?

ndch
он бы ещё с compress сравнил... даёшь nanozip, zcm и rar5!

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

slech

Цитата:

В результате есть архив test.arc где присутсвуют два фйла: test.txt и test2.txt.

WinRAR5 и 7-Zip действуют в точности также. Стандартная ситуация. Есть файл и есть конечный архив, и пользователь сознательно указывает для второго файла имя первого архива.

slech
думаю что полезно было бы сообщать пользователю, что архив с выбранным именем уже существует, скажем вместо Output archive писать Create archive или Add to archive. опять-таки, наличие user-defined GUI позволило бы решить этот вопрос без моего вмешательства. это может быть плагин который любой пользователь может добавить в свой конфиг примерно с таким скриптом

Код: code("add-dialog", :: {
$(output-archive).onChange(:: {
$(output-archive-label).value = fileExists($(output-archive).value)? "2001 Add to" : "2002 Create"
})})

i18n("rus", 2001, "Добавить к");
i18n("rus", 2002, "Создать");
i18n("ukr", 2001, "...");

muzf
Самое главное - отсутствуют требования к памяти компрессии, и особенно декомпрессии (всего в 1 пункте, не в счет).

Bulat_Ziganshin
Цитата:

а что мешает самому в arc.ini вставить?

Ключевые слова - "из коробки". Чтобы было доступно всем и каждому сразу.
Цель тестирования у меня была не выявление самых сильных компрессоров, а самых быстрый, пригодных для повседневного применения и бэкапа (поэтому тот же -m9 и m5p были только для примера). Например, для бэкапа я не буду использовать то что сжимает медленнее 50Mb/s. Цели тестировать непопулярные решения тоже не было, хотя Nanozip вроде неплох, надо будет проверить. Умеет ли Nanozip режим --sync как в Freearc, удобный для бэкапа ? Насколько я вижу нет, поэтому для целей постоянного бэкапа он не подходит. Rar5 - не вижу ссылки в гугле.

Цитата:

обычно графики рисуют так чтобы лучшие точки были справа-свеху

здесь они снизу-слева, вполне логично.

Цитата:

Самое главное - отсутствуют требования к памяти компрессии, и особенно декомпрессии (всего в 1 пункте, не в счет).

Не было такой цели, сравнение решил провести именно потому, что не видел результатов сжатия на мощной машине (до этого видел только на i5 двухядерном). Макимальный алгоритм требует 2гб, но на 16Gb это всё неважно. Ну и как тестировать потребление памяти в пике - я к сожалению не знаю.

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

Добавлено:
В принципе, это все Update Mode.

Булат привет! Как Ваши успехи, скоро увидим релиз?

Bulat_Ziganshin
где почитать про требования к памяти -m8* методов (при компрессии и декомпрессии)

[more] Bulat_Ziganshin
Привет.
Появилась проблема со срепом.
Файлы пакуются с такими параметрами:


Код: arc.exe a -ep1 -dses --dirs -s --workdir=D:\temp -lc- -di -i2 -r -hppass -msrep+lzma:350mb:normal:bt4:273:lc8 data-XXX.arc packeddata\*

Как лучше тестировать Nanozip, standalone или в качестве external compression для Freearc ? В чём разница ?
На этих данных standalone Nanozip x64 показал себя не очень, на nz_optimum1 итоговый размер 516мб получился за 149секунд, напомню у Freearc -m85 за 22 секунды получилось 489мб, в 7 раз быстрее.

И ещё, заметил что Freearc всегда для external compression создаёт временный файл в %temp% ? Я так понимаю это надо только при использовании последовательно нескольких внешних обработчиков. Возможно ли для случаев, когда используется только один внешний архиватор (например один precomp) не создавать дубликат текущего файла в %temp% ?

slowreflex
попробуй lzma с файлами, без stdin/stdout

Цитата:

Ключевые слова - "из коробки". Чтобы было доступно всем и каждому сразу.

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


Цитата:

Цели тестировать непопулярные решения тоже не было, хотя Nanozip вроде неплох, надо будет проверить.

nz в целом сравним с fa, в чём-то лучше один, в чём-то другой


Цитата:

Ну и как тестировать потребление памяти в пике - я к сожалению не знаю.

consmeter из http://freearc.org/download/research/utils.zip


Цитата:

где почитать про требования к памяти -m8* методов

что-то в районе гига-двух. вообще для freearc можно просто запустить сжатие этим методом и посмотреть выдачу на консоль. или создать достаточно большой архив и посмотреть его ArcInfo

C:\>arc a a -m1 -di
FreeArc 0.67 (December 12 2012) using additional options: --logfile=c:\temp\freearc.log --display=hnwftsr
Creating archive: a.arc using rep:96mb:256:c256+4x4:tor:3:2mb:h64kb, $compressed => rep:96mb:256:c256
Memory for compression 177mb, decompression 96mb, cache 16mb
Compressed 57 files, 1,045,998 => 320,317 bytes. Ratio 30.6%
Compression time: cpu 0.03 secs, real 0.03 secs. Speed 32,685 kB/s
All OK


Цитата:

Как лучше тестировать Nanozip, standalone или в качестве external compression для Freearc ? В чём разница ?

standalone конечно. сам же дальше пишешь


Цитата:

На этих данных standalone Nanozip x64 показал себя не очень, на nz_optimum1 итоговый размер 516мб получился за 149секунд, напомню у Freearc -m85 за 22 секунды получилось 489мб, в 7 раз быстрее.

готовить не умеешь. юзай -cf -m12g


Цитата:

И ещё, заметил что Freearc всегда для external compression создаёт временный файл в %temp% ? Я так понимаю это надо только при использовании последовательно нескольких внешних обработчиков. Возможно ли для случаев, когда используется только один внешний архиватор (например один precomp) не создавать дубликат текущего файла в %temp% ?

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

Bulat_Ziganshin
К сожалению, не помогло.

http://i1.imageban.ru/out/2014/07/29/1033e75591273b03400037fa91baf7b4.jpg

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

slowreflex
попытайся дальше повыкидывать "лишнее", например -hp. пока что у тебя получваается что fa сливает данные в один файл, вызывает на нём srep, и srep в процессе работы крашится. что очень странно, поскольку srep тут по сути никак от fa не зависит. проверь хватает ли свободного места, озу и попробуй предыдущие версии (3.91/3.2)

Цитата:

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

Winrar же не задолбали те, у кого в v3 не открываются архивы v4.

Добавлено:
Добавил в сравнение Nanozip, но он меня не впечатлил - http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#5 . Да, он чуть лучше чем простые режимы FreeArc, но хуже чем -m8*. Да, жмёт на 1/10% сильнее всех, но распаковывает также долго, в реальной жизни это бесполезно.

Bulat_Ziganshin
Места и ОЗУ хватает. Этой же цепочкой запаковалось 8 ГБ данных без проблем. Выбрасывали лишнее из цепочки, но не помогло. Пробовались 3.91 и 3.2. На 3.91 был вылет, на 3.2 вылета не было. Тогда поменяли m5f на m3f для 3.92 и проблем не возникло (c m4f проблем также нет). В общем, не пакует именно эти файлы с таким размером срепом 3.9x с m5f.

Bulat_Ziganshin


Цитата:

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

Так получается с методом -mx, который включен в состав FA?

Добавлено:
muzf
Мне тест понравился.
На всякий случай скажу, что я все время экспериментирую и корректирую методы.
На сегодняшний день они выглядят так:
800 = rep:1gb:512:c512+xlz4
80 = rep:1gb:256:c256+xlz4
801 = rep:1gb:176:c128:d1m:s128+xlz4
802 = rep:1gb:128:c64:d1m:s64+xlz4

81f = rep:1gb:512:c512+xtor:3:4m:h4k ; Самый быстрый rep+tor:3
810 = rep:1gb:176:c128:d4m:s128+xtor:3:4m:h16k
81 = rep:1gb:112:c64:d4m:s64+xtor:3:4m:h32k

82 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h512k:l4

83 = rep:1gb:64:c16:d4m:s32+xtor:4:4m:h1m:l8

84 = rep:1gb:96:c16:d4m:s48:h25+4x4:tor:6:4mb:h8mb

85 = rep:1g:48:c16:d4m:s32+xlzma:4mb:h512k:fast:128:mc8

86 = rep:1g:48:c16:d4m:s24+xlzma:4m:h1m:normal:24:mc8

87 = rep:1gb:h24+4x4:i0:lzma:4mb:h32m:normal:bt4:128 ; 1396 МБ

88 = rep:1g+4x4:t2:i0:lzma:64mb:h64m:normal:bt4:128

89 = rep:1g+4x4:t1:i0:lzma:128mb:h128m:normal:bt4:128

Про метод -81f скажу, что его не планировал для использования. Просто в моих тестах такой получалась самая быстрая связка rep+tor:3. Его я держу чисто для сравнения с другими методами rep+tor:3 по времени.
Методы 83 и 82 планирую перевести на tor:6.

Потестил новую версию unarc.dll и unarc.exe, режимы 4x4 отрабатываются корректно, проблем со случайной нехваткой памяти больше нет. Хорошо определяет по количеству памяти сколько потоков использовать. Скорость радует Спасибо большое!

WinArc - оболочка к FreeArc от Александра Марфина
ЗЫ... для архивации используется Arc.exe
имеет симпатичный (WinRar-овский) интерфейс

Цитата:

muzf
Очень наглядные таблички и графики. Жаль tor и xtor отсутствуют.

tor и xtor используются в методах -m8* в freearc, подключается через экспериментальный ini, Shuld выше описал.

Цитата:

4x4:tor

xtor

Цитата:

4x4:t2:i0:lzma

xlzma

Добавлено:

Цитата:

Winrar же не задолбали те, у кого в v3 не открываются архивы v4.

а такие были?


Цитата:

Жаль tor и xtor отсутствуют

для практического применения ударная комбинация - rep+xtor, всё остальное имеет сугубо научный интерес

Vladimir_02
Спасибо, для просмотра и распаковки самое то

Fossius
Чего там самое-то? Г..вноинсталлер натуральный Отказался от всей гадости, не пустил в интернет - теперь прогресс установки висит на ~40% ) Еще и удалиться не хочет без перезагрузки.
И смущает ссылка - почему не сразу офсайт?


Цитата:

Скорость создания архива выше 2-5 раз, в сравнении с другими архиваторами.
Возможность задействовать все ядра процессора, что дает высокую скорость архивирования.

Ага.
Тупо обертка, вид под WinRAR, внутри 7z.dll (9.32!) и Arc.exe (почти двухлетней давности), facompress*.dll и arc.groups отсутствуют, хотя facompress*.dll в среднем на 10% ускоряет работу, arc.groups улучшает сжатие .

Bulat_Ziganshin

Цитата:

для практического применения ударная комбинация - rep+xtor, всё остальное имеет сугубо научный интерес

На двухядерном xtor выглядит как то не очень по сравнению с tor. На четырёхядерном да, xtor просто отличный вариант.
Примеры приводить ?

Shuld

Цитата:

81f = rep:1gb:512:c512+xtor:3:4m:h4k ; Самый быстрый rep+tor:3

Кстати быстродействие очень сильно зависит от кеша проца.

Skif_off 16:12 18-08-2014
Цитата:

внутри 7z.dll (9.32!)

Лол. /9.32 весьма бажный релиз был, если кто не понял прикола.

Bulat_Ziganshin
Цитата:

а такие были?

Видимо имелся в виду случай с вводом нового формата в ВинРАР 3.0, для распаковки которого требовался ВинРАР 2.9 или новее.
То же самое справедливо и для 7з 9-й версии и ЛЗМА2...

ndch
да, попробуй -m2/-m3 для сравнения

Добавлено:

Цитата:

Кстати быстродействие очень сильно зависит от кеша проца.

Shuld оптимизрует под свою машину и свой набор данных

Skif_off

Цитата:

Чего там самое-то?

Возможность drug'n drop и как следствие распаковка отдельного файла, а не всего архива