PARALLEL.RU

Дискуссионный клуб по параллельным вычислениям
Текущее время: 19 авг 19 4:27

Часовой пояс: UTC + 4 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 14 ] 
Автор Сообщение
 Заголовок сообщения: многоагентные симуляторы
СообщениеДобавлено: 14 июл 06 1:31 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
Достаточно известная задача (если коротко): Есть некое виртуальное общество, живущее на "доске" определенных размеров. Жители двигаются, встречаются, обмениваются какой-то информацией. За всеми событиями стоят некие вероятности. Встречи планируются неким глобальным планировщиком. Задача хорошо решается в последовательном программировании. Однако, я пока не могу придумать эффективного способа ее распараллеливания. Одна из идей это очевидная аналогия с газовой динамикой, т.е. можно завязаться на 2D доску где агенты живут. Разбить ее на сектора (самое простое - прямоугольники), сектора раздать процессорам и обрабатывать граничные случаи - т.е. когда агент переходит из одного сектора (процессора) в другой. В этот момент происходит обмен информацией. Все это можно в терминах средних оптимизивать. Примерно также работает сотовая связь: абонента перекидывают на соответствующие соты в зависимости от местоположения оного. Проблем собственно несколько: получается, что теоретически каждый процессор должен иметь запас памяти размером во все сообщество, т.к. есть вероятность того что все население соберется в каком-то секторе. Тогда другие процессы будут просто стоять. Потом проблема синхронизации. Если какая нибудь информация о такого рода системах или может кто может посоветовать как лучше это все организовать.

Спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: многоагентные симуляторы
СообщениеДобавлено: 14 июл 06 9:43 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
Достаточно известная задача (если коротко): Есть некое виртуальное общество, живущее на "доске" определенных размеров. Жители двигаются, встречаются, обмениваются какой-то информацией. За всеми событиями стоят некие вероятности. Встречи планируются неким глобальным планировщиком. Задача хорошо решается в последовательном программировании. Однако, я пока не могу придумать эффективного способа ее распараллеливания...

У меня ситуация обратная. Я не знаю как все это хорошо решается последовательно? Параллельно проблем нет. По крайней мере на формальном уровне. Одно из решений: каждый агент - конечный автомат, множество агентов - автоматная сеть. Это общее решение. Его можно конкретизировать клеточной моделью, нейронной сетью и т.д. и т.п. Но если связи произвольны, передвижения непредсказуемы, связи беспорядочны и т.д. и т.п., то, конечно, выбирать нужно универсальную автоматную сеть.
Опять же нужно уточнять количество агентов, интенсивность/число связей между ними, нужную скорость их работы и т.д. и т.п. От этого зависит выбор реализации "агентной модели" - на одной машине, на множестве и т.п. Для примера: мне приходилось реализовывать на одной машине "общение" в реальном времени от 10000 и более "агентов". Но это уже детали... ;)

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 14 июл 06 11:52 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
Интересно. А можно подробнее? Может ссылки какие дадите где почитать можно?

Спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 14 июл 06 12:42 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
Интересно. А можно подробнее? Может ссылки какие дадите где почитать можно?

Спасибо

