Пример программирования FPGA-ускорителя

[kovserg]

Круто, но дорого. Осталось придумать пирамиду что-то типа «биткоинов», чтоб клиент массово пошел осваивать вычислительные мощности.

[Chugumoto]

ну… между видяшками и асиками биткойны майнили как раз на ПЛИС (например Spartan6 LX150)
но тем не менее и сейчас востребованы. правда уже совсем другие и для других алгоритмов
bitcointalk.org/index.php?topic=3459858.0
вот например тема одна…

[JerleShannara]

Если покупать карту+софт, то да, готовьте 7-10к$. Но: «Круто, я на кластере из 200 Xeon-ов соседский файфай ломану, но купить такое кол-во серваков будет дорого». Зачем покупать, если сейчас можно бесплатно протестировать, а далее можно будет просто арендовать сервер. Вы не покупаете 100500 серверов, когда надо что-то решить, а арендуете мощности в каком-либо облаке на необходимое время. Так и тут.

[TitovVN1974]

Было бы интересно, каких результатов в Linpack можно реально добиться на FPGA.

[datacompboy]

А спрос есть на услугу? Что-то с трудом представляю.

[ToSHiC]

Intel и Xilinx сейчас активно пытаются перенести работу с нейросетками с GPU на FPGA, обещая низкую latency операций за счёт отсутствия батчей.

[Chugumoto]

дак для нейросетей же уже отдельные ускорители типа такого выпускают
sophon.ai/product/introduce/sc1.html

[ToSHiC]

А тут уже нужно выбирать, хотите ли вы больше быстрее новые фичи клепать, или больше производительности. Например, у SC1 2 терафлопса производительности FP32, у теслы V100 — 14, а можно ещё и на FP16, тогда ещё быстрее будет. Если FPGA будете использовать и совсем свой код писать — да хоть FP7 можете использовать, получая соответствующую экономию ресурсов железа.

[Chugumoto]

SC1 — по сути ASIC
в цепочке GPU-FPGA-ASIC чем левее, тем универсальнее и проще в разработке, чем правее, тем быстрее и энергоэффективнее
отсюда каждый выбирает для себя сам :)
а FPGA да — золотая середина :)

[Chugumoto]

вроде где-то проскакивало, что, в текущих реализациях, ядра, писанные на OpenCL, значительно медленнее писанных на HDL

[OYTIS]

Это как бы вполне ожидаемо. Всегда приходится искать баланс между временем/стоимостью разработки и производительностью.

[JerleShannara]

Guru HDL vS OpenCL Coders
Task: GZip compression
HDL таки вышел шустрее, процентов на 5-10. Правда времени на HDL ушло гораздо больше, чем на CL

[Chugumoto]

если мне не изменяет память, то я наталкивался на что-то для майнинга. и там в итоге разница была по скорости в несколько раз. просто запихнутое ядро на OpenCL, которое на видяшках крутили, и на HDL.

[JerleShannara]

Код, оптимизированный под Intel Pentium 3 SSE на Via Cyrix C3/Amd Duron тоже работал медленно =). Под каждую структуру вычислителя код надо по своему оптимизировать.

[DmitriyDev]

Есть предположение, что это больше связано с тем что zip плохо паралелится. Или все алгоритмы, ограничения считывания/записи были обговорены заранее и всё упиралось только в скорость FPGA?

[JerleShannara]

Упиралось в то, что результат перед заливкой в ПЛИС всёравно был на HDL. И тут вступали 5-10% разницы в коде, который генерировал компилятор из OpenCL в VHDL/Verilog и том, который написали гуру HDL.

[algotrader2013]

Есть немногочисленные статьи о том, как хорошо делать рассчет опционов методом монте-карло на FPGA с превосходством в сотни раз относительно CPU (вот одна из них, десятилетней давности). Но было бы очень интересно услышать людей в теме: достаточно ли гибкости у подхода, чтобы иметь практическую ценность в монте-карло, и так ли велико преимущество перед более традиционной и понятной программистам CUDA.

PS: лет 7 назад FPGA прочно ассоциировались с HFT, а само слово было страшилкой для тех, кто торговал чувствительные к скорости стратегии при помощи стандартного железа. ЕМНИП, при помощи топовых FPGA с эзернетом парсили пакеты с маркетдатой, и укладывали в память в готовом виде, минуя CPU, а самые упоротые прямо на плате и стратегию обсчитывали, и сразу заявки формировали.

