» Архиваторы. Сравнение сжатия

Azrailll
я потестил v 0.93с FreeArc'ом - всё работает. Там же на Encode.ru есть код для вставки:


Код: [External compressor:zcm]
packcmd = zcm a -s -r {options} $$arcpackedfile$$.tmp $$arcdatafile$$.tmp
unpackcmd = zcm x $$arcpackedfile$$.tmp

crotoff
Zcm жмет быстрее, это заметно на больших архивах. Например, папку с игрой размером 311 МБ (326 480 156 байт) он сжал за 93.903 Seconds (a -s -r -m7 -t1), NanoZip за 200.851 Seconds (nz9:O), с (nz9:с) за 375.601 Seconds.
А в зависимости от типа данных разница в размерах архивов между ними может быть несущественной или даже меньше у zcm. Причем надо бы еще версию Zcm080 потестить, но не могу найти.
Параметр nz9:с у NanoZip не годится для практического использования, потому как он симметричный и распаковывать будет столько же кучу времени.
С FreeArc'ом там проблема: он отлично пакует архивы с zcm, но не хочет их распаковывать. Пишет invalid compression method or parameters. Если у тебя нормально распаковывает, то можешь сбросить папку с FreeArc'ом на какой-нибудь обменник? Без интеграции в FreeArc он для практического использования не годится.

Azrailll
я через плагин MultiArc от TC пакую, а GUI от FA не использую, щас тогда попробую скачать и настроить под zcm

crotoff
Можешь тогда всю папку MultiArc от TC сбросить если у тебя через него нормально полученные архивы распаковываются?

Azrailll
скачал FA переносной и oбновлeние к нему отсюда http://forum.ru-board.com/topic.cgi?forum=5&topic=35164&start=0&limit=1&m=1#1, закинул туда zcm.exe, прописал в arc.ini блок настроек https://my.mixtape.moe/wgjmya.ini
Упаковка: ключ сжатия zcm -m7, упаковал несколько фвйлов и распаковал им же, всё работает
Мультиарк ежели что https://my.mixtape.moe/kbbycg.zip

crotoff
Спасибо что сбросил, но все равно не распаковывает. Ты уверен что у тебя архив zcm создается? Ключ zcm -m7 создает архив с совершенно другими методами компрессии судя по инфе об архиве. Попробуй просто zcm без параметров указать и распаковать.

Azrailll
да чё-то действительно какая-то херня, шаблон не фурычит. Если вместо {options} напрямую поставить -m7 - пакует, но при распаковке Arc стирает распакованное zcm'ом. Это если несколько файлов в архиве, если же один - распакованное постоянно увеличивается в размере, пока не процесс не остановишь принудительно

Azrailll

Цитата:

Shuld ты не мог старые версии Zcm выложить (Zcm080)?

Могу на почту.
(У меня сейчас Яндекс Диск забит, записать туда ничего не могу. Надо будет в новогодние каникулы почистить.)

Добавлено:
Что касается nz9 - он интересный (сам подход - задавать отдельно сжатие и отдельно объем памяти!), но недоделанный.
При работе из оболочки - проблемы с русскими буквами в названиях папок и файлов, и в некоторых режимах у меня он выдавал ошибку:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=820#3
Ну как таким можно серьезно пользоваться?

Shuld
Спорные утверждения, не поленился повторить эксперимент с nz9. Только что версия была 64bit, может это повлияло. По крайней мере все методы работают без ошибок, и в консоли видны 4 потока. Впрочем я nz9 пакую только через FreeArc, в основном делаю архивы в конце рабочего дня - офисное файло xlsx, docx, pdf, ещё ни разу не наблюдал отказы. Так-то он давно не обновлялся, может уже и покруче сейчас есть архиваторы.

crotoff
Повлиять могло много чего: железо, версия ОС, порядок следования файлов.
Скажу лишь, что у WinRAR или 7z таких косяков не наблюдал.
---
Например, среди сверхплотных архиваторов PAQ8 серия, написанная одним автором - paq8kx_v4/…/paq8kx_v7
на одном из моих компьютерах отказалась работать:
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#19
п. 6 Ж)
А на другом работала.

