Реальное время может быть меньше прогнозируемого, поскольку при прогнозе учитываются не все накладные расходы на поддержку выполнения параллельной программы. Эти неучтенные расходы, например, поиск информации в системных таблицах при выполнении некоторых часто используемых функций (замерять время выполнения которых невозможно без внесения неприемлемых искажений в выполнение программы), могут значительно сократиться при уменьшении количества процессоров до одного.
В результате влияния эффективности использования кэш-памяти и системных накладных расходов при выполнении программы на разных конфигурациях параллельной ЭВМ будут выдаваться различные значения полезного времени. Поэтому, если есть возможность выполнить программу на одном процессоре (а она может требовать гораздо больше оперативной памяти, чем имеется на одном процессоре), то желательно это сделать для получения представления об отличиях прогнозируемых времен от реального времени.
Во-вторых, время выполнения параллельной DVM-программы на одном процессоре может значительно отличаться от времени ее выполнения как последовательной программы. Это может быть следствием следующих причин:
· Доступ к распределенным данным в параллельной программе отличается от доступа к ним в последовательной программе. Дополнительные накладные расходы, появляющиеся в параллельной программе, могут увеличить время ее выполнения на 10-30 процентов. Однако в параллельной программе может быть проведена такая оптимизация доступа к данным, которая для некоторых программ приведет к ускорению их выполнения по сравнению с последовательным случаем.
· Трансформация программы в программу на стандартных языках Фортран 77 или Си может привести к различиям в оптимизации программ стандартными компиляторами. В результате, параллельная программа может выполняться либо медленнее, либо быстрее. Особенности оптимизации программ современными компиляторами существенно (десятки и сотни процентов) определяют эффективность их выполнения.
· Некоторые накладные расходы на поддержку выполнения параллельной программы могут значительно замедлить ее выполнение (например, операции запроса и освобождения памяти в последовательной программе могут превратиться в параллельной программе в гораздо более сложные операции создания и уничтожения распределенного массива).
Поэтому, если есть возможность выполнить программу как обычную последовательную программу на одном процессоре (если это нельзя сделать на параллельной ЭВМ, то может быть это окажется возможным на рабочей станции), то желательно это сделать.
Все это пользователю необходимо иметь в виду, приступая к анализу потерянного времени и его компонент.
Сначала следует оценить три компоненты потерянного времени для интервала нулевого уровня (всей программы). Наиболее вероятно, что основная доля потерянного времени приходится на одну из первых двух компонент (недостаточный параллелизм или коммуникации).
В случае если причиной оказался недостаточный параллелизм, необходимо уточнить, на каких участках он обнаружен - последовательных или параллельных. В последнем случае причина может быть очень простой - неверное задание матрицы процессоров при запуске программы или неверное распределение данных и вычислений. Если же недостаточный параллелизм обнаружен на последовательных участках, то причиной этого, скорее всего, является наличие последовательного цикла, выполняющего большой объем вычислений. Устранение этой причины может потребовать больших усилий.
В том же случае, если основной причиной потерь являются коммуникации, то необходимо, прежде всего, обратить внимание на характеристику потери из-за рассинхронизации. Если ее значение близко к размерам потерь из-за коммуникаций, то необходимо рассмотреть характеристику разбалансировка, поскольку именно разбалансировка вычислений в параллельном цикле является наиболее вероятной причиной рассинхронизации и больших потерь на коммуникациях. Если величина разбалансировки намного меньше величины синхронизации, то необходимо обратить внимание на величину разброса времен коллективных операций. Если рассинхронизация не является следствием разброса времен завершения коллективных операций, то ее возможной причиной могут быть разбалансировки некоторых параллельных циклов, которые на рассматриваемом интервале выполнения программы могли взаимно компенсироваться. Поэтому имеет смысл перейти к рассмотрению характеристик разбалансировки на интервалах более низкого уровня.
Второй вероятной причиной больших потерь из-за рассинхронизации может быть рассинхронизация процессоров, которая возникает при выдаче операций ввода-вывода. Это происходит из-за того, что основная работа (обращение к функциям ввода-вывода операционной системы) производится на процессоре ввода-вывода, а остальные процессоры в это время ждут получения от него данных или информации о завершении коллективной операции. Эту причину потерь легко обнаружить, обратив внимание на соответствующую компоненту характеристики коммуникации - потери из-за коммуникаций при вводе-выводе.
Еще одной причиной больших потерь из-за коммуникаций могут оказаться задержки при запуске коллективных операций в асинхронном режиме, возникающие из-за того, что некоторые реализации 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).
Страницы: 1, 2, 3, 4, 5, 6
