Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
па-пми / лр-3.docx
Скачиваний:
0
Добавлен:
10.06.2026
Размер:
322.84 Кб
Скачать

МИНОБРНАУКИ РОССИИ

Санкт-Петербургский государственный

электротехнический университет

«ЛЭТИ» им. В.И. Ульянова (Ленина)

Кафедра МО ЭВМ

отчет

по лабораторной работе № 3

по дисциплине «Параллельные алгоритмы»

Тема: Коллективные операции.

Студентка гр. 3384

Преподаватель

Татаринов Ю.С.

Санкт-Петербург

2025

Цель работы.

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

Задание. (Вариант 5)

В каждом процессе дан набор из K чисел, где K — количество процессов. Используя функцию MPI_Alltoall, переслать в каждый процесс по одному числу из всех наборов: в процесс 0 — первые числа из наборов, в процесс 1 — вторые числа, и т. д. В каждом процессе вывести числа в порядке возрастания рангов переславших их процессов (включая число, полученное из этого же процесса).

Выполнение работы.

Описание алгоритма выполнения.

Алгоритм организован как согласованное взаимодействие процессов в распределённой среде, где каждый процесс знает свой порядковый номер и общее число участников. В начале каждый процесс формирует набор из K чисел, причём позиция числа в наборе однозначно указывает на адресата этого элемента, элементы с первой позицией предназначены процессу номер 0, с второй позиции процессу номер 1 и так далее по аналогии. Затем выполняется коллективный обмен и в каждый процесс попадает по одному числу из каждого набора, то есть именно те позиции, которые соответствуют рангу приёмника, в процесс 0 приходят все первые элементы, в процесс 1 приходят все вторые и так далее. После завершения обмена происходит синхронизация участников для упорядоченного вывода, при которой процессы поочередно выводят полученные значения в порядке возрастания номеров отправивших процессов включая значение, пришедшее от самого себя, чтобы избежать перемешивания сообщений в общем потоке вывода.

Графики.

На рисунке 1 показана зависимость среднего времени выполнения программы от числа процессов. Среднее время работы вычислялось как среднее на основе работы теста десять раз. По рисунку видно, что с увеличением числа процессов возрастает и время работы программы.

Рисунок 1 – График зависимости времени выполнения программы от числа процессов

На рисунке 2 представлен график замедления функции. Из него видно, что при увеличении числа процессов производительность программы резко падает.

Рисунок 2 – График замедления

Сеть Петри.

Сеть Петри для трех процессов представлена на рисунке 3.

Рисунок 3 – Сеть Петри

Сеть Петри моделирует выполнение коллективной операции MPI_Alltoall так: у каждого процесса есть специальное место data[p], которое визуально и семантически привязывает к процессу его начальный набор из K чисел. Эти исходные данные затем распространяются по системе через переход load[p]. Переход load[p] можно интепретировать как расформирование начального набора. Одновременно load[p] выпускает токен в место ready[p], сигнализируя, что процесс p завершил локальную подготовку данных и готов приступить к следующему этапу.

После инициализации реализована синхронизация. Для каждого процесса существует место ready[p], и переход barrier имеет входы от всех этих мест. Переход сможет сработать только тогда, когда в каждом ready[p] появится токен, то есть, когда все процессы закончили свою локальную подготовку. Когда barrier срабатывает, он производит в каждое место can_send[p] набор разрешений. Такая конструкция гарантирует, что никакая отправка не начнётся до тех пор, пока все процессы не достигли барьера.

Отправка сообщений моделируется переходами send[p]_to_[q]. После срабатывания send[p]_to_[q] происходит перемещение в место-буфер r_q, то есть доставляется сообщение в приёмную сторону процесса q.

Приёмная сторона для каждого процесса q организована как полоса с контролем порядка: для фиксированного q имеются буферы r_q для каждого отправителя p, переходы recv_q_from_p, контрольные места ctrl_q_r и места collected_q_r. Переход recv_q_from_r может сработать только когда в соответствующем буфере r_q_from_r есть токен одновременно есть токен в контрольном месте ctrl_q_r. Изначально в Ctrl_q_step_0 лежит один токен, а все последующие ctrl_q_r пусты. Когда recv_q_from_r срабатывает, он перемещает сообщение в collected_q_r и при необходимости производит токен в ctrl_q_{r+1}, тем самым разрешая следующий приём. Такая зависимость обеспечивает, во-первых, что сообщения выводятся в порядке возрастания рангов отправителей, а во-вторых, что даже если сообщение от отправителя с большим рангом придёт раньше по сети, оно будет ждать в своём буфере r_q_from_p до появления разрешающего токена.

В дополнение для каждого приёмника q предусмотрен переход fnish[q], который имеет на входе все места collected_q_r. Когда все K собранных слотов заполнены и переход Finish[q] срабатывает, он порождает маркер завершения Done[q]. Это позволяет явным образом зафиксировать факт того, что процесс q получил и обработал все K сообщений.

Разработанный программный код см. в Приложении А.

Тестирование программы см. в Приложении В.

Соседние файлы в папке па-пми