Дмитpий Hecтepук

Блог о программировании — C#, F#, C++, архитектура, и многое другое

Почему разработка под FPGA бесит

3 комментария

Сегодня я ходил на конференцию Joker (это Java конфа, так что не совсем моя тематика) и, в разговоре с (бывшими) коллегами из JetBrains, я упомянул что в разработке железа (всякие HDLи) настоящая катастрофа с тулами и производительностью разработчика. В этом посте я хочу немного раскрыть тему, рассказать про то, что вообще можно сделать с железом и почему же разработка под него так мучительна.

Status Quo

Мы живем в мире, где доминируют микропроцессоры, работающие на основе инструкций. Самым популярным набором инструкций является конечно x86, но есть и другие варианты. Эта технология, если говорить конкретно про Intel’евские i7 и Xeon’ы, обкатана, хорошо работает, и самое главное она везде, что гарантирует некую совместимость, на тот случай если вы поставляете софтварный продукт.

Поверх x86 есть еще ряд технологий, которые выдают аппаратную оболочку через софтварный API: это например OpenGL и DirectX для игр и CUDA для обобщенных вичислений на графических картах компании NVIDIA. Это из того что популярно и хоть где-то используется — например, Adobe в своих видео продуктах использует Mercury Engine, которая как раз амортизирует CUDA (умеет ли она использовать OpenCL — не знаю, не уверен).

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

Аппаратные ускорители

x86 решает подавляющее большинство задач. К сожалению, есть задачи которые отдельно взятый процессор, даже самый дорогой Xeon решить по тем или иным причинам не может. Огромный поток данных, которые льются с биржи, не всегда реально обработать на CPU, а если и реально, то с большими задержками. Или аппаратное шифрование — то, что дает вам возможность использовать BitLocker или его аналоги: это отдельный модуль в компьютере.

Есть куча доменно-специфичных задач, которые можно ускорить железом. Также, некоторые структуры данных и алгоритмы, которые вы используете в C++, можно сделать быстрее в железе, т.к. в отличии от Intel процессоров, где уровень параллелизма заранее ограничен кол-вом ядер (ну и плюс “аппаратными потоками”, это я про hyper-threading итп), уровень параллелизма на FPGA массивен. Нужно только задачу найти.

Вообще, в контексте аппаратных ускорителей, я бы упомянул вот эти категории

  • GPGPU — вычисления на графических картах. Хороши только для численных вычислений (математика) и только для data-parallel вещей (там где нет брэнчинга).

  • Intel Xeon Phi — копроцессоры от Intel. Отдельная PCIe карта, на которой 60+ ядер (4 аппаратных потока на ядро), свой Linux, и которую можно использовать либо как компьютер-в-компьютере, либо в тандеме с хостом, отгружая часть данных для рассчетов.

  • FPGA — ПЛИСы или “вентильные матрицы”, технология реконфигурируемого комьютинга, которая позволяет по сути создать свой собственный процессор вместо того чтобы использовать готовый. Ест очень мало энергии. Поддерживает нереальную параллелизацию, но программируется на языках описания железа (Hardware Description Languages, HDLs).

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

Языки описания железа

Железо можно конечно описывать цифровыми схемами, но если учесть что на умножение двух 16-битных чисел может потребоваться 6000 логических ворот, это как-то некомильфо. Поэтому придумали другие языки (самый популярные — VHDL и Verilog), на которых описывается структура и поведение конфигурируемых цифровых систем вроде FPGA.

Проблема №1 этой затеи заключается в том, что вся работа идет на низком уровне. Это значит что нет:

  • Механизмов динамического управления памятью, и как следствие…

  • Динамических структур данных, таких как динамический массив/список/отображение

  • Стандартных алгоритмов (сортировка, поиск)

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

Модели описания поведения интегральной схемы

Для начала, следует понимать, что у нас есть два режима взаимодействия с железом, а именно:

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

  • Параллельный — тут все самое интересное, т.к. можно описать поведение системы, в которой несколько вещей происходят действительно одновременно.

