» FreeArc (часть 4)

Парни ещё вопрос что нужно зделать в скрипте что бы Сначала Распаковывались файлы bin. а из них уже RAR-SREP-Arc и т.д мне главное что бы все архивы были в файлах bin вот скрипт попробуйте похимичить
http://rghost.ru/35642435

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

Быстрое сжатие больших объемов

«Философия»
Подход к линейке методов сжатия для архиваторов консервативен. Для FreeArca – это методы –m1, -m2, … , -m9 (-mex9). Хочешь быстро – используй –m1, хочешь сильно сжать – используй –m9 (-mex9). Но такая линейка «одномерна» и не очень хороша, поскольку учитывает размер файлов однобоко. Например, нет оптимального метода для «быстрого» сжатия большого объема. Конечно, можно воспользоваться –m1 (-m2), но результат будет далек от идеала. Причина – обработка больших массивов данных заложена только в «старших» (медленных) методах (большой rep). Я вижу выход в «двухмерном» подходе.

От слов к делу
Например, для быстрого сжатия больших объемов можно взять большой rep (от m8, mex8) и быстрый алгоритм (подобный –m2). Под «большими объемами» в таком случае будут пониматься данные размером примерно 1GB (и выше).
Я долго тестировал варианты и предлагаю два «оптимальных». Эти методы по «двухмерной» идеологии я назвал –m81 и –m82. Здесь 8 означает большой объем сжимаемых данных (8rep = rep:1gb), а цифры 1 и 2 – «скоростной» и «быстрый» метод. Деление файлов на группы отсутствует.

Вот результаты сравнения с методами –m2 и –mex8, отсортировано по увеличению реального времени работы:

Процессор i3-530, 2 ядерный, 4 поточный, Win7 32-разрядная, ОЗУ 4 ГБ
Консольная версия FreeArc 0.67 от 25 декабря 2011
Метод time: cpu time: real Размер архива Memory for compression Memory for decompression

AftarJjet
мдаааааа.... кому что... 666 - число Сатаны, а версия 0.666 и уже есть 0.67... нет никакого скрытого намека с мусульманством и христианством...
хотя ждем ответа от разработчика

AftarJjet

Shuld
тут есть тег "таблица" (после x2) - может переоформишь с ним?

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

Булат
1. Переоформил
2. Почему при Memory for compression более 1444mb из-под консоли методы сжатия работают без темп-файла, а под оболочкой (GUI) - с темп-файлом (во всяком случае время становится примерно в 2 раза больше)?

AftarJjet

Цитата:

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

Ты о чём? Вроде первое апреля давненько было или у тебя в часах-календаре двух камней не хватает? Дак ты попроси - аж с Тау Кита самые каменные пришлют.

А вообще-то поинтересуйся-ка ты той же Git/SVN/Subversion что сиё за зверь и с чем его едят и вопрос мигом испарится в сторону нетей.... Коминты и распишитесь - хотите придумывайте благозвучные "цыфыры" для версий, хотите нумеруйте версии по ревизиям сорцов, хотите очи к небу и высматривайте там знамения с "цыфырами" - тут каждый разработчик поступает как ему Бог на душу положит. А нечистую силу оставь в покое, а то ненарок накличешь дак спать своими воплями не даст - работа у неё такая...

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

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

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

Добавлено:

Цитата:

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

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

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


Цитата:

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

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


Цитата:

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

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

Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.

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

чем лучше FreeArc 7zip-a?

Что это значит?
Это же не ОЗУ, в чем разница?
(Все ОЗУ 2 ГБ, причем архиватор использует почти 1,5 ГБ)

Bulat_Ziganshin

Цитата:

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

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

Цитата:

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

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

Цитата:

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

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

Цитата:

Нет ли связи в связи с тем, что разработчик из мусульманской страны, и релизом 666? Нет ли тут скрытого намека всех христианским странам?

по такой логике, следующую версию надо назвать 0.69


Цитата:

чем лучше?

чем 7-zip!

Shuld

Цитата:

В методе –m1 по времени стоят вопросы из-за совсем странного (для меня) поведения. Если сжимаешь первый раз, то время 140 с. При повторных сжатиях – около 25 с.

Цитата:

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

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

Цитата:

чем лучше FreeArc 7zip-a?

http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#5

snkreg

Цитата:

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

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

Прочитал про ram-drive.
Во времена компьютера "Поиск" (ХТ) у меня был "электронный диск". Это оно и есть?

Но тогда такие эксперименты полностью "игнорируют" поведение реальных жестких дисков. Это хорошо для абстрактной скорости, но трудно соотнести с быстродействием "реального" компьютера (он неидеален, есть задержки времени на выполнение различных операций, таких как обращение к винту).
А у меня цель - получить оптимальное соотношение время / степень сжатия для реального компьютера.
Я не ставлю цели "максимальное быстродействие".

Вот, например, я вижу, что данные по затратам чисто процессорного времени имеют о-очень отдаленную связь с реальным временем. Поэтому я в будущем буду похоже процессорное время игнорировать.

redson 13:09 11-05-2013
Цитата:

чем лучше FreeArc 7zip-a?

Наличием человеческого GUI и фич, напрочь отсутствующих в 7-zip. Объясняется различиями в подходе у авторов - автора 7-zip кроме алгоритмов сжатия ничего не интересует, автор Freearc думает и об удобстве юзеров.

К сожалению, все плюсы Freearc перечеркиваются его слабой распространенностью.

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

Shuld

Цитата:

Но тогда такие эксперименты полностью "игнорируют" поведение реальных жестких дисков. Это хорошо для абстрактной скорости, но трудно соотнести с быстродействием "реального" компьютера

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

PS: Реальные условия это не только HDD \ SSD, но и объём RAM, + объём исходных данных, т.е. под всё не подстроиться, главное в тестах чтобы условия проведения были обинаковые: скорость диска, загруженность CPU, свободное кол-во RAM. Результаты на разных типах дисках (HDD \ SDD \ RAM-drive) важны например для алгоритма srep, особенно в метода m2, m3.

Поднимаю вопрос про cabal и спокойную сборку на linux

http://www.linux.org.ru/forum/general/7894692
http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=1620#3

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


Цитата:

RSC32 например.

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


Цитата:

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

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


Цитата:

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

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

после архивации ( вызов из контекстного меню - архивация с диалооговым окном), если в диалоге добавить галку на тестирование после архивации, то после архивации окно просто висит. По отдельности операции отрабатываются нормально.

эх добавили бы еще поддержку расширенных атрибутов NTFS

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

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

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

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

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

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

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

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

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

Bulat_Ziganshin
можно на офсайте повесить ожидаемую дату релиза?

Цитата:

главное в тестах чтобы условия проведения были обинаковые: скорость диска, загруженность CPU, свободное кол-во RAM

в этот список нужно обязательно добавить пункт "содержимое системного кэша".

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


Цитата:

такие эксперименты полностью "игнорируют" поведение реальных жестких дисков.

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

Bulat_Ziganshin
В самом деле, как в FA организован ввод-вывод? Он читает очередной байт (блок) как только он понадобится, и записывает очередной байт в архив как только он будет готов?

Цитата:

можно на офсайте повесить ожидаемую дату релиза?

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