Стронгин Р.Г (ред.) Высокопроизводительные параллельные вычисления на кластерных системах

Подождите немного. Документ загружается.

(например, развиваемого в настоящий момент российского полигона

СКИФ-ГРИД, где участвует и ресурсный узел ИПХФ).

Для изучения проблем прохождения параллельных программ с

использованием интерфейса MPI на ресурсном узле GRID в ИПХФ

РАН была использована реальная газодинамическая программа

моделирования на молекулярном уровне процесса образования

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

после

отработки тестов решено несколько реальных задач (со временем

расчета на единичном кластере до нескольких недель).

Стандартные прикладные пакеты в области вычислительной

химии

К изученному ПО относятся пакеты GAMESS-US, Gaussian-03,

Dalton-2, CPMD, VASP, MolPro. Большинство из них поддерживает

работу в SMP-средах собственными средствами, однако их

ресурсоемкость требует использования и независимо-параллельных

(сокетных и MPI) вариантов, а

также возможности запуска на

удаленных ресурсных узлах. К сожалению, для распространения этих

пакетов на расчетные узлы GRID пока возможна только ручная их

установка и настройка, что связано со сложностью установки как

самих пакетов, так и требуемого ими окружения, а размеры пакетов

(сотни мегабайт) не дают реальной возможности их передачи на узлы

качестве единого задания (в качестве тестов это проделывалось).

Однако в рамках создаваемой VO по вычислительной химии

предполагается найти решение данных проблем. Опишем реализации

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

пакетов.

1. Пакет GAMESS (General Atomic and Molecular Electronic

Structure System). Для пакета GAMESS в среде GRID авторами была

создана среда, позволяющая проводить его распараллеливание как

сокетным способом, так и

посредством протокола MPI (пакет mpich2-

1.0.3). Сокетный параллельный вариант отличается существенно более

простой реализацией и повышенным быстродействием, однако при

запуске через GRID-инфраструктуру имеет ряд недостатков:

неправильно оценивает необходимые процессорные ресурсы, требует

фиксированного числа процессоров и обязательного явного указания

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

избыточных вычислительных мощностей этот вариант приемлем

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

проблематично. MPI-вариант реализован только для среды Mpich-2,

поскольку пакет GAMESS требует передачи огромного числа

переменных окружения и параметров (чего не дает ”стандартная”

реализация MPI). Он более применим для GRID-среды, т.к. требует

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

«завязан» на стартующую машину, не нуждается в явном описании

расчетных узлов. Были проведены успешные

запуски ряда заданий для

расчетов по программе GAMESS в тестовой VO RGSTEST, а затем и

проведены масштабные расчеты на нескольких десятках процессоров с

получением результатов расчетов на конкретном UI. В настоящее

время заканчивается отладка WWW-интерфейса для упрощения

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

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

GAMESS отличается

очень обширным количеством входных данных.

Все данные делятся на 114 групп, которые содержат в совокупности

более 500 простых параметров и параметров-массивов, и их «сборка» и

запуск вручную – весьма трудоемкий процесс.

2. Пакет Gaussian. Для Gaussian-D03 был сформирован пакет

скриптов для запуска заданий посредством GRID-технологий на

SMP-серверах (при условии предварительной установки) и успешно

просчитан

ряд реальных задач, запущенных через UI-интерфейс. В

настоящее время изучается возможность его распараллеливания между

отдельными узлами кластеров с использованием пакета Linda (под

управлением PBS Torque). Работу в тривиальных MPI-средах данный

пакет пока не поддерживает. Наибольшую проблему вызывают

вопросы лицензионных ограничений использования данного

коммерческого ПО в рамках распределенных сред.

3. Для пакетов CPMD и Dalton-2 показана возможность

запуска в

распределенных средах (при предварительной установке и настройке),

при этом оба пакета могут совмещать работу в SMP-архитектурах с

работой в MPI-среде.

Перечисленные примеры – лишь небольшая часть задач

вычислительной химии и примыкающих к ним по структуре

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

адаптированы к решению в рамках инфраструктуры

GRID.

