Функции MPI

Функции MPI

Производный тип, Операции, Типы данных

COMM_WORLD Send

Recv

Bsend Buffer_attach Get_count ANY_SOURCE Sendrecv_replace ANY_TAG Probe

BCast

Gather

Gatherv

Scatter

Scatterv

Allgether

Allgetherv Alltoall Alltoallv Reduce Rduce_scatter Scan

Pack Unpack

Производный тип строится из предопределенных типов MPI и ранее определенных производных типов с помощью специальных функций-конструкторов

MPI_Type_contiguous, MPI_Type_vector, MPI_Type_hvector, MPI_Type_indexed, MPI_Type_hindexed, MPI_Type_struct.

Новый производный тип регистрируется вызовом функции MPI_Type_commit. Только после регистрации новый производный тип можно использовать в коммуникационных подпрограммах и при конструировании других типов. Предопределенные типы MPI считаются зарегистрированными.

Когда производный тип становится ненужным, он уничтожается функцией MPI_Type_free.

1)MPI_Init - функция инициализации. В результате выполнения этой функции создается группа процессов, в которую помещаются все процессы приложения, и создается область связи, описываемая предопределенным коммуникатором MPI_COMM_WORLD.

MPI_Type_commit - регистрация типа, MPI_Type_free – уничтожение типа

int MPI_Init(int *argc, char ***argv);

2)MPI_Finalize - Функция завершения MPI программ. Функция закрывает все MPI-процессы и ликвидирует все области связи.

int MPI_Finalize(void);

3)Функция определения числа процессов в области связи MPI_Comm_size. Функция возвращает количество процессов в области связи коммуникатора comm.

int MPI_Comm_size(MPI_Comm comm, int *size);

4)Функция определения номера процесса MPI_Comm_rank. Функция возвращает номер процесса, вызвавшего эту функцию. Номера процессов лежат в диапазоне 0..size-1.

int MPI_Comm_rank(MPI_Comm comm, int *rank);

5)Функция передачи сообщения MPI_Send. Функция выполняет посылку count элементов типа datatype сообщения с идентификатором tag процессу dest в области связи коммуникатора comm.

int MPI_Send(void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm);

6)Функция приема сообщения MPI_Recv. Функция выполняет прием count элементов типа datatype сообщения с идентификатором tag от процесса source в области связи коммуникатора comm.

int MPI_Recv(void* buf, int count, MPI_Datatype datatype, int source, int tag, MPI_Comm comm, MPI_Status *status)

7) Функция отсчета времени (таймер) MPI_Wtime. Функция возвращает астрономическое время в секундах, прошедшее с некоторого момента в прошлом (точки отсчета).

double MPI_Wtime(void)

Функции передачи сообщений между процессами делятся на:

Префикс S (synchronous)

означает синхронный режим передачи данных. Операция передачи данных заканчивается только тогда, когда заканчивается прием данных. Функция нелокальная.

Префикс B (buffered)

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

Префикс R (ready)

согласованный или подготовленный режим передачи данных. Операция передачи данных начинается только тогда, когда принимающий процессор выставил признак готовности приема данных, инициировав операцию приема. Функция нелокальная.

Префикс I (immediate)

относится к неблокирующим операциям.

Структура MPI_Status

После чтения сообщения некоторые параметры могут оказаться неизвестными, а именно: число считанных элементов, идентификатор сообщения и адрес отправителя. Эту информацию можно получить с помощью параметра status. Переменные status должны быть явно объявлены в MPI-программе. В языке C status - это структура типа MPI_Status с тремя полями MPI_SOURCE, MPI_TAG, MPI_ERROR.

8)Для определения числа фактически полученных элементов сообщения необходимо использовать специальную функцию MPI_Get_count.

int MPI_Get_count (MPI_Status *status, MPI_Datatype datatype, int *count);

9) Определить параметры полученного сообщения без его чтения можно с помощью функции MPI_Probe. int MPI_Probe (int source, int tag, MPI_Comm comm, MPI_Status *status);

10)В ситуациях, когда требуется выполнить взаимный обмен данными между процессами, безопаснее использовать совмещенную операцию MPI_Sendrecv. В данной операции посылаемые данные из массива buf замещаются принимаемыми данными.

int MPI_Sendrecv(void *sendbuf, int sendcount, MPI_Datatype sendtype, int dest, int sendtag, void *recvbuf, int recvcount, MPI_Datatype recvtype, int source, MPI_Datatypeа recvtag, MPI_Comm comm, MPI_Status *status);

11) Функция проверки завершения неблокирующей операции MPI_Test.

int MPI_Test(MPI_Request *request, int *flag, MPI_Status *status);

