Современный архиватор-2016

Наверное, xz https://kernel.org/xz-by-default-and-json.html

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

COMPRESSION
dar can use compression. By default no compression is used. Actually gzip, bzip2, lzo, xz/lzma algorithms are available

Не то. Речь именно о cжатии файлов (сompressing), а не об упаковке в контейнер (archiving).

По-моему, xz -9e сжимает лучше 7z с ультра пресетом. Правда не ясно, почему ТС рассуждает про компрессоры, требуя архиваторы, но ладно. 7z кстати не сохраняет права если что, так что его только с архиватором в связке использовать можно, но мое сравнение чисто в плане уровня сжатия.

Хотя не, ну ладно. От исходных данных зависит, наверное. Кстати, как сжимать gzip лучше, например, как 7z умеет?

Я не теряю надежды, что когда-нибудь pigz -11 всё же закончит и я смогу оценить результат его работы.

то есть ли такой архиватор, который всегда сжимает лучше gzip и работает быстрее gzip

Everybody loves the perfect solution
To beat the odds against the poorest possible substitution
Poets Of The Fall — Revolution Roulette.

gzip — утка компрессоров, он одновременно жмет и плохо, и медленно. В чем-то одном gzip обставить легко кому угодно, но уже давным-давно надо бы перестать меряться с ним. Сейчас борьба в нише сильного сжатия закончилась где-то на xz -9 (и дальше уже некуда. им, по-моему, уже можно измерять количество информации), а вот за скоростное нетребовательное к ресурсам сжатие еще вовсю гоняются: lzo, lz4, snappy, zopfli, brotli...

И че-то все как с картинками: каждые два года новый формат жмет лучше, беспотерьнее и универсальнее, а воз и ныне там: в дикой природе лишь jpeg, png и gif. Хвала VCEG и Xiph.Org, хоть в видео и аудио есть надежда на лучшее.

есть ли такой архиватор, который всегда сжимает лучше gzip и работает быстрее gzip (без учёта многопоточности)?

Ты не так подбираешь. Плясать надо всего от двух чисел: скорости сжатия и распаковки.

Пример: надо закинуть сорцов на импотентный тапочек Raspberry Pi 2 в tmpfs? по идеальному гигабитному линку? Берем прикидывалку и смотрим: ага, lzo -1.

Пример 2: кидать надо на фиговую карту памяти с 10МБ/с? Ну это уже xz -7 со сдатем в полтора раза больше.

Для экономии мышления достаточно помнить с какой скоростью твои машины жмут xz -9, lz4 -9 и какой-нибудь brotli между ними.

(надо, кстати, перевести бекапы снапшотов на этот brotli, неплохо смотрится.)

Raspberry Pi 2
гигабитному линку

Не надо так шутить.

А че, там нету? Я просто не шарю в этом.

Там сотка на USB как была, так и осталась. И на третьей ничего не поменялось.

gzip оптимальный вариант, как по скорости, так и по сжатию
7z только если по сжать надо лучше, остальное не нужно

Вот чушь так чушь...

нет, не чушь, можешь тесты разные поискать и убедиться, что в среднем gzip жмёт достаточно при этом быстрый, другие или сильно жмут и медленее (7z) или наоборот

rar около gzip, но он как бы не нужен

Он перепутал с bzip2 просто, бывает. Что ты сразу обвинениями кидаешься.

а вот это уже чушь, ну ладно тогда

Вообще, постановка вопроса в первом сообщении надуманная.

RAR около xz/7z но хуже, балбес.

Выше по треду я давал ссыль. Поиграйся, выбери железо подесктопнее и погляди, сколько гигабит в 2016ом считается «достаточно быстрым».

zstd жмет в разы быстрее чем gzip а степень +-0.0%

bzip2/gzip. Первый если нужно умеренное сочетание сжатия и скорости, второй, если нужна скорость и хоть какое-то сжатие чтобы уж совсем явную избыточность убрать.

xz, если не лень тратить время и где сжатие требуется в смысле 1 раз сжать, много раз разжать, или предполагается много пользователей.

xz2

Самое то - 7zip или xz (LZMA2).
Хочешь изврата - lrzip.

Ты не так подбираешь. Плясать надо всего от двух чисел: скорости сжатия и распаковки.

Это всё понятно. Просто сейчас gzip — это такой своеобразный дефолт для случаев, когда вообще ничего не известно думать вообще не хочется. Т. е. им сжимают всё подряд. Начиная от веб-страничек и потоков данных SSH и заканчивая bzImage/initcpio.

Вопрос состоит в том, есть ли такой алгоритм, который мог бы претендовать на роль нового дефолта, т. е. не имеющий недостатков по сравнению gzip.

Сейчас борьба в нише сильного сжатия закончилась где-то на xz -9 (и дальше уже некуда. им, по-моему, уже можно измерять количество информации)

Не. Есть zpaq, есть PPM* (PPMd), а ещё можно lrzip'ом препроцессировать.

Потому что проблема терминологии. В русском языке и то, и то обычно называют «архиватор», слово «компрессор» AFAICS не прижилось.

А вообще да, спасибо за линк. Попробую как-нибудь взять их датасет и посчитать строгое превосходство.

Потыкав на те картинки ставлю на то, что

1) только новомодный brotli пытается закрыть эту никому не нужную нишу так себе сжатия с так себе скоростью.

2) он будет заруливать gzip на не стоящих перехода 10-20%.

3) все равно на каких-нибудь данных он по какому-нибудь параметру пару раз сольет gzip'у

Моя теория такова: и все это означает не то, что gzip удачен и хорош и годный дефолт, а то, что его диапазон скоростей и коэффициентов сжатия в этом тысячелетии уже почти никому не упал.

Для целей архивирования уже и xz -9 приемлемо быстро жмет.

Для «локального» сжатия «чтобы было» по типу встроенного в ФС на скоростях SSD и RAM нишу заняли lzo/lz4/...

Для «межузлового» сжатия 'compress once — decompress once' на хорошем линке людям нужно сжатие с compression speed / ratio по порядку равному скорости канала. Тут чтобы zlib'у с -1 сожрать ядро современного десктопа, нужны гигабит между узлами и три гигабита самих несжатых данных. Так как второй пункт есть не у всех, то сжимать хочется сильнее, только вот zlib с большими levels тормозить-то тормозит, а вот ratio не сильно поднимает в сравнении с bzip2 и xz. Как только процессора становится достаточно и для них — прощай, zlib.

Для раздачи одних и тех же данных многим потребителям через относительно медленный интернет — то же самое, но для decompression speed / ratio, то есть gzip совсем давно не у дел. Когда-то он был здесь mainstream'ом, но потом пришел bz2, а сейчас уже и xz -9 как-то быстровато разжимается.

Мораль: если отбросить совместимость, то «неуловимый Джо» gzip умеренно хорош в своей уже никому не нужной нише.

Опять оно выползло, это невменяемое t184256... Писать надо так, умник, чтобы понять могли и те, кто веществ не потребляет, так как ты.

Полный бред, если коротко и объективно.

Gzip неоптимальный вариант одновременно и по скорости и по уровню сжатия.

Отлично расписал, спасибо.

Для «локального» сжатия «чтобы было» по типу встроенного в ФС на скоростях SSD и RAM нишу заняли lzo/lz4/...

А на скоростях HDD? Собственно, был gzip, стал brotli.

Это уж больше на спец олимпиаду похоже... Универсальность важнее всяких этих копеек в выйгрыше

ps: https://m.youtube.com/watch?v=F3zLT9KMnbY

Ну тут ключевые слова «чтоб было».

Остаток поста посвящен попыткам проинтерпретировать «А на скоростях HDD?» в пользу gzip/brotli. Можно сразу читать итог.

Признаю, в моем видении мира есть дыра между сценарием «сжатие чтобы было» («А давайте вкорячим lzo в нашу btrfs, проц ведь не ест, а то ведь и IO может уменьшиться») и сценарием «сжатие до скорости канала» («Жмем тем, что позволяет нам выдавать сто мегабит»).

Твое «сжатие со скоростью отдачи HDD» действительно может пожпасть под gzip/brotli. Другое дело, что я не вижу пока реального сценария, где это надо. Вот мои попытки:

1) Допустим web-сервер отдает статический сжимаемый контент с скоростью HDD, где он лежит. Тогда его проще заранее пожать xz -9 и горя не знать.

2) Допустим web-сервер генерит и отдает ведрами уникальный сжимаемый контент. Тогда a) непонятно, откуда взяться привязке к скоростям HDD б) выделять на каждого пользователя по ядру как-то жирно.

3) Допустим мы дампим что-то с HDD в целях бэкапа и сжатие при этом используется для экономии места на диске назначения. Тогда интереснее взять уже lbzip -n4 -9 и заодно и сжать хорошо.

4) Допустим мы бэкапим что-то с HDD и почему-то нам плевать на степень сжатия (с той стороны мы его все равно распаковываем или перепаковываем, или там просто места хоть ложкой ешь). Тут уже поведение будет определяться шириной канала

4a) Если бэкап «близкий» (через гигабит по офису, например), то че-то вообще не очень понятно, зачем напрягаться и что-то сжимать вообще. Ну или сжимать чем-то отличным от lz4.

4б) Если бэкап «дальний» (в другую страну через пару десятков мегабит), то это уже территория (l)bzip2/xz.

4в) Если бэкап «средний» (по городу через сто мегабит, например), то тут, как я уже признал, gzip/brotli начинает смотреться интересно (сам я в таком сценарии просто написал lz4, чтобы не греть ни CPU, ни голову). Только вот сценарий не звучит особо популярным, а скорость HDD тут как бы уже немного и не при чем, ибо узкое место не там.

Ну и финальный облом: судя по тем замерам, zlib/brotli все равно не могут жать «скорость HDD» (гигабит) одним доступным простым смертным ядром CPU. То есть накормленный гигабитом brotli --quality 1 сожрет все ядро, захлебнется, и осиленные 600 мегабит из 1000 сожмет в 200. С точки зрения того, до кого как раз 200 мегабит — это идеально, да. С точки зрения того, до кого скорость выше — lzo/lz4. А для того, до кого скорость меньше, радужность ситуации начинает спадать; повышение compression level только портит итоговую полосу пропускания, так как компрессор станет захлебнется еще сильнее.

мда, че-то не клеится в моей модели. вроде бы sweet spot на текущий день должен быть как раз где-то там, да. только вот получается, что раздача гигабита, пожатого zlib/brotli, оптимальна для потребителя с каналом не более и не менее несколько сотен мегабит (иначе подойдут lzo/lz4 или захлебнется компессор). ситуацию могли бы поправить core i9 или параллельные компрессоры, да вот только SSD и гигабит в каждый дом придут раньше и прикончат эту нишу.

Итог: да, но нет. миру нужны xz для архивирования, медленных линков и сжатия заранее. миру нужны lzo/lz4 для SSD, гигабитов и сжатия «чтобы было» без раскручивания кулера. под zlib/brotli и нарочно фиг подберешь задачу; ни туда, ни сюда.

2834372 fei-mu-dc2undub.btlvfix.iso.pi.gz
2841248 fei-mu-dc2undub.btlvfix.iso.7z.gz
2896136 fei-mu-dc2undub.btlvfix.iso.vanilla.gz
4491436 fei-mu-dc2undub.btlvfix.iso

вот, с таким временем сжатия 7z и pi не актуальны. может ещё можно поиграться с размером блока, однако лично мне не интересно.

А мне zpaq понравился. Сейчас его использую очень часто. Особенно радует на фоне всяких «многопоточных» реализаций xz и gz. Т.к. в сам формат встроенная дедубликация - всё это дело там работает лучше и не сильно сказывается на степени сжатия. в итоге.

Кто знает многопоточные декомпрессоры, кроме формата bzip2?

(Пожалуйста, не надо напоминать о 10-и кратной разнице между скоростью компрессии-декомпресии. Хотя бы потому, что на 12+ ядерной машине всё уже не так радужно. Да и вопрос не в этом)

Посмотрел на data-set и не понимаю зачем нужен весь этот зоопарк.

zlib — хороший такой середнячёк. И жмёт хорошо и по скорости всё в порядке.

Две другие крайности: быстрый, но не жмущий lz4 и тормозной zpaq. Всё остальное в пределах погрешности.

Ну вообще-то там есть бротли, который заруливает zlib на скоростях обмена данными с жёстким диском. Собственно, это и есть ответ на вопрос треда.

Я про этот brotli в первый раз слышу. По графикам он кучкуется между zlib и zpaq. Т.ч. в чём профит?

Одно — устоявшийся и проверенный временем стандарт. Другое — невиданная новая зверушка с сомнительным преимуществом.

Вообще-то ZPAQ не тормозной.
Вот файлсет в 1 гигабайт: https://s3.amazonaws.com/10gb-benchmark/1gb.zpaq
Архивирование ZPAQ используя разные его пресеты:

метод 1 - 0m15.153s 419Mb
метод 2 - 1m7.464s 392Mb
метод 3 - 1m30.766s 358Mb
метод 4 - 3m59.808s 333Mb
метод 5 - 15m3.165s 319Mb

tar.gz - 0m47.775s 507Mb
tar.bz2 - 2m1.458s 480Mb
tar.xz - 6m.44.121s 400Mb
zpaq метод 1 - 0m42.632s 419Mb

У него скорость сжатия как у zlib, а ratio выше.

В сравнении не хватет xz с разными методами сжатия. По-умолчанию у него не «1»?

Смысл? xz однопоточный, любая реализация многопоточности xz резко бьёт по степени сжатия. А сейчас любой компьютер - это многоядерная система. И «современный архиватор» должен это использовать себе на пользу, а не во вред.
Если что для справки вы не читали мануал по ZPAQ - методы 1&2 это LZ77 алгоритм, метод 3 это BWT, метод 4&5 это CM(Контекстное моделирование). Т.е. метод 1 и 2 это аналог gzip, а 3 - bzip2.

любая реализация многопоточности xz резко бьёт по степени сжатия.

Пруф бы. И уж немало времени как в xz есть опции для многопоточности. На лоре обсуждалось.

Если не ставить себе задачу, что бы оно было на века и было переносимым, то почему бы и нет? Хозяин — барин. ;)

Кстати, zstd ещё немного лучше. Только у него опций сжатия нет. И формат не устаканенный. Вроде.

ничоси. xz в пределах погрешности?

Ух ты! Тут тесты провёл - и реально разница в потере степени сжатия небольшая.
На том 1Гб наборе результаты были такие:

xz 1 поток, сжатие 6 - 6m54s 400Mb
xz 8 потков, сжатие 6 - 1m23s 403Mb
xz 1 поток, сжатие 1 - 2m47s 452Mb
xz 8 потков, сжатие 1 - 0m34s 455Mb

xz 1 поток, сжатие 1 - 24m16s 2.89Gb
xz 8 потоков, сжатие 1 - 6m52s 2.93Gb

zpaq 8 потоков, метод 1 - 4m25s 408Mb

По умолчанию если использовать tar с ключём "-J" у xz выставляется степень сжатия «6».