Памятка пользователя

[ Автор: Илья Евсеев ]
[ Организация: ИВВиБД ]
[ Подразделение: ЦСТ ]

Оглавление

• Общие правила
  • Утилиты построения и запуска MPI-приложений
  • Документация
  • Отладка MPI-приложений обычным отладчиком
  • Объединение в кластеры

• MPICH: базовая реализация
  • Документация и подсказки
  • Профилирование: PMPI, Jumpshot
  • Отладка
  • Объединение нескольких машин через P4
  • Реализации, производные от MPICH

• MPI на ЭВМ SPP
  • Запуск
  • Отладка
  • Подсказки и документация
  • Профилирование
  • Почему на SPP не рекомендуется работать с MPI

• WinMPICH: устаревшая реализация для Windows
  • Использование отладочного варианта
  • Недостатки

• WMPI: еще одна реализация MPICH для Windows
  • Недостатки
  • Достоинства
  • Документация и подсказки
  • Построение программ
  • Запуск
  • Отладка
  • Профилирование

• PowerMPI для ЭВМ Parsytec
  • Что будет при попытке использовать MPICH вместо PowerMPI ?

• Версии документа

Общие правила

Здесь перечислены правила, в той или иной степени применимые к большинству реализаций 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=путь_к_MPIbin;%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

Дополнительные ключи, не передаваемые компилятору, а обрабатываемые самим командным файлом, в спецификации не оговорены, но возможны. Например, в MPICH ключ -echo включает трассировку выполнения командного файла, полезную для поиска ошибок в инсталляции сопутствующего мат.обеспечения. У большинства утилит для вывода подсказки служит ключ -help.

Загрузчик MPI-приложений называется mpirun. У него ключей много разных и всяких, но только один из них является обязательным (-np = number of processes):

    mpirun -np N [mpirun_args] program_file [command_line_args ...]

    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 доступна для Вас двумя способами:

• Manual pages через интерфейс man2html (не рекомендуется),
• непосредственно в виде HTML-страниц

Более детальную информацию, как-то: спецификацию, учебники и различные реализации MPI можно найти на сервере NetLib. Первоисточником для данного пособия является книга "MPI: The complete reference" издательства MIT Press - Вы найдете ее на этом сервере.

Отладка MPI-приложений обычным отладчиком

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

Отладка ветви, запускаемой непосредственно из mpirun (в большинстве реализаций так запускается только ветвь 0):

• если mpirun в данной реализации не требуется:
• если mpirun позволяет запустить ветвь 0 под отладчиком:

  нет проблем, запускайте и отлаживайте.

• ... если ни то, ни другое:
  

  тяжелый случай...
  Можно попробовать поместить MPI_Init() в следующее окружение:

  /* в зависимости от реализации MPI,
   * прочие ветви в этот момент могут быть еще не запущены
   */
  MPI_Init( &argc, &argv );
  /* здесь уже все ветви заведомо запущены
   */
  MPI_Comm_size( MPI_COMM_WORLD, &commSize );
  MPI_Comm_rank( MPI_COMM_WORLD, &myRank );
  
  printf("Rank=%d, PID=0x%Xn", myRank, getpid() );
  if( myRank==0 )
  {
      puts("MPI_Init ok, press any key...");
      getch();     /* ветвь 0 остановится здесь */
  }
  MPI_Barrier( MPI_COMM_WORLD );  /*остальные ветви остановятся здесь*/
  

  Дождавшись после после запуска приложения появления указанной надписи, следует "подцепить" (attach) предварительно запущенный отладчик (отладчики) к избранной ветви (ветвям).

• если реализация позволяет ручной запуск ведомых ветвей:
  Как правило, это означает, что вместо команды запуска ветвей будут не выполнены, а выведены на консоль. После этого пользователь должен запустить их сам, и при этом имеет возможность любую из них запустить под отладчиком.

• ... если не позволяет:
  См. выше описание "тяжелого случая". Поскольку ветвь 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 и т.д.)
• полностью реализует все заложенные в спецификацию возможности.

    ./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

Документация и подсказки

Профилирование: 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

Последовательность действий следующая:

1. при конфигурировании MPICH (перед построением) должно быть выбрано "устройство P4":

       ./configure -device=ch_p4 -comm=shared

2. в каталоге .../mpich/util/machines, согласно находящемуся там README-файлу, должны быть созданы текстовые файлы с именами вида machines.<ARCH>, каждый из которых содержит адреса всех машин данной архитектуры.
3. на всех ведомых машинах должен быть настроен сервис "remote shell":
   1. имя протокола для порта 514 прописано в файле /etc/services,
   2. то же самое имя вместе с именем демона rshd прописано в файле /etc/inetd.conf,
   3. имя ведущей машины прописано в файле .rhosts в домашнем каталоге пользователя, или в /etc/hosts.equiv
4. на ведущей машине должен иметься клиент "remote shell".

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

Реализации, производные от MPICH

