» FreeArc (часть 4)

Shuld
по соотношению скорости и степени сжатия. правда, на моей машине и на тестах всего 1-2 файлов

суть в том, что меньший :l улучшает конечное сжатие, но требует больше времени. поэтому для каждого уровня сжатия подбирается такой :l, чтобы получилось не слишком медленно. при этом l257/129/65/33/17 автоматически выставляют :c256/128/..., что позволяет сохранить совместимость архива со старыми версиями FA (не держащими параметр rep:cXX)

Попробовал, сжатый архив: http://rghost.ru/48556675

Лог fa:

arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5

FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 3,445,403 bytes. Ratio 35.3%
Compression time: cpu 3.81 secs, real 4.30 secs. Speed 2,267 kB/s
All OK



Выложил другой архив, что-бы меньше качать было, но тенденция таже самая пишет 3.5 мб, а на диске создается архив размером 8 мб

1noObman1
я ответил в другом форуме:


Цитата:

1. расшифровка методов сжатия выполняется до проверки External compressors и независимо от неё
2. раньше precomp использовался всеми как им вздумается, сейчас у него появился встроенный в arc.exe смысл. то же самое произойдёт например если я встрою srep в программу. я тут вижу неудобство для тех, кто его раньше использовал, но это ж экспериментальные внешние упаковщики, их пользователи должны знать что гарантий совместимости с будущими версиями нет?
3. что ты предлагаешь сделать? я вижу проблему в том что "перехватил" популярное название метода внешнего сжатия, даже если оно использовалось по разному разными людьми

Цитата:

Именно, только через арк.ини. Тк не всегда это удобно, да еще и там jpg сжатие отключено.

а в чём проблема использовать другой метод сжатия? назови его xcomp и определяй как угодно


Цитата:

Только вот большая проблема в том, что unarc.dll теперь не распаковывает эти архивы

т.е. раньше ты давал своё определение precomp (или даже просто использовал встроенное), создавал с ним архивы и теперь эти архивы не распаковываются, поскольку определение поменялось?

смотри - если я оставляю своё новое определение precomp=precomp042:t-j, но переношу его в arc.ini, то у тебя появляется возможность его отключить, но тогда у тебя перестанут работать новые галочки Experimental compressors. и более того, ты будешь создавать архивы с методом precomp, т.е. несовместимые с другими пользователями программы. т.е. это решит твою текущую проблему, но создаст ещё больший бардак в будущем

полноценным решением я вижу признание того, что название precomp уже "захвачено", втч и в настройках arc.ini предыдущих версий freearc, и использование вместо него чего-то нового, скажем unpack

Добавлено:

Цитата:

Что не так с precomp'ом?

это внешний компрессор, надо знать какое у него было определение при упаковке. советую поставить старый freearc, посмотреть какой exe он пытается вызвать и поставить его у себя


Цитата:

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

для precomp это решается запуском на ram-диске (он эти 50 гбайт пишет в текущий каталог), для srep - использованием -m1/m1f

Miggo77

Цитата:

Как возможный вариант - развитие томов восстановления в виде кодов рид-соломона.

В "модемные времена" это было весьма нужно и актуально...

[more=мой лог]
Z:\4>arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5
Compressed 338 files, 9,757,172 => 8,333,609 bytes. Ratio 85.4% cessed
Compression time: cpu 1.76 secs, real 2.45 secs. Speed 3,987 kB/s

Z:\4>C:\Testing\FreeArc666\bin\arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99+lzma:ultra:mc10000:5
FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 3,444,998 bytes. Ratio 35.3%
Compression time: cpu 1.97 secs, real 2.29 secs. Speed 4,253 kB/s
All OK

Z:\4>C:\Testing\FreeArc666\bin\arc create snd.arc snd -m9 -m$wav=tta:s:m3+rep:512mb:128:a99
FreeArc 0.666 creating archive: snd.arc
Compressed 338 files, 9,757,172 => 9,450,527 bytes. Ratio 96.8%
Compression time: cpu 0.67 secs, real 1.05 secs. Speed 9,336 kB/s
All OK
[/more]

в общем, в 0.67 эта ошибка исправлена. очень смутно припоминаю, что там запись из lzma неправильно считалась

Bulat_Ziganshin

Потестировал на нескольких папках версии 25.12.2011 и 14.01.2012.
Результаты практически совпадают и по времени и по сжатию. Где-то чуть лучше, где-то чуть хуже. По сжатию разница на уровне сотых долей процента, по времени - доли процента. Никакого преимущества не заметно.

