» WinRAR (часть 2)

oshizelly
Цитата:

В продолжение обсуждения возникла такая мысль: а является ли сегодняшнее поведение программы в этом отношении логичным?

Является.

Цитата:

Видимо, речь про накопительные архивы: изменения пакуем и восстанавливаем по ним точную копию исходной директории. Но конкретно для этого, насколько я помню, в RAR/WinRAR есть достаточно мощные встроенные средства.

Не.
Ещё раз посмотри внимательно постановку задачи, есть каталог в нём 10000 файлов.
Паковать надо 300 из них, зачем в данном случае время в каталоге?
К чему оно там относится?
Надо время пакуй весь каталог.
Да и вообще опираться на время каталога, зачем? Фиг его знает когда и кем оно там поменялось. Всё равно надо смотреть на файлы..

DVall 19:59 21-11-2014
Цитата:

есть каталог в нём 10000 файлов. Паковать надо 300 из них, зачем в данном случае время в каталоге? К чему оно там относится? Да и вообще опираться на время каталога, зачем? Фиг его знает когда и кем оно там поменялось.

Я ведь объяснил уже чёрным по-русскому: мне нужно при упаковке сохранять время модификации каталога, чтобы оно восстанавливалось при распаковке. Потому что время модификации каталога часто является значимым. Например на разделах NTFS этот параметр показывает, когда в последний раз менялось содержимое каталога.


Цитата:

Надо время пакуй весь каталог.

Зачем? Мне не нужен весь каталог, а нужны, допустим, только 300 файлов в этом каталоге из 10 000.

Вообще, у меня такое впечатление, что все мои уважаемые оппоненты упускают из виду одну совершенно очевидную вещь: целостное резервное копирование данных не является ни единственным, ни даже основным назначением WinRar. А вы почему-то всё время смотрите именно с точки зрения бэкапа.

EugeneRoshal
Евгений, а вы не подскажите при шифровании Winrar 5 - AES-256 работает в каком режиме - как блочный шифр (CBC) или как поточный (CTR - например)?

lelik007
CBC.

Что-то на бете 4 (текущей) перестали распаковываться архивы на сетевых дисках - открывается, но при попытке извлечь 1) вылезает незваный ЮАК 2) и сообщение, что архивы не обнаружены. С тем же файлом, перетащенным на локальный диск, ведет себя адекватно (Вин 7х64, winrar-x64-520b4ru). Т.е. трабл не в конкретных архивах.

WWN
То что архивы не обнаружены, это, видимо, сетевой диск назначен на букву под текущим пользователем, но не под администратором. Windows в такой ситуации тоже не может скопировать файл с UAC. Но почему WinRAR определяет, что в этой ситуации требуется UAC, я не знаю. Сейчас проверял на сетевых дисках, нет UAC.

Я сейчас добавил проверку на тип диска и вывожу UAC диалог только для локальных жестких дисков. Я перевыложил английскую бету 4 на www.rarlab.com. Посмотрите, пожалуйста, исчезла ли у вас эта проблема.

EugeneRoshal
предлагаю выпилить архивацию в формат 4.xx (оставить только поддержку, чтобы можно было распаковать любой архив созданный в rar 4.xx), притом что rar5 сжимает лучше!

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

будет ли это реализовано?

brduakh

Цитата:

предлагаю выпилить архивацию в формат 4.xx (оставить только поддержку, чтобы можно было распаковать любой архив созданный в rar 4.xx), притом что rar5 сжимает лучше!

1) А кто профинансирует переделку всего использующего формат RAR 2.90 и механизмы компрессии данных RAR4 и более старых версий ПО?
2) А кто профинансирует восстановление работоспособности технологических цепочек в промышленности после реализации данной затеи?
3) А откуда возьмутся деньги на финансирование пунктов 1) и 2)?

Казна их не даст ибо у неё своих проблем хватит, банки - "Любой каприз за ваши деньги!". Промышленность и государство не станут оплачивать внедрение новых технологий без особо веских на то причин, а промышленность ещё и переложит всю себестоимость этих работ на потребителя - кто же из купцов или промышленников поступится прибылью ради реализации сомнительной с их точки зрения идеи?

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

Посему - "В морг!"©zg

Почему не предложил выпилить zip-архивацию, ума не приложу?

brduakh

Цитата:

притом что rar5 сжимает лучше!

Не только сжимает лучше, но и распаковывает зачастую быстрее. И создавался без оглядки на MS DOS, а с учетом Unicode и Unix времен файлов. И recovery record эффективнее, и quick open record присутствует. Но Victor_VG прав, и дело не в пользователях, которые сидят на WinRAR 4.x. Им-то есть куда перейти. Дело в пользователях других архиваторов, например, 7-Zip, где поддержка RAR 5.x отсутствует.

