Какой архиватор сейчас самый быстрый?

lzo

bhfq (26.10.2011 18:07:41)

www.linux.org.ru/news/opensource/6054950

registrant (26.10.2011 18:08:25)

винрар же

amorpher (26.10.2011 18:08:33)

два кусочка рафинада этому господину.

adriano32 (26.10.2011 18:10:38)

>Какой архиватор сейчас самый быстрый?
>самый быстрый

bhfq (26.10.2011 18:20:51)

lzo не самый быстрый? а squashfs? короче хз, кастую сравнительные тесты с фороникса :)

adriano32 (26.10.2011 18:23:46)

в некоторых случаях : pbzip2
http://compression.ca/pbzip2/

anTaRes (26.10.2011 18:42:40)

Snappy/Yappy.

devl547 (26.10.2011 18:45:03)

>>Скорость упаковки важна, скорость распаковки важнее. Степень сжатия не особо важна.
[troll] tar [/troll] :)

+ http://www.compression.ru/arctest/act/act-calg.htm

anTaRes (26.10.2011 18:53:53)

+ минитест (1000M .img, 2x core):

$ time lzma -1 Linux.img 
real	0m29.077s
user	0m27.831s
sys	0m1.191s

$ time lzma -d Linux.img.lzma 
real	0m3.964s
user	0m3.945s
sys	0m0.004s

$ time pbzip2 -1 Linux.img 
real	0m15.728s
user	0m26.561s
sys	0m2.087s

$ time pbunzip2 Linux.img.bz2 
real	0m24.031s
user	0m6.023s
sys	0m1.549s

anTaRes (26.10.2011 19:25:51)

>Поэтому я счёл формат ZIP целесообразнее 7Z.

так это ж контейнеры, все едино. Я недавно дампы баз сжимал методом LZMA и засовывал в zip. Скорость сжатия на третьей степени намного выше обычного deflate (тот самый, который в обычном зипе со времен pkzip), при этом сжимается лучше. Скорость распаковки не измерял, мне было важнее, чтоб открывалось даже голой вендой :)

А так можешь взять 7z в руки да проверить на одном своем файле. Контейнеров и методов сжатия не так и много.

nu11 (26.10.2011 20:20:53)

>Май, 2002

Некрофилия в треде!

devl547 (26.10.2011 20:30:40)

> pbzip2

pigz (parallel gzip)

sdio (26.10.2011 20:50:11)

Re: Какой архиватор сейчас самый быстрый?

tar

> Степень сжатия не особо важна.

Тем более. А за сжатием вообще обращаться к компрессорам.

firestarter (26.10.2011 21:10:17)

exdupe maximumcompression fs compression

> lzo

В пакете отсутствуют исполнимые файлы. Использовать пакет lzop?

question4 (27.10.2011 0:12:01)

> www.linux.org.ru/news/opensource/6054950

Snappy? Спасибо, попробую, тем более ебилд уже есть.

question4 (27.10.2011 0:12:09)

> винрар

Чем он лучше нативного консольного rar-а? А заодно и виндового консольного?

question4 (27.10.2011 0:12:13)

> http://www.compression.ru/arctest/act/act-calg.htm

2002 год. Поновее нету?

question4 (27.10.2011 0:12:18)

> Snappy

Спасибо, смотрю...

> /Yappy.

А это что?

question4 (27.10.2011 0:12:22)

> минитест

Спасибо. Надеюсь, Linux.img — несжатый? :)

Насколько я помню, LZMA — 1-поточный. Даже если его научились распараллеливать, в программе lzma была старая версия алгоритма.

То есть 1-поточный LZMA сжимает на проценты медленнее, чем 2-поточный bzip2. А распаковывает вдвое быстрее.

Насколько я знаю deflate (в zip/gzip) — ещё быстрее LZMA.

То есть про pbzip2 можно не вспоминать.

question4 (27.10.2011 0:12:42)

> так это ж контейнеры, все едино

Я имел в виду методы, используемые в этих контейнерах по умолчанию. LZMA для 7z и deflate для zip.

> Скорость сжатия на третьей степени

Это как? «7z -mx=3» ?

> намного выше обычного deflate (тот самый, который в обычном зипе со времен pkzip), при этом сжимается лучше.

Попробую, спасибо. Но для «7z -tzip -mx=1», вроде получилось медленне, чем с «7z -tzip -mx=1» при несущественном выигрыше в сжатии.

> Скорость распаковки не измерял, мне было важнее, чтоб открывалось даже голой вендой :)

Достаточно взять версию 7-zip не ниже :)

> А так можешь взять 7z в руки да проверить на одном своем файле.

С -mx=1 сжимается полчаса.

question4 (27.10.2011 0:12:50)

> pigz (parallel gzip)

Спасибо. И большой выигрыш здесь даёт параллелизм? Будет ли прирост на 4-ядерном процессоре по сравнению с 2-ядерным?

question4 (27.10.2011 0:13:21)

Re: Какой архиватор сейчас самый быстрый?

> tar ... А за сжатием вообще обращаться к компрессорам.

Где взять патчи для tar-а для поддержки компрессоров pigz, lzop и snappy? ОС с кривой реализацией пайпов, tar чтототам | gzip работает через раз.

question4 (27.10.2011 0:13:31)

> http://exdupe.com/

Нет 32-битной версии.

К тому же закрытый. И ни одного стороннего отзыва в интернете не нашёл.

И возникают подозрения: зачем архиватору доступ к IPX, AppleTalk и /proc/net ?

> http://maximumcompression.com/data/summary_mf4.php