См. статьи в разделе КА-технология (http://www.softcraft.ru/auto.shtml#ka).
Ближе всего, как мне кажется, пример из статьи "Открой свое созвездие или тест на воображение" (http://www.softcraft.ru/auto/ka/bugs/index.shtml).
В ней каждый "жук" это и есть агент.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 14 июл 06 13:34 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
А как это можно реализовать с использованием C/MPI для систем с распределенной памятью? Даже упростим задачу: есть агенты, они двигаются в ограниченном пространстве хаотически, встречаются друг с другом хаотически и обмениваются информацией тоже хаотически.

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

Другой вариант - разбить сам грид на прямоугольники. Допустим доска 100 на 100 разбивается на 100 квадратов 10 на 10, по одному квадрату на процессор. Как только какой-то агент на каком-то из нодов собирается из-за блуждание перейти в квадрат соответствующий другому ноду, эти ноды обмениваются этой инфой. Этот вариант лучше, но как я и говорил каждый нод должен иметь запас памяти вмещающий все население, т.к. есть вероятность что все агенты соберуться в каком-то одном сегменте на какой-то промежуток времени. В этом подходе нужно дикое кол-во памяти и есть вероятность перегрузов нодов.

Какие будут предложения? Спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 14 июл 06 15:52 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
А как это можно реализовать с использованием C/MPI для систем с распределенной памятью?

Множестьво автоматов - это модель и каких-то противопоказаний по реализации у нее нет. Сейчас сделано на одном процессоре, но можно осделать и на множестве. Тот, кто ею будет пользоваться, может не знать, на чем реализовано ядро. Так что можно и на С/MPI. Другое дело, что из этого получится и насколько будет эфективно. Вы же сами пишете о проблемах, который могут затем последовать. И эти проблемы должно "прозрачно" решать ядро. Т.е. при необходимости перемещать автоматы с узла на узел, согласовывать данные и т.д. и т.п... Еще раз. Сделать можно, но нужно все это рассматривать с разных сторон. Стоит ли, как говорится, овчинка выделки ;)

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

Ясно. Можн ои так и этак...
Raif писал(а):
Как можно параллелизовать? Один вариант - выдать каждому процессу допустим поровну агентов и их обрабатывать. Неэффективно ибо обмен информацией между нодами требуется постоянно и время независимых вычислений в лучшем случае сравнимо с latency.

Другой вариант - разбить сам грид на прямоугольники. Допустим доска 100 на 100 разбивается на 100 квадратов 10 на 10, по одному квадрату на процессор. Как только какой-то агент на каком-то из нодов собирается из-за блуждание перейти в квадрат соответствующий другому ноду, эти ноды обмениваются этой инфой. Этот вариант лучше, но как я и говорил каждый нод должен иметь запас памяти вмещающий все население, т.к. есть вероятность что все агенты соберуться в каком-то одном сегменте на какой-то промежуток времени. В этом подходе нужно дикое кол-во памяти и есть вероятность перегрузов нодов.

Какие будут предложения? Спасибо

Сразу замечание. Это уже внесение изменений в алгоритм работы "общества" агентов. Их "сшивка" и т.п... Это тоже задача, которую нужно решить.
А предложение пока одно - уточнить проблему. Если говорить о параллельных процессах (нодах, участков грида и т.п.), то надо бы знать их число. Ради 100х100 не стоит и огород городить. Условно до 1000х1000 можно обойтись одним "нодом" ;) Дальше могут быть варианты. В том числе, разбивая множество процессов и на "квадраты". Но, кстати, стараясь реализовать их все на том же одном "ноде". Основная задержка будет связана больше с числом процессов, а не с их "вычислительной мощью" (затратами на вычисление, выполняемые агентом).

Короче. Мне сложно что-то конкретно предложить, не зная специфики задачи. Из моего опыта я бы так сказал: 1000-5000 агентов - не проблема, 10000 - будут некоторые задержки, 100000 - я бы подумал что лучше - 10 "нодов" или раза в 2-4 больший по быстродействию компьютер (последний вариант проще), 1000000 - возможно пришлось бы "бить" на квадраты, чтобы уменьшить число процессов, к примеру, на порядок (т.е. вернуться к предыдущему варианту) и т.д. и т.п.
Ну и, конечно, нужно будет оценить объемы памяти...
Т.е. прежде чем перейти на кластер с MPI я бы испробовал множество вариантов, чтобы этого не произошло ;) Уж больно много будет проблем, если агенты активно общаются, перемещаются и т.д. и т.п.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 15 июл 06 11:11 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
ОК. Понятно, что распараллеливать имеет смысл для действительно больших популяций. Давайте допустим что для сформулированной мной выше упрощенной задачи это имеет смысл, т.е. количество агентов и размер грида такие какие Вы считаете достаточными для того чтобы имело смысл распараллеливание. Как бы Вы это решали, если бы у Вас был кластер с распределенной памятью (остальные характеристики на Ваше усмотрение) и библитека MPI наиболее подходящих на Ваш взгляд для подобной задачи и подобного железа версии и производителя?

