Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Facebook открыл реализацию алгоритма сжатия Zstandard, opennews (??), 01-Сен-16, (0) [смотреть все] Кто-нибудь пояснит, при чём здесь Facebook До этого я думал, что автором Zstd я, Аноним (-), 11:42 , 01-Сен-16, (1) +1 // Микрософт вон атом изобрёл, а пейспук 8212 сабж Всё ок , Аноним (-), 11:46 , 01-Сен-16, (2) // Билл ГейТс изобрел интернеты , commiethebeastie (ok), 11:50 , 01-Сен-16, (3) –1 // Ты лжешь Интернеты изобрел Стиви Жопс из Эйпол, ано (?), 13:13 , 01-Сен-16, (10) +2 Не-не-не Они изобрели скруглённые углы , Sluggard (ok), 20:49 , 01-Сен-16, (32) +2 Вы все не правы Интернеты изобрели в ЦРУ , Аноним (-), 21:35 , 01-Сен-16, (37) Вы нас плавно подводите к тому, что Фэйсбук проект ЦРУ , Yuris (??), 09:42 , 02-Сен-16, (41) +1 Вы будете ржать, но автор сабжа учился на маркетолога Но в какой-то момент реши, Аноним (-), 16:39 , 03-Сен-16, (51) Бывает, что такого И анестезиологи вон ядро пишут У меня приятель филолог писа, Sluggard (ok), 16:45 , 03-Сен-16, (52) –1 Автору хочется кушать, приходится работать на дядю, anonymous (??), 12:26 , 01-Сен-16, (6) // Ужас-то какой Вообще-то работа на дядю в IT в большинстве случаев на порядок ком, Crazy Alex (ok), 12:50 , 01-Сен-16, (8) +10 А в чем работа на дядю состоит Чувак что так пилил свой алгоритм что эдак Дядя, Аноним (-), 20:34 , 01-Сен-16, (30) Так он работает в Facebook, Аноним (-), 13:33 , 01-Сен-16, (11) +1 // Был в Оранжевом филиале французской компании FB больше платит , Аноним (-), 02:56 , 02-Сен-16, (39) Поясняю автору не только новые алгоритмы изобретать, но иногда в процессе изобр, Аноним84701 (?), 13:45 , 01-Сен-16, (12) // Кушать, крыша и тёплая постелька несовместимы с понятиями Настоящей Свободы , Аноним (-), 21:40 , 01-Сен-16, (38) –1 Ср 25 01 2015 09 47 Автор LZ4 представил новый быстрый и эффективный алгоритм , Andrey Mitrofanov (?), 14:04 , 01-Сен-16, (13) объясняем мордокнижка платит афттару zstandard зарплату Чтобы он мог заниматьс, ктонибудь (?), 17:33 , 01-Сен-16, (21)   // если данных терабайтами и при этом вариабельность 100k словаря за год 0 ,то поч, qwerty (??), 18:34 , 01-Сен-16, (23) –1   // вы совсем читать не умеете Ну ладно первоисточник ниасилить это ж надо было ве, . (?), 14:42 , 02-Сен-16, (47) –1   Я сравнивал разные LZ-образные на одноядерном ARMv7 Это несколько отличается от, Аноним (-), 21:05 , 01-Сен-16, (36) +6   // спасибо, это как раз то, чего не сделали авторы - что и вызывает у меня удивлени, . (?), 15:05 , 02-Сен-16, (48) –1   Больше похоже на то что они так просто не умеют ARM вообще забавные штуки Там с, Аноним (-), 17:11 , 03-Сен-16, (53)   нормально просто подобные штуки хоть и не принято сейчас называть 171 пресс , arisu (ok), 10:14 , 02-Сен-16, (46)   // Автор zstd должен был стать маркетологом Но как-то случайно подсел на алгоритмы, Аноним (-), 17:26 , 03-Сен-16, (54)   а я нигде не писал, что сабж плохой, если что я просто немного потоптался на фо, arisu (ok), 17:30 , 03-Сен-16, (55)   Топтаться на презентации маркетолога занятие неблагодарное Маркетологи это умею, Аноним (-), 18:25 , 03-Сен-16, (59)   Читайте внимательней, алгоритм и его реализация в виде кода , Сергей (??), 11:51 , 01-Сен-16, (4) +2 // Реализация в виде кода была сделана автором LZ4 и было выпущено много версий И , Аноним (-), 12:08 , 01-Сен-16, (5) // Эти гады ещё и перелицензировали код с-под GPLv2 на MIT Караул https githu, Andrey Mitrofanov (?), 14:34 , 01-Сен-16, (15) // А что это за КЛА Что за контрибуции Что за , MMx (?), 15:53 , 01-Сен-16, (16) Это какой-та не опенсорц, MMx (?), 15:55 , 01-Сен-16, (17) А так можно MIT вроде не допускает перелицензирование , Аноним (-), 20:27 , 01-Сен-16, (27) –1 В mit как и bsd - полтора условия Поверх которых можно нашлепнуть любые другие , Аноним (-), 20:38 , 01-Сен-16, (31) –1 --Дядя Юра, Вы дурак , Andrey Mitrofanov (?), 09:48 , 02-Сен-16, (43) –1 Может, автор продал свои исходники Фейсбуку , lemon tree (?), 00:19 , 03-Сен-16, (50) –1 А если туда ещё и lepton подмешать - на jpg-ах всех порвёт , mmm (??), 12:41 , 01-Сен-16, (7) –1 А почему никто не обращает внимание на фрактальное сжатие Патенты уже истекли , Аноним (-), 13:10 , 01-Сен-16, (9) // две причины - оно сильно Ассиметрично распаковка - весьма шустра а сжатие в дес, Аноним (-), 16:06 , 01-Сен-16, (18) // Обычный Lempel-Ziv к этому вполне склонен и у того же Zstd есть высокие уровни с, Аноним (-), 20:50 , 01-Сен-16, (33) –1 МГИМО финишд , Аноним (-), 14:32 , 01-Сен-16, (14) +1 // Аск, Аноним (-), 20:32 , 01-Сен-16, (28) Пеговый Дудочник, Аноним (-), 16:53 , 01-Сен-16, (19) +2 // МПеговый дудочник, anonymous (??), 18:27 , 01-Сен-16, (22) +1 // Что ты несешь , Аноним (-), 19:25 , 01-Сен-16, (25) –1 MPEGLA овый Впрочем для MPEGLA тоже подарочек есть https aomedia googlesour, Аноним. (?), 20:54 , 01-Сен-16, (34) –1 // Скорее уж H 265 , KBAKEP (ok), 05:05 , 02-Сен-16, (40) тогда уж AV1 и Daaala, Thor Theora-у ванильную - тоже вяло но ощутимо допилива, Аноним (-), 09:52 , 02-Сен-16, (44) На VP8 почти забили Из него сильно больше уже не выжмешь VP9 достаточно активн, Аноним (-), 18:24 , 03-Сен-16, (58) Наздоровье, гугл и ко задались целью его уделать И уже уделывают существующие р, Аноним (-), 18:20 , 03-Сен-16, (56) Использую в двух своих проектах При равной скорости векторные изображения жмет , Аноним (-), 20:24 , 01-Сен-16, (26) // Да почти все жмет лучше чем zlib Особенно если данных больше чем 32Кб Все-таки, Аноним (-), 20:57 , 01-Сен-16, (35) А как это прикрутить к pifs , Аноним (-), 09:43 , 02-Сен-16, (42) +1 // Месье долгожитель что пользуется pifs , Аноним (64), 14:34 , 03-Янв-19, (64) словари рулят берёшь, значит, весь исходный файл, и засовываешь его в словарь , arisu (ok), 10:10 , 02-Сен-16, (45) +2 // А в каком месте optimal parsing например - читерство , Аноним (-), 18:21 , 03-Сен-16, (57) // именно в том читерство и есть, к тому же ещё и тормозное , arisu (ok), 18:54 , 03-Сен-16, (60) если вы внимательно прочитали статью - там именно так и сделано только не файл,, нах (?), 10:02 , 05-Сен-16, (62) // дык я не говорил, что оно всё плохо я сказал, что оно скучное читерство лично , arisu (ok), 10:37 , 05-Сен-16, (63) 1,4,7,9,14,19,26,42,45

