Распределённые приложения на Erlang

> А кто как не ты обосрал всех заявляющих об ортогональности MPI и Erlang? А теперь - копытами назад?

Да ты оказывается фонатег ;)

Еще раз и по буквам - речь про _парадигму_параллелизма_ коя в субже весmма похожа на MPI но по фичам ImHO беднее.

>А, вы просто троль, так бы рсразу и сказали.

Тролль как раз вы. Но я сегодня добрый - на иди читай https://computing.llnl.gov/tutorials/mpi/

> _Сделать_ и иметь _готовую_ сущность (мегаэффективную и отлаженную) это две большие разницы.

Может ли быть мегаэффективная (+надежная) групповая рассылка вне кластеров? Разработчики Ерланга ответили отрицательно.

> Еще раз и по буквам - речь про _парадигму_параллелизма_ коя в субже весmма похожа на MPI но по фичам ImHO беднее.

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

> Но я сегодня добрый - на иди читай https://computing.llnl.gov/tutorials/mpi/

Я знаком с MPI на уровне данного туториала. распределенных реруляционных БД там нету.

Кстати, чего это ты расттыкался и раскомандовался, кому куда идти? Я тоже могу послать тебя читать маны по ерлангу, тебе оно явно не помешает.

>hint: речь идёт о парадигме _параллелизма_ а не о поисках "серебряной пули". Лично мне парадигма паралеллизма в субже видится весьма убогой (по сравнению с MPI). Другой вопрос что для набора решаемых оным задач этого достаточно.

Они разные. MPI хорош там, где есть небольшое количество относительно жирных процессов, которым в отдельные моменты времени необходимо друг другу что-то сообщить. Соответственно, имеем подвинутые семафоры, локи и рассылку сообщений.

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

Представь стандартный алгоритм поиска выхода из лабиринта. Следопыт на каждой развилке создает столько экземпляров, сколько вариантов выхода и умирает. если следопыт попадает в тупик, он тоже умирает. как только выход найден, посылается сигнал и все дохнут, кроме победителя, который и возвращает ответ. вот это задача для эрланга.

В Эрланге это просто, потому что параллелизм в нем находится в центре всего, соответственно он прост и функционален.

>распределенных реруляционных БД там нету.

Это часть _языка_ ? o_O

PS: Параллельный IO (к файлам, в том числе на распределённых FS) в MPI есть http://beige.ucs.indiana.edu/I590/node86.html

>Речь идет о том, что ерланг - не для параллельных числодробилок.

Спорное утверждение. Хотя, конечно, все, что не фортран - не для вычислений, да уже и в c++ эффективных библиотек достаточно, сама задача , например, вычислений методом конечных элементов очень хорошо подходит для эрланга...

Настран (c++,fortran,mpi), к примеру, доказывает это со всей очевидностью, умирая по любому поводу и выдавая тольео конечный результат, то есть, все или ничего.

> а в случае чего умирает.

Вот это пожалуй существенное отличие в парадигме ...

> распределенных реруляционных БД там нету.

> Это часть _языка_ ? o_O

Поскольку оная БД поддерживается самой средой исполнения ерланга - вполне можно сказать "да". Если под "языком" понимать базовый синтаксис - то "нет", это часть стандартоной библиотеки.

>ЗЫ: Эрланг живёт на кластерах ? Можно по идее проверить. 176 Гигов оперативы есть ;)

Дык надо ж осмысленно проверять, на какой-нибудь простой задачке. Что толку хоть с миллиона спящих процессов?

> Спорное утверждение.

Я помню, что все целый числа там бесконечнодлинные, мне страшно полдумать про вещественные :)

> сама задача , например, вычислений методом конечных элементов очень хорошо подходит для эрланга...

Задач, подходящих под его парадигму - в теории да, навалом, массы дискретных алгоритмов.

>например, вычислений методом конечных элементов очень хорошо подходит для эрланга...

Для даной парадигмы в принципе подходит и всякие методы Монте-Карло и решение задач по расчёту траекторий в многофазных системах, но там критическим является ресурсы процессора. То есть породить миллион процессов можно но это будет неэффективно если у вас всего 1000 процессорных ядер, поэтому там парадигма чуть отличается ...

>Вот это пожалуй существенное отличие в парадигме ...

Ага, небось екнуло в этом месте? ;)

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

>Ага, небось екнуло в этом месте? ;)

> А оно именно так и работает. Смерть процесса - вещь абсолютно естественная, к тому же приводящая к смерти тех процессов, которые из за этого теряют смысл своего существования.

Только в пределах одного коммуникатора...

>но там критическим является ресурсы процессора.

процессы, порождаемые эрлангом минимально связаны. минимум семафоров, минимум локов. Фактически, это управляемое данными вычисление и лучше всего оно пойдет на соответствующем процессоре.

по этой же причине можно использовать максимум халявного ресурса - вплоть до десктопов всей организации.

>Я помню, что все целый числа там бесконечнодлинные, мне страшно полдумать про вещественные :)

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

>Можно по идее проверить. 176 Гигов оперативы есть ;)

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

>Только в пределах одного коммуникатора...

Это искусственное ограничение. Так бесконечно масштабируемое приложение не построить...

>процессы, порождаемые эрлангом минимально связаны. минимум семафоров, минимум локов.

Это как раз сужает область применения. Как и отсутствие групповых операций и коммуникаторов, опять же ассортимент p-p операций невелик (мягко говоря). Это конечно можно сэмулировать, но это уже будет лишняя сущность пристроенная сверху(сбоку/сзади)

>Этого недостаточно. Эту "оперативу" в голове неплохо бы чем-то полезным наполнить, перед тем как что-то "пробовать".

То есть реальных задач для erlang под такие ресурсы нет ? ;)

>Это искусственное ограничение. Так бесконечно масштабируемое приложение не построить...

Чесно говоря не помню есть ли ограничение на число коммуникаторов ;)

Задача же на натянуть одну парадигму на другую а сравнить плюсы и минусы ну и просто различия

> Задача же на натянуть одну парадигму на другую а сравнить плюсы и минусы ну и просто различия

MPI для математики, OTP для масштабируемых серверных задач, чего непонятно то.

> MPI для математики, OTP для масштабируемых серверных задач, чего непонятно то.

Реализации - да.

Еще интересный момент - атомы.

Я вот никогда не понимал, почему я могу без дополнительных усилий ограничить аргумент функции,скажем, только целым или только положительным, но не могу ограничить его списком валидных значений?

Вот есть у меня функция-логарифм, который у меня в программе бывает только натуральный или десятичный. В эрланге я пишу функцию

log (E,x) -> ...; log (10,x) -> ....

и все,вызов функции с другим параметром не пройдет незамеченым, а в других языках по любому будут или две разные функции с разными типами данных и либо везде четко отделяй lg() и ln() или молись, что компилятор везде вызовет верную функцию, то есть кастуй аргумент, но при этом все равно в аргумент может попасть и 9 и 0 и что угодно...

>Это конечно можно сэмулировать,

Не надо эмулировать. Надо менять направление мысли.

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

Такие задачи надо просто решать другими средствами. А эмулировать - не надо.

> Нет. Считать на эрланге не надо. Это просто невозможно за неимением библиотек.

Библиотеки нужны непрерывщикам. :) Вот есть к примеру простая такая задача - генерация всего графа состояний программы на некотором языке. :)

>Чесно говоря не помню есть ли ограничение на число коммуникаторов ;)

Дело не в этом. Ограничение будет в голове, в алгоритме, реализующем задачу. Написать бесконечно растущую задачу, генерящую коммуникаторы и при этом не имеющую спорадически возникающих узких мест и изъянов невозможно...

>Дело не в этом. Ограничение будет в голове, в алгоритме, реализующем задачу. Написать бесконечно растущую задачу, генерящую коммуникаторы и при этом не имеющую спорадически возникающих узких мест и изъянов невозможно...

Это определяется самой задачей а не парадигмой MPI. Просто бОльшая часть HPC задач чувствительны к масштабированию сами по себе а не вследствие той или иной парадигмы их распараллеливания.

ну привычка писать на одном - формирует "туннельное зрение". и все необычное - видится "в штыки. но если(ЕСЛИ !!!) вдуматься, метафора помойки(heap), диспетчиризация вообще(мьютексы или еще как) - ОЧЕНЬ, ОЧЕНЬ нездоровая фигня. повторюсь, это будующее.

1. голословно 2. на других языках - пишут. а тут - "то что доктор прописал".

> Эрланг, это и есть очередь сообщений. Там по другому быть не может.

Ну и зачем он нужен, когда и в Java эта очередь распрекрасненько реализуется?

>Ну и зачем он нужен, когда и в Java эта очередь распрекрасненько реализуется?

"Понмаешь, сынок, эсть такое понятие - родина!" (с) Анекдот

> Эрланг, это и есть очередь сообщений. Там по другому быть не может.

> Ну и зачем он нужен, когда и в Java эта очередь распрекрасненько реализуется?

Я бы перефразировал - зачем нужна Java, если это прекрасно реализуется в Erlang "из коробки"?

Сравнивать лучше так http://shootout.alioth.debian.org/debian/fulldata.php?test=threadring&p1=... Видно, что Scala на Java 6.0 не сильно-то от Эрланга отстает

>Видно, что Scala на Java 6.0 не сильно-то от Эрланга отстает

Да, всего в 10 раз:)

учитывая молодость языка и количество "заточек" под железо у EJB-related и в других нишах - разница(в пользу Erlang) - будет только РАСТИ. но, повторюсь, если его - не замочат.

В Erlang эти очереди есть из коробки, и ничего кроме них и нет. А в Java есть всё, что может вообще в жизни понадобиться.

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

посему считаю, что в языке главное - универсальность. если он такой весь из себя узконаправленный - значит пусть предоставляет богатые возможности взаимодействия с другими языками, дабы можно было на нем писать только ту часть кода, которую реально написать на нем легче.. а проектов, которые ТОЛЬКО тем и занимаются, что используют сильные стороны узкоспециализированного языка - по определению мало.

MPI под java есть? нету... на хер

надоели унылые жабофилы :(

p.s. жаба она, как журналисты... трындёж один

> В Erlang эти очереди есть из коробки, и ничего кроме них и нет. А в Java есть всё, что может вообще в жизни понадобиться.

Вот мне нужны биндинги к SDL. Живые биндинги к SDL в Java есть? Судя по гугдению и apt-cache - нет. А, все пропало, ява не на что не годится.... ;)

любовь к новому отвалится и останется "старое доброе" - реинкарнации пролога и процедурных - в Эрланге. Java и C++(как и C) - уже "отвалились" а любовь(:-) - осталась ;P

>А в Java есть всё, что может вообще в жизни понадобиться.

Дай живые биндинги к Ogre3D или Irrlicht, очень благодарен буду! :)

>Ну и зачем он нужен, когда и в Java эта очередь распрекрасненько реализуется?

Если нужна эта очередь, то да, можно и яву и питон и что угодно использовать. А если нужна программа, молотящая в тысячах процессов, а не тупо жрущая, память как ява или висящая в случайных тредах, как питон, то нужен спец инструмент. И имя ему - эрланг...

2AVL2
"А если нужна программа, молотящая в тысячах процессов" - что именно молотящая?
Как выяснили для расчетов Erlang не особо годится. Что эти тысяча процессов могут делать?
Принять данные с входа и положить в файл/базу, а потом дальше слушать данные?

>"А если нужна программа, молотящая в тысячах процессов" - что именно молотящая?

молотящая concurent processing . SMTP, HTTP, SIP, IMAP. продолжать ?

BTW, http://www.sics.se/~joe/apachevsyaws.html :D

> SMTP и прочие почтовые
SPAM-фильтр тоже на Erlang?

HTTP - смешно :), PHP, Perl, Java J2EE , .NET - все это заменит?

> BTW, http://www.sics.se/~joe/apachevsyaws.html :D
Ну да. Выдать статику из памяти это круто. А то, что Apache имеет функционал на порядки богаче чем YAWS это так, мелочь :)

> SMTP и прочие почтовые SPAM-фильтры тоже на Erlang?

Ты не поверишь :D Есть у меня острое желание (но пока беда со временем) написать SMTP proxy, который бы держал 100-200K concurent connection's и вышибал SMTP time из потока 50-70% спама + routing/balancing по backend'ам. Вот тебе типичная телекомовская задача и прямая дорога к использованию erlang'a. :D

>HTTP - смешно :), PHP, Perl, Java J2EE , .NET - все это заменит?

Ну почему же ? CMS на erlang'e, конечно, выглядит большим извращением, а вот какой-нибудь сильно нагруженный REST - самое оно :D Не ?

>А то, что Apache имеет функционал на порядки богаче чем YAWS это так, мелочь :)

Да, полностью согласен. Я, собственно, и не говорил, что erlang - "серебрянная пуля".

> а вот какой-нибудь сильно нагруженный REST - самое оно :D Не ?
Похоже да.
Erlang - получается узкоспециализированным. Соответственно специалистов (и литературы) по нему мало.

Жаль сейчас не вижу подходящих задач для него. Пока Objective-C поизучаю.

А что мешает отказаться от потоков и написать то же самое на Си с циклами вокруг select()?