КОММЕНТАРИЙ К ПРАКТИЧЕСКОЙ РАБОТЕ №2 «OpenMP» ПО КУРСУ ОПП

КОММЕНТАРИЙ К ПРАКТИЧЕСКОЙ РАБОТЕ №2 «OpenMP» ПО КУРСУ ОПП

ПРО MPIИOPENMP

Данная практическая работа направлена на знакомство со следующей технологией параллельного программирования – OpenMP. Как и MPI, OpenMPявляется стандартом. Но только реализуется этот стандарт не в виде отдельной библиотеки, подключаемой к вашей программе на этапе компиляции, а в самом компиляторе. То есть OpenMP-директивы, которые Вы напишите в сишный код, обязаны восприниматься любым компилятором, поддерживающим эту технологию. Ну и естественно, что все популярные широко используемые компиляторы языков C/C++ и Fortran эту технологию поддерживают.

О том как использовать OpenMPна кластере рассказано здесь:

http: //nusc. nsu. ru/wiki/doku. php/doc/openmp/openmp

Добавлю только, что в случае gccподдержка OpenMPвключается при помощи ключа
«-fopenmp», а в случае интеловского iccили icpc – при помощи «-openmp». То есть:

g++ -fopenmp omp_hello. cpp -o g++_omp_hello. out

icpc -openmp omp_hello. cpp -o icpc_omp_hello. out

MPI-программа ориентирована на запуск множества процессов. Процесс – самостоятельная программная единица. Часть процессов можно запустить на одной машине под одной операционной системой, а другую часть – на другой (именно это вы и делали в первой лабе). В отличие от MPI, технология OpenMP ориентирована на запуск множества потоков (нитей, тредов) в пределах одного процесса. И поскольку процесс со всеми своими потоками должен размещаться в пределах одного экземпляра операционной системы, установленного на одной машине, то OpenMP-программу нельзя запустить на нескольких машинах, входящих в кластер.

Может возникнуть вопрос: а для чего тогда нужен OpenMP, если он накладывает такие жесткие ограничения на масштабируемость? В чем его плюсы перед MPI? Ответ: основной плюс – скорость разработки. Распараллелить программу с помощью OpenMPна порядок проще, чем с помощью MPI. Для того, чтобы получить существенное ускорение иногда достаточно просто поставить директиву распараллеливания перед основным циклом программы и несколько вспомогательных директив. Кроме того, поток является существенно более легкой единицей, чем процесс. Для порождения и последующего содержания потока нужно меньше оперативной памяти, времени и др. В связи с этим программа на OpenMPв nпотоков зачастую оказывается быстрее, чем эквивалентная ей MPI-программа в nпроцессов, запущенная на одном узле.

Схожесть MPIи OpenMPв использовании программной модели SPMD (SingleProgramMultipleData). То есть вы пишите одну программу, код которой выполняют все процессы (в MPI) или все потоки (в OpenMP). Конечно вы можете выбирать исполнителя для какого-то участка при помощи, например, конструкции «if (myrank == P) {…}», но это частности. К слову это будет являться отличием с технологией POSIXThreads (Pthreads), где для каждой нити задается свой собственный код (с Pthreadsмы познакомимся в 5-й лабе).

Если продолжать сравнивать MPIи OpenMP, то специфичные для каждой технологии проблемы также различны. Для MPI – проблема грамотной организации коммуникаций между процессами:

· Накаждый (I, S, B, R, Is, Ib, Ir)Sendобязательно должен быть соответствующий (I)Recv.

· Коллективная коммуникация должна быть вызвана НА ВСЕХ ПРОЦЕССАХ коммуникатора.

· Служебные параметры (тэги, типы данных, количество передаваемых/принимаемых элементов) при коммуникации на всех процессах должны друг другу соответствовать.

· …

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

В случае OpenMPодной из основных проблем является синхронизация доступа к объектам, общим для потоков. Потоки отличаются от процессов в частности тем, что делят общую память, принадлежащую всему процессу. Конечно можно объявить переменную как privateи таких проблем с ней не будет, но, к сожалению, от shared-объектов редко удается избавиться… Если у вас shared-объект изменяется несколькими нитями, то вам сразу нужно думать о том, как обезопасить доступ к нему.

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

Последовательная секция //один поток

Параллельная секция на 4 потока

Последовательная секция

Параллельная секция на 2 потока

Последовательная секция

Для этого служит параметр «num_threads» при создании параллельной секции:

#pragmaomp parallel num_threads(2)

⇐ Предыдущая 123 Следующая ⇒