Хочется понять говно ли эрланг

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

И то что реализация диамитера на эрланге говно ни разу не говорит о том что эрланг говно.

Хочется понять говно ли эрланг

benchmark

Способ детектирования говна не очень

да r в соседнем треде где-то приводил ссылки на сравнение с плюсами. ерланг сливает сильно в плане производительности.

Ок. Сформируем по другому, если в диваметр в эрланге говно, он будет говном для моей задачи, где диаметер важен

Школьники меряются пиписьками: «Кукурузник быстрее мерседеса => мерседес говно»

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

Да я тоже хотел это написать, но не успел.

Возми да запили и проверь. Там есть готовые примеры сервера и клиента, скомпиль и тести.

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

ты неправильно вопрос ставишь - будут всегда мучить сомнения )

Стукнись на контакт в профиле. Завтра попробуем сделать

Кукурузник - это Ан-2 что ли? Тогда немало мерседесов легко заткнут его за пояс.

Я бы не парился. Всегда можно взять с++ и написать nif! хаха.

Nif может скрешить всю vm. Так что тут нужна особая осторожность. Лучше уже port. В любом случае без тестов нечего говорить о тормознутости, надо проверять.

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

Эрланг — это не про бенчмарки, это про другое. И в телекоме считается крутым за другие особенности.

Представьте себе интерпретатор, например, перла (да, считает он небыстро), который запускает одновременно миллионы скриптов. При этом не даёт процессору простаивать сразу подставляя вместо заблокированного какой-нибудь другой. Присутствует миграция как между потоками ОС, так и между разными хостами. Т.е. не хватает производительности — добавь в кластер ещё один сервер.

Плюшки для телекома. Синтаксис заточен под разбор бинарных протоколов и реализацию стейт-машин. Соответственно, писать легко и приятно, а ошибок — мало (т.е. ещё и быстро). Переставлять байты без сложных вычислений довольно шустро получается.

На практике. Диаметр мне никогда не был нужен. Эксплуатирую amqp. 2-сокетный сервер способен с некоторым скрипом перемалывать 50k сообщений/сек (приём, маршрутизация, отдача). За 2 года был один инцидент со вставшим в интересную позицию кластером (т.е. наиболее популярная реализация — beam.smp — таки не безгрешна в плане кластеризации).

Всё руки не доходят погонять это дело под jit-ом llvm.

// тот самый анонимус, который считает, что вы нихрена не знаете кресты :)

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

с прямыми руками, любая задача на С++ всегда будет в выиграше

Знаешь, меня тоже по-началу удивляло, что в AT&T часто рекомендуют использовать язык Си и рекомендуют НЕ использовать язык Си++, хотя вроде бы оба вышли из стен ее лабораторий (Bell Labs). По крайней мере, Си++ точно вышел оттуда.

Конечно же говно. Чего там понимать-то? Все очевидно.

Основывая на чём можно выбрать OCamL или Erlang или Haskell (комментарий)

Что такое «реализация диаметра» в твоём понимании?
Это всего лишь протокол, а не какой-то набор алгоритмов

50kpps? маловато однако, на сях можно раз в 15-20 прокачивать на четырехядернике, без особых напрягов

15-20 раз в секунду? Вот вам и ПРАИЖВАДИТЕЛЬНОШТЬ говняшной.

Реализация протокола DIAMETER.

А в телекоме активно используется протокол DIAMETER

в слове «DIAMETER» очень много ошибок. «RADIUS» - вот так правильней будет.

это я про «активно», если чё :)

ТС, ты путаешь тёплое с зелёным.
Во-первых, не DIAMETER, а Diameter
Во-вторых, он работает на Application layer, то есть эффективность зависит от приложения его использующего, именно в нём должны настраиваться все таймеры, буферы и тд

Всегда можно взять с++ и написать nif! хаха.
xaxa

Это как бы зловещий смех был. Походу ты не понял, всей иронии.

