Подсистема наблюдения, отладки и управления параллельным
advertisement
Дипломная работа студента 524 группы Чугунова А.В. Подсистема наблюдения, отладки и управления параллельным счетом для объектно-ориентированной системы программирования Научный руководитель: Илюшин Александр Иванович 1 1.1 Введение О системе OST Целью системы OST (Objects-Space-Time) является существенное упрощение программирования задач и повышение эффективности их счета при работе на многопроцессорных вычислительных системах. Подход, предлагаемый для построения параллельных программных моделей в рамках проекта OST, отличается от распространенных в настоящее время подходов (в качестве примера можно указать проект DVM) тем, что в нем делается попытка «спрямить» путь от физической модели к программной реализации. Этот подход состоит в следующем. Пусть имеется физическая модель (область), которую здесь мы будем рассматривать в виде множества физических объектов, эволюционирующих и взаимодействующих друг с другом. В любом случае нам нужно отобразить это множество физических объектов на множество программно-аппаратных объектов. Традиционный путь состоит в том, что строится математическая модель для этой области и вычислительная схема, позволяющая получить численные решения для некоторого множества начальных и граничных условий. Более конкретно вычислительная модель чаще всего представляется в виде некоторого набора матриц, векторов, чисел и некоторого последовательного алгоритма обработки этих объектов для получения искомых решений. Далее строится параллельная программно-аппаратная модель (здесь под ней понимается множество программ, работающих на разных процессорах и взаимодействующих друг с другом). В случае прямого использования низкоуровневых средств типа MPI разбиение данных и последовательного алгоритма на относительно независимые части делается вручную, а в случае, например, DVM некоторые этапы такого разбиения делаются автоматически. Подчеркнем главное – при таком подходе изначально параллельная физическая модель сначала отображается на последовательную вычислительную модель, а затем решается обратная задача – последовательная вычислительная модель отображается на параллельную программно-аппаратную модель. Так как при переходе от параллельной физической модели к последовательному алгоритму вычислений теряется информация об изначальном параллелизме физической модели, то, основываясь только на анализе последовательного алгоритма, вообще говоря, невозможно восстановить исходный параллелизм для построения параллельной программно-аппаратной модели. Оказывается невозможным понять, почему, например, два конкретных действия выполняются последовательно. Возможно, порядок этих действий определяется сутью физической модели, а возможно это техническое решение автора последовательного вычислительного алгоритма. Именно поэтому попытки автоматического распараллеливания программ, которые делаются на протяжении последних тридцати-сорока лет, ощутимых результатов не принесли. В идеологии проекта OST естественно строить математические, вычислительные и программные модели независимо для частей физической модели, а затем с помощью средств OST , более или менее автоматически получать композицию из 1 программных частей, которая будет описывать физическую модель в целом. Тем не менее, подчеркнем, что для средств OST несущественен источник получения частей вычислительной модели. Это могут быть и вручную выделенные части последовательной вычислительной модели. Однако естественным будет «фотографическое» отображение частей физической модели и связей между ними на множество программно-аппаратных объектов, минуя стадию построения математической и вычислительной моделей для всей области в целом. Имеется в виду, что математическая и вычислительная модели должны описывать именно части физической модели и взаимодействие на границах (реальных или виртуальных) между ними, а не всю физическую модель в целом. Предлагается интеграция частей в сти ле натурного моделирования на уровне программно-аппаратных объектов, которые в данном случае играют роль виртуальных частей «натурной» модели. В основу решения указанных выше проблем в системе OST положены две идеи: 1. «ВРЕМЯ» практически во всех областях деятельности человека всегда использовалось и используется для упорядочения действий. «Время» в нашем случае — это разметка числами всех рассматриваемых действий. Единственное условие синхронизации - взаимодействие пары объектов разрешается только при «равенстве» их локальных времен. 2. «ПРОСТРАНСТВО», в котором расположено рассматриваемое множество объектов, является столь же широко и эффективно используемым понятием. В нашем случае для организации связей между взаимодействующими объектами используется понятие «близости» пары объектов в пространстве конкретного типа. Например, это может быть трехмерная решетка (шесть соседей) или кольцо (два соседа). Могут взаимодействовать (вызывать операции друг в друге) только «соседи» («близкие» объекты). Использование программных механизмов, основанных на этих идеях, позволяет «автоматизировать» синхронизацию и управление связями между объектами. Такая автоматизация дает два основных результата: 1. Локальность программирования для прикладного программиста. Он описывает алгоритм функционирования каждой подобласти локально, а функционированием модели всей области управляет система OST. 2. Система OST получает возможность автоматически распределять части вычислительной модели (объекты) по процессорам в стиле «подкачек» страниц в операционных системах. Результат – возможность оптимизации загрузки для всей МВС и упрощения для прикладного программиста. 1.2 О данной работе Система OST находится сейчас в разработке, поэтому нужны методы, позволяющие выявлять ошибки в работе системы. Отсюда вытекает задача наблюдения и отладки системы OST. 2 2 Постановка и понимание задачи 2.1 Понимание Понять задачу наблюдения можно по-разному: 1. Визуализация результатов счёта задачи 2. Визуализация работы системы, показ отладочной информации В первом случае задача программ — отображение результатов счёта задач в процессе счёта. В основном это относится к эволюционным задачам, когда имеет смысл следить за результатами в реальном времени, чтобы как можно раньше выявить возможные ошибки и недостатки алгоритма, не дожидаясь окончания его работы. Это отдельная сложная тема, но в данной работе она затронута не будет. Второй подход к пониманию задачи — отладка работы системы (системы OST), а не численного алгоритма. В данном случае это именно тот подход, который соответствует задаче наблюдения и отладки системы OST. В работе будет рассказано о создании программы наблюдения и отладки для системы OST, которая будет носить специализированный характер и опираться на особенности устройства системы. Система OST использует собственный подход к распределённым вычислениям, отличающийся о других. Поэтому создание специализированной программы оправдано как с точки зрения специфики системы, так и в образовательных целях. 2.2 Методы отладки В этом пункте сделаем некоторый обзор существующих систем отладки. Хотя программа, написанная в рамках этой работы, сильно от них отличается, будет полезным рассмотреть подходы, которые используются при отладке распределённых программ. Наблюдение и отладку работы системы можно проводить разными методами, например: ∙ Текстовая – Внутрисистемная – При помощи внешнего отладчика ∙ Специальные системы отладки параллельных приложений с графическим интерфейсом Текстовая отладка предполагает вывод отладочной информации в текстовом виде в консоль, удалённую консоль, или файл. Иногда такого подхода достаточно, к тому же он наименее сложен в реализации. Этот метод можно применять прямо внутри 3 задачи, не создавая и не используя никаких внешних приложений. Можно использовать внешние программы отладки. Например отладчик GDB для компилятора GCC позволяет производить отладку параллельных приложений. Но не всегда достаточно видеть только отладочные записи алгоритма, особенно, если в программе используется много переменных и много потоков или процессов. В этом случае уже тяжело заметить нужную информацию в большом объёме выводимых данных. Многие проблемы можно решить с помощью параллельных отладчиков, представляющих часть информации в графическом виде. Они позволяют в реальном времени следить за переменными всех потоков, используемых программой, могут они отображать и дополнительную информацию о состоянии системы (например, о загрузке процессорных ядер и памяти). Такие отладчики существуют во многих коммерческих и не только средах разработки. Например в Microsoft Visual Studio, Intellij IDEA, Eclipse (PTP). Visual Studio может предоставлять некоторую графическую схему потоков отлаживаемой программы. Выводить уровень загрузки процессора. Рис. 1: Visual Studio. графическая схема потоков В свободной среде разработки Eclipse также есть возможности отладки параллельных приложений с помощью PTP. Такие отладчики позволяют приостанавливать выполнение отдельных потоков и процессов или всей программы целиком. Коммерческие решения часто поддерживают и удалённую отладку программ. Отдельно можно упомянуть специализированные программы для отладки при4 Рис. 2: Visual Studio. уровень загрузки процессора Рис. 3: Рис. 4: Eclipse. Множества процессов (process sets) 5 Рис. 5: Eclipse Точки остановки (breakpoints) Рис. 6: Eclipse Точки остановки (breakpoints) Рис. 7: Структура Nvidia Nexus 6 Рис. 8: Nexus Platform Analysis Рис. 9: OpenCL debugger 7 ложений, выполняющихся с использованием GPGPU, то есть, мощностей графического процессора. Например, Nvidia Nexus с Nexus CUDA Debugger для отладки CUDA-приложений в среде Visual Studio, или Chronos OpenCL Debugger для отладки OpenCl-приложений. 2.3 Сравнение программы данной работы с другими программами отладки Как уже было сказано, существует множество различных систем отладки как текстовых, так и графических, которые поддерживают отладку параллельных программ. Они, в основном, универсальны в рамках тех языков программирования, на которые рассчитаны. Программа, разрабатываемая в данной работе отличается от других подобного типа тем, что ориентирована на отладку конкретной системы, поэтому учитывает только её особенности. Это позволяет сделать её несколько проще с точки зрения внутреннего устройства. Система OST имеет некоторую описанную структуру, что позволяет использовать её особенности для создания более простой системы. Но при этом такая система в некоторых случаях поможет больше узнать о ходе работы системы OST, чем это позволили бы сделать программы общего характера. Существуют программы отладки и для конкретных систем (как уже было сказано об Nvisia Nexus), но их тяжело сравнивать с данной программой, так как они специализированы для отладки GPGPU систем. 3 Цели и инструментальные средства Тема моей работы связана с наблюдением за конкретной системой. Написать программу, способную наблюдать за состоянием программы в частном случае проще, чем создать систему удалённой отладки общего назначения. Созвать универсальную систему для отладки только одной задачи было бы просто бессмысленно, если учесть сложность её создания. 3.1 Цели работы Создать систему наблюдения, управления счётом для вычислительных моделей в среде OST со следующими возможностями: ∙ Отображение мнемосхемы прикладной модели (объекты, связи, процессоры) ∙ Мониторинг прикладных объектов в процессе счета (значения существенных переменных, локальное время, процессорное время и т.п.) ∙ Управление счетом прикладной модели (запуск, приостановка/возобновление счета, вывод данных для оперативного анализа, изменение приоритетов для объектов и т.д.) 8 Этот список целей отражает направление работы, но это не означает, что конечная программа будет обладать жёстко заданным набором возможностей. Возможности программы зависят от самой системы OST, за которой она будет вести наблюдение, а также от полученного при разработке программы опыта, визуального удобства отображения данных, и пожеланий тех, кто разрабатывает исходную систему OST. 3.2 3.2.1 Инструментальные средства Язык Python В качестве основного языка программирования был выбран язык Python. Python — высокоуровневый динамический язык программирования. Основные свойства языка: ∙ Динамическая типизация ∙ Автоматическое управление памятью ∙ Поддержка разных парадигм программирования ∙ Высокая читаемость кода ∙ Удобный механизм обработки исключений Эталонная реализация языка Python — интерпретатор CPython. Он поддерживает большинство активно используемых платформ и распространяется свободно под лицензией, позволяющей использовать его в любых приложениях, включая проприетарные. Python активно развивается. 3.2.2 Выбор библиотеки. Библиотека Qt Qt (произносится «кьют») — кросс-платформенный инструментарий разработки ПО на языке С++. Есть интерфейсы для разных языков программирования, в том числе, для языка Python. Существуют версии библиотеки для различных платформ (в том числе, для некоторых мобильных). Qt включает в себя классы для разработки программного обеспечения начиная с элементов графического интерфейса и заканчивая работой с сеть и базами данных. Прежде чем выбрать библиотеку Qt в качестве основной, нужно было проанализировать основные известные библиотеки, подходящие для вывода графики. Были на практике проанализированы возможности нескольких библиотек: ∙ Pygame ∙ Pyglet 9 ∙ VPython ∙ WxWidgets ∙ Qt Ознакомление со многими другими библиотеками прошло теоритически, на основе их документации и заявленных возможностей. Библиотеки Pygame, Pyglet и VPython рассчитаны, в основном, на вывод графики программными средствами, либо с помощью OpenGL, а также, поддерживают некоторые мультимедийные функции. Но, как выяснилось во время работы над программой, для данной задачи этих функций не достаточно, ведь для более удобного взаимодействия с программой нужны элементы графического интерфейса, такие как кнопки, меню, некоторая система работы с событиями, и т.п. А данные библиотеки таких возможностей не имеют. Поэтому было решено рассмотреть библиотеки, рассчитанные на создание графического интерфейса, такие как WxWidgets, GTK, Qt и прочие. Эти библиотеки заведомо обладают достаточным функционалом для создания удобного интерфейса. Но здесь была возможна другая проблема, а именно, они могли недостаточно хорошо поддерживать работу с графикой. Библиотека Qt была выбрана как обладающая лучшим функционалом и поддерживающая большее число платформ. Qt, как и её интерфейс для Python — PyQt, работает и в Windows и в Linux. Qt имеет широкий набор подходов для работы с графикой (по крайней мере на двумерном уровне), причём библиотека поддерживает и OpenGL ускорение. Причём есть возможность не только рисовать графические примитивы, но и обрабатывать поступающие к ним события, такие как нажатие кнопки мыши. 4 Задачи и решения При создании программы мониторинга возникли следующие задачи: ∙ Подключение к системе OST для обмена данными ∙ Перехват вызовов функций ∙ Перехват изменения значений переменных ∙ Отображение мнемосхемы задачи ∙ Отображение отладочной информации конкретных объектов ∙ Отображение уровня загрузки системы 10 4.1 Подключение в системе Для мониторинга системы OST нужно вначале некоторым образом к ней подключиться, чтобы иметь возможность принимать и передавать данные между системой и программой мониторинга. Система OST внутри для удалённых вызовов использует библиотеку PYRO. Поэтому для подключения к системе и мониторинга можно было использовать её же. Причём был необходим двусторонний канал обмена данными, для того, чтобы можно было посылать управляющие сигналы системе и принимать от неё данные, как по запросу монитора, так и в автоматическом режиме от системы к монитору для отображения изменений параметров системы в реальном времени. Поэтому, необходимо, чтобы не только программа мониторинга подключилась к системе OST в одностороннем порядке, но и чтобы система OST подключилась к монитору. Эту задачу удалось решить при помощи передачи монитором удалённой ссылки на себя во время подключения к системе OST. А так как каждый прикладной объект должен передавать свою информацию отдельно, то передать удалённую ссылку на программу мониторинга можно всем объектам. Подробнее об этом будет рассказано в описании работы программы. 4.2 Перехват вызовов функций и изменения значений переменных Для наблюдения за состоянием системы нужны возможности перехвата вызовов функций и изменения значений переменных. Перехват вызовов нужен, например, для отображения удалённых вызовов между соседями в топологии системы, а перехват изменения значений переменных — для мониторинга основных переменных (например локального времени объектов). Если взглянуть на проблему с точки зрения программирования, то задача сводится к необходимости выполнить какое-либо действия до и после вызова функции или обращения к переменной, при этом не меняя код самой функции. В языке Python есть несколько методов решения задачи. Рассмотрим два из них — декораторы и дескрипторы. 4.2.1 Декораторы Декораторы в языке Python — удобный способ изменения поведения функции (или целого класса). Его синтаксис выглядит так: @f1 def f(x): ... что эквивалентно 11 def f(x): ... f = f1(f) То есть имя функции f теперь соответствует f1(f), и при каждом вызове f(x) будет реально происходить вызов f1(f(x)). Таким образом можно изменить поведение функции при вызове, например для подачи сигнала программе мониторинга. Конечно, реализация этого метода на практике далеко не так проста – нужно, например, очень аккуратно следить за списком аргументов функции f и правильно его передавать, многие нюансы связаны со спецификой конкретной задачи, но не будем сейчас подробно на этом останавливаться. Роль декораторов не ограничивается управлением функций. С их помощью можно управлять и целыми классами. Например, для добавления в класс новых функций можно использовать механизм наследования, а можно использовать декоратор. Выбор метода зависит от конкретной программы. Приведём пример использования декоратора для добавления в класс новой функции: def f(self): ... def decor(cls): cls.f = f return cls @decor class A: ... Теперь к классу A добавлена функция f. В итоге эффект такой же, как и в механизме наследования от родительского класса, имеющего функцию f. Но бывают ситуации, когда наследование по тем или иным причинам лучше не использовать. В описании работы программы будет приведён один такой пример. Пример использования декоратора класса, приведённый выше — это только одно из возможных его применений. Его можно использовать для управления экземплярами класса, отслеживания вызовов атрибутов и многого другого. 4.2.2 Дескрипторы Дескрипторы описывают протокол доступа к атрибутам объекта или класса. Они позволяют переопределить методы доступа к объекту. Формально, если для объекта определены методы __get__(), __set__() и __delete__(), то он является дескриптором. Здесь метод __get__() вызывается при обращении к объекту, __set__() — при установке значения, a __delete__() — при удалении. Рассмотрим пример: class desc(object): def __get__(self, inst, cls=None): 12 return self.x def __set__(self, inst, val): self.x = val class A(object): x = desc() def __init__(self): self.x = 0 Здесь атрибут x класса A — дескриптор. Его можно использовать как обычную переменную, но при этом для доступа будут использоваться функции __get__() и __set__(). Хотя в данном примере поведение x не будет отличаться от поведения обычной переменной, но в реальных задачах это поведение можно менять для достижения необходимых целей. Таким образом, если в некотором классе атрибут сделать дескриптором, то можно полностью контролировать доступ к нему. Например, для сообщения программе мониторинга об изменении значения переменной. Здесь снова стоит заметить, что в конкретной задаче дескрипторы используются более сложным образом, а для перехвата вызовов функций приходится комбинировать оба подхода (дескрипторы и декораторы). Это вызвано тем, что речь здесь идёт не о перехвате обычных функций, а о перехвате функций-членов класса, что осложняет задачу, так как нужно различать, какой именно экземпляр класса вызвал функцию. Различать экземпляры нужно по двум причинам. Во-первых, потому, что вызов функции затрагивает другие атрибуты и методы конкретного экземпляра, и если экземпляры не различать, код может работать неверно. Во-вторых, нужно каким-то образом различать, какой именно объект (в терминологии системы OST) совершил вызов функции, чтобы передать эту информацию программе мониторинга. 4.3 Отображение мнемосхемы задачи Отображение мнемосхемы задачи — составная проблема. Одна её часть — непосредственно графическое представление объектов, связей между ними, отображение значений переменных в удобном для восприятия виде. Сюда можно включить возможность навигации по области отображения объектов, то есть: увеличение/уменьшение масштаба и перемещение по области, ведь при большом числе объектов может оказаться невозможным разглядеть данные, отображаемые на схеме внутри объекта. Другая часть проблемы — метод расположения схемы на экране. В общем случае топология прикладной задачи заранее неизвестна, поэтому нет возможности определить разумный способ эту топологию изобразить. Даже для известных случаев топологий найти эстетически–удобный способ отображения на экране сложно. Если же рассматривать общий случай, то на выходе получается задача об изображении произвольного графа, а эта задача относится к классу NP–полных. Для этой проблемы есть как минимум два решения. 13 Можно использовать простые методы, отображающие граф по заранее заданному шаблону: ∙ Можно мысленно нарисовать на области отображения сетку и расставлять вершины графа √ по узлам этой сетки, выбрав число вершин графа в строке, например, как 𝑁 , где 𝑁 — число объектов счёта. ∙ Либо можно расположить вершины графа равномерно по окружности, радиус которой положить равным 𝑁𝜋𝑎 , где 𝑁 — число объектов, 𝑎 — размер одного объекта. Для простых топологий и небольшого числа объектов эти способы могут работать вполне удачно, особенно в случае расстановки по окружности. Другой способ — использование приближённых методов изображения графов. Например — силовые (Force–based) алгоритмы. Это целый класс алгоритмов, суть которых сводится к тому, чтобы рассматривать вершины графа как некоторые частицы (возможно зараженные), а рёбра графа — как пружины. То есть, получается некоторая физическая система с электростатическим отталкиванием между вершинами и упругим притяжением между ними за счёт пружин. Эту систему действующие силы стремятся привести в положение равновесия. Конечно, этот способ не простой и содержит много проблем на пути к его реализации. Одна из проблем — достижения равновесия. Может случиться так, что система будет бесконечно совершать колебания и никогда не придёт к равновесию. С этой проблемой можно бороться, вводя трение для вершин графа — это поможет избежать бесконечных колебаний. Другая проблема — локальные положения равновесия, соответствующие локальным минимумам энергии системы. Здесь однозначного решения нет, но правильный выбор законов взаимодействия помогает избавиться от этой проблемы в большинстве случаев. Один из способов — использование квадратичного закона упругости пружины вместо линейного. Третья проблема — получение эстетически-подходящего внешнего вида графа. Здесь важен правильный подбор физических законов для получения необходимых расстояний между вершинами. Четвёртая проблема — трудозатраты на алгоритм. Здесь надо учитывать не только сложность каждого шага, но и общее число шагов. Если учесть, что необходимо рассчитывать электростатическое отталкивание для каждой пары вершин, то для графа с n вершинами сложность каждого шага будет пропорциональна 12 𝑛(𝑛 − 1), то есть её можно оценить как 𝑂(𝑛2 ). Общее число шагов, например, для метода наискорейшего спуска будет пропорционально числу вершин n. Таким образом, общая сложность алгоритма будет 𝑂(𝑛3 ). Для большого числа вершин графа этот алгоритм может оказаться очень трудозатратным. Есть способы решения этой проблемы, суть которых состоит в ограничении радиуса взаимодействия вершин. Но для рассматриваемой задачи на данном этапе эта проблема не так критична, так как счёт системы OST на очень большом числе объектов пока не запускался. 14 Рис. 10: Расположение объектов по шаблону Рис. 11: Схема силового алгоритма 15 4.4 Отображение отладочной информации Помимо отображения схемы прикладной задачи и переменных бывает нужна возможность выводить произвольную отладочную информацию в текстовом виде для выявления ошибок в алгоритме или работе системы, так как не всегда можно увидеть проблему, видя лишь графическую схему работы системы. Причём отладочную информацию полезно видеть раздельно для каждого прикладного объекта, а не общим потоком, ведь счёт объектов идёт параллельно, и информация будет смешиваться. Для решения этой задачи можно использовать связь каждого прикладного объекта с программой мониторинга, передавая по ней отладочный вывод. Подробнее это будет рассказано в описании работы программы. 4.5 Отображение загрузки системы В процессе счёта задачи на системе OST полезно видеть уровень загрузки операционной системы каждым прикладным объектом. Это может быть нужно, например, для того, чтобы понять, происходит ли реально в данный момент счёт, или система простаивает. Также это может помочь определить, что счёт задачи завершился. Для решения задачи можно создать функцию, которая возвращает уровень загрузки системы. В Python есть функция, позволяющая узнать время, которое операционная система занята пользовательскими приложениями (user time), и время, занятое самой системой (system time). Периодически вызывая подобную функцию, можно узнавать искомый уровень загрузки. 5 Описание работы программы В предыдущем разделе мы рассмотрели задачи, решение которых нужно для реализации поставленной цели. Теперь рассмотрим некоторые подробности этой реализации и описание принципов работы программы мониторинга. Схему работы программы можно разбить на несколько частей, которые соотносятся с задачами предыдущего раздела: ∙ Подключение к системе OST ∙ Отображение мнемосхемы задачи ∙ Перехват вызовов функций ∙ Перехват изменения значений переменных ∙ Отображение отладочной информации 16 5.1 Подключение к системе OST Как уже было сказано выше, для подключения к системе OST используется библиотека PYRO. Для подключения к системе нужно указать её IP-адрес либо имя (host) машины. После этого программа мониторинга подключается к классу OST_Main (ос- Рис. 12: Окно подключения к системе OST новному управляющему классу) системы OST. Остановимся подробнее на процессе подключения. Так как класс OST_Main не обладает никакой информацией о системе мониторинга, то было необходимо ему эту информацию предоставить. Для этого был создан декоратор (см. раздел «Задачи и решения»), добавляющий необходимую функцию для работы с системой мониторинга. Эта функция передаёт в программу мониторинга информацию обо всех прикладных объектах системы OST, информацию о соседстве объектов, а также, удалённые ссылки на них. Для класса прикладного объекта системы OST также был создан специальный декоратор. Этот декоратор предоставляет набор функций для взаимодействия программы мониторинга с каждым из объектов системы OST. Именно связь с объектами системы должна быть двусторонней, как говорилось в разделе «Задачи и решения». Поэтому декоратор объекта устроен так, чтобы после подключения к нему программы мониторинга, каждый объект подключается к ней сам. Сделаем небольшое отступление по поводу декораторов класса. В процессе работы над программой для добавления новых функций в уже написанные классы системы OST можно было использовать, по крайней мере, два метода: механизм наследования и механизм декораторов. В процессе разработки выяснилось, что механизм наследования для данной системы на практике работает медленнее. Это может быть вызвано тем, что при его использовании поиск нужной функции в дереве наследования занимает некоторое время, что при частых вызовах может замедлить производительность. Теперь рассмотрим процесс подключения к системе OST. Для того, чтобы рассматриваемая программа мониторинга могла подключиться к системе OST, нужно импортировать специальный модуль и поставить соответствующие декораторы перед классами OST_Main и прикладного объекта. О перехвате вызовов и значений переменных будет рассказано в следующих пунктах. 17 5.2 Отображение мнемосхемы задачи После завершения этапа подключения программа мониторинга обладает данными об объектах системы OST и их соседстве. Программа отображает объекты на экране в виде квадратов, а связи вежду объектами — в виде стрелок. Область отображения объектов можно масштабировать с помощью соответствующих пунктов меню программы или сочетаний клавиш, а также по ней можно перемещаться с помощью мыши (по принципу drag&drop). Рис. 14: Крупный план Рис. 13: Общий план Внутри каждого квадрата, изображающего объект, отображается следующая информация об этом объекте: ∙ Локальное время объекта ∙ Индикатор загрузки системы данным объектом ∙ Возможно, некоторые другие заранее заданные переменные По правому клику мыши на объекте происходит вызов окна с выводом в реальном времени отладочной информации по данному объекту. Стрелки, отображающие связи между объектами, мигают при прохождении удалённых вызовов между объектами. Подробнее о выводе информации о каждом объекте будет рассказано далее. 5.3 Перехват вызовов функций Перехват вызовов функций используется в программе мониторинга для двух целей: 18 ∙ Для получения информации об удалённых вызовах функций в соседях (в смысле топологии задачи в системе OST) ∙ Для получения информации об изменении локального времени каждого объекта В первом случае речь идёт о перехвате вызовов между соседними объектами системы, с помощью которых они обмениваются данными. Знание информации о том, как происходят эти вызовы, помогает судить о п равильности работы системы OST. Для перехвата этих вызовов был создан декоратор. Этот декоратор отправляет программе мониторинга информацию о том, какой объект совершил удалённый вызов, и какой объект был при этом вызван. После получения информации монитор отображает произошедший вызов миганием соответствующей стрелки на схеме задачи. Для перехвата этих вызовов был создан декоратор. Этот декоратор отправляет программе мониторинга информацию о том, какой объект совершил удалённый вызов, и какой объект был при этом вызван. После получения информации монитор отображает произошедший вызов миганием соответствующей стрелки на схеме задачи. Вторая цель перехвата функций – получение информации об изменении локального времени объекта. В этом случае можно перехватывать функцию set_XYZT(), которая отвечает за продвижение локального времени объекта в системе OST. В процессе работы над программой мониторинга стало понятно, что проще получать информацию о локальном времени объектов, перехватывая изменение значения переменной локального времени (об этом будет подробнее рассказано в следующем пункте). Но подход с перехватом функции может пригодиться для определения времени, затрачиваемого на вызов функции продвижения локального времени объекта. Для возможности перехвата вызовов удалённых функций надо поставить перед ними соответствующий декоратор. 5.4 Перехват изменения значений переменных Перехват изменения значений переменных можно использовать как для получения информации об изменении локального времени объектов (о чём было сказано ранее), так и для отображения значений других переменных, важных для конкретной прикладной задачи. Для перехвата значений переменных используется механизм дескрипторов (см. «Задачи и решения»). А именно, используется функция __set__() дескриптора, чтобы передать программе мониторинга новое значение переменной времени. После этого новое значение отображается на схеме внутри квадрата, изображающего объект. Для возможности перехвата локального времени нужно включить в тело класса дескриптор, написанный специально для этого. Для перехвата остальных переменных служит другой дескриптор. Здесь помимо простого включения в тело класса нужно задать имя, которое будет отображаться 19 Рис. 15: Крупный план объекта при показе значения переменной. Например: variable = M_variable() variable.name = "name" 5.5 Отображение отладочной информации Для вывода отладочной информации об объекте была написана специальная функция, которая принимает текстовую строку и передаёт её монитору для отображения. Причём выводить можно не только простой текст, но и html, то есть, фактически, есть способ выводить даже изображения. Отладочная информация конкретного объекта показывается в реальном времени после нажатия правой кнопкой мыши на изображении объекта. После нажатия появляется отдельное окно, в котором информация и отображается. Для прекращения вывода достаточно закрыть это окно. 5.6 Отображение уровня загрузки системы Для отображения уровня загрузки операционной системы счётом задачи была написана функция, которая использует средства языка Python, о которых говорилось в разделе «Задачи и решения». Эта функция включена в декоратор прикладного объекта. Раз в секунду программа мониторинга вызывает эту функцию в каждом объекте и отображает уровень загрузки системы в виде цветной полоски в нижней части квадрата, соответствующего на схеме данному объекту. 20 Рис. 16: Отладочная информация объекта 6 Заключение В рамках данной работы была написана программа со следующими возможностями: ∙ Подключение к системе OST, запуск счёта ∙ Отображение мнемосхемы задачи (объекты, связи) ∙ Перехват удалённых вызовов для их отображения (возможно, измерения времени прохождения) ∙ Перехват значений переменных для отображения локального времени и пользовательских переменных ∙ Отображение отладочной информации по каждому объекту ∙ Отображение уровня загрузки системы (относительное системное время) Программа была опробована на задаче умножения матриц в системе OST. 6.1 Количественные данные Рассмотрим некоторые количесивенные аспекты реализации. 21 Итоговая программа заняла около 1130 строк, из которых 138 строк отвечают за декораторы, дескрипторы, и функции для системы OST. Для мониторинга в систему надо добавить: ∙ 6 служебных строк ∙ по одной строке на каждую перехватываемую функцию ∙ по 2 строки на каждую перехватываемую переменную ∙ для вывода отладочной информации нужно вызывать специальную функцию Теперь рассмотрим влияние работы прораммы мониторинга на время счёта. размер матрицы 600×600 600×600 400×400 400×400 400×400 число потоков 4 8 4 8 16 без мониторинга 21,9с 22с 6,65с 6,62с 7с с мониторингом 22,35с (102%) 22,67с (103%) 6,83с (104,1%) 7,14с (107,9%) 8,3с (118,5%) Из этой таблицы видно, что программа мониторинга несколько замедляет счёт, причём влияние тем больше, чем чаще происходят перехваты вызовов фукция и значений переменных. 22 Список литературы [1] Марк Лутц Изучаем Python, третье издание. — Символ-Плюс 2009. [2] Mark Lutz Learning Python, Fourth Edition. — O’Rielly 2009. [3] Mark Summerfield Rapid GUI Programming with Python and Qt. — Prentice Hall 2007. [4] Shalabh Chaturvedi Python Types and Objects. — 2009. [5] Shalabh Chaturvedi Python Attributes and Methods. — 2009. [6] David Beazley Inside Pyhton GIL. [7] Mark Pilgrim Dive into Python. — 2001-2004. [8] Mark Pilgrim Dive into Python 3. — 2001-2010. [9] Will McGunan Beginning game development with Python and Pygame. — Apress 2007. [10] Официальная документация языка Python. [11] Thomas M. J. Fruchterman, Edward M. Reingold Graph drawing by Force-directed placement. — 1991. [12] Daniel Tunkelang A numerical optimization approach to general graph drawing. — 1999. [13] Документация PYRO на http://pyro.sourceforge.net/manual/PyroManual.html [14] http://stackoverflow.com/questions/276281/cpu-usage-per-process-in-python 23
