Приложение, требующее большого кол-во одновременных процессов/потоков

Возможно имеет смысл использовать MPI. Для распределённые систем самое то.

> Возможно имеет смысл использовать MPI. Для распределённые систем самое то.

Штука интересная, но кроме как с C, C++ и Fortran ее использовать нельзя? Например так:

Целевой язык (неважно какой пока) поддерживает green-threads и имеет удобный FFI. Можно ли запустить application instance по числу cpu/core/node и обмениваться сообщениями между этими instance с помощью MPI через FFI?

Легко ли пользоваться этой библиотекой?

простите меня за глупый вопрос, но что за зверь такой эти зелёные потоки? то, что о них пишет википедя? в плане того, что это реализация многопоточности средствами userland aka "многопоточность для бедных"?

// wbr

> Неважно что оно будет делать, вычислять ли матрицу, либо обрабатывать большое число одновременных коннектов.

это, кстати, принципиально важно - что именно оно будет делать. это первый вопрос, который нужно задать. вычислительные задачи и задачи ввода/вывода - это две большие разницы.

// wbr

Ну да

> это, кстати, принципиально важно - что именно оно будет делать. это первый вопрос, который нужно задать. вычислительные задачи и задачи ввода/вывода - это две большие разницы.

Вычислительные задачи.

> Вычислительные задачи.

ну тут видимо нужно смотреть на конкретную реализацию да, собственно, мерить.

// wbr

Тогда, если будет сильно распределённая (несколько компов), то по-моему почти безальтернативно: MPI. Да, он вроде только под C/C++, Fortran, может правда, портирован ещё куда. Но в принципе всё логично, в вычислительных задачах C/C++/Fortran почти всегда только и пользуют.

В своё время писал с использованием MPI, всё довольно просто, но немного другой принцип: тут у тя есть разделяемые данные в памяти и ты к ним просто доступаешься (к примеру), а в MPI ты обмениваешься сообщениями с данными.

> Но в принципе всё логично, в вычислительных задачах C/C++/Fortran почти всегда только и пользуют.

Задачи не совсем вычислительные, т.е. не расчет матриц и пр., будет сложный анализ данных скорее, алгоритмы будут сложные, поэтому на низкоуровневые c/c++/fortran заморачиваться не хотелось бы.

Ну, скажем, GHC раскидывает зелёные потоки по физическим, исполняемым на разных процах.

> Ну, скажем, GHC раскидывает зелёные потоки по физическим, исполняемым на разных процах.

хмм, задачи будут с применением методов AI, удобно ли их будет решать на хаскелл, не знаю

Erlang надо использовать

> Допустим необходимо реализовать subj. Неважно что оно будет делать, вычислять ли матрицу, либо обрабатывать большое число одновременных коннектов. Оно должно работать на SMP системе, возможно даже не на одной.

как уже сказали очень даже важно. если ты напишешь с тредами а окажется что надо работать на многих компах то оно либо вообще не заработает будет, либо будет ужасно медленно, death through latency...

ведь если совсем абстрагироваться от того что приложение должно делать, надо писать не тредами а процессами и общаться по TCP. seti@home, folding@home - слышал про таких? самые параллельные приложения в мире, всякие MPI-решения рядом не стояли :-)

А если тебе треды нужны то нужно ответить на вопрос зачем именно и тд.

Насчет green threads vs native threads посмотри на task parallelism в intel threading building blocks. Идея в том, что ты пишешь код в терминах заданий(функторов), а библиотечный шедулер раскидывает их по реальным нитям. Нити создаются по числу ядер в системе либо вручную.

Если говорить про распределенные вычисления - то тут скорее всего тот самый MPI, либо его комбинация с нитями. Основная фича - скорость + абстракция от interconnect-а, важно когда приложению не будет хватать ethernet, т.е. это вариант для распараллеливания сильно связанных задач.

> seti@home, folding@home - слышал про таких? самые параллельные приложения в мире, всякие MPI-решения рядом не стояли :-)

И задачи небось такие, что сообщения хоть бандеролью с хардами доставляй, пинг не критичен? =))

Ada + GLADE как вариант?

http://ada-ru.org/glade_UG_RU/glade_ug_RU.html

Matlab, R, и прочие умеют использовать MPI, но это будет медленно

> Штука интересная, но кроме как с C, C++ и Fortran ее использовать нельзя?

Можно. OcamlMpi.