M>>Ты свой вопрос считаешь техническим аргументам? Ну-ну. И не тебе говорить про сливы. WH>А что производительность к техническим аргументам уже не относится?
Относится, когда не вопрошают об абстрактной производительности в абстрактных задачах.
WH>>А как там, у ерланга с производительностью? WH>>Он уже научился не сливать С++у в десятки раз?
S>Неужто у эрланга все так плохо? Чего-то не верится...
Тут сейчас тебе Wolfhound начнет нести свою любимую чушь про языки, ты его не слушай. У нас все его ходы записаны, они уже много лет не меняются.
Ты не поверишь, на плюсам в десятки раз сливают все подряд. Ну всякие эти там Питоны, Руби и прочие Немерле. И ничего, народ пользуется. Грамотно написаный код давно уже не сливает в десятки раз. Ни Руби, ни Питон, ни Эрланг, ни, прости господи, Немерле. Понятно, что никто числодробилки на Эрланге писать не будет. Как не будут писать на Руби, Питоне и прочем.
А если говорить именно про Эрланг, то надо еще найти програмистов, которые смогут качественно реализовать эрланговское дерево супервизоров. И нафига нужна абстрактная скорость в абстрактных задачах, если ты не можешь внятно управлять этой скоростью?
Про «фундаментально ущербную модель многопоточности» Wolfhound пусть рассказывает сказки и дальше, ведь он у нас известный теоретик и сказочник. Любую даже самую грамотно спроектированную систему всегда можно нагнуть. Заметь, что он до сих пор носится со ссылкой на сообщение 2005-го года (!), в которой говорится о том, что систему удалось нагнуть однажды (!).
У тебя еще есть доверие этому человеку? У меня уже много лет нет. А вот у нормальных людей есть доверие как к Эрлангу, так и к его модели, которую стремительно вбирают в себя все, кому не лень.
ЗЫ. Надо будет пацанам из Ватсаппа рассказать об ущербной модели многопоточности Эрланга, да...
Здравствуйте, Mamut, Вы писали:
M>Тут сейчас тебе Wolfhound начнет нести свою любимую чушь про языки, ты его не слушай. У нас все его ходы записаны, они уже много лет не меняются.
Я просто уже много лет понимаю, о чём говорю. А вот до тебя всё не доходит.
M>Ты не поверишь, на плюсам в десятки раз сливают все подряд. Ну всякие эти там Питоны, Руби и прочие Немерле.
Про немерле лож.
M>Понятно, что никто числодробилки на Эрланге писать не будет. Как не будут писать на Руби, Питоне и прочем.
Числодробилки это любые вычисления. Если у тебя задача чисто про IO, то на фоне тормозов IO тормоза остального не видно в микроскоп. Но если тебе вдруг нужно будет хоть что-то посчитать, то тебе придётся переходить на другой язык.
M>Про «фундаментально ущербную модель многопоточности» Wolfhound пусть рассказывает сказки и дальше, ведь он у нас известный теоретик и сказочник. Любую даже самую грамотно спроектированную систему всегда можно нагнуть. Заметь, что он до сих пор носится со ссылкой на сообщение 2005-го года (!), в которой говорится о том, что систему удалось нагнуть однажды (!).
А что с тех пор что-то изменилось?
Вообще это вторая ссылка в гугле по запросу selective receive.
M>У тебя еще есть доверие этому человеку? У меня уже много лет нет. А вот у нормальных людей есть доверие как к Эрлангу, так и к его модели, которую стремительно вбирают в себя все, кому не лень.
У меня есть технические аргументы, на которые ты можешь ответить только истерикой, переходом на личности и апелляции к "авторитетам".
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, ELazin, Вы писали:
EL>Очень небольшому подмножеству приложений нужно реализовывать Эрланг, большинству не нужно ничего такого делать даже близко. СУБД должна реализовывать Эрланг внутри себя, или может HTTP сервер?
Конечно. Именно это они и делают. Вы же не думаете, что select * from sysprocesses возвращает что-то, хоть отдалённо имеющее отношение к многозадачным примитивам Винды?
iis внутри себя чуть менее, чем весь, построен на IOCP. А тем нещясным, которые вынуждены писать к нему приложения, остаётся либо бессильно смотреть на "0" в качестве response при выполнении длинных операций во время запроса, либо срочно читать про то, как IAsyncHttpHandler обходит это ограничение. В некотором смысле это и есть изобретение эрланга со всеми его недостатками, но без достоинств.
EL>С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, mmap, контролировать memory layout объектов и структур данных и тд. Это требует большего количества работы, но зато позволяет достичь лучших результатов.
Ну, в те далёкие-далёкие времена, когда я писал С++ код в промышленных масштабах, с памятью в С++ всё обстояло плохо, а с вводом-выводом — совсем плохо.
Потому, что эффективный IO — это IOCP, а никаких средств по его поддержке в языке не было. Ну, то есть он же turing-complete, поэтому теоретически можно напедалить весь нужный код, и он даже может случайно не сломаться из-за просмотренного race condition в моей state machine. Но на практике реализовывать более-менее внятный IOCP на плюсах решались очень немногие.
В частности, например, команды iis и mssql. Пример из MSDN не считается — в жизни задачи, как в нём, не встречаются никогда. В жизни встречаются задачи типа predictive page scan с учётом пары сотен конкурирующих операций, или несколько тысяч HTTP-сокетов, которые надо обслуживать, причём данные в них отправляются не из const char[] text = "hello, world", а из пачки io-bound источников навроде внешних веб-сервисов, файлов, и СУБД.
Про память сейчас вроде бы плюсы улучшили, теперь управление ею не настолько чудовищно неэффективно, как это было во времена Г., прости господи, Шилдта.
А что у нас с IOCP? Есть ли в бусте что-то, позволяющее мне нарезать линейный (по спецификации) алгоритм на фрагменты, которые можно исполнять по мере поступления IOCP, без мучительной отладки и замусоривания кода бойлерплейтом?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>А что у нас с IOCP? Есть ли в бусте что-то, позволяющее мне нарезать линейный (по спецификации) алгоритм на фрагменты, которые можно исполнять по мере поступления IOCP, без мучительной отладки и замусоривания кода бойлерплейтом?
Например:
* Stackful Coroutines — Boost.Coroutine.
Его можно использовать напрямую, либо если нужен IOCP — то в Boost.Asio уже есть готовый обвяз для интеграции с Boost.Coroutine.
На базе Boost.Coroutine я сделал эмуляцию await: 1
EL>Очень небольшому подмножеству приложений нужно реализовывать Эрланг, большинству не нужно ничего такого делать даже близко. СУБД должна реализовывать Эрланг внутри себя, или может HTTP сервер?
Эээээ. Вообще-то им бог велел его внутри реализовывать и они его реализовывают. Стандартная работа и СУБД и веб-сервера — это параллельная обработка большого количества параллельных процессов.
EL>С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, mmap, контролировать memory layout объектов и структур данных и тд. Это требует большего количества работы, но зато позволяет достичь лучших результатов.
Лучших сферовакуумных результатов. На практике для подавляющего большинства задач вся эта работа с памятью по приоритетам стоит где-то на пятнадцатом месте.
M>>Тут сейчас тебе Wolfhound начнет нести свою любимую чушь про языки, ты его не слушай. У нас все его ходы записаны, они уже много лет не меняются. WH>Я просто уже много лет понимаю, о чём говорю. А вот до тебя всё не доходит.
Нет. Ты уже много лет стоишь в позиции «вы все тупые, я один дАртаньян» и в качестве примеров приводишь исключительно Немерле.
M>>Ты не поверишь, на плюсам в десятки раз сливают все подряд. Ну всякие эти там Питоны, Руби и прочие Немерле. WH>Про немерле лож.
Это никому неизвестно, потому что пациент в природе отсутсвует.
M>>Понятно, что никто числодробилки на Эрланге писать не будет. Как не будут писать на Руби, Питоне и прочем. WH>Числодробилки это любые вычисления. Если у тебя задача чисто про IO, то на фоне тормозов IO тормоза остального не видно в микроскоп. Но если тебе вдруг нужно будет хоть что-то посчитать, то тебе придётся переходить на другой язык.
Заявляет с апломбом человек, известный тем, что он неспособен подтвердить свои громкие заявления ни единой ссылкой.
M>>Про «фундаментально ущербную модель многопоточности» Wolfhound пусть рассказывает сказки и дальше, ведь он у нас известный теоретик и сказочник. Любую даже самую грамотно спроектированную систему всегда можно нагнуть. Заметь, что он до сих пор носится со ссылкой на сообщение 2005-го года (!), в которой говорится о том, что систему удалось нагнуть однажды (!). WH>А что с тех пор что-то изменилось? WH>Вообще это вторая ссылка в гугле по запросу selective receive.
У меня — четвертая. И? За 7 прошедших лет так никто больше и не появился, у кого один раз удалось добиться такого поведения. А тюнинг VM, который с тех пор провели искать лень — тебе же все равно. У тебя есть вера в непогрешимость своей позиции.
M>>У тебя еще есть доверие этому человеку? У меня уже много лет нет. А вот у нормальных людей есть доверие как к Эрлангу, так и к его модели, которую стремительно вбирают в себя все, кому не лень. WH>У меня есть технические аргументы, на которые ты можешь ответить только истерикой, переходом на личности и апелляции к "авторитетам".
У тебя нет технических аргументов. Все, что у тебя есть — это голословные утверждения и позиция «вы тупые». И это повторяется из года в год.
, производительностью, фундаментально неущербной многопоточностью? Ой да, я забыл. Кроме пафоса и апломба нет ничего. Уже лет пять-семь как.
Ты уж извини, но «аргументы» от тебя слушать — себя не уважать. Лучше обратить внимание не на твой мир пони, а на реальный, где именно модель Erlang'а становится все более распространенной.
Здравствуйте, Sharov, Вы писали:
S>Не очень хорошо, не спорю, но предложено немалое кол-во решений проблемы, плюс, как уже было замечено, это было давно и много могло поменяться.
Это можно починить, только выпилив selective receive ибо он принципиально O(размер очереди) и не лечится.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Это никому неизвестно,
Мне известно. Ибо пишу на нём код требовательный к производительности.
M>потому что пациент в природе отсутсвует.
Присутствует.
WH>>Числодробилки это любые вычисления. Если у тебя задача чисто про IO, то на фоне тормозов IO тормоза остального не видно в микроскоп. Но если тебе вдруг нужно будет хоть что-то посчитать, то тебе придётся переходить на другой язык. M>Заявляет с апломбом человек, известный тем, что он неспособен подтвердить свои громкие заявления ни единой ссылкой.
Давай, спорь с фактами дальше.
M>У меня — четвертая. И?
Люди утыкаются в неё, плачут и идут пилить костыли.
M>За 7 прошедших лет так никто больше и не появился, у кого один раз удалось добиться такого поведения. А тюнинг VM, который с тех пор провели искать лень — тебе же все равно. У тебя есть вера в непогрешимость своей позиции.
Если алгоритм O(N) то он и будет O(N).
M>У тебя нет технических аргументов. Все, что у тебя есть — это голословные утверждения и позиция «вы тупые». И это повторяется из года в год.
Ну то есть свойства алгоритмов не технические аргументы.
Я тебя правильно понимаю?
M>Да, кстати, как там с популярностью N2
, производительностью, фундаментально неущербной многопоточностью? Ой да, я забыл. Кроме пафоса и апломба нет ничего. Уже лет пять-семь как.
Лучший в мире генератор парсеров уже есть.
Сейчас делаем язык типизации.
M>Ты уж извини, но «аргументы» от тебя слушать — себя не уважать. Лучше обратить внимание не на твой мир пони, а на реальный, где именно модель Erlang'а становится все более распространенной.
У тебя вообще кроме истерики никаких аргументов нет.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Я не ухожу от вопроса. Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком.
языком или рантаймом? вот как ни крути, я не вижу в языке каких-то киллер-фич необходимывх именно для зелёных тредов. такие же треды есть в хаскеле, руби, луа и везде — исключительно средствами рантайма
M>Когда все, что язык предоставляет — это появившиеся в 2011-м стандарте thread'ы
это вообще библиотека, всё что появилось в C++11 — это **стандартный** api для потоков, а так ровно то же самое ты получал давно с бустом. почему многопоточность в чистом C++ неудобна понятно — бибилотеки слабюеньке. если взять скажем Intel TBB, то там будет уже получше — можно создавать граф управления и распространять исключения. после этого остаются проблемы, решаемые только на уровне рантайма — зелёные потоки, сборка мусора. и решаемые только на уровне яхыка — ориентация на immutable структуры данных, что сильно упрощает борьбу с ошибками
Здравствуйте, Mamut, Вы писали:
M>Всего этого в С++ банально нет, это надо лопатить вручную или пользоваться библиотеками, которые в итоге реализуют все тот же Эрланг
т.е. преимущество эрланга в том, что там прибито гвоздями то, что в C++ ревлизуется несколькими опенсорсными бибилотками на выбор? или это его недостаток?
Здравствуйте, Mamut, Вы писали:
M>На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями.
огласите весь список, плиз
M>Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь.
а ты видел презентацию msvc async (или это был их проект расширения C++)? там речь шла о миллиардах сопрограмм
M>Да, есть библиотеки, реализующие корутины и зеленые потоки. Кто будет управлять этими потоками? Синхронизировать их? Отслеживать их аварийное завершение? Гарантировать их выполнение?
а чем собственно эти библитоеки занимаются? тот же intel tbb? вот только насчёт зелных потоков меня терзают смутные сомнения — от корутин они отличаются как раз тем что переключение иежду потоками идёт автоматом, и это как я понимаю на С++ не реализуется никем и не планируется ни в каком виде
кстати ты с win rt api знаком? он весь асинхронный, что в сочетании с async extension даёт удобное программирование. или скаджем node.js — те же асинхронные интерфейсы, добавляем к ним синтаксический сахар и получается вполне аналог эрланга/хаскеля с их зелёными потоками
Здравствуйте, ELazin, Вы писали:
EL>Очень небольшому подмножеству приложений нужно реализовывать Эрланг, большинству не нужно ничего такого делать даже близко. СУБД должна реализовывать Эрланг внутри себя, или может HTTP сервер?
было бы неплохо, если б скриптовые языки, на которых делают веб-бэкенды, умели общую среду, чтобы не надо было синхронизировать их через какие-то промежуточные технологии.
а то, что сейчас делают — это стыд какой-то.
EL>С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, mmap, контролировать memory layout объектов и структур данных и тд. Это требует большего количества работы, но зато позволяет достичь лучших результатов.
и довольно небезопасно.
при должной медитации можно сделать всё качественно, но работодателей с таким подходом немного. поэтому имеем, что имеем.
Здравствуйте, ELazin, Вы писали:
EL>Очень небольшому подмножеству приложений нужно реализовывать Эрланг, большинству не нужно ничего такого делать даже близко. СУБД должна реализовывать Эрланг внутри себя, или может HTTP сервер?
ты как раз успешно указал именно те примеры, которые больше всего нуждаются в зелёных потоках для обработки тысяч одновременных запросов
EL>С памятью и вводом/выводом я могу эффективнее работать в С или С++, так как я могу там использовать векторный ввод/вывод, mmap, контролировать memory layout объектов и структур данных и тд. Это требует большего количества работы, но зато позволяет достичь лучших результатов.
использвание асма, simd и gpgpu позволяет долстичь ещё лучших результатов, впорос в том как соотносятся усилия и выигрыш
Здравствуйте, ELazin, Вы писали:
M>>На практике этих библиотек нет. Те, что есть, реализуют лишь часть из доступного функционала, часто с огромными ограничениями. Ну нет в С++ возможности создать 100500 процессов без того, чтобы не убить ОСь. Да, есть библиотеки, реализующие корутины и зеленые потоки. Кто будет управлять этими потоками? Синхронизировать их? Отслеживать их аварийное завершение? Гарантировать их выполнение?
EL>Во первых, уже можно создать 100500 обычных потоков ОС и не убить ось, сожрется куча памяти, но шедулер будет работать нормально. Во вторых, есть кооперативная многозадачность, я могу создать 100500 лековесных потоков с помощью boost.coroutine например, и переключаться между ними вручную.
Мамут правильные вопросы задал. если ты начнёшь вручную копать с использованием boost.coroutine, то будешь иметь все прелести низкоуровневого программирования. вопрос стоит в том, как получить высокоуровневый подход, аналогичный эрланговскому, и насколько это вообще возможно скажем в c++/js/haskell
EL>В третьих, многим приложениям оно надо?
заметь, что польтзователи давно уже выражают недоумение почеу эти тупые программисты неспособны загрузить работой их тысячеядерное чудо
Здравствуйте, Mamut, Вы писали:
M>А если говорить именно про Эрланг, то надо еще найти програмистов, которые смогут качественно реализовать эрланговское дерево супервизоров.
в tbb/ppl есть граф процессов и распространение исключений по нему. тут бы кого-нибудь грамотного кто сравнил эти два подхода...
M>На удивление многим. На это сложно перестроиться, потому что, как я тут выше говорил, для большинства программистов и Node.js — web scale, и обсчитать длинную задачу так, чтобы GUI не умирал — непосильная задача
Раскроешь мысль? Почему многим, что имеется ввиду, everything is a process?
M>Эээээ. Вообще-то им бог велел его внутри реализовывать и они его реализовывают. Стандартная работа и СУБД и веб-сервера — это параллельная обработка большого количества параллельных процессов.
Спорное утверждение, которое нужно чем-нибудь подкреплять. Вот например цитата из PostgreSQL FAQ:
The PostgreSQL server is process-based (not threaded), and uses one operating system process per database session. A single database session (connection) cannot utilize more than one CPU. Of course, multiple sessions are automatically spread across all available CPUs by your operating system. Client applications can easily use threads and create multiple database connections from each thread.
То, насколько хорошо подходит тот или иной подход к построению сервера, определяется тем, что этот сервер делает, как ни странно. Если запросы достаточно тяжелые и много всего делают, весь этот ваш erlang становится не очень актуален. Когда у нас есть долгоживущие соединения, запросы достаточно легкие, то все ок, а если в запросе нужно писать в B+ дерево, например, то экономика становится совсем другой.
Если например любой запрос сервером выполняется за 10мс и за запросом всегда следует отсоединение, то в любой момент времени сервер будет иметь не более 100 параллельных соединений на ядро (плюс-минус). По этой причине тут не нужен ни erlang ни epool ни даже IOCP, тут будет работать поток на соединение, как в постгресе. То же самое касается HTTP серверов, идеальный HTTP сервер в вакууме можно сделать на erlang-е, чтобы он в базу ходил асинхронно и все такое, в реальности же, HTTP сервер обычно запускает прости-господи-PHP скрипт, который генерирует страничку с html-ем. Скрипт этот лезет в базу много раз (в лучшем случае он не коннектится к базе каждый раз по новой а использует пулл соединений), он лезет в редис и даже в memcache. Допустим это добро выдает 100 запросов в секунду, потом приходит умный PHP программист, заменяет == на === и двойные кавычки на одинарные и все начинает работать супер быстро, выдавая 1000 запросов в секунду. Теперь вопрос — если бы разработчики апача писали бы "свой erlang" и построили свой сервер вокруг пулла потоков и обработки сообщений, смог бы apache выполнять эти говноскрипты быстрее?
M>Лучших сферовакуумных результатов. На практике для подавляющего большинства задач вся эта работа с памятью по приоритетам стоит где-то на пятнадцатом месте.
Это зависит от задач. Если это стоит на 15-м месте то С++ наверное не стоит использовать, да.
