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

Panzer
21:49 07-03-2006
Цитата:

winzip 2-й в "рейтинге полезности". ню-ню.

Так опечатка. Найти и заменить: Что: бес На: Пусто. А выборка сделана без нейтрального элемента в двоичной системе, оттуда и два.
Только вот, непонятка выходит. Как это DOC и XLS попали в разряд текстовых:

Цитата:

Текстовые файлы объемом 63026КБ. 1566 файлов, среди которых TXT, HTML, RTF, DOC и XLS.

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

Цитата:

установленные в системе Sun Java 1.5.0, Mozilla Firefox 1.5, Opera 8.50 с пользовательскими данными и Picasa 2.

и, тем более, отправлять их по интренету, а вот сэкономить пространство на хранении PDF'ов, всегда приятно.
А когда это WinACE 2.6 стал

Цитата:

Цена: бесплатный

Мне казалось, у него минимальная цена $29?
Показательная опечатка:

Цитата:

ZIP, максимальное сжатие Enchanted deflate

Куда с диаграмм исчезли результаты для последних в списке архиваторов, таких как WinUHA и WinZIP?
Думается, что это

Цитата:

Любопытно, что каждый из этих архиваторов использует уникальные алгоритмы сжатия, и тест показал не только борьбу архиваторов, но и борьбу алгоритмов (ALZ-3, LZMA, RAR).

не совсем корректно...

Ну и классный получился результат: WinUHA на последнем месте. Это же не рейтинг полезности, а рейтинг универсальности. Ясное дело, что результаты WinZIP будут ложиться все время посередине и, в конечном счете, WinZIP самый универсальный. Так было бы раньше, но вычислительная мощь современных машин и достаточное количество памяти, естественно, вывели WinRAR на первое место.
Смотрите, как веса от временных затрат забили CAB и UHA в самый конец! И что, после этого мы будем говорить, что это самые бесполезные форматы???
Нужно было проводить итоги по типам файлов и конечных задач.
arsvrn
22:15 07-03-2006
Цитата:

Так 1, 2 и т.д. - не места, занятые архиваторами, а нумерация пунктов в разделе "Подведем итоги."

Нет, это именно места:

Цитата:

Рейтинг полезности
Формула рейтинга будет такова:
R = ((Сумма всех времен) * (Объемы всех архивов)) / ((Кол-во успешных тестов - 10) * 10000)

TCPIP
Экспертная оценка содержащая балы или коэфициенты или формулы субьективного характера - можно долго спорить...
К примеру есть порядка 100 PC PII под NT - большего для этих конккретных рабочих мест обьективно не требуется, а среди прочих есть архивирование
К тому что "вычислительная мощь" надо диффиренцировать на классы немощности, тогда бы результаты тестов стали бв более интересны в прикладном плане.

egor23
Новый WinRK уже тестировали?

Добавлено:
Насчёт статьи: обсуждение - в параллельную ветку лучше бы, но на первый взгляд результаты кажутся бредом, статья Енотуса гораздо более грамотная. Тамошние лидеры сжатием не блещут, я бы отметил 7-zip, UHARC, WinRK, Slim!, Durilca, WinUDA. Кстати, автор - Юрий Меркулов - больше по Мозилле специалист, не по архиваторам, отсюда неграмотная подборка программ и странные результаты.

Добавлено:
Да, совсем забыл: Меркулову, видимо, невдомёк, что ALZ в UHARC не слишком-то серьёзный (он даже не подозревает, что архиватор - UHARС, а WinUHA - оболочка), а вот тамошний PPM уверенно порвёт всех участников теста, исключение - DLL (лидер - 7-zip), см. мои тесты или результаты http://www.maximumcompression.com (они совпадают). Так что лидер по сжатию - не 7-zip, а UHARC.

М-да, этот текст бессмысленно обсуждать. Как-то стыдно за IXBT .

TCPIP

Цитата:

Показательная опечатка:
Цитата:ZIP, максимальное сжатие Enchanted deflate

Вот за это спасибо, очаровательно! Особенно хорошо сочетается с названием "Путеводитель по архиваторам"

Viewgg

Цитата:

статья Енотуса гораздо более грамотная.

Их даже сравнивать нельзя.

Viewgg

Цитата:

Новый WinRK уже тестировали?

Пока нет, еще не до конца с WinRK 3.0 build 2 beta потестил, в ROLZ2 отключил оптимизацию ( Largest optimised match: 0) меня приятно удивил, по затраченому времени, да и степень сжатия не сильно ухудшается.

