Комментарии 29
Пожалуй, достаточно рациональным решением является запись результата в файл
Замечу, что обращение к файлам рекомендуется делать только на одной ноде — стартовой, чтобы избежать проблем с синхронизацией доступа и необходимости использования общей файловой системы.
+3
На всех не-игрушечных кластерах есть общая ФС.
+2
Это-то естественно, но вот с блокировками и буферизацией всё равно как-то интимиться не охото. Особенно — для вывода результатов.
Если ФС общая — либо каждая нода пишет в свой файл, которые потом сливает стартовый, либо просто reduce'ится всё на стартовую ноду которая уже и печатает вывод.
Кстати да, на тему игрушечности и OpenMPI — гонять OpenMPI в распределённой системе (то есть не в LAN) я бы не стал. Жручий он до траффика…
Если ФС общая — либо каждая нода пишет в свой файл, которые потом сливает стартовый, либо просто reduce'ится всё на стартовую ноду которая уже и печатает вывод.
Кстати да, на тему игрушечности и OpenMPI — гонять OpenMPI в распределённой системе (то есть не в LAN) я бы не стал. Жручий он до траффика…
+1
OpenMPI и MPI вообще тут не при чём. Для большинства задач очень важно latency. Даже IB не всегда спасает, некоторые вещи быстрее последовательно, чем параллельно в сети.
+1
+1, для MPI latency критичен. Как правило в больших кластерах такие задачи запускаются на физически близких рэках.
+2
Естественно, что решать всегда имеет смысл только тогда, когда время на передачу задания и результат меньше времени вычисления.
Те же bitcoin прекрасно распределяются на мощные удалённые вообще на JSON :D
Просто когда нужно что-то считать, если берётся OpenMPI уже подразумеваются немелкие передачи данных и очень шустрая связка внутри кластера…
Те же bitcoin прекрасно распределяются на мощные удалённые вообще на JSON :D
Просто когда нужно что-то считать, если берётся OpenMPI уже подразумеваются немелкие передачи данных и очень шустрая связка внутри кластера…
0
> направление это на сегодняшний день является весьма перспективным
В каких областях это перспективно? В вычислительной гидродинамике?
В каких областях это перспективно? В вычислительной гидродинамике?
-3
в любых местах где требуются вычислительные мощности. CUDA хорошо, но 100 машин с CUDA в 100 раз лучше :)
+1
а чем вам не угодила вычислительная гидродинамика? ;)
Кроме того, целый спектр задач имеющих крайне важное прикладное значение решается именно при помощи MPI (поскольку технологии вроде Map/Reduce не применимы) – например, Kernel PCA, который часто требует применения метода Арнольди.
Кроме того, целый спектр задач имеющих крайне важное прикладное значение решается именно при помощи MPI (поскольку технологии вроде Map/Reduce не применимы) – например, Kernel PCA, который часто требует применения метода Арнольди.
+3
> а чем вам не угодила вычислительная гидродинамика? ;)
Всем угодила.
Просто говорят про то, что перспективно, а на деле оказывается, что кроме ученых это никому не нужно.
Вот и хочется выяснить, где это востребованно.
Всем угодила.
Просто говорят про то, что перспективно, а на деле оказывается, что кроме ученых это никому не нужно.
Вот и хочется выяснить, где это востребованно.
-3
Мне же действительно интересно, т.к. я невежественен в данном вопросе.
На hh.ru поискал по запросу «MPI» — только 7 вакансий нашел.
На hh.ru поискал по запросу «MPI» — только 7 вакансий нашел.
-1
> что кроме ученых это никому не нужно
Вот и производят в России тазики под маркой ВАЗиков. И так далее, список длинный. Потому что ученые в одном мире, а производство в другом.
Все проблемы реального производства расчитываются с помощью методов конечных элементов, конечных объемов и т.д. И это все великолепно параллелится. А дальше — задачи логистики, метеорологии, бирж сырья и энергоносителей, оценка рисков. И тоже — куча методов распараллеливания. Открытого знания MPI или OpenMP обычно не требуют. Выучить — пара пустяков (правда заставить себя мыслить «на несколько потоков» задача не тривиальная).
Вот и производят в России тазики под маркой ВАЗиков. И так далее, список длинный. Потому что ученые в одном мире, а производство в другом.
Все проблемы реального производства расчитываются с помощью методов конечных элементов, конечных объемов и т.д. И это все великолепно параллелится. А дальше — задачи логистики, метеорологии, бирж сырья и энергоносителей, оценка рисков. И тоже — куча методов распараллеливания. Открытого знания MPI или OpenMP обычно не требуют. Выучить — пара пустяков (правда заставить себя мыслить «на несколько потоков» задача не тривиальная).
+1
… раз уж начал ;) к примеру, вот здесь: www.scribd.com/fullscreen/6962906?access_key=key-104xd9j4q52y3i7uqtgj — начиная со страницы 608 и далее. Очень даже перспективная область, чесслово ;)
+1
Скажем так. Это является перспективным во всем научном мире. Тысячи исследовательских институтов, центров и тому подобных организаций используют технологии параллелизации. К сожалению в России дела с наукой обстоят не так радужно, как например в Европе, где только ленивый технический ВУЗ не построил себе кластерок для вычислений. Поэтому вам и кажется, что данные технологии не являются перспективными и популярными. Я осознала масштаб только тогда, когда сама столкнулась непосредственно. Не недооценивайте такие вещи. Наука — это будущее.
+1
Ну и для наглядности можно добавить в статью картинки, демонстрирующие работу MPI_Bcast и MPI_Reduce;
и время расчётов обычной и распараллеленной программы.
и время расчётов обычной и распараллеленной программы.
+1
На каждой итерации считать факториал заново??? Для начала над кодом надо чуточку задуматься, а потом уже параллельные вычисления для быстроты использовать. Слегка оптимизированный код на одном процессоре вычислится гораздо быстрее чем этот на десяти.
-2
Как уже говорилось — пример сугубо учебный и на использование, к примеру, в суперкомпьютерах, разумеется, не претендует.
Если использовать последовательное вычисление факториала на основе прошлых расчетов, то распараллеливания достичь будет просто нереально — один процессор не сможет считать частное, пока не дождется значения факториала от другого процессора и получится тоже самое последовательное вычисление, но только с толикой извращения.
Я не спорю, быть может благодаря единому хранящемуся и используемому значению факториала на одном компьютере с последовательным алгоритмом, подсчитать выйдет даже быстрее (хотя и тут есть место для споров), однако данный пример в первую очередь показывает, что и не все методы распараллеливания одинаково полезны
Если использовать последовательное вычисление факториала на основе прошлых расчетов, то распараллеливания достичь будет просто нереально — один процессор не сможет считать частное, пока не дождется значения факториала от другого процессора и получится тоже самое последовательное вычисление, но только с толикой извращения.
Я не спорю, быть может благодаря единому хранящемуся и используемому значению факториала на одном компьютере с последовательным алгоритмом, подсчитать выйдет даже быстрее (хотя и тут есть место для споров), однако данный пример в первую очередь показывает, что и не все методы распараллеливания одинаково полезны
0
Читайте комментарий от Moric. Он все правильно написал. И факториал быстрее считается, и параллелизация сохраняется. А то что вы тут в качестве аргументов приводите — простите, бред.
0
Да у вас MPI будет дольше инициализироваться, чем задача считаться. Так что даже места для споров нет, этот код кроме как концептуально «независимые вещи можно считать параллельно» не показывает.
0
OMG. И какое ускорение тут будет?
Fact(int n) в рекурсию и на каждом шаге пересчитывать? Это будет очень долго.
Наверное стоит сделать так:
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
И еще. Строчка лишняя:
Аргументы и так передадуться всем процессам. Но в общем случае, например когда n вводится с клавиатуры, это было бы верно.
MPI_Bcast(&n, 1, MPI_INT, 0, MPI_COMM_WORLD);
Аргументы и так передадуться всем процессам. Но в общем случае, например когда n вводится с клавиатуры, это было бы верно.
+1
Спасибо, Вы правы, изначально значение n в программме как раз и вводилось вручную, однако потом код был отредактирован под внешнюю оболочку.
Однако смею все же предположить, что в некоторых многопроцесорных архитектурах аргументы из внешней среды могут передаваться сугубо первому процессору и их рассылка остальным лежит сугубо на его плечах. Я могу и ошибаться, но все же мне кажется такие реализации имеют место быть, пускай и не повсеместно
Однако смею все же предположить, что в некоторых многопроцесорных архитектурах аргументы из внешней среды могут передаваться сугубо первому процессору и их рассылка остальным лежит сугубо на его плечах. Я могу и ошибаться, но все же мне кажется такие реализации имеют место быть, пускай и не повсеместно
-1
if (rc= MPI_Init(&argc, &argv))
{
cout << "Ошибка запуска, выполнение остановлено " << endl;
MPI_Abort(MPI_COMM_WORLD, rc);
}
сомнительной полезности условие, так как по умолчанию установлен флаг MPI_ERRORS_ARE_FATAL, т.е. любая ошибка MPI, будь то во время инициализации или передачи данных, ведёт к останову программы на всех узлах.
+2
Мда…
Пример — гавно.
Насколько будут сбалансированы вычисления?
Первый ранк отсчитает очень быстро. Факториалы короткие будут.
Последний будет считать дольше всех.
Короче эффективность использования ресурсов — примерно 50%.
Пример — гавно.
Насколько будут сбалансированы вычисления?
Первый ранк отсчитает очень быстро. Факториалы короткие будут.
Последний будет считать дольше всех.
Короче эффективность использования ресурсов — примерно 50%.
0
а я, как обычно, придерусь к коду.
читать очень трудно, можно же было отформатировать нормально?
не говоря уж о Си-style объявлении переменных со странными именами одним блоком и отсутствии комментов.
читать очень трудно, можно же было отформатировать нормально?
не говоря уж о Си-style объявлении переменных со странными именами одним блоком и отсутствии комментов.
+1
Как практик скажу, весь текст статьи можно заменить словами, «сущевствует MPI, если интересно что это прочитайте книгу». В моем понимании все таки польза от mpi именно при распределенных вычислениях, а не при параллельных.
+3
Спасибо за труд, но практической пользы от него не много, т.к. не рассматриваются парадигмы параллельного программирования, а берется откуда-то MPI. Поскольку статья эта вводная, то необходимо введение в предметную область. И вообще надо как-то обосновывать решение. Было бы интересно почитать об основании в выборе инструмента. А так не о чем. Но в любом случае, успехов в работе.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы MPI для «чайников»