Параллельные вычисления в ИММ УрО РАН
| |
Параллельные вычисления в ИММ УрО РАН
|
ТЕХНОЛОГИЯ ОТЛАДКИ ПРОГРАММ ДЛЯ МАШИН С МАССОВЫМ ПАРАЛЛЕЛИЗМОМ(ИММ УрО РАН) Один из путей решения проблем отладки параллельных программ -- чёткое осознание роли моделей в отладке и распределение отладочных действий по нескольким уровням. В работе вводится понятие поэтапной отладки и описывается начальная реализация системы, поддерживающей технологию такой отладки.
ВведениеЭффективный перевод задачи с языка предметной области на язык ЭВМ -- цель любой технологии программирования. При этом наиболее трудоемким этапом был и остается этап отладки программ. Ситуация усложняется тем, что реализация средств отладки на параллельных ЭВМ существенно затруднена. Исследование путей разрешения этой проблемы для машин с массовым параллелизмом привело к выработке трехуровневого подхода к отладке параллельных программ: на уровне модели программы, на уровне псевдопараллельного исполнения алгоритмического языка и на реальной машине. Элементы выделения модели задачи как особой сущности присутствуют во многих системах, однако, в данной работе сделан уклон в сторону упрощения модели за счет ограничения сферы ее применения. В качестве основной тенденции развития возможностей отладочных средств авторы выделяют интеллектуализацию средств анализа состояния задачи. Основным методом реализации отладки является режим моделирования.
Тенденции развития отладочных средствОсновные потребности пользователя при отладке последовательных программ можно сконцентрировать в лозунге "Пошел -- остановился -- посмотрел". При этом самое сложное -- объяснить отладочной системе какая именно ситуация нас интересует, как до нее добраться и при каком условии остановиться. Поэтому разработчики всех отладочных систем озадачены тем, как лучше дать программисту возможность остановиться в желаемом ему месте (контрольной точке) для последующего изучения сложившейся ситуации. Отладка параллельных программ, сохраняя базовые принципы последовательной отладки, обладает определенной спецификой. В качестве основных специфических моментов можно выделить:
Учет данных особенностей при реализации отладочных средств для параллельных программ приводит к размыванию понятия контрольной точки (КТ) и к усилению роли аналитической составляющей в процессе анализа возникшей ситуации. Рассмотрим эти тенденции более подробно. Абстрагируясь от специфики, которую накладывает та или иная отладочная система, основные возможности отладочных средств можно разделить на четыре группы:
Можно выделить два принципиально различных подхода к реализации гибкого аппарата КТ. Первый -- все КТ одинаковы, а условия срабатывания КТ выражаются в виде обычных операторов типа "Если - то" в блоке реакции на данную КТ [7]. Второй -- введение понятия типа КТ, т.е. статическое описание условия срабатывания КТ [4]. Типизация КТ является на наш взгляд более перспективной, особенно, с учетом перспективы усложнения КТ для обеспечения параллельной отладки. Первым шагом такого усложнения видится введение понятий общей КТ для нескольких процессов, событийной КТ и "путевой" КТ, что обеспечит согласованное состояние нескольких исследуемых процессов, отладку и анализ межпроцессорного взаимодействия и повторяемость ситуаций соответственно. Анализируя развитие второй группы возможностей, можно сказать, что они интенсивно развиваются и начинают определять облик отладочной системы, потеснив первую группу. Действительно, исследование и модификация состояния задачи в условиях множественности потоков данных и управления, недетерминизма в поведения программы, наличия узких мест тупиков и т.п., становится для программиста архитрудной задачей. Единственным выходом в данной ситуации кажется повышении уровня аналитической поддержки. В качестве примера такой поддержки можно привести разнообразные средства визуального отображения информационно-событийных потоков [1, Лекция IX], [8], или переход к анализу программы на более высоком уровне, например, на уровне модели задачи [5].
Выбор уровня представления программы. Поэтапная детализация алгоритма.Упрощение разработки и отладки программ давно стоит в центре внимания системного программирования. Основной путь преодоления трудностей при разработке параллельных (и не только параллельных) программ -- отказ от лишних деталей и разработка каркаса или модели программы с последующим уточнением деталей. Вопрос лишь в том, что является лишним и на каком уровне абстракции следует остановиться. В качестве моделей программы можно использовать их представление в виде сетей Петри, HIPO-диаграмм, схем Несси-Шнейдермана, диагамм потоков данных, диаграмм Буча или обычных блок-схем. Универсальные модели являются нужным и полезным инструментом, однако, учет специфики параллельного выполнения программы может дать хороший эффект. Так как наибольший интерес авторов статьи лежит в области масс-параллельных машин, ориентация на обмен посредством сообщений явилась первым введенным ограничителем. Дальнейший анализ программно-аппаратной ситуации в проекте МВС-100 [10], а также класса задач, позволил ограничится статической заданностью процессов и использованием для связи процессов синхронных однонаправленных каналов. Следующим шагом на пути разработки методики поэтапной детализации алгоритма была попытка выделения параллельной и счетной составляющей алгоритма. Разработка программы начинается с описания и отладки параллельной составляющей алгоритма (Т-модель). На этом этапе основное внимание уделяется проблемам производительности программ, загрузки и синхронизации процессов. Далее на основе модели задачи генерируется программа на целевом алгоритмическом языке и программист переходит к разработке вычислительной составляющей программы. Рассмотрим более подробно назначение и взаимосвязь основных понятий Т-модели. Т-модель -- это алгоритмическая модель задачи, отражающая структуру, дисциплину и объем информационных потоков. В процессе создания и работы с Т-моделью программист преследует следующие цели:
В основе понятия Т-модель лежит CSP Хоара [9]. Т-модель программы состоит из процессов, которые взаимодействуют через синхронные однонаправленные каналы. Процесс предполагается строго последовательным и состоит из операторов работы, обмена и управляющих операторов. Оператор РАБОТА служит модельным отражением загрузки процессора данным процессом. Чтобы выполниться, оператору работа необходимо определенное число тактов модельного процессора. Это число может быть фиксированным, либо случайным (с заданным распределением). Для модельного задания многочисленных видов межпроцессого взаимодействия, существующих в реальных параллельных программах, были выделены следующие типы обменов: по всем каналам из заданного списка, по одному каналу из списка, по всем готовым каналам в списке. Размер передачи по каналу также может быть случайным либо фиксированным. Взаимодействие процесса по зависящим от контекста каналам описывается с помощью шаблонов имен каналов. Принцип работы шаблонов основан на статической либо динамической замене шаблона сопоставившимися с ним именами каналов. В Т-языке присутствуют следующие управляющие операторы: безусловный переход, ветвление и итератор. Итератор может выполнять свое тело бесконечное число раз, заданное число раз либо с заданной вероятностью окончания.
Технология поэтапной отладкиОдин из путей решения проблем отладки параллельных программ -- четкое осознание роли моделей в отладке и распределение отладочных действий по нескольким уровням. Можно выделить следующие уровни отладки:
Крайне важным представляется управление информационными потоками между уровнями и обеспечение обратной связи между ними. Отладка модели позволяет разрабатывать структуру программы, оценивать ее влияние на эффективность и устойчивость без ненужных на этом этапе подробностей. Отладка в режиме псевдопараллельного исполнения обеспечивает устранение ошибок, привнесенных при переходе от модели программы к реальной программе. На этом этапе активно используются развитые средства отладки, существующие на PC. Технологически процесс отладки выглядит одинаково на всех уровнях: установка КТ для попадания в нужную ситуацию и затем исследование состояния задачи. Разница заключается лишь в уровне детализации. Если при отладке на уровне Т-модели нас интересует в основном только поведение программы на макропараллельном уровне: информационные потоки, загрузка процессоров, задержки при обменах информаций, тупики и т.д., то на алгоритмическом языке большее внимание уделяется вычислительной составляющей: правильности вычислений, вызовам процедур, обмену параметрами, а также более детальной проработке параллельной составляющей и уточнению параметров Т-модели. Таким образом, существует не только прямая связь Т-модель -- Реальная программа (РП), но и обратная, что позволяет сохранять и улучшать соответствие результатов моделирования на макро- и микроуровнях. В качестве информационного объекта обратной связи используется также трасса, получаемая при моделировании или реальном исполнении РП. Средства работы с трассой можно разделить на две группы. Системы первой группы обеспечивают представление работы программы в наглядном виде, с использованием различных видов мультимедиа, при этом бремя принятия решений о причинах ошибок и путях их устранения целиком ложится на программиста. Системы второй группы ориентированы на выработку советов и рекомендаций программисту. Наибольшее применение сейчас находят средства первой группы. По нашему мнению, основной путь их развития -- анализ трассы на основе понятия модели программы. Основные средства анализа состояний задачи при отладке на уровне Т-модели построены на принципе сбора, накопления и статистической обработки. Результаты обработки представляются в виде различных таблиц, диаграмм, карт состояний и т.д. Отладка на уровне РП предполагает, кроме того, использование стандартных средств последовательной отладки, например, среды отладки TurboC.
Система Т-Модель -- среда многоуровневой отладкиПомимо модели программы, другая важная составляющая процесса моделирования -- определение среды выполнения (СВ) алгоритмической модели программы. Под СВ понимается сочетание идеализированной параллельной ЭВМ и базовых операционных средств на ней. Можно выделить два основных подхода к СВ: конкретизация СВ вместе с разработкой модели программы, либо разработка в расчете на некоторую идеализированную СВ. Первый подход (его примером может служить [6]) дает пользователю возможность довольно точно настраиваться на конкретные программно-аппаратные конфигурации. Однако контроль за переносимостью при этом утрачивается. Следование второму подходу предполагает, что получившаяся программа на императивном языке потребует существенной run-time поддержки, либо приводит к обеднению языка. При разработке системы Т-модель был выбран компромиссный подход. Он заключается в разделении СВ на два компонента: конфигурируемую пользователем модельную машину и зафиксированные базовые алгоритмы межпроцессного взаимодействия. Пользователь может менять следующие параметры модельной машины:
В основе реализации системы Т-модель лежит принцип тотального моделирования. Действительно, аппаратная база современных супер-ЭВМ в первую очередь ориентирована на достижение максимальной производительности, а не на удобство отладки. В этих условиях резко возрастает роль аппаратных и программных эмуляторов. Однако из соображений эффективности приходится отказаться от традиционной покомандной эмуляции и эмулировать ЭВМ на макроуровне. В рамках системы Т-модель такой подход реализуется компонентой Т-монитор. Т-монитор используется для двух целей. Во-первых, в нем выполняются программы на Т-языке. Во-вторых, Т-монитор позволяет запускать и отлаживать на стандартной PC реальные параллельные задачи [2], эти его возможности будут более подробно рассмотрены в следующем пункте. Кратко перечислим другие компонеты системы. Анализатор трассы позволяет изменять модель программы по результатам прогона программы на реальной ЭВМ. Т-генератор -- это визуальная оболочка базового Т-языка. Т-конвертор делает возможным получать из программы на базовом Т-языке программу на алгоритмическом языке для конкретной параллельной системы. Визуализатор трассы отображает трассу, полученную в результате работы Т-монитора, либо после запуска на реальной машине. В настоящее время T-монитор и Визуализатор трассы находятся в опытной эксплуатации, T-генератор и T-конвертор -- в стадии работающего прототипа, а Анализатор трассы -- в стадии разработки.
Принципы работы с Т-Монитором.Т-Монитор поддерживает разработку программ для МВС-100, работающей под управлением ОС-100 [3] на С и Фортране в следующих системах программирования: TurboC 2.0, BorlandC 3.1 и 4.5, WatcomC 9.5, DJGPP 2.5.7, MicosoftC 6.0, WatcomFortran 9.5 под DOS, и GNU C 2.5.8 под UNIX'ом. Каждая из них обладает своими достоинствами, и у пользователя есть возможность выбрать наиболее полно отвечающее его целям средство. При использовании реального режима DOS доступная пользователю память ограничена 640К; для других сред столь жесткого ограничения нет. Пользователю предоставляется возможность, находясь в привычной среде разработки на PC, писать параллельную программу для МВС-100. Основные отличия от "безмониторного" программирования вызваны тем, что все параллельные процессы выполняются на PC как одна программа. Практически это означает, что пользователю необходимо написать инициализацию, которая содержит описание расположения процессов по процессорам и параметров моделирования. Использование Т-монитора может повлиять на формы проявления хитрых ошибок, связанных с записью в память другого процесса. Это вызвано тем, что память на PC общая и моделируемые процессы друг от друга никак не изолированы. Пользователю предлагается методика, позволяющая разделять пространство имен. Ведутся работы по автоматизации этой процедуры. Кроме просто моделирования МВС-100, Т-Монитор позволяет обнаруживать некоторые явные ошибки в программах пользователя (несоответствие длин при обменах, некоторые виды тупиков и пр.) и обеспечивает дополнительные отладочные возможности, например, получение информации о текущем состоянии всех процессов и позволяет более точно управлять режимами моделирования. Не смотря на то, что моделируются лишь логика межпроцессного взаимодействия, Т-монитор оказался вполне применим в практике параллельного программирования. Особенно уместны такие средства для начинающих параллельных программистов и на ранних стадиях отладки параллельных программ.
ЗаключениеИспользование многоуровневой системы отладки позволяет исправлять ошибки в программе на более ранних стадиях и способствует более качественной проработке алгоритма. Работа с моделью задачи дает возможность не только исследовать поведение программы на верхнем уровне, но и использовать эту модель для обучения основным понятиям параллельного программирования. В будущем планируется расширение понятия КТ на основе введения иерархически организованных совокупностей КТ (доменов КТ) и дальнейшее исследование влияния трассы на модель. Кроме того, базовый Т-язык позволяет создавать и использовать настраиваемые шаблоны таких схем вычислений, как ферма и конвейер. Необходимо дать пользователю средство управлять этой возможностью на мета-уровне. Авторы выражают благодарность С.В. Шарфу за неоднократные плодотворные дискуссии. Работа выполнена при финансовой поддержке МНТЦ (проект 068-94).
Bibliography
|
