Компания Intel представила (http://mail.madler.net/pipermail/zlib-devel_madler.net/2013-...) серию патчей, существенно повышающих производительность библиотеки zlib. Улучшения затронули быстрый и средний уровни сжатия алгоритма deflate. Была реализована ускоренная версия функции хэширования с поддержкой набора команд SSE 4.2, вычисление CRC с использованием команд PCLMULQDQ, оптимизация сдвигов при хэшировании с задействованием SSE2 и ряд иных улучшений.
Разработчик утверждает, что на его системе с CPU Core i5 в режиме высокой скорости сжатие стало на 71% быстрее (правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%). Уровень сжатия 6 стал на 50% быстрее при очень небольших потерях в степени сжатия, а уровень сжатия 9 ускорился на 22%, при том, что степень сжатия вообще не изменилась.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTUyNzY
Новость: http://www.opennet.dev/opennews/art.shtml?num=38551
Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется
У меня такое чувство, что патч не может быть под какой-либо другой лицензией, кроме материнской.
Патч может. Правда в этом случае его вряд ли возьмут в апстрим.
Еще как может, gcc как пример, там куча патчей под разными лицензиями
может. Как показала практика - разработчики Linux ядра могут взять исходники под BSDL потом наложить патчи под GPL и отказаться отдавать изменения в upstream мотивируя что они не хотят лицензировать свои изменеия под BSDL.
И всё правильно. Включали в ядро код одни люди, писали патчи совсем другие. И эти другие совсем не обязаны писать патчи под BSDL, это их выбор.
> Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажетсяА мы не задолбаемся таким макаром? Особенно в новостях про линевый кернел? А то патчей бывает много разных. Но вообще-то обычно патчи не меняют лицензию проекта. Если это не так - вот тут уже стоит написать в новости, да :).
> Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажетсяПод лицензией zlib, наверное. Под какой же еще?
Если лицензия изменилась, то это был бы скорее форк
Судя по всему, только на процессорах Intel? Или я просто К.О...
> Судя по всему, только на процессорах Intel? Или я просто К.О...Понятно что интел оптимизил под себя, но SSE2/SSE4.2 есть не только у них.
Вопрос в том, ограничились ли они применением только тех оптимизаций, которые есть не только у них. Достаточно один раз обратиться к Intel-only логике, чтобы весь патч уже был непригоден для amd64.
Или просто рассчитывать исключительно на топ, игнорируя свои же старые модели. В отстающем AMD сразу отваливается большая часть моделей. Судя по списку ниже, так и сделано.
Intel
- Westmere processor (March 2010).
- Sandy Bridge processor
- Ivy Bridge processor
- Haswell processor
AMD:
- Bulldozer processor (2011).[5]
- Piledriver based processors (including newer AMD A-series APUs)The presence of the CLMUL instruction set can be checked by testing one of the CPU feature bits.
Что то патчи сыпятся как из рога изобилия. Судя по всему, началось настоящее освоение возможностей многоядерных современных процессоров...я так ждал, так ждал :)
> настоящее освоение возможностей многоядерных современных процессоров...Интересно, где там многоядерность? Скорее, новые наборы команд освоили. Но тоже хорошо. А чего они просто так в железе место занимают? :)
Ну, в этой новости не было, но было в других с патчами "офигенной производительности"...судя по всему разрабы перешли таки в век 21 :)
чушь несёшь. Интел чувствует, как приближается к порогу плотности размещения транзистроов, начинает смещение в сторну улучшения качества.
Будет весело, когда мы окончательно упрёмся в ограничения физики и больше не сможем наращивать мощь железа. Разработчики будут вынуждены заниматься оптимизацией, и, быть может, мы даже застанем софт, который с каждой новой версией будет работать быстрее на том же железе. А то сейчас такая мода - поставить проц пожирнее да памяти побольше, когда софт работает слишком медленно.
> когда мы окончательно упрёмся в ограничения физикитогда мы перейден на новый уровень игры :))
зы. я лет 20-ть назад делал моделирование кристалла с переменный порогом уровней (что дает кристалл с примесями ) - электрон просто летал :))) Пишут что IBM уже тестируем образцы.
а смысл уже использовать zlib, когда lz4 в ядре?
> а смысл уже использовать zlibВеб-сервера, веб-браузеры (deflate).
К.О. намекает, что для этого эти патчи не предназначены т.к. увеличена скорость, но уровень сжатия снизился…
К.О. напился и забыл про уровни сжатия?
> а смысл уже использовать zlib, когда lz4 в ядре?Капитан намекает, что самокат, фургон и боинг имеют разные области применения.
LZ4 - "максимально быстрый компрессор". Там никто не заморачивается степенью сжатия - "как-то жмет". Зато "очень быстро". Это одностадийный LZ, простой как топор и быстрый как ракета. Он на современном компьютере может достигать скоростей в сотни Мб/сек и даже Гб/сек на поток. Это позволяет ему жать например данные на диске и при этом еще и выигрывать в скорости записи/чтения, несмотря на, казалось бы, добавочную работу.
Zlib - середнячок. Он не мегатормоз но и не чемпион по скорости. Жмет тоже средне. После lempel-ziv'а прикручен huffman, так что за счет дожатия хаффманом он при прочих равных имеет шансы сжать лучше чем LZ без нифига типа LZ4. Но т.к. это дополнительная стадия - сжатие и распаковка будут разумеется медленеее.
Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).
> Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).Нет, это ещё не тяжеловес, так, чуть выше среднего. Если нужно действительно сильное сжатие, есть paq8l -9. Логи и XML жмёт в 2 раза эффективнее xz -9e, но кушая очень много RAM и CPU, причём скорость распаковки равна скорости сжатия.
Матан семейства PAQ посмотреть можно тут: http://en.wikipedia.org/wiki/PAQ
Там адаптивные алгоритмы и нейронки.
$ paq8 -8 DATA.rndCreating archive DATA.rnd.paq8l with 1 file(s)...
DATA.rnd 4194304 -> 4197134
4194304 -> 4197164
Time 446.99 sec, used 1643022601 bytes of memoryАрхив стал больше исходного, аж на 2860 байт!
Процесс сжатия файла размером 4 мегабайта занял 7.5 минут!!!
При этом сожрав 1.5 гигабайта оперативки!!!Кому он, такой красивый, нужен? :D
> Кому он, такой красивый, нужен? :DЭто переложение анекдота "про суровых сибирских лесорубов и новую японскую бензопилу" на опеннетовскую тематику?
> paq8 -8 DATA.rndВы случайно жали не набор рандомных байт?
Чёрт, я год перепутал. Привет вам из 2016-ого!
> а смысл уже использовать zlib, когда lz4 в ядре?А смысл в lz4, когда lzo давным давно в ядре и он ничем не хуже lz4 (а lz4hc - значительно тормознее)?
да, разницы нет
С ухудшением сжатия не нужно. Но вообще штука очень полезная например при рендеринге карт openstreetmap, где нужно сжимать 100500 png'шек.
> С ухудшением сжатия не нужно.Когда заказывают fastest сжатие - степень сжатия явно не в приоритете, так что некоторый пойнт в таком решении есть.
А случаем никто не объяснит как получилось так, что оптимизация повлияла на степень сжатия? Получается, что изменился алгоритм.
> А случаем никто не объяснит как получилось так, что оптимизация повлияла на
> степень сжатия? Получается, что изменился алгоритм.Сгенерировать один и тот же формат потока можно бесконечным количеством способов. А разогнать любой LZ можно путем более раннего забивания на поиск совпадений, например. При том на fastest методе сжатие такое ничем особо и не плохо, если кто просил побыстрее - значит ему нагрузка на проц и/или скорость работы была важнее.
> Сгенерировать один и тот же формат потока можно бесконечным количеством способов.пруф?
Не нужно цепляться к словам. Не бесконечным, конечно, но довольно большим.
ты даёшь, тут же принципиальная разница
>> Сгенерировать один и тот же формат потока можно бесконечным количеством способов.
> пруф?Моск?
2 - 1 = 1,
3 - 2 = 1
49999999999999999999999999 - 49999999999999999999999998 = 1
...
Элементарно: если алгоритм рассчитан на работу с байтиками, а процессор вполне оптимально ворочает сразу бОльшими блоками, то переориентация на эти блоки ускорит работу, но ухудшит результат.
Если в новости не слепили кислое с зеленым, то, видимо, какой-то сайд-эффект уменьшения точности работы с вещественными числами от перехода на новые инструкции.
В SSE регистры 64-разрядные против 80-тиразрядных традиционных - это само по себе съедает точность, но можено выставить и еще меннее качественную (и более быструю) математику.
> В SSE регистры 64-разрядные против 80-тиразрядных традиционных<sarcasm> вот где "проигрыш примерно на 30%"! </sarcasm>
> правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%Они офигели? Почему бы честно не взять уровень сжатия на единицу меньше?
> Почему бы честно не взять уровень сжатия на единицу меньше?Больше даже похоже на "а почему они не попробовали при произведении измерений включить сжатие?"
> Почему бы честно не взять уровень сжатия на единицу меньше?... при том что это уже и так fastest? :)
Зато
Level 9 is about 22% faster with no change in compression.
Level 6 is about 50% faster with negligible change in compression.
> в режиме высокой скорости сжатие стало на 71% быстрее (правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%)Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
> Да я и на AMD могу ускорить сжатие в ущерб размеру архива.Вы можете сделать это для каждой команды deflate по всем серверам мира?
(А Интел - может ;) )
>> Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
> Вы можете сделать это для каждой команды deflate по всем серверам мира?
> (А Интел - может ;) )Все сервера мира вовсе не обязательно на процессорах Intel...
Под какаю версию патчи? Кто уже юзал? Иль как всегда - попердели в лужу и разбежались?
>Иль как всегда - попердели в лужу и разбежались?Судя по минусу, всё ясно. :D
Ну так вот, на git версию, и на 1.2.8 не накладываются, ~ 90% FAILED, остальные hunk offset.
В ручную идейно не буду править.
Кому нужны исходники LZ4 для своих проектов, см. ссылку: http://code.google.com/p/lz4/