Гдз по английскому спотлайт тетрадь 9 класс: ГДЗ по английскому языку 9 класс рабочая тетрадь Эванс, Дули Решебник

Солнечные бури состоят из массивных взрывов на Солнце, которые могут высвободить энергию более 2 миллиардов мегатонн в тротиловом эквиваленте в форме солнечных вспышек и корональных выбросов массы (CME). КВМ выбрасывают в космос миллиарды тонн намагниченной плазмы, и хотя большинство из них полностью проходит мимо Земли, в прошлом были такие, которые нанесли бы огромный ущерб нашему современному технологическому обществу, если бы столкнулись с нами.Чтобы предсказать последствия таких потенциально катастрофических ударов, нам необходимо более глубокое понимание динамики возникновения и распространения КВМ. Глобальное магнитогидродинамическое (МГД) моделирование, основанное на данных наблюдений, является ключевым компонентом в достижении этой цели.

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

Код MAS

Код магнитогидродинамического алгоритма вне сферы (MAS) разрабатывался более 15 лет и широко использовался в исследованиях солнечной физики, включая моделирование CME и солнечного ветра. Например, его использовали для предсказания того, как будет выглядеть корона во время полного солнечного затмения 21 августа 2017 года [1-3]. MAS решает уравнения термодинамической резистивной магнитогидродинамики на неоднородной сферической сетке.MAS, состоящий из более чем 50 000 строк кода FORTRAN, распараллеливается с использованием MPI, что позволяет ему работать на тысячах процессоров.

Почему именно графические процессоры?

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

Почему OpenACC?

Переписывание больших разделов кода MAS для графических процессоров с использованием низкоуровневых API, таких как CUDA или OpenCL, невозможно из-за требований переносимости и разработки, предъявляемых экспертами в предметной области. OpenACC предлагает отличное решение этих проблем, поскольку он переносим, ​​поскольку код можно запускать на процессорах, графических процессорах и других поддерживаемых архитектурах. Полученный ускоренный код также обратно совместим, поскольку его можно скомпилировать для работы на процессорах с использованием любого ранее поддерживаемого компилятора, просто игнорируя комментарии OpenACC.Поэтому мы решили использовать OpenACC, чтобы добавить ускорение графического процессора к MAS.

Можно ли перенести ваш код? Когда начать?

Кодовые стили

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

В нашем случае нам повезло в том, что MAS использует чистый, модернизированный код FORTRAN 90 и по большей части не страдает от вышеуказанных проблем стиля программирования. Это сделало его отличным кандидатом для реализации OpenACC. Еще одна полезная особенность MAS заключается в том, что параллелизм MPI реализован минимизированным образом, когда каждый ранг работает на небольшом кубе сетки независимо и взаимодействует с MPI только при необходимости.

Рис. 1. Профилированное относительное время для участков кода MAS, выполняющих большое моделирование нулевого бета

Профилирование

Затем используйте профилировщик, чтобы найти критически важные части кода, связанные с производительностью. Эти части кода должны быть нацелены в первую очередь, чтобы определить, гарантирует ли ускорение, полученное с помощью OpenACC, полную реализацию кода. Если эти части кода можно выделить в сокращенный вариант кода или разделить на тестовый код, тем лучше.

Код MAS может быть запущен с минимальным подмножеством полной физической модели, называемой нулевой бета-моделью, которая не учитывает тепловое давление и гравитацию, а эволюция осуществляется просто под действием магнитных сил.Хотя это упрощенная модель, она все еще используется в производстве для различных симуляций, таких как создание начальных конфигураций магнитного поля CME и изучение начала / ранней эволюции извержений. Основные алгоритмы ядра в MAS одинаковы в запусках нулевой бета-версии, поэтому наша цель для представленной здесь первоначальной реализации OpenACC - запустить MAS на нескольких графических процессорах для таких запусков. Профилирование кода показывает, что решатели разреженных предварительно обусловленных сопряженных градиентов (PCG), используемые для уравнений скорости (полунявный предиктор-корректор и вязкость), отвечают за более 90% времени выполнения наших тестовых задач, как показано на рисунке 1. .

Анализ алгоритмов: ключ к векторизации

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

Совет по векторизации от PGI! Выделенные массивы в FORTRAN обычно используются непрерывно. Следовательно, они должны быть объявлены для размещения вместо указателя (или, по крайней мере, указатель, непрерывный ), чтобы сообщить компилятору, что векторизовать

В MAS операции в решателях PCG состоят из разреженных матрично-векторных произведений (операции трафарета), операций AXPY и скалярных произведений, все из которых векторизуемы.Остается только этап предварительной подготовки (ПК). MAS использует два предварительных кондиционера без связи. Первый (PC1) - это точечный Якоби (диагональное масштабирование), а второй (PC2) - это блочный Якоби, использующий неполную LU факторизацию с заполнением нулями. Для прогонов MAS, которые имеют матричное решение, требующее множества итераций решателя («жесткие» решения), PC2 работает быстрее, чем PC1. Однако, когда для решения требуется лишь небольшое количество итераций («простые» решения), использование PC1 выполняется быстрее, чем PC2. PC2 полагается на решения локальной треугольной матрицы, которые вычисляются с использованием стандартного последовательного алгоритма назад и вперед.К сожалению, эта реализация не позволяет ускорить его с помощью OpenACC. Существуют более продвинутые треугольные решатели, а для графических процессоров библиотека NVIDIA cuSparse содержит два таких метода [4].

