Разработка программного обеспечения с использованием OpenMP, MPI, CUDA

В ходе разработки были написаны две программы: тестовая и рабочая. В тестовой программе пользователь сам вводит количество элементов в векторе и сами элементы. В рабочей версии пользователь определяет только размер вектора.

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

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

Таблица 1.1. - Зависимость времени выполнения от количества элементов в массиве

Таблица 1.2. - Зависимости коэффициента ускорения времени выполнения от количества элементов в массиве и количества процессов.

Представим таблицу 1.2 в виде графиков. Результат представлен на рисунке 1.1.

Рис. 1.1 График коэффициента ускорения

1.4 Выводы по главе

При рассмотрении графика на рисунке 1.1 видно, что распараллеливание на малых размеров векторах (10 000, 100 000) нецелесообразно и ведет к увеличению времени работы программы. Это объясняется добавлением времени на создание потоков и дополнительной обработкой данных. Но распараллеливание большой размерности векторов (10 000 000, 100 000 000) целесообразно. Время при распараллеливании намного меньше, чем последовательное выполнение программы, не смотря на то, что во время входит работа по созданию дополнительных потоков и обработка данных.

Обобщив, можно сказать, что выполнение параллельных вычислений обосновано только при наличии большого объёма данных и возможности распараллелить алгоритм. При небольших объёмах данных выполнение без распараллеливания по времени превосходит выполнение с распараллеливанием.

2. Разработка программного обеспечения с применением технологии MPI

2.1 Теоретические сведения о технологии MPI

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

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

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

2.2 Разработка программы

Для выполнения программы использовались следующие процедуры MPI:

int MPI_Init(int *argc, char ***argv) - создается группа процессов, в которую помещаются все процессы приложения, и создается область связи, описываемая предопределенным коммуникатором MPI_COMM_WORLD. Эта область связи объединяет все процессы-приложения.

int MPI_Comm_rank(MPI_Comm comm, int *rank) - возвращает номер процесса, вызвавшего эту функцию.

INcomm- коммуникатор;

OUTrank- номер процесса, вызвавщего функцию.

int MPI_Comm_size(MPI_Comm comm, int *size) - возвращает количество процессов в области связи коммуникатора size.

INcomm- коммуникатор;

OUTsize- число процессов в области связи коммуникатора comm.

double MPI_Wtime(void) - возвращает астрономическое время в секундах, прошедшее с некоторого момента в прошлом.

int MPI_Bcast (void *buf, int count, MPI_Datatype datatype, int source, MPI_Comm comm) - рассылает сообщения от процесса source всем процессам, включая рассылающий процесс. При возврате из процедуры содержимое буфера buf процесса source будет скопировано в локальный буфер процесса.

OUT buf - адрес начала буфера посылки сообщения

IN count - число передаваемых элементов в сообщении

IN datatype - тип передаваемых элементов

IN source - номер рассылающего процесса

IN comm - идентификатор группы

int MPI_Reduce (sendbuf, recvbuf, count, datatype, op, root, comm) - объединяет элементы входного буфера каждого процесса в группе, используя операцию op, и возвращает объединенное значение в выходной буфер процесса с номером root. Буфер ввода определен аргументами sendbuf, count и datatype; буфер вывода определен параметрами recvbuf, count и datatype; оба буфера имеют одинаковое число элементов одинакового типа. Функция вызывается всеми членами группы с одинаковыми аргументами count, datatype, op, root и comm. Таким образом, все процессы имеют входные и выходные буферы одинаковой длины и с элементами одного типа. Каждый процесс может содержать либо один элемент, либо последовательность элементов, в последнем случае операция выполняется над всеми элементами в этой последовательности.

INsendbuf адрес посылающего буфера (альтернатива)

OUTrecvbuf адрес принимающего буфера (альтернатива, используется только корневым процессом)

INcount количество элементов в посылающем буфере (целое)

INdatatype тип данных элементов посылающего буфера (дескриптор)

INop операция редукции (дескриптор)

INroot номер главного процесса (целое)

INcomm коммуникатор (дескриптор)

int MPI_Finalize(void) - закрывает все MPI-процессы и ликвидирует все области связи.

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

Конфигурация ПК:

Процессор: AMD A10-574M;

ОЗУ: 6 Гб;

ОС: Windows 10.

2.3 Вычислительный эксперимент

В ходе разработки были написаны две программы: тестовая и рабочая. В тестовой программе пользователь сам вводит количество элементов в векторе и сами элементы вектора. В рабочей версии пользователь определяет только размер вектора.

Рис. 2.1. Скриншот выполнения тестовой версии программы

Таблица 2.1. - Результаты выполнения программы с различными режимами

Здесь K - кол-во процессов, n - кол-во элементов в массиве, t - время выполнения программы, k - коэффициент ускорения.

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

Рис. 2.2. Графики коэффициентов ускорения.

программа интерфейс вычислительный

3. Разработка программного обеспечения с применением технологии CUDA

3.1 Теоретические сведения о технологии CUDA

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

Направление вычислений эволюционирует от «централизованной обработки данных» на центральном процессоре до «совместной обработки» на CPU и GPU. Для реализации новой вычислительной парадигмы компания NVIDIA изобрела архитектуру параллельных вычислений CUDA, на данный момент представленную в графических процессорах GeForce, ION, Quadro и Tesla и обеспечивающую необходимую базу разработчикам ПО.

Платформа параллельных вычислений CUDA® обеспечивает набор расширений для языков C и С++, позволяющих выражать как параллелизм данных, так и параллелизм задач на уровне мелких и крупных структурных единиц.

Использующая технологию CUDA программа имеет два типа функций: функции host-кода -- набор инструкций, который выполняет центральный процессор; и функций device-кода -- набор инструкций, который выполняет процессором графического адаптера. Фактически, технология позволяет программисту включать в программу специальные функции на C подобном языке, которые при запуске программы будут выполнены графическим процессором.

Алгоритм:

1. Запуск программы;

2. Ввод n -- степень для вычисления k;

3. Выделение памяти под массивы размером (b - a) / h, (a = 1, b = N + 1);

4. Выделение памяти для девайсовых переменных. Задача работы на GPU. Конфигурация ядра;

5. Повторить в цикле на GPU и CPU i = 0, i < (b - a)/h, i = i + 1

6.Вывод результатов;

7.Освобождение памяти;

Делее представлен список используемых параллельных методов вычислений в программе. Этот список верен и для задания №2.

cudaError_t cudaMalloc(void** devPtr, size_t size) -- выделение памяти на видеокарте, devPtr - указательна участок памяти на устройстве, size - размер выделяемой памяти в байтах.

cudaError_t cudaMemcpy (void* dst, const void* src, size_t count, enum cudaMemcpyKind kind) - копирование данных между хостом и устройством, dst и src -- указатели на приемник и источник соответственно (могут указывать на память как на хосте, так и на устройстве), count - размер копируемых данных в байтах, kind - одно из четырех значений (cudaMemcpyHostToDevice, cudaMemcpyDeviceToHost, cudaMemcpyHostToHost, cudaMemcpyDeviceToDevice), обозначающих направление копирования

ccudaError_t cudaFree(void* devPtr) - освобождение памяти на устройстве, devPtr - указатель на память на устройстве

dim3 DimGrid (numOutputElements, 1, 1) - размер грида для запуска. Грид может быть одно- и двухмерным, причем максимальное значение по каждому измерению (65536, 65536, 1), а максимальное число блоков в гриде не может превышать 4294967296.

dim3 DimBlock (BLOCK_SIZE, 1, 1) - размер блока при запуске. Блок может одно-, дву- и трехмерным, причем максимальное значение по каждому измерению (512, 512, 64), а максимальное число тредов в блоке не может превышать 512.

kernelFunk <<<blocks, threads>>> () - вызов ядра на GPU, blocks - количество блоков в сетке, threads - количество потоков в блоке.

В ходе разработки были написаны две программы: тестовая и рабочая. В тестовой программе пользователь ничего не вводит и степень для вычисления шага по умолчанию равна 1. Так же выводятся два массива: вычисленные данные на GPU и на CPU. В рабочей программе пользователь сам вводит степень для вычисления шага.

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

Ниже представлен результат выполнения тестовой версии.

