Здравствуйте, ·, Вы писали:
·>Ну да, как-бы наверное что-то такое этакое... Ещё там как-то SP подменяется. Вот только я не очень понимаю все эти детали.
SP стека которому мы передали управление, для текущего потока выставляет runtime. Наверное.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> Что в принципе несложно сделать и для рекурсивных yeld ов
НС>А что с экспоненциальными взрывами то делать?
Откуда оне в энумераторе шарпа возьмутся? Там простейший автомат для обхода коллекции.
Здравствуйте, ·, Вы писали:
S>>Поддрежка рантайма нужна для диспетчеризации вызова в соотв. фрейм. Это как с обработкой прерывания, только не в одну сторону стек разматывать, а в обе. ·>Ну да, как-бы наверное что-то такое этакое... Ещё там как-то SP подменяется. Вот только я не очень понимаю все эти детали.
Stackful сопрограммы делаются очень просто и тупо. Вызов yield — это обычный вызов функции, сохраняющий состояние вызывающего на стеке. Далее yield делает (аналог) longjump в планировщик, который решает что там нужно запускать дальше.
Когда нужно возобновить сопрограмму — делается longjump обратно в тело yield, что восстанавливает стек. Ну а затем yield штатным образом делает ret и сопрограмма идёт себе дальше.
Здравствуйте, so5team, Вы писали:
S>>>Может тогда объясните, почему тогда в каждом новом релизе Java еще быстрее становится? Наверное, уже обогнала процессоры, на которых работает. S>·> А, что C++ или SObj с каждым релизом становится медленнее? S>Это вы попытались заболтать тезис, что
нет нигде "изначально высокой производительности".
S>Но у вас не получилось.
Заболтать? Какой вопрос (я его специально оставил в квоте), такой ответ. В чём было твоё возражение против тезиса-то?
S>А поскольку вы поражаете своим эээ, специфически ограниченным взглядом, то придется открыть вам очередную банальность: новые фичи не обходятся бесплатно. И где-то да, за новую функциональность приходится расплачиваться. Местами производительностью, местами расходом памяти.
А иногда что-нибудь оптимизируется или предлагаются другие подходы для решения тех же задач. Если ваш продукт с каждым релизом всё медленнее, то вы делаете что-то не то.
S>>>Ну вам-то конечно виднее, из мира JVM. А вот люди из России, например, рассказывают, что для определенных платформ ничего кроме C и C++ нет. И не будет в обозримом будущем. S>·>Не понял зачем ты мне мой тезис доказываешь. "определенных платформ" это и есть "специализированные решения". S>У вас какое-то специфическое представление о "специализированных решениях".
Да ваще.
S>>>Так вы ж не сравнивали. Но мнение имеете. S>·>Вы, похоже тоже. S>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают.
Клёво. А что вы ждёте от нас? И сколько вы готовы за это заплатить?
S>·>Но мне от этих сравнений ни тепло, ни холодно, S>Но рот-то вы зачем-то открыли. Зачем?
Это публичный форум, я тут развлекаюсь. А вы зачем открыли?
S>>>Это было не обещание. А объяснение, как на большом потоке сообщений получить 200M. Это не фокус. Фокус на одиночных сообщениях высокую скорость передачи сообщений обеспечить. S>·>Это не "получить". Т.к. передавать 8-байтный указатель на мелкое сообщение или 8-байтный указатель на большое батч-сообщение — это мягко говоря не про то. S>Скажите, а вы точно уверены в том, что понимаете предмет разговора? Со стороны видно, что вы вообще не представляете себе, чем отличается обработка единичных сообщений в режиме request-reply от обработки стабильно плотного потока входящих сообщений.
Я наоборот очень хорошо представляю, поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие.
S>>>·>В смысле SObj это единственное решение в мире C++? Остальные клепают наколенное? S>>>Не единственное. Но одно из немногих живых и развивающихся. S>·>Почему? S>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О.
Почему "одно", очевидно же, господин тролль.
S>>>Мы вышли из мира C++. S>·>Так не засиживайтесь в своём мирке. S>Ну вот если Rust мир будет и дальше развиваться так же активно, попробуем пойти еще и туда. S>А в вашем Java мире и скучно, и тесно. И идиотов слишком много.
Причём тут ЯП?
S>>>Erlang и Akka, вообще-то говоря, находятся в одной нише. Но вы этого не понимаете, как и многого другого в данном разговоре. S>·>Ы? S>Вот-вот. Отличная демонстрация.
Ты повторяешь мои слова, без всякого смысла, да ещё на личности всё разговор сводишь, господин тролль.
Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой?
S>>>Кто плачется? Вам опять что-то померещилось. S>·>" У нас PR сильно слабее. " — это что было? Хвастовство что-ли? S>Это констатация факта. Плачем было бы, если бы мы написали что-то вроде "У нас, к сожалению, PR сильно слабее не смотря на все прилагаемые усилия и мы уже даже не знаем, что можно еще сделать в этом направлении". Так что вы не только в предмете разговора не разбираетесь, вы еще и читать не умеете.
Т.е. фактически ты заявил "мы — неудачники, и это константация факта". Понятно, спасибо за откровенность.
S>>>А если вы думаете, что из-за публикации результатов бенчмарков внезапно волна интереса возникнет, то разочарую вас. Не возникнет. S>·>Это условие как минимум необходимое. S>А вот вы посмотрели на результаты бенчмарков, которые мы вам показали?
Да, мельком. Могу рассказать о своём впечатлении. Мне не очень понятно что там сравнивалось с т.з. прикладных задач и что этим предполагалось продемонстрировать.
Во-первых, я плохо знаю CAF, никогда не использовал. Как я понял CAF позиционируется как гибкое высокопараллельное распределённое решение. А вы его тестируете для пинг-понга между двумя тредами. Пинг-понг делается volatile переменными, давая охренительную производительность, непонятно зачем для этого нужен целый фреймворк.
Во-вторых, у CAF есть свои бенчмарки, притом они не стесняясь сравнили свой продукт с чем только можно, не ограничиваясь миром С++. Так и вам можно было бы просто реализовать эти же бенчмарки на вашем продукте и показать преимущества. А по факту выглядит так, что в вашем бенчмарке вы сравнивали те сценарии которые вы знаете, на которые ваш SObj _специализированно_ заточен, используя в качестве "груши для битья" _универсальный_ фреймворк, который, грубо говоря, позволяет одним флажком перенести прикладной код с микроконтроллера на массивный кластер или в GPU.
Но даже побить-то особо не получилось. Скажем "scheduling" на одном треде дал прирост аж 30% (но кому нужен actor model на одном треде?!), а на тред-пуле внезапно в 50 раз медленнее.
В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений... а вы тестируете на 8-ядерном компе, большинство тестов — 1-2 треда, при этом постоянно настаиваете на универсальности вашего решения.
S>>>Вменяемые люди оценивают по целому спектру критериев. И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов. S>·>Я говорю о другом, есть задачи, где важна производительность и за выбором языка реализации дело не стоит. S>Не понятно вообще о чем вы говорите в данном случае. То, как можно понять ваши слова, только подтверждает сказанное: "И производительность одного конкретного фреймворка из мира C++ здесь будет где-нибудь к концу первой сотни факторов."
Фреймворк != ЯП. В десятый раз повторяю. Не понимаю почему ты не различаешь.
S>>>А пользователь одного из наших продуктов рассказывал, что они переписывают кусок с Java на C++, потому что на нынешних объемах данных Java тормозит. S>·>Хз что. Если что-то типа числодробилок — поверю. S>Вообще-то нам без разницы, поверите вы или нет. Люди агрегируют большое количество данных в json-е из разных источников. И обработка этого хозяйства на Java менее эффективна, чем на С++.
Обычно нет. Эффективное решение задачи такого типа на Java как правило не отстаёт по производительности от C++ больше, чем на десяток процентов. А та ссылка на web-бенчмарки показывает (с json тоже, кстати), что java код может работать даже эффективнне чем С за счёт JIT. Но у них может быть какой-то специфичный сценарий, я не знаю.
S>>>Тут любой может врать как очевидец. S>·> Мда, религиозные убеждения не лечатся. В лучшем случае, в конце-концов услышишь: "вы всё врёте!" S>Да вы еще и выражение "врать как очевидец" не понимаете. Ну вообще полный комплект: ни русского не понимает, ни в теме не разбирается.
Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Заболтать. Единственное, что у вас получается, это включать дурочку.
·>В чём было твоё возражение против тезиса-то?
Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.
·>А иногда что-нибудь оптимизируется или предлагаются другие подходы для решения тех же задач. Если ваш продукт с каждым релизом всё медленнее, то вы делаете что-то не то.
Да-да, мы вам во всем верим.
S>>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают. ·>Клёво. А что вы ждёте от нас?
От "вас" -- это от кого?
·>И сколько вы готовы за это заплатить?
Мы заплатить? Это типа шутка.
S>>·>Но мне от этих сравнений ни тепло, ни холодно, S>>Но рот-то вы зачем-то открыли. Зачем? ·>Это публичный форум, я тут развлекаюсь.
Было подозрение, что вы херней страдаете. Подтвердилось.
·>А вы зачем открыли?
Вам закрыть. Боремся с непрофессионализмом и мракобесием.
·>Я наоборот очень хорошо представляю
Что-то пока не видно. Вам даже принцип бенчмарка ping-pong пришлось объяснять на пальцах.
·>поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие.
Еще раз: обещаний не было. Вам это русским языком уже было сказано. Но с русским у вас явные проблемы.
S>>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О. ·>Почему "одно", очевидно же, господин тролль.
Продолжаем обучать вас русскому языку. Исходная фраза: "Но одно из немногих живых и развивающихся". Словом "одно" обозначается наше решение, т.е. SObjectizer. SObjectizer в единственном числе. Поэтому "одно [решение] из немногих". Если бы SObjectizer-ов было несколько, фраза была бы построена по другому.
·>Причём тут ЯП?
42.
·>Ты повторяешь мои слова, без всякого смысла, да ещё на личности всё разговор сводишь, господин тролль.
Поскольку вы не можете говорить в предметную область, остается только указывать вам на то, что вы не можете.
·>Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой?
В нише C++: небезопасного нативного языка без сборщика мусора.
·>Т.е. фактически ты заявил "мы — неудачники, и это константация факта".
Нет. Мы заявили, что вы не в ладах с русским языком.
·>Да, мельком. Могу рассказать о своём впечатлении. Мне не очень понятно что там сравнивалось с т.з. прикладных задач и что этим предполагалось продемонстрировать.
На этом можно и закончить. Что, собственно, весь остальной текст и продемонстрировал.
Более того, вы даже не смогли разобрать, что в бенчмарке участвовали как тесты из SO-5, так и тесты из CAF-а.
·> _универсальный_ фреймворк, который, грубо говоря, позволяет одним флажком перенести прикладной код с микроконтроллера на массивный кластер или в GPU.
Это вообще уже за гранью добра и зла.
·>В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений...
Для массивной параллелизации вычислений применяются подходы из области parallel computing-а. OpenMP, например, MPI. И соответствующие библиотеки, вроде TBB или HPX.
А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.
·>Фреймворк != ЯП. В десятый раз повторяю. Не понимаю почему ты не различаешь.
Это просто вы в очередной раз не поняли о чем вам говорят.
·>Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc.
Зафиксируем еще раз проблемы с восприятием. То, что вам сказали про перезапуски -- это не было придумано. Это было взято из статьи Мартина Фаулера, на которую вам дали ссылку. Насколько это соответствует действительности сейчас, спустя несколько лет после публикации статьи -- это уже другой вопрос.
Даже если уже и не рестартуют JVM, то вот этот вот запуск GC только в строго определенное время и переинициализация счетчиков -- это просто образец универсальности решения.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
НС>>>И неэффективность. К примеру, как то раз в Решарпере производилась глобальная вычистка линка из кода. Как раз из-за тормозов при длинных цепочках итераторов. S>>Ну для этого есть <span class='lineQuote level2'>S>>roslyn-linq-rewrite</span>
НС>Это глючный костыль.
S>> Что в принципе несложно сделать и для рекурсивных yeld ов
НС>А что с экспоненциальными взрывами то делать?
Кстати а можно ссылочку на эти взрывы
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, so5team, Вы писали:
S>·>В чём было твоё возражение против тезиса-то? S>Высокая производительность есть как таковая. Не верите -- сравните какие-нибудь вычисления, написанные на чистом C++ и на чистом Ruby, Python-е или Erlang-е. Матрицы, например, поперемножайте или обратите, без использования сторонних библиотек. На Java попробуйте это же сделать, не прогревая JVM.
Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт. Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости.
А если рассуждать о производительности реальной системы, решающей бизнес-задачи, то "изначально высокой производительности" тебе никто не гарантирует.
И вообще, это жуткий увод в сторону. Обсуждаются 2М сообщений, и внезапно "умножаем матрицы не прогревая". Кстати, если прогрев является проблемой, есть решения, например Azul ReadyNow, jaotc и т.п.
S>>>В отличии от вас, у нас есть данные о производительности, о сравнении производительности с ближайшим конкурентом и о том, что эти цифры означают. S>·>Клёво. А что вы ждёте от нас? S>От "вас" -- это от кого?
Вы наверное имели в виду меня.
S>·>И сколько вы готовы за это заплатить? S>Мы заплатить? Это типа шутка.
Ну так хотя бы будет какое-то основание что-то от меня требовать.
S>>>Но рот-то вы зачем-то открыли. Зачем? S>·>Это публичный форум, я тут развлекаюсь. S>Было подозрение, что вы херней страдаете. Подтвердилось.
Я не страдаю, я наслаждаюсь.
S>·>А вы зачем открыли? S>Вам закрыть. Боремся с непрофессионализмом и мракобесием.
Начните с себя. Будет больше результата.
S>·>Я наоборот очень хорошо представляю S>Что-то пока не видно. Вам даже принцип бенчмарка ping-pong пришлось объяснять на пальцах.
Принцип я не спрашивал. Я спрашивал накой такой бенчмарк. Но объяснить вы затрудняетесь.
S>·>поэтому меня удивило обещание 200М. Как оказалось, не зря удивило, т.к. это простое словоблудие. S>Еще раз: обещаний не было. Вам это русским языком уже было сказано. Но с русским у вас явные проблемы.
Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие.
S>>>Почему "живое и развивающееся"? Потому что живое и развивающееся, ваш К.О. S>·>Почему "одно", очевидно же, господин тролль. S>Продолжаем обучать вас русскому языку. Исходная фраза: "Но одно из немногих живых и развивающихся". Словом "одно" обозначается наше решение, т.е. SObjectizer. SObjectizer в единственном числе. Поэтому "одно [решение] из немногих". Если бы SObjectizer-ов было несколько, фраза была бы построена по другому.
Где-то выше было сказано, что альтернатива будет — наколенные решения.
S>·>Я знаю, что erlang и akka в одной нише, я спрашиваю почему SObj в другой и в какой другой? S>В нише C++: небезопасного нативного языка без сборщика мусора.
Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке".
S>·>Т.е. фактически ты заявил "мы — неудачники, и это константация факта". S>Нет. Мы заявили, что вы не в ладах с русским языком.
Халва-халва.
S>·>В-третьих, ведь собственно весь этот Actor Model собственно и затевается для массивной параллелизации вычислений... S>Для массивной параллелизации вычислений применяются подходы из области parallel computing-а. OpenMP, например, MPI. И соответствующие библиотеки, вроде TBB или HPX. S>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются.
Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух?
S>·>Понимаю, конечно, господин тролль. Факт остаётся фактом, что "JVM с этой самой хитрой очередью для Disrutor-а раз в сутки перезапускали" — заблуждение, за которое ты с религиозным фанатизмом цепляешься и делаешь из него странные выводы о неэффективности gc. S>Зафиксируем еще раз проблемы с восприятием. То, что вам сказали про перезапуски -- это не было придумано. Это было взято из статьи Мартина Фаулера, на которую вам дали ссылку. Насколько это соответствует действительности сейчас, спустя несколько лет после публикации статьи -- это уже другой вопрос.
Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь. Как оно работает на самом деле я знаю прекрасно. Не делай выводов из ложного утверждения.
S>Даже если уже и не рестартуют JVM, то вот этот вот запуск GC только в строго определенное время и переинициализация счетчиков -- это просто образец универсальности решения.
Продолжаешь нести бред. Запуск GC тоже давно не делают. Счётчики и снапшоты это специфика бизнеса. Есть такое понятие End of Day на биржах.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт.
Ну т.е. высокая производительность сама по себе есть. ЧТД.
Далее вопрос только в том, как производительность, данная вам языком и рантаймом, вы будете убивать выбранными вами подходами.
И, внезапно, если у вас производительность изначально ниже, то и убить ее проще.
·>Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости.
Здесь границы применимости C++ не обсуждаются.
·>Вы наверное имели в виду меня.
Вряд ли. От вас мы вообще ничего не ждем, в силу никчемности ваших познаний. В том числе и в русском языке.
·>Ну так хотя бы будет какое-то основание что-то от меня требовать.
От вас никто ничего не требует.
·>Принцип я не спрашивал. Я спрашивал накой такой бенчмарк.
Простите, такого вопроса не было видно. Можете показать цитату?
·>Но объяснить вы затрудняетесь.
Вообще-то это очевидно. Подобный ping-pong бенчмарк с двумя рабочими нитями и передачей единичных сообщений в каждую сторону, является самой жесткой проверкой на стоимость передачи одного сообщения между рабочими нитями. Именно здесь видно, сколько стоит передача сообщения. В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики.
·>Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие.
Ничего подобного. Но т.к. вы в предмете не разбираетесь, то объяснять вам в очередной раз про разницу в нагрузке при большом потоке сообщений (когда batch/bulk обработка используется) и при единичных сообщениях, бесполезно.
·>Где-то выше было сказано, что альтернатива будет — наколенные решения.
Вы бы это, раз пришли общаться на русскоязычный форум, язык бы выучили. Поскольку вам русским языком было сказано:
Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.
Тут даже "фреймворки" во множественном числе употреблены, мы не говорили, что наш продукт единственный.
·>Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке".
Это из-за вашего эээ альтернативного понимания. Видите ли, когда вы можете использовать в своей задаче безопасный язык с GC и, более того, с VM, то вы можете сравнивать Erlang с Akka или Akka с Orleans. Но когда вам нужно писать на C, C++, Ada или Rust-е, то вам результаты замеров Erlang-а или Akka будут, мягко говоря, нерелевантны. Вам нужен будет инструмент для своего нативного языка. Со всей стоимостью, которую за это придется заплатить. И вам нужны будут результаты бенчмарков нативных фреймворков, в которых, например, нет GC и используется либо подсчет ссылок, либо вообще отданная на откуп пользователю преаллокация сообщений. Со всеми вытекающими.
S>>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются. ·>Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух?
От задачи зависит. Но т.к. мир C++ от вас бесконечно далек, то посмотрите в качестве примера на Go. Там ведь можно создать 100500 гороутин. И обслуживаться они будут всего несколькими рабочими нитями. Может, по вашему, в этом так же нет смысла?
·>Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь.
Вы сколько угодно можете это повторять. Вас интересовало, откуда взялась инфа про рестарты. Вам сказали. Далее можете спорить с Фаулером. Все приведенные здесь цитаты -- это спор о показаниях разных свидетелей, да еще в разное время.
·>Продолжаешь нести бред. Запуск GC тоже давно не делают.
Но ведь делали: We used to trigger a manual GC each night in a 5-minute trading gap, and tuned so that would be the only major GC in a day.
Это слова того вашего знакомого, на которого вы ссылаетесь.
Опять же, работа без ручного вызова GC лишь за счет Azul Zing -- это еще один признак универсальности Disruptor-а.
Там все ровно то же. Сперва простым алгоритмом строим НКА, потом преобразуем его в ДКА. Вот на этапе построения ДКА и можем получить тот самый взрыв состояний при неудачных данных.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>А я пока и не нанимался тебе его давать во всех подробностях. Интересна тема — вперед.
Интересна в разрезе linq, а не re. Инф-ии на этот счет не густо, можно было бы и на пальцах объясинть.
S>> Про регулярки понятно, а и итератором какие пробелемы?
НС>Ровно те же самые, как только появляются вложенные автоматы, которые нужно собрать в один большой ДКА.
А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?
Здравствуйте, Sharov, Вы писали:
НС>>А я пока и не нанимался тебе его давать во всех подробностях. Интересна тема — вперед. S>Интересна в разрезе linq, а не re. Инф-ии на этот счет не густо, можно было бы и на пальцах объясинть.
На пальцах я уже объяснил — никакой разницы с регексами нет, отличия только в исходном алгоритме построения НКА. Дальше все одинаково.
S>>> Про регулярки понятно, а и итератором какие пробелемы? НС>>Ровно те же самые, как только появляются вложенные автоматы, которые нужно собрать в один большой ДКА. S>А почему у нас nested expression должен развернуться в один большой автомат, а не в n маленьких?
Потому что минимизация ДКА и перформанс. Все ровно то же что и с регексами.
Здравствуйте, so5team, Вы писали:
S>·>Если вы работаете перемножателем матриц, то конечно, java не очень подойдёт. S>Ну т.е. высокая производительность сама по себе есть. ЧТД. S>Далее вопрос только в том, как производительность, данная вам языком и рантаймом, вы будете убивать выбранными вами подходами. S>И, внезапно, если у вас производительность изначально ниже, то и убить ее проще.
Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов?
S>·>Но даже в этом случае выбор C++ будет не очевиден. Сейчас есть GPU, FPGA, упомянутый parallel computing и прочие радости. S>Здесь границы применимости C++ не обсуждаются.
Т.е. применимость java к матрицам — обсуждается, а C++ не обсуждается. Предвзятненько как-то...
S>·>Но объяснить вы затрудняетесь. S>Вообще-то это очевидно. Подобный ping-pong бенчмарк с двумя рабочими нитями и передачей единичных сообщений в каждую сторону, является самой жесткой проверкой на стоимость передачи одного сообщения между рабочими нитями. Именно здесь видно, сколько стоит передача сообщения.
Обычно это проверяют передачей кучи сообщений от одного producer к одному consumer. И это является более менее реально возможным сценарием. В какой системе может понадобится пинг-понг — для меня загадка.
S>В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики.
Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки.
S>·>Не вали с больной головы. Ты заявил "вы получите 200M сообщений в секунду". Что, мягко говоря, словоблудие. S>Ничего подобного. Но т.к. вы в предмете не разбираетесь, то объяснять вам в очередной раз про разницу в нагрузке при большом потоке сообщений (когда batch/bulk обработка используется) и при единичных сообщениях, бесполезно.
И каким же образом получить 200М?
S>·>Где-то выше было сказано, что альтернатива будет — наколенные решения. S>Вы бы это, раз пришли общаться на русскоязычный форум, язык бы выучили. Поскольку вам русским языком было сказано: S>
Пока самая большая проблема в продвижении, это не показать, что наш фреймворк быстрее других. А просто рассказать, что местами можно брать готовые фреймворки, а не клепать на коленке свою thread-safe queue и thread-pool в придачу.
S>Тут даже "фреймворки" во множественном числе употреблены, мы не говорили, что наш продукт единственный.
Блин, настолько странное мировосприятие... повеяло IT моего студенчества, что даже не ожидал, MFC, ATL, EJB, CORBA, проекты на sourceforge... Бедный ваш PR. Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно. Тем более слово "фреймворк" в последнее время стало ругательным. Не удивительно, что это самая большая проблема, так слона вы не продадите.
S>·>Это не ниша. Это детали имплементации. Нет такой бизнес-задачи "запускать приложения на нативном языке". S>Это из-за вашего эээ альтернативного понимания. Видите ли, когда вы можете использовать в своей задаче безопасный язык с GC и, более того, с VM, то вы можете сравнивать Erlang с Akka или Akka с Orleans. Но когда вам нужно писать на C, C++, Ada или Rust-е, то вам результаты замеров Erlang-а или Akka будут, мягко говоря, нерелевантны. Вам нужен будет инструмент для своего нативного языка. Со всей стоимостью, которую за это придется заплатить. И вам нужны будут результаты бенчмарков нативных фреймворков, в которых, например, нет GC и используется либо подсчет ссылок, либо вообще отданная на откуп пользователю преаллокация сообщений. Со всеми вытекающими.
Ну так я и пытаюсь понять, что за такая бизнес-задача? Какого типа системы делаются на базе вашего фреймворка?
S>>>А Модель Акторов -- это подход из области concurrent computing. С его помощью другие задачи решаются и другие инструменты применяются. S>·>Ок. Какой же тогда смысл запускать Actor Model на одном треде?! Или даже на двух? S>От задачи зависит. Но т.к. мир C++ от вас бесконечно далек, то посмотрите в качестве примера на Go. Там ведь можно создать 100500 гороутин. И обслуживаться они будут всего несколькими рабочими нитями. Может, по вашему, в этом так же нет смысла?
Горутины это не модель акторов, насколько я знаю.
S>·>Я тебе в четвёртый раз повторяю. В статье Мартина Фаулера неточность или неоднозначность, которую ты не так понимаешь. S>Вы сколько угодно можете это повторять. Вас интересовало, откуда взялась инфа про рестарты. Вам сказали. Далее можете спорить с Фаулером. Все приведенные здесь цитаты -- это спор о показаниях разных свидетелей, да еще в разное время.
Я не хочу ни с кем спорить по этому поводу. Я знаю факты. Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна. Более того. Если почитать статью повнимательнее, то неоднозначность становится явной:
Restarting the Business Logic Processor is fast, a full restart — including restarting the JVM, loading a recent snapshot, and replaying a days worth of journals — takes less than a minute ....... they also restart the Business Logic Processors every night
Т.е. тот же самый "restart BLP" упомянут дважды, а restart JVM упомянут лишь в контексте "full restart".
В любом случае. Даже если бы пришлось рестартовать каждый хост в системе каждые 10 минут, это всё не имеет значения, благодаря архитектуре системы, когда копии сервисов запущены одновременно на нескольких хостах:
The replication allows them to do this with no downtime, so they continue to process trades 24/7.
Кстати, ещё одна неточность — у них система 24/5, по выходным торгов нет, биржа не работает.
S>·>Продолжаешь нести бред. Запуск GC тоже давно не делают. S>Но ведь делали: We used to trigger a manual GC each night in a 5-minute trading gap, and tuned so that would be the only major GC in a day. S>Это слова того вашего знакомого, на которого вы ссылаетесь.
Ну делали, давным давно перестали. И какой ты делаешь из этого вывод?
S>Опять же, работа без ручного вызова GC лишь за счет Azul Zing -- это еще один признак универсальности Disruptor-а.
Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов. С вашими блокировками эта задача вообще не решается. А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Я имел в виду решение задач, а не микробенчмарки. Можно найти примеры, где C++ сливает Яве. Будем из этого делать вывод, что и у C++ нет никакой изначальной высокой производительности? Или ты предлагаешь заняться тщательным отбором удобных фактов?
Вы высказали тезис, что изначально высокой производительности нет. В этом вы не правы. Она есть. Все. Дальше вы пытаетесь оправдываться.
·>Обычно это проверяют передачей кучи сообщений от одного producer к одному consumer. И это является более менее реально возможным сценарием. В какой системе может понадобится пинг-понг — для меня загадка.
Ну так факт вашего эээ альтернативного восприятия и альтернативной квалификации уже был установлен. Не удивительно, что какие-то вещи для вас загадка.
S>>В бенчмарках, в которых идет обработка пачек сообщений, показываются совсем другие характеристики. ·>Так пачек (batch) сообщений или больших (bulk) сообщений? Это вообще-то немного разные штуки.
Если вы пытаетесь провести такой водораздел между batch/bulk, то в случае в batch-ами, например, тормоза с выборкой сообщений из входящих очередей могут с лихвой компенсироваться тем, что из очереди сразу изымается N сообщений. Так, если у вас захват lock-объекта для очереди при изъятии сообщения стоит 1us, но вы забираете сразу 1000 сообщений, то общую производительность (т.е. количество сообщений, принятых для обработки за единицу времени) вы получите большую, чем если вы захватываете lock-объект за 250ns, но забираете из очереди всего одно сообщение.
Если до вас и такое объяснение не дойдет, то медицина здесь уже бессильна.
·>И каким же образом получить 200М?
Создать соответствующий входящий поток, которого, естественно, не может быть в честном ping-pong-е.
Ну и сразу предупрежу, что в SO-5 вы не получите 200M msg/sec на одном consumer-е, если на входе будет поток единичных сообщений. Даже при том, что некоторые диспетчеры в SO-5 механизм batching-а при извлечении сообщений используют.
·>Вместо тривиальной queue и pool предлагаете внезапно тащить в проект какой-то _фреймворк_. Почему эти queue и pool должны быть наколенными — мне вообще непонятно.
Ну покажите, например, queue и pool в стандартной библиотеке C++.
·>Ну так я и пытаюсь понять, что за такая бизнес-задача?
С вашим эээ альтернативным восприятием вы не сможете, не тратьте время.
·>Какого типа системы делаются на базе вашего фреймворка?
Разные. Из области телекома, платежных сервисов, имитационного моделирования, АСУТП.
·>Горутины это не модель акторов, насколько я знаю.
Ваш альтернативный способ мышления не позволяет проводить аналогии?
·>Хотите верьте, хотите — нет, фактам ваша религиозная вера не интересна.
Наш альтернативно одаренный собеседник, еще раз вынуждены вам сообщить о том, что здесь идет вопрос не о вере, а о свидетельских показаниях разных людей в разное время. Мы ничего не придумали, мы привели вам слова одного из свидетелей. Дальше вы с этим можете делать все, что захотите.
·>Ну делали, давным давно перестали. И какой ты делаешь из этого вывод? ·>Нет, проблема не в универсальности, а в жесткости требований. Задержка более 1ms — являются проблемой, более 10ms — нарушением SLA и звонок от "довольных" клиентов.
Вывод очень простой -- паттерн Disruptor не является универсальным. Это частное решение специфической задачи, да еще заточенное под специфические условия, инструменты и особый режим эксплуатации. А вы, в силу своей альтернативности, пытаетесь сравнивать частные специализированные решения с универсальными фреймворками.
·>С вашими блокировками эта задача вообще не решается.
Не решается. А разве где-то утверждалось обратное?
Более того, тот, кто будет пытаться такую задачу решать на SObjectizer-е, а так же любую другую задачу из области hard real-time, тот просто откровенный идиот.
·>А с жутким и ужасным gc на тормознющей яве — задачу решили много лет назад.
Молодцы. Могли бы еще проще решить на C++, если бы не религиозный фанатизм. Но речь вообще-то не об этом.
А о вашем гавкании "2M msg/sec -- это мало" при абсолютном непонимании того, о чем речь.
Еще как прет. Я на Go решил делать свой новый сервис. Язык классный, с одной стороны все удобства Си: скорость, развертываемость (тупо скопировал на машину файл и запустил), а с другой стороны синтаксис и garbage collection и гороутины делают программирование приятным как скажем на c# или питоне ))
А, что C++ или SObj с каждым релизом становится медленнее? 
