Здравствуйте, 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[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[13]: Эрланг и все-все-все (на самом деле, не совсем)
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[14]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
F>>за исключением проблемы с локами. EL>А что еще за проблема с локами? Может кто-то просто не умеет ими пользоваться?
это проблема технологии в конце концов
...coding for chaos...
Re[13]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, neFormal, Вы писали:
BZ>>разница в целях. при параллельном программировании целью является более быстрая программа чем однопоточная. поэтому интерпретаторы здесь не канают, и поэтому эрланга нету на gpu,
F>да это понятно. просто терминология не очень. F>как будто конкурентность должна быть без параллельности. F>а по сути одно является подмножеством другого. что-то навроде наследования между квадратом и прямоугольником.
Это два независимых подхода, которые дополняют друг друга.
Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.
Re[14]: Эрланг и все-все-все (на самом деле, не совсем)
Здравствуйте, ELazin, Вы писали:
F>>как будто конкурентность должна быть без параллельности. EL>не должна а может
по ходу обсуждения их чуть ли не противопоставляют.
а так да — может, но не должна.
EL>если бы Erlang мог работать только на одном ядре им все равно пользовались бы
разве только в телекоме.
...coding for chaos...
Re[15]: Эрланг и все-все-все (на самом деле, не совсем)
