Распараллеливание вычислений при параметрических исследованиях в пакетном режиме

20/03/2014

До сих пор в серии блогов о гибридном моделировании мы мало говорили о том, как можно ускорить процесс решения, добавив дополнительные вычислительные ресурсы. Сегодня мы обсудим некоторые теоретические исследования, которые объясняют ограничение параллельных вычислений. Мы также покажем вам, как использовать встроенный в COMSOL Multiphysics функционал Batch Sweeps (параметрический расчет в пакетном режиме), отличного инструмента распараллеливания, позволяющего повысить производительность, когда вы достигнете предела.

Законы Амдала и Густавсона-Барсиса

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

Чтобы проанализировать возможное максимальное ускорение алгоритма, предположим, что он состоит из части идеально распараллеленного кода и части последовательного кода. Давайте обозначим часть параллельного кода \varphi, где \varphi — это число между (и включая) 0 и 1. Это автоматически означает, что наш алгоритм имеет часть последовательного кода, которая эквивалента (1-\varphi).

Учитывая время расчета T(P) для P активных процессов, начиная со случая P=1, мы можем записать выражение T(1) = T(1) \cdot(\varphi + (1-\varphi)). При запуске P процессов часть последовательного кода не изменится, но идеально распараллеленный код будет вычисляться в P раз быстрее. Следовательно, время расчета для P процессов — T(P)=T(1) \cdot (\varphi / P + (1 -\varphi)) и ускорение – S(P):=T(1)/T(P)=1/(\varphi/P+(1-\varphi)).

Закон Амдала

Это выражение — главная часть закона Амдала. Зависимость S(P) для разных значений \varphi и P изображена на графике ниже.

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

Для 100% параллельного кода возможности воистину безграничны. Тем не менее, мы считаем, что для \varphi, асимптотический предел или теоретический максимум ускорения S_{max}(\varphi):=\lim_{P\to \infty} S(P)=1/(1-\varphi).

Для 95% параллельного кода, мы считаем, что S_{max}(0.95)=20 — максимальное ускорение в двадцать раз, даже если у нас есть бесконечное число процессов. Кроме того, мы имеем S_{max}(0.9)=10, S_{max}(0.75)=4 и S_{max}(0.5)=2. Теоретическое максимальное ускорение быстро уменьшается с уменьшением части параллельного кода.

Но не опускайте руки!

Закон Густафсона-Барсиса

Есть один момент, который закон Амдала не учитывает и это то, что при покупке более быстрого и большого компьютера с возможностью запуска большего количества процессов, мы обычно не хотим быстрее рассчитывать наши прошлые и простые модели. Вместо этого мы хотим рассчитывать новые и более сложные модели. Как раз об этом идет речь в законе Густафсона-Барсиса. Он основан на предположении, что размер задачи, которую мы хотим рассчитать, линейно растет с количеством доступных процессов.

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

Уравнение, описывающее это явление, — S(P)=\phi\cdot P-(1-\phi) дает нам гораздо более оптимистичный результат для так называемого ускорения масштабирования (которое является аналогом производительности), как показано на графике ниже:

График показывает, как размер задачи увеличивается с количеством доступных процессов
Принимая во внимание то, что размер задачи обычно увеличивается с количеством доступных процессов, наши расчеты более оптимистичны.

"Цена" передачи данных

Закон Густафсона-Барсиса подразумевает, что мы ограничены только размером задачи, которую мы можем вычислить с помощью ресурсов добавленных процессов. Тем не менее, есть и другие факторы, влияющие на ускорение. В этой серии блога мы пытались обратить внимание читателей на то, что "цена" передачи данных является высокой. Но еще не говорили о том, насколько она высока, поэтому давайте посмотрим на некоторые примеры.