Я на сегодняшний день лишь додумался до деления грида. Достаточно легко оценить "нагрузки" на каждый сектор в терминах средних. Весь процесс - суть Марковская цепь и можно легко посчитать такие величины как среднее время нахождения агента в заданной (для простоты, прямоугольной) области или, например, среднее кол-во встреч (т.е. обменов информацией) и пр. И на основании этих данных оптимизировать. Хочется услышать алтернативные подходы или советы.

Спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 17 июл 06 15:23 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
ОК. Понятно, что распараллеливать имеет смысл для действительно больших популяций. Давайте допустим что для сформулированной мной выше упрощенной задачи это имеет смысл, т.е. количество агентов и размер грида такие какие Вы считаете достаточными для того чтобы имело смысл распараллеливание. Как бы Вы это решали, если бы у Вас был кластер с распределенной памятью (остальные характеристики на Ваше усмотрение) и библитека MPI наиболее подходящих на Ваш взгляд для подобной задачи и подобного железа версии и производителя?

Непростая ситуация… Особенно, когда нужно рассуждать абстрактно… Да и условия достаточно жесткие - кластер и MPI...
Но попробую ;)

Если время не критично и стоит задача просто и с меньшими затратами смоделировать агентов – это одно. Если агентов много и время их работы нужно минимизировать – другое. Если взаимодействие агентов активное или, наоборот, очень редкое – третье. Если нужно оперативное отображение состояния агентов – это уже четвертое и т.д. и т.д. И таких нюансов может много. Но в любом случае, если уже есть реализация модели вычислений (безотносительно на чем), то реализуем агентов (хотя бы их часть) и смотрим на результат работы…
Рассмотрим проблемы, которые при этом могут быть, на примере параллельной сортировки, где каждый агент сортирует два попавших к нему в результате обмена с другими агентами два числа…
Пусть связи с другими агентами определены. Тогда работа агента заключается в том, чтобы взять от других агентов два числа и, отсортировав их, отправить другим агентам (возможно, даже тем же, от которых числа поступили).
Решение простое, но время получения результата сортировки может иметь большой разброс. Если мы имеет однопроцессорную систему, то моделирование параллелизма имеет смысл лишь до какого-то числа агентов (до того, пока имеет смысл ждать результат работы). Если мы разместим агентов в узлы кластера (каждому – узел), то результат может быть еще более плачевным, т.к. время обмена данными между узлами съест все выгоды от параллельной работы агентов. Может, чуть лучшие результаты будут, если мы будем работать над общей памятью.
Но если мы можем объединить агентов по нескольку «человек» на узел или, если говорить о сортировке, поручим агенту сортировать не два, а значительно большее число данных, то мы как бы «разрежем» параллельные вычисления на некие «полосы», которые позволят изменить соотношение обмены/вычисления. Но такой подход – это новый алгоритм.
Возможен ли алгоритм «разрезания»? Сможем ли мы его создать? Например, для той же сортировки это выливается в необходимость решения проблемы слияния отсортированных массивов. Потом, возможно, опять их разбивку, сортировку, слияние и т.д. И такое «укрупнение вычислений», безусловно, улучшит временные характеристики всех решений (в том числе, замечу, и однопроцессорного).
Ну а если «резать» нельзя. Тут, как мне кажется, два варианта – однопроцессорный и кластер с общей памятью. И то последний вариант будет эффективным, если у нас процессы достаточно статичны. Если же это что-то типа «клеточной жизни» (вычислительная модель – клеточный автомат, нейронная сеть), то тут уже надо оценивать уже связи между «клетками» (число, дальность, активность и т.д. и т.п.). Да тот же известный алгоритм параллельного суммирования (или так называемый алгоритм сдваивания), который легко «режется», но требует динамического порождения процесса для каждой пары чисел, и так до вычисления результата… Как он будет выглядеть на «статичном кластере»?
Короче. Можно сделать если не все, то многое. Но какими усилиями, за какое время, какой при этом будет алгоритм решения («чистый» или «резаный») и т.д. и т.п. Все это определяется конкретной проблемой, имеющимися техническими и … денежными средствами… И тут говорить – не переговорить… :)
По мне, если есть однопроцессорное решение, то чтобы его ускорить на порядок, так проще взять в десять раз более мощный компьютер, чем переносить решение на эквивалентный кластер, думаю, из ста (?) машин. Но тут другие проблемы – что будет дешевле? – это раз; есть ли вообще в десять раз более мощная машина? – это два; … Другое решение – создать программное/аппаратное ускорение модели. По примеру «клеточных машин». Ну и т.д. и т.п.
Raif писал(а):
Я на сегодняшний день лишь додумался до деления грида. Достаточно легко оценить "нагрузки" на каждый сектор в терминах средних. Весь процесс - суть Марковская цепь и можно легко посчитать такие величины как среднее время нахождения агента в заданной (для простоты, прямоугольной) области или, например, среднее кол-во встреч (т.е. обменов информацией) и пр. И на основании этих данных оптимизировать.

Я не знаю как и насколько легко это можно сделать для уже известных и достаточно простых параллельных задач, например, упомянутой выше параллельной сортировки, алгоритма сдваивания и/или обедающих философов Дейкстры. Если честно, то не уверен, что "цепь" тут вообще может чему-то помочь. По крайней мере, - мне ;)
Raif писал(а):
Хочется услышать алтернативные подходы или советы.

Решения почти известные, только вот выбор из них нужного порой очень сложен ;) Особенно, если еще постановка столь общая... Наверное, надо бы сделать какую-то небольшую "компанию" агентов, которых затем и "гонять" для исследования.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 18 июл 06 11:57 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
Спасибо за столь подробный ответ, многое прорисовывается. Позволю себе несколько конкретизировать задачу. Как и прежде, допустим есть популяция агентов и сетка где они живут. Все агенты разделены на группы (случайно). Группы имеют настраиваемые параметры (кол-во агентов в каждой группе и общее число групп). Агенты могут принадлежать нескольким группам одновременно. Кроме этого агенты разделены на классы (случайно). Для каждой группы пропорцией задается сколько агентов и каких классов должно содержаться в оной. Общее кол-во классов и кол-во агентов каждом классе тоже конфигурируется. Как такие популяции генерировать - отдельная тема (проблем здесь нет).
Далее (вот тут уже требуется совет специалиста насколько это грамотно) группы с определенной частотой (сейчас готова последовательная реализация, где частота у всех одинаковая и определяется некоторой вероятностью) инициируют цепочки встреч своих членов друг с другом. В процессе этих встреч агенты-участники опять же по заданному вероятностному закону обмениваются информацией друг с другом (встреча - когда координаты совпадают).
Агенты, в данный момент задействованные в цепочке встреч, для планировки других встреч использоваться не могут. Как Вы очень кстати заметили, еще нужно оперативное отображение состояния агентов. Можно ли в таких условиях что-то сделать?

К сожалению, условия C, MPI и кластер с распределенной памятью снять нельзя.

Спасибо


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 18 июл 06 16:01 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
…Агенты могут принадлежать нескольким группам одновременно.

Здесь вопросы. Я предполагал, что агенты разбиты на группы. А тут агенты – одно, группы – другое?
Raif писал(а):
Кроме этого агенты разделены на классы (случайно).

Это, например, типа - «жуки», «бабочки», «стрекозы», "мухи", "человеки с сачками/хлопушками"? ;)
Raif писал(а):
Для каждой группы пропорцией задается сколько агентов и каких классов должно содержаться в оной. Общее кол-во классов и кол-во агентов каждом классе тоже конфигурируется. Как такие популяции генерировать - отдельная тема (проблем здесь нет).

Понятно. Если не знать, как генерировать их, о каком решении тогда говорить?
Raif писал(а):
Далее (вот тут уже требуется совет специалиста насколько это грамотно) группы с определенной частотой (сейчас готова последовательная реализация, где частота у всех одинаковая и определяется некоторой вероятностью) инициируют цепочки встреч своих членов друг с другом. В процессе этих встреч агенты-участники опять же по заданному вероятностному закону обмениваются информацией друг с другом (встреча - когда координаты совпадают).
Агенты, в данный момент задействованные в цепочке встреч, для планировки других встреч использоваться не могут. Как Вы очень кстати заметили, еще нужно оперативное отображение состояния агентов. Можно ли в таких условиях что-то сделать?

Я что-то не заметил проблем? Если известно поведение агентов, их число, взаимодействие между ними, чем и как обмениваются, то что еще надо? Думаю, что нужно собирать все это в «кучу» и смотреть на все это «общение».
Я бы, конечно, все сначала смоделировал, создав модель близкую по структуре к кластеру. Т.е. один объект – это узел кластера, с локальным свойством – памятью. В него поместил бы нужное число агентов, создав таким образом группы на узле кластера. Создал бы множество объектов-узлов, установил между ними связи и запустил бы все это «общество» в работу.
Отработав все (особенно обмены между объектами-кластерами), переходил бы к реализации на кластере.
Raif писал(а):
К сожалению, условия C, MPI и кластер с распределенной памятью снять нельзя.
Спасибо

А собственно какая разница на чем реализовать отработанную (в смысле – протестированную ;)) модель? Может, рано и сожалеть-то? ;) Все будет определяться частотой взаимодействия и тем, как часто нужно будет синхронизировать общую память модели. Но, кстати, я пока не увидел необходимость в общей памяти. Может, что-то упустил?
И почему группы "инициируют" обмен, а не члены эти групп – агенты?
Какие «координаты» совпадают?
По «принципу чайника» я бы постарался свести задачу к какой-то подобной. Например философы Дейкстры. Каждый философ – группа (что внутри – не важно пока). Взаимодействие между ними – обмен «вилками». Другое дело, что философы в кольце. А группы?
Опять же постановка мне напоминает моих «жуков», которых нужно разбить на группы (см. ссылку на статью). Сюда вписываются и «координаты»: «жук» догоняет другого, когда координаты их фактически сравниваются (или достигают определенного расстояния между ними, например, расстояния «вытянутой руки/лапы» ;))
Такое чувство, что нужно уточнять дальше… ;)

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 18 июл 06 23:58 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
Цитата:
Здесь вопросы. Я предполагал, что агенты разбиты на группы. А тут агенты – одно, группы – другое?


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

Цитата:
Это, например, типа - жуки, бабочки, стрекозы, "мухи", "человеки с сачками/хлопушками"?


Как вариант. Любая другая легенда тоже подойдет. :wink:

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

Цитата:
Но, кстати, я пока не увидел необходимость в общей памяти. Может, что-то упустил?


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

Цитата:
И почему группы "инициируют" обмен, а не члены эти групп – агенты?


Фактически, это то же самое (или нет?). Если планировщик принимает решение что данная группа (т.е. члены данной группы) должна инициировать новую цепь встреч, то среди множества свободных в текущий момент времени членов этой группы выбираются несколько (случайно) и далее строится дерево встреч. При этом агенты на встречи не спешат, в том смысле что если данный агент должен где-то с кем-то встретися, то в модели передвижения оного у соответствующих направлений к месту встречи повышается приоритет, т.е. блуждания не прекращаются, но во всем процессе есть четкая (в настраиваемой степени) тенденция - доминирующее направление.

Цитата:
Какие координаты совпадают?

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 19 июл 06 9:58 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
...Что касается необходимости в общей памяти - дело в том, что одно из требований - оперативное отображение состояния агентов. Если бы был общий буфер, то это было бы несложно сделать.

Тут уже надо решать - как сделать? Можно сделать и без общей памяти: 1) процесс опрашивает состояния других процессов 2) все процессы посылают свое текущее состояние "отображателю". Можно с общей памятью: все отражают изменения (!) своего текущего состояния в общей памяти, ""отображатель" - отображает текущее состояние общей памяти.
Первый проще, второй и третий - меньше объем обменов. Для кластера второй и третий варианты лучше. Как отображать только изменения состояний: пускаем на каждом узле процесс, следящий за текущим состояние, а он, уловив изменение, посылает уже в общую память или "отображателю".
Raif писал(а):
Цитата:
И почему группы "инициируют" обмен, а не члены эти групп – агенты?


