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 — это сторонняя библиотека, которую надо скачивать, устанавливать и т.п? )

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

_>Т.е. от тебя пока что видны только лозунги

поздравляю, господин, соврамши.

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

M>Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное

Я так понимаю, что и тебе слабо показать реализацию этой

Автор: alex_public
Дата: 30.06.15

простейшей многопоточности на Эрланге? ) Вижу уже начал отмазываться демагогическими лозунгами...

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

F>я тебе уже сказал. но ты не хочешь читать, почему-то.
Неужели и код продемонстрировали? Вот казалось бы, программистский сайт, какой смысл чесать языками клавиатуру — написал код и точка зрения ясна. Пока из-за острой кодонедостаточности складывается ощущение что на Эрланге его фанаты программируют чисто теоретически, без написания этого скучного кода.

F>>>>>и короче, если у плюсов тоже отнять стороннюю библиотеку.
И ещё раз, без handicap'а C++ у Эрланга совсем шансов нет?

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

S>Неужели и код продемонстрировали?

нда, чтение — не твоя сильная сторона.

M>>Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное

_>Я так понимаю, что и тебе слабо показать реализацию этой

Автор: alex_public
Дата: 30.06.15

простейшей многопоточности на Эрланге? ) Вижу уже начал отмазываться демагогическими лозунгами...

Ничего демагогического. Ты просто пошел в ту степь, о которой я говорил уже 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 имеет гибкость: например, можно запустить обработку на другой ноде (которая может быть на другом компьютере)
— реализация этой гибкости занимает чуть больше экрана несложного кода.

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

F>нда, чтение — не твоя сильная сторона.
Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.

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

F>>нда, чтение — не твоя сильная сторона.
S>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.

ты всё равно не поймёшь его

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

_>>Т.е. от тебя пока что видны только лозунги
F>поздравляю, господин, соврамши.

Ну давай ссылку на код или извиняйся. )

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

S>>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.

F>ты всё равно не поймёшь его

т.е. всё-таки вы именно теоретический программист на Эрланге. Ок.

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

S>>>Прошёл по вашим сообщениям вверх к корню, кода нет. Если он приведён в сообщении из другой ветки, дайте ссылку.
F>>ты всё равно не поймёшь его
S>т.е. всё-таки вы именно теоретический программист на Эрланге. Ок.

ожидаемо.

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

_>>>Т.е. от тебя пока что видны только лозунги
F>>поздравляю, господин, соврамши.
_>Ну давай ссылку на код или извиняйся. )

не вижу извинений за враньё

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 например не что иное как отправка сообщения другому потоку используя самый быстрый механизм из всех имеющихся в наличии).

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? Т.е. ты будешь её каждый раз писать заново? )

Ну и если в итоге посмотреть на данный код (для которого надо ещё дописать функции и поставить библиотечку) и на мой пример (собираемый стандартной поставкой компилятора), то где у нас в итоге получается закат солнца вручную в следствие слабой реализации многопоточности? )))

M>Много текста ни о чем. Прекрасно — мьютексы это сообщения (чтоа?). Только на этих «сообщениях» далеко не уедешь.

Почему далеко не уедешь? Почему мой текст ни о чем, ошибся где-то? Я тебе еще в прошлом треде предлагал сравнить два подхода на каком-нибудь примере, получил в ответ "ты не умеешь читать" и вот это вот. Пожалуй буду считать что ты слился и не буду больше тратить свое время на споры в булшит треде. Всего хорошего.

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 когда все, что у тебя предлагает язык, — это мьютексы.

А так да. Читать в этом топике умеют единицы, потому что обо всем этом я уже написал.

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

EL>В общем, мьютекс это довольно клево и интересно. Чтобы это понять, достаточно попробовать запилить что-нибудь нетривиальное на потоках/мьютексах/общей памяти и на сообщениях.

а что есть подобного нетривиального?

EL>Ну и вообще, сообщения vs локи это ложная дихотомия, ибо операции с мьютексом можно рассматривать как отправку сообщения другому потоку. Поток ждет на мьютексе = ждет пока соощение поступит в мейлбокс, поток освобождает мьютекс = отправляет сообщение в мейлбокс.

только в случае нескольких мутехов получается ситуация с несколькими блокировками на нескольких мейлбоксах. нездорово выглядит.
так что рассматривать можно весьма условно.