MPI: ядра или процессоры?

Ответ 1

mpirun выполнит несколько "процессов" на машине. Процессор или ядро, в котором выполняются эти процессы, зависят от операционной системы. На N процессорах с M ядрами на каждом процессоре у вас есть место для процессов N * M, работающих на полной скорости.

Но обычно:

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

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

Ответ 2

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

Что касается аппаратного обеспечения, ядро ​​может запускать только один процесс за раз. Такие технологии, как гиперпоточность, позволяют нескольким процессам совместно использовать ресурсы одного ядра. Бывают случаи, когда два или более процессов на ядро ​​являются оптимальными. Например, если процессы выполняют большой объем ввода-вывода файлов, другой может занять свое место и выполнять вычисления, в то время как первый зависает при чтении или записи.

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

Ответ 3

Планировщик ОС попытается оптимально распределить отдельные ядра для ваших параллельных процессов приложений в многоядерной системе ИЛИ для разделения процессоров в многопроцессорной системе.

Интересным случаем является многоядерная многоядерная система. Снова вы можете позволить планировщику ОС сделать это за вас, или вы можете обеспечить соответствие (логическое/физическое) ядро ​​с вашими процессами привязать их к определенному ядру.

Ответ 4

Команда mpirun использует список хостов. Если он не указан, он, вероятно, будет использовать "localhost" и запускать там все ваши процессы. Если вы запускаете 3 процесса и у вас есть 4-ядерный компьютер, вы, вероятно, получите хорошее ускорение, потому что ОС обычно размещает их на разных ядрах. Если у вас только два ядра, то одно ядро получит два процесса.

Предыдущее не совсем верно, поскольку ОС разрешено перемещать процессы, поэтому вы можете использовать numactl для привязки их к ядру.

Если вы работаете в многоузловом кластере, то хорошо настроенный mpi сгенерирует файл хоста, где каждый узел появляется столько раз, сколько у него ядер. Таким образом, в кластере из 4 узлов с 8 ядрами на узел вы можете запросить до 32 процессов и ожидать почти идеального ускорения. (Если, конечно, ваш код и ваш алгоритм это позволяют.) При запросе 9 процессов в этом кластере можно разместить 8 на одном узле, а 9 - на другом, что, конечно, не очень хорошо для производительности. Вы бы надеялись, что ваше кластерное программное обеспечение поставляется с mpirun, который лучше распределяет процессы.

Ответ 5

из представления производительности работы MPI, есть некоторые явные правила: 1) если вы кодируете чистый код MPI (BLAS не настроен с помощью openMP), отключите гиперпоточность и задайте номер задания задания на node для ядер node 2) если вы код MPI + openMP, вы можете установить PPN (процессы на node) на ядра node и OMP_NUM_THEADS на 2 (если есть два аппаратных потока на ядро) 3) если вы используете код MPI + openMP, и ваш кластер огромен, тогда вы можете настроить PPN (процессы на node) на 1 и OMP_NUM_THEADS на логические номера ЦП, чтобы сохранить служебные данные связи

Ответ 6

Чтобы обеспечить полезную структуру, я хотел бы рассмотреть эту иерархию:

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

В первые дни у вас чаще всего была одна материнская плата с одним чипом и одним процессором с одним потоком. За один раз можно было обрабатывать только один процесс, а набор обслуживающего оборудования назывался процессором. Было однозначное сопоставление между частями программного обеспечения (задача для выполнения) и частями оборудования (устройство для выполнения задачи).

Процесс определенно является программным понятием. "Поток" - это, проще говоря, спецификация "процесса" в контексте параллельных параллельных вычислений. В настоящее время процессор может ссылаться как на физическое устройство, так и на его расширенные возможности обработки (опять-таки многопоточность, что, безусловно, является технологической реализацией). Например, вы можете иметь машины с двумя чипами на материнской плате, с четырьмя ядрами/процессорами на чип и с каждым ядром/процессорами, работающими одновременно по два потока. Тогда вы сможете запускать процессы 2x4x2 = 16 (конечно, без переподписки ресурсов).

Синтаксис MPI, который вы цитируете, обращается к процессам (опция np) или потокам, если хотите. Часть описания man mpirun даже называет процессы "слотами" (например, см. Спецификации для файла хоста). Это звучит как наследие той тесной связи между единицами аппаратного обеспечения и единицами программного обеспечения, которая была тогда стандартной. "Слот" изначально представляет собой материальную/аппаратную функцию, мало чем отличающуюся от термина "сокет", который подвергся аналогичному изменению семантики.

Так что, на самом деле, я чувствую некоторое сочувствие к вашей путанице Если вы пользователь Linux, вы можете визуализировать отчет cat/proc/cpuinfo. Эти строки относятся к одному процессору с именем '2' из четырех:

processor   : 2
...
physical id : 0
siblings    : 4
core id     : 2
cpu cores   : 4

Говорят, что на этой машине я получил только одну микросхему (поскольку "phyical id" принимает только одно значение во всем списке, опущено), что эта микросхема в виде 4 "процессорных ядер" и что эта микросхема работает с четырьмя братьями и сестрами (4 темы, поэтому нет многопоточности). В этом случае есть 4 обрабатывающих элемента и 4 ядра процессора.

В приведенном выше примере с многопоточностью вы увидите список для 16 процессоров, 2 значения для "физического идентификатора" (чипы), "ядра процессора", равного 4 (на чип), и "братьев и сестер", равных 8 (на чип), поскольку многопоточность включена на этом чипе. В этом случае у вас в четыре раза больше процессоров, чем у ядер.

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

Другая полезная команда Linux - это lscpu:

...
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
...

На самом деле "сокет" - это физическое соединение в материнской плате, к которой подключен чип, так что это действительно название чипа. На самом деле здесь нет многопоточности.

Я в долгу перед обсуждениями в этом другом посте https://unix.stackexchange.com/q/146051/132913