Фактически, это то же самое (или нет?). Если планировщик принимает решение что данная группа (т.е. члены данной группы) должна инициировать новую цепь встреч, то среди множества свободных в текущий момент времени членов этой группы выбираются несколько (случайно) и далее строится дерево встреч. При этом агенты на встречи не спешат, в том смысле что если данный агент должен где-то с кем-то встретися, то в модели передвижения оного у соответствующих направлений к месту встречи повышается приоритет, т.е. блуждания не прекращаются, но во всем процессе есть четкая (в настраиваемой степени) тенденция - доминирующее направление.

Группа и агент - разные вещи. Более того, если есть планировщик, то это уже как бы ограничивает роль/смысл самих агентов. Планирование " сверху" - это хорошо (но нужно учесть, что появляется еще один агент - планировщик), но, может, пусть агенты сами планируют (как версия)? Можно также сочетать общее планирование с индивидуальным.
Raif писал(а):
Цитата:
Какие координаты совпадают?

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

Собственно, общие вопросы у меня уже иссякли ;) А те, что "крутятся в голове", больше связаны и зависят уже от конкретной реализации алгоритмов планировщика, агентов, "отображателя" и т.д. и т.п. Для меня лично - это от соответствущим им автоматов, как их алгоритмических моделей.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 19 июл 06 10:35 
Не в сети

Зарегистрирован: 14 июл 06 1:14
Сообщения: 7
ВЛ писал(а):
Тут уже надо решать - как сделать? Можно сделать и без общей памяти: 1) процесс опрашивает состояния других процессов 2) все процессы посылают свое текущее состояние "отображателю". Можно с общей памятью: все отражают изменения (!) своего текущего состояния в общей памяти, ""отображатель" - отображает текущее состояние общей памяти.
Первый проще, второй и третий - меньше объем обменов. Для кластера второй и третий варианты лучше. Как отображать только изменения состояний: пускаем на каждом узле процесс, следящий за текущим состояние, а он, уловив изменение, посылает уже в общую память или "отображателю".

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

ВЛ писал(а):
Группа и агент - разные вещи. Более того, если есть планировщик, то это уже как бы ограничивает роль/смысл самих агентов. Планирование " сверху" - это хорошо (но нужно учесть, что появляется еще один агент - планировщик), но, может, пусть агенты сами планируют (как версия)? Можно также сочетать общее планирование с индивидуальным.


Видимо смотря как посмотреть. Собака виляет хвостом или хвос собакой. Если планировщик что-то планирует для той или иной кучки агентов - на это можно взгянуть как если бы эти агенты сами все это спланировали. Или что Вы имеете ввиду под разными вещами? Что группа - это не обязательно один агент - в этом смысле разные?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: 19 июл 06 11:12 
Не в сети

Зарегистрирован: 19 окт 04 11:21
Сообщения: 197
Raif писал(а):
Видимо смотря как посмотреть. Собака виляет хвостом или хвос собакой.

Как ни смотри, а смотреть и выделять нужно того, кто обладает поведением (если уж мы говорит об агентах). В данном случае "собака виляет хвостом". Все же какие ни есть, но "мозги" следует отнести к собаке, а не к ее хвосту. Хотя, конечно, все в руках пргграммиста - "мозги" можно разместить и в ... хвосте :D
Raif писал(а):
Если планировщик что-то планирует для той или иной кучки агентов - на это можно взгянуть как если бы эти агенты сами все это спланировали. Или что Вы имеете ввиду под разными вещами? Что группа - это не обязательно один агент - в этом смысле разные?

Во-первых, спланировали все же не агенты, а планировщик... Так, наверное?
Но, если смотреть на группу, как на "черный ящик", то она может восприниматься, как один агент. Но реально мы-то знаем, что это группа агентов (наверное, еще и + планировщик). Другое дело, что для группы агентов можно построить агента с эквивалентным этой группе агентов поведением (вот тут и самое место вспоминить про теорию параллельных вычислений;)), тогда, да, группа - это один агент (но тогда забываем, про отдельных агентов).
Другое дело, что нужно еще построить эквивалентного агента. Из теории известно, что даже для пяти философов Дейкстры это почти неразрешимая - даже не теоретически, а практически! - проблема.

_________________
Лучшее - враг хорошего?


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 14 ] 

Часовой пояс: UTC + 4 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB