Текст доклада "Опыт использования PVM в народном хозяйстве"(?) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Сочинил: я (Илья Евсеев). Это примерно то, что я отбубнил на "Телематике-98". Читать рекомендуется, запустив прилагающуюся презентацию (файл-сценарий для 95-го PowerPoint'a). Значок <> в тексте означает, что, дочитав до этого места, в окне прогона презентации надо нажать на пробел. ------ Слайд 1 ------------------------------------------------------- Исторически сложилось так, что аппаратура для параллельных вычислений развивалась по трем слабо связанным направлениям: <> ЭВМ, в которых все процессоры имеют общее ОЗУ, т.н. "симметричные мульти-процессоры" <> ЭВМ, в которых процессорные узлы конструктивно изолированы друг от друга (так что и ОЗУ у каждого из них свое), но соединены быстрой внутримашинной сетью и упрятаны под один кожух - "массивно-параллельные процессоры" <> и сети ЭВМ, которые, согласно крылатому девизу Sun Microsystems также являются вычислительными системами, и представляют немалый интерес как платформа для параллельных вычислений. Разработчикам в зависимости от направления приходилось делать акцент на разные проблемы, как-то: * в сети проблема N1 - это выбор эффективного маршрута между компьютерами, увеличение скорости и надежности пересылки данных тыр-пыр-пыр... * в машине с общей памятью главная головная боль для программиста (да и для самого разработчика такой машины) - обеспечение надежной синхронизации доступа к ОЗУ, и вообще ко всему, что используется совместно несколькими устройствами/программами. * для MPP-машин наблюдается устойчивое отставание наработок в программном обеспечении. Можно сравнительно быстро собрать суперкомпьютер из 16 или 32 пересональных ЭВМ PowerPC, как это делает фирма Parsytec, но чтобы запущенный на таком монстре MatLab for Windows заработал в 30 раз быстрее, его потребуется адаптировать для работы в многопроцессорной выч.среде с раздельной памятью (читай - переписать заново) - а на это уйдет гораздо больше времени, чем на сборку. С определенного момента и по сей день в среде программистов, пишущих параллельные приложения, растет необходимость в стандарте на инструментарий, который должен сделать параллельное программирование столь же: * комфортным, * надежным * и мобильным, каким язык Си сделал программирование вообще. Выгоды от введения стандарта, даже не считая удешевления ПО и ускорения его разработки, очевидны: * Новые машины легче продавать, потому что облегчается перенос ПО на них. * Устаревающие ЭВМ можно объединять в комплексы с приемлемой мощностью. * Сети машин, предназначенных для других целей, становятся пригодными для использования в нерабочее время в качестве импровизированных, но весьма конкурентноспособных суперкомпьютеров. PVM - это стандарт "де-факто", не потому что он безупречен (отнюдь!), а потому что он оказался одним из первых. Аббревиатура PVM расшифровывается как "Параллельная Виртуальная Машина". Основной целью разработки было объединение гетерогенного (т.е. неоднородного) комплекса физических ЭВМ в одну большую виртуальную: многопроцессорную, способную выполнять параллельные приложения, так что программист не обязан задумываться ни о составе и архитектуре машин, ни об архитектуре и топологии сети: он работает на некоей ОДНОЙ гипотетической машине. Проект изначально чисто исследовательский, задуман с целью выяснить: а насколько малой кровью решается эта задача. <><> ------ Слайд 2 ------------------------------------------------------- Какой вид должен иметь алгоритм, для того чтобы быть запрограммированным на PVM ? <> Алгоритм разбивается на ветви. Каждая ветвь имеет свое собственное пространство данных, изолированное от остальных ветвей. <> Ветвям присваиваются номера от 0 до (кол-во ветвей - 1). <> Для доописания алгоритма в параллельном виде вводятся 3 нематематических операции, вставляемые в ветви: * передача( N ветви-получателя, данные ) * прием( N ветви-отправителя, данные ) * точка синхронизации, или барьер( N ветвей ) Здесь мы ничего не говорим о первом пункте: содержание алгоритма, и то, насколько эффективно он запрограммирован, нас не интересует, PVM по отношению к алгоритму - это исключительно система связи, его прерогативой является поддержка пункта 3. <><> ------ Слайд 3 ------------------------------------------------------- После этого проект переходит в стадию программирования. Я опускаю детали инсталляции PVM, которую делает системный администратор, и настройки, которые пользователь вносит в login-файл. Здесь важно одно: и то, и другое должно быть выполнено на КАЖДОЙ физической ЭВМ, которую предполагается использовать в составе ЭВМ виртуальной. Собственно программирование (и не только на PVM) состоит из трех циклически повторяемых этапов: * пункт 1: написание исходного текста программы * пункт 2: ее построение * пункт 4: и выполнение (в отладочном или рабочем режиме, брбрбр...) В PVM для поддержки соответственно каждого из этих этапов введены следующие средства: <> справочная система, имеющая стандартную для Юникса организацию <> заголовочные файлы и библиотеки для языков программирования Си и Фортран <> а также набор утилит, создающих "виртуальную машину", выступающую посредником между исполняющимся PVM-приложением и реальным миром; командных файлов, облегчающих компиляцию и т.д. Особый этап, специфичный именно для параллельных программ: пункт 3. Для запуска процессов приложения на комплексе из неск.машин может потребоваться скопировать либо: а) исходники с последующей там компиляцией/компоновкой, либо, б) если все машины одинаковы, готовые к запуску двоичные файлы - на каждую физическую машину. Эта стадия никак не поддерживается в PVM <> но и ее можно автоматизировать: утилитами Юникса "rdist" и "rsh". Теперь конкретнее о каждом из этапов: <><> ------ Слайд 4 ------------------------------------------------------- Составление программы: с точки зрения PVM существуют процессы (или задачи), но что такое приложение - PVM не знает. PVM оперирует ГРУППАМИ. Группа идентифицируется ее названием - текстовой строкой. Процесс присоединяется к группе, вызывая соответствующую библиотечную функцию PVM. <> При этом ему выдается номер в диапазоне от 0 до (размерГруппы-1). Процесс может быть членом и нескольких разных групп, и ни одной, но такие крайности редки. Принятым методом образования групп является следующий: первоначально из всей группы запускается (с консоли) только один процесс. Этот процесс при присоединении к группе получает, таким образом, номер 0. Он запускает нужное количество своих копий (размножается), <> которые так же выполняются с самого начала, но, получив номера, большие нуля, обходят стадию размножения. <> После барьера процессы приступают к вычислениям ветвей алгоритма с соответствующими номерами <> пользуясь при этом функциями приемопередачи, вспомогательными функциями, барьерами итд... <><> ------ Слайд 5 ------------------------------------------------------- Когда программа построена, как она выполняется? Какова внутренняя структура Виртуальной Машины? "Вход" в виртуальную ЭВМ так же прост, как и вход на физическую: по команде "pvm" <> запускается интерпретатор команд. <> Многие вводимые в нем команды имеют такой же синтаксис, как и в Юниксе ( kill, ps, ... ), но их область действия - виртуальная машина, а не какая-либо из физических. Есть специфичные для PVM команды (z.B., подключить/отключить физическую ЭВМ из состава виртуальной), а многие команды общего назначения отсутствуют. Из этой командной строки нельзя запускать ничего, кроме приложений PVM. Что происходит на заднем плане? <> Интерпретатор запускает программу "pvmd" - "демона PVM" (в Windows это называется сервисом, а в DOS - резидентной программой). Это - "мастер"-демон. Мастер-демон читает файл с сетевыми адресами делегированных в PVM физических машин, и на каждой из них запускает <> "вторичного" демона посредством сетевой Юниксовской службой "rsh". <> Все демоны устанавливают и поддерживают друг с другом связь через сетевой протокол UDP - протокол пользовательских датаграмм. <> Виртуальная машина "жива", пока "жив" мастер-демон. Физическая машина пребывает в составе виртуальной, пока сохраняется связь локального демона с мастером. Это, в частности, предохраняет Виртуальную Машину от ситуации, когда часть slave-демонов теряет связь с мастером, но, поддерживая связь друг с другом, начинает работать автономно как еще одна виртуальная машина ("отпочкование"). <><> ------ Слайд 6 ------------------------------------------------------- Демон выполняет 2 функции: * управление задачами на данной физической ЭВМ, * поддержка связи через UDP "своих" задач с задачами, расположенными на других машинах. Более общее: маршрутизатор сообщений внутри виртуальной машины. Демон является приложением Юникса, и пользуется юниксовскими функциями для запуска процессов. <> Процессы так же являются процессами Юникса, в которые добавлен код из библиотеки PVM. Связь с демоном они устанавливают через Юникс <>, а поддерживают напрямую - через общую память, <> поскольку выполняются на одной и той же машине. Через демона производится связь между процессами, <> но, когда это возможно, библиотечный код программ и друг с другом так же связывается напрямую. <> Процессы свободно пользуются юниксовскими функциями для своих нужд, <> но некоторые из функций PVM подменяет во время компиляции на собственные их варианты, <> дабы, например, выводимая функцией printf() информация из задач, выполняющихся на разных физических машинах, централизованно собиралась мастер-демоном и записывалась в log-файл на той физической ЭВМ, на которой работает пользователь. <> Из всего этого обилия стрелочек хочется особо выделить те, которых здесь нет: нет (и не рекомендуется) никаких взаимосвязей между пользовательскими частями программ в обход PVM. <> ------ Слайд 7 ------------------------------------------------------- Следует упомянуть, что PVM - это машина однопользовательская. Несколько человек могут одновременно работать в своих виртуальных машинах, организованных на одном и том же комплексе машин физических, но задачи из разных виртуальных машин не будут иметь никаких точек соприкосновения, по крайней мере, до тех пор, пока они пользуются для межзадачного взаимодействия средствами PVM. (к этому моменту надо целых 7 раз <>) Если одна физическая ЭВМ одновременно работает в составе двух виртуальных, это означает, что программное обеспечение PVM (демон и прочее) загружено в двух экземплярах. Только так. <><> ------ Слайд 8 ------------------------------------------------------- Рудиментарным, и в то же время хорошо развитым, компонентом PVM являются средства контроля за его состоянием: * Можно зарегистрировать процесс в качестве "хостера", <> * и этот процесс в те моменты, когда меняется состав физических машин ("хостов") внутри машины виртуальной <> * станет получать от PVM уведомляющие сообщения. <> * Аналогично производится контроль за функционированием задач: <> * задача регистрируется в качестве наблюдателя <> * и она будет получать сообщения о запуске/завершении других задач <> Имеется возможность централизованно настроить запуск задач не напрямую, а под отладчиком, и так далее. <><> ------ Слайд 9 ------------------------------------------------------- И в завершение - краткое резюме: обзор достоинств и недостатков. К недостаткам можно отнести: <> Невысокую скорость работы из-за чрезмерной абстрагированности интерфейса программиста от конкретных скоростных машин, чрезмерную его абстрактность. Это сказывается изначальная исследовательская направленность проекта. Первоначально был скудным не только интерфейс между PVM и программистом, но и интерфейс между PVM и операционной системой: PVM всю приемопередачу производил функциями TCP/IP. Позднее этот интерфейс для повышения скорости сделали комбинированным - обмен данными ведется по кратчайшей возможной траектории: * общая память на SMP-машине или в рамках одного процессора, * внутримашинная сеть на MPP-машине (кстати, поскольку стандарта на интерфейс программиста для таких сетей нет, PVM надо адаптировать для каждого типа MPP-машин), * и уж в самом крайнем случае TCP/IP. <> Неудобный интерфейс пользователя: из моего круга общения ВСЕ, кому пришлось осваивать PVM, руководствуясь здравым смыслом + опытом программирования под Юниксом, совершали ОДНИ И ТЕ ЖЕ ошибки (и чаще всего - невозможность верно задать каталог для запуска приложений, поскольку такое задание производится по уж слишком мудреным правилам). Да и вообще, зачем не для исследовательских целей нужна эта самая виртуальная машина со всеми ее хостерами и таскерами?!? Реальному, из жизни, параллельному приложению нужен такой загрузчик, срок жизни которого будет совпадать со сроком жизни самого приложения. Это и проще, и надежнее. Мне сия мысль пришла в голову, чего греха таить, не сразу, слишком уж наглядной и изящной выглядела концепция Виртуальной Машины. Однако в жизни эта концепция выродилась в громоздкую и неуклюжую реализацию, которая меньше, чем следует, занимается обслуживанием межзадачных связей, и больше, чем следует - обслуживанием себя самое, сохранением собственной целостности и все такое прочее. <> До тех пор, пока PVM является однопользовательской, она годится для математических расчетов, но не для баз данных: систему "клиент-сервер", пользуясь ТОЛЬКО PVM, написать НЕЛЬЗЯ. <> В реализации есть довольно гнусные ошибки: ЧРЕЗВЫЧАЙНО трудно ловятся, легко обходятся. Совершены, насколько можно предположить, из простой неряшливости, что возмутительно!!!! Некоторые перекочевывают из версии в версию на протяжении многих месяцев (как минимум одна из них, "зависание после запуска 42 задач", до сих пор там сидит). А вот достоинства: <> Простой интерфейс программиста (хоть и абстрактный;): каждое действие можно запрограммировать ровно одним способом (с очень незначительными вариациями). <> Он распространялся либо дольше, либо быстрее, чем его конкуренты. <> Хотите моего совета? Закончите свое знакомство с PVM моей презентацией. Изучайте лучше MPI-2. <> В С Е !