Оценка исполнения с передачей сообщений - PullRequest
2 голосов
/ 03 мая 2009

Я должен построить распределенное приложение, используя MPI. Одно из решений, которое мне нужно принять, - как отобразить экземпляры классов в процесс (а затем в машины), чтобы получить максимальные преимущества от распределенной среды.

Мой вопрос: есть модель, которая позволяет мне выбрать лучшее отображение? Я имею в виду, что некоторые механизмы, безусловно, неверны (например, помещать в две разные машины два объекта, которые должны последовательно обрабатывать довольно большой объем данных, без потока токенов для обработки), но есть систематический способ определить такие неправильные схемы, определяемые потоком выполнения, сложностью сообщения, временем, затрачиваемым на вычисления, выполняемые алгоритмическими компонентами?

Ответы [ 3 ]

1 голос
/ 04 мая 2009

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

Когда я работал в Lockheed Martin, я познакомился с CSIM , инструментом, который они разработали для моделирования алгоритма, отображающего блоки обработки.

0 голосов
/ 01 февраля 2012

Практическим решением этой проблемы будет использование другой модели параллельного программирования с распределенной памятью, которая напрямую решает ваши проблемы. Я работаю в системе программирования Charm ++ , модель которой - отдельные объекты, отправляющие сообщения от одного к другому. Система времени выполнения облегчает автоматическое сопоставление этих объектов с доступными процессорами для учета проблем с балансировкой нагрузки и локальностью связи.

0 голосов
/ 08 мая 2009

Еще одна вещь, которую вы можете попробовать - Join Calculus . Я нашел примеры программирования с ним на удивление интуитивно понятным, и я думаю, что это хорошо обосновано в теории. Я не уверен, почему это не завоевало популярность.

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

...