Добавлено:
Папки размером от 1 ГБ и больше.

Добавлено:
Хотя...

Compressing 1,082 files, 1,212,406,221 bytes.

FreeArc 0.67 (December 25 2011)
rep:1gb:h24+4x4:i0:lzma:4mb:h32mb:normal:bt4:128
Memory for compression 1380mb, decompression 1064mb, cache 16mb
Compressed 1,082 files, 1,212,406,221 => 847,321,687 bytes. Ratio 69.8%
Compression time: cpu 525.46 secs, real 137.87 secs. Speed 8,794 kB/s

11.01.2012
rep:1gb:c256+4x4:i0:lzma:4mb:h32mb:normal:bt4:128
Compressed 1,082 files, 1,212,406,221 => 847,204,487 bytes. Ratio 69.8%
Compression time: cpu 520.33 secs, real 135.05 secs. Speed 8,977 kB/s

14.01.2012
rep:1gb:c256+4x4:i0:lzma:4mb:h32mb:normal:bt4:128
Compressed 1,082 files, 1,212,406,221 => 847,204,487 bytes. Ratio 69.8%
Compression time: cpu 515.65 secs, real 135.32 secs. Speed 8,959 kB/s

программа не может делить архив на тома. автори обещал исправить до конца года.

Bulat_Ziganshin
0.67 зафиналить не собираетесь?

Цитата:

т.е. раньше ты давал своё определение precomp (или даже просто использовал встроенное), создавал с ним архивы и теперь эти архивы не распаковываются, поскольку определение поменялось?

Те что запакованы на старой версии распаковываются. Те что запакованы новой - нет.


Цитата:

смотри - если я оставляю своё новое определение precomp=precomp042:t-j, но переношу его в arc.ini, то у тебя появляется возможность его отключить, но тогда у тебя перестанут работать новые галочки Experimental compressors. и более того, ты будешь создавать архивы с методом precomp, т.е. несовместимые с другими пользователями программы. т.е. это решит твою текущую проблему, но создаст ещё больший бардак в будущем

А если просто сделать в анарк.длл перехват обеих названий: precomp (чтоб распаковывались архивы сделаные на старых версиях) и precomp042:t-j, то разве не проще будет?


Цитата:

полноценным решением я вижу признание того, что название precomp уже "захвачено", втч и в настройках arc.ini предыдущих версий freearc, и использование вместо него чего-то нового, скажем unpack

Немного не понял... unpack это вариант названия прекомпа в арк.ини или что-то другое? Вообщем сути не меняет - анарк.длл не распаковывает архивы с прекомпом сделанные на новых версиях. В этом то и вся суть проблемы, как писал выше - добавить в анарк опознание как precomp так и precomp042:t-j.

Понятно будем ждать следующего релиза, жалко конечно я уж так обрадовался сжатию до 30% .... А что с -mm и -tta не подскажите? Как написано на сайте они предназначены для сжатия мультимедии в особенности wav, так почему результат такой низкий? Обычный -m9 сжимает данные до 64% а с mm\tta удается достичь только 85%, может я что-то не так делаю?


PS И спасибо за чудесную программу

Bulat_Ziganshin

Цитата:

ещё гляну на фрагментированном файлике

Nero-9.2.6.0_trial.tar 1883МБ 323 фрагмента

1. данные на HDD - запись на другой HDD

старый rep arc + dll
Compressed 1 file, 1,974,371,328 => 510,572,988 bytes. Ratio 25.8%
Compression time: cpu 35.64 secs, real 58.50 secs. Speed 33,750 kB/s

новый rep arc + dll
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 33.92 secs, real 40.64 secs. Speed 48,581 kB/s

новый rep arc без dll
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 27.19 secs, real 34.92 secs. Speed 56,537 kB/s

новый2 rep arc + dll
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 23.06 secs, real 46.11 secs. Speed 42,819 kB/s


2. данные на HDD - запись на HDD

старый rep arc + dll
Compressed 1 file, 1,974,371,328 => 510,572,988 bytes. Ratio 25.8%
Compression time: cpu 36.00 secs, real 61.25 secs. Speed 32,235 kB/s

новый rep arc + dll
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 33.48 secs, real 43.34 secs. Speed 45,551 kB/s

новый rep arc без dll
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 26.73 secs, real 43.17 secs. Speed 45,733 kB/s

новый2 rep arc + dll
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 22.64 secs, real 55.80 secs. Speed 35,385 kB/s

