Здравствуйте, Ночной Смотрящий, Вы писали:
НС>На пальцах я уже объяснил — никакой разницы с регексами нет, отличия только в исходном алгоритме построения НКА. Дальше все одинаково.
Вот думается, что не все одинаково. Иначе бы об трубили в трубы, а гугл на счет взрыва для linq молчит.
S>>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?
НС>Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами.
Да, но у нас линейная зависимость по числу nested expression. Откуда экспоненциальный взрыв? Работает для каждого expression свой автомат и всех делов.
Здравствуйте, so5team, Вы писали:
S>·>Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов? S>Вы высказали тезис, что изначально высокой производительности нет. В этом вы не правы. Она есть. Все. Дальше вы пытаетесь оправдываться.
Так где же она? Покажи.
S>·>Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки. S>Если вы пытаетесь провести такой водораздел между batch/bulk, то в случае в batch-ами, например, тормоза с выборкой сообщений из входящих очередей могут с лихвой компенсироваться тем, что из очереди сразу изымается N сообщений. Так, если у вас захват lock-объекта для очереди при изъятии сообщения стоит 1us, но вы забираете сразу 1000 сообщений, то общую производительность (т.е. количество сообщений, принятых для обработки за единицу времени) вы получите большую, чем если вы захватываете lock-объект за 250ns, но забираете из очереди всего одно сообщение. S>Если до вас и такое объяснение не дойдет, то медицина здесь уже бессильна.
Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать.
S>·>И каким же образом получить 200М? S>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.
Так каким образом создать такой поток? Пусть без пинг-понга.
S>Ну и сразу предупрежу, что в SO-5 вы не получите 200M msg/sec на одном consumer-е, если на входе будет поток единичных сообщений. Даже при том, что некоторые диспетчеры в SO-5 механизм batching-а при извлечении сообщений используют.
Ну и? Я знаю как не получить 200М. Я спрашиваю как можно получить 200М. Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие, т.к. таким образом, т.е. меняя способ подсчёта, можно получить произвольное число и о эффективности передачи ничего не говорит, а только призвано впечатлять невнимательных читателей.
S>·>Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно. S>Ну покажите, например, queue и pool в стандартной библиотеке C++.
Все решения, которых нет в стандартной библиотеке считаются наколенными? Ну это может только с SObj так... не обобщай.
S>·>Какого типа системы делаются на базе вашего фреймворка? S>Разные. Из области телекома, платежных сервисов, имитационного моделирования, АСУТП.
Ок. Хорошо, но уже лучше, хоть какя-то конретика. Теперь попробуем извлечь ответ на заданный выше вопрос: что из них ниша "небезопасного нативного языка без сборщика мусора."?
S>·>Горутины это не модель акторов, насколько я знаю. S>Ваш альтернативный способ мышления не позволяет проводить аналогии?
Мой альтернативный способ мышления не воспринимает аналогии как доказательства. Вопрос был конкретный: "зачем акторы на одном треде?". Вы ответили: "горутины на одном треде". Но горутины это не акторы.
S>·>Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна. S>Наш альтернативно одаренный собеседник, еще раз вынуждены вам сообщить о том, что здесь идет вопрос не о вере, а о свидетельских показаниях разных людей в разное время. Мы ничего не придумали, мы привели вам слова одного из свидетелей. Дальше вы с этим можете делать все, что захотите.
Ты привёл слова, но интерпретировал слова неверно, т.к. не знаком с контекстом. Ты ошибся, но из-за своей упёртости не хочешь признавать ошибку.
S>·>Ну делали, давным давно перестали. И какой ты делаешь из этого вывод? S>·>Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов. S>Вывод очень простой -- паттерн Disruptor не является универсальным. Это частное решение специфической задачи, да еще заточенное под специфические условия, инструменты и особый режим эксплуатации. А вы, в силу своей альтернативности, пытаетесь сравнивать частные специализированные решения с универсальными фреймворками.
ЧТД — неверный вывод из ошибочной посылки. Вот к чему приводит упёртое невежество.
Вообще-то disruptor это не совсем верно называеть паттерном, это название библиотеки. Паттерн, который там используется называется ring buffer. Просто библиотекой он доведён до такого состояния, что он стал более универсальным, т.к. позволяет обеспечить различные схемы взаимодействия продьюсеров и консьюмеров, тогда как классический ring buffer обычно подразумевает 1p-1c.
S>·>С вашими блокировками эта задача вообще не решается. S>Не решается. А разве где-то утверждалось обратное?
Было что-то там про универсальность...
S>Более того, тот, кто будет пытаться такую задачу решать на SObjectizer-е, а так же любую другую задачу из области hard real-time, тот просто откровенный идиот.
Ты почему-то предполагаешь, что disruptor или ring buffer применяется только в RT. Это не так.
S>·>А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад. S>Молодцы. Могли бы еще проще решить на C++, если бы не религиозный фанатизм. Но речь вообще-то не об этом.
Если бы кабы, может и могли, может и не могли. И уж точно не проще. У C++, особенно по состоянию ~7 лет назад, много своих заморочек. Но ты главное — верь!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Русский выучите. Потом перечитайте внимательно и вдумчиво:
Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.
·>Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать.
Русский выучите. Потом перечитайте внимательно и вдумчиво:
Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.
S>>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е. ·>Так каким образом создать такой поток? Пусть без пинг-понга.
От нескольких producer-ов, к примеру. Которые шлют сообщения с заданным темпом, не ожидая подтверждения от consumer-а. Ваш К.О.
·>Ну и?
42.
·>Я спрашиваю как можно получить 200М.
Русский выучите. Потом перечитайте внимательно и вдумчиво:
Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.
·>Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие
Словоблудием и тормозами пока здесь отличаетесь только вы.
А то, что было сказано про пакетирование сообщений -- это обычный инженерный подход.
S>>Ну покажите, например, queue и pool в стандартной библиотеке C++. ·>Все решения, которых нет в стандартной библиотеке считаются наколенными?
Есть то, что в stdlib, есть публично доступные библиотеки, есть наколенные. Отличий доступных библиотек от наколенных разработок не так много.
·>Что из них ниша "небезопасного нативного языка без сборщика мусора."?
Ниша "небезопасного нативного языка без сборщика мусора" -- это разработка софта, где требуется нативный код и нельзя использовать сборщик мусора, ваш К.О. Требуется такая разработка во множестве прикладных применений. Начиная от бортового ПО для марсоходов и заканчивая разгоном PHP кода.
Но вам нужно выучить русский и прочитать это все внимательно и вдумчиво. Только тогда появятся шансы, что хоть что-то поймете.
·>Мой альтернативный способ мышления не воспринимает аналогии как доказательства.
Во-первых, ваш альтернативный способ мышления пытается найти доказательства там, где их нет. Во-вторых, ваш альтернативный способ мышления не позволяет вам задуматься о том, почему гороутины мапятся на нити ОС как M:N. Если бы вы задумались, вы бы поняли, какой в этом смысл. А поняв смысл, вы бы поняли, почему тоже самое работает и с Акторами.
Но не судьба.
·>Вы ответили: "горутины на одном треде"
Ответ был не таким. Но тут мы опять возвращаемся к русскому языку.
·>тогда как классический ring buffer обычно подразумевает 1p-1c.
Мать-мать-мать. Да вы просто клинический случай.
S>>·>С вашими блокировками эта задача вообще не решается. S>>Не решается. А разве где-то утверждалось обратное? ·>Было что-то там про универсальность...
Дословно было следующее:
Если вы еще о чем-то захотите поспорить со взятыми с потолка цифрами, то давайте мы вам сперва простую вещь объясним. Есть универсальные фреймворки. Для C++ это SObjectizer, CAF, QP/C++. Для JVM -- Akka, Vert.x. Для .NET -- Orleans. Универсальность означает, что эти фреймворки могут использоваться для разных задач и разных сценариев.
Наряду с этим есть и специализированные решения, заточенные либо под какой-то сценарий (вроде Disruptor-а), либо под какую-то специфическую задачу и железо.
Так вот, существует очевидная вещь: производительность универсальных фреймворков будет ниже, чем специализированных решений. И это нормально. Т.к. цели у инструментов разные.
Так вот еще раз, специально для клинических идиотов: SObjectizer, CAF, Akka, Vert.x и пр. -- это универсальные фреймворки. А вот Disruptor -- нет. И попытка сравнения универсальных фреймворков со специализированными, да еще на сценариях, под которые специализированные заточены -- это очевидный идиотизм.
Ну и контрольный вопрос: где утверждалось, что SObjectizer заточен под задачи реального времени?
Здравствуйте, so5team, Вы писали:
S>·>Так где же она? S>Русский выучите. Потом перечитайте внимательно и вдумчиво: S>
Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.
О чём я и говорю — выбираем только удобные факты и делаем выводы вселенского масштаба. А давай сравним не какие-нибудь вычисления, а какие-нибудь веб-сервисы?
S>·>Я задал конкретный вопрос — заявленные 200M это для batch или для bulk? Не надо К.О.-шничать. S>Русский выучите. Потом перечитайте внимательно и вдумчиво: S>
Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.
Цитировать умеешь. А за контекстом следить не умеешь. Этот вопрос я задал на это высказывание: "В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики".
S>>>Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е. S>·>Так каким образом создать такой поток? Пусть без пинг-понга. S>От нескольких producer-ов, к примеру. Которые шлют сообщения с заданным темпом, не ожидая подтверждения от consumer-а. Ваш К.О.
А ты попробуй. Все эти твои продьюсеры будут драться за один лок и всё станет только медленее.
S>·>Я спрашиваю как можно получить 200М. S>Русский выучите. Потом перечитайте внимательно и вдумчиво: S>
Если передавать bulk-сообщения, в которых будет 100 мелких прикладных сообщений, то вы получите 200M сообщений в секунду.
Ок, согласен, слажал. Просто я почему-то надеялся на чудо, что это какой-то реальный результат (С++ же, высокая производительность как таковая же), а не китайские ватты, манипуляции цифрами рассчитанные на неграмотных.
S>·>Пока я вижу, только такой вариант: "давайте будем считать что в одном сообщении передаётся 1000 сообщений, то у нас получится 200М". Это мягко говоря словоблудие S>Словоблудием и тормозами пока здесь отличаетесь только вы. S>А то, что было сказано про пакетирование сообщений -- это обычный инженерный подход.
Верно. Но когда измеряют характеристики системы передачи сообщений, измеряют количество переданных сообщений, а не интерпретацию содержимого этих сообщений.
S>>>Ну покажите, например, queue и pool в стандартной библиотеке C++. S>·>Все решения, которых нет в стандартной библиотеке считаются наколенными? S>Есть то, что в stdlib, есть публично доступные библиотеки, есть наколенные. Отличий доступных библиотек от наколенных разработок не так много.
А чем stdlib не публично доступная библиотека?
S>·>Что из них ниша "небезопасного нативного языка без сборщика мусора."? S>Ниша "небезопасного нативного языка без сборщика мусора" -- это разработка софта, где требуется нативный код и нельзя использовать сборщик мусора, ваш К.О. Требуется такая разработка во множестве прикладных применений. Начиная от бортового ПО для марсоходов и заканчивая разгоном PHP кода.
В смысле у вас телеком на марсоходах или АСУТП на php? SObj-то тут причём?
S>·>Мой альтернативный способ мышления не воспринимает аналогии как доказательства. S>Во-первых, ваш альтернативный способ мышления пытается найти доказательства там, где их нет. Во-вторых, ваш альтернативный способ мышления не позволяет вам задуматься о том, почему гороутины мапятся на нити ОС как M:N. Если бы вы задумались, вы бы поняли, какой в этом смысл. А поняв смысл, вы бы поняли, почему тоже самое работает и с Акторами.
Понятно. Доказательство аналогией. Фтопку.
S>Так вот еще раз, специально для клинических идиотов: SObjectizer, CAF, Akka, Vert.x и пр. -- это универсальные фреймворки. А вот Disruptor -- нет. И попытка сравнения универсальных фреймворков со специализированными, да еще на сценариях, под которые специализированные заточены -- это очевидный идиотизм.
Придумать некий ярлык "универсальный" и развесить его как удобнее и делать из этого вселенские выводы — это очевидный идиотизм.
S>Ну и контрольный вопрос: где утверждалось, что SObjectizer заточен под задачи реального времени?
А кто утверждал, что Disruptor только для задач реального времени? Сконфигурил waitStrategy=blocking — и вот никакого РТ. Такой универсальности SObj-у и не снилось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sharov, Вы писали:
S>Вот думается, что не все одинаково.
Да ради бога.
S> Иначе бы об трубили в трубы, а гугл на счет взрыва для linq молчит.
Потому что в linq этого нет. Там автомат генерируется только для одного метода. Вложенные вызовы только через foreach, т.е. остается неоптимизированный НКА и стадии сборки автомата и преобразования его в ДКА нет.
S>>>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких? НС>>Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами. S>Да, но у нас линейная зависимость по числу nested expression. Откуда экспоненциальный взрыв? Работает для каждого expression свой автомат и всех делов.
Послушайте, любезный. Вы уже изрядно утомили своим альтернативным восприятием реальности и неспособностью читать текст на русском языке.
Поэтом кратко и тезисно.
SObjectizer -- это универсальный фреймворк. Универсальные фреймворки, т.к. Akka, Orleans, CAF, SObjectizer и пр. всегда будут проигрывать специализированным решениям. Например, таким, как Disruptor, особенно когда этот Disruptor работает в специализированной конфигурации для биржи.
Вам кажется, что 2M msg/sec на честном ping-pong-е -- это мало. Нет проблем, возьмите любой другой универсальный фреймворк и сравните, если вам это интересно.
Вы не видите смысла в таком бенчмарке? Не вопрос. Не видите, значит не видите. Значит 2M msg/sec для вас вообще не имеет значения.
Вы хотите иметь 200M прикладных сообщений в секунду? Вариант, как это получить в SObjectizer вам сказали. Не нравится? Да не вопрос. Можете попробовать получить эти цифры с любым другим универсальным фреймворком, любым удобным для вас способом.
SObjectizer -- это решение для C++. Видите ли вы ниши для C++ или не видите -- это не важно. SObjectizer предназначен для C++ и здесь он конкурирует с другими такими же фреймворками (коих не много). Сравнение производительности с ближайшим конкурентом мы сделали. Сравнение с решениями для других языков мы не делаем, т.к. не видим в этом смысла. Нравится вам это или не нравится -- это не важно. Кто хочет получить такие сравнения может сделать их самостоятельно, благо все лежит в открытом доступе.
Не понимаете, зачем привязывать несколько акторов к одной рабочей нити? Это проблема вашего образования. Никто вас учить не будет, благо доступной информации в интернете в избытке. Изучите матчасть. Посмотрите на то, как работают диспетчеры в той же Akka. Почему гороутины в Go мапятся на реальные нити M:N. Может даже дойдете до того, что модели CSP и Actors обладают рядом сходств и могут выражаться одна через другую.
Как-то так. Будете тупить и демонстрировать непонимание, общаться дальше будете в одиночестве.
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Ровно как практически нет С++ в вебе, кроме небольшого количества узкоспециализированных сервисов. Да и с поиском у тебя смешно получилось. В сегменте локальных поисковых сервисов однозначный лидер — Эластик. Ну и ELK на его основе для логов. А он, о ужас, на джаве писан, а вовсе не на С++.
Ну и Bing, не забываем, писан аккурат на шарпе.
Хреновая релевантность там никак не связана с ЯП или платформой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, C0x, Вы писали:
C0x>Еще как прет. Я на Go решил делать свой новый сервис. Язык классный, с одной стороны все удобства Си: скорость, развертываемость (тупо скопировал на машину файл и запустил), а с другой стороны синтаксис и garbage collection и гороутины делают программирование приятным как скажем на c# или питоне ))
Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?
Здравствуйте, Тёмчик, Вы писали:
Тё>Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?
Здравствуйте, Тёмчик, Вы писали:
Тё>Я тут прочитал на выходных Go blueprints. Хочется больше почитать, а что именно? Интересует меня практический вопрос: какие в Go есть либы/фреймворки, чтобы «из коробки» actions от redux-а и потом push-notifications на клиента? Какие есть либы, чтобы генерить интерфейсы в Go на JSON- сообщения (из protobuf или из pojo java- есть генераторы в typescript), а не дублировать вручную описания?
Я все ответы нахожу в Гугле по теме какие библиотеки использовать. Благо на Github их уже навалом. Из последней радости которую я раскопал и использую: bbolt — встроенная в приложение No SQL база данных. Тем самым не нужны мне больше Postgres, MySQL и прочие сервисы.
Здравствуйте, Тёмчик, Вы писали:
Тё>Одна крупная (австралийская) контора заявила, что все копромонолиты на жаве распиливают и переписывают на микросервисы на Go. Причём я всегда думал, что Go — это как Python, только гугловский с блекджеком и девушками. Чел заявил, что это как C. Что вообще происходит? Node с typescript уже стух и надо учить Go?
После сишарпа гоу кажется как если бы пересел с последней топовой бэхи на ЗАЗ 968.
Здравствуйте, AlexRK, Вы писали:
ARK>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.
Да ну? :D
Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
Здравствуйте, Hardballer, Вы писали:
H>Здравствуйте, AlexRK, Вы писали:
ARK>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.
H>Да ну? :D H>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
Тут слишком много вопросов: какое железо использовалось? А с аналогичным на С++ кодом сравнивали? А что там вообще на С# написано, может там голый Си на 80% а на C# только обертка красивая? и т.д. и т.п.
Здравствуйте, C0x, Вы писали:
C0x>Здравствуйте, Hardballer, Вы писали:
H>>Здравствуйте, AlexRK, Вы писали:
ARK>>>ядра высокопроизводительных серверных систем (трейдинговых) — нигде здесь C# нет и никогда не будет.
H>>Да ну? :D H>>Если что, единственный известный мне HFT OrderBook, взявший планку в 1М ордеров в секунду на реальном сетевом стеке на 1024 потоках на 10 гигабитном канале -написан на C#
C0x>Тут слишком много вопросов: какое железо использовалось? А с аналогичным на С++ кодом сравнивали? А что там вообще на С# написано, может там голый Си на 80% а на C# только обертка красивая? и т.д. и т.п.
Железо неплохое, сам HFT Server это DELL PowerEdge R640 DX292 в не самой плохой конфигурации, но и не топовой-64 физических ядра, 256Гб памяти. Дисковое хранилище датафида на другом сервере находится, который заточен именно под быструю запись(на таких скоростях исполнения ордеров запись самого датафида ордеров еще та задачка, как и распухание БД под хранение).
На плюсах подобное в удобоваримые сроки ИМХО не сделать.
C# там везде.
А так NDA. Ждите публичную бету
Здравствуйте, reversecode, Вы писали:
R>слился гоу при нагрузке R>https://oatpp.io/benchmark/aws R>С++ его порвал как тузик грелку
ну так там же видно, что на нормальном сервере результаты практически одинаковы после 1000 соединений на aws и на 5000 на digital ocean
не все так однозначно (ц), это при том, что стандарный net/http у golang никогда не считался быстрым, взять тот же fasthttp, который должен быть пошустрее
