Автор: Дацюк В.Н., Букатов А.А., Жегуло А.И.
Источник: Ростовский государственный университет
Эффективность использования компьютеров в решающей степени зависит от состава и качества программного обеспечения, установленного на них. В первую очередь это касается программного обеспечения, предназначенного для разработки прикладных программ. Так, например, недостаточная развитость таких средств для систем MPP типа долгое время являлась сдерживающим фактором для их широкого использования. В настоящее время ситуация изменилась, и благодаря кластерным технологиям MPP системы стали самой распространенной и доступной разновидностью высокопроизводительных вычислительных систем. В данной главе мы кратко рассмотрим средства параллельного программирования для многопроцессорных систем.
Как отмечалось ранее, основной характеристикой при классификации многопроцессорных систем является наличие общей (SMP системы) или распределенной (MPP системы) памяти. Это различие является важнейшим фактором, определяющим способы параллельного программирования и, соответственно, структуру программного обеспечения.
К системам этого типа относятся компьютеры с SMP архитектурой, различные разновидности NUMA систем и мультипроцессорные векторно-конвейерные компьютеры. Характерным словом для этих компьютеров является "единый": единая оперативная память, единая операционная система, единая подсистема ввода-вывода. Только процессоры образуют множество. Единая UNIX-подобная операционная система, управляющая работой всего компьютера, функционирует в виде множества процессов. Каждая пользовательская программа также запускается как отдельный процесс. Операционная система сама каким-то образом распределяет процессы по процессорам. В принципе, для распараллеливания программ можно использовать механизм порождения процессов. Однако этот механизм не очень удобен, поскольку каждый процесс функционирует в своем адресном пространстве, и основное достоинство этих систем - общая память - не может быть использован простым и естественным образом. Для распараллеливания программ используется механизм порождения нитей (threads) - легковесных процессов, для которых не создается отдельного адресного пространства, но которые на многопроцессорных системах также распределяются по процессорам. В языке программирования C возможно прямое использование этого механизма для распараллеливания программ посредством вызова соответствующих системных функций, а в компиляторах с языка FORTRAN этот механизм используется либо для автоматического распараллеливания, либо в режиме задания распараллеливающих директив компилятору (такой подход поддерживают и компиляторы с языка С).
Все производители симметричных мультипроцессорных систем в той или иной мере поддерживают стандарт POSIX Pthread и включают в программное обеспечение распараллеливающие компиляторы для популярных языков программирования или предоставляют набор директив компилятору для распараллеливания программ. В частности, многие поставщики компьютеров SMP архитектуры (Sun, HP, SGI) в своих компиляторах предоставляют специальные директивы для распараллеливания циклов. Однако эти наборы директив, во-первых, весьма ограничены и, во-вторых, несовместимы между собой. В результате этого разработчикам приходится распараллеливать прикладные программы отдельно для каждой платформы.
В последние годы все более популярной становится система программирования OpenMP [3, 6], являющаяся во многом обобщением и расширением этих наборов директив. Интерфейс OpenMP задуман как стандарт для программирования в модели общей памяти. В OpenMP входят спецификации набора директив компилятору, процедур и переменных среды. По сути дела, он реализует идею "инкрементального распараллеливания", позаимствованную из языка HPF (High Performance Fortran - Fortran для высокопроизводительных вычислений) . Разработчик не создает новую параллельную программу, а просто добавляет в текст последовательной программы OpenMP-директивы. При этом система программирования OpenMP предоставляет разработчику большие возможности по контролю над поведением параллельного приложения. Вся программа разбивается на последовательные и параллельные области. Все последовательные области выполняет главная нить, порождаемая при запуске программы, а при входе в параллельную область главная нить порождает дополнительные нити. Предполагается, что OpenMP-программа без какой-либо модификации должна работать как на многопроцессорных системах, так и на однопроцессорных. В последнем случае директивы OpenMP просто игнорируются. Следует отметить, что наличие общей памяти не препятствует использованию технологий программирования, разработанных для систем с распределенной памятью. Многие производители SMP систем предоставляют также такие технологии программирования, как MPI и PVM. В этом случае в качестве коммуникационной среды выступает разделяемая память.
В системах этого типа на каждом вычислительном узле функционирует собственные копии операционной системы, под управлением которых выполняются независимые программы. Это могут быть как действительно независимые программы, так и параллельные ветви одной программы. В этом случае единственно возможным механизмом взаимодействия между ними является механизм передачи сообщений.
Стремление добиться максимальной производительности заставляет разработчиков при реализации механизма передачи сообщений учитывать особенности архитектуры многопроцессорной системы. Это способствует написанию более эффективных, но ориентированных на конкретный компьютер программ. Вместе с тем независимыми разработчиками программного обеспечения было предложено множество реализаций механизма передачи сообщений, независимых от конкретной платформы. Наиболее известными из них являются EXPRESS компании Parasoft и коммуникационная библиотека PVM (Parallel Virtual Machine), разработанная в Oak Ridge National Laboratory.
"MPI"В 1994 г. был принят стандарт механизма передачи сообщений MPI (Message Passing Interface) [7]. Он готовился с 1992 по 1994 гг. группой Message Passing Interface Forum, в которую вошли представители более чем 40 организаций из Америки и Европы. Основная цель, которую ставили перед собой разработчики MPI - это обеспечение полной независимости приложений, написанных с использованием MPI, от архитектуры многопроцессорной системы, без какой-либо существенной потери производительности. По замыслу авторов это должно было стать мощным стимулом для разработки прикладного программного обеспечения и стандартизованных библиотек подпрограмм для многопроцессорных систем с распределенной памятью. Подтверждением того, что эта цель была достигнута, служит тот факт, что в настоящее время этот стандарт поддерживается практически всеми производителями многопроцессорных систем. Реализации MPI успешно работают не только на классических MPP системах, но также на SMP системах и на сетях рабочих станций (в том числе и неоднородных).
MPI - это библиотека функций, обеспечивающая взаимодействие параллельных процессов с помощью механизма передачи сообщений. Поддерживаются интерфейсы для языков C и FORTRAN. В последнее время добавлена поддержка языка C++. Библиотека включает в себя множество функций передачи сообщений типа точка-точка, развитый набор функций для выполнения коллективных операций и управления процессами параллельного приложения. Основное отличие MPI от предшественников в том, что явно вводятся понятия групп процессов, с которыми можно оперировать как с конечными множествами, а также областей связи и коммуникаторов, описывающих эти области связи. Это предоставляет программисту очень гибкие средства для написания эффективных параллельных программ. В настоящее время MPI является основной технологией программирования для многопроцессорных систем с распределенной памятью.
Несмотря на значительные успехи в развитии технологии программирования с использованием механизма передачи сообщений, трудоемкость программирования с использованием этой технологии все-таки слишком велика.
"HPF"Альтернативный подход предоставляет парадигма параллельной обработки данных, которая реализована в языке высокого уровня HPF [8]. От программиста требуется только задать распределение данных по процессорам, а компилятор автоматически генерирует вызовы функций синхронизации и передачи сообщений (неудачное расположение данных может вызвать существенное увеличение накладных расходов). Для распараллеливания циклов используются либо специальные конструкции языка (оператор FORALL), либо директивы компилятору, задаваемые в виде псевдокомментариев ($HPF INDEPENDENT). Язык HPF реализует идею инкрементального распараллеливания и модель общей памяти на системах с распределенной памятью. Эти два обстоятельства и определяют простоту программирования и соответственно привлекательность этой технологии. Одна и та же программа, без какой-либо модификации, должна эффективно работать как на однопроцессорных системах, так и на многопроцессорных вычислительных системах.
Программы на языке HPF существенно короче функционально идентичных программ, использующих прямые вызовы функций обмена сообщениями. По-видимому, языки этого типа будут активно развиваться и постепенно вытеснят из широкого обращения пакеты передачи сообщений. Последним будет отводиться роль, которая в современном программировании отводится ассемблеру: к ним будут прибегать лишь для разработки языков высокого уровня и при написании библиотечных подпрограмм, от которых требуется максимальная эффективность.
В середине 90-х годов, когда появился HPF, с ним связывались большие надежды, однако трудности с его реализацией пока что не позволили создать достаточно эффективных компиляторов. Пожалуй, наиболее удачными были проекты, в которых компиляция HPF-программ выполняется в два этапа. На первом этапе HPF-программа преобразуется в стандартную Фортран-программу, дополненную вызовами коммуникационных подпрограмм. А на втором этапе происходит ее компиляция стандартными компиляторами. Здесь следует отметить систему компиляции Adaptor [9], разработанную немецким Институтом алгоритмов и научных вычислений, и систему разработки параллельных программ DVM, созданную в Институте прикладной математики им. М.В. Келдыша РАН. Система DVM поддерживает не только язык Фортран, но и C [10]. Наш опыт работы с системой Adaptor показал, что в большинстве случаев эффективность параллельных HPF-программ значительно ниже, чем MPI-программ. Тем не менее, в некоторых простых случаях Adaptor позволяет распараллелить обычную программу добавлением в нее всего нескольких строк.
Следует отметить область, где механизму передачи сообщений нет альтернативы - это обслуживание функционального параллелизма. Если каждый узел выполняет свой собственный алгоритм, существенно отличающийся от того, что делает соседний процессор, а взаимодействие между ними имеет нерегулярный характер, то ничего другого, кроме механизма передачи сообщений, предложить невозможно.
Описанные в данной главе технологии, конечно же, не исчерпывают весь список - приведены наиболее универсальные и широко используемые в настоящее время. Более подробный обзор современных технологий параллельного программирования можно найти в книге [3].