» FreeArc (часть 4)

Shuld
а размер процессорного кеша вы учитываете?

Цитата:

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

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

Bulat_Ziganshin,
Насчёт гуи и настроек - как-нибудь поставлю полную - поганяю, гляну что там интересного после 0.666 добавилось...
А использую я консольную версию в паре с Total Commander, потому интересует "консольное" использование.

В архиве обнаружил файлы
srep.exe
srep32.exe
srep32i.exe
srep64.exe
srep64i.exe
В чём разница?

p.s.
x64 версия FreeArc планируется?

Bulat_Ziganshin
Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.

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

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

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

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

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


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

Bulat_Ziganshin

Цитата:

а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.

А вот что я не учел - на одноядерном процессоре размер памяти увеличится.
(Я мыслил своим 4-поточным).
Да и пожалуй, я поторопился с кэшем h256kb для метода -m1, все же h128kb лучше будет.
А размер памяти для
rep:16m+xtor:3:1m:h128k
при четырех потоках 41-38-16MB (упаковка-распаковка-кэш)
при двух потоках 33-29-16MB

На вашем сайте со статистикой есть пользователи с ОЗУ 128 МБ.
Интересно, сколько памяти для упаковки им доступно?

Рассуждения о rep-е.
Если посмотреть в моих тестах на любой график для FreeArc-а, то он извилист.
Причем извилины повторяют rep. (объем данных я всегда тестировал большой).
Начиная с метода -m1 "горб" вверх - у него нет rep-а.
Далее полочка с методами -m2...-m4 - у них одинаковый rep:96m.
Далее опять идет спуск вниз - у последующих методов rep растет.
Хорошо это или плохо, но связь прослеживается.
(на маленьких объемах данных зависимости от rep-а не должно быть).

Цитата:

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

Комментарии я хотел в соответствующую вкладку засунуть

А с комментариями что не так? Поставил галочку написал комментарий и пустил на сжатие.


Цитата:

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

Все уже давно придумано в других прогах, может стоит просто их перенести в ФА?

А за шифрование я совсем вас не понимаю, что с ним не так? можете кратко объяснить.

Блин все нет времени дорисовать другие вкладки. Если они вам еще нужны то на выходных я все сделаю

WatsonRus

Цитата:

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

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

Paramon111

Цитата:

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

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

Shuld
насчёт добавления rep в -m1. думаю, эти данные всё объясняют:

Цитата:

I:\>arc a a -mrep
Compressed 1 file, 810,411,321 => 629,317,667 bytes. Ratio 77.6%
Compression time: cpu 2.89 secs, real 2.39 secs. Speed 339,633 kB/s

I:\>arc a a -mxtor:3
Compressed 1 file, 810,411,321 => 440,306,287 bytes. Ratio 54.3%
Compression time: cpu 11.11 secs, real 1.55 secs. Speed 522,142 kB/s

I:\>arc a a -mrep+xtor:3
Compressed 1 file, 810,411,321 => 372,309,603 bytes. Ratio 45.9%
Compression time: cpu 9.39 secs, real 2.69 secs. Speed 300,804 kB/s

вот если бы rep сделать многопоточным...



Цитата:

Есть предложение, чтобы в консольном arc.exe (хотя бы при упаковке) убрать спаминг процентов при запуске внешнего компрессора, иначе эти 10% все остальные циферки перекрывают. Оставить только изменение времени в заголовке окна и хватит.

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

Добавлено:

Цитата:

а размер процессорного кеша вы учитываете?

Нет, не учитывал.
Он до метода -mex6 вкл. 16 МБ, а свыше 256 КБ.

что такое процессорный кеш - можно посмотреть в гугле. эти 16мб/256кб - дисковый кеш в моей программе. а вот это:
Цитата:

я поторопился с кэшем h256kb

- вообще не кеш, а хеш-таблица

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

ruduk

Цитата:

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

???
Архиватор смотрит объем данных и "скорость работы процессора".
Все!
На основании этого "считает" сколько времени для каждого из методов.
(разумеется, ориентировочно).
Речь именно оценить порядок времени, а не получить точное значение +-1%!

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+...
кстати, на основании ваших же данных!

Bulat_Ziganshin

Цитата:

она и при распаковке нужна будет

Булат, а нельзя ли в перспективе сделать сей процесс со SREP "базонезависимым" чтоль, даже не знаю как выразиться. Или "автономным" ну к примеру если SFX - чтобы он в код ехе встраивался и тд.

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_Ziganshin

Цитата:

всё это надо смотреть и перепроверять

Был бы счастлив, если бы у Вас нашлось время на это. (но его, наверное, нет).

Эффектов, которые я не понимаю, действительно много.
Вот даже сравнение
rep:16m+xtor:3:1m:h128k
и
rep:16m+xtor:3:1m:h256k

- на маленьком объеме данных (до 700 МБ) вариант с хеш-таблицей 256k сжимает предсказуемо сильнее и дольше.
- на больших объемах (свыше 700 МБ) начинают твориться чудеса. На одном и том же компьютере, но на разных данных у меня случалось: сжимали одинаково, но h256k на 5% дольше. В другом случае время одинаково, но h256k сжал заметно сильнее. И были случаи, когда xtor:3 сжимал медленнее (и хуже) чем xtor:5.

Цитата:

в перспективе сделать сей процесс со SREP "базонезависимым" чтоль, даже не знаю как выразиться

а я знаю - встроить его в arc.exe и в sfx-модули (можно не во все, а только в самые "умные").

1.
Имею папку на 30 файлов весом на 8 гигов (5 из них 0,9…1,2 гига, остальные - мелкие).
Требуется максимальное асинхронное сжатие (-m9x) с применением srep (как раз оценю для себя его эффективность).
Пока что комманда имеет вид:
  arc.exe a "f:\P1LIC.arc" <путь_папки> -m9x -i2 -lc- -ld- -di
Чем нужно дополнить для srep максимальной эффективности?

2.
И ещё, совет-пожелание: пожалуйста, НЕ нужно жать sfx-модули upx-ом (или чем там ты их жмёшь), ибо это жутко вешает мне систему (антивирь сканит и вешает). От подобной идеи жать модули уже в своё время отказались разрабы RAR и 7Z. Да и ложные срабатывания тоже встречаются, нехорошо. Всё равно же при мизерном весе этих sfx-ов выигрыш ничтожен, а потеря времени огромна.

з.ы.
Оба мои вопроса (про разницу и х64) всё ещё актуальны.

Цитата:

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

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


Цитата:

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

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

вот ещё результаты тестов:

I:\>arc a a -mrep:64m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,520,453,511 bytes. Ratio 77.6%
Compression time: cpu 16.49 secs, real 14.17 secs. Speed 319,723 kB/s
I:\>arc create a -mrep:256m D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,325,476,638 bytes. Ratio 73.3%
Compression time: cpu 17.00 secs, real 14.39 secs. Speed 314,814 kB/s
I:\>arc create a -mrep:1g D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,046,406,590 bytes. Ratio 67.2%
Compression time: cpu 17.74 secs, real 15.35 secs. Speed 295,262 kB/s
I:\>arc create a -mrep:2040m -lc- -ld- D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 3,081,247,699 bytes. Ratio 68.0%
Compression time: cpu 19.75 secs, real 20.10 secs. Speed 225,402 kB/s

I:\>arc create a -mrep:1g:32 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 2,245,307,762 bytes. Ratio 49.5%
Compression time: cpu 42.49 secs, real 40.07 secs. Speed 113,072 kB/s

I:\>arc create a -mxtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,696,917,637 bytes. Ratio 37.4%
Compression time: cpu 56.35 secs, real 7.49 secs. Speed 604,833 kB/s
I:\>arc create a -mexe+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,627,609,136 bytes. Ratio 35.9%
Compression time: cpu 55.07 secs, real 7.96 secs. Speed 569,268 kB/s
I:\>arc create a -mrep:1g+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,283,372,701 bytes. Ratio 28.3%
Compression time: cpu 46.02 secs, real 16.62 secs. Speed 272,611 kB/s
I:\>arc create a -mrep:1g:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,221,256,024 bytes. Ratio 26.9%
Compression time: cpu 49.31 secs, real 23.43 secs. Speed 193,409 kB/s
I:\>arc create a -mrep:1g:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,151,854,135 bytes. Ratio 25.4%
Compression time: cpu 64.23 secs, real 40.51 secs. Speed 111,850 kB/s
I:\>arc create a -mrep:1g:d1m:s32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,184,277,470 bytes. Ratio 26.1%
Compression time: cpu 74.40 secs, real 49.73 secs. Speed 91,108 kB/s

