Сейчас работаю с матрицей 765х201. Хочется сделать архитектуру универсальной, с масштабируемостью и неким запасом по размерам (оттого и 1000х500). Делаю обучение он-лайн, а не сборками. Я в курсе что batch training лучше, но хочется получить обучаемую систему, которой можно просто показывать один образец за другим. Матрица весов полная, т.е. нулей там ничтожно мало. Вектор же напротив, обычно имеет от 30% до 50% единиц только.
Почему я это делаю на FPGA: хочется получить универсальный нейроаккселератор, пригодный для встраеваемых систем, с низким энергопотреблением и работой в реальном времени. Кстати, моя реализация RBM далеко не первая на плисах. Обычно систему обучают на компьютере и в плисину уже загоняют тренированную сеть. Меня же интересует обучение.

count_enable
Всё верно.
Идея в том, что если у Вас активными (используемыми в вычислениях) будут хотя бы 25% отсчётов, то проще сделать суммирование "влоб" зануляя неиспользуемые.
Для процесса сложения возможно распараллеливание: на один DSP48 отсчёты с нескольких BRAM (например, с трёх одновременно). Тогда можно использовать объединение выходов BRAM через конвейер мультиплексоров.
Это хорошо повлияет на максимальную тактовую частоту, и машина состояний получится достаточно простой.

Спасибо, уже начал потихоньку строчить код. Практичный вопрос по ISE 14.1: есть ли смысл использовать примитив RAMB18 и писать обёртку к нему или же писать свою RAM размером с BRAM, а синтезатор сам догадается, что с ней сделать? По документации BRAM и DSP очень быстрые, 550 МГц. Хотелось бы хотя бы половину из этой частоты получить.

count_enable

теперь конечно проще советовать, но все еще есть вопросы:



однозначно все как полный вектор и полная матрица, 30% - погоды не сделают. (Выше ASN уже верно подметил!)


похвально, но все еще не понятно сколько времени Вам дано на обучение и сколько итераций обычно Ваша матрица обучается?

Если предположить, что матрица у Вас 500х1000, обучается за 1к итераций, то используя хорошо оптимизированные blas2 на Mali ядрах у A20 одна итерация (то есть одно суммирование по матрице) будет вычисляться примерно за 50 мкс, а все обучение будет длиться около 50мс если Вам для этого надобно 1к итераций и не более 1 секунды, если Вам надобно 20к итераций.

Удобство А20 - дешевизна, наличие почти в каждом планшетнике, наличие кучи удобных тулсов, купил, установил софт, и все работает. При желании можно проставить на нем под линуксом октав, чтобы сразу все переносить с матлаба, только немного помучиться оптимальные библиотеки к октаву прикрутить, иначе будет раз так в 10 медленнее.

Теперь о плиске. Конечно на ней можно, нужно, вроде бы правильно, но!

Какая скорость доступа на один брам? В Альтере с одного М9К вы получите примерно 0.8ГБайт/с, и, чтобы сравнится в теоретическом пике с Мали ядром, придется задействовать 60 таких блоков, а чтобы серьезно обогнать - пользовать под 500 таких блоков.

Сразу возникает вопросы:
1. а столько блоков в Вашем виртексе есть?
2. а если смотреть на задачи 500, Вы упираетесь уже в предел параллелизма, то есть алгоритм будет супер-супер плохо параллелиться. То есть Вам надобно будет больше памяти, а она в блочном виде в плисках ну совсем не масштабируема. И задачи Вам нужны побольше, для лучшего параллелизма...

ИМХО (совсем не настаиваю, но настойка бы получилась бы крепкая) пользуйте планшетник с А20 или Exinos 5 или A80 или любым другим процессором, в котором есть мали ядро 4, а лучше 6-ой версии, будет и потребление 2-3Ватта, и работать все из коробки, и все интернеты, блутусы, мультитачи на халяву... А вот если ну очень хочется плиску, я бы брал бы минимум 5-ый и очень жирный стратикс, и поднимал бы размерность задачи до 5к хотя бы.

Приветствую!

Теоретически TC мог бы впихнуть в его чип (Virtex5LX110 ) одну копию матрицы 1000x500 - 250 блоков BRAM18 (а можно и 223 обойтись если не забывать что память 18 бит!)
Опят же теоретически один BRAM18 может выдать на гора ~550*4.5 >2.4 GByte/s (в конфигурации 2 порта по 18 бит)

Но практически для начала я бы ориентировался на частоту 330-400 MНz.
При таком раскладе для одного цикла суммирования надо будет ~530 тактов ~1.6 us

Но дешевым и мало потребляющем конечно такое решение не будет.

Успехов! Rob.

