The OpenNET Project / Index page

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



"Facebook открыл реализацию алгоритма сжатия Zstandard"
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Facebook открыл реализацию алгоритма сжатия Zstandard" +/
Сообщение от Аноним (-), 03-Сен-16, 17:11 
> спасибо, это как раз то, чего не сделали авторы - что и
> вызывает у меня удивление. Скудоумием они явно не могли страдать, значит
> - намеренная и осознаваемая подмена понятий.

Больше похоже на то что они так просто не умеют.

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

ARM вообще забавные штуки. Там соотношения скорости проца vs скорость оперативы другие и в целом соотношения привычные на х86 могут ощутимо перекоситься. Хотя общая идея остается.

Кроме того сильно роялит какие именно были данные. Некоторые виды данных сильно лучше сжимаются если сделать (обратимый) препроцессинг, а при распаковке - вернуть как было. Если грамотно выбрать тестовый набор данных - можно выпятить почти любой алгоритм и задвинуть остальных. Единственная проблема: в других случаях цифры могут быть гораздо менее красивые. Поэтому самый надежный способ - пустить ряд алгоритмов на своих данных и посмотреть что получится. Иногда бывает даже такой "парадокс" что gzip -3 может сжать и лучше и быстрее чем gzip -9. Это касается и многих других алгоритмов, хоть и по разным причинам.

> каждый пятый файл вообще не cможет потом распаковать.

Ну это врядли. Мордокнига думаю мощно потестирует в продакшне. Да и до этого алгоритм народ немало гонял. Это впрочем вообще не архиватор а библа сжатия. Поверх которой можно запилить в том числе и архиватор.

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

Так гугл именно это и сделал: погонял brotli на своей выборке вебни. Сдампил наиболее удачный словарь. Вшил его прямо в библу (более +120 кил к весу либы). И теперь оно на вебне накручивает себе ratio только в путь. Точно так же его может накрутить и сабж, это ровно настолько же (не)честно. Проблема этого метода в том что если данные не похожи на то что в словаре, профита не наступает и цифры гораздо более скромные.

> (причем оно таки делало zlib чуть ли не в восемь раз даже с учетом словаря,
> совершенно неясно, зачем понадобилось такое мелкое жульничество.

Это не столько жульничество, сколько showcase себя любимого с демонстрацией того что можно получить за пределами zlib. Ну да, автор маркетолог-недоучка, поэтому умеет себя показать с выгодной стороны :). Но в целом он предпринял усилия для оптимизации алгоритма и доведения до ума и в целом tradeoff удачный вышел.

> Возможно, ларчик откроется, если засечь время обучения-

Если делать как гугль и ко в brotli - это делается один раз за все время. А потом вгружаешь словарик - и (почти) вся вебня начинает жаться лучше. Прикол в том что по сути часть вебпаги заранее подгружается в виде словаря и поэтому достаточно передать куда более короткие референсы на словарь. Но если уж на то пошло - вебня вообще очень избыточная и скажем заменив теги более короткими представлениями можно нефигово выиграть. ЧСХ это не только работает но один кадр на этом чуть ли не докторскую сделал. Хорошо работает. Но вот только нужда сильно препроцессить и возвращать как было - требует времени. А словарь - относительно халявен, в том плане что по скорости не принципиально референсить ли просто прошлые данные или же заранее подпиханый словарь.

Словарь - это такая оптимизация если характер данных известен. Если это не так то он лишь раздувает либу и ничего не привносит.  По этой причине прошаренные compression contest меряют размер "код для распаковки + сжатые данные". Иначе кто-то снесет половину данных в код и выиграет, "распаковав". Ну это такой совсем частный случай словаря, одноразовый :)

> специфическом словаре, упакованном вместе с данными, кто-то из ранних досовских
> архиваторов именно так и работал...аццки долго ;)

В общем случае внешний словарь имеет смысл только если есть достаточно большой набор однотипных данных, так что перенос некоторошо типового shared куска в либу или рядом себя окупит. Гугл ориентировался на вебню - ну и вынес в такой кусок типовые теги/слова/etc. Почему сабжу так должно юыть нельзя - хз :)

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Facebook открыл реализацию алгоритма сжатия Zstandard, opennews, 01-Сен-16, 11:42  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



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

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