Сообщения

[Сортировка по времени | RSS]

	21. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+/–
	Сообщение от ктонибудь (?), 01-Сен-16, 17:33
	> Кто-нибудь пояснит, при чём здесь Facebook? объясняем: мордокнижка платит афттару zstandard зарплату. Чтобы он мог заниматься своей метафи...зачеркнуто, математикой, с девяти до восьми с перерывом на обед, а не стоять в очереди за бесплатным. > До этого я думал, что автором Zstd является автор алгоритма LZ4 и открыт он был ещё в если не полениться, побороть страх и сомнения и открыть таки ссылку - то ты увидишь, что фейсбучная статья подписана (в том числе) пресловутым автором алгоритма. И то что опубликовано сейчас - работающий как они выразились "ready to production" код, а не proof of concept, который был "в начале прошлого года". Огорчает совершенно другое - афтар зачем-то сравнивает в тестах мягкое с теплым - да, это очень охрененно, что его алгоритм умеет использовать особенности современных процессоров и большую память, но только в тех случаях, когда они по сути лишние, и никаких других задач кроме вот прям счас нам надо получить сжатый файл (один!) не исполняется. А когда они совсем нелишние - сравнивать надо ресурсоемкость, чего они почему-то не сделали в принципе. Теперь прикинем, как это будет внутри какой-нибудь rasp pi, где нет branch prediction (и любой branchless код просто длиннее и медленнее нормального), дорогая 64битная арифметика, где нет лишних ядер, лишней памяти - а заодно оценим количество менее вырожденных случаев (когда тот же opennet ротейтит логи, ага). Ну или даже фейсбук - который под сжатие своих релейшн графов может выделить целую ферму специально-сжимающих серверов, но графов у него нифига не один, поэтому совершенно наплевать, будут шестнадцать ядер жевать шестнадцать графов поочередно тредами, или параллельно - каждый своим ядром. И задумаемся - а почему, собственно, гениальный математик даже не подумал в эту сторону? Ну и вишенка на тортике - изящно вынести специфический(!) словарь в ../ и почему-то проигнорировать тот факт, что его размер вообще-то сопоставим со сжатым результатом. Неотъемлемой частью которого он, на самом-то деле, является. Поневоле закрадываются сомнения - там все остальное-то нормально сделано?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	23. "Facebook открыл реализацию алгоритма сжатия Zstandard"	–1 +/–
	Сообщение от qwerty (??), 01-Сен-16, 18:34
	>- изящно вынести специфический(!) словарь в ../ если данных терабайтами и при этом вариабельность 100k словаря за год  0%, то почему бы и нет?
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Facebook открыл реализацию алгоритма сжатия Zstandard"	–1 +/–
	Сообщение от . (?), 02-Сен-16, 14:42
	>> - изящно вынести специфический(!) словарь в ../ > если данных терабайтами и при этом вариабельность 100k словаря за год  0%, вы совсем читать не умеете? Ну ладно первоисточник ниасилить (это ж надо было весь этот булшит не просто прочесть по диагонали, но и проверить подозрительный момент) - но слово _специфический_ вами тоже не понято? Сперва тренируем на конкретном наборе данных, потом показываем счастливым лохам, как легко и быстро этот самый набор сжимается. Словарь при этом забываем в ../, время его составления тоже ингнорируем, все счастливы и танцуют.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+6 +/–
	Сообщение от Аноним (-), 01-Сен-16, 21:05
	> Теперь прикинем, как это будет внутри какой-нибудь 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 кило.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	48. "Facebook открыл реализацию алгоритма сжатия Zstandard"	–1 +/–
	Сообщение от . (?), 02-Сен-16, 15:05
	> Я сравнивал разные LZ-образные на одноядерном ARMv7. Это несколько отличается от x86. спасибо, это как раз то, чего не сделали авторы - что и вызывает у меня удивление. Скудоумием они явно не могли страдать, значит - намеренная и осознаваемая подмена понятий. Причем совсем непонятно, чего ради - на первый взгляд и честный анализ должен был дать достаточно достойные результаты. Ну а раз совравшему уже не хочется доверять и в остальном - вдруг оно, к примеру, каждый пятый файл вообще не cможет потом распаковать. > проце. Тоже вполне приятный tradeoff. Нагло жульничает на вебне используя встроенный > словарь на добрых 120 кило. ну это не нагло. Нагло это в исходной статье - сперва пообучать алгоритм, потом отложить словарик, потом _эти_же_ данные (не какие-то похожие, а именно те) сжать. (причем оно таки делало zlib чуть ли не в восемь раз даже с учетом словаря, совершенно неясно, зачем понадобилось такое мелкое жульничество. Возможно, ларчик откроется, если засечь время обучения- вызов time там тоже скромно опущен ;) Если словарь является частью программы, ничего плохого в этом я не вижу (как, собственно, и в специфическом словаре, упакованном вместе с данными, кто-то из ранних досовских архиваторов именно так и работал...аццки долго ;)
	Ответить | Правка | Наверх | Cообщить модератору

	53. "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ообщить модератору

	46. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+/–
	Сообщение от arisu (ok), 02-Сен-16, 10:14
	> Поневоле закрадываются сомнения - там все остальное-то нормально сделано? нормально. просто подобные штуки хоть и не принято сейчас называть «пресс‐релизы», но по сути это именно пресс‐релиз. соответственно, рассказывается о плюсах, умалчивается о минусах и всё такое. потому что надо продать. кому непонятно, что именно продаётся — пусть спускается с небес.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

	54. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+/–
	Сообщение от Аноним (-), 03-Сен-16, 17:26
	Автор zstd должен был стать маркетологом. Но как-то случайно подсел на алгоритмы и програмизм. Это ему настолько вштырило что он послал карьеру маркетолога и занялся алгоритмами сжатия. Так что он умеет преподнести себя в выгодном свете. Но соль не в том. Он упрямый чувак, хорошо разбирается в оптимизациях и поэтому смог догнаться до высот на которых сломали зубы многие матерые програмеры. Zstd не самый быстрый и не самый плотный. Зато он практичный и серьезно претендует на нишу zlib, который с точки зрения технологий мало ушел от эпохи DOSовых архиваторов. Zstd в той же нише, только лучше. И по скорости распаковки и по достижимой степени сжатия.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+/–
	Сообщение от arisu (ok), 03-Сен-16, 17:30
	а я нигде не писал, что сабж плохой, если что. я просто немного потоптался на форме презентации.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Facebook открыл реализацию алгоритма сжатия Zstandard"	+/–
	Сообщение от Аноним (-), 03-Сен-16, 18:25
	> а я нигде не писал, что сабж плохой, если что. я просто > немного потоптался на форме презентации. Топтаться на презентации маркетолога занятие неблагодарное. Маркетологи это умеют. А то что одним маркетологом меньше и одним програмером больше - вообще фича :P.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема