Lecture_DVM_1 (1158298), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Ниже приводятся данные об эффективности выполнения шести тестов из пакета NPB 2.3 (BT, CG, FT, LU, MG, SP) класса А, реализованных с использованием подходов, выбранных для сравнительного анализа.

Два других теста из пакета NPB 2.3 (IS и EP) не использовались при исследовании применимости HPF-подхода и гибридного подхода OpenMP+MPI. Причиной этого было то, что первый из них написан на языке Си и не является представительным (параллельная сортировка целых чисел), а второй служит для демонстрации абсолютного параллелизма и его распараллеливание ни у кого никаких проблем не вызывает.

Использованные в приведенных ниже диаграммах данные, заимствованные из различных источников [23,24], были получены на разных параллельных системах. Тем не менее, они позволяют сделать достаточно объективные выводы.

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

• Speedup – ускорение выполнения параллельной программы на нескольких процессорах по отношению к ее выполнению на одном процессоре.

• Efficiency – эффективность параллельного выполнения, равная отношению ускорения к числу процессоров.

Ниже для каждого теста приведены отношения времени выполнения его MPI-версии к времени выполнения версии этого теста, разработанной с использованием трех других подходов (HPF, OpenMP+MPI, DVM).

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

При использовании подхода OpenMP+MPI в MPI-программу для отдельного узла вставлялись директивы OpenMP. Отсюда довольно неожиданный вывод – даже на мультипроцессоре с 4 процессорами на общей памяти, используемом в качестве узла IBM SP, OpenMP проигрывает на регулярных программах MPI-подходу. Это объясняется лучшей локализацией доступа к данным в MPI-программе, что приводит к более эффективному использованию кэш-памяти.

Большой проигрыш HPF при увеличении числа процессоров объясняется принципиальными недостатками HPF-подхода, о которых говорилось выше.

Эффективность DVM-программ гораздо выше, чем эффективность HPF, и вполне сравнима с эффективностью MPI. Для оценки масштабируемости DVM-программ приведены данные о соотношении времен выполнения MPI-версий и DVM‑версий на ЭВМ МВС-1000м [25] для всех восьми тестов класса С (тесты этого класса ориентированы на высокопроизводительные параллельные системы, требуют много памяти и поэтому не могут выполняться на малом числе процессоров).

Из них следует, что в среднем эффективность DVM-версий составляет около 80% от эффективности MPI-версий.

Конечно, сравнение на тестах NPB 2.3 не вполне правомерно – они написаны на очень высоком профессиональном уровне и являются объектом пристального внимания многих специалистов. При разработке реальных параллельных программ, как правило, достижение высокой эффективности требует многократных изменений программы для поиска наилучшей схемы ее распараллеливания. Успешность такого поиска определяется простотой модификации программы. Кроме того, прикладному программисту трудно реализовать многие часто используемые приемы распараллеливания так же эффективно, как они реализуются системами программирования. Поэтому на реальных программах MPI-подход, как правило, проигрывает по эффективности DVM-подходу.

5. Переносимость и повторное использование параллельных программ

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

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

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

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

Гораздо хуже обстоят дела с повторным использованием MPI-программ. Очень сложно разрабатывать программы, способные выполняться на различном числе процессоров с разными по объему данными. Многие программисты предпочитают иметь разные варианты программ для разных конфигураций данных и процессоров, а также иметь отдельный вариант программы для работы на однопроцессорной ЭВМ. В таких условиях использование чужой программы представляется гораздо менее вероятной, чем это было на традиционных ЭВМ.

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

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

Все вышесказанное в значительной мере относится и к гибридному подходу OpenMP+MPI.

Таких принципиальных проблем с повторным использованием параллельных программ нет, если эти программы разрабатываются в рамках подходов HPF или DVM. Более того, в рамках этих подходов можно обеспечить удобный вызов стандартных параллельных программ, разработанных на других языках и входящих в состав известных библиотек (для которых известно их внутреннее представление распределенных массивов). Например, можно позволить вызывать функции пакета ScaLAPACK [26] из HPF-программ или DVM-программ.

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

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

Кроме того, программы на языке Fortran-DVM могут автоматически конвертироваться в программы на языке HPF, HPF2 и OpenMP.

Способность параллельных программ эффективно выполняться на неоднородных кластерах и сетях ЭВМ требует отдельного рассмотрения.

Все три подхода, базирующиеся на существующих стандартах (MPI, HPF, OpenMP+MPI), не рассчитаны на применение на неоднородных распределенных системах.

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

В DVM-системе реализованы возможности задания производительностей процессоров (или их автоматического определения при запуске программы) и их учета при распределении данных и вычислений между процессорами. Это позволяет DVM-программам эффективно выполняться на неоднородных кластерах. Это подтверждают результаты пропуска тестов NAS на модели неоднородного кластера.

Неоднородный кластер был смоделирован на машине МВС-1000м путем увеличения процессорных времен между последовательными обращениями к MPI функциям.

Ниже на диаграммах показано соотношение времен выполнения MPI и DVM версий тестов NAS (класс С) на следующих конфигурациях:

• CL1 – 128 процессоров со скоростью выполнения P,

• CL2 – 128 процессоров со скоростью выполнения 3P,

• CL3 – 128 процессоров со скоростью выполнения P и 128 процессоров со скоростью выполнения 3P (неоднородный кластер).

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

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

Но и в этом случае, DVM-подход может обеспечить эффективное выполнение многих параллельных программ.

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

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

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

6. Заключение

На основании проведенного анализа четырех различных подходов к разработке параллельных программ для вычислительных кластеров и сетей ЭВМ (MPI, HPF, OpenMP+MPI и DVM) можно сделать следующие выводы.

1. С точки зрения простоты разработки и сопровождения параллельных программ, а также их повторного использования явное преимущество имеют подходы HPF и DVM.

2. По эффективности выполнения программ HPF заметно отстает от остальных подходов.

3. Гибридный подход OpenMP+MPI, MPI-подход и HPF-подход, не могут обеспечить эффективного выполнения программ на неоднородных кластерах и сетях ЭВМ.

Таким образом, ни один из трех подходов (MPI, HPF, и OpenMP+MPI), базирующихся на имеющихся стандартах, не может рассматриваться в настоящее время как вполне подходящий для разработки параллельных программ для вычислительных кластеров и сетей ЭВМ. Эту точку зрения разделяют многие ведущие специалисты в области параллельных вычислений.

Освоение DVM-подхода может существенно сократить время написания, отладки и сопровождения программ, и позволит создавать параллельные программы, эффективно выполняющиеся на вычислительных кластерах и сетях.

Характеристики

Список файлов лекций