michz
03:35 08-03-2006
Цитата:

К примеру есть порядка 100 PC PII под NT - большего для этих конккретных рабочих мест обьективно не требуется, а среди прочих есть архивирование

Кстати, раз под NT, то и архивации ZIP не надо --- сжатие потоков NTFS дает почти такой же результат, а временных затрат нет вообще. А зачем нужен ZIP, кроме как для цели минимизации временных затрат не понятно. И эта статья лишь подтверждает факт, что основной вклад в выигрыш ZIP вносят минимальные временные затраты на архивацию. Но что-то слабо верится, чтобы на рабочих станциях были задачи архивации таких объемов данных, что время ожидания получения архива при работе со всеми рассмотренными программами будет вносить хоть сколь-либо заметный вклад. А вот если предстоит задача архивации каких-нибудь баз данных Outlook, то здесь время будет играть роль, ибо несколько минут или несколько часов ожидания все-таки заставляют подумать. Но! С другой стороны: все такие задачи обычно выполняются сервером, а там что час, что 10 не одна ли разница, если экономия места на выходе существенная, а архив будет положен в хранилище и не будет по двести раз на дню из него извлекаться?

Цитата:

К тому что "вычислительная мощь" надо диффиренцировать на классы немощности, тогда бы результаты тестов стали бв более интересны в прикладном плане.

Согласен. (хотя что имеется в виду под понятием "классов немощности" я не очень понял)

Цитата:

Enchanted

Очарованный - это сильно сказано! Писал бы себе Меркулов про свою Мозиллу... Даже не написал, что такое LZ/PPM/CM/BWT и т.д. Вывод: читайте статьи Енотуса и http://www.compression.ru/
egor23
ОК, ждём результатов. Надеюсь, Малькольм не наврал.

---

Извините за небольшой флейм.

TCPIP
"Кстати, раз под NT" - честно говоря я этим 100 PC рекомендаций не даю (полит. мотивы), специфика такова что очень много мелких файлов.
"чтобы на рабочих станциях были задачи архивации таких объемов данных" - гм, бывает что вн. орг. нужно то что в производственной цепочке производителю услуг вобщем то не очень нужно или если нужно то в значительно меньшем объеме. Объемы то же в соотношении с "классами немошности" - NT SP6a еще как то "большие винты" видит, а с пред. SP как то глазки на их размер любят закрывать... Если OS с приложениями - 560 MB, а архивы 2,8GB (без зиповки) мелких файлов, приблизительно так. Гм, а задачи там и не ставят... Это я для примера но "живой" вариант... что может быть.
""классов немощности" - в какой-то мере частота CPU, хотя недостаток памяти дает известные результаты, скорость hdd... короче есть объективные параметры для субъективной классификации

michz

Цитата:

"вычислительная мощь" надо диффиренцировать на классы немощности

Сильно сказано.
Viewgg
egor23
Не разделяю вашего оптимизма по поводу WinRK. Подробности когда-нибудь, но вот конкретно ROLZ2 durilca-light на современной машине обходит и по скорости и по сжатию. Жаль sfx нет.

Panzer
ROLZ2 хорощ тем, что ассиметричный, потому я так и трещу про него всё, что 7-zip позиции сдал.
Цитата:

Жаль sfx нет.

Ну, это не страшно, главное сжатие.

Viewgg

Цитата:

ROLZ2 хорощ тем, что ассиметричный

угу. только симметричный durilca-light обгоняет его и при сжатии и при разжатии

Panzer
Если так, то ляпнул я, вот и всё. А вот FPW1 рулит: http://www.uclc.info/
Он теперь вроде ещё быстрее и сильнее...

Panzer
Кстати, не всегда Дурилка и лучше ROLZ2:
http://uclc.info/gimp_source_compression_test.htm

Добавлено:
http://uclc.info/multilingual_text_compression_test.htm
Даже на тексте Дурилка (light) отстала!

Добавлено:
HL2:
sourcesdk.gcf 512,9Мб
day of defeat source.gcf 833,2Мб
opposing force.gcf 171,8Мб
half-life source.gcf 766,9Мб
lostcoast content.gcf 335,3Мб
counter-strike.gcf 265,1Мб
half-life blue shift.gcf 252,3Мб
half-life.gcf 395,4Мб

for HL2:
WinRK 3.0 build 2 beta профиль ROLZ2_0 ( Largest optimised match: 0)

