Комментарии 16
Где-то в районе " транзитивного замыкания" я отвалился. Замыкание - это когда переменные для функции захватываются в момент создания функции и не меняются. Возможно, подразумевается что-то ещё, но тогда это нужно хорошо и подробно расписать, а не отмахиваться как от очевидного.
Контекст же задан: работа с графами. Так что это про https://ru.m.wikipedia.org/wiki/%D0%A2%D1%80%D0%B0%D0%BD%D0%B7%D0%B8%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D0%B5_%D0%B7%D0%B0%D0%BC%D1%8B%D0%BA%D0%B0%D0%BD%D0%B8%D0%B5
Понятно, что и производители FPGA вносят в это заблуждение немалый вклад рекламируя чудо-компиляторы которые сделают за вас всю работу по переносу функционала из не-HDL языков. Но если таки немного подумать, то становится довольно очевидно, что даже при прочих равных размерах кристалла и технологических нормах GPU очевидным образом выигрывают на грубом MADD-е просто за счёт того, что в их случае нет потерь существенной части транзисторов на перепрограммируемые соединения и прочую гибкость. А если учесть ещё и типовую разницу в реальных частотах функционирования…
Поэтому победа FPGA принципиально возможна только в тех в тех задачах, где гибкость даёт существенный выигрыш, вроде всяких нестандартных типов данных и сложных не типовых функций. Естественно, для тех случаев, когда в видеокарте нет выделенных аппаратных блоков, которые эти не типовые функции в явном виде реализует.
Классический пример — кодирование видео. В былые года я делал на FPGA средней руки энтропийное кодирование, которое без усилий заруливало очень многоядерный серверный процессор. А в видеокартах аппаратной поддержки именно этого стандарта тогда ещё не было. В результате сервер с FPGA-ускорителем кодировал видео заметно быстрее только лишь за счёт выноса энтропийного кодирования из процессора. Но через некоторое количество лет производители GPU просто добавили нужные аппаратные блоки в свои чипы и то же самое ускорение стало возможным получить за счёт использования видеокарты стоимостью в несколько раз меньше чем ускоритель с FPGA, а в каких-то случаях и просто интегрированной в процессор.
Сегодня аналогичная история повторяется с ускорением нейронных сетей.
Так что если некоторая задача хорошо реализована для GPGPU, то попытки сделать что-то аналогичное на FPGA заведомо обречены на неуспех, как минимум по соотношению цена-производительность. Но важно понимать, что под «хорошо реализована» я имею в виду близкую к максимальной загрузку вычислительных элементов (MADD-ов в конечном счёте). А вот если мы говорим про алгоритм, в котором накладные расходы GPGPU превалируют над собственно вычислениями, то уже есть о чём говорить. К сожалению я не имел дела с линейной алгеброй и не могу навскидку оценить, к какой из двух категорий относится рассматриваемый в статье случай. Но в любом случае наивно ожидать эффективной автоматической трансляции в FPGA кода, который глубоко оптимизирован под GPGPU.
А для каких вообще современных задач "народного хозяйства" FPGA будет лучше CPU/GPU, при сравнимых бюджетах?
Для синхронной передачи raw-видео/аудио и обработки(цветокоррекция и т.п.) в real-time.
Цена негуманная, но CPU/GPU «отдыхают».
В чем сложность цветокоррекции на GPU и даже CPU?
Вообще, вы что-то странное рассказываете. 8-битная целая арифметика при процессинге RAW->RGB? Вы ж чудовищно точность будете терять на промежуточных округлениях.
На современных GPU имеет смысл использовать FP16 арифметику для этого, она прям практически в самый раз.
LUT на GPU реализуется через texture lookup, это очень быстро, есть кэш (с 2D locality), есть аппаратная билинейная интерполяция (поэтому текстуру можно делать довольно маленькую)
И это не только видео, но и большое количество телекома. Например инфраструктура всякого 3-4-5G да и вообще высокопроизводительное сетевое оборудование весьма активно потребляет наиболее производительные FPGA. Есть ещё всяческие специфические алгоритмы, вроде моделирования частиц или бизнес-аналитики и трейдинга, обычно покрытые толстым слоем NDA, так что по ним не очень много информации. В эту же серию попадает военка с радарными системами и real time управлением быстро перемещающимися объектами.
На другой стороне ценового диапазона находятся различные промышленные системы, где относительно небольшие FPGA уже есть в силу специфики проекта, робототехника например. И когда нужно сделать что-то вычислительно-интенсивное (в масштабах конкретной системы), то существенно проще использовать ресурсы имеющегося FPGA (или взять из семейства вариант чуть пожирнее в этом же корпусе), чем добавлять ещё что-то, DSP или GPU.
Ещё интересное применение, которое я видел — инференс нейросетей, т.е. использование уже обученной модели квантованной в целые числа. Но есть важная деталь — речь идёт не про универсальный ускоритель, который заведомо проиграет всяческим NPU и Jetson-ам, а про ускорение какой-то конкретной сети. Например распознавание образов каким-нить MobileNet или YOLO. В этом случае можно сделать глубокую оптимизацию под конкретные операции и параметры (включая квантование в разрядности меньше чем 8 бит) и получить преимущество по цене и/или потреблению. А если вдруг нужно будет внести изменения, то FPGA всегда можно перепрограммировать.
добавлено: а ещё скорость работы с внешней памятью оставляет желать лучшего, та же DDR3 память с теми же таймингами на ПК работает в полтора раза быстрее только потому что контроллеры памяти что от интел что от xilinx далеки от оптимальности. А ещё часто у дешёвых и среднего сегмента FPGA карт вообще стоит 1-2 чипа DDR памяти и ширина шины не 64 бита а 16~32 бита всего.
а потом выясняется, что производители GPU забили большой длинный болт на поддержку интерлейса и вообще не очень горят повышать стабильность своих закрытых библиотек.
И понимаешь, зачем нужен FPGA.
Какой кодек вы реализовывали на FPGA?
а потом выясняется, что производители GPU забили большой длинный болт на поддержку интерлейса и вообще не очень горят повышать стабильность своих закрытых библиотек
И понимаешь, зачем нужен FPGA.
Ну это да. Хотя в большинстве случаев потребители вполне удовлетворены качеством на полностью дефолтных настройках, возможно по причине отсутствия образца для сравнения. :)
Какой кодек вы реализовывали на FPGA?
Cначала 264-й, потом 265-й.
"Эльбрус" заточен на работу с разреженными матрицами. По крайней мере вычислительных устройств у него есть точно для таких задач. Правда, что с булевыми матрицами у него — не знаю. Пробуйте, дерзайте. В крайнем случае импортозаместитесь.
мультиплексоры для целых чисел и даже для чисел с плавающей запятой
Видимо, здесь имеются в виду умножители (мультипликаторы), ибо мультиплексоры -- это более простые элементы, агностичные к типу данных.
Во-вторых, проведенный эксперимент показал зрелость стека технологий, применяемого для разработки под FPGA с использованием OpenCL C: реализованные в ходе эксперимента современные алгоритмы сложения и умножение разреженных матриц весьма сложны и достаточно объемны на фоне, например, реализации сверточных фильтров.
Вот к зрелости как раз много вопросов. Проблема со всеми этими OpenCL и прочими программированиями-на-С-под-FPGA состоит в том, что мало чего можно сказать по поводу производительности и качества решения. Пару прагм в правильных местах способны улучшить скорости на порядки и чтобы знать, где их поставить, программисту нужно глубоко понимать железо да ещё и особенности работы OpenCL. До зрелости, имхо, ещё далеко.
Практическое применение сервера с FPGA