Поскольку мы не были уверены, что наши алгоритмы достигнут желаемой производительности на графических процессорах, мы решили, что лучше сначала протестировать их, используя гораздо меньший код, который использует идентичный решатель PCG от MAS под названием POT3D. После внедрения OpenACC и связывания кода с cuSparse для алгоритма PC2 мы обнаружили, что наши матрицы не подходят для эффективного решения треугольных матриц с использованием cuSparse, в результате чего PC1 и PC2 имеют почти одинаковую производительность на графических процессорах.Однако производительность по-прежнему была довольно хорошей по сравнению с запуском на CPU (даже при использовании PC2!). Следовательно, для MAS нам нужно только реализовать PC1, который имеет огромное преимущество в том, что код остается переносимым! (Подробнее о нашей реализации POT3D см. [5-6]). После успеха этой проверки концепции первоначальная реализация MAS получила зеленый свет.

Diving In! Подробности реализации OpenACC

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

Цикл OpenACC Do

Ниже приведен пример OpenACC, примененного к операции do loop с тройным вложением трафарета в MAS:

! $ Acc ядра по умолчанию (присутствует) присутствует (ps) async (1)
! $ acc независимо от цикла
  сделать k = 2, npm1
! $ acc, независимый от цикла
    сделать j = 2, ntm1
! $ acc независимо от цикла
      сделать я = 2, nrm-1
        ii = ntm2 * (nrm-2) * (k-2) + (nrm-2) * (j-2) + (i-1)
        q (ii) = a_r (i, j, k, 1) * ps% r (i, j, k-1)
& + a_r (i, j, k, 2) * ps% r (i, j-1, k)
             + ...
      Enddo
    Enddo
  Enddo
! $ acc end ядра
c... две одинаковые петли ...
! $ acc подождите
 

Обход ошибки
Предложение present (ps) в этом цикле необходимо из-за текущей ошибки в компиляторе PGI (начиная с версии 18.4). по умолчанию (присутствует) не определяет производный тип должным образом. Использование явного настоящего позволяет избежать проблемы.

Директива ядра указывает компилятору распараллелить цикл; предложение по умолчанию (присутствует) сообщает компилятору, что мы уже поместили все массивы данных на GPU.Директива loop сообщает компилятору, что цикл должен быть распараллелен, в то время как независимое предложение сообщает компилятору, что мы уверены, что каждая итерация цикла независима друг от друга и может быть вычислена в режиме SIMD (необходимо из-за ii расчет индекса ). Предложение async (1) сообщает компилятору выполнить цикл в его собственном независимом потоке CUDA (предложение ! $ Acc wait позже используется для синхронизации потоков).Компилятор выбирает топологию сопоставления распараллеливания для каждого цикла, решая, как распределять работу по устройству. Для приведенного выше кода компилятор PGI (v18.4) выводит:

23645, Генерация неявного присутствия (a_r (2: nrm-1,2: ntm1,2: npm1,1: 15))
Генерация настоящего (ps)
Генерация неявного присутствия (q (:))
23647, Цикл можно распараллеливать
23649, Цикл распараллеливается
23651, Цикл распараллеливается
Сгенерировано ядро ​​ускорителя
Генерируется код Tesla
23647,! $ Acc loop gang! blockidx% y
23649,! $ acc loop gang, vector (4)! blockidx% z threadidx% y
23651,! $ acc loop gang, vector (32)! blockidx% x threadidx% x

Альтернативой использованию директивы kernels является использование директивы parallel , которая неявно подразумевает независимое предложение .Использование parallel может быть полезно, если несколько отдельных циклов в строке независимы, поскольку он генерирует одно ядро ​​графического процессора, тогда как директива ! $ Acc kernels обычно генерирует отдельное ядро ​​для каждого цикла, вызывая дополнительные накладные расходы на запуск ядра. Мы решили использовать ядер здесь, потому что мы обнаружим, что компилятор генерирует более эффективный код для этого цикла по сравнению с использованием параллельного .

Что делать, если ничего не делать? Работа с FORTRAN Array-Syntax

FORTRAN поддерживает «синтаксис массива», при котором массивы управляются поэлементно без необходимости явно написанного цикла, например, f (:) = a (:) * x (:) + b (:) * y (:) .Вы не можете применять директивы OpenACC, как указано выше, к этим «циклам», поскольку нет циклов «do» для размещения предложений «цикла». Чтобы избежать явного написания цикла (что может повлечь за собой множество изменений кода), вы можете просто поместить ядра ! $ Acc вокруг кода синтаксиса массива, и компилятор попытается сгенерировать параллельные ядра:

! $ Acc ядра по умолчанию (присутствует)
  f (:) = a (:) * x (:) + b (:) * y (:)
