company_banner

Проекты Центра разработки Intel в России. Intel Integrated Performance Primitives

    Наш рассказ об очередном проекте Intel, сделанном в России. Это библиотека Intel Integrated Performance Primitives – набор готовых к употреблению, высоко оптимизированных под различные архитектуры Intel, к тому же совершенно бесплатных базовых функций для работы с изображениями, сигналами и произвольными данными. Каким образом зародился этот проект, как развивался, что происходит в Intel IPP сейчас – в статье под катом. А начнем мы, как это принято в резюме, с современности.

    На КДПВ — вход на этаж IPP в офисе Intel в Нижнем Новгороде

    Что такое Intel IPP сейчас


    Итак, Intel IPP – это кирпичики функциональных примитивов, позволяющие существенно ускорить работу ПО, обрабатывающего медиа и данные, за счет специфичных для конкретных микроархитектур и платформ Intel оптимизаций, а также максимально широкого использования наборов векторных инструкций Intel SSE и Intel AVX всех версий.
    Функции IPP покрывают четыре больших домена:

    • Обработка изображений;
    • Сжатие данных;
    • Обработка сигналов;
    • Криптография.

    Текущая версия Intel IPP 2020 Update 2 содержит более 2 500 примитивов обработки изображений, 1 300 примитивов обработки сигналов, 500 – компьютерного зрения и 300 – криптографии.

    Библиотека постоянно совершенствуется – оптимизируется под новые платформы, добавляется новая функциональность и неизбежно удаляется старая, малоиспользуемая.
    Intel IPP работает на любом устройстве с х86 архитектурой под управлением Linux, macOS, Windows и Android. То есть, поддерживаются процессоры не только Intel, но и других производителей, причём, работает IPP на них быстро, хотя, конечно, и не так супербыстро, как на устройствах Intel.

    При этом пользователям IPP не требуется глубоких знаний о платформе исполнения их кода, использующего IPP, и связанных с этим действий – нужная версия оптимизаций будет вызвана автоматически.

    IPP написана на языке Си с использованием так называемых интринсик-функций компилятора. Для разных моделей применения библиотеки имеются различные ее версии: однопоточная для вызовов из разных потоков внешних приложений и многопоточная, использующая эффективное внутреннее распараллеливание.

    Для интересующихся скоростью работы на Intel Xeon и Core – некоторые бенчмарки.

    В настоящее время IPP доступна в составе Intel Parallel Studio XE, Intel System Studio, и просто сама по себе. И – абсолютно бесплатно для персонального и коммерческого использования.

    Интересно, что наиболее «закрытая» область нашей жизни – криптография, в случае IPP сейчас является наиболее открытой – это проект с открытым кодом, доступный на Github.

    Тот задел, подход и API, что принёс IPP при своем появлении в обработку сигналов и изображений, сейчас можно назвать негласным стандартом — то же самое касается и криптографии.

    Все компоненты библиотеки используются миллионами пользователей в сотнях тысяч приложений по всему миру. В том числе и внутри самой компании — в различных подразделениях Intel. Intel IPP обеспечивает значительное ускорение работы библиотеки OpenCV. Кстати, специальная сборка Intel IPP c функциями, используемыми OpenCV, выпущенная в 2015 году, стала первой бесплатной свободно распространяемой версией IPP.

    Intel IPP можно встретить в приложениях для распознавания и улучшения изображений во всех областях, включая медицину; принтерах, в том числе и 3D; цифровом видеонаблюдении; автономных автомобилях; распознавании и синтезе речи; сжатии данных; телекоммуникации и играх. IPP работает везде – от серверов до носимых устройств. Можно утверждать, что если бы была изобретена машина времени, то ее софт обязательно использовал бы Intel IPP.

    История IPP


    Начиналось всё с библиотек Intel по обработке сигналов (SPL) и обработки изображений (IPL), разрабатывавшихся по заказу Intel в федеральном ядерном центре ВНИИЭФ в Сарове (мы писали про это в рассказе про OpenCV).

    В 1996 (или 1997 году по свидетельствам разных очевидцев) в головном офисе Intel Санта Клара прошло совещание по поводу дальнейших планов развития SPL и IPL с участием американских кураторов проекта и приглашенных специалистов из Сарова, среди которых был будущий архитектор, вдохновитель и руководитель команды IPP Борис Сабанин, а также Сергей Кириллов, в настоящее время возглавляющий работу над IPP-криптографией.

    Саровская команда привезла свой список предложений, и одним из них было открытие для пользователей интерфейсов низкоуровневых функций IPL и SPL, так как они все равно уже были реализованы и оптимизированы, меж тем некоторым пользователям форматы данных IPL были неудобны, у них в готовых продуктах уже были свои сложившиеся форматы изображений. Предлагаемый прототип интерфейса IPP, использующий более простые в сравнении с IPL/ISL структуры, был создан Борисом Сабаниным в ходе обсуждения буквально на салфетке. Но в то время предложение российской стороны хотя и не было отвергнуто, но и не получило особой поддержки — оно оказалось в середине списка с малым приоритетом. Но через пару лет кто-то в Intel вспомнил об этом (скорее всего, Шин Ли, впоследствии ставший «евангелистом» Intel IPP) и планы поменялись.


    Книга про Intel IPP, написанная в 2004 Stewart Taylor, участником исторического совещания по созданию IPP (в то время — только что нанятым в Intel бакалавром Стэнфорда)

    Так началась работа над библиотеками Intel Performance Primitives, которые позднее были переименованы в Integrated Performance Primitives.

    Внутренний вариант IPP, назовем его 1.0, был создан в 1999 году. Это был скорее Proof of Concept, прототип для подтверждения жизнеспособности концепции. Он не выпускался как продукт, но позволил определить и уточнить концепцию, архитектуру и спецификации IPP. Первая публичная версия сразу носила номер 2.0 и вышла в апреле 2002 года.

    Основная часть работ над библиотеками IPP до 2009 года проходила под руководством Бориса Сабанина, которого по праву можно считать крестным отцом и душой IPP. Он вложил в проект много сил, выстроил команду разносторонних специалистов но, к сожалению, немного не дожил до двадцатилетия Intel IPP.


    Картина «Мост к саровской башне» авторства Бориса Сабанина, известного не только IPP (здесь можно посмотреть другие картины Сабанина, в том числе его автопортрет)

    Но наследием IPL/ISL дело не ограничилось. Практически сразу появились примитивы для криптографии и компрессии данных. Начались эксперименты в области Computer Vision, которые позже переросли в проект с OpenCV, использующий ускорение алгоритмов с помощью примитивов в ippCV домене.

    Конечно же, это был не единственный эксперимент и ответвление в истории создания библиотек. IPP шли в ногу со всем Intel. Соответственно, например, пятая версия IPP помимо x86 поддерживала и процессор Intel XScale (ARM архитектура) и Intel Itanium (IA-64)! В разные годы IPP включали такие компоненты как трассировка лучей (realistic rendering), операции с небольшими матрицами (small matrix operations), проверка целостности данных (data integrity), видео и аудио кодеки.

    Эту функциональность при желании можно использовать и сейчас – с помощью пакета IPP Legacy Libraries, доступного для скачивания.

    Более того, видеокодеки IPP в дальнейшем послужили основой другого известного продукта Intel – Intel Media SDK, а трассировка лучей была реализована в проекте с открытом кодом Intel Embree.

    Из интересных технологических опытов в области IPP-строения можно отметить пример Windows-драйвера для демонстрации возможности работы IPP в режиме ядра, а также версию IPP для работы на интегрированных Intel GPU, написанную на C for Metal.

    Любопытно, что номера версий IPP сначала шли по порядку от 1 до 9, а потом начали обозначаться годом выхода — 2017-2020.


    Команда разработчиков Intel IPP в 2003 году

    За время существования семейства библиотек IPP в работе над ними принимало участие более 100 человек — в Сарове, Нижнем Новгороде и Москве. Сейчас штаб-квартира IPP находится в Нижнем Новгороде и выглядит очень привлекательно!


    Оформление этажа IPP в Intel

    IPP – совсем не примитивная библиотека!


    Хотя в названии Intel IPP и есть слово «примитив», да и на первый взгляд, никаких принципиальных сложностей в наборе «деталей конструктора» для создания производительных программ, которым по сути является IPP, быть не может, устройство этих библиотек совсем не тривиально. Для обеспечения максимальной производительности и удобства использования IPP применены интересные технологические решения.

    Как уже было сказано, в IPP содержатся тысячи функций (а каждая функция имеет несколько версий, оптимизированных под конкретную архитектуру), что приводит к огромным размерам готовых библиотек, что вовсе не является пунктом в списке преимуществ для пользователей IPP.
    Поэтому IPP собирается особым образом. Исходные файлы, включающие большое количество простых функций, перед компиляцией разрезаются специальным скриптом на много мелких, по одной функции на файл. И потом эти мини-файлы компилируются. Причем компилируются не один раз, а несколько – под разные архитектуры с соответствующими флагами. В результате получается несколько огромных статических библиотек — на каждый IPP домен. Но эти статические библиотеки склеены из очень небольших объектных файлов. Поэтому когда IPP линкуется статически к приложению, размер приложения увеличивается практически ровно на размер используемых из IPP функций, ни байтом больше.

    Также в IPP имеется механизм генерации специализированных (custom) библиотек на базе существующих инструментов без необходимости открывать пользователям исходный код. А именно, из заголовочных файлов пользователь выбирает список интересующих его функций, после чего из огромных статических библиотек автоматически скриптом создается небольшая динамическая библиотека только с нужными функциями и их зависимостями. Более того, для дальнейшего сокращения размера эта динамическая библиотека может включать в себя варианты сборки указанных функций не под все варианты железа, а исключительно под заданный пользователем список платформ.

    В ситуации, когда каждый дополнительный процент производительности библиотек IPP имеет значение, очень важным становится решение, на каком уровне осуществлять параллелизацию кода: внутри функций библиотеки, что хорошо для вызовов IPP из одного пользовательского потока, либо снаружи, на уровне пользовательских приложений, что хорошо для многопоточных приложений, самостоятельно разделяющих работу и данные для IPP.

    Поскольку приложения бывают разные, и IPP сделаны тоже разные. А именно, в комплект поставки IPP входят по два набора библиотек в 32 и 64-битной версиях: одна чисто однопоточная внутри, а вторая — с внутренним распараллеливанием значительного количества функций при помощи OpenMP (точный список функций прилагается в сопроводительных документах). Кроме того, для библиотек обработки изображения есть и еще одна версия — «мнопоточный слой» (Threading Layer), представляющая собой надстройку над однопоточной IPP и использующая либо OpenMP либо Intel TBB для внешнего распараллеливания работы над изображениями, разделяемыми для этого на фрагменты (тайлы). Исходные коды IPP Threading Layer доступны в пакете IPP и нужны тем, кто хочет получить максимально возможный контроль над параллельной работой своего кода.

    Почти с самого возникновения IPP разработчикам пришлось озаботиться проблемой того, что конвейеры обработки изображений и сигналов, состоящие из отдельных функций IPP, работают медленнее, чем хотелось бы. Объясняется это просто: при вызове IPP-функций происходит как правило загрузка-выгрузка из кеша или даже из памяти, а эта операция может оказаться заметно дороже собственно вычислений. Этот эффект особенно заметен при обработке больших данных — не тех, что называют big data, а например, изображений формата FullHD (не говоря уже о 4К).

    Решение объединить несколько функций внутри IPP в одну в этом случае не подходит – тогда вместо примитивов-кирпичиков мы получим причудливые детали из игры «тетрис», вставить которые в пользовательские приложения будет проблематично, а разнообразие таких возможных объединений превысит все разумные пределы.

    В результате была реализована C++ надстройка над IPP, которая строила графы конвейеров, нарезала картинки на кусочки, и потом запускала параллельный цикл, который в каждом потоке выполнял не одну операцию, а весь IPP конвейер на отдельном тайле. В конце, конечно результаты склеивались. Сначала был сделан прототип, он показал приличное ускорение. Потом была создана настройка под названием DMIP (deferred-mode image processing). Далее, в 2011 году на одном из первых заседаний комитета стандартизации OpenVX в Khronos, DMIP был упомянут и горячо поддержан комитетом с учетом популярности графов у разработчиков железа. Так стандарт OpenVX получился основанным на графовой технологии. Стандарт OpenVX по разным причинам не получил достаточной популярности, но зато сейчас графовую парадигму поддерживает и развивает технологию команда Intel Graph API. А так как Graph API входит в OpenCV, OpenVINO, Movidius SDK, то налицо прямое влияние технологий IPP на стандарты компьютерного зрения и современные API.

    IPP – полезные ссылки


    Еще раз приведем самые главные ссылки из этой статьи.


    Intel IPP от первого лица


    Предоставим слово людям, в разные годы сыгравшим важную роль в судьбе Intel Performance Primitives.

    Владимир Дудник, руководитель команды Intel IPP в 2009-2011 годах
    По-моему, у IPP по прежнему очень сильная концепция – предоставить индустрии легкий, достаточно низкоуровневый слой абстракции от различий разных аппаратных платформ. Несмотря на существенный прогресс в развитии компиляторов, по-прежнему нет возможности из описания на языке высокого уровня получить оптимальный по размеру и производительности машинный код для функций преобразования Фурье, фильтров разного рода и т.п. Это означает что у IPP по-прежнему есть ниша, где она нужна и действительно полезна для ускорения разработки кросс-платформенных высокопроизводительных программ.
    Думается, есть потенциальная возможность присмотреться к потребностям разных фреймворков глубокого обучения, там много достаточно стандартных, относительно простых операций, которые могут быть ускорены SIMD инструкциями. Часть из них, как правило многомерные свертки, покрываются библиотекой MKL, но и для IPP возможность применения можно найти.

    Вадим Писаревский, лидер проекта OpenCV, участник команды IPPCV в 2006-2008 годах
    Если говорить про IPP в целом, то, конечно, скорость у библиотеки выдающаяся. Особенно флагманские функции типа FFT. Ядра — чистый изумруд! К счастью, у меня была возможность немного поизучать исходники IPP в свое время, и местами это был просто учебник, как надо писать эффективный код.
    В свое время команду IPP очень сильно заинтересовала проблема автогенерации кода, в частности, на OCaml, и впечатлили успехи проекта Spiral, который сумел автоматически сгенерировать ядра FFT и родственных преобразований — на уровне или даже обходивших по скорости реализованные в IPP. Часть этих ядер потом была включена в IPP. А меня, в свою очередь, эта тема зацепила настолько, что мой текущий проект, 13-14 лет спустя, с этой темой связан.

    Павел Бердников, руководитель команды IPP QA в 2011-2015 годах, руководитель команды IPP в 2017-2020 годах
    Работу в IPP я начал в QA команде в Сарове в 2000г. с написания тестов, позже создав единую билдовую систему для такого сложного проекта, автоматизированный процесс построения и тестирования.
    А 17 лет спустя в Нижнем Новгороде стал руководителем всей команды IPP. Пришлось знакомиться с партнёрами внутри Intel и пользователями за его пределами. Изменить способы планирования и разработки кода от старых waterfall & development к современным agile & DevOps. Пересмотреть стратегии проекта и придумать новые. Так проект больше сосредоточился на криптографии и компрессии данных, появились интересные направления работы и новые области развития.
    Реалистичные планы по развитию проекта – развивать что есть и смотреть в смежные области. Фантастические планы, которые были ранее в мечтах, разбились о понимание мировых трендов и нужд наших пользователей. Пришло осознание, что бесконечные ресурсы, которые всегда очень хочется получить чтобы сделать больше и глубже, не дадут ожидаемого результата. Наверное, если бы я получил полную свободу действий и ресурсы, я бы пошёл дальше в область исследований новых алгоритмов, в область университетов и работы с ними.

    Валентин Кубарев, руководитель команды Image & Signal Processing проекта Intel IPP, 2020 год – настоящее время
    Работу в IPP я начал в качестве SW инженера в 2011 году, когда проект только переехал из Сарова в Нижний Новгород. Меня всегда интересовала работа, связанная с математикой и оптимизацией. Знакомство с IPP я начал с функциональности изменения размера изображения, после чего долгое время отвечал за поддержку, разработку и оптимизацию геометрических преобразований, таких как Resize, WarpAffine, WarpPerspective и т. д. C 2017 года активно участвовал в задачах связанных с криптографией, и, в итоге, в 2018 мы смогли открыть код IPP Crypto и выложить проект на GitHub. С конца 2018 года работал в другом проекте, в 2020 году снова вернулся в IPP, но уже как руководитель Image & Signal Processing домена. Считаю, что в данный момент данная часть проекта недооценена, поэтому активно работаю с пользователями продукта IPP и нашими партнёрами внутри компании Intel, чтобы вывести проект на новый уровень.
    Intel
    Компания

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое