Производительность MPI_Reduce по сравнению с (MPI_Gather + Reduction на корне)

Суперкомпьютер CRAY с использованием библиотеки MPICH2. Каждый узел имеет 32 процессора.

У меня есть один поплавок для N разных рангов MPI, где каждый из этих рангов находится на другом узле. Мне нужно выполнить операцию сокращения для этой группы поплавков. Я хотел бы знать, быстрее ли MPI_Reduce, чем MPI_Gather, с уменьшением, рассчитанным на корень, для любого значения N. Пожалуйста, предположите, что сокращение, выполненное на корневом ранге, будет выполнено с использованием хорошего алгоритма параллельного сокращения, который может использовать N потоков .

Если это не быстрее для любого значения N, будет ли это верно для меньшего N, например 16, или большего N?

Если это правда, то почему? (Например, будет ли MPI_Reduce использовать паттерн связи дерева, который имеет тенденцию скрывать время операции сокращения в подходе, который он использует для связи со следующим уровнем дерева?)


mpi supercomputers
person wiowou    schedule 25.04.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Предположим, что MPI_Reduce всегда быстрее, чем MPI_Gather + локальное сокращение.

Даже если бы имел место случай N, когда редукция выполняется медленнее, чем сбор, реализация MPI могла бы легко реализовать редукцию в этом случае с точки зрения сбора + локального редукции.

MPI_Reduce имеет только преимущества перед MPI_Gather + локальное сокращение:

  1. MPI_Reduce — операция более высокого уровня, предоставляющая больше возможностей для оптимизации реализации.
  2. MPI_Reduce нужно выделить гораздо меньше памяти
  3. MPI_Reduce необходимо передавать меньше данных (при использовании дерева) или меньше данных по той же ссылке (при использовании прямой связи "все к одному")
  4. MPI_Reduce может распределять вычисления по большему количеству ресурсов (например, используя древовидный коммуникационный шаблон)

Тем не менее: никогда не предполагайте ничего о производительности. Мера.

person Zulan    schedule 25.04.2018
comment
Отличный ответ. Я бы просто добавил старую статью, в которой предлагаются некоторые общие принципы, лежащие в основе производительности MPI, и их измерение: Самосогласованные рекомендации по производительности MPI JL Traff, WD Gropp, R Thakur, pdfs.semanticscholar.org/0dfc/ - person ang mo; 25.04.2018
comment
@angmo отличная находка! Сначала я думал, что правило (24) будет противоречить моему предположению, однако я думаю, что n означает общий размер собранного массива, а также размер данных для каждого сокращения - так что это имеет смысл. Поэтому я бы добавил MPI_Reduce(n) <= MPI_Gather(n/p). - person Zulan; 25.04.2018
comment
действительно, (24) формируется хитрым способом (и я не знал об этом до вашего комментария, спасибо!). Они говорят, что последовательный блок данных может быть собран из каждого процесса путем суммирования вкладов размера ni со всеми процессами, кроме i, вносящих блоки из ni нулей, так что это похоже на то, что они сравнивают сбор с очень конкретным сокращением... - person ang mo; 25.04.2018
comment
Спасибо за ясный и логически последовательный ответ, @Zulan! Конечно, как вы указываете, измерьте, чтобы подтвердить. Также спасибо @ang mo за ссылку на этот документ. Очень полезно. - person wiowou; 26.04.2018
comment
@Zulan: после более внимательного прочтения правила 24 кажется, что MPI_Gather(n) ‹= MPI_Reduce(n), потому что я всегда могу дополнить элементы процесса i нейтральным элементом и выполнить MPI_Reduce(n) вместо MPI_Gather(n) ), если бы MPI_Reduce(n) работал быстрее, чем MPI_Gather(n). Пример: rank0=[1,2], rank1 [4,7]. Я использую MPI_Reduce с MPI_SUM. Если я читаю значения так, что rank0=[1,2,0,0] и rank1=[0,0,4,7], MPI_Reduce даст мне [1,2,4,7] на rank0 быстрее, чем MPI_Gather дайте мне [1,2,4,7] на rank0, если MPI_Reduce(n) ‹= MPI_Gather(n). Должно быть, что MPI_Gather(n)‹=MPI_Reduce(n). - person wiowou; 26.04.2018
comment
@Zulan, будет ли MPI_Implementation выполнять параллельное сокращение одного ранга на ваш ответ, 2-е предложение? Знает ли MPI, какие ранги на самом деле являются ядрами мультипроцессора, а какие — отдельными процессорами? Кроме того, пункт 1: да, MPI_Reduce — это более высокий уровень, но это более общий случай MPI_Gather, согласно моему объяснению выше. - person wiowou; 26.04.2018
comment
@wiowou, да, именно так я прочитал правило 24. Но опять же для вас правило MPI_Reduce(n/p) <= MPI_Gather(n) (раньше я поменял местами местами) или даже точнее MPI_Reduce(1) <= MPI_Gather(p). - person Zulan; 26.04.2018
comment
Реализации MPI знают об узлах в разделяемой памяти, чтобы избежать сетевого стека при локальном обмене данными. Я не уверен, что сокращение выполняется локально на практике - вот тут-то и появляется часть, не предполагающая меры. Практически есть также аспект, который может не иметь значения для вашего приложения. Чтобы удовлетворить любопытство: многие распространенные реализации MPI имеют открытый исходный код, так что вы можете посмотреть на них :-). - person Zulan; 26.04.2018
comment
@Zulan, еще раз спасибо! Полезно знать, что MPI знает о локальных процессорах. Я проверю, но я думаю, что CrayMPI может быть не открыт. - person wiowou; 27.04.2018