Вопросы о HPC на SLURM

Question

У меня есть несколько вопросов о HPC. У меня есть код с последовательными и параллельными разделами. Параллельные секции работают с разными кусками памяти, и в какой-то момент они общаются друг с другом. Для этого я использовал MPI в нашем кластере. SLURM - это менеджер ресурсов. Ниже приведены спецификации узла в кластере.

Характеристики узла:

Processor: 2x Intel Xeon E5-2690 (totally 16 cores 32 thread) 
Memory : 256 GB 1600MHz ECC 
Disk : 2 x 600 GB 2.5" SAS (configured with raid 1) 

Вопросы:

1) Есть ли все ядра на долю узла та же памяти (ОЗУ)? Если да, делайте все доступ к памяти с одинаковой скоростью?

2) Рассмотрим случай:

--nodes = 1 
--ntasks-per-node = 1 
--cpus-per-task = 16 (all cores on a node) 

Если все ядра разделяют ту же память (зависит от ответа на вопрос 1) будет использоваться все ядра или 15 из них спят, так как OpenMP (для общей памяти) является не используется?

3) Если требуемая память меньше общей памяти узла, не лучше ли использовать один узел, используйте OpenMP для достижения параллелизма на уровне ядра и избегайте потери времени из-за связи между узлами? То есть, использовать этот

--nodes = 1 
--ntasks-per-core = 1 

вместо этого:

--nodes = 16 
--ntasks-per-node = 1 

Остальные вопросы, связанные с заявлениями в this ссылке.

Использовать выделение ядра, если ваше приложение связано с ЦП; чем больше процессоров вы можете бросить на него, тем лучше!

Означает ли это утверждение, что --ntasks-per-core хорош, когда ядра не имеют доступа к ОЗУ слишком часто?

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

Я просто этого не понимаю. Я знаю, что все сокеты и ядра на сокетах имеют одну и ту же память. Вот почему я не понимаю, почему есть опция --ntasks-per-socket?

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

Означает ли это, что если требуемая память больше, чем общая ОЗУ одного узла, то лучше использовать несколько узлов?

Answer 1

В порядке:

1. Да, все ядра разделяют ту же память.Но обычно не с той же скоростью. Обычно каждый процессор (в вашей конфигурации имеет 2 процессора или сокеты) имеет память, которая «ближе» к нему. Обычно ядро ​​Linux будет пытаться выделить память в ближайшей памяти. Это не то, о чем обычно беспокоит пользовательское приложение.
2. Если это серийное задание, то да, 15 ядер будут сидеть без дела. Если ваша работа использует MPI, то она может использовать другие ядра на одном узле. Фактически, MPI на том же узле обычно намного быстрее MPI, растянутого на нескольких узлах.
3. Вы можете использовать OpenMP или MPI на одном узле. Я не уверен в скорости разницы, но если вы уже знакомы с MPI, я бы просто придерживался этого. Разница, вероятно, не такая большая. Но разница между запуском MPI на одном узле и множеством узлов будет большой. Запуск MPI на одном узле будет значительно быстрее, чем на нескольких узлах.

Использование основного распределения, если ваше приложение связано с ЦП; чем больше процессоров вы можете бросить на него, тем лучше!

Это, скорее всего, предназначено для параллельных заданий OpenMP или одиночных узлов.

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

См. Ответ на вопрос 1. Хотя это то же самое, ядра обычно имеют отдельную шину в память.

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

Если вам нужно больше ОЗУ, чем может предоставить один узел, тогда у вас нет выбора, кроме как разделить вашу программу и использовать MPI.