Интервью: перспективы Intel oneAPI и Direct Parallel C++

Intel — не первое имя, которое приходит на ум, когда вы думаете о разработке программного обеспечения, хотя это одна из самых влиятельных и инновационных технологических компаний на планете. Четыре десятилетия назад процессор Intel 8088 помог начать революцию в ПК, и если вы читаете это на настольном компьютере или ноутбуке, скорее всего, у вас есть Intel Inside. То же самое касается серверов и целого ряда другого оборудования, на которое мы полагаемся каждый день. Это не означает, что у AMD и других поставщиков нет конкурентоспособных продуктов, потому что они есть, но Intel по-прежнему доминирует на рынке процессоров x86.

Инженеры-программисты десятилетиями используют аппаратные платформы Intel, как правило, даже не задумываясь о программном и микропрограммном обеспечении, стоящем за ними. Если им нужна была более высокая производительность виртуализации, они выбирали многоядерные продукты Core i7 с гиперпоточностью или Xeon. Для работы с локальной базой данных они могут получить твердотельный накопитель Intel. Но теперь Intel хочет, чтобы разработчики также начали использовать больше ее программного обеспечения.

Что такое Intel oneAPI?

Войдите в oneAPI, который Intel рекламирует как единую унифицированную модель программирования, призванную упростить разработку для различных аппаратных архитектур: ЦП, ГП, ПЛИС, ускорителей искусственного интеллекта и т. д. Все они имеют очень разные свойства и превосходны в различных типах операций.

Теперь Intel придерживается стратегии «программное обеспечение прежде всего» и ожидает, что разработчики обратят на это внимание. Грандиозная идея oneAPI состоит в том, чтобы позволить использовать одну платформу для различных аппаратных средств, поэтому разработчикам не придется использовать разные языки, инструменты и библиотеки, например, при написании кода для процессоров и графических процессоров. С одним API набор инструментов и кодовая база будут одинаковыми для обоих.

Чтобы сделать это возможным, Intel разработала Data Parallel C++ (DPC++) как альтернативу с открытым исходным кодом проприетарным языкам, обычно используемым для программирования для определенного оборудования (например, GPU или FFPGA). Этот новый язык программирования должен обеспечивать производительность и удобство C++, в то же время включая компилятор для развертывания на различных аппаратных устройствах.

Data Parallel C++ также включает SYCL Khronos Group для поддержки параллелизма данных и гетерогенного программирования. В настоящее время Intel предлагает бесплатный доступ к своему DevCloud, что позволяет разработчикам программного обеспечения опробовать свои инструменты и работать с oneAPI и DPC++ в облаке без особых хлопот.

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

Чтобы узнать больше об oneAPI, мы обсудили его происхождение и будущее с Сандживом М. Шахом, вице-президентом группы Intel по архитектуре, графике и программному обеспечению и генеральным менеджером по техническим, корпоративным и облачным вычислениям в Intel.

Санджив: С точки зрения того, что есть в oneAPI, я думаю об этом как о четырех частях. Один — это язык и стандартная библиотека, второй — набор инструментов для глубокого обучения, третий — это уровень аппаратной абстракции и уровень программного драйвера, который может абстрагировать различные ускорители, а четвертый — набор предметно-ориентированных библиотек. , как Matlab и так далее. Это четыре категории вещей в oneAPI, но мы можем пойти глубже и поговорить о девяти элементах oneAPI. Эти девять элементов представляют собой новый язык, который мы представляем под названием Data Parallel C++, и его стандартную библиотеку.

Есть две обучающие библиотеки, одна для нейронных сетей и одна для коммуникаций. Есть библиотека, которую мы называем нулевым уровнем для аппаратной абстракции, и есть четыре библиотеки, ориентированные на предметную область. Мы делаем это очень, очень открыто. Спецификации для всех из них уже открыты и доступны. Мы называем их версией 0.5. Мы намерены перейти на версию 1.0 к концу 2020 года, и у нас также есть реализации всего этого с открытым исходным кодом. Опять же, наша цель — дать людям возможность использовать то, что уже есть. Если поставщик оборудования хочет внедрить этот язык, он может взять то, что с открытым исходным кодом, и работать с ним.