Итого
новый rep arc без dll vs новый2 rep arc + dll
по cpu time новый2 rep быстрее на 15%, но это преимущество можно увидеть в идеальном случае, в теории.

Добавлено:
PS: скорость чтения с диска файла Nero-9.2.6.0_trial.tar ~70МБ\с

Bulat_Ziganshin

Цитата:

в 0.67 эта ошибка исправлена.

Имеет смысл обновиться или все-таки подождать финала?

Цитата:

по cpu time новый2 rep быстрее на 15%, но это преимущество можно увидеть в идеальном случае, в теории.  

с 11 по 14 января я исключил rep из facompress.dll. изменил дефолт с rep:l512:c256 на rep:l512:c128 плюс переписал встроенный в exe алгоритм crc, у меня лично он стал вдвое быстрее

Skif_off
Я с версией 0,666 не мог работать - там ошибки.
А в версии 0,67 те ошибки, что мы замечали, Булат исправил.
Я в последней версии 12-12-2012 пока с ошибками не сталкивался.

Bulat_Ziganshin

Цитата:

с 11 по 14 января я исключил rep из facompress.dll. изменил дефолт с rep:l512:c256 на rep:l512:c128 плюс переписал встроенный в exe алгоритм crc, у меня лично он стал вдвое быстрее

Если ничего больше не делалось, то "переписал встроенный в exe алгоритм crc", ухудшает ситуацию.
"он стал вдвое быстрее" - относительно чего?

1. данные на HDD - запись на другой HDD

новый rep, arc без dll, -mrep:1g:512:c256
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 27.14 secs, real 35.20 secs. Speed 56,085 kB/s

новый rep, arc без dll, -mrep:1g:512:c128
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 28.77 secs, real 36.19 secs. Speed 54,559 kB/s

новый2 rep, arc + dll, -mrep:1g:512:c256
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 21.42 secs, real 43.84 secs. Speed 45,032 kB/s

новый2 rep, arc + dll, -mrep:1g:512:c128
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 22.97 secs, real 43.19 secs. Speed 45,716 kB/s


2. данные на HDD - запись на HDD

новый rep, arc без dll, -mrep:1g:512:c256
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 26.84 secs, real 43.45 secs. Speed 45,437 kB/s

новый rep, arc без dll, -mrep:1g:512:c128
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 28.59 secs, real 42.95 secs. Speed 45,966 kB/s

новый2 rep, arc + dll, -mrep:1g:512:c256
Compressed 1 file, 1,974,371,328 => 514,212,681 bytes. Ratio 26.0%
Compression time: cpu 21.17 secs, real 54.56 secs. Speed 36,185 kB/s

новый2 rep, arc + dll, -mrep:1g:512:c128
Compressed 1 file, 1,974,371,328 => 512,900,101 bytes. Ratio 25.9%
Compression time: cpu 22.02 secs, real 54.16 secs. Speed 36,457 kB/s

QSQ
Заблокируйте у себя картинку в браузере. Ее можно переложить на другой сервис, но на руборд нельзя положить.

Цитата:

0.67 зафиналить не собираетесь?

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


Цитата:

Имеет смысл обновиться или все-таки подождать финала?

обновляйтесь. 0.67 сейчас горазло качественней чем 666


Цитата:

Обычный -m9 сжимает данные до 64% а с mm\tta удается достичь только 85%, может я что-то не так делаю?  

всё зависит от конкретных данных. у вас медкие wav-файлы, fa к этому не приспособлен. попробуйте nz,rar4,uharc

juvaforza зачем мне лишнее правило из-за 1 картинки в 1 теме? замените
Код: http://i.pixs.ru/storage/4/3/6/a6be7ecb7c_4393823_4901436.png

Цитата:

Если ничего больше не делалось,

ах да - и ещё увеличил буфера i/o с 64 кб до 1мб. несколько лет назад (вероятно как раз на xp) проверяли - оптимальные буфера были 32-64 кб. сейчас - 1 мб на моей win7. видимо, надо проверять ОС и в зависимости от неё делать размер буфера

crc от 11-го января - 400 мб/с, от 14-го - 800 мб/с, а с facompress.dll был и остался 1.5 гб/с. можешь проверить - -mcrc

http://lenta.ru/news/2013/09/06/encryption/

это к вопросу о том, достаточно ли шифрования по american encryption standard, к тому же так удобно ускоренного в процессорах американской фирмы intel

Цитата:

