Оправдано ли использование MPI на двух ядерной машине?

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

Нужны ли threads -- IMHO зависит от задачи. Если параллельным процессам/тредам нужна общая память, то threads будут к месту. Если хватит простого обмена сообщениями -- удобнее MPI.

[самому мне не приходилось использовать threads]

> будет ли MPI эффективно работать на одной машине?

Никогда не сталкивался с многоядерными архитектурами.

На hyperthreaded процах MPI (по крайней мере MPICH и производные) не работает по причине злоупотребленя спинлоками.

Проще всего взять и проверить.

>...openmp можно в ближайшем будущем не рассматривать. Поэтому остаются MPI или threads.

Очень странное умозаключение...

А что, fork() отменили?

И, потом, рассматривать MPI как альтернативу тредам... Они для разных вещей!

ringill:

> Нужны ли threads -- IMHO зависит от задачи.

Согласен.

>Если параллельным процессам/тредам нужна общая память, то threads будут к месту. Если хватит простого обмена сообщениями -- удобнее MPI.

Совершенно не согласен!

IMHO треды нужны для автоматического масштабирования на все доступные ресурсы (ценой снижения производительности) и для облегчения имплементации "имманентно" параллельных алгоритмов (типа мультиплексирования ввода/вывода из одного дескриптора).

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

> На hyperthreaded процах MPI (по крайней мере MPICH и производные) не работает по причине злоупотребленя спинлоками

Не знал...
Не работает -- т.е. не даёт прироста производительности?
Где можно подробнее прочитать об этом?

Спасибо.

> IMHO треды нужны для автоматического масштабирования на все доступные ресурсы (ценой снижения производительности) и для облегчения имплементации "имманентно" параллельных алгоритмов (типа мультиплексирования ввода/вывода из одного дескриптора).

Нелегко вас понять, но могу согласиться, что fork() более подходит, чем треды, почему бы и нет.

Так что слова "threads будут к месту" беру назад.

ringill:

> Не работает -- т.е. не даёт прироста производительности?

Либо вообще виснет, либо еле движется (в десятки раз медленнее, чем просто один процесс)

Проверял только MPICH.

> Где можно подробнее прочитать об этом?

Не знаю, самому интересно...

ringill:

> Так что слова "threads будут к месту" беру назад.

Кстати, я там IMHO поставил -- большинство народу со мной не согласны в этом месте. Но я в этом абсоютно уверен.

может от задачи зависит? у меня LAM давал ускорение где-то 10% на HT

Огромное спасибо всем за ответы, очень поучительно! Сейчас буду ставить MPI и прбовать.
А с форком нехорошо получилось ), засмотрелся на MPI и забыл про него, спасибо, что напомнили.

Reset:

> может от задачи зависит? у меня LAM давал ускорение где-то 10% на HT

Да, конечно.

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

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

Только что получил некие результаты на LAM'е. Не связанные с HT; на многоголовом Оптероне гонял, но результаты сильно отличаются от того, что я наблюдал на MPICH!

Похоже, у LAM проблем со спинлоками нет!