Распараллелить задачу

Aiwazovsky

Может кто сможет подсказать следующее...
Вопрос: есть ли способ распараллелить некоторую рассчетную задачу на пару компов соединенных по сети. Есть прога, которая долго и упорно считает, хочется повысить мощность компа (соотв. скорость счета) за счет других компов в сети (не ГЗ).

gerr_piter

шутник вы однако

eee1

да что же. Это реально Даже где-то уже есть готовые решения

Akalash72

есть ли способ распараллелитьнекоторую рассчетную задачу

конечно есть, некоторую

eee1

а что там за задачи-то? вдруг у меня будет желание попрактиковать паралл.програмирование (а то боюсь что скоро забуду его)

tamusyav

Вообще говоря, способов много, юзайте поиск. Скажу лишь только, что прежде чем этим заниматься нелишне будет оценить объем пересылаемых данных и количество пакетов в единицу времени, которые для этого потребуются. Может оказаться, что узким местом окажется сеть (из-за низкой пропускной способности или высокой латентности, соответственно и в результате задача будет считаться не быстрее, а то и заметно медленнее, по сравнению с вариантом на одном компе.

Realist

Ботать в сторону
1) параллельного программирования:
Пишем прогу в расчете, что она будет выполняться одновременно на нескольких процессорах. Например, соединить несколько компов сеткой и считать их одной вычислительной установкой. Самое распространенное тут: использовать MPI. Кратко суть такая. Программа на С++/Fortran компилируется вместе с библиотекой MPI. Запускается по экземпляру программы на каждом проце. Каждый экземпляр (процесс) знает свой номер и общее число процессов. Ты явно указываешь, какую часть вычислений он делает и какие данные какому процессу пересылает. Пересылка данных с помощью библиотеки MPI.
www.parallel.ru
2) распределенного программирования:
полученная байда менее связанна. Например, так всем миром ищут неземные цивилизации, лекарство от рака, простые числа. Есть сервер, который знает, что надо посчитать. Волонтеры ставят себе на комп программулину, которая запрашивает у сервера, что ей посчитать, считает и возвращает результат. О других компах, которые в этом участвуют, она мб не в курсе

Jackill

В твоём случае нужно определиться: стОит ли тебе распараллеливать одну "большую" задачу на несколько машин, либо просто запустить много "маленьких" задач на нескольких машинах. Для некоторых задач применимы оба варианта.
Вот как бы я рассуждал:
Первый вариант следует выбирать, если время, требуемое для расчета минимальной порции вычислений (после выполнения которой можно сказать, что "что-то посчиталось") достаточно велико - например, больше 1-2х дней.
Иначе следует выбирать второй вариант.
В первом случае я бы посоветовал пользоваться каким-нибудь MPI кластером, например, - комплексом НИВЦ МГУ, который здесь уже рекомендовали (http://parallel.ru/cluster). Если ты из МГУ, то получить аккаунт там очень просто. Например, когда я выполнял расчёты для своей диссертации, то в течение 15 месяцев занимал там около 50 процессоров. Большим недостатком распараллеливания задач я вижу достаточно сложное программирование для MPI.
Во втором случае ты можешь использовать GRID. Для меня это было гораздо удобнее и проще, чем работа с MPI-кластером. Использование GRID требует меньше времени на программирование.
Работая в GRID, я использую одновременно порядка 30-100 процессоров. Почитать про грид можно здесь: http://grid.sinp.msu.ru
Также прислушайся к советам и .

Aiwazovsky

Всем большое спасибо!

tamusyav

Еще добавлю пример из собственной практики на тему того "а стоит ли". Некоторое время назад я вместе еще с несколькими людьми занимался разработкой некоторой расчетной программы на заказ. В числе прочего планировалось использовать сабж, что и было реализовано; однако алгоритм позволял распараллеливать лишь на небольшое количество процессоров (не более 6 но это уже неплохо. Вместе с тем, выгода от распараллеливания была только у нас, но не у заказчика, поскольку у его стоял кластер на более медленной сети. После того, как распараллеливание было сделано, обнаружилось, что ряд мест можно сильно оптимизировать. В результате выгода от распараллеливания исчезла и у нас, потому что после оптимизации задача стала на одном процессоре считаться быстрее, чем раньше на шести, а предел латентности сети неоптимизированная задача практически исчерпала.
Чтобы не повторять подобных ляпов, сначала нужно максимально оптимизировать задачу и только потом думать о распараллеливании.
Оставить комментарий
Имя или ник:
Комментарий: