ЛАБОРАТОРНАЯ РАБОТА 1. МОДЕЛИРОВАНИЕ КОНВЕЙЕРНОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ. 1. Цель работы Изучение особенностей функционирования конвейерных вычислительных систем. Ознакомление с основными видами стратегии управления статическим и динамическим конвейером. Нахождение оптимальной стратегии управления. Моделирование работы конвейерной вычислительной системы. 2. Теоретический материал. Идея конвейерной обработки заключается в выделении отдельных этапов выполнения общей операции, причем каждый этап, выполнив свою работу, передавал бы результат следующему, одновременно принимая новую порцию входных данных. Получаем очевидный выигрыш в скорости обработки за счет совмещения прежде разнесенных во времени операций. I1 D1 I2 D2 ВМ1 In D3 ВМ2 R ВМn Конвейер – совокупность ступеней и средств передачи данных между ними, организованных таким образом, что на вход системы поступают исходные данные, затем они последовательно, в соответствии с разбиением базовой функции на подфункции, перемещаются между ступенями, подвергаясь на каждом этапе промежуточной обработке, в результате чего на выходе получается требуемый результат. Одновременно в конвейере может находиться более одного элемента входных данных. Для описания и анализа работы конвейера используется временная диаграмма его работы. Графическое отображение временной диаграммы следующего вида называется таблицей занятости: Время (такт) 0 1 2 . . . Ступень 1 * 2 * 3 * ... Таблицы занятости определяют, каким образом та или иная операция занимает различные ступени в зависимости от времени. 2 В процессе функционирования конвейера возможно возникновение помех. Помеха определяется структурой или применением конвейера и препятствует его работе с максимальной скоростью, которую можно было бы получить в рассматриваемом конвейере. Существуют две общие категории помех: структурные и зависящие от данных. Структурные помехи возникают, когда два различных фрагмента данных пытаются использовать одну и ту же ступень одновременно; помехи этого типа часто называют столкновениями. Существует достаточно мощный математический аппарат, который позволяет минимизировать влияние помех этого типа на быстродействие системы еще на этапе проектирования. Помехи, зависящие от данных, возникают, когда событие, происходящее на одной ступени конвейера, определяет, могут ли данные проходить через другие ступени. Простым примером является обращение с двух различных ступеней конвейера к общей памяти. Если одна ступень использует память, другая ступень должна ожидать завершения работы. Эти помехи в основном зависят от режима работы системы и в меньшей степени поддаются столь же подробному аналитическому исследованию. Однако для их устранения разработано большое число методов, преимущественно эвристических. 2.1. Временная организация и управление работой конвейера Задача управления конвейером разбивается на две подзадачи: – обеспечение входного потока данных (заполнение конвейера) – задача диспетчеризации, т.е. определение моментов времени, в которые каждый элемент входных данных должен начинать свое прохождение по конвейеру. Решение задачи диспетчеризации должно гарантировать высокую производительность и отсутствие конфликтов. Для линейного конвейера задача диспетчеризации является тривиальной. Входные величины в этом случае должны подаваться на вход конвейера по одной за каждый период синхронизации. Реальный конвейер обычно более сложен. Проблемы с диспетчеризацией возникают, когда в конвейере присутствуют одно или несколько отличий от простого линейного конвейера: – разный период времени обработки данных на разных ступенях; – обратная связь от текущей ступени к какой-либо из предыдущих; – множественные пути от текущей ступени к последующим; – подача элемента данных более чем на одну ступень одновременно (элемент распараллеливания обработки); – существование между входными элементами зависимостей, которые принуждают к определенному упорядочению связанных с ними вычислений; Все эти факторы налагают ограничения на новые запуски вычислений и делают общую производительность конвейера критически чувствительной к процедурам управления конвейером. Они так же очень затрудняют задачу оптимизации процедур диспетчеризации. Разработка этих процедур изучалась несколькими группами исследователей. В частности, Рамамурти и Ли показали, что общая задача относится к классу NP-полных задач и является труднорешаемой. Предполагается, что любая задача такого класса не имеет "быстрого" решения", время нахождения которого было бы полиномиальной функцией от числа управляемых объектов. Несмотря на трудности, присущие общему случаю, существуют подклассы конвейеров, для которых существуют оптимальные или хотя бы эвристически хорошие алгоритмы диспетчеризации. Рассмотрим один из наиболее простых. Введем следующие основные определения. 3 Таблица занятости – двумерное представление прохождения данных по конвейеру при одном вычислении функции. Время вычисления – полное число единиц времени, используемых при реализации инициации таблицы занятости, равняется числу столбцов таблицы. Инициация – запуск единичного вычисления функции. Столкновение – попытка двух различных инициаций использовать одну и ту же ступень одновременно. Статическая конфигурация конвейера – все инициации относятся к одной и той же таблице занятости. Динамическая конфигурация конвейера – инициации относятся к смеси таблиц занятости. Латентность – число единиц времени между двумя инициациями. Темп инициаций – среднее число инициаций за период синхронизации. равняется N, деленному на время запуска N инициаций.Является функцией стратегии управления. Средняя латентность – среднее число периодов синхронизаций между инициациями. Величина, обратная темпу инициаций. Использование ступеней – процент (доля) времени, в течение которого каждая ступень используется в рассматриваемой серии инициаций. Стратегия управления – процедура, которая выбирает последовательность латентностей. Жадная стратегия – стратегия управления, которая выбирает всегда минимально возможную латентность между данной и следующей инициацией без учета каких бы то ни было следующих инициаций. Минимальная достижимая латентность – наименьшая средняя латентность, достижимая при любой стратегии управления. Вектор столкновений – вектор, показывающий допустимые латентности между двумя инициациями одной и той же таблицы. Матрица столкновений – матрица, показывающая допустимые латентности между любыми двумя инициациями таблиц занятости из данного набора таблиц. Множество запрещенных латентностей – совокупность латентностей, вызывающих столкновения между двумя инициациями. Последовательность латентностей – перечень латентностей между последовательными инициациями; является результатом стратегии управления. Далее записывается в угловых скобках. Допустимая последовательность латентностей – последовательность латентностей, при которой не возникает столкновений. Правильная стратегия управления должна генерировать только допустимые последовательности. 2.2. Управление статическим конвейером Лемма. Для любого конвейера со статической конфигурацией, реализующего некоторую таблицу занятости, величина минимально достижимой латентности всегда больше или равна максимальному числу меток в любой строке этой таблицы. Это высказывание очевидно. Доказательство этой леммы осуществить самостоятельно. Описанная зависимость позволяет инженеру-проектировщику получить быструю оценку максимальной допустимой производительности для данного конвейера с данной таблицей занятости. Реально достижимая латентность может оказаться существенно отличной от минимально достижимой латентности. 4 Цель стратегии управления – определение моментов времени, в которые необходимо осуществлять новые инициации. Для стратегии диспетчеризации основной необходимой информацией является описание того, приведет ли к столкновению с прежними инициациями новая инициация, осуществляемая в некоторый момент времени. Одним из методов, позволяющих получить эту информацию, является метод построения диаграмм состояний. Каждому состоянию соответствует свой вектор столкновений. Рассмотрим процедуру определения векторов столкновений и построения диаграмм состояний. Предположим, что конвейер должен реализовать следующую таблицу занятости: 0 1 2 3 4 5 6 7 1 * * * * 2 * * 3 * * Построим для этой таблицы полную диаграмму состояний (рис. 1): 11100111 11001110 * 10011100 11111111 00111000 11111110 * 11110011 01110000 11111100 11100110 11111000 11001100 11110000 11100000 10011000 * 11000000 10000000 00000000 * Рис. 1. Полная лиаграмма состояний Диаграмма состояний строится по следующим правилам. 5 Каждый узел диаграммы соответствует такту функционирования К и содержит вектор столкновений. Каждый элемент вектора столкновений содержит данные о том, произойдет ли столкновение в конвейере, если произойдет инициация. Значение «1» говорит о том, что столкновение произойдет. Наличие «1» в крайнем левом элементе вектора столкновений говорит о том, что в текущий момент времени инициация невозможна. В этом случае к следующему такту вектор столкновений сдвигается влево, крайний левый элемент выталкивается, справа дополняется значением «0». Значение «0» в крайнем левом элементе вектора столкновений говорит о том, что инициация возможна – и она либо происходит (на диаграмме соответствующая ветвь помечается «*»), тогда вектор столкновений модифицируется, либо нет – тогда вектор продолжает сдвигаться. Для поиска оптимальных стратегий управления необходимо рассмотреть оба варианта, чтобы в диаграмме состояний присутствовали все возможные в данном К состояния и пути их достижения. Кроме того, необходимо отслеживать появление идентичных векторов столкновений, т.к. они соответствуют идентичным состояниям конвейера и должны присутствовать в диаграмме в единственном варианте. Для более эффективного представления диаграммы состояний производят построение модифицированной диаграммы состояний (МДС), которая подобна исходной, но содержит только те состояния, которые возникают при новых инициациях (рис. 2). Дуги в МДС помечаются числом, соответствующим числу дуг между двумя состояниями в исходной диаграмме. >=8 3 >=8 * 11100111 4 11111111 11110111 Рис. 2. Модифицированная диаграмма состояний 4 * МДС содержит всю необходимую информацию для построения стратегии но является более компактной и легче поддается анализу. После построения МДС задача диспетчера – выбрать оптимальную последовательность инициаций. В предложенном примере можно выделить два основных варианта стратегии управления. Левая ветвь диаграммы описывает жадную стратегию управления, которая выбирает всегда минимально возможную латентность между данной и следующей инициацией без учета каких бы то ни было следующих инициаций. Легко заметить, что при выборе данной стратегии управления мы вынуждены будем чередовать латентности 3 и 8, таким образом, средняя латентность составит 5,5 тактов. В правой ветви диаграммы вторая инициация осуществляется с латентностью 4 и далее может повторяться с той же латентностью, что более эффективно, чем при жадной стратегии. При этом одна из ступеней конвейера будет постоянно работать со 100% загрузкой, т.е. эта стратегия для данного конвейера является оптимальной. В конвейерах с динамической конфигурацией каждая инициация может относиться к своей таблице занятости. По этой причине могут быть моменты, когда в течение одного периода синхронизации возможно осуществление более чем одной инициации. Это происхо- 6 дит, когда две или более таблиц занятости не имеют столкновений ни с одной из предыдущих инициаций. Для динамического конвейера не существует единственного критерия оптимальности диспетчеризации, и, следовательно, единственной стратегии диспетчеризации. Понятие оптимальности может подразумевать один из следующих критериев: – максимизацию общего числа инициаций любого типа; – общего числа инициаций для определенной смеси команд (задаваемой процентным соотношением встречающихся в смеси команд); – минимизацию времени выполнения специфической последовательности инициаций для таблиц занятости разных типов. Подход, связанный с построением диаграмм состояний, может быть распространен и на случай динамического конвейера. При этом процедуры построения графов существенно усложняются и имеющиеся методы анализа становятся менее полными, но, тем не менее, такой подход является эффективным, и поэтому наиболее распространенным. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. 3. Построить для соответствующей варианту таблицы занятости полную и модифицированную диаграмму состояний, выписать допустимые последовательности латентностей, выбрать оптимальную. Сравнить оптимальную и жадную стратегии. 4. Написать программу, моделирующую: – работу статического конвейера, реализующего соответствующую варианту таблицу занятости, с оптимальной стратегией управления; – работу динамического конвейера, выполняющего случайную равновероятную смесь двух таблиц занятости. Вторая таблица занятости соответствует варианту, следующему за вашим. (для последнего варианта в качестве второй таблицы занятости выбирается соответствующая первому варианту). 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 1. Титульный лист. 2. Описание полученного задания; 3. Полную и модифицированную диаграммы состояний; 4. Список допустимых латентностей для анализируемой таблицы занятости, сравнение жадной и оптимальной стратегии; 5. Текст программы, моделирующей работу конвейера; 6. Скриншоты, демонстрирующие процесс работы программы; 7. Выводы. 5. Варианты лабораторных работ Описание варианта лабораторной работы представляет собой таблицу занятости конвейера. Вариант 1. Вариант 6. 7 0 1 2 1 * 2 * * 3 Вариант 2. 0 1 2 1 * * 2 * 3 Вариант 3. 0 1 2 1 * 2 * 3 * Вариант 4. 0 1 2 1 * * 2 * 3 Вариант 5. 0 1 2 1 * 2 * 3 * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 0 1 2 1 * * 2 * 3 Вариант 7. 0 1 2 1 * 2 * 3 * Вариант 8. 0 1 2 1 * 2 * * 3 Вариант 9. 0 1 2 1 * * 2 * 3 Вариант 10. 0 1 2 1 * 2 * * 3 3 4 5 6 7 * * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 3 4 5 6 7 * * * * * 8 6. Вопросы к защите лабораторной работы 1. В чем состоит сущность конвейеризации? 2. При каких условиях возможна и оправдана конвейеризация базовой функции? 3. К какому классу вычислительных систем из классификации Флинна может быть отнесено конвейерное устройство и почему? 4. Что такое стратегия управления конвейером, из каких соображений она выбирается? 5. Какие критерии выбора стратегии управления могут быть использованы для динамического конвейера? 6. Предложите возможное разбиение для исполнения операции: – сложения с плавающей точкой; – умножения с плавающей точкой; – деления с плавающей точкой. Нарисуйте для каждого приблизительную логическую схему. 7. Какие данные требуются при проектировании конвейера для процессора машины с архитектурой ОКОД ? 8. Какие типы помех возникают при конвейеризации процессора ОКОД? Каковы методы борьбы с ними? 9. Доказать, что для любого конвейера со статической конфигурацией, реализующего некоторую таблицу занятости, величина минимально достижимой латентности всегда больше или равна максимальному числу меток в любой строке этой таблицы. 10. Почему опережающая выборка и введение кэш-памяти может быть отнесено к конвейеризации ВС? 7. Литература 1. П.М. Коуги. Архитектура конвейерных ЭВМ. 9 ЛАБОРАТОРНАЯ РАБОТА 2. МОДЕЛИРОВАНИЕ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ КЛАССА ОКМД 1. Цель работы Изучение особенностей функционирования вычислительных систем класса ОКМД. Моделирование работы вычислительной системы класса ОКМД. 2. Теоретический материал. 2.1. Однородные вычислительные среды Однородные вычислительные структуры или среды (ОВС), как правило, относятся к типу ОКМД и представляют собой регулярную решетку из однотипных процессорных элементов (ПЭ). Каждый ПЭ, в зависимости от типа ОВС, может как обладать алгоритмически полным набором операций, так и реализовывать один вид операций, жестко заданный в структуре микросхемы на этапе проектирования, а также операциями обмена или взаимодействия с другими ПЭ. Идея однородных вычислительных сред была сформулирована в начале 60-х годов сотрудником Института математики СО АН СССР Э.В. Евреиновым. Была показана возможность снятия ограничения на рост тактовой частоты в однородных средах за счет коротких связей между соседними ячейками среды и реализации взаимодействия между удаленными ячейками по принципу близкодействия через цепочку ячеек, расположенных между ними. В силу возможности различного направления специализации ячеек и установления различной пропорции между реализацией на жесткой логике и программируемостью, сегодня предложено много вариантов построения специализированных систем с программируемой структурой. К этому классу вычислительных систем относятся также систолические и волновые процессоры, программируемые (raw) процессоры и др [1]. 2.2. Систолические матрицы Систолическая матрица (СМ) есть способ построения ПВС на СБИС. В классическом представлении такая матрица представляет собой регулярный массив процессорных элементов, выполняющих на протяжении каждого такта одинаковые вычислительные операции с пересылкой результатов вычислений своим ближайшим соседям [2]. В целом можно сказать, что СМ предназначена для вычисления некоторой рекуррентной функции. Причем СМ являются проблемно-ориентированными системами, т.е. для решения каждого конкретного типа прикладных задач, как правило, требуется разработка специальной архитектуры связей и алгоритмов работы компонентов СМ. Основными достоинствами подобных структур являются: – короткие соединительные линии между ПЭ, что приводит к уменьшению времени задержки; – регулярность структуры СБИС СМ, что увеличивает плотность упаковки и упрощает разработку; – высокая степень распараллеливания вычислений, а значит,высокая производительность. Области применения систолических матриц 10 СМ характеризуются широким спектром практического использования. Это обработка изображений, системы машинного зрения, моделирование процессов в средах, цифровая обработка сигналов в акустике, радиолокации, метеорологии и т.д. Помимо задач моделирования процессов в средах с использованием систолических матриц могут быть эффективно решены многие прикладные задачи, связанные с многоэтапной обработкой больших массивов информации. Необходимо отметить, что СМ являются специализированными вычислительными системами, т.е. каждая конкретная структура систолической матрицы может быть использована для решения узкого круга однотипных задач. Несмотря на то, что само понятие систолической матрицы достаточно просто для понимания, ее разработка является сложным процессом. Основную сложность представляет не разработка конкретных аппаратных решений, а поиск алгоритмов решения задачи, которые могут быть переложены на СМ и решение задачи перехода от описания алгоритма к структуре СМ. Для ряда задач эта проблема может быть решена формально с использованием специального математического аппарата, но для наиболее интересных применений формального решения не существует. 2.3. Нейрокомпьютеры Толчком к развитию нейрокомпьютинга послужили биологические исследования. По данным нейробиологии нервная система человека и животных состоит из отдельных клеток – нейронов. В мозге человека их число достигает 1.0e10 – 1.0e12. Каждый нейрон связан с 1.0e3 – 1.0e4 другими нейронами и выполняет сравнительно простые действия. Время срабатывания нейрона – 2-5 мс. При этом, как можно наблюдать на практике, подобная «вычислительная система» позволяет решать многочисленные прикладные задачи из области искусственного интеллекта. Нейрокомпьютинг – это научное направление, занимающееся разработкой вычислительных систем шестого поколения – нейрокомпьютеров, которые состоят из большого числа параллельно работающих простых вычислительных элементов (нейронов). Элементы связаны между собой, образуя нейронную сеть. Они выполняют единообразные вычислительные действия и не требуют внешнего управления. Большое число параллельно работающих вычислительных элементов обеспечивают высокое быстродействие. По формальным признакам нейрокомпьютер может быть отнесен к параллельным ВС типа ОКМД (или SIMD). В этой категории параллельных вычислительных систем по организации вычислений нейрокомпьютеры более всего соответствуют однородным вычислительным средам. Единственное отличие – в топологии однородных вычислительных сред присутствуют только локальные взаимосвязи между конструктивными элементами, а в нейросетях топология связей, как правило, более сложная [3]. Вычисления в нейронных сетях существенно отличаются от традиционных, в силу высокой параллеленности их можно рассматривать как коллективное явление. В нейронной сети нет локальных областей, в которых запоминается конкретная информация. Вся информация запоминается во всей сети. Отличия нейрокомпьютеров от вычислительных устройств с традиционной обработкой информации: – параллельная работа очень большого числа простых вычислительных устройств обеспечивает огромное быстродействие; – нейронная сеть способна к обучению, которое осуществляется путем настройки параметров сети; – высокая помехо- и отказоустойчивость нейронных сетей; 11 – простое строение отдельных нейронов позволяет использовать новые физические принципы обработки информации для аппаратных реализаций нейронных сетей. Нейронные сети находят свое применение в системах распознавания образов, обработки сигналов, предсказания и диагностики, в робототехнических и бортовых системах. Нейронные сети обеспечивают решение сложных задач за времена порядка времен срабатывания цепочек электронных и/или оптических элементов. Решение слабо зависит от неисправности отдельного нейрона. Это делает их привлекательными для использования в бортовых интеллектуальных системах. 2.4. Клеточные автоматы Что такое "клеточный автомат"? Это математический объект с дискретными пространством и временем. Каждое положение в пространстве представлено отдельной клеткой, а каждый момент времени - дискретным временным шагом или поколением. Состояние каждого пространственного локуса или клетки определяется очень простыми правилами взаимодействия. Эти правила предписывают изменения состояния каждой клетки в следующем такте времени в ответ на текущее состояние соседних клеток. Впервые, идея таких автоматов отмечена в работах Неймана в 1940-х годах, когда он работал над идеей саморепродуцирующихся машин [5]. Вплоть до конца 60-х идея клеточных автоматов была забыта и лишь в 1970 Джон Конвей, математик Кембриджского университета, описал ныне широко известный двумерный клеточный автомат, названный "Игра жизни" ("Game of life”) Плоские клеточные автоматы обычно задаются на бесконечной двухмерной решётке с квадратными ячейками (клетками, имеющими заданное множество возможных состояний. Соседними для любой ячейки считаются 4 (8) ячеек, имеющих с ней общую сторону или угол. В моменты времени t1, t2, …, tn, … все ячейки клеточного автомата одновременно переключаются в новые состояния, определяемые текущими (до переключения) их состояниями и состояниями соседних им ячеек. При заданной начальной конфигурации – начальных состояниях клеток – последовательность переключений порождает определённую (конечную или бесконечную) эволюцию автомата. Разные клеточные автоматы отличаются числом возможных состояний клетки и правилами их переключения. Семантическое богатство языка клеточных автоматов привлекает исследователей к их использованию в самых различных сферах науки, например, для решения философских вопросов о познаваемости мироздания или для разработки эффективных вычислительных устройств и прикладных программ широкого назначения [6]. С точки зрения архитектур параллельных вычислительных систем клеточный автомат можно представить, как однородную вычислительную среду, относящуюся к классу ОКМД. Каждая клетка автомата соответствует вычислительному модулю такой среды, причем, в полном соответствии с принципами построения однородных сред, все они функционируют по одному алгоритму, синхронно и обмениваются данными только с ближайшими соседями в узлах решетки. В общем случае клеточные автоматы обладают следующими свойствами. – Изменения значений всех клеток происходят одновременно после вычисления нового состояния каждой клетки решетки. – Решетка однородна - невозможно различить какие-либо две области решетки по ландшафту. – Взаимодействия локальны. Лишь клетки окрестности (как правило, соседние) способны повлиять на данную клетку. – Множество состояний клетки конечно. 12 Эволюция клеточного автомата, порождаемая заданной начальной конфигурацией, может быть изучена в общем случае только путём её воспроизведения. В нетривиальных автоматах многие простые конфигурации порождают столь продолжительную и своеобразную эволюцию, что по воспроизведенной её части (любой длительности) бывает невозможно дать содержательного прогноза дальнейшего её хода (например, сказать, будет ли эволюция конечной). Проблема полного и точного описания множества возможных эволюций автомата является одной из самых сложных проблем теории клеточных автоматов. Автомат Дж. Конвея, нетривиален и обладает вычислительной неприводимостью: в общем случае невозможно заранее предсказать ход эволюции, можно только «дожить» до определенного её шага. Никакие вычислительные мощности никогда не позволят в полной мере исследовать данный автомат путём непосредственного расчёта множества всех его эволюций. 2.5. Сеточные вычисления Одно из основных направлений использования высокопроизводительной вычислительной техники – решение сложных инженерных и научных задач путем численного моделирования, которое является альтернативой экспериментальному исследованию процессов и явлений. Численное моделирование постоянно применяется при разработке новых химических соединений, моделировании процессов в атмосфере, исследовании и оптимизации аэродинамических свойств движущихся объектов и т.д [7]. Существует большое количество разновидностей теоретически обоснованных численных моделей. Большую их часть можно разделить на следующие три группы. 1. Точечные вычисления используются в моделях, имитирующих поведение некоторой системы, в которой присутствует взаимное влияние компонентов системы друг на друга. Например, при моделировании поведения системы астрономических тел, каждое из которых оказывает гравитационное воздействие на все остальные компоненты системы. 2. Матричные вычисления применяются, как правило, когда возникает необходимость решить систему одновременно действующих уравнений. 3.Сеточные вычисления применяются при численном решении уравнений в частных производных и других приложениях (например, при обработке изображений), когда исследуемая область разбивается на множество точек, лежащих в узлах некоторой пространственной матрицы. Особенности последней группы моделей таковы, что ее практическая реализация, можно сказать, идеально ложится на параллельные вычислительные системы класса ОКМД, а именно – на однородные вычислительные среды. Рассмотрим эту модель более подробно. Дифференциальные уравнения в частных производных (partial differential equations – PDE) применяются для моделирования процессов в средах. Обычно при решении PDE (кроме самых простых, которые могут быть решены аналитически) нужно найти приближенное решение уравнения на конечном множестве точек, применяя итерационные численные методы. В качестве примера рассмотрим, как решить конкретное уравнение – уравнение Лапласа – с помощью сеточных вычислений по так называемому методу конечных разностей. Уравнение Лапласа является примером т.наз. эллиптического дифференциального уравнения в частных производных. В двумерном варианте это уравнение имеет вид: Функция Ф представляет собой некоторый неизвестный потенциал, например, теплоту или напряжение. 13 По данной области пространства и известным значениям в точках на границе этой области нужно аппроксимировать стационарное решение во внутренних точках области. Это можно сделать, покрыв область равномерной сеткой точек. Каждая внутренняя точка инициализируется некоторым начальным значением. Затем с помощью повторяющихся итераций имитируется изменение состояния полученной картины потенциала до тех пор, пока не будет достигнуто стационарного состояния, признаком которого является уменьшение разницы между текущим и предыдущим состоянием до заранее заданной величины. На каждой итерации новое значение в каждой точке матрицы является комбинацией старых значений соседних точек. Для решения уравнения Лапласа существует несколько итерационных методов: Якоби, Гаусса-Зейделя, последовательной сверхрелаксации и др. В методе итераций Якоби новое значение в каждой точке сетки равно среднему из предыдущих значений четырех ее соседних точек. Этот процесс продолжается либо заранее заданное количество итераций, либо до достижения стационарного состояния. 2.6. Применение сетей Петри для описания параллельных процессов Сети Петри – это средство описания параллельных процессов (ПП). Приведем основные сведения, которые необходимы с точки зрения реализации технологии имитационного моделирования ПП [8]. Одно из основных достоинств аппарата сетей Петри заключается в том, что они могут быть представлены как в графической форме (наглядность), так и в аналитической (позволяет автоматизировать процесс их анализа). При графической интерпретации сеть Петри представляет собой граф особого вида, состоящий из вершин двух типов – позиций и переходов, соединенных ориентированными дугами. При этом каждая дуга может связать лишь разнотипные вершины (позицию с переходом или переход с позицией). Вершины позиции обозначаются кружками, вершины-переходы – черточками. Переходы соответствуют событиям, присущим системе, а позиции – условиям их возникновения. Таким образом, совокупность переходов, позиций и других дуг позволяет описать причинно-следственные связи, присущие системе в статике. Чтобы сеть Петри “ожила”, вводят еще один вид объектов сети – метки позиций (флажки). Переход считается активным (событие может произойти), если в каждой его входной позиции есть хотя бы один флажок. Расположение флажков в позиции сети называется разметкой сети. (рис. 1). В аналитической форме сеть Петри может быть представлена следующим образом: Р = (В, D, I, O, M), где В = {вi} – конечное непустое множество позиций; D = {di} – конечное непустое множество переходов; I– входная функция (прямая функция инцидентности), которая для каждого перехода задает множество его входных позиций; O– входная функция (обратная функция инцидентности), которая для каждого перехода задает множество его выходных позиций; M – функция разметки сети; М: В 0, 1, 2, … ставит каждой позиции сети в соответствие неотрицательное целое число. 14 Входная и выходная функции сети Петри (I и O) позволяют описать любую сеть с помощью двух матриц размером m х n (матрица входных и выходных позиций). Основные направления анализа сети Петри. 1. Проблема достижимости. В сети Петри с начальной разметкой М0 требуется определить достижима ли принципиально некоторая разметка М1 из М0. С точки зрения исследования моделируемой системы, эта проблема интерпретируется как проблема достижимости (реализуемости). 2. Свойства живучести. Под живучестью перехода понимают возможность его срабатывания в данной сети при начальной разметке М0. Анализ модели на свойство живучести позволяет выявить невозможные состояния в моделируемой системе (например, неисполняемые ветви в программе). 3. Безопасность сети. Безопасной является такая сеть Петри, в которой ни при каких условиях не может появиться более одной метки в каждой из позиций. Для исследуемой системы это означает возможность функционирования ее в стационарном решении, на основе анализа данного свойства могут быть определены требования к буферным накопителям в системе. Рис. 1. Изменение разметки сети Петри при срабатывании переходов 15 а. Начальная разметка сети Петри б. Изменение разметки сети Петри в. Завершение функционирования сети Петри Достоинства сетей Петри заключается в следующем: – позволяют моделировать ПП всех возможных типов с учетом вероятных конфликтов между ними; – обладают наглядностью и обеспечивают возможность автоматизированного анализа; – позволяют переходить из одного уровня детализации описания системы к другому (за счет раскрытия/закрытия переходов). 16 Основным недостатком сети Петри является то, что время срабатывания перехода считается равным нулю. Это не позволяет исследовать с их помощью временные характеристики моделируемых систем. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. 3. Написать программу, моделирующую функционирование параллельной вычислительной системы класса ОКМД выбранного типа. 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 1. 2. 3. 4. 5. 6. Титульный лист. Оисание полученного задания; Текст программы, моделирующей работу параллельной ВС; Описание программы. Скриншоты, демонстрирующие процесс работы программы; Выводы. 5. Варианты лабораторных работ. 1. Модель систолической матрицы для сортировки одномерного массива методом пузырька. 2. Модель систолической матрицы для выполнения операции умножения двух квадратных матриц. 3. Модель клеточного автомата «игра Жизнь» 4. Модель, реализующая матрицу Якоби, замкнутую в тор. 5. Модель, реализующая матрицу Якоби с заданными граничными условиями. 6. Модель нейронной сети (без обучения). 7. Модель системы типа «wave front». 8. Модель системы, управляемой потоком данных (сеть Петри). 6. Вопросы к защите лабораторной работы. 1. Каковы особенности архитектуры и организации вычислений в параллельных ВС класса ОКМД? 2. Какие вычислительные системы были построены на базе процессорных матриц? Приведите пример, опишите особенности архитектуры и организации вычислений. 3. В чем состоят основные принципы построения однородных вычислительных сред? 4. В чем достоинства и недостатки параллельных ВС на базе систолических матриц? 5. Для каких практических целей используются клеточные автоматы? 6. В чем особенности организации процесса обработки информации в нейронных вычислительных сетях? 7. В чем состоят основные достоинства и недостатки нейронных сетей? 17 8. В каких случаях для решения научных и инженерных задач применяются точечные, матричные и сеточные методы? 9. На каком типе параллельных ВС сеточные методы реализуются лучше всего и почему? 10. Для чего используются сети Петри? Приведите пример. 7. Литература. 1. Кун, С. Матричные процессоры на СБИС / С.Кун. М.: Мир, 1991. – 672с 2. Мур У. Систолические структуры / У.Мур, Э.Маакейб, Р. Уркхарт. Москва: Радио и связь, 1993. 416 с. 3. Горбань А.Н. Нейронные сети на персональном компьютере / А.Н. Горбань, Д.А. Россиев. Новосибирск: Наука, 1996. 276 с. 4. Вирт Н. Алгоритмы и структуры данных. СПб.: Невский диалект, 2001. 654с. 5. Нейман Дж фон. Теория самовоспроизводящихся автоматов. М.: Мир, 1971. 420с. 6. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования / Г.Р. Эндрюс. Москва: Издательский дом «Вильямс», 2003. 512 с. 7. Питерсон Дж. Теория сетей Петри и моделирование систем. / Дж. Питерсон. М.: Мир, 1984. 386 с. 18 ЛАБОРАТОРНАЯ РАБОТА 3. ИСПОЛЬЗОВАНИЕ ФУНКЦИЙ ОБМЕНА ДАННЫМИ «ТОЧКА-ТОЧКА» В БИБЛИОТЕКЕ MPI. 1. Цель работы Ознакомление с библиотекой программирования параллельных вычислительных систем с использованием технологии передачи сообщений (MPI). Изучение особенностей функций обмена данными «точка-точка». 2. Теоретический материал. В настоящее время самым распространенным стандартом, использующимся при разработке программ, основанных на передаче сообщений, является стандарт MPI (Message Passing Interface – Взаимодействие через передачу сообщений). Этот стандарт, разработанный в середине 90-х годов, предоставляет программисту единый механизм взаимодействия ветвей внутри параллельного приложения независимо от машинной архитектуры (однопроцессорные / многопроцессорные с общей/раздельной памятью), взаимного расположения ветвей (на одном процессоре / на разных) и API операционной системы. В настоящее время разными коллективами разработчиков написано несколько программных пакетов, удовлетворяющих спецификации MPI, в частности: MPICH, LAM, HPVM и т. д. Они выступают базовыми при переносе MPI на новые архитектуры ЭВМ. Минимально в состав MPI входят: библиотека программирования (заголовочные и библиотечные файлы для языков Си, Си++ и Фортран) и загрузчик приложений. Дополнительно включаются: профилирующий вариант библиотеки (используется на стадии тестирования параллельного приложения для определения оптимальности распараллеливания); загрузчик с графическим и сетевым интерфейсом и т. п. Строго говоря, технология MPI подразумевает подход MPMD (Multiple Program − Multiple Data: множество программ − множество данных), при этом одновременно на различных вычислительных устройствах выполняются несколько (базирующихся на различных исходных текстах) программных ветвей, в определенные промежутки времени обменивающихся данными. Однако подобные программы слишком громоздки при написании (для каждого вычислительного устройства требуется отдельный исходной текст), поэтому на практике применяется SPMD-подход (Single Program − Multiple Data: одна программа – множество данных), предполагающий исполнение на различных вычислительных устройствах логически выделенных условными операторами участков идентичного кода. Все ветви программы запускаются загрузчиком одновременно как процессы; количество ветвей фиксировано – согласно стандарту MPI 1.1 в ходе работы порождение новых ветвей невозможно. Ветви объединяются в группы − это некое множество ветвей. Одна ветвь может быть членом нескольких групп. Каждой группе в соответствие ставится область связи. Область связи ("communication domain") − это нечто абстрактное: в распоряжении программиста нет типа данных, описывающего непосредственно области связи, как нет и функций по управлению ими. Области связи автоматически создаются и уничтожаются вместе с коммуникаторами. При запуске приложения все процессы помещаются в создаваемую для приложения общую область связи. При необходимости они могут создавать но- 19 вые области связи на базе существующих. Все области связи имеют независимую друг от друга нумерацию процессов. Программе пользователя в распоряжение предоставляется коммуникатор − описатель области связи. Многие функции MPI имеют среди входных аргументов коммуникатор, который ограничивает сферу их действия той областью связи, к которой он прикреплен. Для одной области связи может существовать несколько коммуникаторов таким образом, что приложение будет работать с ней как с несколькими разными областями. Коммуникаторы являются "несообщающимися сосудами": если данные отправлены через один коммуникатор, ветвь-получатель сможет принять их только через этот же самый коммуникатор, но ни через какой-либо другой. В исходных текстах примеров для MPI часто используется идентификатор MPI_COMM_WORLD. Это название коммуникатора, создаваемого библиотекой автоматически. Он описывает стартовую область связи, объединяющую все процессы приложения. Зачем вообще нужны разные группы, разные области связи и разные их описатели? – они помогают ветви-передатчику и ветви-получателю надежнее определять друг друга, а также содержимое сообщения; – ветви внутри параллельного приложения могут объединяться в подколлективы для решения промежуточных задач − посредством создания групп, и областей связи над группами. Пользуясь описателем этой области связи, ветви гарантированно ничего не примут извне подколлектива, и ничего не отправят наружу. Параллельно при этом они могут продолжать пользоваться любым другим имеющимся в их распоряжении коммуникатором для пересылок вне подколлектива, например, MPI_COMM_WORLD для обмена данными внутри всего приложения; – коллективные функции создают дубликат от полученного аргументом коммуникатора, и передают данные через дубликат, не опасаясь, что их сообщения будут случайно перепутаны с сообщениями функций "точка-точка", распространямыми через оригинальный коммуникатор; – программист с этой же целью в разных кусках кода может передавать данные между ветвями через разные коммуникаторы, один из которых создан копированием другого. Библиотека MPI состоит примерно из 130 функций, в число которых входят: – функции инициализации и закрытия MPI-процессов; – функции, реализующие коммуникационные операции типа точка-точка; – функции, реализующие коллективные операции; – функции для работы с группами процессов и коммуникаторами; – функции для работы со структурами данных; – функции формирования топологии процессов. 2.1. Общие процедуры MPI int MPI_Init( int* argc, char*** argv) Инициализация параллельной части приложения. Реальная инициализация для каждого приложения выполняется не более одного раза, а если MPI уже был инициализирован, то никакие действия не выполняются и происходит немедленный возврат из подпрограммы. Все оставшиеся MPI-процедуры могут быть вызваны только после вызова MPI_Init. Возвращает: в случае успешного выполнения − MPI_SUCCESS, иначе − код ошибки. int MPI_Finalize( void ) Завершение параллельной части приложения. Все последующие обращения к любым MPIпроцедурам, в том числе к MPI_Init, запрещены. К моменту вызова MPI_Finalize не- 20 которым процессом все действия, требующие его участия в обмене сообщениями, должны быть завершены. Настоятельно рекомендуется не забывать вписывать эту инструкцию перед возвращением из программы, то есть: – перед вызовом стандартной функции Си exit ; – перед каждым после MPI_Init оператором return в функции main ; – если функции main назначен тип void, и она не заканчивается оператором return, то MPI_Finalize() следует поставить в конец main. int MPI_Comm_size( MPI_Comm comm, int* size) Определение общего числа параллельных процессов в группе comm. comm – идентификатор группы; OUT size – размер группы. int MPI_Comm_rank( MPI_comm comm, int* rank) Определение номера процесса в группе comm. Значение, возвращаемое по адресу &rank, лежит в диапазоне от 0 до size_of_group-1. comm − идентификатор группы; OUT rank − номер вызывающего процесса в группе comm. double MPI_Wtime(void) Функция возвращает астрономическое время в секундах (вещественное число), прошедшее с некоторого момента в прошлом. Гарантируется, что этот момент не будет изменен за время существования процесса. 2.2. Прием/передача сообщений точка-точка int MPI_Send(void* buf, int count, MPI_Datatype datatype, int dest, int msgtag, MPI_Comm comm) buf − адрес начала буфера посылки сообщения count − число передаваемых элементов в сообщении datatypе − тип передаваемых элементов dest − номер процесса-получателя msgtag − идентификатор сообщения comm − идентификатор группы Блокирующая посылка сообщения с идентификатором msgtag, состоящего из count элементов типа datatype, процессу с номером dest. Все элементы сообщения расположены подряд в буфере buf. Значение count может быть нулем. Тип передаваемых элементов datatype должен указываться с помощью предопределенных констант типа. Разрешается передавать сообщение самому себе. int MPI_Recv(void* buf, int count, MPI_Datatype datatype, int source, int msgtag, MPI_comm comm, MPI_Status *status) OUT buf − адрес начала буфера приема сообщения count − максимальное число элементов в принимаемом сообщении datatype − тип элементов принимаемого сообщения source − номер процесса-отправителя msgtag − идентификатор принимаемого сообщения 21 comm − идентификатор группы OUT status − параметры принятого сообщения Прием сообщения с идентификатором msgtag от процесса source с блокировкой. Число элементов в принимаемом сообщении не должно превосходить значения count. Если число принятых элементов меньше значения count, то гарантируется, что в буфере buf изменятся только элементы, соответствующие элементам принятого сообщения. Если нужно узнать точное число элементов в сообщении, то можно воспользоваться подпрограммой MPI_Probe. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. 3. Написать программу с использованием библиотеки MPI, реализующую выбранное задание. Предусмотреть возможность отображения результатов работы программы на экране. 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 1. Титульный лист. 2. Описание полученного задания; 3. Текст программы с использованием библиотеки MPI, реализующей выбранное задание. 4. Блок-схему программы, описывающую исполнение параллельных фрагментов. 5. Скриншоты, демонстрирующие процесс работы программы; Выводы. 5. Варианты лабораторных работ. 1. Игра с ведущим (съедобное − несъедобное). Процесс 0 поочередно посылает остальным процессам сообщение. Получив сообщение, процесс-приемник информирует об этом процесс 0. 2. Морской бой. Два процесса поочередно обмениваются сообщениями согласно правилам игры в морской бой. 3. Испорченный телефон. Процесс 0 генерирует строковое сообщение и передает его процессу со следующим номером. Процесс-получатель случайным образом меняет в сообщении один символ и передает его дальше. Последний процесс передает получившийся результат «ведущему». 4. Имитация кольцевой топологии. Предполагается, что узлы кластера (и соответствующие процессы) образуют замкнутое кольцо (последний процесс связан с процессом с номером 0). Процессы случайным образом генерируют сообщения, состоящие из информационной части и номера процесса-адресата. Сообщение передается по кольцу до тех пор, пока не дойдет до него. Узел 0 выполняет, кроме того, роль контроллера канала и удаляет из него сообщения, не нашедшие адресата. 5. Поиск минимума в массиве. Процесс 0 генерирует массив и раздает его другим процессам для поиска минимума. Собрав локальные минимумы, ищет общий. 6. Поиск максимума в массиве. См. предыдущее задание. 7. Сортировка массива методом пузырька. Процесс 0 генерирует массив и раздает его другим процессам для сортировки методом пузырька. 22 8. Суммирование элементов массива. Процесс 0 генерирует массив и раздает его другим процессам для вычисления локальных сумм, после чего вычисляет общую сумму. 9. Обработка элементов массива. Процесс 0 генерирует массив и раздает его другим процессам для обработки (например, поиска нулевых элементов), после чего собирает результат. 10. Сдвиг массива, распределенного между узлами. Процесс 0 генерирует массив и раздает его другим процессам, после чего выполняется циклический сдвиг массива. 6. Вопросы к защите лабораторной работы. 1. Что такое сетевой кластер? Почему данная технология так распространена в настоящее время? 2. В чем состоит принцип построения программ SPMD? 3. Что такое коммуникатор и для чего используются коммуникаторы в MPI? 4. Чем отличаются блокирующие и неблокирующие посылка/передача сообщений в MPI? 5. Какие средства синхронизации предусмотрены в MPI? 6. Какие типы операций коллективного взаимодействия имеются в библиотеке? 7. Что нужно для того, чтобы подключить компьютер сети к кластеру с целью запуска программы на MPI? 8. Какая роль обычно возлагается на процесс с номером 0 в группе? 9. К каким последствиям может привести отсутствие в программе вызовов функций MPI MPI_Init и MPI_Finalize? 10. Почему MPI использует собственные типы данных в функциях обмена? 7. Литература. 1. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования / Г.Р. Эндрюс. Москва: Издательский дом «Вильямс», 2003. 512 с. 2. Гергель В.П. Основы параллельных вычислений для многопроцессорных вычислительных систем / В.П. Гергель, Р.Г. Стронгин. Н.Новгород, ННГУ, 2001. 386с. 3. Воеводин В.В. Параллельные вычисления. / В.В. Воеводин, Вл.В. Воеводин. СПб: BHV, 2002. 486с. 4. Немнюгин С.А. Параллельное программирование для многопроцессорных вычислительных систем / С.А. Немнюгин, О.Л. Стесик СПб.: Петербург, 2002. 360 с. 23 ЛАБОРАТОРНАЯ РАБОТА 4. MPI: ИССЛЕДОВАНИЕ БЛОКИРУЮЩИХ ОПЕРАЦИЙ ПРИЕМА/ПЕРЕДАЧИ. ИСПОЛЬЗОВАНИЕ АРГУМЕНТОВ-ДЖОКЕРОВ. 1. Цель работы Изучение различных вариантов реализации команд обмена данными точка/точка в библиотеке MPI, особенностей исполнения блокирующих и неблокирующих операций приема/передачи, возможностей использования аргументов-джокеров. 2. Теоретический материал. В настоящее время самым распространенным стандартом, использующимся при разработке программ, основанных на передаче сообщений, является стандарт MPI (Message Passing Interface – Взаимодействие через передачу сообщений Библиотека MPI состоит примерно из 130 функций, в число которых входят: – функции инициализации и закрытия MPI-процессов; – функции, реализующие коммуникационные операции типа точка-точка; – функции, реализующие коллективные операции; – функции для работы с группами процессов и коммуникаторами; – функции для работы со структурами данных; – функции формирования топологии процессов. 2.1. Прием/передача сообщений точка-точка Существует два вида функций приема/передачи данных в MPI. Блокирующие − останавливают (блокируют) выполнение процесса до тех пор, пока производимая ими операция не будет выполнена. Неблокирующие функции возвращают управление немедленно, а выполнение операции продолжается в фоновом режиме; за завершением операции надо проследить особо. Неблокирующие функции возвращают квитанции ("requests"), которые погашаются при завершении. До погашения квитанции с переменными и массивами, которые были аргументами неблокирующей функции, ничего делать нельзя. Для операций типа точка-точка имеются 4 режима обмена данными, различающимися условиями инициализации и завершения передачи сообщений: – стандартная передача считается выполненной и завершается, как только сообщение отправлено, независимо от того, дошло оно до адресата или нет; – синхронная передача отличается от стандартной тем, что она не завершается до тех пор, пока не будет завершен прием сообщения. Адресат, получив сообщение, посылает процессу, отправившему сообщение, уведомление, которое должно быть получено отправителем для того, чтобы обмен считался выполненным; – буферизованная передача завершается сразу же, когда данные помещаются в специальный буфер обмена, где и ожидают своей очереди на пересылку; 24 – передача «по готовности» начинается только в том случае, когда адресат инициировал прием сообщения, а завершается сразу же, независимо от того, принято сообщение или нет. Каждый из этих четырех режимов может быть выполнен как в блокирующей, так и неблокирующей форме. Таким образом, функции двухточечного обмена данными могут быть сведены в следующую таблицу: Таблица 1. Режимы выполнения С блокировкой Без блокировки Стандартная передача MPI_Send MPI_ISend Синхронная передача MPI_SSend MPI_ISSend Буферизованная передача MPI_BSend MPI_IBSend Согласованная передача MPI_RSend MPI_IRSend Прием MPI_Recv MPI_IRecv int MPI_Send(void* buf, int count, MPI_Datatype datatype, int dest, int msgtag, MPI_Comm comm) buf − адрес начала буфера посылки сообщения count − число передаваемых элементов в сообщении datatype − тип передаваемых элементов dest − номер процесса-получателя msgtag − идентификатор сообщения comm − идентификатор группы Блокирующая посылка сообщения с идентификатором msgtag, состоящего из count элементов типа datatype, процессу с номером dest. Все элементы сообщения расположены подряд в буфере buf. Значение count может быть нулем. Тип передаваемых элементов datatype должен указываться с помощью предопределенных констант типа. Разрешается передавать сообщение самому себе. Блокировка гарантирует корректность повторного использования всех параметров после возврата из подпрограммы. Выбор способа осуществления этой гарантии: копирование в промежуточный буфер или непосредственная передача процессу dest, остается за MPI. Следует специально отметить, что возврат из подпрограммы MPI_Send не означает ни того, что сообщение уже передано процессу dest, ни того, что сообщение покинуло процессорный элемент, на котором выполняется процесс, выполнивший MPI_Send. int MPI_Recv(void* buf, int count, MPI_Datatype datatype, int source, int msgtag, MPI_comm comm, MPI_Status *status) OUT buf − адрес начала буфера приема сообщения count − максимальное число элементов в принимаемом сообщении datatype − тип элементов принимаемого сообщения source − номер процесса-отправителя msgtag − идентификатор принимаемого сообщения comm − идентификатор группы OUT status − параметры принятого сообщения Прием сообщения с идентификатором msgtag от процесса source с блокировкой. Число элементов в принимаемом сообщении не должно превосходить значения count. Если 25 число принятых элементов меньше значения count, то гарантируется, что в буфере buf изменятся только элементы, соответствующие элементам принятого сообщения. Если нужно узнать точное число элементов в сообщении, то можно воспользоваться подпрограммой MPI_Probe. Блокировка гарантирует, что после возврата из подпрограммы все элементы сообщения приняты и расположены в буфере buf. В качестве номера процесса-отправителя можно указать предопределенную константу MPI_ANY_SOURCE − признак того, что подходит сообщение от любого процесса. В качестве идентификатора принимаемого сообщения можно указать константу MPI_ANY_TAG − признак того, что подходит сообщение с любым идентификатором. MPI резервирует для них какие-то отрицательные целые числа, в то время как реальные идентификаторы задач и сообщений лежат всегда в диапазоне от 0 до 32767. Пользоваться джокерами следует с осторожностью, потому что по ошибке таким вызовом MPI_Recv может быть захвачено сообщение, которое должно приниматься в другой части задачи-получателя. Если логика программы достаточно сложна, использовать джокеры можно ТОЛЬКО в функциях MPI_Probe и MPI_Iprobe, чтобы перед фактическим приемом узнать тип и количество данных в поступившем сообщении (вообще-то, можно принимать, и не зная количества − был бы приемный буфер достаточно вместительным, но тип для MPI_Recv надо указывать явно − а он может быть разным в сообщениях с разными идентификаторами). Достоинство джокеров: приходящие сообщения извлекаются по мере поступления, а не по мере вызова MPI_Recv с нужными идентификаторами задач/сообщений. Это экономит память и увеличивает скорость работы. Если процесс посылает два сообщения другому процессу и оба эти сообщения соответствуют одному и тому же вызову MPI_Recv, то первым будет принято то сообщение, которое было отправлено раньше. С одной стороны, мы передаем в MPI_Recv номер задачи, от которой ждем сообщение, и его идентификатор; а с другой − получаем их от MPI в структуре status? Это сделано потому, что MPI_Recv может быть вызвана с аргументами-джокерами ("принимай что угодно/от кого угодно"), и после такого приема данных программа узнает фактические номер/идентификатор, читая поля MPI_SOURCE и MPI_TAG из структуры status. Поле MPI_ERROR, как правило, проверять необязательно − обработчик ошибок, устанавливаемый MPI по умолчанию, в случае сбоя завершит выполнение программы ДО возврата из MPI_Recv. Таким образом, после возврата из MPI_Recv поле status.MPI_ERROR может быть равно только 0 (или, если угодно, MPI_SUCCESS); Тип MPI_Status не содержит поля, в которое записывалась бы фактическая длина пришедшего сообщения. Длину можно узнать так: MPI_Status status; int count; MPI_Recv( ... , MPI_INT, ... , &status ); MPI_Get_count( &status, MPI_INT, &count ); /* теперь count содержит количество принятых ячеек */ 26 Обратите внимание, что аргумент-описатель типа у MPI_Recv и MPI_Get_count должен быть одинаковым, иначе, в зависимости от реализации в count вернется неверное значение или произойдет ошибка времени выполнения. Функции асинхронных приема/передачи дополняются функциями ожидания завершения, например: int MPI_Wait( MPI_Request *request, MPI_Status *status) request − идентификатор асинхронного приема или передачи OUT status − параметры сообщения Ожидание завершения асинхронных процедур MPI_ISend или MPI_IRecv, ассоциированных с идентификатором request. В случае приема, атрибуты и длину полученного сообщения можно определить обычным образом с помощью параметра status. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. 3. Написать программу с использованием библиотеки MPI, реализующую выбранное задание, с использованием блокирующих функций обмена данными и аргументов-джокеров. Предусмотреть способ отображения процесса работы программы на экране. Оценить время исполнения программы. 4. Ввести в текст программы фрагменты, скоторые представляют опасность с точки зрения возникновения «клинча», описать поведение программы в этих ситуациях. 5. Заменить блокирующие функции обмена данными на неблокирующие. Оценить время исполнения программы. 6. Выполнить п. 4 для программы с неблокирующими функциями обмена. Описать поведение программы. 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 7. Титульный лист. 8. Описание полученного задания; 9. Текст программы с использованием библиотеки MPI, реализующую выбранное задание. 10. Блок-схему программы, описывающую исполнение параллельных фрагментов. 11. Скриншоты, демонстрирующие процесс работы программы; 12. Выводы. 5. Варианты лабораторных работ. 1. Пляжный волейбол. Процесс 0 генерирует сообщение и посылает его любому другому процессу группы. Процесс-приемник передает сообщение дальше. Выбор процесса-адресата осуществляется случайным образом. 2. Имитация посылки пакета с маршрутом. Процесс 0 генерирует сообщение, которое состоит из маршрутной и информационной части. Маршрутная часть содержит последова- 27 тельность номеров процессов – промежуточных адресатов. Промежуточный адресат, получив пакет, убирает из адресной части свой номер и передает сообщение дальше согласно списку. Окончательный адресат, получив посылку, отчитывается перед процессом 0. 3. Имитация топологии «звезда» (процесс с номером 0 реализует функцию центрального узла). Процессы в случайном порядке генерируют пакеты, состоящие из адресной и информационной части и передают их в процесс 0. Маршрутная часть пакета содержит номер процесса-адресата. Процесс 0 переадресовывает пакет адресату. Адресат отчитывается перед процессом 0 в получении. Процесс 0 информирует процесс-источник об успешной доставке. 4. Раздача и сборка массива. Процесс 0 генерирует целочисленный массив и раздает его по частям в остальные процессы; порядок раздачи определяется случайным образом, размер каждого следующего передаваемого фрагмента в 2 раза меньше предыдущего. Процессы-получатели выполняют обработку массива и возвращают результат в процесс 0. Процесс 0 должен собрать массив результатов обработки с сохранением последовательности элементов. 5. Игра в снежки. Процессы делятся на 2 группы (четные и нечетные номера). Каждый процесс нечетной группы случайным образом генерирует посылку четному процессу. Четный процесс, получив посылку, в свою очередь, отправляет случайно выбранному нечетному процессу следующую. Предусмотреть ситуацию получения одним процессом нескольких посылок. 6. Вопросы к защите лабораторной работы. 1. В чем достоинства и недостатки кластерных параллельных ВС? 2. Какие варианты функций передачи данных реализованы в MPI? 3. Для чего служат идентификаторы сообщений и процессов? 4. Когда используются идентификаторы-джокеры в MPI? Когда их использование не рекомендуется? 5. Чем отличаются блокирующие и неблокирующие, синхронные и несинхронные функции передачи сообщений в MPI? 6. С какой целью в MPI введены операции коллективного обмена данными? 7. Какие групповые операции обработки данных реализованы в MPI? 8. Для каких целей предназначены функции описания топологии в MPI? 9. Какие поля содержит переменная типа MPI_Status, и как они могут использоваться? 10. Для чего служит функция MPI_Wait? 7. Литература. 1. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования / Г.Р. Эндрюс. Москва: Издательский дом «Вильямс», 2003. 512 с. 2. Гергель В.П. Основы параллельных вычислений для многопроцессорных вычислительных систем / В.П. Гергель, Р.Г. Стронгин. Н.Новгород, ННГУ, 2001. 386с. 3. Воеводин В.В. Параллельные вычисления. / В.В. Воеводин, Вл.В. Воеводин. СПб: BHV, 2002. 486с. 4. Немнюгин С.А. Параллельное программирование для многопроцессорных вычислительных систем / С.А. Немнюгин, О.Л. Стесик СПб.: Петербург, 2002. 360 с. 28 ЛАБОРАТОРНАЯ РАБОТА 5. MPI: ИССЛЕДОВАНИЕ ФУНКЦИЙ КОЛЛЕКТИВНОГО ОБМЕНА ДАННЫМИ 1. Цель работы Изучение различных вариантов реализации групповых команд обмена данными точка/точка в библиотеке MPI, особенностей исполнения блокирующих и неблокирующих операций приема/передачи, возможностей использования аргументов-джокеров. 2. Теоретический материал. В настоящее время самым распространенным стандартом, использующимся при разработке программ, основанных на передаче сообщений, является стандарт MPI (Message Passing Interface – Взаимодействие через передачу сообщений). Библиотека MPI состоит примерно из 130 функций, в число которых входят: – функции инициализации и закрытия MPI-процессов; – функции, реализующие коммуникационные операции типа точка-точка; – функции, реализующие коллективные операции; – функции для работы с группами процессов и коммуникаторами; – функции для работы со структурами данных; – функции формирования топологии процессов. 2.1. Функции коллективного обмена данными. Основные особенности и отличия от коммуникаций типа "точка-точка": – на прием и/или передачу работают все задачи-абоненты указываемого коммуникатора; – коллективная функция выполняет одновременно и прием, и передачу; она имеет большое количество параметров, часть которых нужна для приема, а часть для передачи; в разных задачах та или иная часть игнорируется; – как правило, значения параметров (за исключением адресов буферов) должны быть идентичными во всех задачах; MPI назначает идентификатор для сообщений автоматически; кроме того, сообщения передаются не по указываемому коммуникатору, а по временному коммуникатору-дупликату, тем самым потоки данных коллективных функций надежно изолируются друг от друга и от потоков, созданных функциями "точка-точка". int MPI_Bcast(void *buf, int count, MPI_Datatype datatype, int source, MPI_Comm comm) OUT buf – адрес начала буфера посылки сообщения count – число передаваемых элементов в сообщении datatype – тип передаваемых элементов source – номер рассылающего процесса comm – идентификатор группы Рассылка сообщения от процесса source всем процессам, включая рассылающий процесс. При возврате из процедуры содержимое буфера buf процесса source будет скопировано в локальный буфер процесса. Значения параметров count, datatype и source должны быть одинаковыми у всех процессов. 29 MPI_Gather ("совок") собирает в приемный буфер задачи root передающие буфера остальных задач. Заметьте, что: – recvType и sendType могут быть разные и, таким образом, будут задавать разную интерпретацию данных на приемной и передающей стороне; – задача-приемник также отправляет данные в свой приемный буфер. MPI_Scatter ("разбрызгиватель"): выполняет обратную "совку" операцию – части передающего буфера из задачи root распределяются по приемным буферам всех задач. MPI_Allgather аналогична MPI_Gather, но прием осуществляется не в одной задаче, а во ВСЕХ: каждая имеет специфическое содержимое в передающем буфере, и все получают одинаковое содержимое в буфере приемном. Как и в MPI_Gather, приемный буфер последовательно заполняется данными изо всех передающих. MPI_Alltoall : каждый процесс нарезает передающий буфер на куски и рассылает куски остальным процессам; каждый процесс получает куски от всех остальных и поочередно размещает их приемном буфере. Это "совок" и "разбрызгиватель" в одном флаконе. Для всех команд коллективного обмена данными существуют векторные варианты, которые позволяют задавать разное количество отправляемых данных в разных задачах-отправителях. Соответственно, на приемной стороне задается массив позиций в приемном буфере, по которым следует размещать поступающие данные, и максимальные длины порций данных от всех задач. Оба массива содержат позиции/длины НЕ в байтах, а в количестве ячеек типа recvCount. Например, аналог векторного варианта команды MPI_Gather – MPI_Gatherv. 2.2. Распределенные операции Идея проста: в каждой задаче имеется массив. Над нулевыми ячейками всех массивов производится некоторая операция (сложение/произведение/ поиск минимума/максимума и т.д.), над первыми ячейками производится такая же операция и т.д. Функции, предназначенные для вызова этих операций, отличаются способом размещения результата в задачах. Предопределенных описателей операций в MPI насчитывается 12: – MPI_MAX и MPI_MIN ищут поэлементные максимум и минимум; – MPI_SUM вычисляет сумму векторов; – MPI_PROD вычисляет поэлементное произведение векторов; – MPI_LAND, MPI_BAND, MPI_LOR, MPI_BOR, MPI_LXOR, MPI_BXOR – логические и двоичные операции И, ИЛИ, исключающее ИЛИ; – MPI_MAXLOC, MPI_MINLOC – поиск индексированного минимума/максимума . 2.3. Функции вызова распределенных операций int MPI_AllReduce( void *sbuf, void *rbuf, int count, MPI_Datatype datatype, MPI_Op op, MPI_Comm comm) sbuf – адрес начала буфера для аргументов OUT rbuf – адрес начала буфера для результата count – число аргументов у каждого процесса datatype – тип аргументов op – идентификатор глобальной операции 30 comm – идентификатор группы Выполнение count глобальных операций op с возвратом count результатов во всех процессах в буфере rbuf. Операция выполняется независимо над соответствующими аргументами всех процессов. Значения параметров count и datatype у всех процессов должны быть одинаковыми. Из соображений эффективности реализации предполагается, что операция op обладает свойствами ассоциативности и коммутативности. int MPI_Reduce( void *sbuf, void *rbuf, int count, MPI_Datatype datatype, MPI_Op op, int root, MPI_Comm comm) sbuf – адрес начала буфера для аргументов OUT rbuf – адрес начала буфера для результата count – число аргументов у каждого процесса datatype – тип аргументов op – идентификатор глобальной операции root – процесс-получатель результата comm – идентификатор группы Функция аналогична предыдущей, но результат будет записан в буфер rbuf только у процесса root. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. Варианты лабораторной работы отличаются типом операции группового обмена. 3. Написать программу с использованием библиотеки MPI, реализующую выбранное задание в двух вариантах: с использование групповых операций обмена и с использованием операций типа «точка-точка». Оценить время исполнения программы в обеих вариантах. 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 1. Титульный лист. 2. Описание полученного задания; 3. Текст программы с использованием библиотеки MPI, реализующей выбранное задание. 4. Блок-схему программы, описывающую исполнение параллельных фрагментов. 5. Скриншоты, демонстрирующие процесс работы программы. 6. Оценки времени исполнения различных вариантов реализации программы. 6. Выводы. 5. Задание на лабораторную работу Реализовать программно процессы раздачи исходных данных, выполнения их обработки и сбора полученных результатов в двух вариантах: с использованием операций обмена данными типа «точка – точка» и операций группового обмена данными. Способ генерации 31 исходных данных, их распределения по узлам выбирается самостоятельно согласно требованиям реализуемой функции коллективного обмена. 6. Варианты лабораторной работы. 1. MPI_Bcast 2. MPI_Gather 3. MPI_Scatter 4. MPI_Allgather 5. MPI_Alltoall 6. Вопросы к защите лабораторной работы 1. Какие типы кластерных ВС вы знаете? 2. Какие групповые операции обработки данных реализованы в MPI? 3. С какой целью в MPI введены операции коллективного обмена данными? 4. Какие коллективные функции существуют в MPI? В чем их принципиальной отличие от остальных? 5. Для чего служит функция MPI_Barrier? 7. Литература. 1. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования / Г.Р. Эндрюс. Москва: Издательский дом «Вильямс», 2003. 512 с. 2. Гергель В.П. Основы параллельных вычислений для многопроцессорных вычислительных систем / В.П. Гергель, Р.Г. Стронгин. Н.Новгород, ННГУ, 2001. 386с. 3. Воеводин В.В. Параллельные вычисления. / В.В. Воеводин, Вл.В. Воеводин. СПб: BHV, 2002. 486с. 4. Немнюгин С.А. Параллельное программирование для многопроцессорных вычислительных систем / С.А. Немнюгин, О.Л. Стесик СПб.: Петербург, 2002. 360 с. 32 ЛАБОРАТОРНАЯ РАБОТА 6. ВЛИЯНИЕ ОБЪЕМА ВЫЧИСЛЕНИЙ ИНТЕНСИВНОСТИ ТРАФФИКА НА ЭФФЕКТИВНОСТЬ ПО КЛАСТЕРА 1. Цель работы Исследование зависимости эффективности программы от объема вычислений, выполняемых независимо в каждом узле, и интенсивности обмена данными между процессами. 2. Теоретический материал Прежде чем перейти к практической реализации кластерной технологии необходимо решить для себя несколько принципиальных вопросов. Первый из них звучит так: "Необходим ли для решения моих задач кластер и параллельные вычисления?" Чтобы ответить на этот вопрос надо проанализировать решаемые классы задач, алгоритмы их решения для выявления явного и скрытого параллелизма, рассмотреть альтернативные, возможно, более легко распаралливаемые, алгоритмы решения. Параллельные вычисления - достаточно специфичная область математики и далеко не всегда параллельные вычисления могут быть вами применимы. 2.1. Размер кластера Поскольку кластер, вообще говоря, масштабируемая система, то вопрос количества узлов не является принципиальным. В дальнейшем, в процессе эксплуатации кластера, возможно увеличение числа узлов с минимальными затратами. Естественно, при этом необходимо иметь в виду, что увеличение числа узлов кластера повышает нагрузку на коммуникационную подсистему, и в определенный момент может потребоваться ее реконфигурация. Если же выстроите кластер на базе локальной (корпоративной) сети, то работы по добавлению узла кластера не выйдут за рамки технического подключения новой машины в сеть. Зависимость эффективности кластера от числа узлов, как правило, не является линейной. Вид этой функции зависит от вида задачи, которая решается с помощью кластера. В большинстве случаев эффективность кластера растет до того момента, когда время передачи между узлами информации, необходимой для проведения одной итерации становится сравнимым со временем счета одной итерации. Таким образом, можно порекомендовать при начальном построении кластера ограничится четырьмя узлами (одна консоль и три узла). С одной стороны, вы всегда при необходимости можете нарастить кластер, с другой стороны, меньшее количество узлов может дать не столь ощутимый результат, как ожидалось. Тем не менее, при проблемах с финансированием можно ограничится и двумя узлами. Для ознакомления с особенностями программирования кластера, начального этапа отладки программ часто достаточно одного персонального компьютера с установленным соответствующим программным обеспечением. 2.2. Узлы кластера Кластеры обычно строятся из так называемых «элементов высокой степени готовности», т.е. из распространенных материнских плат или – в самом простом случае – системных блоков. Выбор процессора для узлов кластера определяется финансовыми возможностями. Стоит установить на каждый узел достаточное количество оперативной памяти (опти- 33 мальное количество диктуется особенностями решаемых задач). Один из узлов следует выделить в качестве консоли кластера, куда можно установить достаточно большой жесткий диск, возможно более мощный процессор и больше памяти, чем на остальные (рабочие) узлы. Делать консоль кластера более мощной машиной имеет смысл, если вы захотите иметь на этом компьютере кроме интерфейса командной строки более удобное операционной окружение, офисные программы, программы визуализации данных и т.п. 2.3. Коммуникационная подсистема В простейшем случае для связи между узлами кластера используется один сегмент Ethernet. Однако дешевизна такой сети оборачивается большими накладными расходами на межпроцессорные обмены, а хорошую производительность такого кластера можно ожидать только на задачах с очень простой параллельной структурой и при очень редких взаимодействиях между процессами. Для большинства вычислительных задач параметры коммуникационной подсистемы являются важными, зачастую критичными. Желательно заранее определить объемы передачи данных и частоту взаимодействий. Если один вычислительный шаг вашей задачи длится 10 секунд, после чего каждый процессор обменивается с двумя другими массивами данных размером в 1 мегабайт, то при пропускной способности сети 10 мегабит (обычный Ethernet), задержки составят ~4 секунд (так как надо и послать и принять данные), либо ~2 секунды если связь дуплексная (см. ниже -- обсуждение аппаратной части кластеров). При этом результирующая производительность составит соответственно 60 или 80% от пиковой. При использовании FastEthernet (100 мегабит), задержки составят соответственно ~0.4 и ~0.2 секунды, а производительность – 96 или 98%. Однако, если время обработки данных между обменами составляет 0.1 секунды, то потери даже при использовании FastEthernet составят более 60-80 процентов времени. При этом уже следует задуматься о применении более высокопроизводительной сети, например Myrinet. Для получения приемлемой производительности межпроцессорных обменов как минимум, необходим полнодуплексный Fast Ethernet или Gigabit Ethernet. При этом для уменьшения числа коллизий или устанавливают несколько "параллельных" сегментов Ethernet, или соединяют узлы кластера через коммутатор (switch). Под "параллельными" сегментами подразумевается такая структура сети, когда каждый узел кластера имеет более одной сетевой карты, которые с помощью специальных драйверов объединяются в один виртуальный сетевой интерфейс, имеющий суммарную пропускную способность. Для того, чтобы избежать проблем с конфигурированием такого виртуального интерфеса, следует использовать одинаковые сетевые карты на всех машинах кластера. 2.4. Задача оптимизации управления параллельными процессами Задача управления параллельными процессами на ВС связана с минимизацией времени выполнения параллельной программы и максимизацией эффективности используемых ресурсов. В настоящее время она не имеет точного решения, а используемые алгоритмы управления основываются на обобщении экспериментальных данных, эвристиках, привлечении методов искусственного интеллекта и др. При этом центральной проблемой является умение достаточно точно измерять и прогнозировать параметры, по которым можно эффективно контролировать загрузку кластера. Поэтому чрезвычайно важной задачей является выбор небольшого количества параметров, которые легко измеряются и поведение которых несложно прогнозировать. Перечислим основные параметры, по которым можно достаточно объективно судить о загруженности компьютера: 34 – средняя загрузка процессора, – объем свободной памяти, – интенсивность обменов между дисковой и оперативной памятью, – интенсивность обмена данными с другими компьютерами. Второй и третий параметры взаимосвязаны, по ним можно судить (особенно по третьему параметру) о непроизводительном времени, которое процессор компьютера тратит на обмен между оперативной и дисковой памятью (среднее обращение к дисковой памяти в современных компьютерах при страничном обмене равно 1.5 мс – среднему времени полуоборота дискового носителя). Интенсивность обмена между компьютерами позволяет судить о загруженности каналов сетевого обмена ВС и косвенно показывают насколько часто взаимодействуют процессы, размещённые на различных компьютерах. Параметр – средняя загрузка процессора, в разных ОС рассчитывается по-разному. Так в ОС UNIX – эта величина рассчитывается в зависимости от времени, общей длинны очереди процессов и с учётом физических свойств процессора. В ОС Windows эта величина рассчитывается исходя из долей времени работы и простоя процессора. В ОС Windows, Linux и др. есть специальные программные средства для измерения указанных параметров. Ограничимся рассмотрением способов измерения характеристик загруженности компьютера для двух наиболее широко используемых для высоко производительных вычислений ОС Windows и Linux. Для получения текущей загруженности компьютера, работающего под управлением ОС Windows, разработан набор библиотек с системными функциями, позволяющими измерять – необходимые параметры: – библиотека Process Status Helper (PSAPI); – ToolHelp32 API; – счетчики производительности. Набор функций под названием ToolHelp API включён в ОС Windows, начиная с версии 3.1. Эта библиотека позволяет сторонним разработчикам получить доступ к системной информации. При создании Windows 95 эти функции были добавлены в новую систему под названием ToolHelp32 API. В ранних версиях ОС интерфейс для доступа к данным производительности был крайне запутанным и неудобным, начиная с Windows NT 4.0, была предоставлена библиотека Performance Data Helper, значительно облегчающая получение данных о производительности. Используя ToolHelp32 API, сначала создается моментальный снимок (snapshot) списка процессов с помощью функции CreateToolhelp32Snapshot, а затем осуществляется считывание информации из списка с помощью функций Process32First и Process32Next. Структура PROCESSENTRY32, заполняемая этими функциями, содержит всю информацию о текущем состоянии системы. "Счётчики производительности" (perfomance counters) – это расширяемый механизм сбора различной информации, заложенный в операционные системы линейки Windows. Большая часть счётчиков доступна пользователю через оснастку (snap-in) Performance. Операционная система Windows, начиная с версии NT, предоставляет интерфейс для получения разнообразной информации о системе в виде счетчиков производительности. Этот интерфейс позволяет получить набор глубоко вложенных друг в друга структур. Для получения той или иной информации нужно прочитать из ключа реестра HKEY_PERFORMANCE_DATA значение со специально сформированным именем. В результате возвращается набор вложенных структур, многие из которых переменного размера [3]. 35 С появлением в Windows NT 4.0 библиотеки Performance Data Helper (PDH), этот интерфейс стал более удобным для измерения данных о производительности. Однако эта библиотека не входила в комплект поставки Windows NT 4.0, она распространялась в составе Microsoft Platform SDK. В Windows 2000 PDH.DLL присутствует по умолчанию. Система измерения производительности в Windows NT реализована при помощи понятия объекта, для которого осуществляется подсчет производительности. Примерами объектов являются процессор, жесткий диск и др. Каждый объект может иметь один или более экземпляров, и для каждого объекта существует свой набор счетчиков производительности. Задача состоит в получении значения счетчика. Основная сложность в использовании счётчиков производительности состоит в том, что названия объектов и счетчиков производительности являются локализуемыми. Это значит, что, например, на русской версии Windows NT/2000/XP необходимо использовать зарезервированные константы "Процесс" и "Идентификатор процесса" вместо "Process" и "ID Process". Для получения локализованных имен объектов и формирования полного пути к интересующему нас счетчику производительности необходимо писать вспомогательную функцию, которая бы осуществляла обратное преобразование. Счётчики производительности - это мощный и гибкий механизм. Но, он неочевиден и неудобен. Однако есть несколько ситуаций, когда использование счётчиков производительности может быть необходимо, когда: – нужно следить за каким-то параметром системы, недоступным через другие интерфейсы (например, количество страниц передаваемых из ОП на жёсткий диск в секунду свопинг). – необходимо написать какую-то сложную систему и предоставить администратору возможность использовать стандартные механизмы для доступа к информации о состоянии этой системы. Ядро ОС Linux, которое управляет ресурсами компьютера, предоставляет пользователям набор команд, при помощи которых можно получить информацию о загруженности компьютера. Поэтому программа для сбора информации о загруженности компьютера может быть написана не только на любом языке программирования, имеющем компилятор для ОС Linux, но и напрямую на скриптовом языке Shell OC Linux. Например, команда ps выводит информацию о запущенных процессах. Вывод оформлен в виде таблицы. В первой строке содержатся заголовки колонок таблицы, в последующих строках выводятся сведения о каждом процессе. В следующем примере приведен пример вызова программы и выводимая информация: Названия и значение колонок, выводимых при выполнении команды: – PID - Идентификатор процесса; – USER - регистрационное имя пользователя-владельца процесса; – UID - Реальный идентификатор пользователя; – SIZE - полный объем памяти, занимаемой процессом; – RES RSS - размер резидентной части процесса; – STAT - состояние процесса; – LIB - объем библиотечных подпрограмм; – %CPU - текущее значение загрузки процессора; – %MEM - часть оперативной памяти, занятая резидентной частью процесса; – TIME - процессорное время, затраченное на выполнение процесса; – COMMAND - команда запуска процесса; – PPID - идентификатор родительского процесса; – TSIZE - объем машинного кода программы; – DSIZE - объем данных (области данных и стека) программы; 36 – SWAP - объем части процесса, выгруженной в область свопинга. Процедура получения информации о процессах несколько сложнее. ОС Linux отображает значительную часть своих системных данных в оперативную память через псевдо-файловую систему /proc. /proc/<pid> - каталог, содержащий всевозможную информацию по процессу с указанным <pid>. Команда ps с ключами a u x, позволяет получить полную информацию обо всех процессах. При помощи этой функции можно построить дерево, элементами которого будут являться ссылки на информацию о параметрах процессов. 3. Порядок выполнения 1. Ознакомиться с описанием лабораторной работы. 2. Получить вариант задания у преподавателя. 3. Написать программу с использованием библиотеки MPI, реализующую выбранное задание. 4. Содержание отчета Полный отчет предоставляется в электронном виде и/или твердой копии (по требованию преподавателя). Он должен содержать: 1. Титульный лист. 2. Описание полученного задания; 3. Текст программы с использованием библиотеки MPI, реализующую выбранное задание. 4. Сводные таблицы по результатам экспериментов. 6. Выводы. 5. Задание на лабораторную работу Лабораторная работа № 6 выполняется на основе лабораторной работы № 5. Используя программу, написанную для ЛР 5, выполнить следующие эксперименты, оценить время исполнения программы и проанализировать полученные результаты. Эксперименты выполнять как для программы с обменом данными типа «точка-точка», так и для программы с коллективными операциями обмена (если это возможно). Примечание: объем передаваемых данных должен быть достаточно большим. Эксперимент 1. Зафиксировать размер обрабатываемого массива. Увеличивать количество процессов (соответственно, узлов кластера), выполняющих обработку данных. Эксперимент 2. Увеличиваем размер обрабатываемого массива. Количество узлов фиксировано (повторить для 1-2-4 узлов). Эксперимент 3. Фиксируем размер массива и количество узлов. Увеличиваем объем вычислений в узле (повторить для 1-2-4 узлов). Эксперимент 4. Для программы с операциями обмена типа «точка-точка» фиксируем размер массива и количество используемых узлов. Изменяем размер буфера в функции передачи данных от одного элемента массива до всего передаваемого фрагмента (5-6 точек замера). Эксперимент 5. Предложите свой вариант. 6. Вопросы к защите лабораторной работы 1. Какие параметры определяют уровень загруженности компьютера? Пояснить почему? 37 2. Каковы основные способы измерения параметров загруженности компьютера? 3. Какой метод достижения равномерной загрузки кластерной вычислительной системы на основе измерения параметров загруженности вы можете предложить? 4. Как можно оценить вычислительную сложность определения одного из параметров загруженности компьютера стандартными средствами ОС? 5. Чем отличается определение параметров загруженности компьютера в ОС Windows от ОС Linux 7. Литература 1. Эндрюс Г.Р. Основы многопоточного, параллельного и распределенного программирования / Г.Р. Эндрюс. Москва: Издательский дом «Вильямс», 2003. 512 с. 2. Гергель В.П. Основы параллельных вычислений для многопроцессорных вычислительных систем / В.П. Гергель, Р.Г. Стронгин. Н.Новгород, ННГУ, 2001. 386с. 3. Воеводин В.В. Параллельные вычисления. / В.В. Воеводин, Вл.В. Воеводин. СПб: BHV, 2002. 486с. 4. Воеводин Вл.В. Вычислительное дело и кластерные системы / Вл.В. Воеводин, С.А. Жуматий . М.: Изд-во МГУ, 2007. - 150 с. 5. Лацис, А.О. Как построить и использовать суперкомпьютер / А.О. Лацис. Москва: Бестселлер, 2003. 236 с.