Степень при вычислении шага = 1

Шаг: 0.1 Количество значений функции: 40

==14652== NVPROF is profiling process 14652, command:./cudav42t.bin

Результат вычисления (первые 5 значений):

-0.656473 = -0.656473

-0.252597 = -0.252597

0.61468 = 0.614679

2.86333 = 2.86333

11.0881 = 11.088

==14652== Profiling application:./cudav42t.bin

==14652== Profiling result:

Time(%) Time Calls Avg Min Max Name

62.34% 6.1440us 1 6.1440us 6.1440us 6.1440us calcFunction(float*, float)

22.73% 2.2400us 1 2.2400us 2.2400us 2.2400us [CUDA memcpy DtoH]

14.94% 1.4720us 1 1.4720us 1.4720us 1.4720us [CUDA memcpy HtoD]

Как видно из результата профайлера: большую часть времени занимает время исполнения ядер (62%), остальное время занимает передача данных.

Выполнение рабочей версии программы:

Степень при вычислении шага: 6

Шаг:

1e-06 Количество значений функции: 4000000

==15800== NVPROF is profiling process 15800, command:./cudav42w.bin

Время GPU: 8.75824

Время CPU: 368.321

==15800== Profiling application:./cudav42w.bin

Time(%) Time Calls Avg Min Max Name

65.82% 5.2924ms 1 5.2924ms 5.2924ms 5.2924ms [CUDA memcpy DtoH]

34.18% 2.7481ms 1 2.7481ms 2.7481ms 2.7481ms [CUDA memcpy HtoD]

По результатам полученного профайлера, видно, что почти всё время занимает передача данных. А время исполнения ядер настолько мало, что даже не вывелось на экран. В рабочей программе было замерено время выполнения, не учитывая время на выделение памяти и освобождение памяти на CPU. Результаты собраны в таблице 3.1, где k - делитель в формуле вычисления шага h=N/ k.

Таблица 3.1. - Расчет времени на CPU и GPU

Алгоритм выполнения:

1.Запуск программы;

2.Ввод n -- количество элементов в массиве, block_size = 512;

3.Выделение памяти под массив massive размером n и инициализация массива случайными числами;

4.mul = 1;

5.повторить в цикле i = 1, n: mul = mul * massive_i;

6.Выделение памяти для девайсовых переменных. Задача работы на GPU. Конфигурация ядра;

7.Кол-во блоков = n / (block_size * 2);

8.повторить в цикле

i = blockDim.x, i > 0, i /= 2:

if (threadIdx.x < i)

mul__threadIdx.x *= mul__{threadIdx.x + I};

9.output_blockIdx.x = mul_ _threadIdx.x;

10. Перемножение частичных произведений каждого блока;

11. Вывод результатов;

12.Освобождение памяти.

В тестовой программе пользователь сам вводит количество элементов в векторе и сами элементы вектора. В рабочей версии пользователь определяет только размер вектора.

По результатам полученного профайлера на рисунке 3.1, видно, что большую часть времени занимает исполнение ядер (62%). Остальное время занимает передача данных.

Выполнение рабочей версии программы представлено ниже.

Enter vector size:

1000000=5339= NVPROF is profiling process 5339, command:./cudav4w.bin

Время GPU: 1.380224, результат 89.381302

Время CPU: 3.635904, результат 89.387039

==5339== Profiling application:./cudav4w.bin

==5339== Profiling result:

Time(%) Time Calls Avg Min Max Name

86.03% 704.65us 1 704.65us 704.65us 704.65us [CUDA memcpy HtoD]

13.59% 111.33us 1 111.33us 111.33us 111.33us total(float*, float*, int)

0.38% 3.1040us 1 3.1040us 3.1040us 3.1040us [CUDA memcpy DtoH]

По результатам полученного профайлера видно, что большую часть времени (86,4%) занимает копирование данных. Остальное время - исполнение ядер.

В рабочей программе было замерено время выполнения, не учитывая время на выделение памяти и освобождение памяти на CPU. Результаты собраны в таблице 3.2.

Таблица 3.2. - Зависимость времени выполнения от размера вектора

