Руководство пользователя для MPICH, переносимой реализации MPI версия 1.2.1

Оглавление

• 3 СПЕЦИАЛЬНЫЕ СВОЙСТВА РАЗЛИЧНЫХ СИСТЕМ.
  • 3.1 Кластеры рабочих станций.
    • 3.1.1 Проверка вашего машинного списка.
    • 3.1.2 Использование защитной оболочки.
    • 3.1.3 Использование сервера безопасности.
    • 3.1.4 Неоднородные сети и устройство ch p4.
    • 3.1.5 Переменные окружения, используемые в P4.
    • 3.1.6 Использование специальных схем соединения.
    • 3.1.7 Использование совместных библиотек.
  • 3.2 Быстрый старт с помощью многоцелевого демона и устройство ch p4mpd.
    • 3.2.1 Цели.
    • 3.2.2 Введение
    • 3.2.3 Примеры
    • 3.2.4 Как работают демоны.
    • 3.2.5 Отладка.
  • 3.3 Вычислительные сети: устройство globus2.
  • 3.4 MPP.
    • 3.4.1 IBM SP.
    • 3.4.2 Intel Paragon
  • 3.5 Симметричные мультипроцессоры (SMP)

3. Специальные свойства различных систем.

MPI позволяет сравнительно легко писать переносимые параллельные программы. Однако, одна вещь, которую MPI не стандартизирует – это окружение, в рамках которого исполняется параллельная программа. Существуют три базисных типа параллельных режимов: параллельные компьютеры, кластеры рабочих станций и интегрированные распределенные среды, которые мы будем называть "вычислительными сетями", которые включают параллельные компьютеры и рабочие станции и могут охватывать многие узлы. Естественно, параллельный компьютер (обычно) обеспечивает интегрированный, сравнительно простой путь для исполнения параллельных программ. Кластеры рабочих станций и сетевое оборудование, с другой стороны, не обеспечивают стандартного пути для выполнения параллельных программ и требуют дополнительных усилий. Реализация mpich предназначена для того, чтобы преодолеть эту разницу с помощью сценария mpirunt; однако, если вам необходимы какие-то специальные свойства или параметры, или возникают трудности при выполнении ваших программ, вам необходимо понимать различия между названными выше системами. В дальнейшем, мы опишем специфические особенности, которыми обладают кластеры рабочих станций, вычислительные сети (на устройствах globus2), и определенные параллельные компьютеры.

3.1 Кластеры рабочих станций.

Большинство матричных параллельных процессоров (сокращенно MPP) обеспечивают возможность запуска программы на требуемом количестве процессоров; mpirun обеспечивает употребление соответствующей возможной команды. В отличие от этого, кластеры рабочих станций требуют, чтобы каждый процесс в параллельном задании был запущен индивидуально, хотя и существуют программы для облегчения запуска таких процессов (см. ниже 3.1.3). Поскольку кластеры рабочих станций не организованы как MPP, их использование требует дополнительной информации. Mpich должна устанавливаться со списком имеющихся рабочих станций в файле `machines.!arch?' в каталоге `/usr/local/mpich/share'. Этот файл используется командой mpirun для выбора запускаемых процессоров. (Использование неоднородных кластеров обсуждается ниже.) Остальная часть настоящего раздела посвящена деталям этого процесса и того, как можно исправлять ошибки. Эти инструкции относятся только к устройству ch.p4.

3.1.1 Проверка вашего машинного списка.

Воспользуйтесь сценарием `tstmachines' в `/usr/local/mpich/sbin', чтобы убедиться, что можно использовать все перечисленные машины. Этот сценарий производит rsh и короткий список каталогов; он проверяет, что вы имеете доступ к узлу и что программа в текущем каталоге видима с отдаленного узла. Если обнаруживаются какие-то проблемы, они будут указаны. Эти проблемы должны быть устранены до продолжения работы. Единственный аргумент для tstmachines – имя архитектуры; это то же имя, что и в расширении имени машинного файла.

Например, /usr/local/mpich/bin/tstmachines sun4 проверяет, что программа в текущем каталоге может исполняться на всех машинах

