2009-03-13 5 views
0

Я понимаю различия между многопоточной программой и программой, основанной на межмашинной связи. Моя проблема в том, что у меня есть хорошая многопоточная программа, написанная на языке C, которая работает и работает очень хорошо на 8-ядерном компьютере. Теперь появилась возможность переносить эту программу в кластер, чтобы получить доступ к большему количеству ядер. Стоит ли пытаться вырвать материал pthread и модифицировать MPI (который я никогда не использовал), или нам лучше переписать все это (или большую часть) с нуля? Предположим, что мы «застряли» с C, поэтому опциональная смена языка - это не вариант.Преобразование pthreaded программы в MPI?

ответ

2

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

К сожалению (или, к счастью), передача сообщений - совсем другое зверь, чем pthreading - основное предположение совершенно иное. Я люблю this quote from Joshua Phillips of the Maestro team: «Разница между передачей сообщений и совместным использованием общего состояния эквивалентна разнице между отправкой коллеге по электронной почте с просьбой выполнить задание и открытием ее организатора для записи задачи непосредственно в нее, сделайте список. Больше, чем просто быть грубым, последнее, вероятно, смутит ее - она ​​может стереть его, не заметить, или случайно определить приоритет неправильно ».

К сожалению, способ обмена данными очень отличается. Прямой доступ к данным в других потоках отсутствует (так как это может быть на других машинах), поэтому очень сложно выполнить миграцию с pthreads на MPI. С другой стороны, если код написан так, что каждый поток изолирован, это может быть легкой задачей и, безусловно, стоит.

Чтобы определить, насколько это полезно, вам нужно понять код и то, что вы надеетесь достичь путем переключения. Это может быть полезно как опыт обучения (вы узнаете много о синхронизации и потоковом режиме, работая в MPI), но может быть непрактичным, если прибыль будет незначительной.

+0

Спасибо за быстрый ответ. У этой программы есть преимущество архитектуры ведущий-ведомый. Один поток запускает много идентичных подтипов. Ни одна из подпотоков не нуждается в общении с другими. И обмен данными между мастером и подчиненным является небольшим и нечастым. – Joey

+0

Если это так, портирование в MPI, вероятно, будет довольно простым. Другая проблема заключается в том, как потоки сообщают свои результаты обратно в основной поток - много информации прошло? Тогда состояние и результаты, вероятно, будут вашими заботами. –

+0

Еще раз спасибо. В основном это настройка мастера, позволяющая получить некоторые данные для всех подзадач, каждый из которых выполняет некоторую работу на основе этих данных, а затем каждый делает результат доступным для мастера. Мастер делает некоторые работы и повторяет. Для координации это в основном «Спящая проблема парикмахера». – Joey

0

Re. ваш комментарий к Reed - это звучит как легкое, низкое переключение на MPI. Просто будьте осторожны: не все MPI API поддерживают динамическое создание процессов, то есть вы запускаете свою программу с N процессами (указанными при запуске), и вы застряли с N процессами в течение всего срока службы программы.

+0

Спасибо. Я думал, что комментарий может добавить детали, которые могут помочь с предложениями. Ваш ответ также говорит о потенциальной легкости этого преобразования: каждый раз, когда запускается эта программа, априори известно, сколько потоков (процессов в MPI) будет необходимо. Благодаря! – Joey

+0

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