Добрался до WinRK 3.0 build 3 beta, профиль ROLZ3\ROLZ3_0
добавлен для:
RES.RDT
counter-strike source shared.gcf
half-life source.gcf

В связи с изменениями в алгоритме ROLZ2 (WinRK 3.0 build 3 beta), которые отразились на скорости упаковке и немного на степени сжатия, то сравнивать ROLZ2 (WinRK 3.0 build 2 beta) и ROLZ3 (WinRK 3.0 build 3 beta) несовсем корректно и данные по ROLZ2 при сравнении с ROLZ3 нужно воспринимать как ориентировачные.
Возможно будет добавлен ROLZ2 (WinRK 3.0 build 3 beta) для некоторых файлов.

Panzer

Цитата:

Не разделяю вашего оптимизма по поводу WinRK. Подробности когда-нибудь, но вот конкретно ROLZ2 durilca-light на современной машине обходит и по скорости и по сжатию.

Я так понимаю Вам нравиться durilca, но на сегодня она не совсем стабильна, у меня один раз вылетела при упаковке, на http://www.maximumcompression.com/data/summary_mf.php возникли проблемы с распаковкой.
Мне вот нравился UHARC, когда начинал им пользоваться показывал хорошие показатели, но сегодня он сдаёт позиции по сравнению с 7z, как по степени сжатия так и по времени упаковки, если еще в 7z улучшат сжатие wav, то для мультимедия он будет лучшим вариантом, нежели UHARC.
Любой программный продукт должен развиваться.

egor23

Цитата:

Мне вот нравился UHARC, когда начинал им пользоваться показывал хорошие показатели, но сегодня он сдаёт позиции по сравнению с 7z, как по степени сжатия так и по времени упаковки

Насчёт времени согласен, а вот насчёт сжатия непонятно: в большинстве тестов UHARC 0.6 обыгрывал 7-zip, у последнего, насколько я понимаю, новых алгоритмов не добавлялось, а на большинстве тестов UHARC выигрывал (хотя не на всех), 7-zip ведь в плане сжатия не развивается, развиваются только WinRK и PAQ. Насколько я понимаю, на сжати графики лидирует WinACE, а на сжатии аудио - Slim (из популярных). Или я в чём-то неправ?

Добавлено:
WinRK 3.0 build 3 beta профиль ROLZ3, ROLZ2 for:
п1, п2, п3, п5, п6, п8
HL2 for:
source engine.gcf
source models.gcf
sourcesdk.gcf

Случайно замечено WinRK: как мне кажится невсегда wav архивируется с audio optimised - файл Ногу Свело! - Лесная Школа.wav был сграблен на другом приводе (по ошибке в DVD-ROM попал диск)
и упаковался лучше, отличия по содержимому файлов Ногу Свело! - Лесная Школа.wav сграбленых на CD-ROM и DVD-ROM данные в начале файла немного сдвинуты.
Тоже касается и файла Soulfly - Back To The Primitive.wav, токо переграбление не помогло принципиально улучшить степень сжатия.
Результаты будут позже.

Viewgg

Цитата:

7-zip ведь в плане сжатия не развивается

Может в принципиальном плане и не развивается, но что-то делается:
7-Zip 4.33 Alpha 1
степень сжатия при использовании Zip/GZip/Deflate в режиме Ultra возросла
7-Zip 4.34 Alpha 1
новые ключи командной строки: -mmc={N} позволяет увеличить степень сжатия для LZMA и Deflate в некоторых случаях

А на примере tar-архивов wildsoft.ru видно, что имеет значение не только алгоритм но и как этому алгоритму преподносятся данные для обработки.


Цитата:

а на сжатии аудио - Slim (из популярных)

если брать не специализированные, то WinRK по лучше пакует, чем Slim.

Добавлено:
ресурсный файл archive.dat 202,5Мб из игры Teenage Mutant Ninja Turtles: Mutant Melee 1.0
WinRK 3.0 build 3 beta профиль ROLZ3, ROLZ2 for:
п7, п11
HL2 for:
source materials.gcf
half-life 2 content.gcf
counter-strike source shared.gcf
day of defeat source.gcf
opposing force.gcf
файл half-life source.gcf
lostcoast content.gcf
counter-strike.gcf
half-life blue shift.gcf
half-life.gcf
source sounds.gcf
half-life 2_russian.gcf

