Алгоритм

Алгоритм мы являемся профильными, является самым близким соседним коммуникационным шаблоном. Каждому работнику 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

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

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

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

mpiprofile viewer

Эта откорректированная версия уменьшает время ожидания, чтобы эффективно обнулить. Чтобы видеть это, нажмите Plot All Per Worker Communication после выбора pctdemo_aux_profcomm. Тот же коммуникационный шаблон, описанный выше, теперь не проводит почти времени, ожидая, используя labSendReceive (см. Время ожидания Коммуникации На график Рабочего ниже).

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

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