Rhope: новый потоковый язык

PS: уточнение - не пишу, если это не является необходимостью.

> Я говорю о том, что мир бы не обрушился, если бы такое случилось.

Обрушились бы все до единого веб-интерфейсы. Думаю, это сойдет за обрушения мира.

> Пока не проснется, другие ерланговские потоки не будут выполняться.

Вот я и спрашиваю - если есть receive, а данных нет - то, выходит, смерть всему ерлангу? На практике не подтверждалось.

> А удобно бы было конечным пользователям.

В среднем на ЯВУ получаются лучшие программы, чем на ЯНУ. В принципе, на ассемблере довольно просто писать, не сложнее, чем на С.

> Обрушились бы все до единого веб-интерфейсы. Думаю, это сойдет за обрушения мира.

Спорный вопрос, на Си вполне таки можно генерить HTML. Правда если отменить HTML и JavaScript, тогда да.

> В среднем на ЯВУ получаются лучшие программы, чем на ЯНУ.

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

> В принципе, на ассемблере довольно просто писать, не сложнее, чем на С.

На ассемблере писать кроссплатформенный софт и поддерживать программы нереально.

>Вот я и спрашиваю - если есть receive, а данных нет - то, выходит, смерть всему ерлангу? На практике не подтверждалось.

Если он _блокирующий_. А на самом деле там обертка над неблокирующим сокетом с epoll и recv. Но это вовсе не означает, что он не может заснуть и завесить все приложение...

То же самое с записью на диск - буферизированная и неблокирующая в _теории_, а из-за возможности спать в системном вызове - вуаля, весь ерланг будет висеть.

Кстати, запись на NFS при повисшем сервере завесит _все_ потоки ерланга (если один системный форкнутый процесс, если несколько суть не меняется, несколько пишуших ерланговских потоков завесят остальные)...

сегфолтится оно что-то: 

oleg@traveler:/tmp/rhope_src$ ./rhope webserver.vistxt 
Loading program webserver.vistxt
Reading text program
Size: 2603
initpredefworkers()
parse
Segmentation fault (core dumped)

и даже само по себе падает:
oleg@traveler:/tmp/rhope_src$ ./rhope 
Segmentation fault (core dumped)

"Я буду долго гнать велосипед..."

> Если он _блокирующий_. А на самом деле там обертка над неблокирующим сокетом с epoll и recv.

Так оно вообще бывает блокирующим в природе?

> То же самое с записью на диск - буферизированная и неблокирующая в _теории_, а из-за возможности спать в системном вызове - вуаля, весь ерланг будет висеть.

А там не используется неблокирующий ввод-ввод ОС, по аналогии с сетью? Или имеется в виду, что сон может наступит при старте асинхронного ввода-вывода? (А в Mnesia какой ввод-вывод?)

Спасибо за разъяснения.

> Так оно вообще бывает блокирующим в природе?

Я про receive, а не про recv, конечно.

Чего-то от такого кода поблевать захотелось...

>Лучше бы к erlang написали драйвера к БД, вместо долбаного ODBC.

К какой именно БД?

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

Тогда если он спит, то кто выполняет работу на yaws, ejabberd и софтварных коммутаторах? Что ты за бред городишь? Давай пруфлинк.

>Так оно вообще бывает блокирующим в природе?

Бывает для ерланговского потока iirc. Но в конечном итоге любой вызов ерланг попадает на системный вызов ОС.

А даже неблокирующий системный вызов может стать блокирующим при определенных обстоятельсвах :)

Легко привести пример с записью в файл.

>Тогда если он спит, то кто выполняет работу на yaws, ejabberd и софтварных коммутаторах? Что ты за бред городишь? Давай пруфлинк.

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

Что-то нашел в архивах, хотя не совсем про блокирующие вызовы:

> My other question is whether Erlang offers any realtime garuntees. If
> so, how do implementations manage interactions between the kernel's
> scheduling garuntees and the Erlang scheduler garuntees?

No, it doesn't.

I think you could call it best-effort (or "soft real-time".) The
scheduler does pass control around frequently, and having some
processes do heavy lifting doesn't starve the rest, but there are no
guarantees (and no doubt if you start swapping virtual memory etc
you'd see real delays.)

The rule of thumb for Erlang programmers is that you can expect things
to happen within about a millisecond of when they're supposed to
(e.g. 'after' timeouts in receives), and the scheduler makes its
best-effort to make this happen. This is a tremendous luxury compared
with other languages in my experience :-) and evidently the scheduler
implementation is good enough for high-end telecomms systems (<-
obligatory Erlang real-world boast ;-))

> Лучше бы к erlang написали драйвера к БД, вместо долбаного ODBC.

Драйвера к mysql и postgress Yariv(автор ErlyWeb) поддерживает. Плюс к этому есть ORM и обертка для запросов.

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

Тогда не понимаю к чему было писать FUD про работу с сетью? Я тебе могу для чего угодно придумать "очень специфические обстоятельства" при которых не будет работать. На практике сетевые эрланговские сервисы работают под серьезной нагрузкой и справляются с ней.

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

