Здравствуйте, Mamut, Вы писали:

M>В конце 90-х в офисе Эрикссона почти в полном составе сидела команда, создавшая GHC. Они полтора года пытались придумать для Эрланга систему типов. Не смогли Некоторые свойства системы (типа hot code loading) этому очень мешают.

Всякие штуки типа hot code loading или какие-нибудь живые monkey patch'и — это одно из главных преимуществ динамических языков.
Интересно послушать про твой опыт использования подобного в контексте реальных боевых программ на Erlang'е.

Здравствуйте, Mamut, Вы писали:

M>>>Что именно «прибито гвоздями»? В нем «прибита гвоздями» грамотная реализация того, что в библиотеках реализуется с разной степенью кривизны.

BZ>>т.е. эрланг был идеален с первой же версии и никогда не развивался?

M>Я перестал тебя понимать.

была ли эта грамотная реализация в првой версии эрланга? почему ты думаешь, что сейчас она грамотна и эрланг дальше не будет разиваться? на чём основано убеждение в кривизне бибилотек — ты с ними хоть знаком?

Здравствуйте, Mamut, Вы писали:

M>- Lightweight, massive concurrency
M>- Asynchronous communication
M>- Process isolation
M>- Error handling
M>- Continuous evolution of the system
M>- Soft real-time

M>Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.

чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать параллельные программы, нельзя обойтись без пунктов 5 и 6? по моему, тут просто перечислены свойства которые есть в эрланге (и которые нужны были им для их весьма специфических хадач), а никак не то что нужно лично мне в многопоточной программе

M>Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").

M>Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:

собственно, проблема в том, что мне не нужно разрабатывать высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам ака телекоммуникационных систем

соответственно, вопрос "нужен ли эрланг разработчикам свитчей" предлагаю оставить открытым и перейти ко всяким там nginx'ам

M>В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.

всегда мечтал встретить человека, который знаком с большинством современных языков и рантаймов. ты можешь проанализировать свои утверждения хотя бы в контексте ghc/ruby/tbb/ppl/node.js?

Здравствуйте, Mamut, Вы писали:

M>В начале 2000-х Эрикссон опрашивал своих крупнейших клиентов, хотят ли они типы в Эрланге. Почти дружный ответ был: нет, нам это не нужно.
Не уверен, что это показатель чего-либо. У динамических языков есть свои поклонники, логично, что они пишут, в основном, именно на таких языках (ну и наоборот). Правильнее было бы узнать нужны в сложившейся инфраструктуре преимущества именно динамических языков, а то может оказаться, что оно так по историческим причинам.

Здравствуйте, DarkEld3r, Вы писали:

M>>В начале 2000-х Эрикссон опрашивал своих крупнейших клиентов, хотят ли они типы в Эрланге. Почти дружный ответ был: нет, нам это не нужно.
DE>Не уверен, что это показатель чего-либо. У динамических языков есть свои поклонники, логично, что они пишут, в основном, именно на таких языках (ну и наоборот). Правильнее было бы узнать нужны в сложившейся инфраструктуре преимущества именно динамических языков, а то может оказаться, что оно так по историческим причинам.

но эрланг же выбирают не потому, что он динамический.

Здравствуйте, Mamut, Вы писали:

M>По сути, Эрланг выступает в виде современного Лиспа То, что было когда-то в Лиспе постепенно переползло в мейнстрим. Сейчас то, что есть в Эрланге тоже медленно переползает в мейнстрим Плюс концепции, заложенные в Эрланг, доказали, что они работают. Причем настолько, что чуваки, разрабатывающие распределенные базы данных, открыто говорят, например, что они стараются пользоваться только тем, что доступно в стандартной поставке Erlang'а — в 99% случаев этого более, чем достаточно.

Да не причем здесь язык. Просто (см. 10 требований телекома) сейчас стало нормой для разработки игры в пятнашки,
в которую могут играть сотни тысяч одновременно. Я уж не говорю про фб, гугл и проч.

И да, раз уж Эрланг так крут, чего же гугл стал изобретать свой велосипед Go, а не форкнул Эрланг.
Эрланг это язык, конкретно заточенный под телеком, со своими минусами и плюсами. Зачем его всюду пихать?
Это исключительно нишевый язык.

Здравствуйте, ELazin, Вы писали:

EL>>>Как определить что нуждается в зеленых потоках а что нет, есть ли какой-нибудь формальный метод, который позволяет определять, какую пользу потенциально могут принести зеленые потоки проекту?

