Установка и использование OpenMPI

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

В принципе, это не сложно:
1. Берем OpenMPI с http://www.open-mpi.org/
2. Для компиляции потребуется CMake - качается с cmake.org. Заморачиваться со сборками не стоит, сразу берем версию с GUI.
3.Разбираемся с CMake. Все, что мне пришлось сделать - нажать на Configure и сказать, какая версия Visual Studio у меня стоит, CMake сама ее нашла и прописала себе все пути. Также нужно указать, где лежат сорцы - это [путь к папке, куда скачали архив с openmpi]/openmpi-1.4.2 (кстати, вот этот момент не очень четко описан в документации).
4. Дальше компиляция - надо получить Visual Studio solution, в котором в районе 10 проектов. Занимает это в районе получаса (ну, чай попить точно успеешь).
5. Получили solution, открываем его в VS, делаем build. В Debug (я дебаг-версию делал)
создается куча файлов.

Все, OpenMPI готов к употреблению.

Что теперь, как на создавать MPI-приложения? Понятное дело, нужно инклюдить mpi.h. Он есть в поставке OpenMPI, нужно только переложить его туда, где Студия его увидит.
Еще я прикомпилил libmpid.dll (d в конце - от debug, сделал бы release - было б просто
libmpi.dll) и libmpi_cxxd.dll (возможна, последняя и не нужна или нужна в особых случаях - вроде, символы из нее не грузятся). Делается это путем включения в проект соответствующих экспортных lib.

Все, собрали свой проект - например, test.

Дальше можно сделать так - положить готовый test.exe в отдельную папку. Там же должны находиться: mpirun.exe, libmpid.dll, libopen_pald.dll, libopen_rted.dll (я еще соответствующие lib положил, но, видимо, и без них можно). Запускать так: mpirun test.exe.

Пока не решил проблему отсутствия хелпа. Например, если написать просто test, то mpirun его не найдет и напишет:

Sorry! You were supposed to get help about:
orterun:exe-not-found
But I couldn't open the help file:
[путь]\openmpi-1.4.2\installed\share\openmpi\help-
orterun.txt: No such file or directory. Sorry!

Вот такой он вежливый. А хелп куда дел?

INUIT - читать

Весьма продвинутый курс по ЧМ в матфизе - Лобанов, Петров Численные методы решения уравнений в частных производных.

Шпаргалка по Makefile

Трудное это дело - писать makefile-ы) Своеобразная у них логика.

В очередном блоге нашел Шпаргалку по Makefile. Болей-менее исчерпывающая информация, но примеры можно было написать покомпактнее - не до конца еще автор прочухал всю глубину языка makefile-ов.

MPICH и один блог

Нашел тут интересный блог некоего Сухинова из ИММ - iproc.ru. Посвящен он обработке изображений, но там много статей и на другие темы - параллельное программирование, гидродинамика.

Особенно мне близки:
MPICH и Windows
Измерение интервалов времени в Windows
История гидродинамики.

Data breakpoints и debug modes

Data breakpoint - это когда прерывание происходит при изменении данных по определенному адресу. В Visual Studio: Debug->New Breakpoint->Set data breakpoint.

Может оказаться, что эта опция отключена. Работает она только в native debug mode (в mixed и managed режимах - не работает). Режимы отладки переключаются в свойствах проекта, ветка Debugging (сразу под General).

У меня даже после перехода в нативный режим пункт Set data breakpoint не включился. Пришлось сделать так: поставить бряк в самом начале main. Непонятно почему, но полсе этой остановки появилась возможность ставить data breakpoint.

(to be continued. maybe.)

MPI

Стандарт MPI - здесь.

Еще один учебник - MPI для начинающих

Аккуратно оформленный список MPI функций - на сайте DeinoMPI ("The Great and Terrible implementation of MPI-2").

Production quality code

Переведем это как "код, имеющий товарный вид".

Как определить, что программа готова к передаче заказчикам? В интернете нашел следующий список требований:

Design

* Design documents are readily available and organized for easy access
* All functionality is specified to an appropriate amount of detail
* Presentation, Business Logic, and Data have been abstracted (ie. Three tier architecture)
* Code is well-documented such that it explains all functionality and facilitates maintenance
* An effective test strategy/plan exists

Implementation

* The application does what it was intended to do
* Modules pass unit tests
* Log messages provide accurate portrayal of runtime and facilitate debugging
* Errors have been handled effectively
* Configuration variables have been abstracted into a sane configuration scheme
* Code meets the benchmark criteria
* Resource utilization is sane
* Test plan has been executed and application has been accepted

Deployment

* Code/documentation has undergone peer review
* Interagency coordination (ie. "one-hand knows what the other is doing")
* A rollback plan exists
* Deployment recipe exists

А бывалые прогеры говорят проще:
When the amount of flak the project manager is getting over late delivery exceeds the amount of flak he expects over the bugs remaining in the software, then the software is ready for deployment.
(Когда втык, получаемый менеджером проекта за невыполнение работы в срок, становится сильнее втыка за невыловленные баги - программа готова к внедрению)