Медленное параллельное программирование — MPI, VB.NET и FORTRAN

Я работаю над распараллеливанием программного обеспечения, которое моделирует процесс переноса и потока в зоне ненасыщенного грунта. Программное обеспечение состоит из пользовательского интерфейса VB.NET и ядра FORTRAN DLL для выполнения вычислений. Я распараллелил программное обеспечение, используя пакет MPI.NET в части VB.NET. Когда программа запускается с несколькими процессами, все они, кроме главного процесса, переходят в режим ожидания, в то время как главный процесс заботится о взаимодействии программного обеспечения с пользователем. Когда все данные, необходимые для моделирования, введены, главный процесс входит в FORTRAN DLL и вызывает другие процессы. Они переходят к начальной точке функции в DLL, и вместе все процессы решают линейную систему уравнений примерно 10-20 раз (исходное уравнение в частных производных нелинейно, поэтому эти итерации для получения точности решения ). Когда решение вычислено, все процессы возвращаются к VB.NET. Это делается для всех временных шагов моделирования. Когда все шаги вычислены, главный процесс продолжает взаимодействие с пользователем, в то время как другие процессы возвращаются в функцию ожидания до тех пор, пока они не будут снова вызваны главным процессом. Дело в том, что эта программа работает намного медленнее, чем ее исходная, последовательная версия. На это может быть несколько причин. Я использовал библиотеку PETSc в FORTRAN DLL для решения системы уравнений, и я думаю, что настроил ее достаточно хорошо. Мой вопрос заключается в том, может ли в какой-то момент в архитектуре, которую я описал, быть точка или две, которые могут вызвать значительное замедление, если они не будут обработаны правильно. Я не уверен, т.е. если последующие вызовы функции DLL могут стоить много времени. Моя система представляет собой процессор Intel Xeon 3470 с 8 ГБ оперативной памяти. Системы, которые я пытался решить, имели до 120 000 неизвестных, что, как я знаю, находится на самой нижней границе того, что следует вычислять параллельно, но, по крайней мере, с матрицей 120 000 я ожидал бы лучшей производительности, чем я измерял.

Заранее спасибо за ваши мысли, Мартин


performance vb.net parallel-processing fortran mpi
person Martin    schedule 27.04.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Я бы сказал, что 120 000 степеней свободы и 10-20 итераций — не такая уж большая проблема. Задачи с миллионом степеней свободы были решены, когда я зарабатывал на жизнь анализом конечных элементов, а это было 16 лет назад.

Можно ли решить ее с помощью решателя в памяти, без распараллеливания, с 8 ГБ ОЗУ? Это, безусловно, будет вашим эталоном. Это то, с чем вы сравниваете свои параллельные результаты?

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

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

person duffymo    schedule 27.04.2011

arrow_upward
0
arrow_downward

Если у вас несколько ядер, когда вы запускаете свою программу последовательно, видите ли вы, что используется только один или несколько процессоров? Если нагрузка в последовательном случае большая и равномерно распределяется по всем ядрам то ИМХО нет необходимости распараллеливать вашу программу.

person 8DH    schedule 27.04.2011

arrow_upward
0
arrow_downward

В моей системе установлен Xeon 3470, четырехъядерный процессор. Таким образом, все вычисления выполняются на этих машинах 4 на 1. Конечно, я не запускаю программу с более чем 4 процессами. Старый решатель, который был в программном обеспечении, конечно, был последовательным, и он по-прежнему работает быстрее, чем параллельная версия. Когда я отображаю количество процессов в зависимости от времени выполнения, я вижу, что время выполнения даже немного увеличивается с меньшими моделями, но этого следовало ожидать из-за накладных расходов на связь.

И в последовательном, и в параллельном случае используются все 4 процессора, и баланс нагрузки между ними приемлем.

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

person Martin    schedule 27.04.2011
comment
Это не должно быть отдельным ответом. Если вы хотите предоставить дополнительную информацию, вы можете отредактировать исходный вопрос; если вы хотите ответить на конкретный ответ, вы можете разместить комментарий под ним. - person eriktous; 27.04.2011
comment
@eriktous: Я думаю, Мартин опубликовал это как ответ, потому что он случайно создал и вошел в систему под другой учетной записью. @Martin: вы можете попросите модераторов объединить ваши учетные записи, чтобы вы могли лучше отслеживать свои сообщения, а также комментировать их. - person Helen; 27.04.2011