В: Что касается алгоритмов и реализации, как это работает?

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

В: Как это работает на аппаратном уровне?

Если вы являетесь поставщиком оборудования, давайте возьмем матрицу ИИ, например, кто-то создает ASIC для ИИ — у этого поставщика оборудования есть два способа «подключиться» и использовать экосистему ИИ. Один из них — предоставить этот низкоуровневый аппаратный интерфейс, который мы называем нулевым уровнем, и если они предоставят свою версию нулевого уровня с использованием стандартного API, они смогут использовать открытый исходный код, если захотят, а затем все уровни программного обеспечения выше. может автоматически использовать это.

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

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

Итак, наша инициатива oneAPI состоит из двух частей. Один из них — отраслевая часть, а другой — продукты Intel. Отраслевая спецификация составляет 0,5, и примерно в середине года мы хотели бы довести ее до 1,0. Параллельно с этим Intel создает набор продуктов, и продукты, которые Intel создает, сегодня находятся в стадии бета-тестирования и реализуют спецификацию 0.5. К концу года мы хотели бы перейти к продукту версии 1.0.

Продукт Intel выходит за рамки девяти элементов oneAPI, потому что в дополнение к основным элементам программирования, которые мы предоставляем, мы также хотим предоставить то, что действительно нужно программистам, например, отладчики, анализаторы и инструменты совместимости, чтобы они могли переходить с существующих языков на языки данных. Параллельный язык C++.

В: Насколько сложно разработчику переходить? Является ли более широкая среда похожей на то, что они использовали в течение многих лет?

Да, очень похоже. Позвольте мне немного описать Data Parallel C++, потому что это большая часть того, чем мы занимаемся. DPC++ — это три вещи. Он основан на международном стандарте ISO на языке C++. Есть группа Khronos, которая определяет стандарт SYCL, а SYCL накладывается поверх C++. Мы берем SYCL, а затем добавляем расширения поверх SYCL. То, как мы строим Data Parallel C++, на самом деле является просто C++ с расширениями, что и представляет собой SYCL.

Любой компилятор C++ может его скомпилировать. Прелесть DPC++ в том, что его может скомпилировать любой компилятор, только опытный компилятор может воспользоваться преимуществами этого языка и сгенерировать ускорительный код. То, как мы ведем этот язык, мы делаем это очень, очень открыто, поэтому все наши обсуждения Data Parallel C++ происходят с комитетом SYCL. Реализации с открытым исходным кодом, все расширения уже опубликованы, и мы очень и очень тщательно работаем над тем, чтобы убедиться, что у нас есть хорошая скользкая дорожка для будущих стандартов SYCL. Глядя на 5-10 лет вперед, я также планирую переход к ISO C++.

В: Что касается компиляторов и перехода на DPC++, кривая обучения не должна быть большой проблемой?

Да, это зависит от того, откуда вы начинаете, конечно. Для программиста на C++ кривая обучения будет очень небольшой. Для программиста C вам придется преодолеть трудности изучения C++, но это все. Это очень знакомый C++. Для программиста, привыкшего к таким языкам, как OpenCL, это должно быть очень похоже.

Другая часть, которую я должен подчеркнуть, заключается в том, что мы делаем работу с открытым исходным кодом, используя инфраструктуру LLVM. Весь наш исходный код уже открыт, есть репозиторий Intel GitHub, куда вы можете зайти и посмотреть реализацию языка, даже скачать компилятор с открытым исходным кодом. Все инструменты Intel, наши предложения продуктов, которые являются бета-версиями, также доступны бесплатно для всех, кто хочет поиграть и загрузить их. У нас также есть облако для разработчиков, где людям не нужно ничего скачивать или устанавливать, они могут просто написать код и начать использовать все инструменты, о которых мы говорили.