Исследования, проведенные в рамках проекта, продемонстрировали

огромные возможности параллельных и/или распределенных

технологий в среде GRID в области вычислительной химии.

Существенные трудности, связанные с установкой различного

middleware (LCG-2/gLite, Condor, Xcom), многократно перекрываются

новыми возможностями и перспективами в решении масштабных

задач.

Литература

1. Алдошин С.М., Варламов Д.А., Волохов В.М.,

Покатович Г.А., Сурков Н.Ф., Станиловский А.И. GRID и

вычислительная химия в ИПХФ РАН // Научный сервис в сети

Интернет: технологии параллельного программирования.

Труды Всероссийской научной конференции, М.:,

Изд-во

МГУ, 2006. с.91-93.

2. Варламов Д.А., Волохов В.М., Покатович Г.А., Сурков Н.Ф.,

Пивушков А.В. Российский сегмент GRID в области

вычислительной химии // В сб.: Распределенные вычисления и

грид-технологии в науке и образовании, Труды второй

международной конференции (Дубна, 26–30 июня 2006 г.),

Дубна: Изд-во ОИЯИ, 2006. Д11-2006-167, 419 с. C.243-254

Варламов Д.А., Волохов В.М., Пивушков А.В., Покатович

Г.А., Сурков Н.Ф. Применение параллельных и

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

ИПХФ РАН // Высокопроизводительные параллельные

вычисления на кластерных системах. Материалы шестого

Международного научно-практического семинара (Под ред.

проф. Стронгина Р.Г.) Санкт-Петербург: Изд-во СПбГУ, 2007.

281 с. Том 1. С.71-79.

4. Варламов Д.А., Волохов В.М., Покатович Г.А., Сурков Н.Ф.,

Пивушков А.В. Параллельные квантово-химические

вычисления в среде ГРИД // Международная научная

конференция "Параллельные вычислительные технологии"