в списке для sun4. Эта программа молчит, если все в порядке. Если вы хотите увидеть, что она делает, употребите –v в составе многословного аргумента:

/usr/local/mpich/bin/tstmachines –v sun4 Выход этой команды может выглядеть подобно следующему:

Trying true on host1.uoffoo.edu …

Trying true on host2.uoffoo.edu …

Trying ls on host1.uoffoo.edu …

Trying ls on host2.uoffoo.edu …

Trying user program on host1.uoffoo.edu …

Trying user program on host2.uoffoo.edu …

Если tstmachines обнаружит неувязку, она выдает возможные причины и решения.

3.1.2 Использование защитной оболочки.

В Руководстве по установке говорится, как настроить ваше окружение так, чтобы устройства ch p4 в сети использовали защитную оболочку ssh вместо rsh. Это полезно в сетях, где в целях безопасности использование rsh не принято или не разрешается.

3.1.3 Использование сервера безопасности.

Так как каждая рабочая станция в кластере обычно требует регистрации каждого нового пользователя и так как этот процесс требует много времени, то mpich предлагает программу для ускорения этого процесса. Это – сервер безопасности, который помещается в `serv.p4' в каталоге `/usr/local/mpich/bin'. Сценарий `chp4.servs' в том же каталоге можно использовать для запуска `serv.p4' на тех рабочих станциях, на которых есть программы rsh. Сервер можно запустить вручную как фоновую программу; это удобно на машинах, которые не принимают связей rsh, но на которых есть ваши записи. Перед запуском сервера проверьте, что сервер был установлен для общего пользования; тогда им могут пользоваться все. В этом режиме для установки сервера требуется корневой доступ. Если сервер не был установлен, вы можете установить его для себя без требования специальных привилегий командой

-port=, должен быть отличным от всех других портов, используемых на рабочих станциях. Чтобы использовать сервер безопасности на устройстве ch.p4,

добавьте следующие определения к вашему окружению:

setenv MPI.USEP4SSPORT yes setenv MPI.P4SSPORT 1234

Значением MPI.P4SSPORT должен быть порт, с которым вы запускаете сервер безопасности. Когда эти переменные окружения установлены, mpirun пытается

использовать сервер безопасности для запуска программ, использующих ch.p4. (Аргумент командной строки –p4ssport для mpirun можно употреблять вместо этих переменных окружения;

mpirun –help сообщит вам и другую информацию.)

3.1.4 Неоднородные сети и устройство ch p4.

Сеть рабочих станций называется неоднородной, если связанные ею машины имеют различную архитектуру и/или операционные системы.

Например, сеть может содержать 3 Sun SPARC (sun4) рабочие станции и 3 SGI IRIX рабочие станции, которые все связываются по протоколу TCP/IP. С помощью следующей команды mpirun можно использовать их всех:

мультикомпьютеров. Для обеспечения такой конфигурации нужно использовать устройство globus2. Подробности см. в следующем разделе.

Устройство globus2 не использует сервер безопасности. Оно пользуется моделью безопасности, реализованной с помощью GSS API. См. приложение С по

поводу информации о безопасности в Globus.

Специальное программное имя program.%a позволяет вам указывать различные исполнимые варианты для программ, поскольку исполнимый вариант для Sun

Программы можно помещать также в разные каталоги; например, mpirun –arch sun4 –np 3 –arch IRIX –np 3 /tmp/%a/program

Для еще большего контроля над запуском заданий мы должны познакомиться с тем, как mpirun запускает параллельную программу на кластере рабочих станций. При каждом своем выполнении mpirun строит и использует новый файл машинных имен только для текущего исполнения, используя как вход машинный файл. (Этот новый файл называется PIyyyy, где yyyy означает идентификатор процесса.) Если вы в вызове mpirun указываете –keep.pg, вы можете воспользоваться этой информацией, чтобы посмотреть, где mpirun выполняет ваши последние задания. Вы сами должны создать этот файл и указать его как аргумент для mpirun. Чтобы сделать это для ch.p4, выдайте

mpirun –p4pg pgfile myprog где pgfile – имя файла.

Формат этого файла указан ниже. Это необходимо, когда вы хотите строго контролировать хосты, на которых исполняется ваша

программа или когда mpirun не может этого сделать автоматически. Такой случай имеет место, если вы хотите исполнять программу на множестве машин, отличном от указанного в машинном файле.

Или вы хотите запускать разные исполнимые на разных хостах (ваша программа не есть SPMD).

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

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

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

Формат файла ch.p4 procgroup – множество строк формы!hostname? !#procs? !progname? ^!login?Примером такого файла, где команда выдана с хоста sun1, может быть

sun1 0 /users/jones/myprog sun2 1 /users/jones/myprog

sun3 1 /users/jones/myprog hp1 1 /home/mbj/myprog mbj

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

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

пользователем по его команде.

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

sun1 0 /users/jones/myprog sun1 1 /users/jones/myprog

sun1 1 /users/jones/myprog Это запустит три процесса на sun1 с коммуникацией через гнезда (sockets).

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

на alaska общаются через совместно используемую память, вы должны использовать local 0 /home/jbg/main alaska 3 /afs/u/graphics

Передавать различные аргументы из командной строки различным процессам при MPI невозможно.

3.1.5 Переменные окружения, используемые в P4.

Имеются несколько переменных окружения, которые могут использоваться для настройки производительности устройства ch.p4. Заметим, что эти переменные

должны быть определены для всех создаваемых процессов, а не только для процессов, которые вы запускаете из программ MPI (т.е., установка этих переменных должна быть предусмотрена в ваших стартовых файлах `.login' или