В: C++ эффективен и относительно прост, но мы все знаем, что он стареет, разработка идет медленно, слишком много заинтересованных сторон, поэтому они все замедляют. Это, очевидно, не было бы в случае с DPC++. Вы хотели бы гораздо более быстрые итерации и обновления?

Я думаю, вы достигли очень, очень важного для нас момента, а именно быстрого развития, которое не замедляется стандартами. Итак, мы хотим вести открытое обсуждение стандарта, поэтому есть способ ознакомиться со стандартами, но мы также хотим сделать это быстро.

Языки работают лучше всего, когда они разрабатываются совместно пользователями и разработчиками по мере развития архитектур. Наша цель — очень быстрое итеративное проектирование кода, когда мы практикуемся, находим лучший способ делать вещи и делаем их стандартными. Так что, безусловно, быстрая итерация — это большая цель.

В: Один вопрос, который был поднят некоторыми из моих коллег (вы, наверное, понимаете, что они несколько обеспокоены открытостью всего, что исходит от большой корпорации): будет ли DPC++ всегда оставаться открытым для всех пользователей и поставщиков?

Абсолютно! Спецификация выполняется с лицензией Creative Commons. Любой может использовать спецификацию, взять ее и разветвить, если захочет, и развивать ее. Я хочу подчеркнуть, что не все элементы oneAPI имеют открытый исходный код, но мы находимся на пути к тому, чтобы сделать почти все элементы открытым исходным кодом. Все это любой может взять и использовать - доступно для реализации.

Codeplay, компания из Великобритании, объявила о внедрении Nvidia DPC++, и мы действительно призываем всех поставщиков оборудования и поставщиков программного обеспечения сделать свой порт. Мы находимся на уникальном этапе в отрасли, когда ускорители становятся общими для многих поставщиков. Когда это происходит в истории, когда есть только один провайдер, его язык доминирует. Индустрия программного обеспечения требует стандартного решения и нескольких поставщиков.

То, что мы пытаемся сделать здесь, это то, что мы сделали около двух с половиной десятилетий назад с OpenMP, где существовало несколько параллельных языков, но не было ни одного действительно доминирующего. Мы взяли все это и объединили в стандарт, который теперь, 25 лет спустя, является способом программирования для высокопроизводительных вычислений.

В: Правильно ли будет сказать, что DPC++ претерпит значительные изменения в ближайшие несколько лет? Как насчет тензоров, как насчет нового оборудования?

Да, абсолютно, вы правы. Мы должны развивать язык для поддержки нового оборудования, которое выходит. Это цель более быстрой итерации. Еще один момент, который я хочу подчеркнуть, заключается в том, что мы разрабатываем Data Parallel C++, чтобы вы также могли подключать расширения, зависящие от архитектуры, если хотите.

Итак, хотя это стандартный язык, который мы хотим использовать в нескольких архитектурах, мы также понимаем, что иногда аудитории, очень важной аудитории, требуется максимально возможная производительность. Они могут захотеть погрузиться в очень низкоуровневое программирование, которое не обязательно будет архитектурно-переносимым. Мы создаем расширения и механизмы, чтобы у вас могли быть расширения для тензоров и так далее, зависящие от архитектуры.

В: Какой контроль над кодом, сгенерированным для оборудования, может иметь разработчик? Насколько они могут контролировать управление памятью между системой и различными ускорителями?

Мы заимствуем концепцию буферов из SYCL, которые дают пользователю очень явное управление памятью, но в дополнение к этому мы также добавляем понятие унифицированной памяти . Наша цель — предоставить программисту необходимый уровень контроля не только для управления памятью, но и для быстрого создания кода. Некоторые из расширений, которые мы добавляем поверх SYCL, — это такие вещи, как подгруппы, сокращения, конвейеры и т. д. Это позволит вам генерировать гораздо лучший код для разных архитектур.

В: Интересным моментом является дистрибутив oneAPI для Python — Intel специально указала NumPy, SciPy, SciKit Learn. Меня интересует прирост производительности и преимущества производительности, которые можно разблокировать с помощью oneAPI. У вас есть какие-то показатели по этому поводу?