Shuld
Да понятно, это же ещё альфы всё. Может при компиляции ключu указали, которые процессор не поддерживает. Paqи вроде прогрессивные jpgи не распознают. Кстати однажды тоже столкнулся с ситуацией когда на работе архивы перестали распаковываться после того как прав администратора у пользователя не стало, а rzm, который подавал надежды, на некоторых файлах споткнулся и начал ерунду какую-то писать при распаковке.
Сегодня нашёл ещё один интересный развивающийся пакер mcm. Я тестил 64bit версию 0.83 от Skymmerа http://encode.ru/attachment.php?attachmentid=3743&d=1436746789
с ключом -x10 Counter-strike 1.6 48 затаренный сжал до 297805643, -x11 уже не тянет - вылетает после стадии анализа, не хватает памяти. С ключом -m10 (middle) размер 302546721, быстрее на 2 минуты. С FA без проблем работает, вот код

Код: [External compressor:mcm_sk64]
packcmd = {compressor} {-option} $$arcdatafile$$.tmp $$arcpackedfile$$.tmp
unpackcmd = {compressor} d $$arcpackedfile$$.tmp $$arcdatafile$$.tmp

Все эти упаковщики, NanoZip в том числе имеет смысл использовать только с FreeArc'ом. Тогда плюшки от fa остаются, а минусы самих пакеров убираются.
Shuld я скинул мыло в личку или можешь на любой другой обменник выложить, а тут просто ссылку.
Самая первая версия zcm без проблем подключается к fa , можно посмотреть на какой версии код был переделан, может чем поможет.
P.S. С новым годом!

Все. Я уже почистил (частично) Яндекс диск.
Во всяком случае место уже появилось:
https://yadi.sk/d/alBxY9Rl7mOH0
Накидал туда на всякий случай zcm, начиная с версии 0,31.
Интересно, что у Вас получится.

Добавлено:
Кстати, похоже на сегодня самый плотный архиватор - cmix.
Но не смог с ним работать.

crotoff
А fp8_v3 не пробовали?
Он у меня никогда не сбоил, и мне понравился (теоретически).


Добавлено:
В продолжение старого теста 2012 г. по PAQ8
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=760#19
в августе 2015 проверял новые версии программ, на новом компьютере:

Плюсом справа отмечены данные на новом компьютере, минусом - старые (необновленные) данные. Стало быстрее в 1,64-1,69 раза.
Красным цветом показана ошибка: данные сжимались, но потом не распаковывались - версии от paq8pxd_v11 до paq8pxd_v16_skbuild3_x64. Так что "самой плотной" по сжатию среди новых программ в моем тесте оказалась paq8pxd_v10.
---
Пробовал Tangelo - впечатление непонятное.
Первая версия - по времени (в целом) как fp8_v3, но сжатие местами хуже.
Вторая версия стала быстрее и сжимала хуже.
Версия 2.2 стала еще быстрее и на многих файлах сжимает хуже WinRAR/7Z/FreeArc.

Shuld
Да пробовал ещё в то время, когда он появился - не получилось подцепить к FA, сам fp8_v3 пакует как надо,но размер arc на выходе получается разжатым. Как это победить - не знаю.

Решил я протестировать эффективность сжатия входящих во FreeArc-PowerPack упаковщиков, а также режимов FreeArc нацеленных на максимальное сжатие в сравнении с зарекомендовавшими себя упаковщиками (NanoZip, Zpaq и др.).

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



Показаны не все пакеры из arc.ini так как там много версий и различных модификаций, дающих сопоставимые результаты.
Тройка лидеров семейства paq с максимальным сжатием текста никуда не годится по скорости. Никто в здравом уме не будет ими пользоваться для практических целей. Ppmd, а также pmm (ppmonstr) используемые в FreeArc для сжатия текста тоже уже устарели и не выдерживают конкуренции ни по степени сжатия, ни по скорости.

Потом сжималась папка с игрой Counter-strike 1.6 48 (бинарные, текстовые и мультимедиа данные) размером 743 703 Кб. Результаты сортировались сначала по размеру, потом по времени сжатия. Упаковщики настроены на максимальные параметры сжатия.



Безусловным лидером в этом тесте является NanoZip, особенно с использованием многопоточности. Mcm на втором месте, и режим x10 (максимальное сжатие с приемлемыми требованиями) аналог nO, но пока нет многопоточности, так что стоит подождать и понаблюдать за его развитием.

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

