бесплатные рефераты

Анализ эффективности MPI-программ

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

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

4.2 Методика отладки эффективности

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

В системе DVM были реализованы соответствующие средства, которые позволяют представить выполнение программы в виде иерархии интервалов [подробнее - 6].

Интервалы:

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

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

4.3 Рекомендации по анализу

При разработке параллельной программы пользователь, как правило, преследует одну из двух возможных целей - обеспечить решение задачи в приемлемые сроки, либо создать программу, способную эффективно решать на различных параллельных ЭВМ задачи определенного класса.

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

Важно помнить, что: во-первых, потерянное время (как и коэффициент эффективности распараллеливания) вычисляется, опираясь не на реальное время выполнения программы на одном процессоре, а на прогнозируемое время. Этот прогноз может отличаться от реального времени и в ту, и в другую сторону.

Реальное время может быть больше прогнозируемого из-за того, что при выполнении программы на одном процессоре одни и те же вычисления могут осуществляться медленнее, чем при выполнении на нескольких процессорах. Это объясняется тем, что при изменении объема используемых при вычислениях данных меняется скорость доступа к ним через кэш-память. Поскольку производительность современных процессоров сильно зависит от эффективности использования кэш-памяти, то реальное время может заметно превысить прогнозируемое.

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

В результате влияния эффективности использования кэш-памяти и системных накладных расходов при выполнении программы на разных конфигурациях параллельной ЭВМ будут выдаваться различные значения полезного времени. Поэтому, если есть возможность выполнить программу на одном процессоре (а она может требовать гораздо больше оперативной памяти, чем имеется на одном процессоре), то желательно это сделать для получения представления об отличиях прогнозируемых времен от реального времени.

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

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

· Трансформация программы в программу на стандартных языках Фортран 77 или Си может привести к различиям в оптимизации программ стандартными компиляторами. В результате, параллельная программа может выполняться либо медленнее, либо быстрее. Особенности оптимизации программ современными компиляторами существенно (десятки и сотни процентов) определяют эффективность их выполнения.

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

Поэтому, если есть возможность выполнить программу как обычную последовательную программу на одном процессоре (если это нельзя сделать на параллельной ЭВМ, то может быть это окажется возможным на рабочей станции), то желательно это сделать.

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

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

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

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

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

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

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

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

5. Средство анализа эффективности MPI программ

5.1 Постановка задачи

В системе DVM существуют развитые средства анализа эффективности выполнения параллельной DVM-программы. Эти средства являются более мощными, чем те, которые существуют для MPI-программ, поскольку многие важные характеристики выполнения MPI-программ (например, соотношение параллельных и последовательных вычислений) невозможно определить из-за отсутствия необходимой информации. Кроме того, в настоящее время при разработке MPI-программ у нас в стране практически не используются инструментальные средства отладки эффективности. Это вызвано следующими основными факторами: - разные средства требуют от пользователя знания их собственного интерфейса (отсутствие фактического стандарта); - отсутствием вообще каких-либо инструментальных средств анализа эффективности на многих параллельных ЭВМ.

Поэтому важно создать такие средства для получения характеристик эффективности MPI-программ, которые могли бы быть доступны пользователям на любых многопроцессорных ЭВМ.

Целью данной дипломной работы является создание экспериментальной системы отладки эффективности MPI-программ.

Входными данными для нее будут трассы, создаваемые DVM-системой для функциональной отладки MPI-программ. В этих трассах отражены обращения к MPI-функциям и времена их работы. Для получения характеристик, аналогичных тем, которые выдаются для DVM-программ, от программиста потребуется дополнительная информация о том, какие вычисления являются параллельными, а какие последовательными (дублированными на каждом процессоре). Эти указания должны быть оформлены таким образом, что их наличие в MPI-программе не мешало ее правильному и эффективному выполнению на тех ЭВМ, где отсутствует данная система отладки эффективности MPI-программ. Таким же образом должны оформляться и средства описания тех интервалов выполнения программы, для которых требуется отдельно собирать все характеристики эффективности.