I:\>timer exdupe D:\Testing\dll4g.dll a
COMPRESSED 4,531,060,447 bytes in 1 file(s) into 1,861,014,750 bytes
Kernel Time = 1.934 = 00:00:01.934 = 19%
User Time = 50.497 = 00:00:50.497 = 505%
Process Time = 52.431 = 00:00:52.431 = 525%
Global Time = 9.984 = 00:00:09.984 = 100%
I:\>arc create a -mxtor:3 a
Compressed 1 file, 1,861,014,750 => 1,665,934,654 bytes. Ratio 89.5%
Compression time: cpu 37.75 secs, real 5.03 secs. Speed 369,888 kB/s

I:\>arc create a -mrep:512m+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,309,468,532 bytes. Ratio 28.8%
Compression time: cpu 46.43 secs, real 16.13 secs. Speed 280,945 kB/s
I:\>arc create a -mrep:512m:128+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,249,238,776 bytes. Ratio 27.5%
Compression time: cpu 49.17 secs, real 23.01 secs. Speed 196,931 kB/s
I:\>arc create a -mrep:512m:32+xtor:3 D:\Testing\dll4g.dll
Compressed 1 file, 4,531,060,447 => 1,181,619,756 bytes. Ratio 26.0%
Compression time: cpu 63.34 secs, real 39.06 secs. Speed 115,996 kB/s

в общем, надо
1. сделать rep многопоточным
2. в идеале - найти способ реализовать rep:32 таким же быстрым, как rep:512
3. опционально - интегрировать его в tor:3 (в основном это имеет смысл если удастся сделать быстрый rep:32)
4. добавить в tor:3 пропуск несжимаемых данных

У МЕНЯ КО ВСЕМ СОВЕТ-ПОЖЕЛАНИЕ - НЕ РЕДАКТИРУЙТЕ СТАРЫЕ ПОСТЫ ДЛЯ ДОБАВЛЕНИЯ НОВОГО СОДЕРЖАНИЯ. ПРОСТО НАПИШИТЕ НОВЫЙ ПОСТ - МНЕ ТАК БУДЕТ УДОБНЕЙ


Цитата:

сейчас freearc по команде lt/ArcInfo выводит для собственных архивов следующую информацию:

сделал и для .7z:

Код: C:\>Arc.exe lt a.7z
...

Compression memory: 35 mb
Decompression memory: 18 mb
Dictionary: PPMD:16mb LZMA:3mb BZip2:900kb Deflate:32kb

Pos Size Compressed Files Method
-----------------------------------------------------------------------------
0 7,257,513 7,349,363 1 LZMA:3m:lp2
0 51 56 1 Deflate
0 42 78 1 BZip2
0 3,981,824 976,075 1 BCJ PPMD:o6:mem3m
0 4,724,224 1,183,064 1 BCJ PPMD:o6:mem24
-----------------------------------------------------------------------------
5 files, 15,963,654 bytes, 9,508,636 compressed

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

в морг.

Не айс.

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

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

using 4x4:tor:3:2mb:h256kb
Compressed 361 files, 430,097,775 => 299,114,442 bytes. Ratio 69.5%
Compression time: cpu 18.50 secs, real 5.01 secs. Speed 85,877 kB/s

rep:16mb+4x4:tor:3:1mb
Compressed 361 files, 430,097,775 => 281,437,322 bytes. Ratio 65.4%
Compression time: cpu 17.64 secs, real 5.19 secs. Speed 82,866 kB/s


