Алгоритм

Алгоритм мы являемся профильными, является самым близким соседним коммуникационным шаблоном. Каждому работнику MATLAB нужны данные только из себя и одной соседней лаборатории. Этот тип шаблона параллели данных предоставляет себя хорошо многим матричным проблемам, но, когда сделано неправильно, может быть напрасно медленным. Другими словами, каждая лаборатория зависит от данных, которые уже доступны на смежной лаборатории. Например, в кластере с четырьмя лабораториями, лаборатория 1 хочет отправить некоторые данные лаборатории 2 и нуждается в некоторых данных лаборатории 4, таким образом, каждая лаборатория зависит только от еще одной лаборатории:

1 зависит от-> 4

2 зависит от-> 1

3 зависит от-> 2

4 зависит от-> 3

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

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

Можно просмотреть код для pctdemo_aux_profbadcomm и pctdemo_aux_profcomm видеть полноценные внедрения этого алгоритма. Посмотрите на первый файл и заметьте, что он использует labSend и labReceive для коммуникации.

Это - частая ошибка начать думать в терминах labSend и labReceive когда это не необходимо. Взгляд, в как этот pctdemo_aux_profbadcomm реализация выполняет, даст нам лучшее представление о том, что ожидать.

Профилирование labSend Реализация

spmd
    labBarrier; % to ensure the labs all start at the same time
    mpiprofile reset;
    mpiprofile on;
    pctdemo_aux_profbadcomm;
end

Worker  1: 
  sending to 2
Worker  2: 
  receive from 1
Worker  3: 
  receive from 2
Worker  4: 
  receive from 3
Worker  5: 
  receive from 4
Worker  6: 
  receive from 5
Worker  7: 
  receive from 6
Worker  8: 
  receive from 7
Worker  9: 
  receive from 8
Worker 10: 
  receive from 9
Worker 11: 
  receive from 10
Worker 12: 
  receive from 11
Worker  1: 
  receive from 12
Worker  2: 
  sending to 3
Worker  3: 
  sending to 4
Worker  4: 
  sending to 5
Worker  5: 
  sending to 6
Worker  6: 
  sending to 7
Worker  7: 
  sending to 8
Worker  8: 
  sending to 9
Worker  9: 
  sending to 10
Worker 10: 
  sending to 11
Worker 11: 
  sending to 12
Worker 12: 
  sending to 1

mpiprofile viewer

Параллельный Сводный отчет Профиля отображен. На этой странице вы видите, что время потратило ожидание в коммуникациях как оранжевая панель в соответствии с Общим столбцом Графика временной зависимости. Данные ниже показов, что значительное количество времени было проведено, ожидая. Давайте смотреть, как параллельный профилировщик помогает идентифицировать, что причины их ожидают.

Шаги быстрого запуска

Чтобы видеть все профилируемые строки кода, прокрутите вниз к последнему элементу на странице. Пример этого аннотируемого листинга кода виден ниже.

Коммуникационные графики Используя больший нелокальный кластер

Ясно видеть проблему с нашим использованием labSend и labReceive, посмотрите, в следующий Коммуникационный Раз (Ожидая) график от кластера с 12 узлами.

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

Используя labSendReceive Реализовывать этот Алгоритм

Можно использовать labSendReceive отправить и получить данные одновременно лаборатории, что вы зависите от получить минимальное время ожидания. Вы видите это в откорректированной версии коммуникационного шаблона, реализованного в pctdemo_aux_profcomm. Безусловно, использование labSendReceive не возможно, если необходимо получить данные, прежде чем можно будет отправить их. В таких случаях используйте labSend и labReceive гарантировать хронологический порядок. Однако в случаях как этот пример, когда нет никакой потребности получить данные перед отправкой, labSendReceive использования. Профилируйте эту версию, не сбрасывая данные, собранные по предыдущей версии (используйте mpiprofile resume).

spmd
    labBarrier;
    mpiprofile resume;
    pctdemo_aux_profcomm;
end

Worker  1: 
  sending to 2 receiving from 12
Worker  2: 
  sending to 3 receiving from 1
Worker  3: 
  sending to 4 receiving from 2
Worker  4: 
  sending to 5 receiving from 3
Worker  5: 
  sending to 6 receiving from 4
Worker  6: 
  sending to 7 receiving from 5
Worker  7: 
  sending to 8 receiving from 6
Worker  8: 
  sending to 9 receiving from 7
Worker  9: 
  sending to 10 receiving from 8
Worker 10: 
  sending to 11 receiving from 9
Worker 11: 
  sending to 12 receiving from 10
Worker 12: 
  sending to 1 receiving from 11

mpiprofile viewer

Эта откорректированная версия уменьшает время ожидания, чтобы эффективно обнулить. Чтобы видеть это, просмотрите графики рабочего к коммуникации рабочего для pctdemo_aux_profcomm функция. Используя labSendReceive, тот же коммуникационный шаблон теперь не проводит почти времени, ожидая, как показано в следующий Коммуникационный Раз (Ожидая) график.

Цветовая схема графика

Для каждого 2D графика изображений окрашивающая схема нормирована к задаче под рукой. Поэтому не используйте окрашивающую схему в графике, который, как показывают выше, соответствовал другим графикам, поскольку цвета нормированы и зависят от максимального значения. В данном примере использование макс. значения является лучшим способом сравнить огромную разницу во времена ожидания, когда мы используем pctdemo_aux_profcomm вместо pctdemo_aux_profbadcomm.