Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 29

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


Замечу, что обращение к файлам рекомендуется делать только на одной ноде — стартовой, чтобы избежать проблем с синхронизацией доступа и необходимости использования общей файловой системы.
Всего голосов 5: ↑4 и ↓1+3
На всех не-игрушечных кластерах есть общая ФС.
Всего голосов 4: ↑3 и ↓1+2
Это-то естественно, но вот с блокировками и буферизацией всё равно как-то интимиться не охото. Особенно — для вывода результатов.
Если ФС общая — либо каждая нода пишет в свой файл, которые потом сливает стартовый, либо просто reduce'ится всё на стартовую ноду которая уже и печатает вывод.

Кстати да, на тему игрушечности и OpenMPI — гонять OpenMPI в распределённой системе (то есть не в LAN) я бы не стал. Жручий он до траффика…
Всего голосов 1: ↑1 и ↓0+1
OpenMPI и MPI вообще тут не при чём. Для большинства задач очень важно latency. Даже IB не всегда спасает, некоторые вещи быстрее последовательно, чем параллельно в сети.
Всего голосов 1: ↑1 и ↓0+1
+1, для MPI latency критичен. Как правило в больших кластерах такие задачи запускаются на физически близких рэках.
Всего голосов 2: ↑2 и ↓0+2
Естественно, что решать всегда имеет смысл только тогда, когда время на передачу задания и результат меньше времени вычисления.
Те же bitcoin прекрасно распределяются на мощные удалённые вообще на JSON :D

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

В каких областях это перспективно? В вычислительной гидродинамике?
Всего голосов 5: ↑1 и ↓4-3
в любых местах где требуются вычислительные мощности. CUDA хорошо, но 100 машин с CUDA в 100 раз лучше :)
Всего голосов 3: ↑2 и ↓1+1
а чем вам не угодила вычислительная гидродинамика? ;)

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

Всем угодила.
Просто говорят про то, что перспективно, а на деле оказывается, что кроме ученых это никому не нужно.
Вот и хочется выяснить, где это востребованно.
Всего голосов 3: ↑0 и ↓3-3
Мне же действительно интересно, т.к. я невежественен в данном вопросе.
На hh.ru поискал по запросу «MPI» — только 7 вакансий нашел.
Всего голосов 1: ↑0 и ↓1-1
> что кроме ученых это никому не нужно
Вот и производят в России тазики под маркой ВАЗиков. И так далее, список длинный. Потому что ученые в одном мире, а производство в другом.
Все проблемы реального производства расчитываются с помощью методов конечных элементов, конечных объемов и т.д. И это все великолепно параллелится. А дальше — задачи логистики, метеорологии, бирж сырья и энергоносителей, оценка рисков. И тоже — куча методов распараллеливания. Открытого знания MPI или OpenMP обычно не требуют. Выучить — пара пустяков (правда заставить себя мыслить «на несколько потоков» задача не тривиальная).
Всего голосов 1: ↑1 и ↓0+1
Скажем так. Это является перспективным во всем научном мире. Тысячи исследовательских институтов, центров и тому подобных организаций используют технологии параллелизации. К сожалению в России дела с наукой обстоят не так радужно, как например в Европе, где только ленивый технический ВУЗ не построил себе кластерок для вычислений. Поэтому вам и кажется, что данные технологии не являются перспективными и популярными. Я осознала масштаб только тогда, когда сама столкнулась непосредственно. Не недооценивайте такие вещи. Наука — это будущее.
Всего голосов 1: ↑1 и ↓0+1
Ну и для наглядности можно добавить в статью картинки, демонстрирующие работу MPI_Bcast и MPI_Reduce;
и время расчётов обычной и распараллеленной программы.
Всего голосов 1: ↑1 и ↓0+1
На каждой итерации считать факториал заново??? Для начала над кодом надо чуточку задуматься, а потом уже параллельные вычисления для быстроты использовать. Слегка оптимизированный код на одном процессоре вычислится гораздо быстрее чем этот на десяти.
Всего голосов 4: ↑1 и ↓3-2
Как уже говорилось — пример сугубо учебный и на использование, к примеру, в суперкомпьютерах, разумеется, не претендует.
Если использовать последовательное вычисление факториала на основе прошлых расчетов, то распараллеливания достичь будет просто нереально — один процессор не сможет считать частное, пока не дождется значения факториала от другого процессора и получится тоже самое последовательное вычисление, но только с толикой извращения.
Я не спорю, быть может благодаря единому хранящемуся и используемому значению факториала на одном компьютере с последовательным алгоритмом, подсчитать выйдет даже быстрее (хотя и тут есть место для споров), однако данный пример в первую очередь показывает, что и не все методы распараллеливания одинаково полезны
Всего голосов 2: ↑1 и ↓10
Читайте комментарий от Moric. Он все правильно написал. И факториал быстрее считается, и параллелизация сохраняется. А то что вы тут в качестве аргументов приводите — простите, бред.
Всего голосов 2: ↑1 и ↓10
Да у вас MPI будет дольше инициализироваться, чем задача считаться. Так что даже места для споров нет, этот код кроме как концептуально «независимые вещи можно считать параллельно» не показывает.
Комментарий пока не оценивали0
Сработало старое правило: если материал из разряда «для чайников», то писать его должен как минимум не чайник. Вот из-за этого и статья не вышла.
Всего голосов 3: ↑2 и ↓1+1
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;
  }
