Здравствуйте, vdimas, Вы писали:
EP>>В ASIO есть поддержка IOCP, если чего-то необходимого нет — то при необходимости реализуется. EP>>Вопрос же скорее был про неявную нарезку алгоритма на фрагменты ("same fringe problem") — вот для этого подходит Boost.Coroutine, причём не только для IOCP — а и для любого другого подобного асинхронного кода. V>Ну, stateful нечестно ))
Они как раз для этого и предназначены.
Также есть частичная эмуляция stackless в Boost.Asio.
V>Для которотких и "неглубоких" обработчиков он, прямо скажем, из пушки по воробьям.
Не спорю, поэтому и считаю что нужны и stackless и stackful — они подходят для разных задач.
V>Вот у тебя 200k сессий съели почти всю память под стеки, а в случае stateless нужно ровно столько стеков, сколько физических потоков в пуле. При том, что "коротких" stateless-обработчиков может быть хоть под миллион и они нифига не съедят столько памяти.
Это понятно, тут со stateless хорошо то что они требуют ровно столько памяти, сколько требуется. Но вопрос-то был про другое.
Тем не менее, я без проблем запускал 400k stackful корутин на ноутбуке
Здравствуйте, so5team, Вы писали:
S>Т.о. зачем перекладывать на VM задачи, которые уже решены на уровне ОС, не понятно в принципе.
разные подходы в шедулинге.
F>>3. единое пространство потоков/процессов на нескольких физических юнитах S>Честно скажу, не очень понимаю, что это такое и зачем это нужно. Полагаю, что хороший пример чего-то подобного можно увидеть в .NET-овском Orleans, который уже упоминался выше в связи с очень интересной моделью акторов.
это довольно удобная штука, которая позволяет балансить нагрузку в соответствии со своими представлениями, загружать код на удалённые железки и динамически подключать новые юниты в кластер.
в orleans я, честно говоря, не нашёл ничего про это. по идее, должно бы быть описано в блоке silos. но он пустой.
а что там интересного в модели акторов? что они "виртуальные"? что это даёт?
Здравствуйте, neFormal, Вы писали:
S>>Т.о. зачем перекладывать на VM задачи, которые уже решены на уровне ОС, не понятно в принципе.
F>разные подходы в шедулинге.
Насколько разные? В одном только Linux-е несколько типов диспетчеров, под разные профили нагрузки. В РТОС свои диспетчеры, со своими тараканами.
Вы хотите сказать, что Erlang-овский шедулер заруливает их все по-определению?
F>это довольно удобная штука, которая позволяет балансить нагрузку в соответствии со своими представлениями,
Зачем для этого единое пространство процессов-потоков?
F>загружать код на удалённые железки и
Это проблема системы деплоймента. Не обязательно она должна быть зашита в язык.
F> динамически подключать новые юниты в кластер.
Зачем для этого единое пространство процессов-потоков? Разве недостаточно лишь ссылочной прозрачности для акторов?
F>в orleans я, честно говоря, не нашёл ничего про это. по идее, должно бы быть описано в блоке silos. но он пустой. F>а что там интересного в модели акторов? что они "виртуальные"? что это даёт?
Тем, что актор виртуально присутствует на любом узле в любое время. На самом деле его может и не быть в памяти, он автоматически поднимется, когда в этом возникнет необходимость. Причем, если позволяют условия, его могут поднять максимально близко к тому, кому этот актор понадобился (если я правильно помню PDF-ку с описанием).
Здравствуйте, so5team, Вы писали:
S>Несложно показать, что в принципе, сам Erlang не спасает ни от зависаний, ни от крахов.
всё не отпускает? а если метеорит упадёт, то оно тоже не должно зависать, да?
заканчивай с придирками.
S>Спрашивается, почему по-уму нельзя сделать на C++, Scala или Haskell?
на c++ нельзя добиться отказоустойчивости при ошибке в коде.
в скале в принципе можно всё сделать, но я не в курсе, что там с остальными пунктами.
хаксель тоже покрывает только часть пунктов, потому что натив.
Здравствуйте, neFormal, Вы писали:
S>>Спрашивается, почему по-уму нельзя сделать на C++, Scala или Haskell?
F>на c++ нельзя добиться отказоустойчивости при ошибке в коде.
Поэтому C++ -- это один из языков, разрешенных к применению в mission-critical системах.
Здравствуйте, neFormal, Вы писали:
S>>Спрашивается, почему по-уму нельзя сделать на C++, Scala или Haskell? F>на c++ нельзя добиться отказоустойчивости при ошибке в коде.
Можно, почему нет?
Вообще, что имеется в виду? Какой-нибудь seg-fault?
Здравствуйте, so5team, Вы писали:
S>Параллельное выполнение множества задач поддерживается в многозадачных ОС уже лет 50 как, если не больше. А с момента появления и распространения ОС, в которых единицей диспетчеризации является не процесс, а нить, прошло уже лет 25-30.
Ок, без проблем. Какая из распространённых ОС позволит запустить одновременно 100К нитей? Какое железо ей для этого потребуется?
25-30 лет назад понятие "множество" означало "примерно 100".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
V>>Просто напомню, что IOCP — это не только ввод/вывод, это просто механизм очереди событий, некий "порт", к которому можно подключить и ввод-вывод в том числе, и тогда PostQueuedCompletionStatus будет выполнять сама система по готовности данных. S>IOCP, в данном контексте, это механизм, который позволяет нам "ждать" неограниченного, в принципе, количества событий, не потребляя на каждое из них системный thread. S>Напомню, что исходная проблема — ровно в том, что традиционные императивные ЯП ориентированы именно на концепцию "control flow", и весь ввод-вывод предполагается блокирующим. S>Готовых механизмов для того, чтобы "уснуть" в точке вызова, и "проснуться" в момент прихода события, и при этом не занимать thread, в них нету.
а boost.coroutine? и вообще проблема не в том что языки плохие, а в том что в такой парадигме банально удобней програмировать. погляди на node.js — там от этой модели избавились, и кому это нужно?
а как это доказыват тезис о том что нужны *все* особенности эралнговской vm? у меня например архиватор, некоторых вохможностей эрланга/ghc мне не хватает, но устойчивость к аппаратным ошибкам в их число не входит
Здравствуйте, Sinclair, Вы писали:
S>Ок, без проблем. Какая из распространённых ОС позволит запустить одновременно 100К нитей? Какое железо ей для этого потребуется?
Полагаю, что 64-х битовые Linux, FreeBSD, Windows. На хорошем железе, да.
Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а. Соответственно, повторю в очередной раз: в большинстве распространенных языков нет того, что есть в Erlang. По определению. Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е.
Здравствуйте, so5team, Вы писали:
S>Вы хотите сказать, что Erlang-овский шедулер заруливает их все по-определению?
с чего вдруг? я такого не говорил.
F>>это довольно удобная штука, которая позволяет балансить нагрузку в соответствии со своими представлениями, S>Зачем для этого единое пространство процессов-потоков?
можно прозрачно обращаться к разным узлам.
F>>загружать код на удалённые железки и S>Это проблема системы деплоймента. Не обязательно она должна быть зашита в язык.
ээ, нет. деплой тут уже ни при чём.
если весь кластер является одной большой машиной, то тут уже можно свободно выбирать, где будет запускаться та или иная задача. не ограничивая себя деплоем.
F>> динамически подключать новые юниты в кластер. S>Зачем для этого единое пространство процессов-потоков? Разве недостаточно лишь ссылочной прозрачности для акторов?
что это значит в данном случае? а то я подозреваю, что мы об одном и том же.
F>>а что там интересного в модели акторов? что они "виртуальные"? что это даёт? S>Тем, что актор виртуально присутствует на любом узле в любое время. На самом деле его может и не быть в памяти, он автоматически поднимется, когда в этом возникнет необходимость. Причем, если позволяют условия, его могут поднять максимально близко к тому, кому этот актор понадобился (если я правильно помню PDF-ку с описанием).
не понимаю пока, чем это может быть полезно. видимо, это для просто параллельных рассчётов, где не важно расположение актора.
а когда хочется размещать это-там-а-это-вон-там, то подобное поведение начинает мешать.
Здравствуйте, so5team, Вы писали:
S>Но там же было сказано и более важное: нельзя предъявлять к C++/Scala/C#/Haskell/Ada и пр. такую претензию, что в этих языках нет фишек Erlang-а. Конечно их там нет. Более того, очевидно, что их там и не может быть (особенно если язык нативный). Но для решения таких же проблем concurrency computing и distributed computing в этих языках просто-напросто будут использоваться другие подходы и другие инструменты. И результат будет получаться не менее достойный.
в ghc (нативный компилятор хаскела) есть зелёные потоки, переключение происходит в момент аллокации, а она происходит постоянно
и я не согласен с твоей идеей что в C++ можно использовать только акторы. зелёные потоки — это по сути короутины, выполняемые из пула потоков, с автоматическим yield. ближайшим их аналогом в C++ являются те же самые короутины с ручным yield. при этом логика программы остаётся понятной, и очевидно кого срубать при возникновении исключения. task parallelism следует использовать только в случаях, когда очевидного разделения на процессы нет, а есть к примеру поток объектов, подвергаемых разнообразным преобразованиям
чем отличаются акторы от task parallelism, я пока не в курсе
Здравствуйте, so5team, Вы писали:
S>Боюсь, вы уводите разговор в другую сторону.
Да, в практическую — из стороны "спасает ли Erlang от зависаний и крахов в 100% случаев" и "можно ли на С++ написать все что угодно".
В теории ответы нет и да.
На практике написать отказоустойчивое приложение во многих случаях быстрее и дешевле на Эрланге, а две строки кода устанавливающие system_monitor срубающий обожравшийся памяти процесс спасли бы флюссоник от падений (но не от бага, конечно!) в широком спектре возможных неприятностей, включая описанную.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>и я не согласен с твоей идеей что в C++ можно использовать только акторы. зелёные потоки — это по сути короутины, выполняемые из пула потоков, с автоматическим yield. ближайшим их аналогом в C++ являются те же самые короутины с ручным yield. при этом логика программы остаётся понятной, и очевидно кого срубать при возникновении исключения.
У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
BZ>чем отличаются акторы от task parallelism, я пока не в курсе
В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
Акторы могут принимать поток из разных типов сообщений, обработка которых может зависеть от состояния актора. Грубо говоря, актор может представлять из себя читатель MQ-шных топиков, откуда идут запросы check_client, money_reserve, money_transfer_begin, money_transfer_status, money_transfer_cancel и т.д. При этом актор может проконтролировать, что сейчас он перегружен, не способен нормально обслуживать заявки и на запросы, скажем check_client/money_reserve/money_transfer_begin будет отвечать специальным кодом ошибки "overloaded".
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, meadow_meal, Вы писали:
_>>Мы пишем игровые сервера на Эрланге, приходилось интегрировать bullet3d (порядка 500 динамических миров на сервер, шедулер справляется), box2d, самописные тайловые и воксельные движки, но это 5-10% задач, большая часть времени все равно уходит на игровую логику, так что достоинствами Эрланга наслаждаемся в полный рост.
F>а что за игрушки?
Здравствуйте, neFormal, Вы писали:
S>>Вы хотите сказать, что Erlang-овский шедулер заруливает их все по-определению?
F>с чего вдруг? я такого не говорил.
Вот с этого:
F> 1. параллельное выполнение множества задач
Шедулеры ОС прекрасно справляются с этой штукой и труда в доведения шедулеров ОС до state-of-the-art тратиться в разы больше, чем для шедулера Erlang-а.
F>>>это довольно удобная штука, которая позволяет балансить нагрузку в соответствии со своими представлениями, S>>Зачем для этого единое пространство процессов-потоков?
F>можно прозрачно обращаться к разным узлам.
Это возможно и в случае, если адресация акторов не привязана к конкретным узлам.
F>>>загружать код на удалённые железки и S>>Это проблема системы деплоймента. Не обязательно она должна быть зашита в язык.
F>ээ, нет. деплой тут уже ни при чём. F>если весь кластер является одной большой машиной, то тут уже можно свободно выбирать, где будет запускаться та или иная задача. не ограничивая себя деплоем.
На узлах кластера дистрибутив Erlang-а откуда возникает? Записывается на винчестер производителем железа.
Т.к. Erlang VM вам нужно деплоить на все узлы кластера, точно так же вы можете деплоить хоть нативный код, хоть jar-ы, хоть .NET-овские сборки.
F>>> динамически подключать новые юниты в кластер. S>>Зачем для этого единое пространство процессов-потоков? Разве недостаточно лишь ссылочной прозрачности для акторов?
F>что это значит в данном случае? а то я подозреваю, что мы об одном и том же.
Это значит, что у актора есть ID/имя, по которому к актору можно обратиться из любого узла вне зависимости от того, где актор в данный момент находится.
F>>>а что там интересного в модели акторов? что они "виртуальные"? что это даёт? S>>Тем, что актор виртуально присутствует на любом узле в любое время. На самом деле его может и не быть в памяти, он автоматически поднимется, когда в этом возникнет необходимость. Причем, если позволяют условия, его могут поднять максимально близко к тому, кому этот актор понадобился (если я правильно помню PDF-ку с описанием).
F>не понимаю пока, чем это может быть полезно. видимо, это для просто параллельных рассчётов, где не важно расположение актора. F>а когда хочется размещать это-там-а-это-вон-там, то подобное поведение начинает мешать.
Не противоречит ли "хочется размещать это-там-а-это-вон-там" вашему же собственному требованию о прозрачности?
Здравствуйте, meadow_meal, Вы писали:
_>На практике написать отказоустойчивое приложение во многих случаях быстрее и дешевле на Эрланге,
На практике все упирается как в условия конкретной задачи, так и в наличие подходящих инструментов. Полагаю, что написание какой-нибудь Web-ни на Erlang-е на порядок проще, чем на C++. Тогда как в ситуации со специализированным софтом для управления оборудованием с применением CORBA и DDS все будет наоборот.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Вообще, что имеется в виду? Какой-нибудь seg-fault? F>>да, я про него. EP>Это решается компилятором и рантаймом. И проверка адресной арифметики, и контроль разыменования dangling poitners.