Этапы работы анализатора.

В работе анализатора можно выделить следующие этапы.

Этап 1

Обработка трасс со всех процессоров и вычисление для каждого интервала и каждого процессора следующих характеристик:

Основные характеристики и их компоненты

Коэффициент эффективности (Parallelization efficiency) равен отношению полезного времени к общему времени использования процессоров.

Время выполнения (Execution time).

Число используемых процессоров (Processors).

Общее время использования процессоров (Total time) - произведение времени выполнения (Execution time) на число используемых процессоров (Processors).

Полезное время (Productive time) - прогнозируемое время выполнения на одном процессоре

Потерянное время (Lost time).

Коммуникации (Communication) и все компоненты.

Простои (Idle time).

Разбалансировка (Load_Imbalance).

Потенциальные потери из-за синхронизации (Synchronization) и все компоненты.

Потенциальные потери из-за разброса времен (Time_variation) и все компоненты.

Характеристики выполнения программы на каждом процессоре

Потерянное время (Lost time) - сумма его составляющих - потерь из-за недостаточного параллелизма (User insufficient_par), системных потерь из-за недостаточного параллелизма (Sys insufficient_par), коммуникаций (Communication) и простоев (Idle time).

Простои на данном процессоре (Idle time) - разность между максимальным временем выполнения интервала (на каком-то процессоре) и временем его выполнения на данном процессоре.

Общее время коммуникаций (Communication).

Реальные потери из-за рассинхронизации (Real synchronization).

Потенциальные потери из-за разброса времен (Variation).

Разбалансировка (Load_imbalance) вычисляется как разность между максимальным процессорным временем (CPU+MPI) и соответствующим временем на данном процессоре.

Время выполнения интервала (Execution_time).

Полезное процессорное время (User CPU_time).

Полезное системное время (MPI time).

Число используемых процессоров для данного интервала (Processors).

Времена коммуникаций для всех типов коллективных операций

Реальные потери из-за рассинхронизации для всех типов коллективных операций.

Потенциальные потери из-за рассинхронизации для всех типов коллективных операций.

Потенциальные потери из-за разброса времен для всех типов коллективных операций.

Этап 2

Подготовка текстового представления вычисленных характеристик. Такое представление упрощает первоначальный анализ характеристик при запуске параллельной программы на удаленной ЭВМ.

Этап 3

Визуализация результатов анализа эффективности.

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

5.3 Устройство анализатора

Итак, анализатор состоит из трех основных компонент.

Первая - сбор информации по трассе. Вторая - анализ собранных данных. Третья - визуализация.

5.3.1 Сбор трассы

При каждом запуске параллельной программы в режиме трассировки, создается группа файлов с информацией обо всех ключевых событиях в трассе. Тут есть времена и параметры всех событий, которые имели место при выполнении программы. К этим данным есть возможность доступа через специальные функции интерфейса. Также можно получить информацию для разного рода вспомогательных таблиц (имена используемых функций, исходных файлов и т.п.).

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

