The OpenNET Project / Index page

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

Facebook опубликовал реализацию алгоритма сжатия Zstandard 1.0

01.09.2016 10:49

Facebook опубликовал первый стабильный релиз библиотеки и инструментария для работы с новым эффективным алгоритмом сжатия данных Zstandard, готовый для промышленного внедрения. Алгоритм подходит для организации сжатия в режиме реального времени и может рассматриваться как оптимальный компромисс, между быстрым но неэффективым lz4 и медленным но хорошо сжимающим xz. Zstandard, по сравнению с zlib/Deflate, демонстрирует в 3-5 раз более высокую скорость сжатия и в два раза более быструю распаковку, при уровне сжатия выше на 10-15%. Код написан на языке Си и распространяется под лицензией BSD. Алгоритм разработан Яном Колле (Yann Collet), автором эталонной реализации алгоритма LZ4, который ныне работает в Facebook.

В Zstandard задействован метод кодирования конечного состояния энтропии (Finite State Entropy), в котором для кодирования энтропии применяется теория асимметричных численных систем (Asymmetric Numeral Systems). Эффективность и скорость сжатия в Zstandard очень близка к предложенному Google алгоритму brotli, но Zstandard почти в три раза быстрее при распаковке. По скорости сжатия и распаковки Zstandard заметно отстаёт от Snappy (330 и 940 MB/s против 480 и 1600 MB/s), но опережает его по уровню сжатия почти на 30%.

Особенностью Zstandard является возможность тренировки для повышения эффективности сжатия мелких наборов данных. Алгоритм можно оптимизировать для определённого типа данных, сформировав словарь на основе предварительно предоставленных примеров. Словарь загружается до сжатия или распаковки и позволяет существенно повысить степень сжатия для типовых данных. Например, использование словаря, размером 64 Кб позволяет увеличить уровень сжатия с 2.8 до 6.9 при упаковке данных о 1000 пользователях GitHub (846 Кб со словарём сжимается в 122 Кб, а без в 300 Кб).

В отличие от zlib в Zstandard также предоставлены гибкие средства для использования доступных аппаратных возможностей - поддерживается распараллеливание операций на многоядерных CPU. Под окно сжатия можно выделить как несколько килобайт, так и несколько мегабайт памяти (в zlib используется 32 Кб), в зависимости от имеющихся ресурсов. Кроме того, Zstandard предоставляет более широкий диапазон для варьирования параметрами упаковки - на выбор предоставляется 22 уровня сжатия (1 - важна скорость, 22 - важен размер), позволяющих увеличить степень сжатия за счёт снижения скорости или, наоборот, повысить скорость ценой эффективности сжатия. В будущем число уровней сжатия планируется увеличить, также будут предоставлены типовые словари для увеличения эффективности сжатия JSON, HTML и типовых сетевых протоколов.



  1. Главная ссылка к новости (https://code.facebook.com/post...)
  2. OpenNews: Dropbox опубликовал реализацию алгоритма сжатия изображений Lepton
  3. OpenNews: Компания Apple открыла реализацию алгоритма сжатия без потерь LZFSE
  4. OpenNews: Автор LZ4 представил новый быстрый и эффективный алгоритм сжатия ZSTD
  5. OpenNews: Компания Google представила новый алгоритм сжатия данных Brotli
  6. OpenNews: Выпуск библиотеки сжатия LZHAM 1.0, нацеленной на создание более быстрой альтернативы LZMA
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45058-zlib
Ключевые слова: zlib, zstandard
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (59) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:42, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Кто-нибудь пояснит, при чём здесь Facebook? До этого я думал, что автором Zstd является автор алгоритма LZ4 и открыт он был ещё в начале прошлого года, если не раньше: https://www.opennet.dev/opennews/art.shtml?num=41534
     
     
  • 2.2, Аноним (-), 11:46, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Микрософт вон атом изобрёл, а пейспук — сабж. Всё ок.
     
     
  • 3.3, commiethebeastie (ok), 11:50, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Билл ГейТс изобрел интернеты.
     
     
  • 4.10, ано (?), 13:13, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ты лжешь! Интернеты изобрел Стиви Жопс из Эйпол
     
     
  • 5.32, Sluggard (ok), 20:49, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не-не-не. Они изобрели скруглённые углы.
     
     
  • 6.37, Аноним (-), 21:35, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Вы все не правы. Интернеты изобрели в ЦРУ.
     
     
  • 7.41, Yuris (??), 09:42, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы нас плавно подводите к тому, что Фэйсбук проект ЦРУ? ;)
     
  • 6.51, Аноним (-), 16:39, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Не-не-не. Они изобрели скруглённые углы.

    Вы будете ржать, но автор сабжа учился на маркетолога. Но в какой-то момент решил что труба шатал углы закруглять. И занялся сжатием. Преуспев в этом получше многих других.

     
     
  • 7.52, Sluggard (ok), 16:45, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Вы будете ржать, но автор сабжа учился на маркетолога. Но в какой-то
    > момент решил что труба шатал углы закруглять. И занялся сжатием. Преуспев
    > в этом получше многих других.

    Бывает, что такого. И анестезиологи вон ядро пишут. У меня приятель филолог писал под Symbian сперва на Python, потом на C++.

     
  • 2.6, anonymous (??), 12:26, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Автору хочется кушать, приходится работать на дядю
     
     
  • 3.8, Crazy Alex (ok), 12:50, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Ужас-то какой.

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

     
  • 3.30, Аноним (-), 20:34, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А в чем работа на дядю состоит? Чувак что так пилил свой алгоритм что эдак. Дядя заинтересовался в этом результате и нанял чувака чтобы тот мог делать то что делает фултайм. Результвт доступен что дяде, что чуваку, что нам с вами.

    В последних ревизиях годный кстати алгоритм. Жмет лучше zlib и при том распаковывается быстрее. Именно с zstd яппл собезьянничал свой алгоритм.

     
  • 2.11, Аноним (-), 13:33, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так он работает в Facebook
     
     
  • 3.39, Аноним (-), 02:56, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Был в Оранжевом филиале французской компании.
    FB больше платит.
     
  • 2.12, Аноним84701 (?), 13:45, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто-нибудь пояснит, при чём здесь Facebook? До этого я думал, что автором
    > Zstd является автор алгоритма LZ4 и открыт он был ещё в
    > начале прошлого года, если не раньше: https://www.opennet.dev/opennews/art.shtml?num=41534

    Поясняю: автору не только новые алгоритмы изобретать, но иногда в процессе изобретательства и кушать  хочется,  да и ночевать скорее всего предпочитает в теплой постельке, под крышей ;)


     
     
  • 3.38, Аноним (-), 21:40, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кушать, крыша и тёплая постелька несовместимы с понятиями Настоящей Свободы.

     
  • 2.13, Andrey Mitrofanov (?), 14:04, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Кто-нибудь пояснит, при чём здесь Facebook? До этого я думал, что автором
    > Zstd является автор алгоритма LZ4 и открыт он был ещё в
    > начале прошлого года, если не раньше: https://www.opennet.dev/opennews/art.shtml?num=41534

    Ср.:

    25.01.2015 09:47  Автор LZ4 представил новый быстрый и эффективный алгоритм сжатия ZSTD

    Ян Колле (Yann Collet), автор эталонной реализации алгоритма LZ4, представил новый [...]

    и

    https://code.facebook.com/posts/1658392934479273/smaller-and-faster-data-compr
    17 hours agoData · Performance · Storage
    Smaller and faster data compression with Zstandard
    Yann Collet Chip Turner

    People are creating, sharing, and storing [...]


    Выводы?

     
  • 2.21, ктонибудь (?), 17:33, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    объясняем мордокнижка платит афттару zstandard зарплату Чтобы он мог заниматьс... большой текст свёрнут, показать
     
     
  • 3.23, qwerty (??), 18:34, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >- изящно вынести специфический(!) словарь в ../

    если данных терабайтами и при этом вариабельность 100k словаря за год  0%,
    то почему бы и нет?

     
     
  • 4.47, . (?), 14:42, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> - изящно вынести специфический(!) словарь в ../
    > если данных терабайтами и при этом вариабельность 100k словаря за год  0%,

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

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


     
  • 3.36, Аноним (-), 21:05, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > Теперь прикинем, как это будет внутри какой-нибудь rasp pi, где нет branch
    > prediction (и любой branchless код просто длиннее и медленнее нормального), дорогая
    > 64битная арифметика, где нет лишних ядер, лишней памяти -

    Я сравнивал разные LZ-образные на одноядерном ARMv7. Это несколько отличается от x86.

    1) LZ4: по прежнему в лидерах скорости сжатия/распаковки. Может догнаться до скорости memcpy(), а на хорошо сжимаемых данных даже обогнать memcpy (вероятно, разгрузив read исходных данных из оперативы по сравнению с memcpy). Ratio как обычно скромный. А он сильно жать в принципе не может. Не для этого он.

    2) Zstd: в отличие от x86 где zstd заметно быстрее zlib, на ARM zstd примерно как zlib. Ну может капельку быстрее иногда. Но жмет все-равно значительно лучше zlib'а. Профит по любому.

    3) Brotli. Это уже тяжеловес. По скорости на ARM уже несколько сливает zlib. Но жмет кардинально плотнее и на верхних уровнях приближается к LZMA. Распаковываясь в ТРИ РАЗА быстрее чем LZMA на том же проце. Тоже вполне приятный tradeoff. Нагло жульничает на вебне используя встроенный словарь на добрых 120 кило.

     
     
  • 4.48, . (?), 15:05, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я сравнивал разные LZ-образные на одноядерном ARMv7. Это несколько отличается от x86.

    спасибо, это как раз то, чего не сделали авторы - что и вызывает у меня удивление. Скудоумием они явно не могли страдать, значит - намеренная и осознаваемая подмена понятий.
    Причем совсем непонятно, чего ради - на первый взгляд и честный анализ должен был дать достаточно достойные результаты. Ну а раз совравшему уже не хочется доверять и в остальном - вдруг оно, к примеру, каждый пятый файл вообще не cможет потом распаковать.

    > проце. Тоже вполне приятный tradeoff. Нагло жульничает на вебне используя встроенный
    > словарь на добрых 120 кило.

    ну это не нагло. Нагло это в исходной статье - сперва пообучать алгоритм, потом отложить словарик, потом _эти_же_ данные (не какие-то похожие, а именно те) сжать. (причем оно таки делало zlib чуть ли не в восемь раз даже с учетом словаря, совершенно неясно, зачем понадобилось такое мелкое жульничество. Возможно, ларчик откроется, если засечь время обучения- вызов time там тоже скромно опущен ;) Если словарь является частью программы, ничего плохого в этом я не вижу (как, собственно, и в специфическом словаре, упакованном вместе с данными, кто-то из ранних досовских архиваторов именно так и работал...аццки долго ;)

     
     
  • 5.53, Аноним (-), 17:11, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Больше похоже на то что они так просто не умеют ARM вообще забавные штуки Там ... большой текст свёрнут, показать
     
  • 3.46, arisu (ok), 10:14, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Поневоле закрадываются сомнения - там все остальное-то нормально сделано?

    нормально. просто подобные штуки хоть и не принято сейчас называть «пресс‐релизы», но по сути это именно пресс‐релиз. соответственно, рассказывается о плюсах, умалчивается о минусах и всё такое. потому что надо продать. кому непонятно, что именно продаётся — пусть спускается с небес.

     
     
  • 4.54, Аноним (-), 17:26, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Автор zstd должен был стать маркетологом. Но как-то случайно подсел на алгоритмы и програмизм. Это ему настолько вштырило что он послал карьеру маркетолога и занялся алгоритмами сжатия.

    Так что он умеет преподнести себя в выгодном свете. Но соль не в том. Он упрямый чувак, хорошо разбирается в оптимизациях и поэтому смог догнаться до высот на которых сломали зубы многие матерые програмеры. Zstd не самый быстрый и не самый плотный. Зато он практичный и серьезно претендует на нишу zlib, который с точки зрения технологий мало ушел от эпохи DOSовых архиваторов. Zstd в той же нише, только лучше. И по скорости распаковки и по достижимой степени сжатия.

     
     
  • 5.55, arisu (ok), 17:30, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    а я нигде не писал, что сабж плохой, если что. я просто немного потоптался на форме презентации.
     
     
  • 6.59, Аноним (-), 18:25, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > а я нигде не писал, что сабж плохой, если что. я просто
    > немного потоптался на форме презентации.

    Топтаться на презентации маркетолога занятие неблагодарное. Маркетологи это умеют. А то что одним маркетологом меньше и одним програмером больше - вообще фича :P.

     

  • 1.4, Сергей (??), 11:51, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Читайте внимательней,  алгоритм и его реализация в виде кода...
     
     
  • 2.5, Аноним (-), 12:08, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Реализация в виде кода была сделана автором LZ4 и было выпущено много версий. И только к последней версии под номером 1.0.0 примазался Facebook.
     
     
  • 3.15, Andrey Mitrofanov (?), 14:34, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Реализация в виде кода была сделана автором LZ4 и было выпущено много
    > версий. И только к последней версии под номером 1.0.0 примазался Facebook.

    Эти гады ещё и перелицензировали код с-под GPLv2+ на MIT.  Караул!!

    https://github.com/facebook/zstd/commit/0588ee66cc003ab781c7ab3f57df04619c48e5
    https://github.com/facebook/zstd/commit/4ded9e591cbed57c54fc8f7a50412af5980e23
    https://github.com/facebook/zstd/commit/1c59c20903ecd2881c09dc8992fc4e56b95512

    И да, не забываем
    https://github.com/facebook/zstd/search?q=facebook
    отписывать контрибуции
    https://github.com/facebook/zstd/commit/4ded9e591cbed57c54fc8f7a50412af5980e23

    ...https://github.com/Cyan4973/FiniteStateEntropy/search?q=Yann+Collet
    ---https://github.com/facebook/zstd/search?q=Yann+Collet+Facebook

     
     
  • 4.16, MMx (?), 15:53, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А что это за КЛА?
    Что за контрибуции?
    Что за???
     
  • 4.17, MMx (?), 15:55, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Это какой-та не опенсорц
     
  • 4.27, Аноним (-), 20:27, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А так можно? MIT вроде не допускает перелицензирование?
     
     
  • 5.31, Аноним (-), 20:38, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А так можно? MIT вроде не допускает перелицензирование?

    В mit как и bsd - полтора условия. Поверх которых можно нашлепнуть любые другие без нарушения лицензии ;). Проприерасы вообще EULA всем в рожу тычут, и ничего, так можно. А GPL чем принципиально отличается от других лицензий? :)

     
  • 5.43, Andrey Mitrofanov (?), 09:48, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > А так можно? MIT вроде не допускает перелицензирование?

    --Дядя Юра, Вы дурак?

     
  • 4.50, lemon tree (?), 00:19, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Может, автор продал свои исходники Фейсбуку?
     

  • 1.7, mmm (??), 12:41, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А если туда ещё и lepton подмешать - на jpg-ах всех порвёт.
     
  • 1.9, Аноним (-), 13:10, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему никто не обращает внимание на фрактальное сжатие? Патенты уже истекли.
     
     
  • 2.18, Аноним (-), 16:06, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > А почему никто не обращает внимание на фрактальное сжатие? Патенты уже истекли.

    две причины - оно сильно Ассиметрично. распаковка - весьма шустра а сжатие в десятки, порой сотни раз медленее.
    а второе - там необычная математика и ... программисты - просто не осилят прикручивать либы(две компании, лицензировавшие у луравэйв/лизардтех уже после покупки остатков итератед оными в конце нулевых - так и не смогли купленные либы прикрутить к своему решению, несмотря на то что в Ф500 входят и опыт "абстрактной" разработки софта у них - был).


     
     
  • 3.33, Аноним (-), 20:50, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Обычный Lempel-Ziv к этому вполне склонен и у того же Zstd есть высокие уровни с... большой текст свёрнут, показать
     

  • 1.14, Аноним (-), 14:32, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > конечного состояния энтропии (Finite State Entropy)

    МГИМО финишд?

     
     
  • 2.28, Аноним (-), 20:32, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> конечного состояния энтропии (Finite State Entropy)
    > МГИМО финишд?

    Аск

     

  • 1.19, Аноним (-), 16:53, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Пеговый Дудочник
     
     
  • 2.22, anonymous (??), 18:27, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    МПеговый дудочник
     
     
  • 3.25, Аноним (-), 19:25, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Что ты несешь?
     
  • 3.34, Аноним. (?), 20:54, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > МПеговый дудочник

    MPEGLA'овый :)

    Впрочем для MPEGLA тоже подарочек есть: https://aomedia.googlesource.com/aom - эта крутень дает довольно приличную картинку 1080P даже при ... 500 Кбит?! Вау. Эй, H.264 а попробуй так же? И чтоб не превратиться в блочную муть? :)

     
     
  • 4.40, KBAKEP (ok), 05:05, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Скорее уж H.265.
     
     
  • 5.44, Аноним (-), 09:52, 02/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    тогда уж AV1 и Daaala, Thor ;)
    Theora-у ванильную - тоже вяло(но ощутимо)допиливают да и VP8, VP9 для "внутреннего использования" гугль юзает вовсю )
     
     
  • 6.58, Аноним (-), 18:24, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > тогда уж AV1 и Daaala, Thor ;)
    > Theora-у ванильную - тоже вяло(но ощутимо)допиливают да и VP8, VP9 для "внутреннего
    > использования" гугль юзает вовсю )

    На VP8 почти забили. Из него сильно больше уже не выжмешь. VP9 достаточно активно пилят и фиксят. Daala частично внедрили в AV1, который в первом приближении смесь VP10 с Daala, может и из Thor чего-то выдрали. Основные коммитеры - из daala и vp10.

     
  • 5.56, Аноним (-), 18:20, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Наздоровье, гугл и ко задались целью его уделать И уже уделывают существующие р... большой текст свёрнут, показать
     

  • 1.26, Аноним (-), 20:24, 01/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Использую в двух своих проектах. При равной скорости векторные изображения жмет на 40% сильнее zlib.
     
     
  • 2.35, Аноним (-), 20:57, 01/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Использую в двух своих проектах. При равной скорости векторные изображения жмет на
    > 40% сильнее zlib.

    Да почти все жмет лучше чем zlib. Особенно если данных больше чем 32Кб. Все-таки 32 Кб окно без возможности увеличения - ловит мало совпадений. Ну и FSE как вторая стадия - это такой удачный компромисс где скорость побольше чем у хаффмана при том что степень сжатия на уровне арифметического кодиорования. Это Jarek Duda придумал свой ANS и потом пополам с спецами по сжатию прикрутили все это к реальным алгоритмам. Так появился FSE.

     

  • 1.42, Аноним (-), 09:43, 02/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А как это прикрутить к pifs?
     
     
  • 2.64, Аноним (64), 14:34, 03/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Месье долгожитель что пользуется pifs?
     

  • 1.45, arisu (ok), 10:10, 02/09/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    словари рулят. берёшь, значит, весь исходный файл, и засовываешь его в словарь. БУМ! всех порвал, мегасжатие, скорость потрясающая, памяти почти не требует.

    вообще, многопроходное сжатие — скучное читерство.

     
     
  • 2.57, Аноним (-), 18:21, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > вообще, многопроходное сжатие — скучное читерство.

    А в каком месте optimal parsing например - читерство?

     
     
  • 3.60, arisu (ok), 18:54, 03/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> вообще, многопроходное сжатие — скучное читерство.
    > А в каком месте optimal parsing например - читерство?

    именно в том. читерство и есть, к тому же ещё и тормозное.

     
  • 2.62, нах (?), 10:02, 05/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > словари рулят. берёшь, значит, весь исходный файл, и засовываешь его в словарь

    если вы внимательно прочитали статью - там именно так и сделано (только не файл, а файлы)
    Сам словарь предусмотрительно вынесен в ../, поэтому к размеру сжатых данных не отнесен.
    То есть не как у гугля - потренировали на своих данных, и потом жмем любые похожие (и фейлимся на похожих, но недостаточно похожих), а именно словарь под эти конкретные.

    > вообще, многопроходное сжатие — скучное читерство.

    вообще - нет. Читерство начинается, когда размер такого словаря и время на его создание "как-то вот забыли учесть".

    Для данных которые "сжимаются один раз, распаковываются тыщу" нет ничего ужасного в том, что при сжатии тратится время на словарь. До тех пор, пока однопроходное сжатие не оказывается только на пару процентов хуже ;-)

    В общем, совершенно загадочно, зачем им это понадобилось - когда и честное сравнение в их пользу.

     
     
  • 3.63, arisu (ok), 10:37, 05/09/2016 [^] [^^] [^^^] [ответить]  
  • +/
    дык я не говорил, что оно всё плохо. я сказал, что оно скучное читерство. лично мне хватает zlib, который всё равно уже есть в любой системе, а нет — так разжиматель после deflate пишется в несколько килобайт. поэтому я интересуюсь остальным чисто с точки зрения: «а это интересно?» неа, неинтересно: и не ново, и не особо впечатляет, и к тому же для лучшего сжатия рекомендуют читерить. скука.

    p.s. zlib, кстати, тоже умеет в 'deflateSetDictionary()' и 'inflateSetDictionary()'.

     

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



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

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