Визуальные средства создания, отладки и анализа программ для параллельных вычислений (стр. 1 )

Нижегородский государственный университет им. Лобачевского

Лаборатория ITLab

Визуальные средства создания, отладки и анализа программ для параллельных вычислений

Выполнили:

Гусева Мария

Минаев Дмитрий

Ткаченко Роман

Руководитель:

Лабутина Анна

2007 г.

Введение.. 3

Разработка визуальных средств.. 4

Основные задачи, проблемы.. 4

Немного истории.. 5

Обзор некоторых средств online анализа.. 6

Система визуализации и отладки параллельных программ Panorama (Visualization and debugging tool for parallel programs Panorama). 6

Обзор Panorama. 6

Общее впечатление. 8

Paradyn – средство для анализа больших параллельных программ (Paradyn Parallel Performance Tool for measuring the performance of large-scale parallel programs). 8

Обзор Paradyn.. 8

Общее впечатление. 11

Falcon – система онлайн мониторинга и управления для параллельных программ.. 11

Обзор Falcon.. 11

Общее впечатление. 12

Системы визуального программирования.. 13

Code. 13

TRAPPER.. 14

DEEP.. 15

Converse. 15

Heterogeneous Network Computing Environment. 15

The Phred.. 17

Система PCG... 17

Offline анализ параллельных программ.. 21

Jumpshot-4.. 21

Лог-файлы и библиотека MPE.. 22

Библиотека MPE.. 22

Создание лог-файлов средствами MPE.. 23

Пример 1 (HelloWorld_parallel_1). 24

Анализ лог-файлов.. 25

Пример 2 (HelloWorld_parallel_2). 26

Пример 3 (QuickSort_parallel). 28

Заключение.. 31

Список литературы... 32

Введение

Развитие параллельного программирования шло подобно развитию программирования в целом. Первые низкоуровневые языки программирования постепенно вытеснялись все более наглядными и понятными для человека языками. То же самое можно увидеть и в развитии параллельного программирования. Изначально оно было нацелено на решение трудоемких задач, и соответствующее программное обеспечение было сфокусировано, прежде всего, на высокой эффективности. Но с другой стороны, эта трудоемкость и сложность решаемых задач определила сложность и самого программирования. Таким образом, процесс создания эффективных параллельных программ становился неэффективным сам по себе. В связи с быстрым развитием параллельных вычислений и их все большей доступностью, при создании программного обеспечения для параллельных систем большое внимание стало уделяться тому, чтобы программисту было проще написать, понять и отладить параллельную программу. Самый простой способ сделать что-либо более понятным – сделать это наглядным, поэтому важнейшим инструментом здесь стали средства визуализации. Не секрет, что хороший график, диаграмма или рисунок могут содержать такой же объем информации, что и сотни и тысячи строк текста. Однако и сам процесс визуализации не является простым. С начала 90-х годов ведутся активные разработки и исследования в этом направлении, но до сих пор остаются неразрешенными многие вопросы. Чем мощнее становятся параллельные системы, тем сложнее становится программирование и тем труднее его визуализировать.

Разработка визуальных средств

Основные задачи, проблемы

Средства визуализации параллельных программ принято классифицировать по двум категориям: системы визуального программирования (Visual Programming) и системы визуализации программирования (Program Visualization), иногда также выделяют средства визуального представления вводимой и выводимой информации. И если последние облегчают непосредственное использование параллельной программы и ее понимание пользователем, то средства, относящиеся к первым двум категориям, призваны повлиять на процесс самого программирования.

Средства визуального программирования (языки визуального программирования) позволяют создавать программы с помощью различных графических средств. Чаще всего программа представляется в виде графа, отображающего потоки данных или потоки управления.

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

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

Средства визуализации могут использовать самые различные методики отображения данных, и если в целом понятно, как отображать, то гораздо более серьезной проблемой становится поиск того, что отображать. Таким образом, второй важной задачей является сбор данных и связанный с ним способ организации работы визуального средства. Существует два различных подхода: исторически первый и более простой в реализации off-line анализ, а также более прогрессивный и информативный on-line анализ.

