Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
I>Ну да, твоя любимая тактика — один ты умный, а другие даже читать не умеют.
Что поделать, если другие действительно даже читать не умеют.
Последняя попытка. Без надежды на понимание. Убедительная просьба сначала прочитать, а потом отвечать. Хотя лучше не отвечать. «Аргументы» мне давно известны.
Дальше в топике я называю потоками и потоки и корутины и легковесные процессы. Так просто проще.
Итак.
Тема топика: Mногопоточность: C++ vs Erlang vs другие
Начиналось все с этого вопроса: Итак, что там у С++ за траблы с многопоточной невнятностью? И какие языки размалывают его по внятности?
Тезис топика: Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком. Когда все, что язык предоставляет — это появившиеся в 2011-м стандарте thread'ы, то далеко на нем не уедешь. Во всяком случае пока умные люди не напишут вокруг всего этого костыли и библиотеки. Потому что первый же залетный mutex.lock убъет любую многопоточность и многоядерность.
Если ты и прочие готовы обсуждать только и исключительно:
— производительность VM Erlang'a, ты не умеешь читать
— особенности VM Эрланга, то ты не умеешь читать
— область применения Эрланга, то ты не умеешь читать
— и т.п.
Потому что топик — ВНЕЗАПНО! — не про Эрланг. Если ты не можешь это понять, то ты не умеешь читать. И понимать.
Я внятно выразился? С пониманием проблем нет? Если есть, то все, на этом любое обсуждение прекращаем. Если нет, то идем дальше.
Вводная часть
Практически каждое первое приложение сегодня так или иначе [многопоточно, многоядерно, распределенно] (выбрать любую комбинацию из этого списка). Если нет, то будет в ближайшие годы. Даже самые тупые домашние странички, написанные школотой на PHP управляются весьма себе веб-серверами, заточенными под этот список. Даже самые тупые однопоточные мобильные приложения часто имеют backend где-то в облаках, которые должен уметь обрабатывать множество вещей одновременно. Ну и т.п. Весь десктоп давно многопоточный, даже если всякая школота до сих пор не умеет показать progress bar без того, чтобы завесить весь UI-поток.
При этом в подавляющем большинстве современных языков программирования отсутствуют:
— поддержка работы с этим списком (рантайм + сам язык знают и умеют это делать)
— средства для удобной работы с этим списком (высокоуровненвые инструменты, доступные или прямо из языка или в составе стандартной библиотеки)
И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка. Смешной момент: всякие лямбды, замыкания и прочая функциональщина прекрасно себе решались Boost'ом, но появление всего этого в С++11 было воспринято просто на ура. Но когда заходит речь о многопоточности, например, внезапно общее отношение кажется таким: все решается библиотеками легко и просто нафига это на уровне языка? Понятно, что это относится не только к С++.
Давайте посмотрим, что у нас считается state of the art в некоторых современных языках. Для тех, кто в наглухо забронированном танке. Это то, что доступно в языках на уровне стандартов и стандартных библиотек:
(понятно, что я могу ошибаться, или ошибаться в деталях)
Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы. Буквально единицы представляют еще и асинхронные вызовы через futures/promises, но и они обычно являются отдельным потоком/процессом в ОСи с общением через разделяемую память.
Еще раз для тех, кто в наглухо запаянном танке: это — state-of-the-art, кодифицированный в стандартах языка и его стандартных библиотеках. О third-party библиотеках я еще не начал говорить.
И это — только самая-самая вершина айсберга.
Вниз по кроличьей норе
Если у тебя однопоточное приложение — проходим мимо. Как только потоков становится N > 1, все становится очень печально (в большинстве языков). Потому что потоками надо управлять и потокам надо общаться друг с другом.
Что такое управлять потоками?
Все просто. Мы запустили поток, нам нужно:
— Знать, что поток выполняется
— Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
— Возможно, перезапустить поток, если он завершился
— Убить поток, если это необходимо
Что такое общаться друг с другом?
Все просто. Часто одному потоку надо знать о промежуточном состоянии другого потока или передать в другой поток какое-то свое промежуточное состояние. Как простейшие примеры:
— UI поток должен узнать, что что-то изменилось в долгоиграющем потоке, чтобы обновить свое состояние (прогрессбар, например)
— Долгоиграющий поток должен узнать, что что-то изменилось в окружающем мире, чтобы продолжить работу (появились новые данные, изменилась конфигурация и т.п.)
Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов. Вплоть до смешного:
There is no portable way in C++11 (that I'm aware of) to non-cooperatively kill a single thread in a multi-thread program (i.e. without killing all threads).
Не удивительно, что при таком сне разума рождаются чудовища:
— люди просто не знают о каких-либо инструментах за пределами условного mutex.lock и не понимают, зачем такие инструменты нужны. Потому что даже фраза «потоки могут общаться друг с другом» являются китайской грамотой для языков, в которых while(shared_variable != true) execute() является единственным способом общения между потоками
— те, которые понимают, всеми силами стараются обойти ограничения языка и рантайма, создавая (иногда десятки) библиотек разной степени «фичастости». В итоге получается как в комиксе xkcd про стандарты. Есть разные библиотеки с пересекающимся функционалом, ни одна из которых не предлагает комплексного подхода к решению.
Э, так чё там Эрланг
Ситуация с Эрлангом — как с Лиспом и всякими ML'ями.
C and ML were both finished in 73. ML had first-class functions, GC, type inference, algebraic data types, pattern matching, and exceptions.
Это все было «неэффективное, тормозное, никому не нужное, это можно было решить библиотеками». За буквально десять прошедших лет каждый первый язык программирования поспешил обзавестись хотя бы некоторыми из этих фич. И активно всасывают оставшиеся.
Ситуация с Эрлангом на данный момент примерно такая же
Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
Не обязательно потому что люди обязательно вдохновляются Erlang'ом, нет. А потому что Erlang раньше большинства многих других пришел к тому, к чему сейчас только приходят в других языках (и их библиотеках).
Ээээ. Так что там Эрланг, я так и не понял
Erlang не появился ниоткуда. Он появился в Ericsson'е для решения проблем в телекоме. Какие это были проблемы? Надо было обрабатывать множество пользовательских запросов одновременно, в пределах заданных параметров, с возможностю прозрачно переносить пользователя с системы на систему в случае сбоев — в том числе и хардварных. То есть, то чем сегодня занимается чуть ли не каждый первый В 80-х такие задачи стояли у достаточно небольшого количества компаний.
Над этой задачей Ericsson работал давно и успешно. В частности, до Erlang'а у Ericsson'а уже был PLEX: special-purpose, pseudo-parallel and event-driven real-time programming language. В 81-м году Ericsson организовал лабораторию, перед которой ставилась задача: "to suggest new architectures, concepts and structures for future".
В 1993-м году заведующий этой лабораторией Bjarne Däcker сформулировал накопившийся опыт построения телекоммуникационных систем так (цитирую по DÄ2000):
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.
(tl;dr по списку: люди, которые говорят, что это — маркетинг буллшит просто не имеют ни малейшего понятия, что они несут)
Механизмы и инструменты которые Erlang предоставляет из коробки, выросли напрямую из необходимости соответствовать этим требованиям. По некоторым пунктам:
1. Требует возможность создать множество параллельных процессов, которыми надо управлять, и которым надо общаться между собой.
2. Требует гарантий на время отклика системы
3. Требует механизмов для распределения системы по нескольким компьютером, что тянет за собой множество требований. Например, если умерла система X, система Y должна иметь возможность гарантированно об этом узнать
5. Нужны из коробки механизмы управления крупными системами (в случае с Эрлангом — управления множеством процессов)
8. Нужно иметь возможность обновить систему, не останавливая ее, что тянет за собой множество требований: как заставить долгоживушие процессы обновить код, что делать со stale code в памяти, как производить апгрейд структур в памяти и т.п.
10. В частности: если процесс умирает, он не должен утянуть за собой всю систему. Если процесс умер на машине X, об этом надо гарантированно узнать на машине Y и т.п.
Остальные пункты могут быть не такие радужные, поэтому я описал выборочно
Все это выливается в требования, сформулированные одним из создателей языка, Вирдингом:
Properties of the Erlang system
— Lightweight, massive concurrency
— Asynchronous communication
— Process isolation
— Error handling
— Continuous evolution of the system
— Soft real-time
И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования именно в подходах к многопоточному программированию.
Но как же библиотеки и Эрланг не нужен?
Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
Начало любого диалога про Erlang неизбежно скатывается в «я тоже умею делать 100500 потоков, как Erlang, зачем мне Erlang».
Просто создать 100500 потоков недостаточно. Ими надо управлять. Какие из них завершились аварийно? Надо ли их перезапустить? Надо ли их перезапустить, если они завершились не аварийно? Программа получила сигнал QUIT, как сообщить всем потокам, что усё, надо завершаться и подчищать за собой? Некоторые из потоков запускают какие-то дополнительные потоки, как управляются они? Потоки зависят от промежуточных данных других потоков, как организовано взаимодействие этих потоков? И еще несколько десятков таких вопросов.
Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
— Библиотека X может создать 100500 потоков, но общение строго через shared state с мьютексами и прочим.
— Библиотека Y может создать 100500 потоков, общение агентами/сообщениями, но нет никакой возможности управлять этими потоками, кроме как врукопашную реализовывать весь мониторинг и прочее
— Библиотека Z, может создать 100500 потоков, общение агентами/сообщениями, есть управление потоками, но нет изоляции потоков, поэтому любое залетное деление на 0 просто убивает всю программу
и так далее и тому подобное.
При этом люди, заявляющие, что «мы создаем 100500 потоков без управления» или «я всего за несколько часов все сделал» лгут. В первую очередь, самим себе. Все там есть. Есть там и управление (пусть даже самое рудиментарное — процесс X следит за завершением процесса Y). И заботливо разбросанные по коду try/catch'и (иначе умрет вся программа или где-то не будут подчищены ресурсы). И «всего несколько часов» приходится тратить каждый раз, когда надо это все реализовать (причем стандартизированного подхода ведь не существует). Ну и т.п.
Итак, что там у С++ за траблы с многопоточной невнятностью? И какие языки размалывают его по внятности?
По внятности всех размалывает Erlang. Потому что он из коробки предоставляет удобные, мощные, единообразные и предсказуемые инструменты для создания многопоточных приложений. Не удивительно, что эти инструменты медленно, но верно проникают в другие языки и библиотеки других языков. Потому что многопоточность и распределенность — это не сказки для подрастающего поколения времен DOS'а, а суровая реальность, и с убогими thread.create и mutex.lock в ней не выжить. Но еще некоторое время себя можно обманывать, что «подходы Erlang'а не нужны» и т.п. neFormal все парвильно сказал достаточно рано во всей этой дискуссии
S>Ну и если уж зашла речь о том, что могут другие языки, то не так уже и мало.
ага, все умеют "свою половину языка Erlang".
так много слов а суть проста. другим технологиям необходимо добиться паритета по следующим пунктам:
1. параллельное выполнение множества задач
2. отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)
3. единое пространство потоков/процессов на нескольких физических юнитах
К сожалению, множество нечистоплотных людей решило, что они не будут стараться понимать написанное, и приложило множество усилий к тому, чтобы обсуждать все что угодно, только не топик. Оставим это на их совести. В топике было множество попыток от neFormal'а и meadow_meal'а вернуть обсуждение на нужные рельсы. Кто хотел понять, понял. Кто не хотел — на них не обижаются.
Здравствуйте, Mamut, Вы писали:
M>Если ты не можешь это понять, то ты не умеешь читать. И понимать. M>Я внятно выразился? С пониманием проблем нет? Если есть, то все, на этом любое обсуждение прекращаем. Если нет, то идем дальше.
да забаньте вы уже это батхёртящее хамло.
kalsarikännit
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Что поделать, если другие действительно даже читать не умеют.
Вот это уже слив.
M>Последняя попытка. Без надежды на понимание. Убедительная просьба сначала прочитать, а потом отвечать. Хотя лучше не отвечать. «Аргументы» мне давно известны.
А на кой ты начал тред с такого ?
M>К сожалению, множество нечистоплотных людей решило, что они не будут стараться понимать написанное, и приложило множество усилий к тому, чтобы обсуждать все что угодно, только не топик. Оставим это на их совести. В топике было множество попыток от neFormal'а и meadow_meal'а вернуть обсуждение на нужные рельсы. Кто хотел понять, понял. Кто не хотел — на них не обижаются.
У тебя почти весь текст состоит из хамства, намеков на квалификацию и разных провокаций. Как то так.
Re: Эрланг и все-все-все (на самом деле, не совсем)
Ваш крайне эмоциональный, но содержащий мало технической информации текст, базируется на двух если не 100% неверных, то уж точно крайне спорных тезисах:
M>Тезис топика: Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком. M>Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы.
Первый тезис несостоятелен потому, что далеко не все языки программирования затаскивают все, что может потребоваться пользователю, в сам язык. Язык предоставляет базис, остальное реализуется библиотеками. Язык должен содержать в себе условия для генерации корректно работающего в условиях многопоточности кода (например, правильное поведение с volatile данными, расстановка барьеров в нужных местах и т.д., включая корректное поведение стандартной библиотеки в многопоточном приложении). Эти гарантии для современных языков (полагаю, практически всех) соблюдаются повсеместно.
Второй тезис несостоятелен потому, что зафиксированное в стандарте не есть state-of-the-art. В стандарты не принято включать то, что не апробировано на практике и не прошло проверку временем. Так что содержание стандарта -- это вчерашний, если не позавчерашний день.
Собственно, на этом все ваши хвалебные оды Erlang-у можно было бы и зарывать.
Но, благодаря вашей воинственности, невозможно не пройти мимо еще нескольких вещей.
Во-первых, вашей неспособности давать ответы на вполне конкретные вопросы. Например, вы в очередной раз поминаете гарантированное время отклика. При этом не можете сказать, что и как обеспечивает эти гарантии в Erlang. А ведь вопрос не праздный, т.к.:
a) язык Erlang имеет GC, но является ли этот GC real-time-овым?
b) вам приводили примеры с просадками производительности selective receive, но вы от этих примеров отмахиваетесь так, как будто их не существует;
Во-вторых, вы упрекаете другие языки/платформы в ненадежностии, мол, если в каком-то потоке случается деление на 0, то падает вся программа. При этом:
a) вы позволяете себе объединять native и managed платформы под одной крышей. Что уже неправильно. Разве деление на 0 в одном из потоков Java-приложения уронит всю JVM? Кроме того, даже в native есть сильно разные языки, предоставляющие разные уровни безопасности. То, что актуально для C и C++, не является таковым для Eiffel, Modula-2, Ada или OCaml с Haskell-ем;
b) вы, видимо, не знаете или же не желаете об этом говорить, но стоит только в Erlang-приложение включить написанную на C или C++ NIF-ку или драйвер, так сразу же надежность Erlang-ового приложения оказывается на уровне надежности C-шного кода. Причем не нужно даже совершать такую ошибку, как деление на 0. Достаточно просто запросить у Erlang-а через enif_alloc_resource больше памяти, чем есть сейчас в наличии, и вся Erlang-овская VM будет убита обращением к abort(). А ведь производительность pure-Erlang кода такова, что как только на Erlang-е потребуется написать что-то быстрое, так необходимость реализации NIF-ов, драйверов, а то и портов на C или C++, становится крайне актуальной.
В-третьих, вы упорно не желаете признавать разницу между parallel computing и concurrent computing, даже не смотря на то, что вам на это неоднократно указывали. И если достоинства Erlang-а в области concurrent computing мало у кого вызывают сомнения, то вот применимость Erlang-а в parallel computing нужно доказывать и доказывать. Полагаю, для специализирующихся в этой области такие инструменты, как OpenMP и MPI, доступные для C, С++ и Fortran практически “из коробки”, перевешивают все, что придется вручную городить на Erlang-е и OTP. Тем не менее, вы продолжаете утверждать, что Erlang хорош для параллельности и многозадачности вообще, без оглядки на специализацию.
В-четвертых, вы демонстрируете потрясающий уровень безграмотности в областях, не относящихся к Erlang-у. Такое ощущение, что вы придумали себе какую-то картину мира, в которой нет ничего, кроме ручного управления памятью, нитями и мутексами, после чего упорно не желаете взглянуть на объективную реальность. Что делает невозможным донесение до вас простых известий о том, что даже то, что вы считаете неоспоримыми достоинствами Erlang-а, уже давным давно существует для других языков и платформ. И достигнуто это совсем не такими титаническими усилиями, о которых вы упорно говорите.
Ну и, в-пятых, ваш стиль ведения дискуссий не позволяет понять, что в высказываниях оппонентов вас не устраивает. Пишешь вам ответ, а вы вместо того, чтобы сказать, с чем не согласны, отправляете что-нибудь читать “до просветления”: либо стартовое сообщение, либо какую-то документацию (которой, может вообще нет в природе). Т.е. вам проще объявить, что несогласные с вами читатели ничего не понимают (либо вообще, либо в написанном вами тексте), чем сделать усилие и признать, что собеседники вполне вас понимают и услышали то, что вы хотели сказать. И теперь ждут, что вы услышите их точку зрения.
Впрочем, можно сказать еще пару вещей.
Ericsson не единственная компания, выпускающая телекомовское оборудование. Поэтому не нужно выдавать Erlang за стандарт для разработки подобного рода софта, другие производители успешно использовали и используют другие технологии.
Разработкой инструментария для построение распределенных и отказоустойчивых систем озаботились давным-давно. Тот же CORBA появился на свет в 1991-м году, когда Erlang был всего лишь предметом исследований в одной из лабораторий Ericsson-а. Ну а про многочисленные MQ-шные системы и говорить не приходится. Что, кстати говоря, еще раз опровергает ваш тезис о том, что средства для построения многопоточных и/или распределенных приложений должны быть зафиксированы в стандарте языка.
Ну и, конечно же, вытащенный вами в качестве аргумента тезис neFormal-а о том, что “отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)”... Это не поддается цензурному описанию.
Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно.
Что этого нельзя сделать на других языках? Очевидный бред
Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
Истерика вокруг мьютексов вообще непонятна: у каждого инструмента своя область применения, и можно легко представить случаи когда и модель обмена сообщениями, и STM уступят по производительности обычной блокировке настолько, что никакой синтаксический сахар не перевесит выигрыша в скорости.
Здравствуйте, Mamut, Вы писали:
M>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
А можете Akka покритиковать?
Re[2]: Эрланг и все-все-все (на самом деле, не совсем)
S>Ваш крайне эмоциональный, но содержащий мало технической информации текст, базируется на двух если не 100% неверных, то уж точно крайне спорных тезисах:
Я готов обсудить тезисы, но ведь ты не обсуждал эти тезисы? Ты прикопался к Эрлангу, потом прикапывался к отдельным пунктам, занимался передергиванием и сменой тем на ровном месте
M>>Тезис топика: Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком. M>>Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы.
S>Первый тезис несостоятелен потому, что далеко не все языки программирования затаскивают все, что может потребоваться пользователю, в сам язык. Язык предоставляет базис, остальное реализуется библиотеками. Язык должен содержать в себе условия для генерации корректно работающего в условиях многопоточности кода (например, правильное поведение с volatile данными, расстановка барьеров в нужных местах и т.д., включая корректное поведение стандартной библиотеки в многопоточном приложении). Эти гарантии для современных языков (полагаю, практически всех) соблюдаются повсеместно.
Тезис, что ты выдвинул, не менее спорный.
Например, как ты ни крутись, какие библиотеки не пиши, а в Питоне у тебя будет GIL. И ты ничего с этим не сможешь сделать. То есть реализовать четыре параллельных scheduler'а, которые будут параллельно обрабатывать свои процессы тебя не получится (кроме костылей вроде использования Process).
Или, как ни крутись, а в Java у тебя будет (изредка, зависит от реализаций, но все же) stop-the-world для сборки мусора. И ты ничего с этим поделать не сможешь.
Или, как ни крутись, а непойманное исключение в потоке в С++ согласно стандарту убивает все потоки, включая основной. Поэтому тебе придется изворачиваться, чтобы реализовывать полноценную изоляцию процессов, чтобы ошибка в простейшей корутине не убила все приложение нафиг.
Ну и т.п.
Понятно, что все, что можно реализовать на одном Тьюринг-полном языке, можно реализовать на другом Тьюринг-полном языке. Только ценой каких усилий? Например, вместо того, чтобы 20 лет пилить SObjectizer, чтобы дать возможность в С++ использовать модель акторов, эти усилия можно было вообще не тратить, если бы эта модель была в С++ из коробки. Так ведь? Но почему-то эти 20 лет (в том числе) называются «и достигнуто это совсем не такими титаническими усилиями, о которых вы упорно говорите»
S>Второй тезис несостоятелен потому, что зафиксированное в стандарте не есть state-of-the-art. В стандарты не принято включать то, что не апробировано на практике и не прошло проверку временем. Так что содержание стандарта -- это вчерашний, если не позавчерашний день.
Интересно. Поддержка многопоточности со множеством доступных из коробки инструментов — это стандарт Эрланга (потому что апробировано на практике и прошло проверку временем). Если это — позавчерашний день, а боюсь представить, что будет в Эрланге послезавтра, когда другие языки только дойдут до стандарта Эрланга сегодняшнего
Обсуждение особенностей Эрланга и его VM скипнуто.
S>Во-вторых, вы упрекаете другие языки/платформы в ненадежностии, мол, если в каком-то потоке случается деление на 0, то падает вся программа. При этом: S>a) вы позволяете себе объединять native и managed платформы под одной крышей. Что уже неправильно.
Правильно. Только надо не прикапываться к частностям, а научиться понимать, что пишут оппоненты. Полная цитата звучала так: «Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов. Вплоть до смешного:». Что для любого читающего человека понятно: есть разные уровни, но в некоторых языках это доходит до смешного
S>b) вы, видимо, не знаете или же не желаете об этом говорить, но стоит только в Erlang-приложение
Если ты и прочие готовы обсуждать только и исключительно:
— производительность VM Erlang'a, ты не умеешь читать
— особенности VM Эрланга, то ты не умеешь читать
— область применения Эрланга, то ты не умеешь читать
— и т.п.
Потому что топик — ВНЕЗАПНО! — не про Эрланг.
S>В-третьих, вы упорно не желаете признавать разницу между parallel computing и concurrent computing, даже не смотря на то, что вам на это неоднократно указывали. И если достоинства Erlang-а в области concurrent computing мало у кого вызывают сомнения, то вот применимость Erlang-а в parallel computing нужно доказывать и доказывать. Полагаю, для специализирующихся в этой области такие инструменты, как OpenMP и MPI, доступные для C, С++ и Fortran практически “из коробки”, перевешивают все, что придется вручную городить на Erlang-е и OTP. Тем не менее, вы продолжаете утверждать, что Erlang хорош для параллельности и многозадачности вообще, без оглядки на специализацию.
Этого я не утверждаю.
S>В-четвертых, вы демонстрируете потрясающий уровень безграмотности в областях, не относящихся к Erlang-у. Такое ощущение, что вы придумали себе какую-то картину мира, в которой нет ничего, кроме ручного управления памятью, нитями и мутексами, после чего упорно не желаете взглянуть на объективную реальность. Что делает невозможным донесение до вас простых известий о том, что даже то, что вы считаете неоспоримыми достоинствами Erlang-а, уже давным давно существует для других языков и платформ. И достигнуто это совсем не такими титаническими усилиями, о которых вы упорно говорите.
Цитрую сам себя:
И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка.
Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
— Библиотека X может создать 100500 потоков, но общение строго через shared state с мьютексами и прочим.
— Библиотека Y может создать 100500 потоков, общение агентами/сообщениями, но нет никакой возможности управлять этими потоками, кроме как врукопашную реализовывать весь мониторинг и прочее
— Библиотека Z, может создать 100500 потоков, общение агентами/сообщениями, есть управление потоками, но нет изоляции потоков, поэтому любое залетное деление на 0 просто убивает всю программу
и так далее и тому подобное.
Твое упорное нежелание понимать, что тебе пишут, просто удивительно.
У тебя есть конкретные возражения по тому, что я написал? Ну именно возражение, а не битье себя пяткой в грудь в стиле «у меня клиенты создают 100500 потоков без управления».
S>Ну и, в-пятых, ваш стиль ведения дискуссий не позволяет понять, что в высказываниях оппонентов вас не устраивает.
Вообще-то, это я написал разными простейшими словами несколько раз. Включая этот топик.
S>Впрочем, можно сказать еще пару вещей.
Скипнуто, так как ты приписываешь мне тезисы, которые я не выдвигал. Предлагаю тебе не придумывать за меня то, что я не пишу, а все таки сесть и прочитать, что именно я пишу
M>>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
С>А можете Akka покритиковать?
К сожалению, не смогу Я ее трогал пальцем очень давно, практически, когда они только начинались. Но, имхо, они молодцы. Они как раз стараются решить проблему комплексно — от создания потоков до управления ими и т.п.
Плюс они пошли дальше, чем тот же Erlang. Например, некоторых из их утилит нет в Erlang'е в стандартной поставке (типа CircuitBreaker). Я, единственное, помню, что они таки наткнулись на ограничения JVM, но, к сожалению, не вспомню, где я это читал.
В общем, из всех библиотек, Akka, имхо, пример того, как делать надо (как минимум в плане подхода к решению проблем. В реальности она вполне может оказаться монструозной бякой )
S>Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Все описано и в сообщении и в соседнем топике
S>Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно. S>Что этого нельзя сделать на других языках? Очевидный бред
Все упирается в количество затрачиваемых усилий. Очевидно же?
S>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
Действительно. Ведь Эрланг — это только message passing. Или Эрланг — это только 100500 процессов. /o\ И вообще, мы говорим строго и исключительно об Эрланге.
Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?
Здравствуйте, Somescout, Вы писали:
S>Скажите, а в чём был смысл этого сообщения?
ещё раз мокнуть so5team
S>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
видимо, надо попробовать устрицу, чтобы не спорить о вкусе, зная лишь вкус картошки.
...coding for chaos...
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Ты прикопался к Эрлангу, потом прикапывался к отдельным пунктам, занимался передергиванием и сменой тем на ровном месте
На этом месте остается только посоветовать вам перечитать то, что вам писали. Как в этой теме, так и в предыдущих. Вы явно ничего не поняли. А если помножить это еще и узость кругозора
, то смысла общаться с вами на темы concurrency и parallel computing нет вообще.
M>Но почему-то эти 20 лет (в том числе) называются «и достигнуто это совсем не такими титаническими усилиями, о которых вы упорно говорите»
Я очень сильно удивлюсь, если выяснится, что все вложенные в разработку SObjectizer-а усилия составляют хотя бы целые проценты от того, что Ericsson вложил в Erlang в 1980-х и 1990-х. Скорее речь будет идти о долях процентов. Это не может быть титаническими усилиями в принципе.
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Somescout, Вы писали:
S>>Скажите, а в чём был смысл этого сообщения? F>ещё раз мокнуть so5team
Типа может в этот раз да и получится? В предыдущей теме сообщения so5team единственное что было интересно читать.
S>>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга). F>видимо, надо попробовать устрицу, чтобы не спорить о вкусе, зная лишь вкус картошки.
Вы сравниваете Эрланг со склизкой гадостью, способной вызвать смертельное отравление?
Здравствуйте, Mamut, Вы писали:
S>>Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести? M>Все описано и в сообщении и в соседнем топике
Я так и думал что вы тоже не сможете сформуливать цель.
M>Все упирается в количество затрачиваемых усилий. Очевидно же?
В смысле потребуется дополнительно выучить Эрланг и портировать туда существующий код?
M>Действительно. Ведь Эрланг — это только message passing. Или Эрланг — это только 100500 процессов. /o\ И вообще, мы говорим строго и исключительно об Эрланге. M>Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?
См. первый вопрос — вы сами не можете сформулировать о чём пишите, так что конечно проблема.
А насчёт "строго и исключительно" — так может укажете на конкретику о других языках (и библиотеках) в вашем сообещении? А то кроме избиения сферического стандарта C++ в вакууме: "Ааааааaa! В C++11 есть только потоки и мьютексы. Ну ещё есть futures. А в Эрланге намного больше!!!!1111", никакой конкретики по другим средствам в вашем сообщении нет. Так что да, поздравляю, у стандарта C++11 Эрланг выигрывает всухую, ура, ура.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Somescout, Вы писали:
S>>Типа может в этот раз да и получится? F>как будто для этого нужно много усилий
Ну, судя по тому что возникла эта тема с истерикой в первом же сообщении...
F>это твой виртуал?
Нет, просто учитывая раздел было странно увидеть в нём кого-то адекватного, вот и запомнилось.
S>Вы сравниваете Эрланг со склизкой гадостью, способной вызвать смертельное отравление?
ARI ARI ARI... Arrivederci!
Re: Эрланг и все-все-все (на самом деле, не совсем)
M>Эрланг и все-все-все (на самом деле, не совсем) M>Тема топика: Mногопоточность: C++ vs Erlang vs другие M>Э, так чё там Эрланг M>Ситуация с Эрлангом — как с Лиспом и всякими ML'ями. M>Ситуация с Эрлангом на данный момент примерно такая же M>Не обязательно потому что люди обязательно вдохновляются Erlang'ом, нет. А потому что Erlang раньше большинства многих других пришел к тому, к чему сейчас только приходят в других языках (и их библиотеках). M>Ээээ. Так что там Эрланг, я так и не понял M>Erlang не появился ниоткуда. M>В частности, до Erlang'а у Ericsson'а уже был PLEX M>Механизмы и инструменты которые Erlang предоставляет из коробки, выросли напрямую из необходимости соответствовать этим требованиям. По некоторым пунктам: M>Properties of the Erlang system M>И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования M>Но как же библиотеки и Эрланг не нужен? M>Начало любого диалога про Erlang неизбежно скатывается в «я тоже умею делать 100500 потоков, как Erlang, зачем мне Erlang». M>Вот так выглядит вполне стандартная программа, написанная на Erlang'е: https://youtu.be/lHoWfeNuAN8 M>Для не-Erlang'иста это — нереализуемо даже в самых страшных (или влажных) снах. M>По внятности всех размалывает Erlang. M>ага, все умеют "свою половину языка Erlang".
Здравствуйте, Mamut, Вы писали:
M>Тезис топика: Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком.
Не верный тезис в общем случае. Всё зависит от возможностей кастомизации обсуждаемого языка. К примеру у какого-нибудь там JS или VB они почти на нуле и для них твоя фраза справедлива. А скажем на D можно написать прямо средствами языка ещё один встроенный язык — понятно что в таком случае можно реализовать на уровне библиотек всё что угодно. Ну и конечно же желательно иметь нативный язык, чтобы не было ограничений виртуальный машины (типа того же глобального сборщика мусора и т.п.). Что касается обсуждаемого C++, то конечно же он не является лидером по кастомизации, но всё же очень и очень не плох в этой области. Ну и как системный язык естественно не имеет никаких ограничений платформы. Так что в случае конкретно C++ я не вижу каких-то проблем в реализации обсуждаемых возможностей с помощью библиотек.
M>И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка. Смешной момент: всякие лямбды, замыкания и прочая функциональщина прекрасно себе решались Boost'ом, но появление всего этого в С++11 было воспринято просто на ура. Но когда заходит речь о многопоточности, например, внезапно общее отношение кажется таким: все решается библиотеками легко и просто нафига это на уровне языка? Понятно, что это относится не только к С++.
Там на самом деле немного другой расклад. Вообще пользоваться чем угодно (в том числе и библиотекой) включённым в стандарт всегда удобнее, чем сторонними решениями.
M>Давайте посмотрим, что у нас считается state of the art в некоторых современных языках. Для тех, кто в наглухо забронированном танке. Это то, что доступно в языках на уровне стандартов и стандартных библиотек: M>... M>Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы. Буквально единицы представляют еще и асинхронные вызовы через futures/promises, но и они обычно являются отдельным потоком/процессом в ОСи с общением через разделяемую память.
Ну давай посмотрим) Вот например в D имеем хорошо знакомую тебе модель акторов: http://dlang.org/phobos/std_concurrency.html Это естественно помимо обычных потоков, мьютексов и т.п. И что самое интересное, всё это опять же реализовано исключительно в виде библиотеки. Правда входящей в стандарт языка, что конечно же отдельный плюс (в сравнение с C++).
M>Еще раз для тех, кто в наглухо запаянном танке: это — state-of-the-art, кодифицированный в стандартах языка и его стандартных библиотеках. О third-party библиотеках я еще не начал говорить.
Да да, в промышленных языках обычно самое главное как раз в библиотеках. )
M>Если у тебя однопоточное приложение — проходим мимо. Как только потоков становится N > 1, все становится очень печально (в большинстве языков). Потому что потоками надо управлять и потокам надо общаться друг с другом.
Ну у кого как. ) У меня что-то никакой печали нет. )
M>- те, которые понимают, всеми силами стараются обойти ограничения языка и рантайма, создавая (иногда десятки) библиотек разной степени «фичастости». В итоге получается как в комиксе xkcd про стандарты. Есть разные библиотеки с пересекающимся функционалом, ни одна из которых не предлагает комплексного подхода к решению.
А с чего ты взял, что всегда требуется комплексное решение? )
M>Все это выливается в требования, сформулированные одним из создателей языка, Вирдингом: M>
M>Properties of the Erlang system
M>— Lightweight, massive concurrency
M>— Asynchronous communication
M>— Process isolation
M>— Error handling
M>— Continuous evolution of the system
M>— Soft real-time
M>И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования именно в подходах к многопоточному программированию.
Это как раз и есть твоя основная ошибка. Ты сводишь огромное число разных задач многопоточного программирования к одному очень узкому варианту. И найдя для него неплохо решение, почему-то распространяешь его на всё богатство вариантов многопоточных задач. А это полный бред. К примеру обычному десктопному приложению (1 UI поток и парочка фоновых) или числодробилкам (количество потоков равно числу ядер процессора) твои тысячи лёгких потоков не просто не полезны, а даже вредны — тут могут быть эффективнее даже банальные системные потоки. Т.е. если бы ты проводил все свои утверждения выше для узкой ниши полезного применения Эрланга, то думаю никто и стал бы с тобой спорить. Но ты же замахиваешься на многопоточность вообще (во всех её проявлениях) и соответственно получается что несёшь бред, т.к. тут во многих отдельных нишах не то что другие языки догоняют Эрланг, а как раз наоборот, он во многих случаях будет откровенно плохим решением.
M>Начало любого диалога про Erlang неизбежно скатывается в «я тоже умею делать 100500 потоков, как Erlang, зачем мне Erlang».
Насколько я видел в той темке, твои собеседники как раз утверждали, что в их моделях вообще не используются 100500 потоков, не смотря на то, что современные системы это позволяют (и тут видимо ради шутки было доказательство этого факта). Но ты это как-то постоянно пропускал мимо ушей. )))
M>Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
Так может дело в том, что подобный комплексный подход нужен только в очень узкой нише? )))
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ops, Вы писали:
CC>>Ребе, расслабьтесь, вы в ветке для срачей. Батхёрт тут основной продукт. Ops>Именно что продукт. А на вентилятор нужно нечто другое кидать.
То, что кидают на вентилятор называется "продукт вторичный" а процесс появления вторичного продукта высокой очистки от примесей как правило сопровождается батхёртом.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Понятно, что это относится не только к С++.
В 80-х такие задачи стояли у достаточно небольшого количества компаний.
