VladD2 wrote: > А кто-то проводил реальные эксперементы эффективности? Есть доставерная > информация о том, что Эрлэнговый ЖЦ дествительно эффективнее дотнетного? > Ведь кроме псевда-раелтайм-гарантий еще важна эффективность.
Мне непонятно как сравнивать.
> И не фатк, что алгоритм с поколениями плюс джит-компиляция не окажется > эффктивнее.
Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они
работать будут заметно эффективнее, чем в .NET (не нужен write barrier).
Ну а JIT — это к GC не относится.
> Лично у меня большое подозрение, что окажется и сильно.
Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг
совершенно из-за этого не подходит.
Здравствуйте, Cyberax, Вы писали:
C>Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они C>работать будут заметно эффективнее, чем в .NET (не нужен write barrier).
Извини. Меня не интересуют пустые слова. Будут данные, подходи.
А write barrier просто пушинка супротив интерпретатора и динамики.
C>Ну а JIT — это к GC не относится.
Еще как отностится. Есть две системы с разными проектными решениями. У одной поколенчатый ЖЦ, возможность модифицировать данные в хипе, компилирумый код. У второй интерпретация, своя схема ЖЦ, и т.п. Слушать разглагольствования о теоритическом превосходстве просто нет желания. Тут можно говорить только о эксперементальном подтвержедении.
>> Лично у меня большое подозрение, что окажется и сильно. C>Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг C>совершенно из-за этого не подходит.
Ну, вот сдается мне, что из-за джита и не только он может и во многих других местах отстать. А тут только и слышно что диферамбы его спер производительности без оглядки на задачи.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
eao197,
E>Уважаемые коллеги, обсуждающие, как аналогичные задачи можно успешно решать за счет очередей сообщений и пулов потоков. Мне кажется, вы недооцениваете одной важной вещи, которую предоставляет поход Erlang-а. Если упустить ее из виду, то очередь сообщений действительно может успешно использоваться (равно как и язык ассемблера в умелых руках). Разница всего лишь в цене и в возможностях.
Точно! Только хотел написать n0name2-у, что обычно предметная область допускает некоторую "естественную" декомпозию. И если подходить к решению задачи неестественно (проще говоря, через зад), то предел сложности начнёт надвигаться гораздо быстрее (это такая сложность, что сколько бабла не вкладывай, довести решение до конца будет невозможно).
Мне сразу вспоминается пункт из диссертации Джо Армстронга, когда постановка задачи предполагала естественное решение в 6 процессов на соединение, но тогдашний эрланг не тянул получающееся итоговое количество потоков, и они вынуждены были сильно усложнить обслуживание соединения, сократив до 2-х (или 3-х) процессов на соединение. Усложнение решения конечно же тянет за собой усложнение тестирования (причём суперпропорционально) и поддержки. А, надо сказать, поддержка больших систем — это вполне самостоятельный проект, и отнюдь не дешёвый.
Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
Ну ответ-то собственно прост как три копейки: weblogic подошла вплотную к пределу сложности, и теперь если начать работать напильничком, то эта работа (даже для такой денежной фирмочки как BEA) рискует никогда не закончиться. Потому вот только "кенгурятники" (напр. soap) навешивают и тряпочкой протирают для создания товарного вида.
Почему Виста имеет хороший аппетит и так долго не выходила? По той же самой причине. Windows вплотную подошла к пределу сложности и дальнейшее развитие будет только как расширение функционала преимущественно _внешним_ образом.
Этот кажущийся отход от темы на самом деле не отход, а скорее поднятие точки зрения чуть выше, потому что технические возможности, человеческие возможности и наличные ресурсы (бабло и время) взаимно влияют друг на друга и чем больше масштаб систем, тем больше влияние.
E>Вот как-то так. Или я что-то не правильно про Erlang понял?
Да в общем-то даже сами создатели не поняли, чего сделали. Хотели как всегда, а получилось лучше.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Точно! Только хотел написать n0name2-у, что обычно предметная область допускает некоторую "естественную" декомпозию. И если подходить к решению задачи неестественно (проще говоря, через зад), то предел сложности начнёт надвигаться гораздо быстрее (это такая сложность, что сколько бабла не вкладывай, довести решение до конца будет невозможно).
Все верно. Не вопрос. Только вот хороший SMP scheduler user-level потоков тоже весьма непростая задача. Вообще говоря, не более простая чем довести стоимость kernel thread до стоимости lightweight thread. Ее пытались решить в Sun Solaris (LWP), плюнули и перешли на 1:1 модель. Пытались сделать в JVM несколько раз — глючило и в реальной жизни все было не так здорово. Сейчас Erlang работает на SMP в разы медленнее чем на одном ядре (что уже нонсенс для современного железа). Посмотрим, получится у них сделать более стабильный и правильный SMP scheduler. У меня есть сомнения, не вижу чем тут функциональщина сильно поможет.
LCR>Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
Прости, но вы performance profile делали? Есть большое подозрение что это application тормозит и дело не в weblogic вообще.
n0name2,
LCR>>Так что интересно? Одновременное количество работающих процессов? Пиковая нагрузка? Или время отклика на приоритетное сообщение при максимальной нагрузке?
N>Интересно кол-во запросов, которое может быть обработано в секунду. Т.е. throughput. Под запросом я понимаю — рендеринг web страницы или например в терминах телекома запрос на инициализацию звонка.
Ясно. Глянь ejabberd, eddie, YXA, Tsung.
N>Пока ни одной не искуственно выдуманной задачи я не видел.
Курилка,
К><skipped/>
К>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>><skipped/>
К>>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
LCR>Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
LCR>Кстати, что там Вадлер ответил?
Да ничего интересного:
A tool was produced but I don't think it was publically released; at any
rate it is no longer maintained. More recently, Kostis Sagonas has
produced a more sophisticated type checker for Erlang.
=============перевод=====================
Утилита (речь про type tool, что у Вадлера на сайте) была создана, но я не думаю, что
её зарелизили, в любом случае она больше не поддерживается. В недавнее время, Костис Сагонас
сделал более сложный тайп-чекер для Эрланга (речь про Dialyzer)
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
N>>Интересно кол-во запросов, которое может быть обработано в секунду. Т.е. throughput. Под запросом я понимаю — рендеринг web страницы или например в терминах телекома запрос на инициализацию звонка.
LCR>Ясно. Глянь ejabberd, eddie, YXA, Tsung.
erjabberd — вполне себе нормальный сервис, не вопрос. только вот ничего сверхъестественного в его performance benchmarks (2000mess/sec, 7000users) я не вижу. Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>><skipped/>
К>>Я тут написал в эрланг-квесчнз вопрос примерно на эту тему, и вот что Ульф Вигер мне ответил по поводу добавления стат. типизации в эрланг (для фантома: ниже приведён перевод ):
LCR>Да читал, читал .. Полтора года назад тоже было подобное обсуждене ("намдескать нужно делать сверхнадёжный софт, а вы подсовываете езык ниразу непохожий на Йаву да ишо без статической типизации").
n0name2,
LCR>>Подойдём с другой стороны: перед глазами у меня BEA WebLogic. Работает прямо скажем не сверхбыстро, и аппетиты тоже будь здоров, но очень хорошо масштабируется, поэтому заказчик стиснув зубы терпит тормоза и заранее откладывает на железо. Вопрос: почему бы разработчикам из BEA не взять и не подкрутить там чего-нибудь, чтобы она вдобавок к масштабируемости ещё и забегала побыстрей (уж не до полётов)? Заодно конкурентов, там задвинут подальше...
N>Прости, но вы performance profile делали? Есть большое подозрение что это application тормозит и дело не в weblogic вообще.
Хи. А ещё у меня есть подозрение, что 2 GB нынче это не память. В действительности, аргумент работает в обе стороны — можно сказать, что железо неадекватно, а можно сказать, что софт слишком мрачный. Но я бы предпочёл не развивать эту тему... присоединяйся
Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Курилка,
К>>Кстати вот интересное письмо Тобиас Линдал ещё написал, где упоминал разрабатываеммый Typer для эрланга (подробней — http://www.it.uu.se/research/group/hipe/papers/typer.pdf)
LCR>Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
F>> Ну хорошо, но как связана интерпретакция с throughput-ом? Всё зависит от того что интерпретируем. Короче меряемся неизвестно чем, хотя бы попугаи были. Так что бестолковый разговор.
N>Ты всерьез веришь что Erlang сможет построить динамическую веб страницу быстрее Java или .NET?
Страница странице рознь
Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
VladD2 wrote: > C>Поколения на Эрланговском GC с недавнего времени тоже есть. Причем они > C>работать будут заметно эффективнее, чем в .NET (не нужен write barrier). > Извини. Меня не интересуют пустые слова. Будут данные, подходи. > А write barrier просто пушинка супротив интерпретатора и динамики.
Ну так я не утверждаю, что сам язык в целом быстрее. Попробуй набросать
мне план проверки производительности именно GC — я могу попробовать его
реализовать.
> C>Ну а JIT — это к GC не относится. > Еще как отностится. Есть две системы с разными проектными решениями. У > одной поколенчатый ЖЦ, возможность модифицировать данные в хипе, > компилирумый код.
GC с поколениями УЖЕ ЕСТЬ в Erlang.
> У второй интерпретация, своя схема ЖЦ, и т.п. Слушать > разглагольствования о теоритическом превосходстве просто нет желания. > Тут можно говорить только о эксперементальном подтвержедении.
А ты сравни теоретическую модель с крутым GC и крутым JITом одновременно.
> C>Из-за JIT'а — запросто. Собственно, для числодробилок и прочего Эрланг > C>совершенно из-за этого не подходит. > Ну, вот сдается мне, что из-за джита и не только он может и во многих > других местах отстать. А тут только и слышно что диферамбы его спер > производительности без оглядки на задачи.
Где ты такие видишь? Большинство Erlang'истов вполне понимают
ограничения Erlang'а.
Здравствуйте, Mamut, Вы писали:
M>Страница странице рознь M>Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
Ну, вполне может быть, no silver bullet так сказать. Только что это за мифическая задача — пока никто сформулировать не смог. JSP разумеется изначально в байт код транслируются.
VD>Кстати, подумалось, что для большинства задач реального мира было бы достаточно исползовать и потоки ОС. Все же найти задачу где действительно потребовлось бы запускать 100 и более параллельных потоков (не спящих) не так то просто. А на сотнях потоков все и так будет работать на ура. Учитывая же, что эти потоки скорее всего и так загрузят процессор по самое нехочу можно сказать, что решение будет более чем жизныенным и востребованным.
В рассылке по Эрлангу рассматривался такой вот подход к созданию веб-приложений:
Например, чат. На каждую комнату выделяется один supervisor, каждое подсоединение — отдельный процесс, обмениваются между собой посылкой сообщений. Круто, да? В рамках Эрланга задача тривиальна и для небольших сайтов даже реализуема.
n0name2,
N>Pure Java messaging servers (SoniqMQ например) легко делают 16к сообщений/сек на примерно томже железе и они более масштабируемы т.к. добавление еще 2-4-8 ядер для таких задач легко даст практически линейный рост.
Интересно. Данные впечатляют, даже если дать скидку на то, что передаваемые сообщения бывают разные и цифры округлены в большую сторону... В-общем, я хочу подробнее разобраться, откуда такой чудо-throughput, и обсудить как-нибудь потом в тематическом форуме.
Курилка,
LCR>>Идея неплохая, но здесь на мой взгляд нужно либо ничего, либо нужна поддержка ИДЕ в виде комплита. А так, натравливать тулзу на выстраданные потом и кровью исходники — страшно, даже несмотря на то, что тулзу делал Тобиас.
К>В смысле "страшно"?
Тулза вставляет гварды — ограничения на типы — в исходник. Производится глобальная модификация исходника. А если мой файл некорректный (ну там случайно скобку стёр, или вместо тупла список вколотил)? Лучше пусть это делает hipe. Ну или на крайний случай руками.
M>>Страница странице рознь M>>Скажем, ErlyWeb компилирует страницы в файлы .beam (Эрланговский байт-код). А если взять в качестве базы данных Mnesia, которая также крутится внутри Эрланговской VM, то на определенных задачах Yaws может и порвать Яву.
N>Ну, вполне может быть, no silver bullet так сказать. Только что это за мифическая задача — пока никто сформулировать не смог. JSP разумеется изначально в байт код транслируются.
Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
Но вот если это уже будут данные, которые неизвестно откуда берутся (например, из базы), то тут уже все не так однозначно. Потому что сформулировать задачу для такого теста будет очень сложно (потому что неизвестно, согласно каким критериям и что оценивать )
Здравствуйте, Mamut, Вы писали:
M>Кстати, вопрос. Что понимать под динамической страницей? Если это просто страница с расширением .erl, .yaws, .jsp и т.д. и статической информацией в них, то, боюсь, Erlang может здесь порвать всех согласно тесту Apache vs. Yaws
Java + NIO это совсем не Apache, на 100к юзеров оно не загнется. Думаю, слабо будет порвать Особенно на SMP. Если ты готов сделать benchmark для Yaws, то, можем попробовать.
M>Но вот если это уже будут данные, которые неизвестно откуда берутся (например, из базы), то тут уже все не так однозначно. Потому что сформулировать задачу для такого теста будет очень сложно (потому что неизвестно, согласно каким критериям и что оценивать )
Вообще, есть нормальные драйверы под Erlang для Oracle допусим?
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
):
)