Цитата:

будет ли это реализовано?

Вероятно, будет, но через какое-то время. Год, два, сейчас точно не скажу.

brduakh

Цитата:

предлагаю выпилить архивацию в формат 4.xx (оставить только поддержку, чтобы можно было распаковать любой архив созданный в rar 4.xx), притом что rar5 сжимает лучше!

EugeneRoshal

Цитата:

Вероятно, будет, но через какое-то время. Год, два, сейчас точно не скажу.

Не надо ничего выпиливать! Не все файлы 5-ка жмет лучше и быстрее 4-ки.

Например, многогигабайтные данные в CSV формате типа таких:

Цитата:

Time,Ask,Bid,AskVolume,BidVolume
2003.08.04 10:00:05.092,2.1951,2.1947,2.4,2.4
2003.08.04 10:00:09.051,2.19507,2.19477,2.8,4.8
2003.08.04 10:00:10.840,2.19512,2.19468,8.3,2.4
2003.08.04 10:00:20.613,2.19512,2.19468,5.2,4

Это тиковые данные котировок Forex, каждый файл весит около 10 гигабайт на данный момент.
Версия 4.2 или 5.11 с включенной опцией "Text compression" (остальные Audio/TrueColor/EXE не влияют никак... и Delta тоже вроде) жмет такие файлы нааамного быстрее и сильнее, чем 5.11 в формат 5-ки и даже 7-zip 9.2 в LZMA 2: словарь 32-128 Мб, размер слова 256 и размер солид блока в 4 Гб!
Проверено на х64 версиях всех этих архиваторов на реальной машине (Core 2 Quad) и VPS (х86). Чего я только не вертел в параметрах архивации у 5.11 и 7-zip. Жмут они сильно дольше, потребляют немало памяти, а сжатие - хуже.


Добавлено:
А тем, кому как-то мешает формат 4-ки могу посоветовать зайти в Настройки -> Сжатие -> Профиль по умолчанию (или как там, в русской версии эта кнопка называется) и выставить что душе угодно

timsky

Цитата:

Версия 4.2 или 5.11 с включенной опцией "Text compression" (остальные Audio/TrueColor/EXE не влияют никак... и Delta тоже вроде) жмет такие файлы нааамного быстрее и сильнее, чем 5.11 в формат 5-ки

Сильнее - да, насчет намного быстрее - сомневаюсь. Разве что если вы указали такой размер словаря, что физической памяти не хватило и пришлось использовать своп. Можете интереса ради измерить скорость упаковки с text compression и без нее со словарем не очень большого размера. А потом еще скорость распаковки сравнить. Или тестирования - та же распаковка, только в память, чтобы исключить влияние диска и дискового кэша. Не удивлюсь, если скорость распаковки rar5 окажется раз эдак в 15 - 20 выше.

Цитата:

А тем, кому как-то мешает формат 4-ки могу посоветовать зайти в Настройки -> Сжатие -> Профиль по умолчанию (или как там, в русской версии эта кнопка называется) и выставить что душе угодно

А соглашусь.

Через год-два достаточно будет сделать RAR5 форматом по умолчанию. Выпиливать в самом деле ничего не нужно. Иногда до сих пор возникает необходимость в создании rar-архивов, которые можно было бы распаковать даже под Win9x или DOS.

timsky

Цитата:

Чего я только не вертел в параметрах архивации у 5.11 и 7-zip. Жмут они сильно дольше, потребляют немало памяти, а сжатие - хуже.

Формат PPMD в 7-zip пробовали? На текстовых файлах намного быстрее и эффективнее, чем LZMA/LZMA2.

EugeneRoshal

Цитата:

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

Насчет СВОПа я в курсе и жал таким словарем, чтобы этого не было. Сейчас специально прогоню несколько тестов на 10,3Гб файле и выложу результаты здесь.

Abs62

Цитата:

Формат PPMD в 7-zip пробовали? На текстовых файлах намного быстрее и эффективнее, чем LZMA/LZMA2.

Вот им сейчас и жмется для пробы в 7z 9.22 x64 с макс. настройками.

Чуть позже выложу результаты.

Добавлено:
Файл тиковых котировок c dukascopy.com по паре GBPJPY с 2003.08.03 по 2014.10.31, без выходных флэтов (w/o weekend flats) размером 10.3 Гб (11 146 324 966 байт)
Все тесты проводились на отдельном жестком диске (Maxtor 160Gb SATA), к которому не было обращений ни одной программы кроме самих архиваторов.
Проц.: Core2 Quad Q6600 (2.4GHz) в безопасном разгоне по шине до 3.2GHz (8*400)
Память: DDR2 Transcend 800MHz

