В состав ядра Linux 3.11 принята (http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...) библиотека, реализующая алгоритм сжатия LZ4. Алгоритм LZ4 отличается от аналогов высокой скоростью работы. Например, в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатия и распаковки, обеспечивая сравнимую степень сжатия.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTQwODY
Новость: http://www.opennet.me/opennews/art.shtml?num=37404
> Например, в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатия и распаковки, обеспечивая сравнимую степень сжатия.Ага, а вот у меня их lz4c проигрывал lzop и по скорости и по объему выходных данных.
Сильно зависит от природы данных. Где-то лучше, где-то хуже. В среднем по больнице - он как правило несколько быстрее и при этом чуть лучше жмет, если в среднем по больнице. Но всегда можно найти набор данных удобный (или неудобный) для того и для другого, дабы выпятить конкурента. В целом это сравнимые алгоритмы одного класса ("скоростной LZ").
А где еще, кроме btrfs и всяких zram/zswap, используются такие библиотеки?
Образ ядра, initrd, ваш КО.
Разве ядро само сжимает/разжимает свой образ? Я думал, это делает система сборки/загрузчик.
> Разве ядро само сжимает/разжимает свой образ? Я думал, это делает система
> сборки/загрузчик.А это где как. Где-то загрузчик, где-то ядро. Возможны варианты.
> А это где как. Где-то загрузчик, где-то ядро.unzip.zip?
> unzip.zip?Пройти прямо и налево, спросить барона Мюнхаузена, он расскажет как такие приколы проворачивать. Программеры оценили байки по достоинству - теперь половина софта спокойно развлекается вытаскиванием себя за волосы из болота :)
А если серьезно, все просто: в начале ядра пишется небольшой кусок кода - декомпрессор (для LZ4 он простой как топор и мелкий). Ну вот он запускается загрузчиком как "ядро" а дальше ядро само себя и распаковывает.
Но какое отношение декомпрессор (который, по сути, является внешним кодом по отношению к самому ядру) имеет к встроенным в ядро библиотекам? Он же не может их использовать.
> Но какое отношение декомпрессор (который, по сути, является внешним кодом по отношению
> к самому ядру) имеет к встроенным в ядро библиотекам? Он жеОбычно под такое пишут мелкий оптимизнутый анпакер, который натурально отдельная сущность.
> Разве ядро само сжимает/разжимает свой образ? Я думал, это делает система сборки/загрузчик.Сжимает система сборки. Разжимает ядро само себя, в начало образа вставляется небольшой довесок на асме, который разжимает и передает управление.
zfs
Боюсь, оно вряд ли сможет так просто использовать библиотеку из ядра Linux.
там обертка солярка -> zfs модуль -> ядро
> там обертка солярка -> zfs модуль -> ядроРазве в ZFS кто-то будет добавлять работу с алгоритмами сжатия, которых нет в солярке?
Бехлендорф, разве что.
> Разве в ZFS кто-то будет добавлять работу с алгоритмами сжатия, которых нет
> в солярке?
> Бехлендорф, разве что.Давно на ОпенНете не были? ;-)
>Разве в ZFS кто-то будет добавлять работу с алгоритмами сжатия, которых нет в солярке?Дык - уже добавили :)
Чем оно лучше rar?
Быстрее и лучше жмет, например.
Жмет, в общем-то, хуже. Но намного быстрее, да.
Хуже чем rar? Вы серьезно?
> Чем оно лучше rar?Чем болид F1 лучше карьерного самосвала? Ну а что, оба - автомобили :)
RAR проприетарный.Лучше сравнивать с p7zip, tar/lzma, tar/xz.
Без tar, наверное.
> RAR проприетарный.Трындишь. Unrar - нет.
> Лучше сравнивать с p7zip, tar/lzma, tar/xz.
то что он freeware не мешает ему быть проприетарным, выдержка из лицензии:1. All copyrights to RAR and the utility UnRAR are exclusively
owned by the author - Alexander Roshal.
> то что он freeware не мешает ему быть проприетарным, выдержка из лицензии:
> 1. All copyrights to RAR and the utility UnRAR are exclusively
> owned by the author - Alexander Roshal.То, что у rar-а есть праообладатель, вообще говоря, не делает его проприертарным. Вот половина, большая, из остальных 10-ти пунктов http://ftp-master.metadata.debian.org/changelogs//non-free/r... -- да.
>> RAR проприетарный.
> Трындишь. Unrar - нет.http://ftp-master.metadata.debian.org/changelogs//non-free/u...
2. The UnRAR sources may be used in any software to handle RAR
archives without limitations free of charge, but cannot be used
to re-create the RAR compression algorithm, which is proprietary.
Distribution of modified UnRAR sources in separate form or as a
part of other software is permitted, provided that it is clearly
stated in the documentation and source comments that the code may
not be used to develop a RAR (WinRAR) compatible archiver.
> but cannot be used to re-create the RAR compression algorithm,
> which is proprietary.Ну простите, автор сам же и называет свой алгоритм проприетарным. Прямым текстом. Что еще надо?
И ограничения - совсем не в стиле открытого софта. EULA с сорцем в комплекте по сути.
>Чем оно лучше rar?Тем что оно сжимает, а не детектирует дебилов.
Еще один https://code.google.com/p/snappy/
> Еще один https://code.google.com/p/snappy/Плюсатая либа в ядре - no way, сам понимаешь. Хотя есть и порт на си. Но в свете наличия LZ4 и LZO смысл в нем не очевиден. Ну гугля то понятно что NIH укусил. На этом достоинства и заканчиваются. Потому как в среднем по больнице оно ничем не лучше того же LZ4 в общем то.
Оно не лучше, оно сильно хуже! снэппи хорошо работает на сильно разреженных данных. все типы лемпел-зива - на данных, в которых есть многобайтовые повторяющиеся последовательности. И на каком нибудь 10-12-битном шумноватом изображении не дадут такого результата который выдаст примитивнейший бит-пакер, ни по сжатию, ни тем более по скорости. то есть повторяя то что кто-то уже написал выше - все зависит от структуры данных! все алгоритмы сжатия работают на специфической структурированности в данных.
> Оно не лучше, оно сильно хуже! снэппи хорошо работает на сильно разреженных данных.Да на самом деле и на остальных работает.
> все типы лемпел-зива - на данных, в которых есть многобайтовые
> повторяющиеся последовательности.Ну спасибо, Кэп. Вообще, рассказывать о том как работает LZ тому кто разок написал анпакер одного их таких "простых LZ" - довольно интересное начинание :).
> И на каком нибудь 10-12-битном шумноватом изображении не дадут такого результата
Насчет скорости - у сабжевых LZ поиск совпадений минимальный. Скорость сжатия LZ компрессора зависит от того насколько быстро он забивает на поиск совпадений, в ущерб сжатию, разумеется. Чем быстрее забивает, тем хуже сжатие и выше скорость. Можно задетектировав плохо сжимающиеся данные вообще перейти к просто копированию, чтобы скорость не снижать. В целом упомянутые "быстрые LZ" достаточно универсальны. В хучем случае они просто не сожмут, но отработают все-равно достаточно быстро.
> который выдаст примитивнейший бит-пакер, ни по сжатию, ни тем более по скорости.Ну если заморачиваться классификацией данных, на что надо отдельное время и усилия, тогда и LZ можно костыли подставить в виде препроцессора, который сделает данные удобнее для сжатия. Таких трюков придумано немеряно, в том числе и для битмапов различной природы. Но это дополнительное время на классификацию и препроцессинг. Для скоростного универсального алгоритма сжатия который не знает что дадут на вход (например, компрессия в ФС или БД) это неприемлимо.
Кстати у LZ4 есть и режим генерации pre-compressed данных на случай если скорость сжатия не интересует а вот размер данных и скорость распаковки - важны.
Раз уж вы хотели с шумом и прочая - вот, получите:
$ ./lz4c -b0 photo2011_1.dng test.1
*** LZ4 Compression CLI , by Yann Collet (Jul 12 2013) ***
photo2011_1.dng : 11127342 -> 9333542 (83.88%), 205.5 MB/s , 1025.2 MB/s
То что доктор прописал - равка с матрицы. Шум и прочие прелести - в комплекте. Даже сжалось. Не сильно, зато на скорости 205Мб/сек. А распаковка так вообще гиг в секунду. Поди плохо, да?Если хочется сжать получше - оно и так умеет:
$ ./lz4c -b1 photo2011_1.dng test.1
*** LZ4 Compression CLI , by Yann Collet (Jul 12 2013) ***
photo2011_1.dng : 11127342 -> 7152148 (64.28%), 11.9 MB/s , 931.4 MB/sЭто если что в 1 поток было. При желании и распараллелить ведь можно - паковать разные субблоки на нескольких ядрах, например.
> то есть повторяя то что кто-то уже написал выше - все зависит от структуры данных!
Ясен перец. А LZO, LZ4 и прочие - это скоростные и не ресурсоемкие алгоритмы сжатия, которые не требуют предварительных знаний о структуре и типе данных и используются там где скорость роялит (запись на диск, отсылка по сети, ...). Это универсальные быстрые алгоритмы без претензий на максимальное сжатие и оптимальность во всех возможных случаях. Это "какое-то" сжатие. Зато быстро. Очень быстро. Как видите оно даже трудно жмущуюся равку прожевало на довольно убедительных 200 Мб/сек и даже уменьшило при этом размер на 1/5. К слову, скорость записи на винч где делался опыт - 120Мб/сек на внешних треках, так что такая компрессия может поднять скорость записи, даже на относительно неудачных данных. А на более удачных и подавно :)
> все алгоритмы сжатия работают на специфической структурированности в данных.
Конкретно эти LZ* задуманы быть generic скоростной давилкой данных без какого либо предварительного знания. Не чемпионские параметры, зато быстро.
задерка одна секунда на обороботку чанков
>в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатия и распаковки, обеспечивая сравнимую степень сжатия.В каких тестах? Какая версия LZO? По тестам автора LZO версия LZO-2012 сравнима и чуть-чуть обгоняет LZ4. При этом LZO уже давно есть в ядре.
>>в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатия и распаковки, обеспечивая сравнимую степень сжатия.
> В каких тестах? Какая версия LZO? По тестам автора LZO версия
> LZO-2012 сравнима и чуть-чуть обгоняет LZ4. При этом LZO уже давно
> есть в ядре.я бы сжимал lz4 man'ы и html документацию в репозитарии
ну и dpkg (apt-get) перелючил на lz4
> ну и dpkg (apt-get) перелючил на lz4Размер даунлоадов и сетевой траффик вырастут. Там скорее LZMA смотрелся бы нормально.
apt-get слишком медленный, дельта срезов нету
Полный шлак
> apt-get слишком медленный,Да нормальный. На SSD весьма бодренько пашет.
- Можно разогнать? Да, в несколько раз.
- Наступит профит? Не слишком заметный: даже на 50Мбит канале зачастую закачка занимает больше чем все остальное. Особенно для файрфоксов и прочих либрофисов. Так что в этом плане лучше сжатие поплотнее.> дельта срезов нету
Да и фиг с ними. Судя по чертыханиям некоторых на время этой операции.
> Полный шлак
Ух ты, какой жирненький. Иди сюда, цып-цып-цып-цып-цып :).
>apt-get слишком медленныйБыстрее, чем yum.
>дельта срезов нетуdebdelta
>> debdeltaUnresolved issues
- indexfile format for deltas or integration into main Packages.gz
- timeline for launchpad integration
- provide a sha256 of the uncompressed deb? currently the sha is build against the compressed deb, but that causes a unneeded compress/uncompress just for the signature checking
А я бы грудь женскую в руках сжал, это способствует развитию мелкой моторики особенно мелкая грудь
Продолжай сжимать то, что сжимаешь, это способствует росту волос на ладонях.
Собственный опыт или стороннее наблюдение?
> Собственный опыт или стороннее наблюдение?Посоны на переменке рассказывали.
>dpkg (apt-get) перелючил на lz4DEB переводят на XZ и правильно делают.
Лет через 10 они узнают и про lz4.
> Лет через 10 они узнают и про lz4.Технология должна созреть (поднимает палец вверх)!
> Лет через 10 они узнают и про lz4.LZO уже фиг знает сколько есть. Вот только распаковка сама по себе - далеко не основная статья расходов времени пакетного манагера как правило.
>>>в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатия и распаковки, обеспечивая сравнимую степень сжатия.
>> В каких тестах? Какая версия LZO? По тестам автора LZO версия
>> LZO-2012 сравнима и чуть-чуть обгоняет LZ4. При этом LZO уже давно
>> есть в ядре.
> я бы сжимал lz4 man'ы и html документацию в репозитарии
> ну и dpkg (apt-get) перелючил на lz4И зачем? LZO и LZ4 нужны там, где требуется большая скорость упаковки/распаковки на лету, например, для данных на уровне ФС. Собирать пакеты и генерировать документацию ты явно не будешь с такой интенсивностью, чтобы упираться в производительность более медленных алгоритмов сжатия, потому логичнее использовать их (например, LZMA) для улучшения качества сжатия, что, впрочем, и без наших с тобой советов уже делается.
>> Собирать пакеты и генерировать документацию ты явно не будешь с такой интенсивностьюУвы но это так
Сколько в граммах^W - сколько манов в в секунду? :)
> В каких тестах? Какая версия LZO? По тестам автора LZO версия
> LZO-2012 сравнима и чуть-чуть обгоняет LZ4.Да на самом деле где как. В среднем по больнице - у меня есть ощущение что LZ4 таки немного шустрее и при этом чуть лучше жмет. По поводу чего - пусть себе будет. Жалко чтоли?
> При этом LZO уже давно есть в ядре.
С этим никто и не спорит...
>Жалко чтоли?Мне нет. А вот разработчикам ядра — жалко.
https://lkml.org/lkml/2013/1/29/145
> Мне нет. А вот разработчикам ядра — жалко.Ничего не знаю, либа прилетела в ядро. В торвальдсовском гите лежит уже.
Во, нашёл ссылку.
https://lkml.org/lkml/2013/2/26/361
> Во, нашёл ссылку.
> https://lkml.org/lkml/2013/2/26/361Но стоит все-таки понимать что там:
From "Markus F.X.J. Oberhumer" <>Ну да, для програмера все просто - подыграл себе лишний раз и порядок. Ну подумаешь, запатчил немного у себя в кулуарах :)
Маркус, вообще-то, за таким замечен не был. и компрессией далеко не первый год занимается.а вообще — да, плохой, вредный программер. взял — и ускорил свой код, гад такой.
> Маркус, вообще-то, за таким замечен не был. и компрессией далеко не первый год занимается.Как бы это сказать? Не следует забывать что програмеры склонны делать себе скидки :). Помнится сам же Оберхамер и упоминал что его оптимизации возымеют эффект далеко не везде.
> а вообще — да, плохой, вредный программер. взял — и ускорил свой код, гад такой.
FYI, этот дяденька сколько-то лет пилил коммерческий LZO Pro и не особо чесался в открытой версии чего-либо улучшать, покуда не оказалось что тут LZ4 оказывается какой-то там появился и работает лучше, так что народ на LZO кивает что это уже как бы и не чемпион, и вообще есть алгоритмы лучше :).
Ну а тут то да - пришлось для восстановления репутации шашкой помахать. То что он в компрессии разбирается - спору нет. Но в паблик изначально ушла несколько ослабленная относительно Pro версия, которую довольно долго никто потом не улучшал. Дяденьк Pro версией барыжил. Ну, как бы, его право. А право остальных - обштопать публичную версию по параметрам, что и получилось с LZ4 "в среднем по больнице".
LZO - хорошо плючит текст.
LZMA - бинари и смешанное.
LZ4 - быстрее, по размеру жирнее LZO и раза в два LZMA
> LZO - хорошо плючит текст.Хорошо плющат текст всякие там PPM-based и тому подобные странные конструкции типа моделировщиков контекста и т.п. эзотерика, только у таких обычно сжатие тормозное + распаковка столь же ресурсоемка как и сжатие. Характерный пример - упаковщики семейства paq :). Но зато степень сжатия заставляет остальных завидовать, да.
LZO - довольно generic давилка, он никак не оптимизирован особо на текст или что-либо еще. У него нет ни препроцессоров ни фильтров на что либо. Скоростной LZ без нифига.
> LZMA - бинари и смешанное.
Он и текст лучще сожмет чем LZO в общем случае - просто потому что за скоростью сжатия не гоняется и потому намного лучше ищет совпадения в LZ, да потом еще додавливает второй стадией (о чем намекает суффикс "MA"). Зато скорость сжатия - понятно какая. Чем злее поиск совпадений тем дольше сжатие. К тому же фаза дожатия еще есть. По той же причине он и на распаковке медленнее. Но будучи вариантом LZ распаковка там все-таки доволно резвая, как и у всех LZ-based.
> LZ4 - быстрее, по размеру жирнее LZO и раза в два LZMA
А LZ4 от LZO не так уж далеко ушел по своим свойствам. Скоростные LZ без фазы дожатия чем-то еще - все на одно лицо и похожи по общим свойствам :).
> в проведённых тестах LZ4 почти в два раза обгоняет LZO по скорости сжатияВ проведённых _ДО оптимизации LZO в ядре_ тестах.
всё равно криво будет и тормозно. меня больше интересует когда же свободные драйвера для mali, vivante, и videocore4 наконец то с аппаратным ускорением, будут?
> всё равно криво будет и тормозноНу вас никто не заставляет пользоваться ни этим алгоритмом, ни ядром Linux. Вы в вашем праве пойти на хутор бабочек ловить.
> меня больше интересует когда же свободные драйвера для mali, vivante, и videocore4
> наконец то с аппаратным ускорением, будут?Если интересует - редактор и компилер в зубы.
Скорость я не мерял, а вот сжатие - отстаёт ОТО ВСЕХ:
1 993 281 text.uha
2 078 111 text.7z
2 093 050 text.rar
2 739 255 text.mht.lz4
3 243 240 text.mhtСжимался последний в списке MHT-шник - казалось бы, идеальнее данных не найти!
(уровень сжатия во всех компрессорах максимальный)
> Скорость я не мерял, а вот сжатие - отстаёт ОТО ВСЕХ:
> 1 993 281 text.uha
> 2 078 111 text.7z
> 2 093 050 text.rar
> 2 739 255 text.mht.lz4
> 3 243 240 text.mhtКто из них уже есть в ядре? И в ARM?
> Скорость я не мерял,Мсье большой оригинал - не померял один из ключевых параметров алгоритма "скоростной LZ" :)
Вообще-то есть разные классы алгоритмов. Кто-то старается сжать получше. А кто-то нацелен на обработку кучи данных в приближенных к реалтайму условиях. Например при записи на диск или при отправке по сети, с минимальными задержками и затратами ресурсов на этот процесс.
То-есть те кто жмет хорошо но долго. И есть те кто "как-то жмет", зато - зверски быстро.
Я вот показал простой пример - достаточно неудачный файл aka лобовой RAW с матрицы камеры сжался со скоростью 200Мб/сек и при том все-таки похудел на 1/5. С учетом скорости записи на диск 120Мб/сек, так даже профит в скорости I/O операций можно поиметь. Прошу показать сжатие равки с камеры на скорости 200Мб/сек вашими uha, 7z, rar или кем там еще. На обычном десктопнике, ясен перец.
> 3 243 240 text.mht
"Видно птицу по помету".
В соревнованиях болида F1 и Белаза болид приехал к финишу в 20 раз быстрее а белаз привез 10 тонн песка. Мнения судей о том кому присудить победу разделились.