RISC-V — многообещающая архитектура для создания нового поколения процессоров. И она может стать платформой для решения задач AI. Инженер Владислав Виноградов работает в команде, которая создаёт и оптимизирует связанное с искусственным интеллектом программное обеспечение в компании YADRO. В статье он делится опытом разработки тензорного компилятора для процессора на базе RISC-V.
Описанный подход сочетает в себе автоматическую кодогенерацию и использование ручных оптимизаций. Это позволяет существенно экономить ресурсы инженерной команды для работы над наиболее вычислительно трудоёмкими операциями, которые реализуются средствами внешних библиотек.
- что такое тензорный компилятор
- чем хороши технологии OpenVINO и MLIR
- как применение гибридного подхода высвобождает ресурсы команды оптимизаторов
- какие слои абстракций лежат между моделью в OpenVINO и машинным кодом
Что такое тензорный компилятор
Тензорным компилятором называют отдельный проект либо компонент в большем фреймворке, который занимается оптимизацией и переводом модели глубокого обучения в исполняемый формат под конкретное устройство. Этим устройством может быть CPU, GPU или специализированные AI-акселераторы.
Тензорный компилятор выполняет ту же работу, что и компиляторы традиционных языков программирования, — комбинирует высокоуровневые оптимизации (планирование исполнения, оптимизации ресурсов) и низкоуровневые (оптимизации уровня машинных инструкций).
Идея исследования
Эффективное исполнение (инференс) моделей глубокого обучения требует предварительной оптимизации под конкретную архитектуру. В рамках исследований команды мы решили разработать прототип оптимизирующего тензорного компилятора для RISC-V CPU.
Технологический стек для тензорного компилятора
Основой эксперимента по созданию компилятора стали две технологии — OpenVINO и MLIR.
Почему OpenVINO
OpenVINO — это библиотека с открытым исходным кодом для оптимизации инференса сетей глубокого обучения под различные устройства: CPU, iGPU, GPU, FPGA. Библиотека разрабатывается компанией Intel и в первую очередь ориентирована на оптимизацию именно под их устройства. При этом у нее расширяемая архитектура, которая позволяет писать собственные плагины для сторонних устройств.
OpenVINO предоставляет общее внутреннее представление моделей глубокого обучения и отдельный инструментарий по конвертации из разных фреймворков и форматов в это общее представление. Библиотека значительно упрощает разработку тензорного компилятора, поскольку команда может сфокусироваться на обработке внутреннего представления. В OpenVINO также есть набор утилит по валидации аккуратности и бенчмаркингу, которые экономят ресурсы на начальных этапах разработки.
Почему MLIR
- гибкое и расширяемое внутреннее представление (IR),
- общие алгоритмы и подходы по работе с IR,
- оптимизирующие пассы,
- инструменты анализа и диагностики IR,
- инструменты для тестирования и отладки.
Также в MLIR большое внимание уделено оптимизации работы самого компилятора. В инфраструктуре есть:
- поддержка многопоточной компиляции,
- оптимизированные структуры данных для IR,
- средства профилирования пайплайна компиляции.
OpenVINO поддерживает запуск и оптимизацию моделей под CPU с архитектурой x86 и ARM. Его тензорный компилятор по сути просто планирует операции, которые написаны и оптимизированы вручную. То есть для каждой операции написана своя реализация, оптимизированная под расширения x86/ARM (либо как часть самого плагина OpenVINO, либо как примитив из библиотеки DNNL). Прототипирование такого прямого подхода на RISC-V требует значительных усилий по написанию большой библиотеки оптимизированных операций.
Использование MLIR позволяет применить гибридный подход.
Его идея в том, что разработчики занимаются реализацией для RISC-V трудоемких операций, а код для остальных генерируется автоматически средствами инфраструктуры. Такой подход позволяет команде сфокусироваться на оптимизации наиболее тяжелых bottleneck-операций, таких как свертка или матричные умножения.
Более того, написанное на MLIR решение можно в теории адаптировать и запустить на разном «железе» и архитектурах:
- CPU: x86, ARM, RISC-V,
- GPU,
- NPU.
Есть и еще одна причина выбора MLIR. Процесс компиляции из высокоуровневого представления в низкоуровневый машинный код достаточно сложен из-за cемантического разрыва между ними. Пытаясь сразу прыгнуть из высокоуровневого представления в низкоуровневое, например, в LLVM IR, можно потерять много семантической информации и возможность проводить некоторые высокоуровневые оптимизации. MLIR предлагает постепенную трансформацию и перевод из абстракций высокого уровня в низкоуровневые через разные уровни абстракции. Отсюда Multi-Level в названии технологии.
MLIR предоставляет механизм, называемый диалектами. Они позволяют описывать разные уровни абстракции и домены применения операций, будь то тензорная алгебра, control flow, взаимодействие с потоками или акселератором и так далее. В итоге процесс компиляции представляет собой постепенную трансформацию внутреннего представления из высокоуровневых диалектов в более низкоуровневые.
Трансформация модели глубокого обучения в машинный код
В MLIR между моделью в OpenVINO и машинным кодом лежат 6 уровней абстракций:
- Исходное представление модели (input DSL).
- Внешние библиотеки оптимизированных операций (external libraries).
- Тензорная алгебра (tensor algebra).
- Циклы и работа с памятью (loops on buffers).
- Вызовы функций (function calls).
- Низкоуровневое внутреннее представление (low-level IR).
У каждого уровня абстракции свой диалект. Дальше мы рассмотрим суть каждого из них.
Исходное представление модели
Сначала мы переводим внешнюю модель в формате OpenVINO в диалект OV, который написали сами. Он представляет модель один к одному в терминах MLIR и дает отдельные операции, работающие с тензорами.
На этом этапе осуществляется приведение внутреннего представления к «каноническому» виду для упрощения последующих этапов. Этот шаг включает в себя:
- Обработку константных путей вычисления.
- Тривиальные оптимизации, например, reshape (reshape (x, shape1), shape2) -> reshape (x, shape2).
- Объединение нескольких операций в одну: convolution+bias.
- Декомпозицию некоторых сложных операций на более простые.
Внешняя библиотека оптимизированных операций
Следующим шагом нужно трансфоровать представление в диалекте OpenVINO в диалект DNNL, который представляет специфику этой внешней библиотеки. Реализацию диалекта мы тоже написали сами.
Конвертация из OV-диалекта в DNNL делается выборочно для тех операций, что представлены в библиотеке или могут быть выражены через ее API. Например, мы трансформировали связку из конволюции и последующего добавления биаса в операцию, представляющую собой семантику подобной операции из внешней библиотеки:
На этом уровне также можно производить оптимизации планирования вызова DNNL/oneDNN. Например:
- выбрать наиболее подходящую для каждой операции схему расположения данных в памяти — так называемые лейауты (layouts),
- согласовать лейауты между разными операциями,
- добавить дополнительные операции по изменению лейаута.
Тензорная алгебра
Далее мы переходим в ветку автоматической кодогенерации. Здесь используется диалект linalg, который доступен в самом MLIR. На этом уровне мы сводим разные операции к более общему представлению тензорной алгебры. Эту конвертацию делаем после того, как оптимизировали планировщик операций на предыдущем уровне. В результате получаем возможность автоматически генерировать код для добавляемых операций, например, смены лейаута.
Циклы и работа с памятью
Четвертый шаг понижения семантики — это диалект affine и переход от операций алгебры над тензорами к обычным циклам по работе с памятью.
На этом этапе мы можем решать задачи выделения памяти — например, для того, чтобы выделять ее заранее, а не при каждом вызове инференса. Представление похоже по семантике на операции с памятью в языке С: прочитать из памяти, сохранить в нее данные, произвести операции над элементами и так далее.
Вызов функций внешних библиотек
Следующий шаг — это трансформация из DNNL-диалекта непосредственно в вызовы функций из внешних библиотек. Для этого используется диалект func.
На этом этапе мы также можем разделить для некоторых сложных операций этап инициализации примитива из внешней библиотеки и этап непосредственно вызова этого примитива средствами MLIR.
Низкоуровневое внутреннее представление
На последнем шаге компиляции к единому низкоуровневому представлению сводятся как представление вызова функций внешней библиотеки, так и автоматически сгенерированный код. Таким представлением выступает LLVM-диалект, который является зеркалом LLVM IR.
Генерация машинного кода
Финальный этап работы тензорного компилятора — это генерация машинного кода средствами LLVM и его бэкэнда для RISC-V.
Итого компиляция представляет собой пошаговую оптимизацию и перевод внутреннего представления во все более низкоуровневые диалекты.
При разработке экспериментального тензорного компилятора мы использовали гибридный подход. Вручную мы реализуем свертки, матричные умножения и data-dependent операции (например, DetectionOutput из SSD-моделей детектирования). Все остальное делает кодогенерация MLIR. Получились следующие результаты:
- 17 операций — ручная реализация библиотеки ядер,
- 38 операций — автоматическая кодогенерация.
Запуск на «железе» и выводы
В качестве тестового стенда для разработанного плагина OpenVINO с интегрированным MLIR-компилятором мы использовали плату MangoPI с одноядерным RISC-V процессором CPU RV64GCV @ 408 МГц и пиковой производительностью 1.63 GFlops @ 408 МГц. Данная плата поддерживает векторное расширение RISC-V версии 0.7.1 (RVV 0.7.1), но при этом кодогенерация в бэкенде RISC-V LLVM работает только с версией 1.0.
По этим причинам в кодогенерации слоев мы использовали скалярный, а не векторизованный код, хотя слои, написанные во внешней библиотеке, использовали возможности RVV версии
Мы сравнили вызовы всех операций через внешнюю библиотеку и гибридный режим, когда вызовы во внешнюю библиотеку отправляются только для самых тяжелых слоев, а все остальные генерируются автоматически. Для представленных моделей команда оптимизаторов также реализовала все необходимые слои во внешней библиотеке. Вот результаты запуска на реальном «железе»:
В итоге производительность гибридного режима сопоставима с производительностью использования внешней библиотеки.
В отдельных случаях результаты гибридного режима даже лучше. Это объясняется тем, что в библиотеке оптимизированных операций код написан для общего случая (разных размеров тензоров, разных раскладок по памяти
Автоматическая генерация забрала на себя немалое число слоев, но время их работы существенно не влияет на общее время работы нейронной сети. Зато освобождаются ресурсы команды, которая может сфокусироваться на оптимизации более тяжеловесных слоев.
Вывод, который мы сделали при реализации прототипа тензорного компилятора, — гибридный подход имеет право на жизнь.
Мы также отметили несколько минусов в подобном подходе. Первый — это достаточно высокий порог входа в MLIR для людей, которые не сталкивались со спецификой написания компиляторов и LLVM-фреймворком. И второй минус — отсутствие поддержки RVV 0.7.1 в LLVM.
Дальнейшие шаги
В дальнейших исследованиях мы хотим поработать над тремя направлениями:
- Развитие оптимизации для автоматической кодогенерации.
- Бо́льшая кооперация с библиотекой ядер.
- Увеличение покрытия поддерживаемых моделей.
Во-первых, мы хотим заняться дальнейшим улучшением оптимизации для автоматической кодогенерации. Рассмотреть более сложные паттерны оптимизации, векторизации для слоев, и увеличить покрытие слоев, для которых производится кодогенерация.
Второе направление, которое мы планируем изучить, — это бо́льшая кооперация компилятора с внешней библиотекой ядер. Например, когда некоторые слои конволюции на стадии кодогенерации разбиваются на более мелкие примитивы или микроядра, небольшие матричные умножения. Их реализация будет во внешней библиотеке ядер. Тогда кодогенерация будет заниматься планированием микроядер и их оптимизацией по типу фьюзинга с другими операциями, например, активациями. Это избавит команду оптимизаторов от необходимости реализовывать обвязки вокруг микроядер и поддержку фьюзинга.
И третье — мы хотим увеличивать покрытие поддерживаемых моделей. Например, добавить поддержку моделей с динамическими размерами тензоров и моделей для обработки естественного языка (RNN, transformers).