BZ>>очень простой — сравни число логических параллельных ветвей в твоей программе (в данном случае число одновременно обращающихся клиентов умножить на параллелизм внутри каждого обращения) с числом аппаратных потоков cpu. как только первое больше второго, становится эффективней использовать пул потоков, а удобней всего это делать с помощью green threads

EL>Это единственный критерий? То что выполняется внутри зеленых потоков не имеет значения? А что если у меня клиентов всего вдвое больше хардварных потоков, что лучше использовать, потоки ОС или зеленые потоки?

BZ>>как раз с ними всё ровно — они программируются так же легко, как обычные, но при этом работают эффективней

EL>Они не программируются легко, в С++ ты должен сам написать всю логику их переключения, ты должен подумать об их приоритетах, ты должен подумать о возможном starvation этих потоков и об инверсии их приоритетов (если она возможна).

это мне напоминает давний спор о неудобстве использования lazy evaluation в хаскеле, который закончился тем, что мой оппонент признался что он пробовал его только в бусте

зелёные потоки, по определению — это когда обычный многопоточный код пускают не на потоках ОС, а на потоках рантайма. код при этом не меняется от слова вообще. как я тут уже упоминал, это сделано например в haskell/ghc. там просто лет десять назад в очережной версии компилятора добавили новый рантайм, затем подумали и выпилили за ненадобностью старый, поскольку он давал выигрыш всего в несколько процентов. на С++ это имхо невозможно, тут остаются только реализации с явным yield, т.е. stackful coroutines. ну или stackless, но их использовать ещё сложнее

поэтому вопрос в ghc стоит так — у нас есть зелёные потоки и нам в общем-то пофиг на соотношение числа потоков и ядер. и собственно никаких проблем это не создаёт, за исключением отсутствия проритетов. но их ведь тоже можно сделать, верно?

возвращаясь к С++ — зелёные потоки позволяют не задумываться о том как лучше поступить если ядер окажется меньше чем потоков, или если какие-то потоки выполняют слишком мало работы, и тем самым упрощают работу программиста. поэтому их отсутствие — недостаток языка/рантайма. просто представь как здоровобы было, если бы все твои многопотчоные программы автоматом стали использовать зелёные потоки и не пришлось бы разучивать futures, async/await, tbb/ppl и всё прочее, что нагородили в языке/библиотеках/бусте/vendor-specific and 3rd-party libs

>Ты должен учитывать характер нагрузки, если ты пишешь сервер, который отдает данные, которые лежат в замапленном с помощью mmap файле, ты тоже будешь использовать зеленые потоки или потоки ОС?

а в чём тут проблема? nginx например отдаёт файлы с диска с помощью sendfile и тысячи их могут одновременно исполняться на одном потоке ОС

Здравствуйте, Sinclair, Вы писали:

V>>Т.е. просто куча потоков сидит себе на UDP-сокете, и по мере прихода новых пакетов просыпается очередной поток. В Linux при этом можно управлять шедуллингом потоков, в т.ч. достичь алгоритма, близкого по логике к популярному ныне work stealing.
S>Что-то я не понял. Ну, вот есть у меня, скажем, сервер на порту, скажем, TCP 80. Предположим, что http.sys в системе отсутствует — т.е. я работаю напрямую с сокетами.
S>У меня активно 20000 TCP-сессий параллельно. Сколько у нас будет потоков, что они будут делать, и каким образом?

Речь про UDP-сокет. На одном сокете банально сидят в блокирующем ожидании несколько потоков (обычно кол-во ядер + 1). Так работает IAX. Кол-во одновременных VoIP сессий неограниченно (вернее, ограничено кол-вом исходящих UDP-портов на ближайшем роутере).

По приходу пакета с ним приходит его обратный адрес и порт — это ключ сессии, с этим ключом к нам постучались изначально для установления связи. Ответные пакеты посылаются по этому же адресу и роутеры знают, что с этим делать — так работают UDP-сессии (как бы дико это ни звучало).

Потеря пакетов/повторы и т.д. обыгрываются на прикладном уровне протокола IAX, т.е. получается свой транспорт поверх UDP.

Классических "окон" как в TCP нет, потому что трафик по каждой сессии не бесконечен, а определяется параметрами звукового кодека, поэтому, в плане передачи медиа всё близко к тому, что происходит в RTP, с тем чудесным отличием, что для RTP для каждой сессии нужно создавать свой сокет и без IOCP подобной схемы уже не достичь.

