Как стать автором
Обновить

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

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

Эх, не переводятся на Руси программисты, которые ожидают что FPGA чудесным образом зарулят GPGPU без каких-либо усилий на тех задачах, для которых эти GPGPU собственно и заточены (массово-параллельное умножение-сложение).
Понятно, что и производители 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?

когда я делал видеопроцессор raw-->rgb (то что делает AdobeLightroom) оказалось что 90% умножений 8 битные и часто на константу, а ещё было много сложений и вычитаний и поэтому ресурсы FPGA использовались очень оптимально и тактовую удалось поднять до 300~400 Mhz. И это было эквивалентно работе десятков тысяч простейших вычислительных ядер низкой битности, которые заняты расчётами около 90% рабочего времени. Алгоритмы были такие как дебаеризация, расчёт векторных полей градиентов и краёв, удаление шума, усиление краёв и контрастности, улучшение текста и прочее. Почти всё требует 4-8 битной арифметики, часто без сложных операций типа умножений, делений и тригонометрии, но много LookUpTable — а скорость RAM внутри FPGA много террабайт в сек.

Вообще, вы что-то странное рассказываете. 8-битная целая арифметика при процессинге RAW->RGB? Вы ж чудовищно точность будете терять на промежуточных округлениях.

На современных GPU имеет смысл использовать FP16 арифметику для этого, она прям практически в самый раз.
LUT на GPU реализуется через texture lookup, это очень быстро, есть кэш (с 2D locality), есть аппаратная билинейная интерполяция (поэтому текстуру можно делать довольно маленькую)

Как уже упомянул уважаемый fougasse — это массивная обработка потоков данных «на лету».
И это не только видео, но и большое количество телекома. Например инфраструктура всякого 3-4-5G да и вообще высокопроизводительное сетевое оборудование весьма активно потребляет наиболее производительные FPGA. Есть ещё всяческие специфические алгоритмы, вроде моделирования частиц или бизнес-аналитики и трейдинга, обычно покрытые толстым слоем NDA, так что по ним не очень много информации. В эту же серию попадает военка с радарными системами и real time управлением быстро перемещающимися объектами.
На другой стороне ценового диапазона находятся различные промышленные системы, где относительно небольшие FPGA уже есть в силу специфики проекта, робототехника например. И когда нужно сделать что-то вычислительно-интенсивное (в масштабах конкретной системы), то существенно проще использовать ресурсы имеющегося FPGA (или взять из семейства вариант чуть пожирнее в этом же корпусе), чем добавлять ещё что-то, DSP или GPU.
Ещё интересное применение, которое я видел — инференс нейросетей, т.е. использование уже обученной модели квантованной в целые числа. Но есть важная деталь — речь идёт не про универсальный ускоритель, который заведомо проиграет всяческим NPU и Jetson-ам, а про ускорение какой-то конкретной сети. Например распознавание образов каким-нить MobileNet или YOLO. В этом случае можно сделать глубокую оптимизацию под конкретные операции и параметры (включая квантование в разрядности меньше чем 8 бит) и получить преимущество по цене и/или потреблению. А если вдруг нужно будет внести изменения, то FPGA всегда можно перепрограммировать.
надо ещё не забывать что если пишешь не на HDL типа верилога и поэтому не оптимизируешь на скорость, а используешь высокоуровневый синтез, то частота получается 100-200 MHz, а количество DSP блоков не сильно больше чем у GPU. таким образом не получится сделать в 10 раз больше умножений с накоплениями за такт а частота порой в 10 раз ниже чем у GPU.
добавлено: а ещё скорость работы с внешней памятью оставляет желать лучшего, та же DDR3 память с теми же таймингами на ПК работает в полтора раза быстрее только потому что контроллеры памяти что от интел что от xilinx далеки от оптимальности. А ещё часто у дешёвых и среднего сегмента FPGA карт вообще стоит 1-2 чипа DDR памяти и ширина шины не 64 бита а 16~32 бита всего.
> через некоторое количество лет производители GPU просто добавили нужные аппаратные блоки в свои чипы

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

И понимаешь, зачем нужен FPGA.

Какой кодек вы реализовывали на FPGA?

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

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

Какой кодек вы реализовывали на FPGA?

Cначала 264-й, потом 265-й.

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

мультиплексоры для целых чисел и даже для чисел с плавающей запятой

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

Во-вторых, проведенный эксперимент показал зрелость стека технологий, применяемого для разработки под FPGA с использованием OpenCL C: реализованные в ходе эксперимента современные алгоритмы сложения и умножение разреженных матриц весьма сложны и достаточно объемны на фоне, например, реализации сверточных фильтров.

Вот к зрелости как раз много вопросов. Проблема со всеми этими OpenCL и прочими программированиями-на-С-под-FPGA состоит в том, что мало чего можно сказать по поводу производительности и качества решения. Пару прагм в правильных местах способны улучшить скорости на порядки и чтобы знать, где их поставить, программисту нужно глубоко понимать железо да ещё и особенности работы OpenCL. До зрелости, имхо, ещё далеко.

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