The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Компания Google представила новый алгоритм сжатия данных Brotli

22.09.2015 12:38

Компания Google анонсировала алгоритм сжатия данных Brotli, который отнесён к алгоритмам сжатия общего назначения, но позиционируется как решение для минимизации объёма данных, передаваемых по сети. Спецификация Brotli передана в комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры Интернет, в качестве претендента на получение звания интернет-стандарта. В настоящее время Brotli уже применяется в качестве алгоритма сжатия шрифтов Web Open Font Format 2.0. Эталонная реализация Brotli написана на языке С++ и распространяется под лицензией Apache 2.0.

Brotli демонстрирует уровень сжатия, сопоставимый с лучшими современными методами сжатия общего назначения, но опережая их по скорости кодирования и декодирования. Например, в тесте Canterbury Corpus алгоритм Brotli превосходит по уровню сжатия LZMA и bzip2 и при этом меньше потребляет ресурсов CPU. По производительности Brotli близок к алгоритму Deflate, но превосходит его по степени сжатия. По сравнению с представленным в 2013 году алгоритмом Zopfli, совместимым с Zlib и Deflate, Brotli позволяет сжимать данные на 20–26% эффективнее.

Brotli является комбинацией современного варианта алгоритма LZ77, адаптивного кодирования Хаффмана и методов контекстного моделирования второго порядка. Более высокий уровень сжатия по сравнению с LZMA и bzip2 достигается применением контекстного моделирования второго порядка, повторным использованием кодов энтропии, более крупным размером окна кодирования и использованием совместных кодов распределения (joint distribution code). Компания Google надеется, что в скором времени поддержка данного формата будет реализована во всех основных браузерах (в рамках поддержки Web Open Font Format 2.0), что позволит уменьшить размер передаваемых данных и, как следствие, приведёт к меньшему потреблению энергии при открытии контента на мобильных устройствах.

  1. Главная ссылка к новости (http://google-opensource.blogs...)
  2. OpenNews: Компания Google представила совместимый с zlib алгоритм сжатия Zopfli
  3. OpenNews: Компания Google открыла исходные тексты библиотеки регулярных выражений RE2
  4. OpenNews: Компания Google открыла код Snappy, библиотеки для сжатия данных
  5. OpenNews: Автор LZ4 представил новый быстрый и эффективный алгоритм сжатия ZSTD
  6. OpenNews: Выпуск библиотеки сжатия LZHAM 1.0, нацеленной на создание более быстрой альтернативы LZMA
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/43006-zopfli
Ключевые слова: zopfli, compress
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (84) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 13:17, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    цитата кода
    "#define NUM 9  /* Good value: 9. */"
     
     
  • 2.3, Crazy Alex (ok), 13:20, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +16 +/
    В подобной алгоритмике экспериментально подобранные "хорошие значения" сплошь и рядом, особенно на ранних этапах. Иногда потом теория под них находится, иногда - нет.
     
     
  • 3.28, Аноним (-), 15:54, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –5 +/
    возможно, аноним имел ввиду что лучше написать "const int NUM = 9;"
     
     
  • 4.30, pavlinux (ok), 16:29, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +13 +/
    А чё не " const static unsigned short volatile const NUM __attribute__ ((aligned (16))) = 0b1001u;" ?
    Ну так, чисто чтоб всех анонимов сразу в моск пробило. :)
     
     
  • 5.33, Sw00p aka Jerom (?), 17:44, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    убил
     
     
  • 6.43, pavlinux (ok), 19:57, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > убил

    Чорт, забыл inline

     
     
  • 7.46, Аноним (-), 20:52, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    И дважды const поставил.
    А вот register - забыл.
     
     
  • 8.47, pavlinux (ok), 22:05, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Курить стандарт срочно Туда же ... текст свёрнут, показать
     
     
  • 9.51, Аноним (-), 22:32, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Вам бы самому тоже не помешало ... текст свёрнут, показать
     
     
  • 10.52, pavlinux (ok), 23:37, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Слив засчитан ... текст свёрнут, показать
     
     
  • 11.66, Аноним (-), 19:49, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    О, Ктулху, что тебя разбудило ... текст свёрнут, показать
     
     
  • 12.69, pavlinux (ok), 20:28, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Осень, велосезон заканчивается, обострение -P ... текст свёрнут, показать
     

  • 1.2, Аноним (-), 13:20, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    оффтоп: изнутри наружу =)
     
  • 1.4, anonymous (??), 13:20, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Почему Хаффман, а не арифметическое кодирование?
     
     
  • 2.5, Crazy Alex (ok), 13:21, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому что хаффман быстрее, скорее всего.
     
     
  • 3.49, Аноним (-), 22:28, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    К тому же вокруг арифметического кодирования патентов много.
     
     
  • 4.63, anonymous (??), 12:49, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Патент IBM уже давно истек
     
     
  • 5.65, Andrey Mitrofanov (?), 19:30, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    #>патентов много.
    > Патент IBM уже давно истек

    Один из "много"?  АргУмент.

     

  • 1.6, Crazy Alex (ok), 13:23, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то с графиком странное. deflate:1 медленнее deflate:9? Что за бред?
     
     
  • 2.9, Аноним (-), 13:30, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    все с ним в порядке.....это у вас там...
     
  • 2.10, z (??), 13:34, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чем больше распаковывается данных из окна совпадений - тем быстрее, т.к. это hot cache, при низком сжатии данные распаковываются меньшими частями, т.е. чаще вычитываются из входного потока, который тоже больше
     
     
  • 3.12, Crazy Alex (ok), 13:40, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А, ну да. Decompression же.
     
     
  • 4.13, z (??), 13:43, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Поздно, меняй ник
     

  • 1.8, Аноним (-), 13:27, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Гугл таки купил Pied Piper?
     
     
  • 2.38, dr Equivalent (ok), 18:19, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не, это они Nucleus переименовали.
     

  • 1.14, Crazy Alex (ok), 14:09, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Мда, основной вывод - gzip можно выкидывать окончательно - эта штука его перекрывает полностью - и на 1 и на 9 жмёт быстрее и лучше и распаковывает быстрее, чем gzip на аналогичном уровне. bzip2 и подавно идёт лесом - при сравнимом сжатии скорость различается в разы.

    А вот lzma в скорости сжатия при сравнимом ratio новичок проигрывает, хотя распаковывает быстрее - то есть надо выбирать в зависимости от задачи. Хотя, моежт, можно уровень 10 подобрать, чтобы был сравним - тогда получится совсем универсал.

     
     
  • 2.17, Аноним (-), 14:42, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    gzip (как и zip), скорее всего, не выкинут, ибо совместимо с любыми системами. А bzip2 уже давно можно выкидывать - примерно со времен появления xz.
     
     
  • 3.19, Crazy Alex (ok), 15:12, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Там, где сжимаешь чаще, чем распаковываешь (бэкапы те же) bzip2 часто интереснее.

    А совместимость... нарастёт со временем. Во всяком случае, понятно, в какую сторону двигаться.

    Но о zip я ничего не говорил. zip, в отличие от, стал скорее контейнером, чем компрессором. Там само сжатие вообще не критично в большинстве случаев.

     
     
  • 4.67, Аноним (-), 19:52, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Там, где сжимаешь чаще, чем распаковываешь (бэкапы те же) bzip2 часто интереснее.

    Ничем он не интересный: ресурсоемкий и на сжатие и на распаковку и плохо (по сравнению с другими сильными компрессорами) жмет.

    > Но о zip я ничего не говорил. zip, в отличие от, стал скорее контейнером,

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

     
     
  • 5.77, Crazy Alex (ok), 02:57, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Cильные - жмут дольше, вообще-то, потому bzip2 и лучше. А в случае тех же бекапов в большинстве случаев их вообще не приходится ни разу распаковывать, а если приходится - время не сильно критично. Но это всё от конкретного случая зависит, конечно.

    zip - ну ограничения, но обычно это не особо важно. Часто вы встречали те же офисные документы или jar, которые в эти ограничения не укладываются?

     
     
  • 6.80, Аноним (-), 23:12, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще, сильно зависит от настроек разогнать большинство сильных алгоритмов с... большой текст свёрнут, показать
     
  • 2.29, хрю (?), 16:25, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >Мда, основной вывод - gzip можно выкидывать окончательно

    Есть мнение, что gzip вас переживёт.

     
     
  • 3.45, Crazy Alex (ok), 20:34, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Кхм, ну, пережить меня - это вряд ли, но да, древний мусор болтается долго, даже не имея вообще никаких преимуществ. Что весьма печально.
     
     
  • 4.72, Аноним (-), 00:44, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Crazy Alex ... Саша, ты дурак!
    На "старьё" ресурсы не тратятся. Лежит оно где то в тёмных углах /*bin/* и жрать не просит. Раз в пятилетку его надо перекомплять текущим набором компиляторов, пересобитать с текущей версией [g]libc и прогонять тесты на текущих оЗЪ.вёдрах. Всё. И это изюавит тебя от эшелона гиммороя, если старьё реально выкинуть. АЗЪ!
     
     
  • 5.74, Аноним (-), 01:46, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    и как, много нынче желающих таскать древний compress? Вот gzip куда-то туда же уже метит. Поганенько жмет при том что ресурсоемкость у него вполне себе на уровне иных "LZ+дожатие".

    У gzip и вообще deflate - максимум словарь в 32 кило. Это не память, это склероз.

     
  • 2.58, Ytch (ok), 03:59, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они разве что про ресурсы как-то тактично умолчали или это я с ходу не нашел ... большой текст свёрнут, показать
     
     
  • 3.61, Crazy Alex (ok), 09:59, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ниш со слабыми ресурсами становится всё меньше и так, разумеется, будет и дальше. Что до разницы архитектур - как минимум, между ARM и x86 я неожиданых различий в плане скорости не видел на довольно широком диапазоне задач - приходится по работе обращать внимание на это.
     
     
  • 4.71, Ytch (ok), 23:33, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В не бытовухе ресурсы систем растут далеко не так стремительно, хоть в целом и... большой текст свёрнут, показать
     
  • 3.88, arisu (ok), 23:10, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    ну, если загнуть все параметры по максимуму 8212 задумается надолго, а прирос... большой текст свёрнут, показать
     
  • 2.87, arisu (ok), 23:03, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Мда, основной вывод - gzip можно выкидывать окончательно - эта штука его
    > перекрывает полностью

    особенно по размеру кода и размеру бинарей.

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

    и словарь, словарь… фэйспалм.

     

  • 1.15, vitalif (ok), 14:37, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    только щас представила? эта хрень же в WOFF2 уже хз сколько времени используется
     
     
  • 2.34, Аноним (-), 17:59, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    что это "WOFF2"?
     
  • 2.35, Andrey Mitrofanov (?), 18:07, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > только щас представила?

    "Google анонсировала" + "Спецификация Brotli передана [...] в комитет"

    > эта хрень же в WOFF2 уже хз сколько времени используется

    "В настоящее время Brotli уже применяется в качестве алгоритма сжатия шрифров Web Open Font Format 2.0."

    Трудная языка? Понимаю.  Читаю новости вверху -- дорого, паяльник свой.

     

  • 1.16, Аноним (-), 14:41, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Круто, конечно, но не очень понятно при чем тут Интернет. Чтобы им что-то начали жать, надо еще стандартизировать что и когда можно жать и как клиент с сервером об этом могут договориться.
     
     
  • 2.21, Crazy Alex (ok), 15:13, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот они и подали для стандартизации.
     
  • 2.89, arisu (ok), 23:12, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Круто, конечно, но не очень понятно при чем тут Интернет.

    при том, что они собрали дурных размеров словарь из обрывков слов, чтобы «лучше жать страницы».

     

  • 1.18, Аноним (18), 14:46, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Проталкивают новый формат, а сами не удосужились даже bzip, lzma, ppmd реализовать. В итоге будет как с WebP.
     
     
  • 2.20, Crazy Alex (ok), 15:13, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем реализовывать заведомо худшие алгоритмы?
     
     
  • 3.22, Аноним (18), 15:15, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А зачем реализовывать заведомо худшие алгоритмы?

    Сейчас Chrome поддерживает только gzip, deflate. Перечисленные выше алгоритмы явно лучше этих.

     
     
  • 4.24, Crazy Alex (ok), 15:27, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну вот этот и реализуют. Чем убьют любой смысл использования в вебе чего-то кроме. Это, конечно, злоупотребление монопольным положением - но в данном случае я буду аплодировать стоя, потому что иначе старыфе алгоритмы ещё лет десять не подохнут.
     
     
  • 5.25, Аноним (18), 15:31, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Ну вот этот и реализуют. Чем убьют любой смысл использования в вебе
    > чего-то кроме. Это, конечно, злоупотребление монопольным положением - но в данном
    > случае я буду аплодировать стоя, потому что иначе старыфе алгоритмы ещё
    > лет десять не подохнут.

    Firefox и остальные как будет на такую монополию смотреть? Конечно же точно также как и на WebP. Тот тоже был лучше и убивал всякий смысл продолжать использовать JPEG, а воз и ныне там.

     
     
  • 6.36, SysA (?), 18:08, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> Ну вот этот и реализуют. Чем убьют любой смысл использования в вебе
    >> чего-то кроме. Это, конечно, злоупотребление монопольным положением - но в данном
    >> случае я буду аплодировать стоя, потому что иначе старыфе алгоритмы ещё
    >> лет десять не подохнут.
    > Firefox и остальные как будет на такую монополию смотреть? Конечно же точно
    > также как и на WebP. Тот тоже был лучше и убивал
    > всякий смысл продолжать использовать JPEG, а воз и ныне там.

    Firefox ка бы почти Chrome уже... :)

     
  • 6.75, Аноним (-), 01:49, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Firefox и остальные как будет на такую монополию смотреть? Конечно же точно
    > также как и на WebP.

    Да им тоже прилетело за такую некооперативность: на их apng тоже как-то подзабили.

    И вообще, если мозилла будет щелкать клювом - ну ок, у юзерей хрома контент пожатый более сильным алгоритмом будет грузиться быстрее. А юзеры лисы опять в минусе? Ну ок, тогда пусть мозилла не обижается когда у нее останется 2% как у оперы.

     
  • 6.91, Crazy Alex (ok), 20:52, 26/01/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А файрфокс посмотрел... и поддержал в выпуске 44: http://www.opennet.ru/opennews/art.shtml?num=43764
     
  • 2.26, фыва олдж (?), 15:32, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > bzip, lzma, ppmd

    Почитай про zip-бомбы, про скорость сжатия.

     
     
  • 3.27, Аноним (18), 15:40, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Почитай про zip-бомбы, про скорость сжатия.

    И? gzip и Brotli точно также подвержены этому. Это концептуальная проблема любой архивации, единственным способом нейтрализации которой, являются выставление лимита размера распакованных данных.

     
  • 2.48, vitalif (ok), 22:11, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    оно для веба слабо годится
     
  • 2.70, Яро Ш. Я. (?), 21:52, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >В итоге будет как с WebP

    С WebP всё прекрасно - я все скриншоты только им и кодирую. Визуально качество как jpeg, а весит в разы меньше

     
     
  • 3.76, Аноним (-), 01:50, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > С WebP всё прекрасно - я все скриншоты только им и кодирую.
    > Визуально качество как jpeg, а весит в разы меньше

    Вообще-то для скриншотов PNG есть. Он вообще lossless. Размер правда как повезет, однородная графика жмется хорошо, а градиентная... ну это не жыпег.

     
  • 3.78, Аноним (18), 03:55, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    >С WebP всё прекрасно

    Конечно. Но открыть можно только Chrome и Opera которая фактически Chrome.

     
  • 3.81, Аноним (-), 23:17, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > С WebP всё прекрасно - я все скриншоты только им и кодирую.
    > Визуально качество как jpeg, а весит в разы меньше

    ...но есть способ лучше! BARF! http://mattmahoney.net/dc/barf.html - сжимает вообще любые файлы. Быстро. До 0 байтов. И даже может распаковать обратно.

    ...но правда те кто немного знает математику, начнут что-то подозревать, хотя формально он делает именно то что заявлено :)

     

  • 1.31, Аноним (-), 16:45, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Почему они взяли "LZMA implementation in 7zip 9.20.1"?
    7zip 9.20 был выпущен 2010-11-18 и не использовал LZMA2
     
     
  • 2.32, Ан (??), 17:19, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    По умолчанию не использовал, но поддержка LZMA2 там уже была.

    Вообще эти черти удивляют. Зачем они столько времени бету гоняют и не делают релиз?

     

  • 1.37, абвгдейка (ok), 18:11, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    забавно, судя по графику, он вообще-то на 20% сильнее сжимает, чем deflate9, при этом на 18% медленнее. Так что не надо спешить и сломя голову бросаться менять ваши системы :)
     
     
  • 2.39, Аноним (-), 19:09, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мы разные графики смотрим? Brotli1 и 9 во всех номинациях лучше/быстрее deflate1 и 9, соотв-но.
     
     
  • 3.40, абвгдейка (ok), 19:30, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    разные deflate9 быстрее Brotli1
     
     
  • 4.44, Crazy Alex (ok), 20:32, 22/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    deflate9 надо менять на Brotli9 - будет быстрее и сжатие, и распаковка, и лучше ратио
     
     
  • 5.53, абвгдейка (ok), 00:17, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    это если сравнивать "ратио", а если, как гугл, сравнивать "скорость", то получается наоборот :)
     
     
  • 6.56, Crazy Alex (ok), 00:27, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Так у него и скорость больше. Можете pdf открыть, там цифры есть. deflate проигрывает вообще по всем статьям.
     
     
  • 7.90, arisu (ok), 23:18, 30/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Так у него и скорость больше. Можете pdf открыть, там цифры есть.
    > deflate проигрывает вообще по всем статьям.

    а теперь ограничим доступную память 64-мя килобайтами.

     

  • 1.50, Ilya Indigo (ok), 22:30, 22/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как его самостоятельно с p7zip сравнить по скорости, степени сжатия и потреблению ресурсов?
     
     
  • 2.57, Crazy Alex (ok), 00:29, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    В новости есть сылка на гитхаб
     

  • 1.59, Аноним (-), 08:57, 23/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    гугл таки купил фирму "пегий дудочник" (крысолов) ? =D
     
  • 1.60, Аноним (-), 09:39, 23/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И чем же он лучше arj?
     
  • 1.62, Джо (?), 10:30, 23/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    а что там насчет lzo
     
     
  • 2.68, Аноним (-), 19:54, 23/09/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > а что там насчет lzo

    То же что и LZ4: алгоритмы другой весовой категории. Они на скорость ориентированы, при приемлимом сжатии. А эти - на степень сжатия, при приемлимой скорости. Очень разные оптимизации.

     
  • 2.83, Led (ok), 01:30, 26/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > а что там насчет lzo

    Не нужен при наличии lz4

     

  • 1.64, Аноним (-), 13:01, 23/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    какой у него коэффициент Вальцмана?
     
     
  • 2.73, Аноним (-), 01:21, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > какой у него коэффициент Вальцмана?

    7

     

  • 1.79, Аноним (-), 13:38, 24/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    с ходу что получилось
    hobot@SERVER:~/WORK/brotli/tools# time cat bro |./bro > bro.bro

    real    0m2.487s
    user    0m2.444s
    sys     0m0.040s
    hobot@SERVER:~/WORK/brotli/tools# ls -lh /bin/^C
    hobot@SERVER:~/WORK/brotli/tools# time cat bro |gzip > bro.gzip

    real    0m0.053s
    user    0m0.044s
    sys     0m0.008s
    hobot@SERVER:~/WORK/brotli/tools# ls -lh ./bro*
    -rwxr-xr-x 1 root root 947K сент. 24 12:33 ./bro
    -rw-r--r-- 1 root root 243K сент. 24 12:35 ./bro.bro
    -rw-r--r-- 1 root root 426K сент. 24 12:35 ./bro.gzip

    2.4 секунды с bro и 50ms с gzip

     
     
  • 2.82, Аноним (-), 23:22, 24/09/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > 2.4 секунды с bro и 50ms с gzip

    А ничего что bro у вас кажись фигарил с максимальным сжатием? И в результате уделал gzip-а по сжатию ... всего-ничего, В ДВА РАЗА. И да, там нелинейная зависимость: улучшить результат сжатия в 2 раза вообще удается далеко не всегда и тем более это сложнее не в 2 раза. Поиск например более удачных совпадений, повышающий степень сжатия - очень быстро становится крайне медленной операцией. Практические реализации LZ-based - забивают по некоторому таймауту на поиск "еще более удачного совпадения", иначе они будут вкалывать ооооочень долго.

     
  • 2.84, Аноним (-), 13:58, 26/09/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Предполагаю, что результаты вашего теста некорректны, т.к. в первом случае файл поднимался с диска, а во втором уже из page cache.
     

  • 1.85, Evolve32 (ok), 07:31, 28/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему они про zstd забыли в тесте?
     
  • 1.86, arisu (ok), 22:58, 30/09/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    …а ещё дурацкого словаря, высосаного из… неизвестно октуда (обрывки русского в нём умилили), и дичайших тормозов при попытке чуть‐чуть подкрутить уровень сжатия. плавали, знаем, не впечатлило.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру