Comments 62
UFO just landed and posted this here
Т.е. код на erlang`е в 80-200 раз производительней чем в ruby? Интересно сколько ядер у них на серверах.
И да, и нет — в зависимости от того, что понимать под производительностью. Если количество серверов — да, Erlang более оптимально использует ресурсы сервера как раз для такиз задач. Если просто скорость исполнения линейного кода — совсем нет, в Erlang ужасная производительность операций со строками и математики (особенно с плавающей точкой), а ведь именно последнюю обычно проверяют во всяких бенчмарках,
«Пишлите, Шура! пишлите...» © :)
Ну в целом, учитывая что они фермы клепают, эрланг неплохой выбор.
А вот как быть с играми, в которых состояние это не банальный набор грядок, а где есть активные действия между игроками в реальном времени, котоые к тому же завязаны на довольно тяжелые расчеты коллизий и прочих вещей?
Всякие стрелялки и т.д. типа танковонлайн…
Сдается мне, что эрланг не потянет такое…
А вот как быть с играми, в которых состояние это не банальный набор грядок, а где есть активные действия между игроками в реальном времени, котоые к тому же завязаны на довольно тяжелые расчеты коллизий и прочих вещей?
Всякие стрелялки и т.д. типа танковонлайн…
Сдается мне, что эрланг не потянет такое…
Любые сложные расчёты лучше вынести куда либа, например NIF, OCaml, Clojure или что больше нравится. Ничего плохого в этом нет, такова общепринятая практика.
Вынести то можно… только что тогда останется? просто обработка входящего пакета и отправка его в нормальный сервер, который уже все сделает?
Тогда выигрыш будет ничтожным… если вообще будет.
Тогда выигрыш будет ничтожным… если вообще будет.
Будет-будет. Вы просто не представляете, как удобно обрабатывать подключения пользователей в э-ге. =)
Да при чем тут удобство то?
Мне в скале тоже просто отлично все обрабатывается)
Я про то, что все равно будет 80-200 серверов на чем тяжелом для всех расчетов и 1 (ну или парочка) серверов на эрланге для обработки подключений… и это не ничем не отличается от просто 80-200 серверов орбабатывающих все.
Я не вижу тут профита. Разве чтоб можно было шильдик повесить «дезигн бай эрланг».
Мне в скале тоже просто отлично все обрабатывается)
Я про то, что все равно будет 80-200 серверов на чем тяжелом для всех расчетов и 1 (ну или парочка) серверов на эрланге для обработки подключений… и это не ничем не отличается от просто 80-200 серверов орбабатывающих все.
Я не вижу тут профита. Разве чтоб можно было шильдик повесить «дезигн бай эрланг».
Не, если у вас скала с акторами — почему бы и нет, ваш выбор. Там почти тот же эрланг, плюс-минус.
Профит в разделении логики поддержки соединения и бизнес-логики. Наличие фронтенда-роутера, позволяющего держать подвешенными тысячи подключений дает крутые возможности по балансировке нагрузки бэкэндов. Или, например, миграции бэкэндов между машинами «на лету» — повесить клиентов в режим ожидания, снять снапшот бэкэнда, перезапустить его на отдельной машине с повышенными квотами, сообщить клиентам «продолжаем».
Профит в разделении логики поддержки соединения и бизнес-логики. Наличие фронтенда-роутера, позволяющего держать подвешенными тысячи подключений дает крутые возможности по балансировке нагрузки бэкэндов. Или, например, миграции бэкэндов между машинами «на лету» — повесить клиентов в режим ожидания, снять снапшот бэкэнда, перезапустить его на отдельной машине с повышенными квотами, сообщить клиентам «продолжаем».
Не правильно. Можно так же паралельно через акторы обчисливать сложные рассчеты. Актеры — это не столько сетевая технология, как технология распаралеливания. Scala же и ее akka полный аналог актеров Erlang.
Емнип, ребята из Echo (JS-Kit) примерно так и делают — сервер на Erlang, бизнес-логика на Haskel (или на Scala, точно не помню, но на чем-то расово-функциональном), фронтэнд на JS.
Вот презентация про MMOG — www.erlang-factory.com/upload/presentations/297/PikkoServerErlangconference.pdf. Там есть неосвещенные моменты, но идея интересная.
Алсо, танки и прочее, назовем это instance-based, пишется по-другому. Если хочется эрланг — на нем пишется фронтенд, обрабатывающий пользовательские подключения и лобби, и управление бэкэндами, отдельные игры обсчитываются бэкэндами на других языках.
Алсо, танки и прочее, назовем это instance-based, пишется по-другому. Если хочется эрланг — на нем пишется фронтенд, обрабатывающий пользовательские подключения и лобби, и управление бэкэндами, отдельные игры обсчитываются бэкэндами на других языках.
Ха, прикольно. У дураков мысли сходятся))
Один в один мой сервак на Scala+Akka… прямо дежавю при чтении.
Один в один мой сервак на Scala+Akka… прямо дежавю при чтении.
О, а как вы решали вопрос взаимодействия игроков на разных Mast, выражаясь терминологией этой презентации?
Упрощенный пример: игрок с одного mast стреляет в игрока с соседнего mast, который в рейнжде оружия первого.
Упрощенный пример: игрок с одного mast стреляет в игрока с соседнего mast, который в рейнжде оружия первого.
Этот вопрос решен так, что сервер пока делается для конкретной игры, она сессионная.))
Т.е. запускается карта, на ней воюют игроки. Игрок понятия не имеет на каком он сервере.
При старте боя, игроки объединяются на одном сервере, чтобы все задержки свести к минимуму.
Это процесс настраиваемый и происходит динамически.
При этом механизмы миграции игроков и серверов, очень похожи на описываемые в презентации.
Но заданный вами вопрос интересен и он будет прорабатываться…
Если это интересно, можно будет статейку написать по результатам. Чего удалось добиться и как это все работает.
Т.е. запускается карта, на ней воюют игроки. Игрок понятия не имеет на каком он сервере.
При старте боя, игроки объединяются на одном сервере, чтобы все задержки свести к минимуму.
Это процесс настраиваемый и происходит динамически.
При этом механизмы миграции игроков и серверов, очень похожи на описываемые в презентации.
Но заданный вами вопрос интересен и он будет прорабатываться…
Если это интересно, можно будет статейку написать по результатам. Чего удалось добиться и как это все работает.
Сравнение с Akka непонятно. Говорится о интеграции, но при этом ничего не говорится о интеграции с Erlang.
Мне нравится Erlang, но какое-то одностороннее сравнение получилось.
Мне нравится Erlang, но какое-то одностороннее сравнение получилось.
В результате беглого знакомства с Erlang был больше всего впечатлён узкой специализацией его Garbage Collector и связанными с этим трюками, благодаря которой зачастую реально выполнить с ним soft real-time требования. Но с уменьшением количества ядер эффективность Erlang падает заметно, типичный пример очень хорошего инструмента для очень узкого класса задач.
Так никто и не позиционирует его, как серебрянную пулю.
Как это никто? Вся статья о том, как люди выбрали эрланг, выкинули нафиг 200 серверов и оставили 2.
Сплошные положительные эмоции, ни слова о недостатках…
Сплошные положительные эмоции, ни слова о недостатках…
В любом посте про бекенды на не ерланге, появляется ерлангер и пишет, что автор ничего не умеет, надо было на э-г. Потом появляюсь я и говорю, что «В любом посте про бекенды на не ерланге, появляется ерлангер и пишет, что автор ничего не умеет, надо было на э-г. Потом появляюсь я и говорю, что...»
Даже на однопоточной VM прекрасно живут десятки и сотни тысяч процессов. С эффективностью все ок.
«всё ок» в том смысле, что она не падает до уровня интерпретируемых языков? О да. Но и только. Не так давно тестировал Erlang/Cowboy в рамках экспериментов с веб серверами — на 8 ядрах было топовым решением с однозначно лучшим latency. На 2х в серединке и вся стабильность latency сошла на нет. То есть уже ничем не лучше любого другого умеренно адекватного решения.
Есть еще скорость разработки, простота поддержки, и тп. Если 2х ядер не хватает выгребать тестовый поток, то чуда, конечно, не случится.
А в этих областях Erlang ничем не примечателен.
2х ядер хватало для нативно компилируемых языков, речь идёт именно о том, что management overhead окружения заметно сказывается в таких условиях, пока вся сила системы многозадачности ещё не проявляется.
2х ядер хватало для нативно компилируемых языков, речь идёт именно о том, что management overhead окружения заметно сказывается в таких условиях, пока вся сила системы многозадачности ещё не проявляется.
Не удивительно. Любой опытный эрлангист может долго перечислять области и ситуации в которых Erlang ничем не примечателен, и ещё дольше те, где он вообще аутсайдер :)
Это, правда, совсем не мешает им ругаться и крутить пальцем у виска, когда кто-то не использует erlang (или модель акторов вообще) там, где он примечателен или станет примечателен в будущем при горизонтальном масштабировании.
Это, правда, совсем не мешает им ругаться и крутить пальцем у виска, когда кто-то не использует erlang (или модель акторов вообще) там, где он примечателен или станет примечателен в будущем при горизонтальном масштабировании.
Не очень большой оверхед, если честно. Если брать те же веб-сервера, на Erlang'е можно выкатить цельное решение, которое будет себя вести вполне прилично даже при скромном ресурсопотреблении. Оно быстро напишется, его будет удобно деплоить, обслуживать и развивать, ИМХО, годная овчинка, полезная в реальной жизни.
По личным впечатлениям — быстрее питона. Но в питоне, в то же время, больше библиотек, написанных на C.
Ерланг хорош исключительно для сетевых приложений, все что работает с сетью пишется на ерланге за милую душу. Работа с пакетами вообще выше всяких похвал.
Проблема в том что в остальном он не так хорош. Он не такой быстрый и проводить в нем тяжелые мат. расчеты это откровенная лажа. Он очень плохо работает с текстом, особенно с кодировками. В какойто новой версии это вроде бы обещали исправить(больше к сожалению об этом не слишал). На нем не очень удобно писать логику, так как ее приходится ломать под функциональный язык, на котором человек не думает.
Так же я общался с некоторыми дедами ерланга которые расказывали что в больших проектах не все так гладко как хотелось.
Так что увы Ерланг тоже не серебрянная пуля, хотя и заслуживает того что бы его знать и использовать под нишевые задачи.
Проблема в том что в остальном он не так хорош. Он не такой быстрый и проводить в нем тяжелые мат. расчеты это откровенная лажа. Он очень плохо работает с текстом, особенно с кодировками. В какойто новой версии это вроде бы обещали исправить(больше к сожалению об этом не слишал). На нем не очень удобно писать логику, так как ее приходится ломать под функциональный язык, на котором человек не думает.
Так же я общался с некоторыми дедами ерланга которые расказывали что в больших проектах не все так гладко как хотелось.
Так что увы Ерланг тоже не серебрянная пуля, хотя и заслуживает того что бы его знать и использовать под нишевые задачи.
А вот координировать тяжелые вычисления — в самый раз.
Пришел и написал, все то, что уже написали выше, смысл таких комментов?
В больших проектах лажа бывает из-за пространства имен, оно глобальное и каждый новый модуль должен иметь свое уникальное имя, так что если ты подключаешь чужие модули — иногда бывают конфликты.
Логику на нем нормально писать, не надо себя проецировать на всех людей, человек прекрасно думает в терминах функционального языка, даже лучше императивного. Более того, так как язык полностью immutable о коде можно вести разумные рассуждения, потому что он предсказуем.
В больших проектах лажа бывает из-за пространства имен, оно глобальное и каждый новый модуль должен иметь свое уникальное имя, так что если ты подключаешь чужие модули — иногда бывают конфликты.
Логику на нем нормально писать, не надо себя проецировать на всех людей, человек прекрасно думает в терминах функционального языка, даже лучше императивного. Более того, так как язык полностью immutable о коде можно вести разумные рассуждения, потому что он предсказуем.
Логику нормально писать на любом production-языке. Проблема в том, что разные языки предоставляют разной степени выразительности различные парадигмы для выражения и структуризации бизнес-логики, и _каждая_ парадигма сильно ограничивает возможности. За это любят пайтон и руби — они весьма выразительны и мультипарадигменны, что позволяет лаконично делать то, что удобнее программисту, а не компилятору/интерпретару языка программирования.
В этом смысле эрланг очень сильно ограничивает возможности и заставляет усложнять логику, просто из-за ограниченности парадигмы чистого функционального программирования.
В этом смысле эрланг очень сильно ограничивает возможности и заставляет усложнять логику, просто из-за ограниченности парадигмы чистого функционального программирования.
из-за ограниченности парадигмы чистого функционального программирования
Erlang — не чисто функциональный язык, в отличие, например, от Haskell. Да и функциональная парадигма, при небольшой привычке, часто порождает более естественную, ясную и тестируемую логику.
Скажу в терминах математики. Допустим логика человека это А, лоигака программы это Б, Ф это отображение А в Б.
Функциональный язык имеет довольно сложную фукцию Ф, в то время как императивне имеют более простую. Именно по этой причине сложно писать логику. Второй момент который видимо забывают это то что логику в играх пишут не девы а геймдевы. А они от языков крайни далеки, а особенно от функциональных.
К примеру World Of Tanks крутиться на Сишном двигле, но игровая логика написана на пайтоне, что бы упростить жизнь геймдевам.
Есть к примеру язык для описания логики, который часто в школах учат. Он крайне похож на бейсик или пыху, но не на функ. язык. Уже из этого можно сделать кое какой вывод.
Простота тестируемости о которой выговорит вообще не связана с простотой логики… просто в функ. языках отловить ошибку крайне просто ввиду мат описуемости языка. В ерланге к примеру есть тулза которая строит график логики приложения. В императивных языках такое можно получить только через страшные костыли.
Функциональный язык имеет довольно сложную фукцию Ф, в то время как императивне имеют более простую. Именно по этой причине сложно писать логику. Второй момент который видимо забывают это то что логику в играх пишут не девы а геймдевы. А они от языков крайни далеки, а особенно от функциональных.
К примеру World Of Tanks крутиться на Сишном двигле, но игровая логика написана на пайтоне, что бы упростить жизнь геймдевам.
Есть к примеру язык для описания логики, который часто в школах учат. Он крайне похож на бейсик или пыху, но не на функ. язык. Уже из этого можно сделать кое какой вывод.
Простота тестируемости о которой выговорит вообще не связана с простотой логики… просто в функ. языках отловить ошибку крайне просто ввиду мат описуемости языка. В ерланге к примеру есть тулза которая строит график логики приложения. В императивных языках такое можно получить только через страшные костыли.
С чего это Erlang не чистый функциональный язык? :). В нем даже переменных нету в отличие от того же Haskell, нету ООП и процедурщины. Вполне себе чистый функциональный язык.
По поводу выразительности, берем Elixir и получаем язык похожий на Ruby. Да и очень спорно, что Erlang не выразительный, как и любой функциональный язык — он вполне себе выразительный.
По поводу выразительности, берем Elixir и получаем язык похожий на Ruby. Да и очень спорно, что Erlang не выразительный, как и любой функциональный язык — он вполне себе выразительный.
Вообще говоря у акторов может быть shared state, что сразу делает язык не «чисто функциональным».
Относительно Elixir'а вы несколько загнули — это скорее загибающаяся на сегодняшний день штука для тех, кому трудно освоить синтаксис эрланга.
Относительно Elixir'а вы несколько загнули — это скорее загибающаяся на сегодняшний день штука для тех, кому трудно освоить синтаксис эрланга.
С чего это Erlang не чистый функциональный язык?
В нем даже переменных нету
Как минимум есть put, использовать который, разумеется, очень плохая практика. Ну и вообще бОльшая часть логики приложений на Erlang зиждется на последовательности посылаемых сообщений, т.е. реализации протокола, что по своей сути глубоко императивно. Любая функция может «изменить состояние мира» даже без всяких мутабельных структур данных и переменных.
Сравните с Haskell, где работа, к примеру, с файлом невозможна из функции, не имеющей IO монады в сигнатуре (есть, конечно, unsafePerformIO, но он нужен лишь в крайних ситуациях, в основном для вызова чистых по сути функций через FFI).
По поводу выразительности… Мне Erlang не кажется сильно выразительным языком. Часть «выразительности» ему придаётся стандартной стратегией обработки ошибок: падаем и откатываемся на предыдущее состояние (или эскалируем падение). Это отбрасывает довольно много проверочного кода, необходимого в других языках. Ну и сопоставление с образцом весьма облегчает жизнь.
Мне лично по выразительности больше нравится Scala. К сожалению, она гораздо сложнее Erlang и перегружена семантикой.
Его можно использовать на одном сервере в паре с другим языком? Например прослойка на Erlang которая для вычисления передает все в какую то часть написанную, скажем, на Python/Ruby/PHP?
Естественно, можно.
Например, bert-rpc.org
Go точно так же подходит под аргументы статьи — язык изначально заточен под удобную параллелизацию, и есть удобная синхронизация между серверами. И, да, не приходится насиловать бизнес-логику дополнительным разбиением на 100500 функций, потому что immutable переменные и прочие ограничения.
Абсолютно верное замечание.
Как я понимаю, ничего похожего на OTP и supervision tree там в комплекте не идёт? На самом деле крайне важная вещь.
Нет, не идёт. Стандартная библиотека выглядит неплохо, но супервизоров при необходимости нужно реализовывать самим. Кстати, мне кажется, в Go это сделать «правильно» под конкретную задачу с использованием горутин и каналов несколько проще, чем было бы в Erlang на spawn_link, не будь стандартных поведений.
По удобству супервизоров, конечно, Erlang впереди.
По удобству супервизоров, конечно, Erlang впереди.
Говоря другим языком, они создали веб сервер для хранения состояния игроков, это значит, что каждый игрок, который ирает в данный момент, обслуживается отдельным актором внутри Erlang VM
Решение проблемы фактически архитектурное. И аналогичный «актор», написанный на любом другом языке дал бы такой же прирост производительности.
вот почему все постоянно говорят про параллелизм (concurrency)Не стоило переводить concurrency как «параллелизм» (parallelism). Это совершенно разные, хоть и связанные, концепции: Rob Pike: Concurrency Is Not Parallelism
Эрланг хорош не только и не столько встроенной поддержкой акторов, а ещё и наличием отличных примитивов для построения сложных отказоустойчивых систем, «поведений» (behaviours); серверов, обработчиков событий, супервизоров, приложений. Без OTP Erlang был бы совсем не так интересен.
И, конечно, нужно упомянуть практическую возможность горячей замены кода.
Sign up to leave a comment.
Почему Erlang?