! $ acc end ядра
 

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

Мы использовали директиву kernels по возможности, чтобы избежать перезаписи кода для MAS, но нам нужно было преобразовать несколько сегментов кода синтаксиса массива в явные циклы.

Управление данными: унифицированная / управляемая память по сравнению с областями неструктурированных данных

Избегание передачи данных между CPU и GPU - часто цитируемая мантра программирования GPU. Они генерируют высокие

Bug Watch!
Убедитесь, что вызов ! Acc exit data delete (a) поступает до освобождения версии ЦП массива!

задержки из-за низкой скорости передачи. Области неструктурированных данных представляют собой один из способов передачи данных в графический процессор и обеспечения их доступности столько, сколько нужно пользователю.Например, вы можете использовать ! $ Acc enter data copyin (a) , который копирует элемент данных a на устройство, или ! $ Acc enter data create (a) , который выделяет пространство для и на устройстве. устройство без инициализации. За ними следуют соответствующие предложения ! $ Acc exit data delete (a) , когда элемент данных больше не нужен. Этот метод передачи данных может выполняться в любом месте кода, включая глобальные массивы в модулях, избегая многократного копирования данных назад и вперед.

Мы копируем все массивы основных полей в MAS после вычисления их начальных условий на CPU. Эти поля остаются на устройстве в течение всей симуляции, обновляя их только на хосте (с помощью директивы ! $ Acc update self () ), когда это необходимо для вывода в файл. Мы выделяем / освобождаем временные массивы, используемые в подпрограммах, с помощью предложений данных create и delete .

Привлекательной альтернативой ручному управлению передачей данных GPU-CPU является использование CUDA Unified Memory с помощью опции PGI «управляемая память».Эта опция приводит к тому, что все ваши выделения массива выполняются как объединенные выделения памяти CUDA, позволяя автоматическое разбиение на страницы при использовании массивов на GPU. Это не только устраняет необходимость беспокоиться о передаче данных, но и для современных графических процессоров, а также позволяет использовать больше данных, чем объем памяти графического процессора (хотя и с падением производительности).

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

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

Производные типы: «Истинное» или «Ручное» глубокое копирование

Производные типы создают трудности при передаче данных в и из графического процессора, поскольку объект типа необходимо передать графическому процессору в дополнение к любым массивам, которые он может содержать.Тип также может содержать другие типы, которые содержат типы и т. Д. На нескольких уровнях с массивами на каждом этапе. Копирование всей структуры типа со всем ее содержимым называется «глубокой копией». API OpenACC в настоящее время не поддерживает такое «истинное» глубокое копирование, но поддерживает «ручное» глубокое копирование. Например, предположим, что у вас есть тип, определенный как:

 тип :: t1
  реальный, размер (:), размещаемый :: x
  тип (t2) :: y
тип конца
 

, где тип t2 определяется как:

 тип :: t2
  реальный, размер (:), размещаемый :: z
тип конца
 

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

Чтобы скопировать (уже выделенный) экземпляр этого типа (например, type (t1) :: a ) в графический процессор, вы должны использовать ! $ Acc enter data copy (a, a% x, a% y, а% у% г) . Размещение всех подтипов и их содержимого в одной директиве данных позволяет избежать использования предложения attach (дополнительную информацию см. В спецификации OpenACC 2.6).

PGI реализовал настраиваемую автоматическую опцию компилятора «истинного» глубокого копирования, которая позволяет передавать целые типы сразу (например,грамм. для примера выше ! $ acc введите копию данных (a) ). Это может быть спасением, если ваш код имеет огромные и / или очень глубокие структуры типов, избавляя вас от написания длинных директив данных.

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

Подождите ... Эта процедура также вызывается ЦП ...

Определенные подпрограммы в вашем коде, которые вызываются в тяжелых вычислительных областях, также могут использоваться в тех областях кода, которые вы не хотите (и не должны) ускорять с помощью OpenACC. Это особенно верно для очень больших кодов. Например, в MAS несколько процедур, используемых во время установки начального условия, также используются в основных решающих программах. Этап установки занимает очень мало времени ЦП и содержит огромное количество дополнительных процедур, которые потребуют довольно много времени для применения OpenACC.

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

Мы хотели избежать добавления новых параметров в код MAS или необходимости добавлять условные предложения в каждый цикл OpenACC (беспорядок!). Итак, пока мы просто сделали дубликаты тех немногих подпрограмм, которые требуются для установки; одна версия с OpenACC, а другая без.(Оба работают на ЦП, когда код компилируется без ускорения графического процессора). После того, как весь код будет перенесен, количество этих дублированных подпрограмм должно в конечном итоге быть минимальным. Дальнейшая разработка OpenACC API может также привести к новым решениям этой небольшой проблемы.

Редукции массива

Операторы сокращения повсеместно используются во многих кодах; от вычисления скалярных произведений до вычисления средних значений. Для скалярной переменной OpenACC включает предложение сокращения, как показано здесь:

 вещественных (8) :: сумма = 0
! $ acc ядерное сокращение цикла (+: sum) присутствует (a)
сделать j = 1, м
  сумма = сумма + a (j)
Enddo
 

Однако часто возникает необходимость в коллективной операции над массивом, например:

 выделить (сумма (n))
сумма (:) = 0
сделать j = 1, м
  сумма (:) = сумма (:) + a (:, j)
Enddo
 

К сожалению, OpenACC в настоящее время не имеет возможности напрямую выразить компилятору такое сокращение.В таблице 1 показаны два примера реализации указанного выше сокращения:

! $ Acc ядра
! $ acc цикл
  сделать j = 1, м
! $ acc цикл
    делать я = 1, п
! $ acc атомарное обновление
      сумма (я) = сумма (я) + а (я, j)
    Enddo
  Enddo
! $ acc end ядра
 

! $ Acc
делать я = 1, п
  сумма (я) = СУММ (а (я, 1: м))
Enddo
 

Grain of Salt Заявление об отказе от ответственности
Результат, что пример (1) быстрее, чем (2), сильно зависит от проблемы и оборудования.Может существовать больше способов сделать это, которые могут работать лучше. Найдите их и дайте нам знать!

Пример кода (1) сохраняет циклы в порядке «шаг-1». Во внутреннем цикле вы можете подумать, что можете использовать что-то вроде ! $ Acc loop reduce (sum (i)) , но этот синтаксис не распознается OpenACC. Это связано с тем, что поскольку цикл «j» распараллелен, два потока с разными «j» могут попытаться обновить сумму с одним и тем же «i». Для предотвращения этого требуется директива atomic .Атомарные операции могут быть довольно медленными на старых моделях графических процессоров, но мы обнаружили хорошую производительность, используя их с архитектурами Pascal и Volta. Пример кода (2) инвертирует циклы и распараллеливает только внешний цикл. Хотя это позволяет избежать использования атомики и является более компактной формой кода, он страдает от неупорядоченного доступа к памяти и распараллеливания только по одному (возможно короткому) измерению. Итак, какой из них использовать? Чтобы выяснить это, мы профилировали код с помощью pgprof и обнаружили, что пример (1) был быстрее, чем (2), как на CPU, так и на GPU.Хотя сейчас мы используем пример (1), из-за того, что в то время мы не решались использовать атомику, в результатах этого блога использовался пример (2).

Для графических процессоров не следует выполнять одни вычисления: несколько устройств

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

Чтобы использовать несколько графических процессоров, предположим, что рассматриваемый код уже распараллеливается между процессорами с использованием MPI, как в MAS (если ваш код использует OpenMP, см. [7]).Затем нам нужен способ сообщить OpenACC API, с каким графическим процессором мы хотим вычислить определенный ранг MPI. Это можно сделать с помощью директивы ! $ Acc set device_num () . Он сообщает компилятору, что любой код OpenACC после нажатия этой директивы должен выполняться на указанном устройстве. Итак, если вы хотите, чтобы каждый ранг MPI управлял 1 графическим процессором (типичное расположение), вы можете сделать что-то вроде:

 вызов MPI_Comm_rank (MPI_COMM_WORLD, iprocw, ierr)
  ngpus_per_node = 4
  igpu = МОДУЛО (iprocw, ngpus_per_node)
! $ acc set device_num (igpu)
 

Легко, правда? Проблема! Приведенный выше код предполагает линейную близость рангов по всем ядрам и узлам кластера.Хотя иногда так и бывает, это ни в коем случае нельзя. Вы, , могли бы убедиться, что настроили машинный файл и / или расширенные аргументы команды mpiexec для вашей конкретной системы, но есть более переносимый способ. MPI-3 имеет возможность создавать коммуникатор на уровне узла с его собственными локальными рангами. Эти «общие» коммуникаторы довольно легко настроить и могут использоваться для наших целей, как показано здесь:

 вызов MPI_Comm_split_type (MPI_COMM_WORLD, MPI_COMM_TYPE_SHARED, 0,
& MPI_INFO_NULL, comm_shared, ierr)
вызовите MPI_Comm_size (comm_shared, nprocsh, ierr)
вызов MPI_Comm_rank (comm_shared, iprocsh, ierr)
  igpu = МОДУЛО (iprocsh, nprocsh)
! $ acc set device_num (igpu)
 

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

Усилители производительности

На данный момент у вас (надеюсь) есть рабочая версия OpenACC вашего кода - по крайней мере, в сложных вычислительных частях. Теперь давайте оптимизируем производительность!

Распознает ли ваша библиотека MPI графические процессоры?

Ранее мы показали, что использование директив неструктурированных данных и / или управляемой памяти позволяет нам хранить данные на GPU в максимально возможной степени. Однако при использовании нескольких графических процессоров с MPI данные передаются в ЦП, используются в вызовах MPI, а затем полученные данные передаются обратно.К счастью, этих передач можно избежать, используя так называемый MPI с поддержкой CUDA. Эта функция реализована почти во всех основных библиотеках MPI. Короче говоря, MPI с поддержкой CUDA позволяет напрямую использовать массивы устройств в вызовах MPI, теоретически устраняя необходимость в передаче данных между GPU и CPU. В идеале ваша библиотека MPI с поддержкой CUDA будет полностью обходить ЦП за счет использования прямых передач RDMA от графического процессора к графическому процессору на доступном оборудовании. Тем не менее, это полностью зависит от библиотеки MPI относительно того, как она реализует это, и в некоторых случаях может даже по умолчанию использовать передачу GPU-CPU для лучшей производительности на основе MPI.Поэтому очень важно тщательно выбирать и настраивать библиотеку MPI, оборудование и системные драйверы для обеспечения наилучшей производительности нескольких графических процессоров на основе MPI.

Обход ошибки
В текущей версии PGI (v18.4) есть ошибка, при которой, если вы передаете производный тип в подпрограмму и пытаетесь использовать его члены в вызовах MPI с поддержкой CUDA, код не работает. Чтобы обойти это, измените подпись подпрограммы так, чтобы члены типа вводились напрямую (в виде простых массивов).

Чтобы указать компилятору использовать массивы устройств в вызове MPI, мы используем директиву ! $ Acc host_data use_device .Чтобы проиллюстрировать это, ниже мы показываем пример обновления границы трафарета из MAS:

 c ****** Загрузить буферы.
! $ acc введите данные создать (sbuf11, sbuf12, rbuf11, rbuf12)
! $ acc ядра по умолчанию (присутствует)
  sbuf11 (:,:) = x (n1-1,:, :)
  sbuf12 (:,:) = х (2,:, :)
! $ acc end ядра
c ****** Начать переводы.
! $ acc host_data use_device (sbuf11, sbuf12, rbuf11, rbuf12)
  вызов MPI_Irecv (rbuf11, lbuf1, ntype_real, iproc_rm, tag, comm_all, req (1), ierr)
  вызов MPI_Irecv (rbuf12, lbuf1, ntype_real, iproc_rp, tag, comm_all, req (2), ierr)
  вызов MPI_Isend (sbuf11, lbuf1, ntype_real, iproc_rp, tag, comm_all, req (3), ierr)
  вызов MPI_Isend (sbuf12, lbuf1, ntype_real, iproc_rm, tag, comm_all, req (4), ierr)
c ****** Дождитесь завершения всех передач.вызов MPI_Waitall (4, req, MPI_STATUSES_IGNORE, ierr)
! $ acc end host_data
c ****** Выгрузить буферы.
! $ acc ядра по умолчанию (присутствует)
  если (iproc_rm.ne.MPI_PROC_NULL) то
    х (1,:,:) = rbuf11 (:, :)
  конец, если
  если (iproc_rp.ne.MPI_PROC_NULL) то
    x (n1,:,:) = rbuf12 (:, :)
  конец, если
! $ acc end ядра
! $ acc удалить данные выхода (sbuf11, sbuf12, rbuf11, rbuf12)
 

Темная сторона резидентности данных, или «Действительно ли мне нужно ускорить

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

Оптимизация цикла: «Вы должны забыть то, что вы узнали…»

Если вас всегда учили, что «шаг-1 лучше!», Иногда это может быть не так! Взгляните на два примера циклов на рисунке 2. Хотя эти два цикла выглядят очень похожими, они отличаются расположением в памяти матричных коэффициентов, хранящихся в a_r . На рисунке 2 (слева) массив пересекает идеальный шаг-1, гарантируя, что большой фрагмент данных находится в кеше, что ускоряет доступ к указанным данным (т.е. дружественный к кешу). Однако этот макет stride-1 не согласован с циклом i-j-k, что затрудняет векторизованные инструкции SIMD.

Рисунок 2. Две формы расчета трафарета в MAS. Левый цикл является «дружественным к кешированию», а правый цикл «дружественным к векторам».

На рисунке 2 (справа) каждый из 15 коэффициентов в a_r находится далеко друг от друга в памяти, ведя себя как 15 уникальных потоков памяти, что может быть довольно медленным для ЦП в зависимости от размера кеша. Однако каждый из этих потоков памяти теперь доступен для циклов i-j-k, что позволяет выполнять большие инструкции SIMD (т.е.е. дружелюбный к векторам).

Похоже, у нас был компромисс между производительностью GPU и CPU, что было проблематично, учитывая нашу цель иметь только одну базу кода. Чтобы решить, какой цикл использовать, мы измерили время с помощью обоих методов, используя тестовый прогон, аналогичный описанному ниже, и записали время прогонов на настенных часах. (Эти модифицированные петли составляют ~ 60% времени настенных часов). Мы также воспользовались этой возможностью, чтобы протестировать код в том виде, в котором он был, когда мы начали это предприятие, по сравнению с кодом с небольшими изменениями кода ЦП, которые нам потребовались для реализации OpenACC до сих пор.

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

Рисунок 3. Сравнение производительности при использовании циклов трафарета с дружественным кэшированием или векторным форматом.Также показаны результаты CPU из исходного кода по сравнению с модифицированным кодом OpenACC.

Любопытно отметить, что использование более широких векторных инструкций AVX-512 для векторных циклов на процессорах SkyLake не показало улучшенной относительной производительности по сравнению с меньшими инструкциями AVX на процессорах Sandy Bridge. Это может быть связано с требованием использовать дополнительные параметры компилятора (более чем -xAVX-512 ) для включения возможностей векторизации полной ширины процессоров с поддержкой AVX512, которые, если они используются, понижают тактовую частоту процессора.

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

Параллель, Ядра, Банды, Рабочие, Векторы… Боже мой!

Компилятор OpenACC выполняет сложную работу по преобразованию последовательного кода в параллельный код для работы на указанном устройстве. Каждый поставщик компилятора реализует некоторый тип параллелизма по умолчанию при обнаружении ядер или параллельной области . Для точной настройки производительности OpenACC содержит директивы, которые вы можете использовать, чтобы давать подсказки / указания компилятору для распараллеливания ваших циклов по вашему желанию.К ним относятся пункты топологии gang , worker и vector , а также более сложные пункты, такие как cache и tile .

Навигация по этим параметрам и выбор их переменных параметров (например, длины вектора) может быть сложной задачей из-за множества возможных комбинаций. Знание об устройстве, на которое вы нацеливаете, может подсказать вам подмножество разумных вариантов, но даже это подмножество может быть очень большим. Итак, что нужно делать? Для MAS мы взяли тот же код цикла, который использовался выше (что составляет 60% времени настенных часов), и протестировали его с многочисленными вариантами топологии, включая значение по умолчанию для параллельных ядер и ядер .На рисунке 4 показаны временные результаты процедуры (самой по себе) для каждого выбора, который мы пробовали.

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

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

Режущая кромка может быть довольно острой

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

Я думал, что компилятор это поддерживает!

Иногда не все подробности о новых функциях документируются или желание их опробовать перевешивает осторожность, что приводит к длительным ошибкам при реализации. Некоторыми примерами, с которыми мы столкнулись, был правильный порядок производных типов и их членов в предложении данных, требующий использования use_device (a% r) вместо use_device (a) для массивов производных типов в директивах host_data , и в основном все пункты «отслеживания ошибок», упомянутые выше.Кроме того, иногда определенные комбинации новых функций просто еще не реализованы (например, в текущей версии PGI (v18.4) сообщества, вы не можете использовать предложение cache для массивов внутри производных типов).

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

При разработке OpenACC для POT3D и MAS мы столкнулись с определенной долей ошибок компилятора в PGI, все из которых в настоящее время имеют обходные пути или исправлены. Включено несколько примеров:

• Сбой при использовании многоуровневых производных типов (исправлено в v17.10)
• Требование явного присутствия (a) вместе с по умолчанию (присутствует) при использовании производных типов (еще не исправлено)
• Сбой при использовании членов производного типа в директиве host_data use_device вокруг CUDA-совместимого MPI (запущено в v17.10 и еще не исправлено)

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

Я думал, что система HPC поддерживает это!

Ошибки устранены. Код, работающий на вашем локальном сервере. Теперь готов к запуску в кластере с графическим процессором. Вы входите в систему, переносите свой код и тестовый запуск, компилируете, настраиваете очередь и все готово к работе.Запускается пробег, и… seg fault!

В зависимости от приоритета вычислений на графическом процессоре в конкретном кластере, который вы используете, система HPC может быть «отстающей» с точки зрения программного обеспечения. Например, библиотека MPI может быть слишком старой для поддержки CUDA-Aware MPI или компилятор слишком стар для поддержки нужной вам версии OpenACC. Даже если программные стеки обновлены, могут возникнуть ошибки при настройке оборудования и межбиблиотечном взаимодействии, особенно если вы работаете так, как не слишком часто (или когда-либо).В некоторых случаях проблемы с лицензированием могут помешать центру установить необходимый компилятор или драйвер.

При тестировании портов POT3D и MAS в кластерах мы столкнулись с этими проблемами на нескольких машинах. В одном случае в библиотеке MPI была ошибка, из-за которой MPI с поддержкой CUDA вообще не работал. В другом случае единственным доступным компилятором PGI была версия до того, как было реализовано необходимое исправление ошибки, и срок его лицензии истек! В другом кластере из-за проблемы с настройкой все запуски с несколькими графическими процессорами просто прекращались.Многие из этих проблем были на машинах, функции GPU которых были второстепенными, и никто ранее не пробовал код OpenACC с несколькими GPU. К счастью, сотрудники помогли нам найти способы заставить все работать. В системах HPC, разработанных специально для вычислений на GPU, такого рода проблемы должны возникать гораздо реже. Контейнеры также могут решить эти проблемы [8].

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

Итак, после всего этого… Как это было причастно?