Соответственно мы, как разработчики железа, можем описывать и оптимизировать параллельно-последовательную структуру FPGA в одном приложении и, заметьте, что такие термины как “многопоточность” не имеют никакого смысла вообще, т.к. нет никаких “виртуальных потоков” в контексте одного аппаратного.

Одна вещь, которую мы не обсудили — это хранение в памяти. Точно так же как у CPU есть регистры, кэши разного уровня и RAM, на FPGA есть возможность хранить данные — прямо в логических ячейках или в RAM, если он вам предоставлен. То есть чисто теоретически, можно конечно пытаться строить динамические структуры, но что там по перформансу — я не знаю.

В чем проблема?

Субъективно говоря, разработывать на FPGA то же самое что на CPU раз в 100 сложнее. Вреня-деньги, и никто их не будет тратить на мучения.

Отчасти в катастрофическом, просто идиотском затыке виноваты чисто тулы, то есть EDA которые используются для разработки. Тулы воспринимают FPGA как электрическую схему с набором сигналов вместо того чтобы воспринимать ее как некоторый domain transform обычных программ в зону параллельного.

Вообще, как нынче модно на рынке, сюда могут забежать люди и сказать что де “меняй менталитет”, у нас все так, терпи или вон с рынка. Но мне кажется что нужно как раз больше думать про high-level synthesis: может кому-то и нравятся VHDL/Verilog, но все-таки нужно начинать с того чтобы переходить полностью на высокоуровневый синтез.

Я в какой-то момент пробовал MATLAB, но что-то мне подсказываeт, что будущее на FPGA за OpenCL. Но это решает только проблему языка: еще есть проблема отладки, в которой пока все почему-то считают что мы следим за уровнем сигналов, а не за агрегированным состоянием ООП-образных структур.

И да, объекты, товарищи! Я не настаиваю на присутствии v-табличке, но если мне нужно распарсить биржевой протокол, то лучше все это будет на каком-то вменяемом языке.

Про низкоуровневость

Чтобы реализовать устройство для ethernet на PCIe нужно по обе стороны реализовывать протоколы. Это ппц как сложно. Вот вы, вы хотите писать свой собственный драйвер? Я — нет. Я даже не знаю как все это устроено.

А ведь производители могли бы все разжевать и в рот полодить. Почему CUDA может, а FPGA производители — нет? Потому что им всем на нас плевать, и они ничего не понимают.

Ничего…

Со всем этим нужно бороться. Менять парадигму, выводить тулы строго в опенсорс (это хороший пример где проприетарщина == гниль). Всех несогласных закопать.

Я пишу feed handler. Детали будут позже. ▪

Реклама

Written by Dmitri

17 октября 2016 в 21:08

Опубликовано в FPGA

комментария 3

Subscribe to comments with RSS.

  1. +1 Уже несколько раз присматривался к FPGA, т.к. железки очень интересныей. Но каждый раз, перечитывая Getting started, приходил к выводу «да ну нафиг, жесть какая-то» =)

    ShakirovRuslan

    19 октября 2016 at 12:13

    • Getting Started — это еще нормально, побаловаться, помигать диодом. А вот когда хочется сделать полезное решение — тут начинаются мучения. Но я бы не рекомендовал подход «да ну нафиг, это жесть» — весь кайф в том чтобы во-первых разобраться а во-вторых, понять как сделать лучше.

      Dmitri

      19 октября 2016 at 15:15

  2. 1. Я слышал, что преобразование OpenCL в код для FPGA очень «громоздкое». Если объём «конфигураций» для чипа FPGA фиксирован и время прохождения сигнала по чипу не зависит от количества инструкций программы, то проблем не должно быть? Пусть преобразование OpenCL->FPGA займёт хоть максимум конфигураций чипа, лишь бы разработка была проще.
    2. Может ли программа написанная для OpenCL для одной GPU, смаштабироваться для оборудования с 8 GPU? Такое впечатление, что все существующие языки — это все ещё не то, что нужно. Вроде Microsoft со своим AMP мыслит в категориях решения (языка), которое охватывало бы максимум возможностей hardware, но пока ничего универсального типа C++ для CPU не видно.

    Sasha Prokopenko

    8 декабря 2016 at 14:40


Оставить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: