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

Ну зачем же стреляться? Вслед за компом.
Первые 2 пункта размыто.
В 3 есть проблемы.
4 Флешки не имею, промолчу.
5 Инсталяторы я к архиваторам не причисляю, это иная сила.
6 и etc... Хер с ними. Не хочу я с тобой спорить, Кесарю кесарево...
Архивируй на здоровье, хорошего дня.

krasniybox

Цитата:

5 Инсталяторы я к архиваторам не причисляю, это иная сила.

Там используются те же алгоритмы сжатия.


Цитата:

Архивируй на здоровье, хорошего дня.

Тебе того же. И ещё - никогда не пользуйся архиваторами. Даже если будут заставлять, даже если это будет очень нужно. Из принципа.

krasniybox
Smitis

флуд
в этой теме нет вопроса "а зачем?", есть только сообщения от знающих что они делают.

Цитата:

не парьтесь с архивацией данных, просто удалите их.

спасибо! поставлю в эпиграф к своей программе

кстати, к преднему архиватору у меня был эпиграф:

arj работает как часы.
arjz работает как arj, но в два раза быстрее

WinRar, 7z , WinUDA
В порядке используемости. И в обратном - по степени компрессии.

Bulat_Ziganshin
Цитата:

обзор обновлён

Спасибо, очень интересная информация. Добавил в шапку.

Цитата:

Наконец, за недостатком места просто перечислю, в каком порядке финишировали архиваторы в моём собственном тесте текстового сжатия: LPAQ1, CCMX, CCM, FreeArc, UHARC, Durilca’Light, 7-zip. Этот тест содержит наборы данных среднего размера (30-100 мб) и включает наиболее распространённые типы текстовых данных – html, исходники и художественные тексты.

