» FreeArc (часть 4)

Benchmark
Пользуясь случаем, в продолжение оффтопа как бы, спрошу:
Сколько ж ядер на печатных машинках, что решает многопоточность ?
Есть ли возможность прикрутить LZHAM к 7-Zip—у ? (как Lzmh.dll когда-то)

Цитата:

Ну скажите на милость, почему все авторы считают, что нужно выбирать из "Скоростного", "нормального" и "ультара"?
Да пользователям до фонаря эти названия.
Пользователи были бы рады другому.
Если бы при сжатии конкретной папки (файла) архиватор бы выдал полоску сжатия типа:
+------------------------------------------+
| 1с 1м 1ч |
| ххххх|ххххххххххх |
| 1Гб 0,8Гб |
+------------------------------------------+
А пользователь бы установил требуемое (примерно) время сжатия.
И рядом кнопочка "дополнительно", где можно было бы указать, непрерывно или нет, ограничивать ОЗУ или нет, и т.п.
Сейчас ведь как бывает, установил пользователь сжатие "ультра", а архиватор - буду жать 1 час. И бедный пользователь отменяет, и по новой! Про спецов не говорю. Да и им разве менее удобно бы было?)

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

Действительно, бывает случаи, когда по дефолту ставишь ультра, а он пишет, что закончит часа через два. И приходится выходить и переставлять силу сжатия.
Хотелось бы, чтобы можно было поменять силу сжатия (даже, если придётся пережимать с нуля) в процессе (ну там окна всякие на "вы действительно хотите???").

И ещё, нужно делать юзерфрендли. 95% людей (в т.ч. я) не хочет разбираться в 100500 параметрах сжатия. Нужно, чтоб я только выбирал "ультра", а он сам догадывался каких файлов больше, и какие параметры применять. А то картинка сверху от vasulpr меня со своим delta lzma 192mb bt4 273 ... жутко пугает.

Цитата:

А то картинка сверху от vasulpr меня со своим delta lzma 192mb bt4 273 ... жутко пугает.

это просто параметр забыл вытереть. там стандартные настройки сжатия: ультра, высоко ..!

sabio
в случае ошибок сообщения о них выводятся под прогрессбаром

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

Цитата:

Есть ли возможность прикрутить LZHAM к 7-Zip—у ? (как Lzmh.dll когда-то)

он прикручен, взгляни на encode.ru/forum


Цитата:

Алгоритм, архитектурно упирающийся в 2 ядра - это тупик. Именно поэтому будущее за алгоритмами вроде LZHAM, а не за LZMA/LZMA2.

думаю что и к lzma это прикручивается, надо просто поработать. не удивлю.сь если игорь именно над этим корпит


Цитата:

супер-быстрый хэш: https://code.google.com/p/xxhash/

в srep гораздо быстрее

SunkaZlo

Цитата:

Действительно, бывает случаи, когда по дефолту ставишь ультра, а он пишет, что закончит часа через два
...
И ещё, нужно делать юзерфрендли. 95% людей (в т.ч. я) не хочет разбираться в 100500 параметрах сжатия.

Выходит, вы хотите, чтобы программа несколько раз анализировала возможное время сжатия разными методами. Но ведь программа пишет время окончания "только" после анализа файлов и "только" после начала упаковки. Тестовый запуск сжатия игры/файлов/документов на 4 ядерном процессоре 2,67 ГГц тратит порядка 20 секунд на каждых 10,000 файлов только для анализа, так сказать "что будем сжимать".
После анализа файлы начинают сжиматься выбраным методом (см.ниже)и имеем предположительное время, фиксируем его. Теперь прерываем сжатие, удаляем временные файлы.
Дальше - вы хотите видеть возможную степень сжатия. Как ее узнать? Наверное вы хотели бы, чтобы программа сама выбрала несколько файлов, да еще и разного типа, и попыталась их сжать? То-есть снова запускаем анализ содержимого этих "контрольных" файлов и приступаем к сжатию.
А как сжимать? вы же не хотите разбираться в 100500 параметрах?
Тогда программе нужно уметь самой выбрать нужный алгоритм. И самое простое это запустить брутефорс. Алгоритмов сжатия много (встроенные + внешние из комплекта Powerpack) и каждый имеет свои опции. Тот же lzma - у него 8 параметров, и различные их комбинации могут дать на выходе различную степень сжатия.
Выбираем самый быстрый режим, ждем завершения упаковки и апроксимируем результаты на все колличество файлов. Дальше меняем опции и параметры некоторых методов, меняем режимы и снова переходим к сжатию...

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

Bulat_Ziganshin

