Здравствуйте, BulatZiganshin, Вы писали:
V>>К тому же, алгоритм "work stealing" является наилучшим известным на сегодня для диспетчеризации зеленых потоков. Какой алгоритм диспетчеризации в Эрланге?
BZ>мне кажется, ты под зелёными потоками понимаешь не то, что afaik общепринято — зелёные потоки это симметричных короутины по сути своей реализации, но с автоматическим переключением, как у обычных потоков.
Поясни "автоматическое переключение". Это грубое вытеснение? Чем это тогда отличается от обычных потоков?
BZ>реализуется в интерпретаторах дополнительным if в шаге интерпретации, а в хаскеле — дополнительным if при аллокации, благо что она происхолдит постоянно
Да плевать как оно реализуется. Можно сделать переключение по принципам кооперативной многозадачности (как в дотнете), т.е. в моменты обращения к "АПИ", которое может потенциально блочить текущий "логический" поток исполнения.
BZ>соответственно, никакого work stealing при этом просто быть не может, как впрочем и в симметричных короутинах
С моим замечанием — может и именно так и работает.
Думаю, ты неправильно понимаешь work stealing. 99% задач в реальных асинхронных сценариях того же дотнета ЖДУТ другие задачи (т.е. средний async-метод состоит из 2-х или более асинхронных вызовов внутри, собсно, затем async и нужен, чтобы породить автомат, у которого будет хотя бы два состояния, бо для одного состояния async не нужен, оно у нас и так есть). А это ожидание одной задачей сигнала от другой надо как-то обыгрывать. Вот тут стоит помедитировать — а как же это происходит?
Здравствуйте, BulatZiganshin, Вы писали:
V>>TBB не использует "зеленые потоки", поэтому сравнивать можно только PPL.
BZ>мне показалось что возможности их примерно одинаковы (вероятно постоянно дерут друг у друга), в частности зелёные потоки реализуемы только на уровне компилятора, и ни в одном C++ их нет и никогда не было. а что ты называешь зелёными потоками в PPL?
Здравствуйте, vdimas, Вы писали:
V>>>TBB не использует "зеленые потоки", поэтому сравнивать можно только PPL.
BZ>>мне показалось что возможности их примерно одинаковы (вероятно постоянно дерут друг у друга), в частности зелёные потоки реализуемы только на уровне компилятора, и ни в одном C++ их нет и никогда не было. а что ты называешь зелёными потоками в PPL?
V>А что ты называешь зелеными потоками?
Здравствуйте, so5team, Вы писали:
S>Процессы в Erlang-е -- это более продвинутая разновидность легковесных потоков. ОС про них ничего не знает, представление о них имеет только VM Erlang-а. Но, т.к. Erlang-овская VM сама выделяет кванты времени своим процессам, она имеет возможность вытеснять процесс после определенного количества редукций (т.е. выполненых инструкций VM). Кроме того, стандартная библиотека Erlang-а позволяет Erlang-овскому шедулеру снимать процесс при обращении к блокирующим операциям, передавать саму операцию на соответствующий рабочий поток, а затем поднимать задачу при получении ответа. Т.е. получается своя мини-ОС, которая работает хорошо только, если Erlang-овый код не использует обращения к NIF-ам (т.е. функциям, написанным на C).
Слово "только" здесь ошибочно:
Во-первых, vm отлично справляется при обращении к NIF-ам, которые быстро завершаются (в документации приведена безопасная оценка 1 миллисекунда, но на самом деле можно и дольше).
Во-вторых, есть экспериментальная поддержка "dirty nifs", не имеющих ограничений по времени выполнения.
В-третьих, всегда можно поменять ниф на драйвер и использовать driver_async — раз уж упомянули о выносе блокирующего IO в async thread, никто не мешает пользоваться ими для пользовательских функций.
В конце концов, есть и просто enif_thread_create/erl_drv_create_thread.
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а как это доказыват тезис о том что нужны *все* особенности эралнговской vm?
Ну это же вы предложили перейти к nginx.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, neFormal, Вы писали:
S>>>Спрашивается, почему по-уму нельзя сделать на C++, Scala или Haskell? F>>на c++ нельзя добиться отказоустойчивости при ошибке в коде.
EP>Можно, почему нет? EP>Вообще, что имеется в виду? Какой-нибудь seg-fault?
Я думаю что правильнее сказать что на Erlang/OTP гораздо проще написать отказоустойчивый код так как тебе сама платформа диктует правила которые помогают это сделать. В С++ добиться того же результата требуеться больше сил так как гибкость языка и множество решений одной задачи дает больше шансов выстрелить себе в ногу.
кста. сам pure Erlang не интересен. Я так понимаю что в дискусси все говорят о Erlang/OTP
Здравствуйте, kostik78, Вы писали:
S>>>>Спрашивается, почему по-уму нельзя сделать на C++, Scala или Haskell? F>>>на c++ нельзя добиться отказоустойчивости при ошибке в коде. EP>>Можно, почему нет? EP>>Вообще, что имеется в виду? Какой-нибудь seg-fault? K>Я думаю что правильнее сказать что на Erlang/OTP гораздо проще написать отказоустойчивый код так как тебе сама платформа диктует правила которые помогают это сделать. В С++ добиться того же результата требуеться больше сил так как гибкость языка и множество решений одной задачи дает больше шансов выстрелить себе в ногу.
Возможность выстрелить в ногупамять либо есть — либо её нет. Сколько там вариантов это сделать — не существенно.
Сам язык C++ говорит что в случае "выстрела" происходит UB, что в том числе разрешает среде действовать как ей требуется оставаясь в рамках языка — например подставить бронированный щит от таких пуль.
Вопрос вроде как был как раз про это.
Здравствуйте, BulatZiganshin, Вы писали:
V>>>>TBB не использует "зеленые потоки", поэтому сравнивать можно только PPL. BZ>>>мне показалось что возможности их примерно одинаковы (вероятно постоянно дерут друг у друга), в частности зелёные потоки реализуемы только на уровне компилятора, и ни в одном C++ их нет и никогда не было. а что ты называешь зелёными потоками в PPL?
V>>А что ты называешь зелеными потоками? BZ>ну или вот: http://en.wikipedia.org/wiki/Green_threads
Тогда я непонимаю твоих придирок. Я называю "зелеными потоками" любые потоки, переключение м/у которыми осуществляется НЕ ср-вами ОС и за счет этого (отсутствия ядерных вызовов) сами операции переключения потоков получаются более легковесными. В этом смысле Windows Fibers — всё еще достаточно тяжеловесны и отличаются от обычных потоков лишь тем, что переключение м/у ними происходит не в вытесняющей манере, а в кооперативной, вручную.
BZ>а теперь ответь на мой вопрос — что такое есть в PPL, чего нет в TBB?
Тут надо начинать с целей и задач TBB и PPL.
TBB был разработан тогда, когда не было С++11. Т.е., по-сути, TBB — это С++ АПИ для многопоточности в отсутствии таких ср-в в стандарте С++ на тот момент и уже наличии OpenMP и Cilk, которые оба чужды С++ и не получили должной популярности. Помимо примитивов для многопоточности, TBB даёт такую хрень как task, автоматический пул потоков + work stealing для автоматического диспатчинга этих task. Это усё, собсно.
MS Concurrency Runtime напротив, был выпущен MS ОДНОВРЕМЕННО с выходом их реализации тех пунктов будущего C++0x, которые относятся к многопоточности (std::thread, mutex, future, conditional_vatiable и т.д.) и решает задачи, которые НЕ решает С++0x. Появился этот рантайм в VS2010.
Конкретно PPL — лишь небольшая часть этого рантайма и довольно-таки близка к TBB в плане task. Но обычно весь MS Concurrency Runtime (ConcRT) часто обзывают кратко PPL (считай, жаргон такой), поэтому, сравнивать надо ВСЕ с-ва от MS со ВСЕМИ ср-вами от Intel для параллельности. И тут выясняется, что у Intel есть, собсно, только дублирование С++11 в плане стандартных примитивов (которая уже 3 года как obsolete) + библиотека порождения и выполнения task. Абсолютно никаких ср-в для контроля за происходящим с этими task НЕТ, это просто альтернатива OpenMP и Cilk для целей дать решение в духе "true C++". В то время как в MS Concurrency Runtime есть все ср-ва для написания библиотек, аналогичных PPL/TBB, помимо этого есть ср-ва для создания и шедуллинга зеленых потоков, и даже для разработки собственных шедуллеров (!!!).
В этом смысле ConcRT даёт неплохую базу для любых разработок по всем этим направлениям, в то время как TBB смогло родить только flow graph, т.е. некую очередную прибитую к самой себе гвоздями "архитектуру" поверх task для не самого широкого круга сценариев: http://habrahabr.ru/company/intel/blog/157735/
Хотя — это заявка на "умный" шедуллинг, который, при возможности описать его в декларативном виде (например, для неизменяемых алгоритмов обработки сигналов), может дать профит в виде экономии на "холостых" срабатываниях (те самые task reordering) относительно тупого work stealing.
Здравствуйте, BulatZiganshin, Вы писали:
V>>Возможно. Но уже есть готовые реализации. Дело в их популяризации. BZ>а вот тут как раз вылезают недостатки C++ — отсутствие GC и зелёных потоков, дороговизна immutables. в хаскеле/эрланге это популяризовать не надо — оно просто работает в любой многопоточной программе, даже не спрашивая твоего разрешения
Можно было просто ограничиться immutables, остальное лишь следствие. ))
Здравствуйте, Ikemefula, Вы писали:
I>Догадываюсь, откуда твоя боль. "однопоточная VM" — это ты скорее всего про Node.js. Ты наверное попутал Node.js с абстрактным джаваскриптом. I>Node.js как VM никогда, ни разу не был однопоточной VM. И это несмотря на то, что js в ноде однопоточный. Парадокс ? Как то так
Тем не менее, Node.js сугубо однопоточный, ы-ы-ы. ))
Каждый "другой" поток — это отдельная несообщающаяся с другими потоками вселенная.
JS-"потоки" — это группа корутин (с т.з. VM), тупо сидящих на одном и том же физическом потоке без возможности переползти на другой физический поток хотя бы с целью load balancing.
Да, собсно, load balancing в Node.js, это вовсе не load balancing в исходном смысле динамического распределения ресурсов в зависимости от нагрузки уже имеющихся задач, это тупой подход, который считает, что каждая отдельная "задача" достаточна дешева и не подлежит балансированию ресурсов во время своего исполнения, а балансируются процедуры запуска самих задачи, собсно, ы-ы-ы много раз. ))
I>"вершиной мысли в большинстве языков" — смешно. Джава, дотнет, питон уже давно отказались от этой вершины мысли. С, С++ — вобщем, в процессе.
Да лан, Node.js — это дестад для детсада. "Быстро слепить и впарить".
Ну и че-то тормозит асинхронный IO в дотнете безбожно, дорогой очень в затратах на самого себя.
Пока что "сыровато" это всё для использования где-либо, кроме веба, с его нормами задержек в десятки и сотни MS. ))
Эрланг — это не только возможность создавать миллион потоков.
BZ>а я тебе предлагаю перечитать ответ, который я тебе дал на то сообщение. в эрланге есть много чего, что мне лично не нужно.
Раз не нужно тебе, значит никому не нужно? Ты название топика читал вообще?
BZ>поэтому я предлагаю сосредоточиться именно на миллионе потоков, включая сюда распространение исключений (вещь жизненно необходимая), но не возможность продолжать работать при поломках оборудования, realtime и прочую коммутаторную специфику
Ничего специфичного для коммутаторов тут же нет. Сейчас каждый первый проект работает где-нибудь в облаках на нцати машинах и ядрах.
S>>>Наглядная демонстрация того, что даже 64-бит Windows Home на далеко не серверном железе позволяет запускать 100K нитей. Что уже про Linux-ы/Unix-ы говорить.
M>>Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
S>Ссылка на исходник была дана выше. Посмотрите в код, поищите ручную работу с нитями/mutex-ами и еще чем-либо низкоуровневым.
Блин. Почему в этом топике никто не способен:
— прочитать про Эрланг больше, чем «аааа миллион процессов, корутины умеют так же»
— Продолжить мылсь дальше, чем «аааа он сказал мьютексы у меня нет мьютексов»
В общем, почему то в этом топике все опираются строго на одну строчку строчку того, что написано.
Так и тут. Первое. Даже в процитированном я ВНЕЗАПНО говорил не только о мьютексах. Второе. Я вообще-то написал, что умением создать миллион корутин Эрланг не ограничивается.
Нет, блин. «аааааа создали миллион рутин там нет мьютексов нафиг нужен эрланг».
Здравствуйте, vdimas, Вы писали:
I>>Догадываюсь, откуда твоя боль. "однопоточная VM" — это ты скорее всего про Node.js. Ты наверное попутал Node.js с абстрактным джаваскриптом. I>>Node.js как VM никогда, ни разу не был однопоточной VM. И это несмотря на то, что js в ноде однопоточный. Парадокс ? Как то так
V>Тем не менее, Node.js сугубо однопоточный, ы-ы-ы. )) V>Каждый "другой" поток — это отдельная несообщающаяся с другими потоками вселенная.
В ноде вообще нет потоков и при этом VM многопоточная. Так понятно ?
I>>"вершиной мысли в большинстве языков" — смешно. Джава, дотнет, питон уже давно отказались от этой вершины мысли. С, С++ — вобщем, в процессе.
V>Да лан, Node.js — это дестад для детсада. "Быстро слепить и впарить".
node.js это не слепить, это очень узкая ниша, где не требуется никаких числодробилок, а требуется в основном ввод-вывод, что естественно ведет к асинхронщине.
V>Ну и че-то тормозит асинхронный IO в дотнете безбожно, дорогой очень в затратах на самого себя.
В дотнете асинхронный IO тормозит, дорогой слишком, а детский сад почему то node.js
Ну и как всегда, никаких жостких данных у тебя нет, одни только ы-ы-ы.
И кстати, пока не забыл, ты так и показал образец асинхронщины "любой студент за пару часов", уже два года несёшь. Зато мнения по этой асинхронщине, хоть отбавляй, и что характерно — всегда без жостких данных.
Здравствуйте, BulatZiganshin, Вы писали:
I>>Не сильно понятно что ты хотел сказать про нод. Вроде как растет популярность
BZ>что там модель с колбеками и она банальна неудобна по сравнению с зелёными потоками. а популярность растёт постому что альтернатив, т.е. реваоалихация зелёных потоков среди популярных скриптовых языков (js/python) пока что нету
На зеленых потоках конечно было бы гораздо посильнее, но при этом шедулинг зеленых потоков накладывает конские ограничения. node это ручная диспетчеризация асинхрронного кода. Это конечно треш и угар местами, зато область применения поширше того же эрланга.
node, кроме того, влегкую позволяет юзать на клиенте и сервере ровно один и тот же язык, код и даже фремворки. Более того, JS становится вообще единтсвенным ЯП на проекте.
Здравствуйте, Mamut, Вы писали:
M>Блин. Почему в этом топике никто не способен: M>- прочитать про Эрланг больше, чем «аааа миллион процессов, корутины умеют так же» M>- Продолжить мылсь дальше, чем «аааа он сказал мьютексы у меня нет мьютексов»
Может потому, что ТС сам задает такой уровень обсуждения:
M>>>Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
Дело в том, что когда Erlang-еры начинают делать предположения о том, как в других языках работают с многопоточностью, то приводят какие-то крайние варианты: рукопашная работа с мутексами/семафорами/кондишенами, ручное управление потоками и т.д. Между тем, мир за пределами Erlang-а настолько велик, что в нем можно найти все, что угодно. Можно и жуткий код, в котором операции lock/unlock прописывают вручную, да еще и наплевав на любые exception guarantees. А можно и высокоуровневый, к котором выполняется многопоточная обработка огромных объемом данных, но прикладной программист не видит ни одного объекта блокировки и ни одной нити.
Здравствуйте, hi_octane, Вы писали:
I>>Опять "лучший" и уже наверное третий год обещаний "скоро мы сделаем тааакоое !" _>Чисто развеять сомнения — сорцы нитры открыты, можешь дать ссылку на хотя-бы аналогичный?
Ты сказал, тебе аргументировать. Т.е. предполагается, что пруф у тебя должен быть.
Вот как выложишь пруф, я поделюсь своими аргументами, за сказаное мной.
M>>Блин. Почему в этом топике никто не способен: M>>- прочитать про Эрланг больше, чем «аааа миллион процессов, корутины умеют так же» M>>- Продолжить мылсь дальше, чем «аааа он сказал мьютексы у меня нет мьютексов»
S>Может потому, что ТС сам задает такой уровень обсуждения:
M>>>>Хорошо. Запустил ты их. Дальше что? mutex.lock? WaitForThread? Ручной менеджмент потоков?
Внезапно я виноват в том, что тут народ читать не умеет
S>Дело в том, что когда Erlang-еры начинают делать предположения о том, как в других языках работают с многопоточностью, то приводят какие-то крайние варианты: рукопашная работа с мутексами/семафорами/кондишенами, ручное управление потоками и т.д. Между тем, мир за пределами Erlang-а настолько велик, что в нем можно найти все, что угодно.
Ну так показывайте «все, что угодно». Пока что упирается в «ура мы создали миллион корутин»
Здравствуйте, Sharov, Вы писали:
I>>Догадываюсь, откуда твоя боль. "однопоточная VM" — это ты скорее всего про Node.js. Ты наверное попутал Node.js с абстрактным джаваскриптом. I>>Node.js как VM никогда, ни разу не был однопоточной VM. И это несмотря на то, что js в ноде однопоточный. Парадокс ? Как то так
S>А на что еще потоки, кроме js? Ну IO допустим. Два потока. А еще?
Чем Erlang будет лучше Java или Scala, например, в таких задачах? Покажите на Erlang-е что-нибудь отличное от "ура мы создали миллион легковесных процессов", "у нас все надежно, если ничего не ломается и все настроено правильно, а если что-то не настроено или таки сломалось, то 100% гарантий надежности и не бывает"...
