» FreeArc (часть 4)

Цитата:

Более быстрый LZMA.

Довольно сильно проигрывает LZMA в сжатии. И на голову ниже LZMH по скорости распаковки.


Цитата:

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

lzma:d128mb - 855 mb
lzmh:d128mb - 874 mb
lzham:d29:х - 872 mb
*lzma:lc1:fb64:lp0:pb2:d512mb - 533 mb

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


Цитата:

Какой здесь будет вывод?

Неудачная реализация многопоточности. В WinRAR она сделана куда более удачно, небольшой тест:


Tools:
ProcProfile v1.5 x64
RAR 5.21 [15 Feb 2015]
SoftPerfect RAM Disk v 3.4.5 x64

System:
i7-4700MQ @2.40 GHz.
8 GB RAM.
Windows 7 Ultimate SP1 x64.


Цитата:

Вот как Вы отнесетесь к этим тестам:

Там (S)REP должен решить проблему с маленьким словарём у LZMA.

Не могу разбить архив на несколько частей. Вместо этого он все пакует в один архив.
У меня win x64, а когда я скачиваю с оф. сайта, там 32. В этом может быть проблема?

Shuld

Цитата:

Еще раз повторю: универсальных зависимостей не существует.

Безусловно. Обратное и не утверждалось

Цитата:

Вот как Вы отнесетесь к этим тестам:

Это частный случай для конкретного типа файлов (doc). Если приблизить его к реальным современным условиям и заменить doc на docx, результаты могут сильно отличаться. Не стоит забывать, что многие из популярных современных форматов (графика, документы, аудио, видео, дистрибутивы, образы дисков) изначально используют компрессию. Поэтому хочется увидеть более реалистичный "test set".

В данном конкретном случае соглашусь с Edison007007 - неудачная реализация. По сути там просто неспособность эффективно использовать более 1 потока в плане сжатия и более 2 потоков в плане скорости.

Black_Ghost

Цитата:

Не могу разбить архив на несколько частей

Если речь про .arc архив, то многотомность пока еще не реализована (смотри Планы дальнейшего развития Версия 0.75)
Используй сжатие (на вкладке "Основное" поменяй "Тип архива") в .zip или .7z, тогда будет многотомность. Но, увы, будет другой формат архива.

вышел WinRAR5 с новым форматом сжатия RAR5, с обычным режимом сжатия в этом формате на моих файлах ситуация такая: на каких-то файлах на уровне best assymetric +/- 1мб, но фриарк стабильно проигрывает до 20мб если данные очень большого объема
(старый rar в 4-ой версии стабильно проигрывал фриарку по 5-15мб на моих файлах),
скорость сжатия\распаковки RAR5 повыше чем у freearc (4 ядра, 4 гига оперативы)
конкуренты не спят, новый винрар жмет неслабо, по крайней мере с теми файлами с которыми я имею дело

Ну docx это вообще старый добрый zip с xml внутри, его только с перепаковкой precomp можно сжать.

All
Такой вопрос - как FreeArc относится к своим битым/недокачанным архивам (в смысле без информации для восстановления)? Может он их вообще открыть и извлечь неповрежденные файлы?
У 7-zip с этим ой как плохо... недокачанные даже за свои архивы е признает...

cross125
21:28 18-05-2013
Цитата:

конкуренты не спят, новый винрар жмет неслабо

А зачем вообще в нынешних условиях, при нынешних размерах носителей и нынешних скоростях интернет эта погоня за мегабайтами?
Сейчас ИМХО на первое место выходят удобство и доп.фичи (каковых кстати, у FreeArc много - меня сдерживает от его использования только нераспространенность формата arc).

Скажите а как быть если мне нужно запаковать файл а сохранять его я хочу из своего приложения есть ли какая реализация в Dll ?

Ну то есть нужно запаковать файл/информацию в памяти не создавая фаил на жестком диске.

Конечно можно создать на жестком диске потом удалить но это некрасиво и так сказать фрагматично ...

Подскажите, как создать архив, если в источнике присутствуют не только файлы, но и папки (например по 5 Гб, и их надо разделить на несколько архивов) с файлами? Необходимо, чтобы при извлечении, чтобы сохранилась структура папок.

WatsonRus
ну фриарк как раз этим и силен - мегабайтами) я перелопатил свои репаки, распаковка RAR5 на всех в 2.5-3 раза быстрее чем у арк-архивов с практически тем же размером
фичи? ну смотря какие, например такой банальной вещи как многотомный арк-архив нету (хотя лично мне - не надо)
а нераспространенность по мне так плюс - не открывается в других популярных архиваторах, переименовываешь расширение и готово, неча копатся в моих архивах))) (защита от дураков но работает реально XD) 5ый рар тож не открывает арки

G787
нет
Shad0wl0rd
только вручную подбирать

Цитата:

ну фриарк как раз этим и силен - мегабайтами) я перелопатил свои репаки, распаковка RAR5 на всех в 2.5-3 раза быстрее чем у арк-архивов с практически тем же размером

У меня fa всегда быстрей и лучше пакует и распаковывает чем rar5. Для упаковки использую rep:22m:64:c16:d4m:s32+exe+xtor:4:4m:h512k:l4 как показала практика, это оптимальное соотношение сжатия и скорости.

Хочу ужать игру симпсы 3, флешка 16gb, а вес игры 23gb, реально ужать, чтобы влезла и после этого на другом компе, запустить установку?
И вообще, на сколько сейчас он актуален, заранее спс.

cross125 23:25 19-05-2013
Цитата:

ну фриарк как раз этим и силен - мегабайтами

Зачем сейчас их так экономить? И тот же RAR5 тоже - зачем?
23:25 19-05-2013
Цитата:

такой банальной вещи как многотомный арк-архив нету

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


All
Так как насчет чтения FA своих битых/недокачанных архивов?

vitppc
На флешке места скорее всего меньше, чем 16Гб. Сомневаюсь, что влезет. Хотя как повезет: сжатие раз на раз не приходится. Если есть возможность, можно создать многотомный архив и перенести за 2 раза. Или на вторую флешку остаток записать.

WatsonRus

Цитата:

Зачем сейчас их так экономить? И тот же RAR5 тоже - зачем?

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

Paramon111

Цитата:

У меня fa всегда быстрей и лучше пакует и распаковывает чем rar5. Для упаковки использую rep:22m:64:c16:d4m:s32+exe+xtor:4:4m:h512k:l4 как показала практика, это оптимальное соотношение сжатия и скорости.

ну я юзаю Best assymetric т.к. дает лучшее сжатие (причем лучше чем максимальное), рар5 с обычным сжатием дает тот же результат (+/-1мб), но упаковка\распаковка быстрее, тонкой настройкой заниматься лень, просто юзаю готовые пресеты

в чем причина таких ошибок SREP 3.93a beta (October 11, 2014) при распаковке архива ?

описание в arc.ini
unpackcmd = srep {options} -d -s - - <stdin> <stdout>

с версией SuperREP 3.0 (Jan 30, 2012) проблем нет

Paramon111
rep:22m:64:c16:d4m:s32+exe+xtor:4:4m:h512k:l4
Узнаю знакомые черты.
А почему 22m? не 16 и не 32?

PS на текущий момент считаю более удачными (конкретно для xtor:4:4m:h512k:l4) параметры
rep:..m:80:c32:d4m:s40+...
кстати, на основании ваших же данных!

Diana_Kovalenko
у вас в скрине две ошибки, конфиг-файл видимо из второй. предлагаю начать с первой, там проще разобраться. желательно скинуть мне полный архив, включая все файлы arc.exe arc.ini и т.д. необходимые для воспроихведения ошибки

Shuld

Цитата:

rep:22m:64:c16:d4m:s32+exe+xtor:4:4m:h512k:l4   Узнаю знакомые черты. А почему 22m? не 16 и не 32?

Действительно, этот алгоритм взял с твоих исследований. 22m это минимальное потребление памяти при этих параметрах. А вообще можно и rep:128m поставить, на скорость практически не влияет.


Цитата:

на текущий момент считаю более удачными (конкретно для xtor:4:4m:h512k:l4) параметры rep:..m:80:c32:d4m:s40+...

Согласен, скорость возросла почти при том же сжатии. В конечном счете можно предложить вариант rep:128m:80:c32:d4m:s40+exe+xtor:4:4m:h512k:l4 для быстрой упаковки и распаковки.

Bulat как я могу переслать вам необходимые файлы ?

rg.ru, mega.co.nz...

Цитата:

22m это минимальное потребление памяти при этих параметрах.

н-да, сурово.


Цитата:

Так как насчет чтения FA своих битых/недокачанных архивов?

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

Bulat вот ссылка

Bulat_Ziganshin 19:47 20-05-2013
Цитата:

в морг.

Не айс.

Добавлено:
Значит, мне FA не подойдет.

Ситуация такая - допустим, нужен только один не очень большой файл из большого архива, точно известно, что он где-то в начале архива. Для того же rar я скачиваю часть архива чуть более примерного размера файла и обрываю закачку, затем вытаскиваю нужный файл из недокачанного архива. С arc такое не прокатит (равно как и с 7z).

Цитата:

с версией SuperREP 3.0 (Jan 30, 2012) проблем нет

у меня получилось следующее:

с srep 3.0 этот архив распаковать невозможно:


Код: M:\11>arc t data.arc
FreeArc 0.67 (March 15 2014) testing archive: data.arc
Testing 113 files, 54,676,790 bytes. Processed 0%
Unpacking 36,437,086 bytes with srep -d -s $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

ERROR! Incompatible compressed data format: v2098180 (this program supports only v1..v3) in file $$arcpackedfile$$.tmp

Errorlevel=4

ERROR: invalid compression method or parameters in srep

Bulat_Ziganshin
Не так написал. Хотел сказать что 22m это минимальное ОЗУ распаковки.

[more] 1 тест srep3.0_x86_30-01-12

Код: FreeArc 0.67 (March 15 2014) creating archive: С:\ARC\data.arc
Compressing 114 files, 54,676,790 bytes. Processed 0%
Compressing 54,676,790 bytes with srep -m3 -l512 -c256 -a1 $$arcdatafile$$.tmp $
$arcpackedfile$$.tmp
SREP 3.0 (January 30, 2012): input size 52 mb, memory used 36 mb, -m3 -l512 -c25
6 -a1
100%: 54,676,790 -> 35,971,447: 65.79%. Cpu 96 mb/s, real 77 mb/s

Errorlevel=0
Compressed 114 files, 54,676,790 => 15,565,150 bytes. Ratio 28.47%
Compression time: cpu 22.11 sec/real 13.28 sec = 166%. Speed 4.12 mB/s
All OK

All done.

Цитата:

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

чем качаешь-то? вообще-то fa умеет сам распаковывать через http, и скачивает при этом необходимый минимум данных


Цитата:

Хотел сказать что 22m это минимальное ОЗУ распаковки.

ясно. хоть для xtor должно и 4 мб хватать, но это ещё не доделано. только неясно, а зачем тебе такое? меньше чем 128 мб озу ты всё равно сейчас не найдёшь, а если найдёшь - будет ли там fa/unarc работать?

Diana_Kovalenko
да, ошибка возникает от сочетания опций -l512 -c256. я посмотрю, а вам советую заменить "-m3 -l512 -c256" на -m5