Здравствуйте, neFormal, Вы писали:

F>да это понятно. просто терминология не очень.

дело привычки

F>как будто конкурентность должна быть без параллельности.

большую часть жизни и была. erlang 30 лет прожил без smp, windows — 10 лет

Здравствуйте, Ikemefula, Вы писали:

I>Это два независимых подхода, которые дополняют друг друга.

не сказал бы, что они независимы. но дополняют.

I>Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.

думаю, возникло расхождение в понимании целей.
кому-то нужно посчитать быстро результат, а кому-то управлять кучей состояний.
поэтому первым важна производительность(где эрланг проигрывает), а вторым — удобство использования и поддержки.

Здравствуйте, Mamut, Вы писали:

MD>>В общем, многопоточность давно уже не требует ручного управления потоками на большом числе языков. Просто инерция мышления загоняет большинство народа в старые рамки: для легковесных потоков есть Эрланг, и только он.

M>Что по-твоему является управлением потоками?

Забавно, как ты меняешь формулировки. Месяц назад я сам объяснял тебе, что основа Эрлага это именно управление нативными потоками. У тебя были в основном общие фразы "Эрланг он не о том".

А теперь, смотрю, ты сам в этом разобрался и суешь это управление в каждое сообщение.

Здравствуйте, Mamut, Вы писали:

M>>>>>Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?

M>Они прекрасно относятся к подавляющему большинству. Можешь еще раз ответить на поставленный вопрос.

уже интересно. а можешь называть какие ещё языки кроме эрланга не относятся к этому подавляющеему большинству???

Здравствуйте, Mamut, Вы писали:

I>>Просто когда у некоторых персонажей в руках Эрлангмолоток , то им все кажется гвоздями.

M>Тут пока что некоторые персонажи не могут понять, что такое управлять потоками/процессами/задачми, а все ту да же — «ненужно».

А чего удивляться, если всего месяц назад тебе объяснял, что Эрланге основной тренд был и есть управление потоками-задачами и тд.

Так что да, кое кто очень плохо умеет читать, только почему то приписывает это свойство окружающим.

Здравствуйте, ELazin, Вы писали:

F>>это проблема технологии в конце концов
EL>это не ответ на вопрос

почему же?
люди пользуются GC не потому же, что не умеют вручную чистить память
защита от ошибок на уровне технологии — это обычное дело

M>>Что по-твоему является управлением потоками?
I>Забавно, как ты меняешь формулировки. Месяц назад я сам объяснял тебе, что основа Эрлага это именно управление нативными потоками.

Ахахахахаха. Ну не позорься же так

I>У тебя были в основном общие фразы "Эрланг он не о том". А теперь, смотрю, ты сам в этом разобрался и суешь это управление в каждое сообщение.

Специально для тебя, который тут обижается, что я его обвиняю, что он не умеет читать:

Дальше в топике я называю потоками и потоки и корутины и легковесные процессы.

Здравствуйте, BulatZiganshin, Вы писали:

BZ>erlang 30 лет прожил без smp

20

Здравствуйте, neFormal, Вы писали:

EP>>>>Густо-негусто, но стартовый тезис это разбивает в пух и прах:
F>>>за исключением проблемы с локами.
EP>>Какой проблемы, и с какими именно локами?
F>что можно внести туда локи и всё поломать.

1. А зачем их туда вносить?
2. Как-будто native модуль в Erlang'е не может "внести туда локи и всё поломать".

F>впрочем, с плюсами поломать можно и так всё очень просто.

Это ортогонально.

EP>>Буквально с первых страниц этой темы (подобное было и в предыдущей):
F>некоторое подмножество задач многопоточности можно решить и классическими методами.
F>кто бы спорил...

Что такое "классические методы" и что такое "неклассические"?

F>тем не менее "огромное число разных задач многопоточного программирования" осталось нераскрытым.

* Например вычислительные задачи из области CAE/CAD.
* Задачи решаемые через GPGPU
* Задачи решаемые на кластерах из top500.org
* Большинство задач решаемых посредством TBB, PPL, OpenMP, MPI
* Рендеринг 3D сцен, обработка изображений и т.п.

F>почему же?
F>люди пользуются GC не потому же, что не умеют вручную чистить память
F>защита от ошибок на уровне технологии — это обычное дело

GC он не про чистку памяти, а про memory safety и упрощение многих алгоритмов и API
на вопрос ты так и не ответил

Здравствуйте, ELazin, Вы писали:

EL>на вопрос ты так и не ответил

о проблеме?
дедлоки.

Здравствуйте, 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 сцен, обработка изображений и т.п.

по-моему, половина про одно и то же.

F>о проблеме?
ага

F>дедлоки.
бывают редко, лечатся элементарно (особенно после появления thread sanitizer-а в gcc), очень легко можно запилить архитектуру в которой дедлоки невозможны в принципе
можно легко получить лайвлок на сообщениях и чем угодно вообще, это не исключительная проблема локов

