Исследование межплатформенной переносимости прикладных программ

Автор: Пользователь скрыл имя, 23 Августа 2011 в 13:30, автореферат

Краткое описание

Актуальность темы: Теоретическое и экспериментальное исследование вопросов переносимости прикладных программ (ПП) представляется достаточно актуальным. Эта актуальность тем выше, чем выше уровень гетерогенности среды и чем больше масштаб задачи, для которой создается прикладная программа. Как известно, в настоящее время большое развитие получает так называемая GRID-архитектура, представляющая собой распределенную гетерогенную высокопроизводительную среду.

Файлы: 1 файл

Автореферат Межплатформенная переносимость.doc

— 177.50 Кб (Скачать)

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

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

     Во  второй главе "Переход на открытое ПО и анализ проблем переносимости ПП при решении малых задач”. Обсуждается разница между открытым и закрытым программным обеспечением, преимущества открытого ПО, соотношение понятий «переносимого программного обеспечения» и «программное обеспечение с открытым кодом». На конкретном примере задач системы управления городским хозяйством  
(г. Москва) показаны тенденции и особенности переносимости малых задач, не требующих методов параллельного программирования и высокопроизводительных ресурсов. Проведен анкетный опрос около 50 разработчиков, решающих самые разнообразные задачи системы управления городским хозяйством и статистическая обработка полученных данных. Выяснялись решаемые задачи, анализировались программно-аппаратные платформы, используемые языки программирования и динамика их изменения. Наблюдается многообразие программно-аппаратных платформ, для которых разрабатываются программы. Растет число операционных систем семейства Unix, основанных на POSIX.  В диссертации приведен набор полученных номограмм, из которого следует актуальность проблемы переносимости ПП для задач городского управления, показано, что основным языком программирования служит язык Си (или Си++) и выработаны рекомендации по написанию переносимых ПП с учетом постоянного обновления стандартов POSIX. Сделанные рекомендации оформлены в виде Технических условий, принятых Заказчиком (Московским комитетом по науке и технологиям). Существо рекомендаций состоит в том, что :

  • программа должна удовлетворять стандарту на язык Си [ISO/IEC 9899] или Си++ [ISO/IEC 14882]. Использование нестандартизованных расширений снижает переносимость;
  • все вызываемые в программе функции должны быть либо описанными в ней самой, либо описанными в стандарте [POSIX 1003.1], последняя редакция которого включает в себя стандартную библиотеку языка Си [ISO/IEC 9899]. Включение прототипов вызываемых извне функций должно осуществляться через стандартные заголовочные файлы.
  • допустимо использование любых переносимых библиотек, доступных в открытых кодах, реализованных только на основе POSIX и других открытых  библиотеках, основанных на POSIX. 

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

     В третьей главе "Особенности проблем переносимости ПП при решении крупномасштабных задач" исследуются особенности создания переносимых ПП при решении крупномасштабных задач из области вычислительного эксперимента, требующих высокопроизводительных ресурсов и методов параллельного программирования.

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

     В первую очередь потребовалось пересмотреть классическую модель вычислительного  эксперимента, что и сделано впервые  в данной работе. В данной главе  описан результат  синтеза модели вычислительного эксперимента (по А.Н.Самарскому) с моделью среды открытой системы (см. Рис.3).

       