`.cshrc'). P4 SOCKBUFSIZE.

Указывает в байтах размер буфера гнезда (socket). Увеличивая этот размер, можно улучшить производительность некоторых систем. Однако, под LINUX, в частности для систем LINUX с заплатками TCP, это увеличение увеличивает вероятность зависания mpich.

P4 WINSHIFT.

Это другой параметр гнезда, который употребляется только на некоторых платформах. Рекомендуем не трогать его.

P4 GLOBMEMSIZE.

Это – количество памяти в байтах, резервированное для коммуникаций с совместной памятью (если mpich конфигурирована с –comm=shared). Увеличьте его,

если получите сообщение об ошибке, говорящее что p4.shmalloc возвращает NULL.

3.1.6 Использование специальных схем соединения.

В некоторых установках отдельные узлы могут быть соединены многими способами.

Например, «нормальная» Ethernet может быть дополнена быстродействующим кольцом FDDI. Обычно для идентификации быстродействующих связей используются

альтернативные имена узлов. Вам нужно только вписать эти альтернативные имена в ваш файл machines.xxxx.

В таком случае важно не употреблять форму локального 0, а использовать имя локального хоста.

Например, если узлы host1 и host2 имеют ATM (асинхронный способ передачи) связанный с host1-atm и host2-atm соответственно,

то правильный ch.p4 procgroup-файл для них (при выполнении программы `/home/me/a.out') будет

host1-atm 0 /home/me/a.out host2-atm 1 /home/me/a.out

3.1.7 Использование совместных библиотек.

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

Вместе с тем, имеются некоторые практические трудности в использовании совместных библиотек. В этом разделе говорится о некоторых из них и о способах их разрешения.

В настоящее время совместные библиотеки не поддерживаются для C++.

Для постройки совместных библиотек для mpich нужно конфигурировать и строить mpich с параметром –enable-sharedlib. Поскольку каждая Unix-система и

фактически каждый компилятор используют различные и часто несовместимые параметры для создания общих объектных модулей и библиотек, mpich может

оказаться не в состоянии определить правильные параметры. В настоящее время mpich «понимает» Solaris, GNU gcc (на большинстве платформ, включая LINUX

и Solaris), и IRIX. Информацию о построении совместных библиотек на других платформах нужно посылать в mpi-bugs@mcs.anl.gov. Если совместные библиотеки

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

использоваться по умолчанию, выясняется ниже). Вы можете сделать это либо параметром командной строки –shlib, либо установкой переменной окружения

mpicc –o cpi –shlib cpi.c или setenv MPICH.USE.SHLIB yes

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