Возможно некоторые строки поменять местами,
А также добавить под кнопкой "+" раздел типа "Estimated end of Operation" где вычислялось бы примерное время окончания, путем суммирования текущего системного времени и остатка времени операции.

Цитата:

он прикручен

x86

Pedro2007
и тебе спасибо, что редактируешь сообщения

вообще стандартный путь для нового пользователя - сначала решить что программа не работает вообще, затем найти что у неё какая-то частная проблема, с которой он тем не менее столкнулся с первого раза. на заметку - ещё 7-zip корректно с длинными именами работает

вообще прикрутить хотя бы сообщение о слишком длинном имени файла - хорошая идея

вообще из предложенного мне понравились идеи:
1. при выборе метода сжатия сразу писать прогнозируемое время
2. экспорт настроек операции в .bat

Bulat_Ziganshin

Цитата:

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

мне он нравится тем, что лучше пакует мои данные чем тот же rar или 7-zip для моего домашнего архива - кратковременного. (для длительного хранения я использую zip и только его). Но, извините, для каждодневного использования я выбираю winrar для того, чтобы архивировать данные в rar или zip и отправить их по почте.

Bulat_Ziganshin

Цитата:

2. экспорт настроек операции в .bat

Спасибо, что обратили внимание на это. Я думаю что это многим полезно будет.
Булат, подумайте пожалуйста над оформлением, мне кажется, что простота на первых парах - спасет мир. Упомяну еще раз перечень софта, на который бы я обратил внимание в плане простоты и в то же время удобства в дизайне - это TrueCrypt, InsidePro.PasswordsPro, PSI+. Там масса настроек, которые вполне себе уживаются как для новичков, так и для продвинутых пользователей.
Хотел бы спросить - какие есть еще варианты по реализации информации для восстановления? В плане, у РАРа сделано на ХОRе, а как можно это все дело улучшить в ARCe?

Цитата:

x86

а чего тут плохого? не линукс, забивающий лишнюю память 64 битный виндовс 32 битку прекрасно крутит. или про ARM горе?

Цитата:

x86

ну возьми исходники и откомпиляй под 64. или автора попроси

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

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

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

Добавлено:

Цитата:

Я думаю что это многим полезно будет.

да, идея оригинальная и к тому же легко реализуемая - на самом деле и сейчас можно вытаскивать комстроку из логфайла

а как конкретно лучше сделать - добавить в диалог кнопку "save as...", или сделать её одной из командных кнопок (как ok/cancel), или сделать где-то список УЖЕ ВЫПОЛНЕННЫХ команд, из которого можно сохранять?


Цитата:

Булат, подумайте пожалуйста над оформлением

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


Цитата:

какие есть еще варианты по реализации информации для восстановления?

исходники par2-based утилит. поищите выше

Цитата:

говоря кратко, есть предложение включить cls-precomp.dll и cls-srep.dll в комплект программы, и сделать в ней поддержку гибридных кодеков (например в данном случае CLS должен обеспечивать только распаковку, а упаковка - внешними прогами), что позволит ускорить распаковку стандартного набора precomp+srep+lzma и не создавать при этом монстроидальные временные файлы. короче, как это уже делается в инсталяторах. что скажете?

Вообще идея хороша, но зачем srep? Ведь есть метод распаковки stdin stdout, который по сути не отличается от того же фильтра. Ну и насколько я помню была обещана поддержка srep как внутреннего алгоритма, вместо rep. Вот прекомп конечно бы неплохо было добавить. Так же как и сжатие PCM аудио алгоритмами frog и tak, как это сделано в msc у профрагера (распаковка так же идет с cls фильтром).

Bulat_Ziganshin

Цитата:

а как конкретно лучше сделать - добавить в диалог кнопку "save as...", или сделать её одной из командных кнопок (как ok/cancel), или сделать где-то список УЖЕ ВЫПОЛНЕННЫХ команд, из которого можно сохранять?

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

Цитата:

я со своей стороны смотрю и вижу только предложение вынести шифрование в отдельный таб

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

Цитата:

я именно от вас жду обсуждения оформления

Мне кажется, что для начала можно в шапке и на сайте повесить "Объявление" о том, что проводится конкурс иконок для новой версии, и отобрать их. Можно попросить инвайт или написать в песочницу Хабра об ARC, там любят опенсорс и там же тоже написать об вопросах юзабилити и иконок, т.к. дизайнеров полно, и наверняка найдутся те, кто готовы внести свой вклад в сообщество опенсорс, тем более отечественного коллеги по коду.

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

snkreg

Цитата:

Хотел бы спросить - какие есть еще варианты по реализации информации для восстановления?