Так же, как коммерческие полеты - это самый быстрый и безопасный способ путешествовать, но в каждом кармане сиденья есть небольшой мешочек, поэтому OpenACC - один из самых быстрых, эффективных и безопасных для переносимости способов ускорить ваш код, но не Не ожидал, что это будет прогулка по парку. В нашем случае фактическое кодирование OpenACC для первоначального переноса MAS (в наш целевой режим функций подмножества) было на самом деле довольно простым и требовало очень небольших изменений кода ЦП (многие из которых увеличивали производительность ЦП!).Выделялась одна трудоемкая задача - ускорить множество небольших подпрограмм для хранения данных на графических процессорах. Мы суммируем необходимые модификации кода с точки зрения директив OpenACC и изменений кода ЦП в таблице 2:

Мы видим, что нам нужно было только добавить директиву OpenACC в размере примерно 1% от общего количества строк кода и модифицировать под 2% кода ЦП (некоторые из которых были необязательной оптимизацией).В итоге мы добавили в общей сложности 5% строк кода, многие из которых можно удалить после исправления некоторых ошибок компилятора и добавления новых функций API в OpenACC. Однако помните, что эта реализация охватывает только набор функций Zero-Beta в MAS. Как только наша полная реализация будет завершена, количество модификаций будет выше.

Хотя кодирование OpenACC проходило довольно гладко, самая сложная и трудоемкая часть нашей разработки оказалась работа над ошибками компилятора и библиотеки, а также решение проблем в системах HPC, о которых говорилось выше.Однако мы ожидаем, что по мере того, как компиляторы, системы HPC, библиотеки MPI и API OpenACC будут продолжать расти и совершенствоваться, эти трудности резко уменьшатся.

Хорошо, хорошо… но сработало ли это? Давайте посмотрим на цифры!

Что такое «справедливое» время?

Не существует действительно «честного» способа сравнить производительность GPU и CPU для данного кода, поскольку оптимальная реализация алгоритмов часто уникальна для каждого оборудования (либо явно в коде, либо неявно через компилятор).Кроме того, некоторые алгоритмы могут работать лучше на одном оборудовании, чем на другом, в то время как другие будут работать наоборот (например, наш предварительный кондиционер PC2 больше подходит для CPU, а PC1 лучше всего на GPU).

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

К сожалению, часто можно увидеть результаты производительности только для тех областей кода, которые были ускорены, но не за все время. Поскольку мы заботимся о времени принятия решения, такие результаты могут вводить в заблуждение (и искусственно обходить закон Амдала). Здесь мы записываем абсолютное время настенных часов наших запусков, включая всю настройку кода ЦП, ввод-вывод, передачу ЦП-ГП и т. Д.Хотя мы делаем , а не , включаем время ожидания в очереди в системах HPC, время ожидания выполнения вашего задания не следует игнорировать, так как оно может стать довольно большим для больших запусков и / или когда кластер HPC занят.

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

Тестовая задача

Используемый нами прогон представляет собой МГД-моделирование нулевого бета-излучения извержения CME (см. Ссылку [9] для аналогичных расчетов). Он использует неравномерную сферическую сетку с 33 миллионами точек. Среднее количество итераций решателя на временной шаг за прогон составляет ~ 500 для ПК1 и ~ 100-> 200 для ПК2 (ПК2 ухудшается в сокращении итераций по мере увеличения числа рангов MPI).Все вычисления выполняются с использованием двойной точности (FP64). Параметры прогона генерируются нашим интерактивным инструментом, используемым для изучения извержений CME. Этот инструмент имеет эвристическую оценку (баланс производительности и использования ресурсов) того, сколько ядер ЦП необходимо использовать для достижения «приемлемого» времени принятия решения. Мы используем это «приемлемое» время до решения в качестве основы для оценки производительности. Предполагается, что запуск, используемый здесь, составит 90 минут с использованием 16 двухпроцессорных узлов Haswell, что соответствует 384 ядрам ЦП.На рисунке 5 показаны визуализации пробега.

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

Подробная информация об окружающей среде

Таблица 3 показывает некоторые детали аппаратной и программной среды, используемой для выполнения тестов производительности. Запуск ЦП выполнялся с использованием суперкомпьютеров NASA NAS Pleiades и Electra , а запуск графического процессора выполнялся на тестовом кластере NVIDIA PSG.Все коды были скомпилированы с «-O3» и наивысшим набором команд / вычислительными возможностями, совместимыми с соответствующим оборудованием.

Результаты деятельности

Результаты синхронизации с использованием нескольких узлов ЦП и моделей графических процессоров показаны на рисунке 6.

Рисунок 6. Время настенных часов для выполнения тестовой задачи на нескольких двухпроцессорных узлах ЦП (слева) и нескольких графических процессорах (справа). Показана эвристика «приемлемого времени решения».

Основной вывод из этих результатов заключается в том, что мы достигли «приемлемого» времени до решения, используя несколько графических процессоров, которые могут уместиться в одном внутреннем сервере. Нам потребовалось ~ 16 24-ядерных узлов Haswell или ~ 8 40-ядерных узлов Skylake для достижения того же времени выполнения с использованием ЦП. Таким образом, мы можем перейти от необходимости кластера высокопроизводительных вычислений к работе с собственными силами для решения подобных проблем.Мы также видим, что алгоритм PC1 лучше масштабируется на процессорах, чем PC2, но PC2 в целом по-прежнему намного быстрее.

