В этом примере показано, как профилировать явную связь с ближайшей соседней лабораторией. Он иллюстрирует использование labSend, labReceive, и labSendReceive, показывая как медленный (неправильный), так и быстрый (оптимальный) способ реализации этого алгоритма. Проблема рассматривается с помощью параллельного профилировщика. Начало работы с параллельным профилированием см. в разделе Профилирование параллельного кода.
Рисунки в этом примере получены из 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 реализация исполняет даст нам лучшее представление о том, чего ожидать.
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Появится окно Function Summary Report (Сводный отчет о функциях). На этой странице можно увидеть время ожидания в коммуникациях в виде оранжевой полосы под заголовком «График общего времени». Приведенные ниже данные показывают, что значительное количество времени было потрачено на ожидание. Давайте посмотрим, как параллельный профилировщик помогает определить причины этих ожиданий.
В сводном отчете функции профилировщика просмотрите запись pctdemo_aux_profbadcomm и щелкните Сравнить максимальное и минимальное TotalTime. Обратите внимание на большое оранжевое время ожидания, указанное в функции iRecFromPrevLab. Это раннее указание на то, что с соответствующей отправкой что-то не так, из-за проблем с сетью или алгоритмом.
Используйте верхнюю таблицу панели инструментов, чтобы щелкнуть Plot All Per Worker Communication. На первом рисунке в этом представлении показаны все данные, полученные каждой лабораторией. В этом примере каждая лаборатория получает одинаковое количество данных из предыдущей лаборатории, поэтому это не кажется проблемой распределения данных. На втором рисунке показаны различные времена связи, включая время ожидания связи. На третьем рисунке график Comm Waiting Time Per Worker показывает пошаговое увеличение времени ожидания. Пример графика Comm Waiting Time Per Worker можно увидеть ниже с использованием 12-узлового кластера. Хорошо вернуться и проверить, что происходит в исходной лаборатории.
Просмотрите, что происходит в лаборатории 1. a.) В окне Profiler нажмите кнопку Home. б.) Щелкните верхний уровень pctdemo_aux_profbadcomm для перехода к подробному отчету о функциях. в.) Убедитесь, что выбран параметр Показать список функций. д.) Прокрутите вниз и посмотрите, где лаборатория 1 проводит время и какие строки закрыты. e.) Для сравнения просмотрите таблицу Строки, где было потрачено больше всего времени, и выберите последнюю лабораторию usinAAg в списке Перейти к рабочему.
Чтобы просмотреть все профилированные строки кода, прокрутите вниз до последнего элемента на странице. Пример этого аннотированного кода приведен ниже.
Чтобы четко увидеть проблему с нашим использованием 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Эта исправленная версия сокращает время ожидания до нуля. Чтобы увидеть это, нажмите кнопку «Распечатать все на одного работника» после выбора pctdemo_aux_profcomm. Тот же шаблон связи, описанный выше, теперь почти не тратит времени на ожидание, используя labSendReceive (см. график Comm Waiting Time Per Worker ниже).
Для каждого 2-D графика изображения схема раскраски нормализуется к рассматриваемой задаче. Поэтому не используйте схему раскраски на графике, показанном выше, для сравнения с другими графиками, так как цвета нормализуются и зависят от максимального значения (см. вверху справа коричневым цветом). Для этого примера использование максимального значения является лучшим способом сравнения огромной разницы в времени ожидания при использовании pctdemo_aux_profcomm вместо pctdemo_aux_profbadcomm.