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

Question

Я распараллелил механизм моделирования в 12 потоках, чтобы запустить его на кластере из 12 узлов (каждый узел запускает один поток). Поскольку вероятность доступности 12 систем, как правило, меньше, я также настроил ее для 6 потоков (для работы на 6 узлах), 4 потоков (для работы на 4 узлах), 3 потоков (для работы на 3 узлах) и 2 потоков ( работать на 2-х узлах). Я заметил, что чем больше количество узлов / потоков, тем больше ускорение. Но очевидно, что чем больше узлов я использую, тем дороже (с точки зрения затрат и мощности) выполнение.

Я хочу опубликовать эти результаты в журнале, поэтому я хочу знать, существуют ли какие-либо законы / теоремы, которые помогут мне определить оптимальное количество узлов, на которых я должен запустить эту программу?

Спасибо
Akshey

Answer 1

Как вы распараллелили свою программу и что находится внутри каждого из ваших узлов?

Например, в одном из моих кластеров у меня есть несколько сотен узлов, каждый из которых содержит 4 двухъядерных Xeon. Если бы я запускал программу OpenMP в этом кластере, я бы поместил одно выполнение на один узел и запустил не более 8 потоков, по одному на каждое ядро ​​процессора. Мои кластеры управляются Grid Engine и используются для пакетных заданий, поэтому нет конфликтов во время выполнения задания. В общем случае нет смысла запрашивать более одного узла для выполнения задания OpenMP, поскольку подход с разделяемой памятью не работает на оборудовании с распределенной памятью. И мало что можно получить, запросив менее 8 потоков на 8-ядерном узле, у меня достаточно оборудования, чтобы не делиться им.

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

Как @Blank уже указал, что наиболее эффективный способ запуска программы, если под эффективностью подразумевается «минимизация общего числа процессорных часов», - это запуск программы на 1 ядре. Только. Однако для моей работы, которая может занять, скажем, неделю на 256 ядрах, ждать 128 недель, пока одно ядро ​​завершит свою работу, не очень приятно.

Если вы еще не знакомы со следующими условиями, поищите их в Google или перейдите в Википедию:

• Закон Амдала
• Закон Густафсона
• слабое масштабирование
• сильное масштабирование
• параллельное ускорение
• параллельная эффективность
• Масштабируемость.

Answer 2

"есть ли какие-нибудь законы / теоремы, которые помогут мне определить оптимальное количество узлов, на которых я должен запустить эту программу?"

Нет таких общих законов, потому что каждая проблема имеет немного отличающиеся характеристики.

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

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

• Время до завершения как функция числа процессоров: T (P)
• Ускорение как функция числа процессоров: S (P) = T (1) / T (P)
• Параллельная эффективность: E (P) = S (P) / P

Как вы выбираете «правильное» количество узлов? Это зависит от того, сколько заданий вам нужно выполнить, и какое допустимое использование вычислительных ресурсов.

Так, например, при составлении графика ваших результатов синхронизации вы можете обнаружить, что у вас есть минимальное время до завершения T (P) на некотором количестве процессоров - скажем, 32. Так что это может показаться «лучшим» выбором. Но когда вы посмотрите на показатели эффективности, может стать ясно, что эффективность начала резко падать задолго до этого; и вы получили (скажем) только 20-процентное сокращение времени выполнения по сравнению с работой на 16 процессорах - то есть, если вдвое увеличить объем вычислительных ресурсов, вы получили только 1,25-кратное увеличение скорости. Обычно это плохая сделка, и вы предпочитаете работать с меньшим количеством процессоров, особенно если у вас много таких симуляций. (Например, если у вас есть 2 симуляции для запуска, в этом случае вы можете выполнить их за 1,25 единицы времени вместо 2 единиц времени, запустив две симуляции на 16 процессорах одновременно, вместо того, чтобы запускать их по одной на 32 процессорах ).

С другой стороны, иногда у вас есть только пара пробежек, и время действительно имеет значение, даже если вы используете ресурсы неэффективно. Финансовое моделирование может быть таким - им нужны прогнозы для завтрашних рынков , сейчас , и у них есть деньги, чтобы использовать вычислительные ресурсы, даже если они не используются на 100% эффективно.

Некоторые из этих концепций обсуждаются в разделе «Введение в параллельное выполнение» любого учебного пособия по параллельному программированию; вот наш пример, https://support.scinet.utoronto.ca/wiki/index.php/Introduction_To_Performance

Answer 3

Увеличение количества узлов приводит к уменьшению отдачи. Два узла не в два раза быстрее одного узла; четыре узла даже меньше, чем два. Таким образом, оптимальное количество узлов всегда равно одному; именно с одним узлом большую часть работы выполняется для каждого узла.