IAX — это порождение Linux, на нем нет IOCP, но есть вот такие трюки. И есть еще целый набор "фиктивных" файлов, типа eventfd, на которых можно организовать похожую схему.

Просто напомню, что IOCP — это не только ввод/вывод, это просто механизм очереди событий, некий "порт", к которому можно подключить и ввод-вывод в том числе, и тогда PostQueuedCompletionStatus будет выполнять сама система по готовности данных.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

S>>>Есть ли в бусте что-то, позволяющее мне нарезать линейный (по спецификации) алгоритм на фрагменты, которые можно исполнять по мере поступления IOCP, без мучительной отладки и замусоривания кода бойлерплейтом?
V>>Нет.

EP>Как это нет? В Boost.Asio есть поддержка stackful coroutine из коробки.

Ты, наверно, недопонял вопрос.
См. примеры реализации асинхронщины на дотнете на async/await.
Там обыгрывается не только и не столько ввод/вывод (т.е. не только asio), а вообще любой асинхронный код.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

V>>>>ИМХО, для statefull ничего в сам язык добавлять не надо, это запросто реализуется на уровне библиотек.
EP>>>Да, реализуются, точно также как и обычные потоки. Но в любом случае не помешают.
V>>Можно пример синтаксиса?

EP>Чего? Stateful coroutine? — Boost.Coroutine.

Еще раз, в сам язык надо что-то добавлять или нет?
Моё мнение, что для stateful — ничего не надо. Синтаксис и так вполне.

EP>А я не говорил что есть разница. Я как раз наоборот показываю пример что обычные потоки в C++ реализовывались в чисто библиотечном виде — например boost::thread, который практически полностью перекочевал в ISO.
EP>Точно также факт того что stackful coroutine реализуется в виде библиотеки, не является аргументом против включения их в стандарт (в таком же библиотечном виде, без дополнительных ключевых слов).

А ну эт да, на уровне библиотеки — ОК.


EP>Одна из проблем была в том, что предлагалось каждую stackless корутину аллоцировать в куче. Я же считаю что аллокация должна быть ортогональна — задача компилятора сгенерировать класс конечный автомат из моего "линейного" кода с yield, а уж где я его буду размещать — в куче, на стэке, в каком-нибудь векторе — это моя забота.

Э, нет. Эта корутина, по-сути, наследник shared_state у целевого future, представляющего собой состояние корутины. Т.е. этот shared_state заведомо необходимо делить м/у потоками.


EP>Также хочется чтобы такой класс конечный автомат поддерживал и копирование и перемещение, а в предложениях ЕМНИП он был прибит гвоздями к тому месту где был создан.

Я тебе скажу, что это НЕВОЗМОЖНО. Но это совершенно отдельный тред. Ты готов будешь возражать? ))
Что есть future, вообще? Как ты создашь "копию" future, если это бессмысленно, т.к. тебе надо создать копию некоего процесса, дергающего за promise (или сразу за внутренний shared_state), но этот процесс — это внешний асинхронынй источник событий. Вот как ты этот "внешний мир" скопируешь и куда, собсно??? ))


EP>Другой проблемой было то, что первоначально предложенные корутины (насколько я помню, они даже были реализованы как расширение MSVC) — вобрали в себя всё худшее от stackless и stackful, и убрав преимущества. Использование было как у stackless (то есть нельзя сделать yield через несколько уровней), а вот реализация была как у stackful (то есть относительно громоздкие, в десятки байт их без большого труда не поместить).

Сейчас proposal оперирует универсальной парадигмой resumable, где resumable ф-ии могут состоять из других resumable ф-ий.

Здравствуйте, vdimas, Вы писали:

S>>>>Есть ли в бусте что-то, позволяющее мне нарезать линейный (по спецификации) алгоритм на фрагменты, которые можно исполнять по мере поступления IOCP, без мучительной отладки и замусоривания кода бойлерплейтом?
V>>>Нет.
EP>>Как это нет? В Boost.Asio есть поддержка stackful coroutine из коробки.
V>Ты, наверно, недопонял вопрос.
V>См. примеры реализации асинхронщины на дотнете на async/await.
V>Там обыгрывается не только и не столько ввод/вывод (т.е. не только asio), а вообще любой асинхронный код.

