Контроль потока служебной информации (легко регулируется периодичность запросов);

5.    Контроль потока служебной информации (легко регулируется периодичность запросов);

6.    Простота сбора данных.

В каждом запросе указывается объект определенной иерархии и запрашиваемая метрика:

·     вид ресурсов;

·     уровень иерархии;

·     номер объекта на данном уровне иерархии;

·     код запрашиваемой метрики для данного объекта.

Структура получаемой информации однозначно определяется типом объектов указанных в запросе.

Возможно получение информации сразу по всем объектам и/или всем метрикам – при указании специальных значений последних двух  полей. В данном случае в ответ на запрос возвращается массив однотипных структур.

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

Таким образом, диспетчер поддерживает рабочий профиль параллельной программы. Общий вид структуры информации представляет собой двумерную матрицу. Одна размерность состоит из наименований однотипных объектов, другая – из наименований метрик, измеряемых для данных объектов. В качестве объектов используются процессоры, задачи и каналы. Таким образом, имеется три матрицы текущих параметров параллельной программы. Также, имеются вектора средних и общих параметров.

Для процессора вычисляются, например, следующие параметры: загруженность, количество памяти, время простоя и др.

Для задач вычисляются общее время вычисления, время обмена данными и др.

Для каналов: счетчики входов в процедуры обмена send/recv, объем переданных/принятых данных, среднее время нахождения в режиме приема/передачи и др.

5. Контроль производительности.

В данном разделе описываются идейные соображения для построения системы, анализирующей производительность параллельных программ в реальном времени.

Накопленная диспетчером информация – рабочий профиль – может использоваться для анализа выполнения параллельной программы. Далее описан примерный сценарий анализа.

Пусть задан вопрос: работает ли программа эффективно.

Гипотеза H₀: программа работает эффективно.

Гипотеза H₁: программа работает неэффективно.

Проверку гипотез производим из следующих соображений. Выделим основные типы неэффективной работы параллельной программы, один из них:

·     большая доля времени простоя задач от общего времени работы.

Упрощенно это выражается следующим выражением:

Можно взять критерий: E_п < 0,8.

Итак, если время простоя занимает более 20 процентов общего времени работы программы, то есть основания считать работу программы неэффективной.

Подтвердив данную гипотезу – первого уровня, – переходим к анализу гипотез второго уровня. Предположим, в программе имеется «узкое место» в плане обмена данных. Рассмотрим участок графа потоков данных программы, показанный на рисунке.

Взаимодействуют две задачи через канал. Задача T₁ генерирует данные, они передаются по каналу, являющемуся выходным для T₁, а задача T₂ принимает их на свой входной порт и обрабатывает.

Существует два типа «узких мест»:

1.    T₂ не успевает обрабатывать входные данные, T₁ находится в состоянии ожидания обработки выходных данных. При этом наблюдается:

a)    загруженность T₂ высока (> 90 %), загруженность T₁ низка (< 50%),

b)    количество сгенерированных L₁ и обработанных L₂ данных находятся в отношении L₁ – L₂ > d > 0,

c)    длина очереди данных входного канала для T₂ велика.

2.    T₁ генерирует мало данных, T₂ находится в состоянии ожидания входных данных. При этом наблюдается:

a)    загруженность T₁ высока (> 90 %), загруженность T₂ низка (< 50%),

b)    длина очереди данных входного канала для T₂ мала.

В данном случае можно выдвинуть две соответствующие гипотезы. Их проверку можно осуществить из следующих соображений.

Рассмотрим метрику канала связи процессоров – среднее время обмена. Для первой задачи это функция send, для второй – recv.

Пусть процесс изменения этих метрик во времени выглядят примерно так, как показано на рисунке.

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

Если имеет место вторая причина, то все наоборот.

Для подтверждения тех или иных гипотез можно применить методы анализа случайных процессов.

Заключение

Описанная система параллельного программирования является основой для создания программ визуализации, анализа производительности, оптимального начального распределения задач, динамической оптимизации выполнения параллельных программ.

Программы визуализации и анализа производительности могут использоваться для изучения параллельных алгоритмов, как таковых.

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

Преимущество данной системы состоит в том, что она не требует применения мощных компьютерных систем, вместо этого она полноценно использует ресурсы любых локальных сетей на базе ОС Windows 95.

Литература:

1.    Сервер ВЦ РАН http://www.ccas.ru/paral/

2.    Ian Foster, “Designing and Building Parallel Programs”, 1995

3.    Barton P. Miller and others, “The Paradyn Parallel Performance Measurement Tools” Computer Sciences Department, University of Wisconsin-Madison. http://www.cs.wisc.edu/paradyn/

4.    Бертекас, Галлагер, “Сети передачи данных”, 1989.