Здравствуйте, hi_octane, Вы писали:
I>>Опять "лучший" и уже наверное третий год обещаний "скоро мы сделаем тааакоое !" _>Чисто развеять сомнения — сорцы нитры открыты, можешь дать ссылку на хотя-бы аналогичный?
Ближайший конкурент ANTLR4.
Но изменение грамматики во время разбора он не умеет и восстановление после ошибок у меня лучше (но ещё есть что улучшить).
Да и сам язык описания грамматики более человечный.
Остальные даже близко не стояли.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
V>К тому же, алгоритм "work stealing" является наилучшим известным на сегодня для диспетчеризации зеленых потоков. Какой алгоритм диспетчеризации в Эрланге?
Грубо говоря:
— По scheduler'у на ядро
— У каждого scheduler'а очередь, в которую кладутся процессы
— Когда начинает выполняться процесс, ему присваиватеся счетчик редукций
— На каждое действие (вызов функции, посылка сообщения и т.п.) счетчик уменьшается на один
— Когда счетчик доходит до нуля, процесс перемещается в конец очереди
— Процессы, которые ничего не выполняют (например, ожидают сообщение), в очереди не участвуют
— scheduler, у которого пустая очередь, может попросить другие scheduler'ы отдать ему процесс на обработку
Каждый из списка пункт настраивается: можно менять количество scheduler'ов, поведеине по передаче процессов, количество редукций и т.п. В последних версиях огромное количество внимание уделено внутренностям "scheduler'ов": все очереди lock-free, передачи процессов берут в расчет переключение контекстов CPU и cache misses, и стараются их избежать и т.п.
M>>Я перестал тебя понимать.
BZ>была ли эта грамотная реализация в првой версии эрланга?
Почти Потому что первая версия — это, по сути, Пролог с сахаром
BZ>почему ты думаешь, что сейчас она грамотна и эрланг дальше не будет разиваться? на чём основано убеждение в кривизне бибилотек — ты с ними хоть знаком?
То, что она грамотна доказывается эмпирически — опытом использования То, что она будет развиваться — понятно, что будет А кривизна баблиотек выливается из их кривизны: то, что в Эрланге считается простым туториалом для новичков (реализация gen_server) для большинства языков — это задача для семи пядей во лбу или вообще невыполнима
Здравствуйте, WolfHound, Вы писали:
_>>для 2) — не имеет значения, так как N всегда мало. WH>Ровно до тех пор, когда их вдруг станет много. WH>Именно это случилось в истории по ссылке.
Да нет же, в истории по ссылке случилась проблема с selective receive при коллах, и ее пофиксили 5 лет назад, ссылку я приводил.
Кроме коллов — не могу придумать причину использовать selective receive в нагруженных процессах, если кто-то использует — было бы интересно узнать зачем, но в любом случае это уже экзотика какая-то, а сама претензия уровня — почему реверс списка O(n). Для коллов — другое дело, т.к. функциональность базовая.
WH>1)Динамическая типизация -> неустранимые тормоза.
Ну и ладно.
WH>2)selective receive -> неустранимые тормоза + отказ в обслуживании в результате кратковременного сбоя.
S>Боюсь, вы уводите разговор в другую сторону. Некто под ником neFormal выдвинул ряд требований к языкам/фреймворкам/платформам, которые должны быть выполнены прежде, чем эти языки/фреймворки/платформы смогут считаться достойными сравнения с Erlang-ом. При этом в списке требований был пункт про отсутствие зависаний и крахов в принципе.
S>Несложно показать, что в принципе, сам Erlang не спасает ни от зависаний, ни от крахов.
Эрланг и не претендует. Потому что отказоустойчивая система обязана иметь как минимум две машины (см. работу Армстронга).
Как только у тебя есть две машины, вторая должна гарантированно узнать, что первая умерла, и почему.
Здравствуйте, Mamut, Вы писали:
BZ>>почему ты думаешь, что сейчас она грамотна и эрланг дальше не будет разиваться? на чём основано убеждение в кривизне бибилотек — ты с ними хоть знаком?
M>То, что она грамотна доказывается эмпирически — опытом использования
а опыт использования tbb у тебя есть?
M>То, что она будет развиваться — понятно, что будет А кривизна баблиотек выливается из их кривизны: то, что в Эрланге считается простым туториалом для новичков (реализация gen_server) для большинства языков — это задача для семи пядей во лбу или вообще невыполнима
а какие конкретно проблемы ты не смог решить, используя tbb?
S>Наглядная демонстрация того, что даже 64-бит Windows Home на далеко не серверном железе позволяет запускать 100K нитей. Что уже про Linux-ы/Unix-ы говорить.
Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
S>Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а.
Почему?
S>Соответственно, повторю в очередной раз: в большинстве распространенных языков нет того, что есть в Erlang. По определению. Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е.
Хуже. Потому что то, что в Эрланге есть из коробки (или реализуется на уровне туториала), в других языках лопатится вручную.
Здравствуйте, so5team, Вы писали:
S>Тогда зачем был написан вот этот список: S>Если для многих задач Erlang не подходит чуть больше, чем полностью.
ну, обойтись можно почти чем угодно.
но если уж мы решили померять, кто лучше энларга, то стоит сравнить с его основными фичами, которые дают удобство, скорость и дешевизну разработки.
S>Причем там, где он не подходит, все эти пункты решены давным-давно и никто уже по этому поводу даже не парится?
где они решены все сразу, а не частично?
не надо игнорировать какие-то пункты. иначе мы дойдём до того, что в принципе и на брейнфаке это всё реализуемо, если захотеть и не лениться.
пункты обязательны для сравнения. по остальным (скорость работы, удобства языка, чтотоещё) можно уже торговаться при выборе технологии для проекта.
Здравствуйте, so5team, Вы писали:
S>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine и сказал что подход с потоками принципиально неприменим в C++. на мой же взгляд, акторы — это малопопулярная парадигма, а основная как раз сейчас — task paralleleism к постепенным переходом к асинку (stackful/stackless coroutines)
S>В task parallelism, если я правильно помню, есть однородный поток задач, которые обрабатываются одним и тем же образом. Грубо говоря, идет поток текстовых сообщений, которые нужно зашифровать и подписать.
один вариант — это дерево задач, порождающих задачи и ждущих результата их исполнения. c++11 futures с доп. операциями типа waitAll и then. второй — это статичный граф задач, через которые текут потоки сообщений. в обоих случаях понятно как распространять исключения. в общем-то, мне кажется и в sobj это можно сделать — если кто-то подписался на сообщения от скончавшегося актора, то вместо очередного сообщения возбуждаем исключение в получателе. вероятно, в вашей скада-системе это просто незачем, да и вообще в моих по крайней мере задачах publish-subscribe имеет смысл только для доп. функционала (ui, logfile), а граф управления выглядит иначе
M>>То, что она грамотна доказывается эмпирически — опытом использования
BZ>а опыт использования tbb у тебя есть?
Нет
M>>То, что она будет развиваться — понятно, что будет А кривизна баблиотек выливается из их кривизны: то, что в Эрланге считается простым туториалом для новичков (реализация gen_server) для большинства языков — это задача для семи пядей во лбу или вообще невыполнима
BZ>а какие конкретно проблемы ты не смог решить, используя tbb?
Покажи мне реализацию supervision trees или простейшего gen_server'а на tbb.
Здравствуйте, so5team, Вы писали:
S>>>Вы хотите сказать, что Erlang-овский шедулер заруливает их все по-определению?
F>>с чего вдруг? я такого не говорил.
S>Вот с этого:
F>> 1. параллельное выполнение множества задач
S>Шедулеры ОС прекрасно справляются с этой штукой и труда в доведения шедулеров ОС до state-of-the-art тратиться в разы больше, чем для шедулера Erlang-а.
ты всё же определись — справляется ли шедулер винды с 100К потоков так же легко как эрланг или нет, а то ты уже несколько раз свою точку зрения в этом треде менял
Здравствуйте, Mamut, Вы писали:
S>>Наглядная демонстрация того, что даже 64-бит Windows Home на далеко не серверном железе позволяет запускать 100K нитей. Что уже про Linux-ы/Unix-ы говорить.
M>Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
Ссылка на исходник была дана выше. Посмотрите в код, поищите ручную работу с нитями/mutex-ами и еще чем-либо низкоуровневым.
Здравствуйте, so5team, Вы писали:
S>Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а. Соответственно, повторю в очередной раз: в большинстве распространенных языков нет того, что есть в Erlang. По определению. Тем не менее, задачи из области parallel-, concurrent- и distributed computing на этих языках решаются ничуть не хуже, чем на Erlang-е.
хорошо, ответим здесь. в хаскеле зелёные потоки есть. в C++ есть короутины, которые отличаются только тем, что надо вручную делать yield. соответственно, самый удобный для программистов вариант — именно короутины, а все прочие подходы, включая акторы — там где они удобны именно для выражения алгоритма задачи, безотсносительно к тому, один поток ОС их исполняет или десять
Здравствуйте, Mamut, Вы писали:
S>>Но суть в другом: не нужно работать с потоками ОС так же, как с легковесными процессами Erlang-а. M>Почему?
потому что не обязательно для параллельных вычислений.
но в этой парадигме непонятно, как происходит обмен сообщениями между сущностями. и есть ли вообще акторо-подобные сущности.
Здравствуйте, so5team, Вы писали:
F>>Полагаю, что 64-х битовые Linux, FreeBSD, Windows. На хорошем железе, да. S>Со 100K нитями в пуле.
так ты говорил как раз про потоки ОС. а здесь тестируешь нити своего SO5, т.е. как раз аналог легковесных потоков эрланга
S>Отработал, пруф. Было съедено где-то 7Gb RAM.
Здравствуйте, BulatZiganshin, Вы писали:
S>>У меня нет такой идеи. Даже в первом своем сообщении в этой теме в качестве примера фреймворка для C++ был приведен фреймворк Synca, который как раз сопрограммы и использует.
BZ>среди штук 5 акторных бибилотек. при этом ты ни словом не упомянул наиболее известные tbb/ppl/boost.coroutine
Boost.Coroutine -- это как раз низкоуровневая либа, при работе с которой нужно, как и при работе с threads вручную заниматься стартом/стопом и синхронизацией. Это не интересно. Интересно то, что над Coroutine надстраивают, та же Synca, тому пример.
tbb/ppl, как и недавно ставшая известной, hpx -- это инструменты для parallel computing. А так как, на мой взгляд, Erlang вообще не является инструментом для parallel computing, то и смысла упоминать tbb/ppl/hpx в разговоре про Erlang нет. Зато есть смысл говорить про инструменты для concurrent и distributed computing.
BZ> скаал что подход с потоками принципиально неприменим в C++.
S>>Наглядная демонстрация того, что даже 64-бит Windows Home на далеко не серверном железе позволяет запускать 100K нитей. Что уже про Linux-ы/Unix-ы говорить.
M>Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
да то же самое, что в эрланге — длительные операции кооперируются с шедулером и уводят свои потоки в спячку, выставляя completion handler. нет только автоматическолго yield
Потому что первая версия — это, по сути, Пролог с сахаром 