(ПаВТ'2007) труды Международной научной конференции

(Челябинск, 29 января - 2 февраля 2007 г.). – Челябинск:

Изд-во ЮУрГУ, 2007. – Т.2. 297 с. С.3-14.

ПРАКТИКА ПРИМЕНЕНИЯ ПРОГРАММНЫХ СИСТЕМ

РАСПРЕДЕЛЕННЫХ И ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛЕНИЙ

ДЛЯ РЕШЕНИЯ ЗАДАЧ ВЫЧИСЛИТЕЛЬНОЙ ХИМИИ

Д.А. Варламов, А.В. Пивушков, В.М. Волохов, Н.Ф. Сурков,

Г.А. Покатович

Институт проблем химической физики РАН, Черноголовка

Введение

ИПХФ - крупнейший в России академический институт,

проводящий теоретические и экспериментальные исследования по

следующим направлениям: общие

теоретические проблемы

химической физики; строение молекул и структура твердых тел;

кинетика и механизм сложных химических реакций и др. При

исследовании этих направлений необходимо проводить параллельные

и/или распределенные расчеты. Для проведения расчетов

используются как лицензионные программы (Gaussian, Mopac,

MolPro), так и программы, распространяемые на условиях “open

source” (CPMD, Dalton-2, Gamess-US, NWChem). Также используется

оригинальное авторское ПО.

Структура вычислительной среды

ИПХФ

В течение 2005-2007 годов в ИПХФ была создана и

эксплуатируется гетерогенная распределенная вычислительная среда

на платформе промежуточного ПО (middleware) LCG-2/gLite: были

сформированы ресурсный узел сервисов GRID и ряд пользовательских

интерфейсов и шлюзов к инфраструктуре GRID.

Реализованы основные серверные компоненты узла GRID,

включая Computing Element (CE), Storage Element (SE), Monitor

Element (MON), Work Node(s) (WN, 14 процессоров). Данные

компоненты формируют ресурсный узел GRID (в рамках LCG-2) и

используются для решения входящих

задач. Для CE- и SE-элементов

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

рамках инфраструктуры EGEE. В качестве остальных обязательных

компонентов узла использованы внешние ресурсы (брокер ресурсов и

proxy-сервер – НИИЯФ МГУ, сертификационный центр –

Курчатовский РНЦ).

Для пакетной обработки заданий на СЕ выбраны системы Condor

и PBS Torque. Они позволяют решать как параллельные задачи с

непрерывным обменом данными, так и генерируемые "пучки"

формально независимых задач. Для обработки параллельных задач

использован пакет Mpich (1 и 2).

Для решения исходящих задач (задач, формируемых

пользователями и решаемых на внешних ресурсах) были установлены

пользовательские интерфейсы (UI). Они используются для передачи

задач и данных на внешние узлы инфраструктуры GRID и проведения

там расчетов в рамках

различных виртуальных организаций. Для

обеспечения комфортной работы пользователя и автоматизации

запуска часть UI была интегрирована в WWW-портал

http://grid.icp.ac.ru (Grid Enabled Chemical Physics – GECP). Портал

является подбором пилотных пользовательских интерфейсов для

запуска авторских задач и прикладных программ в области

вычислительной химии и роста кристаллов. В ИПХФ РАН ряд

пользователей получили сертификаты с регистрацией в тестовой VO

RGSTEST консорциума RDIG, после чего

ими был решен ряд задач на

ресурсных узлах в рамках данной VO – НИИЯФ и НИВЦ МГУ, ИФВЭ

(Протвино), Харьковский ФТИ, собственный узел ИПХФ – всего до

200 процессоров.

В течение 2006-2007 годов проводились работы по созданию

прикладных интерфейсов (включая высокоуровневые

WWW-варианты) для запуска в распределённой вычислительной среде

однопроцессорных и параллельных приложений. Была отработана

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

подготовки задач определенного класса, технологии формирования

параллельных «пучков» задач, их запуска на распределенных ресурсах

и «сборки» результатов. Был проведен ряд экспериментов с

использованием внешних ресурсов VO RGSTEST и ресурсного узла

ИПХФ (через инфраструктуру GRID) в самых различных вариантах

заданий: с использованием одно- и многопроцессорных конфигураций,

с созданием «

пучков» заданий (до 70000 вариантов расчетов), с

использованием параллельных вычислений (MPI 1 и 2). Были

проведены адаптация и запуски квантово-химических задач GAMESS

(сокетный и MPI варианты) и Gaussian.

Авторские программы

1. Расчет процесса туннельного прохождения протона через

потенциальный барьер (создание материалов для оптической

сверхплотной памяти). Вычисления в каждой точке сетки происходят

независимо, что позволило разбить область вычислений на множество

непересекающихся подобластей и на каждой из них запускать задачу

на подмножестве процессоров. Область решения задачи: 30

подобластей по ~4200 точек в каждой. При применении одиночного

ПК оцениваемое время решения задачи достигает 5-6 тысяч часов. Для

расчетов на сегменте EGEE–RDIG в рамках виртуальной организации

RGSTEST были использованы шлюзы

Condor-Globus и авторский.

Распараллеливание задачи осуществлялось на UI узле ИПХФ

средствами системы Condor или авторскими скриптами, задания

выполнялись индивидуально и независимо друг от друга. Бинарный

файл программ вместе с входными данными для одной из

подобластей, получившихся в результате расщепления области

данных, помещались во входной “box” и передавались на брокер

ресурсов, который определял свободный CE в VO RGSTEST,

на

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

Объем передаваемых входных данных для одного задания составлял

около 1 Mб, выходных – до 0.5 Mб, всего для расчета типовой задачи

происходила передача до 7.5 Гб данных на внешние расчетные узлы.

Выходные данные вместе с файлом результатов передавались на

хранение в SE, откуда передавались на UI. Показана возможность

работы с любым количеством CE виртуальной организации. Расчет в

распределенной системе в среде GRID (до 100 процессоров) занимает

около 30-40 часов.

2. Расчет оптимальных параметров для создания промышленной

высокопроизводительной установки (теплового узла) по выращиванию

крупногабаритных кристаллов. Двумерная задача предусматривает до

единичных параллельных независимых расчетов, что делает ее

идеальной для решения путем запуска “пучков” задач на

распределенных вычислительных мощностях. Набор авторских

скриптов «нарезает» задачу и запускает ее через брокер ресурсов на

вычислительных мощностях VO RGSTEST. Решено несколько

упрощенных вариантов задачи, однако полномасштабный

вычислительный эксперимент требует до 1000 процессоров, что

возможно лишь в рамках крупных

полигонов (например, СКИФ-

ГРИД).

3. Для изучения проблем прохождения параллельных программ с

использованием интерфейса MPI на ресурсном узле GRID в ИПХФ

РАН была использована газодинамическая программа моделирования

на молекулярном уровне процесса образования ударной волны в

ударной трубе применительно к газовой смеси и после отработки

тестов решено несколько реальных задач (со временем расчета до

нескольких недель).

Программы сторонних производителей

Пока для распространения программ сторонних производителей на

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

связано со сложностью установки программ и требуемого ими

окружения, а

размеры программ (сотни мегабайт) затрудняют

возможности их передачи в качестве единого задания.

Пакет GAMESS (General Atomic and Molecular Electronic Structure

System). Для пакета GAMESS в среде GRID авторами создана среда,

позволяющая проводить его распараллеливание как сокетным

способом, так и посредством протокола MPI (Mpich-2). Сокетный

параллельный вариант отличается более простой реализацией и

повышенным быстродействием, однако при запуске через

GRID-инфраструктуру имеет ряд недостатков:

неправильно оценивает

необходимые процессорные ресурсы, требует фиксированного числа

процессоров и обязательного явного указания стартующего узла.

MPI-вариант реализован только для среды, поскольку пакет GAMESS

требует передачи огромного числа переменных окружения и

параметров (чего не дает ”стандартная” реализация MPI). Однако он

более применим для GRID, т.к. требует определения только

минимального числа доступных процессоров, не «

завязан» на

стартующую машину, не нуждается в явном описании расчетных

узлов. Были проведены успешные запуски ряда заданий для расчетов

по программе GAMESS в тестовой VO RGSTEST, а затем проведены

масштабные расчеты на нескольких десятках процессоров с

получением результатов расчетов на конкретном UI. Заканчивается

отладка WWW-интерфейса для упрощения формирования и запуска

пакета.

Пакет Gaussian. Для Gaussian-D сформирован пакет

скриптов для

запуска заданий посредством GRID-технологий на SMP-серверах (при

условии предварительной установки) и просчитан ряд задач,

запущенных через UI-интерфейс. Изучается возможность его

распараллеливания с использованием пакета Linda (под управлением

PBS Torque). Однако большую проблему вызывают вопросы

лицензионных ограничений использования данного ПО в

распределенных средах.

Ведется адаптация ПО Dalton для распределенных сред.

Заключение

Наши исследования продемонстрировали огромные возможности

применения параллельных и/или распределенных технологий в среде

GRID в области вычислительной химии.

ПРИНЦИПЫ АППАРАТНОЙ РЕАЛИЗАЦИИ МЕТОДА

ВЗАИМНОГО ИСКЛЮЧЕНИЯ ДЛЯ СИНХРОНИЗАЦИИ

ПАРАЛЛЕЛЬНЫХ ПРОЦЕССОВ

Н.П. Вашкевич, Р.А. Бикташев

Пензенский государственный университет

Архитектура современных операционных систем (ОС) содержит

типичные

компоненты, которые наиболее часто используются

вычислительным процессом при своей реализации. К ним относятся

механизмы межпроцессорного взаимодействия, управления памятью,

планирования процессов и обработка прерываний. Анализ,

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

значительная часть функций этих компонентов реализуется

программным путём. Высокая частота использования компонентов ОС

приводит к значительным непроизводительным временным затратам,

которые могут

достигать нескольких десятков процентов от общего

времени реализации процессов, порождаемых пользовательскими

программами [1].

Аппаратной реализации алгоритмов ОС, особенно в

распределенных и многопроцессорных системах, исследователи не

уделяли должного внимания. Имеются отдельные работы, из которых

на сегодня наиболее интересными является аппаратная поддержка

барьерной синхронизации, примененная в архитектуре компьютера

Cray T3D/ T3E [2], и аппаратная синхронизация процессов,

реализованная

в многопроцессорной системе Sequent Balance модели

21000, причем ускорение достигается применением

специализированной быстродействующей памяти, которая названа

атомарной памятью блокировки [3].

Целью данной работы является исследование принципов

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

при осуществлении синхронизации параллельных процессов, и синтез

устройств синхронизации для многопроцессорных и распределённых

систем. Включение такого устройства в параллельную

вычислительную систему должно привести не только к увеличению

производительности, но и к некоторому упрощению создания

параллельных программ, а также к уменьшению вероятности ошибок

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

синхронизацией взаимодействующих процессов.

В вычислительных системах синхронизация

взаимодействующих

процессов заключается в том, что запрашивающий процесс

анализирует глобальную блокирующую переменную (mutex),

закрепленную за общим ресурсом. Операция чтения блокирующей

переменной, её проверки и установки, а также записи в ячейку

производится единой (неделимой) командой [4]. Время выполнения

неделимой команды увеличивается, что ухудшает характеристики

систем прерывания и условия работы конвейера команд. Особенно это

ощутимо

для RISC-процессоров, в которых время выполнения

команды «читать–проверить–установить–записать» по сравнению со

временем выполнения обычных команд увеличивается в два - три раза,

что приводит к простоям конвейера команд и уменьшению реакции

системы прерывания.

Применение неделимой операции «читать–проверить–

установить–записать» в многопроцессорной системе вызывает также

необходимость блокировки межпроцессорной шины

функционирующей в режиме расщепления транзакций чтения памяти.

Этим исключается возможность одновременного доступа к общему

ресурсу со стороны нескольких процессов, выполняющихся в разных

процессорах, поскольку в промежутке недовыполненной транзакции

шину может захватить другой процессор и обеспечить вход его

процесса в свою критическую секцию.

Кроме того, если процессоры содержат в своем составе

кэш-

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

процессорных узлов возможно необоснованное увеличение трафика

на межпроцессорной шине из-за частого перемещения строки кэш,

содержащей слово блокировки, которая необходима процессам,

конкурирующим за доступ к общему ресурсу [5]. Последние два

обстоятельства приводят к снижению реальной пропускной

способности межпроцессорной шины и, в конечном

счете, к потерям

производительности всей вычислительной системы.

Возможны два варианта аппаратной реализации системы

синхронизации взаимодействующих процессов: с использованием

специальной команды или специального сигнала “Запрос общего

ресурса”.

В первом варианте устройство синхронизации процессов

подключается как общедоступное для любого процессора устройство,

функционирующее в адресном пространстве памяти или ввода-вывода,

время доступа к которому сравнимо со временем доступа к внешнему

кэш второго или третьего уровня. Любой процессор, реализующий

некоторый процесс (поток), может сформировать команду запроса

общего ресурса и получить ответ о его занятости или незанятости. Для

этого в аппаратуру устройства синхронизации включены два регистра:

регистр запросов РгЗп и регистр текущего процесса РгТП (рис.1).

Регистры размещаются в адресном пространстве памяти или устройств

ввода-вывода.

ЦП1

ЦПn ОП

Межпроцессорная шина

Устройство синхронизации

Рг ЗП Рг ТП

Логика управления

(САП, СВЗИ)

...

Критические секции

Запрос на доступ к ОР

(команда вывода)

Разрешение доступа к ОР

(команда ввода)

Рис.1. Аппаратная реализация системы синхронизации с использованием

специальной команды “Запрос общего ресурса”

В регистре запросов фиксируются запросы на общий ресурс,

поступающие от процессов, реализуемых в разных процессорах.

Каждому процессу выделяется один бит в регистре запросов, причём

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

процесса также выделяется по одному биту на один процесс.

Единичное значение i-го разряда регистра означает, что

соответствующий ему

процесс находится в критической секции и

работает с общим ресурсом. Состояние текущего процесса