На графических процессорах мы видим хорошее масштабирование до 4 графических процессоров, но после этого масштабирование ухудшается. Вероятно, это связано с тем, что система, на которой мы тестировали, имеет 4 графических процессора на узел и не имеет возможности GPUDirect / RDMA. Мы ожидаем, что масштабирование будет лучше при использовании до 16 графических процессоров на одном сервере с несколькими графическими процессорами (до 5 на настольной рабочей станции), особенно тех, которые оснащены NVLink, например DGX-Station , DGX-1 , и DGX-2 .Другая возможная причина снижения масштабирования может заключаться в том, что текущая проблема слишком мала для эффективного использования более чем нескольких графических процессоров.

Чтобы проиллюстрировать преимущество в производительности графического процессора в домашних условиях, на рисунке 7 показаны результаты синхронизации (в часах) с использованием одного двухпроцессорного сервера ЦП по сравнению с использованием до 8 графических процессоров. Серверы отделов, как правило, имеют двухпроцессорную конфигурацию или, в лучшем случае, четырехсокетную конфигурацию.

Рис. 7. Все это можно сделать собственными силами. Серверы с графическим процессором обеспечивают гораздо лучшую производительность, чем типичные серверы ЦП отдела.

Несмотря на то, что мы сосредоточились на использовании ускорения графического процессора для выполнения небольших и средних симуляций внутри компании, мы легко можем рассчитывать на то, что сможем в полной мере воспользоваться преимуществами крупных кластеров HPC на базе графического процессора, таких как недавно развернутый суперкомпьютер Summit в ORNL. который использует 6 графических процессоров NVIDIA Volta на каждый узел, подключенный к NVLink и RDMA между узлами. Использование таких систем позволило бы нам проводить большие симуляции с использованием меньшего количества ресурсов распределения, а также добиться более быстрого «времени принятия решений», требуя работы на меньшем количестве узлов, избегая длинных очередей ожидания.

Что дальше?

Наши следующие шаги в реализации OpenACC MAS, в первую очередь, заключаются в реализации оставшихся физических модулей и наборов функций, что позволяет нам использовать ускорение GPU для современного моделирования CME. Мы также рассмотрим возможность использования новых векторизуемых предобуславливателей для решений PCG и / или альтернативных алгоритмов для повышения производительности графического процессора. Например, предварительное тестирование с использованием метода RKL2 Super Time-Stepping [10] дало очень многообещающих результатов .

Я убежден! Где я могу начать?

Если вы заинтересованы в использовании OpenACC для своего кода, вы можете найти множество отличных руководств и информации на сайте ресурсов OpenACC, которые включают презентации, книги, учебные пособия, записанные курсы, образцы кодов, а также предстоящие семинары и хакатоны. GTC on-demand - отличное место для начала работы с множеством выступлений и практических руководств. Хакатоны - это фантастический ресурс, где вы и ваша команда можете неделю поработать с экспертами OpenACC над кодом и кодом .Готовы начать? Зайдите в PGI, скачайте бесплатный компилятор от сообщества и начните тестирование! Если вас также интересует более подробная информация о нашей реализации MAS, ознакомьтесь с нашим докладом на GTC 2018.

Благодарности

Эта работа была поддержана Национальным научным фондом , программами НАСА «Жизнь со звездой» и «Гелиофизика», а также Управлением научных исследований ВВС . Вычислительные ресурсы были предоставлены Подразделением передовых суперкомпьютеров НАСА и корпорацией NVIDIA.

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

[1] http://www.predsci.com/eclipse2017

[2] https://www.nasa.gov/feature/goddard/2017/scientists-used-nasa-data-to-predict-the-corona-of-the-aug-21-total-solar-eclipse

[3] Прогнозирование короны для полного солнечного затмения 21 августа 2017 г. З. Микич, К. Даунс, Дж. А. Линкер, Р. М. Каплан, Д. Х. Маккей, Л. А. Аптон, П. Райли, Р. Лионелло, Т. Торок, В.С. Титов, Дж. Виджая, М. Дракмюллер, Дж. М. Пасачофф и В.Карлос. Отправлено в Nature Astronomy (2018)

[4] https://docs.nvidia.com/cuda/cusparse

[5] Возможные полевые решения солнечной короны: преобразование решателя PCG из MPI в MPI + OpenACC Р. Каплан, Дж. Линкер и М. Зоран. Представлено на конференции NVIDIA GPU Technology Conference 2017 http://on-demand.gputechconf.com/gtc/2017/video/s7535-ronald-caplan-potential-field-solutions-of-the-solar-corona-converting-a -pcg-solver-from-mpi-to-mpi + openacc.МР4

[6] От MPI к MPI + OpenACC: преобразование устаревшего решателя FORTRAN PCG для сферического уравнения Лапласа Р. Каплан, Дж. Линкер и М. Зоран. arXiv: 1709.01126 [cs.MS] (2017)

[7] https://www.slideshare.net/jefflarkin/early-results-of-openmp-45-portability-on-nvidia-gpus-cpus

[8] https://developer.