The OpenNET Project / Index page

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

Компания Intel представила серию патчей, существенно ускоряющих библиотеку сжатия zlib

29.11.2013 12:25

Компания Intel представила серию патчей, существенно повышающих производительность библиотеки zlib. Улучшения затронули все уровни сжатия алгоритма deflate. Была реализована ускоренная версия функции хэширования с поддержкой набора команд SSE 4.2, вычисление CRC с использованием команд PCLMULQDQ, оптимизация сдвигов при хэшировании с задействованием SSE2 и ряд иных улучшений.

Разработчик утверждает, что на его системе с CPU Core i5 в режиме высокой скорости сжатие стало на 71% быстрее (правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%). Уровень сжатия 6 стал на 50% быстрее при очень небольших потерях в степени сжатия, а уровень сжатия 9 ускорился на 22%, при том, что степень сжатия вообще не изменилась.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
Автор новости: Аноним
Тип: Программы
Ключевые слова: zlib, compress
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (51) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, oops (ok), 17:55, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется
     
     
  • 2.2, anonimchiikun (?), 18:02, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +16 +/
    У меня такое чувство, что патч не может быть под какой-либо другой лицензией, кроме материнской.
     
     
  • 3.3, annulen (ok), 18:11, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Патч может. Правда в этом случае его вряд ли возьмут в апстрим.
     
  • 3.27, oops (ok), 02:02, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Еще как может, gcc как пример, там куча патчей под разными лицензиями
     
  • 3.37, linux must __RIP__ (?), 14:21, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    может. Как показала практика - разработчики Linux ядра могут взять исходники под BSDL потом наложить патчи под GPL и отказаться отдавать изменения в upstream мотивируя что они не хотят лицензировать свои изменеия под BSDL.
     
     
  • 4.45, Аноним (-), 21:28, 01/12/2013 [^] [^^] [^^^] [ответить]  
  • +/
    И всё правильно. Включали в ядро код одни люди, писали патчи совсем другие. И эти другие совсем не обязаны писать патчи под BSDL, это их выбор.
     
  • 2.9, Аноним (-), 18:36, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется

    А мы не задолбаемся таким макаром? Особенно в новостях про линевый кернел? А то патчей бывает много разных. Но вообще-то обычно патчи не меняют лицензию проекта. Если это не так - вот тут уже стоит написать в новости, да :).

     
  • 2.10, Аноним (-), 18:36, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Под какой лицензией выпущены патчи? В новости стоит указать тоже, мне кажется

    Под лицензией zlib, наверное. Под какой же еще?

     
  • 2.17, Аноним (-), 19:24, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Если лицензия изменилась, то это был бы скорее форк
     

  • 1.5, Anonymous1 (?), 18:16, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Судя по всему, только на процессорах Intel? Или я просто К.О...
     
     
  • 2.12, Аноним (-), 18:37, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Судя по всему, только на процессорах Intel? Или я просто К.О...

    Понятно что интел оптимизил под себя, но SSE2/SSE4.2 есть не только у них.

     
     
  • 3.31, тоже Аноним (ok), 10:50, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Вопрос в том, ограничились ли они применением только тех оптимизаций, которые есть не только у них. Достаточно один раз обратиться к Intel-only логике, чтобы весь патч уже был непригоден для amd64.
    Или просто рассчитывать исключительно на топ, игнорируя свои же старые модели. В отстающем AMD сразу отваливается большая часть моделей. Судя по списку ниже, так и сделано.
     
  • 2.26, ADMIN (?), 02:00, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    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.

     

  • 1.6, 3draven (ok), 18:28, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Что то патчи сыпятся как из рога изобилия. Судя по всему, началось настоящее освоение возможностей многоядерных современных процессоров...я так ждал, так ждал :)
     
     
  • 2.11, Аноним (-), 18:37, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > настоящее освоение возможностей многоядерных современных процессоров...

    Интересно, где там многоядерность? Скорее, новые наборы команд освоили. Но тоже хорошо. А чего они просто так в железе место занимают? :)

     
     
  • 3.16, 3draven (ok), 18:54, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну, в этой новости не было, но было в других с патчами "офигенной производительности"...судя по всему разрабы перешли таки в век 21 :)
     
  • 2.35, all_glory_to_the_hypnotoad (ok), 12:24, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    чушь несёшь. Интел чувствует, как приближается к порогу плотности размещения транзистроов, начинает смещение в сторну улучшения качества.
     
     
  • 3.38, burjui (ok), 18:30, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Будет весело, когда мы окончательно упрёмся в ограничения физики и больше не сможем наращивать мощь железа. Разработчики будут вынуждены заниматься оптимизацией, и, быть может, мы даже застанем софт, который с каждой новой версией будет работать быстрее на том же железе. А то сейчас такая мода - поставить проц пожирнее да памяти побольше, когда софт работает слишком медленно.
     
     
  • 4.46, fi (ok), 22:48, 01/12/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > когда мы окончательно упрёмся в ограничения физики

    тогда мы перейден на новый уровень игры :))

    зы. я лет 20-ть назад делал моделирование кристалла с переменный порогом уровней (что дает кристалл с примесями ) - электрон просто летал :))) Пишут что IBM уже тестируем образцы.

     

  • 1.7, Fracta1L (ok), 18:34, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    а смысл уже использовать zlib, когда lz4 в ядре?
     
     
  • 2.13, Аноним (-), 18:42, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > а смысл уже использовать zlib

    Веб-сервера, веб-браузеры (deflate).

     
     
  • 3.23, apollo2k4 (ok), 23:17, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    К.О. намекает, что для этого эти патчи не предназначены т.к. увеличена скорость, но уровень сжатия снизился…
     
     
  • 4.40, burjui (ok), 18:33, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    К.О. напился и забыл про уровни сжатия?
     
  • 2.14, Аноним (-), 18:47, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +18 +/
    > а смысл уже использовать zlib, когда lz4 в ядре?

    Капитан намекает, что самокат, фургон и боинг имеют разные области применения.

    LZ4 - "максимально быстрый компрессор". Там никто не заморачивается степенью сжатия - "как-то жмет". Зато "очень быстро". Это одностадийный LZ, простой как топор и быстрый как ракета. Он на современном компьютере может достигать скоростей в сотни Мб/сек и даже Гб/сек на поток. Это позволяет ему жать например данные на диске и при этом еще и выигрывать в скорости записи/чтения, несмотря на, казалось бы, добавочную работу.

    Zlib - середнячок. Он не мегатормоз но и не чемпион по скорости. Жмет тоже средне. После lempel-ziv'а прикручен huffman, так что за счет дожатия хаффманом он при прочих равных имеет шансы сжать лучше чем LZ без нифига типа LZ4. Но т.к. это дополнительная стадия - сжатие и распаковка будут разумеется медленеее.

    Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).

     
     
  • 3.39, bircoph (ok), 18:31, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну а если нам надо будет тяжеловеса - мы вообще позовем LZMA. Этот жмет весьма конкретно. Но медленнее, особенно на сжатие (у LZ-based есть асимметрия, тормознуть декомпрессию сложно, а вот компрессор при желании может довольно долго сопли жевать, выискивая наилучшие совпадения из всех возможных).

    Нет, это ещё не тяжеловес, так, чуть выше среднего. Если нужно действительно сильное сжатие, есть paq8l -9. Логи и XML жмёт в 2 раза эффективнее xz -9e, но кушая очень много RAM и CPU, причём скорость распаковки равна скорости сжатия.

    Матан семейства PAQ посмотреть можно тут: http://en.wikipedia.org/wiki/PAQ
    Там адаптивные алгоритмы и нейронки.

     
     
  • 4.41, pavlinux (ok), 19:33, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    $ paq8 -8 DATA.rnd

    Creating 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

     
     
  • 5.48, Аноним (-), 16:58, 02/12/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кому он, такой красивый, нужен?  :D

    Это переложение анекдота "про суровых сибирских лесорубов и новую японскую бензопилу" на опеннетовскую тематику?

     
  • 5.52, Гентушник (ok), 14:28, 07/07/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  paq8 -8 DATA.rnd

    Вы случайно жали не набор рандомных байт?

    Чёрт, я год перепутал. Привет вам из 2016-ого!

     
  • 2.28, Led (ok), 02:46, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а смысл уже использовать zlib, когда lz4 в ядре?

    А смысл в lz4, когда lzo давным давно в ядре и он ничем не хуже lz4 (а lz4hc - значительно тормознее)?

     
     
  • 3.29, Fracta1L (ok), 10:09, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    да, разницы нет
     

  • 1.8, Аноним (-), 18:35, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    С ухудшением сжатия не нужно. Но вообще штука очень полезная например при рендеринге карт openstreetmap, где нужно сжимать 100500 png'шек.
     
     
  • 2.15, Аноним (-), 18:49, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > С ухудшением сжатия не нужно.

    Когда заказывают fastest сжатие - степень сжатия явно не в приоритете, так что некоторый пойнт в таком решении есть.

     
     
  • 3.18, Аноним (-), 19:46, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А случаем никто не объяснит как получилось так, что оптимизация повлияла на степень сжатия? Получается, что изменился алгоритм.
     
     
  • 4.22, Аноним (-), 23:01, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А случаем никто не объяснит как получилось так, что оптимизация повлияла на
    > степень сжатия? Получается, что изменился алгоритм.

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

     
     
  • 5.30, Fracta1L (ok), 10:10, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Сгенерировать один и тот же формат потока можно бесконечным количеством способов.

    пруф?


     
     
  • 6.34, www2 (ok), 11:01, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Не нужно цепляться к словам. Не бесконечным, конечно, но довольно большим.
     
     
  • 7.36, Fracta1L (ok), 12:35, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    ты даёшь, тут же принципиальная разница
     
  • 6.42, pavlinux (ok), 19:53, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Сгенерировать один и тот же формат потока можно бесконечным количеством способов.
    > пруф?

    Моск?

    2 - 1 = 1,
    3 - 2 = 1
    49999999999999999999999999 - 49999999999999999999999998 = 1
    ...

     
  • 4.32, тоже Аноним (ok), 10:58, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Элементарно: если алгоритм рассчитан на работу с байтиками, а процессор вполне оптимально ворочает сразу бОльшими блоками, то переориентация на эти блоки ускорит работу, но ухудшит результат.

     
  • 4.47, Аноним (-), 14:31, 02/12/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если в новости не слепили кислое с зеленым, то, видимо, какой-то сайд-эффект уменьшения точности работы с вещественными числами от перехода на новые инструкции.
    В SSE регистры 64-разрядные против 80-тиразрядных традиционных - это само по себе съедает точность, но можено выставить и еще меннее качественную (и более быструю) математику.
     
     
  • 5.50, XoRe (ok), 18:33, 05/12/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > В SSE регистры 64-разрядные против 80-тиразрядных традиционных

    <sarcasm> вот где "проигрыш примерно на 30%"! </sarcasm>

     

  • 1.19, gegMOPO3 (?), 20:52, 29/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%

    Они офигели? Почему бы честно не взять уровень сжатия на единицу меньше?

     
     
  • 2.20, Аноним (-), 21:55, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Почему бы честно не взять уровень сжатия на единицу меньше?

    Больше даже похоже на "а почему они не попробовали при произведении измерений включить сжатие?"

     
  • 2.21, Аноним (-), 22:58, 29/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Почему бы честно не взять уровень сжатия на единицу меньше?

    ... при том что это уже и так fastest? :)


     
  • 2.25, Серж (??), 01:28, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зато
    Level 9 is about 22% faster with no change in compression.
    Level 6 is about 50% faster with negligible change in compression.
     

  • 1.24, Zenitur (ok), 01:13, 30/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > в режиме высокой скорости сжатие стало на 71% быстрее (правда, в ущерб размеру сжатых данных, проигрыш примерно на 30%)

    Да я и на AMD могу ускорить сжатие в ущерб размеру архива.

     
     
  • 2.33, тоже Аноним (ok), 10:59, 30/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Да я и на AMD могу ускорить сжатие в ущерб размеру архива.

    Вы можете сделать это для каждой команды deflate по всем серверам мира?
    (А Интел - может ;) )

     
     
  • 3.43, Anonymous1 (?), 12:43, 01/12/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Да я и на AMD могу ускорить сжатие в ущерб размеру архива.
    > Вы можете сделать это для каждой команды deflate по всем серверам мира?
    > (А Интел - может ;) )

    Все сервера мира вовсе не обязательно на процессорах Intel...

     

  • 1.44, pavlinux (ok), 16:14, 01/12/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Под какаю версию патчи? Кто уже юзал? Иль как всегда - попердели в лужу и разбежались?
     
     
  • 2.49, pavlinux (ok), 18:07, 02/12/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Иль как всегда - попердели в лужу и разбежались?

    Судя по минусу, всё ясно. :D

    Ну так вот, на git версию, и на 1.2.8 не накладываются, ~ 90% FAILED, остальные hunk offset.
    В ручную идейно не буду править.

     

  • 1.51, DrPill (?), 12:49, 03/07/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кому нужны исходники LZ4 для своих проектов, см. ссылку: http://code.google.com/p/lz4/
     

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



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

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