Всего голосов 2: ↑2 и ↓0+2
И еще. Строчка лишняя: 
MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);

Аргументы и так передадуться всем процессам. Но в общем случае, например когда n вводится с клавиатуры, это было бы верно.
Всего голосов 1: ↑1 и ↓0+1
Спасибо, Вы правы, изначально значение n в программме как раз и вводилось вручную, однако потом код был отредактирован под внешнюю оболочку.
Однако смею все же предположить, что в некоторых многопроцесорных архитектурах аргументы из внешней среды могут передаваться сугубо первому процессору и их рассылка остальным лежит сугубо на его плечах. Я могу и ошибаться, но все же мне кажется такие реализации имеют место быть, пускай и не повсеместно
Всего голосов 3: ↑1 и ↓2-1
При чём тут архитектура вычислительной системы к конкретной библиотеке передачи сообщений?
Всего голосов 3: ↑2 и ↓1+1
if (rc= MPI_Init(&argc, &argv))
{
cout << "Ошибка запуска, выполнение остановлено " << endl;
MPI_Abort(MPI_COMM_WORLD, rc);
}

сомнительной полезности условие, так как по умолчанию установлен флаг MPI_ERRORS_ARE_FATAL, т.е. любая ошибка MPI, будь то во время инициализации или передачи данных, ведёт к останову программы на всех узлах.
Всего голосов 2: ↑2 и ↓0+2
Мда…
Пример — гавно.
Насколько будут сбалансированы вычисления?
Первый ранк отсчитает очень быстро. Факториалы короткие будут.
Последний будет считать дольше всех.
Короче эффективность использования ресурсов — примерно 50%.
Всего голосов 2: ↑1 и ↓10
а я, как обычно, придерусь к коду.
читать очень трудно, можно же было отформатировать нормально?
не говоря уж о Си-style объявлении переменных со странными именами одним блоком и отсутствии комментов.
Всего голосов 1: ↑1 и ↓0+1
Как практик скажу, весь текст статьи можно заменить словами, «сущевствует MPI, если интересно что это прочитайте книгу». В моем понимании все таки польза от mpi именно при распределенных вычислениях, а не при параллельных.
Всего голосов 3: ↑3 и ↓0+3
Спасибо за труд, но практической пользы от него не много, т.к. не рассматриваются парадигмы параллельного программирования, а берется откуда-то MPI. Поскольку статья эта вводная, то необходимо введение в предметную область. И вообще надо как-то обосновывать решение. Было бы интересно почитать об основании в выборе инструмента. А так не о чем. Но в любом случае, успехов в работе.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr