Практическая польза распараллеливания вычислений при расчете в пакетном режиме

До сих пор в серии блогов о гибридном моделировании мы мало говорили о том, как можно ускорить процесс решения, добавив дополнительные вычислительные ресурсы. Сегодня мы обсудим некоторые теоретические исследования, которые объясняют ограничение параллельных вычислений. Мы также покажем вам, как использовать встроенную в 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 изображена на графике ниже.

Speedup for increasing the number of processes Практическая польза распараллеливания вычислений при расчете в пакетном режиме
Зависимость ускорения от увеличения числа процессов для разного количества частей параллельного кода.

Для 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) дает нам гораздо более оптимистичный результат для так называемого ускорения масштабирования (которое является аналогом производительности), как показано на графике ниже:

Graph depicting how the size of the job increases with the number of available processes Практическая польза распараллеливания вычислений при расчете в пакетном режиме
Принимая во внимание то, что размер задачи обычно увеличивается с количеством доступных процессов, наши расчеты более оптимистичны.

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

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

Рассмотрим затраты вычислительных ресурсов, в которых наибольшую часть занимают передача данных и синхронизация, необходимые для параллельной обработки, и смоделируем это как время, добавленное к времени расчета. Это означает, что количество переданных данных увеличивается с увеличением числа процессов и что это увеличение будет функцией 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)результат еще хуже, и, как вы можете вспомнить из нашей предыдущей статьи блога по вычислениям с распределенной памятью, рост передачи данных является квадратичным в случае передачи данных между всеми процессами.

Speedup with added overhead Практическая польза распараллеливания вычислений при расчете в пакетном режиме
Ускорение с учетом затрат вычислительных ресурсов. Константа 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 для трех ядер и даже уменьшается для четырех ядер. Это связано с тем, что эта небольшая модель имеет маленькое число степеней свободы на каждый поток для каждого временного шага. Теперь мы будем использовать функциональность расчета в пакетном режиме для распараллеливания этой задачи по-другому: мы перейдем от распараллеливания данных к распараллеливанию задач. Мы создадим пакетное задание для каждого значения параметра и посмотрим, как это влияет на наши вычисления. Для этого мы сначала активируем "Advanced Study Options" (расширенные настройки исследования), затем щелкнем правой кнопкой мыши на "Study 1" (исследование 1) и выберем "Batch Sweep" (расчет в пакетном режиме), как показано на анимации ниже:

Как активировать batch sweep (расчет в пакетном режиме ) в модели, включить значения параметров и указать количество одновременных задач.

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

Batch sweep simulations per day versus configuration of processes and threads Практическая польза распараллеливания вычислений при расчете в пакетном режиме
Число моделирований в день для модели безэлектродной лампы. "4×1" означает, что четыре пакетных задания запускаются одновременно, используя по одному ядру каждое.

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

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

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

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

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


Теги

Кластеры
Загрузка комментариев...

Темы публикаций


Теги