Собственно:

Asynchronous threads in the ERTS is a way of stopping blocking calls from interrupting the scheduling of Erlang processes while the calling thread is blocked. The blocking calls are done in separate OS threads, allowing the emulator to schedule the Erlang processes that are not doing the blocking calls. If there is no asynchronous thread available, the job request will be queued until an asynchronous thread becomes idle.

Это помимо epoll и т.п. но их тоже не бесконечно много...

http://erlang-consulting.com/thesis/tcp_optimisation/tcp_optimisation.html

>Тогда не понимаю к чему было писать FUD про работу с сетью? Я тебе могу для чего угодно придумать "очень специфические обстоятельства" при которых не будет работать. На практике сетевые эрланговские сервисы работают под серьезной нагрузкой и справляются с ней.

Из-за таких разработчиков и появляются ботнеты и черви :)

Я уже привел пример с отвалом NFS и записью...

Ниша Erlang в межпоточной пересылке сообщений, там он безусловно лидер (хотя масштабироваться на несколько процесоров нацчился совсем недавно), при работе с IO все не совсем здорово, а может даже шатко...

Вроде Haskell/ghc может не намного меньше держать потоков и хорошо параллелится, не?

> Я уже привел пример с отвалом NFS и записью...

Ты используешь на боевых серваках NFS или windows?

> Ниша Erlang в межпоточной пересылке сообщений, там он безусловно лидер (хотя масштабироваться на несколько процесоров нацчился совсем недавно), при работе с IO все не совсем здорово, а может даже шатко...

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

>Ну так расшатай, а потом отпиши как у тебя это получилось.

Я же написал пример :) Не с сетью, а с NFS. Если нет async threads, то все повиснет. Если есть, то повиснет один async thread. Несколько клиентов, пишуших в файл (обычно в системе только десятки async threads), и вся система висит.

Другое дело, что возможно все остальные (haskell/java/whatever) будут так же висеть... Но при использовании подхода один поток-один клиент в Linux такой проблемы не будет, благо переключение контекста в современных ядрах занимает меньше микросекунды на современных процессорах. но нужно много памяти, так что у всего свои минусы...

>Ниша Erlang в межпоточной пересылке сообщений, там он безусловно лидер (хотя масштабироваться на несколько процесоров нацчился совсем недавно)

Недавно - это в виндовз. В Linux и Solaris - давно

ОООООООООО!!!!

Main(0,0)

|:

[[[Build["Cow"]

]Num Bells << [453]

]Name << ["Betsy"]

]Owner Name << ["Mike"]

|:

Print[ [~]Num Bells >>]

Print[ [~]Name >>]

Print[ [~]Owner Name >>]

:|

:|

/me ушёл под стол собирать мозги после взрыва.

>Недавно - это в виндовз. В Linux и Solaris - давно

IMHO в 2007 или в конце 2006 в Linux повилось? Если не ошибаюсь, поводом начать включать чужие хаки на эту тему стали как раз linux native threads :)

> Не с сетью, а с NFS.

Я понимаю, что может возникнуть сферически-коневая ситуация повисания на NFS-е, но в Эрланге он уже встроен из коробки. Тоесть ты можешь прозрачно работать с файлами на разных нодах без сторонних приблуд вроде NFS-а. Так что man hands и все будет в порядке.

> Но при использовании подхода один поток-один клиент в Linux такой проблемы не будет

Да, а будут банально заканчиваться потоки, что и проявляется на _практике_: http://www.sics.se/~joe/apachevsyaws.html .

>> Недавно - это в виндовз. В Linux и Solaris - давно

> IMHO в 2007 или в конце 2006 в Linux повилось?

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

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

http://shootout.alioth.debian.org/gp4/benchmark.php?test=threadring&lang=all

Бугага. Разница в скорости между нативными(C++) и зелеными(Erlang/Haskell) почти в 10 раз. Ничего так благо.

>MHO в 2007 или в конце 2006 в Linux повилось?

В мае 2006-го (т.е. два года назад), в R11B-0

>Да, а будут банально заканчиваться потоки, что и проявляется на _практике_: http://www.sics.se/~joe/apachevsyaws.html

Apache - это не пример, я говорил о любом сервере, где на каждого клиента создается новый поток. Именно в этом направлении развивается async IO в Linux - syslets: если сискол блокируется, то создается новый ядерный поток для него, а управление возвращается в userspace (вообще говоря в другом потоке, но это не важно).

>Я понимаю, что может возникнуть сферически-коневая ситуация повисания на NFS-е, но в Эрланге он уже встроен из коробки. Тоесть ты можешь прозрачно работать с файлами на разных нодах без сторонних приблуд вроде NFS-а. Так что man hands и все будет в порядке.