В ASIO есть поддержка IOCP, если чего-то необходимого нет — то при необходимости реализуется.
Вопрос же скорее был про неявную нарезку алгоритма на фрагменты ("same fringe problem") — вот для этого подходит Boost.Coroutine, причём не только для IOCP — а и для любого другого подобного асинхронного кода.

M>>По внятности C++ (и кого бы то ни было) размалывает только Erlang. Пока другие тольк-только подбираются к концепциям, которые были в нем уже в начале 90-х, они уже думают о том, как правильно работать на десятках тысяч ядер, и оптимизируют работу системы для грамотной работы с переключением контекстов в CPU и cache miss.

Объективности ради, пока кто-то думает, как правильно работать на десятках тысяч ядер, нативный код на Fortran-е и C++ давным давно, с 80-х годов решает вычислительные задачи такого объема, которые Erlang-ерам могут даже и не снится. Например, построение прогнозов погоды. В качестве инструментария -- старые добрые MPI и OpenMP.

M>Отвечу тут сразу на несколько веток о том, почему я считаю, что по параллельности и распределенности Эрланг на данный момент уделыввает всех, а остальные ему завидуют активно вбирают те же идеи и реализуют их или на уровне языка или в библиотеках.

Уместно ли здесь употребление термина "параллельность"? Parallel computing -- это способ сократить время выполнения задачи за счет максимально полного одновременного задействования всех вычислительных ресурсов, т.е. ядер. Разве можно всерьез говорить о parallel computing на Erlang-е с его скоростью выполнения родного Erlang-овского кода? Пока pure-Erlang-реализация какого-нибудь вычислительного алгоритма только только завершит валидацию входных аргументов, реализация того же самого на C/C++/Fortran уже закончит расчет.

Если же переписывать критичные по скорости куски на С/C++/Fortran, то Erlang превратиться всего лишь в клеевой язык, не имеющий особых преимуществ перед каким-нибудь Python или Ruby, т.к. хваленый шедулер Erlang-а ничего не сможет сделать с нативным кодом, который будет находиться в NIF-ах и драйверах, написанных на нативных языках.

M>Если ваш язык реализует только корутины — это не распеределенность/параллельность и не Эрланг.
M>Если ваш язык реализует только зеленые потоки — аналогично
M>Если у вас есть какая-то библиотечка для менеджмента потоков — аналогично
M>... вписать остальное ...
M>Начнем с того, что...

Начинать нужно с того, что подход Erlang-а к решению проблем concurrent computing не единственный возможный. Т.е. если выделять отдельный процесс под выполнение какой-то активности от начала и до конца, то здесь Erlang вне конкуренции за счет того, что у него собственный шедулер и сборщик мусора, успешно поддерживающие работу сотен тысяч легких процессов.

Существует и другой подход, который принято называть SEDA-way, при котором отдельный процесс/нить заводится не под всю активность, а под определенную операцию (stage) в рамках активности. Сами же активности могут оформляться либо в виде легковесных короутин, либо в виде еще более легковесных объектов (конечных автоматов). Задача этих объектов всего лишь передача сообщений между stages.

Так, если у нас есть задача:

• принять по HTTP запрос;
  
• проверить, не повторный ли это запрос (если повторный, то отдать уже имеющийся результат и прекратить обработку);
  
• провалидировать параметры запроса;
  
• передать запрос сторонней системе;
  
• получить ответ от сторонней системы;
  
• зафиксировать ответ в БД;
  
• отдать ответ назад;

То в случае с Erlang-ом естественным выглядит выделение на каждый такой запрос отдельного Erlang-овского процесса. Этот процесс будет инициировать все стадии обработки. За счет возможностей Erlang-овой VM можно будет параллельно обрабатывать сотни тысяч каких запросов.

Однако, в случае с C++ или Scala такой подход не представляется разумным из-за того, что нет легковесных потоков, для которых бы рантаймом языка обеспечивалась бы вытесняющая многозадачность. В этих языках более разумным будет выделение отдельной сущности со своим рабочим контекстом (или несколькими контекстами) под каждую из стадий. Как то:

• отдельный stage под проверку уникальности запроса;
  
• отдельный stage под валидацию параметров;
  
• отдельный stage под работу со сторонней системой;
  
• отдельный stage под фиксацию ответов сторонней системы в БД;