Лиха беда начало... Существующие реализации RBM имеют ускорение от х25 до х100 при сравнении с процессорами класса Intel Core. ( http://web.stanford.edu/~pmcmahon/fpl09_dbn.pdf "A Fully Pipelined FPGA Architecture of a Factored Restricted
Boltzmann Machine Artificial Neural Network" http://delivery.acm.org/10.1145/2540000/25...759a6160147408e ). Вполне возможно, что перейду на Zynq, с обучением на процессоре если будет выгоднее. Пока что Zynq не впечатляет меня своей плис-частью. Еще лежит под столом Virtex 7, но существующие корки, используемые нами созданы под V5/ PLB. В общем, работы непочатый край. Всем большое спасибо за дельные советы, я еще не одну тему здесь создам в процессе творения.

Сразу практический вопрос: необходим ли RAMB18 примитив, или можно как-то без него убедить синтезатор в использовании BRAM? Пока что мне синтезирует однопортовую память в LUT.

UPD: Сам себе отвечаю: включить принудительное использование BRAM и DSP в опциях синтеза, ну и полностью синхронный дизайн памяти.

Есть в описаниях XST шаблоны, которые приводятся к Block RAM и шаблоны которые приводятся синтезатором к Distrubuted RAM. Их синтезатор находит в коде, и генерирует именно те блоки, которые в них описаны.
Плюс такого подхода - быстрая симуляция без лишних библиотек.

Еще раз акцентирую Ваше внимание: RBM фактически требует максимально быстрого доступа к памяти, и у Вас есть два пути: использовать специальные процессоры а ля ГПУ, или блочную память плиски. Если сравнить современное отношение скорости доступа к внутренней памяти графических карт и обычных процессоров, то это отношение как раз и соответствует 100 раз, то есть в графической карте есть 6 гигабайт памяти, к которой Вы сможете в 100 раз быстрее достучаться, чем к обычной оперативной на обычном процессоре. Чтобы обогнать плиской 250 ГБайт в секунду стационарных, и 50ГБайт в секунду на портаберльных графических карт, Вам надобно очень сильно постараться и иметь достаточно жирные виртексы

В то же время, я одобряю Вашу идею использования плисок, так как это более эффективное расходование транзисторов, чем на графических картах для Вашей задачи, но, поймите, для РБМа Вы столько подводных камней на плиске получите, что, я бы, на Вашем месте, вначале на Опен-Це-еЛе это все обкатал бы, а только потом бы на плиску двинулся бы, благо какой-нибудь олинуксино за 65 евро берется, в котором все есть и пользуй-проверяй сколько хочешь.

Я на все это с той колокольни смотрю, что я много статистики запрограммировал и распараллелил, в том числе РБМы правда у меня больше подход со стороны линейной алгебры - вначале выжать все из алгоритма, а потом только железо и параллельную модель выбирать. Могу по телефону детали рассказать, на путь истинный направить, а если есть желание, можете подъехать, лично расскажу, я пока в отпуске вблизи Монтекарловки, Вам вроде бы не далеко

Я бы ещё добавил:
1. Идея использования двух портов одновременно весьма здравая.
2. Если важна задержки доступа к памяти (latency) то FPGA должны серьезно обогнать и CPU и GPU.

Но ведь я-то не в отпуске . Лучше Вы к нам, здесь значительно дешевле, а выпивка и море отличные.

Почему всё же FPGA? Ну, во-первых это предмет моего PhD и он уже пересмотру не подлежит. Во-вторых, так же как безалкогольное пиво это первый шаг к резиновой женщине, так и FPGA это дорожка ведущая к ASICu. Существует несколько очень обещающих аналоговых и гибридных нейрочипов, я же думаю о чисто цифровом.

Очень рад слышать, что кто-то еще здесь работал с RBM. Если не секрет, то какая область? Распознавание образов, системы управления? А строили свёрточные сети и автоэнкодеры? Они сейчас реально рулят, просто магия какая-то.

так тем более - за знаниями в статистической области в командировку в Монтекарловку - к светиле в области статистики (у меня Нейчер есть) я Вам бы командировку-бы и подписал бы


ну так бы и сказали бы - "шашечки", правда, в Вашем случае, довольно интересные.


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

А по-существу, позвольте дать Вам несколько советов:

1. в статистических алгоритмах обычно очень много подгоночных параметров и нет четко устоявшихся алгоритмов, имейте рядом с хорошей вычислительной системой что-то типа софт-процессора. Очень желательно, чтобы у этого софтпроцессора было на борту и памяти и ресурсов достаточно, чтобы на лету что-то досчитать. Правда в диссере - это особенно не учитывается, а потребуется, когда Вы реально этим начнете заниматься

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

3. Не ленитесь хотя бы на уровне статей сравнивать то, что получается на плиске у Вас или Ваших коллег/конкурентов с результатами на графических картах - часто помогает быстро упасть (или уронить шефа) с пьедестала.

Успехов!

Если есть вопросы по вычислительной математике вокруг да около Вашей работы - пишите в личку, постараюсь найти время, надеюсь, смогу дельного чего посоветовать.

Да, конечно, будет или Микроблейз или Паверписишка работать с памятью, интерфейсами и для мелких вычислений.