Коммерческие реализации выпускаются производителями ЭВМ. Как правило, они напрямую основаны на MPICH, поэтому повторяют его не только вследствие стандарта, но и во многих технических мелочах. Отличия могут заключаться в:

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

Большинство 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

Полезные дополнительные утилиты, в MPICH отсутствующие (подробности - в ManPages, или при запуске с ключом -help):

• mpijob - выводит информацию о запущенных MPI-приложениях, запущенных как на локальной машине, так и на HPMPI-кластере. Аналогична команде Юникса jobs.

• mpiclean - уничтожает MPI-приложение, действует наподобие команды kill. Идентификаторы приложений выдает команда mpijob. Ключ -m служит для освобождения "подвисшей" разделяемой памяти.

• xmpi - графический загрузчик и монитор:

Отладка

MPI-приложение под CXdb запускается так: все аргументы mpirun записываются в отдельный файл, назовем его mpi_ex0.cmd:

    -np 4 ./mpi_ex0

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-приложениями. Я с ним не работал.

Допустим следующий способ профилирования:

1. mpirun запускается с ключом -t:

       mpirun -np 4 -t mystatfile program_name [program_args...]

   каждая ветвь в ходе выполнения будет писать статистику в свой файл, имена всех файлов будут иметь общий префикс mystat и расширение .tr

2. созданный двоичный файл с расширением .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
          ---------------------------------------------------------
   

3. Несколько .tr-файлов могут быть объединены в один утилитой mpitrget. Предполагается, что таким образом файлы ветвей будут объединяться в единый файл-отчет приложения.

4. Запись статистики можно включать и отключать программно вызовами функций MPIHP_Trace_on() и MPIHP_Trace_off(). Запуск с первоначально отключенной статистикой делается так:

       mpirun -np 4 -t mystatfile:off program_name [program_args...]

   Собираемая статистика предназначена исключительно для профилирования MPI, а не пользовательской части приложения:
   • сколько вызовов MPI-подпрограмм было сделано за время трассировки,
   • сколько времени потрачено в процентном/абсолютном отношении,
   • какое количество времени ушло на ожидания при приемопередачах,
   • и какая его доля при этом не была использована приложением, и т.д.

   Почему на SPP не рекомендуется работать с MPI

   Основных причин - три:

   1. С 1996 года процессор PA-RISC 7200 успел морально устареть, и производительность SPP на фоне современных ЭВМ довольно невелика.

   2. На ЭВМ с общей памятью, какой является SPP, MPI по скорости работы проигрывает программам, использующим общую память, семафоры и многопоточность.

   3. На ЭВМ с оптимизирующими распараллеливающими компиляторами, какой опять-таки является SPP, MPI проигрывает традиционному программированию по скорости разработки приложения, поскольку требует явного ручного распараллеливания, с сомнительным выигрышем по скорости выполнения (см.пред.пункт).

   По-видимому, наилучшим стало бы такое разделение обязанностей:

   • на SPP производится отладка и (частично) профилирование; для этого на SPP имеется удобный отладчик, а кроме того, большое ОЗУ, большой жесткий диск, качественное "железо" и надежное программное обеспечение,
   • затем приложение MPI переносится на более быстрый, но менее оснащенный мат.обеспечением компьютер, где после минимальных исправлений запускается в рабочем режиме.

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

    
   

   ---

   WinMPICH: устаревшая реализация для Windows

   Свои первые примеры на MPI я писал, используя пакет WinMPICH 0.92b и Microsoft Visual C++ 4.0. Все работает нормально. К примерам прилагается make-сценарий.

   WinMPICH скомпилирован в отладочном режиме, а именно...

   • На экране регулярно будут появляться окна наподобие этого:

     

     Выбирайте "Ignore" ( "Пропустить" ).

   • Отладочному варианту для работы требуются две дополнительных динамических библиотеки, доступных через PATH. Скачайте их со страницы WinMPICH, поместите в его BIN-директорию, и добавьте C:WinMPICHbin в переменную окружения 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 подробно указаны все изменения, которые требуется внести в проект по умолчанию.

   Вниманию фанатов командной строки предлагается пример mpicc.bat для построения консольных WMPI-приложений.

   Запуск

   Построенный EXE-файл запускается без всяких загрузчиков.

   Он требует для работы динамическую библиотеку CVWMPI.DLL (если программа консольная) или VWMPI.DLL (если она графическая). Соответственно, Вам требуется либо вписать каталог с DLL в переменную окружения PATH, либо скопировать DLL в...:

   1. The directory from which the application loaded.
   2. The current directory.
   3. 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.
   4. 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.
   5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
   6. 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 filesWMPI_1.2LibConsole;%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/home/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

   Предлагаемые здесь варианты mpicc/mpif77 и mpirun я написал, чтобы иметь меньше возни с: а) переносом готовых MPI-приложений на Парситек; б) пересаживанием закоренелых MPI-пользоватетелей на него же. Для размещения сценариев в каталоге с 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 посвежее, уже имели место в-прошлом, и нет никакой гарантии, что впредь ничего похожего больше не произойдет.