В таком подходе окажется, что нужно иметь очень небольшое количество рабочих потоков, которые будут обслуживать те же самые сотни тысяч параллельных активностей. При этом получаются еще и приятные бонусы в виде более простого overload control (нагрузка на каждую стадию хорошо видна) и bulk processing (каждая стадия может накапливать пачки запросов и обрабатывать их одной операцией).

Так что достаточно странно сейчас читать лозунги о том, что Erlang круче всех потому, что того, что есть в Erlang нет в других языках. Да, точно такого нет. Но нет потому, что в других языках более естественным является использование других подходов, как к concurrent programming, так и к parallel programming.

Ну и если уж зашла речь о том, что могут другие языки, то не так уже и мало. Особенно, если посмотреть на Akka, в которую вкладываются приличные ресурсы. Ни в один из OpenSource-фреймворков для C++ такие ресурсы не вкладываются, но сами фреймворки есть и они вполне себе живы-здоровы: C++ Actor Framework, Synca, SObjectizer. Список того, что есть для других экосистем, можно посмотреть в Wikipedia. Там примечателен, например, Orleans для .NET, у которого вообще своя довольно уникальная модель акторов.

PS. Ну и да, супервизоры в C++ных фреймворках делаются на раз два. Что в CAF, что в SObjectizer.

Здравствуйте, vdimas, Вы писали:

V>>>Можно пример синтаксиса?
EP>>Чего? Stateful coroutine? — Boost.Coroutine.
V>Еще раз, в сам язык надо что-то добавлять или нет?
V>Моё мнение, что для stateful — ничего не надо. Синтаксис и так вполне.

Да, синтаксис менять не надо.

EP>>Одна из проблем была в том, что предлагалось каждую stackless корутину аллоцировать в куче. Я же считаю что аллокация должна быть ортогональна — задача компилятора сгенерировать класс конечный автомат из моего "линейного" кода с yield, а уж где я его буду размещать — в куче, на стэке, в каком-нибудь векторе — это моя забота.
V>Э, нет. Эта корутина, по-сути, наследник shared_state у целевого future, представляющего собой состояние корутины. Т.е. этот shared_state заведомо необходимо делить м/у потоками.

Нет, корутины ортогональны future — их можно использовать вместе, но совсем необязательно. В коде Boost.Coroutine "future" вообще нигде нет.

EP>>Также хочется чтобы такой класс конечный автомат поддерживал и копирование и перемещение, а в предложениях ЕМНИП он был прибит гвоздями к тому месту где был создан.
V>Я тебе скажу, что это НЕВОЗМОЖНО. Но это совершенно отдельный тред. Ты готов будешь возражать? ))

Конечно, и даже готов показать как это именно возможно на примере stackless coroutine из Boost.Asio.

V>Что есть future, вообще? Как ты создашь "копию" future, если это бессмысленно, т.к. тебе надо создать копию некоего процесса, дергающего за promise (или сразу за внутренний shared_state), но этот процесс — это внешний асинхронынй источник событий. Вот как ты этот "внешний мир" скопируешь и куда, собсно??? ))

future тут вообще не причём, stackless coroutine как фича языка должна брать код/функцию обычного вида и трансформировать её в класс-автомат, где поля это переменные из тела функции, а состояния — точки останова yield. В C# yield именно таким образом и реализован.
future и подобное появляются только в частных случаях корутин применения типа await.

V>Сейчас proposal оперирует универсальной парадигмой resumable, где resumable ф-ии могут состоять из других resumable ф-ий.

Насколько я помню, там был далеко не единственный proposal (причём от разных авторов). В каком оно сейчас состоянии — не знаю, надо будет проверить.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>а зачем вообще стандартные библиотеки в язык добавляют?

Насчет либы согласен. Я подумал, что по аналогии с resumable предлагается добавлять какие-то ключевые слова.

BZ>PS: хотя я несколько запутался. мы ведь под stateful подразумеваем именно stackful? вообще лучше пользоваться терминологией stack*, тут интерпретация однозначна

Да.

stateful — это как виндовые фиберы + механизм для создания произвольных точек входа/выхода,

stateless — это синтаксический сахар над

task1().then(task2).then(task3)...

Вместо показанного синтаксиса можно будет писать так (resumable):

future<void> foo() resumable
{
  int x = await task1(); 
  double y = await task2(x); 
  complex z = await task3(y);
  store_result(z);
}
// где
future<int> task1(void) {}
future<double> task2(int) {}
future<complex> task3(double) {}
void store_result(complex){}

Хотя, для некоторых вещей мне первый вариант больше нравится.. Это привычные тебе монады, где результат предыдущих вычислений по мере их готовности передаётся в следующее вычисление и так до конца или до первой ошибки.

Напомню, что future — это maybe{value, error}, если хоть какой-то taskN перейдет в состояние error, то остаток цепочки не вызывается, а результатом конечного future сразу станет error (std::exception_ptr, хранящее в себе копию исключения).

Ну и еще напомню, что в С++ можно переопределять операторы чуть ли не как угодно, потому я не удивлюсь, если умельцы довольно скоро станут безобразничать на примерно такой манер:

task1 >> task2 >> task3 >> store_result;

Ну и еще отличие от обычных монад в том, что разные >> будут выполнены в разных потоках (в общем случае), т.к. это просто подписка на событие set_value()/set_exception(), которое затем происходит каждый раз где угодно.

А не, вру. Если на момент, когда в текущем потоке мы производим подписку через then, целевое future уже is_ready, то колбэк выполняется сразу из текущего потока.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>2. Я в код не смотрел, но разве boost::future::then создаёт новый поток с блокирующим wait/get, вместо того чтобы просто прицепить продолжение к текущему future?

Да, потому что у текущего future<> некуда цеплять продолжение.

EP>Если так — то конечно это плохо, но я что-то сомневаюсь.

Ерунда. Еще proposal толком не утвержден, т.е. это только макет и в доке буста так и сказано.

Здравствуйте, vdimas, Вы писали:

EP>>2. Я в код не смотрел, но разве boost::future::then создаёт новый поток с блокирующим wait/get, вместо того чтобы просто прицепить продолжение к текущему future?
V>Да, потому что у текущего future<> некуда цеплять продолжение.

Я вижу внутри вектор под продолжения:
https://github.com/boostorg/thread/blob/master/include/boost/thread/future.hpp#L137

typedef std::vector<continuation_ptr_type> continuations_type;
// ...
continuations_type continuations;

EL>>Они не программируются легко, в С++ ты должен сам написать всю логику их переключения, ты должен подумать об их приоритетах, ты должен подумать о возможном starvation этих потоков и об инверсии их приоритетов (если она возможна).

BZ>это мне напоминает давний спор о неудобстве использования lazy evaluation в хаскеле, который закончился тем, что мой оппонент признался что он пробовал его только в бусте

я использовал зеленые потоки в Go совсем недавно, это сойдет за опыт использования?

BZ>зелёные потоки, по определению — это когда обычный многопоточный код пускают не на потоках ОС, а на потоках рантайма. код при этом не меняется от слова вообще. как я тут уже упоминал, это сделано например в haskell/ghc. там просто лет десять назад в очережной версии компилятора добавили новый рантайм, затем подумали и выпилили за ненадобностью старый, поскольку он давал выигрыш всего в несколько процентов. на С++ это имхо невозможно, тут остаются только реализации с явным yield, т.е. stackful coroutines. ну или stackless, но их использовать ещё сложнее

спасибо за ликбез, без тебя не разобрался бы никогда, жаль что ты так же хорошо не ответил на кучу прямых вопросов в моем сообщении
если что, я не спорил с тем что в с++ это реализуется сложнее, я спорил с тем, что зеленые потоки — штука универсальная, которую нужно использовать везде, о чем ты тут пытаешься толковать для меня остается загадкой

BZ>поэтому вопрос в ghc стоит так — у нас есть зелёные потоки и нам в общем-то пофиг на соотношение числа потоков и ядер. и собственно никаких проблем это не создаёт, за исключением отсутствия проритетов. но их ведь тоже можно сделать, верно?

эммм...?? на что ты ссылаешься (ссылка на статью, или хотя бы на запись в бложек)? ты вообще в курсе того как это работает и того что для нормальной работы зеленым потокам нужна серьезная поддержка рантайма, которая может сказываться на производительности? Ну вот например как из зеленого потока делать системные вызовы, чтобы шедулер этих потоков колом не вставал? Если ответишь на этот вопрос, ответь пожалуйста и на такой — как это может быть пофиг и не создавать проблем? Я могу привести множество кейсов, когда зеленые потоки будут хуже (я кстати приводит такой кейс, ты проигнорировал).

