roboforum.ru

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

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

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

Может я повторюсь но мне до сих пор не ясны просто многие и важные детали такие как:
1 Механизм распараллеливания задач (планировщик балансировщик нагрузки)
2 Механизм вызова задачи RPC или shared mem
3 Механизм обмена данными и кодом между модулями.
4 Механизм обмена данными с системой.
5 Язык программирования всей системы

1 - изначально - рзделение нагрузки производится на этапе "компиляции" "программы".. динамическое же перераспределение шаг не первый...

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

3 - зачем обмениваться кодами ?
в первоначальной идее данные ходят по схеме модуль - арбитр - модуль, либо модуль-модуль... все транзакции являются изначально явно заданными.. т.е. не должно возникать ситуаций, когда модуль 1 хочет отдать данные модулю 5, если это не предусматривается при "компиляции" "программы"

4 - с системой ? какой ? чего ? о чем речь не сильно понятно...

5 - язык - да любой.. у модуля есть конкретная задача, т.е. по сути модуль - функция... или их набор... от АСМа до ВАСИКа...

1 Из ответа я могу сказать что решение главной и наиболее сложной задачи в мире || программирования не есть сложная задача для вас. Это не подкол и не наезд. Как || задачи это очень и очень сложно. см. п.5
2 Это вопрос предназначался для того что бы понять где в системе будет узкое место.
3 Если система не предполагается перепрограммируемой то может посмотреть на чисто аппаратную реализацию?
4 Имелась ввиду внешная сисетам кто дает данные и получает результаты.
5 Это уход от ответа. внизу всегда будет Asm просто если на реализацию одного мьютекса надо будет тратить 3-4 дня то в топку такой язык. Языки программирования появляются не от балы (в основном)

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

посмотрев пункт пять - ответ тот же.. непонято.. НЕТ задачи написать линейный код (некоторую программу) и выполнить его N процами.. таким образом получаю бонус производительности в 1 задаче..

по сути то что я хочу можно написать и под ПК.. я делать этого не желаю.. в том числе по не адекватным причинам..

иначе вы бы сидели не в СРУВЧ секции )

2 - узкость узкого места вопрос неизвестный пока не будет готовой архитектуры софта.

3 - в каком плане ?

4 - я уже писал, что на ряду с вычислителями на шине могут висеть "рецепторы/эффекторы" для полноты СРУВЧности - повторюсь что в мыслях ИИшные замашки..

5 - это ни разу не уход от ответа. если мне понадобится модуль способный получить некоторые данные некоторым определенным образом - там может стоять и ПЛИС.. и АРМ с писанным на АСМе софтом..

Ясности все меньше и меньше.
Может задачу озвучите?

Да пароли он хочет лома, что тут непонятного. В конце 90-х была такая программа от SETI, по-русски называлась "корова". Скачивала диапазон перебора паролей и, пока комп в идле, перебирала. Сейчас это делают параллельно на видеокартах или на кластерах из SONY PS2. Хватит херней заниматься.

dc.. вы в своем репертуаре... щас убегаю... отпишу позже..

SETI это классический RPC call: тонкий и мало объемный канал для передачи параметров + большая вычислительная мощность за ним

ну ладно, поищем корни.. а корни этой идеи растут из размышлений об ИИ...

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

я склонен к модели:
1 - есть набор сенсоров, их препроцессоров обработки..
2 - есть набор эффекторов, для них также пригодятся небольшие специфические мозги..
3 - есть БД, ассоциативного типа
4 - есть "обработчики" - процессы поиска ассоциаций, как в реалтайме, т.е. прямо при поступлении данных, так и работающих в фоне.. постоянно перевзвешивающих ассоциативные веса, перестраивающие ассоциативные цепочки...

каждый процесс по сути независим, и может быть выполнен даже железно в отдельном законченном модуле..

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

ПС что-то я чую щас поток оффтопа )

Вот теперь ясно.
Сразу скажу что метод RPC тут изначально не преминем.
Тут надо действительно что то типа shared-mem.

И надо подумать

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

Мне видится все не так. Мама и модули будут очень жестко связаны
Есть одна концептуальная идея но ее надо обязательно картинкой пояснить. А на нее нет времени, чуть позже нарисую

жду )