Этот пример показывает, как профилировать явную коммуникацию в самую близкую соседнюю лабораторию. Это иллюстрирует использование labSend, labReceive и labSendReceive, показывая и (неправильное) медленное и быстрый (оптимальный) способ реализовать этот алгоритм. Проблема исследуется с помощью параллельного профилировщика.
Предпосылки:
Интерактивный параллельный режим в Parallel Computing Toolbox™ (См. pmode в руководстве пользователя.)
Фигуры в этом примере производятся из кластера с 12 узлами.
Пример кода включает явную коммуникацию. В MATLAB® явная коммуникация синонимична с прямым использованием коммуникационных примитивов Parallel Computing Toolbox (например, labSend, labReceive, labSendReceive, labBarrier). Проблемы производительности, включающие этот тип коммуникации, если не связанный с используемым оборудованием, может быть трудно проследить. С параллельным профилировщиком могут быть в интерактивном режиме идентифицированы многие из этих проблем. Важно помнить, что можно разделить различные части программы в отдельные функции. Это может помочь при профилировании, потому что некоторые данные собраны только для каждой функции.
Алгоритм мы являемся профильными, является самым близким соседним коммуникационным шаблоном. Каждому работнику 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 выполняет, даст нам лучшее представление о том, что ожидать.
P>> labBarrier;% to ensures the labs all start at the same time
P>> mpiprofile reset; P>> mpiprofile on; P>> pctdemo_aux_profbadcomm;
1 sending to 2
receive from 122 receive from 1
sending to 33 receive from 2
sending to 44 receive from 3
sending to 55 receive from 4
sending to 66 receive from 5
sending to 77 receive from 6
sending to 88 receive from 7
sending to 99 receive from 8
sending to 1010 receive from 9
sending to 1111 receive from 10
sending to 1212 receive from 11
sending to 1P>> mpiprofile viewer;
1 Sending pmode lab2client to the MATLAB client for asynchronous evaluation.
Функциональный Сводный отчет отображен. На этой странице вы видите, что время потратило ожидание в коммуникациях как оранжевая панель в соответствии с Общим заголовком Графика временной зависимости. Данные ниже показов, что значительное количество времени было проведено, ожидая. Давайте смотреть, как параллельный профилировщик помогает идентифицировать, что причины их ожидают.
В Сводном отчете Функции профилировщика посмотрите на pctdemo_aux_profbadcomm запись и нажмите Compare макс. по сравнению с min TotalTime. Наблюдайте большое оранжевое время ожидания, обозначенное под функциональным iRecFromPrevLab. Это - ранняя индикация, что существует что-то не так с соответствием, отправляют, или из-за сетевых проблем или из-за проблем алгоритма.
Используйте главную таблицу панели инструментов, чтобы нажать Plot All Per Lab Communication. Первые данные в этом представлении показывают все данные, полученные каждой лабораторией. В этом примере каждая лаборатория получает тот же объем данных от предыдущей лаборатории, таким образом, это, кажется, не проблема распределения данных. Вторые данные показывают различные коммуникационные времена включая время, проведенное, ожидая коммуникации. В третьей фигуре Получить график Времени ожидания Коммуникации показывает пошаговое увеличение во время ожидания. Пример Получает график Времени ожидания Коммуникации, видны ниже использования кластера с 12 узлами. Хорошо возвратиться и проверять то, что происходит на исходной лаборатории.
Просмотрите то, что происходит на лаборатории 1. a.) В Профилировщике нажимают Home. b.) Кликают по функции pctdemo_aux_profbadcomm верхнего уровня, чтобы перейти к Функциональному Детализированному отчету. c.) Быть уверенным, которые Показывают, функциональный листинг выбран. d.) Прокручивают вниз и видят, где лаборатория 1 проводит время и какие строки покрыты. e. Для сравнения, посмотрите на таблицу Busy Line и выберите последнюю лабораторию с помощью поля списка лаборатории Goto.
Чтобы видеть все профилируемые строки кода, прокрутите вниз к последнему элементу на странице. Пример этого аннотируемого листинга кода виден ниже.
Чтобы ясно видеть проблему с нашим использованием labSend и labReceive, посмотрите на следующее, Получают график Времени ожидания Коммуникации от кластера с 12 узлами.
В графике выше, вы видите, что ненужное ожидает с помощью Графика Вся Коммуникация PerLab. Это время ожидания увеличивается, потому что блоки labReceive до соответствующего парного labSend завершились. Следовательно, вы получаете последовательную коммуникацию даже при том, что последующим лабораториям только нужны данные, которые порождают в ближайшем соседе labindex.
Можно использовать labSendReceive, чтобы отправить и получить данные одновременно лаборатории, что вы зависите от получить минимальное время ожидания. Смотрите это в исправленной версии коммуникационного шаблона, реализованного в pctdemo_aux_profcomm. Безусловно, использование labSendReceive не возможно, если необходимо получить данные, прежде чем можно будет отправить его. В таких случаях используйте labSend и labReceive, чтобы гарантировать хронологический порядок. Однако в случаях как этот пример, когда нет никакой потребности получить данные перед отправкой, labSendReceive использования. Давайте профилировать эту версию, не сбрасывая данные, собранные по предыдущей версии (используйте mpiprofile resume).
P>> labBarrier; P>> mpiprofile resume; P>> pctdemo_aux_profcomm;
1 sending to 2 receiving from 12 2 sending to 3 receiving from 1 3 sending to 4 receiving from 2 4 sending to 5 receiving from 3 5 sending to 6 receiving from 4 6 sending to 7 receiving from 5 7 sending to 8 receiving from 6 8 sending to 9 receiving from 7 9 sending to 10 receiving from 8 10 sending to 11 receiving from 9 11 sending to 12 receiving from 10 12 sending to 1 receiving from 11
P>> mpiprofile viewer;
1 Sending pmode lab2client to the MATLAB client for asynchronous evaluation.
Эта исправленная версия уменьшает время ожидания, чтобы эффективно обнулить. Чтобы видеть это, нажмите Plot All PerLab Communication после выбора pctdemo_aux_profcomm. Тот же коммуникационный шаблон, описанный выше, теперь не проводит почти времени, ожидая, используя labSendReceive (см. Получить график Времени ожидания Коммуникации ниже).
Для каждого 2D графика изображений окрашивающая схема нормирована к задаче под рукой. Поэтому не используйте окрашивающую схему в графике, который, как показывают выше, соответствовал другим графикам, поскольку цвета нормированы и зависят от максимального значения (замеченный в правом верхнем коричневого цвета). В данном примере использование макс. значения является лучшим способом сравнить огромную разницу во времена ожидания, когда мы используем pctdemo_aux_profcomm вместо pctdemo_aux_profbadcomm.