По полученным в результате эксперимента таблицам 3.1 и 3.2 видно, что GPU версия с разделяемой памятью выполняется быстрее, чем версия на CPU. Так же стоит отметить, что я учитывала время копирования данных с хоста на девайс и обратно. Именно копирование занимает большую часть времени, поэтому количество перемещений данных между CPU и GPU по-возможности необходимо свести к минимуму. Потому что при маленьком наборе данных время для передачи информации между GPU и CPU занимает большую часть общего времени. Но при большом объёме данных время расчета на GPU вместе с копирование на девайс и обратно меньше, чем вычисления на CPU. Но при условии, что алгоритм хорошо распараллеливается. Для вычисления значений функции алгоритм подошел очень хорошо, так как он не итерационный и вычисления не зависят от других значений. А в вычислении произведения вычислялось частичное произведение некоторых отрезков вектора, а затем уже эти частичные произведения перемножались между собой.

Объединив результаты всех полученных профайеров, получим, что если данных мало (как на тестовых программах), то большую часть общего времени занимают вычисления (~60%), а не передача данных. На реальных данных гораздо большего размера время передачи данных занимает большую часть общего времени (86% и почти 100%). Но даже с учетом времени копирования вычисления на GPU выполняются намного быстрее, чем на CPU.

Заключение

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

Целью данной курсовой работы были: разработка программного обеспечение по заданной задаче с использованием технологий OpenMP, MPI и CUDA и дальнейший анализ полученных данных.

Задачи курсовой работы:

ознакомление с технологиями OpenMP, MPI и CUDA со средствами дл организации параллельного выполнения программы;

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

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

При анализе полученных данных для OpenMP, оказалось, что распараллеливание для векторов малых размеров (10 000, 100 000 элементов) нецелесообразно и ведет к увеличению времени работы. Это объясняется затратой ресурсов на инициализацию дополнительных процессов и передачу данных. Но распараллеливание векторов больших размеров (10 000 000, 100 000 000 элементов) оправдывает себя. Время, затраченное на выполнение получается намного меньше даже вместе даже с потраченным временем на создание новых процессов и передачу данных.

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

По полученным в результате эксперимента данным при использовании технологии CUDA видно, что GPU версия с разделяемой памятью выполняется быстрее, чем версия на CPU. Стоит отметить, что именно копирование занимает большую часть времени. Поэтому при маленьком наборе данных время для передачи информации между GPU и CPU занимает большую часть общего времени. Но при большом объёме данных время расчета на GPU вместе с копирование на девайс и обратно меньше, чем вычисления на CPU.

Объединив результаты всех полученных профайеров, получим, что если данных мало (как на тестовых программах), то большую часть общего времени занимают вычисления (~60%), а не передача данных. На реальных данных гораздо большего размера время передачи данных занимает большую часть общего времени (от 86% до 99%). Но даже с учетом времени копирования вычисления на GPU выполняются намного быстрее, чем на CPU.

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

Список литературы

1. Антонов А.С. Параллельное программирование с использованием технологии OpenMP: Учебное пособие. - М.: Изд-во МГУ, 2009. - 77 с.

2. Антонов А.С. Параллельное программирование с использованием технологии MPI: Учебное пособие. - М.: Изд-во МГУ, 2004. - 71 с.

3. Боресков А. В., Харламов А. А. Основы работы с технологией CUDA. - М.: ДМК Пресс, 2010. - 232 с: ил.

4. Параллельные вычисления [Электронный ресурс] // Википедия Свободная энциклопедия.

5. Актуальность параллельных вычислений [Электронный ресурс] // Хабрахабр, 2011.

6. OpenMP и C++ [Электронный ресурс] // Microsoft, Канг Су Гэтлин, Пит Айсенси.

7. ПАРАЛЛЕЛЬНЫЕ ВЫЧИСЛЕНИЯ С CUDA [Электронный ресурс] // nvidia.

8. CUDA: Как работает GPU [Электронный ресурс] // Хабрахабр, 2009.

9. Параллельные вычисления. MPI. CUDA [Электронный ресурс] // Indico Integrated Digital Conference. Поминов Роман, ИФВЭ, 2011.

Размещено на Allbest.ru