зачем мне лишнее правило из-за 1 картинки в 1 теме? замените

Ну так если тебе так мешает, не заходи сюда. Зачем тебе лишнее правило из за одной картинки в одной теме???

Цитата:

ах да - и ещё увеличил буфера i/o с 64 кб до 1мб. несколько лет назад (вероятно как раз на xp) проверяли - оптимальные буфера были 32-64 кб. сейчас - 1 мб на моей win7. видимо, надо проверять ОС и в зависимости от неё делать размер буфера

надо щупать, у меня нет Win7.


Цитата:

crc от 11-го января - 400 мб/с, от 14-го - 800 мб/с, а с facompress.dll был и остался 1.5 гб/с. можешь проверить - -mcrc

новый rep, arc без dll
Nero-9.2.6.0_trial.001 - Compression time: cpu 4.38 secs, real 4.45 secs. Speed 164,829 kB/s
Nero-9.2.6.0_trial.tar - Compression time: cpu 11.67 secs, real 11.78 secs. Speed 167,586 kB/s

новый2 rep, arc без dll
Nero-9.2.6.0_trial.001 - Compression time: cpu 3.45 secs, real 3.48 secs. Speed 210,656 kB/s
Nero-9.2.6.0_trial.tar - Compression time: cpu 9.20 secs, real 9.25 secs. Speed 213,446 kB/s

новый2 rep, arc + dll
Nero-9.2.6.0_trial.001 - Compression time: cpu 2.80 secs, real 2.84 secs. Speed 258,111 kB/s
Nero-9.2.6.0_trial.tar - Compression time: cpu 7.50 secs, real 7.59 secs. Speed 260,000 kB/s


в 7z в тесте 1200 МБ\с, а на реальном файле ~700 МБ\с

timer.exe 7z h -mm=crc32 Nero-9.2.6.0_trial.tar

crc32 Size Name
-------- ------------- ------------
1DA6E18E 1974371328 Nero-9.2.6.0_trial.tar

Kernel Time = 1.781 = 00:00:01.781 = 62%
User Time = 1.062 = 00:00:01.062 = 37%
Process Time = 2.843 = 00:00:02.843 = 99%
Global Time = 2.860 = 00:00:02.860 = 100%


7z b -mm=CRC -md30

....
30: 1243

Avg: 1370

Bulat_Ziganshin

Цитата:

это к вопросу о том, достаточно ли шифрования по american encryption standard, к тому же так удобно ускоренного в процессорах американской фирмы intel

Быстрее зашифрует - быстрее и расшифрует Думаю, их аппаратный RNG тоже не совсем random.

Булат, вопрос к тебе как к автору arjz. Есть arj-архив, в нем есть упакованный exe'шник, дающий при распаковке ошибку crc. Инфы для восстановления в архиве ессно никогда не было. Есть серьезные основания полагать, что ошибка не более, чем в 1 бит (к примеру правильный байт был 87, а "стал" C7). Вопрос: как локализовать место в сжатом файле, где возникает ошибка ? Чтобы на край хоть все 256 вариантов сбойного байта перебрать

shrmn я залил, смени ссылку: лень, что-ли?

QSQ
Нет, совсем не лень. Да и залить я и сам бы смог. Все, что ты делаешь- по русски называется хамство. Мне плохо- делайте все ради меня, любимого. Успокойся. Тебе уже дали совет, ну что тебе не нравится? Нет, родной, некрасиво так...

Цитата:

в 7z в тесте 1200 МБ\с, а на реальном файле ~700 МБ\с

это понятно - на чтение файла тоже уходит время

ты попробуй старым arc (от 25 декабря или 11 января) с dll - там чтение шло по 64 кб, для твоей xp будет вероятно побыстрее

Добавлено:
egor23
кстати, вспомнил - попробуй http://encode.ru/threads/1450-Reading-to-a-buffer?p=27926&viewfull=1#post27926

Benchmark
посмотреть в расжатом файле до какого места он выглядит правдоподобно и с какого места - неправдобподобно. соответственно между ними локализована ошибка

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

в любом случае это требует программирования

shrmn тогда я пожалуюсь на тебя. ты создаёшь неудобство пользователям.

Я запутался.
Консольный arc.exe использует facompress.dll или нет?
Проверил все варианты.
Процессор i3-530 (2 ядерный, 4 поточный), Win7 32-разрядная, ОЗУ 4 ГБ

Старый rep
Метод Размер Время, v25.12.2011 Время, +facompress.dll