Для примера я взял средний в списке метод сжатия 9n. Для упаковки уже сжатых данных там используется slug. Меняем slug на более эффективный slugx в arc.ini и вуаля метод становится лидером по степени сжатия (9nsx). Затем распараллеливаем основной алгоритм сжатия lzma с более тонкими настройками сжатия и метод чудесным образом выбивается в лидеры группы как по скорости, так и по степени сжатия (9nsx:4x4)!
Ссылка на таблицу: https://yadi.sk/i/RQql741AmdtTy

Вобщем было бы неплохо составить новый arc.ini использующий эффективные методы сжатия с помощью внешних упаковщиков в новом PowerPack.
P.S. Shuld спасибо за версии

Azrailll
Тогда уж и arc.groups новый придётся составлять. В основном пакуют игры, скажем взять с десяток современных игрух и прогнать каждое из встретившихся расширений через десятку лидеров-упаковщиков; одни на текстах себя покажут, другие - на бинарных данных, и вписать оные расширения в arc.groups. Надо ещё учесть, что у некоторых пакеров свои препроцессоры есть и анализаторы, и перед ними сторонние препроцессоры не стоит писать в цепочку, а бывает что наоборот, сторонний круче (например xwrt для xml)

crotoff
Да, конечно, arc.groups тоже стоит обновить. Но там проще добавить несколько новых расширений в группы.
Неплохо бы сообща этим заняться, так как ты верно заметил, тонкостей хватает и можно было бы протестировать полученные варианты на разных конфигурациях систем.
Архив .arc имеет смысл использовать как контейнер (как mkv для видео) для внешних более эффективных упаковщиков.

Сравнил версии архиватора ZCM между собой.
Сначала в однопоточном режиме сжималась папка с игрой Counter-strike 1.6 48 размером 743 703 Кб с параметрами: a -m7 -r -s.



Первые версии являются лидерами по сжатию, но и времени им нужно гораздо больше. Оптимальный вариант по соотношению время/размер - версия 088. Самой быстрой оказалась версия 092.

Потом в многопоточном режиме с параметрами: a -m7 -r -s -t3.



Многопоточный режим неважно реализован, поэтому профит был только с режимов не выше -t3. Опять же лидер по скорости версия 092.
Ссылка на таблицу: https://yadi.sk/i/vr_uBLRgmeNaj

К FA подключить так и не получилось, но судя по тесту особого смысла и нет. Режим распаковки симметричный, так что лучше настраивать режимы Nanozip с многопоточностью.

Azrailll
Результаты не совпадают с моими.
Но нечто общее есть:
1. После версии Zcm080 все последующие сжали хуже. Быстрее - может быть, но хуже.
2. Многопоточность в Zcm заметно ухудшает сжатие.

Shuld
Так данные же разные паковались, да и системы разные. Так что сравнивать можно только относительно других участников теста. Zcm080 действительно лучшая по сжатию из новых, а версия Zcm092 у тебя 32х-битная.
А кстати были тесты на сжатие текстовых данных? Не WinRar/7z, а других сторонних упаковщиков.

Azrailll

Цитата:

а других

С моей точки зрения, "других" интересных для тестов в общем-то и нет. Что было интересного - выкладывал.

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

zmashine
Эта http://www.softwareok.com/?seite=Microsoft/NonCompressibleFiles ?

Engaged Clown, вроде, не она. на сколько помню там функционала побольше было.

Наткнулся на очень быстрый пакер с поддержкой NVIDIA CUDA - bsc (http://libbsc.com/).
Быстрый тест на текстовом файле enwik8(XML) размером 100000000 байт показал впечатляющие результаты:



Кто-нибудь пробовал его уже и может есть сохраненные старые версии?

Azrailll, а как включается CUDA? Я пробовал, но у меня грузится только CPU.

Здравствуйте!
Чем посоветуете максимально качественно и быстро сжать базы Консультант+?
Есть ли на Ваш взгляд варианты заставить Оболочку К+ работать прямо из архива?

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

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

Добавлено:
Я, например, пользуюсь портабельным Office 2007 размером 265 Мб

Я провёл небольшое тестирование различных алгоритмов сжатия и дедупликации базы К+, при которых Оболочка запускается и работает с той же скоростью:
Варианты Исходник NTFS Дедупликация LZX LZX+NTFS Сжатие