WinRar 5.11 x64
Режим RAR 4, сжатие - Best, словарь - 4Mb
Скриншоты параметров: и
Время архивации 1446 сек!
Потребление RAM - ~145 Мб
Загрузка CPU - 25-30% (одно ядро)
Размер архива: 1,16 GB (1 248 800 687 bytes)
Сжатие: 11%!
Комфорт: Параллельно серфил, смотрел Физрука

Тест: 20 мин. 2 сек. (1202 сек.)
Потребление RAM - ~60 Мб
Загрузка CPU - 25% ровно.


WinRar 5.11 x64
Режим RAR 5, сжатие - Best, словарь - 4Mb
Скриншоты параметров: и
Время архивации 2194 сек
Потребление RAM - ~105 Мб
Загрузка CPU - 90% +/- 3-5% (почти все ядра)
Размер архива: 1,62 GB (1 740 050 579 bytes)
Сжатие: 15%
Комфорт: Тут уже не до комфортного серфинга Онлайн Физрук (flash) жутко лагал, так что пришлось оставить комп в покое на время теста.

Тест: 41 сек.!
Потребление RAM - ~25 Мб
Загрузка CPU - 40% +/- 3-5%


7-zip 9.22 x64
Режим PPMD, сжатие - Ultra, словарь - 1024Mb
Скриншот параметров:
Время архивации 2761 сек
Потребление RAM - ~1024+ Мб
Загрузка CPU - 25% +/- чуть-чуть (одно ядро)
Размер архива: 1,45 GB (1 562 116 237 bytes)
Сжатие: 14%
Комфорт: Параллельно серфил, смотрел Физрука

Тест: WinRar и 7-Zip оценили время в ~53-54 мин. и ~ 1 час 10 мин. соответственно.
Потребление RAM - у обоих ~1055 Мб
Загрузка CPU - 33%% +/- 3-5% и 25% соответственно.

Окончания теста PPMD архива не стал ждать. Зачем?

ЗЫ:
После архивации в RAR 4, я файл архива переименовал, чтобы следующий тест не пытался обновить существующий архив.
Время архивации определяю вычитанием времени создания из времени последней модицикации файла.
Windows 7 x64 SP1 En со всеми апдейтами и свежими драйверами. Из софта установлены только KAV WKS и Office 2003 + несколько мелочей. Аналогичные результаты я получил в начале ноября на уже порядком загаженной винде. 17-го ноября я переустановил винду.

timsky, для полноты эксперимента не хватает теста распаковки.

timsky
У меня RAR5 при словаре разумного размера и пакует стабильно быстрее, чем текстовое сжатие RAR4. То ли у вас данные идеальные для PPMd, то ли "железо" влияет. Я тестировал на CPU поновее: i7-2600 и Q9550. Но в любом случае основной недостаток текстового сжатия в вашем тесте тоже никуда не делся. Сравните 20 минут распаковки для текстового сжатия и 40 секунд для обычного. 30-тикратная разница в скорости. Ждать 20 минут для распаковки файла в 10гб это сильно на любителя.

hooo
См. строки, начинающиеся с Тест:

EugeneRoshal

Цитата:

То ли у вас данные идеальные для PPMd, то ли "железо" влияет.

Ну еще аналогичный тест проводил на х86 XEN VDS c 512 Мб оперативы и 2x2.80GHz проце... Xeon поколения Core2, кажись... могу вечером скриншот CPU-Z сделать и бенчмарки погонять, если нужно.
Как раз PPMD (в 7-zip 9.2 и 9.22) на этих данных тоже спотыкается и никуда не годится. Вообще, заметил, любые котрировки Forex (даже минутки, которые весят ~250 Мб) жмутся именно 4-кой лучше всего, что по одиночке, что в один солид архив.


Цитата:

Сравните 20 минут распаковки для текстового сжатия и 40 секунд для обычного. 30-тикратная разница в скорости. Ждать 20 минут для распаковки файла в 10гб это сильно на любителя.

А ждать на 52% дольше, чтобы сжать файл и потратить заливку / скачивание на 40% больше трафика при том, что далеко не везде он бесплатный и достаточно шустрый...? А еще не надо забывать, что помимо значительно более долгой упаковки, этот процесс еще и занимает почти все ресурсы 4-ядерного процессора и намного больше оперативы, если словарь стоит от 32Мб и больше. Т.е. либо ждем вполовину дольше и не трогаем комп все это время, либо переводим процес архивации в фоновый и ждем еще дольше? Про энергопотребление тоже не стоит забывать...

