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

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

Эффективность (ускорение) показывает, что OpenMP даёт больший прирост производительности, нежели использование дополнительных процессоров. Это вполне ожидаемо, т.к. нити openmp используют разделяемую память и им не приходится обмениваться данными через MPI вызовы.

Эффективность для технологии CUDA при малом размере задачи растёт крайне нелинейно, это связано с тем, что при увеличении количества вычислительных узлов, количество пересылок возрастает, в то время как количество вычислений на каждый узел – падает, это приводит к падению эффективности, так как существенная часть времени уходит на пересылки данных.

Данный эффект может наблюдаться для совершенно любых задач, однако для высокопроизводительной cuda и исследуемого размера задачи оно достигается уже на малом количестве узлов (так – оптимальная эффективность достигается для сетки 1000x1000 на 7-ми узлах)

График зависимости времени выполнения (в мс) от количества процессов для выполнения на разных архитектурах, разных матриц, с разными технологиями, при отключённых оптимизациях компилятора (без флага «-O3»)

Объединённый рисунок:

Визуализация 4-х самых быстрых составов (аппаратура - размер матрицы – использованная технология):

Стоит отметить, что BlueGene/P отличается крайне высокой стабильностью времени вычисления (выяснено практическим путём).

1. Точное решение диф. уравнения

Точное решение дифференциального уравнения совпадает с функцией граничного условия.

Достаточно подставить u(x,y) = ln(1+x*y)

1. Графическое изображение функции, погрешности вычислений

1. Графическое изображение точного аналитического решения и вычисленного решения дифференциального уравнения

Рисунок приближённого решения для сетки размером 2000x2000 (визуально изображение совпадает при использовании любых, из приведённых выше технологий):

Рисунок точного решения (100x100 точек):

1. Графическое изображение абсолютной погрешности

Для всех архитектур (NVIDIA Tesla X2070, Lomonosov Intel Xeon X5570, BlueGene/P PowerPC 450) графические изображения визуально не отличаются.

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

• Ломоносов (nvidia tesla и intel xeon) – 32 процесса, матрица 1000x1000

• BlueGene/P (PowerPC) – 128 процессов, матрица 1000x1000

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

Графическое изображение абсолютной погрешности:

Заметим, что несмотря на то, что рассчёты велись пока шаг итерации не изменит значение функции менее, чем на 0.0001, само итоговое решение имеет погрешность гораздо большую (на 2 порядка).

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

1. Графическое изображение относительной погрешности

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

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

Графическое изображение относительной погрешности (граничные точки обрезаны, так как функция принимает в этих точках значение ноль):

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

1. Графическое изображение скорости сходимости.

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

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

Графический вид сходимости для конфигураций (BlueGene/P, p=128, n=1000) и (Lomonosov, p=32, n=1000) – совпадает:

Графическое изображение сходимости для конфигурации, соответствующее вычислениям на графической карте (Lomonosov (cuda), p=1, n=1000), также ничем не отличается:

1. Профилирование и анализ работы с графическим ускорителем

Профилирование проводилось для разбиения сетки 5000x5000, одной gpu карты NVIDIA Tesla X2070 на Lomonosov и первых 3-х итераций алгоритма.

Общий вид загрузки графического ускорителя:

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

По результатам профилирования можно отметить, что все задачи разделяются на 2 категории:

• очень большие (рассчёты, которые ведутся на всей внутренней области сетки)

• очень маленькие (рассчёты, которые ведутся для краёв разбиения (краёв сетки))

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

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

При вычислении скалярного произведения (stream1), ядра выполняются без описанной выше задержки (потому что там отсутствует работа cpu между вызовами ядер, просто подряд запускаются gpu ядра).

Работа с памятью почти полностью отсутствует, так как почти все вычисления в моей программе производятся на gpu и данные туда/оттуда почти не пересылаются.

В stream21 можно видеть выполнение очень короткой задачи counting_5star_nxm_corners. Она хорошо показывает, что после старта задачи в stream12 counting_5star_insides, cpu продолжает свою работу (там в частности происходит небольшая работа с mpi (небольшая, т.к. профилирование происходило для 1 процесса, и поэтому там холостые waitall, а также несколько проверок, которые не пошлют данные соседним процессам (так как их нету))), и уже после того, как cpu отработает часть своих задач, оно запустит на выполнение короткую задачу, которая выполнится параллельно основной долгой задаче.

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

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

29

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

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