[JerleShannara]

А кто вы думаете первым пылесосом смели все альтеровские ускорители, когда там ещё первые условно-рабочие чипы стояли?
Cuda и OpenCL — это очередной holywar будет, с одной стороны «это привычно, мы там так уже делаем», с другой «это универсально, хоть на тостере запускай, хоть на процессоре, хоть на видяхе, хоть на плисе — учите язык».

[algotrader2013]

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

[JerleShannara]

Главное отличие между GPU и FPGA тут в том, что CreateProgrammWithSource не поддерживается вообще (т.к. компиляция простого a=b+c занимает часы), надо WithBinary. Если код удовлетворяет стандартам OpenCl 1.2 (точно не помню, умеет ли сейчас оно полностью 2.0 или нет), то скомпилируется и запустится, если ресурсов хватит. Тут какраз видеокарта менее гибкая, сколько ядер на чипе есть, столько максимум и получится заюзать, в FPGA всё круче, толи 1024, толи 4096 ядер максимум. Не следует забывать, что у FPGA есть и выходящие за рамки OpenCL плюшки — host_pipe к примеру, раньше ещё были host_channels, но они как-то весело пролетели, анонсировали их в 17.0, а в 18.0 уже убрали (и рабочих вариантов я не видел вообще, даже от саппорта не добились примера, который бы работал), плюс на FPGA можно присобачить любой нужный интерфейс и работать с ним через channel-ы, ещё можно что-то на HDL(главное, чтобы это было с avalon stream интерфейсом) нарисовать и подключить как библиотеку.
Другой вопрос, что то, что шустро работает на GPU на FPGA может быть отборным тормозом, оптимизация это отдельная глава. Из таких примеров — это случайный доступ к памяти, на GPU торчит GDDR5 обычно, а тут DDR4 (хотя можно QDR4 сделать, оно тогда по скорости будет рвать видеокарту, но вот объем будет мизерный, а ценник конский), зато объем памяти можно сделать и 32 и 64 Гб. Ну и локальной памяти можно гораздо больше сделать на FPGA, чем на GPU (ещё можно пожертвовать логикой и юзать регистровую память, тут GPU сольёт вчистую, т.к. у него такой либо нет, либо вообще мизер)
И вишенкой на торте будет упоминание OPRA FAST Parser, раз уж мы лезем в HFT. Получаем пакет по сети, дербаним его на FPGA и готово, а уж всякие Low Latency MAC на FPGA уже давно есть. Главная плюшка — если раньше весь алгоритм писался на HDL, отлаживался черт знает сколько времени (24-48 часов на прогон моделирования это было нормально), то сейчас для моделирования и отладки компилироваться под железку нет необходимости, есть эмулятор, для которого всё это компилится за минуты.

[sergbe]

В Америке выигрыши в HFT формируются не только за счет сервера, но и гораздо больше дает построение собственной радиолинии между биржами. Т.к. скорость сигнала радио — 300К, а в стекловолокне только 200К.
nag.ru/articles/article/31845/chastnyie-mikrovolnovyie-radioseti-millisekunda-za-100-mln.html

[SADKO]

Тут, сочетание многих факторов, и железные сервера, и линии передачи данный и общая архитектура…
… грубо говоря, пока один транслирует ленту и стакан по быстрой линии, другой передаёт расчётные параметры по медленной, значительно быстрее

[SADKO]

Не, всё по старому, всё по прежнему, у меня на Москве FPGA арбитражил между секциями и прочие без рисковые крошки собирал. Потом стало не выгодно, и я свалил, но было не плохо, хотя и мелко.
Было измерение чего-то, разбор пакетов, вычисление всякого и даже формирование и отправка ордеров, в то время как компутер решал не критичные ко времени стратегические задачки. Поведение FPGA менялось не за счёт перепрошивки, а за счёт интерпритации простых команд на изменения «управляющих констант» и изначально гибкой архитектуре…
… и на самом деле ничего особенно сложного в универсальной архитектуре нет, ведь это не какое-то охренительное пространство вариантов, все трейдеры делают примерно одно и тоже, вариаций не так уж и много, а вот делают по разному, да.

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