. V>Одно плохо. V>Пока что бустовские future реализуют then/when_all/when_any через создание доп. потоков. А этого там вовсе НЕ требуется.
1. Это вообще говоря ортогонально, так как этот await работает с любым then, а не только boost::future::then.
2. Я в код не смотрел, но разве boost::future::then создаёт новый поток с блокирующим wait/get, вместо того чтобы просто прицепить продолжение к текущему future? Если так — то конечно это плохо, но я что-то сомневаюсь.
Здравствуйте, vdimas, Вы писали:
V>>>ИМХО, для statefull ничего в сам язык добавлять не надо, это запросто реализуется на уровне библиотек. EP>>Да, реализуются, точно также как и обычные потоки. Но в любом случае не помешают.
V>Без претензий на холивар, разве есть большая разница м/у вызовом некоторого зарезервированного ключевого слова V>и использованием некоей библиотечной ф-ии (абстрактно):
а зачем вообще стандартные библиотеки в язык добавляют? наверно чтобы гарантировать пользователю некий переносимый минимум сервиса. мне кажется, что и statefull предлагают добавить в таком виде, новый синтаксис предлагают только для stateless
PS: хотя я несколько запутался. мы ведь под stateful подразумеваем именно stackful? вообще лучше пользоваться терминологией stack*, тут интерпретация однозначна
Здравствуйте, neFormal, Вы писали:
BZ>>т.е. преимущество эрланга в том, что там прибито гвоздями то, что в C++ ревлизуется несколькими опенсорсными бибилотками на выбор? или это его недостаток?
F>эрланг — это фреймворк с dsl. F>странно реализацию фичи называть недостатком.
смотри, с одной стороны у нас есть экосистема эрланга с одной реализацией на уровне рантайма. с другой — экосистема С++ с несколькими реализациями на уровне OSS библиотек
Здравствуйте, vdimas, Вы писали:
V>Возможно. Но уже есть готовые реализации. Дело в их популяризации.
а вот тут как раз вылезают недостатки C++ — отсутствие GC и зелёных потоков, дороговизна immutables. в хаскеле/эрланге это популяризовать не надо — оно просто работает в любой многопоточной программе, даже не спрашивая твоего разрешения
M>>Эээээ. Вообще-то им бог велел его внутри реализовывать и они его реализовывают. Стандартная работа и СУБД и веб-сервера — это параллельная обработка большого количества параллельных процессов.
EL>Спорное утверждение, которое нужно чем-нибудь подкреплять.
И тут же рядом:
EL>HTTP сервер обычно запускает прости-господи-PHP скрипт, который генерирует страничку с html-ем. Скрипт этот лезет в базу много раз (в лучшем случае он не коннектится к базе каждый раз по новой а использует пулл соединений), он лезет в редис и даже в memcache. Допустим это добро выдает 100 запросов в секунду
Множество мелких процессов что на сервере, что в базе данных
M>>Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
BZ>т.е. преимущество эрланга в том, что там прибито гвоздями то, что в C++ ревлизуется несколькими опенсорсными бибилотками на выбор? или это его недостаток?
Что именно «прибито гвоздями»? В нем «прибита гвоздями» грамотная реализация того, что в библиотеках реализуется с разной степенью кривизны.
Здравствуйте, vdimas, Вы писали:
V>К тому же, алгоритм "work stealing" является наилучшим известным на сегодня для диспетчеризации зеленых потоков. Какой алгоритм диспетчеризации в Эрланге?
мне кажется, ты под зелёными потоками понимаешь не то, что afaik общепринято — зелёные потоки это симметричных короутины по сути своей реализации, но с автоматическим переключением, как у обычных потоков. реализуется в интерпретаторах дополнительным if в шаге интерпретации, а в хаскеле — дополнительным if при аллокации, благо что она происхолдит постоянно
соответственно, никакого work stealing при этом просто быть не может, как впрочем и в симметричных короутинах
Здравствуйте, Mamut, Вы писали:
M>Что именно «прибито гвоздями»? В нем «прибита гвоздями» грамотная реализация того, что в библиотеках реализуется с разной степенью кривизны.
т.е. эрланг был идеален с первой же версии и никогда не развивался?
Здравствуйте, BulatZiganshin, Вы писали:
F>>эрланг — это фреймворк с dsl. F>>странно реализацию фичи называть недостатком. BZ>смотри, с одной стороны у нас есть экосистема эрланга с одной реализацией на уровне рантайма. с другой — экосистема С++ с несколькими реализациями на уровне OSS библиотек
плюсы дают больше гибкости возможностей облажаться. это их недостаток.
но есть выбор. это их преимущество.
эрланг даёт один единственный вариант реализации. это его недостаток.
но облажаться почти невозможно. это его преимущество.
эрланг можно назвать фреймворком со своим dsl. и там всё крутится вокруг одной-двух основных фичей.
напрасно язык считают подходящим для любых задач. он же не существует отдельно.
поэтому странно называть реализацию VM недостатком языка.
Здравствуйте, ELazin, Вы писали:
BZ>>ты как раз успешно указал именно те примеры, которые больше всего нуждаются в зелёных потоках для обработки тысяч одновременных запросов
EL>Как определить что нуждается в зеленых потоках а что нет, есть ли какой-нибудь формальный метод, который позволяет определять, какую пользу потенциально могут принести зеленые потоки проекту?
очень простой — сравни число логических параллельных ветвей в твоей программе (в данном случае число одновременно обращающихся клиентов умножить на параллелизм внутри каждого обращения) с числом аппаратных потоков cpu. как только первое больше второго, становится эффективней использовать пул потоков, а удобней всего это делать с помощью green threads
EL>>>С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, BZ>>использвание асма, simd и gpgpu позволяет долстичь ещё лучших результатов, впорос в том как соотносятся усилия и выигрыш EL>ровно то же самое можно сказать про любую технологию, даже про зеленые потоки (:
как раз с ними всё ровно — они программируются так же легко, как обычные, но при этом работают эффективней
Здравствуйте, vdimas, Вы писали:
V>Т.е. просто куча потоков сидит себе на UDP-сокете, и по мере прихода новых пакетов просыпается очередной поток. В Linux при этом можно управлять шедуллингом потоков, в т.ч. достичь алгоритма, близкого по логике к популярному ныне work stealing.
Что-то я не понял. Ну, вот есть у меня, скажем, сервер на порту, скажем, TCP 80. Предположим, что http.sys в системе отсутствует — т.е. я работаю напрямую с сокетами.
У меня активно 20000 TCP-сессий параллельно. Сколько у нас будет потоков, что они будут делать, и каким образом?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, neFormal, Вы писали:
F>плюсы дают больше гибкости возможностей облажаться. это их недостаток. F>но есть выбор. это их преимущество.
странная у теюя логика. получается что любая библиотека ухудшает язык, поскольку даёт больше возможностей облажаться? преимущество C++ — и в выборе, и в том что эти библиотеки можно кустомизировать, и в том что они развиваются независимо от самого языка и компиляторов. недостатки связаны с самим языком C++ (отсутствие GC, неудобства с immutables, адресная арифметика, отсутствие зелёных потоков) и никак не проистекают из наличия выбора между библиотеками
Здравствуйте, vdimas, Вы писали:
BZ>>в tbb/ppl есть граф процессов и распространение исключений по нему. тут бы кого-нибудь грамотного кто сравнил эти два подхода...
V>TBB не использует "зеленые потоки", поэтому сравнивать можно только PPL.
мне показалось что возможности их примерно одинаковы (вероятно постоянно дерут друг у друга), в частности зелёные потоки реализуемы только на уровне компилятора, и ни в одном C++ их нет и никогда не было. а что ты называешь зелёными потоками в PPL?
EL>>Как определить что нуждается в зеленых потоках а что нет, есть ли какой-нибудь формальный метод, который позволяет определять, какую пользу потенциально могут принести зеленые потоки проекту?
BZ>очень простой — сравни число логических параллельных ветвей в твоей программе (в данном случае число одновременно обращающихся клиентов умножить на параллелизм внутри каждого обращения) с числом аппаратных потоков cpu. как только первое больше второго, становится эффективней использовать пул потоков, а удобней всего это делать с помощью green threads
Это единственный критерий? То что выполняется внутри зеленых потоков не имеет значения? А что если у меня клиентов всего вдвое больше хардварных потоков, что лучше использовать, потоки ОС или зеленые потоки?
BZ>как раз с ними всё ровно — они программируются так же легко, как обычные, но при этом работают эффективней
Они не программируются легко, в С++ ты должен сам написать всю логику их переключения, ты должен подумать об их приоритетах, ты должен подумать о возможном starvation этих потоков и об инверсии их приоритетов (если она возможна). Ты должен учитывать характер нагрузки, если ты пишешь сервер, который отдает данные, которые лежат в замапленном с помощью mmap файле, ты тоже будешь использовать зеленые потоки или потоки ОС?
EL>>HTTP сервер обычно запускает прости-господи-PHP скрипт, который генерирует страничку с html-ем. Скрипт этот лезет в базу много раз (в лучшем случае он не коннектится к базе каждый раз по новой а использует пулл соединений), он лезет в редис и даже в memcache. Допустим это добро выдает 100 запросов в секунду
M>Множество мелких процессов что на сервере, что в базе данных
Где ты увидел множество мелких процессов в моем примере и почему ты отвечаешь только на часть моего сообщения? Пример с постгресом слабо опровергнуть?
Здравствуйте, ELazin, Вы писали:
EL>Почему сразу глупость? сначала ты пожаловался на то, что рантайм у динамических языков говно
не говно, а что приложениям на динамических языках надо бы реализовать эрланг, чтобы получить больше пользы.
EL>потом на то что делать хорошо на с++ сложно и работодатели не хотят, предполагалось что мы об этом поговорим и я посочувствую или что?
я просто продемонстрировал тебе общеизвестный факт.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>странная у теюя логика. получается что любая библиотека ухудшает язык, поскольку даёт больше возможностей облажаться?
эм... ещё больше лажи в плюсах — это рандомный sigsegv на шаблонах с автогенерируемыми макросами?
не знаю, как ты сделал этот дикий вывод про библиотеку, но ты очень далёк от правды. я говорил только о языке. и добавление библиотеки не сделает жизнь вне её проще.
M>По внятности C++ (и кого бы то ни было) размалывает только Erlang. Пока другие тольк-только подбираются к концепциям, которые были в нем уже в начале 90-х, они уже думают о том, как правильно работать на десятках тысяч ядер, и оптимизируют работу системы для грамотной работы с переключением контекстов в CPU и cache miss.
Отвечу тут сразу на несколько веток о том, почему я считаю, что по параллельности и распределенности Эрланг на данный момент уделыввает всех, а остальные ему завидуют активно вбирают те же идеи и реализуют их или на уровне языка или в библиотеках.
Если ваш язык реализует только корутины — это не распеределенность/параллельность и не Эрланг.
Если ваш язык реализует только зеленые потоки — аналогично
Если у вас есть какая-то библиотечка для менеджмента потоков — аналогично
... вписать остальное ...
Начнем с того, что Эрланг изначально разрабатывался для поддержки высоконагруженных распределенных приложений, устойчивых к хардварным ошибкам. Основополагающая работа тут: http://www.erlang.org/download/armstrong_thesis_2003.pdf (почему-то заголовок был сменен на "in the presence of software errors", хотя изначально было "hardware errors").
Вот 10 требований к телекоммуникационным системам, для которых разрабатывался Erlang:
1. The system must be able to handle very large numbers of concurrent activities.
2. Actions must be performed at a certain point in time or within a certain time.
3. Systems may be distributed over several computers.
4. The system is used to control hardware.
5. The software systems are very large.
6. The system exhibits complex functionality such as, feature interaction.
7. The systems should be in continuous operation for many years.
8. Software maintenance (reconfiguration, etc) should be performed without stopping the system.
9. There are stringent quality, and reliability requirements.
10. Fault tolerance both to hardware failures, and software errors, must be provided.
Корутины поддерживают хоть половину этих пунктов? Что произойдет с первым же залетным OOM в корутине? Кто это обработает? Ваш наколенный менеджер потоков сможет перезапустить процесс/поток/корутину, если тот умер? А если умер он сам? А если на разных машинах? А если... И таких если — полно.
— Lightweight, massive concurrency
— Asynchronous communication
— Process isolation
— Error handling
— Continuous evolution of the system
— Soft real-time
Properties of the Erlang language
— Immutable data
— Pattern matching
— Functional language
So to run Erlang the BEAM needs to support all this.
AT LEAST
Даже если не обращать внимание на свойства собственно самого языка, то в вашем языке/рантайме должны быть первые шесть пунктов, чтобы грамотно, внятно, понятно, единообразно и предсказуемо реализовывать свои параллельные и распределенные вычисления и программы.
В большинстве современных языков и рантаймов все эти пункты находятся в сугубо зачаточном состоянии, и их пытаются решить натягиванием на примитивную основу костыли в виде библиотек, пытающихся эту примитивную основу расширить. Где-то это успешно, если сам рантайм хорош. Где-то это не более, чем библиотеки, в которых реализовать тот же supervision tree из Эрланга — это многомесячная ручная работа. При том, что в Эрланге supervision trees реализуются в виде туториала к языку.
По сути, Эрланг выступает в виде современного Лиспа То, что было когда-то в Лиспе постепенно переползло в мейнстрим. Сейчас то, что есть в Эрланге тоже медленно переползает в мейнстрим Плюс концепции, заложенные в Эрланг, доказали, что они работают. Причем настолько, что чуваки, разрабатывающие распределенные базы данных, открыто говорят, например, что они стараются пользоваться только тем, что доступно в стандартной поставке Erlang'а — в 99% случаев этого более, чем достаточно.
В конце 90-х в офисе Эрикссона почти в полном составе сидела команда, создавшая GHC. Они полтора года пытались придумать для Эрланга систему типов. Не смогли Некоторые свойства системы (типа hot code loading) этому очень мешают.
В начале 2000-х Эрикссон опрашивал своих крупнейших клиентов, хотят ли они типы в Эрланге. Почти дружный ответ был: нет, нам это не нужно.
Влияние динамической типизации на свойства языка и системы сильно преувеличено.
M>>Что именно «прибито гвоздями»? В нем «прибита гвоздями» грамотная реализация того, что в библиотеках реализуется с разной степенью кривизны.
BZ>т.е. эрланг был идеален с первой же версии и никогда не развивался?
