Визуализация программного обеспечения параллельных вычислений включает в себя исследования и разработки визуальных языков параллельного программирования, визуальных отладчиков и систем настройки, отладки и измерения производительности параллельных программ. Если в случае программирования последовательных систем визуализация зачастую играет лишь вспомогательную роль, то в параллельных вычислениях она, как правило, оказывается жизненно необходимой. Важнейшая задача визуализации связана с обеспечением эффективности параллельных программ. Именно поэтому большинство проектов, вышедших за рамки академических, относятся к системам отладки, настройки и измерения производительности. Применение средств визуализации на ранних этапах жизненного цикла параллельной программы может облегчить как ее разработку, так и последующую отладку, в том числе и отладку эффективности. Поэтому предпринимаются попытки разработать интегрированные системы визуализации параллельных вычислений, включающих в себя как средства визуального программирования и/или визуальной поддержки программирования, так и средства отладки. Интегрированные системы естественно требуют единства средств визуального представления программ на всех этапах работы с ней. Таким образом, происходит обратный дрейф методик визуализации, используемых в отладчиках различного типа, в системы визуального программирования параллельных вычислений.
В [1] описан визуализатор данных о производительности DVM-программ. Эти средства, применяемые для отладки эффективности, разрабатывались в качестве первой очереди визуальной среды для системы DVM. Ниже мы рассмотрим как существующие подходы к созданию визуальных языков параллельного программирования, так и наши предложения и пилотные реализации средств визуальной поддержки процесса разработки DVM-программ.
Проектирование визуальных языков параллельного программирования началось достаточно давно, еще в 80-ые годы. При этом прежде всего ставились задачи обеспечить отображение специальных понятий параллельного программирования таких как посылка, порт, одновременное исполнение или при, задании общей структуры системы, -- описать наличие иерархичности, перехода из состояния в состояние и т.п. Эти языки, как правило, опирались на графовое представление потока управления и/или потока данных и использовали смешанные диаграмматические и иконические нотации.
Одним из первых примеров такого решения является система Pigsty/I-PIGS [13] -- язык и среда для поддержки параллельного программирования и базирующаяся на языках Паскале и CSP (Communication Sequential Processes). Язык использует текст и диаграммы для представления программ. Его последовательная часть в основном аналогична языку Паскаль. Управляющие конструкции представляются в форме схем. Программа на CSP состоит из одного или более последовательных процессов, каждый из которых представляется в виде прямоугольника. Процессы могут взаимодействовать друг с другом посредством однонаправленных связей через порты. Среда поддержки параллельного программирования может выполнять программы, представленные в виде диаграмм, посредством механизма, моделирующего параллельное выполнение и указывает тупиковые ситуации во время выполнения параллельной программы.
В дальнейшем подобная тенденция в развитии визуальных языков параллельного (четко изображать взаимодействие параллельных процессов, построенное, например, по правилам библиотек PVM или MPI) нашла отражение во многих системах.
В частности в языке VPE [12] имеется возможность рисования одной или более графовых схем, представляющих структуру задач для параллельной программы. При этом описываются процессы, их порты с указанием за счет направления соответствующих стрелок на порт приема или порт передачи. Кроме схемы программы имеются тексты-аннотации. Язык VPE в принципе имеет много общего с другими языками, например, языком GRAPNEL, хотя последний представляется намного более развитым.
GRAPNEL [11] -- гибридный язык, то есть он использует как графическое так и текстовое представления, для того чтобы описать полноценную распределенную прикладную программу. Графика используется для того, чтобы изобразить те части программы, которые содержат важные элементы параллелизма, а текстовые описания применяется, например, для декларации и определения данных, сегментов программы, не содержащих обменов и т.д. Основная задача графических представлений -- обеспечить высокоуровневые абстракции распределенных программ, в которых ключевым является обеспечение взаимодействия процессов.
В языке реализована графическая поддержка структурированного проектирование на уровне процессов, динамического создания и уничтожения процессов; предопределены топологии схем (например, двумерная сетка, дерево, кольцо и т.п.), которые могут использоваться для установки регулярной топологии процессов. При этом размер топологий определяется во время выполнения. Автоматическая последовательность обменов проверяется на стадии написания программы. Поддерживается высокоуровневая отладка. Та же самая графическая среда может использоваться и для того, чтобы писать и отлаживать прикладную программу.
В рамках системы VISO [8] реализован практически полный визуальный вариант языка параллельного программирования Occam. В составе его словаря -- набор иконов, представляющих различные программные конструкции. Графический синтаксис также базируется на языке Occam. Можно указать, что в VISO активно используются идеи, впервые примененные в Pigsty/I-PIGS. Разработчиками системы сформулирована задача исследований в области визуального программирования -- поиск естественных и практичных способов обеспечения программистов возможностями выразить их двумерное понимание задачи непосредственно в вычисления, не заставляя их отображать свое понимание в текстовом виде.
В ряде других систем одновременно с описанием самой семантики параллельного программирования ставилась задача уже на этапе проектирования и "визуального кодирования" добиться правильности (в частности, детерминированности) и эффективности параллельных программ.
В этой связи интересен пример системы Phred [9], который не только является языком описания вычисления, но и служит для возможности описания детерминированного поведения параллельных программ. Программа на языке Phred состоит из потока управления, потока данных и множества интерпретаций узлов (то есть процедур, запускаемых при достижении узла). Визуальная компонента языка Phred обеспечивает изображение потоков управления и данных, создаваемых непосредственно при помощи графического редактора. Интерпретации узлов представляются спецификациями процедур. Граф потока управления языка Phred обеспечивает представление последовательных потоков, переключение управления, параллелизм и синхронизацию. Одновременно применяются и методы, характерные для визуальных языков на базе потоков данных. Структура языка такова, что в нем не важно описание взаимодействия процессов.
Эта же тенденция -- изображать в визуальном виде распараллеливание процессов или потенциальное распараллеливание -- четко реализована в языке визуального параллельного программирования Visper [15], в котором введено понятие графа взаимодействия процессов. В свою очередь граф взаимодействия процессов опирается на понятия карта параллельности и диаграмма пространства-времени.
Карта параллельности отображает возможную параллельность задачи. Это одновременно структура данных для перезапуска (переигровки) потока управления и графический метод представления параллельных процессов. Карта показывает историю проработки процессов в виде потока событий на временной шкале.
Динамика выполнения параллельной программы в диаграммах пространства-времени представляется как поток событий в двумерном пространстве, где одна ось показывает время, а вторая -- реальные отдельные процессоры.
Отметим, что эти методики отображения параллельности ранее использовались на этапах отладки и настройки эффективности параллельной программы. При реализации языка Visper было проведено расширение методик с тем, чтобы позволить их использование и на этапе конструирования программы. При этом временная ось переосмысливается как ось потока управления, а процессорная ось расширяется за счет введения понятия группы. Граф взаимодействия процессов определяется на трехмерном пространстве программирования. По оси X показываются процессоры и группы процессоров, а также потоки данных, которыми они обмениваются. Ось Y определяет поток управления программы, а на оси Z показано количество процессоров.
Язык Visper структурирован как трехуровневая система. На каждом уровне содержатся графические и текстовые символы, которые используются для выражения различных примитивов посылки сообщений и параллельных конструкций. При этом в реальных конструкциях объединяются как обобщенные, так и примитивные языковые компоненты. Такой подход не требует от программиста знания всех аспектов парадигмы передачи сообщений, а позволяет наращивать программу по частям, так как язык скрывает сложность парадигмы. Программирование на языке Visper не является полностью визуальным. Визуальные механизмы широко используются в тех случаях, когда обнаружены потоки управления и параллелизма. Декларативные и последовательные фрагменты программного кода пишутся на обычных языках, таких как C или Фортран, и таким образом не представляются в виде визуальных компонент.
В языке Vorlon [17] реализована модель параллельного исполнения потока объектов ( parallel object-flow execution model). Эта модель объединяет объектно-ориентированную модель и модель потока данных. Таким образом, существует возможность обеспечить как задание параллелизма, так и всей сложности конкретной прикладной задачи. При этом такие аспекты параллелизма, как синхронизация, обеспечиваются за счет конструкций, поддерживающих поток данных, а задание типов и их взаимосвязи дает возможность описывать все многообразие прикладной области.
Параллельный граф потока объектов состоит из узлов и дуг. Узлы представляют некоторую форму вычисляемого элемента, а дуги описывают взаимозависимости потоков управления и возможные маршруты передачи параметров между узлами.
Наконец рассмотрим еще одну тенденцию при разработке визуальных языков описания параллельных вычислений, когда для этого используется естественное в каком-то смысле представление самих математических объектов, а не графовое представление потока управления или потока данных соответствующей программы.
При этом в ряде разработок систем визуализации параллельных вычислений (например, на базе языка VIM Language [4] делается попытка визуализации как параллелизма, так и динамики обработки данных. Предусматривается прямое отображение таких визуальных спецификаций непосредственно в программу конкретной ЭВМ. В этих случаях визуальные образы должны представлять высокоуровневые математические объекты, например, параметризированную матрицу и вектор при описании методов решения задач линейной алгебры.
В других случаях визуальный интерфейс, задающий начальные значения для прикладной вычислительной системы, можно рассматривать как специализированный визуальный язык параллельного программирования. Так, в рамках проекта ASSY [5], который направлен на создание метасистемы, поддерживающей разработку проблемно-ориентированных систем программирования, реализованы средства для решения задачи о взаимодействиях потоков разреженной плазмы. Плазма представляется набором довольно большого числа модельных частиц, которые характеризуются набором параметров, таких как заряд, координаты, скорость и т.п. Область решения разбивается равномерной прямоугольной сеткой на ячейки. С каждой частицей связывается ячейка, в которой частица в данный момент находится. В определенных методом точках сетки вычисляются сеточные функции, описывающие, в частности, действующие в ней силы. Программирование заключается в задании вычислительных функций внутри каждой ячейки, которые определяют и состояние соседних ячеек. Пользователь может отслеживать ход программирования, наблюдая собранное из "кирпичей"-ячеек пространство моделирования вместе с заданными вычислениями. Распараллеливание осуществляется компилятором автоматически. При этом проблемы эффектного распараллеливания алгоритмов, также как и в предыдущем случае, не рассматривается. Предполагается, что специализированная система обеспечивает наивысшую производительность.
Методики визуального программирования в данной системе, также как и при использовании языков аналогичных VIM, сильно зависят от конкретных вычислительных методов и используемых моделей. Проблемно-ориентированные языки подобного типа подтверждают тезис о необходимости визуализации только лишь основных сущностей программирования, в данном конкретном случае являющимися высокоуровневыми понятиями определенного вычислительного метода.
В следующем разделе подводятся некоторые итоги нашего краткого обзора. Более подробные обзоры визуальных языков параллельного программирования приведены в [16], [18]. Электронные копии этих работ доступны через Internet.
При создании визуальных средств разработки должен учитываться ряд моментов. Среди них решение о том, какие сущности параллельной программы или ее окружения будут представляться в текстовом виде, а какие -- в графическом. Вообще важен ответ на вопрос -- что первично при разработке программы, текст или графическое представление. Если первичным является исходный текст, а графические образы вторичны и служат лишь для облегчения проектирования программы (и автоматизации построения исходного текста), то нужно определить, какие именно элементы программы будут визуализироваться. Если же предполагается первичность графических образов, то фрагменты текста должны употребляться пользователем только в местах, где это не обеспечивается визуальными средствами. Такие визуальные языки реализуются либо за счет средств "исполняемой графики", либо за счет препроцессирования визуального текста и генерации текста на одном из обычных языков программирования. В последнем (сейчас наиболее распространенном) случае нужно обеспечить как взаимно обратимую конвертацию текста и графического представления, так и стыковку фрагментов кода, созданных автоматически и написанных вручную.
Визуальный язык параллельного программирования должен обеспечивать создание эффективных программ, в том числе и программ "промышленного" счета.
Отметим существование полноценных систем визуального программирования, включающих в себя средства проектирования и отладки визуальных программ. Очевидно, что при проектировании таких систем следует поддерживать связь видов отображения разработки программы и отладки правильности.
Средства визуальной поддержки проектирования и программирования предполагают, что пользователь, взаимодействуя с графическими образами, задает информацию, необходимую для генерирования исходного текста или же самих машинных кодов.
Средства визуальной отладки правильности, в свою очередь, требуют для построения графических образов и взаимодействия с ними использования информации, содержащейся в тексте программы и полученной в ходе компиляции, а также задаваемой пользователем дополнительной информации о процессе отладки. Кроме этого, при проектировании средств визуальной отладки правильности (также как других средств визуализации программного обеспечения) необходимо учитывать, как пользователь представляет абстрактные сущности программирования. От правильности построения визуальных образов зависит качество и скорость интерпретации их пользователем. В настоящее время это, возможно, один из наиболее важных и, в тоже время, малоизученных вопросов. О важности представления пользователем функционирования программы отмечалось в [2].
В предыдущем (обзорном) разделе рассказывалось о языках, в которых имеет место спецификация таких различных сущностей параллельной программы, как потоки управления и данных, процессы, семафоры, порты и взаимодействие между процессами. При этом в одних языках делаются попытки визуально описать практически все объекты программы, тогда как в других визуализируется лишь то, что имеет непосредственное отношение к параллелизму. Кроме этого, в специализированных системах параллельного программирования могут использоваться визуальные представления высокоуровневых понятий вычислительного моделирования. Тогда пользователь оперирует с такими объектами как строки и столбцы матрицы, двумерные и трехмерные сетки, предназначенные для решения задач математической физики и пр. Здесь, также как и в случае ряда ранних "графовых" языков, проблема непосредственного распараллеливания и его эффективности не рассматривается.
В ряде визуальных систем параллельного программирования проявляется принцип единства видов отображения, предназначаемых как для визуального проектирования и кодирования, так и для отладки программ. Еще интереснее попытки использовать для спецификации параллельных программ методики, применяемые в системах отладки и настройки эффективности. Кроме упомянутых выше карт параллельности и диаграмм пространства-времени, опишем идеи по проектированию динамического визуального языка параллельного программирования на базе аналога диаграмм Гантта, традиционно применяемых в системах отладки производительности параллельных программ. При этом делались попытки для улучшения восприятия общей картины изображать диаграммы не в виде прямой линии, а в виде цветного двумерного и трехмерного кольца. Был реализован двумерный вариант этого визуального языка параллельного программирования.
Наиболее важной смысловой единицей предлагаемого языка является процесс. Процесс описывается на уровне взаимодействия процессов и на внутреннем уровне. Каждый процесс имеет графический и текстовый вид отображения. Первый вид служит для описания коммуникационных связей с другими процессами (отображает порты и каналы) и текущего состояния процесса, отображаемое в виде аналога диаграмм Гантта. Это уровень взаимодействия процессов. Второй вид отображает внутренние структуры процесса и отображает, соответственно, внутренний уровень описания. Вся прикладная программа описывается в специальном графическом окне на уровне взаимодействия процессов в виде графа процессов. Узлом графа является единственный процесс. Для определения внутренней структуры процесса отведена текстовая страница.
Пользователь, используя такие понятия, как процесс, обмен, работа, ожидание, канал и др., и задавая времена работы и ожидания, должен определять основные характеристики процессов в специальных окнах. Затем визуально описываются коммуникационные связи между процессами. Уже на ранних этапах описания процесса начинается динамическое отображение его работы в виде модифицированных диаграмм Гантта. Дополнительные описания процесса как на внутреннем уровне, так и на уровне взаимодействия изменяют картину, отображающую его деятельность. (Предложенные идеи близки к идеям, описанным в [7] и [11].)
Таким образом, можно говорить о (незавершенных) попытках реализации общего подхода к визуализации при обеспечении всего цикла "проектирование, редактирование, выполнение, отладка, отладка эффективности".
Кроме всего прочего на системы визуального программирования может возлагаться еще и образовательная задача. Существует ряд моментов, когда целесообразно применение визуальных средств в изучении параллельного программирования. Визуальные средства полезно использовать в интерактивной связке с представлением генерируемого исходного текста или других аналогичных конструкций. Тогда, взаимодействуя с визуальным представлением, пользователь может видеть, как изменяется исходный текст.
Для простых случаев такое решение кажется избыточным, но оно становится полезным при росте сложности конструкций. Когда использование одних компонент определяется значением или фактом наличия других, может оказаться полезным показывать наличие зависимости между компонентами по применимости.
Примером реализации этих предложений может служить описываемый ниже мастер командных строк запуска DVM.
При создании систем визуализации параллельных вычислений важной задачей является осознание проектировщиком основных сущностей, подлежащих описанию в видах отображения. При этом для любого вида отображения очень большую важность представляет его потенциальная интерпретация. Проектировщик обязан понимать как пользователь будет рассматривать картинку, что при этом думать и как с ней взаимодействовать.
DVM по сути является параллельным расширением процедурных языков C и Fortran77, базирующимся на модель параллелизма по данным (Data-Parallel) [6]. Можно ожидать, что для прикладного программиста разработка DVM-программ будет не сильно отличаться от разработки последовательной программы.
В случае DVM распараллеливание программы заключается во внедрении в исходный текст директив, невидимых для обычного компилятора, но разворачиваемых DVM-конвертером в коммуникационные вызовы [6]. Распараллеливание цикла приведет к тому, что его витки будут выполняться параллельно на разных процессорах. В качестве тела параллельного цикла выступает тело цикла последовательного, написанного пользователем DVM.
Разработка программ для системы DVM часто осуществляется следующим образом:
Естественно, возможен случай, когда сразу пишется параллельный вариант DVM-программы. Тогда первые три пункта объединяются в один.
Параллелизм по данным означает, что в параллельной программе одни и те же действия осуществляются одновременно над множеством наборов данных. В DVM такими наборами данных являются фрагменты массивов, распределенные по виртуальным процессорам, а действиями -- тела параллельных циклов или фрагментов задачи, являющихся, в конечном итоге, наборами операторов на процедурных языках C и Fortran.
Главную сложность составляет точность DVM-специфицирования программы. Для такого распараллеливания от пользователя требуется четкое представление о функционировании программы и ее работе с данными. Необходимо ответить на ряд вопросов:
Взаимодействие с чисто графическими видами отображения с последующим внедрением результатов в текст программы может осуществляться несколькими способами. В первом варианте система автоматически генерирует требуемый текст и помещает его в файл. Пользователь видит исходный текст и имеет ограниченные возможности его редактирования. В этом случае главным способом написания программы является взаимодействие с графическими образами. В другом варианте пользователь может вызывать графические средства представления в процессе "ручного" создания программы для автоматизации рутинного написания незначительных фрагментов (чаще всего для генерации описания функций или классов). Наконец, возможен вариант, когда вызов графических средств инициируется пользователем, а взаимодействие с ними приводит к модификации уже существующего программного кода.
При распараллеливании DVM-программы от пользователя (программиста-прикладника) требуется точное понимание и описание ряда моментов, о которых в последовательном случае вопросов не возникает. Как уже указывалось, специфика разработки DVM-программ заключается в распараллеливании по данным. Дело не в том, что для распараллеливания по данным до настоящего времени не выработано адекватных видов отображения, а в том, что распараллеливаемая программа написана на процедурных языках. Постоянное переключение внимания с исходных текстов на графические образы, которые сами требуют знания тех же самых исходных текстов, порой является слишком сложной задачей.
Распараллеливание начинается с ответа на ряд четких вопросов и заканчивается точным описанием всего необходимого в терминах DVM-директив. Поэтому было предложено использовать не абстрактные графические образы, а диалоговые формы, аналогичные стандартно применяемым в различных системах тестирования и анкетирования. При этом исходный текст генерируется на основе информации, заданной пользователем. Таким образом можно говорить о кодировании с использованием мастера текста.
Мастерами принято называть диалоговые формы, последовательно запрашивающие у пользователя всю необходимую информацию и шаг за шагом приводящие его к получению результата. Название "Мастер" появилось при русификации Microsoft Windows и было поставлено в соответствие английскому слову "Wizard".
В нашем случае Мастером текста является форма, при взаимодействии с которой пользователь отвечает на вопросы путем выбора элемента из списка или указания конкретного имени. По окончанию работы с мастером пользователь получает текст, сгенерированный на основе указанной им информации. В мастере используются такие стандартные элементы управления, как флажки (CheckBox), переключатели (RadioButtons), окна редактирования, списки и т.д. Кардинальное различие между мастером текста и мастерами Windows заключается в том, что в мастере текста вся запрашиваемая (и запрошенная) информация отображается на одной форме, а вместо перехода вперед-назад используется появление-скрытие элементов управления.
Мастера используются для генерации DVM-команд, а также для задания ряда DVM-директив, требующих больших по объему спецификаций. К примеру, при описании распараллеливания цикла требуется явно указать все используемые переменные, размещенные на других процессорах.
При построении DVM-команды на компиляцию могут указываться ключи либо анализатора эффективности, либо динамического отладчика. Указание ключа включает соответствующий режим компилятора, но одновременное указание ключей из обеих групп является ошибкой и может привести к непредсказуемым результатам. По выбору одного из пунктов (Опций нет, Использовать анализатор, Использовать отладчик) происходит появление элементов управления для выбора ключей, допустимых в данном режиме (См. Рис.1).
Вопросы, задаваемые мастером, формулируются на естественном для пользователя языке и кратко характеризуют назначение элемента (пункта списка, флажка). Четкая детализация назначения элемента и описание результата применения позволяют избежать написания синтаксически заведомо неправильного кода.
Часто возникает ситуация, когда необходимость задания одних параметров -- "подчиненных" -- определяется значением других -- "главных". Эта зависимость визуально отображается появлением (сокрытием) элементов управления, задающих подчиненные значения, в зависимости от значений главных параметров.
Использование диалоговой схемы взаимодействия и привычных элементов управления не требует коренного изменения мышления или дополнительных навыков. Использование для разработки текстовых мастеров не отменяет написание кода пользователем, но заметно облегчает этот процесс. Также текстовые мастера могут использоваться в качестве связующего звена между редактором исходного текста и графическими схемами проектирования (скрывающими получаемый исходный текст).
К особенностям текстовых мастеров можно отнести их однонаправленность -- с помощью мастера можно описать все необходимые моменты, но представить на "языке" мастера уже написанный текст (особенно написанный вручную) порой довольно трудно. Хотя мастер лучше всего может обеспечить детальный анализ написанного. Здесь можно говорить как об использовании мастеров в отладке правильности программ, так и об использовании их в обучении программиста программированию для системы DVM.
В то же время, если рассматривать идею мастера немного шире -- не просто как средство поштучной генерации директив, а в роли полноправного участника написания текста (мастер разбирает уже написанный код и может обеспечить проверку программы на предмет синтаксических ошибок сразу на этапе написания DVM-кода), то мастера вполне могут обеспечить и поддержку отладки правильности. Система визуальной поддержки проектирования, таким образом, превратится в визуальную систему программирования, где одним из главных видов отображения будет представление исходного текста исходным же текстом, из окна редактирования которого вызываются мастера для непротиворечивого изменения (не приводящего к заведомо неправильным, по крайней мере на этапе компиляции, конструкциям) исходного текста. От традиционных визуальных систем, требующих рисования диаграмм, такая концепция отличается большей понятностью для человека, привыкшего к программированию на уровне исходного текста. По сути, мастера текста можно считать узкоспециализированными системами визуального программирования на основе SpreadSheet (большой таблицы) (См. Рис.2, 3, 4).
Расширяя зону влияния мастеров, можно (и нужно) расширить и набор их возможностей за счет использования элементов управления, основанных на более абстрактных графических образах, сохранив, в то же время, интерактивность и одновременность присутствия как визуального представления, так и исходного текста.
Чисто последовательная программа отличается от последовательной же программы, предназначенной для дальнейшего распараллеливания. На отладку эффективности такой программы может уйти больше времени, чем было бы потрачено на разработку последовательной программы сразу с учетом дальнейшего распараллеливания. То есть, несмотря на возможную последовательность, программа изначально должна разрабатываться как параллельная.
Как уже говорилось, визуальные средства проектирования и отладки правильности могут выполнять две противоположные задачи -- генерирование кода (исходного или объектного) на основе визуальных образов и, напротив, построение визуальных образов по исходному тексту. Разработка средств визуальной поддержки проектирования DVM-программ предполагает решение обеих этих задач. С одной стороны, в проектировании программы содержится ряд трудностей, которые разрешаются при помощи визуализации. С другой стороны, при отладке правильности визуализация необходима для обеспечения понимания функционирования программы и поиска неправильностей.
Одним из факторов эффективного распараллеливания является удачный выбор топологии процессоров. Существуют примеры систем, предусматривающих настройку физической топологии процессоров под конкретную задачу [10]. В других случаях предусмотрена настройка логической топологии. В визуальном виде такая настройка реализована в Grapnel. В общем виде конфигурирование логической топологии предусматривается в коммуникационных библитеках, например в MPI [14].
В DVM введена концепция виртуальных процессоров, на массив которых происходит распределение данных (фрагментов многомерных массивов). На виртуальных процессорах происходит выполнение витков параллельных циклов и фрагментов задачи. Под фрагментом задачи понимается вызов подпрограммы, выполяемый параллельно с другими действиями (скажем, с выполнением той же подпрограммы с другими аргументами).
Одномерный массив данных может быть распределен по одномерному массиву процессоров одним из нескольких способов: равномерно, блоками равной длины или блоками переменной длины. В многомерных массивах распределению может подвергаться каждое измерение. Кроме того, для эффективности вычислений бывает полезно обеспечить "выравнивание" -- распределение на один процессор определенных элементов различных массивов.
Естественно, для облегчения проектирования программ и отладки правильности были предприняты попытки разработать средства визуализации распределения данных. Перед средствами визуального распределения ставились, по сути, две противоположные задачи -- по взаимодействию с графическим образом генерировать исходный текст, а данные о распределении, имеющиеся в исходном тексте, в свою очередь отображать на графической схеме. В отличие от мастеров текста, в визуальных "распределителях" использовались абстрактные графические образы. В основе визуального распределителя лежит принцип непосредственного действия, когда манипуляции с графическим объектом приводят к изменению исходного текста, в данном случае к модификации DVM-директивы DISTRIBUTE. В качестве графического объекта выступала таблица, представляющая вектор или двумерный массив данных. Распределение (распиливание) массива по процессорам изображается более толстыми линиями, разграничивающими ячейки-элементы. По выбору элемента массива во всплывающей подсказке и специальном окне на форме визуального распределителя выводится информация о процессоре назначения. Созданные Е.М. Гусевой и А.А. Даеничевой экспериментальные прототипные системы показали возможность решения задачи визуализации распределения для одно- и двух-мерных массивов (См. Рис.5).
Наибольший интерес (и трудности у пользователей) представляет работа с многомерными массивами. Однако, отображение таких объектов уже само по себе является задачей очень нетривиальной [3]. Еще более сложной задачей является разработка взаимодействия пользователя с такими объектами. Однако принцип указания распределения для каждого измерения позволяет декомпозировать многомерное распределение в совокупность одно- и двух-мерных распределений с последующей взаимосвязной их визуализацией.
Система DVM позволяет разрабатывать программы, переносимые на уровне исходных текстов между экземплярами системы, развернутыми на различных платформах. Более того, предполагается, что пользователь будет вести отладку DVM-правильности на персональном компьютере, а счет осуществлять на параллельном вычислителе. К преимуществам такого подхода можно отнести простоту разработки программы на первых этапах за счет разработки программы как последовательной (со всеми последующими сложностями параллельной отладки) и наличие множества существующих сред разработки последовательных программ, со знакомым интерфейсом и подходящей пользователю лицензионной политикой. Кроме этого, такой подход экономит ресурсы параллельного вычислителя.
Недостатком такого цикла разработки является необходимость при малой модификации параллельного исходного текста осуществлять возврат на персональную рабочую станцию и прохождение заново части цикла разработки. Такое неизбежно происходит при отладке эффективности, когда для достижения параллельной эффективности необходимо модифицировать последовательный текст.
Более удобным для пользователя может оказаться распределенная среда, обеспечивающая единство разработки как на персональной рабочей станции, так и на параллельном вычислителе, тем более что отладку параллельной эффективности (а, порой, и параллельной правильности) возможно вести только на той платформе, на которой планируется вести счет, т.е. на параллельном вычислителе. Говоря точнее, пользователю нужна прозрачность перемещения между персональным компьютером и параллельным вычислителем исходного текста (и отладочной информации). Прозрачность может подразумевать и единый интерфейс взаимодействия.
Для достижения единства среды разработки возможны различные варианты проектирования:
Анализ литературы и наш опыт разработки средств визуализации для системы DVM показывает, что построение полноценной среды визуализации требует учета всех факторов, как теоретических, касающихся основ визуализации и параллельного программирования, так и чисто практических, включая проблемы организации счета в конкретном вычислительном центре.
