Параллельная Обработка Данных, 10 лекция (от 06 ноября)

Материал из eSyr's wiki.

Версия от 18:05, 17 ноября 2007; Allena (Обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)

Закончили архитектуру пар выч систем. Для классов были выписаны сложности.

Вторая тема -- Технологии параллельного программирования. Програмирование на асме уходит в рошлое. Нужен посредник, который записывает методы на языке понятном и нам и машине.

Технологиии параллельного пограммирования

Задача-- Метод-- Алгоритм -- Технлогия программирования -- Программа -- Компилятор -- Компьютер

ТП - центральная часть. Речь пойдет о тп параллельных. На всей цепочке не долэжно быть ни одного узкого места, в том числе и в технологиях. Технологии должны эффективно выражать метод и эффективно отображать их на разные классы компов. Иногда помогает то, что уже реализовано в архитектуре(супер склярность), но без спец технологий не обойтись. Для того чтобы достчиь цели можно выбрать и массу обходных путей -- сразу с яву на комп(например при использовании какого-нибудь мощного пакета).Вообще,в озможен почти любой обходной путь через основные понятия. Вообще есть три критерия для тп:

эффективность. Допускает ои она создание эф программ?
переносимость. Хочется.ю чтобы программа не была привязана к конкретному компьютеру
продуктивность. Работы прораммиста.

Любая технология это компромисс между этими критериями. С точки зрения этих критереев будем оценивать технологии

Когда говорим про тпп имеется ввиду целый набор подходов, которыми можно ользоваться:

Использование традиционных языков программирования. Паскаль, фортран. Предполагается, что комп с парал арх. Кто-то должен определить параллельную струкутуру. Это нагрузка ложиться нак омпилятор. Надежда на умный компилятор, как показыввает история -- пустая.В любом случае требуется вмешательство. Так что, как бы ни был удобен этот путь(столько всего написано), но неээфективен.
спец комментарии. Не влияют на суть программы, там указываются доп сведения, упрощающие жизнь компилятору. Чутьчуть сдвигаемся в торону эффективности, остаемся в рамках прежней программной инфраструктуры(такую прорамму можно скормить и не поддерживающему спецкоменты компилеру). Это часто использовали на векторных компах. В них самое главное было распознать внутренние циклы без зависимостей. Именно эта доп информация и была наиболее часто используемым видом комментариев.
Введение доп конструкций в традициионые языки. Была иллюзия, что добавим несколько новых конструкций, человку нужно будет немножко поменять и все станет параллельно. Пример HPF -- через 7-8 лет осознали, что страдает эффективность. MPC - поззволяет прораммировать для неоднородной сети компьютеров.Большие проблемы с переносимостью -- без спецефичных компиляторов для платформы не будет параллельных программ.
Новые языки. Occam, Sisal. Опять проблемы с переносимостью. Появление любых новых стандартов, вовлечение в свою веру, привлечение людей -- это большие сложности В ипмебыл создан язык НОРМА - для обработки сеточных функций. Хорошо с эффективностью и продуктивностью, плохо с переносимостью, Речи о том чтобы использовать везде к сожалению не идет.

Сейчас наиболле распространненая арх - компы с распр памятью. Общение -- передачей сообщений. Появилось много библиотек передачи сообщений.

Библиотеки передачи сообщений. PVM, MPI, Shmem. За основу беруться традиционные программы. На сегодняшнитй день 95% процентов прорамм -- это наполовину с, наполовину фортран.
параллельные предмнтные библиотеки. Хорошие пакеты по линейке, преобр фурье, обработки изображений. Обвязка на обычном языке, а весь паралеллизм в спец библиотеке, реализованной специалистами, грамотно распралеллеными. ПРимеры -- Scalapack - основные функции линала для компов с распр памятью.FFTW - преобразования фурье, часто используется, и многие другие. Подход удачный, часто используется.
Специализированные комплексы программ. Средство самого выского уровня, чел формулирует задачу в терминах предметной области, все этапы за программиста сделают. Maxima, ANSYS GAMESS, Flow Vision. Это самый идеальный вариант, если можно этим подходом решить задачу -- то так и надо делать.

