Научная статья на тему 'Выбор архитектуры параллельной вычислительной системы для эмулятора среды исполнения языка «Пифагор»'

Выбор архитектуры параллельной вычислительной системы для эмулятора среды исполнения языка «Пифагор» Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
327
36
i Надоели баннеры? Вы всегда можете отключить рекламу.
Ключевые слова
ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ / ФУНКЦИОНАЛЬНЫЕ ЯЗЫКИ ПРОГРАММИРОВАНИЯ / КОМПИЛЯТИВНЫЙ ПОДХОД / СРЕДА ИСПОЛНЕНИЯ ФУНКЦИОНАЛЬНО-ПОТОКОВЫХ ПРОГРАММ / АРХИТЕКТУРЫ ПАРАЛЛЕЛЬНЫХ ВЫЧИСЛИТЕЛЬНЫХ СИСТЕМ / PARALLEL COMPUTINGS / FUNCTIONAL PROGRAMMING LANGUAGES / COMPILATION APPROACH / FUNCTIONAL DATAFLOW PROGRAM RUNTIME ENVIRONMENT / PARALLEL COMPUTING ARCHITECTURES

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Андреев Антон Сергеевич, Леонова Анна Всеволодовна, Леонова Наталья Всеволодовна

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

i Надоели баннеры? Вы всегда можете отключить рекламу.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Андреев Антон Сергеевич, Леонова Анна Всеволодовна, Леонова Наталья Всеволодовна

iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

CHOOSING parallel COMPUTING architecture for Pifagor language run-time ENVIRONMENT emulator

The paper deals with the methods of parallel computing organization. The objective is to find the most suitable architecture for running the event processor emulator of the functional dataflow programming language Pifagor. The requirements for emulator architecture are defined. Existing parallel computer system architectures are analyzed. A conclusion is made that the cluster architecture is best in compliance with the requirements for functional parallel computing machine structure.

Текст научной работы на тему «Выбор архитектуры параллельной вычислительной системы для эмулятора среды исполнения языка «Пифагор»»

УДК 681.3.06

ВЫБОР АРХИТЕКТУРЫ ПАРАЛЛЕЛЬНОЙ ВЫЧИСЛИТЕЛЬНОЙ СИСТЕМЫ ДЛЯ ЭМУЛЯТОРА СРЕДЫ ИСПОЛНЕНИЯ ЯЗЫКА «ПИФАГОР»

© А.С. Андреев1, А.В. Леонова2, Н.В. Леонова3

1 Сибирский федеральный университет, 660041, Россия, г. Красноярск, пр. Свободный, 79. 2,3 Иркутский государственный технический университет, 664074, Россия, г. Иркутск, ул. Лермонтова, 83.

Рассматриваются способы организации параллельных вычислений. Данная работа преследует цель нахождения оптимальной архитектуры для исполнения эмулятора событийного процессора функционально-потокового языка «Пифагор». Определены требования, предъявляемые к архитектуре исполнения эмулятора. Проведен анализ существующих архитектур параллельных вычислительных систем. Сделан вывод о том, что кластерная архитектура наиболее полно отвечает требованиям соответствия структуре вычислительной машины функционально-параллельного языка. Библиогр. 10 назв.

Ключевые слова: параллельные вычисления; функциональные языки программирования; компилятивный подход; среда исполнения функционально-потоковых программ; архитектуры параллельных вычислительных систем.

CHOOSING PARALLEL COMPUTING ARCHITECTURE FOR PIFAGOR LANGUAGE RUN-TIME ENVIRONMENT EMULATOR

A.S. Andreev, A.V. Leonova, N.V. Leonova

Siberian Federal University, 79 Svobodny Av., Krasnoyarsk, Russia, 660041. Irkutsk State Technical University, 83 Lermontov St., Irkutsk, Russia, 664074.

The paper deals with the methods of parallel computing organization. The objective is to find the most suitable architecture for running the event processor emulator of the functional dataflow programming language Pifagor. The requirements for emulator architecture are defined. Existing parallel computer system architectures are analyzed. A conclusion is made that the cluster architecture is best in compliance with the requirements for functional parallel computing machine structure. 10 sources.

Key words: parallel computings; functional programming languages; compilation approach; functional dataflow program runtime environment; parallel computing architectures;

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

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

и научных расчетов. Разнообразие архитектур вычислительных систем (ВС) и исторически сложившаяся практика разработки под конкретное архитектурное решение приводят к проблеме переносимости программного обеспечения. В свете этого особую актуальность в области параллельных вычислений приобретают архитектурно-независимые методы.

Методы архитектурно-независимого параллельного программирования основаны на разделении на отдельные этапы процессов формирования логики программы и ее архитектурной привязки. При таком подходе программа может разрабатываться для некото-

1Андреев Антон Сергеевич, магистрант кафедры вычислительной техники, тел.: 89832967543, e-mail: mail.4o@ya.ru Andreev Anton, Master's Degree Student of the Department of Computer Engineering, tel.: 89832967543, e-mail: mail.4o@ya.ru

2Леонова Анна Всеволодовна, студентка кафедры радиоэлектроники и телекоммуникационных систем, тел.: 89148989368, e-mail: anleonova@mail.ru

Leonova Anna, Student of the Department of Radio Electronics and Telecommunication Systems, tel.: 89148989368, e-mail: anleonova@mail.ru

3Леонова Наталья Всеволодовна, кандидат химических наук, доцент кафедры радиоэлектроники и телекоммуникационных систем, тел.: 89148765940, e-mail: anleonova@mail.ru

Leonova Natalya, Candidate of Chemistry, Associate Professor of the Department of Radio Electronics and Telecommunications Systems, tel.: 89148765940, e-mail: anleonova@mail.ru

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

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

К этому направлению относится язык программирования «Пифагор» [2]. «Пифагор» - функционально-потоковый язык программирования, предназначенный для разработки переносимых (архитектурно-независимых) параллельных программ.

Язык «Пифагор» разработан в Красноярском государственном техническом университете в 1995 году, в настоящее время разработка ведется в Институте космических и информационных технологий Сибирского федерального университета. Название является сокращением от «Параллельный Информационно-Функциональный Алгоритмический» или «Parallel Informational and Functional AlGORthmic».

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

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

При исполнении функционально параллельных программ можно определить два основных подхода.

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

Второй подход - эмулятивный - подразумевает непосредственную интерпретацию функционально-параллельных программ с использованием специально разработанного эмулятора для конкретной архитектуры ВС. Несмотря на падение производительности, данный подход допускает более простую реали-

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

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

- определить методы и алгоритмы управления ФП программами на этапе исследования;

- при необходимости обеспечить требуемое масштабирование и провести анализ результатов;

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

В настоящее время реализованы две версии среды исполнения [6] (событийных процессоров) при помощи языка программирования «Си». Активно идет разработка аппаратного процессора на базе ПЛИС (Программируемая Логическая Интегральная Схема). Для дальнейшего развития языка необходимо создание унифицированного интерфейса (среды исполнения), который мог бы объединить в одну вычислительную систему специальные процессоры различных типов.

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

- параллелизм на уровне команд [4];

- параллелизм на уровне операций [7];

- крупноблочный параллелизм [5];

- многоуровневость виртуальной машины языка.

Среда исполнения также должна поддерживать

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

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

- SMP (системы с общей памятью);

- MPP (системы с распределенной памятью);

- кластерные системы;

- системы NUMA.

SMP системы - параллельные вычислительные системы, состоящие из нескольких процессоров и общей для них памяти [9]. Все процессоры обладают равными правами на доступ ко всему объему общей памяти, иными словами, система симметрична. Кроме того, в данных системах аппаратно поддерживается когерентность кэшей процессоров и общей памяти. Симметричность архитектуры позволяет выстроить

эффективный обмен с другими вычислительными устройствами.

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

Основные преимущества SMP систем:

- архитектура системы достаточно гибкая для обеспечения как параллелизма на уровне процессов (потоки для каждого ядра независимы), так и параллелизма на уровне инструкций (взаимозависимость потоков по данным);

- организация межпроцессорного обмена не представляет трудностей, так как существует достаточное количество общедоступных открытых многопоточных библиотек;

- низкая стоимость владения вследствие низкого энергопотребления: используются сравнительно небольшое количество коммутирующих устройств и конвекционная система охлаждения;

- низкая стоимость приобретения подобных систем.

Основной недостаток SMP систем - принципиально слабая масштабируемость. Максимальное количество процессоров в архитектуре находится в прямой зависимости от скорости системной шины.

Система NUMA (Non Uniform Memory Architecture) является расширением архитектуры SMP. Она представляет набор SMP модулей, соединенных через высокоскоростной интерфейс. Из внутренних блоков физической памяти каждого SMP модуля формируется виртуальный блок памяти со сплошной адресацией.

В системе NUMA удалось добиться увеличения количества процессоров по сравнению с SMP системой за счет изменения архитектуры коммутации и частично за счет снижения скорости обращения отдельного процессора к памяти. При аппаратной поддержке когерентности кэша процессоров система называется ccNUMA (cache-coherent NUMA).

Интересна модификация системы, называемая NUMAflex. Данная архитектура является кластером из набора SMP модулей, которые могут быть в реальном времени произвольным образом соединены в SMP или NUMA вычислительные узлы. В целом система NUMA обладает теми же характеристиками, что и SMP системы, за исключением производительности, возросшей за счет увеличения предела подключенных процессоров. Также NUMA системы обладают большей латентностью.

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

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