Рассмотрим затраты вычислительных ресурсов, в которых наибольшую часть занимают передача данных и синхронизация, необходимые для параллельной обработки, и смоделируем это как время, добавленное к времени расчета. Это означает, что количество переданных данных увеличивается с увеличением числа процессов и что это увеличение будет функцией OH(P)=c\cdot f(P), где c — это константа и f(P) некоторая функция. Следовательно, мы можем вычислить ускорение как: S(P)_{OH}=1/(\varphi/P+(1-\varphi)+c \cdot f(P)).

На приведенном ниже графике показаны зависимости ускорения от роста количества процессов для разных функций f(P), предполагая c= 0.005 (эта константа может варьироваться в зависимости от различных задач и платформ), часть распараллеленного кода составляет 95%. В случае отсутствия затрат вычислительных ресурсов результат такой, как и ожидалось по закону Амдала, но, когда мы начинаем добавлять затраты вычислительных ресурсов, картина меняется.

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

Ускорение с добавленными затратами вычислительных ресурсов
Ускорение с учетом затрат вычислительных ресурсов. Константа c равна 0.005.

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

Параметрические исследования в пакетном режиме (Batch Sweeps) в COMSOL Multiphysics

Давайте теперь оставим теоретическую сторону вопроса и узнаем, как использовать функцию параметрического свипа в пакетном режиме в COMSOL Multiphysics. В качестве примера мы будем использовать модель безэлектродной лампы, которая доступна в нашей Галерее приложений. Эта модель небольшая, примерно с 80,000 степенями свободы, но для ее решения требуется порядка 130 временных шагов. Добавим к исходному расчету во временной области параметрическое исследование: рассчитаем её для нескольких значений мощностей лампы, а именно: 50 Вт, 60 Вт, 70 Вт и 80 Вт.

На моем автоматизированном рабочем месте Fujitsu® CELSIUS®, оснащенным четырехядерным процессором Intel® Xeon® E5-2643 и 16 GB ОЗУ, получены следующие расчетные времена:

Количество ядер Время расчета на параметр Время расчета для пакетной развертки
1 30 мин. 120 мин.
2 21 мин. 82 мин.
3 17 мин. 68 мин.
4 18 мин. 72 мин.

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

Теперь же давайте воспользуемся функционалом Batch Sweep для распараллеливания этой задачи по-другому: мы перейдем от распараллеливания данных к распараллеливанию задач. Мы создадим пакетное задание для каждого значения параметра и посмотрим, как это влияет на наши вычисления. Для этого мы сначала активируем "Advanced Study Options" (расширенные настройки исследования), затем щелкнем правой кнопкой мыши на "Study 1" (исследование 1) и выберем "Batch Sweep" (параметрический расчет в пакетном режиме), как показано на анимации ниже:

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

Гистограмма ниже показывает производительность или ускорение, которые мы можем получить, контролируя распараллеливание. При запуске одного пакетного задания с использованием четырех ядер мы получаем результат около: 72 минут. Изменяя конфигурацию на два пакетных задания одновременно, каждое из которых использует по два ядра, мы можем рассчитать все параметры за 48 минут. Наконец, при одновременном вычислении четырех пакетных заданий, каждое из которых использует по одному процессору, общее время вычисления составит 34 минуты. Это дает ускорение в 2.5 и 3.5 раза, соответственно, что намного лучше по сравнению с вариантом использования только совместной памяти.

Зависимость числа симуляций в пакетном режиме в день от конфигурации процессов и многопоточности.
Число расчетных циклов в день для модели безэлектродной лампы. "4×1" означает, что четыре пакетных задания запускаются одновременно, используя по одному ядру каждое.

Резюме серии блога по гибридному моделированию

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

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

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

Fujitsu является зарегистрированным товарным знаком Fujitsu Limited в США и других странах. CELSIUS является зарегистрированным товарным знаком Fujitsu Technology Solutions в США и других странах. Intel и Xeon являются товарными знаками Intel Corporation в США и (или) других странах.


Комментарии (0)

Оставить комментарий
Войти | Регистрация
Загрузка...
РУБРИКАТОР БЛОГА COMSOL
РУБРИКИ
ТЕГИ