Здесь перечислены правила, в той или иной степени применимые к
большинству реализаций MPI. Некоторые замечания относятся к особенностям Юникса,
о которых не мешает помнить всегда, а работая с MPI - в особенности.
Утилиты построения и запуска MPI-приложений
Эти утилиты находятся в подкаталоге bin каталога MPI.
Для их быстрого запуска наберите в командной строке или укажите в стартовом
файле следующую команду: C-Shell (файл .cshrc): setenv PATH путь_к_MPI/bin:$PATH
bash (файл .bashrc): export PATH=путь_к_MPI/bin:$PATH
DOS/Win (C:\AUTOEXEC.BAT): set PATH=путь_к_MPI\bin;%PATH%
Командные файлы с именами mpicc, mpiCC,
mpif77 и т.д. предназначены для компиляции и компоновки соответствующих
исходных текстов. Примеры: mpicc mpi_ex0.c -o mpi_ex0
mpiCC mpi_ex1.cc -o mpi_ex1
mpif77 mpi_ex2.f -o mpi_ex2 -g -lm При этом будет вызван обычный
компилятор Си/Си++/Фортрана с указанной командной строкой, дополненной
директивами подключения заголовочных и библиотечных файлов MPI.
Дополнительные ключи, не передаваемые компилятору, а
обрабатываемые самим командным файлом, в спецификации не оговорены, но возможны.
Например, в MPICH ключ -echo включает трассировку выполнения командного
файла, полезную для поиска ошибок в инсталляции сопутствующего мат.обеспечения.
У большинства утилит для вывода подсказки служит ключ -help.
Загрузчик MPI-приложений называется mpirun. У
него ключей много разных и всяких, но только один из них является обязательным
(-np = number of processes): mpirun -np N [mpirun_args] program_file [command_line_args ...] Параллельное
приложение будет образовано N задачами-копиями, загруженными из программного
файла program_file. В момент запуска все задачи одинаковы (и имеют
одинаковые параметры командной строки), но получают от MPI разные номера от 0 до
N-1. Пример: mpirun -np 5 ./mpi_ex0
Примечание: текущий каталог "./" указывается здесь
явно, потому что без явного указания либо в имени программы, либо в переменной
окружения PATH Юникс НЕ станет искать в нем приложение. Если по
умолчанию PATH не содержит ".", Вы можете сами исправить
.cshrc или .bashrc в своем домашнем каталоге: C-Shell: set path = ( . $path )
bash: export PATH=.:$PATH
Документация
Практика показывает, что на период работы с той или иной
библиотекой полезно бывает распечатать и держать под рукой ее заголовочные файлы
из подкаталога include. В Convex MPI такой файл один: mpi.h, в
MPICH их три: mpi.h (описания констант и типов), mpi_errno.h
(коды ошибок и их описания) и binding.h (прототипы функций). В случае
для Windows печатать рекомендуется не оригиналы, а копии, из которых вычищены
все детали, относящиеся к реализации ("_declspec(dllimport)" и проч.).
Manual pages - хорошее подспорье, когда они есть. Независимо от
этого, документация из разных версий MPICH доступна для Вас двумя способами:
Более детальную информацию, как-то: спецификацию, учебники и
различные реализации MPI можно найти на сервере NetLib. Первоисточником для
данного пособия является книга "MPI: The complete reference"
издательства MIT Press - Вы найдете ее на этом сервере.
Отладка MPI-приложений обычным отладчиком
MPI-приложение состоит из множества процессов (по одному на
каждую ветвь), в то время как большинство отладчиков позволяют отлаживать только
один процесс. Здесь приведены некоторые общие советы, применимые более чем к
одной из описываемых далее реализаций.
Отладка ветви, запускаемой непосредственно из mpirun
(в большинстве реализаций так запускается только ветвь 0):
- если mpirun в данной реализации не требуется:
- если mpirun позволяет запустить ветвь 0 под отладчиком:
нет проблем, запускайте и отлаживайте.
- ... если ни то, ни другое:
/* в зависимости от реализации MPI,
* прочие ветви в этот момент могут быть еще не запущены
*/
MPI_Init( &argc, &argv );
/* здесь уже все ветви заведомо запущены
*/
MPI_Comm_size( MPI_COMM_WORLD, &commSize );
MPI_Comm_rank( MPI_COMM_WORLD, &myRank );
printf("Rank=%d, PID=0x%X\n", myRank, getpid() );
if( myRank==0 )
{
puts("MPI_Init ok, press any key...");
getch(); /* ветвь 0 остановится здесь */
}
MPI_Barrier( MPI_COMM_WORLD ); /*остальные ветви остановятся здесь*/ Дождавшись
после после запуска приложения появления указанной надписи, следует
"подцепить" (attach) предварительно запущенный отладчик (отладчики) к
избранной ветви (ветвям). Отладка ветвей, запускаемых из
MPI_Init() нулевой ветви:
- если реализация позволяет ручной запуск ведомых ветвей:
Как
правило, это означает, что вместо команды запуска ветвей будут не выполнены, а
выведены на консоль. После этого пользователь должен запустить их сам, и при
этом имеет возможность любую из них запустить под отладчиком.
- ... если не позволяет:
См. выше описание "тяжелого
случая". Поскольку ветвь 0 изначально запускается под отладчиком, вместо
puts+getch в приведенном примере - после MPI_Init, но перед
MPI_Barrier - можно просто поставить точку останова (breakpoint, говоря
по-нашему).
Объединение в кластеры
Администратору, выбирая реализацию MPI для установки на ту или
иную машину, обязательно следует иметь представление о следующих вещах:
- в какой момент определяется протокол для приемопередачи между ветвями
приложения:
- в момент построения MPI,
- в момент конфигурирования MPI (если оно может быть выполнено без повторного
построения),
- в момент построения приложения,
- автоматически на стадии выполнения приложения,
- является ли выбираемый протокол лучшим из возможных?
- предусмотрена ли возможность многомашинной работы,
- ... и поддерживается ли протокол P4?
В многомашинной конфигурации - о каждой части MPI и
MPI-приложения рекомендуется в общих чертах знать:
- на каких машинах (узлах) эта часть должна находиться,
- в какой момент она попадает на узел:
- при инсталляции MPI,
- при построении MPI-приложения,
- при запуске MPI-приложения, и т.д.
- и каким образом она туда попадет:
- требуется инсталляция,
- требуется компиляция+инсталляция,
- необходимо копировать вручную,
- копирование производится автоматически, и т.д.
Как
правило, найти в документации ответ на эти вопросы не составляет труда, но
четкая постановка самих вопросов требует некоторого времени и опыта.
MPICH: базовая реализация
MPI
CHameleon - это реализация, которую разработчики стандарта MPI выпускают как средство
наглядной пропаганды своих замыслов. MPICH:
- перенесен на большое количество Unix-платформ,
- поддерживает разные коммуникационные интерфейсы нижнего уровня (SVR4 IPC,
TCP/IP, IBM MPL и несколько архитектурно-зависимых для массивно-параллельных
машин - Intel NX и т.д.)
- полностью реализует все заложенные в спецификацию возможности.
Следует отметить, что хотя, с одной стороны, MPICH реализует все, с
другой - не все он реализует предельно эффективно. Например, сконфигурированный
с использованием разделяемой памяти для внутримашинных пересылок, MPIСH не может
работать на кластере, а сконфигурированный с поддержкой сети, использует
TCP/IP-протокол и загрузчик rsh даже для
внутримашинной связи. Выбор одного из вариантов задается при инсталляции ключем
-comm: ./configure -comm=ch_shmem
./configure -comm=ch_p4 -device=shared
По умолчанию установка производится в каталог
/usr/local/mpich. Следовательно, после установки делаем: export PATH=/usr/local/mpich/bin:$PATH
export MANPATH=/usr/local/mpich/man:$MANPATH
Документация и подсказки
Присутствует все необходимое: в виде man-pages, в
виде HTML-страниц, в виде
PostScript- и Tex- документов - в подкаталогах man, www и
doc соответственно. Кроме того, представляют интерес рассыпанные по
подкаталогам README-файлы.
Профилирование: PMPI, Jumpshot
Профилирующая библиотека в MPICH идентична базовой, а функция
MPI_Pcontrol ничего не делает. Таким образом, формально эта часть спецификации
поддерживается, фактически - нет.
Тем не менее, в MPICH включены средства, предназначенные
облегчить генерацию и обработку статистики вручную. Это набор подпрограмм
CLOG_Xxx,
которыми программист может пользоваться для сохранения статистических данных, и
написанное на Яве средство визуализации под названием Jumpshot. Ни то,
ни другое мною не испытывалось.
Отладка
mpirun имеет ключи для запуска приложения из-под того
или иного отладчика, например, -gdb запустит GDB, -xxgdb - GDB
c графическим интерфейсом для X-Window, и так далее. Поскольку GDB позволяет
отлаживать только один процесс, mpirun запускает под ним нулевую ветвь.
Нулевая ветвь запускается автоматически и останавливается после входа в
MPI_Init(), поэтому пытаться ставить точки останова до
MPI_Init() в высшей степени бессмысленно. Запуск остальных ветвей
производится в MPI_Init() нулевой ветви.
В последнее время ходит много слухов о параллельном отладчике
TotalView, который якобы
весьма перспективен, перенесен на многие платформы и совместим с MPI. Сам я
никогда его не видел, но так говорят.
Объединение нескольких машин через P4
Последовательность действий следующая:
- при конфигурировании MPICH (перед построением) должно быть выбрано
"устройство P4":
./configure -device=ch_p4 -comm=shared
- в каталоге .../mpich/util/machines, согласно находящемуся там
README-файлу, должны быть созданы текстовые файлы с именами вида
machines.<ARCH>, каждый из которых содержит адреса всех машин
данной архитектуры.
- на всех ведомых машинах должен быть настроен сервис "remote
shell":
- имя протокола для порта 514 прописано в файле /etc/services,
- то же самое имя вместе с именем демона rshd прописано в файле
/etc/inetd.conf,
- имя ведущей машины прописано в файле .rhosts в домашнем каталоге
пользователя, или в /etc/hosts.equiv
- на ведущей машине должен иметься клиент "remote
shell".
Проверка работоспособности: rsh имя_машины uname
-a Показатель того, что rsh не работает: сообщение
Permission denied.
Программный файл приложения должен быть предварительно вручную
скопирован на те машины, на которых его предполагается запускать
mpirun'ом.
Реализации, производные от MPICH
Коммерческие реализации выпускаются производителями ЭВМ. Как
правило, они напрямую основаны на MPICH, поэтому повторяют его не только
вследствие стандарта, но и во многих технических мелочах. Отличия могут
заключаться в:
- оптимизации под конкретную платформу,
- учете архитектурных особенностей,
- дополнительных функциях и утилитах,
- совместимости с уже наработанным для данной платформы мат.обеспечением
(отладчики, профайлеры и т.д.).
В-частности, HP-MPI, установленный на
ЭВМ HP SPP-1600, расчитан на одновременное использование всех коммуникационных
интерфейсов с автоматическим выбором самого быстрого: разделяемая память (в т.ч.
с оптимизацией для SPP), P4 и т.д.
Большинство Win32-реализаций MPI - так же не свободные, а
коммерческие продукты. Это объясняется тем, что собственно MPICH изначально для
переноса и оптимизации под Windows не предназначен и не приспособлен; ожидать,
что эта работа будет проделана на безвозмездной основе, не приходится.
MPI на ЭВМ SPP-1600
Адрес компьютера: spp.csa.ru.
MPI находится в каталоге /opt/mpi. Это HP MPI: коммерческая
реализация, оптимизированная специально под архитектуру машин этой фирмы. Она
работает на всех компьютерах (от рабочих станций до майнфреймов) с процессорами
PA RISC и операционными системами HP-UX и SPP-UX.
Запуск
Собственно, mpirun, хотя на SPP можно обойтись и без
него: ./mpi_ex0 -np 5 то есть mpirun не нужен, а его ключи
указываются первыми в командной строке приложения.
Полезные дополнительные утилиты, в MPICH отсутствующие
(подробности - в ManPages, или при запуске с ключом -help):
- mpijob - выводит информацию о запущенных MPI-приложениях,
запущенных как на локальной машине, так и на HPMPI-кластере. Аналогична команде
Юникса jobs.
- mpiclean - уничтожает MPI-приложение, действует наподобие команды
kill. Идентификаторы приложений выдает команда mpijob. Ключ
-m служит для освобождения "подвисшей" разделяемой памяти.
- xmpi - графический загрузчик и монитор:
Отладка
Параллельный отладчик на SPP есть! Называется он CXdb. Фирма
Convex адаптировала CXdb к процессору PA-RISC и операционной системе HP-UX фирмы
Hewlett-Packard после своего превращения в Convex Division of HP. CXdb позволяет
отлаживать приложение, состоящее из множества процессов, каждый из которых, в
свою очередь, состоит из множества потоков. Пользователь имеет возможность
указывать область действия для вводимых команд, т.е. перечислять те потоки и
процессы, на которые команда распространяется. Управлять отладчиком можно как
через систему меню и экранных кнопок, так и через несложный командный язык.
Замечание из собственного опыта: в CXdb оказалось все необходимое для отладки
писавшихся мною приложений, как параллельных, так и чисто последовательных.
MPI-приложение под CXdb запускается так: все аргументы
mpirun записываются в отдельный файл, назовем его mpi_ex0.cmd:
-np 4 ./mpi_ex0 Команда для запуска отладчика выглядит так:
cxdb -mpi mpi_ex0.cmd. Отладчик запускает программу, прогоняет ее до
MPI_Init(), приостанавливает, после чего переходит в режим ввода
команд.
2 предупреждения касательно точек останова:
- Не ставьте точек останова до MPI_Init! К тому моменту, когда у Вас
появится такая возможность, вся эта часть программы до MPI_Init
включительно уже выполнена.
- Точка останова, включаемая щелчком мыши по номеру строки в окне исходного
текста, действует только в текущем потоке текущего процесса. Будьте внимательны!
Подсказки и документация
Manual pages по HP MPI находятся в каталоге /opt/mpi/share/man:
C-Shell: setenv MANPATH /opt/mpi/share/man:$MANPATH
bash: export MANPATH=/opt/mpi/share/man:$MANPATH
Справочная информация по CXdb:
- Как видно на вышеприведенной картинке (см.в верхний правый угол обоих окон),
в самом отладчике имеется оперативная помощь. Составлена она качественно.
- man cxdb на SPP-1600 - описание запуска и ключей командной строки.
- man csd на dragon.csa.ru или
magic.csa.ru. Может пригодиться, если CXdb
используется в консольном режиме, то есть с ключом -csd. При этом его
собственная полноэкранная подсказка становится недоступна.
Профилирование
Стандартный профайлер CXpa приспособлен для работы с
MPI-приложениями. Я с ним не работал.
Допустим следующий способ профилирования:
- mpirun запускается с ключом -t:
mpirun -np 4 -t mystatfile program_name [program_args...] каждая
ветвь в ходе выполнения будет писать статистику в свой файл, имена всех файлов
будут иметь общий префикс mystat и расширение .tr
- созданный двоичный файл с расширением .tr может быть просмотрен в
мониторе xmpi, либо в генераторе отчета mpitrstat:
mpitrstat foo.tr | more Вот пример такого отчета: mpitrstat HP MPI 1.2 - SPP-UX Sat Nov 7 07:58:05 1998
Application Summary
Duration Average
Trace Procs [secs] User MPI [kbytes]
---------------------------------------------------------
foo 4 21.16959 100.00% 0.00% 0.000K
Application Analysis
foo
Duration
Process Executable Segments [secs] MPI
---------------------------------------------------------
0:11971(0) mpi_ex9 0 5.305031 0.00%
0:11972(1) ... 0 5.274548 0.00%
0:11973(2) ... 0 5.305022 0.00%
0:11970(3) ... 0 5.284993 0.00%
Routine Summary
Overhead Blocking
Routine Calls [secs] [secs] Percent
---------------------------------------------------------
USER_code 4 21.16959 0.00000 100.00%
Process Summary
Overhead Blocking User
Process [secs] [secs] [secs] Dominating Routines
---------------------------------------------------------
- Несколько .tr-файлов могут быть объединены в один утилитой
mpitrget. Предполагается, что таким образом файлы ветвей будут
объединяться в единый файл-отчет приложения.
- Запись статистики можно включать и отключать программно вызовами функций
MPIHP_Trace_on() и MPIHP_Trace_off(). Запуск с первоначально
отключенной статистикой делается так:
mpirun -np 4 -t mystatfile:off program_name [program_args...]
Собираемая статистика предназначена исключительно для профилирования
MPI, а не пользовательской части приложения:
- сколько вызовов MPI-подпрограмм было сделано за время трассировки,
- сколько времени потрачено в процентном/абсолютном отношении,
- какое количество времени ушло на ожидания при приемопередачах,
- и какая его доля при этом не была использована приложением, и т.д.
Почему на SPP не рекомендуется работать с MPI
Основных причин - три:
- С 1996 года процессор PA-RISC 7200 успел морально устареть, и
производительность SPP на фоне современных ЭВМ довольно невелика.
- На ЭВМ с общей памятью, какой является SPP, MPI по скорости работы
проигрывает программам, использующим общую память, семафоры и многопоточность.
- На ЭВМ с оптимизирующими распараллеливающими компиляторами, какой опять-таки
является SPP, MPI проигрывает традиционному программированию по скорости
разработки приложения, поскольку требует явного ручного
распараллеливания, с сомнительным выигрышем по скорости выполнения
(см.пред.пункт).
По-видимому, наилучшим стало бы такое разделение обязанностей:
- на SPP производится отладка и (частично) профилирование; для этого на SPP
имеется удобный отладчик, а кроме того, большое ОЗУ, большой жесткий диск,
качественное "железо" и надежное программное обеспечение,
- затем приложение MPI переносится на более быстрый, но менее оснащенный
мат.обеспечением компьютер, где после минимальных исправлений запускается в
рабочем режиме.
К сожалению, в настоящий момент SPP сверх всякой меры
перегружен именно рабочими расчетами некоторых особенно достойных деятелей,
из-за чего 8-процессорный монстр работает как черепаха. Эта безответственная
практика безнаказанно цветет столь пышным цветом, что какое-то более
рациональное его использование стало практически невозможным.
WinMPICH: устаревшая реализация для Windows
Свои первые примеры на MPI я писал, используя пакет WinMPICH 0.92b и Microsoft
Visual C++ 4.0. Все работает нормально.
WinMPICH скомпилирован в отладочном режиме, а именно...
- На экране регулярно будут появляться окна наподобие этого:
Выбирайте "Ignore" ( "Пропустить"
).
- Отладочному варианту для работы требуются две дополнительных динамических
библиотеки, доступных через PATH. Скачайте их со страницы WinMPICH,
поместите в его BIN-директорию, и добавьте C:\WinMPICH\bin в переменную
окружения PATH.
- WinMPICH без проблем компилируется в релиз-версию, не содержащую отладочной
информации, не выводящую ненужных окошек и не требующую дополнительных
библиотек.
Недостатки
- Последняя версия WinMPICH вышла в 1996 году. Судя по всему, проект заглох.
Таким образом, эта реализация не предоставляет программисту ту часть MPI,
которая была или будет стандартизована позднее.
- WinMPICH не совместим с другими реализациями MPI, то есть не может служить
для объединения разнотипных машин в MPI-кластер. Объясняется это тем, что для
межмашинной связи WinMPICH использует свой собственный упрощенный протокол
вместо стандартного P4, используемого в базовом MPICH.
- В WinMPICH-кластере все машины, кроме ведущей (с которой происходит запуск
mpirun) должны работать под управлением Windows NT, а не Windows'9x.
- Поскольку все ветви запускаются загрузчиком MPIRUN.EXE, их нельзя
запустить из-под отладчика. Отладчик требуется "присоединять" к уже
запущенной ветви, в запланированную для начала отладки точку исходного текста
которой рекомендуется вписать вызов assert(0), или, на худой конец,
getch(). За более подробными разъяснениями по поводу отладки в среде
Win32 милости прошу сюда.
WMPI: еще одна реализация MPICH для Windows
WMPI наиболее популярен в среде Windows в настоящий момент.
Работает в '95 и в NT, с Си и Фортраном. В обоих случаях имеются в виду
компиляторы от Микрософта. Путем определенных манипуляций можно заставить WMPI
работать с Borland C++.
Сайт разработчиков: http://dsg.dei.uc.pt/wmpi
Недостатки
- исходники не публикуются,
- мне не удалось связать его с MPICH/Linux, несмотря на заявления авторов WMPI
о возможности такого симбиоза.
Достоинства
- развивается в ногу с MPICH (в частности, поддерживает MPI-IO),
- запускается и работает быстрее, чем WinMPICH,
- пригоден для образования MPI-кластеров на базе машин с Win32.
Документация и подсказки
В HTML-формате, смотрите файл .../Docs/index.html.
Описание MPI-IO (функций распределенного файлового ввода-вывода) отсутствует.
Построение программ
Kомандные файлы MPICC.BAT и MPIRUN.BAT отсутствуют, так как
предполагается, что программист использует для работы интегрированную среду
Microsoft Developer Studio, а не командную строку. Применительно к Developer
Studio подробно указаны все изменения, которые требуется внести в проект по
умолчанию.
Запуск
Построенный EXE-файл запускается без всяких загрузчиков.
Он требует для работы динамическую библиотеку CVWMPI.DLL (если
программа консольная) или VWMPI.DLL (если она графическая). Соответственно, Вам
требуется либо вписать каталог с DLL в переменную окружения PATH, либо
скопировать DLL в...:
- The directory from which the application loaded.
- The current directory.
- Windows 95: The Windows system directory. Use the GetSystemDirectory
function to get the path of this directory. Windows NT: The 32-bit Windows
system directory. Use the GetSystemDirectory function to get the path of this
directory. The name of this directory is SYSTEM32.
- Windows NT only: The 16-bit Windows system directory. There is no Win32
function that obtains the path of this directory, but it is searched. The name
of this directory is SYSTEM.
- The Windows directory. Use the GetWindowsDirectory function to get the path
of this directory.
- The directories that are listed in the PATH environment variable.
Так гласит описание LoadLibrary в справочнике по WinAPI.
Количество и место запуска ветвей задается в текстовом файле,
имеющим то же имя, что EXE-файла, плюс расширение .PG. Строки в нем имеют такой
вид: # комментарий
local Количество_ветвей
Адрес_машины Количество_ветвей Имя_EXE_файла
Когда PG-файл читается, ветвь номер 0 уже создана (в запущенном
EXE-файле в этот момент выполняется функция MPI_Init), таким образом, общее
количество ветвей на 1 больше указываемого в PG-файле. То есть, чтобы запустить
приложение из 4 ветвей на своей машине, надо написать в PG-файле: local 3
При желании, если вместо стандартного интерпретатора команд
Command.com или Cmd.exe используется 4DOS или
4NT, простейший mpirun.btm может быть записан так: @echo off
:: This is mpirun.btm (4DOS/4NT batch file) sample for WMPI
if "%1" ne "-np" (
echo Usage mpirun -np NN program.exe args...
beep
quit 1
)
echo local %@dec[%2] > %@path[%3]%@name[%3].pg
set PATH=C:\Program files\WMPI_1.2\Lib\Console;%PATH%
%3&
Чтобы получить подсказку по ключам запуска WMPI-приложения,
запустите его с ключом -p4help.
Отладка
Параллельных отладчиков для Win32 нет. Каждая отлаживаемая
ветвь должна выполняться под управлением отдельного экземпляра отладчика. Ветвь
0 отлаживается запуском EXE-файла непосредственно из интегрированной среды или
автономного отладчика (WinDbg для Visual C++, Turbo Debugger для Borland C++).
К остальным ветвям отладчик следует "цеплять". В DevStudio это
делается через пункт меню "Build->Start Debug->Attach to
Process...".
Профилирование
Профилирующий вариант библиотеки, требования к которому
поверхностно сформулированы в спецификации на MPI, в состав WMPI не входит.
Следовательно, быстродействие коммуникационной части может замеряться лишь
вручную: расставленными вокруг вызовов MPI-процедур вызовами
GetTickCount() или чем-то в этом роде.
Пользовательская часть MPI-приложения может профилироваться
стандартными средствами (от Микрософт и аналогичными). При этом, впрочем, вполне
возможен конфликт ветвей, запущенных из одного EXE-файла, так как они могут
начать писать прифилировочную статистику в один и тот же файл-отчет, что,
естественно, недопустимо.
PowerMPI для Парситека
PowerMPI - это MPICH, адаптированный к архитектуре ЭВМ
Parsytec. В качестве коммуникационного уровня он использует API Parix. Файлы
PowerMPI располагаются внутри каталога с Париксом
(/export/var/www/parix/mpi на ЭВМ pink.csa.ru, /epx/mpi на всех
остальных).
В построенном приложении от MPI не остается уже ничего - это
обычное приложение Парикса, которое и запускаться должно командой px
run. Это, кстати, означает, что при использовании PowerMPI Парситеки не
могут быть объединены в MPI-кластеры ни друг с другом, ни с ЭВМ других типов.
Поскольку Парcитек не cтал утруждать себя созданием таких типовых утилит, как
mpicc, mpif77 и mpirun, строить MPI-приложение тоже
предлагается как-то так: px ancc mpi_sin.c -o mpi_sin.px -I/epx/mpi/include \
-L/epx/mpi/lib/parix/ch_px -lmpi
Для размещения сценариев в каталоге с PowerMPI
создается подкаталог bin, который затем должен быть подключен к
переменной окружения PATH: setenv PATH /epx/mpi/bin:$PATH
Замечания по mpicc:
- переменная PX_MPI в исходном тексте mpicc (секция
"Options") должна содержать правильный путь к PowerMPI,
- драйвер к компилятору Фортрана-77 получается следующим образом: ln -s
mpicc mpif77,
- редактируйте при необходимости секцию "Check self name" для
исправления имени компилятора Фортрана-77 и добавления поддержки других
компиляторов (f90, etc.).
Эти командные файлы могут быть либо не
установлены на некоторых Парситеках, либо содержать ошибки и недоработки. Самые
последние версии всегда находятся на этой странице.
Отладка и профилирование
Для этого доступны все средства, какие есть в составе Парикса.
Разбираться с ними я либо не пробовал, либо пробовал, но безуспешно. Сюда
относятся параллельный полноэкранный отладчик DeTop (у меня не
запустился), профайлеры prof и gprof. Собственно PowerMPI в
своем составе ничего ни для отладки, ни для профилирования не имеет;
документация так же отсутствует.
Что будет при попытке использовать MPICH вместо PowerMPI ?
MPICH будет использовать для межузловой связи "P4 поверх
TCP/IP поверх Ethernet" вместо значительно более быстрого "Parix
поверх HighSpeedLink", поскольку ничего не знает о последнем.
Пользователь должен самостоятельно копировать программный файл
MPICH-приложения на те узлы, на которых собирается его запускать. Для этого
администратор системы должен открыть локальные диски вычислительных узлов для
пользовательского доступа.
В случае, если предыдущий пункт не выполнен, или загрузчик
mpirun запускается только с ключем -np, MPICH запустит
приложение не на всем Парситеке, а на одном-единственном узле (надо полагать,
это будет входной узел). Естественно, что в этом случае никакое
распараллеливание не принесет ни малейшего выигрыша.
Я пишу это все потому, что подобные попытки превратить
крестьянскую лошаденку в стального коня, установив на него (на Парситек) MPICH
посвежее, уже имели место в-прошлом, и нет никакой гарантии, что впредь ничего
похожего больше не произойдет.
|