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".
Ваш крайне эмоциональный, но содержащий мало технической информации текст, базируется на двух если не 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-а о том, что “отказоустойчивость в случае ошибок (система не должна зависать и падать в принципе)”... Это не поддается цензурному описанию.
Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
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>Последняя попытка. Без надежды на понимание. Убедительная просьба сначала прочитать, а потом отвечать. Хотя лучше не отвечать. «Аргументы» мне давно известны.
А на кой ты начал тред с такого ?
M>К сожалению, множество нечистоплотных людей решило, что они не будут стараться понимать написанное, и приложило множество усилий к тому, чтобы обсуждать все что угодно, только не топик. Оставим это на их совести. В топике было множество попыток от neFormal'а и meadow_meal'а вернуть обсуждение на нужные рельсы. Кто хотел понять, понял. Кто не хотел — на них не обижаются.
У тебя почти весь текст состоит из хамства, намеков на квалификацию и разных провокаций. Как то так.
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
можно сократить без потери смысла:
— в эрланге ты разбираешься только на уровне базвордов
— в остальных системах не разбираешься вообще
в общем, типичный портрет фанатика, который уверен что только apple, linux или что-нибудь ещё решает все мировые проблемы
Люди, я люблю вас! Будьте бдительны!!!
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Твое упорное нежелание понимать, что тебе пишут, просто удивительно. M>У тебя есть конкретные возражения по тому, что я написал? Ну именно возражение, а не битье себя пяткой в грудь в стиле «у меня клиенты создают 100500 потоков без управления».
Я согласен с so5team, он несколько раз опровергал именно что твои тезисы. Есть разные параллельные задачи, которые решаются разными способами. Ты перечислил всякие GUI-потоки, задачи телекома и т.д.
У so5team были конкретные возражения с примерами: OpenMP, например. Что это такое, для чего, как выглядит? Внезапно, этот стандарт поддерживается многими компиляторами из коробки и используется как часть языка (языка, а не в качестве сторонней библиотеки!) для организаций параллельных вычислений. Внезапно может оказаться, что программа на С++, использующая OpenMP, окажется более выразительной, более краткой, более производительной и более надёжной, чем аналог на Эрланге.
Что это за программа? Да те же матричные вычисления на, внезапно, кластере. Или решение систем дифуров. Или даже перебор паролей. Или любая вычислительно тяжёлая задача в пользовательском приложении.
Это тот раздел параллельного программирования, для которого Эрланг не создавался, под который не затачивался, который ты упорно игнорируешь в сообщениях собеседников. В своих тезисах ты описываешь лишь те особенности параллельного программирования, под которые так или иначе заточен Эрланг. А вокруг живёт большой мир со своими задачами и своими потребностями, нельзя просто так взять и отвернуться от него.
Ещё раз: основная критика именно что твоих тезисов заключается в том, что они описывают лишь те задачи и средства их решения, которые есть в Эрланге и которые он способен решать. То есть проблема не столько в тезисах, сколько в их ограниченности.
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, 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>Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
Так может дело в том, что подобный комплексный подход нужен только в очень узкой нише? )))
M>>Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а? I>Может тебе поработать над качеством изложения ? Да и вообще, сложилось ощущение, что для тебя определенные темы в Эрланге — табу.
С качеством изложения у меня все в порядке. Есть одна только мааааааленькая проблема:
К сожалению, множество нечистоплотных людей решило, что они не будут стараться понимать написанное, и приложило множество усилий к тому, чтобы обсуждать все что угодно, только не топик. Оставим это на их совести. В топике было множество попыток от neFormal'а и meadow_meal'а вернуть обсуждение на нужные рельсы. Кто хотел понять, понял. Кто не хотел — на них не обижаются.
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>Впрочем, можно сказать еще пару вещей.
Скипнуто, так как ты приписываешь мне тезисы, которые я не выдвигал. Предлагаю тебе не придумывать за меня то, что я не пишу, а все таки сесть и прочитать, что именно я пишу
Здравствуйте, neFormal, Вы писали:
I>>>>Раньше вообще не знали о программировании и ничего, жили люди. Даже до изобретения колеса тоже как то справлялись. F>>>и что же изменилось к лучшему с новым термином? I>>Разные задачи, что очевидно, решаются по разному. F>поясни же F>параллельные задачи — ... F>конкурентные задачи — ...
В этом и предыдущем топике уже многократно поясняли, причём разные участники. Если на пальцах, то:
* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат, и достигается это путём задействования всех доступных вычислительных ресурсов (грубо говоря всех ядер). Железные потоки/процессы здесь — это необходимость, а не средство упрощения кода. Более того, однопоточный вариант является самым простым, но естественно не задействует все вычислительные ресурсы.
В самом коде обычно нет никакого явного управления потоками и взаимодействия между ними. Всё это прекрасно скрывается внутри библиотек типа TBB, PPL, Thrust и различных реализаций MapReduce — предоставляя пользователю параллельные примитивы типа parallel_transform, parallel_foreach, parallel_for и parallel_reduce.
Конкретный пример — оптимизационная задача: есть набор параметров, ограничения и целевая функция. Необходимо найти значения параметров соответствующие минимуму/максимуму целевой функции. Вычисление значений целевой функции для разных параметров можно выполнять параллельно в разных вычислительных потоках, улучшая утилизацию железа.
* При конкурентом программировании сама задача решается на порядки проще с использованием процессов, нежели без них. То есть процессы здесь это не необходимость, а благо. Причём процессы здесь необязательно железные, даже более того — всё может работать в одном железном потоке.
Каноничный пример: сетевой сервер обслуживающий клиентов проще всего выражается через модель наподобие "один логический поток на одного клиента".
(Вообще говоря и параллельное и конкурентное программирование охватывают бОльшие области чем я описал, но для первого приближения такого описания достаточно)
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Если ты не можешь это понять, то ты не умеешь читать. И понимать. M>Я внятно выразился? С пониманием проблем нет? Если есть, то все, на этом любое обсуждение прекращаем. Если нет, то идем дальше.
Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно.
Что этого нельзя сделать на других языках? Очевидный бред
Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
Истерика вокруг мьютексов вообще непонятна: у каждого инструмента своя область применения, и можно легко представить случаи когда и модель обмена сообщениями, и STM уступят по производительности обычной блокировке настолько, что никакой синтаксический сахар не перевесит выигрыша в скорости.
M>>Твое упорное нежелание понимать, что тебе пишут, просто удивительно. M>>У тебя есть конкретные возражения по тому, что я написал? Ну именно возражение, а не битье себя пяткой в грудь в стиле «у меня клиенты создают 100500 потоков без управления».
N>Я согласен с so5team, он несколько раз опровергал именно что твои тезисы.
Ничего он не опровергал. Он занимался придиркой к частностям, передергиваниями и прыжками с темы на тему.
N>Есть разные параллельные задачи, которые решаются разными способами. Ты перечислил всякие GUI-потоки, задачи телекома и
N>Ещё раз: основная критика именно что твоих тезисов заключается в том, что они описывают лишь те задачи и средства их решения, которые есть в Эрланге и которые он способен решать. То есть проблема не столько в тезисах, сколько в их ограниченности.
Нет. Основная критика выливается в передергивания и уводы темы в сторону. Об этом говорил не только я, если что.
Здравствуйте, Mamut, Вы писали:
M>>>Все просто. Мы запустили поток, нам нужно: M>>>- Знать, что поток выполняется M>>>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой) M>>>- Возможно, перезапустить поток, если он завершился M>>>- Убить поток, если это необходимо Ф>>Зачем всё это? (зачем управлять потоками) M>Тут наш коллега Ikemefula спрашивает, почему я считаю, что люди не читают, что я пишу. Ну а как еще говорить, если пишешь, зачем управлять потоками, и тут же тебя спрашивают: а зачем управлять потоками? M> ... M>Остальное все поскипано, потому что надоело по пятидесятому кругу что-то объяснять людям, которые предпочитают отвечать, не читая и даже не потратив и секунды на размышление.
1. С терпеливостью удава ждём кого-то кто действительно не читал тему
2. Стремительный бросок — "Я же говорил!"
3. Чрезмерное обобщение — "Оппоненты не читают!"
4. ???
5. PROFIT! Demagogy wins!
Re[29]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Сколько бы потоков не создавалось, это все упирается в создание X штук неуправляемых потоков. Повторю еще раз: как тебе понадобится что-то чуть более сложное, ты загнешься.
_>Само собой. Просто в случае малого числа задач, управление этими системными потоками весьма тривиально (собственно просто каждая задача исполняется в своём системном потоке) и соответственно сложная система с кучей оверхеда, предназначенная для работы с тысячами одновременных задач, выглядит в этом случае неуместно.
1. Что там за оверхед, известно только тебе
2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял
M>>>>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере) _>>>Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. ) M>>Это напрямую имеет отношение к написанию софта. Никакой администратор не научит твой openmp находить ноды в сети и запускать код на этих нодах.
_>А причём тут мой код и такое? ) Распространением софта должны заниматься специлизированные инструменты, уже давно написанные и конфигурируемы админами.
Боже. Ты даже не удосужился попытаться понять, что я говорю /o\ Главное поскорее настрочить ответ!!!
_>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях).
«Легко», я так предполагаю.
_>>>Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? ) M>>Возьми структуру данных, в которой реализован доступ по индексу — и вперед
_>Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L.
Действительно, раз нет аргументов, придерись к отдельным кускам кода. Хотя я прямым текстом написал, что в Эрланге не получится сделать точно так же, потому что нет такой же структуры данных. И написал что? Ах, да «предположим, что у нас есть функция get_index». Читать? Понимать написанное? Зачем?!
_>>>Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? ))) M>>Действительно. Широкие выводы из умению развернуть цикл в параллельный fold/map.
_>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование.
Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
M>И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка. Смешной момент: всякие лямбды, замыкания и прочая функциональщина прекрасно себе решались Boost'ом, но появление всего этого в С++11 было воспринято просто на ура. Но когда заходит речь о многопоточности, например, внезапно общее отношение кажется таким: все решается библиотеками легко и просто нафига это на уровне языка? Понятно, что это относится не только к С++.
Лямбды в бусте были на основе expression templates, они были малоюзабельны, поэтому их появление в стандарте и восприняли с энтузиазмом. Появление всего остального, в том числе и тредов с мьютексами было воспринято с этузиазмом тупо потому что теперь не нужно тащить буст в виде зависимости. Появление атомиков было воспринято с энтузиазмом потому что даже в бусте их не было. Точнее было в details пространстве имен в библиотеке boost.interprocess и все. Бустовские потоки люди продолжают использовать просто потому что там больше возможностей есть.
M>- С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures.
Во первых, futures вполне себе равноценны (если они конечно композируются как надо). На мой взгляд это очень клевая абстракция, она может объединять параллельные вычисления и всякие асинхронные api. В общем, попробуй докажи сначала что furures это что-то плохое.
M>Еще раз повторю. State-of-the-art для практически любого современного языка программирования является: создание OC-потоков и процессов, общение между потоками через разделяемую память, мьютексы. Буквально единицы представляют еще и асинхронные вызовы через futures/promises, но и они обычно являются отдельным потоком/процессом в ОСи с общением через разделяемую память.
Выделенное — очень спорно, требует пояснения или доказательства. State of the art в этой области (С++ и многопоточность) это язык Cilk++ а вовсе не новый стандарт С++. Ну и ты тут про concurrency в основном говоришь, но ведь еще есть параллельность, векторизация. Я могу на С++ написать простой цикл обсчитывающий массив, компилятор его векторизует и он будет работать как целый erlang кластер а еще я могу директивы OpenMP для data parallel вычислений расставить и все будет еще лучше, без всяких mutex.lock (которые тебя так пугают).
M>Еще раз для тех, кто в наглухо запаянном танке: это — state-of-the-art, кодифицированный в стандартах языка и его стандартных библиотеках. О third-party библиотеках я еще не начал говорить.
Это очень спорно, в стандарты обычно включают как раз наоборот, очень старые и всем понятные вещи (мьютексы потоки), а сомнительные вещи не включают (зеленые потоки, акторы и все такое).
M>Если у тебя однопоточное приложение — проходим мимо. Как только потоков становится N > 1, все становится очень печально (в большинстве языков). Потому что потоками надо управлять и потокам надо общаться друг с другом.
State of the art как раз в том, чтобы потокам как раз как можно меньше общаться друг с другом.
M>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов. Вплоть до смешного:
M>
M>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).
Во первых, ты наверное понимаешь почему в ерланге можно остановить процесс. Потому что он исполняет байткод, поэтому VM может проверить — не нужно ли остановить поток и, собственно остановить его. С++ приложение как правило компилируется в нативный код, который нельзя так просто остановить. Есть ОС вызов для того, чтобы убить поток, но вот штука в том, что в документации _ОС_ сказано что его нельзя использовать практически никогда. Тем не менее потоки останавливать можно даже в С++, в boost.thread есть ф-я interrupt, она позволяет прервать выполнение потока. Поток прерывается не в любом месте а в одной из interruption-points (многие вызовы из boost.thread являются interruption points, также их можно вручную расставлять). Можно прервать поток в любом месте, но в этом случае поток не должен выделять память, пользоваться большинством системных вызовов и общаться с внешним миром он должен только через lock-free структуры данных. В этом случае поток можно прибить через TerminateThread. Я точно знаю что такой подход исползовался в одном из известных антивирусов для запуска файловых сканеров, файл скармливался такому потоку через lock free очередь, при этом если сканер работал слишком долго можно было сделать terminate thread и продолжить работу.
В общем, тормознутый байткод можно легко остановить (js в бразуере или VM ерлагна), с нативным кодом все сложнее, это плата за эффективность.
M>В 1993-м году заведующий этой лабораторией Bjarne Däcker сформулировал накопившийся опыт построения телекоммуникационных систем так (цитирую по DÄ2000):
M>
M>1. The system must be able to handle very large numbers of concurrent activities.
M>2. Actions must be performed at a certain point in time or within a certain time.
M>3. Systems may be distributed over several computers.
M>4. The system is used to control hardware.
M>5. The software systems are very large.
M>6. The system exhibits complex functionality such as, feature interaction.
M>7. The systems should be in continuous operation for many years.
M>8. Software maintenance (reconfiguration, etc) should be performed without stopping the system.
M>9. There are stringent quality, and reliability requirements.
M>10. Fault tolerance both to hardware failures, and software errors, must be provided.
M>(tl;dr по списку: люди, которые говорят, что это — маркетинг буллшит просто не имеют ни малейшего понятия, что они несут)
Это я говорил, ну вот например что можно сказать про №5 или про №7? Можно сказать "спасибо кэп", может в 93-м это было чем-то новым, но вот сейчас это все является нормой жизни для любого софтверного проекта. №3 — several computers Крал! Я тебе в той ветке пытался показать что в реальных системах люди без ерланга это все решают, но выяснилось что я читать не умею.
M>По внятности всех размалывает Erlang. Потому что он из коробки предоставляет удобные, мощные, единообразные и предсказуемые инструменты для создания многопоточных приложений. Не удивительно, что эти инструменты медленно, но верно проникают в другие языки и библиотеки других языков. Потому что многопоточность и распределенность — это не сказки для подрастающего поколения времен DOS'а, а суровая реальность, и с убогими thread.create и mutex.lock в ней не выжить. Но еще некоторое время себя можно обманывать, что «подходы Erlang'а не нужны» и т.п. neFormal все парвильно сказал достаточно рано во всей этой дискуссии
Все эти "суровые распределенные системы" вообще не про языки программирования вообще ни разу.
Все эти сложности, которые исправляли создатели erlang-а в реальных системах чаще всего не встречаются — сложная распределенная система? Можно наплодить процессов общающихся друг с другом, а можно все сделать вокруг share nothing архитектуры написав однопоточные сервисы не общающиеся друг с другом вообще никак (привет 99% веба). Нужна горячая замена кода? Пишем скрипт для выливки (pupet, ansible) выводящий сервисы из балансировки, деплоящий код и рестартующий их по одному. Отказы оборудования — пишем репликацию одинаково на любом языке (chain replication, state machine replication и тд). Ну ты понял в общем.
Re[2]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Somescout, Вы писали:
S>>Скажите, а в чём был смысл этого сообщения? F>ещё раз мокнуть so5team
Типа может в этот раз да и получится? В предыдущей теме сообщения so5team единственное что было интересно читать.
S>>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга). F>видимо, надо попробовать устрицу, чтобы не спорить о вкусе, зная лишь вкус картошки.
Вы сравниваете Эрланг со склизкой гадостью, способной вызвать смертельное отравление?
ARI ARI ARI... Arrivederci!
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>- С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures.
Дальше можно не читать. Идеология языка С++ — необходимый минимум, всё остальное реализовывается сторонними библиотеками. И даже std::thread это всего лишь часть библиотеки stl без которой жили 20 лет. Сторонних
библиотек с самыми разными идеологиями многопоточности вагон и маленькая тележка, от студенческих поделок до гигантов индустрии типа Mictosoft или Intel.
M>- C#? Objective-C? Ruby? Php бггг? кто там еще есть в индексе? Все то же самое и одно и то же.
А это ещё один шедевр. Ну к примеру в C# уже давно ни кто не использует Thread, ибо есть целая кучам
современных механизмов для реализации монопольности. Только вы почему-то об этом всём ни чего не знаете.
Лучше бы почитали какую-нибудь книжку по C# чем графоманить такой большой и глупый пост.
Здравствуйте, Mamut, Вы писали:
M>С качеством изложения у меня все в порядке.
Нет. Это объективный наблюдаемый факт. Дискуссии ты ведешь плохо, потому что не утруждаешь себя тщательной проработкой ответов оппонентам. Это создает ощущение неуважения, даже если у тебя этого и не было в намерениях. Поэтому либо научись работать над собой, либо не участвуй в подобных дискуссиях вообще.
Я, конечно, понимаю, что уровень дискуссий в СВ обычно низок, и прорабатывать ответы тамошним оппонентам — это зачастую "метать бисер перед свиньями". Однако слишком активное участие в СВ, очевидно, расслабляет, и тебя заносит в общении со значительно более вменяемыми оппонентами. Именно об этом тебе и пытаются сказать. На твоем месте я бы прислушался.
Здравствуйте, alex_public, Вы писали:
_>Ну даже если мы сумеем сделать их маленькими (в Эрланге кстати не выйдет, но в некоторых других платформах можно попробовать), то остаётся ключевой вопрос — а зачем нам все эти мучения то? ))) Ведь никаких преимуществ то относительно пула системных потоков нам это не даст.
учитывая, что пул системных потоков — это и есть способ реализации лёгких потоков, ответ я думаю очевиден — в эрданге ты получаешь иллюзию множества обычных потоков, а в твоём варианте — спецбиблиотеку, работающую только с этим пулом. т.е. универсальность меньше, а проихводительность ровно такая же
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, so5team, Вы писали:
S>Задачи решаются посредством инструментов. Поэтому таск в Ada может быть использован как для реализации параллельности, так и для реализации конкурентности.
у меня есть мысль, что конкурекнтность — это свойство кода, а параллельность — это свойство реализации. поэтому любые языковые средства реализуют только конкурентность, а уж то что их можно использовать для параллельности — это свойство реализации. в частности, банального наличия в машине >1 ядра
даже банальное создание потоков не является средством параллельности в win95
Люди, я люблю вас! Будьте бдительны!!!
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Философ, Вы писали:
BZ>>при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков
Ф>Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться: Ф>[q] Ф>Я с многопоточностью воюю уже лет семь, наверное. Ф>Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
я в своё время недоумённо спрашивал, откуда у вас, сишников, проблемы многопоточности — на хаскеле их у меня не было. при message passing approach ошибки синхронизации просто отсутствуют. на самом деле в реальной программе у меня есть несколько раздляемых ресурсов, но их так мало, что контролировать несложно. скажем, обращение к выходному файлу я просто обернул в мьютекс и потому разные потоки в принципе не могут его делать одновременно
сейчас я пишу на С++, ошибки есть, и мне интересно попробовать TBB чтобы всё делалось через него — общение между задачами, их убийство
Ф>Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой
напоминает мне дидактическую историю о чуваках, которые пошли в кафе, напились до хрюканья и покалечились в драке. теперь они приняли меры — не ходят в кафе
у тебя проблемы с синхронизацией, так попробуй использовать m.p. вместо неё
Ф>Ты здесь предлагаешь почти тоже самое, ибо вынесение всей конкуренции в один "синхронизирующий" поток — фактический отказ от многопоточности. Может лучше вообще не заморачиваться, а?
о нет, речь у меня во-первых, о выносе разделяемых данных (а не всей конкуренции), а во-вторых, в структурно убиваемые потоки (а не один поток). т.е. поток, который работает только с локальными данными и messages, можно убивать прямо средствами ОС. и наоборот — если реализовать механизм работы с сообщениями, который я описал, то поток может спокойно работать с разделяемыми данными
Ф>Понимаешь, если совсем нет связи по данным, то незачем связываться с многопоточностью: вполне можно обойтись многопроцессностью, а для надёжности код на разных машинах выполнять.
связь по данным есть — скажем один поток читает данные, другой считает хеш, третий сжимает и четвёртый записывает. фишка в том, что между потоками передаётся только указатель на буфер. при этом в каждый момент времени буфером владеет/пользуется один-единственный поток. вот так — глобальные данные есть, а разделяемых — нет
что касается выноса задач в процессы ОС, то ради бога. по сути это и есть эмуляция process isolation & control из erlang
Люди, я люблю вас! Будьте бдительны!!!
Re[46]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Насколько я вижу, динамическая типизация тут ни при чём, это реализуется и в статической.
в статике сложнее сопоставить туплы, которые в эрланге повсюду. плюс вложенность.
в статике одна ф-ция с кучей разномастных по типам реализаций расползётся куда сильнее. а в динамике достаточно соблюдать арность ф-ции.
вдобавок без типов код пишется на порядок быстрее. в том же хаскеле или скалке подгон типов под решение занимает кучу времени.
EP>Кстати, а насколько оправданны сообщения со стёртыми типами? Не лучше ли будет статическое описание возможных типов сообщений для процесса а-ля variant?
большинство сообщений уникальны. плодить для них одноразовые типы — это лишняя работа. поэтому даже местные структуры используются в основном для состояний.
но поскольку куча народу полагается на типизацию, то там есть свои сигнатуры, которые обрабатываются редактором и статическим анализатором.
по мне лучше тесты. правда в эрланге с ними очень плохо, потому что поднимать всё дерево процессов долго и неудобно.
...coding for chaos...
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>можешь не капитанить. я трогал и системные потоки тоже. F>я бы даже не сказал, что расходы какие-то фатальные до определённой границы.
Согласен. Как раз поэтому в большинстве случаев лёгкие потоки не нужны. Границу легко увидеть если посмотреть на графики нагрузки для Apache vs Nginx.
_>>У лёгкие потоков мы имеем маленькие накладные расходы на создание и переключение и ненулевые (а в случае Эрланга особенно) на исполнение. F>а тут ты опять сравниваешь скорость рантайма. F>эрланг тормозной, это все знают. и шедулинг там не самая большая проблема. основные вещи там реализованы низкоуровнево.
Да не в быстродействие языка дело. Даже если мы напишем это всё на C++, то оно всё равно будет уступать на числодробилке тупому пулу системных потоков, потому как будет исполнять ненужный код.
F>а что на плюсах есть хорошего для акторов?
Ну например http://www.theron-library.com или более новый http://actor-framework.org. Ещё слышал про http://sourceforge.net/projects/sobjectizer/ и https://github.com/gridem/Synca (от яндекса, но недоделанный). Это всё для обобщённого случая. А для самых простых можно вообще обойтись системными потоками с очередями.)))
_>>P.S. Кстати, лично мне как раз больше всего нравится именно модель акторов — я стараюсь именно её применять везде. Только вот на C++. И с системными и с лёгкими потоками, в зависимости от задачи. F>там обычно даже достаточно простой очереди сообщений, чтобы избежать усложнения изза блокировок. F>ну и культуры кода, чтобы соблюдать соглашения.
Да да, о том и речь. )
Re[2]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
С>А можете Akka покритиковать?
К сожалению, не смогу Я ее трогал пальцем очень давно, практически, когда они только начинались. Но, имхо, они молодцы. Они как раз стараются решить проблему комплексно — от создания потоков до управления ими и т.п.
Плюс они пошли дальше, чем тот же Erlang. Например, некоторых из их утилит нет в Erlang'е в стандартной поставке (типа CircuitBreaker). Я, единственное, помню, что они таки наткнулись на ограничения JVM, но, к сожалению, не вспомню, где я это читал.
В общем, из всех библиотек, Akka, имхо, пример того, как делать надо (как минимум в плане подхода к решению проблем. В реальности она вполне может оказаться монструозной бякой )
Здравствуйте, neFormal, Вы писали:
EP>>Если бы "параллельный" код исполнялся в одном потоке — то не было бы никакого смысла распараллеливать однопоточный — это сложнее и дороже в любом случае (как минимум нужно подключить параллельную библиотеку, добавить опции компилятора, изменить код (иногда изменения минимальны, иногда увы нет) и т.п.). F>поддержу AlexRK. F>всё, что ты перечислил — это нюансы технологии. F>весь вопрос в том, от чего ты строишь решение: от организации кода или от железа.
https://en.wikipedia.org/wiki/Concurrent_computing
Concurrent computing is related to but distinct from parallel computing, though these concepts are frequently confused,[2][3] and both can be described as "multiple processes executing during the same period of time". In parallel computing, execution literally occurs at the same instant, for example on separate processors of a multi-processor machine, with the goal of speeding up computations – parallel computing is impossible on a (single-core) single processor, as only one computation can occur at any instant (during any single clock cycle).[a] By contrast, concurrent computing consists of process lifetimes overlapping, but execution need not happen at the same instant. The goal here is to model processes in the outside world that happen concurrently, such as multiple clients accessing a server at the same time. Structuring software systems as composed of multiple concurrent, communicating parts can be useful for tackling complexity, regardless of whether the parts can be executed in parallel.[4]:1
For example, concurrent processes can be executed on a single core by interleaving the execution steps of each process via time slices: only one process runs at a time, and if it does not complete during its time slice, it is paused, another process begins or resumes, and then later the original process is resumed. In this way multiple processes are part-way through execution at a single instant, but only one process is being executed at that instant.
Concurrent computations may be executed in parallel,[2][5] for example by assigning each process to a separate processor or processor core, or distributing a computation across a network, but in general, the languages, tools and techniques for parallel programming may not be suitable for concurrent programming, and vice versa.
https://en.wikipedia.org/wiki/Parallel_computing
Parallel computing is closely related to concurrent computing – they are frequently used together, and often conflated, though the two are distinct: it is possible to have parallelism without concurrency (such as bit-level parallelism), and concurrency without parallelism (such as multitasking by time-sharing on a single-core CPU).[5][6] In parallel computing, a computational task is typically broken down in several, often many, very similar subtasks that can be processed independently and whose results are combined afterwards, upon completion. In contrast, in concurrent computing, the various processes often do not address related tasks; when they do, as is typical in distributed computing, the separate tasks may have a varied nature and often require some inter-process communication during execution.
Здравствуйте, Пацак, Вы писали:
П>Интереснее было бы, если бы каждый процесс получал некоторые данные извне (можно эмулировать через ГСЧ для простоты), анализировал их и в зависимости от результата решал, что ему делать дальше: П>- завершиться штатно П>- сдохнуть аварийно П>- запустить N дочерних процессов и опрашивать их при дальнейшем анализе П>- притормозить на время и известить об этом родителя П>- грохнуть принудительно всех детей П>- и т.п.
П>Я ж так понимаю Мамут в своих спичах делает упор на легкость именно управления процессами, а не тупо их создания в количестве "дофига штук". А легкость управления лучше всего проверяется его многообразием.
Фокус в том, что реализации actor model для других языков уже предоставляют готовые инструменты для этого (в Akka и C++ Actor Framework чуть ли не 1-в-1 слизано из Erlang-а, в SObjectizer чуть-чуть иначе, собственно, вот пример). Только это не является частью языка, а сделано в виде библиотек. Потому и игнорируется Mamut-ом.
Здравствуйте, Somescout, Вы писали:
S>Скажите, а в чём был смысл этого сообщения?
ещё раз мокнуть so5team
S>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
видимо, надо попробовать устрицу, чтобы не спорить о вкусе, зная лишь вкус картошки.
...coding for chaos...
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Ты прикопался к Эрлангу, потом прикапывался к отдельным пунктам, занимался передергиванием и сменой тем на ровном месте
На этом месте остается только посоветовать вам перечитать то, что вам писали. Как в этой теме, так и в предыдущих. Вы явно ничего не поняли. А если помножить это еще и узость кругозора
, то смысла общаться с вами на темы concurrency и parallel computing нет вообще.
M>Но почему-то эти 20 лет (в том числе) называются «и достигнуто это совсем не такими титаническими усилиями, о которых вы упорно говорите»
Я очень сильно удивлюсь, если выяснится, что все вложенные в разработку SObjectizer-а усилия составляют хотя бы целые проценты от того, что Ericsson вложил в Erlang в 1980-х и 1990-х. Скорее речь будет идти о долях процентов. Это не может быть титаническими усилиями в принципе.
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ops, Вы писали:
CC>>Ребе, расслабьтесь, вы в ветке для срачей. Батхёрт тут основной продукт. Ops>Именно что продукт. А на вентилятор нужно нечто другое кидать.
То, что кидают на вентилятор называется "продукт вторичный" а процесс появления вторичного продукта высокой очистки от примесей как правило сопровождается батхёртом.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Nuzhny, Вы писали:
N> Что это за программа? Да те же матричные вычисления на, внезапно, кластере. Или решение систем дифуров. Или даже перебор паролей. Или любая вычислительно тяжёлая задача в пользовательском приложении.
AFAIK, на кластере используются связки из OpenMP (для распараллеливания внутри одной ноды) и MPI (распараллеливание между нодами).
N>Это тот раздел параллельного программирования, для которого Эрланг не создавался, под который не затачивался, который ты упорно игнорируешь в сообщениях собеседников. В своих тезисах ты описываешь лишь те особенности параллельного программирования, под которые так или иначе заточен Эрланг. А вокруг живёт большой мир со своими задачами и своими потребностями, нельзя просто так взять и отвернуться от него.
Кстати говоря, вот еще один совсем свежий пример от NVidia по задействованию мощностей современных GPU: MapD. Что, очевидно, так же находится совсем в другой стороне от тех областей, для которых предназначался как сам Erlang, так и actor model, на базе которой Erlang и построен.
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Что такое управлять потоками?
M>Все просто. Мы запустили поток, нам нужно: M>- Знать, что поток выполняется M>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой) M>- Возможно, перезапустить поток, если он завершился M>- Убить поток, если это необходимо
Зачем всё это? (зачем управлять потоками)
Почему нельзя положиться на рантайм — пусть он управляет. Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.
Что за глупость убивать поток?
Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?
M>Что такое общаться друг с другом?
M>Все просто. Часто одному потоку надо знать о промежуточном состоянии другого потока или передать в другой поток какое-то свое промежуточное состояние. Как простейшие примеры: M>- UI поток должен узнать, что что-то изменилось в долгоиграющем потоке, чтобы обновить свое состояние (прогрессбар, например) M>- Долгоиграющий поток должен узнать, что что-то изменилось в окружающем мире, чтобы продолжить работу (появились новые данные, изменилась конфигурация и т.п.)
Не вижу здесь никакой проблемы: пусть UI узнает. Надо чтоб узнал — сообщи ему об этом, или пусть сам спросит, только не у потока, а у объекта, который ему предоставит Task<T>.Result .
Долгоиграющий поток????
Зачем такое что он делает: ждёт всю дорогу или что-то делает? Если он чего-то ждёт всю дорогу — то чего-нибудь дождётся, если что-то делает, то обрывать его плохая идея — пусть делает, и когда будет готов, то сам проверит.
M>
M>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).
И слава богу!
Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
M>Потому что даже фраза «потоки могут общаться друг с другом» являются китайской грамотой для языков, в которых while(shared_variable != true) execute() является единственным способом общения между потоками
Я, кстати, тоже не совсем понимаю что такое общение между потоками. Пояснишь?
Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
M>Механизмы и инструменты которые Erlang предоставляет из коробки, выросли напрямую из необходимости соответствовать этим требованиям. По некоторым пунктам: M>1. Требует возможность создать множество параллельных процессов, которыми надо управлять, и которым надо общаться между собой. M>2. Требует гарантий на время отклика системы M>3. Требует механизмов для распределения системы по нескольким компьютером, что тянет за собой множество требований. Например, если умерла система X, система Y должна иметь возможность гарантированно об этом узнать M>5. Нужны из коробки механизмы управления крупными системами (в случае с Эрлангом — управления множеством процессов) M>8. Нужно иметь возможность обновить систему, не останавливая ее, что тянет за собой множество требований: как заставить долгоживушие процессы обновить код, что делать со stale code в памяти, как производить апгрейд структур в памяти и т.п. M>10. В частности: если процесс умирает, он не должен утянуть за собой всю систему. Если процесс умер на машине X, об этом надо гарантированно узнать на машине Y и т.п.
Ты заешь что такое PAGE_FAULT?
Это то, от чего ты не можешь избавиться и то, что лишает тебя любых гарантий на время отклика системы.
В связи с этим, расскажи мне, как Erlang это гарантирует — не верю.
По остальным пунктам тоже комментарии не помешали бы.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Зачем всё это? (зачем управлять потоками)
а почему бы и нет?
Ф>Почему нельзя положиться на рантайм — пусть он управляет. Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.
плюсопроблемы.
Ф>Что за глупость убивать поток? Ф>Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток?
ПА-НИ-КО-ВАТЬ! ААА!
Ф>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам.
но это же проблема реализации, а не идеи
Ф>Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
ну да, всё верно.
если технология не позволяет освобождать внешние связи, то всё плохо.
Ф>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности.
а чем идея плоха?
...coding for chaos...
Re[8]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>>>Раньше вообще не знали о программировании и ничего, жили люди. Даже до изобретения колеса тоже как то справлялись. F>>и что же изменилось к лучшему с новым термином? I>Разные задачи, что очевидно, решаются по разному.
поясни же
параллельные задачи — ...
конкурентные задачи — ...
I>"потоками надо управлять и потокам надо общаться друг с другом" — в каждом из случаев это делается по разному. Мамут вещает ровно про один, только нигде про это явно не говорит.
я всё ещё не понимаю принципиальной разницы.
I>Диссонанс какой то. Что бы сравнивать и утверждать "там ничего нет", надо бы ознакомиться что же "там".
это да.
...coding for chaos...
Re[10]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат EP>* При конкурентом программировании сама задача решается на порядки проще
т.е. разница лишь в количестве потоков относительно процессоров и нагрузке на каждый поток.
негусто, если честно.
...coding for chaos...
Re[11]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат EP>>* При конкурентом программировании сама задача решается на порядки проще
F>т.е. разница лишь в количестве потоков относительно процессоров и нагрузке на каждый поток.
разница в целях. при параллельном программировании целью является более быстрая программа чем однопоточная. поэтому интерпретаторы здесь не канают, и поэтому эрланга нету на gpu, и его smp вариант появился не сразу (или до сих пор не появился?)
в конк. пр. быстродействие олднопоточного варианта нас вполне устроит, задача состоит в упрощении описания алгоритма. поэтому лучшим средством здесь яляются сопрограммы, выполняемые в рамках одного потока ОС — либо изолированные процессы с обменом сообщениями
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>разница в целях. при параллельном программировании целью является более быстрая программа чем однопоточная. поэтому интерпретаторы здесь не канают, и поэтому эрланга нету на gpu,
да это понятно. просто терминология не очень.
как будто конкурентность должна быть без параллельности.
а по сути одно является подмножеством другого. что-то навроде наследования между квадратом и прямоугольником.
BZ>и его smp вариант появился не сразу (или до сих пор не появился?)
давно существует.
...coding for chaos...
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Философ, Вы писали:
Ф>Всё было бы просто, если бы задачи были совсем независимы, по данным, но это не про реальную жизнь: в реальной жизни независимых задач крайне мало, и с ними всё решается достаточно просто, например, с помощью Parallel.ForEach(), который в составе параметров принимает в том числе и CancellationToken.
Ф>Повторюсь: убивать поток — плохая идея. Даже с процессом может плохо получиться: Ф> при грубом завершении потока тебе нужно как минимум файлы закрыть (и, кстати, закрывать ли — тот ещё вопрос), а ещё лучше — объекты синхронизации в правильное состояние вернуть — вот это уже совсем не простая задача, которая в общем случае не решается.
Ф>Для прекращения выполнения кода существуют другие методы. Самый удачный, на мой взгляд — реакция самой задачи на CancellationToken.
Ф>Может быть ты знаешь какую-то магию, которую я не знаю в этой области? Как эта проблема решается в Erlang'е?
потоки должны быть изолированы по данным. в true FP языках с их once-assign это решается автоматически, в других — при минимальных усилиях со стороны программиста
правда, есть ещё всякие memory buffers & files, они могут либо принадлежать специальному потоку, тогда алгоритм выглядит так — убиваем использующие их потоки, затем даём ему команду освободить ресурсы; либо поток должен завершаться структурированно и тогда их можно как обычно освободить обычным деструктором в потоке-владельце
далее, поток можно убить либо низкоуровнево — просто перестать отдавать ему тайм-слайсы, либо структурированно — возбудить в нём исключение. в эрланге и других интерпретаторах можно просто вставить проверку в цикл интерпретации, когда система находится в заведомо консистентном состоянии. в ghc, нативном компиляторе — в момент выделения памяти, благо что в once-assign languages она распределяется постоянно. в результате этой проверки в ghc возбуждается асинхронное исключение, которое дальше обрабатывается обычным структурированным образом
при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков
наконец, в С++ можно структурированно убивать потоки, возложив весь message passing между ними на специально написанную библиотеку, такую как tbb/ppl. в ней GetMessage()/PutMessage() должен просто возбуждать исключение при необходимости убийства потока, таким образом любые проблемы в других потоках не отразятся на нашем — он просто доработает до очередной точки синхронизации самостоятельно и дальше умрёт если что-то у соседей пошло не так. я сейчас использую такой подход (правда с своей реализацией вместо tbb/ppl) и вроде всё работает
Люди, я люблю вас! Будьте бдительны!!!
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
F>>за исключением проблемы с локами. EL>А что еще за проблема с локами? Может кто-то просто не умеет ими пользоваться?
это проблема технологии в конце концов
...coding for chaos...
Re[13]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>во-первых, создание потоков ОС ничем не отличается в плане парадигмы программирования от создания потоков рантайма, рахница только в эффективности.
и поэтому используются разные подходы.
вплоть до того, что кому-то удаление потоков ОС будет казаться преступлением.
BZ>во-вторых, основная проблема в CP — не создание потоков, а коммуникация между ними, и тут с 60-х годов придумано безумное число идей. CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам эрланг)
да, но большое количество старых идей сейчас достаётся из истории и начинает применяться.
поэтому я сторонник разделения oldschool/newwave по использованию широкими массами кодеров.
BZ>мне кажется, лучше делить подходы на shared memory/messaging
тоже вариант
...coding for chaos...
Re[11]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат EP>>* При конкурентом программировании сама задача решается на порядки проще F>т.е. разница лишь в количестве потоков относительно процессоров и нагрузке на каждый поток. F>негусто, если честно.
Эта самая разница в количестве кардинально меняет ситуацию. К примеру если взять те же самые лёгкие потоки (все их разновидности) — откуда по твоему берётся их преимущество перед системными? Очевидно из-за отсутствия огромных накладных расходов. Однако это актуально только для задач с тысячами короткоживущих потоков (высоконагруженными серверами и т.п.). А скажем для случая числодробилок (где число потоков равно числу ядер на машине) подобных накладных расходов нет вообще, т.е. системные потоки тут отлично подходят. В то время как Эрланг (в котором у нас только лёгкие потоки) наоборот будет вносить накладные расходы за счёт своего планировщика и ещё кучи всякой мишуры.
Так что казалось бы всего лишь количественная разница вносит вполне себе качественные различия. И соответственно в разных случаях надо применять разные инструменты. С тем же C++ это кстати совсем не проблема, т.к. там это всё реализовано в виде библиотек — просто выбираем нужную. А вот в случае попытки применения Эрланга где-то за пределами его узкой ниши мы получим множество неудобств.
Re[12]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Эта самая разница в количестве кардинально меняет ситуацию.
оно только может поменять часть требований.
при чём ключевое слово "может", а не "поменять".
_>К примеру если взять те же самые лёгкие потоки (все их разновидности) — откуда по твоему берётся их преимущество перед системными? Очевидно из-за отсутствия огромных накладных расходов. _>А скажем для случая числодробилок (где число потоков равно числу ядер на машине) подобных накладных расходов нет вообще
и расходов тоже нету, и накладок тоже нету...
в смысле, слова не пропускай. а то ни там, ни там нет никаких затрат.
_>Так что казалось бы всего лишь количественная разница вносит вполне себе качественные различия.
ты смешиваешь скорость рантайма с количеством потоков.
это ошибочно.
_>И соответственно в разных случаях надо применять разные инструменты. С тем же C++ это кстати совсем не проблема, т.к. там это всё реализовано в виде библиотек — просто выбираем нужную.
ха-ха
_>А вот в случае попытки применения Эрланга где-то за пределами его узкой ниши мы получим множество неудобств.
ха-ха
...coding for chaos...
Re: Эрланг и все-все-все (на самом деле, не совсем)
Обожаю сравнения языков с нулем строчек реального кода на паре этих языков и роликом с youtube. По теме — не увидел ничего, что не решалось бы тасками с Rx в шарпе, остальными языками не пользуюсь уже давно. Общение между компами интересно, но без примеров это выглядит всемогутором который хрен знает как внутри работает, давным давно есть очереди сообщений на любой вкус и цвет. Не падать от неучтенных ошибок — да не горит в общем то, чуть больше руками накодить catch->log. Immutable везде — нафиг нафиг все эти теоретизации. Какие задачи невозможно (сложнее на порядок) решить на шарпе, чем на эрланге? Примеры, нужно больше примеров=)
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++. И с системными и с лёгкими потоками, в зависимости от задачи.
Ну то есть все остальное приходится закатывать вручную — изоляцию потоков, разделение данных, управление потоками и т.п. Ты смотри. Как раз то, о чем я говорил в изначальном сообщении
Здравствуйте, alex_public, Вы писали:
_>Нуу так тут получается, что собственно SMP вообще ни при чём.
если используется шедулер лёгких потоков и он не занимается балансировкой, то накладные расходы на балансировку становятся незаметными.
smp здесь в качестве примера того, что несколько шедулеров по количеству ядер не будут заниматься балансировкой, а, значит, и не будут тратить ресурсы.
F>>вообще нет. у меня вот долгие прямые коннекты, кастомный протокол и лёгкие эрланговские треды. F>>и высокая нагруженность достигается лишь активностью юзеров. _>Так это всё равно получается высоконагруженный сервер) Тут Эрланг действительно подходит. Как впрочем и многие другие языки. )
на эрланге это получается заметно проще. относительно плюсов, я бы сказал, на порядок, а то и два.
это заслуга как языка, так и модели использования потоков.
если не ставить целью сделать максимально(именно "максимально") эффективный относительно ресурсов сервер, то эрланг — хороший выбор.
...coding for chaos...
Re[20]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
Ф>>>>Зачем всё это? (зачем управлять потоками) Ф>>>>Почему нельзя положиться на рантайм — пусть он управляет.
M>>>Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.
Ф>>Объясни рантайму, что ты хочешь.
M>О. Внезапно. То есть уже надо управлять потоками.
Задачи и потоки — разные вещи. Как бы то ни было, но задачу ты каким-либо образом определяешь. Даже просто написав функции, и упорядочив их исполнение, ты определил задачи и связь между ними. При таком же подходе, у тебя задачи становятся чем-то весомым, осязаемы, тем, ты можешь манипулировать в процессе исполнения. При желании, их можно на экране отобразить, например затем, чтобы смотреть на скорость создания/завершения.
Потоки это не задачи, это то, что задачи исполняет.
Определять задачи и "управлять" ими я вижу необходимость, рулить потоками — нет.
Ф>>Хочешь ты наверняка не потоками управлять, а задачу (в фоне) выполнить. Так и создавай задачу, например вот так: Ф>>Задача — это не поток, задача может использовать отдельный поток, но не обязательно. Задачи ты можешь комбинировать (сцеплять, задавать зависимости между ними), отменять отдельные задачи — совершенно другой уровень.
M>Каким образом это я буду делать, если мне ни язык ни библиотеки не предоставляют никакой возможности это делат, кроме как устраивать закаты вручную?
Например с помощью TPL, которая входит в B ase C lass L ibrary.
Ф>>Повторюсь: убивать поток — плохая идея. Ф>>Для прекращения выполнения кода существуют другие методы. Самый удачный, на мой взгляд — реакция самой задачи на CancellationToken.
Ф>>Может быть ты знаешь какую-то магию, которую я не знаю в этой области? Как эта проблема решается в Erlang'е?
M>В Эрланге это решается шатными средствами: в любой поток(он же процесс он же задача) можно послать сообщение, которое поток/задача/процесс может обработать и завершиться штатными средствами.
гм...
с моей точки зрения это ничем не отличается от упомянутого ранее CancellationToken'а: когда задача становится способной обработать завершение, то в зависимости от ситуации, может быть брошено исключение (если выставлен ThrowIfCancellationRequested), либо она сама прочитает IsCancellationRequested и штатно завершиться. Тут я тоже вижу штатное завершение — никак не TerminateThread, и не Thread.Abort
Всё сказанное выше — личное мнение, если не указано обратное.
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>неправда.
Не думаю.
BZ>короутины, futures, message passing, вообще все средства конкурентного программирования используются и в параллельных задачах тоже
Если опуститься еще на уровень ниже, то окажется, что futures/promises, message passing и даже stm, реализуется посредством низкоуровневых примитивов синхронизации вроде атомиков, критических секций, семафоров, мутексов, событий, кондишенов и т.д.
Имеет ли смысл инструментарий относить к конкретному классу задач?
BZ>т.е. конкурентные срежства программирования, такие как те же короутины — это механизм, урощающий описание некоторых алгоритмов. параллеьбность — это когда у нас есть посолеждовательный алгоритм, колтрый мы зотели бы раскидать на несколько ядер. в идеале компилятор должен брать последовательный алгоритм и раскидывать его сам, а на практике программисту чаще всего приходится помогать, используя эти средства конкурентного программирования. но в отличие от чистого конкурентного программирования для нас в этом слусчае важно что реализация этих средств умеет работать на >1 ядре
Не вижу противоречий. Parallel computing и concurrent computing -- это разные типы задач. В реализации которых используется один и тот же набор базовых механизмов. Набор этот зачастую именуют concurrency, что создает дополнительную путаницу.
Посему, возвращаясь к вопросу AlexRK "Вот таски в Ada — это средства для параллелизма или конкурентности?" получается, что сам по себе таск в Ada -- это один из набора механизмов для обеспечения concurrency. Но вот будет ли таск использован для решения задачи из категории parallel computing или из категории concurrent computing -- зависит уже от конкретного прикладного кода.
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
такой же, если берётся сторонняя библиотека/модуль.
и короче, если у плюсов тоже отнять стороннюю библиотеку.
...coding for chaos...
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>То есть проблемы с созданием потоков, управлением потоков и взаимодействием потоков. Но «зачем на это нужно на уровне языка, не понимаю»
Ну понимаешь, если слово mutex станет ключевым словом языка, а не частью названия библиотечной функции, жизнь от этого особо не изменится.
А ничего шибко более умного пока и не придумано.
M>Не суть важно. Особой разницы — потоки это или процессы с точки зрения необходимости ... как там ... ах да, создавать, управлять, взаимодействовать. Сам же говоришь, с этим проблема
Как раз, важно. Потоки отличаются от процессов тем, что у потоков есть общая память и общие, хм, объекти операционной системы (файловые хендлы, сокеты и т.п.).
Re[25]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное
_>Я так понимаю, что и тебе слабо показать реализацию этой
простейшей многопоточности на Эрланге? ) Вижу уже начал отмазываться демагогическими лозунгами...
Ничего демагогического. Ты просто пошел в ту степь, о которой я говорил уже 100500 раз. Все, на что ты способен — это показать «у нас тут создается 100500 потоков Эрланг не нужен». И это ты демонстрируешь своим «тривиальным примером».
ЗЫ. Пример на Erlang'е будет сложнее, потому что в Erlang'е нет структур позволяющих их менять in-place, например. Массивов тоже нет, поэтому надо работать со списками, где lists:nth() имеет сложность O(n) и прочие заморочки.
На самом деле приведенный пример — это map. Если брать на коленке написанную (не мной ) распределенно-параллельную функцию map отсюда, то будет что-то типа (предположим, что get_index будет возвращать индекс элемента в списке).
L = read_data(),
F = fun(X) ->
(lists:nth(get_index(X) - 1) + X + lists:nth(get_index(X) + 1)) / 3
end,
%% так как в системе столько планировщиков, сколько у нас ядер,
%% запустим на доступных ядрах
plists:map(F, L, [{processes, schedulers}]).
%% ну или взять отсюда: https://github.com/klarna/tulib/blob/master/src/tulib_par.erl
tulib_par:eval(F, L, [{workers, <сколько-то там воркеров>}])
При этом:
— в отличие от твоего примера это решение работает для любых функций F любой сложности
— в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере)
— реализация этой гибкости занимает чуть больше экрана несложного кода.
Здравствуйте, Somescout, Вы писали:
F>>нда, чтение — не твоя сильная сторона. S>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.
ты всё равно не поймёшь его
...coding for chaos...
Re[34]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Somescout, Вы писали:
S>>>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку. F>>ты всё равно не поймёшь его S>т.е. всё-таки вы именно теоретический программист на Эрланге. Ок.
ожидаемо.
...coding for chaos...
Re[27]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Ничего демагогического. Ты просто пошел в ту степь, о которой я говорил уже 100500 раз. Все, на что ты способен — это показать «у нас тут создается 100500 потоков Эрланг не нужен». И это ты демонстрируешь своим «тривиальным примером». _>Вообще то в данном примере как раз создаётся совсем мало потоков. И именно поэтому Эрланг здесь действительно не нужен.
Сколько бы потоков не создавалось, это все упирается в создание X штук неуправляемых потоков. Повторю еще раз: как тебе понадобится что-то чуть более сложное, ты загнешься.
M>>На самом деле приведенный пример — это map. Если брать на коленке написанную (не мной ) распределенно-параллельную функцию map отсюда, то будет что-то типа (предположим, что get_index будет возвращать индекс элемента в списке). _>Т.е. в языке из коробки отсутствует инструмент для реализации подобного многопоточного кода и надо ставить стороннюю библиотеку. Правильно? )
_>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
такой же, если берётся сторонняя библиотека/модуль.
и короче, если у плюсов тоже отнять стороннюю библиотеку.
M>>При этом: M>>- в отличие от твоего примера это решение работает для любых функций F любой сложности _>А где в моём примере какие-то ограничения на алгоритм в цикле? )
Да, это мой косяк.
M>>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере) _>Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. )
Это напрямую имеет отношение к написанию софта. Никакой администратор не научит твой openmp находить ноды в сети и запускать код на этих нодах.
M>>- реализация этой гибкости занимает чуть больше экрана несложного кода.
_>Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? )
Возьми структуру данных, в которой реализован доступ по индексу — и вперед
_>Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? )))
Действительно. Широкие выводы из умению развернуть цикл в параллельный fold/map.
— Библиотека X может создать 100500 потоков, но общение строго через shared state с мьютексами и прочим.
— Библиотека Y может создать 100500 потоков, общение агентами/сообщениями, но нет никакой возможности управлять этими потоками, кроме как врукопашную реализовывать весь мониторинг и прочее
— Библиотека Z, может создать 100500 потоков, общение агентами/сообщениями, есть управление потоками, но нет изоляции потоков, поэтому любое залетное деление на 0 просто убивает всю программу
и так далее и тому подобное.
Именно потому ты так упорно цепляешься строго и исключительно за этот пример, а остальное называешь демагогией.
M>>Много текста ни о чем. Прекрасно — мьютексы это сообщения (чтоа?). Только на этих «сообщениях» далеко не уедешь.
EL>Почему далеко не уедешь? Почему мой текст ни о чем, ошибся где-то? Я тебе еще в прошлом треде предлагал сравнить два подхода на каком-нибудь примере, получил в ответ "ты не умеешь читать" и вот это вот. Пожалуй буду считать что ты слился и не буду больше тратить свое время на споры в булшит треде. Всего хорошего.
Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет. Это не так. Второе. Мне интересно, сколько времени у тебя уйдет на реализацию http://learnyousomeerlang.com/supervisors когда все, что у тебя предлагает язык, — это мьютексы.
А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.
Здравствуйте, Пацак, Вы писали:
П>Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга)
вообще этого не было. по крайней мере в отношении akka в этом треде.
ну и akka уже странновато называть отдельной библиотекой. в скалке оно давно заменило старую реализацию акторов. по крайней мере в той версии, которую(другую) запустил Одерски(забыл название).
реализация же этого на чём-то ещё — да, является половиной эрланга. может для кого-то это и плохо. но моя точка зрения, что было бы неплохо это иметь на какой-то иной технологии. пусть даже это JVM.
на нативных языках это невозможно без поддержки ядра. потому что нужны метрики для рассчёта затрат процессора(а эрланг это делает ровно так же, как и питон: через подсчёт действий интерпретатора), чтобы можно было балансить шедулером(системным али нет) лёгкие потоки. с поддержкой этого в ядре проблема нивелируется.
когда это станет возможным в системе, то остальное можно будет реализовать уже любыми доступными средствами.
хотя, единственной недоступной, как мне кажется, фичой останется заливка кода в рантайме. потому что без VM нельзя заменить какой-то модуль другим вариантом. но если это возможно, то тоже нет никаких проблем с реализацией этой фичи(ну, если архитектуры не отличаются).
в эрланговских приложениях горячие апдейты тоже редко используются(есть разные проблемы с обновлением состояния), но это активно используется в отладке и иногда в продавшоне.
...coding for chaos...
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>C++ AMP — это же не кроссплатформенно. EP>>Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL. _>Спецификации — это дело десятое.
Вообще, поинт в том, что C++ AMP style намного ближе к идиомам C++ нежели OpenACC, независимо от того взлетит или нет.
_>Нужна именно реализация. MS вряд ли создаст реализацию под другие платформы. А другие тем более не будут.
AMD and Microsoft jointly released C++ AMP version 1.2 compiler that supports Linux alongside Windows.
EP>>Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки. _>Ну это как с SIMD в данный момент. Автовекторизация вполне себе работает, но руками можно сделать заметно быстрее.
Да, но в случае с GPGPU проблема строго сложнее, причём на порядки:
* данные нужно передавать между CPU RAM <-> GPU RAM — эта передача может перечеркнуть весь выигрыш.
* Множество потоков разбито на блоки, которые в свою очередь разбиты на под-блоки simd'ы (warp'ы). На каждом из уровней свои ограничения и особенности, правильно используя которые можно получать приличное ускорение (либо огромные просадки, если неправильно).
* Есть несколько видов явной памяти, каждая из которых опять-таки имеет свои ограничения и особенности.
Re[45]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
EP>>А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее. BZ>имея опыт в программировании от stl до хаскела, скажу что чем высокоуровневей язык, тем удобней и надёжней программирование,
чистота != высокий уровень
императивность != низкий уровень
BZ>особенно в многопоточной среде кстати.
Какая разница мутируем ли мы локальные переменные функций?
BZ>при описании сложных алгоритмов обработки данных stl всё ещё втрое уступает хаскелу по объёму кода (довелось недавно один модуль переписать..)
А зачем ограничиваться *только* STL?
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Сначала решил ответить где-то в подветке, но решил ответить отдельным топиком, потому что текста много, не хочу, чтобы он терялся во глубине рсдновских руд.
S>Скажите, а в чём был смысл этого сообщения? Что вы пытаетесь донести?
Все описано и в сообщении и в соседнем топике
S>Что в принципе на Эрланге тоже можно написать распределённое приложение? Ну да, наверно можно. S>Что этого нельзя сделать на других языках? Очевидный бред
Все упирается в количество затрачиваемых усилий. Очевидно же?
S>Что это удобнее делать на Эрланге? А вот тут вы как раз ничего и не показали. По крайней мере чем оно сильно лучше древнющего MPI (привожу исключительно в качестве примера) непонятно, т.к. оно с лёгкостью и распараллеливается, и масштабируеться да и проблем с конкурентным доступом нет. (Да и производительность, подозреваю, будет намного выше Эрланга).
Действительно. Ведь Эрланг — это только message passing. Или Эрланг — это только 100500 процессов. /o\ И вообще, мы говорим строго и исключительно об Эрланге.
Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?
Здравствуйте, 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>Вы сравниваете Эрланг со склизкой гадостью, способной вызвать смертельное отравление?
Здравствуйте, Mamut, Вы писали:
M>Действительно. Ведь Эрланг — это только message passing. Или Эрланг — это только 100500 процессов. /o\ И вообще, мы говорим строго и исключительно об Эрланге.
M>Слушайте, это разве действительно такая проблема — прочитать, что именно я пишу, а?
Может тебе поработать над качеством изложения ? Да и вообще, сложилось ощущение, что для тебя определенные темы в Эрланге — табу.
Здравствуйте, Somescout, Вы писали:
F>>это твой виртуал? S>Нет, просто учитывая раздел было странно увидеть в нём кого-то адекватного, вот и запомнилось.
ясно, понятно
...coding for chaos...
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
...
M>Твое упорное нежелание понимать, что тебе пишут, просто удивительно.
Подозреваю, это связано с твоим изложением.
1 у тебя всё что касается эрланга и его VM, это табу(пудозреваю, и для тебя самого).
2 как решаются задачи вне эрлага ты не представляешь, ибо нет опыта
3 с эмоциями ты справиться не можешь
Так шта
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Nuzhny, Вы писали:
N>У so5team были конкретные возражения с примерами: OpenMP, например. Что это такое, для чего, как выглядит? Внезапно, этот стандарт поддерживается многими компиляторами из коробки N> Что это за программа? Да те же матричные вычисления на, внезапно, кластере.
OpenMP основан на shared memory model, так что кластера — вряд ли. можешь назвать хоть один такой компилятор?
N>Это тот раздел параллельного программирования, для которого Эрланг не создавался
учитывая, что эрланг вообще создавался под конкурентное программирование...
Здравствуйте, so5team, Вы писали:
S>Кстати говоря, вот еще один совсем свежий пример от NVidia по задействованию мощностей современных GPU: MapD. Что, очевидно, так же находится совсем в другой стороне от тех областей, для которых предназначался как сам Erlang, так и actor model, на базе которой Erlang и построен.
Мне больше нравится вариант с openacc — не видел ничего более простого в других языках. ) Интересно, если хоть что-то сравнимое (а так же ещё на тему SIMD — тоже же распараллеливание) в Эрланге... )))
M>>С качеством изложения у меня все в порядке.
CX>Нет. Это объективный наблюдаемый факт. Дискуссии ты ведешь плохо, потому что не утруждаешь себя тщательной проработкой ответов оппонентам.
Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям.
Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.
M>>Все просто. Мы запустили поток, нам нужно: M>>- Знать, что поток выполняется M>>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой) M>>- Возможно, перезапустить поток, если он завершился M>>- Убить поток, если это необходимо
Ф>Зачем всё это? (зачем управлять потоками)
Тут наш коллега Ikemefula спрашивает, почему я считаю, что люди не читают, что я пишу. Ну а как еще говорить, если пишешь, зачем управлять потоками, и тут же тебя спрашивают: а зачем управлять потоками?
Ф>Почему нельзя положиться на рантайм — пусть он управляет.
Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.
Ф>Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.
Ф>Что за глупость убивать поток? Ф>Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток? Ф>И слава богу! Ф>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам. Ф>Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира.
Простейший пример, который я чуть ли не в каждой первой десктопной прграмме: фоновые задачи. Например, всякие IDE индексируют файлы для поиска, компилируют программы и т.п. в отдельных потоках, не влияющих на GUI-поток. Ты не поверишь, но возникает необходимость выполнение этих задач прекратить. И таких примеров (управление потоками и прочее, что я описал) сотни. Надо только немного подумать и взглянуть за пределы своих уютных мирков.
Остальное все поскипано, потому что надоело по пятидесятому кругу что-то объяснять людям, которые предпочитают отвечать, не читая и даже не потратив и секунды на размышление.
Здравствуйте, Mamut, Вы писали:
M>Тут наш коллега Ikemefula спрашивает, почему я считаю, что люди не читают, что я пишу. Ну а как еще говорить, если пишешь, зачем управлять потоками, и тут же тебя спрашивают: а зачем управлять потоками?
Если бы ты проявил пример чистоплотности, при чем с употреблением терминов "конкурентный", "параллельный", все было бы горадо проще.
Ты же почему то отказываешься использовать точные термины, вместо этого используешь сомнительные примеры, или слишком общие термины "многопоточно, многоядерно, распределено"
Собтсвенно отсюда ясно, часть людей могут тебя понять, и что характерно, у них опыт в эрланге. А вот другие, без опыта в эрланге, догадываются, что же ты хотел сказать.
Здравствуйте, Mamut, Вы писали:
CX>>Нет. Это объективный наблюдаемый факт. Дискуссии ты ведешь плохо, потому что не утруждаешь себя тщательной проработкой ответов оппонентам.
M>Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям.
M>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.
Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе.
M>>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я. I>Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе.
Есть очень четкая корреляция: люди не понимают написанное даже если там больше половины текста про Эрланг вообще не упоминает. Ты, например, тому тоже яркий пример
Здравствуйте, Mamut, Вы писали:
Ф>>Зачем всё это? (зачем управлять потоками) Ф>>Почему нельзя положиться на рантайм — пусть он управляет.
M>Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.
Объясни рантайму, что ты хочешь.
Хочешь ты наверняка не потоками управлять, а задачу (в фоне) выполнить. Так и создавай задачу, например вот так:
// Create and start the task in one operation.var taskA = Task.Factory.StartNew(() => Console.WriteLine("Hello from taskA."));
Задача — это не поток, задача может использовать отдельный поток, но не обязательно. Задачи ты можешь комбинировать (сцеплять, задавать зависимости между ними), отменять отдельные задачи — совершенно другой уровень.
Ф>>Я даже в абсолютном большинстве ситуаций не вижу смысла "запускать поток" — в пень, не хочу ни создавать ещё один, лишний, объект, ни следить за его временем жизни.
M>
Зачем?
Ф>>Что за глупость убивать поток? Ф>>Когда это может быть необходимо? Что делать с оставшейся программой, у которой убили поток? Ф>>И слава богу! Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам. Ф>>Для того чтобы иметь возможность безболезненно убить MANAGED поток нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира.
M>Простейший пример, который я чуть ли не в каждой первой десктопной прграмме: фоновые задачи.
Ты правильные термины начинаешь использовать.
M>Например, всякие IDE индексируют файлы для поиска, компилируют программы и т.п. в отдельных потоках, не влияющих на GUI-поток. Ты не поверишь, но возникает необходимость выполнение этих задач прекратить. И таких примеров (управление потоками и прочее, что я описал) сотни.
Всё было бы просто, если бы задачи были совсем независимы, по данным, но это не про реальную жизнь: в реальной жизни независимых задач крайне мало, и с ними всё решается достаточно просто, например, с помощью Parallel.ForEach(), который в составе параметров принимает в том числе и CancellationToken.
Повторюсь: убивать поток — плохая идея. Даже с процессом может плохо получиться:
при грубом завершении потока тебе нужно как минимум файлы закрыть (и, кстати, закрывать ли — тот ещё вопрос), а ещё лучше — объекты синхронизации в правильное состояние вернуть — вот это уже совсем не простая задача, которая в общем случае не решается.
Для прекращения выполнения кода существуют другие методы. Самый удачный, на мой взгляд — реакция самой задачи на CancellationToken.
Может быть ты знаешь какую-то магию, которую я не знаю в этой области? Как эта проблема решается в Erlang'е?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Mamut, Вы писали:
I>>Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе.
M>Есть очень четкая корреляция: люди не понимают написанное даже если там больше половины текста про Эрланг вообще не упоминает. Ты, например, тому тоже яркий пример
"больше половины текста про Эрланг вообще не упоминает" — это ты про своё сообщение, где у тебя в каждой строчке "Эрланг" ?
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Если бы ты проявил пример чистоплотности, при чем с употреблением терминов "конкурентный", "параллельный", все было бы горадо проще.
слово "конкурентный" появилось-то в нашем лексиконе совсем недавно. и то, как более точное описание проблем многопоточных приложений.
а раньше никого это не волновато. и никто не умер.
I>Ты же почему то отказываешься использовать точные термины, вместо этого используешь сомнительные примеры, или слишком общие термины "многопоточно, многоядерно, распределено"
три разные ситуации. как их можно связывать с параллельностью?
...coding for chaos...
Re[5]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>слово "конкурентный" появилось-то в нашем лексиконе совсем недавно. и то, как более точное описание проблем многопоточных приложений. F>а раньше никого это не волновато. и никто не умер.
Раньше вообще не знали о программировании и ничего, жили люди. Даже до изобретения колеса тоже как то справлялись.
I>>Ты же почему то отказываешься использовать точные термины, вместо этого используешь сомнительные примеры, или слишком общие термины "многопоточно, многоядерно, распределено"
F>три разные ситуации. как их можно связывать с параллельностью?
В том то и дело, что три разные. Мамут ничего внятного здесь не говорит. Между тем, параллельное программирование оно тоже и многопоточно, и многоядерно и распределено. И конкурентное так же многопоточно, многоядерно и распределено.
Здравствуйте, neFormal, Вы писали:
Ф>>Что делать с оставшейся программой, у которой убили поток?
F>ПА-НИ-КО-ВАТЬ! ААА!
Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии. Именно так и делают языки для нативного кода.
Ф>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам. F>но это же проблема реализации, а не идеи
Нет, сама идея убога.
Ф>>...нужно иметь возможность гарантировать, что он в процессе своего выполнения не зааффектил ничего из внешнего мира. Даже с процессами не всегда такое возможно.
F>ну да, всё верно. F>если технология не позволяет освобождать внешние связи, то всё плохо.
Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
Ф>>Не имеешь ли ты ввиду часом то, что имели ввиду авторы Smalltalk'а, когда говорили об "общении" между объектами? Если да, то это плохая идея.
F>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности. F>а чем идея плоха?
Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Ikemefula, Вы писали:
I>Раньше вообще не знали о программировании и ничего, жили люди. Даже до изобретения колеса тоже как то справлялись.
и что же изменилось к лучшему с новым термином?
F>>три разные ситуации. как их можно связывать с параллельностью? I>В том то и дело, что три разные. Мамут ничего внятного здесь не говорит. Между тем, параллельное программирование оно тоже и многопоточно, и многоядерно и распределено. И конкурентное так же многопоточно, многоядерно и распределено.
ну да, и чо? какая вообще разница?
...coding for chaos...
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
Ф>>>Зачем всё это? (зачем управлять потоками) Ф>>>Почему нельзя положиться на рантайм — пусть он управляет.
M>>Действительно, ведь рантайм наделен телепатической силой и знает о том, что программист хочет сделать.
Ф>Объясни рантайму, что ты хочешь.
О. Внезапно. То есть уже надо управлять потоками.
Ф>Хочешь ты наверняка не потоками управлять, а задачу (в фоне) выполнить. Так и создавай задачу, например вот так: Ф>Задача — это не поток, задача может использовать отдельный поток, но не обязательно. Задачи ты можешь комбинировать (сцеплять, задавать зависимости между ними), отменять отдельные задачи — совершенно другой уровень.
Каким образом это я буду делать, если мне ни язык ни библиотеки не предоставляют никакой возможности это делат, кроме как устраивать закаты вручную?
M>>Простейший пример, который я чуть ли не в каждой первой десктопной прграмме: фоновые задачи. Ф>Ты правильные термины начинаешь использовать.
Я их изначально правильные использую. Просто для людей, у которых в руках нет никаких инструментов для работы со всем этим, это кажется разными задачами
M>>Например, всякие IDE индексируют файлы для поиска, компилируют программы и т.п. в отдельных потоках, не влияющих на GUI-поток. Ты не поверишь, но возникает необходимость выполнение этих задач прекратить. И таких примеров (управление потоками и прочее, что я описал) сотни.
Ф>Всё было бы просто, если бы задачи были совсем независимы, по данным, но это не про реальную жизнь: в реальной жизни независимых задач крайне мало, и с ними всё решается достаточно просто, например, с помощью Parallel.ForEach(), который в составе параметров принимает в том числе и CancellationToken.
Да-да. Форич, расшариваемые токены, к которым доступ идет через lock(object). Бггггг. В общем все ровно то, о чем я говорю. Но потом удивляются, что я говорю, что люди вообще даже не прилагают усилий к тому, чтобы прочитать написанное
Ф>Для прекращения выполнения кода существуют другие методы. Самый удачный, на мой взгляд — реакция самой задачи на CancellationToken.
Ф>Может быть ты знаешь какую-то магию, которую я не знаю в этой области? Как эта проблема решается в Erlang'е?
В Эрланге это решается шатными средствами: в любой поток(он же процесс он же задача) можно послать сообщение, которое поток/задача/процесс может обработать и завершиться штатными средствами. Для более развесистых конструкций ест опять же штатные средства (в 90% случаев ничего делать не надо, для чистки ресурсов достаточно реализовать подчистку в функции terminate).
Здравствуйте, Философ, Вы писали:
Ф>>>Что делать с оставшейся программой, у которой убили поток? F>>ПА-НИ-КО-ВАТЬ! ААА! Ф>Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии. Именно так и делают языки для нативного кода.
я что-то не понял, почему.
поток убили снаружи? а его в этот момент использовали?
Ф>>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам. F>>но это же проблема реализации, а не идеи Ф>Нет, сама идея убога.
аргументы?
Ф>Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно?
почему не знаю? файл нужно закрыть, если он был открыт.
Ф>Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока?
не этому потоку.
F>>да, именно, как в ST. с этой стороны эрланг можно назвать даже объектно-ориентированным языком. с известной долей условности. F>>а чем идея плоха? Ф>Это отдельная тема — потом отвечу (если не забуду). Если вкратце, то плохо это потому, что такой подход плодит ошибки в процессе разработки, которые могли бы быть исправлены до компиляции программы.
блин, я, можно сказать, только ради этой темы сюда и влез, а ты вот как значит, да?
I>>>Есть очень четкая корреляция — тобой написаное хорошо понимают в основном люди с опытом в эрланге. Это демонстрирует, что ты объясняешь как будто сам себе. M>>Есть очень четкая корреляция: люди не понимают написанное даже если там больше половины текста про Эрланг вообще не упоминает. Ты, например, тому тоже яркий пример I>"больше половины текста про Эрланг вообще не упоминает" — это ты про своё сообщение, где у тебя в каждой строчке "Эрланг" ?
Во-во. Ровно то, о чем я говорю. Ни в вводной части ни в «вниз по кроличьей норе» нет ни слова про Эрланг. И часть «Но как же библиотеки и Эрланг не нужен?» тоже не про Эрланг, хоть он там и упоминается. Но ты же даже не притворяешься, что перед тобой стоит задача понять, что там написано.
Здравствуйте, neFormal, Вы писали:
Ф>>Правильно, рубить процесс к чертям, ибо он в неконсистентном состоянии. Именно так и делают языки для нативного кода.
F>я что-то не понял, почему. F>поток убили снаружи? а его в этот момент использовали?
Он использовал.
Или не использовал — ты в общем случае не знаешь, поэтому можешь перекреститься, и надеяться на то, что не использовал.
Ф>>>>Убивать нативные потоки — очень-очень плохая идея (читай классиков). Убийство managed потоков — тоже не есть здравая мысль, почти по тем же причинам. F>>>но это же проблема реализации, а не идеи Ф>>Нет, сама идея убога.
F>аргументы?
Ф>>Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно? F>почему не знаю? файл нужно закрыть, если он был открыт.
А если создан, стало быть, удалить? Бгг ))
Ф>>Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока? F>не этому потоку.
А кому? — В этом ведь весь вопрос.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[5]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
I>>Если бы ты проявил пример чистоплотности, при чем с употреблением терминов "конкурентный", "параллельный", все было бы горадо проще. F>слово "конкурентный" появилось-то в нашем лексиконе совсем недавно. и то, как более точное описание проблем многопоточных приложений.
Это описание частных проблем многопоточных приложений, то есть некоторый подкласс задач.
F>а раньше никого это не волновато. и никто не умер.
, не догадывается о существовании целого класса "параллельных" задач, и всё время говорит об конкуретных, при этом используя неверные термины (например называя конкуретность параллельностью — на что ему уже многократно указывали).
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
I>>Раньше вообще не знали о программировании и ничего, жили люди. Даже до изобретения колеса тоже как то справлялись.
F>и что же изменилось к лучшему с новым термином?
Разные задачи, что очевидно, решаются по разному.
F>>>три разные ситуации. как их можно связывать с параллельностью? I>>В том то и дело, что три разные. Мамут ничего внятного здесь не говорит. Между тем, параллельное программирование оно тоже и многопоточно, и многоядерно и распределено. И конкурентное так же многопоточно, многоядерно и распределено.
F>ну да, и чо? какая вообще разница?
"потоками надо управлять и потокам надо общаться друг с другом" — в каждом из случаев это делается по разному. Мамут вещает ровно про один, только нигде про это явно не говорит.
Сравнение с другими инструментами:
"Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов."
"Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа"
и тут же "не знаю, не пробовал, не в курсе, пробовал но давно"
Диссонанс какой то. Что бы сравнивать и утверждать "там ничего нет", надо бы ознакомиться что же "там".
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Философ, Вы писали:
F>>я что-то не понял, почему. F>>поток убили снаружи? а его в этот момент использовали? Ф>Он использовал. Ф>Или не использовал — ты в общем случае не знаешь, поэтому можешь перекреститься, и надеяться на то, что не использовал.
кого же он использовал или не использовал?
F>>аргументы?
я всё ещё надеюсь их увидеть.
Ф>>>Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно? F>>почему не знаю? файл нужно закрыть, если он был открыт. Ф>А если создан, стало быть, удалить? Бгг ))
зачем? тоже закрыть. это не транзакции, даже не надейся.
Ф>>>Ещё пример: кому должен принадлежать мютекс, после принудительного завершения потока? F>>не этому потоку. Ф>А кому? — В этом ведь весь вопрос.
а кому принадлежит мутех после того, как процесс его освободит? вот и здесь так же.
...coding for chaos...
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
, не догадывается о существовании целого класса "параллельных" задач, и всё время говорит об конкуретных, при этом используя неверные термины (например называя конкуретность параллельностью — на что ему уже многократно указывали).
Здравствуйте, Mamut, Вы писали:
M>Во-во. Ровно то, о чем я говорю. Ни в вводной части ни в «вниз по кроличьей норе» нет ни слова про Эрланг. И часть «Но как же библиотеки и Эрланг не нужен?» тоже не про Эрланг, хоть он там и упоминается. Но ты же даже не притворяешься, что перед тобой стоит задача понять, что там написано.
Угу, сообщение совсем, совсем не про Эрланг: M> И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования именно в подходах к многопоточному программированию.
Оно, конечно, не в прологе, но ведь сами же настаиваете: M> Убедительная просьба сначала прочитать, а потом отвечать
Вот после прочтения всего и делается вывод об Эрланге.
И ладно бы вы привели бы сравнения реализации одних и тех же задач на разных языках, и показали что в Эрланге это потенциально лучше/надёжнее и в каких случаях это стоит использовать.
Вместо этого сначала выдвигается требование "Все возможности должны быть в спецификации стандарта языка", видимо без такого handicap'а Эрлангу вообще не светит: М>"Давайте посмотрим, что у нас считается state of the art в некоторых современных языках. Для тех, кто в наглухо забронированном танке. Это то, что доступно в языках на уровне стандартов и стандартных библиотек",
Затем в ход идёт очень странная индукция: "В с++ есть потоки, мьютексы. Ну еще есть futures." -> "C#? Objective-C? Ruby? Php бггг? кто там еще есть в индексе? Все то же самое и одно и то же.".
(Эта индукция сама по себе показательна, поэтому я не буду заострять внимания на C# async/await, TPL — которые как раз входят в стандартную библиотеку)
"Вниз по кроличьей норе"
Абсурд достигает пика: M> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? Никакие. Нет таких инструментов. Вплоть до смешного: M> “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)."
Опять та же самая альтернативная логика. И да, с какого перепугу жёсткое прерывание потока (non-cooperatively kill a single thread) должно входить в стандарт, если его убирают даже из тех языков, где оно первоначально было?
Остальная часть так-же изобилует отсутствием конкретики (по крайней мере там, гда не упоминается Э.).
S>Опять та же самая альтернативная логика. И да, с какого перепугу жёсткое прерывание потока (non-cooperatively kill a single thread) должно входить в стандарт, если его убирают даже из тех языков, где оно первоначально было?
S>Остальная часть так-же изобилует отсутствием конкретики (по крайней мере там, гда не упоминается Э.).
Специально ткну тебя носом:
Если у тебя однопоточное приложение — проходим мимо. Как только потоков становится N > 1, все становится очень печально (в большинстве языков). Потому что потоками надо управлять и потокам надо общаться друг с другом.
Что такое управлять потоками?
Все просто. Мы запустили поток, нам нужно:
— Знать, что поток выполняется
— Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
— Возможно, перезапустить поток, если он завершился
— Убить поток, если это необходимо
Что такое общаться друг с другом?
Все просто. Часто одному потоку надо знать о промежуточном состоянии другого потока или передать в другой поток какое-то свое промежуточное состояние. Как простейшие примеры:
— UI поток должен узнать, что что-то изменилось в долгоиграющем потоке, чтобы обновить свое состояние (прогрессбар, например)
— Долгоиграющий поток должен узнать, что что-то изменилось в окружающем мире, чтобы продолжить работу (появились новые данные, изменилась конфигурация и т.п.)
Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос.
Только не надо мне рассказывать сказки про то, что тебе не надо ничем управлять и ни с чем общаться.
Здравствуйте, Mamut, Вы писали:
M>Давайте посмотрим, что у нас считается state of the art в некоторых современных языках. Для тех, кто в наглухо забронированном танке. Это то, что доступно в языках на уровне стандартов и стандартных библиотек:
M>- С++. Стандарт С++11. http://en.cppreference.com/w/cpp/thread Уровень примерно на уровне WinAPI середины 90-х. Потоки, мьютексы. Ну еще есть futures. M>- Python. https://docs.python.org/2/library/threading.html#module-threading и https://docs.python.org/3/library/threading.html#module-threading. То же самое. Потоки, мьютексы. Ну или смешные костыли в виде запуска отдельного ОС-процесса M>- Java. Возьмем ссылку на википедию. https://en.wikipedia.org/wiki/Java_concurrency Все то же. Потоки и мьютексы. Плюс возможно процессы ОСи M>- C#? Objective-C? Ruby? Php бггг? кто там еще есть в индексе? Все то же самое и одно и то же.
M>(понятно, что я могу ошибаться, или ошибаться в деталях)
Подброшу деталей на вентилятор, уж не серчайте:
C#: Thread является managed thread, т.е. однозначного соответствия с потоками, которыми ворочает планировщик, уже может и не быть (на усмотрение Фреймворка)
Ещё раз C#: async/await, TPL, "вот это всё (c)" — здорово напоминает идиому Win32 Message queue, но только там пул системных потоков вместо цикла прокачки сообщений, и разгребаются таски (т.е. функции с контекстом выполнения) вместо системных сообщений
Идиома "Green threads", интернациональная (Java и не только, https://en.wikipedia.org/wiki/Green_threads#Green_threads_in_other_languages)
В общем, многопоточность давно уже не требует ручного управления потоками на большом числе языков. Просто инерция мышления загоняет большинство народа в старые рамки: для легковесных потоков есть Эрланг, и только он.
Re[2]: Эрланг и все-все-все (на самом деле, не совсем)
MD>В общем, многопоточность давно уже не требует ручного управления потоками на большом числе языков. Просто инерция мышления загоняет большинство народа в старые рамки: для легковесных потоков есть Эрланг, и только он.
Здравствуйте, neFormal, Вы писали:
EP>>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат EP>>* При конкурентом программировании сама задача решается на порядки проще F>т.е. разница лишь в количестве потоков относительно процессоров и нагрузке на каждый поток. F>негусто, если честно.
Густо-негусто, но стартовый тезис это разбивает в пух и прах:
M>Тезис топика: Для удобного использования многоядерности и вообще распараллеливания чего бы то ни было, нужно иметь, по сути, одну вещь: поддержку этого языком. Когда все, что язык предоставляет — это появившиеся в 2011-м стандарте thread'ы, то далеко на нем не уедешь. Во всяком случае пока умные люди не напишут вокруг всего этого костыли и библиотеки. Потому что первый же залетный mutex.lock убъет любую многопоточность и многоядерность.
TBB, MPI, MapReduce и т.п. — отлично позволяют решать параллельные задачи без поддержки со стороны языка.
Здравствуйте, Mamut, Вы писали:
M>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
M>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос.
никаких. можно ли из этого сделать какие-либо выводы в отношении конкретного языка, ну скажем эрланга?
Люди, я люблю вас! Будьте бдительны!!!
Re[12]: Эрланг и все-все-все (на самом деле, не совсем)
S>В-третьих, вы упорно не желаете признавать разницу между parallel computing и concurrent computing, даже не смотря на то, что вам на это неоднократно указывали. И если достоинства Erlang-а в области concurrent computing мало у кого вызывают сомнения, то вот применимость Erlang-а в parallel computing нужно доказывать и доказывать. Полагаю, для специализирующихся в этой области такие инструменты, как OpenMP и MPI, доступные для C, С++ и Fortran практически “из коробки”, перевешивают все, что придется вручную городить на Erlang-е и OTP. Тем не менее, вы продолжаете утверждать, что Erlang хорош для параллельности и многозадачности вообще, без оглядки на специализацию.
M>>И я утверждаю, что именно потому, что Erlang предоставляет комплексное решение возникающих из требований проблем, он заруливает подавляющее большинство других языков программирования именно в подходах к многопоточному программированию.
_>Это как раз и есть твоя основная ошибка. Ты сводишь огромное число разных задач многопоточного программирования к одному очень узкому варианту. И найдя для него неплохо решение, почему-то распространяешь его на всё богатство вариантов многопоточных задач. А это полный бред. К примеру обычному десктопному приложению (1 UI поток и парочка фоновых) или числодробилкам (количество потоков равно числу ядер процессора) твои тысячи лёгких потоков не просто не полезны, а даже вредны — тут могут быть эффективнее даже банальные системные потоки. Т.е. если бы ты проводил все свои утверждения выше для узкой ниши полезного применения Эрланга, то думаю никто и стал бы с тобой спорить. Но ты же замахиваешься на многопоточность вообще (во всех её проявлениях) и соответственно получается что несёшь бред, т.к. тут во многих отдельных нишах не то что другие языки догоняют Эрланг, а как раз наоборот, он во многих случаях будет откровенно плохим решением.
M>>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
M>>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос.
BZ>никаких. можно ли из этого сделать какие-либо выводы в отношении конкретного языка, ну скажем эрланга?
Можно. Берешь в руки стартовый топик и перечитываешь.
Здравствуйте, Mamut, Вы писали:
M>>>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
M>>>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос.
BZ>>никаких. можно ли из этого сделать какие-либо выводы в отношении конкретного языка, ну скажем эрланга?
M>Можно. Берешь в руки стартовый топик и перечитываешь.
хорошо, а как насчёт C++, java, c#, ruby, ghc и любого другого языка из первой 20-ки? какие ты выводы делаешь из того, что они не относятся к этому "подавляющему большинству" языков?
M>>>>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? M>>>>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос. BZ>>>никаких. можно ли из этого сделать какие-либо выводы в отношении конкретного языка, ну скажем эрланга?
M>>Можно. Берешь в руки стартовый топик и перечитываешь. BZ>хорошо, а как насчёт C++, java, c#, ruby, ghc и любого другого языка из первой 20-ки? какие ты выводы делаешь из того, что они не относятся к этому "подавляющему большинству" языков?
Они прекрасно относятся к подавляющему большинству. Можешь еще раз ответить на поставленный вопрос.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Густо-негусто, но стартовый тезис это разбивает в пух и прах: F>>за исключением проблемы с локами. EP>Какой проблемы, и с какими именно локами?
что можно внести туда локи и всё поломать.
впрочем, с плюсами поломать можно и так всё очень просто.
EP>Буквально с первых страниц этой темы (подобное было и в предыдущей):
некоторое подмножество задач многопоточности можно решить и классическими методами.
кто бы спорил...
тем не менее "огромное число разных задач многопоточного программирования" осталось нераскрытым.
...coding for chaos...
Re[13]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
BZ>>разница в целях. при параллельном программировании целью является более быстрая программа чем однопоточная. поэтому интерпретаторы здесь не канают, и поэтому эрланга нету на gpu,
F>да это понятно. просто терминология не очень. F>как будто конкурентность должна быть без параллельности. F>а по сути одно является подмножеством другого. что-то навроде наследования между квадратом и прямоугольником.
Это два независимых подхода, которые дополняют друг друга.
Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
F>>как будто конкурентность должна быть без параллельности. EL>не должна а может
по ходу обсуждения их чуть ли не противопоставляют.
а так да — может, но не должна.
EL>если бы Erlang мог работать только на одном ядре им все равно пользовались бы
разве только в телекоме.
...coding for chaos...
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Это два независимых подхода, которые дополняют друг друга.
не сказал бы, что они независимы. но дополняют.
I>Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.
думаю, возникло расхождение в понимании целей.
кому-то нужно посчитать быстро результат, а кому-то управлять кучей состояний.
поэтому первым важна производительность(где эрланг проигрывает), а вторым — удобство использования и поддержки.
...coding for chaos...
Re[3]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
MD>>В общем, многопоточность давно уже не требует ручного управления потоками на большом числе языков. Просто инерция мышления загоняет большинство народа в старые рамки: для легковесных потоков есть Эрланг, и только он.
M>Что по-твоему является управлением потоками?
Забавно, как ты меняешь формулировки. Месяц назад я сам объяснял тебе, что основа Эрлага это именно управление нативными потоками. У тебя были в основном общие фразы "Эрланг он не о том".
А теперь, смотрю, ты сам в этом разобрался и суешь это управление в каждое сообщение.
Здравствуйте, Mamut, Вы писали:
M>>>>>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
M>Они прекрасно относятся к подавляющему большинству. Можешь еще раз ответить на поставленный вопрос.
уже интересно. а можешь называть какие ещё языки кроме эрланга не относятся к этому подавляющеему большинству???
Люди, я люблю вас! Будьте бдительны!!!
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
I>>Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.
M>Тут пока что некоторые персонажи не могут понять, что такое управлять потоками/процессами/задачми, а все ту да же — «ненужно».
А чего удивляться, если всего месяц назад тебе объяснял, что Эрланге основной тренд был и есть управление потоками-задачами и тд.
Так что да, кое кто очень плохо умеет читать, только почему то приписывает это свойство окружающим.
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
M>>Что по-твоему является управлением потоками? I>Забавно, как ты меняешь формулировки. Месяц назад я сам объяснял тебе, что основа Эрлага это именно управление нативными потоками.
Ахахахахаха. Ну не позорься же так
I>У тебя были в основном общие фразы "Эрланг он не о том". А теперь, смотрю, ты сам в этом разобрался и суешь это управление в каждое сообщение.
Специально для тебя, который тут обижается, что я его обвиняю, что он не умеет читать:
Дальше в топике я называю потоками и потоки и корутины и легковесные процессы.
Здравствуйте, neFormal, Вы писали:
EP>>>>Густо-негусто, но стартовый тезис это разбивает в пух и прах: F>>>за исключением проблемы с локами. EP>>Какой проблемы, и с какими именно локами? F>что можно внести туда локи и всё поломать.
1. А зачем их туда вносить?
2. Как-будто native модуль в Erlang'е не может "внести туда локи и всё поломать".
F>впрочем, с плюсами поломать можно и так всё очень просто.
Это ортогонально.
EP>>Буквально с первых страниц этой темы (подобное было и в предыдущей): F>некоторое подмножество задач многопоточности можно решить и классическими методами. F>кто бы спорил...
Что такое "классические методы" и что такое "неклассические"?
F>тем не менее "огромное число разных задач многопоточного программирования" осталось нераскрытым.
* Например вычислительные задачи из области CAE/CAD.
* Задачи решаемые через GPGPU
* Задачи решаемые на кластерах из top500.org
* Большинство задач решаемых посредством TBB, PPL, OpenMP, MPI
* Рендеринг 3D сцен, обработка изображений и т.п.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. А зачем их туда вносить?
по ошибке, например.
EP>2. Как-будто native модуль в Erlang'е не может "внести туда локи и всё поломать".
может. и без nif можно всё поломать только на обмене сообщениями.
это тоже проблема технологии.
EP>Что такое "классические методы" и что такое "неклассические"?
1. создание системных потоков и раскидывание задач по ним
2. все остальные
F>>тем не менее "огромное число разных задач многопоточного программирования" осталось нераскрытым. EP>* Например вычислительные задачи из области CAE/CAD. EP>* Задачи решаемые через GPGPU EP>* Задачи решаемые на кластерах из top500.org EP>* Большинство задач решаемых посредством TBB, PPL, OpenMP, MPI EP>* Рендеринг 3D сцен, обработка изображений и т.п.
по-моему, половина про одно и то же.
...coding for chaos...
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
F>о проблеме?
ага
F>дедлоки.
бывают редко, лечатся элементарно (особенно после появления thread sanitizer-а в gcc), очень легко можно запилить архитектуру в которой дедлоки невозможны в принципе
можно легко получить лайвлок на сообщениях и чем угодно вообще, это не исключительная проблема локов
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>Что такое "классические методы" и что такое "неклассические"?
F>1. создание системных потоков и раскидывание задач по ним F>2. все остальные
это очень неинформированное мнение. во-первых, создание потоков ОС ничем не отличается в плане парадигмы программирования от создания потоков рантайма, рахница только в эффективности. во-вторых, основная проблема в CP — не создание потоков, а коммуникация между ними, и тут с 60-х годов придумано безумное число идей. CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам эрланг)
мне кажется, лучше делить подходы на shared memory/messaging
EP>>* Задачи решаемые через GPGPU
F>по-моему, половина про одно и то же.
так не только половина, а всё — о том что нам нужно как можно быстрее получить результат, неважно сколько cpu/gpu при этом задействовано
Люди, я люблю вас! Будьте бдительны!!!
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам эрланг)
Судя по всему всё же на акторах, а не CSP:
https://en.wikipedia.org/wiki/Communicating_sequential_processes
CSP message-passing fundamentally involves a rendezvous between the processes involved in sending and receiving the message, i.e. the sender cannot transmit a message until the receiver is ready to accept it. In contrast, message-passing in actor systems is fundamentally asynchronous, i.e. message transmission and reception do not have to happen at same time, and senders may transmit messages before receivers are ready to accept them.
BZ>мне кажется, лучше делить подходы на shared memory/messaging
Параллельные вычисления реализуются и там и там: TBB (shared memory), MPI (Message Passing).
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>1. А зачем их туда вносить? F>по ошибке, например.
По ошибке добавить мьютекс?
Всё же не пойму к чему это — параллельное программирование можно строить поверх готовых примитивов типа parallel_transform, parallel_reduce и т.п., без всяких мьютексов и очередей в пользовательском коде.
Здравствуйте, Mamut, Вы писали:
M>Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям. M>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.
Ну я в той дискуссии не участвовал. Однако в данной темке ты так и не смог ничего мне возразить. ))))
Здравствуйте, Mamut, Вы писали:
M>Специально ткну тебя носом:
M>...
M>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос. M>Только не надо мне рассказывать сказки про то, что тебе не надо ничем управлять и ни с чем общаться.
Что, культурно общаться уже не получается? Жаль.
M> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
Я, к сожалению, не могу говорить за "подавляющее большинство языков", поскольку не являюсь в них экспертом. Но, конкретно эти два вопроса решается либо асинхронными событиями, либо синхронизацией (гм, забавно если задуматься). Рискну предположить, что библиотеки, реализующие подобную функциональность есть для большинства живых языков.
И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки?
M>>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос. M>>Только не надо мне рассказывать сказки про то, что тебе не надо ничем управлять и ни с чем общаться.
S>Что, культурно общаться уже не получается? Жаль.
Мне сложно общаться с людьми, которые не читают написанного. Потому что постоянно приходится отвечать цитатми из самого первого сообщения.
M>> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов? S>Я, к сожалению, не могу говорить за "подавляющее большинство языков", поскольку не являюсь в них экспертом. Но, конкретно эти два вопроса решается либо асинхронными событиями, либо синхронизацией (гм, забавно если задуматься). Рискну предположить, что библиотеки, реализующие подобную функциональность есть для большинства живых языков.
S>И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки?
И первый и второй пункт, безусловно, могут быть в какой-то мере решены на уровне библиотек. Но эти решения будут всегда ограничены возможностями как самого языка, так и возможностями рантайма этого языка.
...
Без комплексного подхода и доступности бОльшей части возможностей из коробки, использование любых библиотек и языков программирования обречено на то, что в коде будут сплошные закаты солнца вручную для всего, что нереализовано библиотекой или языком.
Для подавляющего большинства библиотек (в том числе и приведенных в этом топике) на эти вопросы нет ответа. Все или почти надо делать врукопашную. И, повторю, нет ни единого действительно комплексного подхода.
— Библиотека X может создать 100500 потоков, но общение строго через shared state с мьютексами и прочим.
— Библиотека Y может создать 100500 потоков, общение агентами/сообщениями, но нет никакой возможности управлять этими потоками, кроме как врукопашную реализовывать весь мониторинг и прочее
— Библиотека Z, может создать 100500 потоков, общение агентами/сообщениями, есть управление потоками, но нет изоляции потоков, поэтому любое залетное деление на 0 просто убивает всю программу
и так далее и тому подобное.
Но так — да. «Тривиальные операции» реализуются. Вот рядом люди уже 20 лет пилят модель акторов для C++ и ничего, называют это «нет ничего сложного»
Здравствуйте, 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[2]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, 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>А что делать, если чиать ты точно не умеешь. Иначе мне не пришлось бы отвечать исключительно цитатами из самого себя.
Полагаю, вам просто нечего сказать. Ведь аргументация ваших утверждений потребует конкретики, а вы так и не смогли её выдать.
И поэтому, до тех пор пока мне не надоест с вами общаться, вы будете продолжать к месту и не к месту цитировать своё первое сообщение.
ARI ARI ARI... Arrivederci!
Re[13]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, AlexRK, Вы писали:
EP>>Если бы "параллельный" код исполнялся в одном потоке — то не было бы никакого смысла распараллеливать однопоточный — это сложнее и дороже в любом случае (как минимум нужно подключить параллельную библиотеку, добавить опции компилятора, изменить код (иногда изменения минимальны, иногда увы нет) и т.п.). EP>>Конкуретный же код наоборот использует процессы для упрощения решения, и в общем случае без проблем может работать на одном железном потоке. EP>>Грань вполне чёткая. ARK>Все же не могу согласиться. Если взять какой-нибудь код, например, на Ada, где есть встроенная многопоточность, сможем ли мы сказать, какой это код — параллельный или конкурентный? Ну, может в каких-то случаях сможем. А в каких-то нет. Собственно, у меня может быть код одновременно и производительнее, и проще однопоточного. Я бы не назвал это четкой гранью.
Упрощённые критерии, отчасти по вторичным признакам:
* Если код проще с потоками, то это конкурентное программирование (которое в некоторых случаях может также давать преимущества по скорости, но необязательно).
* Если код сложнее, и без использования нескольких железных потоков такое усложнение вообще не имеет смысла — то это параллельное программирование.
Но, повторюсь — это сильно упрощённое описание. О чём я и сказал в исходном сообщении:
EP>(Вообще говоря и параллельное и конкурентное программирование охватывают бОльшие области чем я описал, но для первого приближения такого описания достаточно)
Например бывают случаи где никакой однопоточной альтернативы нет в принципе, и соответственно оценки "проще/сложнее" не применимы.
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Соответственно, если мы запускаем скажем числодробилку на лёгких потоках, то получаем отображение например 8 лёгких потоков в 8 системных (обычный пул по числу ядер) и в итоге планировщик и вся инфраструктура поддержки (то самое, чем ты там гордишься в Эрланге) лёгких потоков будут заняты исключительно обогревом воздуха. Тупо трата ресурсов в никуда без единого плюса взамен. F>с smp, я так понимаю, эта проблема уходит. F>выбирать между несколькими лёгкими уже просто не надо.
Эммм, причём тут мультипроцессорные машины? Или ты что-то другое имел в виду? ) Ну и даже если бы это было так, то в случае Эрланга всё равно остаётся куча мусора из-за встроенности поддержки кооперативной многозадачности в саму платформу. Кстати, в тех же реализация лёгких потоков на C++ через сопрограммы это всё контролируется руками, так что ситуация становится менее печальной. Хотя планировщик и в C++ будет отрабатывать в пустую.
_>>Да, и кстати... Если говорить о типах потоков, то в подавляющем большинстве задач полезнее как раз системные. Просто потому, что написание серверов, работающие с тысячами подключений не является сильно распространённой задачей. ))) F>свят-свят! F>не все пишут числодробилки. много народу занимается как раз обработкой запросов юзеров.
Тут ключевым была именно высокая нагруженность сервера. Потому как большую часть современного веба (ты же его подразумевал под запросами юзеров?) занимает Apache+php, а это как раз пример реализации схемы "по системному потоку (ну или процессу — не суть) на подключение".
Re[16]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
F>>эрланг тормозной, это все знают. и шедулинг там не самая большая проблема. основные вещи там реализованы низкоуровнево. _>Да не в быстродействие языка дело. Даже если мы напишем это всё на C++, то оно всё равно будет уступать на числодробилке тупому пулу системных потоков, потому как будет исполнять ненужный код.
если в шедулере будет один лёгкий поток на ядро, то накладные расходы будут незначительны.
при шедулере на ядро(как в erlang smp) и тем же самым одним лёгким потоков расходы будут ещё более ничтожны.
Судя по всему, Theron умер года полтора назад.
Из живых и OpenSource для C++ есть только C++ Actor Framework и SObjectizer.
Впрочем, в Wiki есть список, по которому можно судить о живости и степени свежести.
Synca не столько от Яндекса, сколько от сотрудника Яндекса В Synca только короутины используются. Ну и автор сам говорит, что у него, к сожалению, не так много времени, чтобы довести Synca до хорошего, презентабельного состояния.
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
F>>с smp, я так понимаю, эта проблема уходит. F>>выбирать между несколькими лёгкими уже просто не надо. _>Эммм, причём тут мультипроцессорные машины?
в соседнем сообщении написал.
_>Тут ключевым была именно высокая нагруженность сервера. _>Потому как большую часть современного веба (ты же его подразумевал под запросами юзеров?)
вообще нет. у меня вот долгие прямые коннекты, кастомный протокол и лёгкие эрланговские треды.
и высокая нагруженность достигается лишь активностью юзеров.
_>занимает Apache+php, а это как раз пример реализации схемы "по системному потоку (ну или процессу — не суть) на подключение".
статистикой не интересовался, но надеюсь, что это не так, потому что адово медленно.
апач много лет уже не в тренде.
...coding for chaos...
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
не, ну какая разница, кто как что называет? суть от этого не меняется.
у тебя есть поток, на нём что-то выполняется. общается ли оно с соседними потоками — это уже детали, а не основа основ.
...coding for chaos...
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, so5team, Вы писали:
F>>но в нативе всё равно балансировка лёгких потоков без поддержки ядра будет фиговой, потому что их не прервать. S>Зависит от платформы. На Windows 64-bit есть User-Mode Scheduling.
не нашёл противоречий.
...coding for chaos...
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Ну то есть все остальное приходится закатывать вручную — изоляцию потоков, разделение данных, управление потоками и т.п. Ты смотри. Как раз то, о чем я говорил в изначальном сообщении
Кстати, насчёт вручную... Ну просто не могу не задать один коротенький практический вопрос. Вот есть у меня такой код (из реального теста):
int F(int){...}
int main()
{
auto d=LoadData();
#pragma omp parallel for
for(int i=0; i<d.size(); i++) d[i]=F(d[i]);
SaveData(d);
}
который очевидно выполняет некую многопоточную обработку массива данных, с использованием всех ресурсов процессора. И я даже не буду просить написать код работающий быстрее (зачем смешить людей). Я предложу всего лишь написать на Эрланге код с той же функциональностью, но при этом более простой и удобный в написание, чем данный пример. Ведь на Эрланге у нас же не требуется "закатывать солнце вручную" для реализации многопоточности, не так ли? )
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
Да, что-то в этом есть. Однако, с точки зрения программного кода мы, получается, вообще не можем сказать, что у нас за программа вышла — Parallel или Concurrent. Для этого мы должны знать детали конкретной платформы. А то вдруг наподключали заголовков Intel TBB, объявили все параллелизмом, а потом глядь — а процессор-то один. А есть еще всякие штуки типа High Performance Fortran, который _сам_ распараллеливает чисто последовательные алгоритмы (ну, не все, конечно, но это в данном случае не важно).
То есть если мы видим в коде явные потоки, то это может быть по разным причинам — то ли компилятор сам распараллелить не смог, то ли алгоритм изначально многопоточный, но эффект-то все равно один — есть код с потоками, вот и все. Причем любой код с потоками может выполняться как на одном процессоре, так и на нескольких.
Хуже того, даже совершенно однопоточная с виду программа на фортране может внезапно выполняться параллельно.
Получается, "параллелизм" — термин с точки зрения программного кода особо ни о чем, он о конкретной реализации.
Не знаю, в общем. Вот таски в Ada — это средства для параллелизма или конкурентности?
Здравствуйте, alex_public, Вы писали:
_>Кстати, насчёт вручную... Ну просто не могу не задать один коротенький практический вопрос. Вот есть у меня такой код (из реального теста): _>
Здравствуйте, neFormal, Вы писали:
F>если в шедулере будет один лёгкий поток на ядро, то накладные расходы будут незначительны. F>при шедулере на ядро(как в erlang smp) и тем же самым одним лёгким потоков расходы будут ещё более ничтожны.
Ну даже если мы сумеем сделать их маленькими (в Эрланге кстати не выйдет, но в некоторых других платформах можно попробовать), то остаётся ключевой вопрос — а зачем нам все эти мучения то? ))) Ведь никаких преимуществ то относительно пула системных потоков нам это не даст.
F>но в нативе всё равно балансировка лёгких потоков без поддержки ядра будет фиговой, потому что их не прервать.
И как раз поэтому оно быстрое. ) Да и кстати, зачем тебе там прерывания, если лёгкие потоки в C++ используются совместно с асинхронным IO?
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Эммм, причём тут мультипроцессорные машины? F>в соседнем сообщении написал.
Нуу так тут получается, что собственно SMP вообще ни при чём. Как я понял, это просто реализация Эрланга научилась делать множественные планировщики только в версии с поддержкой SMP.
F>вообще нет. у меня вот долгие прямые коннекты, кастомный протокол и лёгкие эрланговские треды. F>и высокая нагруженность достигается лишь активностью юзеров.
Так это всё равно получается высоконагруженный сервер) Тут Эрланг действительно подходит. Как впрочем и многие другие языки. )
_>>занимает Apache+php, а это как раз пример реализации схемы "по системному потоку (ну или процессу — не суть) на подключение". F>статистикой не интересовался, но надеюсь, что это не так, потому что адово медленно. F>апач много лет уже не в тренде.
Опять же сайты с высокой посещаемость не являются большинством в вебе. )
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, AlexRK, Вы писали:
ARK>Да, что-то в этом есть. Однако, с точки зрения программного кода мы, получается, вообще не можем сказать, что у нас за программа вышла — Parallel или Concurrent. Для этого мы должны знать детали конкретной платформы. А то вдруг наподключали заголовков Intel TBB, объявили все параллелизмом, а потом глядь — а процессор-то один.
Тут важно то, что если бы Intel TBB не давал преимуществ на многоядерных машинах — то никто бы его и не использовал для параллельных вычислений. Зачем усложнять код, ограничивать семантику операций там где это не даёт преимуществ?
ARK>А есть еще всякие штуки типа High Performance Fortran, который _сам_ распараллеливает чисто последовательные алгоритмы (ну, не все, конечно, но это в данном случае не важно).
Это есть и в C++ компиляторах: MSVC, GCC. И заметь — это называется авто-параллелизацией, а не авто-конкурентизацией или авто-многопотокизацией.
ARK>Не знаю, в общем. Вот таски в Ada — это средства для параллелизма или конкурентности?
После беглого просмотра — это скорее средства конкурентности (которые в том числе могут быть основой для параллельных решений). Кстати, насколько я вижу, в Ada обмен сообщениями ближе к CSP, чем у Erlang.
Здравствуйте, AlexRK, Вы писали:
ARK>Не знаю, в общем. Вот таски в Ada — это средства для параллелизма или конкурентности?
Параллелизм и конкурентность -- это типы задач.
Процессы, нити, таски, короутины, файберы -- это типы инструментов.
Задачи решаются посредством инструментов. Поэтому таск в Ada может быть использован как для реализации параллельности, так и для реализации конкурентности.
А вот уже параметры инструмента могут определять, насколько он пригоден или не пригоден к решению тех или иных задач. Например, короутины хороши при работе с async IO, но доставляют много хлопот в вычислительных задачах. Процессы хороши в вычислительных задачах, но не подходят для модели "один запрос, одна задача". Легкие процессы Erlang-а хороши когда стоимость обслуживания одной активности в VM нас устраивает. Но не подходят, если нужно выжимать такты и биты.
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
EP>В контексте C++ основное (и возможно единственное) преимущество OpenMP — это доступность из коробки в популярных средах.
1. Только если parallel_transform умеет принимать лямбду (а не std::function), иначе это не подойдёт для распараллеливания прямо в коде (без выноса в функцию — обычно то просто цикл с неким кодом стоит).
2. Библиотечку надо ещё собирать и подключать... Кстати, а какую ты тут имел в виду? )
3. А что скажешь насчёт openacc? )
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Ну даже если мы сумеем сделать их маленькими (в Эрланге кстати не выйдет
это почему это? какие там такие большие расходы?
_>но в некоторых других платформах можно попробовать), то остаётся ключевой вопрос — а зачем нам все эти мучения то? ))) Ведь никаких преимуществ то относительно пула системных потоков нам это не даст.
для числодробилок — никаких.
но я говорю, если использовать общий механизм создания потоков.
F>>но в нативе всё равно балансировка лёгких потоков без поддержки ядра будет фиговой, потому что их не прервать. _>И как раз поэтому оно быстрое. ) Да и кстати, зачем тебе там прерывания, если лёгкие потоки в C++ используются совместно с асинхронным IO?
для равномерного выполнения и балансировки.
опять же никакой поток не сможет заблокировать всю работу.
...coding for chaos...
Re[16]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Кстати, насчёт вручную... Ну просто не могу не задать один коротенький практический вопрос. Вот есть у меня такой код (из реального теста): _>который очевидно выполняет некую многопоточную обработку массива данных, с использованием всех ресурсов процессора. И я даже не буду просить написать код работающий быстрее (зачем смешить людей). Я предложу всего лишь написать на Эрланге код с той же функциональностью, но при этом более простой и удобный в написание, чем данный пример. Ведь на Эрланге у нас же не требуется "закатывать солнце вручную" для реализации многопоточности, не так ли? )
будет то же самое, только вместо omp+for будет parallel_map.
но т.к. этого нет в дефолтной поставке, то будет либо дополнительный код, либо подключённая библиотека, которые уже будут использовать эрланговские потоки.
если придираться, то да, кода типа больше. но за omp тоже скрывается много.
...coding for chaos...
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, Философ, Вы писали:
F>>>я что-то не понял, почему. F>>>поток убили снаружи? а его в этот момент использовали? Ф>>Он использовал. Ф>>Или не использовал — ты в общем случае не знаешь, поэтому можешь перекреститься, и надеяться на то, что не использовал.
F>кого же он использовал или не использовал?
Кого угодно — в общем случае ты не знаешь, кого он использовал.
Мог, например, из файла читать, периодически дёргая SetFilePointer(), или общие счётчики увеличивать/уменьшать. А ты ему вот так бряк, и TerminateThread(), посреди дороги. В самом лучшем случае он мог на экран что-нибудь выводить — хотя бы данные не испортишь.
F>>>аргументы? F>я всё ещё надеюсь их увидеть.
Вот это и есть аргументы, они состоят в том, что насильно вырубая поток ты приводишь программу в неконсистентное состояние, после чего её можно только вырубить. Создание файла, который ты постом выше отказался удалять в случае вырубания потока — тоже приведение программы, а иногда и системы в неконситентность — это может быть даже хуже, ибо при старте софтина может опираться на наличие/отсутствие этого файла или даже попытаться прочитать из него.
Вот это ты никакой технологией не исправишь.
Т.е. исправишь, конечно, но только фактическим отказом от многопоточности: как тут предлагают, переносом всей конкуренции в один "критический" (синхронизирующий) поток.
Ф>>>>Проблема не в технологии, а в том, что в общем случае ты не знаешь что и в какое состояние нужно всё возвращать. Простой пример: нужно ли закрывать файл, открытый в другом потоке? Может быть его удалить нужно? F>>>почему не знаю? файл нужно закрыть, если он был открыт. Ф>>А если создан, стало быть, удалить? Бгг ))
F>зачем? тоже закрыть. это не транзакции, даже не надейся.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
EP>>В контексте C++ основное (и возможно единственное) преимущество OpenMP — это доступность из коробки в популярных средах. _>1. Только если parallel_transform умеет принимать лямбду (а не std::function), иначе это не подойдёт для распараллеливания прямо в коде (без выноса в функцию — обычно то просто цикл с неким кодом стоит).
Обычно parallel_transform это шаблон функции.
Про std::function не понял — она точно также может принимать лямбду, там же шаблонный конструктор.
_>2. Библиотечку надо ещё собирать и подключать...
Тут согласен, у OpenMP как раз плюс в доступности, правда тоже есть свои нюансы.
_>Кстати, а какую ты тут имел в виду? )
Конкретно такой parallel_transform есть в PPL. В libstdc++ есть аналогичный __gnu_parallel::transform. В Intel TBB был бы какой-нибудь parallel_for.
И есть кстати proposal подобных алгоритмов (там небольшое отличие).
_>3. А что скажешь насчёт openacc? )
Тот же подход что и в OpenMP — и если для C и Fortran это и приемлемо, то для C++ как-то не айс. Например C++ AMP выглядит более идиоматично.
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Ну даже если мы сумеем сделать их маленькими (в Эрланге кстати не выйдет F>это почему это? какие там такие большие расходы?
Так обсудили же это уже. В Эрланге кроме расходов на планировщик идут ещё и расходы на поддержку кооперативной многозадачности (то самое прерывание потоков и т.п.). В C++ реализации лёгких потоков мы такие вещи ставим руками, так что в случае чего-то типа числодробилки мы можем минимизировать потери. Хотя это в любом случае бредовая идея, даже на C++ — гораздо проще взять системные потоки, причём возможно даже в автоматической реализации (типа openmp).
F>для равномерного выполнения и балансировки. F>опять же никакой поток не сможет заблокировать всю работу.
Какая блокировка то и равномерное выполнение? ) Ты представляешь вообще как работает скажем boost.asio в варианте с сопрограммами? ) Там стоит (на каждом потоке) ожидание пакета из сети. Когда пакет приходит, то происходит асинхронный вызов (ну или эмуляция всего этого через epoll в линухе) и исполнение соответствующей сопрограммы. Никто нигде ничего не блокирует и не исполняется зазря.
Ну а разбалансировка между системными потоками конечно теоретически возможно, но только при малом числе запросов (а тогда и смысла в лёгких потоках нет). А при большом очевидно всё будет нормально.
Re[5]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>потоки должны быть изолированы по данным. в true FP языках с их once-assign это решается автоматически, в других — при минимальных усилиях со стороны программиста BZ>... BZ>при неструктурированном убийстве и автоматическом переключении потоков первая проблема — возвращение памяти, принадлежащей переменным внутри этого потока. её можно решить, используя GC. вторая — неконсистентность разделяемых данных, её можно решить, используя в убиваемых потоках только message passing, и оставляя использование разделяемых данных на долю структурированно завершаемых потоков
Всё правильно, я тоже за категорический отказ от многопоточности. Позволю себе повториться:
Я с многопоточностью воюю уже лет семь, наверное.
Знаешь, я до сих пор не осилил: всё равно периодически допускаю ошибки синхронизации и падение производительности там, где теоретически она должна была бы вырасти.
Последующих поиск ошибок распаралеливания и синхронизации настолько сложная и нетривиальная задача, что я предпочитаю обходится без неё там, где без многопоточности можно обойтись.
Простой пример: в одном из 100 случаев не валидируются данные клиента. Такое нельзя отдебажить — в дебаге у тебя всё будет работать как часы. Нужно перечитывать код, и переделывать его так, чтобы ошибка стала очевидна. А это значительное время, и учитывая мою зарплату большие деньги. Если нет проблемы с производительностью, то лучшим выходом здесь будет отказ от многопоточности — проблема уйдёт сама собой.
Ты здесь предлагаешь почти тоже самое, ибо вынесение всей конкуренции в один "синхронизирующий" поток — фактический отказ от многопоточности. Может лучше вообще не заморачиваться, а?
Понимаешь, если совсем нет связи по данным, то незачем связываться с многопоточностью: вполне можно обойтись многопроцессностью, а для надёжности код на разных машинах выполнять.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Вот это и есть аргументы, они состоят в том, что насильно вырубая поток ты приводишь программу в неконсистентное состояние, после чего её можно только вырубить. Создание файла, который ты постом выше отказался удалять в случае вырубания потока — тоже приведение программы, а иногда и системы в неконситентность — это может быть даже хуже, ибо при старте софтина может опираться на наличие/отсутствие этого файла или даже попытаться прочитать из него.
поэтому никто не должен полагаться на существование чего-либо. и такой подход работает.
Ф>Вот это ты никакой технологией не исправишь. Ф>Т.е. исправишь, конечно, но только фактическим отказом от многопоточности: как тут предлагают, переносом всей конкуренции в один "критический" (синхронизирующий) поток.
это, похоже, та самая проблема с shared memory.
от неё приходится отказываться, иначе — да, всё, как ты и описываешь.
...coding for chaos...
Re[21]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>на эрланге это получается заметно проще. относительно плюсов, я бы сказал, на порядок, а то и два. F>это заслуга как языка, так и модели использования потоков. F>если не ставить целью сделать максимально(именно "максимально") эффективный относительно ресурсов сервер, то эрланг — хороший выбор.
Согласен) Вот если бы Mamut писал бы только подобные фразы, то разве с ним кто-нибудь тут спорил бы? )))
Re[20]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Так обсудили же это уже. В Эрланге кроме расходов на планировщик идут ещё и расходы на поддержку кооперативной многозадачности (то самое прерывание потоков и т.п.).
это всё работа планировщика.
_>В C++ реализации лёгких потоков мы такие вещи ставим руками, так что в случае чего-то типа числодробилки мы можем минимизировать потери. Хотя это в любом случае бредовая идея, даже на C++ — гораздо проще взять системные потоки, причём возможно даже в автоматической реализации (типа openmp).
да, поэтому я пояснил, что такое происходит только в случае использования общего механизма с лёгкими потоками.
да, можно от этого отказаться в пользу системных в простых случаях.
F>>для равномерного выполнения и балансировки. F>>опять же никакой поток не сможет заблокировать всю работу. _>Какая блокировка то и равномерное выполнение? )
простая блокировка.
приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
...coding for chaos...
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>это, похоже, та самая проблема с shared memory. F>от неё приходится отказываться, иначе — да, всё, как ты и описываешь.
Если у тебя нет разделяемых данных, то нафига тебе многопоточность? Юзай процессы.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[16]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, so5team, Вы писали:
S>А вот уже параметры инструмента могут определять, насколько он пригоден или не пригоден к решению тех или иных задач. Например, короутины хороши при работе с async IO, но доставляют много хлопот в вычислительных задачах.
неправда. короутины, futures, message passing, вообще все средства конкурентного программирования используются и в параллельных задачах тоже
т.е. конкурентные срежства программирования, такие как те же короутины — это механизм, урощающий описание некоторых алгоритмов. параллеьбность — это когда у нас есть посолеждовательный алгоритм, колтрый мы зотели бы раскидать на несколько ядер. в идеале компилятор должен брать последовательный алгоритм и раскидывать его сам, а на практике программисту чаще всего приходится помогать, используя эти средства конкурентного программирования. но в отличие от чистого конкурентного программирования для нас в этом слусчае важно что реализация этих средств умеет работать на >1 ядре
Люди, я люблю вас! Будьте бдительны!!!
Re[17]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>будет то же самое, только вместо omp+for будет parallel_map. F>но т.к. этого нет в дефолтной поставке, то будет либо дополнительный код, либо подключённая библиотека, которые уже будут использовать эрланговские потоки. F>если придираться, то да, кода типа больше. но за omp тоже скрывается много.
На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать:
#pragma omp parallel for
for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать: _>
_>#pragma omp parallel for
_>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>
с точки зрения энларга ничего не изменилось.
всё равно нужна будет лямбда.
...coding for chaos...
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
случаем?
EP>Про std::function не понял — она точно также может принимать лямбду, там же шаблонный конструктор.
std::function — тормоз. Но зато не требует шаблонов (и соответственно позволяет хранить массивы и т.п.). Поэтому её любят некоторые разразботчики библиотек, но тут тормоза явно противопоказаны. )))
_>>3. А что скажешь насчёт openacc? ) EP>Тот же подход что и в OpenMP — и если для C и Fortran это и приемлемо, то для C++ как-то не айс. Например C++ AMP выглядит более идиоматично.
C++ AMP — это же не кроссплатформенно. Мне в общем тоже не особо нравятся подходы openmp/openac. Но если у openmp есть много сравнимых аналогов, то ничего проще openacc на рынке не видно — Cuda, OpenCL и т.п. на этом фоне выглядят просто как мегастрах. )
Re[18]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать: _>
_>#pragma omp parallel for
_>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>
В общем случае будет parallel_for (есть и в TBB и PPL):
Здравствуйте, alex_public, Вы писали:
_>C++ AMP — это же не кроссплатформенно. Мне в общем тоже не особо нравятся подходы openmp/openac. Но если у openmp есть много сравнимых аналогов, то ничего проще openacc на рынке не видно — Cuda, OpenCL и т.п. на этом фоне выглядят просто как мегастрах. )
AMP можно начать использовать за день и затем месяц изучать более продвинутые техники. ACC можно выучить тоже за день, и на этом собственно всё закончится. ну а для реальной работы они оба не подходят
Люди, я люблю вас! Будьте бдительны!!!
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>учитывая, что пул системных потоков — это и есть способ реализации лёгких потоков, ответ я думаю очевиден — в эрданге ты получаешь иллюзию множества обычных потоков, а в твоём варианте — спецбиблиотеку, работающую только с этим пулом. т.е. универсальность меньше, а проихводительность ровно такая же
Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность.
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
BZ>>CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам EP>Судя по всему всё же на акторах, а не CSP:
спасибо, я всё время это забываю
BZ>>мне кажется, лучше делить подходы на shared memory/messaging
EP>Параллельные вычисления реализуются и там и там: TBB (shared memory), MPI (Message Passing).
а мы говорили о классификации подходов к concurrency. кстати, TBB реализует и message passing approach, в виде графа задач
Люди, я люблю вас! Будьте бдительны!!!
Re[21]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
BZ>>учитывая, что пул системных потоков — это и есть способ реализации лёгких потоков, ответ я думаю очевиден — в эрданге ты получаешь иллюзию множества обычных потоков, а в твоём варианте — спецбиблиотеку, работающую только с этим пулом. т.е. универсальность меньше, а проихводительность ровно такая же
_>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность.
имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?
Люди, я люблю вас! Будьте бдительны!!!
Re[21]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>простая блокировка. F>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
Ну так в случае асинхронного IO это физически невозможно) А использование лёгких потоков в сочетание с асинхронным IO — это практические негласное правило в C++. ))) Правда опять же это всё предназначено для очень узкой ниши...
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать: _>>
_>>#pragma omp parallel for
_>>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>>
F>с точки зрения энларга ничего не изменилось. F>всё равно нужна будет лямбда.
А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
F>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка. _>Ну так в случае асинхронного IO это физически невозможно)
это почему это?
...coding for chaos...
Re[20]: Эрланг и все-все-все (на самом деле, не совсем)
Есть parallel_for.
EP>>Про std::function не понял — она точно также может принимать лямбду, там же шаблонный конструктор. _>std::function — тормоз.
Да, тем не менее лямбды может хранить.
_>Но зато не требует шаблонов (и соответственно позволяет хранить массивы и т.п.). Поэтому её любят некоторые разразботчики библиотек, но тут тормоза явно противопоказаны. )))
Здесь да, лучше шаблон функции, так как соседние итерации скорей всего будут выполняться последовательно в одном потоке, и инлайн + unroll тут эффективен.
_>>>3. А что скажешь насчёт openacc? ) EP>>Тот же подход что и в OpenMP — и если для C и Fortran это и приемлемо, то для C++ как-то не айс. Например C++ AMP выглядит более идиоматично. _>C++ AMP — это же не кроссплатформенно.
Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL.
_>Мне в общем тоже не особо нравятся подходы openmp/openac. Но если у openmp есть много сравнимых аналогов, то ничего проще openacc на рынке не видно — Cuda, OpenCL и т.п. на этом фоне выглядят просто как мегастрах. )
Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки.
Или например там есть возможность управлять локальной памятью, барьерами внутри блоков?
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
BZ>>при дефолтных настройках апач не выдержит даже одного посетителя в секунду на 8 гигах озу
_>Ну это уже бред) Разве что время одного коннекта часами измеряется)))
а ты сможешь корректно ответить на три вопроса:
— сколько занимает процесс апача в озу
— сколько коннектов открывает один клиент
— сколько времени длится один коннект
и на бис — как исходя из этих чисел посчитать сколько озу требуется апачу
Люди, я люблю вас! Будьте бдительны!!!
Re[20]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>На самом деле я не очень хороший пример показал — из него не совсем понятна разница между openmp и просто функциями типа parallel_transform. Скажем вот с таким вариантом что делать: _>>>
_>>>#pragma omp parallel for
_>>>for(int i=1; i<size-1; i++) d[i]=(s[i-1]+s[i]+s[i+1])/3;
_>>>
F>>с точки зрения энларга ничего не изменилось. F>>всё равно нужна будет лямбда. _>А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )
В случае с parallel_map можно использовать ленивый список индексов по типу boost::irange
Re[19]: Эрланг и все-все-все (на самом деле, не совсем)
Воот, это уже другое дело. Это уже может заменить самые стандартные применения openmp. Правда опять же оно такое мало где есть под рукой (скажем в __gnu_parallel)...
Re[21]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
_>>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность. BZ>имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?
При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких).
Re[22]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>Ещё раз повторюсь: в Эрланге не получится получить ровно такую же производительность. BZ>>имеем бибилиотеку С++, реализующую лёгкие потоки (скажем boost::fiber или Win32 fiber) внутри системных и библиотеку C++, реализующую пул потоков, куда можно кидать таски. внимание вопрос — какая из них будет быстрее?
_>При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких).
а чем эрланг хуже?
Люди, я люблю вас! Будьте бдительны!!!
Re[23]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка. _>>Ну так в случае асинхронного IO это физически невозможно) F>это почему это?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>C++ AMP — это же не кроссплатформенно. EP>Там же отрытая спецификация, и вроде даже есть компилятор в OpenCL.
Спецификации — это дело десятое. Нужна именно реализация. MS вряд ли создаст реализацию под другие платформы. А другие тем более не будут.
EP>Думаю что для требовательных задач без них не обойтись — OpenACC скорей всего не хватит, точнее результат будет слишком неоптимальным по сравнению с возможным. Потому что потоки GPGPU очень легковесные, и там шаг вправо-влево и получаем серьёзные просадки.
Ну это как с SIMD в данный момент. Автовекторизация вполне себе работает, но руками можно сделать заметно быстрее. ) Однако в будущем думаю всё будет автоматически.
EP>Или например там есть возможность управлять локальной памятью, барьерами внутри блоков?
Не знаю, я ещё не пробовал на практике) Тем более, что в gcc оно поддерживает только Nvidia.
Re[23]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а ты сможешь корректно ответить на три вопроса: BZ>- сколько занимает процесс апача в озу BZ>- сколько коннектов открывает один клиент BZ>- сколько времени длится один коннект
BZ>и на бис — как исходя из этих чисел посчитать сколько озу требуется апачу
Так это же зависит от реализации сайта. Если там скажем код по полчаса в БД сидит, то понятно что быстро всё сдохнет. А если код вменяемый, то Апач спокойно держит такие смешные нагрузки как один клиент в секунду. )))
Re[21]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
_>>А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? ) EP>В случае с parallel_map можно использовать ленивый список индексов по типу boost::irange
Да, в C++ можно так извратиться) А в Эрланге? )
Re[23]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
_>>При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких). BZ>а чем эрланг хуже?
Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.
Re[24]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
F>>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка. _>>>Ну так в случае асинхронного IO это физически невозможно) F>>это почему это? _>Ну потому что асинхронное IO в принципе не блокируется.
так IO не заблокируется. заблокируется обработчик и свяжет всё остальное.
...coding for chaos...
Re[24]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.
вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям.
...coding for chaos...
Re[25]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? ) F>слово-в-слово — нет. потому что язык другой. F>удивительно, правда?
Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
Re[23]: Эрланг и все-все-все (на самом деле, не совсем)
_>>Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? )
F>слово-в-слово — нет. потому что язык другой. F>удивительно, правда?
Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное
Здравствуйте, neFormal, Вы писали:
_>>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь. F>вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям.
Хыхы, а как ты думал реализована та самая "возможность прерывания потоков"? ) Магия что ли? )))
Re[26]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь. F>>вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям. _>Хыхы, а как ты думал реализована та самая "возможность прерывания потоков"? ) Магия что ли? )))
пруфов нет, окай.
...coding for chaos...
Re[26]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>Как заблокируется то, если блокирующих вызовов ОС нет? ) Разве что специально накосячить, вставив там мьютексы какие-то... )
это
...coding for chaos...
Re[24]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
F>>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка. _>>>Ну так в случае асинхронного IO это физически невозможно) F>>это почему это?
_>Ну потому что асинхронное IO в принципе не блокируется.
Блокируется не IO, а конкретный поток. Если у тебя основная логика в одном потоке, то в него нужно диспетчеризовать всё, что идет от IO. Вот с такой диспетчеризацией проблемы — она делается исключительно через event loop.
Re: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Все просто. Мы запустили поток, нам нужно: M>- Знать, что поток выполняется M>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой) M>- Возможно, перезапустить поток, если он завершился M>- Убить поток, если это необходимо
Зачем все это?
Основные сложности и непонятки с потоками начинаются вовсе не вокруг их создания/завершения, а на тему, как организовать их совместную работу, чтобы все были заняты делом и никто никому не мешал.
Я уж не говорю о том, что есть три причины использовать потоки, они принципиально разные:
1. Чтобы раскидать работу по нескольким процессорам (фактически, это обход аппаратного ограничения; мы умеем делать многопроцессорные машины, но не умеем делать достаточно производительных процессоров)
2. Потому, что некоторым кажется, что программу, которая одновременно делает несколько дел, так проще писать. Хотя непродуманное взаимодействие между процессами убивает всё упрощение.
3. Потому, что иногда это единственный способ обойти ограничение операционной системы или той среды программирования, в которой приходится писать. Например, если надо ждать 2 разнотипных события, и в один WaitForMultipleSumething их одновременно не засунешь, не остается выбора, кроме как разбросать это дело по нескольким потокам.
И вот для начала людям стоило бы научиться рефлектировать, почему они вообще выбрали многопоточную модель для решения той или иной задачи. А потом продумать, как они будут делить данные между потоками. И в принципе, я не очень понимаю, какая поддержка в языке для этого нужна.
M>
M>Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.
Я уже слышал раньше эту фразу. Только вместа с;пва "Erlang" было слово "LISP"
M>Не обязательно потому что люди обязательно вдохновляются Erlang'ом, нет. А потому что Erlang раньше большинства многих других пришел к тому, к чему сейчас только приходят в других языках (и их библиотеках).
Эрлангу так хорошо живется потому, что в нем, как бы это сказать помягче, нет потоков. В нем есть взаимодействующие процессы. Каждый из которых полностью изолирован от других, и общается с ними только через специально приспособленные отверстия. Любой из эрланговских процессов можно поместить в отдельное адресное пространство, или даже утащить на другую машину, семантика от этого не изменится.
В эрланге это ограничение не очень заметно, потому что он — функциональный язык с иммутабельными данными, и уж раз данные в нем иммутабельны, то изоляция контекстов процессов особо ни на что и не влияет. Эрлангу не становится хуже от отсутствия общей памяти, потому что даже если бы она и была, с ней мало чего можно было бы сделать. Но вот в Си это не так.
Потоки, имеющие доступ к общим данным (общей памяти) и прочим системным ресурсам нужны только для эффективности. С точки зрения корректности кода (наплевав на эффективность) вполне можно было бы обойтись взаимодействующими процессами. Но слишком уж большую цену придется платить, если на каждый пук, чтобы передать данные от процесса к процессу, придется городить какой-нибудь message passing.
В эрланге это мало кого заботит, потому что он тормозной по сути своей. Это такое сознательное инженерное решение, пожертвовать эффективностью, чтобы добиться других целей. Ни в более других языках ставятся более другие цели, и эрланговский подход оказывается неподходящим, потому, что вынуждает платить слишком большую цену.
Re[25]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге. F>такой же, если берётся сторонняя библиотека/модуль.
Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )
F>и короче, если у плюсов тоже отнять стороннюю библиотеку.
OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.
Re[2]: Эрланг и все-все-все (на самом деле, не совсем)
Pzz>Основные сложности и непонятки с потоками начинаются вовсе не вокруг их создания/завершения, а на тему, как организовать их совместную работу, чтобы все были заняты делом и никто никому не мешал. Pzz>И вот для начала людям стоило бы научиться рефлектировать, почему они вообще выбрали многопоточную модель для решения той или иной задачи. А потом продумать, как они будут делить данные между потоками. И в принципе, я не очень понимаю, какая поддержка в языке для этого нужна.
То есть проблемы с созданием потоков, управлением потоков и взаимодействием потоков. Но «зачем на это нужно на уровне языка, не понимаю»
Pzz>Эрлангу так хорошо живется потому, что в нем, как бы это сказать помягче, нет потоков. В нем есть взаимодействующие процессы. Каждый из которых полностью изолирован от других, и общается с ними только через специально приспособленные отверстия. Любой из эрланговских процессов можно поместить в отдельное адресное пространство, или даже утащить на другую машину, семантика от этого не изменится.
Не суть важно. Особой разницы — потоки это или процессы с точки зрения необходимости ... как там ... ах да, создавать, управлять, взаимодействовать. Сам же говоришь, с этим проблема
Здравствуйте, alex_public, Вы писали:
_>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )
нет, только там и есть нормальная))0)
F>>и короче, если у плюсов тоже отнять стороннюю библиотеку. _>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.
не только в компиляторе.
...coding for chaos...
Re[27]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
_>>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? ) F>нет, только там и есть нормальная))0)
Ну тогда ты без проблем продемонстрируешь реализацию того элементарного примера (который на C++ занимает 2 строчки), не так ли? )
F>>>и короче, если у плюсов тоже отнять стороннюю библиотеку. _>>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки. F>не только в компиляторе.
Не суть, главное что идёт в поставке компилятора, т.е. есть из коробки.
Re[28]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? ) F>>нет, только там и есть нормальная))0) _>Ну тогда ты без проблем продемонстрируешь реализацию того элементарного примера (который на C++ занимает 2 строчки), не так ли? )
я тебе уже сказал. но ты не хочешь читать, почему-то.
F>>>>и короче, если у плюсов тоже отнять стороннюю библиотеку. _>>>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки. F>>не только в компиляторе. _>Не суть, главное что идёт в поставке компилятора, т.е. есть из коробки.
когда не надо, то не суть? отличный пример демагогии.
...coding for chaos...
Re[4]: Эрланг и все-все-все (на самом деле, не совсем)
M>>То есть проблемы с созданием потоков, управлением потоков и взаимодействием потоков. Но «зачем на это нужно на уровне языка, не понимаю» Pzz>Ну понимаешь, если слово mutex станет ключевым словом языка, а не частью названия библиотечной функции, жизнь от этого особо не изменится. Pzz>А ничего шибко более умного пока и не придумано.
Я же говорю. State-of-the art почему-то считаются мьютексы. Ну-ну.
M>>Не суть важно. Особой разницы — потоки это или процессы с точки зрения необходимости ... как там ... ах да, создавать, управлять, взаимодействовать. Сам же говоришь, с этим проблема Pzz>Как раз, важно. Потоки отличаются от процессов тем, что у потоков есть общая память и общие, хм, объекти операционной системы (файловые хендлы, сокеты и т.п.).
Да неужели. Пойду расскажу своим коллегам, что они не могут иметь в своих Эрланговских процессах объекты операционной системы. Им Pzz запретил.
Здравствуйте, neFormal, Вы писали:
_>>Ну тогда ты без проблем продемонстрируешь реализацию того элементарного примера (который на C++ занимает 2 строчки), не так ли? ) F>я тебе уже сказал. но ты не хочешь читать, почему-то.
Да, ты сказал, что только в Эрланге и есть нормальная многопоточность. Но при этом почему-то не можешь показать как на Эрланге будет выглядеть решение такой простейшей многопоточной задачи:
int main()
{
auto d=LoadData();
#pragma omp parallel for
for(int i=1; i<d.size()-1; i++) d[i]=(d[i-1]+d[i]+d[i+1])/3;
SaveData(d);
}
Т.е. от тебя пока что видны только лозунги и ноль кода.
_>>Не суть, главное что идёт в поставке компилятора, т.е. есть из коробки. F>когда не надо, то не суть? отличный пример демагогии.
Где демагогия то? ) Или ты хочешь сказать, что OpenMP — это сторонняя библиотека, которую надо скачивать, устанавливать и т.п? )
Re[30]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное
Я так понимаю, что и тебе слабо показать реализацию этой
Здравствуйте, neFormal, Вы писали:
F>я тебе уже сказал. но ты не хочешь читать, почему-то.
Неужели и код продемонстрировали? Вот казалось бы, программистский сайт, какой смысл чесать языками клавиатуру — написал код и точка зрения ясна. Пока из-за острой кодонедостаточности складывается ощущение что на Эрланге его фанаты программируют чисто теоретически, без написания этого скучного кода.
F>>>>>и короче, если у плюсов тоже отнять стороннюю библиотеку.
И ещё раз, без handicap'а C++ у Эрланга совсем шансов нет?
Здравствуйте, neFormal, Вы писали:
F>нда, чтение — не твоя сильная сторона.
Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.
ARI ARI ARI... Arrivederci!
Re[31]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
S>>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.
F>ты всё равно не поймёшь его
т.е. всё-таки вы именно теоретический программист на Эрланге. Ок.
ARI ARI ARI... Arrivederci!
Re[32]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, alex_public, Вы писали:
_>>>Т.е. от тебя пока что видны только лозунги F>>поздравляю, господин, соврамши. _>Ну давай ссылку на код или извиняйся. )
не вижу извинений за враньё
...coding for chaos...
Re[5]: Эрланг и все-все-все (на самом деле, не совсем)
M>Я же говорю. State-of-the art почему-то считаются мьютексы. Ну-ну.
Не мьютексы сами по себе, а масштабируемые алгоритмы на них построенные. Сами мьютексы тоже не так просты как кажутся. В операционной системе тоже есть шедулер, прямо как в Erlang-е, который умеет шедулить потоки (которые прямо как Erlang-овские зеленые потоки в некотором смысле). Так вот, этот шедулер знает о том какие потоки блокируют друг друга, он знает приоритеты потоков и умеет их менять динамически, чтобы быстрее реагировать на ввод/вывод, он умеет отдавать квант времени другому потоку, если первый ждет чего-нибудь, на него завязан механизм RCU и механизм предотвращения инверсии приоритетов (random boosting в винде и priority inheritence в linux). В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях.
Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку. Поток ждет на мьютексе = ждет пока соощение поступит в мейлбокс, поток освобождает мьютекс = отправляет сообщение в мейлбокс. Процессор under the hood в общем то тоже сообщения использует (фиксированного размера в 64 байта) и многие алгоритмы на shared memory тоже один в один транслируются на message passing (идиома write release/read acquire например не что иное как отправка сообщения другому потоку используя самый быстрый механизм из всех имеющихся в наличии).
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
EL>Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку. Поток ждет на мьютексе = ждет пока соощение поступит в мейлбокс, поток освобождает мьютекс = отправляет сообщение в мейлбокс. Процессор under the hood в общем то тоже сообщения использует (фиксированного размера в 64 байта) и многие алгоритмы на shared memory тоже один в один транслируются на message passing (идиома write release/read acquire например не что иное как отправка сообщения другому потоку используя самый быстрый механизм из всех имеющихся в наличии).
Много текста ни о чем. Прекрасно — мьютексы это сообщения (чтоа?). Только на этих «сообщениях» далеко не уедешь.
Здравствуйте, Mamut, Вы писали:
M>Ничего демагогического. Ты просто пошел в ту степь, о которой я говорил уже 100500 раз. Все, на что ты способен — это показать «у нас тут создается 100500 потоков Эрланг не нужен». И это ты демонстрируешь своим «тривиальным примером».
Вообще то в данном примере как раз создаётся совсем мало потоков. И именно поэтому Эрланг здесь действительно не нужен.
M>ЗЫ. Пример на Erlang'е будет сложнее, потому что в Erlang'е нет структур позволяющих их менять in-place, например. Массивов тоже нет, поэтому надо работать со списками, где lists:nth() имеет сложность O(n) и прочие заморочки.
Нет, основная сложность здесь как раз в области многопоточности — в языке нет готового инструмента для подобных параллельных вычислений.
M>На самом деле приведенный пример — это map. Если брать на коленке написанную (не мной ) распределенно-параллельную функцию map отсюда, то будет что-то типа (предположим, что get_index будет возвращать индекс элемента в списке).
Т.е. в языке из коробки отсутствует инструмент для реализации подобного многопоточного кода и надо ставить стороннюю библиотеку. Правильно? )
M>
M>L = read_data(),
M>F = fun(X) ->
M> (lists:nth(get_index(X) - 1) + X + lists:nth(get_index(X) + 1)) / 3
M> end,
M>%% так как в системе столько планировщиков, сколько у нас ядер,
M>%% запустим на доступных ядрах
M>plists:map(F, L, [{processes, schedulers}]).
M>%% ну или взять отсюда: https://github.com/klarna/tulib/blob/master/src/tulib_par.erl
M>tulib_par:eval(F, L, [{workers, <сколько-то там воркеров>}])
M>
M>При этом: M>- в отличие от твоего примера это решение работает для любых функций F любой сложности
А где в моём примере какие-то ограничения на алгоритм в цикле? )
M>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере)
Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. )
M>- реализация этой гибкости занимает чуть больше экрана несложного кода.
Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? )
Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? )))
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
M>Много текста ни о чем. Прекрасно — мьютексы это сообщения (чтоа?). Только на этих «сообщениях» далеко не уедешь.
Почему далеко не уедешь? Почему мой текст ни о чем, ошибся где-то? Я тебе еще в прошлом треде предлагал сравнить два подхода на каком-нибудь примере, получил в ответ "ты не умеешь читать" и вот это вот. Пожалуй буду считать что ты слился и не буду больше тратить свое время на споры в булшит треде. Всего хорошего.
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
EL>В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях.
а что есть подобного нетривиального?
EL>Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку. Поток ждет на мьютексе = ждет пока соощение поступит в мейлбокс, поток освобождает мьютекс = отправляет сообщение в мейлбокс.
только в случае нескольких мутехов получается ситуация с несколькими блокировками на нескольких мейлбоксах. нездорово выглядит.
так что рассматривать можно весьма условно.
...coding for chaos...
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет. Это не так. Второе. Мне интересно, сколько времени у тебя уйдет на реализацию http://learnyousomeerlang.com/supervisors когда все, что у тебя предлагает язык, — это мьютексы.
M>А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.
Точнее аргументы у тебя говно. neFormal, Синклер и тд уже нескольким показывали, где ошибка в том подходе, что у Elazin, у них получилось.
А вот ты продолжаешь "куридопосинения" и "неумеешьчитать"
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
M>А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.
Ты видимо не входишь в их число, так как я не утверждал что кроме мьютексов ничего нет. M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет.
M>Во-первых, ты утвердаешь, что ничего, кроме мьютексов нет. Это не так. Второе. Мне интересно, сколько времени у тебя уйдет на реализацию http://learnyousomeerlang.com/supervisors когда все, что у тебя предлагает язык, — это мьютексы.
Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Re[6]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
EL>Не мьютексы сами по себе, а масштабируемые алгоритмы на них построенные. Сами мьютексы тоже не так просты как кажутся. В операционной системе тоже есть шедулер, прямо как в Erlang-е, который умеет шедулить потоки (которые прямо как Erlang-овские зеленые потоки в некотором смысле). Так вот, этот шедулер знает о том какие потоки блокируют друг друга, он знает приоритеты потоков и умеет их менять динамически, чтобы быстрее реагировать на ввод/вывод, он умеет отдавать квант времени другому потоку, если первый ждет чего-нибудь, на него завязан механизм RCU и механизм предотвращения инверсии приоритетов (random boosting в винде и priority inheritence в linux). В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях.
Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
EL>Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку.
Да, все правильно. Дело не в сообщениях, а в том, кто обеспечивает корректность состояния. С мутексами у тебя этим занят каждый из потоков.
Сообщения это никакие не сообщения, а агенты. Просто у мамута такая терминология — каждое слово чтото значит, только он забывает сказать, какое слово в каком смысле употребляет. Каждый агент обеспечивает корректность своего состояния, и никто, кроме него, это состояние не видит.
EL>Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Реализовать можно, естественно
EL>Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Где ты увидел продолжение слива, известно только тебе.
Зачем нужны супервайзоры и прочее, я уже писал. Прикинь. В превом сообщении в этой теме. Потому что каждый первый, кто говорит, что ничего это ненужно на практике занимается (почти цитата) «ну пару catch'ей ручками расставим, не сложно» и прочими ручными реализациями «половины эрланга». В этой подветке
Здравствуйте, ELazin, Вы писали:
EL>Во первых, я предложил реализовать какой-нибудь параллельный алгоритм (на erlang-е же можно их писать, да?), а не часть erlang-а. Слабо написать параллельный счетчик например, ну или CM-sketch? Мне не очевидно, что erlang может быть полезен для решения параллельных задач, с которыми мне приходилось сталкиваться в реальной жизни. Слабо верится что с его помощью можно даже простые статистические свойства потока сообщений приходящих на сервер оценить, я уже молчу о какой-нибудь более сложной обработке.
Параллельные алгоритмы для мамута — табу. Скорее всего он тебе ответит "Ага, попался ! Снова — 'я умею создавать 100500 потоков эрланг не нужен' => неумеешьчитать"
EL>Во вторых, твои любимые супервайзеры имеют смысл только в языке с теми же свойствами что и erlang, процесс упал, мы его рестартанули и все, процесс продолжил потреблять очередь. В языке с общей памятью таск может упасть не из-за того что лежит в очереди а из-за того что лежит в этой самой общей памяти. Принцип let it fail тут применять не принято. В общем, вижу это как продолжение слива, решил предложить то что никто не возьмется делать и то что в erlang-е уже есть.
Дело в различных принципах декомпозиции систем. На эрланге скорее всего никогда не возникает "упадёт из-за того что лежит в этой самой общей памяти".
Собтвенно, это одна из причин, почему эрланг мало где применяется. Слишком много ограничений накладывает.
Re[28]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
M>Сколько бы потоков не создавалось, это все упирается в создание X штук неуправляемых потоков. Повторю еще раз: как тебе понадобится что-то чуть более сложное, ты загнешься.
Само собой. Просто в случае малого числа задач, управление этими системными потоками весьма тривиально (собственно просто каждая задача исполняется в своём системном потоке) и соответственно сложная система с кучей оверхеда, предназначенная для работы с тысячами одновременных задач, выглядит в этом случае неуместно.
_>>Т.е. в языке из коробки отсутствует инструмент для реализации подобного многопоточного кода и надо ставить стороннюю библиотеку. Правильно? ) M>
_>>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
M>такой же, если берётся сторонняя библиотека/модуль.
M>и короче, если у плюсов тоже отнять стороннюю библиотеку.
Так в C++ то как раз OpenMP из коробки. Т.е. ты всю эту темку утверждал как всё удобно и классно в Эрланге из коробки, а в C++ надо мучиться с установкой сторонних библиотек. А на данном примере мы увидели, что это Эрлангу надо ставить сторонние библиотеки для реализации элементарной многопоточности, в то время как в C++ данная функциональность как раз имеется из коробки.
M>>>- в случае с plists имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере) _>>Это уже не имеет отношения к написанию софта — это скорее вопрос к администраторам. ) M>Это напрямую имеет отношение к написанию софта. Никакой администратор не научит твой openmp находить ноды в сети и запускать код на этих нодах.
А причём тут мой код и такое? ) Распространением софта должны заниматься специлизированные инструменты, уже давно написанные и конфигурируемы админами. Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях).
_>>Ну да, ну да, немного несложного кода... Кстати, а функция get_index где? ) Ты вообще понимаешь, что при таком раскладе она должна быть замыканием, содержащим сам список L? Т.е. ты будешь её каждый раз писать заново? ) M>Возьми структуру данных, в которой реализован доступ по индексу — и вперед
Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L.
_>>Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? ))) M>Действительно. Широкие выводы из умению развернуть цикл в параллельный fold/map.
А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. Вот и я делаю аналогичные выводы на основе этого примера: Эрланг вообще ничего не может, т.к. тривиальный пример выглядит на нём на порядок страшнее, чем в даже древнем Фортране. Нравится подобный стиль формирования выводов?
M>Именно потому ты так упорно цепляешься строго и исключительно за этот пример, а остальное называешь демагогией.
Я думаю ты знаешь, что в математике наличие даже маленького одиночного контрпримера, полностью опровергают всю предложенную теорию. Так вот реализация данной задачки — это контрпример ко всем твоим размышлениям в первом сообщение темки.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
EL>>В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях. F>а что есть подобного нетривиального?
Я там выше предлагал CM sketch или даже простой параллельный счетчик. Тривиальный параллельный алгоритм, это например embarrassingly parallel задачи, Монте-Карло например, ну или data parallel задачи, это когда данные, с которыми работает процесс, принадлежат этому потоку и никто их больше не трогает. Нетривиальный параллельный алгоритм, это когда данные, к сожалению, не могут принадлежать одному потоку и при этом данные нужно как-нибудь обновлять.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
I>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
I>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения.
Здравствуйте, Mamut, Вы писали:
M>1. Что там за оверхед, известно только тебе
От ненужного кода. Планировщик то никуда не девается, хотя пользы от него тут нет. И т.п.
M>2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял
В том то и дело, что не позволяет — мы это уже увидели на примере. )
_>>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях). M>«Легко», я так предполагаю.
Конечно. Ведь на этой связке (ну плюс ещё CUDA для гетерогенных систем) работает большинство больших вычислительных комплексов.
_>>Я не про это. У тебя в get_index передаётся только элемент списка, но не сам список. Соответственно чтобы такой странный код работал, у тебя внутри get_index должна содержаться ссылка на этот конкретный список L. M>Действительно, раз нет аргументов, придерись к отдельным кускам кода. Хотя я прямым текстом написал, что в Эрланге не получится сделать точно так же, потому что нет такой же структуры данных. И написал что? Ах, да «предположим, что у нас есть функция get_index». Читать? Понимать написанное? Зачем?!
Ты похоже плохо воспринимаешь текст. ) Я же вроде по русски пишу, что претензия не в проблемах с массивами в Эрланге, а в том, что у тебя тут функции get_index передаётся исключительно элемент X, на основе которого она как-то вычисляет его индекс в списке L (не известном ей). Поясни работу эту функции (предполагая, что допустим структура работающая с индексами у тебя есть). Иначе этот твой код не засчитывается за реализацию.
_>>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. M>Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? )
Re[8]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
I>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость.
EL>Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость.
Да, мамут все время говорит только про ту масштабируемость, которая решается переносом на другую машину
Re[9]: Эрланг и все-все-все (на самом деле, не совсем)
I>>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. EL>>Легкость переноса процессов на другие машины вовсе не гарантирует масштабируемость. I>Да, мамут все время говорит только про ту масштабируемость, которая решается переносом на другую машину
Да уж. УРовень твоего понимания печатного текста просто поражает.
Здравствуйте, Mamut, Вы писали:
I>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
M>Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков".
Параллельные задачи это целиком про управление потоками-процессами-задачами.
Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
Потому правильно говорить например про масштабирование, а не абстрактное управление.
M>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения.
Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
Re[31]: Эрланг и все-все-все (на самом деле, не совсем)
M>>1. Что там за оверхед, известно только тебе _>От ненужного кода. Планировщик то никуда не девается, хотя пользы от него тут нет. И т.п.
Угу. Сферовакуумный оферхед из твоих фантазий. mmkay.
M>>2. Система, которая позволяет единообразно работать с потоками/процессами — это плохо, ок, я тебя понял _>В том то и дело, что не позволяет — мы это уже увидели на примере. )
Там решение строго на основе единообразных инструментов, если что. А не в виде «расширения к языку с равным уровнем поддержки в разных компиляторах».
_>>>Если же ты говоришь про взаимодействие моего софта, при его выполнение на нескольких узлах, то это уже действительно моё дело и оно легко реализуется с помощью MPI (инструмент дополняющий OpenMP и SIMD, для полноценного распараллеливания на всех трёх возможных уровнях). M>>«Легко», я так предполагаю.
_>Конечно. Ведь на этой связке (ну плюс ещё CUDA для гетерогенных систем) работает большинство больших вычислительных комплексов.
Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
_>Ты похоже плохо воспринимаешь текст. ) Я же вроде по русски пишу, что претензия не в проблемах с массивами в Эрланге, а в том, что у тебя тут функции get_index передаётся исключительно элемент X, на основе которого она как-то вычисляет его индекс в списке L (не известном ей). Поясни работу эту функции (предполагая, что допустим структура работающая с индексами у тебя есть). Иначе этот твой код не засчитывается за реализацию.
/o\ Просто без комментариев. У него, видите ли, претензия к функции, про котороую сразу написано, что она гипотетическая.
_>>>А это я просто попытался взять пример с тебя) Эрланг же действительно неплох в своей узкой нише. Но ты на основе этого сделал вывод что он хорош вообще в любом многопоточном программирование. M>>Мне еще попрекают, что я обвиняю других в том, что они читать не умеют. А что поделать, если действительно не умеют читать. Вот именно из разряда: вижу текст, пишу ответ по каким-то своим фантазиям, с текстом несвязанным.
_>Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? )
I>>>Мамут в каждом сообщении подразумевает масштабируемость, распределенность и тд. С мутексами всё в порядке до тех пор, пока не понадобится масштабируемость. I>>>Именно это он имеет ввиду, когда дает ссылку на дерево супервизоров.
M>>Когда я даю ссылку на дерево супервизоров, я имею в виду управление потоками/процессами/задачами в первую очередь.
I>И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков". I>Параллельные задачи это целиком про управление потоками-процессами-задачами.
Покажи мне, где у alex_public в его примере управление потоками.
I>Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
Пока что все, что большинство, включая тебя, смогло сказать про управление — это «зачем оно нужно», «не, невозможно», «зачем убивать потоки» и прочее типа «на мьютексах все можно сделать, это как сообщшения»
Хотя, казалось бы, даже без привязки к Эрлангу все было написано в первом же сообщении. Но читать? Думать над написанным? ЗАЧЕМ?!
I>Потому правильно говорить например про масштабирование, а не абстрактное управление.
M>>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения. I>Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
Там действительно все просто. Просто ты не делаешь даже попыток понять, что там написано. Плюс зашоренность.
Здравствуйте, Mamut, Вы писали:
M>Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
Ну давай проверим, чего там. Придумаем простецкий воркфлоу, что бы была польза от эти десятка потоков-процессов, ну скажем, конвертацию из одного формата в другой. Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд. Ну и основной контекст это оффлайн, юзеры просят, аж пищат.
Для андройда кстати очень актуальная проблема — там очень сложно всё с потоками, Эрланг ажно просится.
Плагин простой — встраивается в UI и показывает прогресс этих самых задач.
Валяй, покажи чем ты тут науправляешь и сколько десятков лет или столетий у тебя уйдет на то, что бы всунуть Эрланг в классические десктоп и мобайл приложения.
Код писать не нужно, просто объясни внятно, без идиотии в духе "вот ссылка на дерево супервизоров"
Re[10]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали:
I>>И когда тебе напоминают про параллельные задачи, ты тут же начинаешь стенать "снова 100500 потоков". I>>Параллельные задачи это целиком про управление потоками-процессами-задачами.
M>Покажи мне, где у alex_public в его примере управление потоками.
Запустить, выбрать все физические ядра, выполнить, собрать результаты, остановить.
I>>Скажем, системно-зависимый функционал, он тоже про такое управление. Но внезапно, эрланг уже не может в силу ряда причин — например потому, что в ОС целый вагон блокирующих вызовов из за того, что куча объектов прибито гвоздями к физическому потоку.
M>Пока что все, что большинство, включая тебя, смогло сказать про управление — это «зачем оно нужно», «не, невозможно», «зачем убивать потоки» и прочее типа «на мьютексах все можно сделать, это как сообщшения»
Ты прямо про себя пишешь, с небольшой разницей, если поменять мутексы на супервайзеры. Для чего нужно управление такое, тебе еще предстоит открыть.
M>Хотя, казалось бы, даже без привязки к Эрлангу все было написано в первом же сообщении. Но читать? Думать над написанным? ЗАЧЕМ?!
Над всяким говном никто в своём уме думать не будет.
M>>>Заметно, как ты понимаешь, что я пишу, несмотря на максмально простой стиль изложения. I>>Я и говорю — ты объясняешь сам себе, потому всё кажется просто.
M>Там действительно все просто. Просто ты не делаешь даже попыток понять, что там написано. Плюс зашоренность.
Я уже давно замечаю, когда основной аргумент "там всё просто", то всегда кругозор с игольное ушко.
Скажу страшное — простота меряется не в количестве строчек текста и даже не в строчках на Эрланге.
Re[7]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, BulatZiganshin, Вы писали:
BZ>я в своё время недоумённо спрашивал, откуда у вас, сишников, проблемы многопоточности — на хаскеле их у меня не было. при message passing approach ошибки синхронизации просто отсутствуют. на самом деле в реальной программе у меня есть несколько раздляемых ресурсов, но их так мало, что контролировать несложно. скажем, обращение к выходному файлу я просто обернул в мьютекс и потому разные потоки в принципе не могут его делать одновременно
Элементарно, Ватсон!
Первый вариант программы скорее всего не содержит ошибок синхронизации: инварианты учтены, шареные данные синхронизированы правильно (места возможных гонок и дедлоков просмотрены), а потом, в процессе развития программы (или в процессе багфиксов) допишет что-нибудь вот такое:
private volatile m_sumThingEnabled
public bool IsSumThingEnabled
{
get{ return m_sumThingEnabled;}
set
{
m_sumThingEnabled = value;
OnChangedEnabledSomthing();
}
}
не учтя при этом, что свойство из другого потока может быть изменено, и всё — привет отладка логированием.
Ясен пень, что этот пример взят с потолка, но суть проблемы он в принципе демонстрирует.
Всё сказанное выше — личное мнение, если не указано обратное.
Re[33]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Ну давай проверим, чего там. Придумаем простецкий воркфлоу, что бы была польза от эти десятка потоков-процессов, ну скажем, конвертацию из одного формата в другой.
Зачем ковертацию? Это опять же получится числодробилка, где несколько параллельных процессов порождаются, обслуживают некоторые вычислительные задачи и дохнут безо всякого управления. Интереснее было бы, если бы каждый процесс получал некоторые данные извне (можно эмулировать через ГСЧ для простоты), анализировал их и в зависимости от результата решал, что ему делать дальше:
— завершиться штатно
— сдохнуть аварийно
— запустить N дочерних процессов и опрашивать их при дальнейшем анализе
— притормозить на время и известить об этом родителя
— грохнуть принудительно всех детей
— и т.п.
Я ж так понимаю Мамут в своих спичах делает упор на легкость именно управления процессами, а не тупо их создания в количестве "дофига штук". А легкость управления лучше всего проверяется его многообразием.
Ку...
Re[35]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, so5team, Вы писали:
S>Фокус в том, что реализации actor model для других языков уже предоставляют готовые инструменты для этого (в Akka и C++ Actor Framework чуть ли не 1-в-1 слизано из Erlang-а, в SObjectizer чуть-чуть иначе, собственно, вот пример). Только это не является частью языка, а сделано в виде библиотек. Потому и игнорируется Mamut-ом.
Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга) и утверждает, что на специализированном языке то же самое можно сделать проще и красивее. Сам я, как человек далекий от сложных распределенных вычислений, в этом совершенно не копенгаген, но интуиция мне подсказывает, что лучше всего такие вещи обсуждать на примерах. Ну а раз уж в плане утверждений Мамута никто за язык не тянул — то и примеры, получается, тоже с него.
Ку...
Re[36]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Пацак, Вы писали:
П>Опять же, насколько я понял из диагонального прочтения темы, оно не совсем игнорируется — просто Мамут считает это изобретением восьмиколесного велосипеда без педалей (aka половины эрланга) и утверждает, что на специализированном языке то же самое можно сделать проще и красивее.
Так кто ж спорит с тем, что если язык заточен под конкретную задачу, то эта задача будет воплощена на этом языке с минимальными усилиями?
Проблема в том, что есть языки общего назначения, которые предназначены для более широкого круга задач. И как раз в силу своей универсальности они и не тянут в себя всего, а позволяют сторонним разработчикам делать недостающие инструменты в виде библиотек. Как показывает практика, работает это весьма неплохо.
Особую пикантность спору придает то, что Erlang довольно специфичен и если выйти за рамки комфортной для него ниши, например, пробовать сделать на Erlang-е тяжелый расчет, в котором используются расшаренные между несколькими потоками данные, то окажется, что это сделать не так то и просто. Даже потому, что в Erlang-е нет такого понятия, как массив с прямым доступом по индексу. Не говоря уже про расшаренные (да еще и не дай Бог) мутабельные данные. Т.е. пока на Erlang-е делаешь то, для чего он предназначен, то все хорошо. Но шаг влево, шаг вправо и все. Тогда как другие языки, которые противопоставляются Erlang-у, позволяют двигаться в более широких пределах. И как раз из-за необходимости двигаться в более широких пределах в этих языках (особенно если речь идет об императивных, вроде Java и C#, и уж тем более об императивных и нативых, вроде C++/Eiffel/Ada) нельзя внедрить модель конкурентности из Erlang-а на уровне стандарта языка.
Об этом Mamut-у неоднократно намекали с разной степенью прозрачности. Но все как горохом об стенку.
Re[33]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд.
встраивай VM, как JS, и вперёд.
скорей всего придётся сделать свою VM, т.к. дефолтную под это использовать будет странно.
странно предлагать энларг для таких вещей. это же фреймворк, по сути.
да, его можно использовать для широкого круга задач из бэкенда, но использовать его, как язык общего назначения, глупо.
by design, как говорится.
...coding for chaos...
Re[8]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Философ, Вы писали:
Ф>не учтя при этом, что свойство из другого потока может быть изменено, и всё — привет отладка логированием. Ф>Ясен пень, что этот пример взят с потолка, но суть проблемы он в принципе демонстрирует.
по ходу срача я так понял, что предлагается такого просто не делать
как и баги вообще.
...coding for chaos...
Re[37]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>на нативных языках это невозможно без поддержки ядра. потому что нужны метрики для рассчёта затрат процессора(а эрланг это делает ровно так же, как и питон: через подсчёт действий интерпретатора), чтобы можно было балансить шедулером(системным али нет) лёгкие потоки. с поддержкой этого в ядре проблема нивелируется.
1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду.
2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
Re[32]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Mamut, Вы писали: M>Угу. Сферовакуумный оферхед из твоих фантазий. mmkay.
Аргументированно. ))) M>Там решение строго на основе единообразных инструментов, если что. А не в виде «расширения к языку с равным уровнем поддержки в разных компиляторах».
Ну да, только оно не работает. ) M>Что делать, если у меня не «вычислительный комплекс»? Что, если я хочу просто запустить десяток потоков/процессов? Ах да, я помню. «проще несколько catch'ей ручками расставить», ага
Десяток потоков — это что конкретно? ) Вот скажем если мы возьмём десктопные или мобильные приложения (по задачам многопоточности они не особо отличаются), то там обычно требуется что-то вроде главного потока (в котором весь GUI), переодически запускающего несколько фоновых. Так такие вещи реализуются вообще абсолютно тривиально, т.к. у нас есть в языке поддержка системных потоков, а вместе с GUI библиотекой автоматом получаем готовую очередь у главного потока. В итоге даже не надо ставить какие-то крутые библиотеки, а можно просто писать так:
Скрытый текст
class MyWindow: public Window{
Button start_button, stop_button;
Editbox adress;
Textbox output;
public:
MyWindow()
{
start_button.Connect(ClickEvent, [&]{//Connect - функция из GUI библиотеки
start_button.Enable(false);
thread([&, url=adress.text()]{//thread - класс из стандартной библиотеки C++try{
auto cancel=Cancel();
PostMessage(ThreadEvent, MakeMessage(Message::Start, cancel));//PostMessage - функция из GUI библиотекиauto data=DownloadFile(url, cancel);//наша длительная блокирующая фоновая операция
PostMessage(ThreadEvent, MakeMessage(Message::End, data));
}catch(exception& e){
PostMessage(ThreadEvent, MakeMessage(Message::Error, e));
}
}).detach();
});
Connect(ThreadEvent, [&](auto message){
switch(message.id){
case Message::Start:
stop_button.Connect(ClickEvent, [&, cancel=message.Get<Cancel>()]{
stop_button.Enable(false);
cancel();
});
stop_button.Enable();
break;
case Message::End:
output<<message.Get<string>();
start_button.Enable();
stop_button.Enable(false);
break;
case Message::Error:
MessageBox("Error", message.Get<exception>().what());
start_button.Enable();
stop_button.Enable(false);
}
});
}
};
Причём это ещё считай пример на голом C++, т.е. без подключения крутых библиотек многопоточности и без линеаризации кода через сопрограммы. С этим всем код ещё сократился бы раз в два при той же функциональности. ) Ну так и какие проблемы ты видишь здесь? ) M>/o\ Просто без комментариев. У него, видите ли, претензия к функции, про котороую сразу написано, что она гипотетическая.
ОК, мы уже поняли, что решения на Эрланге предложенной мною простейшей задачки на многопоточность не существует. _>>Т.е. ты согласен, что Эрланг полезен (и то если скорость разработки важнее расходов на железо) только для узкой ниши высоконагруженных серверов? ) M>Нет.
Хм, тогда поясни подробнее свою точку зрения. От претензии на универсальное решение в многопоточности ты вроде как уже отказался. Но при этом и нишевость не признаешь. Тогда что? )
Re[34]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
I>>Вот смотри — надо наклепать плагинчик для офиса какого, что бы работал у вындоусе ин-процес или на андройде и тд.
F>встраивай VM, как JS, и вперёд. F>скорей всего придётся сделать свою VM, т.к. дефолтную под это использовать будет странно.
Предполагалось что ответ будет давать Мамут
Re[38]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
Целевая область будет меняться в зависимости от того, как хорошо ты сможешь шедулить. На ЯП общего назначения типичный код может и не делать никаких библиотечных вызовов долгое время.
Кроме того, в таких языках пока не ясно, чем обеспечить гарантии, что глобальное состояние юзается корректно.
Re[38]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду.
и получается ситуация наоборот. т.е. совсем не то.
EP>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)?
это зависит от того, насколько ты считаешь себя умней шедулера.
да и как по yield'ам ты будешь оценивать затраты времени?
...coding for chaos...
Re[39]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>и получается ситуация наоборот. т.е. совсем не то.
Что значит наоборот, и почему не то?
EP>>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)? F>это зависит от того, насколько ты считаешь себя умней шедулера.
В каком смысле?
Во всех примерах что я видел на Erlang — расстояние между библиотечными вызовами минимальное — получили сообщение, на его основе выбрали следующее действие, создали и отправили новое сообщение, либо сделали какой-то вызов. Если такой сценарий не типичный для реального кода, то хотелось бы увидеть код с типичным сценарием.
F>да и как по yield'ам ты будешь оценивать затраты времени?
Например через какой-нибудь performance counter или cycle counter.
Re[39]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, в таких языках пока не ясно, чем обеспечить гарантии, что глобальное состояние юзается корректно.
1. Инструкцией программистам "глобальное состояние не менять".
2. Проверять наличие глобального состояния через символы в объектных файлах, и выдавать ошибку при наличии оного.
3. Верификатор кода запрещающий часть языковых конструкций, например на базе Clang AST Matcher.
4. Опциональная защита страниц (а-ля PAGE_NOACCESS) не относящихся к текущему процессу.
5. Генерация компилятором соответствующих проверок, либо маскирование любого доступа к памяти (то есть вместо *p будет что-то типа current_process_memory[index_p & 0x400], либо исползование индексов ограниченной разрядности).
Re[40]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>>и получается ситуация наоборот. т.е. совсем не то. EP>Что значит наоборот, и почему не то?
афаик в эрланге шедулер останавливает потоки, а не потоки решают, когда им отдать управление.
потому что управлять очередью инструкций к интерпретатору легко.
в питоне, кстати, тоже передача управления между тредами определяется количеством инструкций. я уже писал об этом где-то выше.
EP>>>2. Учитывая целевую область применения, насколько это вообще необходимо? То есть недостаточно ли будет тех yield'ов которые внутри библиотечных вызовов (типа async_read, receive и т.п.)? F>>это зависит от того, насколько ты считаешь себя умней шедулера. EP>В каком смысле?
если ты изнутри кода отдаёшь управление, то ты берёшь работу шедулера на себя.
можно этого не делать.
EP>Во всех примерах что я видел на Erlang — расстояние между библиотечными вызовами минимальное — получили сообщение, на его основе выбрали следующее действие, создали и отправили новое сообщение, либо сделали какой-то вызов. Если такой сценарий не типичный для реального кода, то хотелось бы увидеть код с типичным сценарием.
затрудняюсь назвать типичный сценарий, т.к. у меня местами большие блоки кода.
F>>да и как по yield'ам ты будешь оценивать затраты времени? EP>Например через какой-нибудь performance counter или cycle counter.
yield'ы же у тебя изнутри кода дёргаются.
а тебе надо снаружи хоть по тем же счётчиками (кстати, что за cycle counter? откуда он?) прервать выполнение. чтобы поток не смог зависнуть.
это если мы говорим о более-менее здоровой реализации, а не о соглашениях на проекте.
...coding for chaos...
Re[41]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>>>1. Это реализуется без модификации ядра — например компилятор расставляет соответствующие счётчики/yield'ы по коду. F>>>и получается ситуация наоборот. т.е. совсем не то. EP>>Что значит наоборот, и почему не то? F>афаик в эрланге шедулер останавливает потоки, а не потоки решают, когда им отдать управление. F>потому что управлять очередью инструкций к интерпретатору легко.
А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции.
F>>>да и как по yield'ам ты будешь оценивать затраты времени? EP>>Например через какой-нибудь performance counter или cycle counter. F>yield'ы же у тебя изнутри кода дёргаются. F>а тебе надо снаружи хоть по тем же счётчиками прервать выполнение. чтобы поток не смог зависнуть.
Если именно нужно прерывать по счётчикам — то смотри пункт 1. Другой вариант — отдельный watchdog поток.
F>(кстати, что за cycle counter? откуда он?)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>потому что управлять очередью инструкций к интерпретатору легко. EP>А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции.
да, если только с помощью генерёжки где-то на уровне инструкций процессору.
теперь осталось реализовать тот самый soft-realtime(т.е. прерывание ожидания ответа по таймеру) и своя половина эрланга с менее удобным, но более быстрым языком у нас готова.
F>>(кстати, что за cycle counter? откуда он?) EP>https://en.wikipedia.org/wiki/Time_Stamp_Counter
о_О никогда б не догадался.
...coding for chaos...
Re[43]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>>>потому что управлять очередью инструкций к интерпретатору легко. EP>>А в чём здесь принципиальная разница? Считай что инструкции расставленные компилятором относятся к планировщику, то есть его код interleaved с пользовательским кодом на этапе компиляции. F>да, если только с помощью генерёжки где-то на уровне инструкций процессору.
Да, об этом и речь.
F>и своя половина эрланга с менее удобным
Насколько я вижу, основное удобство в Erlang это Pattern Matching (в C++ PM по типам реализуется легко, так как уже встроено в компилятор, а вот PM по выражениям/значениям — да, сложнее и не удобно).
А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее.
Re[44]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее.
имея опыт в программировании от stl до хаскела, скажу что чем высокоуровневей язык, тем удобней и надёжней программирование, особенно в многопоточной среде кстати. при описании сложных алгоритмов обработки данных stl всё ещё втрое уступает хаскелу по объёму кода (довелось недавно один модуль переписать..)
Люди, я люблю вас! Будьте бдительны!!!
Re[44]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>и своя половина эрланга с менее удобным EP>Насколько я вижу, основное удобство в Erlang это Pattern Matching (в C++ PM по типам реализуется легко, так как уже встроено в компилятор, а вот PM по выражениям/значениям — да, сложнее и не удобно).
да, это удобство от динамической типизации.
EP>А вот например "чистота" и иммутабельность внутри тел функций — это скорее минус, императивный код и проще и удобнее.
дело привычки. меня это уже не беспокоит.
куда больше угнетает отсутствие композиции, как в хакселе, и необходимость писать кучу скобок.
...coding for chaos...
Re[46]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
F>>>и своя половина эрланга с менее удобным EP>>Насколько я вижу, основное удобство в Erlang это Pattern Matching (в C++ PM по типам реализуется легко, так как уже встроено в компилятор, а вот PM по выражениям/значениям — да, сложнее и не удобно). F>да, это удобство от динамической типизации.
Насколько я вижу, динамическая типизация тут ни при чём, это реализуется и в статической. То есть сообщение с полностью стёртым типом, можно сопоставлять со статически типизированными шаблонами/patterns, получая на выходе значение статически типизированное с точностью до типизации шаблона (для шаблона вида ((char, _), int, double), получим значение типа tuple<tuple<char, any>, int, double>).
Кстати, а насколько оправданны сообщения со стёртыми типами? Не лучше ли будет статическое описание возможных типов сообщений для процесса а-ля variant?
Re[47]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
BZ>>>особенно в многопоточной среде кстати. EP>>Какая разница мутируем ли мы локальные переменные функций? F>а какие языки позволяют мутировать только локальные переменные?
Например в Haskell есть ST Monad, которая в определённом смысле позволяет мутировать локальные переменные в ограниченной области видимости, при этом возвращая чистый результат. Конечно неудобно, через многоэтажные замыкания (скрытые под синтаксических сахаром do), но всё же позволяет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например в Haskell есть ST Monad, которая в определённом смысле позволяет мутировать локальные переменные в ограниченной области видимости, при этом возвращая чистый результат. Конечно неудобно, через многоэтажные замыкания (скрытые под синтаксических сахаром do), но всё же позволяет.
монады — это боль хаскелекода.не дай б-г ты вляпался в одну из них. и всё. тяни её до самого верха.
так что я не соглашусь. там ты мутируешь не столько локальные переменные, сколько целую ветку ф-ций и вычислений.
поэтому шутка про "тридэ-экшон в три строки" — это нифига не шутка.
...coding for chaos...
Re[47]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>Насколько я вижу, динамическая типизация тут ни при чём, это реализуется и в статической. F>в статике сложнее сопоставить туплы, которые в эрланге повсюду. плюс вложенность.
Вложенность тоже не проблема.
F>в статике одна ф-ция с кучей разномастных по типам реализаций расползётся куда сильнее.
Разные реализации-то не на ровном месте появились — а от того что для самой задачи требуется разная обработка. Если не требуется, то есть же шаблоны.
F>а в динамике достаточно соблюдать арность ф-ции.
"перегрузки", только реализованные вручную, а не компилятором.
F>вдобавок без типов код пишется на порядок быстрее. в том же хаскеле или скалке подгон типов под решение занимает кучу времени.
В C++ с этим намного проще чем в Haskell, так как типы выводятся по месту использования, эдакий duck-typing, получается прям как в динамически типизированных языках (правда с вытекающими отсюда подобными проблемами, только в compile-time).
EP>>Кстати, а насколько оправданны сообщения со стёртыми типами? Не лучше ли будет статическое описание возможных типов сообщений для процесса а-ля variant? F>большинство сообщений уникальны. плодить для них одноразовые типы — это лишняя работа. поэтому даже местные структуры используются в основном для состояний.
В тех случаях где стоит выбор между структурой и безликим кортежем — я предпочту структуру. Описать её это секундное дело, выразительность увеличивается (например именованные поля), плюс есть возможность посылать разные сообщения с одинаковыми наборами полей. В Erlang'е же, как я понял, для этого используются атомы, то есть по сути получаются именованные структуры с безымянными полями — poor man's struct.
F>по мне лучше тесты. правда в эрланге с ними очень плохо, потому что поднимать всё дерево процессов долго и неудобно.
Даже 100% покрытие тестами (по строчкам кода) не гарантирует того что отловлены все ошибки с типами. Более того, думаю в общем случае при динамической типизации такую гарантию вообще невозможно получить.
При статической же типизации отлавливается целый класс ошибок, практически бесплатно.
Re[49]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>Например в Haskell есть ST Monad, которая в определённом смысле позволяет мутировать локальные переменные в ограниченной области видимости, при этом возвращая чистый результат. Конечно неудобно, через многоэтажные замыкания (скрытые под синтаксических сахаром do), но всё же позволяет. F>монады — это боль хаскелекода.не дай б-г ты вляпался в одну из них. и всё. тяни её до самого верха.
Это если какая-нибудь IO. В случае с ST есть runST — таким образом как раз реализуется сценарий "внутри функции мутации локальных переменных, а наружу выдаётся чистый немонадный результат".
F>так что я не соглашусь. там ты мутируешь не столько локальные переменные, сколько целую ветку ф-ций и вычислений.
Вот пример:
sumST :: Num a => [a] -> a
sumST xs = runST $ do-- runST takes out stateful code and makes it pure again.
n <- newSTRef 0 -- Create an STRef (place in memory to store values)
forM_ xs $ \x -> do-- For each element of xs ..
modifySTRef n (+x) -- add it to what we have in n.
readSTRef n -- read the value of n, and return it.
Здесь мутируется как раз "локальная переменная", а не ветка функций.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>в статике одна ф-ция с кучей разномастных по типам реализаций расползётся куда сильнее. EP>Разные реализации-то не на ровном месте появились — а от того что для самой задачи требуется разная обработка. Если не требуется, то есть же шаблоны.
это больше похоже на перегрузку виртуальных методов или, действительно, шаблоны. только более выразительно.
F>>а в динамике достаточно соблюдать арность ф-ции. EP>Так там появляются точно такие же
"перегрузки", только реализованные вручную, а не компилятором.
фуууу!
EP>В тех случаях где стоит выбор между структурой и безликим кортежем — я предпочту структуру.
попытайся поюзать "безликие кортежи". очень быстро поймёшь преимущества.
EP>Описать её это секундное дело
поменять уже сложнее.
EP>выразительность увеличивается (например именованные поля)
для 2-3 полей это совершенно неважно.
EP>плюс есть возможность посылать разные сообщения с одинаковыми наборами полей.
оно и так есть. если чего-то не лезет, то сделать ещё вложенность.
EP>В Erlang'е же, как я понял, для этого используются атомы, то есть по сути получаются именованные структуры с безымянными полями
именованные туплы. атом — это тип.
это тоже довольно интересная находка. особенно в плане их обработки. много ф-ций заточено именно под именованные туплы.
EP>poor man's struct.
ага, мапы — это классы для бедных, а классы — это мапы для бедных.
F>>по мне лучше тесты. правда в эрланге с ними очень плохо, потому что поднимать всё дерево процессов долго и неудобно. EP>Даже 100% покрытие тестами (по строчкам кода) не гарантирует того что отловлены все ошибки с типами.
особенно, если типов нет.
я покрываю тестами фичи, а не строчки. поэтому мне нужно, чтобы конкретная ветка вычислений работала на всех ожидаемых входных данных.
EP>При статической же типизации отлавливается целый класс ошибок, практически бесплатно.
и вводится новый класс ошибок компиляции. чтоб жизнь мёдом не казалась.
когда оно тебе помогало?
я часто слышу о пользе, даже приводят примеры, но меня оно ещё ни разу не спасало. т.е. вообще.
...coding for chaos...
Re[50]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это если какая-нибудь IO. В случае с ST есть runST — таким образом как раз реализуется сценарий "внутри функции мутации локальных переменных, а наружу выдаётся чистый немонадный результат".
да, спутал. у меня другая монада была.
...coding for chaos...
Re[49]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>В тех случаях где стоит выбор между структурой и безликим кортежем — я предпочту структуру. F>попытайся поюзать "безликие кортежи". очень быстро поймёшь преимущества.
Использовал, и в Python, и в C++. Преимущества вижу только внутри какого-нибудь метапрограммирования, там где у нас действительно набор безликих полей.
Например в C++ STL в некоторых местах используется pair, причём по смыслу там не просто пара безликих элементов, а у каждого элемента своё особое предназначение.
std::pair<iterator, bool> std::set::insert( const value_type& value );
Постоянно приходится вспоминать какой там порядок элементов в этой паре. Хорошо хоть типы есть, да.
EP>>Описать её это секундное дело F>поменять уже сложнее.
Намного проще чем сообщения-кортежи, так как компилятор поможет найти все ссылающиеся места.
EP>>выразительность увеличивается (например именованные поля) F>для 2-3 полей это совершенно неважно.
Если сам придумал, сразу же использовал и забыл — то может и неважно. В других же случаях даже с парами возникают неудобства — пример выше.
EP>>В Erlang'е же, как я понял, для этого используются атомы, то есть по сути получаются именованные структуры с безымянными полями F>именованные туплы. атом — это тип. F>это тоже довольно интересная находка.
Насколько я понял, атом же по сути это строка, которую в некоторых случаях можно писать без кавычек.
EP>>При статической же типизации отлавливается целый класс ошибок, практически бесплатно. F>и вводится новый класс ошибок компиляции. чтоб жизнь мёдом не казалась. F>когда оно тебе помогало?
Постоянно. Да, с помощью тестов можно отловить подобные ошибки, но при статической типизации обнаружение происходит намного раньше, плюс я могу себе позволить не писать юнит-тесты для простых/очевидных/тривиальных вещей.
Re[50]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>попытайся поюзать "безликие кортежи". очень быстро поймёшь преимущества. EP>Использовал, и в Python, и в C++. Преимущества вижу только внутри какого-нибудь метапрограммирования, там где у нас действительно набор безликих полей. EP>Постоянно приходится вспоминать какой там порядок элементов в этой паре. Хорошо хоть типы есть, да.
по мне, проблема столь же надуманна, как и то, что забудешь, какого типа у тебя переменная, и, мол, поэтому надо использовать венгерку.
тут всё решение в понятных именах переменных. не TempPair, а IdToUser.
EP>>>Описать её это секундное дело F>>поменять уже сложнее. EP>Намного проще чем сообщения-кортежи, так как компилятор поможет найти все ссылающиеся места.
наверное, это единственная проблема. но больше связана с динамикой, чем с безликими кортежами.
решается анализаторами. костыльно, да.
EP>Если сам придумал, сразу же использовал и забыл — то может и неважно. В других же случаях даже с парами возникают неудобства — пример выше.
возможно дело в том, что твои пары потом ещё долго обрабатываются.
в случае же эрланга очень быстро происходит передача кортежей в вызовы. а там уже можно по сигнатуре посмотреть, что да как.
я так всё меньше смотрю на код и всё больше на имена переменных и сигнатуры ф-ций.
EP>Насколько я понял, атом же по сути это строка, которую в некоторых случаях можно писать без кавычек.
это не строка. атом — это специальный тип, который пишется в апострофах только, если выбивается за разрешённый формат. например atom против '$ATOM'
атомы хранятся в специальной таблице на протяжении всей жизни приложения. и количество их ограничено настройкой VM. поэтому генерить атомы противопоказано.
EP>Постоянно. Да, с помощью тестов можно отловить подобные ошибки, но при статической типизации обнаружение происходит намного раньше, плюс я могу себе позволить не писать юнит-тесты для простых/очевидных/тривиальных вещей.
а я не могу позволить не писать тесты для каких-то случаев.
потому что типы типами, а глупость или невнимательность своё возьмут.
...coding for chaos...
Re[51]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
EP>>Постоянно приходится вспоминать какой там порядок элементов в этой паре. Хорошо хоть типы есть, да. F>по мне, проблема столь же надуманна, как и то, что забудешь, какого типа у тебя переменная, и, мол, поэтому надо использовать венгерку. F>тут всё решение в понятных именах переменных. не TempPair, а IdToUser.
Так об этом и речь, вместо внятных имён получаем невнятные .first и .second.
EP>>Если сам придумал, сразу же использовал и забыл — то может и неважно. В других же случаях даже с парами возникают неудобства — пример выше. F>возможно дело в том, что твои пары потом ещё долго обрабатываются.
В каком смысле?
F>в случае же эрланга очень быстро происходит передача кортежей в вызовы. а там уже можно по сигнатуре посмотреть, что да как.
По какой сигнатуре?
F>я так всё меньше смотрю на код и всё больше на имена переменных и сигнатуры ф-ций.
Имён-то у полей внутри кортежа нет.
EP>>Насколько я понял, атом же по сути это строка, которую в некоторых случаях можно писать без кавычек. F>это не строка. атом — это специальный тип, который пишется в апострофах только, если выбивается за разрешённый формат. например atom против '$ATOM'
Это понятно, я о том что семантически это очень близко к обычной строке.
EP>>Постоянно. Да, с помощью тестов можно отловить подобные ошибки, но при статической типизации обнаружение происходит намного раньше, плюс я могу себе позволить не писать юнит-тесты для простых/очевидных/тривиальных вещей. F>а я не могу позволить не писать тесты для каких-то случаев. F>потому что типы типами, а глупость или невнимательность своё возьмут.
Код-то весь будет тестироваться, я имею в виду что для простых случаев можно обойтись только укрупнённым интеграционным тестированием, без юнит-тестов.
Re[52]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
F>>тут всё решение в понятных именах переменных. не TempPair, а IdToUser. EP>Так об этом и речь, вместо внятных имён получаем невнятные .first и .second.
ну, это у тебя.
а у меня автоимён совсем нет, поэтому надо самому нормально их называть.
F>>в случае же эрланга очень быстро происходит передача кортежей в вызовы. а там уже можно по сигнатуре посмотреть, что да как. EP>По какой сигнатуре?
по сигнатуре ф-ции. там всё видно.
F>>я так всё меньше смотрю на код и всё больше на имена переменных и сигнатуры ф-ций. EP>Имён-то у полей внутри кортежа нет.
имена нужны при отправлении и получении. а промежуточные имена не нужны.
EP>Это понятно, я о том что семантически это очень близко к обычной строке.
уникальный строковый идентификатор, да.
...coding for chaos...
Re[44]: Эрланг и все-все-все (на самом деле, не совсем)
F>афаик в эрланге шедулер останавливает потоки, а не потоки решают, когда им отдать управление.
Так и есть. Каждому процессу выдается 1000 редукций (настраиваемо). Редукция — это вызов функции, посылка сообщения. Когда количество редукций доходит до нуля, процесс выталкивается в конец очереди, и начинает исполняться другой процесс.
Некоторые специальные процессы (типа IO) могут планировщиком насильно передвигаться вперед по очереди, потому что IO в Erlang'е приоритизировано.
Здравствуйте, Mamut, Вы писали:
M>Сильно зависит от алгоритмов. Есть алгоритмы, которые проще и удобнее в императивщине, есть которые в функциональщине.
Да, но в императивном коде можно ограничить себя чистым подмножеством, а в функциональном использовать императив намного труднее (монады с многоэтажными замыканиями)
M>Для 90% быдлокода, что мы все тут в основном пишем, функциональщина выигрывает по простоте и удобности, имхо.
Надо определится с терминами. Многие считают что ФП это "я тут замыкания заиспользовал" — в то время как подобные фичи ортогональны "ФП vs ИП", и присутсвуют и там и там (даже в древнем Smalltalk были замыкания).
Re[46]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
M>>Сильно зависит от алгоритмов. Есть алгоритмы, которые проще и удобнее в императивщине, есть которые в функциональщине. EP>Да, но в императивном коде можно ограничить себя чистым подмножеством, а в функциональном использовать императив намного труднее (монады с многоэтажными замыканиями)
На самом деле многие базовые вещи в синтаксисе Эрланга идут совсем не из функциональщины, а из логического программирования. Но к сожалению они их так кастрировали (кстати как раз раз попыткой подвинуться в сторону функциональщины), что почти все фантастические бонусы исчезли. Мы тут используем в одном проекте полноценный Пролог и работа с ним доставляет только удовольствие. Но почти ничего из его главных возможностей не сохранено в Эрланге. Там это всё обрезали, сохранив только визуальные элементы синтаксиса. Так что даже наличие атомов в Эрланге не имеет особого смысла, в отличие от Пролога.
Понятно, что это относится не только к С++.