Хорошо бы указать количество и объём файлов каждого типа - например, как сделано на www.maximumcompression.com: Тестирование на 46 типах файлов (510 файлов, 301 Мб), архиваторы ранжированы по эффективности ([more=смотрим табличку с информацией о файлах у нас]Типы файлов _46 типов

предлагаю разделить в шапке сайты, сравнивающие сжатие, и форумы:

тесты сжатия:
http://www.maximumcompression.com/
http://squeezechart.freehost.ag/
http://maxcompress.narod.ru/
http://blackfox.wz.cz/pcman/benchmark.htm (last updated 17-06-2007)
http://www.uclc.info/ (last updated 29-04-2007)

форумы:
http://forum.compression.ru:8080/
encode.ru

вообще хорошая подоборка ссылок на http://www.geocities.com/lovepimple_mail/

Bulat_Ziganshin
Булат, спасибо, классно. Было бы интересно увидеть зависимость ratio/time/data, чтобы можно было сделать задачно-ориентированные оценки: для каких данных какой архиватор нужно выбрать, чтобы уложиться в заданные временные рамки.
(Знал бы как, попросил бы автограф...)

Цитата:

Было бы интересно увидеть зависимость ratio/time/data, чтобы можно было сделать задачно-ориентированные оценки: для каких данных какой архиватор нужно выбрать, чтобы уложиться в заданные временные рамки.

freearc, freearc, freearc. all you need is freearc. it's all you need

у него есть некоторый верхний порог сжатия, выше которого надо применять ccm, ccmx, lpaq, durilca и прочие программы. если же тебя не устраивает даже скорость CCM, то дальше идёт практически безраздельное госполство fa - вплоть до -m1 режима со скоростью в десятки мб/сек. речь правда идёт об fa 0.40, который пока находится в стадии тестирования

я надеюсь, что в эти выходные страничка http://www.maximumcompression.com/data/summary_mf2.php будет обновлена и это можно будет воочию увидеть

Bulat_Ziganshin
"Nothing you can do but you can learn how to be in time". Tackling the problem in time is what matters! Freearc это что-то новенькое для меня; выглядит впечатляюще! Однако страница дает лишь результат на взвешенном наборе разнородных данных. Иными словами, этот самый "set [that] contains 100's of files " обрабатывается как единое целое, правильно? Но ведь редко когда вы делаете архивы смешанных наборов (кроме варианта complete backup на ум ничего больше не приходит). Однако, уже таблица с результатами обработки документов НЕ содержит показателя эффективности. Практически интересно было бы видеть динамическую гистограмму, показывающую какие архиваторы попали в заданный диапазон при заданной (на сайте) параметризации. Как пример, возьмем WinRAR. Очевидно (хотя мне легко доказать это лишь накопленной стастистикой), WinRAR есть тот самый вариант, который максимально плотно попадает в распределение по всем параметрам: за оптимальное время вы получаете оптимальное сжатие, полученное на количестве данных оптимальной разнородности. Я могу столь же быстро и эффективно сжать документы офиса, сколь быстро и эффективно я могу сжать электронную книгу или дистрибутив какой-то программы. Хотелось бы иметь возможность интерактивной параметризации гистограммы на сайте.
olegpronin
Неплохой вариант, но хороший пример неплохой оптимизации (хотя вот оценка в 5 часов на сжатие ~200 мегабайт MHT-файлов дает повод для раздумий).

WinUDA рулит!

кстати, на форуме encode сейчас идёт обсуждение того, как сделать "Идеальный бенчмарк", так что знающие английский могут там напрямую высказаться

Bulat_Ziganshin
Экый у вас там коллектив собрался, однако. Интересно. Спасибо за ссылку.

Может, кто тестировал и скажет насколько % в среднеем WinRK эффективней WinRAR при сжатии текстовых файлов?

Цитата:

Если время вдруг появится, то буду делать версию тестов 2.0.

Анонс тестов
(страничка в разработке)
Если есть предложения пишите в ПМ.

Егор, посмотри http://www.encode.ru/forums/index.php?action=vthread&forum=1&topic=566

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

64 бита, 4 ядра - это было бы очень полезно. тесты должны заглядывать немного в будущее. ты ведь в январе 2008-го не станешь перетестирвоать?

впрочем, 4 ядра сейчас реально нико ещё не держит

Bulat_Ziganshin
сейчас и 2 ядра никто не держит. это псевдо-распаралеливание. второй процик грузиться на 60-70% всего. а сколько уже лет прошло? единственное правильное распарралеливание написано в gogo-no-coda 2.39 на asm-e. вот там я понимаю число молотилка. вот её бы ещё на плейстейшине запустить. это конечно дорогой вариант. гораздо дешевле будет анализировать список входящих файлов и делить его на кол-во потоков. и после этого уже с ним работать.
но это тупиковая ветьв эволюции так как. так как винты не смогут отдавать потоково данные с 4х файлов. Упремся в веники.

Farch

Цитата:

но это тупиковая ветьв эволюции так как. так как винты не смогут отдавать потоково данные с 4х файлов. Упремся в веники.

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

Приступаю собственно к практической части, надеюсь в две недели уложусь, иначе будет "долгострой".
news_v2_08.12.07
(общая страничка (в разработке))

Цитата:

64 бита, 4 ядра - это было бы очень полезно.

4 ядра - только улучшат время сжатия;
64 бита - улучшают степень сжатия (за счёт памяти, если её не хватало), немного улучшают время сжатия.
Архиваторов 64bit, практически нету.

Цитата:

ты ведь в январе 2008-го не станешь перетестирвоать?

не стану, у меня не будет 4-х ядерного процессора

Хочу спросить: есть библиотека электронная книжная, около 100 Гб, форматы разные --- TIFF Group4 (fax format b/w), jpeg, djvu, txt, html -- сотни тысяч страниц книг.
Естественно, все по разделам, темам... но грубо --- графика к графике, текстовые файлы --- к текстовым. Поэтому мне понятно, что универсальный архиватор вроде как не очень рационален будет. Просто можно архивировать 7zip' ом или RAR'ом.

Но хотелось бы разделить мух и котлет - текстовые и графические архиваторы - для получения более эффективного сжатия, то есть сильного и быстрого О Д Н О В Р Е М Е Н Н О .

Например, на дискету я сжимаю WinUDA, но он медленный для архивирования объемов 100 Мб - 100 Гб. В среднем текстовая книга (txt, html) имеет объем до 1-3 Мб до архивирования. Таких книг тысячи. В графике книг меньше, зато одна энциклопедия может иметь 10000-20000-50000 страниц в jpg, djvu, tiffG4 (каждый том примерно по 1000 стр.=файлов), один словарь -1000 до 3000 страниц-файлов). При этом, один том = 1 архив.

Вероятно tiffG4, djvu вообще не следует сжимать.

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

Кто и что может посоветовать конкретное по организации работы. Хотя бы адекватные типы архиваторов на указанные форматы. Воспользоваться готовыми таблицами результатов нельзя, потому что мои конкретные задачи сильно отличаются от абстрактных условий тестов и экспериментов. Можно строить только гипотезы. - ТНХ.

ПС. По работе мне приходится давать людям задания с литературой, этакий "подарочек" каждый раз делать... Флэшки не надаришься... А вот дискету - пожалста. Между прочим, на стандартную дискету 1,44 Мб входят 30-35 обычных нормальных книг, распознанных и в текстовом формате... Правда, если их сжимать WinUDA. Туда же и архиватор 18 Кб уходит. ЭТА ИНФА ДЛЯ ТЕХ, КТО ПРЕЗИРАЕТ АРХИВАТОРЫ.

Пеар detected

определение по структуре же ещё не реализовано ?