Рис.3 Синтез модели вычислительного эксперимента и эталонной модели среды открытой системы

     В классической модели вычислительного  эксперимента присутствовали два компонента: прикладная программа и компьютер. Не рассматривалась проблема переносимости прикладной программы на различные платформы, не рассматривалась проблема удаленного доступа к вычислительным ресурсам, в том числе к распределенным. Действительно, еще некоторое время назад эти задачи можно было рассматривать как технические и непринципиальные для вычислительного эксперимента. Однако, как было показано в главе 1, решение крупномасштабных задач требует таких вычислительных ресурсов, которые в полной мере могут быть предоставлены в настоящее время лишь в распределенной вычислительной среде, в которую входят, например, кластеры и суперкомпьютеры. Вычислительный эксперимент также часто должен включать ресурсоемкие системы хранения, обработки данных и их визуализацию. Ввиду этого, в современную схему вычислительного эксперимента необходимо включить еще один элемент – пользователя (экспериментатора), который должен управлять как вычислительным экспериментом, так и системами представления данных. Таким образом, для современной реализации вычислительного эксперимента в модели появляются компоненты "интерфейс ПП с платформой" (API), "компьютер" заменяется термином "платформа", которая в общем случае является распределенной. Соответственно, согласно эталонной модели среды открытых систем появляется "интерфейс с внешней средой" (EEI), частью которой служит пользователь, управляющий вычислительным экспериментом. В противном случае, пакет программ вычислительного эксперимента будет связан с конкретным компьютером или процессором, формат представления данных не будет унифицирован, удаленный доступ будет затруднен и т.д.

            Показано, что ПП, выполняемая на вычислительном ресурсе  типа GRID-структуры, должна удовлетворять определенным требованиям. Для взаимодействия с ядром операционной системы ПП должна использовать только стандартные функции интерфейса прикладных программ (API), а для осуществления обмена информацией между автономно исполняемыми частями (процессами) - функции принятого в данной GRID-структуре интерфейса обмена сообщениями. В большинстве случаев в качестве такого интерфейса используется MPI.

      Разработанные к настоящему времени программные  системы, позволяющие создавать  из компьютеров, объединенных в сеть, GRID-структуры, к сожалению, несовершенны. По этой причине ПП должна учитывать специфику ресурса GRID-структуры: ее гетерогенность, относительно низкую степень надежности (в процессе счета часть узлов может быть по тем или иным причинам исключена из вычислительного поля задачи), строгое ограничение на время выполнения программы. Для этого в ПП необходимо ввести ряд сервисных функций, реализующих следующие свойства:

  • определение быстродействия каждого узла вычислительного поля. На основании полученных данных ПП должна сбалансировать загрузку таким образом, чтобы время выполнения одного «кванта» вычислений на каждом из узлов было приблизительно одинаковым;
  • определение доступного объема оперативной памяти на каждом узле. Перед началом проведения вычислений ПП, по возможности, должна захватить такое количество этого ресурса, который может ей понадобиться на протяжении всего времени работы, динамическое же выделение памяти в процессе счета крайне нежелательно (это связано с многопользовательским режимом работы системы);
  • определение дискового пространства, доступного ПП. Требуемый для нормального функционирования ПП объем дискового пространства определяется как размером получаемых файлов данных, так и объемом переменных задачи, сохранение которых необходимо для продолжения вычислений в случае аварийной остановки программы;
  • получение оценочного значения времени выполнения всей задачи. “Зная” это время, ПП перед началом основных вычислений может определить шаг формирования так называемой "контрольной точки";
  • сохранение промежуточных результатов и значений переменных задачи (формирование контрольной точки). Для обеспечения возобновления программ в случае сбоя  или истечения кванта времени, отведенного для выполнения ПП, стандарты POSIX для суперкомпьютера предусматривают механизм контрольной точки. К сожалению, он не всегда реализуется создателями суперкомпьютеров. В частности, такого механизма до недавнего времени не было в  самых производительных на данный момент отечественных суперкомпьютерах МВC-1000M и МВС-5000M. В таких случаях задача формирования контрольной точки и рестарта с нее, если время расчета длительно и это требуется, возлагается на автора ПП;
  • повторный запуск вычислений с использованием промежуточных (ранее сохраненных) результатов (рестарт с контрольной точки);
  • идентификация окончания выполнения программы с указанием признака причины окончания (нормальное завершение, аварийный останов, окончание выделенного времени счета). Наличие такой информации о завершении выполнения позволяет при следующем запуске ПП выбрать нужную ветвь алгоритма (начать расчет с новыми параметрами или выполнить рестарт с контрольной точки).

Далее описана переносимая реализация библиотеки эмуляции общей памя-ти на основе библиотеки Message Passing Interface (MPI) версии 1.1. Библиотека создана в целях облегчения создания программ удовлетворяющих указанным требованиям, в частности переноса последовательных программ в суперкомпьютерную среду. Она обеспечивает работу с большими распределенными массивами, части которых хранятся на разных вычислительных узлах, и не требует предварительной установки дополнительного ПО на суперкомпьютере (рис 4).

     

Рис. 4. Реализация библиотеки, блок-схема функции Gstart() 

     В главе 4 "Экспериментальная проверка переносимости ПП (аттестационное тестирование)" описаны методика, алгоритм и программа для тестирования ПП на межплатформенную переносимость, разработанные на основе общей методологии тестирования, содержащейся в известных нормативно-технических документах. Алгоритм тестирования ПП на переносимость приведен на Рис. 5.

                

Рис. 5 Алгоритм тестирования ПП на переносимость. 

     Разработанные средства позволяют тестировать  ПП не только на соответствие стандартам POSIX, но и на соответствие стандарту MPI, т.е и параллельные программы тоже. Методика тестирования оформлена как нормативно-технический документ и была принята в установленном порядке. Программа тестирования оформлена согласно правилам Единой системы программной документации, т.е. представляет собой программный продукт, зарегистрированный в Фонде алгоритмов и программ и аттестованный в системе добровольной сертификации "Росинфосерт". Таким образом и Методика, и программа являются аттестованными средствами, вошедшими в состав средств, используемых аккредитованной испытательной лабораторией Центра открытых систем ИРЭ РАН. Приведены пять примеров тестирования различных ПП, написанных на языке Си, с помощью разработанной программы тестирования. В число этих примеров вошли "калибровочные" ПП, которые должны были заведомо пройти тестирование, ПП которые заведомо не должны были пройти тестирование, и две программы от третьих разработчиков, для которых ответ был заранее неизвестен. Одна из этих программ относилась к задачам системы управления городским хозяйством, вторая - к вычислительному эксперименту в области гидроакустики. В тексте диссертации приводятся распечатки, которые позволяют судить о подробностях тестирования. Таким образом, разработаны методы и средства тестирования ПП на межплатформенную переносимость, и с их помощью проведено опытное тестирование ряда ПП.

Информация о работе Исследование межплатформенной переносимости прикладных программ