Что-то маловато нейронов. При таком подходе оно будет ну очень схематично "учиться".

Поставил : R 0.1 ; - это так называемый в умных статейках lerning rate. Ждем несколько минут, пока нейросеть перетрахивает ((с) Лукашенко) коэффициенты, в результате видимые глазом ошибки в ответах нейросети остаются преимущественно (можно даже сказать исключительно) на границе тьмы и света, т.е. там, где гигантский перепад значений с минимума на максимум и обратно. Учитывая примитивное устройство (за основу взята нейросеть, которая чуть ли не в 99% случаев описывается в статьях из цикла "нейросети для домохозяек", которая обучается вычислять xor) и небольшое количество нейронов в скрытом слое, можно считать, что вполне нормальный результат. Да и не требовалось изобретать нейросеть, которая идеально бы клонировала изображения. Тут скорее один из многих промежуточных тестов, а в конечном итоге я для себя хотел бы понять, как должен (или мог бы) выглядеть Форт для работы с нейросетями. И какие фишки там были бы удобны.

ссылка на изображение

Для Форта я придерживаюсь простого правила. Он нужен там, где в процессе разработки часто производятся изменения. Где редко - пользуемся возможностями "хост-платформы". Например, вычисление выхода нейрона не изменяется - можно его и зафиксировать внутри низкоуровневого слова.

Безусловно, так и сделаю, перепишу на "низкоуровневом" javascript. Тут узкое место - перемножение матриц, вот его-то и буду оптимизировать в первую очередь. Но сейчас экспериментирую с разными функциями активации, на этом этапе главное, чтобы хоть в каком-то виде работало, а оптимизацииями займусь после того, как все обкатаю и лишнее повыбрасываю

Переписал пока сложение произведений (используется при перемножении матриц) на ассемблере... Пардон, на javascript. В несколько раз по ощущениям быстрее стало. И пока гиперболический тангенс в качестве функции активации.
Для обучения используется слово n! , а для чтения состояния n@ Вот прям просится Форт в нейронный процессор, только входы и выходы нужны аналоговые, а не цифровые Кстати, а бывают ли в природе ПЛИС с аналоговыми входами/выходами?

Надо бы теперь какую-нибудь простенькую сверточную сеть родить на пробу.

Бывают ПАИС (аналоговые, да, с переключаемыми конденсаторами). В ПЛИС бывают АЦП. Но вообще подключить АЦП+ЦАП - не такая большая проблема.

Зацените, какую штуку придумал. Ну как придумал... Уже даже сделал в простом (2 ядра) варианте, но пока толком не успел проверить, хотя уже видно, что зашевелилось.
У меня самодельный микроконтроллер в ПЛИС организован следующим образом:
- шина данных закольцована, каждое устройство имеет вход и выход, на выход передает либо транзитом со входа (если на шине адреса выставлен адрес какого-то другого устройства), либо запрашиваемые данные (если установлен адрес из адресного пространства текущего устройства):
- также из процессора на все устройства заведен адрес, сигнал разрешения записи и сигнал выбора текущего устройства, кроме того заводится тактовая частота и сигнал сброса;
- все общение с устройствами производится через один или несколько регистров из адресного пространства этих устройств;
Процессор работает, пробовал варианты с параллельным выполнением нескольких команд, но производительность вырастает не более, чем в 2 раза даже в ситуации, когда одновременно выполняется несколько литералов. Это при том, что код более чем наполовину из этих самых литералов и состоит. Все-таки не очень хорошо форт-код на уровне команд распараллеливается, по крайней мере в моей системе команд: все команды хотят поменять глубину стека и его содержимое.

Возникла мысль зайти с другой стороны и добавить в систему другие ядра просто навесив их на шину данных. И работать с ними как с любыми другими периферийными устройствами:
Периферийные процессоры (ppu) после рестарта спят, но могут быть инициализированы адресом любой подпрограммы, после чего начнут выполнять код начиная с этого адреса. Периферийные процессоры имеют доступ к общей прошивке, на борту есть стеки данных и возвратов нужной глубины и необходимое количество RAM (она будет видна и центральному процессору), в планах добавить к ним функционал всех или некоторых периферийных устройств (UART, GPIO, TIMER, I2C, ...), оставив на шине данных только периферийные процессоры (ppu).
В результате периферийный процессор может выполнять код параллельно с центральным процессором. Чем-то похоже на обработчик прерывания с той лишь разницей, что теперь центральному процессору не требуется прерывать работу основной программы, сохранять текущее состояние, прыгать на код обработчика и выполнять его, а затем восстанавливать состояние. И адреса обработчиков настраиваются и перенастраиваются прямо в процессе работы прошивки, буквально в пару действий. Так что центральному процессору остается навесить максимум работы на своих рабов и подгонять их кнутом Понятно, что выигрыш в производительности будет только на тех задачах, которые хорошо распараллеливаются, но сама возможность поручить часть работы кому-то другому греет душу Т.е. здесь получается параллелизм на уровне процессов, а не отдельных команд. Ну и наконец никто не запрещает комбинировать варианты, если позволить центральному и периферийным процессорам выполнять несколько команд за такт. Платой за это будет рост потребления блоков BRAM. Но если остаются свободные, то почему бы не задействовать? Ну а пока жду понедельника

Ну вот, поехала правильная методология применения ПЛИС Много ядер это действительно не только классическая "симметричная мультипроцессорность", тут можно исхитряться и распределять ядра по тем задачам, которые возникли в конкретном проекте. В ПЛИС же нет вот этого ограничения "надо, чтобы пригодилось широкому кругу потребителей".


Скоро 10 лет, как я такое показывал на семинаре у Баранова Правильные мысли приходят в умные головы независимо

Да я пока как та обезьяна из анекдота: и к умным хочется, и к красивым, все никак не определюсь... Чувствую, что впереди меня ожидает куча велосипедов, которые предстоит переизобрести заново.

Сегодня времени было мало, но кое-что успел проверить. Например, добавил в бродилку процесс в отдельном ядре, который в цикле делает инкремент цвета стены. Получил разноцветную стену вместо монохромной. И пару-тройку тестов с тремя периферийными ядрами сделал. Назначил каждому отдельное задание (инкркмент, декремент и побитовая инверсия), а потом останавливал процессы и запускал заново, менял адреса "обработчиков", переназначал задачу на другое ядро и т.д и т.п.. Работает, но тест слишком простой, надо что-то более сложное. Радует, что максимальная частота такого монстра просела незначительно (с 72Mhz до 69MHz).
Задания ядрам примерно так раздаются:В теории на моей плис можно до 20 ядер сделать (по количеству умножителей), если речь о 16-18-битных ядрах, для 32-битных не более 6 получится (по 3 умножителя на брата), ну или пару 64-битных. Блоков BRAM тоже 20 штук, если прошивка небольшая (до 4K команд), то тогда "каждой твари по паре" - 10 блоков BRAM на 20 ядер, а еще 10 остается на RAM, маловато, но должно хватить, тем более, что не всем периферийным ядрам нужно большое количество памяти, где-то можно и несколькими регистрами обойтись. Буду дальше экспериментировать

upd. Проверил и 8 ядер (1 основное+7 периферийных), все прекрасно. Правда максимально допустимая частота просела до 55МГц, но не смертельно. И количество RAM в периферийных ядрах пришлось уменьшить до 1 блока BRAM (1K слов, в принципе, за глаза для простых задач), чтобы блоков BRAM на всех потребителей хватило. Сейчас задействовано 15 блоков BRAM: 4 на прошивку (8 ядер поделить на 2), 4 на RAM в основном ядре и по 1 для каждого из 7 периферийных. В резерве осталось 5 блоков, их можно или на более жирную прошивку потратить (сразу уйдет еще 4 блока, если прошивка превысит нынешний лимит 4K команд, бродилка, для сравнения, сейчас весит меньше 2K команд) или пару ядер добавить (1 блок на прошивку плюс 2 блока на RAM), место в ПЛИС еще осталось. Хотя я даже 8 штук ядер не знаю, куда девать
Еще забавно, что в таком многоядерном процессоре можно замешивать ядра разной разрядности (допустим, 16/32-битные), но они без проблем будут работать от одной и той же прошивки. Такая система команд получилась

А еще подумалось, что основное ядро в многоядерной системе лучше сразу делать двухъядерным, RAM у ядер будет общей, раз уж BRAM такие трюки позволяет. А шину данных, которая сейчас представляет из себя длинное кольцо, распилить на два кольца поменьше. Если придумаю как, то и периферийные компоненты тоже сразу двухъядерными сделаю, но пока нет идей.

еще upd. Ну и, наконец, сделал основной процессор двухъядерным, максимальная частота так и осталась 72MHz. В бродилке при отрисовке сцены часть работы поручаю второму ядру, если оно в текущий момент времени свободно. В итоге из 80 столбцов второе ядро отрисовывает примерно 40. Но производительность, понятное дело, вырастает не в 2 раза, т.к. помимо отрисовки есть еще другие вычисления, а их (пока) всегда делает основное ядро. Все проверял на втором варианте системы команд, где команда 2/ заменена на rshift.
Цифры примерно такие:
одно ядро - 80 fps @ 20MHz = 4.00 fps/MHz
два ядра - 119 fps @ 20MHz = 5.95 fps/MHz
два ядра + параллельное выполнение нескольких команд в каждом из ядер - 204 fps @ 20MHz = 10.20 fps/MHz
Для сравнения:
одно ядро (1-я версия системы команд) - 74 fps @ 20MHz = 3.70 fps/MHz
одно ядро (3-я версия системы команд) - 98 fps @ 20MHz = 4.90 fps/MHz
ARM - 72 fps @ 64MHz = 1.13 fps/MHz
Thumb - 67 fps @ 48MHz = 1.40 fps/MHz
самодельный 8-битный процессор из видоса, который KPG присылал - 19 fps @ 4 MHz = 4.75 fps/MHz, но т.к. здесь отрисовывается не 25 строк, а 60, то правильнее будет пересчитать 4.75*60/25 = 11.40 fps/MHz
Надо будет сделать двухъядерный вариант процессора с 3-й версией системы команд и посмотреть, ну а пока есть только со 2-й, т.к. она все-таки проще.