Пиар - не пиар, а прога от Зиги рулит по ЭФФЕКТИВНОСТИ!
Известные архиверы - вне конкуренции сидят дауном в дауне:
http://www.maximumcompression.com/data/summary_mf2.php

Мне б вот тока с моими типами файлов и объемами разобраться...

cuneiform
Согласен. UDA'шке только кроссплатформенности не хватает.

Пока для jpeg'ов нашел тока paq8fthis2 - консоль, дает 25% экономии. С 4-х дивиди энциклопедии -- экономия 1 дивиди. Для размножения и переписывания - это много.

Не смог справиться с командной строкой FreeArc'a... куда уж мне . он хочет почему то все файлы в корневой директории заархить вместо 1 файла...

tiffG4 (fax) , djvu - сжимать вроде нет смысла?

Эффективнее WinUDA оказались у меня Slim23d на текстовых файлах и Durilca05, Ppmdj --- эти быстрее Slim23d. И все они эффективнее WinUDA, кроме Ppmdj. PAQ8o8 слишком медленный -- нереально 700 Мб с книгами в текстовом формате архивить.

Для jpeg лучше StuffIt или PackJPG юзать.
По остальному хз.

Стаффит конечно лучше, но больно они жадные - даже за разархивирование хотят денег... Лучше болванок на ети деньги накупить... с такими из-за 3-5% связываться - дороже выйдет -- только напороться (у нас есть "общество сторонников легального софта", хотят с милицией по предприятиям и проверяют лицензии, живут на выручку от штрафов и возбужденных дел). Хорошо, что человек из stuffit еще консоль сделал, а то внутри простой зип-архивер, даже не 7-зип, даже в делюкс! Вот это и есть ацтой ....ПацкЙПГ всего макс 18% дает, даже не 25% как паку8фтхис2, который бесплатный ...

Всеэти эксперименты убедили меня, что пришло время отказаться от RARa в качестве основного архивера на компе--- в пользу 7-zip --- из-за эффективности (сжатие/время). Выбираем нужный алгоритм -- PPM для текстов и LZM для программ, софта. ---- Результат будет лучше RARa однозначно. И бесплатно.

Может стоит заняться реабилитацией Slim!'a:

_http://www.bars-trade.com/slim/

Просмотрел по поиску на форуме -- нет такой отдельной темы.

Что сказать? - Пацан повозился немало, начав с алгоритма РРМ, перешел на наработки Д. Шкарина потом, приблизился к плотности PAQ'a (который на моем компе с 256 МБ рамы 4 Мб пакует ровно 1 час), сразу за ним по плотности, зато з а м е т н о б ы с т р е е , а потом... бросил на билде 0.23, решив, видно, что не солидно стока возиться.

Как нормально задать упаковать им целую папку или составить List для упавковки?!

Это у него все предусмотрено, точно знаю (прога пишет 1/1 при упаковке одного файла в один архив и по-другому с несколькими файлами).

Конечно, можно прогу обмануть, упаковав зипом с 0 сжатия сначала в 1 файле. Или написать просто имя папки, тогда он упакует... и самого себя !!! при этом. Варварство.

cuneiform
Про Slim! тут много писали, по сжатию приблизительно сравним с WinUDA.
http://forum.ru-board.com/topic.cgi?forum=5&topic=8076&start=300#3
Есть также в тестах Егора32.


Цитата:

Как нормально задать упаковать им целую папку или составить List для упавковки?!

Попробуйте прикрутить к FAR или TC.
(исправлено)
Файл, ссылку на который я выкладывал, больше там не лежит, сейчас у меня под рукой нету - но потом постараюсь выложить. Или спросите у arsvrn - нашего специалиста по multiarc.

Viewgg

Плииз если можно выложите еще раз куда-нить эти штуки --- SLIM! аддоны для TC/FAR от arsvrn... На рапиде уже нет их.

На моем (архаичном весьма) компе Slim! эффективнее UDA получяается, заметнее. Особенно, на экзешниках.

Не удается заменить RAR например 7-zip'ом из-за того, что в RAR есть пакетная обработка --- поставил галочку и 1000 файлов архивятся в 1000 файлов, а не в 1 файл. Это важно для электронных библиотек книг.

Написал в личку arsvrn - может ответит....

Время быстро бежит... На странице по вашей указанной ссылке цитируется Slim 0.16, а после того был билд 0.21 (адгоритм РРМ) и 0,23 (другой алгоритм)... WinUDA был 0.29 , а есть консоль 0.30 - по другому архивит.
ТО есть материал быстро устаревает и выводы соответственно...

В общем загорелся Slim'om. Хорошо б кто-то написал как выставлять опции, чтобы заархивить более 1 го файла. Понятно, можно затарить перед тем (тока после затаривания логфайла в ТС для примера, его объем возрос!)... ЕДинственный реальный конкурент -- PPMonstr . Чтобы превзойти UDA-