Добавлено:
using 4x4:tor:3:2mb:h256kb
Compressed 2,905 files, 236,542,287 => 186,087,534 bytes. Ratio 78.6%
Compression time: cpu 10.14 secs, real 3.23 secs. Speed 73,138 kB/s

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

Может я чего не учитываю, но разница по времени мала, а сжатие заметно.

Добавлено:
В своих тестах я эффекта от rep:32 не заметил

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

rep:16mb:32+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,205,644 bytes. Ratio 75.7%
Compression time: cpu 12.50 secs, real 5.83 secs. Speed 40,571 kB/s


Добавлено:
Разве что только на rep:256

rep:16mb+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,805,028 bytes. Ratio 76.0%
Compression time: cpu 10.62 secs, real 3.52 secs. Speed 67,215 kB/s

rep:16mb:256+4x4:tor:3:1mb
Compressed 2,905 files, 236,542,287 => 179,616,048 bytes. Ratio 75.9%
Compression time: cpu 11.19 secs, real 3.80 secs. Speed 62,244 kB/s

А меньше rep:256 скорее вред, чем польза.

Цитата:

прочтите наконец описание -lc/-ld

уже почитал-поглядел, разобрался. я ж ещё сразу тогда поблагодарил за помощь.

Цитата:

-mc:rep/srep:mem256mb - смотрится как раз в GUI версии. ставишь галочку и он наверху пишет комстроку

уже заметил, спасибо!

Цитата:

к концу этого года компилятор должен появиться

понял, буду ждать с нетерпением

Цитата:

в скорости. и x64-коде

то, что х32 и х64 - это ясно и так... а, вот, буковка "i" означает что? добавленое или, наоборот, облегчённое? просто, хочу выбрать наиболее функциональный вариант.

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

http://freearc.org/download/testing/fazip01.zip

FAZip is a standalone compression utility like gzip and bzip2.
It doesn't support any cmdline options but features the same great
compression power as FreeArc itself.


I don't recommend to use it for doing real compression due to it's
lack of CRC checking, file identification and other features common
for Unix compression tools. Consider it as technology demonstration
which may sometimes grow into really useful tool. Compression methods
supported and their parameters are exactly the same as in FreeArc
(so see FreeArc.htm for details). In paricular, it supports CLS external
compressors placed in cls-*.dll and accelerated compression functions
from facompress*.dll


Usage examples:

Fast binary data compression and decompression:
Код: fazip 4x4:tor:3 example.tar example.fazip
fazip d example.fazip example.tar

Цитата:

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

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


Цитата:

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

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

insorg
srep*i - как правило, самый быстрый


Цитата:

А с комментариями что не так? Поставил галочку написал комментарий и пустил на сжатие.

есть ещё удаление комментария из архива, установка комментария из файла. ещё полезно было бы добавить кнопки Load/Save для текста комментария


Цитата:

Все уже давно придумано в других прогах, может стоит просто их перенести в ФА?

в том-то и дело, что у fa есть свои уникальные возможности как ядра (скажем keyfiles для шифрования), так и GUI


Цитата:

А за шифрование я совсем вас не понимаю, что с ним не так? можете кратко объяснить.

там есть пароль и keyfile шифрования, алгоритм шифрования, и наконец пароли и keyfiles дешифрования


Цитата:

Блин все нет времени дорисовать другие вкладки. Если они вам еще нужны то на выходных я все сделаю

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

Прошу протестировать.
Я создал Яндекс.Диск,
в котором открыл (надеюсь, только для чтения) папку FreeArc.
http://yadi.sk/d/gytcnNw85PaCA
В ней лежат файлы arc.ini.
(с разными датами)
Открывается эта папка? Читаются файлы?

Bulat_Ziganshin
В чём отличае fazip.exe от arc.exe, для чего он нужен ?

Цитата:

srep*i - как правило, самый быстрый

и, как я понимаю, без "i" - самый эффективный по сжатию?

Shuld
да. да

ndch


Цитата:

1. freearc is an archiver while fazip is a compressor. for example, fazip can compress to nul or to stdout
2. fazip prints more stats using just one line - it's what i need for benchmarking

Первый пункт для меня более предпочтителен, ну и главное чтоб еще распаковывал в stdout.