Посоветуйте язык для параллельной разработки

Google Go, но он пока сырой. Erlang? Scala/Scala+Akka/Java+Akka?

ppl.stanford.edu/wiki/index.php/Delite ppl.stanford.edu/wiki/index.php/Pervasive_Parallelism_Laboratory

ppl.stanford.edu/wiki/index.php/Parallelism_Primitives

http://www.erlang.org

если совсем-совсем параллельно то тогда да, Erlang. он под это и заточен.

>если совсем-совсем параллельно то тогда да, Erlang.

И в особенности - если «с большим числом дискретных элементов»

А как Эрланг на суперкомпьютерах? Речь идет о запуске на 1000+ процессах (должно быть до ста тысяч). У Charm++ все в порядке с этим.

А это работает на распределенной памяти? Там вроде говорят о мултикорах и сравнивают с OpenMP и тп., то есть с разделяемой памятью

Scala вроде не то. Как и UPC или Coarray Fortran

А вот Google go что-то интересное, вроде.

да вроде должно нормально параллелиться на ноды.
см. вот там - http://erlang.org/white_paper.html

Erlang is designed to be run in a distributed environment. An Erlang virtual machine is called an Erlang node. A distributed Erlang system is a network of Erlang nodes (typically one per processor). An Erlang node can create parallel processes running on other nodes, which perhaps use other operating systems. Processes residing on different nodes communicate in exactly the same was as processes residing on the same node.

>А как Эрланг на суперкомпьютерах? Речь идет о запуске на 1000+ процессах (должно быть до ста тысяч).

Запустишь «сто тысяч» процессов в программе - заюзает все сто тысяч процессоров. Но эрланговские процессы настолько легковесны, что сто тысяч процессов можно спокойно и на ноутбуке выполнять.

Хотел порекомендовать V8 и spidermonkey, но не уверен насчёт работы на таком количестве процов, хотя распаралеливание там есть.

Occam?

А по-старинке Fortran/C/C++ и MPI уже не модно?

+ еще не рекомендавали Fortress.

еще не рекомендавали Fortress

и Data Parallel Haskell. однако рекомендовать стоит то, чем успешно пользовался в реальной жизни, не?

Очень модно. C + MPI это выбор номер 2 сейчас. По-сути, все решается между Charm++ и C99/MPI. Но хочется рассмотреть еще альтернативы, включая Erlang. Речь идет об очень большом количестве вычислений и от выбора много чего зависит. C имеет то преимущество, что его все в области более или менее понимают.

> чем успешно пользовался в реальной жизни, не?

Если кто здесь реально делал большие параллельные модели в чем-то - совет был бы просто бесценным. В том числе и отрицательный опыт.

> Occam?

Объективный верблюд не подходит. Их академическая недоделка для параллельных вычислений пока нигде не опробована.

> Запустишь «сто тысяч» процессов в программе - заюзает все сто тысяч процессоров.

А есть реальный опыт работы с Erlang? Так как я не уверен, что вот так «запустишь» и она заюзает все ноды. Что она использует под капотом? Какой слой? MPI? или что-то свое?

MPI в чистом виде несколько гемморно. Дело в том, что сама модель вычислений скорее походит на то, что используют в Charm++. То есть куча локальных островков, трудно все загнать в массивы и разделить. Но все происходит локально и разбить на туеву хучу мелких процессов как бы получается довольно легко.

Не OCaml, а Occam.

Понял. Пардон тогда. А он разве все еще жив? Ща пороюсь.

Clojure (http://clojure.org, видео-рассказ на тему concurrency в clojure: http://clojure.blip.tv/file/812787/ )

>А есть реальный опыт работы с Erlang?

Да.

Так как я не уверен, что вот так «запустишь» и она заюзает все ноды.

«Вера» - для необразованных. Проверь. Или прочти хотя бы статью на википедии.

Что она использует под капотом? Какой слой? MPI? или что-то свое?

Я не знаю, что такое «под капотом» и «слой». MPI не использует - он там нахрен не нужен.

> MPI не использует - он там нахрен не нужен.

Ага, и инфинибэнд без прослоек ipoib тоже не нужнет? Точно на 1000 нод пробовали?

ТС, используй C++ + MPI и не парься. Там хоть масштабируемость будет ограничена кривизной твоих рук, а не чужих. Imho при таком числе ядер ничего кроме ручного распараллеливания по mpi не поможет.

однако рекомендовать стоит то, чем успешно пользовался в реальной жизни, не?

А у кого на ЛОРе есть доступ к машинам с сотнями тысяч процессоров? У пары человек если

Scala вроде не то

из-за jvm?

пишете софт для ботнетов?

Вообще по-умолчанию он создается столько же планировщиков, сколько процессоров.

Шутки ради:

$ erl +S 1000
(no error logger present) error: «Failed to create 1000 scheduler-threads (eagain:11); only 353 scheduler-threads were created.\n»
Erlang R13B02 (erts-5.7.3) [source] [smp:353:2] [rq:1000] [async-threads:0] [kernel-poll:false]

и это на простом x86 с 2 ядрами.

оооо....дааа!! ja-ja!! незаметно (с) установить рантайм эрланга, ага.

MPI2

а может у американцев купить готовый модуль?

Насчет erlang спроси здесь, но вроде бы на числодробительных операциях он не очень производителен (видел где-то статью)

>однако рекомендовать стоит то, чем успешно пользовался в реальной жизни, не?

Ну, тогда C+MPI+OpenMP. И с OpenMP осторожно, там куча граблей и тонкостей. Начать можно с C+MPI.

Речь идет об очень большом количестве вычислений и от выбора много чего зависит.

Erlang - high-throughput, а не high-performance.

Почему бы тогда не поднять кластер? Например, на Condor.

>на числодробительных операциях он не очень производителен
http://www.davispj.com/2009/11/23/erlang-nif-test.html

>Ага, и инфинибэнд без прослоек ipoib тоже не нужнет?

На «голом» инфинибенде пока не работает - njkmrj xthtp ipoib. Идея реализовать это у нас есть, но пока что «руки не дошли». Хотя, можно попробовать заюзать libspb-враппер.

Точно на 1000 нод пробовали?

А в чём проблема?

ТС, используй C++ + MPI и не парься.

Не, лучше как все хомячки использовать .NET и «не париться»:)

Imho при таком числе ядер ничего кроме ручного распараллеливания по mpi не поможет.

Спасибо, насмешил:))

>Scala вроде не то

Как сказать. Та же акторная модель что и в эрланге.

>Так как я не уверен, что вот так «запустишь» и она заюзает все ноды.

Заюзает, заюзает. Не переживай.

Что она использует под капотом?

Планировщик своей виртуальной машины. Акторную модель, т.е. легковесные «процессы» обмениваются сообщениями и это единственный способ их взаимодействия.

Идет в комплекте с фреймворком OTP, где есть много жизненно необходимых вещей (типа распределенной БД). В текущй версии активно пилят блблиотеку, которая позволяет писать ерланговские функции на С, это не считая имеющихся двух штатных способов взаимодействия с нативным окружением.

Разрабатывается с конца 80-х, в опенсорсе с конца 90-х.

>Есть альтернативы?

Специализированные параллельные языки и расширения существующих языков. http://parallel.ru/tech/tech_dev/par_lang.html

Да, но вроде она рассчитана на «одна ОС/kernel - одна JVM». потоков экторов может быть хоть миллионы, но в пределах одной JVM, а JVM работающая одновременно на тысячах процессоров - я о таком не знаю.

Всем кто откликнулся, спасибо. Сейчас занят по работе, отвечу подробно. Пока лишь. Да речь идет о машинах с инфинибандом с сотней нод по 8-16 ядер. Разработка идет в США. МПИ и ОпенМП знаю (надеюсь) очень хорошо. Не в них дело. Никто ничего не сказал про Чарм++, а он масштабируется отлично на блюджин.

>работающая одновременно на тысячах процессоров

Да, пожалуй. Но все-таки это очень специализированные системы, если они конечно еще существуют.

Все-таки современные системы построены из узлов с достаточно скромным количеством ядер.

Судя по постам в блогах скалу используют в highload системах, в принципе успешно. Конечно, применять в числодробилках скалу не получится, но к слову сказать, акторная модель сама по себе не везде может применяться.

О! А про NIF я и забыл, но они все же недавно появились

>но вроде бы на числодробительных операциях он не очень производителен

Даже не «вроде бы», а точно :)

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=hipe&lang2=gpp

Его сила именно в крайне легковесных процессах и масштабируемости.

>Да, но вроде она рассчитана на «одна ОС/kernel - одна JVM». потоков экторов может быть хоть миллионы, но в пределах одной JVM

Т.е. на Scala нельзя развернуть одну систему на нескольких нодах?

В общем, посовещавшись коллектив пришел к соглашению лабать в C/MPI для начала, и параллельно смотреть на альтернативы. Издалека. :)