5.3.2 Анализ
В соответствии с описанной в пункте 4.2 методикой, вся программа будет разбита на систему интервалов, точнее дерево интервалов. Корнем дерева будет вся программа, она считается интервалом нулевого уровня.
Далее в соответствии с вложенностью интервалы первого уровня и т.д.
Как указать границы интервалов?
Для этого используются пара функций MPI_Send() и MPI_Recv() для указания начала интервала, и такая же пара для указания его окончания. При этом посылка и прием сообщения происходят самому себе и от самого себя (имеется ввиду, что в качестве номера отправителя/получателя используется номер самого процесса). Кроме того, тэг сообщения имеет следующий вид:
TAG = 0x(aa)(id)(aa/bb).
Тэг является четырехбайтным целым числом. Первый байт у «нашего» тэга - это 0xaa. Это позволяет отличить его от обычных посылок/приемов сообщений. Последний байт может быть 0xaa - символизирует начало интервала, 0xbb - конец интервала. Внутри специальный идентификатор интервала (2 байта), его можно использовать, например, для того, чтобы отдельно выделить итерации цикла.
Такой способ выделения был выбран потому, что:
· он всегда попадает в трассировку (некоторые специальные функции вроде MPI_Pcontrol() в текущей версии трассировщика не попадают).
· занимает относительно немного времени (порядка 100 тиков процессора).
· прост в использовании и не требует дополнительных средств, помимо стандартных MPI-функций.
Таким образом, программист может добавить в свой код границы интересующих его областей программы (в нашей терминологии интервалы).
Далее по этим тэгам среди всех событий будут найдены те, которые являются границами интервалов и будут определены их идентификаторы.
Для этого вводится специальный класс:
class Margin
{
public:
Margin(bool ,unsigned long ,int ,unsigned int ,int);
friend bool operator <( const Margin& s1, const Margin& s2)
bool enter_leave;
unsigned long time;
int identity;
unsigned int proc;
unsigned int scl;
};
И функция:
vector<Margin>* createMargins(void);
которая и вычисляет=> определяет необходимые границы вместе со всеми параметрами.
После определения границ, создается структура дерево, в которой хранятся все данные обо всех интервалах.
Кратко об используемых структурах данных.
Создан специальный класс tree:
class tree
{
public:
static int Intervallevel; // current interval level
static int IntervalID; // current interval ID
long index;
int level; // Interval level
int EXE_count;
int source_line;
string source_file;
int ID;
//Characteristics for every interval
unsigned long Exec_time;
unsigned long Productive_time;
double Efficiency;
unsigned long CPU_time;
unsigned long MPI_time;
unsigned long Lost_time;
unsigned long Comm_time;
unsigned long SendRecv_time;
unsigned long CollectiveAll_time;
unsigned long Idle_time;
unsigned long AllToAll_time;
unsigned long Time_variation;
unsigned long Potent_sync;
unsigned long T_start;
vector < pair<unsigned long,unsigned int> >* cmp_pairs;
//for intelval's tree
tree* parent_interval;
int count;
vector<tree *> nested_intervals;
vector<Processors> Procs;
};
Этот класс содержит информацию обо всех характеристиках данного интервала, описанных в 5.2. Кроме того, в нем есть информация о родительском узле дерева, а также обо всех «листьях-потомках».
В этом классе в качестве вспомогательного используется класс Processors.
class Processors
{
public:
unsigned long enter_time;
unsigned long leave_time;
unsigned int number;
unsigned long MPI_time;
unsigned long SendRecv_time;
unsigned long CollectiveAll_time;
unsigned long Idle_time;
unsigned long AllToAll_time;
unsigned long CPU_time;
unsigned long Comm_time;
unsigned long Time_variation;
unsigned long Potent_sync;
unsigned long T_start;
};
В этом классе содержатся элементарные составляющие всех компонентов, собранные на каждом интервале каждого процессора.
Далее, после определения границ интервалов, происходит создание дерева интервалов. В этом дереве и будет храниться информация обо всех интервалах.
Класс tree включает методы, которые и собирают информацию из структур, собранных на трассе.
Первая группа характеристик собирается в функции

Leave(int line, char* file, long index,unsigned int proc,unsigned long time).

· MPI_time Используем - getMPITimebyProc();

· SendRecv_time - getSendRecvCommunicationTimebyProc();

· CollectiveAll_time - getCollectiveAllByProc();

· AllToAll_time - getAllToAllByProc();

· Potent_sync - getPotentSyncByProc();

· Time_variation - getTimeVariationByProc();

· T_start - getNonBlockedTimebyProc();

Вычисление характеристик.

getMPITimebyProc() - Происходит суммирование интервалов времени, занятых под MPI-функции (интервалы получаются как разность между временем выхода и входа в MPI-функцию).

getSendRecvCommunicationTimebyProc( )- Происходит суммирование интервалов времени, вычисляемых как разность времени выхода из функции приема сообщения и времени входа в функцию посылки сообщения.