Например, вы можете иметь единственный файл `.cshrc', который вы используете и с SGI (IRIX) и с Solaris. Вы не хотите установить LD.LIBRARY.PATH для

указания на SGI из-за другой версии для Solaris совместных библиотек mpich.

Вместо этого вам хотелось бы установить переменную окружения до запуска

mpirun:

setenv LD.LIBRARY.PATH $-LD.LIBRARY.PATH"»:/usr/local/mpich/lib/shared mpirun –np 4 cpi

К несчастью, это не всегда сработает. В зависимости от метода, который mpirun и mpich используют для запуска процессов, переменная окружения может быть не передана новому процессу. Это приведет к аварийному завершению с сообщением подобным

ld.so.1: /home/me/cpi: fatal: libpmpich.so.1.0: open failed: No such file or directory Killed Чтобы справиться с этой проблемой, вы должны использовать новый сервер безопасности (раздел 3.1.3). Этот сервер построен по make serv.p4 и может быть установлен на всех машинах из машинного файла текущей архитектуры с помощью chp4.servs –port=1234 Новый сервер безопасности распространяет все переменные окружения на отдаленный процесс и обеспечивает в окружении этого процесса (содержащего вашу MPI-программу) присутствие всех переменных окружения, имя которых начинается с LD (как раз в тех случаях, когда система использует LD.SEARCH.PATH или другие имена для нахождения совместных библиотек). Альтернативой для использования LD.LIBRARY.PATH и сервера безопасности является добавление некоторый опции к команде компоновки, которая обеспечит путь для поиска совместных библиотек. К несчастью, эта желаемая опция есть «добавить этот каталог к пути поиска» (что вы и имеете). Вы можете осуществить проверку `.cshrc' вида системы, на которой исполняется программа и соответственно этому выбрать путь. Это не так удобно, как установка переменной окружения из действующей оболочки с помощью –L. Вместо этого, многие компиляторы позволяют только «заменить» путь поиска на такой-то путь». Например, некоторые компиляторы допускают

-Rpath:path:…:path для указания замены пути. Таким образом, если и mpich и пользователь оба обеспечивают путь поиска с –R, один из путей будет потерян. В конце концов mpicc и прочие подобные могут проверить параметры –R и создать унифицированную версию, но до настоящего времени они этого не сделали. Но вы можете сами обеспечить полный

поиск пути, если ваш компилятор имеет такой параметр как –R.

Сказанное выше звучит слишком сложно для исполнения, и в некоторой степени это так и есть. Однако для больших кластеров игра стоит свеч. Программы будут запускаться быстрее и надежнее.

3.2 Быстрый старт с помощью многоцелевого демона и устройство ch p4mpd.

Это – экспериментальное устройство и для него версия mpirun немного отлична от аналогичной версии для других устройств. В этом разделе говорится, как

работает система демонов mpd и как выполнять программу MPI с ее помощью. Чтобы воспользоваться этой системой, MPICH должна быть сконфигурирована

с устройством ch p4mpd и демоны должны быть запущены на машинах, на которых будет исполняться ваша программа. В этом разделе описано, как все это сделать.

3.2.1 Цели.

Назначение многоцелевого демона (т.е. mpd и связанного с ним устройства ch p4mpd) – придать mpirun свойства единой программы даже тогда,

когда она запускает много процессов при выполнении задания MPI.

Мы будем ссылаться на процесс mpirun и процессы MPI. Такое обращение включает быстрый общий запуск процессов MPI (и даже не-MPI). Для тех, кто

привык использовать устройство ch p4 в сетях TCP, следующее окажется наиболее заметным сразу изменением:

Более быстрый запуск заданий.

Замена набора stdout и stderr от процессов MPI на stdout и stderr для процесса mpirun.

Переход от stdin при mpirun к stdin для MPI process 0.

Передача сигналов от процесса mpirun к процессам MPI.

Это означает следующее:

Убить, задержать или закончить ваше параллельное задание так же легко, как отдельный процесс, с помощью cntl-C, cntl-Z, или командами bg и fg.

Передачу аргументов командной строки всем процессам MPI.