Radius несколько устарел

Спасибо, что ты мне это рассказал, а то я не знаю что такое Diameter! Речь идет о простейшем бенчмарке? когда приложение принимает команду, например CCR и отвечает CCA, просто перекладывая большинство полей из запроса. Таймеры в этом случае особо не должны влиять. Буфера, в случае не кривой реализации тоже.

Речь идет о простейшем бенчмарке?

Вот и я пытаюсь понять о какой эффективности реализации идёт речь.
Обычно всё сожрёт либо транспорт (TCP), либо I/O в DB биллинга.

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

Мне эрланг на первый взгляд непонраился отсутвием классов и структур. Мне кажется, что это замедлит разработку и увеличит количество ошибок. У нас для каждой диаметровой команды заведен класс (точнее 2 - один для входящих, другой для исходящих). У этого класа есть поля, каждое поле имеет свой тип. Т.е. если это enum, то это enum. У тебя без особых ухищрений нет способа добавить avp которой нет в описании команды. Даже просто редактор дает автоподстановку методов.

я бы так не сказал. в диаметр заложен дюже большой оверхед. циски вон, вполне себе отлично реализовали ISG на базе радиуса и вполне себе хорошо живет. более того, диаметр работает в tcp стеке, что накладывает существенный отпечаток в производительности, чего не сказать про радиус. кстати, автор freeradius по этому поводу тоже писал, что за диаметр не возьмется, покуда он сильно перегружен и из простого ААА из него пытаются сделать монстра. это то же самое, как с SOAP - круто, но аццки тяжеловесно и трудоемко в разработке. зато да, ынтерпрайзненько :). диаметр пользуется популярностью лишь у мобильных оперов. там да, его юзают во все поля, но обычные интернет провайдеры обходятся обычным радиусом.

PS: знаю это потому как ШПД билайна я разрабатывал (там мобила пользует диаметр, а вот домашний инет - исключительно на радиусе).

Нам никуда не деться, мы используем стандартные протоколы. если оборудование (PCEF, DPI) хочет диаметер, значит будет он.

Ёпланг - динамически типизированная какашка. Не пачкайся об нее.

PCEF

PCRF?

Мы делаем PCRF

Мы делаем PCRF

Peter-Service?

так ведь, действительно, говно же, по сравнению с кукурузником. вот в способны на мерседесе пересечь океан? а Чкалов на кукурузнике пересёк

см. выше

Свят-свят-свят... Yota

Ок. Сформируем по другому, если в диваметр в эрланге говно, он будет говном для моей задачи, где диаметер важен

Прицепи к Эрлангу парсер/генератор протокола, написанный на C++, делов-то. Вы ведь на плюсах веб-морду и скрипты сценариев писать не будете?

Или будете?..

Ёпланг - динамически типизированная какашка. Не пачкайся об нее.

Как-будто C++ какие-то гарантии даёт?

Мне эрланг на первый взгляд непонраился отсутвием классов и структур

структуры там есть

структуры там есть

Там все есть для удобного решения подходящих задач. ТС просто «ниасилил» или не захотел «асилить».

У меня нет задачи изучить все языки программирования

Как-будто C++ какие-то гарантии даёт?

не обращай внимание, мальчик на паскале вырос :)

Утверждается ведь, что эрланг крут именно в этом

Эрланг крут если тебе надо писать вычислительно несложные штуки с большим сетевизмом. Под сетевизмом подразумеваются много разных всяких нодов. Либо если задачи производительно-сложные можно форкнуть в C и звать из эрланга. Если у тебя задача - высокопроизводительная обработка сложных структур - эрланг тут сольет по производительности. Если задачу можно линейно масштабировать - то он выиграет по простоте реализации. Если у тебя большие структуры (под большими я имею ввиду много многомегабайтные) - эрланг сольет по производительности.

Чем erlang в этом смысле хуже той же clojure?