Это отличный вопрос. Мы поддерживаем эту экосистему. Зачем Python использовать ускоритель? Это нужно для того, чтобы получить производительность от своих математических библиотек, аналитических библиотек. Что мы делаем, так это «подключаем» NumPy, SciPy, SciKit Learn и т. д., чтобы мы могли добиться хорошей производительности, используя имеющиеся у нас библиотеки. Реализация по умолчанию NumPy, SciPy, SciKit Learn и т. д. по сравнению с той, которая правильно подключена к оптимизированным нативным пакетам, может дать очень, очень большой выигрыш. Мы видели прирост порядка 200x, 300x и т. д.

Наша цель с Python состоит в том, чтобы получить разумную долю, в пределах 2x, может быть, в пределах 80 процентов от производительности нативного кода. Состояние искусства сегодня таково, что вы часто в 10 раз или больше. Мы действительно хотим преодолеть этот разрыв, объединив все высокопроизводительные задачи так, чтобы вы были в пределах 2, а на самом деле намного выше.

Q: О каких типах оборудования мы говорим? Смогут ли разработчики раскрыть этот потенциал на обычной рабочей станции или потребуется что-то более мощное?

Нет, это было бы везде. Если подумать, откуда идет выигрыш, то вы поймете. Обычные библиотеки Python не используют никаких возможностей виртуализации на процессорах. Они не используют какие-либо многоядерные возможности процессоров. Они не оптимизированы, система памяти и все такое не оптимизировано. Итак, все сводится к матричному умножению, написанному наивным программистом и скомпилированному компилятором без какой-либо оптимизации, а затем сравниваем это с тем, что пишет эксперт в ассемблере. Вы можете увидеть многократный 100-кратный выигрыш, когда сравните эти два, и в мире Python, по сути, это то, что происходит.

Интерпретаторы Python и стандартные библиотеки настолько высокоуровневы, что код, который вы получаете, становится очень, очень наивным кодом. Когда вы правильно подключитесь к оптимизированным библиотекам, вы получите огромные преимущества. Ноутбук уже имеет от двух до шести или восьми ядер ЦП, они многопоточные и имеют довольно приличные возможности векторизации, может быть, 256, может быть, 512. Таким образом, в ноутбуках и рабочих станциях много производительности. Когда вы масштабируете это до графических процессоров, когда у вас есть доступная графика, вы можете представить, откуда берется выигрыш.

Если вы посмотрите на нашу интегрированную графику, она также становится очень мощной. Я уверен, что вы видели Ice Lake Gen 11, где встроенная графика значительно лучше, чем в предыдущем поколении. Вы можете видеть, откуда берутся преимущества, даже на ноутбуках.

В: Что насчет доступности DevCloud? Если я правильно помню, на данный момент это бесплатно для всех, но останется ли это так после того, как вы станете золотым в следующем году?

Это хороший вопрос. На данный момент, я буду честен, я не знаю ответа. На данный момент мы намерены сделать его бесплатным навсегда. Это для развития, для игры, и там много лошадиных сил, так что люди могут на самом деле делать свои пробежки.

В: Итак, вы не будете возражать, если мы попросим несколько тысяч разработчиков попробовать?

О, абсолютно нет. Мы бы очень хотели, чтобы это произошло!

Я могу обобщить то, что мы пытаемся сделать. Во-первых, мы очень, очень рады возможности oneAPI. Настало время, когда решение с несколькими поставщиками становится популярным, поскольку сейчас на рынке доступно несколько поставщиков. Если вы взглянете на нашу линейку процессоров, а не только на грядущие графические процессоры, все более и более мощные интегрированные графические процессоры, а также на нашу дорожную карту FPGA, то поймете, что настало захватывающее время для создания стандарта для всего этого. Наша цель — производительность, производительность и отраслевая инфраструктура, чтобы вы могли опираться на нее.

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