Технический форум по робототехнике.
WickedGoblin » 18 янв 2011, 12:13
Похоже что проблема не в железе, а что идет попытка создания новой парадигмы параллельного вычисления. А это извините совсем другой калибр.
Duhas » 18 янв 2011, 12:30
ну как сказать парадигму.. суть не в новом подходе в параллельным вычислениям вообще, а именно части прикладных задач...
в любом случае на выходе железа получено должно быть: материнка - может оказаться не нужной на край, модули - вполне себе самостоятельные мозги для робота...
WickedGoblin » 18 янв 2011, 12:57
Может я повторюсь но мне до сих пор не ясны просто многие и важные детали такие как:
1 Механизм распараллеливания задач (планировщик балансировщик нагрузки)
2 Механизм вызова задачи RPC или shared mem
3 Механизм обмена данными и кодом между модулями.
4 Механизм обмена данными с системой.
5 Язык программирования всей системы
Duhas » 18 янв 2011, 13:12
1 - изначально - рзделение нагрузки производится на этапе "компиляции" "программы".. динамическое же перераспределение шаг не первый...
2 - а оно мне вроде и не нада...
банк памяти - тот что у арбитра, разбивается на области.. выход их пределы в части задач невозможен.. если нужна динамика распределения - это работа арбитра, у его и должна висеть "карта" распределения памяти..
3 - зачем обмениваться кодами ?
в первоначальной идее данные ходят по схеме модуль - арбитр - модуль, либо модуль-модуль... все транзакции являются изначально явно заданными.. т.е. не должно возникать ситуаций, когда модуль 1 хочет отдать данные модулю 5, если это не предусматривается при "компиляции" "программы"
4 - с системой ? какой ? чего ? о чем речь не сильно понятно...
5 - язык - да любой.. у модуля есть конкретная задача, т.е. по сути модуль - функция... или их набор... от АСМа до ВАСИКа...
WickedGoblin » 18 янв 2011, 14:06
1 Из ответа я могу сказать что решение главной и наиболее сложной задачи в мире || программирования не есть сложная задача для вас. Это не подкол и не наезд. Как || задачи это очень и очень сложно. см. п.5
2 Это вопрос предназначался для того что бы понять где в системе будет узкое место.
3 Если система не предполагается перепрограммируемой то может посмотреть на чисто аппаратную реализацию?
4 Имелась ввиду внешная сисетам кто дает данные и получает результаты.
5 Это уход от ответа. внизу всегда будет Asm просто если на реализацию одного мьютекса надо будет тратить 3-4 дня то в топку такой язык. Языки программирования появляются не от балы (в основном)
Duhas » 18 янв 2011, 20:02
1 - имхо, не верно понято что я имею ввиду. в моем случае (моих задумках софта) нет задачи динамического распараллеливания.. если говорить еще точнее - параллельные процессы независимы, но используют общие данные..
посмотрев пункт пять - ответ тот же.. непонято.. НЕТ задачи написать линейный код (некоторую программу) и выполнить его N процами.. таким образом получаю бонус производительности в 1 задаче..
по сути то что я хочу можно написать и под ПК.. я делать этого не желаю.. в том числе по не адекватным причинам..
иначе вы бы сидели не в СРУВЧ секции )
2 - узкость узкого места вопрос неизвестный пока не будет готовой архитектуры софта.
3 - в каком плане ?
4 - я уже писал, что на ряду с вычислителями на шине могут висеть "рецепторы/эффекторы" для полноты СРУВЧности - повторюсь что в мыслях ИИшные замашки..
5 - это ни разу не уход от ответа. если мне понадобится модуль способный получить некоторые данные некоторым определенным образом - там может стоять и ПЛИС.. и АРМ с писанным на АСМе софтом..
WickedGoblin » 18 янв 2011, 21:10
Ясности все меньше и меньше.
Может задачу озвучите?
dccharacter » 19 янв 2011, 03:52
Да пароли он хочет лома, что тут непонятного. В конце 90-х была такая программа от SETI, по-русски называлась "корова". Скачивала диапазон перебора паролей и, пока комп в идле, перебирала. Сейчас это делают параллельно на видеокартах или на кластерах из SONY PS2. Хватит херней заниматься.
Duhas » 19 янв 2011, 06:57
dc.. вы в своем репертуаре... щас убегаю... отпишу позже..
WickedGoblin » 19 янв 2011, 10:15
SETI это классический RPC call: тонкий и мало объемный канал для передачи параметров + большая вычислительная мощность за ним
Duhas » 19 янв 2011, 13:31
ну ладно, поищем корни.. а корни этой идеи растут из размышлений об ИИ...
я не считаю возможным, скорее даже нужным более чем возможным, пытаться создать "ИИ" настраивая и разращивая некую нейросеть...
я склонен к модели:
1 - есть набор сенсоров, их препроцессоров обработки..
2 - есть набор эффекторов, для них также пригодятся небольшие специфические мозги..
3 - есть БД, ассоциативного типа
4 - есть "обработчики" - процессы поиска ассоциаций, как в реалтайме, т.е. прямо при поступлении данных, так и работающих в фоне.. постоянно перевзвешивающих ассоциативные веса, перестраивающие ассоциативные цепочки...
каждый процесс по сути независим, и может быть выполнен даже железно в отдельном законченном модуле..
с ростом числа написанных обработчиков растет и число железных модулей.. в чем собственно может крыться минус железной реализации такого принципа..
ПС что-то я чую щас поток оффтопа )
WickedGoblin » 19 янв 2011, 19:44
Вот теперь ясно.
Сразу скажу что метод RPC тут изначально не преминем.
Тут надо действительно что то типа shared-mem.
И надо подумать
Duhas » 20 янв 2011, 07:31
видишь, смысл в железе как рас в том, что мона будет спокойно писать модули.. и даже если конфигурация материнки будет не подходящей, то переделать только ее...
WickedGoblin » 20 янв 2011, 11:42
Мне видится все не так. Мама и модули будут очень жестко связаны
Есть одна концептуальная идея но ее надо обязательно картинкой пояснить. А на нее нет времени, чуть позже нарисую
Duhas » 20 янв 2011, 20:26
жду )