Проект zlib-ng (https://github.com/Dead2/zlib-ng) нацелен на создание совместимой на уровне API замены библиотеке zlib (http://www.zlib.net/), предоставляющей некоторые сторонние оптимизации, которые не реализованы в официальном репозитории zlib. В отличие от достаточно консервативного в плане приёма изменений проекта zlib, проект zlib-ng позиционируется как предоставляющий более низкий порог включения патчей, что способствует более быстрому доведению новых решений до пользователей.
Zlib-ng также допускает удаление обходных решений, используемых в zlib для поддержки старых компиляторов и платформ, если они мешают реализации более эффективных методов (например, в zlib применяются некоторые ограничения, необходимые для поддержки 16-разрядных систем и не совместимых с ANSI C компиляторов).
Из добавленных в zlib-ng изменений отмечается интеграция оптимизаций, подготовленных компаниями Intel (http://www.opennet.me/opennews/art.shtml?num=38551) и Cloudflare, а также накопившихся в пакетах дистрибутивов мелких патчей. В частности, заметно повысить скорость сжатия/распаковки позволило использование инструкций SSE. Также проведена чистка кода от поддержки устаревших компиляторов и архитектур, которые нагромождают кодовую базу и усложняют сопровождение проекта.
URL: https://news.ycombinator.com/item?id=9664655
Новость: http://www.opennet.me/opennews/art.shtml?num=42374
Более быстрому доведению пользователей до чего, простите?
Не до чего, а до кого.
До меня. :)
Это правильно, а то как-то редко посещаешь. Развелось людишек - вон, уже 8 миллиардов...
до вас каналы связи быстро должны доносить
Теперь initrd будет распаковываццо на 2 миллисекунды быстрее. Как я раньше жил без этого ?
Слоупок, initcpio давно уже xz/lzo/lz4 сжимаютzlib используется там, где другие методы никак не подходят, например сжатие вебстраниц (apache, nginx).
Какой initrd? Zlib - это юзерспейная либа, которая применяется просто в куче проектов.
а это что простите?linux-2.6.32-504.12.2.el6/include/linux
/* zlib.h -- interface of the 'zlib' general purpose compression libraryCopyright (C) 1995-2005 Jean-loup Gailly and Mark Adler
>а это что простите? linux-2.6.32-504.12.2.el6/include/linuxА это у вас анабиозная камера протекла, что и вызвало вашу разморозку
Впрочем прощаю
> Какой initrd? Zlib - это юзерспейная либаНе помешало передрать deflate в кернель...
кто такой весь этот Dead2, почему он так похож на Саймона Пегга и о чём будет эта новая комедия?
И чем он тебе не угодил?
> И чем он тебе не угодил?а где я это сказал? я спросил, кто он такой, чем он известен и почему надо пиарить именно его. а то, казалось бы, пакеты собирать, например — тоже достаточно быть просто аккуратным. а потом бац — бебиан, опенссл…
вот и про этого интересно, чем он отметился.
А, ясно. Показалось, что как-то злобно прозвучало. А так - ну какая разница, через год-другой вот этим себя и проявит, когда все убедятся во вменяемости. Или не проявит.
> А, ясно. Показалось, что как-то злобно прозвучало.саркастично немного. но я же не виноват, что он действительно похож на Саймона Пегга! после этого уже ни в какую серьёзность я не смог.
Там cамый большой профит от оптимизаций в crc32, которая нужна только для обертки gzip, а в чиcтых inflate/deflate вообще не иcпользуютcя.
Ещё zlib часто используется для [де]компрессии при работе с zip-архивами и является чем-то вроде бекэнда для libpng. Там оптимизации вычисления CRC32 лишними тоже не будут.
Я в курcе. Проcто чтобы понимали, где именно ожидать улучшений и на cколько. ~ 20-30% на раcпаковке. Еcли эмбедить и не нужен именно gzip, то deflate c адлером будет быcтрее.
adler по любому будет быстрее. он даже быстрее или так же с аппаратным crc32 / crc32c
> adler по любому будет быстрее....но и несколько менее надежен. Чудес не бывает.
Это как-то будет исправлять кривое поведение GZIP на файлах > 4GB ? (gzip -l myarchive.bin.gz неправильно показывает размер)
Тоже мне новость, этот форк cloudflare c оптимизациями под интеловские процы уже года 2 как живет на https://github.com/cloudflare/zlib и широко известен в узких кругах хайлодщиков.
Ну вот глядишь - будет известен не только "в узких кругах".
а Google будет продолжать проталкивать свой Snappy?
У них разные области применения, zlib никогда не достигнет скорости snappy, а snappy - сжатия zlib. Snappy это конкурент lzo и lz4.
> а Google будет продолжать проталкивать свой Snappy?...которого по скорости сжатия и распаковки давно сделали LZ4 и LZO, если уж кого скорость интересовала.
> Zlib-ng также допускает удаление обходных решений, используемых в zlib для поддержки старых компиляторов и платформКак-то раз в Glibc тоже приняли один патч. Он оптимизировал memcpy с помощью SSE4.1. Если посмотреть историю GIT, то таких патчей было множество (SSE, SSE2), но конкретно этот сделал так, что в некоторых случаях данные записывались задом наперёд, иначе никакого прироста производительности. Недовольным же сказали что поведение пересекающихся регионов не описано в стандарте, поэтому может быть каким угодно, и если вы полагаетесь на традиционный порядок - вы нуб и клинический идиот.
Ну что скажу. Могли вообще сделать чередование: 10 бит слева направо, потом 10 бит справа налево. Кто не учёл такое поведение memcpy - сам виноват! А вообще я бы откатил патч-первопричину, а не создавал обходные пути решения проблемы.
Интересно, что отвалится при использовании zlib-ng вместо zlib? Уверен что половина софта точно.
Как-то раз в Adobe Flash тоже приняли один патч. Он использовал memcpy вместо memmove для копирования перекрывающихся областей. Недовольным же сказали что поведение пересекающихся регионов не описано в стандарте, поэтому может быть каким угодно, и если вы не используете реализацию, копирующую строго в том порядке, как это предположили разработчики Adobe, - вы нуб и клинический идиот.Ну что скажу. Могли вообще сделать копирование из /dev/urandom. У кого значение генератора случайных чисел не совпадает с копируемым контентом - сам виноват. А вообще я бы использовал при сборке -Dmemcpy=memmove, а не создавал новые проблемы.
Интересно, что отвалится при использовании zlib-ng вместо zlib? Уверен что снова Adobe Flash.
> Недовольным же сказали что поведение пересекающихся регионов не описано в стандартеЛожь. Поведение пересекающихся регионов ОПИСАНО в стандарте - там чётко написано, что для них надо использовать другую функцию.
>> Недовольным же сказали что поведение пересекающихся регионов не описано в стандарте
> Ложь. Поведение пересекающихся регионов ОПИСАНО в стандарте - там чётко написано, что
> для них надо использовать другую функцию.подобным идиотам на документацию плевать: у них виноваты все вокруг, но только не обезьяна, которая наплевала на документацию.
что, конечно, никак не отменяет изначальной идиотичности API memcpy(3) и memove(3).
> подобным идиoтам на документацию плевать:Ну, блин, это ж зенитар.
>> Недовольным же сказали что поведение пересекающихся регионов не описано в стандарте
> Ложь. Поведение пересекающихся регионов ОПИСАНО в стандарте - там чётко написано, что
> для них надо использовать другую функцию.Спасибо за наводку, посмотрю.
Ты хочешь пользоваться API неправильно, и чтобы оно ещё корректно работало? Я рад, что не работаю с тобой в одной компании.
Я хочу переносимость бинарей между дистрами, и не хочу чтобы в Ubuntu 15.04 не запустился бинарь от Fedora 22 из-за того, что в Fedora (например) чуть более новый GCC, а в Ubuntu чуть более новый zlib.И вообще я использую Athlon XP и SLED 10 - а в новости написано что в zlib дропнут старые компиляторы. Я регулярно устанавливаю новые либы, последнее, что я устанавливал - libstdc++.so.6 из GCC 4.9 для 2GIS (в самой же системе - GCC 4.1). Обновить дистр - не вариант, так как новые на таком железе тормозят, поэтому для очередного Skype 5.0 я обновлю zlib, и получу незапускающуюся систему!
Так бинарь изначально написан криворукими макаками, и работал только потому, что так сложились звезды.
Переносимость бинарей? А зачем, собственно? Чтобы поганой проприетарщине удобнее было? Что до дропа старых компиляторов - там надо было написать не "старые", а "антикварные, кривые и замшелые". 16 бит? Несовместимые с ANSI C? Их сто лет как пора выкинуть.Ну и ожидать, что мейнстримная ось будет работать на совсем не мейнстримном (а адски устаревшем) железе - довольно глупо. Специализированные дистры в помощь для такого случая.
> Обновить дистр - не вариант, так как новые на таком железе тормозятВыкинь говнодистр и поставь нормальный.
>я обновлю zlib, и получу незапускающуюся систему!
Песочница + ldd для проверки спасут тебя
> для очередного Skype 5.0 я обновлю zlib, и получу незапускающуюся систему!А откуда ты взял что кого-то колышут твои проблемы? Особенно разработчиков дистров и либ?
Тебе с твоей любовью к проприетарному гомнецу проще всего было бы использовать винды. Там и шкап чуть ли не из коробки, и горб-гис наверняка готовый есть, и совместимость бинарников между дистрами есть (*).
* Дистрибутив может быть сделан любой компанией, при условии что эта компания - Майкрософт.
> А откуда ты взял что кого-то колышут твои проблемы?ну так Ватсон без трубки уже не может, вот и страдает прилюдно.
> Как-то раз в Glibc тоже приняли один патч. Он оптимизировал memcpy сТы всё переврал от и до. Тебя бульварный журналист покусал или ты сам себя за задницу цапнуть умудрился?
> Кто не учёл такое поведение memcpy - сам виноват!Если ты решил изобразить из себя кулхацкера и использовал функцию для того, для чего ее не предназначали, завязавшись на какое-то конкретное поведение конкретной реализации, которое никто в общем то нигде не гарантировал, а кто-то возьми да и напиши другую реализацию, работающую иначе - кто ж тебе доктор? Любители использовать недокументированные и нестандартные возможности не имеют права жаловаться что что-то отвалилось.
А буквы "-ng" в названии - это их BSD'шники покусали?
> А буквы "-ng" в названии - это их BSD'шники покусали?Не, new gen. это Прелевин. </покусал>
Это «next generation», а не «new». И вряд ли разработчики zlib-ng или той же Miranda NG знают о наших писателях-мухоморщиках. )
Формат архива ведь не изменился, zlib-ng полностью совместим с zlib?
> Формат архива ведь не изменился, zlib-ng полностью совместим с zlib?Какого архива, малыш?
> Формат архиваЭто называется bitstream (двоичный поток).
У zlib разве нет флагов сборки с оптимизацией работы под конкретной архитектурой?
А бенчмарки есть, первые результаты???
> А бенчмарки есть, первые результаты???Сколько волка^W zlib не оптимизируй, а LZ4 все-равно быстрее :)