Рефераты | Рефераты по информатике, программированию | Команда "шаг" в параллельных отладчиках
Команда "шаг" в параллельных отладчикахКатегория реферата: Рефераты по информатике, программированию Теги реферата: развитие россии реферат, скачать бесплатно конспекты Добавил(а) на сайт: Olimpiada. Предыдущая страница реферата | 1 2 3 4 5 6 | Следующая страница реферата |
||||
|
8 |
13 |
13 |
13 |
. |
Таблица 1. Текущие позиции для различных процессов при пошаговом выполнении MPI программы.
В данном примере за восемь шагов параллельной программы процесс с rank равным 0 сделал 7 последовательных шагов, процесс с rank равным 1 сделал 6 последовательных шагов, остальные процессы сделали 5 последовательных шагов, и пользователю не потребовалось никаких дополнительных действий для этого.
Основные отличия предложенной схемы выполнения команды "шаг" от существующих схем:
Первые три шага в параллельном отладчике с синхронной схемой команды "шаг" будут идентичны приведённым выше. Однако пользователь не дождётся завершения шага 4 в таком отладчике, поскольку процесс с rank равным 1 не сможет завершить свою часть команды. Пользователю придётся прервать выполнение команды. В результате он получит набор процессов, остановленных в разных точках программы. Он не будет знать, какой из процессов остановился самостоятельно, выполнив свой элементарный шаг, а какой был прерван пользователем.
Если в отладчике реализована асинхронная модель параллельной команды "шаг", то пользователь, после того, как выдал команду и получил управление в отладчике (сразу же после выдачи команды), не может быть уверен, что все процессы завершили выполнение своих частей общей параллельной команды "шаг". Пользователь может убе-диться в полном завершении (или незавершении) общей команды лишь исследовав статус каждого процесса вручную и проанализировав их.
Важно отметить, что в обоих рассмотренных случаях после четвёртого шага процесс с rank 1 будет находиться где-то внутри функции MPI_Recv. В тоже время отладчик уровня исходного текста языка параллельного програм-мирования должен обеспечивать отладку в терминах самого языка. Отладчик MPI-программ также должен поддерживать отладку в терминах MPI и языка последовательного программирования, из которого вызываются функции MPI. Соответственно, для него функции MPI должны являться неделимыми примитивами. Для пользователя, отлаживающего MPI-программу, получить информацию о том, что один из процессов его программы находится в какой-то внутренней функции, вызванной, например, внутри MPI_Recv также неестес-твенно, как для пользователя, отлаживающего последовательную программу на языке высокого уровня, получить информацию, что программа выполняет какую-то из ассемблерных операций. Мы считаем это существенным недостатком существующих схем параллельных команд перемещения, который устраняется в предлагаемом подходе.
Предлагаемая реализация шага параллельной программы возможна только в том случае, если отладчик понимает семантику функций MPI и имеет модель выполнения MPI-программы. Это невозможно без поддержки отладчиков со стороны MPI, так же как отладка программ на языке высокого уровня невозможна без поддержки со стороны компилятора. В настоящее время поддержка параллельных отладчиков реализациями MPI ограничивается интерфейсом, разработанным для TotalView [7], который ориентирован только на просмотр очередей сообщений и не позволяет обрабатывать "тривиальные параллельные" причины незавершения шага в MPI-программе.
Современные параллельные отладчики (например, p2d2[6]) имеют следующую клиент-серверную архитектуру:
Рис. 1
В ней сервер состоит из двух частей: нераспределенной, которая отвечает за управление параллельной программы как целым, и распределенной, которая отвечает за непосредственное управление выполнением каждого из процессов параллельной программы. Соответственно, нераспределенная часть должна поддерживать модель текущего состояния параллельной программы и, на основании информации, получаемой от распределенных частей обрабатывать "тривиальные параллельные" причины незавершения шага.
Рассмотрим, какой информации не хватает в текущем интерфейсе "MPI - отладчик" [7] на примере функции MPI_Send. С помощью этого интерфейса доступна очередь незаконченных посылок для каждого коммуникатора. Элемент этой очереди имеет тип структуры mqs_pending_operation[8] и содержит большое количество информации о посылке. Известно, что реализация MPI самостоятельно принимает решение о том буферизировать, или нет пересылаемое сообщение. В случае буферизации сообщения операция пересылки является локальной и заканчивается вне зависимости от соответс-твующего запроса на прием. В противном случае она не является локальной и не может закончиться, если не был выдан соответствующий запрос на прием. Для того, чтобы передать эту информацию компоненте отладчика, связанной с конкретным процессом, достаточно просто добавить в структуру mqs_pending_operation еще одно поле, которое говорило бы о том было ли сообщение буферизировано или нет. Построение полного интерфейса "MPI - отладчик", удовлетворяющего требованиям предлагаемого подхода, не является целью данной работы. Мы просто хотим обратить внимание на то, что он может быть получен путем незначительной доработки уже имеющегося интерфейса.
Мы реализовали предлагаемый подход в отладчике для языка параллельного программирования mpC, который описан ниже.
Язык параллельного программирования mpC был разработан в конце 90х в Институте системного программирования РАН. В языке mpC, который является расширением языка С, вводится понятие вычислительного пространства, которое определяется как некоторое доступное для управления множество виртуальных процессоров. Основным понятием mpC является понятие сетевого объекта или просто сети. Сеть является областью вычислительного пространства, которая может быть использована для вычисления выражений и выполнения операторов.
Размещение и освобождение сетевых объектов в вычислительном пространстве выполняется аналогично размещению и освобождению объектов данных в памяти. Концептуально, создание новой сети инициируется процессором уже существующей сети. Этот процессор называется родителем создаваемой сети. Родитель всегда принадлежит создаваемой сети. Единственным виртуальным процессором, определенным от начала и до конца выполнения программы, является предопределенный виртуальный хост-процессор.
Любой сетевой объект, объявленный в программе, имеет тип. Тип специфицирует число и производительности процессоров. Например, объявление
nettype SimpleNet(n) {
coord I=n;
};
вводит параметризованный сетевой тип с именем SimpleNet, соответствующий сетям, состоящим из n виртуальных процессоров. Виртуальные процессоры сети связаны с координатной переменной I, значение которой изменяется от 0 до n-1. Родитель сети имеет по умолчанию координату равную 0. Это простейшая сеть, определение которой содержится в стандартном файле mpc.h.