![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
Пример разработки приложения для гибридной параллельной вычислительной системы.Приложение: решение задачи Дирихле для уравнения Пуассона на равномерной прямоугольной сетке.Начнем с планирования структуры исходного текста. Текст приложения делится на общую часть и реализацию конкретного численного метода на конкретном оборудовании. Общая часть (в нашем случае – главная программа) не должна, по возможности, зависеть ни от выбранного метода решения задачи (например, метода Якоби, метода верхней релаксации или какого-то другого), ни от вида оборудования, выбранного для реализации вычислительно-емкой части приложения. Реализация конкретного метода на конкретном оборудовании (набор вызываемых функций), напротив, зависит и от того, и от другого, но должна быть оформлена некоторым унифицированным образом. Например, набор функций, реализующий метод Якоби на SMP-узле, не должен, в идеале, отличаться по внешнему интерфейсу от набора функций, реализующего метод верхней релаксации на векторно-мультитредовом ускорителе. Поделив приложение на две такие части, мы делаем первый и самый главный шаг в разработке гибридного приложения – структурно выделяем и локализуем именно ту часть программы, которую предстоит переписывать в расчете на нестандартную архитектуру вычислителя. В реальных приложениях эта часть (реализация конкретного метода на конкретном оборудовании) обычно составляет довольно малую долю исходного текста. Общая часть, очевидно, включает в себя логику организации итерационного процесса на многоузловом вычислителе. Для каждого из узлов эта логика проста и хорошо известна:
В данном модельном приложении с целью его упрощения контроль сходимости опущен. Выполняется фиксированное, заранее заданное число итераций. В качестве части, реализующей конкретный численный метод на конкретном оборудовании, естественно выделить выполнение одной итерации метода над той частью сетки, которая обрабатывается данным узлом. При попытке спроектировать интерфейс между двумя частями приложения (прототипы вызываемых функций), обнаруживаем существенное различие между чисто программной реализацией и реализацией с использованием ускорителя. При чисто программной реализации в функцию, реализующую одну итерацию выбранного метода, достаточно передать в качестве аргумента указатель на часть сетки, обрабатываемую данным узлом. При реализации на том или ином сопроцессоре – ускорителе эта часть сетки, очевидно, была предварительно скопирована в память ускорителя, где и обрабатывается. Для того, чтобы после очередной итерации можно было выполнить обмен границами, соответствующие значения надо:
Унификация интерфейса с общей частью приложения означает, что реализация конкретного метода должна включать в себя функции обмена данными между процессором узла и ускорителем. В случае, если конкретная реализация никаких ускорителей не использует, эти функции будут пустыми, но главная программа их все равно вызовет «на всякий случай». В полной аналогии с функциями передачи данных между процессором и сопроцессором – ускорителем, «на всякий случай» в функции выполнения итерации вводятся дополнительные аргументы: указатели на обрабатываемые данные в памяти ускорителя. Чисто программная реализация эти аргументы игнорирует. Ниже приводится описание программного интерфейса общей части приложения. Программный интерфейс вычислительного ядра «итерация численного метода решения задачи Дирихле для уравнения Пуассона».Прототипы функций находятся в poissn.h. Задача решается в прямоугольнике, на равномерной прямоугольной сетке. Данные, используемые в расчете
Описание функций:
Обзор текста реализаций метода Якоби на различном оборудовании.Тексты общей части приложения progrev_shmem.c и poissn.h в особых комментариях не нуждаются. Для лучшей ориентации в вызываемых функциях коммуникационной библиотеки полезно иметь под рукой текст ее описания. Текст программной реализации метода находится в файле poissn_soft.c. Этот текст в действительности содержит в себе два разных текста: текст реализации метода на единичном процессоре и текст реализации метода на SMP-узле при помощи OpenMP. При трансляции обычным компилятором, в котором поддержка OpenMP отсутствует или выключена, директивы #pragma игнорируются, и получается реализация метода на единичном процессоре. Если мы захотим запустить это приложение на МВС-экспресс, каждый вычислительный узел которой содержит по 3 доступных пользователю процессорных ядра, есть смысл воспользоваться командой запуска на счет, порождающей по 3 пользовательских процесса на каждом узле установки (в полном соответствии с Руководством пользователя). При трансляции этого же исходного текста компилятором с работающей поддержкой OpenMP мы получим реализацию метода на SMP-узле, то есть параллельную программу с гибридным параллелизмом. Каждую ветвь такой программы следует запускать на одном вычислительном узле МВС-экспресс. Использование для параллельного счета того факта, что узел содержит несколько процессорных ядер, достигается средствами OpenMP. Наконец, можно реализовать метод на векторно-мультитредовом ускорителе CUDA, входящем в состав каждого из узлов МВС-экспресс. По техническим причинам, упомянутым в Руководстве пользователя, общую часть приложения придется оформить как программу на C++, хотя по существу это программа на C. Файл progrev_shmem.cpp отличается от варианта из общей части приложения для программной реализации только расширением («.cpp» вместо «.c») и именем включаемого файла прототипов библиотечных функций (shmem++.h вместо shmem.h). В этом случае каждая ветвь приложения запускается на отдельном узле МВС-экспресс, поскольку она (ветвь) нуждается в отдельном ускорителе CUDA, а в составе узла такой ускоритель один. Текст реализации метода на ускорителе находится в poissn_cuda.cu. При рассмотрении этого текста важно понимать следующее. На первый взгляд, его сходство с текстом для универсального процессора не просматривается вообще. Тем не менее, текст этот в действительности реализует ровно ту же вычислительную процедуру, что и текст программной реализации метода. Отсутствие внешнего сходства объясняется тем, что при переносе приложения с универсального процессора на ускоритель зачастую мало бывает механически учесть различия в системе программирования между ускорителем и процессором общего назначения. Для того, чтобы расчет от такого переноса ускорился в максимальной степени, иногда требуется предварительно переписать алгоритм в другой форме. В данном случае было сделано именно это. Чтобы облегчить понимание текста для ускорителя, следует рассмотреть вариант этого текста для универсального процессора, переписанный в такой форме, чтобы его перенос на ускоритель дал максимальный эффект. Отличия сосредоточены, в основном, в функции poissn(). Сводятся они к тому, что в программе организуются три вспомогательных массива, которые содержат предыдущую, текущую и следующую обрабатываемую строки матрицы. При переписывании для ускорителя именно эти вспомогательные массивы будут размещены в быстрой, расслоенной памяти ускорителя, что и позволит достичь максимального ускорения. Отметим, что эта техника реализации сама по себе способна несколько ускорить расчет, даже на универсальном процессоре. На ускорителе же эффект от ее применения является многократным. Приложения
|
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||
Тел. +7(499)220-79-72; E-mail: inform@kiam.ru |