Здравствуйте, Joie de vivre, Вы писали:
M>>При желании. Можно нписать. В упрощенном виде. Ага-ага. Свежо предание, только нифига не существует. JDV>Различные схемы failover-а люди и без эрланга реализовывают.
И какой объём заката солнца вручную в каждом случае для того, что в OTP уже есть и активизируется, грубо говоря, тремя стандартными строчками?
Здравствуйте, so5team, Вы писали:
S>Это намек на AXD301? Так ведь Ericsson не смог написать его без С и C++, что характерно.
Так ведь никто сейчас не пишет даже компилятор C++ без C и C++, что характерно
AXD301 имел сишный код, да. В драйверах работы с оборудованием. Для реализации самого Erlang. И в куче других достаточно очевидных для этого мест. А ещё там, представляешь, ассемблер был. Там, где надо написать то, что вообще не вкладывается в парадигму сишной функции — аналогично тому, как Java не может запустить саму себя, пока кто-то должен вызвать ${mainclass}.Main
S>Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике.
Нужна ли там эта скорость? Или важнее другие характеристики?
Здравствуйте, so5team, Вы писали:
S>Приводя в 2015-ом году данные замеров от 2009-го года вы рассчитываете, что вас будут принимать сколько нибудь всерьез?
Нет, рассчитываю, что собеседники либо приведут более современное опровержение замеров, либо сядут ровно.
S>Ну вы бы на динамику обратили внимание. Nginx появился намного позже Apache и свою долю постоянно увеличивает.
Ну вот прямо сейчас динамика его доли — -0.45%. Ещё раз: давайте не будем решать технические вопросы голосованием, или приводить цифры популярности в разговорах о техническом совершенстве.
S>О чем же? Софт для телекома пишут на C++ без Erlang-а давно и успешно.
Ну и веб-сервера тоже пишут давно и успешно. Зачем писать мегабайт эрланг-кода, когда можно обойтись втрое большим объёмом С-кода, не так ли?
S>Нет, публично доступных в Web-е нет.
Ну, приведите хотя бы результаты приватных замеров. Я даже поверю вам на слово, несмотря на невозможность лично запустить ваш бенчмарк.
S>Да ладно.
И где там Эрланг/Yaws?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Sinclair, выньте наконец голову из убогого .NET-овского мирка. Посмотрите хотя бы на Scala+Akka или на то, что LinkedIn делает вообще на голой Java. S>Я посмотрел. Если у вас есть пример более шустрого HTTP-сервера на "голой Java", чем MochaWeb, то мы можем попытаться найти для него метрики производительности. S>Потому что MochaWeb как-то не впечатляет.
Если вам нечем заняться, то попробуйте зарулить всех на Erlang-е вот в этом аттракционе.
Кроме того, речь шла не об HTTP-серверах, а о вещах вроде Kafka (которую следует сравнивать с RabbitMQ) или Pinot.
Здравствуйте, so5team, Вы писали:
S>Кроме того, речь шла не об HTTP-серверах
Это я уже заметил — что сначала собеседники кричат "примеров!", а когда их тычешь носом, говорят "у вас не те примеры!".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Ikemefula, Вы писали:
I>Правильно. Потому ручная диспетчеризация асинхронного кода — адский АДъ. В многопоточном коде ты можешь остановить все потоки и глянуть, что же там не так. В асинхронном коде у тебя такого фокуса нет. И многих других — тоже нет.
Мнэээ... а вот тут уже непонятно. А почему нельзя?
У шедулера такого кода есть в явном виде очередь отложенных задач, которые чего-то ждут (внешнего события или просто таймера). Остановить их всех — задача чисто техническая. Манипулировать этой очередью на ходу — тоже.
Более того, в отличие от многонитевости на мьютексах, у тебя нет проблемы того, что ты не можешь прервать выполнение треда, не приведя к тяжёлому разрушению состояния всего процесса (и не только). Только текущая активность, пока она снова не создала future и не закончилась; с ней могут быть проблемы, но не более того.
Ситуация же "два асинхронных мьютекса и будут бесконечно пулять две задачи при асинхронном дедлоке" ((c)vdimas) вылавливается там "на раз" и соответственно отстреливается. Это не так удобно, как в Erlang+OTP, где ты можешь убить любой внутренний процесс без разлома полной работы, но ближе к тому.
V>>А изобретателей асинхронных мьютексов вменяемые разработчики давно послали туда, где им место. V>>Это же надо было, вместо того, чтобы создать нужные зависимости, додуматься тупо отпуливать таски в конец очереди... бррр... )) I>Не только не послали, но и активно развивают это направление. Ибо — дёшево.
Надеюсь, до определённого количества таких отпуливаний? Потому что зациклить таки элементарно.
Здравствуйте, so5team, Вы писали:
S>>>Смотря на каких задачах. Если в ситуациях, когда все 100K нитей готовы к работе и нуждаются в кванте процессорного времени, то еще более интересно, как с такой ситуацией будет справляться расхваливаемый здесь Erlang. S>>Такая ситуация — это ошибка дизайна, на более-менее любой системе. Поясню очевидное: S>В сухом остатке получается, что возможность Erlang-а создать 100K процессов является лишь маркетинговой фишкой, которая далеко не всегда будет востребована на практике.
Вполне реальная фишка, для ситуаций типа "слэшдот-эффект".
Здравствуйте, Sinclair, Вы писали:
S>>Приводя в 2015-ом году данные замеров от 2009-го года вы рассчитываете, что вас будут принимать сколько нибудь всерьез? S>Нет, рассчитываю, что собеседники либо приведут более современное опровержение замеров, либо сядут ровно.
Смысл сидеть ровно и смотреть на результаты замеров от 2009-го года, когда Nginx уже выпустил несколько мажорных версий с тех пор? Тогда Yaws и Nginx могли идти вровень. Как сейчас -- не понятно. Зачем сейчас верить тому, что было пять с половиной лет назад?
S>>Ну вы бы на динамику обратили внимание. Nginx появился намного позже Apache и свою долю постоянно увеличивает. S>Ну вот прямо сейчас динамика его доли — -0.45%. Ещё раз: давайте не будем решать технические вопросы голосованием, или приводить цифры популярности в разговорах о техническом совершенстве.
Техническое совершенство получается синонимом сфероконя в вакууме. Если мифический Yaws или MochaWeb так хороши, то где они?
Люди не так глупы, как вам кажется. Когда Nginx начал уделывать Apache в раздаче статического контента, это сразу стало востребовано и доля Nginx стала расти.
Где реальные преимущества Yaws/MochaWeb в сравнении с тем, что уже есть? Может все эти преимущества есть только в одном-единственном бенчмарке, проведенном не понятно кем, непонятно как пять с половиной лет назад?
S>>О чем же? Софт для телекома пишут на C++ без Erlang-а давно и успешно. S>Ну и веб-сервера тоже пишут давно и успешно. Зачем писать мегабайт эрланг-кода, когда можно обойтись втрое большим объёмом С-кода, не так ли?
Сам по себе объем кода не имеет значения. Важно то, насколько стоимость разработки/сопровождения соотносится с получаемой в итоге прибылью. Если бы Yaws был настолько же успешен и востребован, как Nginx, можно было бы говорить о том, что за счет меньшего объема кода издержки на развитие Yaws ниже, посему с экономической точки зрения использование Erlang-а в подобной разработке выгоднее.
Но Yaws нужно разыскивать в микроскоп. Вот в чем дело.
S>>Нет, публично доступных в Web-е нет. S>Ну, приведите хотя бы результаты приватных замеров. Я даже поверю вам на слово, несмотря на невозможность лично запустить ваш бенчмарк.
Наиболее характерный пример: обработка больших объемов текстовых файлов с извлечением информации для биллинга на динамическом Ruby занимала больше 24-х часов. Переписанная на C++ стала занимать около 5 минут. Про различия скорости парсинга и формирования бинарных данных, логирования, подготовки запросов к БД между C++ и динамическими языками, вроде Ruby и Python и говорить не приходится, там счет идет на порядки. Насколько я помню, на задачах обработки данных Erlang показывал себя не лучше Python-а.
Вполне возможно, что кода речь идет о том, чтобы принять от C-шного кода 200 байт, создать лековесный процесс, который толкнет эти 200 байт в какой-то другой C-шный код, Erlang рулит и бибикает. Но Python и Ruby будут бибикать здесь не хуже, т.к. все самое тяжелое написано вовсе не на Erlang-е.
S>>Да ладно. S>И где там Эрланг/Yaws?
Здравствуйте, Sinclair, Вы писали:
S>>Кроме того, речь шла не об HTTP-серверах S>Это я уже заметил — что сначала собеседники кричат "примеров!", а когда их тычешь носом, говорят "у вас не те примеры!".
Sinclair, вы ветки попутали. HTTP-сервера обсуждаются в другом месте. А судя по тому, что вы оперируете результатами бенчмарков от 2009-го года, то еще и в другом времени.
Здравствуйте, netch80, Вы писали:
N>AXD301 имел сишный код, да. В драйверах работы с оборудованием. Для реализации самого Erlang. И в куче других достаточно очевидных для этого мест.
Из того, что до меня доходит про использование Erlang в реальном мире, складывается ощущение, что Erlang без С или C++ не справляется с более-менее серьезными нагрузками.
S>>Ну и да, доводилось писать софт для работы с GSM/SMPP/UCP на C++. Отлично пишется, удобнее чем на Java и работает быстрее, чем на Erlang-е или какой-нибудь другой динамике.
N>Нужна ли там эта скорость? Или важнее другие характеристики?
Когда пропускная способность одного SMPP-канала должна превышать 200sms/sec скорость оказывается важна.
Здравствуйте, so5team, Вы писали:
S>Смысл сидеть ровно и смотреть на результаты замеров от 2009-го года, когда Nginx уже выпустил несколько мажорных версий с тех пор? Тогда Yaws и Nginx могли идти вровень. Как сейчас -- не понятно. Зачем сейчас верить тому, что было пять с половиной лет назад?
За неимением лучшего. Ваш К.О. Yaws тоже, судя по гитхабу, эти пять с половиной лет не на печи лежал.
S>Техническое совершенство получается синонимом сфероконя в вакууме. Если мифический Yaws или MochaWeb так хороши, то где они?
Нет, техническое совершенство — это объективная реальность. Есть набор измеримых показателей. Например, перформанс в интересных нам сценариях, и объём кода (от которого напрямую зависит стоимость разработки и поддержки).
А популярность — штука субьективная. Стас Михайлов популярнее Металлики, а PHP — популярнее C#.
Когда мы принимаем решение, кого использовать для нашего будущего проекта, надо выбирать по техническим и экономическим характеристикам. А когда выбираем, кого позвать на корпоратив — по популярности. Наоборот делать не нужно.
S>Люди не так глупы, как вам кажется.
Разумеется, они значительно глупее.
S>Где реальные преимущества Yaws/MochaWeb в сравнении с тем, что уже есть?
Мы говорим не про преимущество Yaws. Мы говорим о том, что написать высокопроизводительный веб-сервер на С/С++ требует в три раза больше времени и нервов, чем на Erlang.
Это отвечает на вопрос топика. S>Сам по себе объем кода не имеет значения. Важно то, насколько стоимость разработки/сопровождения соотносится с получаемой в итоге прибылью.
Совершенно верно. S>Но Yaws нужно разыскивать в микроскоп. Вот в чем дело.
Вы опять мне пытаетесь продать Стаса Михайлова.
S>Наиболее характерный пример: обработка больших объемов текстовых файлов с извлечением информации для биллинга на динамическом Ruby занимала больше 24-х часов. Переписанная на C++ стала занимать около 5 минут.
Вы обещали показать GSM-роутинг на C++, а показываете парсинг текста на Руби. Давайте вы сделаете вид, что вы не жульничали, а я — что я этого не заметил.
S>Вполне возможно, что кода речь идет о том, чтобы принять от C-шного кода 200 байт, создать лековесный процесс, который толкнет эти 200 байт в какой-то другой C-шный код, Erlang рулит и бибикает. Но Python и Ruby будут бибикать здесь не хуже, т.к. все самое тяжелое написано вовсе не на Erlang-е. В задаче "принять 200 байт из сокета, отпарсить, и отправить в другой сокет" всё самое тяжёлое — ровно здесь. И оно, будучи написанным на эрланге, цветёт и летает.
S>Вот именно, где там Erlang?
Да там и ASP.Net не участвует. Зато всяких PHP — в ассортименте. Из чего я делаю вывод, что про быстродействие эрланга ваша страница никакой информации не даёт.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Смысл сидеть ровно и смотреть на результаты замеров от 2009-го года, когда Nginx уже выпустил несколько мажорных версий с тех пор? Тогда Yaws и Nginx могли идти вровень. Как сейчас -- не понятно. Зачем сейчас верить тому, что было пять с половиной лет назад? S>За неимением лучшего. Ваш К.О. Yaws тоже, судя по гитхабу, эти пять с половиной лет не на печи лежал.
Ну так покажите свежие результаты. А то ведь можно попробовать сделать выводы о скорости работы Java на основании замеров 2000-го года, а то и 1995-го.
S>>Техническое совершенство получается синонимом сфероконя в вакууме. Если мифический Yaws или MochaWeb так хороши, то где они? S>Нет, техническое совершенство — это объективная реальность. Есть набор измеримых показателей. Например, перформанс в интересных нам сценариях, и объём кода (от которого напрямую зависит стоимость разработки и поддержки).
Ну и? Есть Nginx, который используется тысячами админов и который должен удовлетворять их насущным требованиями.
И есть Yaws, который нахрен никому не упал.
Объем кода никому не нужной херни в три раза меньше объема кода продукта, который ежедневно используется тысячами людей.
Вы хотите сделать из этого какие-то выводы о техническом совершенстве? Флаг вам в руки.
S>Разумеется, они значительно глупее.
Корона не жмет?
S>>Где реальные преимущества Yaws/MochaWeb в сравнении с тем, что уже есть? S>Мы говорим не про преимущество Yaws. Мы говорим о том, что написать высокопроизводительный веб-сервер на С/С++ требует в три раза больше времени и нервов, чем на Erlang.
Во-первых, разница в объеме кода не должна 1-в-1 соответствовать разнице в количестве времени и нервов.
Во-вторых, Nginx и Apache написаны на C. Не нужно приплетать сюда C++.
S>>Но Yaws нужно разыскивать в микроскоп. Вот в чем дело. S>Вы опять мне пытаетесь продать Стаса Михайлова.
Я вам пытаюсь указать, что объем работы над широковостребованным продуктом будет больше, чем над никому не нужной херней. Отсюда напрямую будет и разница в объеме кода.
S>>Наиболее характерный пример: обработка больших объемов текстовых файлов с извлечением информации для биллинга на динамическом Ruby занимала больше 24-х часов. Переписанная на C++ стала занимать около 5 минут. S>Вы обещали показать GSM-роутинг на C++, а показываете парсинг текста на Руби. Давайте вы сделаете вид, что вы не жульничали, а я — что я этого не заметил.
Это была часть роутинга, состоявшего из нескольких взаимосвязанных между собой компонентов. Один из них был написан на динамически-типизированном Ruby. Когда тормоза этого компонента превысили границы допустимого, он бы заменен на более быструю реализацию.
S> В задаче "принять 200 байт из сокета, отпарсить, и отправить в другой сокет" всё самое тяжёлое — ровно здесь. И оно, будучи написанным на эрланге, цветёт и летает.
Ну да, ну да. Вы вот сами что-нибудь подобное на Erlang-е делали?
S>>Вот именно, где там Erlang? S>Да там и ASP.Net не участвует. Зато всяких PHP — в ассортименте. Из чего я делаю вывод, что про быстродействие эрланга ваша страница никакой информации не даёт.
Здравствуйте, Ikemefula, Вы писали: I>Это за того самого недетерминированого порядка выполнения. Смотри внимательно мой пример.
Да он всё время тешит себя иллюзией, что весь асинхронный код сводится к I = I + 1.
При стандартных для x86 определениях = и +.
А то, что на самом деле I = I + 1 в интересных нам приложениях означает I = GetRemoteResource("I"); SetRemoteResource("I", I.Add(GetRemoteResource("1"));, где каждая из трёх операций — это долгое ожидание, он предпочитает игнорировать.
Потому что если это перестать игнорировать, то отсутствие yield/await между операциями означает, что мы блокируем исполнитель на это время.
И в вытесняющей многозадачности это ещё работает хоть как-то, в том смысле, что у нас есть шанс запустить 100К таких потоков одновременно и положиться на шедулер оси (ну вот тут по соседству на SObjectizer сумели запустить 100К нативных потоков, сожрав "всего лишь" 7GB накладных расходов) — благодаря возможности гранулярных блокировок, а в кооперативе — нет, т.к. шедулер не может вытеснить заблокированную таску, и все остальные 99999 тасок встанут в ожидании окончания сетевого обмена с ресурсами "I" и "1".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
I>>Правильно. Потому ручная диспетчеризация асинхронного кода — адский АДъ. В многопоточном коде ты можешь остановить все потоки и глянуть, что же там не так. В асинхронном коде у тебя такого фокуса нет. И многих других — тоже нет.
N>Мнэээ... а вот тут уже непонятно. А почему нельзя?
В нативных тредах у тебя есть колстек. В асинхронном коде его нет ни капли. Что откуда каким путём пришло — ахез.
Если ты остановил все треды, скажем в дотнете или плюсах, то анализ колстека дает тебе почти всю информацию.
N>У шедулера такого кода есть в явном виде очередь отложенных задач, которые чего-то ждут (внешнего события или просто таймера). Остановить их всех — задача чисто техническая. Манипулировать этой очередью на ходу — тоже.
Не получится чесно остановить тот же http.get. И здесь другой фокус- как только отпускаешь отладчик, получаешь автоматом вырожденный кейс, когда респонсы валятся лавиной.
Другая проблема — нет способа отлаживать ровно одну логическую задачу.
N>Ситуация же "два асинхронных мьютекса и будут бесконечно пулять две задачи при асинхронном дедлоке" ((c)vdimas) вылавливается там "на раз" и соответственно отстреливается. Это не так удобно, как в Erlang+OTP, где ты можешь убить любой внутренний процесс без разлома полной работы, но ближе к тому.
I>>Не только не послали, но и активно развивают это направление. Ибо — дёшево.
N>Надеюсь, до определённого количества таких отпуливаний? Потому что зациклить таки элементарно.
Именно. Поэтому мутексы хорошо использовать там, где логика более-менее линейная и все прозрачно. В более сложных сценариях мутексы создают слишком много проблем.
Как то так сложилось, что многие авторитетные источики пропагандируют идеи "в асинхронном коде гонок нет", "дедлоки не бывают" и потому контингент обкладывает control flow разными флажками и тд и тд.
Фактически получаются те же мутексы, только размазаные по коду.
Здравствуйте, so5team, Вы писали:
S>Ну так покажите свежие результаты.
Ещё раз: я показал результаты, которые есть у меня. Если вам они не нравятся, то это ваша задача аргументировать своё недоверие — желательно при помощи каких-то более других результатов.
S>Объем кода никому не нужной херни в три раза меньше объема кода продукта, который ежедневно используется тысячами людей.
S>Вы хотите сделать из этого какие-то выводы о техническом совершенстве?
Конечно. И вам предстоит научиться сравнивать технические реализации по техническим критериям, если хотите работать за пределами маркетинга.
S>Во-первых, разница в объеме кода не должна 1-в-1 соответствовать разнице в количестве времени и нервов.
Совершенно верно. Разница, обычно, примерно как N*log(N), т.к. линейная асимптотика возможна только в случае полностью независимого кода, а это в реальной жизни — редкость.
Для плохого монолитного кода асимптотика будет примерно как N^2, из-за большого количества лишних связей.
S>Во-вторых, Nginx и Apache написаны на C. Не нужно приплетать сюда C++.
Отлично. Покажите мне высокопроизводительный веб-сервер на C++, и мы поговорим об этом.
S>Я вам пытаюсь указать, что объем работы над широковостребованным продуктом будет больше, чем над никому не нужной херней. Отсюда напрямую будет и разница в объеме кода.
Попытка не удалась. Если посмотреть в гитхаб, то окажется, что всего и там и там примерно по 4 мегабайта, т.е. объём работы примерно одинаковый.
Вот только авторы эрланга на сам сервер потратили 1 из этих мегабайт, а всё остальное там — это тесты, примеры, и прочие плюшки. А nginx, при всей его мегапопулярности — это практически голый src.
S>Это была часть роутинга, состоявшего из нескольких взаимосвязанных между собой компонентов. Один из них был написан на динамически-типизированном Ruby. Когда тормоза этого компонента превысили границы допустимого, он бы заменен на более быструю реализацию.
Дааа? И каким образом парсинг CDR файлов у вас затесался в роуминг? Не отвечайте — это риторический вопрос. И без ответа на него понятно, что под роутингом вы понимаете что-то своё, не то, что эриксон.
S>Ну да, ну да. Вы вот сами что-нибудь подобное на Erlang-е делали?
Я — нет. Я вижу, как это делают другие. S>Она говорит о том, что Erlang никому не упал.
Не смешите меня. У половины из остальных игроков распространённость ещё меньше, чем у эрланга. Из этого я делаю вывод, что нахрен не упал ваш бенчмарк, а вовсе не эрланг.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, netch80, Вы писали:
N>И какой объём заката солнца вручную в каждом случае для того, что в OTP уже есть и активизируется, грубо говоря, тремя стандартными строчками?
Это безусловно плюс, что это очень просто сделать на эрланге. Если это было бы из коробки в той же java, то продукты вроде Zookeeper и компании были несколько проще, но не настолько проще — суть того же Zookeeper-а это алгоритм, которого из коробки нигде нет.
К тому же под распределенными системами я понимаю не N приложений общающихся через несколько очередей — такую задачу сейчас каждый второй хипстер решает на всяких Redis-ах, а 15 лет назад решали на каком-нибудь J2EE.
Мне интересно как решит эрланг задачи вроде стандартной (в распределенном системе) схемы лидер + последователи, когда один процесс принимает от клиентов команды и реплицирует их на остальные машины, падение лидера должно запустить процесс выбора нового лидера, который потом также начнет принимать команды и т.д. и т.п.
Куда мне смотреть если я такое хочу реализовать на эрланге?
Здравствуйте, Sinclair, Вы писали:
S>>Во-первых, разница в объеме кода не должна 1-в-1 соответствовать разнице в количестве времени и нервов. S>Совершенно верно. Разница, обычно, примерно как N*log(N), т.к. линейная асимптотика возможна только в случае полностью независимого кода, а это в реальной жизни — редкость. S>Для плохого монолитного кода асимптотика будет примерно как N^2, из-за большого количества лишних связей.
Для плохого монолитного кода асимптотика будет N!, как раз из за количества связей. Количество цепочек выполнения это фактически количество всех путей между двумя точками на направленном циклическом графе.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Joie de vivre, Вы писали: S>Не "нужно", а "можно". Обработка сообщения в отдельном потоке — это естественная реализация интуитивно понятных алгоритмов. S>На "другом ЯП" нужно отказаться мыслить терминами реализуемого вами RFC, а заниматься epoll, рукопашным написанием и отладкой конечных автоматов, бороться с race condition и проездами по памяти, возвращаться к уже написанным местам, потому что при 100К параллельных реквестов выбранная вами в прошлый раз архитектура складывает ласты в интересные фигуры, и т.п.
Я не зря называл Paxos — он никогда не относился к категории даже просто понятных алгоритмов, но при этом используется в модифицированном виде в любой решении, которое не является тупым кэшом, размазанным по нодам кластера. Мне интересно применение эрланга для решения подобных задач, а не 100к параллельных запросов, которые ничего не делают.
Я хочу написать распределенную очередь на эрланге с репликацией, фейловером, блакджеком и бэкапнодами. Куда мне смотреть?
Здравствуйте, Sinclair, Вы писали:
S>>Ну так покажите свежие результаты. S>Ещё раз: я показал результаты, которые есть у меня.
Отлично, продолжайте строить свои выводы на результатах пятилетней давности. Поскольку, как уже выяснилось, сами на Erlang-е вы ничего не делаете, вам просто все равно.
S>>Во-вторых, Nginx и Apache написаны на C. Не нужно приплетать сюда C++. S>Отлично. Покажите мне высокопроизводительный веб-сервер на C++, и мы поговорим об этом.
При чем здесь пример веб-сервера на C++?
Вы сравнивали реализацию на Erlang-е с реализацией на С. Но при этом приплели C++. Это некорректно, т.к. C и C++ давным давно являются разными языками. Поэтому ваша фраза должна была звучать как: "Мы говорим о том, что написать высокопроизводительный веб-сервер на С требует в три раза больше времени и нервов, чем на Erlang."
Поскольку от темы веб-серверов я сам довольно далек, единственное, что вспоминается про веб-сервера на C++ -- это Google-овские сервера, а так же работы в Facebook по переводу PHP-шного кода на C++ные рельсы (как в виде более производительной PHP VM на C++, так и в виде трансляции PHP кода в C++). Но данных об их производительности у меня нет.
S>>Это была часть роутинга, состоявшего из нескольких взаимосвязанных между собой компонентов. Один из них был написан на динамически-типизированном Ruby. Когда тормоза этого компонента превысили границы допустимого, он бы заменен на более быструю реализацию. S>Дааа? И каким образом парсинг CDR файлов у вас затесался в роуминг? Не отвечайте — это риторический вопрос.
Чтобы бросаться фразами вроде "риторический вопрос" неплохо было бы сначала научиться отличать роутинг от роуминга. Ключевое слово мной было упомянуто: биллинг. Имеющий непосредственное отношение к роутингу. Настолько непосредственное, что роутинг без биллинга просто никому не нужен.
S> И без ответа на него понятно, что под роутингом вы понимаете что-то своё, не то, что эриксон.
Очевидно, что мы не делали софт для такого же телефонного свитча, какой выпустил давным давно Ericsson.
У нас был свой софт для роутинга, который решал свой спектр задач. И результаты я вам привел из нашего собственного опыта.
Кроме того, информация из категории "был вот такой телекомовский софт на технологии X, его полностью переписали на технологии Y и получили выигрыш в N процентов" попадается на глаза очень и очень редко. Потому что в серьезных задачах объемы таковы, что big rewriting инициируется очень редко, и еще реже он завершается удачно.
Так что если вы хотите составить реальную картину превосходства Erlang-а при перемалывании больших объемов бинарных PDU-шек над C++ или Java в выдуманных вами самими условиях, вам придется проделать эти эксперименты самостоятельно.
S>>Ну да, ну да. Вы вот сами что-нибудь подобное на Erlang-е делали? S>Я — нет. Я вижу, как это делают другие.
Ну понятно.
S>>Она говорит о том, что Erlang никому не упал. S>Не смешите меня. У половины из остальных игроков распространённость ещё меньше, чем у эрланга. Из этого я делаю вывод, что нахрен не упал ваш бенчмарк, а вовсе не эрланг.
Как вы там говорите: "Если вам они не нравятся, то это ваша задача аргументировать своё недоверие — желательно при помощи каких-то более других результатов."
Вам привели результаты одного из самых известных бенчмарков для Web-фреймворков последних лет. Вам не нравится, вы не находите там Erlang-а -- ваши проблемы
Попробуйте найти какие-нибудь современные замеры для Erlang-а.
Здравствуйте, Ikemefula, Вы писали:
I>В нативных тредах у тебя есть колстек. В асинхронном коде его нет ни капли. Что откуда каким путём пришло — ахез.