Автору нравится FreeARC :) Snappy в списке нет. Но в остальном хорошая таблица.

> http://extrememoderate.wordpress.com/2011/08/20/synthetic-test-of-filesystem-com...

Довольно специфическая задача. Но хотя бы показывает соотношение Snappy-LZO. Спасибо.

question4 (27.10.2011 0:13:48)

Та же фигня, только от Яндекса.

devl547 (27.10.2011 0:16:05)

>параллелизм

Попробуй lrzip от Коливаса. Он даже PAQ параллелит.

devl547 (27.10.2011 0:17:10)

> lrzip

Спасибо, посмотрю и его заодно.

Хотя в http://ck.kolivas.org/apps/lrzip/README ничего нет о параллелизме. И на файлах больше 10 гигабайт 32-битная версия проигрывает стандартным реализациям LZMA.

question4 (27.10.2011 0:37:52)

> Та же фигня, только от Яндекса.

Snappy с их патчами? Ссылку можно? А то в поиске одни чихуахуа.

question4 (27.10.2011 0:38:01)

tar?

shty (27.10.2011 0:39:13)

Я по его блогу сужу - он там подробности постоянно пишет.

devl547 (27.10.2011 0:41:28)

гоню, гоню. Но компрессор есть - http://blog.gamedeff.com/?p=371

devl547 (27.10.2011 0:43:10)

> tar?

Есть сильные подозрения, что что-нибудь быстро сжимающее и разжимающее (на основе LZO?) обработает большой объём хорошо сжимаемых данных быстрее. Будет меньше работы с диском.

question4 (27.10.2011 0:44:20)

обращаю внимание уважаемого:

>>скорость распаковки важнее

так что быстрее не будет

shty (27.10.2011 0:46:19)

> http://blog.gamedeff.com/?p=371

:)

Быстро. Но автор пишет, что на больших объёмах будет проигрывать Snappy.

Спасибо.

question4 (27.10.2011 0:53:19)

>>скорость распаковки важнее

> так что быстрее не будет

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

question4 (27.10.2011 0:58:22)

Плюсую tar :). А потом сверху любой компрессор.

post-factum (27.10.2011 0:58:31)

tar cf -O /dev/null??

etwrq (27.10.2011 0:59:53)

> tar cf -O /dev/null

Попробуй это запустить :) Заодно узнаешь размер /dev/null в архиве.

question4 (27.10.2011 1:10:07)

да, lzop.

bhfq (27.10.2011 1:10:09)

> Плюсую tar :). А потом сверху любой компрессор.

Который компрессор?

question4 (27.10.2011 1:10:20)

> да, lzop.

Спасибо.

question4 (27.10.2011 1:10:44)

xz, например.

post-factum (27.10.2011 1:22:57)

ну я подразумевал в качестве архиватора /dev/null. может выразился немного неправильно)

etwrq (27.10.2011 1:58:54)

> xz, например.

Никаких преимуществ перед LZMA из свежего 7-zip. Кроме сохранения атрибутов, которые в данном случае не играют роли, т.к. по умолчанию. И долго работает.

question4 (27.10.2011 3:19:41)

>> 2002 год. Поновее нету?

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

вот, к примеру, я еще с конца 90х помню что rar сжимает текст лучше чем zip
и я даже проверять не буду, уверен за 10 лет ничего не изменилось

>>Спасибо. Надеюсь, Linux.img — несжатый? :)

это образ какой-то вм, qemu чтоль
зх как там с сжатием, но уверен там много нулей ;)

anTaRes (27.10.2011 3:22:58)

> >> 2002 год. Поновее нету?

> алгоритмы обычно не меняются,

Неверно.

Кроме того, конкретные реализации важнее.

> даже если со временем изменились цифры - общее соотношение осталось прежним

Опять неверно.

> вот, к примеру, я еще с конца 90х помню что rar сжимает текст лучше чем zip и я даже проверять не буду, уверен за 10 лет ничего не изменилось

Учитывая, что zip не развивается с середины 1990-х, неудивительно. А вот про реализацию deflate в 7-zip я бы не был не столь уверен :)

Ещё контрпример: 15 лет назад rar уступал ha. Сейчас превосходит.

>> Linux.img

> это образ какой-то вм,

Так и запишем, с ядром линукса anTaRes не знаком :)

question4 (27.10.2011 9:51:37)

>> Так и запишем, с ядром линукса anTaRes не знаком :)

ядро тут не причем , это образ виртуалки
а что там внутри - хз, возможно она вообще пустая :)
но Вам же образы и сжимать, ткчто они тоже не всегда на 100% заполнены будут
и даже со степенью сжатия "1" можно будет раз в 5-10 ужать

вобшшем как определитесь - обнародуйте свое решение ;) интересно будет узнать что выбрали и почему

anTaRes (27.10.2011 13:36:27)

>Это как? «7z -mx=3» ?
угу

>Но для «7z -tzip -mx=1», вроде получилось медленне, чем с «7z -tzip -mx=1» при несущественном выигрыше в сжатии.
не понял, что с чем сравниваешь :) Deflate тормоз изначально, при этом ЕМНИП работает только в один поток

>Достаточно взять версию 7-zip не ниже :)
неа, в том и фишка, что открывается без сторонних приблуд

>С -mx=1 сжимается полчаса.
так отрежь от него кусок небольшой для теста

nu11 (27.10.2011 16:31:56)

xz сжимает лучше всяких bzip'ов и gzip'ов.

Eddy_Em (27.10.2011 16:37:37)