MPP-системы (Massively Parallel Processors) представляют собой класс систем с распределенной памятью [1]. Архитектура MPP систем является эволюционным развитием архитектуры SMP. В данных системах, как и в системах NUMA, атомарные блоки состоят или из SMP-модуля, или просто из пары процессор-память. Но в отличие от архитектуры NUMA, в MPP системах нет общей памяти. Каждому вычислительному узлу доступна только локальная память. Взаимодействие между вычислительными модулями осуществляется через протокол пересылки сообщений.

Вычислительные модули в MPP системе однородны. Так как в данном случае условно нет преград к масштабированию системы, то чаще всего в качестве процессоров используют низкопроизводительные RISK-процессоры с низким энергопотреблением. Ввиду того что в данной системе коммутация между узлами усложняется, в архитектуре появляются сервисные узлы: узлы ввода-вывода, коммутационные узлы (выполняющие роль контроллеров шины данных и шины адреса) и т.д.

Среди достоинств MPP-систем:

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

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

В качестве недостатков MPP-систем можно выделить:

- межпроцессорный обмен через протоколы передачи сообщений уступает аналогу в SMP, что повышает латентность системы;

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

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

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

Кластерная архитектура [8] идеологически близка к MPP архитектуре. В основе кластера - сеть из рабочих станций или персональных компьютеров. Каждый «вычислительный» узел кластера находится под управлением собственного экземпляра операционной системы. В качестве сети чаще всего используется один из стандартных интерфейсов (например, Ethernet).

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

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

Кластеры могут служить архитектурой не только систем для высокопроизводительных вычислений (1М1_Б- кластеры), но и систем высокой надежности (РО-кластеры) путем дублирования отдельных элементов или всей архитектуры кластера.

К достоинствам кластерной архитектуры относятся:

- гетерогенность (разнородность узлов кластера);

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

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

В качестве недостатка кластерной архитектуры можно выделить низкую удельную эффективность вычислений и повышенное энергопотребление системы.

Основные критерии выбора ПВС для реализации исследований - соответствие архитектуры структуре вычислительной машины языка «Пифагор», масштабируемость вычислительной системы. Из рассмотренных выше возможных архитектур для реализации ПВС требованиям, предъявляемым вычислительной машиной языка «Пифагор», полностью отвечает кластерная архитектура, как обладающая следующими важными особенностями:

- абстракция на уровне узлов ВС;

- гетерогенность ВС, что позволяет выделять специализированные узлы в системе;

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

- возможность построения высоконадежных систем (FO-кластеров).

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

1. Головкин Б.А. Параллельные вычислительные системы. М.: Наука, 1980. 520 с.

2. Казаков Ф.А., Кузьмин Д.А., Легалов А.И. Параллельный язык управления потоков данных // Математическое обеспечение и архитектура ЭВМ: сб. научных работ. Красноярск, 1997. Вып.2. С.105-113.

3. Крюков В.А. Разработка параллельных программ для вычислительных кластеров и сетей // Информационные технологии и вычислительные системы. 2003. № 1-2. С.42-61.

4. Кузьмин Д.А., Легалов А.И. Использование кластера для интерпретации функционально-параллельных программ // Актуальные проблемы электронного машиностроения: материалы VII междунар. конф. Новосибирск, 2004. Т.6. С.257-260.

5. Кузьмин Д.А., Легалов А.И. Трехуровневая эмуляция функционально-параллельных программ // Распределенные и кластерные вычисления: избранные материалы четвертой школы-семинара / Институт вычислительного моделирования СО РАН. Красноярск, 2005. С.140-147.

ский список

6. Кузьмин Д.А., Рыженко И.Н., Легалов А.И. Интерпретация функциональных программ под управлением Mosix // Вестник Красноярского государственного технического университета. Вып. 33: Математические методы и моделирование. Красноярск: ИПЦ КГТУ, 2004. С.218-227.

7. Модель функционально-потоковых параллельных вычислений и язык программирования «Пифагор» / А.И. Легалов [и др.] // Распределенные и кластерные вычисления: избранные материалы второй Школы-семинара / Институт вычислительного моделирования СО РАН. Красноярск, 2002. С.101-120.

8. Орлов С. Искусство объединения // Открытые системы: «LAN». 2003. №9. http://www.osp.ru/lan/2003/09/072.htm

9. Амамия Е., Танака Ю. Архитектура ЭВМ и искусственный интеллект / пер. с японск. М.: Мир, 1993. 400 с.

10. Пеппер П., Экснер Ю., Зюдхольд М. Функциональный подход к разработке программ с развитым параллелизмом // Системная информатика. Новосибирск: Наука, 1995. Вып.4. C.334-360.

i Надоели баннеры? Вы всегда можете отключить рекламу.