Это локальная неблокирующая операция. Если связанная с запросом request операция завершена, возвращается flag = true, а status содержит информацию о завершенной операции. Если проверяемая операция не завершена, возвращается flag = false, а значение status в этом случае не определено.

12) Функция снятия запроса без ожидания завершения неблокирующей операции MPI_Request_free.

int MPI_Request_free(MPI_Request *request);

Параметр request устанавливается в значение MPI_REQUEST_NULL.

13)Достижение эффективного выполнения операции передачи данных от одного процесса всем процессам программы(широковещательная рассылка данных) может быть обеспечено при помощи функции MPI:

int MPI_Bcast(void *buf,int count,MPI_Datatype type,int root,MPI_Comm comm)

Функция MPI_Bcast осуществляет рассылку данных из буфера buf, содержащего count элементов типа type с процесса, имеющего номер root, всем процессам, входящим в коммуникатор comm.

14)При необходимости приема сообщения от любого процесса-отправителя для параметра source может быть указано значение MPI_ANY_SOURCE

15)При необходимости приема сообщения с любым тегом для параметра tag может быть указано значение MPI_ANY_TAG

16)Параметр status позволяет определить ряд характеристик принятого сообщения:

-status.MPI_SOURCE – ранг процесса-отправителя принятого сообщения,

-status.MPI_TAG - тег принятого сообщения.

17)Функция

MPI_Get_count(MPI_Status *status, MPI_Datatype type, int *count)

возвращает в переменной count количество элементов типа type в принятом сообщении.

18)Операции передачи данных от всех процессов одному процессу. В этой операции над собираемыми

значениями осуществляется та или иная обработка данных(для подчеркивания последнего момента данная операция еще именуется операцией редукции данных)

int MPI_Reduce(void *sendbuf, void *recvbuf,int count,MPI_Datatype type, MPI_Op op,int root,MPI_Comm comm)

19)Синхронизация процессов, т.е. одновременное достижение процессами тех или иных точек процесса вычислений, обеспечивается при помощи функцииMPI: int MPI_Barrier(MPI_Comm comm); Функция MPI_Barrier определяет коллективную операции и, тем самым, при использовании должна вызываться всеми процессами используемого коммун+икатора. При вызове функции MPI_Barrier

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

20)Для использования буферизованного режима передачи должен быть создан и переданMPI буфер памяти

для буферизации сообщений– используемая для этого функция имеет вид: int MPI_Buffer_attach(void *buf, int size),

где

-bufбуфер памяти для буферизации сообщений,

-size– размер буфера.

21)После завершения работы с буфером он должен быть отключен отMPI при помощи функции:

int MPI_Buffer_detach(void *buf, int *size).

22)Достижение эффективного и гарантированного одновременного выполнения операций передачи и приема данных может быть обеспечено при помощи функцииMPI:

int MPI_Sendrecv(void *sbuf,int scount,MPI_Datatype stype,int dest, int stag, void *rbuf,int rcount,MPI_Datatype

rtype,int source,int rtag, MPI_Comm comm, MPI_Status *status)

23) Когда сообщения имеют одинаковый тип, в MPI имеется возможность использования единого буфера: int MPI_Sendrecv_replace(void *buf, int count, MPI_Datatype type, int dest,

int stag, int source, int rtag, MPI_Comm comm, MPI_Status* status)

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

int MPI_Scatter(void *sbuf,int scount,MPI_Datatype stype,

void *rbuf,int rcount,MPI_Datatype rtype, int root, MPI_Comm comm)

25)Операция обобщенной передачи данных от всех процессоров одному процессу(сбор данных) является обратной к процедуре распределения данных(см. рис. 4.5). Для выполнения этой операции вMPI предназначена функция:

int MPI_Gather(void *sbuf,int scount,MPI_Datatype stype,

void *rbuf,int rcount,MPI_Datatype rtype, int root, MPI_Comm comm)

26)Следует отметить, что при использовании функции MPI_Gather сборка данных осуществляется только

на одном процессе. Для получения всех собираемых данных на каждом из процессов коммуникатора

необходимо использовать функцию сбора и рассылки:

int MPI_Allgather(void *sbuf, int scount, MPI_Datatype stype, void *rbuf, int rcount, MPI_Datatype rtype, MPI_Comm comm)

27)Передача данных от всех процессов всем процессам является наиболее общей операцией передачи данных(см. рис. 4.6). Выполнение данной операции может быть обеспечено при помощи функции:

В ее основе лежат принципы RISC-архитектуры: фиксированный формат команд, регистровые операции, однотактовое выполнение команд, простые способы адресации, большой регистровый файл. В то же время имеется несколько существенных особенностей, отличающих данную архитектуру от архитектур других RISC-процессоров. К ним относятся: независимый набор регистров для каждого из исполнительных устройств; включение в систему отдельных CISC-подобных инструкций; отсутствие механизма “задержанных переходов”; оригинальный способ реализации условных переходов. Основной областью применения микропроцессоров с архитектурой являются высокопроизводительные серверы и суперкомпьютеры.

Такие компьютеры основаны на архитектуре, отделяющей команды обработки от команд работы с памятью, и делали упор на эффективную конвейерную обработку. Система команд разрабатывалась таким образом, чтобы выполнение любой команды занимало небольшое количество машинных тактов (предпочтительно один машинный такт). Сама логика выполнения команд с целью повышения производительности ориентировалась на аппаратную, а не на микропрограммную реализацию. Чтобы упростить логику декодирования команд использовались команды фиксированной длины

ификсированного формата.

Вчем смысл технологии буфера целевых адресов переходов

Впроцессоре предусмотрен механизм динамического прогнозирования направления переходов. С этой

целью на кристалле размещена небольшая кэш-память, которая называется буфером целевых адресов переходов (BTB), и две независимые пары буферов предварительной выборки команд (по два 32битовых буфера на каждый конвейер). Буфер целевых адресов переходов хранит адреса команд, которые находятся в буферах предварительной выборки. Работа буферов предварительной выборки организована таким образом, что в каждый момент времени осуществляется выборка команд только в один из буферов соответствующей пары. При обнаружении в потоке команд операции перехода вычисленный адрес перехода сравнивается с адресами, хранящимися в буфере BTB. В случае совпадения предсказывается, что переход будет выполнен, и разрешается работа другого буфера предварительной выборки, который начинает выдавать команды для выполнения в соответствующий конвейер. При несовпадении считается, что переход выполняться не будет и буфер предварительной выборки не переключается, продолжая обычный порядок выдачи команд. Это позволяет избежать простоев конвейеров

Структурные конфликты и способы их минимизации

Совмещенный режим выполнения команд в общем случае требует конвейеризации функциональных устройств и дублирования ресурсов для разрешения всех возможных комбинаций команд в конвейере. Если какая-нибудь комбинация команд не может

быть принята из-за конфликта по ресурсам, то говорят, что в машине имеется структурный конфликт. Наиболее типичным примером машин, в которых возможно появление структурных конфликтов, являются машины с не полностью конвейерными функциональными устройствами.

Минимизация: конвейер приостанавливает выполнение одной из команд до тех пор, пока не станет доступным требуемое устройство.

Конфликты по данным, остановы конвейера и реализация механизма обходов

Одним из факторов, который оказывает существенное влияние на производительность конвейерных систем, являются межкомандные логические зависимости. Конфликты по данным возникают в том случае, когда применение конвейерной обработки может изменить порядок обращений за операндами так, что этот порядок будет отличаться от порядка, который наблюдается при последовательном выполнении команд на неконвейерной машине. Проблема, поставленная в этом примере, может быть разрешена с помощью достаточно простой аппаратной техники, которая называется пересылкой или продвижением данных (data forwarding), обходом (data bypassing), иногда закороткой (short-circuiting).

Конфликты по данным, приводящие к приостановке конвейера

Вместо этого нам нужна дополнительная аппаратура, называемая аппаратурой внутренних блокировок конвейера (pipeline interlook), чтобы обеспечить корректное выполнение примера. Вообще такого рода аппаратура обнаруживает конфликты и приостанавливает конвейер до тех пор, пока существует конфликт. В этом случае эта аппаратура приостанавливает конвейер начиная с команды, которая хочет использовать данные в то время, когда предыдущая команда, результат которой является операндом для нашей, вырабатывает этот результат. Эта аппаратура вызывает приостановку конвейера или появление "пузыря" точно также, как и в случае структурных конфликтов.

Буфера прогнозирования условных переходов

Буфер прогнозирования условных переходов представляет собой небольшую память, адресуемую с помощью младших разрядов адреса команды перехода. Каждая ячейка этой памяти содержит один бит, который говорит о том, был ли предыдущий переход выполняемым или нет. Это простейший вид такого рода буфера. В нем отсутствуют теги, и он оказывается полезным только для сокращения задержки перехода в случае, если эта задержка больше, чем время, необходимое для вычисления значения целевого адреса перехода. Буфер прогнозирования переходов может быть реализован в виде небольшой специальной кэш-памяти, доступ к которой осуществляется с помощью адреса команды во время стадии выборки команды в конвейере (IF), или как пара битов, связанных с каждым блоком кэшпамяти команд и выбираемых с каждой командой.