В итоге, на аналогичном текстовом наборе данных (образец выше я давал) RAR 5 имеет только один аргумент ЗА - скорость распаковки, зато сразу несколько аргументов ПРОТИВ. Мне кажется, для архиватора, скорость упаковки и сила сжатия важнее.

В первый раз, в начале ноября я проверял далеко не на одном файле, как 8-10 Гб размеров, так и на кучках ~250 Мб файлов, по отдельности и в солид. Результаты отличались незначительно. Только 7z был 9.2, а сейчас 9.22 бета и WinRAR, возможно, был 5.1.

ЗЫ:
Дело, конечно, хоязйское, но формат RAR 4 для определенных задач (один яркий пример уже есть) на голову превосходит 5-ю версию со словарем от 32 до 128Мб (256Мб тоже вроде пробовал, толку от него почти 0). Все то же самое относится к LZMA 2 и PPMD.

timsky

Цитата:

Как раз PPMD (в 7-zip 9.2 и 9.22) на этих данных тоже спотыкается и никуда не годится.

В RAR4 в качестве текстового сжатия тоже используется PPMd.

Цитата:

А ждать на 52% дольше, чтобы сжать файл

Можете попробовать у RAR5 "Normal" вместо "Best". "Normal" запросто может оказаться в 2 - 3 раза быстрее при разнице в степени сжатия меньше 5%. "Best" далеко не всегда является оправданным выбором.

Цитата:

В итоге, на аналогичном текстовом наборе данных (образец выше я давал) RAR 5 имеет только один аргумент ЗА - скорость распаковки

Только вот разница катастрофическая для RAR4 по этому параметру, иначе 30-тикратное отставание в скорости и не назвать.

Цитата:

зато сразу несколько аргументов ПРОТИВ

Расход памяти RAR5 регулируется, скорость упаковки - тоже. У меня он стабильно пакует текст быстрее, чем RAR4. По крайней мере с "Normal" вместо "Best", да и с "Best" при небольших словарях тоже. Впрочем, похоже у вас данные - не просто текст, а максимально удобный для PPMd текст. Загрузку CPU, если она позволяет быстрее выполнить операцию, я за недостаток не считаю, но при необходимости и ее можно ограничить ценой скорости.

Если речь идет о дорогих и медленных каналах связи, тогда, конечно, важно сжатие любой ценой. Но RAR это архиватор общего назначения и его задача - сохранять баланс между скорость упаковки, распаковки, расходом памяти и степенью сжатия. 20-тиминутная распаковка 10гб приемлема для архиватора для спецзадач, но не для общего назначения.

Впрочем, упаковка в RAR4 в близком будущем из RAR не исчезнет, я об этом написал с самого начала.

EugeneRoshal


Цитата:

"Best" далеко не всегда является оправданным выбором.

Но если нужно запаковать с максимальным сжатием не считаясь со временем, то нужно использовать Best.
А скорость распаковки не зависит от выбора степени сжатия

Я правильно все понял?

Ar0ma

Цитата:

А скорость распаковки не зависит от выбора степени сжатия

Я правильно все понял?

Да. Разница в скорости распаковки RAR5 "Best" и "Normal" пренебрежимо мала.

timsky
дайте попробовать
Цитата:

которые весят ~250 Мб

EugeneRoshal
Сперва - RAR 5:

WinRar 5.11 x64
Режим RAR 5, сжатие - Normal, словарь - 4Mb
Время архивации 820 сек.
Размер архива: 1,62 GB (1 746 471 334 bytes)
Сжатие: 15%

Шустро

Режим RAR 5, сжатие - Good, словарь - 4Mb
Время архивации 1679 сек.
Размер архива: 1,62 GB (1 741 904 192 bytes)
Сжатие: 15%

Немного сильнее сжатие, но незначительно и ценой в +105% времени.

Режим RAR 5, сжатие - Normal, словарь - 256Mb
Время архивации 1799 сек.
Размер архива: 1,62 GB (1 752 610 404 bytes)
Сжатие: 15%

С 256Мб словарем сжал еще хуже, чем при 4-мегабайтном.

Теперь RAR 4:

Режим RAR 4, сжатие - Normal, словарь - 4Mb
Время архивации 663 сек.!
Размер архива: 1,1 GB (1 189 737 716 bytes)
Сжатие: 10%
Супер шустро! Причем, итоговый архив получился даже меньше, чем при сжатии Best.

