M>>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос. M>>Только не надо мне рассказывать сказки про то, что тебе не надо ничем управлять и ни с чем общаться.
S>Что, культурно общаться уже не получается? Жаль.
Мне сложно общаться с людьми, которые не читают написанного. Потому что постоянно приходится отвечать цитатми из самого первого сообщения.
M>> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? S>Я, к сожалению, не могу говорить за "подавляющее большинство языков", поскольку не являюсь в них экспертом. Но, конкретно эти два вопроса решается либо асинхронными событиями, либо синхронизацией (гм, забавно если задуматься). Рискну предположить, что библиотеки, реализующие подобную функциональность есть для большинства живых языков.
S>И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки?
И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка.
...
Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
— Библиотека X может создать 100500 потоков, но общение строго через shared state с мьютексами и прочим.
— Библиотека Y может создать 100500 потоков, общение агентами/сообщениями, но нет никакой возможности управлять этими потоками, кроме как врукопашную реализовывать весь мониторинг и прочее
— Библиотека Z, может создать 100500 потоков, общение агентами/сообщениями, есть управление потоками, но нет изоляции потоков, поэтому любое залетное деление на 0 просто убивает всю программу
и так далее и тому подобное.
Но так — да. «Тривиальные операции» реализуются. Вот рядом люди уже 20 лет пилят модель акторов для C++ и ничего, называют это «нет ничего сложного»
Здравствуйте, alex_public, Вы писали:
_>Эта самая разница в количестве кардинально меняет ситуацию.
оно только может поменять часть требований.
при чём ключевое слово "может", а не "поменять".
_>К примеру если взять те же самые лёгкие потоки (все их разновидности) — откуда по твоему берётся их преимущество перед системными? Очевидно из-за отсутствия огромных накладных расходов. _>А скажем для случая числодробилок (где число потоков равно числу ядер на машине) подобных накладных расходов нет вообще
и расходов тоже нету, и накладок тоже нету...
в смысле, слова не пропускай. а то ни там, ни там нет никаких затрат.
_>Так что казалось бы всего лишь количественная разница вносит вполне себе качественные различия.
ты смешиваешь скорость рантайма с количеством потоков.
это ошибочно.
_>И соответственно в разных случаях надо применять разные инструменты. С тем же C++ это кстати совсем не проблема, т.к. там это всё реализовано в виде библиотек — просто выбираем нужную.
ха-ха
_>А вот в случае попытки применения Эрланга где-то за пределами его узкой ниши мы получим множество неудобств.
ха-ха
...coding for chaos...
Re: Эрланг и все-все-все (на самом деле, не совсем)
Обожаю сравнения языков с нулем строчек реального кода на паре этих языков и роликом с youtube. По теме — не увидел ничего, что не решалось бы тасками с Rx в шарпе, остальными языками не пользуюсь уже давно. Общение между компами интересно, но без примеров это выглядит всемогутором который хрен знает как внутри работает, давным давно есть очереди сообщений на любой вкус и цвет. Не падать от неучтенных ошибок — да не горит в общем то, чуть больше руками накодить catch->log. Immutable везде — нафиг нафиг все эти теоретизации. Какие задачи невозможно (сложнее на порядок) решить на шарпе, чем на эрланге? Примеры, нужно больше примеров=)
Здравствуйте, Mamut, Вы писали:
M>Мне сложно общаться с людьми, которые не читают написанного. Потому что постоянно приходится отвечать цитатми из самого первого сообщения.
Позвольте, но как раз по вашему "первому сообщению" домнога вопросов, если вместо ответов на них вы будете продолжать самоцитироваться то вопросы не исчезнут.
M>>> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
"Сложно общаться с людьми, которые не читают написанного". Зачем вы требовали ответа, если в итоге проигнорировали его?
M>И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка.
Можно примеры, как рантайм ограничевает (до невозможности реализации) асинхронную отправку сообщений и синхронизацию? Я бы понял, если фанаты хаскеля сейчас бы жёстко троллили всех STM'ом (вроде как только в нём он реализуется без огромных костылей).
M>Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
А я назову это синтаксическим сахаром, и тоже буду прав.
M>Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную.
Это и написанное ниже требует доказательств. И да, для "подавляющего большинства"?
M>и так далее и тому подобное.
Угу, именно что.
S>>И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки? M>Но так — да. «Тривиальные операции» реализуются. Вот рядом люди уже 20 лет пилят модель акторов для C++ и ничего, называют это «нет ничего сложного»
Да, как же распределённые/многопоточные приложения писали без "модели акторов для C++"... тёмные люди видимо были, не знали что совершают невозможное.
S>>>И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки? M>>Но так — да. «Тривиальные операции» реализуются. Вот рядом люди уже 20 лет пилят модель акторов для C++ и ничего, называют это «нет ничего сложного» S>Да, как же распределённые/многопоточные приложения писали без "модели акторов для C++"... тёмные люди видимо были, не знали что совершают невозможное.
Вот именно про это я говорил, когда писал про нечистоплотных людей. Я нигде не писал, что это невозможно.
А ты продолжаешь иллюстрировать мой тезис о неумении читать.
всеми силами стараются обойти ограничения языка и рантайма, создавая (иногда десятки) библиотек разной степени «фичастости». В итоге получается как в комиксе xkcd про стандарты. Есть разные библиотеки с пересекающимся функционалом...
Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
<и т.д.>
Ну и где-то рядом про то, что на любом Тьюринг-полном языке можно реализовать то, что реализовано на другом Тьюринг-полном языке. Вопрос только: какой ценой.
Здравствуйте, neFormal, Вы писали:
F>и расходов тоже нету, и накладок тоже нету... F>в смысле, слова не пропускай. а то ни там, ни там нет никаких затрат.
Повторюсь ещё раз, более разжёвано. У системных потоков мы имеем большие накладные расходы на создание и переключение потоков и нулевые на исполнение. У лёгкие потоков мы имеем маленькие накладные расходы на создание и переключение и ненулевые (а в случае Эрланга особенно) на исполнение. Соответственно в случае большого количества короткоживущих потоков (тот самый случай высоконагруженного сетевого сервиса) выгоднее использовать лёгкие потоки, а в случае небольшого количества долгоживущих (та же самая числодробилка) выгоднее системные. Это исключительно вопрос производительности.
А кроме этого ещё можно рассматривать вопрос организации кода, который существует уже поверх каких-то (выбранных из соображения производительности) потоков. И тут можно с ходу набросать множество разных вариантов:
— низкий уровень (те самые системные потоки/сопрограммы и локи)
— автоматизированный низкий уровень — например openmp позволяет в одну строчку распараллелить цикл, вставив все нужные потоки и локи
— модель акторов — грубо говоря организация кода через обмен сообщениями между потоками
— линеаризация параллельного кода — например aync/await в .net или аналоги в других языках, записываемые через сопрограммы
....
_>>Так что казалось бы всего лишь количественная разница вносит вполне себе качественные различия. F>ты смешиваешь скорость рантайма с количеством потоков. F>это ошибочно.
Какой ещё рантайм? ) То, что обсуждалось выше — это всё вообще было без привязке к языку. Т.е. в начале мы выбираем тип нужных нам потоков (это зависит от задачи) и способ организации кода (а это уже больше от нашего вкуса зависит), а уже потом смотрим какой язык может предложить нужное. Скажем C++ может предложить все варианты (за счёт бесчисленного количества разных библиотек). Эрланг может предложить неплохую реализации модели акторов поверх лёгких потоков. И т.д. и т.п.
F>ха-ха
... F>ха-ха
Аргументированно. )))
P.S. Кстати, лично мне как раз больше всего нравится именно модель акторов — я стараюсь именно её применять везде. Только вот на C++. И с системными и с лёгкими потоками, в зависимости от задачи.
Re[10]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>В этом и предыдущем топике уже многократно поясняли, причём разные участники. Если на пальцах, то:
EP>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат, и достигается это путём задействования всех доступных вычислительных ресурсов (грубо говоря всех ядер). Железные потоки/процессы здесь — это необходимость, а не средство упрощения кода. Более того, однопоточный вариант является самым простым, но естественно не задействует все вычислительные ресурсы. EP>В самом коде обычно нет никакого явного управления потоками и взаимодействия между ними. Всё это прекрасно скрывается внутри библиотек типа TBB, PPL, Thrust и различных реализаций MapReduce — предоставляя пользователю параллельные примитивы типа parallel_transform, parallel_foreach, parallel_for и parallel_reduce. EP>Конкретный пример — оптимизационная задача: есть набор параметров, ограничения и целевая функция. Необходимо найти значения параметров соответствующие минимуму/максимуму целевой функции. Вычисление значений целевой функции для разных параметров можно выполнять параллельно в разных вычислительных потоках, улучшая утилизацию железа.
EP>* При конкурентом программировании сама задача решается на порядки проще с использованием процессов, нежели без них. То есть процессы здесь это не необходимость, а благо. Причём процессы здесь необязательно железные, даже более того — всё может работать в одном железном потоке. EP>Каноничный пример: сетевой сервер обслуживающий клиентов проще всего выражается через модель наподобие "один логический поток на одного клиента".
Хм. По-моему, это одно и то же.
По факту в обоих случаях мы имеем одно и то же: алгоритм, логически выполняющийся в нескольких потоках (а физически — зависит от реализации). Понятный-непонятный, быстрый-медленный — это уже неформальные критерии. Можно, конечно, в курилке потрындеть "я вот тут алгоритм конкурентно запрограммировал", "да ни хрена, он у тебя конкурентный только на 30%, а параллельный на все 70".
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
_>Повторюсь ещё раз, более разжёвано. У системных потоков мы имеем большие накладные расходы на создание и переключение потоков и нулевые на исполнение. У лёгкие потоков мы имеем маленькие накладные расходы на создание и переключение и ненулевые (а в случае Эрланга особенно) на исполнение. Соответственно в случае большого количества короткоживущих потоков (тот самый случай высоконагруженного сетевого сервиса) выгоднее использовать лёгкие потоки, а в случае небольшого количества долгоживущих (та же самая числодробилка) выгоднее системные. Это исключительно вопрос производительности.
Что мешает запустить небольшое количество долгоживущих легковесных? Ах да, ничего, кроме зашоренности. Ну и того, что инструменты не позволяют это нормально сделать.
_>А кроме этого ещё можно рассматривать вопрос организации кода, который существует уже поверх каких-то (выбранных из соображения производительности) потоков. И тут можно с ходу набросать множество разных вариантов:
_>Какой ещё рантайм? ) То, что обсуждалось выше — это всё вообще было без привязке к языку. Т.е. в начале мы выбираем тип нужных нам потоков (это зависит от задачи) и способ организации кода (а это уже больше от нашего вкуса зависит), а уже потом смотрим какой язык может предложить нужное.
Да, кстати. Твой список «организации» кода обошел все проблемы, связанные с организацией этого кода, которые надо решать исключительно вручную.
_>P.S. Кстати, лично мне как раз больше всего нравится именно модель акторов — я стараюсь именно её применять везде. Только вот на C++. И с системными и с лёгкими потоками, в зависимости от задачи.
Ну то есть все остальное приходится закатывать вручную — изоляцию потоков, разделение данных, управление потоками и т.п. Ты смотри. Как раз то, о чем я говорил в изначальном сообщении
Здравствуйте, agat50, Вы писали:
A>Обожаю сравнения языков с нулем строчек реального кода на паре этих языков и роликом с youtube. По теме — не увидел ничего, что не решалось бы тасками с Rx в шарпе, остальными языками не пользуюсь уже давно.
внутри оно работает тривиально:
1. на пачке железок лежит VM
2. с первой железки открывается ssh-сессия до остальных и запускается VM с определёнными параметрами типа где взять код и кто мастер
3. все железки подключаются к первой по определённому порту и цепляются к роутеру процессов
4. если код лежит на удалённых нодах, то он там и запускается. либо можно залить код прямо на удалённые ноды
5. эрланговский кластер готов
в принципе, такое можно сделать для любого популярного языка, если завести нумерацию процессов и написать роутер.
A>давным давно есть очереди сообщений на любой вкус и цвет.
Кос-ты-ли...
Утоли мои печали, костыли...
A>Не падать от неучтенных ошибок — да не горит в общем то, чуть больше руками накодить catch->log.
A>Immutable везде — нафиг нафиг все эти теоретизации.
меньше шансов сотворить лажу
ну и GC становится проще.
A>Какие задачи невозможно (сложнее на порядок) решить на шарпе, чем на эрланге?
Здравствуйте, Mamut, Вы писали:
S>>Да, как же распределённые/многопоточные приложения писали без "модели акторов для C++"... тёмные люди видимо были, не знали что совершают невозможное. M>Вот именно про это я говорил, когда писал про нечистоплотных людей. Я нигде не писал, что это невозможно.
Конечно, вы просто писали что нет средств, что всё пропало и надежда только на Эрланг. Цитаты нужны?
M>А ты продолжаешь иллюстрировать мой тезис о неумении читать.
А вы продолжайте хамить.
M>всеми силами стараются обойти ограничения языка и рантайма, создавая (иногда десятки) библиотек разной степени «фичастости». В итоге получается как в комиксе xkcd про стандарты. Есть разные библиотеки с пересекающимся функционалом...
Ну и замечательно: выбирается конкретная библиотека, а не всё многообразие.
M>>Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком. S>А я назову это синтаксическим сахаром, и тоже буду прав.
M>Ну и где-то рядом про то, что на любом Тьюринг-полном языке можно реализовать то, что реализовано на другом Тьюринг-полном языке. Вопрос только: какой ценой.
И какой ценой? Я с первого сообщения интересовался конкретикой, а не демагогией:
Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно.
Что этого нельзя сделать на других языках? Очевидный бред
Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали.
ARI ARI ARI... Arrivederci!
Re[11]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, AlexRK, Вы писали:
ARK>Хм. По-моему, это одно и то же. ARK>По факту в обоих случаях мы имеем одно и то же: алгоритм, логически выполняющийся в нескольких потоках (а физически — зависит от реализации). Понятный-непонятный, быстрый-медленный — это уже неформальные критерии.
Вполне формальный.
Если бы "параллельный" код исполнялся в одном потоке — то не было бы никакого смысла распараллеливать однопоточный — это сложнее и дороже в любом случае (как минимум нужно подключить параллельную библиотеку, добавить опции компилятора, изменить код (иногда изменения минимальны, иногда увы нет) и т.п.).
Конкуретный же код наоборот использует процессы для упрощения решения, и в общем случае без проблем может работать на одном железном потоке.
Грань вполне чёткая.
ARK>Можно, конечно, в курилке потрындеть "я вот тут алгоритм конкурентно запрограммировал", "да ни хрена, он у тебя конкурентный только на 30%, а параллельный на все 70".
Даже если допустить что грани нет, то тезис в стартовом сообщении всё равно неверен — большой класс многопоточных задач (те которые принято называть parallel computing) решается без специальной поддержки со стороны языка.
S>>>Да, как же распределённые/многопоточные приложения писали без "модели акторов для C++"... тёмные люди видимо были, не знали что совершают невозможное. M>>Вот именно про это я говорил, когда писал про нечистоплотных людей. Я нигде не писал, что это невозможно. S>Конечно, вы просто писали что нет средств, что всё пропало и надежда только на Эрланг. Цитаты нужны?
Давай-давай. Особенно, что «надежда только Эрланг», ага-ага.
M>>А ты продолжаешь иллюстрировать мой тезис о неумении читать. S>А вы продолжайте хамить.
А что делать, если чиать ты точно не умеешь. Иначе мне не пришлось бы отвечать исключительно цитатами из самого себя.
M>>всеми силами стараются обойти ограничения языка и рантайма, создавая (иногда десятки) библиотек разной степени «фичастости». В итоге получается как в комиксе xkcd про стандарты. Есть разные библиотеки с пересекающимся функционалом... S>Ну и замечательно: выбирается конкретная библиотека, а не всё многообразие.
Еще раз: зачем? Про библиотеки я тоже написал, если что.
M>>Ну и где-то рядом про то, что на любом Тьюринг-полном языке можно реализовать то, что реализовано на другом Тьюринг-полном языке. Вопрос только: какой ценой. S>И какой ценой?
Ценой переизобретения велосипедов. Ценой ручного заката солнца. Ценой wasted effort на задачи, которые не должны требовать этих самых усилий.
S>Я с первого сообщения интересовался конкретикой, а не демагогией: S>Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Описано в первом сообщении
S>Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно. S>Что этого нельзя сделать на других языках? Очевидный бред
Этого я не утверждал. Это показывает, насколько хорошо ты умеешь читать, да
S>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали.
Да. Это удобнее сделать в Эрланге. Потому что множество вещей, которые описаны в первом же сообщении, там доступны из коробки. Могу подсказать: «Вводная часть» и «Вниз по кроличьей норе». Плюс очень неплохо в «Ээээ. Так что там Эрланг, я так и не понял». Ну и подведение итогов в «Но как же библиотеки и Эрланг не нужен?»
Поверь — это так просто: сесть и прочитать. А потом подумать, что же там написано. Взять не один, и не два пункта из разных списков, а пять, например. И посмотреть, как они будут решаться на твоем любимом языке.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если бы "параллельный" код исполнялся в одном потоке — то не было бы никакого смысла распараллеливать однопоточный — это сложнее и дороже в любом случае (как минимум нужно подключить параллельную библиотеку, добавить опции компилятора, изменить код (иногда изменения минимальны, иногда увы нет) и т.п.). EP>Конкуретный же код наоборот использует процессы для упрощения решения, и в общем случае без проблем может работать на одном железном потоке. EP>Грань вполне чёткая.
Все же не могу согласиться. Если взять какой-нибудь код, например, на Ada, где есть встроенная многопоточность, сможем ли мы сказать, какой это код — параллельный или конкурентный? Ну, может в каких-то случаях сможем. А в каких-то нет. Собственно, у меня может быть код одновременно и производительнее, и проще однопоточного. Я бы не назвал это четкой гранью.
EP>большой класс многопоточных задач (те которые принято называть parallel computing) решается без специальной поддержки со стороны языка.
Да, это безусловно.
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Повторюсь ещё раз, более разжёвано. У системных потоков мы имеем большие накладные расходы на создание и переключение потоков и нулевые на исполнение.
можешь не капитанить. я трогал и системные потоки тоже.
я бы даже не сказал, что расходы какие-то фатальные до определённой границы.
_>У лёгкие потоков мы имеем маленькие накладные расходы на создание и переключение и ненулевые (а в случае Эрланга особенно) на исполнение.
а тут ты опять сравниваешь скорость рантайма.
эрланг тормозной, это все знают. и шедулинг там не самая большая проблема. основные вещи там реализованы низкоуровнево.
_>А кроме этого ещё можно рассматривать вопрос организации кода, который существует уже поверх каких-то (выбранных из соображения производительности) потоков.
это да.
_>Скажем C++ может предложить все варианты (за счёт бесчисленного количества разных библиотек).
а что на плюсах есть хорошего для акторов?
_>Аргументированно. )))
да ваще!
_>P.S. Кстати, лично мне как раз больше всего нравится именно модель акторов — я стараюсь именно её применять везде. Только вот на C++. И с системными и с лёгкими потоками, в зависимости от задачи.
там обычно даже достаточно простой очереди сообщений, чтобы избежать усложнения изза блокировок.
ну и культуры кода, чтобы соблюдать соглашения.
...coding for chaos...
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Что мешает запустить небольшое количество долгоживущих легковесных? Ах да, ничего, кроме зашоренности. Ну и того, что инструменты не позволяют это нормально сделать.
Эм, я не понял, ты предлагаешь как-то ввести в какой-то язык сразу все описанные возможности? ) Или ты считаешь, что какой-то вариант является универсальным? )
Да, и кстати... Если говорить о типах потоков, то в подавляющем большинстве задач полезнее как раз системные. Просто потому, что написание серверов, работающие с тысячами подключений не является сильно распространённой задачей. )))
_>>P.S. Кстати, лично мне как раз больше всего нравится именно модель акторов — я стараюсь именно её применять везде. Только вот на C++. И с системными и с лёгкими потоками, в зависимости от задачи. M>Ну то есть все остальное приходится закатывать вручную — изоляцию потоков, разделение данных, управление потоками и т.п. Ты смотри. Как раз то, о чем я говорил в изначальном сообщении
Управление потоками в модели акторов? ) Забавно что же ты под этим подразумеваешь... ))) Если ты про собственно их запуск и обмен сообщениями, то это естественно входит в библиотеку поддержки.
Re[12]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Если бы "параллельный" код исполнялся в одном потоке — то не было бы никакого смысла распараллеливать однопоточный — это сложнее и дороже в любом случае (как минимум нужно подключить параллельную библиотеку, добавить опции компилятора, изменить код (иногда изменения минимальны, иногда увы нет) и т.п.).
поддержу AlexRK.
всё, что ты перечислил — это нюансы технологии.
весь вопрос в том, от чего ты строишь решение: от организации кода или от железа.
...coding for chaos...
Re[16]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Соответственно, если мы запускаем скажем числодробилку на лёгких потоках, то получаем отображение например 8 лёгких потоков в 8 системных (обычный пул по числу ядер) и в итоге планировщик и вся инфраструктура поддержки (то самое, чем ты там гордишься в Эрланге) лёгких потоков будут заняты исключительно обогревом воздуха. Тупо трата ресурсов в никуда без единого плюса взамен.
с smp, я так понимаю, эта проблема уходит.
выбирать между несколькими лёгкими уже просто не надо.
_>Да, и кстати... Если говорить о типах потоков, то в подавляющем большинстве задач полезнее как раз системные. Просто потому, что написание серверов, работающие с тысячами подключений не является сильно распространённой задачей. )))
свят-свят!
не все пишут числодробилки. много народу занимается как раз обработкой запросов юзеров.
Здравствуйте, Mamut, Вы писали:
M>Давай-давай. Особенно, что «надежда только Эрланг», ага-ага.
Это то, что доступно в языках на уровне стандартов и стандартных библиотек:
С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures.
...
— C#? Objective-C? Ruby? Php бггг? кто там еще есть в индексе? Все то же самое и одно и то же.
...
И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования именно в подходах к многопоточному программированию.
M>Еще раз: зачем?
Зачем иметь возможность выбрать библиотеку?
М>Про библиотеки я тоже написал, если что.
Тогда вам не составит труда ответить на проигнорированный вами вопрос: S>Можно примеры, как рантайм ограничевает (до невозможности реализации) асинхронную отправку сообщений и синхронизацию? Я бы понял, если фанаты хаскеля сейчас бы жёстко троллили всех STM'ом (вроде как только в нём он реализуется без огромных костылей).
M>Ценой переизобретения велосипедов.
Библиотеки. М>Ценой ручного заката солнца.
Синтаксический сахар М>Ценой wasted effort на задачи, которые не должны требовать этих самых усилий.
И, как обычно, примеров таких задач не будет
S>>Я с первого сообщения интересовался конкретикой, а не демагогией: М>Описано в первом сообщении
См. последний абзац этого сообщения.
S>>Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно. S>>Что этого нельзя сделать на других языках? Очевидный бред М>Этого я не утверждал. Это показывает, насколько хорошо ты умеешь читать, да
См. первый абзац этого сообщения.
S>>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. M>Да. Это удобнее сделать в Эрланге. Потому что множество вещей, которые описаны в первом же сообщении, там доступны из коробки. Могу подсказать: «Вводная часть» и «Вниз по кроличьей норе». Плюс очень неплохо в «Ээээ. Так что там Эрланг, я так и не понял». Ну и подведение итогов в «Но как же библиотеки и Эрланг не нужен?»
Доступны из коробки по сравнению с чем? Со "стандартной библоотекой С++"? S>видимо без такого handicap'а Эрлангу вообще не светит
М>Взять не один, и не два пункта из разных списков, а пять, например. И посмотреть, как они будут решаться на твоем любимом языке.
Я должен вместо вас этим заниматься? Бремя доказательства лежит на высказавшем утверждение, особенно учитывая ваши поистине безграничные познания во всех языках и библиотеках.
M>А что делать, если чиать ты точно не умеешь. Иначе мне не пришлось бы отвечать исключительно цитатами из самого себя.
Полагаю, вам просто нечего сказать. Ведь аргументация ваших утверждений потребует конкретики, а вы так и не смогли её выдать.
И поэтому, до тех пор пока мне не надоест с вами общаться, вы будете продолжать к месту и не к месту цитировать своё первое сообщение.