Off-line анализ подразумевает «посмертную» обработку данных, то есть после непосредственного выполнения параллельной программы. Чаще всего для этого используется трассировка. Она основывается на том, что в процессе выполнения программы создается так называемая трасса – журнал, содержащий информацию о ходе выполнения программы. Сбор информации происходит в конкретных участках программы, которые определяются автоматически или самим пользователем. Существуют средства (например, Vampir), позволяющие исследовать отдельные участки программы, не анализируя всю программу в целом. Обычно записи включают в себя временные отметки, количество задействованных процессоров, взаимодействие процессов между собой и другую информацию. После завершения программы файл трассы сохраняется для последующего изучения. Современные средства визуализации на основе файла трасс позволяют строить различные схемы, иллюстрирующие состояние программы в каждый момент времени, диаграммы, отображающие статистику работы параллельной программы. Кроме того, имеется возможность «проиграть» трассу, то есть эмулировать работу параллельной программы на основе собранных о ней данных. Результаты эмуляции могут быть представлены динамически, с помощью анимации.

On-line анализ основан на «живом» взаимодействии с программой. Это анализ непосредственно в ходе выполнения программы. Такой способ выглядит более эффективным по сравнению с off-line, но он и более сложен в реализации. Главной проблемой является тот факт, что такие средства анализа не могут не влиять на саму программу. Конечно, и в процесс трассировки мы вмешиваемся в ход выполнения программы, но все же это воздействие неизмеримо меньше, чем возможное влияние on-line средств. Стремясь сократить вмешательство таких инструментов, приходится жертвовать какими-то анализируемыми характеристиками. Важной задачей является найти баланс между вмешательством в выполнение программы и сбором необходимой для визуализации информации. Наибольшую проблему представляет поиск такого способа сбора информации.

Немного истории

Первые визуальные средства для параллельного программирования появились еще в 80-х годах. Сначала это были средства визуализации, ориентированные на графическое отображение алгоритмов вычислений (например, одна из первых систем The BALSA Brown university ALgorithm Simulator and Animator, а также BALSA-II, разрабатываемые в 1984-88 годах). В конце 80-х годов появляются первые системы визуального программирования (например, The CODE Computation-Oriented Display Environment, 1989), которые явили собой абсолютно новый подход к программированию вообще, включая и параллельное программирование. С конца 80-х годов достаточно активно развивались как языки визуального параллельного программирования, так и визуальные средства отладки и анализа параллельных и распределенных программ. На середину 90-х годов пришелся расцвет визуализации программного обеспечения параллельных вычислений, появилось большое количество систем, хотя и принципы их работы часто были очень схожими. В последующие годы можно наблюдать замедление темпов развития в этой сфере. Все разработки основаны на старых идеях, зачастую не соответствуя современным супервычислениям.

Обзор некоторых средств online анализа

Система визуализации и отладки параллельных программ Panorama (Visualization and debugging tool for parallel programs Panorama)

Department of Computer Science and Engineering

University of California, San Diego

Обзор Panorama и порядок использования

Создатели Panorama определяют ее «скорее как online инструмент, чем post - mortem». Panorama позиционируется как независящий от конкретной архитектуры машины отладчик, так как ее работа основана на использовании базового отладчика произвольной параллельной системы. Panorama использует средства базового отладчика (такие как контрольные точки или контрольные данные) на низком уровне с целью получения данных для визуального представления работы параллельной программы на более высоком уровне. Ясно, что стандартные отладчики для различных систем могут сильно отличаться организацией и возможностями. Поэтому в Panorama используется специальная модель взаимодействия с низкоуровневым отладчиком. Суть ее состоит в том, что функции общего назначения отделяются от остальных специфических функций данного отладчика, и полученный в результате код легко адаптируется для потребностей Panorama.

Однако если нам важно знать, например, время выполнения каких-то фрагментов кода, использование системы в онлайн режиме не даст никаких значимых результатов, так как, во-первых, в процессе отладки события могут происходить в несколько ином порядке, нежели при непосредственном запуске. Во-вторых, время выполнения, естественно, будет сильно отличаться от реального. В таком случае рекомендуется сначала в режиме логирования создать трассу. После чего в replay-режиме происходит отладка программы с одновременной визуализация на основе созданного log-файла, при этом все действия происходят именно в том порядке, как это было на самом деле, а в качестве данных для визуализации (таких, как время) используются данные лог-файла.