А>Из чего логически следует, что для этого в С++ либо есть готовая свободная либа, либо эффорт настолько мал, что сторонняя либа не нужна и пишется своими силами.
Эффорт, вообще-то, огромен. И есил его делать, как надо, в итоге родится Эрланг
Здравствуйте, Ikemefula, Вы писали:
I>Условно, если ты захочешь писать под винду на эрланге чтото навроде десктоп приложений. Функция SendMessage — блокирующая. Если адресат слегка задумался, на пол-секунды, ты висишь вместе с ним.
а, понял об чём ты.
да, это будет разрыв шедулера изза неконтролируемой задержки. поэтому вся эта шняга должна будет работать через какой-нибудь драйвер.
M>>Потому что первый же залетный mutex.lock убъет любую многопоточность и многоядерность.
EL>Вот откуда эта боязнь мьютексов и уверенность в том что захват мьюеткса обязательно убьет производительность? Бывают медленные message-ориентированные системы и быстрые системы с кучей мьютексов то тут то там. Можно попробовать какой-нибудь параллельный алгоритм реализовать на Erlang(Akka, чем угодно умеющем акторы) и на мьютексах и общей памяти. Я уверен что смогу на мьютексах уж точно не хуже напедалить (а скорее всего намного лучше).
Ну, я во многом образно написал. «Мьютексы» или, вернее, блокирующие вызовы в Эрланге есть (или, вернее, реализуются из неблокирующих). Эрланг предоставляет множество плюшек — от легковесных процессов до supervision trees, до практически гарантированной обработки этих процессов даже при высокой заргуженности системы, до достаточно грамотной реализации работы на многоядерных системах (минимизация context switch, cache miss и прочих — они в это очень активно вкладываются).
Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
Здравствуйте, Аноним931, Вы писали:
А>>>Так это же без проблем реализуемо на любом из распространенных языков, или нет? I>>Теоретически — да. Нужно всего лишь заврапать все такие вызовы в короутины, прикрутить внятный шедулинг, тред-пул и тд и тд.
А>Из чего логически следует, что для этого в С++ либо есть готовая свободная либа, либо эффорт настолько мал, что сторонняя либа не нужна и пишется своими силами.
Наоборот, задача слишком сложна для ручной реализации.
А>Итак, со сторонней ли либой или со своей, в С++ "выталкивание тяжелых блокирующих вызовов в тред-пул" работает прекрасно. Какие тогда остаются преимущества эрланга перед С++?
Выталкивать, по факту, придется вообще всё. Тот же Эрланг почти ничего не юзает, из системного, АПИ, а то немногое выталкивает в тред-пул.
Хочешь юзать по максимуму сервисы ОС — добро пожаловать в АДъ
M>Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
Ну то есть библиотеки все же есть. Следующий вопрос: какая на практике разница, делаю я что-то средствами "самого языка" или с помощью библиотеки?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Ikemefula, Вы писали:
I>>Ужос. При таких аццких достоинствах эрланг таки болтается на грани стат-погрешности. Что-то не так в датском королевстве. Подскажешь, что именно ?
F>у него очень узкая ниша и кастрированные возможности по абстрагированию и метаизвращениям. F>если утрировать, то выйдет, что это язык ровно для одной задачи — переложить что-то куда-то.
Переложить что-то куда-то — это 90%, а то и больше, задач в программировании. С точки зрения темы топика, пока что справедливо
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
M>>Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
А>Ну то есть библиотеки все же есть. Следующий вопрос: какая на практике разница, делаю я что-то средствами "самого языка" или с помощью библиотеки?
На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями. Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь. Да, есть библиотеки, реализующие корутины и зеленые потоки. Кто будет управлять этими потоками? Синхронизировать их? Отслеживать их аварийное завершение? Гарантировать их выполнение?
Здравствуйте, Mamut, Вы писали:
M>Переложить что-то куда-то — это 90%, а то и больше, задач в программировании.
это ничего не значит. 90% может быть обвязкой вокруг 10% более полезной работы.
вот если бы 90% проектов, то это было бы интересней.
а я на энларге однажды пытался сделать обычное перемещение персонажа на тайловой карте. и это очень медленно и неудобно.
хотя, казалось бы, проблема не сложная.
Здравствуйте, neFormal, Вы писали:
I>>Условно, если ты захочешь писать под винду на эрланге чтото навроде десктоп приложений. Функция SendMessage — блокирующая. Если адресат слегка задумался, на пол-секунды, ты висишь вместе с ним.
F>а, понял об чём ты. F>да, это будет разрыв шедулера изза неконтролируемой задержки. поэтому вся эта шняга должна будет работать через какой-нибудь драйвер.
Да, нужно навроде драйвера. Сам драйвер так же вводит издержки, вроде пенальти на времени отклика и тд.
И здесь весь блеск и нищета Эрланга. Если можешь свести к нулю количество зависимостей, получаешь профит. Если нет, получаешь тупик и петлю на шею.
Собственно, отсюда ясно, почему ниша Эрланга очень узкая — он рулит в тех немногих областях, где уже удалось убрать лишние зависимости.
Проблем добавил Chaos Godгражданин Брюер, своей теоремой. Затейники из Эрланга давно догадались вытащить плохие депенденсы наружу, получив распределенную систему. DeityГражданин Брюер сказал примерно следующее — *I* hereby punish you распределенное приложение может гарантировать только два условия, из трёх — consistency, availability и partition tolerance.
Не будь этой теоремы, щас бы все предавались пороку писали на Эрланге.
M>Ну, я во многом образно написал. «Мьютексы» или, вернее, блокирующие вызовы в Эрланге есть (или, вернее, реализуются из неблокирующих). Эрланг предоставляет множество плюшек — от легковесных процессов до supervision trees, до практически гарантированной обработки этих процессов даже при высокой заргуженности системы, до достаточно грамотной реализации работы на многоядерных системах (минимизация context switch, cache miss и прочих — они в это очень активно вкладываются). M>Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
Очень небольшому подмножеству приложений нужно реализовывать Эрланг, большинству не нужно ничего такого делать даже близко. СУБД должна реализовывать Эрланг внутри себя, или может HTTP сервер?
С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, mmap, контролировать memory layout объектов и структур данных и тд. Это требует большего количества работы, но зато позволяет достичь лучших результатов.
M>>Переложить что-то куда-то — это 90%, а то и больше, задач в программировании.
F>это ничего не значит. 90% может быть обвязкой вокруг 10% более полезной работы. F>вот если бы 90% проектов, то это было бы интересней.
F>а я на энларге однажды пытался сделать обычное перемещение персонажа на тайловой карте. и это очень медленно и неудобно. F>хотя, казалось бы, проблема не сложная.
Есть некоторые задачи, которые плохо ложатся на ФП. Это не проблема Эрланга, как такового. Ну 90% проектов у тебя не будет просто банально потому, что в 2015-м году вершиной мысли в большинстве языков является аналоги WaitForThread и mutex.lock(), а однопоточная VM называется web-scale
В таких условиях Erlang, к сожалению, остается в основном инфраструктурным клеем для таких языков (ну типа Erlang + RoR, Erlang + C++). Хотя люди на Эрланге делают что угодно — от распределенных баз данных и real-time аналитики до тестирования софта в автомобилях.
M>На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями. Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь. Да, есть библиотеки, реализующие корутины и зеленые потоки. Кто будет управлять этими потоками? Синхронизировать их? Отслеживать их аварийное завершение? Гарантировать их выполнение?
Во первых, уже можно создать 100500 обычных потоков ОС и не убить ось, сожрется куча памяти, но шедулер будет работать нормально. Во вторых, есть кооперативная многозадачность, я могу создать 100500 лековесных потоков с помощью boost.coroutine например, и переключаться между ними вручную. В третьих, многим приложениям оно надо?
Здравствуйте, Mamut, Вы писали:
M>Твой? Безусловно. Как всегда, в общем. Приперся в топик с видом «я дАртаньян, а вы тупое необразованное быдло» и говоришь об ортогональных топику вещах.
Ты хотел знать, почему ерланг никому не нужен, я тебе сказал.
M>Так как там мега Немерле
Я про немерле ни слова не сказал. Ты вообще адекватен?
Если бы я написал с другого аккаунта ты бы даже ответить ничего не смог.
Ибо ты всегда сливаешься, когда в обсуждении появляются технические аргументы.
M>и мега Нитра поживают?
Весьма не плохо для продукта, который ещё не написан.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sharov, Вы писали:
S>Неужто у эрланга все так плохо? Чего-то не верится...
Именно так всё плохо. Как и у любого другого динамически типизированного языка.
Да и модель многопоточности у него фундаментально ущербна.
Стоимость selective receive O(размер очереди). http://erlang.org/pipermail/erlang-questions/2005-November/017766.html
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Да, нужно навроде драйвера. Сам драйвер так же вводит издержки, вроде пенальти на времени отклика и тд.
если там и так задержки, то не пофиг ли уже?
I>И здесь весь блеск и нищета Эрланга. Если можешь свести к нулю количество зависимостей, получаешь профит. Если нет, получаешь тупик и петлю на шею.
если нет, то приходится обкладываться прокладками и получать доп.задержки.
I>Не будь этой теоремы, щас бы все предавались пороку писали на Эрланге.
как что-то плохое.
я тут пишу не по-неволе. что я могу ещё сказать?
M>>Твой? Безусловно. Как всегда, в общем. Приперся в топик с видом «я дАртаньян, а вы тупое необразованное быдло» и говоришь об ортогональных топику вещах. WH>Ты хотел знать, почему ерланг никому не нужен, я тебе сказал.
Нет. Ты просто что-то там заявил. Там, где Эрланг нужен, он очень даже нужен.
M>>Так как там мега Немерле WH>Я про немерле ни слова не сказал. Ты вообще адекватен? WH>Если бы я написал с другого аккаунта ты бы даже ответить ничего не смог. WH>Ибо ты всегда сливаешься, когда в обсуждении появляются технические аргументы.
Ты свой вопрос считаешь техническим аргументам? Ну-ну. И не тебе говорить про сливы.
Здравствуйте, Mamut, Вы писали:
M>Ты свой вопрос считаешь техническим аргументам? Ну-ну. И не тебе говорить про сливы.
А что производительность к техническим аргументам уже не относится?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
M>>На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями. Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь. Да, есть библиотеки, реализующие корутины и зеленые потоки. Кто будет управлять этими потоками? Синхронизировать их? Отслеживать их аварийное завершение? Гарантировать их выполнение?
EL>Во первых, уже можно создать 100500 обычных потоков ОС и не убить ось, сожрется куча памяти, но шедулер будет работать нормально. Во вторых, есть кооперативная многозадачность, я могу создать 100500 лековесных потоков с помощью boost.coroutine например, и переключаться между ними вручную. В третьих, многим приложениям оно надо?
На удивление многим. На это сложно перестроиться, потому что, как я тут выше говорил, для большинства программистов и Node.js — web scale, и обсчитать длинную задачу так, чтобы GUI не умирал — непосильная задача
Тот же boost.coroutine, из того, что я вижу — вполне шаг в нужном направлении (но к нужному направлению еще идти и идти)