Копированием окружения PATH от окружения, в котором исполняется mpirun, к окружению, в котором исполняются процессы MPI.

Употребление выборочного аргумента для передачи других переменных окружения.

Использование другого выборочного аргумента для указания, где процессы MPI будут исполняться (см. ниже),

даже в тех случаях, когда компоновщик (linker) может обеспечить «добавку к пути поиска».

3.2.2 Введение

Устройство ch p4 по умолчанию запускает процесс на отдаленной машине с помощью rsh. Необходимость идентификации во время запуска задания вкупе с

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

В версии 1.2.1 он значительно усовершенствован и теперь будет устанавливаться при установке mpich с make install. На системах с gdb он имеет простой параллельный отладчик, который мы назвали mpigdb.

Его основная идея состоит в установке еще до запуска задания некоторой сети демонов на машинах, на которых будут исполняться процессы MPI, и на машине, на которой будет выполняться mpirun. Тогда команды запуска задания (и другие команды) вступят в контакт с местным демоном и используют предварительно созданных демонов в стартовых процессах. Этим исключается начальная синхронизация, производимая устройством ch p4, поскольку демоны могут использоваться для установления связей между процессами.

Чтобы использовать новый механизм старта, вы должны конфигурировать с новым устройством:

Запуск демонов:

– On fire: fire% mpd &  ² 23792 ^fire.55681: MPD starting fire% – On soot: soot% mpd –h fire –p 55681 &  ¹ 6629 ^soot.35836: MPD starting soot%

mpd идентифицируются хостом и номером порта. Если демоны себя не обнаруживают, можно найти хост и порт командой mpdtrace:

– On fire: fire% mpd & fire% mpdtrace mpdtrace: fire.55681: lhs=fire.55681 rhs=fire.55681

rhs2=fire.55681 fire%

– On soot: soot% mpd –h fire –p 55681 & soot% mpdtrace mpdtrace: fire.55681: lhs=soot.33239 rhs=soot.33239

rhs2=fire.55681 mpdtrace: soot.33239:

localmpds !number? запускает !number? mpds на локальной машине. Практически это используется только для тестирования. Обычно делают

remotempds !hostfile?

формата файлов MACHINES, используемых устройством ch p4 и могущих содержать комментарии и другие символы.

См. также сценарий startdaemons, который устанавливается при установке mpich.

Наконец, можно запускать задания как обычно, командой mpirun:

mpirun –np 4 a.out Убивать демонов можно командой mpdallexit.

3.2.3 Примеры

Приведем несколько примеров использования mpirun, которая образована при конфигурации MPICH и построена с устройством ch p4mpd.

Запуск примера cpi:

mpirun –np 16 /home/you/mpich/examples/basic/cpi Ели вы внесете /home/you/mpich/examples/basic в ваш путь посредством

setenv PATH $-PATH"»:/home/you/mpich/examples/basic то вы можете выполнить просто

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

Используйте аргументы и переменные окружения.

mpirun –np 32 myprog arg1 arg2 –MPDENV– MPE.LOG.FORMAT=SLOG « GLOBMEMSIZE=16000000

Аргумент –MPDENV – есть ограничивающая метка. Все аргументы после него mpirun обрабатывает вместо прикладной программы.

Указывайте, где должен исполняться первый процесс. По умолчанию, процессы MPI порождаются последовательными mpd в кольце, начиная с первого после локального ( исполняемого на той же машине, что и процесс mpirun).

Таким образом, если вы зарегистрированы в dion и есть mpd, исполняемые в dion и в belmont1, belmont2, . . . , belmont64, и вы ввели

mpirun –np 32 cpi –MPDLOC– belmont33 belmont34 … belmont64 то ваше задание будет исполняться на belmont33, belmont34, . . . , belmont64.

Вообще то, процессы будут исполняться только на машинах из списка после –MPDLOC-. Это представляет крайне предварительный и неудобный способ для mpirun выбирать места для размещения процессов MPI. В будущем мы собираемся использовать проект mpd как средство для исследования интерфейса между планировщиками, менеджерами процессов, параллельными прикладными программами

(в частности, в динамическом окружении MPI-2) и командами пользователя.