getPotentSyncByProc() - Вычисляется по-разному для операций одиночных посылок/приемов сообщений и коллективных операций. Сюда входят все случаи, когда Recv был выдан раньше Send'а. Эти «задержки» как раз и суммируются. Для коллективных же операций суммируется время «задержки» старта операции на некоторых процессорах.

getTimeVariationByProc() - Вычисляется время, рассинхронизации окончания коллективной операции.

getNonBlockedTimebyProc() - Вычисляется аналогично getMPITimebyProc(), только суммируются времена работы только не блокирующих операций.

Все эти характеристики собираются на каждом процессоре для данного интервала. Прототип всех функций одинаков:

getFunction(unsigned long enter_time, unsigned long leave_time, unsigned int proc).

Собранные «элементарные» характеристики, затем собираются в более общие по всему интервалу.

Первая используемая для этого функция - это функция Integrate().

В этой функции собираются следующие характеристики:

· CPU_time

· MPI_time

· SendRecv_time

· CollectiveAll_time

· AllToAll_time

· Comm_time(Общее время коммуникаций)

· Idle_time(время бездействия)

· Potent_sync

· Time_variation

· T_start

Все они уже являются характеристиками всего интервала.

Далее происходит вычисление уже не общих, а сравнительных характеристик. Зная все эти компоненты на каждом процессоре для интервала, мы находим процессоры с максимальным, минимальным значением по времени, а также среднее значения всех характеристик.

После функции Integrate() вычисляется полезное время calculateProductive(), потом время запуска - calculateExecution(),

эффективность распараллеливания - efficiency(), и, наконец, потерянное время - calculateLost().

На этом сбор и анализ информации оканчиваются. Следующий этап, это генерация соответствующих текстовых выдач. Эти выдачи представляют собой текстовый файл и имеют следующий вид (Пример).

Пример. Текстовый файл с итоговыми характеристиками.

Interval (LineNumber = 153 SourceFile = exch.c) Level=0 EXE_Count=1

---Main Characteristics---

Parallelization Efficiency 0.978833

Execution Time 2.079975

Processors 4

Total Time 8.319900

Productive Time 8.143794 (CPU MPI)

MPI время на одном процессоре считается полезным, а на остальных - потерянным

Lost Time 0.176106

---MPI Time 0.173490

---Idle Time 0.002616

Communication Time 0.076563

*****SendRecv Time 0.013295

*****CollectiveAll Time 0.063268

*****AllToAll Time 0.000000

Potential Sync. 0.068763

Time Variation 0.001790

Time of Start 0.000000

---Comparative Characteristics---

Tmin Nproc Tmax Nproc Tmid

Lost Time 0.033087 3 0.060057 0 0.044026

Idle Time 0.000000 1 0.000898 0 0.000654

Comm. Time 0.006597 3 0.034854 0 0.019140

MPI Time 0.032259 3 0.059159 0 0.043372

Potential Sync. 0.001800 0 0.029369 3 0.017190

Time variation 0.000161 1 0.000607 3 0.000447

Time of Start 0.000000 0 0.000000 0 0.000000

Для каждого интервала выдается следующая информация:

· имя файла с исходным текстом MPI-программы и номер первого оператора интервала в нем (SourceFile, LineNumber);

· номер уровня вложенности (Level);

· количество входов (и выходов) в интервал (EXE_Count);

· основные характеристики выполнения и их компоненты (Main characteristics);

· минимальные, максимальные и средние значения характеристик выполнения программы на каждом процессоре (Comparative characteristics);

При выдаче характеристик их компоненты располагаются в той же строке (справа в скобках), либо в следующей строке (справа от символов “*” или “-“).

Информация о минимальных, максимальных и средних значениях характеристик оформлена в таблицу. Также есть информация обо всех характеристиках на каждом процессоре.

5.3.3 Визуализация
Следующим этапом после того, как все необходимые характеристики собраны, является этап визуализации.
Этот этап необходим, так как хотя текстовый файл содержит всю необходимую информацию, при большом числе интервалов пользоваться им не очень удобно. Кажется целесообразным, что, так как интервалы “отображались” логически в виде дерева, то и визуализировать их нужно в виде дерева. Было выбрана форма отображения, аналогичная древовидной организации файловой структуры данных на дисках. Соответственно, каждый интервал доступен из своего родителя, интервалы нижних уровней отображаются правее. Также при нажатии на интервал, в текстовое поле
выводится информация обо всех характеристиках именно этого интервала.
Это значительно облегчает поиск необходимой для анализа области.
Рис.6. Окно программы анализа.
Также полезным для представления общей картины запуска является упорядоченный по времени список событий. При этом используется так называемый (TimeLine), все события отображаются на линии определенным цветом в соответствии со временем, когда они произошли. Это позволяет отслеживать не просто нужную область, а точно интересующее событие.
Используя механизм Tooltip'ов, пользователь получает возможность узнать тип события (пользовательский (UserCode) или MPI) и название функции (для MPI - функций).
Рис.7. TimeLine
Узнать это можно по цвету линии с событием. Список цветов описан в Приложении 2.

Заключение

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

Приблизительный объем программы на С++ в строках кода = 6500 строк.

Программа оттестирована на тестах, поставляемых с MPI - реализациями, а также с тестами NAS (NPB2.3), с добавлением описанных выше директив для границ интервала.

В процессе дипломной работы были:

ь Проанализированы современные средства анализа параллельных программ.

ь Изучены алгоритмы анализа и сбора характеристик.

ь Реализовано программное средство со следующими возможностями:

1. Отображение выполнения программы в виде дерева интервалов

2. Сбор и отображение характеристик выбранного интервала.

3. Выдача общей информации обо всех интервалах в текстовый файл.

4. Показ time-line.

Выводы:

· Отладка эффективности параллельных программ - процесс очень сложный и трудоемкий

· Развитые средства анализа эффективности могут существенно ускорить этот процесс.

· Необходима грамотная - наглядная визуализация результатов.

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

· Необходимо учитывать различные эффекты, связанные с нестабильностью поведения параллельных программ.

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

Приложение 1

Структура программы.

14

Модуль main - вызов процедур сбора информации, анализа и генерации результата. Compute - вычисление все необходимых характеристик трассы. Для этого используется модуль tree, который отвечает за формирование дерева с данными об искомых характеристиках. Модуль determine позволяет находить и выделять интервалы в исходном коде и в трассе программы. Модуль visual занимается графическим отображением полученных данных и состоит и timeline - события в трассе, и characteristics - дерево интервалов с отображаемыми характеристиками.

Приложение 2

Используемые цвета на TimeLine:

1. Коллективные операции:

MPI_Barrier, MPI_Bcast, MPI_Gather, MPI_Gatherv, MPI_Scatter, MPI_Scatterv, MPI_Allgather, MPI_Allgatherv, MPI_Alltoall, MPI_Alltoallv, MPI_Reduce, MPI_Allreduce, MPI_Reduce_scatter, MPI_Scan

черный

2. Операции посылки

MPI_Send, MPI_Bsend, MPI_Ssend, MPI_Rsend

тёмно-зелёный

3. Неблокирующие операции посылки

MPI_Isend, MPI_Ibsend, MPI_Issend, MPI_Irsend

светло-зелёный

4. Операции получения/ожидания/посылки-получения с блокировкой MPI_Recv, MPI_Wait, MPI_Waitany, MPI_Waitall, MPI_Waitsome, MPI_Probe, MPI_Sendrecv, MPI_Sendrecv_replace

темно-синий

5. Операции получения/проверки без блокировки

MPI_Irecv, MPI_Test, MPI_Testany, MPI_Testall, MPI_Testsome, MPI_Iprobe голубой

6. Другие (малоиспользуемые) операции

MPI_Request_free, MPI_Cancel, MPI_Test_cancelled, MPI_Send_init, MPI_Bsend_init, MPI_Ssend_init, MPI_Rsend_init, MPI_Recv_init, MPI_Start, MPI_Startall

светло-серый

7. Пользовательский код

светло-розовый

Страницы: 1, 2


© 2010 РЕФЕРАТЫ