egor23
Есть вопросы по ресурсным файлам gcf. Почему для UHARC нет результатов для PPM? Проводились ли тесты, и имеют ли они смысл? (Возможно, словарные методы заведомо лучше на этих данных? Или скорость PPM слишком низка для таких объёмов?) Интересно, каково сожержание этих файлов, т. к. UHARC имеет здесь значительное преимущество. И последний вопрос: Slim и прочие "монстры" не тестировались из-за низкой скорости?

Viewgg

Цитата:

Есть вопросы по ресурсным файлам gcf. Почему для UHARC нет результатов для PPM? Проводились ли тесты, и имеют ли они смысл? (Возможно, словарные методы заведомо лучше на этих данных? Или скорость PPM слишком низка для таких объёмов?) Интересно, каково сожержание этих файлов, т. к. UHARC имеет здесь значительное преимущество. И последний вопрос: Slim и прочие "монстры" не тестировались из-за низкой скорости?

Содержимое *.gcf файлов описано в Исходных данных.
Для PPM нет, так как не имеет смысла, разница в степени сжатия крайне мала, и притом это симметричный алгоритм. hl2 брался уже запакованный, например counter-strike source shared.gcf был в ppm и распаковывался 1ч20мин, одно дело потратить время на упаковку, другое на распаковку.
А вообще там есть результаты для PPMVC можете экстраполировать для других упаковщиков.
И соответственно нету: Slim - это PPMII, ну и "монстры" типа PAQ, WinRK3(PWCM) и т.п. времени будет потрачено очень много.

Да, вот про durilca забываю сказать, незнаю как у кого, но у меня она вбивает в память данные которые упаковывает, поэтому большие объёмы данных, даже txt, нет возможности упаковывать.

egor23
Спасибо, всё понял. Один нюанс:

Цитата:

Slim - это PPMII

Да, но в нём есть и фильтры для текстов, исполняемых файлов, аудио. Первые два можно включать принудительно. Или всё же скорость этого архиватора также слишком мала?

Изменено:
Опер.память 2T\1T Timing (Command Rate) поставлен 1T.
В результате получился небольшой прирост скорости упаковки.

Добавлено:
exe,dll п7, п8
MPlayer - The Movie Player
Codecs for use with MPlayer

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

Если есть абсолютно стандартный компот из всех распространённых типов файлов (которые вообще потенциально могут быть сжаты) эдак в 500 метров размеров, то какой архиватор всё-таки сожмёт без учёта времени и системных ресурсов это всё лучше всего?

cracklover
WinRK 3.03, я полагаю, методом PWCM. Большинство тестов он выигрывает, да и по времени имеет некоторое преимущество перед блишайшими "преследователями". Разумеется, "компот" не должен быть специальным образом заточен подо что-либо.

Добавлено:
Monstrous PPMII compressor based on PPMd var.J, Feb 16 2006
DURILCA - dirty useless really illusory compressor/archiver, v.0.5(non-public) (C) 1 Apr 2006
for: п1,п2,п3,п5.

Очень поучительная статья:

http://www.overclockers.ru/softnews/21894.shtml

cracklover

Цитата:

Очень поучительная статья:
http://www.overclockers.ru/softnews/21894.shtml

Что-то этот KGB активно продвигают, а ведь основан он на PAQ6.

Сравнили бы его хотя бы с аналогичным WinUDA, а потом уже звали бы "королем"! На мой взгляд, "король" сейчас WinRK, судя по тестам. Кстати, "UNARC" - это они остроумно написали, молодцы! Похоже, авторы этой статьи - очередные неграмотные люди, вот и всё. Архиваторы, с которыми они сравнивают свой продукт, далеко не лидеры в области сжатия! Похоже, на http://www.maximumcompression.com/ его и тестировать не стали, как очередной клон PAQ6. Причём Малькольм тоже берёт PAQ за основу, но его PWCM изрядно лучше конкурентов, а тут... Даже не о чем говорить.

Я его где-то пару недель назад попробовал и даже писать не стал - жмет часто даже хуже PAQ6,7, Slim, Durilka. От WinRK однозначно отстает. Зато опережает всех по времени (в смысле дольше ). Конкретных данных не дам - уже удалил, но впечатление именно такое.

Цитата:

Зато опережает всех по времени (в смысле дольше ). Конкретных данных не дам - уже удалил, но впечатление именно такое.

Агалогично!
Прожил у меня на компе минут 15. Снесён без сожаления

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