Основы MPI для «чайников»

[datacompboy]

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

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

[gribozavr]

На всех не-игрушечных кластерах есть общая ФС.

[datacompboy]

Это-то естественно, но вот с блокировками и буферизацией всё равно как-то интимиться не охото. Особенно — для вывода результатов.
Если ФС общая — либо каждая нода пишет в свой файл, которые потом сливает стартовый, либо просто reduce'ится всё на стартовую ноду которая уже и печатает вывод.

Кстати да, на тему игрушечности и OpenMPI — гонять OpenMPI в распределённой системе (то есть не в LAN) я бы не стал. Жручий он до траффика…

[gribozavr]

OpenMPI и MPI вообще тут не при чём. Для большинства задач очень важно latency. Даже IB не всегда спасает, некоторые вещи быстрее последовательно, чем параллельно в сети.

[sgzmd]

+1, для MPI latency критичен. Как правило в больших кластерах такие задачи запускаются на физически близких рэках.

[datacompboy]

Естественно, что решать всегда имеет смысл только тогда, когда время на передачу задания и результат меньше времени вычисления.
Те же bitcoin прекрасно распределяются на мощные удалённые вообще на JSON :D

Просто когда нужно что-то считать, если берётся OpenMPI уже подразумеваются немелкие передачи данных и очень шустрая связка внутри кластера…

[professor_kuvalda]

> направление это на сегодняшний день является весьма перспективным

В каких областях это перспективно? В вычислительной гидродинамике?

[datacompboy]

в любых местах где требуются вычислительные мощности. CUDA хорошо, но 100 машин с CUDA в 100 раз лучше :)

[sgzmd]

а чем вам не угодила вычислительная гидродинамика? ;)

Кроме того, целый спектр задач имеющих крайне важное прикладное значение решается именно при помощи MPI (поскольку технологии вроде Map/Reduce не применимы) – например, Kernel PCA, который часто требует применения метода Арнольди.

[professor_kuvalda]

> а чем вам не угодила вычислительная гидродинамика? ;)

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

[professor_kuvalda]

Мне же действительно интересно, т.к. я невежественен в данном вопросе.
На hh.ru поискал по запросу «MPI» — только 7 вакансий нашел.

[futureader]

> что кроме ученых это никому не нужно
Вот и производят в России тазики под маркой ВАЗиков. И так далее, список длинный. Потому что ученые в одном мире, а производство в другом.
Все проблемы реального производства расчитываются с помощью методов конечных элементов, конечных объемов и т.д. И это все великолепно параллелится. А дальше — задачи логистики, метеорологии, бирж сырья и энергоносителей, оценка рисков. И тоже — куча методов распараллеливания. Открытого знания MPI или OpenMP обычно не требуют. Выучить — пара пустяков (правда заставить себя мыслить «на несколько потоков» задача не тривиальная).

[sgzmd]

… раз уж начал ;) к примеру, вот здесь: www.scribd.com/fullscreen/6962906?access_key=key-104xd9j4q52y3i7uqtgj — начиная со страницы 608 и далее. Очень даже перспективная область, чесслово ;)

[nixby]

Скажем так. Это является перспективным во всем научном мире. Тысячи исследовательских институтов, центров и тому подобных организаций используют технологии параллелизации. К сожалению в России дела с наукой обстоят не так радужно, как например в Европе, где только ленивый технический ВУЗ не построил себе кластерок для вычислений. Поэтому вам и кажется, что данные технологии не являются перспективными и популярными. Я осознала масштаб только тогда, когда сама столкнулась непосредственно. Не недооценивайте такие вещи. Наука — это будущее.

[KEPZ]

Ну и для наглядности можно добавить в статью картинки, демонстрирующие работу MPI_Bcast и MPI_Reduce;
и время расчётов обычной и распараллеленной программы.

[WhiteD]

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

[XFactor]

Как уже говорилось — пример сугубо учебный и на использование, к примеру, в суперкомпьютерах, разумеется, не претендует.
Если использовать последовательное вычисление факториала на основе прошлых расчетов, то распараллеливания достичь будет просто нереально — один процессор не сможет считать частное, пока не дождется значения факториала от другого процессора и получится тоже самое последовательное вычисление, но только с толикой извращения.
Я не спорю, быть может благодаря единому хранящемуся и используемому значению факториала на одном компьютере с последовательным алгоритмом, подсчитать выйдет даже быстрее (хотя и тут есть место для споров), однако данный пример в первую очередь показывает, что и не все методы распараллеливания одинаково полезны

[WhiteD]

Читайте комментарий от Moric. Он все правильно написал. И факториал быстрее считается, и параллелизация сохраняется. А то что вы тут в качестве аргументов приводите — простите, бред.

[gribozavr]

Да у вас MPI будет дольше инициализироваться, чем задача считаться. Так что даже места для споров нет, этот код кроме как концептуально «независимые вещи можно считать параллельно» не показывает.

[WhiteD]

Сработало старое правило: если материал из разряда «для чайников», то писать его должен как минимум не чайник. Вот из-за этого и статья не вышла.

[Moric]

OMG. И какое ускорение тут будет?
Fact(int n) в рекурсию и на каждом шаге пересчитывать? Это будет очень долго.

Наверное стоит сделать так:

fact=1;for(j=2;j<myid;j++)fact*=j;
  for (i = myid; i <= n; i += numprocs)
  { 
    drob = 1/fact;
    for(j=i;j<i+n;j++)fact*=j;
    drobSum += drob;
  }

[Moric]

И еще. Строчка лишняя:

MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);

Аргументы и так передадуться всем процессам. Но в общем случае, например когда n вводится с клавиатуры, это было бы верно.

[XFactor]

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

[gribozavr]

При чём тут архитектура вычислительной системы к конкретной библиотеке передачи сообщений?

[ftynse]

if (rc= MPI_Init(&argc, &argv))
{
cout << "Ошибка запуска, выполнение остановлено " << endl;
MPI_Abort(MPI_COMM_WORLD, rc);
}

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

[DustCn]

Мда…
Пример — гавно.
Насколько будут сбалансированы вычисления?
Первый ранк отсчитает очень быстро. Факториалы короткие будут.
Последний будет считать дольше всех.
Короче эффективность использования ресурсов — примерно 50%.

[mark_ablov]

а я, как обычно, придерусь к коду.
читать очень трудно, можно же было отформатировать нормально?
не говоря уж о Си-style объявлении переменных со странными именами одним блоком и отсутствии комментов.

[AlanKochev]

Как практик скажу, весь текст статьи можно заменить словами, «сущевствует MPI, если интересно что это прочитайте книгу». В моем понимании все таки польза от mpi именно при распределенных вычислениях, а не при параллельных.

[Tthread]

Спасибо за труд, но практической пользы от него не много, т.к. не рассматриваются парадигмы параллельного программирования, а берется откуда-то MPI. Поскольку статья эта вводная, то необходимо введение в предметную область. И вообще надо как-то обосновывать решение. Было бы интересно почитать об основании в выборе инструмента. А так не о чем. Но в любом случае, успехов в работе.