Здравствуйте, cadet354, Вы писали:
R>>А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).
C>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
Чо-то ещё я такое видел серьёзное, там даже препроцессор был, но сейчас не могу вспомнить название. Мне кажется, если погуглить или посоурсфорджить, то можно значительно больше найти.
Это же с Thinking Parallel, правильно? Я на него подписан и читал там всё по мере публикации.
Ну и что мы там видим?
Удаётся получить 4-ёх кратное увеличение производительности на 4-ёх ядерном процессоре. Заметь как он аккуратен в формулировках. Полная версия — Удаётся получить 4-ёх кратное увеличение производительности на 4-ёх ядерном процессоре для некоторых программ, которые мы специально сделали для этого теста. Ну это уже хорошо, что они устранили очевидные боттлнеки внутри самого ран-тайма. Но это никак не говорит о легкости/возможности достижения этого результат для всех реальных программ.
Далее ещё интереснее. На 32-ядерной машине получили только 18-кратное ускорение. Почему не 32 кратное? Потому что масштабируемость не линейная, т.е. на 48-ядрах у нас будет 20-кратное, а на 64 — 10 кратное. И это опять же на программе, которую они специально для этого выбрали.
Здравствуйте, abch-98-ru, Вы писали:
A9R>Здравствуйте, remark, Вы писали:
R>>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
A9R>А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо) A9R>А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает A9R>Я даже слово волшебное знаю, пожалуйста
в общем пока монстры спорят о философии — мы тут плюшками балуемся. видимо как-то оно так выглядет на erlange ( c учетом моих более чем скромных познаний в нем). все пример, дедлока привел(если after убрать, то вечный, а так по таймауту все разрулится), можно пересесть к зрителям.
-module(dl).
-export([start/0, dl/2]).
dl(P1,P2) ->
receive
{P1, A}->
A ! {P2, self()},
io:format("got dl with ~p ~p ~n", [P1,P2])
after
5000 ->
io:format("timeout dl with ~p ~p ~n", [P1,P2])
end.
start() ->
spawn (dl, dl, [p1,p2]),
spawn(dl, dl, [p2,p1]).
Здравствуйте, remark, Вы писали:
R>Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.
там же очередь сообщений, сначала Г ждем сообщения от Б, а потом уж от B и ничего выдумывать не надо, разве не так?
что то вроде этого:
Здравствуйте, abch-98-ru, Вы писали:
A9R>Здравствуйте, remark, Вы писали:
R>>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
A9R>А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо) A9R>А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает A9R>Я даже слово волшебное знаю, пожалуйста
Примерчик не могу.
Но гугл по словам "erlang deadlock" выдаёт много интересного. Первая идёт академическая статья "Towards a deadlock analysis for Erlang programs".
И вот ещё Lazy Cjow Rhrr приводил "Towards a deadlock analysis for Erlang programs": http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.8054
Я думаю, что там должны быть примеры. Ну и соотв. видимо проблема не надуманная, раз пишут статьи и делают тулзы.
Здравствуйте, cadet354, Вы писали:
C>там много чего найти можно, но в реальности хрен применишь , C>посмотрю по другим ссылкам,что ты выложил, реально что-то из этого пробывал?
Я на .NET мало программирую, поэтому ничего не пробовал. Возможно кто-то из .NET программистов что-то подскажет. Можно спросить в .NET разделе.
А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.
Здравствуйте, cadet354, Вы писали:
R>>Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.
C>там же очередь сообщений, сначала Г ждем сообщения от Б, а потом уж от B и ничего выдумывать не надо, разве не так?
В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.
Здравствуйте, Gajdalager, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Вот функция без побочных эффектов, которая используется при распараллеливании: R>>
R>>void func(int* a, int* b, int begin, int end)
R>>{
R>> for (int i = begin; i != end; ++i)
R>> a[i] += b[i];
R>>}
R>>
R>>Какие тут проблемы?
G>То, что здесь есть побочные эффекты, проблемой не является?
О, действительно.
Но так даже лучше. Потому что наличие таких специфических побочных эффектов действительно НЕ мешает для распараллеливания (это плюс, т.к. больше свободы и не надо создавать дополнительный объект под результат). Но в то же время можно и чисто без побочных эффектов (надеюсь в этот раз получится):
R>Примерчик не могу. R>Но гугл по словам "erlang deadlock" выдаёт много интересного. Первая идёт академическая статья "Towards a deadlock analysis for Erlang programs". R>И вот ещё Lazy Cjow Rhrr приводил "Towards a deadlock analysis for Erlang programs": R>http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.33.8054
это все я вчера смотрел, когда мне рассказывали о том, как "вообще нет" дедлоков
R>Я думаю, что там должны быть примеры.
не нашел, там вроде дедлоки ищут, а не создают
R>Ну и соотв. видимо проблема не надуманная, раз пишут статьи и делают тулзы.
я и не спорю. просто хотелось хлеба, а не только зрелищ.
да и не ожидал, что ерлангистов здесь нет. Думаю то, что я написал
R>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.
не видел там такого, в любом случае паттерн матчинга не будет хватать.
Сейчас смотрю в сторону F#
Здравствуйте, remark, Вы писали:
R>В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.
я к тому что если надо закладываться на определенный порядок сразу, это легко сделать с минимальными приседаниями,
в отличие от других языков. С другой стороны, конечно erlang на это заточен, dsl так сказать, в последней версии
они поправили кстати баг с jinterface
A bug when Jinterface did not detect remote node disconnects has been corrected.
Здравствуйте, cadet354, Вы писали:
R>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang. C>не видел там такого, в любом случае паттерн матчинга не будет хватать. C>Сейчас смотрю в сторону F#
Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, cadet354, Вы писали:
R>>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang. C>>не видел там такого, в любом случае паттерн матчинга не будет хватать. C>>Сейчас смотрю в сторону F#
R> R>Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.
в С# ? про batch это понятно, а вот как например обработать конкретное сообщение, а остальные пусть подождут и пусть накапливаются?
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, cadet354, Вы писали:
R>>>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang. C>>>не видел там такого, в любом случае паттерн матчинга не будет хватать. C>>>Сейчас смотрю в сторону F#
R>> R>>Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.
C>в С# ? про batch это понятно, а вот как например обработать конкретное сообщение, а остальные пусть подождут и пусть накапливаются?
АФАИК Сhoice называется примитив для выборки одного сообщения из множества.
Здравствуйте, cadet354, Вы писали:
R>>В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.
C>я к тому что если надо закладываться на определенный порядок сразу, это легко сделать с минимальными приседаниями, C>в отличие от других языков.
Если сразу закладываться на отсутствие дедлоков, то их тоже тривиально устранить. Во-первых, 90% lock-based кода вообще не подвержены дедлокам, 90% из оставшихся 10% легко решается применением либо упорядоченного локинга, либо иерархического локинга. Оставшееся просто переписывается, ибо криво. Вот видишь тоже все просто. На словах. А ведь некоторые кричат, что там типа дедлоки и не компосабельность и т.д.
По поводу "приседаний в отличие от других языков". Ну если мы сравниваем с языком, который вообще без встроенного обмена сообщениями, то упорядочивание сообщений тут не релевантно. Если мы используем какую-то библиотеку для обмена сообщениями, то почему бы там не быть встроенному упорядочиванию? Например можешь посмотреть Concurrency and Coordination Runtime (CCR) для .NET от Microsoft — там есть экстремально продвинутые встроенные возможности, по сравнению с которыми Эрланг всасывает. Например, ожидание сразу нескольких сообщений разных типов и/или из разных источников, ожидание сразу пачки сообщений одного типа из одного источника, reader-writer агент (т.е. часть сообщений обрабатывается последовательно, а часть параллельно — это даже и не смоделировать в Эрланг никакими бубноплясками). Или Asynchronous Agents Library (AAL) это уже для С++. Там есть такие встроенные вещи как write once очереди для агентов, или single element очереди (что-то типа доски объявлений получается), или bounded очереди, или маршрутизация сообщений одному из нескольких агентов на основе фильтров, или балансировка нагрузки (когда несколько агентов подключаются к одной очереди) и т.д. Эрланг-то сам по себе как раз экстремально минималистичен, и чуть что надо сделать не типовое надо делать присядания.
Здравствуйте, AndrewVK, Вы писали:
C>>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
TPL — это другое, это — task-based программирование, подходит в одновном для паралельных вычислений, а неструктурированный параллелизм поддерживается плохо. M$ ещё делает AAL (Asynchronous Agents Library), но это для С++. Но о каких планах переноса потом агентно-ориентированного программирования под .NET я пока не слышал, хотя это вполне логично, так что возможно в MSVC2012...
Здравствуйте, remark, Вы писали:
R>Не понял смысл аналогии с ассемблером. Давай более конкретно. Вот
Этим я хотел выразить такую мысль, что Эрланг предоставляет наиболее высокий уровень абстракции при работе с многопоточными приложениями.
R>Вот функция без побочных эффектов, которая используется при распараллеливании: R>
R>void func(int* a, int* b, int begin, int end)
R>{
R> for (int i = begin; i != end; ++i)
R> a[i] += b[i];
R>}
R>
R>Какие тут проблемы?
А то, что тут как раз явный побочный эффект торчит, тебя не смущает? То есть при выполнении этой функции в отдельном потоке, у тебя где-то еще в другом потоке, может изменяться твой массив 'a', разве это не проблема?
Теперь безотносительно побочного эффекта и связанных с ней проблем. По моим сугубо религиозным взглядам, твой пример должен параллелиться автоматически компилятором, средой, а не вручную как это делаешь ты. Попробую обосновать, когда ты это делаешь вручную, ты привязываешься на фиксированное количество ядер/процессоров (хотя конечно можно вручную тоже это рулить, но это тот еще геморрой). Поэтому я считаю, что такой код должен быть распараллелен компилятором, средой. По одной простой причине, что среде исполнения будет известно количество ядер/процессоров на которой исполняется твоя программа и она сможет эффективно ее распараллелить для конкретной машины. Например, твой пример для одно ядерной машины будет эффективнее выполнить целиком, то бишь передать: begin = 0, end = lenght — 1. А для двух ядерной машинки в два потока: (begin = 0, length/2) и (begin = length/2 + 1, end = length — 1).
R>Мммм... ну и как в Эрланге работать с общей памятью?
См. mnesia.
Y>>Напиши. Вся проблема в том, что ты этого не напишешь.
R>Мммм... даже не знаю, что ответить... Разве что я уже две написал. И работал с рядом проектов, которые активно использовать передачу сообщений, хотя и до актёр-ориентированных не дотягивали. R>Написать рабочую базовую версию — на это надо примерно 1 день. А дальше полная свобода действий. Хочешь вставляешь логирование всех проходящих сообщений, хочешь делаешь специальную фильтрацию при широковещательных рассылках, хочешь делаешь перехватчики сообщений, хочешь делаешь диспетчиризацию при отправке, хочешь при получении, хочешь делаешь reader-writer агенты и т.д.
Я имел ввиду Erlang style concurrency с такими же TTX.
R>
Пиво пить, вредно для здоровья
Кстати уж больно ты мне одного товарища напоминаешь, ты случаем не с софтового отдела Intel'а?
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, remark, Вы писали:
R>Здравствуйте, cadet354, Вы писали:
R>>>В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.
C>>я к тому что если надо закладываться на определенный порядок сразу, это легко сделать с минимальными приседаниями, C>>в отличие от других языков.
R>Если сразу закладываться на отсутствие дедлоков, то их тоже тривиально устранить. Во-первых, 90% lock-based кода вообще не подвержены дедлокам, 90% из оставшихся 10% легко решается применением либо упорядоченного локинга, либо иерархического локинга. R> Оставшееся просто переписывается, ибо криво. Вот видишь тоже все просто. На словах. А ведь некоторые кричат, что там типа дедлоки и не компосабельность и т.д.
дьявол как известно в мелочах, одно дело ты будешь это писать, другое дело я .
Вот в недавнем сообщение от Ayende (не самый последний программист ), расказал как он задумал к NH Prof прикрутить immutable message passing,
в результате раздумал,будет делать с помощью bus model, так что в один другой день это не реализуется, а он строчит как из пулемета
Мне гораздо удобнее писать эти вещи на ерланге, а с ним взаимодействовать OTP.NET (название явно не не соответствует содержанию), правда я ерланг использовал в двух проектах суть которых сбор информации и первичная обработка, так настоящим эрлангистом меня назвать нельзя. R>По поводу "приседаний в отличие от других языков". Ну если мы сравниваем с языком, который вообще без встроенного обмена сообщениями, то упорядочивание сообщений тут не релевантно. Если мы используем какую-то библиотеку для обмена сообщениями, то почему бы там не быть встроенному упорядочиванию? Например можешь посмотреть Concurrency and Coordination Runtime (CCR) для .NET от Microsoft — там есть экстремально продвинутые встроенные возможности, по сравнению с которыми Эрланг всасывает. Например, ожидание сразу нескольких сообщений разных типов и/или из разных источников, ожидание сразу пачки сообщений одного типа из одного источника, reader-writer агент (т.е. часть сообщений обрабатывается последовательно, а часть параллельно — это даже и не смоделировать в Эрланг никакими бубноплясками).
часть приложений которые параллельно решается запуском отдельных threads, чем не решение?
Я особенно глубоко не разбирался с ССR (видимо зря), не подскажешь как сделать такую вещь как очередь с приоритетом, причем приоритет определяться по определенному полю в обьекте, его значению, грубо говоря больше/меньше определенного параметра.
Здравствуйте, abch-98-ru, Вы писали:
A9R> можно пересесть к зрителям.
я уж так для очистки своей совести приведу более 'кошерный' код дедлока. если ерлангисты на rsdn существуют (в чем я лично уже сомневаюсь )
может сделают что-нить краше.
-module(dl).
-export([start/0, two/2, sem/0]).
sem() ->
receive
{take, A}->
A ! {taken, self()},
receive
{free, A} ->
A ! {freed, self()}
after
30000 ->
io:format("timeout dl with ~p free ~n", [A])
end
after
30000 ->
io:format("timeout dl with take ~n", [])
end,
sem().
two(P1,P2) ->
P1 ! {take, self()},
receive
{taken, P1}->
timer:sleep(1000),
P2 ! {take, self()},
receive
{taken, P2} ->
timer:sleep(1000),
P2 ! {free, self()}
after
5000 ->
io:format("!!!DEADLOCK!!! taken ~p cant take ~p ~n", [P1, P2])
end,
P1 ! {free, self()}
after
5000 ->
io:format("cant take ~p, nor ~p ~n", [P1, P2])
end,
io:format(".", []),
two(P1,P2).
start() ->
P1 = spawn (dl, sem, []),
P2 = spawn(dl, sem, []),
spawn(dl, two, [P1,P2]),
spawn(dl, two, [P2,P1]).
Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо)