BZ>возвращаясь к С++ — зелёные потоки позволяют не задумываться о том как лучше поступить если ядер окажется меньше чем потоков, или если какие-то потоки выполняют слишком мало работы, и тем самым упрощают работу программиста. поэтому их отсутствие — недостаток языка/рантайма. просто представь как здоровобы было, если бы все твои многопотчоные программы автоматом стали использовать зелёные потоки и не пришлось бы разучивать futures, async/await, tbb/ppl и всё прочее, что нагородили в языке/библиотеках/бусте/vendor-specific and 3rd-party libs

зеленые потоки не решают всех проблем, fine-coarse grained traidoff никуда не исчезает, если твои зеленые потоки будут слишком мелкими ты будешь платить за их переключение слишком много, если нет — не будешь в полной мере использовать возможности системы, ну опять же, зеленые потоки должна поддерживать каждая сраная библиотека (вспоминаем историю с питоновским gevent), в противном случае все будет вставать колом при любом удобном случае

>>Ты должен учитывать характер нагрузки, если ты пишешь сервер, который отдает данные, которые лежат в замапленном с помощью mmap файле, ты тоже будешь использовать зеленые потоки или потоки ОС?
BZ>а в чём тут проблема? nginx например отдаёт файлы с диска с помощью sendfile и тысячи их могут одновременно исполняться на одном потоке ОС

в том, что с помощью sendfile nginx перекладывает работу на ядро (никаких зеленых потоков там нет) и в том, что во многих других случаях, твои зеленые потоки не дадут никакого преимущества, а скорее наоборот, я приводит пример сервера, который мапит себе что-нибудь в память, соответственно, при любом обращении к этой памяти может произойти page fault, а это блокировка потока. В случае потка ОС это не проблема, в случае зеленого потока это -1 поток в тред пуле поверх которого это все работает.

В общем, дискуссии явно не получится если каждый будет обсуждать то что ему интересно. Я предлагаю на досуге поискать инфу о том, как в разное время в разных системах пытались имплементировать M:N threading и что из этого получалось.

Здравствуйте, WolfHound, Вы писали:

M>>Про «фундаментально ущербную модель многопоточности» Wolfhound пусть рассказывает сказки и дальше, ведь он у нас известный теоретик и сказочник. Любую даже самую грамотно спроектированную систему всегда можно нагнуть. Заметь, что он до сих пор носится со ссылкой на сообщение 2005-го года (!), в которой говорится о том, что систему удалось нагнуть однажды (!).
WH>А что с тех пор что-то изменилось?
WH>Вообще это вторая ссылка в гугле по запросу selective receive.

Selective receive нужен:
1) для коллов
2) в короткоживущих рабочих процессах, например посредниках, агрегаторах, и т.п.
и на практике больше нигде (т.к. подавляющая часть процессов произвольного приложения эрланга это gen_server'ы или его аналоги и попадают под пункт 1)

для 1) — да, изменилось, в 2010:
http://www.erlang.org/download/otp_src_R14A.readme
см. OTP-8623

Идея в том, что если мы создаем уникальный терм и отправляем его получателю а затем далее в этой же функции выполняем selective receive по образцу содержащему этот терм, то компилятор делает специальную оптимизацию и стоимость всегда константна. Это может и хак, но во-первых он спрятан в недрах стандартной библиотеки (gen:call), а во-вторых решает практическую задачу (а Эрланг, как промышленный язык, ориентирован в первую очередь на практику)

До 2010 года существовала как минимум реализация gen_server2 (сторонняя библиотека), обходящая эту проблему.

для 2) — не имеет значения, так как N всегда мало.

Не знаю, есть ли у эрланга фундаментальные проблемы, но selective receive точно не одна из них.

Здравствуйте, so5team, Вы писали:

S>Ну и если уж зашла речь о том, что могут другие языки, то не так уже и мало.

ага, все умеют "свою половину языка Erlang".
так много слов а суть проста. другим технологиям необходимо добиться паритета по следующим пунктам:
1. параллельное выполнение множества задач
2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)
3. единое пространство потоков/процессов на нескольких физических юнитах

для этого желательна виртуалка с байт-кодом, модель акторов или схожий механизм обмена сообщеньками и сетевые примочки для кластеризации.
это не весь список, но по поводу остальных вещей возможен разумный торг.

Здравствуйте, neFormal, Вы писали:

F>2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)

Загляните, пожалуйста, в исходники Erlang/OTP, в функцию erts_alc_fatal_error в частности. И объясните, как это ваше требование выполняется в Erlang-е, где невозможность аллокации памяти приводит к завершению работы всей VM.