Это не сферически-коневая ситуация, а пример из жизни :) Возможно сейчас уже есть свой NFS клиент, который не виснет при отвале сервера, но проблема этим не решается: заканчивается память - спим, пока страницы выйдут из свопа, bad block - спим. Причем спит не один клиент, спит весь процесс, все тысячи потоков erlang (с учетом количества async threads). И это проблема.

Не уверен начет R11B-0, но в R11 точно. Может в 0 была бета версия...

>Бугага. Разница в скорости между нативными(C++) и зелеными(Erlang/Haskell) почти в 10 раз. Ничего так благо.

Ога, и все проблемы из-за создания потока, а не переключения контекста.

> К какой именно БД?

да ко всем популярным, хоть к postgresql бы. Ну есть там пара поделок - все убогие. А unixodbc - фтопку.

> Драйвера к mysql и postgress Yariv(автор ErlyWeb) поддерживает. Плюс к этому есть ORM и обертка для запросов.

Ссылки дай а

PS: ErlyWeb помоему загнулся.

Ой, сорри, я прочитал как erlybird

а вот здесь есть http://erlang-consulting.com/aboutus/opensource.html какой‐то для постгреса. смотрел его?

просто тоже скоро понадобится подружить erlang с какой‐нибудь RDBMS, вероятно PostgreSQL, ищу варианты…

>да ко всем популярным, хоть к postgresql бы

Мы используем pgsql в продакшн - вроде работает.

Читал про него, говорят недоделанный. Что время терять.

> Ога, и все проблемы из-за создания потока, а не переключения контекста.

Тоесть ты хочешь сказать, что Си создает 504 потока целых 40 секунд? Да ты врунишка оказывается:

gcc thread_ring.c -lpthread

time ./a.out 1000
498
./a.out 1000 0.01s user 0.01s system 106% cpu 0.019 total

time ./a.out 10000000
361
./a.out 10000000 6.32s user 28.31s system 95% cpu 36.235 total

> 106%

а это как?

>Тоесть ты хочешь сказать, что Си создает 504 потока целых 40 секунд? Да ты врунишка оказывается:

Глупый, в первом случае в glibc все стеки закешированы, выдаления памяти вообще наверное не было (о чем и говорит нулевое system time), во втором случае нужно было вызвать mmap сискол на каждое выделение памяти (ну минус то, что было закэшировано).

Так что бегом RTFM, а потом уже рассказывать про то, как умеете запускать программы...

Плюс та программа, что вы тестируете, использует futex для синхронизации, а это еще один сискол... Когда в этом shotout был пример на ассемблере, это было дело.

Кстати, в postresql есть свои spinlock, с ними тоже скорость в разы растет при синхронизации тредов.

> Ой, сорри, я прочитал как erlybird

http://code.google.com/p/erlang-psql-driver/ - Ярив переделал консалтинговский драйвер(кстати для мускула он тоже УХО-вский драйвер красиво обпилил и причесал).

>> 106%

>а это как?

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

>http://code.google.com/p/erlang-psql-driver/ - Ярив переделал консалтинговский драйвер

Вот это немного напрягает: «Project status: This project was just a proof of concept and is currently unmaintained».

>Глупый, в первом случае в glibc все стеки закешированы, выдаления памяти вообще наверное не было (о чем и говорит нулевое system time), во втором случае нужно было вызвать mmap сискол на каждое выделение памяти (ну минус то, что было закэшировано).

Стоп, это я не в тот бенчмарк посмотрел, виноват, там действительно 503 потока перебрасывают сообщения.

Статистика говорит о проблемах в количестве сисколов futex, который использется для синхронизации. Так что проблема в программе, а не скорости переключения контекста.

> Глупый, в первом случае в glibc все стеки закешированы, выдаления памяти вообще наверное не было (о чем и говорит нулевое system time), во втором случае нужно было вызвать mmap сискол на каждое выделение памяти (ну минус то, что было закэшировано).

Программа запущена первый раз на 1000 итераций, второй раз на рабочее число 10000000. Ты написал:

> Ога, и все проблемы из-за создания потока, а не переключения контекста.

Я тебе понял следующим образом: потоки создаются очень медленно, зато переключения контекста пипец быстро. Соответственно тест на малое число показал, что время создание потоков мизерное по сравнению с общим временем выполнения. Тоесть ты соврал.

Если это не так, расшифруй что ты имел ввиду.

> но проблема этим не решается: заканчивается память - спим, пока страницы выйдут из свопа, bad block - спим. Причем спит не один клиент, спит весь процесс, все тысячи потоков erlang (с учетом количества async threads). И это проблема.

Пока что проблема только в твоей голове. Ниодного пруфлинка, ничего конкретного ты не привел. На thread-ring-е с Си облажался... вообщем балабол.

Интересный язык. Я думаю, продолжателем будет язык вот с таким синтаксисом:

[:]||printresult||[:]
:-/
:) Здравствуйте. Это тестовая программа Грегоре :)
/-:


=)
[:]||printresult||[:]
:LOL: Нажмите "Ок" :LOL:
=(