» FreeArc (часть 4)

В srep хэш быстрее чем xxxhash ? Так может надо бенч провести и опубликовать его отдельно, пускай везде используется.

Benchmark

Цитата:

Если разница в сжатии - считанные проценты, а скорость растет пропорционально количеству потоков, то многопоточность решает.

Универсальной зависимости нет. А пользователи, скорее всего, даже не догадаются поэкспериментировать.
Вот, например,
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=840#2
Zcm080 (-t1) – 3 m 22 s, 140 858 897 – загрузка процессора 25 %
Zcm080 (-t2) – 2 m 49 s, 195 288 141 – загрузка процессора 75 %
Zcm080 (-t3) – 2 m 33 s, 234 349 823 – загрузка процессора 100 %
Zcm080 (-t4) – 2 m 36 s, 268 775 356 – загрузка процессора 100 %
Как видите, разница вовсе не проценты, а время вовсе не пропорционально количеству потоков!
Какой здесь будет вывод?
(Мой вывод - кроме (-t1) - все остальное неудачно).
И такая ситуация, возможно, бывает чаще, чем та, которую Вы обрисовали. (никто же экспериментирует!)


Цитата:

Сегодня даже на компьютерах класса "печатная машинка" стоит минимум 4 Gb памяти.

А для 7zip 9.30a, словарь 1024 МБ, потоков 8, нужно 46 ГБ + запас!
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#10

Для rep из FreeArc на машине с ОЗУ 4 ГБ не реализуется 2 Гб!
А как было бы хорошо при сжатии огромных данных, например, rep 8 ГБ + tor.
---
Так что, на мой взгляд, 4 ГБ очень немного.

Добавлено:
Внес исправления.

Цитата:

А для 7zip 9.30a, словарь 1024 МБ, потоков 8, нужно 46 ГБ + запас!

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

Цитата:

В srep хэш быстрее чем xxxhash ? Так может надо бенч провести и опубликовать его отдельно, пускай везде используется.

там используется vhash, на x64 скорость 128-битного хеширования 0.4cpb, т.е. 10 ГБ/с при 4ГГц cpu. я его регулярно людям на encode.ru советую, но его и готовить сложнее, и не особо он им нужен


Цитата:

Для rep из FreeArc на машине с ОЗУ 4 ГБ не реализуется 2 Гб!

это особенность реализации алгоритма, так-то для словаря в 2000 мб достаточно 2512 мб озу. rep со словарём >4ГБ реализован в srep:m0, но понятно что это не так удобно как встроенный в fa алгоритм

sergEO7905

Цитата:

в этом же тесте, говорится что размер архива почти не меняется

Еще раз повторю: универсальных зависимостей не существует.
Вот как Вы отнесетесь к этим тестам:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#19
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#21
?

Добавлено:
Комментарий:
4. Забегая вперед, можно отметить, что размер архива для уровня сжатия Быстрый 1024 МБ и 1 поток в данном тесте получился меньше, чем для любых 4-поточных методов, включая Ультра

Как-то пропустил, что корейцы добавили в свой BandiZip поддержку FreeArc, скрин из темы по архиватору:
http://i9.pixs.ru/storage/5/1/3/Bezimyanni_6339734_16016513.jpg

Цитата:

Более быстрый 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.

Shuld

Цитата:

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

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

Цитата:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bulat вот ссылка

Цитата:

с версией 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

[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.

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

Цитата:

советую заменить "-m3 -l512 -c256" на -m5

Bulat действительно с этим параметром srep3.93a_beta_x86_11-10-14 работает безукоризненно.

Спасибо большое и дай бог вам крепкого здоровья!

Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

Булат, есть ли уже на данный момент решение этой проблемы (сжатие открытых для записи файлов в 7z)?

Bulat_Ziganshin, FreeArc не переезжает ?

Bidding farewell to Google Code

slech
Булат, подскажите пжалуйста как можно проследить причину проблемы с прекращением архивации.

Есть задача по архивации 4-ёх баз. Более года всё работало хорошо.


Код: D:\Backup\DBIntermediate>Arc a -mx4 --logfile=BackupArc.log -w=D:\Backup\DBIntermediate -ep -ag%Y%m%d DBIntermediate_backup_.arc @DBIntermediate.lst
FreeArc 0.67 (November 11 2013) Creating archive: DBIntermediate_backup_20150301.arc using exe+delta+lzma:96mb:normal:32:mc16, $obj => delta+lzma:96mb:normal:32:mc16, $text => dict:64mb:75%+lzma:96mb:normal:32:mc16, $compressed => 4x4:tor:8mb:c3, $wav => tta:m1, $bmp => mm+lzma:96mb:normal:32:mc16
Memory for compression 320mb, decompression 128mb, cache 16mb
Compressed 4 files, 48,826,658,816 => 5,981,402,928 bytes. Ratio 12.25%
Compression time: cpu 23838.55 sec/real 14722.44 sec = 162%. Speed 3.32 mB/s
All OK

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

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


Цитата:

пока только так. я должен научить fa передавать опцию -ssw в 7-zip

ещё не сделано. но я поправлю, это недолго

Цитата:

дай lt успешно созданного архива. добавь -di -di+$#! и сравни вывод умпешной и неуспешной команд

lt DBIntermediate_backup_20150324.arc

Код: FreeArc 0.67 (March 15 2014) listing archive: DBIntermediate_backup_20150324.arc

Archive type: FreeArc
Total bytes: 49,715,728,384
Compressed bytes: 6,139,778,739
Ratio: 12.35%

Directory blocks: 1
Directory, bytes: 256
Directory, compressed: 175
Solid blocks: 1
Avg. blocksize: 46 gb

Compression memory: 192 mb
Decompression memory: 96 mb
Dictionary: lzma:96mb

Archive locked: -
Archive comment: -
Recovery info: -
SFX size: -
Headers encrypted: -
Encryption algorithms: -

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
31 49,715,728,384 6,139,778,739 4 exe+delta+lzma:96mb:normal:16:mc8
-----------------------------------------------------------------------------
4 files, 49,715,728,384 bytes, 6,139,778,739 compressed
All OK

Цитата:

добавь -di -di+$#! и сравни вывод успешной и неуспешной команд

это надо добавлять в команды архивации

Bulat_Ziganshin
Понял, добавил. Сообщу результат как отработает задача. Спасибо!