Здравствуйте, neFormal, Вы писали:

EP>>Что такое "классические методы" и что такое "неклассические"?

F>1. создание системных потоков и раскидывание задач по ним
F>2. все остальные

это очень неинформированное мнение. во-первых, создание потоков ОС ничем не отличается в плане парадигмы программирования от создания потоков рантайма, рахница только в эффективности. во-вторых, основная проблема в CP — не создание потоков, а коммуникация между ними, и тут с 60-х годов придумано безумное число идей. CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам эрланг)

мне кажется, лучше делить подходы на shared memory/messaging

EP>>* Задачи решаемые через GPGPU

F>по-моему, половина про одно и то же.

так не только половина, а всё — о том что нам нужно как можно быстрее получить результат, неважно сколько cpu/gpu при этом задействовано

Здравствуйте, BulatZiganshin, Вы писали:

BZ>во-первых, создание потоков ОС ничем не отличается в плане парадигмы программирования от создания потоков рантайма, рахница только в эффективности.

и поэтому используются разные подходы.
вплоть до того, что кому-то удаление потоков ОС будет казаться преступлением.

BZ>во-вторых, основная проблема в CP — не создание потоков, а коммуникация между ними, и тут с 60-х годов придумано безумное число идей. CSP (а вовсе не акторы), на которых основан эрланг — это идея из 70-х, так что она тоже более чем классическая (как и сам эрланг)

да, но большое количество старых идей сейчас достаётся из истории и начинает применяться.
поэтому я сторонник разделения oldschool/newwave по использованию широкими массами кодеров.

BZ>мне кажется, лучше делить подходы на shared memory/messaging

тоже вариант

Здравствуйте, 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).

Здравствуйте, neFormal, Вы писали:

EP>>1. А зачем их туда вносить?
F>по ошибке, например.

По ошибке добавить мьютекс?
Всё же не пойму к чему это — параллельное программирование можно строить поверх готовых примитивов типа parallel_transform, parallel_reduce и т.п., без всяких мьютексов и очередей в пользовательском коде.

Здравствуйте, Mamut, Вы писали:

M>Я оппонентам отвечаю ровно до тех пор, пока эти самые оппоненты не начинают прыгать из стороны в сторону, переводить темы и придираться к сугубым частностям.
M>Еще раз повторю, не умеете читать — ваши проблемы, не мои. О вашей (оппонентов) нечистоплотности говорил в соседнем топике не только я.

Ну я в той дискуссии не участвовал. Однако в данной темке ты так и не смог ничего мне возразить. ))))

Здравствуйте, Mamut, Вы писали:

M>Специально ткну тебя носом:

M>...

M>У тебя есть пробелмы с пониманием написанного? Нет? Хорошо. Ответь на поставленный в конце вопрос.
M>Только не надо мне рассказывать сказки про то, что тебе не надо ничем управлять и ни с чем общаться.

Что, культурно общаться уже не получается? Жаль.

M> Какие инструменты предлагает нам подавляющее большинство современных языков программирования для решения этих двух вопросов?
Я, к сожалению, не могу говорить за "подавляющее большинство языков", поскольку не являюсь в них экспертом. Но, конкретно эти два вопроса решается либо асинхронными событиями, либо синхронизацией (гм, забавно если задуматься). Рискну предположить, что библиотеки, реализующие подобную функциональность есть для большинства живых языков.

И скажите, вы действительно считаете что эти достаточно тривиальные операции в том же C++ не реализуются никакими средствами? Пусть даже используя исключительно мьютексы объекты синхронизации и потоки?

Здравствуйте, neFormal, Вы писали:

EP>>* При параллельном программировании главная цель состоит в том, чтобы как можно быстрее получить результат
EP>>* При конкурентом программировании сама задача решается на порядки проще
F>т.е. разница лишь в количестве потоков относительно процессоров и нагрузке на каждый поток.
F>негусто, если честно.

Эта самая разница в количестве кардинально меняет ситуацию. К примеру если взять те же самые лёгкие потоки (все их разновидности) — откуда по твоему берётся их преимущество перед системными? Очевидно из-за отсутствия огромных накладных расходов. Однако это актуально только для задач с тысячами короткоживущих потоков (высоконагруженными серверами и т.п.). А скажем для случая числодробилок (где число потоков равно числу ядер на машине) подобных накладных расходов нет вообще, т.е. системные потоки тут отлично подходят. В то время как Эрланг (в котором у нас только лёгкие потоки) наоборот будет вносить накладные расходы за счёт своего планировщика и ещё кучи всякой мишуры.

Так что казалось бы всего лишь количественная разница вносит вполне себе качественные различия. И соответственно в разных случаях надо применять разные инструменты. С тем же C++ это кстати совсем не проблема, т.к. там это всё реализовано в виде библиотек — просто выбираем нужную. А вот в случае попытки применения Эрланга где-то за пределами его узкой ниши мы получим множество неудобств.