Режим RAR 4, сжатие - Good, словарь - 4Mb
Время архивации 809 сек.
Размер архива: 1,07 GB (1 149 998 435 bytes)
Сжатие: 10%

По скорости примерно аналогичен режиму RAR 5 со сжатием Normal и словарем в 4Mb, но жмет на 5% сильнее.
А если смотреть с другого ракурса, то файл, выдаваемый RAR 5 / Normal / 4Mb на ~52% больше, чем RAR 4 / Good / 4Mb при сопоставимом времени сжатия.
Только RAR 5 все равно потребляет намного больше ресурсов процессора.

Добавлено:
Inoz2000

Цитата:

timsky
дайте попробовать
Цитата:
которые весят ~250 Мб

Поставлю на заливку на ночь....

timsky

Цитата:

С 256Мб словарем сжал еще хуже, чем при 4-мегабайтном.

Специфические данные. Мало длинных повторяющихся строк на больших расстояниях.

Цитата:

Режим RAR 4, сжатие - Normal, словарь - 4Mb
Время архивации 663 сек.!
Размер архива: 1,1 GB (1 189 737 716 bytes)
Сжатие: 10%
Супер шустро! Причем, итоговый архив получился даже меньше, чем при сжатии Best.

У вас текстовое сжатие установлено в Auto в "Advanced compression parameters". WinRAR 5.x в алгоритме RAR4 при этом использует на подходящих данных сжатие текста и в Normal, но снижает порядок модели PPM до 4 (для Best он равен 8, для Good - 6). Это повышает скорость, но для нормальных текстов ухудшает сжатие. В ваших данных длинные устойчивые контексты встречаются редко, поэтому предсказание вероятности по короткому контексту работает эффективнее. При желании можете сами поподбирать prediction order в advanced compression parameters.

Но каких-то глобальных выводов на основании этих данных я бы не делал. Это не классический текст и даже не классическая база данных. Длинные повторы редки, много коротких повторов. Для LZ это хуже, для PPM с коротким model order - хорошо, для PPM с длинным model order - не очень хорошо.

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

И, кстати, распаковка этого Normal + text compression все равно будет раз в 15 медленнее, чем RAR5. Ну хоть не в 30, и то ладно

timsky
У меня много разных тестов было.
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=800#16
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#15
Да, иногда формат RAR4 бывает лучше.
Но в основном - хуже.

Добавлено:
Мой опыт показывает, что не существует "оптимального" алгоритма или метода, который ВСЕГДА будет лучше.
Для разных конкретных данных оптимальными получаются различные методы и параметры.
И если Вы для своих данных подберете наилучший вариант, то это - самый правильный подход.

Inoz2000, минутки по 8 парам (по ~25Mb) под ковриком #

EugeneRoshal

Цитата:

WinRAR 5.x в алгоритме RAR4 при этом использует на подходящих данных сжатие текста и в Normal, но снижает порядок модели PPM до 4 (для Best он равен 8, для Good - 6). Это повышает скорость, но для нормальных текстов ухудшает сжатие. В ваших данных длинные устойчивые контексты встречаются редко, поэтому предсказание вероятности по короткому контексту работает эффективнее.

Спасибо за подробности, интересно

Цитата:

При желании можете сами поподбирать prediction order в advanced compression parameters.

Подбирал еще в начале месяца для RAR 4 и если не ошибаюсь, то ли эффекта не было, то ли AUTO Prediction order всегда давал лучший результат...
Я правильно понимаю, что если побаловаться с Prediction order и Compression method, то можно добиться более быстрой распаковки при оптимальном коэффициенте сжатия?

Цитата:

Но каких-то глобальных выводов на основании этих данных я бы не делал. Это не классический текст и даже не классическая база данных.

Это понятно. Но армия юзеров, оперирующих этими данными тоже не самая маленькая.

Shuld
Вижу твои тесты в той теме постоянно

timsky

Цитата:

Я правильно понимаю, что если побаловаться с Prediction order и Compression method, то можно добиться более быстрой распаковки при оптимальном коэффициенте сжатия?

Compression method влияет только на те данные, которые обрабатываются обычным алгоритмом. Если весь файл пакуется текстовым сжатием, подбирать имеет смысл prediction order. Меньшие значения дадут большую скорость упаковки и распаковки.

Скажите пожалуйста, планируется ли внедрить асимметричное шифрование архивов в winrar?

melboyscout

Цитата:

Скажите пожалуйста, планируется ли внедрить асимметричное шифрование архивов в winrar?

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

Шифровать ими данные напрямую во-первых очень неудобно, во-вторых очень медленно. Они просто не для этого.