» FreeArc (часть 4)

Bulat_Ziganshin

Цитата:

напомнило мне один из розыгрышей Стива Возняка

А что такое, всё плохо?

Цитата:

мне кажется что в процессе архивации сотые интересны только конченым гикам.

А мне кажется что гики тоже люди. А для не совсем конченных гиков, можно и десятые доли выводить.
Фриарк, ведь, для таких маньяков/гиков и разрабатывался, да и кто, если не ты, Булат, что-то сделает для гиков?
Тем более что:

Цитата:

а зачем нормальному пользователю использовать freearc, а не rar/zip?

Engaged Clown
Стив сделал псевдо-рекламу компьютеров, где они сравнивались по фейковым параметрам. так и здесь - про 16-битные коды рида-соломона в par2/iceecc и сущестоввание более надёжных 32-битных кодов я слышал только здесь


Цитата:

Реально ли сделать чтобы метод -mx использовал больше 2-х потоков?

конечно, мы здесь все идиоты, ты один такой умный

insorg
-lc/-ld

Bulat_Ziganshin
Разобрался. Все дело в lzma.

WildGoblin
пожалуйста -
Bulat_Ziganshin

Цитата:

v8

красивое решение.

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-поточных методов, включая Ультра

Bulat_Ziganshin
ещё одна вариация с отступлением от "классических канонов" - (v9)

..............Files .... Compressed ........ Bytes ...... Time
Processed ....... 8 ..... 6,229,876 ... 16,188,368 ... 0:00:02
Total .......... 35 .. ~ 51,893,133 .. 134,844,601 . ~ 0:00:17
.............................. | ...... | .. | ............ |
.............................. +- 38 % -+ .. +- 7,970 kB/s -+
................................ Ratio .......... Speed

не совсем логично получается, что Compressed и Bytes переставлены местами
зато Ratio и Speed очень наглядны, кмк

более логичный, но и более громоздкий вариант - (v10)

..............Files ........ Bytes .... Compressed ...... Time
Processed ....... 8 ... 16,188,368 ..... 6,229,876 ... 0:00:02
Total .......... 35 .. 134,844,601 .. ~ 51,893,133 . ~ 0:00:17
.............................. | ............ | ........... |
..................... Ratio .. +---- 38 % ----+ ........... |
..................... Speed .. +--------- 7,970 kB/s -------+

Bulat_Ziganshin
И снова не поняли друг друга.
Мне упаковку принудительно ограничивать по памяти не нужно.
Мне интересно:
Какое наибольшее количество памяти может потребоватся для распаковки архива с "-m9x", если НЕ ограничивать? (хотя бы приблизительно)

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

все варианты на одной странице со ссылками на загрузку соответствующих freearc.exe: http://freearc.org/download/testing/progress/

insorg
-m9x -lc- -ld- -di напечатает макс. необходимую память для упаковки и распаковки

Цитата:

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

Спасибо.

ruduk
подретушировал твои варианты и добавил их как v11 и v12 на http://freearc.org/download/testing/progress/



Добавлено:
вариация v8, выводящая Speed справа:

v13 - http://freearc.org/download/testing/progress/FreeArc13.exe :

Цитата:

3. в поле Словарь писать все алгоритмы, найденные в архиве, с их максимальными словарями, переведёнными в байты, например: "LZMA:512mb LZMA2:256mb PPMD:48mb BZip2:900kb", таким образом это заодно станет и описанием алгоритмов, использованных в архиве
 
Кроме того, последний пункт я думаю распространить и на описание архивов freearc, скажем там может появиться "rep:512mb+lzma:64mb ppmd:384mb grzip:8mb"

не дождавшись критики и предложений, сделал для freearc так:

Dictionary: dict:93kb+lzp:93kb+ppmd:384mb rep:10mb+lzma:10mb grzip:728kb
Dictionary: rep:96mb+xtor:16mb rep:30mb+xlzma:16mb grzip:8mb
Dictionary: rep:512mb+xlzma:16mb dict:34mb+lzp:34mb+xppmd:384mb grzip:197kb

сделал вот картинки
v9


v10

Bulat_Ziganshin
Cегодня обновился до февральской версии, заметил новую (для меня, по крайней мере) утильку SREP (аж 3.01 версии).
Как её можно эффективно использовать?

Shuld

Цитата:

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

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

Цитата:

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

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

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

sabio
спасибо, добавил на http://freearc.org/download/testing/progress/

Добавлено:
v14:

insorg
поставить галочку в настройке метода сжатия. только учти - она и при распаковке нужна будет. помогает при сжатии, если у тебя 1 гб и более данных

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

Another proposal for idea from v9+v10 in text:

..............Files......Time............Bytes.... .Compressed..
Processed ........8.....0:00:02.......16,188,368.....6,229,876..
Total ...........35...~ 0:00:17......134,844,601..~ 51,893,133..
..........................|..............|....|... ....|........
..........................+- 7,970 kB/s -+....+- 38 % -+........
...............................Speed .......... Ratio...........

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

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

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

Всё это субъективно, но мне больше всего нравятся v13 (или v12)

Цитата:

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

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

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


Цитата:

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

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

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

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

v15 - http://freearc.org/download/testing/progress/FreeArc15.exe :



это v11 с Ratio и Speed в обратном порядке. я думаю что мне надо центрировать Speed/Ratio в последней строке, отказавшись от какого-либо выравнивания с числами над разделителем. и возможно добавить ETA (время завершения операции) в самом конце - это очень удобно для длительных операций

Добавлено на http://freearc.org/download/testing/progress/

ruduk

Цитата:

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

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

Bulat_Ziganshin
v14 как-то больше нравится, всё просто и понятно

Bulat_Ziganshin

Цитата:

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

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

Имхо, самым компактным и удобным вариантом было бы нечто такого типа:

Proceeded:                 58%
Files:               2823/5447
Bytes:       24984984/52046849
Compressed:    4984984/2046849
Ratio:                     72%
Time:        01:02:03/20:22:24

На первом месте - процент обработанного, далее - количество файлов (сделано/всё) и аналогично байты общие и обработанные, после этого логичнее всего показывать процент сжатия, и в конце - время по схеме [прошло/общее] или [прошло/осталось].

Как вариант, можно время разделить:

Обработано: 58%
Файлы: 2823/5447
Всего байт: 24984984/2046849
Сжатых байт: 4984984/2046849
Степень сжатия: 72%
Прошло: 01:02:03
Осталось: 20:22:24

Или даже так...

Proceeded:                 58%    Time:        01:02:03/20:22:24    
Files:               2823/5447    Ratio:                     72%    
Bytes:       24984984/52046849    Compressed:    4984984/2046849    


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