Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет ringill ([info]ringill)
@ 2006-03-29 12:30:00


Previous Entry  Add to memories!  Tell a Friend!  Next Entry
MPI
Совершенно утомили различия в реализациях MPI, а именно кривизна LAM/MPI по сравнению с MPICH 1.2.5.
1) В LAM/MPI возникают значительные (до 0.5 с) задержки во времени при отсылке нескольких асинхронных сообщений подряд (MPI_Isend()) вперемешку к MPI_Irecv(). Приходится изворачиваться, запаковывать их в структуры и т.п.
2) Установка сообщениям различных тегов, с целью создания "независимых" каналов обмена, не даёт в LAM/MPI ожидаемого результата: неполучение (MPI_Recv()) асинхронного сообщения из одного канала блокирует другой канал.
3) Бесконечный цикл вызовов MPI_Test() вместо одного вызова MPI_Wait() тормозит передачу сообщений от "проверяемому" узлу от другим узлов. Это, конечно не проблема, т.к. MPI_Wait() правильнее, но в MPICH и с MPI_Test() трудностей нет.
4) При частой отсылке асинхронных сообщений с нескольких узлов может возникнуть ситуация, когда некоторые сообщения ДУБЛИРУЮТСЯ (при этом соответствующее количество теряется). Очень неприятно, но этого можно избежать, если не нагружать очередь, т.е. например не посылать
больше 5 сообщений подряд, пока не получено подтверждение о получении первого.

Вдобавок, есть общая для всех реализаций MPI проблема: environment.
Во-первых, системные переменные окружения не передаются автоматически от того узла, на котором программа запущена, к остальным (это связано с безопасностью и/или с использованием rsh вместо ssh для запуска программ на других узлах). Люди пишут workaround для передачи этих переменных посредством MPI_Bcast() в самом начале исполнения программы.
Во-вторых, даже для корневого процесса не гарантируется наличие окружения с той системы, на которой он запущен.
Вывод: environment лучше вовсе не использовать, если требуется переносимость.