Чтобы установит, на каких хостах работают ваши mpd, нужно:

mpirun –np 32 hostname – sort – uniq Это запустит 32 экземпляра хост-имени в предположении, что /bin находится

в вашем пути, независимо от того, сколько mpd имеется. Другие процессы будут оборачиваться вокруг кольца mpd.

3.2.4 Как работают демоны.

Когда демоны запускаются, они связываются в кольцо: «консольный» процесс (mpirun, mpdtrace, mpdallexit и пр.) может связаться с любым mpd, который он создает, используя то, что в Unix называется гнездом (socket) и устанавливается в /tmp локальным mpd. Если рассматриваемый процесс есть mpirun, он запрашивает запуск некоторого количества процессов на машинах, указанных посредством –MPDLOC-, как об этом говорилось выше.

Демоны последовательно выбираются из кольца и назначаются менеджерами заказанных процессов. Менеджеры исполняемых процессов называются mpdman и помещаются в каталог mpich/mpid/mpd.

Менеджеры сами организуются в кольцо, обслуживаемые ими процессы называются клиентами.

Консоль отсоединяется от mpd и вновь связывается с первым менеджером. stdin от mpirun передается клиенту менеджера 0. Менеджеры перехватывают стандартные ввод/вывод от клиентов и передают им аргументы командной строки и переменные окружения, определенные в команде mpirun. Гнезда, несущие stdout и sdterr, образуют дерево с корнем в менеджере 0. Ситуация в этот момент подобна изображенной на рис. 1. Когда клиенты хотят вступить в контакт

остается необходимым отдельное кольцо из mpd для каждого пользователя.

пароль. Этот файл читается, когда запускается mpd. Только те mpd, которые знают этот пароль, могут входить в кольцо существующих mpd.

Новым свойством является возможность конфигурировать систему mpd так, чтобы демоны могли запускаться как корневые программы. Чтобы получить это, после

конфигурации /mpich/ ее нужно реконфигурировать в каталоге /mpich/mpid/mpd с –enable-root и перестроить.

mpirun должна быть установлена как программа setuid. Многократные пользователи могут использовать одно и то же множество mpd, которые

исполняются как корневые программы, хотя их mpirun, менеджеры и клиенты будут исполняться как пользователь, выдавший mpirun.

3.2.5 Отладка.

Одной из команд в системе mpd является простой параллельный отладчик, который позволяет вам выполнять все процессы под контролем отладчика gdb и взаимодействовать с ними по отдельности или вместе путем перенаправления stdin. Вот простой пример выполнения mpich/examples/cpi таким способом:

donner% mpigdb –np 3 cpi # default is stdin bcast (mpigdb) b 33

# set breakpoint for all 0: Breakpoint 1 at 0x8049eac: file cpi.c, line 33. 1: Breakpoint 1 at 0x8049eac: file cpi.c, line 33. 2: Breakpoint 1 at 0x8049eac:

file cpi.c, line 33. (mpigdb) r # run all 2: Breakpoint 1, main (argc=1, argv=0xbffffab4) at cpi.c:33 1:

Breakpoint 1, main (argc=1, argv=0xbffffac4) at cpi.c:33 0:

Breakpoint 1, main (argc=1, argv=0xbffffad4) at cpi.c:33 (mpigdb) n # single step all 2: 43 MPI.Bcast(&n, 1, MPI.INT, 0, MPI.COMM.WORLD);

0: 39 if (n==0) n=100; else n=0; 1: 43 MPI.Bcast(&n, 1, MPI.INT, 0, MPI.COMM.WORLD); (mpigdb) z 0

# limit stdin to rank 0 (mpigdb) n # single step rank 0 0: 41 startwtime = MPI.Wtime(); (mpigdb) n

# until caught up 0: 43 MPI.Bcast(&n, 1, MPI.INT, 0, MPI.COMM.WORLD); (mpigdb) z # go back to bcast (mpigdb) n

# single step all …. # несколько раз (mpigdb) n

# until interesting spot 0: 52 x = h * ((double)i – 0.5); 1: 52 x = h * ((double)i – 0.5); 2: 52 x = h * ((double)i – 0.5); (mpigdb) p x

