G>Работа с массивами — слабое место Эрланга. На эрланге это будет очень медленно, так как в той задаче вместо массива придется использовать словарь процесса (хэш-таблицу).
Ну, дык та задача — это честная числодробилка. Понятно, что более высокоуровневые вещи будут на динамике выглядеть лучше, так как многое может лечь на библиотеки.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, FR, Вы писали:
FR>От задач зависит, с задачами хорошо ложащимися на библиотеки типа NumPy скорость вполне приличная.
Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, FR, Вы писали:
FR>>От задач зависит, с задачами хорошо ложащимися на библиотеки типа NumPy скорость вполне приличная.
VD>Ежу понятно. Но это уже не совсем честное сравнение. Это уже пенисометрия библиотек, или, что еще хуже, сравнение С с С но замаскированный под Питор (обман, значичь).
Тебе шашечки или ехать?
Это нормальное использование для glue языка.
Здравствуйте, eao197, Вы писали:
A>>Вот собственно интересно было бы замутить бенчмарк...
E>Я такой делал E>Причем, если помниться, мой ноутбук был по производительности практически такой же, как упоминался в работе Одерски. Так что 30K токенов в секунду -- это фигня А после того Remark подсказал еще несколько оптимизаций, скорость еще процентов на 7-8 выросла.
E>Только вот 600K агентов на своей машине я запустить не могу, после 200K агентов 512Mb RAM оказывается мало.
30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
Здравствуйте, Gaperton, Вы писали:
G>30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
Настольная система — понятие растяжимое, например у меня на столе Core2Duo с 4GB на борту . По этому и скалу смотреть надо на той же машине с аналогичным алгоритмом, да и в статье довольно древний пень использовался...
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Кстати, эти скаловские акторы прерываются шедулером, или он должен дождаться, когда они вернут управление? A>Нет по несольким причинам: A>1. jvm не продставляет возможностей для управление стеком (а следовательно честные continutation реализовать очень проблематично) A>2. scala все таки не чисто функциональный язык, значит прерывать выполнение грубым suspend нельзя
A>По этому идея такая: актер, ожидающий сообщения — суть замыкание. Когда приходит сообщение, это замыкание (внутри которого паттерн-матчинг конструкция) вызывается в контексте посылающего потока. Если актер блокируется в receive, то вместо этого бросается исключение раскручивающее стек. Если актер завершается, то происходит просто возврат как из функции. Посылающим может быть либо шелдулер в случае асинхронного вызова (и тогда это будет worker thread), либо другой поток — в случае синхронной посылки сообщения. При этом, если обнаруживается, что все рабочие потоки у шелдулера заняты, он может родить еще один поток. По этому максимум актеров, которые используют длительные операции может быть ~5.5k, при которотких операциях их может быть на прядки больше.
Так я и думал. Получается, что эрланговские процессы лучше и удобнее. У них честная вытесняющая многозадачность.
Здравствуйте, eao197, Вы писали:
E>>>Тысячи, десятки тысяч, сотни тысяч реактивных (т.е. реагирующих на внешние воздействия) легко решаются одной рабочей нитью и очередью заявок. G>>Не легко. Ты затрахаешься обеспечивать хорошую реактивность системы в этом случае, если часть запросов у тебя длительные. Во-вторых, при возникновении ошибки при обработке запроса ты не сможешь гарантировать, что это не повлияет на выполнение остальных — а эрланг-система дает 100% гарантию этого.
E>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
E>Даже в случае отсутствия работы с переферией, когда грузится только процессор, переключение контекстов на 10K вычислительных задач будет означать, что каждый процесс будет получать порядка 10ms каждые пару минут. Реактивность здесь классная, как будто 10K черепах ползут.
Это при условии, что все 10К процессов постоянно заняты научными вычислениями — а в реальных приложениях процессы заняты как раз вводом-выводом и общением друг с другом. Эрланг даст хорошую реактивность для 9000 коротких процессов в случае, если в системе есть 1000 длительных. Вот это — факт.
G>>Особенность Эрланговского рантайма в том, что не происходит деградации производительности при пиковой нагрузке — пропускная способность системы остается постоянной. Это требование телеком приложений. G>>
E>еще бы было объяснение что это все означает. http://www.sics.se/~joe/apachevsyaws.html
G>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
E>А ты?
А я в CQG возглавлял группу разработки сервера, который по требованиям должен иметь хорошую реактивность и soft-realtime поведение. Собственно, CQG — это софт-рилтайм система, чем меньше время отклика и задержка прохождения котировок, тем меньше денег теряет клиент. Это добро написано на С++, и я не понаслышке знаю, как тяжело на практике в большом приложении обеспечить хорошую реактивность и отсутствие деградации производительности при нагрузке. К слову, я являюсь автором подсистемы "легких потоков", основанных на файберах со своим специализированным шедулером, которая сейчас применяется в клиенте и сервере CQG — разработаной чтобы побороть проблемы с реактивностью сервера. И могу сказать как врач — это, коллега, охрененно не просто — совсем не так, как ты тут с легкостью пишешь о пулах процессов, тредов, и очередях сообщений. Это только кажется, что все просто, пока сам не делал.
E>Пока ты только ссылаешься на чужой опыт выдавая Erlang за серебрянную пулю, но, как я понимаю, сам не нем серьезных систем не сделав.
Я сказал ровно то, что сказал. Эрланг в реальных приложениях, которые можно скачать и потестировать, дает хорошую реактивность и пропускная способность системы не падает под нагрузкой, и в этом он превосходит все существующие платформы, добиться на которых подобного можно только не по децки затрахавшись. Я не считаю Эрланг серебряной пулей — за серебряными пулями обращайся к Владу и последователям культа Немерле. У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
Что до опыта — на Эрланге у нас построена система моделирования. Это достаточно серьезная система. Только тебе это все равно — вон gandalfgray серьезную промышленную систему забабахал — не чета нашей, и к его словам ты в равной степени не прислушиваешься. На опыт Джо Армстронга (который сделал несколько лучших в индустрии по характиристикам систем, превосходящих по сложности все мои проекты и проекты gandalfgray), Пера Берквиста, Ульфа Вигера, и команды Эрикссона занимавшейся AXD301, я тоже ссылаться не считаю зазорным. Опыт, который проанализирован и по которому написаны отчеты — это не форумное бла-бла-бла, понты, и детские замеры.
Здравствуйте, Gaperton, Вы писали:
E>>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
G>Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
Не сомневаюсь, что в случае отсуствия операций ввода-вывода так и есть. Я говорил как раз о наличии таких операций.
G>>>Ты много приложений сделал, с характеристикой по пропускной способности от нагрузки, как на приведенной мной картинке? Сделаешь — будешь приводить серьезные контраргументы и альтернативные варианты. Пока — неубедительно.
E>>А ты? G>А я в CQG возглавлял группу разработки сервера, который по требованиям должен иметь хорошую реактивность и soft-realtime поведение. Собственно, CQG — это софт-рилтайм система, чем меньше время отклика и задержка прохождения котировок, тем меньше денег теряет клиент. Это добро написано на С++, и я не понаслышке знаю, как тяжело на практике в большом приложении обеспечить хорошую реактивность и отсутствие деградации производительности при нагрузке. К слову, я являюсь автором подсистемы "легких потоков", основанных на файберах со своим специализированным шедулером, которая сейчас применяется в клиенте и сервере CQG — разработаной чтобы побороть проблемы с реактивностью сервера. И могу сказать как врач — это, коллега, охрененно не просто — совсем не так, как ты тут с легкостью пишешь о пулах процессов, тредов, и очередях сообщений. Это только кажется, что все просто, пока сам не делал.
Мы, конечно, не CQG (кстати, может по московским меркам CQG и крутая контора, но у нас про нее никто не знает).
Но у нас так же работает в софт-реалтайме система, написанная на C++ и обеспечивающая нормальную реактивность при больших нагрузках. Так что я говорю о том, что сам делал. И десятки тысяч агентов (по аналогии с Erlang-овскими процессами), о которых я говорил, существовали в реальных приложениях. И переход от множества агентов к нескольким агентам так же был вызван опытом реальной эксплуатации со своими тебованиями не только к реактивности, но и к сопровождаемости и обозримости (в том числе и к мониторингу).
G>У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
Кстати, мне показалось, что Армстронг несколько по другому оценивает плюсы Erlang-а, нежели ты.
Но я его диссер пока не дочитал, так что спорить пока не буду.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, aka50, Вы писали:
A>Логика проста если посмотреть на конкурентов: A>* Ruby/Python — основная реализация открыта и может быть портирована при необходимости, планирование фич производится авторами, все основные библиотеки открыты и теоретически чисты в плане патентов.
см. ниже.
A>* Java — ...
Так, а при чем тут Java? Я про Ruby спрашивал. А это все из серии "А у меня брат — матрос, он завтра придет в школу и тебя побьет!"
Превосходство Java над Mono, по большинству параметров у меня сомнения не вызывает. Там есть, конечно, свои нюансы, но это тема для отдельного разговора.
A>Чем из этого может похвастаться mono? A>Переносимость между самим собой (т.е. mono рантайма) — да.
Собственно дальше можно и не продолжать. Весь этот спор начался с того, что утверждалось "нет" без всяких оговорок.
A>Но A>- фреймворк, который по сути сплошной реверсинжиниринг
Это безответственное утверждение. Есть стандарт.
A>— фреймворк вечно догоняющий и не имеющий никакого влияния на основную ветку
Совершенно верно.
A>— несовместим с основной веткой от MS (точнее есть нехилый зазор между поддерживаемыми фичами) и часть фич принципиально отсутсвует, например CAS
Да, это серьезный недостаток.
A>— возможные проблема с патентами
Фактически эта фраза семантически эквивалентна преведенной выше "теоретически чисты в плане патентов" — но звучит, конечно, гораздо страшнее. Да, патентный троллинг вообще серьезная угроза, но превосходство Ruby в этом плане совершенно неочевидно.
A>— большинство готовых решений пишутся под ОС Windows и работа их под mono абсолютно не гарантированна
Да.
A>— mono-develop нельзя и близко сравнить не то что с Intellij Idea / Reshaper, но и с чистым Visual Studio
Опять появляется брат-матрос. Ну расскажите, насколько альфа-плагин для Ruby и Idea круче mono-develop.
A>Мне лично этого выше крыше хватает чтобы не рассматривать mono как серьезную платформу. Гораздо проще взять python/ruby или jvm.
Тема превосходства Java над Mono раскрыта. Тема превосходства Ruby над Mono по качеству — нет. Это меня не очень устраивает потому, что спрашивал я как раз про второе.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
E>Чтоже до стабильности (и косвенно о качестве) Mono, то достаточно посмотреть в ChangeLog:
E>http://www.go-mono.com/archive/1.2.2/ E>
E>Specifically, this release:
E>* 496 new methods implemented.
E>* 212 removed bogus TODOs.
E>* 65 removed NotImplementExceptions
E>Stats:
E>* 1,933 missing methods were implemented.
E>* 164 methods with pending implementations were fixed.
E>Мне как-то сомнительно, что стабильная платформа устраняет по несколько десятков не реализованных ранее методов в минорных релизах.
1) Не вижу сравнительной статистики.
2) Это имеет отношение, в основном, к повторению закрытых Майкрософтовских библиотек. А мы говорили, о качестве рантайма, нет? Даже в таком аспекте у Ruby должно быть преимущество по качеству хотя-бы потому, что naive interpreter и JIT по сложности реализации несопоставимы. Но вот только они и по функциональности несопоставимы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
E>>>Если часть запросов длительная, то и Erlang-овская система затрахается. Сильно сомневаюсь, что при наличии длительных операций ввода-вывода Erlang будет диспетчировать процессы лучше ОС.
G>>Эрланг-система диспетчеризует свои процессы лучше ОС. И это наглядный факт, наблюдаемый по поведению программ — можешь сомневаться, можешь нет.
E>Не сомневаюсь, что в случае отсуствия операций ввода-вывода так и есть. Я говорил как раз о наличии таких операций.
Как раз при вводе-выводе это так. Если ввода-вывода нет, то процессы шедулятся крайне тупо — по кругу раздаюшь кванты и все — это лучшая схема. Ты график пропускной способности веб-сервера вообще смотрел, что я приводил, нет? Видел, как от количества одновременных соединений throughput зависит? В веб-сервере каждый процесс занимается ввобом-выводом.
E>Мы, конечно, не CQG (кстати, может по московским меркам CQG и крутая контора, но у нас про нее никто не знает). E>Но у нас так же работает в софт-реалтайме система, написанная на C++ и обеспечивающая нормальную реактивность при больших нагрузках. Так что я говорю о том, что сам делал. И десятки тысяч агентов (по аналогии с Erlang-овскими процессами), о которых я говорил, существовали в реальных приложениях. И переход от множества агентов к нескольким агентам так же был вызван опытом реальной эксплуатации со своими тебованиями не только к реактивности, но и к сопровождаемости и обозримости (в том числе и к мониторингу).
Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.
С агентами эта задача практически не решаема за разумные сроки с разумным качеством (сдохнешь на рефакторинге — бить последовательные процессы на несколько "агентов", и вводить систему веревочек, чтобы обеспечить приоритеты) — параллельных активностей слишком много, именно для решения этих проблем и была введена легкая многозадачность с собственным планировщиком. Имея такой рантайм, каким обладает Эрланг, этих проблем попросту бы не было. Воспроизвести свойства этого рантайма на С++ невозможно даже со своими потоками — файберы (в отличии от эрланговских процессов) жрут адресное пространство со страшной силой, иметь их в системе десятки тысяч сложно, и практически невозможно, плюс — в файберах приходится помечать точки возможного прерывания шедулером руками. А агенты — вообще отстой, их применение усложняет код и время разработки в два раза по нашим метрикам (за счет того, что длительная обработка разворачивается из последовательного кода в конечный автомат, и программа становится асинхронной). В простом случае ты конечно того не заметишь, и, возможно, не поймешь, о каких проблемах я говорю, но вообще — вот так бывает, дружище.
Вообще непонятно, зачем ты споришь с очевидным. Так сложно пережить факт, что Эрланговский рантайм содержит лучшую на текущий момент поддержку параллельного программирования? Извини, люди специально старались, чтоб было именно так, что тут удивляться. Старались они потому, что считали, что это очень важно. И не идиоты люди-то — заслуженные инженеры, с опытом, понимают, что делают. Можно допустить, что тут есть какая-то полезная фишка? Или все отстой, кроме пчел?
G>>У Эрланга есть минусы, есть плюсы. Я тебе пока рассказываю о плюсах.
E>Кстати, мне показалось, что Армстронг несколько по другому оценивает плюсы Erlang-а, нежели ты.
Моя оценка плюсов и минусов не отличается от мнения эрланговского мэйллиста, могу тебя заверить. Но если тебе что-то показалось — так ты скажи, что именно. Хочешь — перенесем дискуссию в эрланг мэйллист, и ты увидишь мнение Джо.
Армстронг делает упор на Concurrency Oriented Programming (ему как Степанову с STL, кажется, что он новую парадигму изобрел), и надежность в условии присутствия программных и аппаратных ошибок. При этом, мотивация разработки Эрланга, которую я тебе привел в посте про преимущества в телекоме, ты можешь прочесть конспективно в FAQ по языку (это элементарщина — не надо за этим Джо теребить) и материалах по истории разработки Эрланга.
Здравствуйте, VladD2, Вы писали:
G>>Работа с массивами — слабое место Эрланга. На эрланге это будет очень медленно, так как в той задаче вместо массива придется использовать словарь процесса (хэш-таблицу).
VD>Ну, дык та задача — это честная числодробилка. Понятно, что более высокоуровневые вещи будут на динамике выглядеть лучше, так как многое может лечь на библиотеки.
В Эрланге просто нет массивов нормальных, и все . Плавающую запятую HIPE компилирует нормально, рекурсия там тоже быстра. Что-нить без того, чтобы лопатить вперехлест здоровый массив, как в альфабленде — это будет совсем другое дело. Хоть перемножение матриц. Здесь можно будет обогнать Питон.
Но лучше что-нить нейтральное — работа с какими-нибудь деревьями. Это достаточно низкоуровнево, библиотеки не нужны — все по честному. Можно в эти деревья плавающую запятую добавить и целые числа.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>30К токенов в секунду — то вообще ерунда. Мы делали тест с кольцом сумматоров на Эрланге. По результатам измерений на настолькой машине Эрланг система прокачивает около 600К сообщений в секунду.
A>Настольная система — понятие растяжимое, например у меня на столе Core2Duo с 4GB на борту . По этому и скалу смотреть надо на той же машине с аналогичным алгоритмом, да и в статье довольно древний пень использовался...
Одно ядро, П4, 3 гигагерца. Памяти по моему гиг — она не узкое место. Тест был — кольцо сумматоров (следующий получает мессаги от двух предыдущих).
Здравствуйте, Klapaucius, Вы писали:
K>Здравствуйте, aka50, Вы писали:
Я руби не защищаю, я отвечал на вопрос — почему mono — недоплатформа. Возможно надо было не тебе отвечать, а на первоначальный пост.
K>Собственно дальше можно и не продолжать. Весь этот спор начался с того, что утверждалось "нет" без всяких оговорок.
Ну я и ответил: нет обезьянам. Что ruby only — я тоже с этим не согласен , мне больше jvm + scala симпатичнее и erlang.
A>>Но A>>- фреймворк, который по сути сплошной реверсинжиниринг K>Это безответственное утверждение. Есть стандарт.
CLI — да, но это далеко не все, что есть в CLR...
The .Net Framework Class Library is a superset of the libraries defined in the CLI (including the BCL); it includes those libraries as well as several that are not standardised, such as System.Windows.Forms and System.Web.
A>>— возможные проблема с патентами K>Фактически эта фраза семантически эквивалентна преведенной выше "теоретически чисты в плане патентов" — но звучит, конечно, гораздо страшнее. Да, патентный троллинг вообще серьезная угроза, но превосходство Ruby в этом плане совершенно неочевидно.
Не эквивалентны. mono _уже_ нарушает патенты реимплементируя (см ниже цитату из FAQ) те-же winforms, в ruby — надо еще доказать... К тому же это принциально разное нарушение: в mono — прямое копирование, в ruby — возможное нарушение каких-то алгоритмов.
For people who need full compatibility with the Windows platform, Mono's strategy for dealing with any potential issues that might arise with ASP.NET, ADO.NET or Windows.Forms is: (1) work around the patent by using a different implementation technique that retains the API, but changes the mechanism; if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandalfgrey, Вы писали:
G>>Ну, в данном случае переменные M,F,D локальны в пределах двух строчек. Оттого я и сократил их до инициалов. В том примере для другой посылки используются более вразумительные имена, так как там они локальны в целых 6-и строчках. G>>Подход к именованию у меня именно такой — где коротко, там и имена короткие. WH>Плохой подход. Ибо сегодня коротко, а завтра еще строк добавят.
В Эрланге сокращения M и F применяются для обозначения модуля и функции, так же традиционно, как i j k применяются для переменных циклов. Второй строкой идет spwan_link, популярная билиотечная функция, аргументы которой и предназначение знает наизусть даже новичок. Написано нормально, предельно читабельно. все gandalfgray сделал правильно. Именно так в этом случае все и пишут.
WH>Да и читать это как?
Язык учить сначала, а только потом читать и учить людей оформлению кода.
Здравствуйте, Mamut, Вы писали:
M>Имхо, главная мощь именно Эрланга, которая, возможно, имеет/не имеет отношения к чему-либо, будь то типизация или что иное, это его тривиальная сериализуемость и (частично как следствие, частично как причина) его тривиальная работа с сетью.
M>Будь в любом другом языке такое же, имхо, Эрланг курил бы в стороне и, возможно, вообще бы не появился
M>Возможность написать: M>
M>Pid ! {Любая, [структура, данных]}
M>
M>это наигениальнейшая вещь.
M>Я как вспомню все эти пляски с бубном вокруг решений о том, что и как запаковывать/распаковывать и передавать по сети... Бррр.
M>Каким боком здесь динамика? А никаким
Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики. Именно поэтому Эрланг динамический. Это довольно глубокая мысль — думая ее ты достигнешь просветления.
G>Забавно. Слона то ты и не заметил. Да наипрямейшим образом тут динамика. Именно динамика дает тебе такую легкость сериализации и десериализации — не нужны никакие фабрики.
как человек, написавший пару библиотек сериализации на хаскеле, я протестую против наглой и циничной лжи!
правда, тип для десериализации всё равно знать приходится но в языке с действительно строгой типизацией это обычно и не является проблемой
Здравствуйте, Gaperton, Вы писали:
G>Этот переход возможен только в случае, если у тебя время обработки каждого запроса предсказуемо и постоянно. Это простой случай, тут думать практически не надо. Только жизнь сложная штука, там далеко не всегда бывает так. Например, серверу CQG приходится иметь дело с запросами, время выполнения которых непредсказуемо, и колеблется в широком биапазоне от очень быстрых до крайне медленных. Одновременно серверу приходится отвечать на множество запросов с моментальной реакцией, и прокачивать через себя кучу обновлений по открытым соединениям в реальном времени с минимальной задержкой. Периодически бывают ситуации пиковой нагрузки (ферма серверов балансирует нагрузку или отрабатывает сбой, перекидывая пользователей с сервера на сервер), при которой все должно работать так же, как обычно.
А имеет смысл писать сервер аналогичный CQG'шному на erlang? Если да, то в чём будет выигрыш и проигрыш? Если можно с примерными количественными оценками.