RSC32 например.
http://forum.ru-board.com/topic.cgi?forum=5&topic=24050&glp

Цитата:

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

v8 - http://freearc.org/download/testing/progress/FreeArc8.exe:

Вопрос по методам -mx и -mex9. Если я правильно понял, то это одинаковые методы сжатия, с той лишь разницей, что -mx это двухпоточное сжатие, а -mex9 это многопоточное (например 4 как у меня). Так ли это?

Andrey_Verkhoglyadov

Цитата:

Вы можете сделать это опционально (платно) или не сделать вообще.

Убейся уже, пожалуйста, об стену.

Bulat_Ziganshin

Цитата:

v8

Отлично выглядит!
Строка "Files Bytes Compressed Time" очень упрощает восприятие - взгляд сразу выхватывает нужное.

Paramon111
у них общий базовый алгоритм, но -mex9 бьёт данные на блоки, которые сжимаются независимо, поэтому сжатие хуже -mx9


Цитата:

RSC32 например.

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


Цитата:

проводится конкурс иконок для новой версии

конкурс уже был. а вот поддержки иконок в fa до сих пор нет


Цитата:

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

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

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 ГБ очень немного.

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

Вопрос назрел по причине весьма интересной формулировки справки по FreeArc касательно количества используемой памяти. Что интересно, конкретного ответа на мой вопрос в справке я не нашёл, а тема использования памяти описывается весьма условно.

Читаем в справке:
Цитата:

Максимальное сжатие
  –m9x – самое мощное асимметричное сжатие, доступное при вашем объёме памяти. При распаковке будет использоваться в 8 раз меньше памяти, и она будет идти гораздо быстрее, чем упаковка. Этот режим сжатия удобен для создания дистрибутивов и т.п.

(интересующий момент выделен цветом).

А теперь рассуждаем логически.
1. Имеем х64 ОС с 12 ГБ оперативки.
2. Поскольку исполнялка - 32-битная, следовательно, на неё может быть выделено не более двух гигов оперативы (определено опытным путём). Отсюда, верхняя планка памяти для упаковки стремится к 2048 МБ.
3. Если сказано, что на архив (8 гигов инфы, создан по методу "-m9x") при распаковке будет использовано в 8 раз меньше памяти, получаем, что нужно будет 2048МБ/8=256МБ.

Теперь же, собственно, вопросы:

1. Действительно ли размер словаря составит тоже 256 МБ? (столько же, как видим, потребуется для распаковки)

2. Хватит ли для распаковки такого архива 512 МБайт оперативы? (т.е., часть скушает ОСька, и где-то около 300 свободно, как раз хватить должно, но мало ли...)

з.ы.
Если я где-то что-то упустил или допустил ошибку - прошу поправить.

insorg
есть три метода сжатия:
-mx, он же -m9
-m9x, он же -mx9
-mex9

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

-m9 - симметричный, т.е. памяти при распаковке и упаковке нужно одинаково

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

если вас интересует именно последнее, то используйте -m9x -md256m - и вам будет гарантировано, что при распаковке нужно будет не больше 256мб памяти

Bulat_Ziganshin
1) Почему бы не пересунуть "Ratio" под столбик "Compressed" для наглядности? Юзер будет видеть примерный ~размер архива (после сжатия) и сразу понимать при какой степени сжатия, (Текст "Ratio" выравнять по первой букве с "Compressed")
2) также для Скорости сжатия нужно сделать подпись, что это "Скорость",
"Скорость" (сам текст) подсунуть под столбик "Files" (выравнять по последней букве)
3) неплохо выглядит также линия, которая отделяет зону диалога прогресса "Files Bytes Compressed Time"
а также спасает от неразберихи оригинального v8: - сверху столбика текст "Bytes", но числа почему-то внизу в "kB/s", но строка начинается "Ratio", со временем можно привыкнуть и понимать что к чему, но когда когда есть линия текст после линии уже читается не так сложно.
Вариант 1:


Вариант 2 без линии:

Bulat_Ziganshin
Немного не так.
Меня интересует самый-самый мощный алгоритм сжатия (без внешних упаковщиков), который не потребует столько памяти при распаковке, сколько нужно было для упаковки.
Как я понимял, асинхронка "-m9x" - это и есть что нужно.
Вопрос в том, какой максимум памяти он может потребовать на больших обьёмах инфы (напр., 8 гигов при 20…16000 файлов).

Цитата:

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

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

Bulat_Ziganshin
Реально ли сделать чтобы метод -mx использовал больше 2-х потоков? Тогда и -mex9 будет не нужен ))

Цитата:

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

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


Цитата:

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

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