# bcast print command 0: $2 = 0.0050000000000000001 # 0's value of x 2: $2 = 0.025000000000000001

# 2's value of x 1: $2 = 0.014999999999999999 # 1's value of x (mpigdb) c

# continue all 0: pi is approximately 3.1416009869231249, Error 0.0000083333333318

0: Program exited normally.

1: Program exited normally.

2: Program exited normally. (mpigdb) q # quit donner%

3.3 Вычислительные сети: устройство globus2.

Устройство globus2, (которое заменило устройство globus) обеспечивает выполнение программ MPI на «вычислительных сетях», которые могут содержать параллельные компьютеры и рабочие станции, и которые могут охватывать много узлов. В рамках такой сети различные узлы могут иметь различные механизмы безопасности и механизмы создания процессов. Устройство globus2 скрывает от вас такие детали нижнего уровня, позволяя запускать с помощью mpirun на сетях программы как на MPP и кластерах рабочих станций. Устройство globus2 имеет и другие полезные свойства, такие как удаленный доступ к файлам и перемещение вычислительных данных. Эти свойства обеспечиваются услугами инструментария Globus.

См. детали в http://www.globus.org.

Устройство globus2 требует функционирования специальных серверов на компьютерах, на которых создаются процессы. В нашей дискуссии о том, как

использовать устройство globus2, мы предполагаем, что мы используем устройство globus2 на группе машин, на которых установлены и работают

различные серверы Globus. На такую группу часто ссылаются как на вычислительную сеть, например, NASA's Information Power Grid (IPG). Если возможно, мы рекомендуем вам использовать устройство globus2 в таком окружении. Если вы хотите использовать устройство globus2 в других ситуациях, сообщите пожалуйста об этом в developers@globus.org.

Подробности того, как выполнять программы MPI с использованием устройства globus2 на вычислительных сетях типа Globus

см. в Приложении C.

3.4 MPP.

Все MPP немного различаются, и даже системы, полученные от одного и того же поставщика, могут иметь различные способы выполнения заданий на разных установках. Программа mpirun старается приспособиться к этому, но может оказаться, что она не работает на вашей установке. Вы можете попробовать параметры –show или –t (для теста) в mpirun. Это покажет, как mpirun будет запускать ваши программы MPI, не делая этого на самом деле. Часто эта информация вместе с инструкциями о запуске программ в вашей системе может помочь вам при запуске программ. Пожалуйста дайте нам знать (mpi-bugs@mcs.anl.gov) о любых особенностях эксплуатации.

3.4.1 IBM SP.

Использование mpirun на компьютерах IBM SP может быть затруднено, потому что существует много различных (и часто взаимно исключающих) способов выполнения

программ на них.

mpirun, распространяемая с mpich, работает на системах, использующих планировщик Argonne (называемый иногда EASY) и с системами, использующими по умолчанию значения менеджера ресурсов (т.е. те, которые не требуют от пользователя выбора какого-нибудь RMPOOL).

Если имеются затруднения с выполнением программы mpich, попробуйте следовать правилам вашей установки для выполнения программ MPL или POE (если

используются устройства ch.mpl) или для выполнения p4 (при использовании устройств ch.p4).

3.4.2 Intel Paragon

Использование mpirun с Intel Paragon может быть сложным, потому что существует очень много различных (и часто взаимно исключающих) путей

выполнения программ. Команда mpirun, поставляемая с mpich, работает с Paragon'ами, которые по умолчанию обеспечивают разделение вычислений. Имеются некоторые параметры –paragon…, для выбора других форм. Например,

-paragonpn compute1 определяет для выполнения предварительно определяемое (pre-existing) разделение.

3.5 Симметричные мультипроцессоры (SMP)

На многих реализациях с совместно используемой памятью (устройства ch.shmem) mpich резервирует часть совместной памяти для передаваемых в разные стороны сообщений. По умолчанию, mpich резервирует около четырех CHECK MBytes совместной памяти. Это можно изменить с помощью переменной окружения

MPI.GLOBMEMSIZE. Например, чтобы резервировались 8 MB, введите