Базовый вопрос - дали систему из 1000 процов. А как себе представить себе функционирование программы, анд которой одновременно работают 1000 процессоров. Вопрос о модели о конца не решен, пока есть два подхода

SPMD(Single program Multiple Data). Берется один код программы и все процессоры работают согласно одной и той же программе, но каждый процесс работает над своими данными. Как этого добиться? В любом случае в тп предусматривается средство самоопределение роцесса. пусть это функция MyID. Оно взвращает униек номер приписанный данному процессору. Как разделить работу? Очен просто --- ид == работе с роцессором номер ид.
Мастер/Рбочие -- разбиение всего множествоа процессов параллеьной программы на мастера(распределяюещего ресурсы) и подчиненных. Подчиенные как правило работают по одномк =у тексту прораммы, мастр по собственной. Master/Slaves -- запретили по соображением политкорректности.

Перейдем к детальному рассмотрению MPI.

MPI

Начало 90 годов. Аббревиатура от Message Passing Interace. Ориентирована на компы с распр памятью, в которых роцессы общаются с помощью передачи сообщений. Полный вариант стандарта -- более 100 функций. Разберем основные идеи. Стандарт 1.1 До сих пор используется, хотя появился уже 2.0. Пользователи не уверены в том что переход н 2.0 эффективен и многие юзают 1.1. МПИ распр в виде библиотек для с и фортрана. Все детали текущей реализации доступны на mpiforum.org,.На всех современных платформах есть мпи. Изначально он был ориентирован на инукс, но уже давно есть погддержка для виндовс, в вин клстер сервер - он выдвинут на первый план. Конструкции мпи начинаются с MPI_ .

include<mpi.h>

Что из себя представляет парл мпи программа -- набор независимых процессов(процесс в терминах юникса, у каждого процесса свое адресное пространство, общей памяти у процессов нет). Предпорлагается что породили м штук процессов одновремено, потом завершаются. Нельзя динамически породить парал процесс.В мпи2 от этого отошли. В очень большом числе случаев это вполне достаточно, как показывает опыт. Введено понятие группы процессов. Для группы выделяется специальное пространство для общение, которое называется коммуникатор. Есть надежда, что общение в нескольких коммуникаторах эффективней, чем в общей куче. Имеется нечто всеобъемлющее -- коммуникатор куда погружены все процессы. Он называется MPI_COMM_WORLD -- определен всегда. Каждый пар процесс имеет уникальный номер. В каждом коммуникаторе процесс может иметь свой номер. В способе формирования коммуникаторов и групп - полная свобода, они могут полностью вкладываться,частично пересекаться, вовсе не пересекаться. То, что касается сообщений. Набор однотипных данных, кот передаются от одного процесса к другому. Это содержательная сторона сообщения. Важно, что все данные имеют один и тот же тип, для разнородной инфы требуется спец ритуальный танец. Каждое сообщение имеет тэг(некая доп информация, целое число). Введено понятие производных типов.Пользователь может создавать свои типы и их передавать. Например туда пользователь может внести неоднородность. Не во всех задачах процессы общаются аморфной кучей. Иногда процессы например образовывают кольцо, у каждого ровно два соседа. Есть понятие виртуальная топология, опредлив которое можно навести порядок в общении процессов друг с другом. Часто процессы распологают в узлах прямоугольной решетки с/без зацикленности по тору. Несколько слов о самой технлогии. Рассматривать будем на примере с. Основа с эта функция.

Любая мпи функция возвращает код - MPI_SUCCESS - все закончилось нормально. Если вернулось не это значение -- код ошибки можно посмтореть в стандарте.

Общие функции.

mpi_init(int *argc, char***argv); сколько процессов породилось - указано в аргв. Все остальные действия могут выполняться только поосле того как выполнилась функция мпи инит. Но и выполнить ее можно только один раз. mpi_inalize(void) - закончить все мпи процессы. mpi_initialized(int *flag) - запускал ли кто-нибудь уже мпи_инит или нет.Содержательный результат возвращется через флаг .mpi_comm_size(MPI_COMM comm, int *size) - количество параллельных процессоров в данном коммуникаторе. mpi_comm_run(MPI_COMM comm, int *my_id) -- коммуникатор и переменная куда будет зписан номер процесса. Осмысленная мпи программа: Порождает некторое кол-во процессов, каждый процесс определяет сколько работает рядом с ним и свой номер.

include <mpi.h>

main(int argc, char * argv[]) { int size;//щбщее кол-во процессов int my_id;//номер текущего mpi_init(&argc, &argv); // порождение произошло, теперь смотрим сколько вокруг и свой номер mpi_comm_size(MPI_COMM_WORLD, &size); mpi_comm_run(MPI_COMM_WORLD, &my_id); printf("Total: %d \n proc %d", size, my_id); mpi_finalize(); }

Сколько процессов порождается -- указывается через аргв. Напечатано будет столько раз, сколько процессов породилось. Порядок в котором появятся выдачи заранее не определен, он может быть любым. Гарантируется лишь что строка эьто неделимая сущность и она выдается целиком.

Взаимодействие процессов
- Коллективные операции(все процессы воввлечены)
- Точка-точка(взаимодействует пара процессов между собой)
  - Синхронные(с блокировкой)

MPI_send(void *buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm) -- буффер сообщения который надо передать, кол-во элементов, тип элементов, номер процесса получателя, тэг, в рамках какого коммуникатора Причем тут синхронность? Она тут трактуется не совсем стандартно. ПОсылающий процесс блокируется до тех пор, пока у него есть опасение испортить отправляемые параметры.Гарантируется, что что бы в отправляющем процессе не стояло после мпи_сенд, оно будет отправлено ровно в том виде в каком было на моент вызова мпи_сенд. Доставка не гарантируется. MPI_Recv(void *buf, int count, MPI_Datatype, int dest, int tag, MPI_comm comm, MPI_Status * status) -- статус описывает статус принимаемого сообщения. Возврат произойдет только когда в буффер запишутся все каунт элементов принмаемого сообщения. Вся система построена на том, что есть два процесса -- один посылает, а другой принимает. Несколько общих замечаний. Предположим, есть процесс А и процесс Б. В некоторый момент процесс А посылает Б два сообщения. Процесс Б их может принять. И оба сообщения идут с одним и тем же тэгом. Есть ли гарантия того что сообщения придут в определенном порядке? Да. Если от одного и того же процесса ушли два сообщения, то первым приде то, кторое первым было отправлено. Но вот если А и С отправляют что-то Б, то чьё сообщение придет первым -- неопределено Есть константа MPI_ANYSOURCE - если ее поставить в ресв то сообщения будут ждаться от любого процесса. Аналогично MPI_ANYTAG. Справедливости в обслуживании процессов нет. Если Б зкидывает А сообщениями в цикле, то еденичное сообщение из С в А может и не пробиться. Принятая семантика синхронных операций может приводить к тупиковым ситуациям. Есть два процесса, им надо обменяться сообщениями. Оба пишут MPI_Send MPI_Recv А сделал сенд Б, аналогично Б сделал сенд А. А дальше у них стоит прием. Оба процесса могут стоять бесконечон долго ожидая завершения мпи_сенд, из за особенности семантики мпи_сенд. Конкретная реализация может ожидать того, что принмающая сторона заберет сообщение. И все друг друга ждут. Эта ситуация описана во всех мануалах, она просто обходится при помощи операций асинхронного взаимодействия. Но к этому надо быть готовыми. Она может проявятьс япо разному -- аналогичный эффет возникает если надо организовать обмен сообщений между соседями в кольце.