Особенности использования программных инструментальных платформ параллельных вычислительных систем общего назначения

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

Примерами такого рода инструментальных сред являются Rational Rose и IBM Rational Software Architect. Среды разработки программ могут иметь встроенные средства трансформации логической структуры программы, представленной диаграммой классов, в исходный код и обратной трансформации и интегрировать в себя средства специализированных сред визуального моделирования на основе диаграмм UML. Так, встроенные средства среды Visual Studio.Net поддерживают постоянную синхронизацию программного кода и соответствующей ему диаграммы классов, выполняя прямую и обратную трансформацию при изменении визуального представления диаграммы классов или программного кода C#. Вид диаграммы классов в среде Visual Studio.Net приведен на рис. 2.8. Кроме того, в среду Visual Studio.Net могут быть интегрированы средства Retional XDE, что обеспечивает работу со всеми видами диаграмм UML.

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

Традиционным подходом к моделированию дискретно-событийных систем является разработка библиотеки многократно используемых компонент, из которых могут быть собраны модели различных систем [271]. Примером такой библиотеки может служить библиотека AnyLogicTM Enterprise Library. Библиотека предоставляет высокоуровневый интерфейс для быстрого создания дискретно-событийных моделей с помощью блок-схем.

увеличить изображение
Рис. 2.8. Диаграмма классов в Visual Studio.Net

Графическое представление систем с помощью блок-схем широко используется во многих сферах деятельности: производстве, логистике, системах обслуживания, бизнес-процессах, моделировании компьютерных и телекоммуникационных сетей и т. д. Поддержка графического представления моделируемой системы в виде, привычном для специалиста в предметной области, позволяет конструировать модель и выполнять ее параметризацию в стиле "перетащить и оставить" (drag-and-drop). На рис. 2.9 приведена блок-схема модели системы массового обслуживания, сконструированная из стандартных объектов: генераторов заявок, очередей, задержек, разветвителей и т. п.

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

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

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

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

Ход времени рассматривается как последовательность события в той же логической последовательности и с теми же относительными по отношению к реальному времени интервалами, что и в моделируемой сиcтеме. Моделирование реакции системы на событие сводится к перестройке управляющего списка.

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

увеличить изображение
Рис. 2.9. Блок-схема модели массового обслуживания в обозначениях AnyLogic Enterprise Librar

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

Системотехнические выводы по лекции 2

1. Отправной точкой распараллеливания вычислений является алгоритм, откуда следует, что коэффициент распараллеливания программы не может быть выше, чем у вычислительного алгоритма, реализуемого этой программой. Сам вычислительный алгоритм является эквивалентной формой записи аналитической модели предметной области, в которой строго определены приоритеты, а значит, и порядок выполнения операций.
2. Методы и средства конструирования программ являются не только прерогативой параллельных нейрокомпьютерных технологий и технологий с микропрограммным уровнем поддержки, но и широко используются при создании программных продуктов для ВС общего назначения. При этом надо отличать инструментальные платформы, которые ориентированы на использование уже существующих аппаратных платформ, от инструментальных платформ, ориентированных на их создание. В первом случае допускается только специфицированная реконфигурация аппаратной платформы под требования вычислительного алгоритма пользователя, что было апробировано в транспьютерных и многопроцессорных ЦПОС -проектах, а во втором случае вычислительный алгоритм известен и требуется методами и средствами (полу)заказного проектирования синтезировать аппаратуру его поддержки, что характерно для систолических матриц.
3. Центральная проблема создания современных инструментальных платформ - это формализованные средства представления и поддержки параллелизма, использование которых требует углубленного знания возможностей целевой аппаратной платформы, призванной воплотить в жизнь затребованный программным конструктором параллелизм.
4. Решить в общем виде задачу формализованного представления параллелизма пока не удалось, что вынуждает:
   • использовать интерактивный режим (микро)программного конструирования либо на всех стадиях проекта, как это имеет место в систолических и бит-потоковых технологиях, либо на отдельных, но самых ответственных этапах декомпозиции проекта и распределения (конфигурирования) затребованных ресурсов между коллективом вычислителей, как это имеет место в транспьютерных и многопроцессорных ЦПОС- и RISC-технологиях;
   • строить по иерархическому принципу инструментальные платформы "собственных нужд", поэтапно решая задачи извлечения из вычислительного алгоритма потенциально достижимого коэффициента распараллеливания вычислений, представления граф-потока сигнала в "терминах" целевой аппаратной платформы, устранения синонимии, возникающей из-за ограниченных размеров целевой аппаратной платформы.