Достал ты уже со своим ерлангом , Я не ничего не имею против ассинхронных сообщений (сделать это можно на любом языле я думаю)
Как абстракции на нем писать предлагаешь , можно конешно через жопу (и на асемблере можно), Но в данном
случае например предпочитаю нормальные обьектно ориентированные языки.
Я смотрел на синтаксис ерланга и чесно говоря он него тошнит , хотя в некоторых случаях думаю имеет смысл
заюзать.
G>В случае Эрланга, где присутствует сопоставление с образцом и селективный receive, заводить явно этого mailbox не надо. Достаточно написать:
G>rpc_call( CalleePID, Method, ArgList ) -> G>CalleePID ! { self(), Method, ArgList }, G>receive { CalleePID, Result } -> Result.
Здравствуйте, DenysSG, Вы писали:
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
Во-первых, никто не мешает их смешивать (с умом, естественно). Далее ещё есть Transactional Memory — сложно охарактеризовать, но определено не Shared memory... по сути получается вообще как однопоточное выполнение с кооперативным шедулингом (на логическом уровне, на физическом — по-прежнему параллельное исполнение). Далее — Data Parallel Programming — некого рода автоматическое распараллеливание (естественно с некоторым (возможно значительным) участием разработчика). Некоторые апологеты функциональных языков вообще говорят, что ФЯ в будущем дадут автоматическое распараллеливание (т.е. запускаем старую "однопоточную" программу, а она работает быстрее).
DSG>Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java.
Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
В контексте "языки общего назначения vs языки специального назначения" нельзя упускать из виду тот факт, что "практически любая фича/идея/модель будучи реализована в языке специального назначения достаточно тривиально реализуется и в языке общего назначения" (вольный перевод, по-моему, Страуструпа).
DSG>Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Ну это зависит. Во-первых, естественно для какой задачи. Во-вторых, как к этой Shared Memory подходить и как использовать.
Ну и надо учитывать тот факт, что сейчас оооооооооооочень много хайпа вокруг данного вопроса. Большинство из тех, кто говорит про это либо что-то продаёт, либо сам создаёт (даже "бескорыстное" академическое сообщество в большинстве своём создаёт какие-то конкретные модели и, естественно, описывают их приемущества, на описании "голой" разделяемой памяти понятно дело сейчас диссертацию не сделаешь).
Я ни в коем образе не говорю, что Shared memory — это superior модель. Наоборот я призываю смотреть шире, более объективно оценивать достоинства и недостатки моделей/языков, смотреть в корень, а не на малозначительные детали и т.д.
DSG>Теперь вопрос, что же будет дальше. 32 ядра от Интел в следующем или 2010 году — очень неожиданно. DSG>И Java не очень-то готова. DSG>А уже написанные приложения работающие с Shared Memory, как я понимаю, DSG>еще в худшем положении, если возникнет потребность увеличить ресурсы и использовать все ядра.
DSG>Решения, которые я нашел DSG>A Java Fork/Join Framework DSG>DataRush DSG>Что выглядит не очень привликательно.
А почему Fork/Join не очень привлекательно? АФАИК — должно войти/уже вошло в официальную спецификацию Java. Позволяет добиваться линейной масштабируемости для любого кол-ва ядер.
DSG>А что ещё есть — Scala или Erlang через Jinterface Application.
DSG>Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java.
В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
----------------
Теперь конструктивная часть.
Во-первых, надо определиться с классом задач. Одно дело — число-дробилки (моделирование, научные расчёты, обработка изображений, распознавание речи и т.д.), другое дело — неструктурированный параллелизм общего назначения (различное серверное ПО, системное ПО, клиентское ПО).
Для последнего *модель программирования* Erlang достаточно хороша. Основное, что тут надо учитывать:
(1) для разных приложений разная степень "достаточности". Для многих степень достаточности достаточная. Для некоторых — не очень. Ну и опять же вопрос — сколько мы хотим выжать из железа — 100% или 80% нам будет достаточно?
(2) *модель программирования* Erlang ни в коем случае не ограничена только самим Erlang'ом.
Для первого типа задач модель Erlang может как подходить и совсем нет. Для распределённых кластеров она, наверное, подходит, т.к. там обычно используют обмен сообщениями в том или ином виде. Для SMP/multicore, я думаю, в большинстве случаев модель разделяемой памяти подходит больше, т.к. ... ну т.к. это просто Shared Memory Processing.
Так же можно привести такой пример. Допустим в программе есть некий кэш данных (хэш-мап). В Erlang подходе мы этот хэш-мап отдадим одному процессу, и когда нам надо будет к нему обратиться будем посылать этому процессу сообщения. На физическом уровне это будет включать: создание объекта сообщения, помещение его в очередь, переключение контекста с текущего процесса, доставание сообщение сообщения другим процессом, обработку сообщения, удаление первого сообщения, создание сообщения-ответа, помещение сообщения-ответа в очередь, переключение контекста опять на первый процесс, доставание сообщения из очереди, удаление сообщения.
В модели с общей памятью мы... просто обращаемся к хэш-мапу.
Далее, что бы было понятно, что на самом деле эти модели имеют не такое уж и большое значение можно рассмотреть иерархию того, как они реализуются.
На нижнем уровне у нас транзисторы — разделяемая память.
На основе транзисторов многоядерные процессоры реализуют обмен сообщениями (будь то общие шины, либо соединения точка-точка).
Далее процессор реализует для программиста опять модель общей памяти.
На основе этого программисты делают библиотеки обмена сообщениями.
На основе библиотек обмена сообщениями реализуется DSM (distributed shared memory).
Распределённые кластеры, использующие DSM, объединяются на основе обмена сообщениями по глобальным сетям.
В глобальных сетях создаются системы управлениями объектами, которые позволяют работать с объектами "как с локальными" и пытаются поддерживать консистентность (shared memory).
...
Это действительно не столь принципиально, ты можешь использовать любую модель, можешь надстроить над любой любую, и всё равно в конечном итоге будешь использовать обе
Здравствуйте, Gaperton, Вы писали:
G>Понятно, то есть, тебе хочется докопаться.
Мимо.
G>>>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
E>>Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
G>Для опровержения тезисов ремарка вполне достаточно одного примера, где "сообщения" показывают лучший результат, а тут их два.
См. ниже.
G>Еще раз, приведу два тезиса:
G>remark: "разделяемая память" имеет преимущества, которые безвозвратно и необходимо утрачиваются при применении message passing style.
Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.
Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества. Для доказательства этого тезиса, как я наивно полагал, достаточно привести пример случая, когда это преимущество доказано экспериментально. Такое доказательство приведено в упомянутой тобой статье.
Однако, если бы remark утверждал, что разделяемая память всегда имеет преимущество, тогда было бы достаточно всего лишь одного контрпримера для его опровержения. Но remark этого не утверждает. А вот какие тезисы ему приписываешь ты -- это совсем другая история.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали: G>>Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?
S>Это, кстати, мне до боли напоминает "теорему существования" (c) P.Dvorkin. Там, где он "доказывал", что раз все языки высокого уровня компилируются в ассемблер, значит программа на ассемблере гарантированно не медленнее никакой программы на ЯВУ. Здесь только народ поаккуратнее, и не пытается протолкнуть аналогичное доказательство
Отчего же аккуратнее? Одна такая попытка уже зарегистрирован от remark в соседней ветке.
Дворкина можно было бы отослать на форум геймеров, где они пытались обойти Intel C++ ручным кодированием на ассемблере на короткой программе — я ссылку несколько лет назад давал, — подтверждать свою теорию практикой. Проблема в том, что авторы таких теорем обычно не имеют представления, как на современных процах выполняется программа на ассемблере, и насколько компилятор больше них знает об исполнительном конвейре проца . Вот на том форуме, я помню, народ чуть себе лоб до затылка не расшиб, пытаясь понять (когда попытки обогнать уже бросили), почему более длинный "и корявый" код, сгенеренный IC++, быстрее, чем их "оптимизированный" ассемблер .
Вот, кстати, пример — как бесхитростный gcc компилирует формулу с двумя умножениями для прямолинейного MIPS.
В MIPS, который сам по себе single issue, команда умножения асинхронна. То есть, она занимает один такт, однако результат полагается забирать через несколько тактов из специальной регистровой пары HL.
Так вот, gcc одно умножение заряжает родное, а второе умножение в это время мутит на сдвигах-сложениях. Потому, что так быстрее. Я бы посмотрел на программиста на ассемблере, который попробует обойти gcc под простейший MIPS .
Здравствуйте, Gaperton, Вы писали:
G>Характерный пример — во время обработки какого-либо сообщения, процесс хочет выполнить RPC-вызов. Для этого, он отправляет сообщение процессу, и встает в блокирующее ожидание на мэйлбокс. Второй процесс выполняет запрос, и возвращает результат. Один. В виде одного объекта. В указанный мэйлбокс, специально для этого созданный.
G>В случае Эрланга, где присутствует сопоставление с образцом и селективный receive, заводить явно этого mailbox не надо. Достаточно написать:
G>rpc_call( CalleePID, Method, ArgList ) -> G>CalleePID ! { self(), Method, ArgList }, G>receive { CalleePID, Result } -> Result.
G>И не важно, свалятся в мэйлбокс во время выполнения RPC другие запросы, или нет. В случае тех языков, где selective receive не поддержан, например, Java, C++, и C#, для приема результата разумные люди заводят отдельный мэйлбокс в вызывающем процессе. Что, кстати, еще и эффективнее.
G>И разумеется, полной очереди здесь создавать не обязательно — здесь гарантированно хватит специального мэйлбокса, рассчитанного на одно сообщение. Групповой receive в данном случае на группе мэйлбоксов изобразить также возможно, кстати, — он ждет первого сообщения из любой из указанных очередей. Получишь почти полный изоморфизм с моделью Эрланга, и характерными для него приемами проектирования.
Собственно, я не сказал вам самого интересного про эти однообъектные мэйлбоксы. У них есть специальное название — фьючерс. И они сами по себе представляют интересную концепцию, настолько, что она достойна поддержания на уровне языка.
Фьючерс — это значение, которое будет вычислено. Его вычисление форсируется в момент первого обращения к фьючерсу. Это обобщение ленивых вычислений и асинхронного межпроцессного взаимодействия.
То есть, в случае примера с RPC — мы просим другой процесс асинхронно обработать наш запрос, положив результат во фьючерс. И, когда мы попробуем из фьючерса что-то считать, а там ничего нет — то мы встанем в блокирующее ожидание.
Более интересный пример, демонстрирующий силу фьючерсов. Допустим, мы хотим рассчитать массив из десяти значений. Каждое — параллельно. Мы просто заполняем этот массив в цикле фьючерсами, каждый из которых — RPC-вызов к какому-то потоку (или старт отдельного потока, выполняющего рассчет, возможно — асинхронный старт, по мере доступности потоков в пуле). И все. Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.
При этом, мы можем сделать вычисление не параллельным, а "ленивым", чтобы оно вычислялось в момент обращения. Программа будет выглядеть так же.
Фьючерсы — это совершенно потрясающая модель, дружественная к асинхронным сообщениям и тому стилю программирования, про который я сейчас рассказал, но еще более высокоуровневая, и в еще меньшей степени подверженная ошибкам. Пример того, как фьючерсы поддержаны в языке, можно увидеть в Alice ML.
Здравствуйте, remark, Вы писали:
R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Здравствуйте, Gaperton, Вы писали:
G>>>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.
E>>Классическое образование, надо полагать, заставляет думать, что доступ к разделяемым данным можно сделать только на семафорах. Ничего не поделать, у классического образования так же есть недостатки.
G>Извини, пока я не вижу никаких фактов, демонстрирующих какие-либо твои познания и представления, выходящие за рамки стандартного API, которое реализует в основном семафорную модель. Ты можешь меня разубедить, переведя тему разговоров с личностей обратно на предмет дискуссии. Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.
Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, yumi, Вы писали:
R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.
Демагогия.
Проектов, которые на универсальных императивных языках реализуют модель актеров, не так уж и мало. Для Ruby -- Revactor, для Java была сделана SEDA, для Scala -- ScalaActors, для Python -- Eventlet и Kamaelia.
R>>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
Y>Напиши. Вся проблема в том, что ты этого не напишешь.
Вы пытаетесь брать "на слабо" не того человека. Ему и не нужно писать это самому, вокруг достаточно велосипедостроителей, которые делают уже это. При этом широко используя знания и идеи remark-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, EvilChild, Вы писали:
EC>>>А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?
G>>Почему нельзя? Можно. Получишь в точности очередь сообщений, а именно — ее предельный случай с глубиной 1 и полиси вытеснения при переполнении по FIFO — что станет совершенно очевидно даже тем, кто в танке, если завернуть то что получится в класс, и посмотреть на функциональный интерфейс. EC>Можно и о скаляре думать как об одномерном массиве с одним элементом, вопрос в том когда такой взгляд на вещи полезен.
Можно и об очередях сообщений (вернее, мэйлбоксах, так правильнее) думать как о разделяемой памяти, вопрос, когда такой взгляд на вещи полезен. Мой взгляд на вещи позволяет писать такие программы, пример которой я привел. Насколько он полезен для тебя — это ты сам решай, а я тебе немного расскажу пока про то, какие вообще бывают мэйлбоксы, и ситуации их употребления.
Данный объект по всем своим свойствам объективно является мэйлбоксом для приема асинхронных сообщений, и в данном случае употребляется в том контексте, где применяется мэйлбокс. Подобного рода мэйлбоксы на одно сообщения — распространенная вещь в дизайне на асинхронных сообщениях. А вот, например, семафор по всем своим свойствам мэйлбоксом не является.
Характерный пример — во время обработки какого-либо сообщения, процесс хочет выполнить RPC-вызов. Для этого, он отправляет сообщение процессу, и встает в блокирующее ожидание на мэйлбокс. Второй процесс выполняет запрос, и возвращает результат. Один. В виде одного объекта. В указанный мэйлбокс, специально для этого созданный.
В случае Эрланга, где присутствует сопоставление с образцом и селективный receive, заводить явно этого mailbox не надо. Достаточно написать:
И не важно, свалятся в мэйлбокс во время выполнения RPC другие запросы, или нет. В случае тех языков, где selective receive не поддержан, например, Java, C++, и C#, для приема результата разумные люди заводят отдельный мэйлбокс в вызывающем процессе. Что, кстати, еще и эффективнее.
И разумеется, полной очереди здесь создавать не обязательно — здесь гарантированно хватит специального мэйлбокса, рассчитанного на одно сообщение. Групповой receive в данном случае на группе мэйлбоксов изобразить также возможно, кстати, — он ждет первого сообщения из любой из указанных очередей. Получишь почти полный изоморфизм с моделью Эрланга, и характерными для него приемами проектирования.
А то, какую именно реализацию очереди ты применяешь в каждом конкретном случае — исключительно вопрос оптимизации, а не модели программирования. И более того, количество разных видов этих очередей сильно конечно.
G>>Потом можно пойти еще дальше, упереться, и под разными предлогами не называть это очередью сообщений. EC>Я ниразу не против называть это очередью. EC>Я спрашивал не в разрезе вашего увлекательного спора message passing vs shared memory, EC>а исключительно в контексте конкретного решения с иммутабельным деревом.
В контексте данного примера — речь об предварительной оптимизации, дающей совершенно мизерный эффект на общую производительность, в силу небольшого потока данных по данному каналу в сравнении с основным. Конкретнее, речь идет о специальной оптимизированной реализации подобного мэйлбокса на одно сообщение, соответствующего мультикаст-группе.
G>>Видишь ли, asynchronous message passing — это не более чем дизайн-идиома, которая в конечном счете на современных архитектурах все равно превратится в те примитивы, через которые реализуются семафоры все остальное. Так же, как программа на функциональном языке в конечном счете превратится в ассемблерные инструкции. EC>Мне кажется важным различать то, в каких терминах мы можем думать о решении и то, как оно реализуется.
А мне кажется важным применять в разработке фреймворки, которые позволяют тебе делать реализацию решения в тех терминах, в которых формулируется решение. Боюсь, я не один, кому так кажется.
G>>Если использовать это как аргумент, все закончится Теоремой Существования Дворкина (http://rsdn.ru/forum/message/3194838.1.aspx
), на которую любят опираться люди, которым с пеной у рта нечего сказать. Ну так что на таких время тратить — только портить. EC>Что вы так Дворкина любите пинать? Я с ним во многих случаях тоже не согласен, это же не повот его пинать по любому поводу.
Здравствуйте, Gaperton, Вы писали:
G>Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Ну, я в свободное время люблю размышлять "по аналогии". На пальцах можно прикинуть такие соображения (оффтоп, но всё равно остальная часть дискуссии как-то завяла):
Итак, чем (на пальцах) отличается динамика от статики? Наверное, тем, что оно вот как-то так:
public class StaticPerson
{
public string Name { get; set;}
public int Age {get;set;}
}
public class DynamicPerson
{
public object this[string PropName] { get; set} ;
}
Интуитивно сразу понятно, что для первого пёрсона умный компилятор сможет фиксировать расположение полей, и мембер аксессы будут на диво шустрыми:
public static int TotalAge(StaticPerson[] persons)
{
int totalAge = 0;
foreach (var p in persons) totalAge+= p.Age; // здесь мы имеем эффективный косвенный доступ и нативные целочисленные операции
}
Тормозная динамика явно потребует честного просмотра хеш-таблицы и полиморфного сложения на каждой итерации, и очевидным образом пролетит:
public static int TotalAge(DynamicPerson[] persons)
{
object totalAge = 0;
foreach (var p in persons) totalAge = PolymorhicAdd(totalAge, p['Age']); // здесь у нас всё плохо.
}
Зачем тогда вообще нужна эта дурацкая динамика?
Ну, например затем, чтобы мы могли быстро добавлять в Person новые свойства без перекомпиляции зависимого кода (который вообще может разрабатываться неизвестными нам 3rdParty).
Или, например, затем, чтобы редкоиспользуемые свойства не жрали место под свои null значения, ухудшая характеристики тесных циклов вроде обсуждаемого.
В итоге, по факту архитектор, озабоченный этими факторами, искусственно делит Person на две части: статическую, для Well-Known Properties, и динамическую, для всякого редконужного мусора.
public class CombinedPerson
{
public int Age {get;set;}
public object this[string PropName] { get; set} ;
}
Понятно, что эффективность полученного решения тесно связана с практикой применения. Если оказалось, что в конкретном контексте у пёрсона прямо-таки всегда заполнено свойство НомерПаспорта, и оно участвует в каких-то многочисленных операциях, то невнесение его в статическую часть — плохо. А если, наоборот, возраст нам малоинтересен, то его наличие в теле объекта раздувает расход памяти.
Такие измышления наталкивают нас на идею о том, где же сможет рулить "автотипизация".
Она сможет рулить там, где границу между статикой и динамикой трудно провести заранее. Именно рантайм, исходя из статистики использования, поймёт, какой нужно построить статический тип для некоторых данных. И сможет получить эффективный результирующий код, полностью использующий преимущества статики.
А маловостребованная часть так и останется сидеть в медленной динамике.
Вот такие примерно соображения. И это — только про runtime performance.
А основное, конечно, преимущество — это отсутствие необходимости вообще проектировать типы заранее. Просто пишешь код, который работает.
Умный компилятор, джит и фреймворк за тебя найдут те 99% объектов, которые по факту в твоей программе имеют статический тип, и сгенерят статические типы именно для этих объектов. В итоге ты будешь иметь класс Point, работающий с эффективностью дотнетовского struct, но без необходимости ручного описания. То есть речь не о том, чтобы "порвать", а о том, чтобы не получить abstraction penalty.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Нуууу эээээ, это похоже на то как какой-нить крестьянин заснул в 1900 году, потом проснулся в 1950 и сказал — "Ох$%ть!! Большевики!!?"
Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Машины для erlang пока сыроваты, но когда-нибудь и они займут свою нишу в production. Но мне кажется это будет просто отдельный критический функционал как JNI, а обвязка все равно будет на java или .net.
Здравствуйте, Gaperton, Вы писали:
G>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.
Плохо формализуемо. И для особо сложных случаев есть специальный пункт о том, что модератор может забанить на свое усмотрение даже за то, что в правилах не прописано. Есть все таки определенная прелесть в диктатуре
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
G>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?
G>Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.
RSDN как обычно жжот. Спорят все команды. Одна команда воображает, будто вторая говорит, что разделяемая память всегда эффективнее сообщений, и, соответственно опровергает его. Вторая команда воображает, что первая утверждает, что сообщения всегда эффективнее разделяемой памяти и тоже опровергает его. Единственное в чем все спорщики сходятся — это в игнорировании аргументов друг друга
Здравствуйте, Gaperton, Вы писали:
G>Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
G>2%, 7%, 9%, и 69% — тесты с выигрышем OpenMP. Значимый отрыв только в одном тесте. 2% — это вообще не смешно, а что такое 9% — ну вместо минуты займет у тебя расчет 55 секунд. Для вашей пенисометрии это может быть и значимый отрыв, но мне, честно, на такую разницу плевать — что есть она, что нет.
G>27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
G>Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
Gaperton, постарайся хотя бы для начала понять моё изначальное высказывание, которое изложено на вполне нормальном русском языке, и которое, я вижу, тут понял не один человек, и даже были попытки тебе его тут пояснить.
Ещё раз, дабы не затуманить основную мысль: ТЫ НЕ ПОНЯЛ МОЁ ВЫСКАЗЫВАНИЕ, и говоришь о чём-то другом.
Здравствуйте, AndrewVK, Вы писали:
C>>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
TPL — это другое, это — task-based программирование, подходит в одновном для паралельных вычислений, а неструктурированный параллелизм поддерживается плохо. M$ ещё делает AAL (Asynchronous Agents Library), но это для С++. Но о каких планах переноса потом агентно-ориентированного программирования под .NET я пока не слышал, хотя это вполне логично, так что возможно в MSVC2012...
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали:
S>>>А иначе никаких разделяемых данных вовсе нет. Я имел в виду, что совместно используется общее значение s. Его нужно обязательно синхронизировать, потому что никакого контроля за тем, сколько потоков одновременно попробуют получать к нему доступ, нету.
R>>Как нет? q — разделяемые данные, множество потоков его меняют и множество — читают. S>В твоем примере нет никакой записи в q.
Ну как же нет? Если б не было записи, то не было бы и мьютекса. Подразумевается, что там есть ещё методы, которые захватывают мьютекс и меняют q. Я просто показал только относящуюся к делу часть.
R>>В смысле в каком? В каком-то.
S>Почему этот поток считает, что s можно безопасно модифицировать? Это вырожденный пример. В жизни слагаемые приватны, разделяются именно суммы. S>Там, где нет конфликта зависимостей, ничего интересного с точки зрения распараллеливания не происходит.
Тут есть конфликт на q. Я просто так понял условие, в условии ничего не было про модификацию s, и уже тем более про одновременную. Так что должно модифицироваться? s? А q?
S>>>Может быть, нужно представить какой-то более человеческий пример? Ну вот — пусть у нас N потоков считают сумму массива. Каждый считает свой фрагмент и кидают сумму в общую кучу. В разделяемой памяти каждый вычислительный поток захватывает мьютекс — делает += — отпускает мьютекс. S>>>В MPS один актер хранит сумму, остальные кидают ему слагаемые. Он ловит и прибавляет к своей сумме. Кто больше потратит на синхронизацию?
R>>Я думаю, что разделяемые данные будут эффективнее. S>На основании чего ты так думаешь?
Что будет из себя представлять решение при использовании разделяемых данных — захватываем мьютекс, делаем небольшое действие, отпускаем. Всё. Операция закончена.
Что будет из себя представлять решение при использовании сообщений — захватываем мьютекс, делаем небольшое действие, отпускаем. Это было только добавление сообщения в очередь агента. Всё? Нет. До этого у нас была некая подготовка (создание сообщения). Потом у нас будет ещё доставание этого сообщения, и обработка (обработка включает некоторые пре- и пост- действия).
Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
Плюс системы на основе сообщений могут иметь ещё один неприятный момент. Этот пример с суммированием как раз ему подвержен. Представь у нас 4 ядра. На 3 ядрах работают агенты, которые постоянно генерируют сообщения для некого одного агента. Даже если мы выделим под этого одного агента отдельное ядро, то всё равно может быть такая ситуация, что другие 3 ядра генерируют для него работу быстрее, чем он может её обрабатывать. В результате — аварийное завершение. Очень неприятная ситуация, тем более, что её возникновение зависит от того, на какой аппаратной платформе мы работаем.
Разделяемая память тут предоставляет некую форму "лоад-балансинга", что типа каждый сам за себя — генерируешь много работы, сам же её и делаешь; делаешь много работы — сильно загружен — генерируешь меньше работы. Т.е. поток не может просто взять и по-хитрому сгенерировать много работы для кого-то другого, тем самым вызывая перегрузку системы.
Ещё один момент. Системы на основе передачи сообщений обычно обрабатывают сообщения в FIFO порядке. А, как говорится, FIFO — это лучший способ остудить данные в кэше. Это что-то, что сложно замерить на микро-бенчмарках, однако это может иметь существенное значение в реальном приложении. Агент отправляет сообщение. Это сообщение остывает в кэше. Теперь мы его достаём и обрабатываем, вызывая ряд промахов в кэш.
R>>Ну в очередь-то надо что-то класть. Если очередь на основе списка, то нужен элемент, который класть в этот список. S>Пусть в этот список всегда кладется ссылка.
Ну а узел-то для списка откуда взять?! Ты представляешь как устроен список? Даже если мы хотим туда положить указатель на что-то, то куда мы его записываем?
Далее, если в сообщении должен идти указатель на отправителя, то в общем-то особо не на что будет класть туда указатель. Надо будет формировать дополнительную структуру, которая содержит, указатель на данные + указатель на отправителя. Тем более, что системы на основе сообщений обычно ещё кладут в сообщение ряд вспомогательных полей.
R>>Тем более, например, в Эрланг зачастую посылают (PID отправителя, данные), такой структуры у потока нет — она ему не нужна, занчит надо её аллокировать, скопировать в неё данные, потом освободить (это плюс к тому элементу, который находится в очереди на основе списка). S>Аллокирование у нас сделано заранее. Ведь данные уже есть, не так ли? Значит, сама передача может выполняться без аллокаций.
Ну это сложный вопрос — смотри выше.
R>>Большую часть съедают всякие мелочи — аллокация вспомогательной структуры — несколько тактов, освобождение — несколько тактов, инициализация — несколько, проверки тут да там — несколько и т.д.
S>Ну, я плохо знаком с предметом, но что-то мне подсказывает, что в очереди на основе кольцевого буфера "аллокирование" и "освобождение" может быть сравнимым с выделением в хипе.
Кольцевые буфера... а что делать, если он переполняется?
Если хип локальный для потока, то добавление в очередь не может быть таким же дешевым — потому что надо разрешать конкуренцию между потоками — класть в очередь же могут несколько потоков.
R>>Плюс разделяемых данных, что их не обязательно делать с мьютексом. Можно с атомарными read-modify-write операциями, можно с обычными чтениями/записями, можно применять "не традиционные" мьютексы, которые способны сводить стоимость lock/unlock практически к нулю.
S>Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
Модель не предусматривает таких оптимизаций. Мы же сознательно открещиваемся от разделяемых данных. А это как раз оптимизации, которые хорошо ложатся именно на разделяемые данные, потому что данные... *разделяемые* по сути своей.
Ну вот например. Есть некий объект, который обновляется, допустим раз в 100 мкс. Допустим — таблица маршрутизации. Множество потоков/агентов постоянно его читают, он им нужен для выполнения каждой операции (маршрутизации).
В модели с разделяемыми данными потоки могут просто читать объект. При этом можно элиминировать возможные блокирования и модификации разделяемых данных для читателей — т.е. будет экстремально легко и линейная масштабируемость. Обновляющий поток — изменяет этот объект.
В модели с обменом сообщениями как мы можем это решить?
Было бы интересно так же услышать мнение Gaperton, который говорит, что у разделяемых данных нет никаких преимуществ вообще.
Здравствуйте, C0s, Вы писали:
C0s>в частности (и мне такое доводилось делать), если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать в силу определённых ограничений — пожалуйста, ставим контроль ограничений на получателя C0s>доводилось также делать многоступенчатую обработку, при которой была цепочка сообщений и, соответственно, цепочка получателей, каждый из которых проверял определённые условия, делал определённую работу и мог отсечь выполнение при несоблюдении каких-то условий
Если говорить о бизнес-требованях и высоком уровне, то тут, мне кажется, выгода от ФИФО становится ещё более явной.
Во-первых, ФИФО — это надмножество НЕФИФО, т.е., пожалуйста, делай синхронный запрос-ответ.
Но так же ФИФО позволяет реализовывать и другие паттерны. Один, мне кажется, ты сам привёл — "...если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать...", в этой ситуации требовалось ФИФО для этих быстро посланных сообщений?
Я не против того, что бы система предоставляла возможность сказать "для этого агента порядок не требуется", если она может реализовать что-то лучше для такого случая. Но в то же время для "высокоуровневой", "удобной" системы, я считаю обязательным так же и возможность задать гарантированный ФИФО. При этом ФИФО больше как выбор "по-умолчанию", а не ФИФО — как оптимизация.
По моему опыту, если идут "низходящие" сообщения (т.е. менеджер устройства посылает устройству) и сообщения типа "запрос", то тогда, в принципе, возможно делать какое-то высокоуровневое управление. Хотя зачастую это только лишняя работа.
Но если идут "восходящие" сообщения (т.е. устройство посылает кому-то — нижние уровни не должны знать о верхних) и/или сообщения типа "нотификация", то тут ФИФО необходимо, т.к. нижний уровень и/или нотификатор не знает даже есть ли там кто-то сверху, а при нотификациях бессмысленно ждать ответа — ну посылает агент-устройство нотификацию, что он детектировал, что связь с устройством разорвалась, ну и что ему делать потом с ответом? отменить разрыв соединения, если с верхнего уровня сказали "отменить"? Детектировал агент, что связь установлена — послал нотификацию, что установлена; детектировал что разоравана — послал, что разорвана. А обрабатывает там кто ещё предыдущие сообщения или нет — пофигу, главное — что бы сообщения "связь установлена", "связь разорвана" не перепутались местами. Плюс не этот агент выбирает время разрыва соединения, его тоже ставят перед фактом, что ему делать? Можно конечно сообщения складывать во внутренний вспомогательный буфер (кстати, обязательно в ФИФО порядке) и потом выдавать их, когда приходят ответы на предыдущие сообщения. Но попахивает уже маразмом...
Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования,
т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
Во-первых, все мы знаем что закон Мура изменился: теперь производители процессоров начинают делать многоядерные решения.
К примеру,
Intel has a project called Keifer aimed at producing at a thirty two
core processor timed for the market in 2009/2010. Sun
already has an eight-core (with four hardware threads per
core) Niagra machine on the market today. Цитата из книги Programming Erlang, Joe Armstrong
Все мы знаем что в "параллельном мире" существуют 2 основные концепции:
— Shared memory
— Message Passing Interface (MPI)
Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java.
Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Особенно мне нравится философское видение вопроса тем же Армстронгом
We don’t have shared memory. I have my memory. You have yours.
We have two brains, one each. They are not joined together. To
change your memory, I send you a message: I talk, or I wave my
arms.
You listen, you see, and your memory changes; however, without
asking you a question or observing your response, I do not know
that you have received my messages.
This is how it is with Erlang processes. Erlang processes have no
shared memory. Each process has its own memory. To change the
memory of some other process, you must send it a message and
hope that it receives and understands the message.
To confirm that another process has received your message and
changed its memory, you must ask it (by sending it a message).
This is exactly how we interact.
Sue: Hi Bill, my telephone number is 45 67 89 12.
Sue: Did you hear me?
Bill: Sure, your number is 45 67 89 12.
These interaction patterns are well-known to us. From birth onward
we learn to interact with the world by observing it and by
sending it messages and observing the responses.
Теперь вопрос, что же будет дальше. 32 ядра от Интел в следующем или 2010 году — очень неожиданно.
И Java не очень-то готова.
А уже написанные приложения работающие с Shared Memory, как я понимаю,
еще в худшем положении, если возникнет потребность увеличить ресурсы и использовать все ядра.
Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java.
Другой вариант — многоязычное приложение, что, возможно, тоже не самое лучшее — ведь разные языки должны интегрироваться, и интеграция потребует затрат.
remark,
R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
В случае Эрланга дедлок совсем не смертелен — потомушта процесс сохраняет возможность принимать другие сообщения. В том числе и те сообщения, которые вызовут badmatch с последующим перезапуском процесса (а мы же строим приложение на принципах OTP). Это кардинально отличается от замёрзшего на вайте потока.
Кроме того, в случае Эрланга есть эффективный и надёжный способ анализа программы на счёт отсутствия дедлоков: Towards a deadlock analysis for Erlang programs. Хотя возможно и для обычных джавы и дотнета есть подобные тулзы.
R>Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.
Не мог бы ты проиллюстрировать сиё подробнее. Всегда считал, что как только мы пишем receive, то тем самым задаём явное упорядочение.
R>Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.
Здравствуйте, Nicht, Вы писали:
DSG>>Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков. Вообще подход написания другой. N>А в erlang прям "Дивный новый мир". Простой пример. есть у меня адрес и индекс. Понятно что они всегда толжны соответствовать друг другу. Как в таком случае без синхронизации? (Пример гипотетический — так что не придерайся). Опять же, повторюсь что вся эта erlang модель в java да и везде, называется Compare and Set.
Эта erlang модель называется "гармонично взаимодействующие процессы" и придумана Дийкстрой, или более точно для erlang, она называется actors model. В яве вашей модель называется wait-notify, и придумана Хоаром — и она более безопасна, чем семафоры-мутексы, которые, кстати, тоже придумал Дийкстра. Есть другие модели синхронизации и параллельного взаимодействия, скажем, барьерная синхронизация, механизм рандеву, joint-calculus, etc. Все модели выразимы друг через друга, то есть эквивалентны, и этот факт доказан. Что ровным счетом ничего не меняет в контексте заданного автором вопроса.
Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
Compare-and-set — вообще никакая не модель, это процессорная инструкция, на которую полагаются lock-free data structures. В случае, разумеется, разделяемых данных, которых в actors model нет.
Еще раз повторяться вам, мне кажется, не стоит. А то народу может и надоесть.
Здравствуйте, RailRoadMan, Вы писали:
G>>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
RRM>Он на то и пример, чтобы быть простым.
RRM>Дельта зависит как от полученного числа так и от потока. В этом случае пример корректен, хотя получаемые числа и будут недерерминированы, а кто сказал, что это не то, что мы хотели? Потоки знают, что числа будут случайные.
Если все, что ты хочешь получить, это случайное число, то я выполняю алгоритмическую оптимизацию и убираю все твои потоки.
Разные модели программирования нельзя сравнивать на бессмысленных тестах, потому что применяются разные подходы к декомпозиции алгоритмов. Давай другой пример — осмысленный. Задача, которую надо распараллелить. И посмотрим, что получится.
G>>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
RRM>Почему по очереди? За единицу времени, один поток может пять раз поработать числом, второй шесть, третий вообще не работал с ним. Потом ситуация изменится. Кроме того потокидолдны получать число каждые раз не только для того чтобы потом обновить но и для дальнейшего использования
Чушь полная. Все вычисления сериализованы, и конкурируют за общий ресурс. Это очень плохая программа.
Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Когда нечего сказать — переходят на личности (ну или на оценки примеров).
Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.
А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.
RRM>Я описал совершенно надуманный пример максимально оптимальный для разделения памятию. Это в первую очередь пример. RRM>Готов ты именно его решить на передаче сообщений, что бы получилось эффектичнее чем с разделением памяти?
Ты не описал вообще никакого примера. Ты предложил нам с Синклером эмулировать разделяемую память на одной переменной поверх сообщений. Что разумеется не получится эффективнее, чем прямое использование разделаемой памяти, и чего ни один нормальный человек, работая с сообщениями, в реальных условиях делать не будет.
RRM>Да — с удовольствием посмотрю. RRM>Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.
Ну да, если взять плохо написанную программу на разделяемой памяти, да переписывать на сообщениях, эмулируя разделяемую память — станет еще хуже. С этим кто спорит-то?
G>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
Здравствуйте, Gaperton, Вы писали:
G>А то, что OpenMP, например, в тесте "IS" не медленнее, а С.О.С.Е.Т. (да именно так) на целых 139% — это, конечно, не имеет никакого отношения к делу, и никак не может служить опровержением тезисов remark, который установил безусловные и неоспоримые преимущества разделяемой памяти над передачей сообщений, не проводя никаких тестов, не читая статей, и не делая поиска в интернете . Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Ну зачем эти устаревшие ужасы! Ментальное сканирование, скажешь тоже... Кто там будет копаться в этих твоих потемках, отделяя детские комплексы от урматов? См. Minority Report — наши специалисты уже предсказали, что ты проиграешь этот спор в середине 2009.
З.Ы.: Если серьезно, то незачем подкалывать ремарка. Он честно старается выяснить истину. Позитивным моментом в этой драке на табуретках является то, что вы притаскиваете интересные ссылки, до которых большинство читателей бы сами не дорыли. А вот взаимное ущемление самолюбий — момент безусловно негативный.
Лично мне как раз интересно, есть ли способ выбрать одну модель многозадачности, которая бы показывала оптимальную производительность на широком классе задач.
Или хотя бы понять границы оптимальности для каждой из моделей.
А интересно мне это потому, что в последние годы я регулярно наблюдаю, как "интуитивно оптимальные" решения прогибаются под напором "очевидно неоптимальных".
Когда Java с очевидно тормозным GC рвет на веб-сервере плюсы как тузик грелку.
Когда корявый код, сгенерированный VC++, на 30% уделывает по производительности красивый код, написанный вручную ассемблерщиком.
Когда ось, не использующая аппаратную изоляцию процессов, уделывает про IPC промышленные оси, использующие x86 на полную катушку.
Когда векторный UI на HTML рвет по производительности классику на comctl32.
И так далее.
Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику.
И сможет ли "очевидно тормозной обмен сообщениями" порвать "интуитивно быструю" разделяемую память.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[53]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, eao197, Gaperton Вы писали:
R>"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
Коллеги, давайте перестанем друг друга подкалывать и не будем выяснять кто первый начал, просто перестанем.
Понимаю, что некоторый высказывания коллег провоцируют, но давай просто будем немного взрослее.
А то взрослые мужики, обсуждаете интересную тему, но ведете себя как малые дети в песочнице.
Re[54]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AVM, Вы писали:
AVM>Коллеги, давайте перестанем друг друга подкалывать и не будем выяснять кто первый начал, просто перестанем. AVM>Понимаю, что некоторый высказывания коллег провоцируют, но давай просто будем немного взрослее. AVM>А то взрослые мужики, обсуждаете интересную тему, но ведете себя как малые дети в песочнице.
А еще лучше, если кто нибудь возьмет обсуждаемую задачу и напишет совсем совсем простой тест с очередью и разделяемой памяти и просто померяет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Nicht, Вы писали:
N>Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
N>А в erlang прям "Дивный новый мир". Простой пример. есть у меня адрес и индекс. Понятно что они всегда толжны соответствовать друг другу. Как в таком случае без синхронизации? (Пример гипотетический — так что не придерайся). Опять же, повторюсь что вся эта erlang модель в java да и везде, называется Compare and Set. Это сравнительно новая технология в процессорах позволяет менять данные не блокируясь на них. Там уже люди кучу алгоритмов напридумывали, который используются в java.util.concurrent на пример.
Боюсь Вы совсем не понимаете, что такое Эрланг.
N>Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам N>И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Без поддержки виртуальной машины, это в принципе невозможно.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, remark, Вы писали:
R>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.
Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.
R>В контексте "языки общего назначения vs языки специального назначения" нельзя упускать из виду тот факт, что "практически любая фича/идея/модель будучи реализована в языке специального назначения достаточно тривиально реализуется и в языке общего назначения" (вольный перевод, по-моему, Страуструпа).
Также нельзя упускать из виду, что Эрланг тоже язык общего назначения. Насчет "достаточно тривиально" очень спорное утверждение.
R>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).
Напиши. Вся проблема в том, что ты этого не напишешь.
R>Так же можно привести такой пример. Допустим в программе есть некий кэш данных (хэш-мап). В Erlang подходе мы этот хэш-мап отдадим одному процессу, и когда нам надо будет к нему обратиться будем посылать этому процессу сообщения. На физическом уровне это будет включать: создание объекта сообщения, помещение его в очередь, переключение контекста с текущего процесса, доставание сообщение сообщения другим процессом, обработку сообщения, удаление первого сообщения, создание сообщения-ответа, помещение сообщения-ответа в очередь, переключение контекста опять на первый процесс, доставание сообщения из очереди, удаление сообщения. R>В модели с общей памятью мы... просто обращаемся к хэш-мапу.
Переключение контекста очень дешевое, т.к. там легковесные потоки.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, WFrag, Вы писали: S>>Впервые слышу про NUMA в Java. WF>http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
Бугога. И какое отношение это имеет к заявлениям DenysSG? Каждый объект по-прежнему существует в единственном экземпляре; никаких репликаций не выполняется.
За что люблю этот форум — так за то, что если пропустил comedy club в субботу, так тут не дадут заскучать.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, DenysSG, Вы писали: DSG>Сейчас нету времени искать, но должно быть здесь DSG>Threads and Locks
Естественно, там ничего относящегося к твоим фантазиям нету.
Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
G>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...
G>Даже если твою фразу понимать так, как ты здесь пишешь, то тезис о наличии значимых преимуществ у разделяемой памяти, которых якобы лишена модель передачи сообщений, тебе надо для начала доказать. Потому, например, что практика применения MPI и OpenMP его на данный момент не подтверждает. MPI во многих случаях быстрее, чем OpenMP даже на SMP конфигурациях с общей памятью.
Здравствуйте, remark, Вы писали:
R>Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью. R>НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
Тезис доказывает тот, кто его выдвигает. Я говорил, что у разделяемой памяти есть некие недостатки, которых модель с
сообщениями лишена. Это я готов доказать.
Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
Это ты должен доказать, что они у разделяемой памяти _есть_, а не я, что их нет. Тезис — твой. Для начала — тебе стоит хотя бы озвучить эти декларируемые преимущества. Скорость им не является — MPI обходит OpenMP во многих случаях даже на SMP.
R>Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
Тесты в данной статье производятся на SMP-машине, а не на распределенном кластере.
R>Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ. R>Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
Сформулируй мою точку зрения, которую я пытаюсь доказать. Очень любопытно. По-моему, я оппонирую тебе насчет твоего тезиса о якобы имеющихся преимуществах разделяемой памяти, которые необходимо утрачиваются в модели передачи сообщений.
R>Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
Настоящие программы содержат натуральные способы управления параллелизмом.
Выполнение некоторого этапа зависит от результатов выполнения предыдущего. Если это не так, то это взрывной параллелизм, который возникает, например, при умножении матриц (из O(N^2) данных получается O(N^3) операций).
В dynamic data flow сообществе с этим отлично умеют бороться. Штука называется throttling, успешно применялась ещё в CM-5, по-моему.
Читайте книги, это прикольно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
R>>Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью. R>>НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
G>Тезис доказывает тот, кто его выдвигает. Я говорил, что у разделяемой памяти есть некие недостатки, которых модель с G>сообщениями лишена. Это я готов доказать.
Это оставим, с этим никто не спорит.
G>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения. У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: (1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки. (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО. (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
Пока некоторые всё ещё пребывают в эйфории от обмена сообщениями, другие уже просто прошли этот этап, увидели и осознали недостатки этого подхода, и положили его свой набор инструментов наравне с другими.
R>>Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
G>Это ты должен доказать, что они у разделяемой памяти _есть_, а не я, что их нет. Тезис — твой.
А твой-то какой тезис в данном контексте? Беспартийный? Просто тусуешься вокруг и бросаешь умные фразы?
G>Для начала — тебе стоит хотя бы озвучить эти декларируемые преимущества. Скорость им не является — MPI обходит OpenMP во многих случаях даже на SMP.
Уже озвучил. Попробуй обращать внимание на то, что и другие пишут.
Я гляжу, мои надежды не оправдались, и ты всё-таки не намеренно вносишь логические ошибки. Если MPI где-то обходит OpenMP, то это не значит, что разделяемая память не имеет преимуществ. Не согласен? И озвучь, кстати, что это за SMP такой, о котором ты говоришь.
R>>Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
G>Тесты в данной статье производятся на SMP-машине, а не на распределенном кластере.
Что это за SMP-то кстати? Для супер-вычислений, с сотней процессоров, c распределеннной памятью и NUMA архитектурой, датирован 2000 годом. Ничего не путаю?
R>>Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ. R>>Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
G>Сформулируй мою точку зрения, которую я пытаюсь доказать. Очень любопытно. По-моему, я оппонирую тебе насчет твоего тезиса о якобы имеющихся преимуществах разделяемой памяти, которые необходимо утрачиваются в модели передачи сообщений.
Сейчас попробую сформулировать твою точку зрения, которую ты пытаешься доказать: Gaperton — самый крутой и эрудированный, за словом в карман не лезет, аргументы приводит не в тему, но зато сильные, и готов спорить, даже не читая, что пишет оппонент.
Здравствуйте, remark, Вы писали:
G>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
R>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.
Не удивляйся, в дискуссии вовсе не обязательно у обеих сторон должны быть строго противоположные тезисы. В ней доказательство одного тезиса ни как не связано с тезисом противоположной стороны.
Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>ААААААААААА! Вы вместе?
G>Ага. Что, страшно? По-моему, неплохая у нас компания получилась. Синклер, thesz, и я. Мне нравится.
Ну молодцы, радуйтесь дальше, компания пытающаяся доказывать нерелевантными примерами, стирающая в ответе аргументы оппонента, зато придирающаяся к словам, и обвиняющая в отсутствии этих самых стёртых аргументов, приплетающая какие-то римские дискуссии, несущая логическую ахинею...
Против Синклера и thesz то я ничего не имею, но ты, блин, — настоящий тролль.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
E>>>Питон там давно порвали на британский флаг.
G>>C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.
E>Тогда возникает вопрос: E>
E>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает.
E>под "отлично" здесь понимается "правильно, но в четыре раза медленее"?
Под "отлично" здесь понимается то, что задача хорошо ложится на модель передачи сообщений, а Эрланг служит для иллюстрации.
Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях, а не о том, что С++ быстрее чем Эрланг. В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.
G>>Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.
E>Видимо, у нас разные представления о разделяемой памяти и задачах, которые решаются с помощью передачи сообщений.
Мое представление в целом соответствует взглядам Дийкстры и Хоара, ты уж меня прости, классическое образование — ничего не могу с собой поделать. И комплексовать на тему, что оно у меня не такое, как у тебя — тоже не получается, извини.
Читайте книги, это прикольно. ((с) Зефиров)
G>>В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются...
E>Если только процессы не работают на разных нодах.
А что, изобрели способ передавать данные с одного компа на другой без копирования? С этого момента подробнее.
В Эрланге нет абсолютно никакого резона запускать несколько нодов на одной машине — виртуальная машина знает, что такое SMP и умеет его готовить.
Здравствуйте, eao197, Вы писали:
E>1. Я не могу отвечать за remark-a.
Ну так и не надо вообще за него тогда впрягаться.
E>3. Я воспринимаю эту фразу в том же смысле: "в некоторых случаях обмен сообщениями на любых очередях останется медленее на несколько порядков", но не в 100% случаев.
Э нет. Вот если бы он сказал именно так, то конечно можно было много воды налить. Но он ясно выразился — "ситуация, где нам надо только считать данные".
E>4. В качестве примера такой ситуации
У рыбы блох нет, а вот если бы были ...
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Слыш, Sincler, ты хотел примера, где у гармонично взаимодействующих процессов есть убедительный чистый выигрышь? Так вот, eao197 преподнес все ценителям данного подхода настоящий подарок. Он наконец дал пример, в котором отрыв у "сообщений" будет точным убедительным — а я, честно говоря, до последнего момента думал, что такое в принципе невозможно. Спасибо, дорогой друг eao197.
Ну а теперь, парни, читаем задачу. Это отличный пример, как можно писать на Java или C#, в надежном стиле, с иммутабельными структурами данных, да еще и выиграть в производительности.
E>4. В качестве примера такой ситуации я могу привести гипотетический пример с маршрутизацией звонков/sms по номерам телефонов: имеется большая таблица или специальное дерево, с помощью которой по префиксу номера адресата определяется оператор, которому принадлежит адресат. Эта таблица может совместно использоваться несколькими потоками-маршрутизаторами (может быть даже несколькими десятками таких потоков) -- они обращаются к ней только для чтения.
И имеется один или два потока, которые на основании какой-то внешней информации время от времени вносят изменения в данную таблицу. Например, если процент успешно обработанных пакетов в канале связи с каким-то операторам падает ниже некоторого уровня, то его трафик переадресуется через других операторов.
Таблица выполняется в виде функционально-чистого сбалансированного дерева. Когда изменяющий поток ее изменяет, он высылает потокам worker-ам новую ссылку на корень одним сообщением, multicast-рассылкой. Все.
Это будет работать быстрее, чем [мутабельная] "разделяемая память" [требующая явной синхронизации], по причине того, worker-ы при look-up-ах по таблице не будут пользоваться вообще никакими примитивами синхронизации, а функционально-чистое дерево обладает свойством транзакционности. Учитывая то, что look-up выполняется в сотни раз чаще, чем изменения.
E>В данном случае оформление таблицы маршрутизации в виде агента, взаимодействие с которым выполняется только в режиме асинхронного обмена сообщениями, может повысить накладные расходы по сравнению с разделяемой памятью в разы. Только за счет того, что заявки должны складироваться в какой-то очереди, извлекаться оттуда, обрабатываться, ответ должен сохраняться в какой-то другой очереди и т.д.
Не я реально не пойму — ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы, и путая "гармонично взаимодействующие процессы" с полным отсутствием разделяемой памяти? Честно?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, eao197, Вы писали:
G>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
G>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
Example POWER Implementation for C/C++ Memory Model: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
(раздел "PowerPC Code Sequences")
И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке.
E>Ничего подобного. Писатель создает новую копию структуры, а затем подменяет ссылку на нее в глобальной переменной одной атомарной операцией (перед которой писатель выполняет все необходимые fences).
Именно. Так где используется широковещательная рассылка сообщений для публикации объекта, можно использовать обычную публикацию указателя, мьютекс тут не нужен. Не надо его сюда приплетать.
G>>Касательно того, что atomic_read, на котором eao
E>eao197, eao -- это такое же некорректное сокращение, как и Gaper.
Ещё одна из его фишек, типа называть собесебника на "Вы", но при этом "вы" писать с маленькой буквы, или вставлять в середину абзаца вспомогательное предложение что типа собеседник не написал ни одной программы, или что собеседнику никогда не додуматься до таких первоклассных решений как Gaperton'у. А потом ещё как ни в чём не бывало говорить, что он типа выше таких низких вещей, и что его интересует только техническая дискуссия.
Я ещё могу понять, когда человек высказывает такое прямо и открыто. Но когда вот так, изподтяжка...
G>>собирался решать эту задачу, медленнее обычного — это правда и остается правдой, в данном случае нужен честный барьер в получателе чтобы все работало.
E>Зачем барьер в получателе?
Вот видишь, Gaperton, люди-то тут следят за ходом дискуссии. И твои левые попытки оправдать свою техническую неграмотность приплетанием левых фактов типа, что получателю надо упорядочивать какие-то store, или пуще того какие-то store-load последовательности — не остаются не замеченными. Тебя уже все раскусили.
Здравствуйте, eao197, Вы писали:
E>Можно еще одну ситуацию вспомнить. Допустим, у нас есть агенты s и r. Они работают на узлах A и B (имеются в виду узлы локальной сети). Но эти узлы соеденены не напрямую, а через несколько других узлов. И путь от A к B может лежать через маршрут A -> D -> E -> B или через маршут A -> C -> B. Агент s с узла A отправляет сообщения m1, m2, m3. Сообщения m1 и m3 уходят по маршруту A->D->E->B, а сообщение m2 -- по маршруту A->C->B. В этом случае сообщения r может получить как m2, m1, m3, так и m1, m3, m2, так и m1, m2, m3. Если логика взаимодействия s и r построена на гарантиях ФИФО для сообщений от одного источника, то все накрывается медным тазом.
Вот мне в этом плане вот что интересно: протокол IP как раз описывает ровно эту ситуацию.
И есть традиционное решение для построения на нём FIFO порядка, которое не требует никакой синхронизации "в середине", широко известное под аббревиатурой TCP.
Я так понимаю, что концепция примерно такая:
1. В схеме single producer-single consumer можно построить FIFO на протоколе без упорядочивания, применив 1-в-1 стандартные техники из TCP/IP, выкинув обработку потери пакетов. Получатель упорядочивает сообщения на своей стороне. В характерных реалистичных примерах "окно просмотра" для таких получателей будет не очень большим. Затраты оценить навскидку сложно, но они не зависят от латентности канала между отправителем и получателем. Это означает, что всегда найдется такое значение латентности, начиная с которого этот механизм окажется выгоднее, чем классическая синхронизация на семафорных примитивах.
2. В схеме multiple producers-single consumer никакого порядка лучше не вводить. Ну то есть если есть желание устроить себе Bottleneck, то можно устроить генератор sequence и теребить его. Но в общем случае понятия порядка и одновременности один хрен становятся еще слабее, чем в специальной теории относительности. В том смысле, что могут происходить даже артефакты, выглядящие как нарушение принципа причинности.
3. Ничего сильно плохого от этого не произойдет. Не так уж много есть мест, где прямо так нужна вот эта упорядоченность. Управление устройством не делается толпой; над устройством висит агент-драйвер, который его мучает в эксклюзивном синхронном режиме. Все остальные должны договариваться с драйвером. Ну и там уже два варианта: либо протокол подразумевает произвольный порядок (вот тебе содержимое страницы номер X, сбрось ее на диск), либо см.п.1.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[67]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.
Полностью корректна. Еще раз: если отправителю/получателю важно, в каком порядке приходят сообшения, он просто добавляет в сообщения seq number.
Другого способа нет — разве что неявно всовывать LSN принудительно во все сообщения, но я не вижу в этом никакого смысла.
E>В случае отсылки сообщений, если в сообщениях не заданы эти параметры предшествования/упорядочения самим разработчиком, информации для восстановления порядка отсылки сообщений нет. Можешь увидеть это на примере SMTP -- если ты отправляешь одному и тому же получателю несколько писем, то они могут придти к получателю в разном порядке (особенно, если сообщения сильно различаются по размеру).
И, заметь, никакой проблемы это не представляет.
Если получатель хочет упорядочить по порядку отправки — нет проблем, в каждом письме есть хидер sent timestamp.
Опять же, если мне важно, чтобы ты читал письма в определенном порядке, то я включу эту информацию в письмо.
Еще раз намекаю, что с моей точки зрения, не стоит запихивать поддержку FIFO прямо в самый-самый нижний слой системы. Достаточно сделать удобные библиотеки, позволяющие описывать протокол взаимодействия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
R>Пока не похоже. Пока что ты обрисовал решение на *логическом* уровне. Попробуй обрисовать его *эффективную* реализацию на *физическом* уровне в софте для общего случая. Ты увидишь, что это сделать нельзя. То, что ты говоришь — это решение, но это решение либо для железа (ты ж оттуда эту идею взял?), либо для частных случаев в софте. Но не для общего случая в софте. Ты не можешь с таким решением выходить и громко заявлять, что ты решил какую-то общую проблему, и что "Её можно сделать сколь угодно мало требовательной путём группировки сообщений.".
Почему не могу. Могу. Смотри.
Громко заявляю, что я решил какую-то общую проблему, и что "её можно сделать сколь угодно мало требовательной путём группировки сообщений".
R>Как ты будешь справляться со значительной внесённой латентностью? Кто будет рулить этими промежуточными узлами? Отдельные потоки, рабочие потоки этим нельзя нагружать, т.к. они могут обрабатывать сообщения долго.
Так не надо, чтобы долго обрабатывали. Надо, чтобы недолго.
Более того, динамический поток данных даёт возможность рулить размером программы сообщения. Можно балансировать — чем больше входов у узла, тем больше будет программа узла и меньше выявляемый параллелизм выше уровня ILP. И наоборот.
R> Отдельные процессоры выделять под эти потоки не целесообразно. Если они будут разделять процессоры с другими потоками, значит они могут шедулиться для выполнения через 40 мс и больше. Ну вот проходит такое сообщение через эту сеть и получаем внесённую латентность 200 мс.
Да.
При условии, что оно через неё проходит.
R>Такой схемой ты порождаешь массу дополнительно трафика по протоколу когерентности.
Нет. Я не понимаю, откуда ты это взял.
R>В традиционной схеме у нас сообщение сразу качует от кэша-источника в кэш-получателя. С твоей схемой оно покачает по N кэшей. Это чудовищный оверхед, проще сразу сделать одну атомарную RMW операцию и отправить сообщение получателю. Как ты предлагаешь это нивелировать?
Путём высокопараллельной обработки небольших сообщений.
R>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё
R>Динамический лоад-балансинг как будешь делать? Пока что ты увильнул статическим.
Динамическую балансировку нагрузки делать трудно, согласен. Но совсем не по той причине, о которой ты думаешь.
Дело в том, что одно из нескольких сообщений, необходимых для старта программы обработки оной группы сообщений может сперва пойти на один узел, а потом — динамически, — на другой.
Но это тоже решаемо. Достаточно отправлять выше по иерархии те сообщения, что не должны сейчас выполняться на этом процессоре.
R>Но это не катит для систем общего назначения. Обработка сообщений выполняется недетерминированнное, но малое и с небольшой дисперсией время, зависит от входных данных, не зависит от внешних систем, плюс часть процессоров периодически занимается другими процессами. Тот лоад-балансинг, который ты описал всасёт в такой ситуации — скорость работы системы будет определяться самым медленным процессором, а он может быть сколь угодно медленным.
Вставки мои.
Посему достаточно поменьше нагружать самый медленный процессор.
Вот.
R>Вобщем, пока ты никакой общей задачи не решил, и ничего нового не открыл. Я подобные решения применял, но в очень *частных* случаях, и оно не обобщается на общий случай.
Я и не решал. "Всё украдено до нас" (C) ОЫ
R>Если можешь обрисовать решения всех проблем, которые я указал — то, пожалуйста. Буду очень признателен. И это будет, наверное, первая интересная и новая информация в этом топике.
Я ленюсь.
Вот ссылки: http://thesz.mskhug.ru/svn/hiersort/ — там в подкаталоге doc лежит статья про машину динамического потока данных с частичной сортировкой сообщений.
http://thesz.livejournal.com/545287.html — чуток описания про преобразование обычной программы в программу для машины динамического потока данных. Делаем такую VM и все преимущества у нас в кармане.
Где-то у меня ещё что-то было, но я сейчас отыскать не могу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях
Не-а не понял. В указанном мной примере WideFinder наилучшего результата добиваются программы, в которых несколько потоков используют один и тот же буфер для записи данных и для их анализа. Т.е. используют разделяемые между несколькими потоками данные. Стоит только начать передавать каждому потоку копию этого буфера для эксклюзивного пользования -- и кранты, производительность упадет.
То, о чем говоришь ты -- это когда сообщения используются лишь для управления синхронизацией действий между потоками, но основная работа все равно ведется с разделяемой памятью. Когда объем передаваемых в сообщении данных настолько мал, что общая разница в затратах между явной синхронизацией и синхронизацией на сообщениях будет ниже погрешности измерений.
Хотя может вы тут с remark-ом как раз обсуждаете затраты на выполнение синхронизации на основе тупых mutex/condition_variable по сравнению с затратами на синхронизацию через очереди сообщений. Тогда дико извиняюсь, не понял этого из предшествующего разговора.
G>В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.
Тем не менее, что-то не видно, чтобы MPI порвал тот же OpenMP. Даже из упомянутой тобой статьи.
The performance analysis (hardware performance counters and breakdown of the execution time) of our OpenMP SPMD version of the NAS benchmark demonstrates that we succeed in getting the same performance as the MPI version for the computing loops and better performance than the MPI version for the communication part.
Прочитайте хотя бы сами то, что советуете читать другим. Это прикольно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[34]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Таблица выполняется в виде функционально-чистого сбалансированного дерева. Когда изменяющий поток ее изменяет, он высылает потокам worker-ам новую ссылку на корень одним сообщением, multicast-рассылкой. Все.
Ссылку на корень можно подменить даже не рассылая ее worker-ам.
Более того, даже сбалансированное дерево не обязательно делать полностью иммутабельным -- отдельные его фрагменты могут подвергаться изменениям, но при этом не требовать синхронизации доступа.
G>Не я реально не пойму — ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы, и путая "гармонично взаимодействующие процессы" с полным отсутствием разделяемой памяти? Честно?
Ты правда думаешь, что можешь просить меня не переходить на личности утверждая, что я не написал ни одной программы?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>На практике 7% называется "одинаковая производительность", и никто не будет расшибаться в лепешку, чтобы эти 7% ликвидировать.
Расшибаться не обязательно. Достаточно выбрать для задачи подходящий инструмент. В некоторых случаях это будет OpenMP.
E>>На практике, ты не сможешь этот выигрыш нивелировать. G>На практике, смогу. Если захочу.
"Дайте мне точку опоры и я сдвину Землю". Вижу, что аргументы в разговоре уже перешли в разряд "непробиваемых".
G>В любом случае, тебе-то откуда знать, что я смогу а что нет.
Судя по твоему заявлению о том, что на C++ можно программировать в стиле Erlang с использованием MPI.
G>Да? Тогда прокомментируй еще вот это: G>
G>А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
А там все понятно. Remark дал эту оценку одному вполне конкретному примеру. Вот этому
. Все. Никаких претензий на всемирное господство разделяемой памяти.
G>Так вэлкам! Что ж ты никак не покажешь-то эти преимущества? Что тогда для тебя преградой то является, а?
Нет смысла заниматься доказательствами, когда глобальная переменная-указатель в любой момент может быть объявлена вырожденой очередью сообщений длиной 1. Что такой же маразм, как и утверждение, что точка является частным случаем прямой.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G> Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.
Пример из моего последнего выступления на Платформе:
Здравствуйте, abch-98-ru, Вы писали:
A9R>а у тебя код красивый, но не рабочий пока A9R>что или как запускать-то чтобы заработало-то в смысле за дедлочило A9R>можно по слогам
-module(dl).
-export([start/0,sem/0,start_two/2]).
sem()->sem(none,{"",""}).
sem(State,{Txt,Id}=Mess) ->
receive
{take, A} when State==none->
A ! {taken, self()},
sem(taken,{"take",""});
{free, A} when State==taken->
A ! {freed, self()},
sem(none,{"free",A})
after 3000->
io:fwrite("timeout dl with ~p ~s ~n", [Id,Txt]),
sem(none,{"",""})
end.
start_two(P1,P2)->
P1 ! {take, self()},
two(none,P1,P2,"~p ~p~n").
two(State,P1,P2,Mess) ->
receive
{taken, P1} when State==none->
timer:sleep(1000),
P2 ! {take, self()},
two(take,P1,P2,"!!!DEADLOCK!!! taken ~p cant take ~p ~n");
{taken, P2} when State==take->
timer:sleep(1000),
P2 ! {free, self()},
P1 ! {free, self()},
two(none,P1,P2,"cant take ~p, nor ~p ~n")
after 5000->
io:fwrite(Mess,[P1,P2]),
two(none,P1,P2,"~p ~p~n")
end.
start() ->
P1 = spawn (?MODULE, sem, []),
P2 = spawn(?MODULE, sem, []),
spawn(?MODULE, start_two, [P1,P2]),
spawn(?MODULE, start_two, [P2,P1]).
Здравствуйте, eao197, Вы писали:
G>>Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях
E>Не-а не понял. В указанном мной примере WideFinder наилучшего результата добиваются программы, в которых несколько потоков используют один и тот же буфер для записи данных и для их анализа. Т.е. используют разделяемые между несколькими потоками данные. Стоит только начать передавать каждому потоку копию этого буфера для эксклюзивного пользования -- и кранты, производительность упадет.
"Передача сообщений" как модель синхронизации не говорит, надо тебе передавать копии буферов, или нет. Она даже не утверждает, что нельзя иметь общих данных. Она утверждает, что нельзя иметь мутабельные общие данные, которым требуется синхронизация, и что единственный доступный способ коммуникации параллельных процессов — это асинхронная посылка сообщений с семантикой мэйлбокса. Как именно она реализована — совершенно неважно с точки зрения модели.
E>То, о чем говоришь ты -- это когда сообщения используются лишь для управления синхронизацией действий между потоками, но основная работа все равно ведется с разделяемой памятью. Когда объем передаваемых в сообщении данных настолько мал, что общая разница в затратах между явной синхронизацией и синхронизацией на сообщениях будет ниже погрешности измерений.
Да, и это правильно. "Общая память" — это вообще не модель синхронизации. На общей мутабельной памяти можно применять семафоры, wait-notify (близко к мониторам Хоара), рандеву с protected objects как в Аде, или "аккорды", как в Polyphonic C# и joint calculus. На общей иммутабельной памяти отлично живет обмен сообщениями.
В этой ветке "общая память" применяется как собирательный термин для всех методов, допускающий наличие разделяемого изменяемого состояния, из которых спорщики знакомы в массе своей только с семафорами, и поэтому не могут отличить "модель синхронизации" и "общую память", думая что это одно и то же. Это и есть источник путаницы.
Чтобы быстро поиметь представление, близкое к моему — открой учебник Танненбаума по оперсистемам (у тебя он есть? Если нет — рекомендую купить), и прочти главу про синхронизацию. Знание — свет. Особенно, если его получение занимает меньше часа. Флуд — тьма.
G>>В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.
E>Тем не менее, что-то не видно, чтобы MPI порвал тот же OpenMP. Даже из упомянутой тобой статьи. E>
E>The performance analysis (hardware performance counters and breakdown of the execution time) of our OpenMP SPMD version of the NAS benchmark demonstrates that we succeed in getting the same performance as the MPI version for the computing loops and better performance than the MPI version for the communication part.
E>Прочитайте хотя бы сами то, что советуете читать другим. Это прикольно.
Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?
Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.
Здравствуйте, DenysSG, Вы писали:
DSG>Java и Erlang используют разные модели. Java — Shared Memory, Erlang — MPI.
Да, и ключивое слово тут модель. Просто сейчас erlang лучше передает модель синхронизации реализованных в севременных процессорвах. Прошу заметить, что тут я не пускаюсь в полемику так как просто не знаю erlang.
Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
DSG>Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков. Вообще подход написания другой.
А в erlang прям "Дивный новый мир". Простой пример. есть у меня адрес и индекс. Понятно что они всегда толжны соответствовать друг другу. Как в таком случае без синхронизации? (Пример гипотетический — так что не придерайся). Опять же, повторюсь что вся эта erlang модель в java да и везде, называется Compare and Set. Это сравнительно новая технология в процессорах позволяет менять данные не блокируясь на них. Там уже люди кучу алгоритмов напридумывали, который используются в java.util.concurrent на пример.
DSG>В Java этого нету. В JVM поддержка multicore есть. В Java нужно писать explicit code используя сторонние библиотеки.
Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам
И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Здравствуйте, yumi, Вы писали:
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.
Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.
Здравствуйте, Sinclair, Вы писали:
R>>Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков, S>А как же lock()? Ты думаешь, lock() не приведет к блокировке потока в ожидании того, пока кто-то другой не сделает unlock()?
Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Здравствуйте, DenysSG, Вы писали:
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
Есть еще STM (Software transactional memory) и использование полностью immutable data types.
DSG>А что ещё есть — Scala или Erlang через Jinterface Application.
Здравствуйте, DenysSG, Вы писали:
DSG>Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования, DSG>т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
Java давным давно позволяла писать многопоточные приложения, причем без использования сторонних библиотек. И так же давным давно Java использует все ядра, какие найдет в вашем процессоре, причем опять без использования сторонних библиотек и без каких-либо дополнительных настроек.
Что касается MPI — то это, скажем так, с одной стороны, некоторое конкретное апи, а сдругой стороны просто идеология. Тут, конечно, без сторонних библиотек не обойтись, причем есть готовые библиотеки для MPI в виде JNI оберток вокруг с-шных реализаций MPI, есть Pure Java библиотеки, реализующие MPI, и есть библиотеки, которые предоставляют аналогичный по смыслу сервис обмена сообщениями между потоками при помощи не-MPI апи. Конечно, нормальный MPI позволяет общяться не только ядрам в одном процессоре, но если рассматривать отдельно взятый компьютер, то передача сообщений между потоками сделана, очевидно, через ту самую общую памать.
Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Здравствуйте, DenysSG, Вы писали:
DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели. DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
А Erlang автоматически будет, что ли? Это зависит от программы. Она может и на 1.5 процессоре в I/O упереться.
Непонятно, что именно нужно распараллелить и какие проблемы это сделать на Java, кроме общих слов? Пример какой-нибудь.
DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Есть пулы потоков. 100.000 потоков, конечно, не создавать, но чтобы загрузить 32 процессора — запросто (скажем, штук 200 потоков создать — и всех делов).
А вот интересно, если много ядер, то архитектура скорее всего NUMA. Erlang-машина это как-то учитывает? Не получится ли так, что обмен сообщениями убьёт производительность Erlang-программы, в то время, как неспешные 32 потока Java будут (каждый со своей областью памяти, локальной для процессора) осваивать процесорное время, выполняя полезные задачи?
Здравствуйте, Курилка, Вы писали:
К>А есть примеры как поддержка сообщений может быть поддержана аппаратно?
А на транспьютерах. Тамошние каналы как раз служат для передачи сообщений, а вот разделяемой памяти у них, насколько я понимаю, нет вовсе.
Между прочим, сейчас начинается некий ренессанс транспьютеров — видимо, вследствие того, что научились эффективно их использовать
Re[36]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
S>Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.
Я здесь вижу только одну проблему: если у нас есть 2 потока, модифицирующих дерево, и оба они "одновременно" получат сообщение, приводящее к необходимости это дерево модифицировать. Тогда каждый из них построит своё новое дерево, и после этого разошлёт новый корень, но в результате данные, изменённые одним из потоков будут потеряны.
Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
T>>Разделяемая память поддержана аппаратно (да-да! поддержана аппаратно), передача сообщений — нет. Посмотрим, что будет, если будет хотя бы поддержка обоих. К>А есть примеры как поддержка сообщений может быть поддержана аппаратно?
Это совсем низкий уровень, совсем маленькие сообщения.
Сравни общую простоту реализации и масштабируемость с простотой реализации и масштабируемостью "системы с разделяемой памятью", ранее известной под именем обычный процессор (RISC, допустим).
В обычных процессорах разделяемая память — регистровый файл.
И мало кто знает, что в лучшем представителе семейства RISC DEC Alpha 21264 оная память была разделена на две части по числу каналов исполнения инструкций и половинки синхронизировались через такт после окончания операции.
Это ужас просто.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Aib, Вы писали:
Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
Здравствуйте, DenysSG, Вы писали:
DSG>Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования, DSG>т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.
DSG>Во-первых, все мы знаем что закон Мура изменился: теперь производители процессоров начинают делать многоядерные решения.
DSG>К примеру, DSG>
DSG>Intel has a project called Keifer aimed at producing at a thirty two
DSG>core processor timed for the market in 2009/2010. Sun
DSG>already has an eight-core (with four hardware threads per
DSG>core) Niagra machine on the market today.
DSG>Цитата из книги Programming Erlang, Joe Armstrong
DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>- Shared memory DSG>- Message Passing Interface (MPI)
DSG>Очень многие языки, в т.е. пошли по первому пути, в т.ч. и Java. DSG>Я не знаком с обширным мнением экспертов по данному вопросу, но то что я прочитал — первый путь (Shared Memory), как особенно видно сейчас, неудачен.
Шаред то она шаред но все мы знаем что у потоков в java есть свое пространство памяти где и происходит в основном вся работа.
DSG>This is exactly how we interact. DSG>Sue: Hi Bill, my telephone number is 45 67 89 12. DSG>Sue: Did you hear me? DSG>Bill: Sure, your number is 45 67 89 12. DSG>These interaction patterns are well-known to us. From birth onward DSG>we learn to interact with the world by observing it and by DSG>sending it messages and observing the responses. DSG>[/q]
Так это же Compare And Swap. В java вполне себе присутствует. С учетом, опять же, собсвенных пространств памяти у потоков, java не сильно отличается от erlang.
Надеюсь в erlang так же аллегорично описывается атомарность изменения нескольких значений и поддержка данных up to date в нескольких "мозгах".
DSG>Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java. DSG>Другой вариант — многоязычное приложение, что, возможно, тоже не самое лучшее — ведь разные языки должны интегрироваться, и интеграция потребует затрат.
DSG>У кого какое мнение — высказывайтесь.
Вообще надо понимать что ноги многозадачности растут из архитектур процессоров. Вот есть сейчас в процессорах CAS, вот и везде он есть. Язык всего лишь предоставляет модель использования. Будет что-то другое вместо CAS и языки тоже модифицируются и модель ерланга не покажется уже такой красивой.
Как мне кажется, от многозадачности можно получить больше плюсов, когда ты ее используешь с умом, тоесть непосредственно для определенных задач. А в таком контексте все равно на чем программировать.
А в будущем ничего не поменяется. И 10 лет наза люди писали приложения которые работали на сотнях процессоров и ничего, справлялись. Просто серверные стойки будут меньше, шуму будет меньше, отдача температуры будет меньше. В общем к светлобу будущему движемся
Здравствуйте, Аноним, Вы писали:
А>Java давным давно позволяла писать многопоточные приложения, причем без использования сторонних библиотек. И так же давным давно Java использует все ядра, какие найдет в вашем процессоре, причем опять без использования сторонних библиотек и без каких-либо дополнительных настроек.
Ну дык, тогда уж и С++ это умеет. Да и вообще ОС сама масштабирует потоки на ядра. Речь-то ведь изначально совсем о другом шла...
А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Здравствуйте, Nicht, Вы писали:
N>А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.
Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?
Y>>Без поддержки виртуальной машины, это в принципе невозможно.
N>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Здравствуйте, DenysSG, Вы писали: DSG>Это интересно. До боли мне кажется что вы второй раз ошибаетесь. DSG>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты?
Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах.
В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, remark, Вы писали:
R>А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).
а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
R>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.
R>Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.
Здравствуйте, Gaperton, Вы писали:
R>>Я надеюсь, это шутка?
G>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ. Вопрос на подумать — почему, например, параллельная одновременная сборка мусора в .NET/Java реализована на основе разделяемой памяти, а не основе обмена сообщениями.
R>>Очевидные и широко-известные приемущества разделяемой памяти — это (1) скорость работы и (2) низкая латентность.
G>"Очевидное и широко-известное преимущество" не работает на современных суперкомпьютерах, состоящих их сотен или тысяч машин, соединенных сетями InifiniBand или подобными. Там рулит MPI, основанный на модели передачи сообщений.
R>>А таком контексте вопрос по поводу факта наличия преимуществ у разделяемлой памяти меня просто шокирует.
G>Предлагаю перевести мозг в позицию on. И внимательно посмотреть, что я тебе пишу. И свои посты перечитать. Сопоставить. ПОДУМАТЬ.
Называется "научи дурака богу молиться...". Я, конечно, извиняюсь, что я не привёл контекст, просто я думал, что это достаточно очевидно. Контекст — многоядерные/многопроцессорные машины, которые имеют разделяемую память и даже более — разделяемая память — это основная (и скорее всего — единственная) физическая модель взимодействия на них. И даже ещё более — даже машины в кластере внутри себя могут общаться на основе разделяемой памяти, если машины — многоядерные/многопроцессорные. Естественно, если мы говорим о распределенных системах, то тут разделяемая память не релевантна. Так же как не релевантен обмен сообщениями на, например, некоторых микроконтроллере, там даже скорее всего и ран-тайм-то не влезет. Ну и что из этого? Если следовать твоей линии рассуждений, то получается, что обмен сообщениями — это @#$%%^, т.к. он не может применяться на маленьких микроконтроллерах. Конечно, это неправильно. Невозможность применения обмена сообщенями в некоторых ситуациях ничего не говорит о нём как таковом, просто значит — это не его область. Точно так же и с разделяемой памятью — просто не пытайся привинчивать её к распределенным кластерам (я этого не делаю). У неё другая область применения — и там у неё есть преимущества.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, prVovik, Вы писали: V>>Что в свою очередь решается I/O APM S>Ну то есть опять же пул потоков.
Только потоки там халявные, и по сути не потоки вовсе. Это я к тому, что зелёные потоки для этого случая являются скорее средством повышения удобства программирования, чем необходимостью.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>>>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
G>>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
R>Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...
Форумный язык таков, что запятую можно и пропустить, это нормально и на это никто не обращает внимания. К тому же, слово "преимуществ" ты выделил болдом, что играет роль запятой, отделяя его от предыдущих слов акцентом. Можно, можно было так воспринять. Я так и воспринял.
Здравствуйте, Gaperton, Вы писали:
R>>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
G>Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
G>http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf G>We have demonstrated that it is absolutely not obvious G>to get better performance with OpenMP codes compared to G>MPI ones on shared memory machines.
G>А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью.
НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.
Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.
Во-вторых, что бросается в глаза, они тестируют на неких IBM SP3 Night Hawk II и SGI Origin 3800 — если не ошибаюсь, то это всё датировано 2000 годом и ранее. Это машины прошлого поколения, во-вторых, очень специфические. Я ориентируюсь и говорю про машины, которые использует 99% из нас сейчас — либо однопроцессорные многоядерные, либо несколько-процессорные многоядерные. Опять же, если на тех машинах обмен сообщениями оказывается быстрее, то это никак не говорит в пользу того, что у разделяемой памяти не преимуществ вообще (ну точнее говорит, но очень-очень слабо).
Когда прочитаю статью прокомментирую по-сути статьи.
Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?
Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ.
Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, remark, Вы писали: S>>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>Вот другой пример: RRM>Есть некое число s инициализированное нулем. RRM>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
Здравствуйте, RailRoadMan, Вы писали: RRM>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Грамотная реализация очереди будет делать то же самое.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
G>>>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
RRM>>А ничего, что в примере до этого (ктр про s и q) не сильно больше?
G>Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
Практически идеальная ситуация но увы, есть это число и с ним нужно работать именно так как я описал.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
R>>>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>>>Ну, какой тут будет оптимизированный вариант на сообщениях?
RRM>>Именно это и имел в виду
G>Не знаю, что ты имел в виду и какое отношение это имеет к серверу, потому что описал ты отвратительную реализацию генератора случайных чисел.
Когда нечего сказать — переходят на личности (ну или на оценки примеров).
Я описал совершенно надуманный пример максимально оптимальный для разделения памятию. Это в первую очередь пример.
Готов ты именно его решить на передаче сообщений, что бы получилось эффектичнее чем с разделением памяти?
Да — с удовольствием посмотрю.
Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.
G>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?
Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Когда нечего сказать — переходят на личности (ну или на оценки примеров).
G>Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.
Ты то, что в скобочках написано прочитал? Ты перешел на оценки пример, что на мой взгляд так же не конструктивно как и переход на личности только в более вежливой форме.
G>А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
G>>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.
R>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
G>Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
Что-то я только не понял, почему точка, что разделяемая память не имеет преимуществ принята за изначальную и не требующую даказательств. Вообще-то это не доказано. Так что давай так, за изначальную точку принимаем, что разделяемая память лучшая по всем параметрам модель. А дальше применяем твои "правила научных дискуссий".
Отмашка. Начинаем. Пожалуйста, мы все слушаем тебя — теперь ты *должен* даказать, что обмен сообщениями имеет хоть какие-то преимущества перед разделяемой память, а потом, что он лучше во всех ситуациях.
А вот это я вообще не понял твоей @#$ни с вырезанием и игнорированием как раз моих аргументов по существу вопроса в таком контексте, что типа я ничего не доказываю, а ты типа ведёшь "научные дискуссии", и ты опять тычешь своим неревантным примером и говоришь, что я ничего на него не отвечаю, хотя я тебе по поводу него уже отвечал. И как тут не переходить на личности?! Озвучивать я не буду, но мне про тебя уже всё понятно...
Аргументы придётся скопировать ещё раз:
Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: (1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки. (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО. (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
G>Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
Во-первых, я не раз указывал, что твой пример практически не имеет отношения к вопросу. Во-вторых, ну ты рассмешил, ты сам-то смотрел эту статью? Там во множестве случаев OpenMP быстрее причём на обеих машинах. А вот это факт уже имеет отношение к делу и доказывает, что разделяемая память имеет преимущества перед обменом сообщениями.
G>Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
А какое правило-то? Что твоя точка принимается за аксиоматическую, а моя за требующую доказательства? В споре-то 2 точки зрения, нет?
R>>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.
G>Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.
Ну вот реальное доказательство — посмотри статью, которую ты приводил
G>Не удивляйся, в дискуссии вовсе не обязательно у обеих сторон должны быть строго противоположные тезисы. В ней доказательство одного тезиса ни как не связано с тезисом противоположной стороны.
Т.е. ты согласен с моим тезисом? Замечательно, молодец. Прекращаем дискуссию.
G>Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
Ну свою-то статью посмотри. Класс задач — научные вычисления.
Я не ставлю отсылки уведомлений.
R>А теперь и на throttling. R>По названию могу предположить, что это что-то типа того, что определяем агента, который вызывает перегрузку и временно отключаем его, и даёт приоритет перегруженному агенту. Если это так, то это ни фига не решение проблемы. Это не что иное как затычка, которая служит для предотвращения съедания всей памяти и падения системы. Но в то же время она снижает производительность системы. Представь система периодически входит в перегрузку и мы периодически отключаем все процессоры кроме одного, что бы разгрузить агнета.
Нет.
Читайте книги, это прикольно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
G>>Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.
R>Что-то я только не понял, почему точка, что разделяемая память не имеет преимуществ принята за изначальную и не требующую даказательств. Вообще-то это не доказано.
Ты не понял, так я тебе разъясню. За изначальную точку принято то, что не известно, имеет ли разделяемая память преимущества или нет. Тебе понятна разница меджу "имеет", "не имеет" и "не известно"? Когда ты переходишь от "не известно" к "имеет", или "не имеет" — ты выдвигаешь тезис, он требует доказательства, и это доказательство может быть оспорено.
R>Так что давай так, за изначальную точку принимаем, что разделяемая память лучшая по всем параметрам модель. А дальше применяем твои "правила научных дискуссий".
С какой это стати? За начальную точку принимаем, что неизвестно, какая лучшая и покаким параметрам. Я выдвинул тезис, подразумевающий существование недостатков у разделяемой памяти, и заявил, что этих недостатков нет в модели на сообщениях. Ничего кроме этого я не говорил. По этому тезису — готов его попробовать доказать. Ты можешь по всем понятиям придираться к этому тезису и всем его пунктам.
R>Отмашка. Начинаем. Пожалуйста, мы все слушаем тебя — теперь ты *должен* даказать, что обмен сообщениями имеет хоть какие-то преимущества перед разделяемой память, а потом, что он лучше во всех ситуациях.
Извини, без меня начинай. Я доказываю только те тезисы, которые выдвигаю сам. Ты же сейчас с какого то дуба решил, что тезис "что разделяемая память лучшая по всем параметрам модель" не надо доказывать, и просишь меня его опровергнуть, опять грубо нарушая правила благородной научной дискуссии .
R>А вот это я вообще не понял твоей @#$ни...
Ты попал под пункт правил о матюгах, и тебя за эту строку могут забанить на законном основании.
R> с вырезанием и игнорированием как раз моих аргументов по существу вопроса в таком контексте, что типа я ничего не доказываю, а ты типа ведёшь "научные дискуссии", и ты опять тычешь своим неревантным примером и говоришь, что я ничего на него не отвечаю, хотя я тебе по поводу него уже отвечал. И как тут не переходить на личности?! Озвучивать я не буду, но мне про тебя уже всё понятно...
Просто — взять, и не переходить. Или будешь общаться с кем-то еще. Тролль, блин.
R>Аргументы придётся скопировать ещё раз:
Давай посмотрим на твои аргументы.
R>Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: R>(1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки.
Это доказательство рассчитано на пионеров. В случае модели с сообщениями и разделяемой памяти дизайн программы будет до такой степени разным, что прямого соответствия между очередями и примитивами наблюдаться не будет. Сравнивать надо на реальных задачах. Пример — посмотри, насколько различается производительность теста LINPACK на SMP машине для OpenMP и MPI. Фокус в том, что для случая MPI применяется другой, блочный алгоритм умножения, никто на сообщениях разделяемую память не эмулирует — дураки только в твоем воображении существуют. Это — релевантный пример, и если ты этого понять не в состоянии, то разговаривать больше не о чем.
> (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО.
Приведи пример реальной задачи, а не микробенчмарка, где это будет проблемой и просадит мне производительность хотя бы на 2 процента. Это не является проблемой в случае MPI — никто этого эффекта в реальности не наблюдает.
Если бы ты смог привести пример задачи, я бы убрал оттуда микропараллелизм при переходе на модель сообщений, и с высокой вероятностью выиграл по производительности по сравнению с тобой.
> (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
С этим эффектом слишком легко бороться — достаточно притормозить посылателя. Пример системы, где эта проблема решена на уровне шедулера — Erlang. Я уверен, что в MPI она тоже решена.
R>Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.
Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ.
Вот это — факт, хочешь ты того или нет. Объясни результат — почему MPI обходит НА ОДНОЙ МАШИНЕ систему с общей памятью OpenMP. Объясни, как так выходит, что практика не пожтверждает твои теоретические выкладки. Тебе еще исследований подкинуть?
G>>Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.
R>Во-первых, я не раз указывал, что твой пример практически не имеет отношения к вопросу.
А я не понял, почему не имеет. Давай, ты претендуешь, что ты умнее меня, знаешь что-то, чего я не знаю? Валяй, я не против, растолкуй мне подробно, что тут не так. Давай по пунктам проверим:
1) MPI — построена на обмене сообщениями? Да.
2) OpenMP — построена на общей памяти? Да.
3) На одной и то же SMP машине, без всяких кластеров, кто быстрее? MPI в подавляющем большинстве случаев, за редкими исключениями.
Что не так?
> Во-вторых, ну ты рассмешил, ты сам-то смотрел эту статью? Там во множестве случаев OpenMP быстрее причём на обеих машинах. А вот это факт уже имеет отношение к делу и доказывает, что разделяемая память имеет преимущества перед обменом сообщениями.
Да чо ты говоришь. Что ж в этой статье Conclusion-то такой странный тогда, а?
We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines. The `naive' loop
level OpenMP version is simply not competitive compared
to MPI and other OpenMP versions. The `improved' loop
level version which uses less parallel regions provides very
limited performance improvement.
...
However, SPMD programming
style is not enough because 1) the code generation of the
compiler for handling thread private arrays may limit signi
cantly the performance and 2) the performance of shared
memory algorithms for interthread communications may be
lower than the one of MPI.
...
И нашел еще две статьи, ты только не волнуйся — с аналогичным результатом, где OpenMP сосет.
G>>Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.
R>А какое правило-то? Что твоя точка принимается за аксиоматическую, а моя за требующую доказательства? В споре-то 2 точки зрения, нет?
Выше я тебе достаточно доходчиво объяснил.
R>Т.е. ты согласен с моим тезисом? Замечательно, молодец. Прекращаем дискуссию.
Нет конечно, ты вообще ничего связного сказать не можешь в его защиту. По крайней мере пока у тебя очень слабенько получается. Над доказательствами надо работать, поменьше рвать тельняшку на груди, и побольше думать.
G>>Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
R>Ну свою-то статью посмотри. Класс задач — научные вычисления.
Да ну? А тут какой-то тролль давеча с матюгами орал, что этот пример не имеет отношения к делу? Кто ж был этот тролль, а, не напомнишь?
Здравствуйте, Cyberax, Вы писали:
G>>Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ. C>Просто-напросто, модель OpenMP не подходит для многих задач.
C>Что тут такого удивительного, не понимаю?
А я разве удивляюсь? Это вон remark так удивился, что аш в истерике зашелся .
Тише, не спугни его, я хочу посмотреть, у него ума хватит в интернете что-нибудь поискать, или нет.
C>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
Здравствуйте, eao197, Вы писали:
G>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
E>Питон там давно порвали на британский флаг.
C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.
G>>1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.
E>Ага, вычитывает блоки по несколько Mb, а затем высылает их другим процессам/нитям. E>А если не высылает, а передает указатель на преаллоцированный буфер, то что это такое, как не использование разделяемой памяти?
Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.
В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются, управление памятью будет практически аналогично С++. При этом, никакой разделяемой памяти, видимой программисту, в Эрланге нет.
G>>Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.
E>Победитель просто использует boost::thread без очередей сообщений и аллокатора.
Победитель просто использует С++, и оптимизированный ввод-вывод, потому что программа утыкается в диск, а не в CPU.
Здравствуйте, RailRoadMan, Вы писали: RRM>Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все.
Видишь ли в чем дело — атомик функции хорошо работают тогда, когда память реально разделена. Ну там, к примеру, речь идет о нескольких ядрах с общим кэшем.
Как только это предположение перестает выполняться, всё становится очень плохо.
Тот "спец поток", который тебе кажется лишним, лучше описывает ситуацию с NUMA. RRM>Да если это erlang то поток будет очень легким, а если нет? Если у меня системные потоки?
Поясняю: этот "владеющий поток" — всего лишь удобная абстракция. Не нужно трактовать его буквально, как "системный поток". Идея именно в том, что некий фреймворк (например эрланг) предоставляет тебе некий набор абстракций. Ты строишь реализацию из этих абстракций; а затем она автоматически превращается в низкоуровневое решение на конкретной аппаратуре. Если есть возможность — потоки окажутся лёгкими. Если нет — будет поднят системный поток. RRM>Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Тут важно при обсуждении пользоваться одинаковыми уровнями абстракции. А то получается, что под разделяемой памятью понимается InterlockedIncrement, а под сообщениями — PostThreadMessage. В таком варианте разделяемая память почти всегда победит. А если мы говорим об абстракциях, то оптимизировать программу с разделяемой памятью крайне тяжело — в отличие от программы, написанной в терминах посылки сообщений. Дийкстра неспроста придумал гармонично взаимодействующие процессы RRM>
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Понятно, то есть, тебе хочется докопаться.
G>>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
E>Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
Для опровержения тезисов ремарка вполне достаточно одного примера, где "сообщения" показывают лучший результат, а тут их два.
G>>Это не опровержение тезиса?
E>Неа. Утвеждение may be ни в коей мере не может быть опровержением, ни утверждением.
Утверждения may be вполне достаточно для опровержения утверждения, в математике это называется умным словом "контрпример". Что известно всем студентам первого курса, которые не прошляпили высшую математику.
Еще раз, приведу два тезиса:
remark: "разделяемая память" имеет преимущества, которые безвозвратно и необходимо утрачиваются при применении message passing style.
авторы статьи: We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines.
Противоречие налицо. Всего доброго, докапывайся дальше.
Глянул.
G>Вот на это в статье глянь. G>Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
Из шести тестов в четырех(!) быстрее оказывается вариант на OpenMP.
G> Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв.
Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями. После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах (в большинстве которых, как ни странно OpenMP таки выигрывает).
Собственно, неприятное впечатления производят две вещи:
1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей. Например, в текстовом редакторе может быть буфер, разделяемый между нитью отрисовки, проверки орфографии, автосохранения и в этот же буфер будут вноситься изменения по мере реакции на действия пользователя. На разделяемой памяти могут быть реализованы различные таблицы маршрутизации трафика, с большим количеством нитей-читателей и одной/двумя нитями-писателями. И т.д.
2. Результаты тестов в приводимых тобой статьях ты же сам извращаешь. По твоим словам выходит, что в большинстве случаев OpenMP варианты медленее MPI, тогда как быстрые версии OpenMP программ в большинстве тестов быстрее MPI. При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор. И это, во-вторых, поскольку первая статья вообще проводила пример отвратительного качества сгенерированного OpenMP компилятором кода (он был даже медленее последовательного). А во второй статье рассматривается OpenMP компилятор из GCC, которому всего несколько лет отроду и в который не было вложено еще достаточного количества времени и ресурсов по сравнению с теми же реализациями MPI.
G>Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>Да что ты говоришь, дорогой. Прям все совсем-пресовсем не так, да?
E>Да, в первой статье прямо говорится, что хорошо оптимизированная OpenMP программа обгоняет хорошо оптимизированную MPI программу.
В первой статье прямо говорится, что это абсолютно не очевидно, что можно получить лучшую производительность при помощи OpenMP.
G>>Вот на это в статье глянь. G>>Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
E>Из шести тестов в четырех(!) быстрее оказывается вариант на OpenMP.
Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
2%, 7%, 9%, и 69% — тесты с выигрышем OpenMP. Значимый отрыв только в одном тесте. 2% — это вообще не смешно, а что такое 9% — ну вместо минуты займет у тебя расчет 55 секунд. Для вашей пенисометрии это может быть и значимый отрыв, но мне, честно, на такую разницу плевать — что есть она, что нет.
27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
G>> Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв.
E>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
E> После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах...
После чего я напомнил remark-у о том, что тезис доказывает тот, кто его выдвигает, и, для демонстрации того, что его тезис далеко не так очевиден, дал ему сравнение стиля asynchronous message passing и shared memory на одной и той же программе. Авторы статьи прям такой вывод и сделали — "мы продемонстрировали, что нихрена не очевидно преимущество OpenMP".
Что очень сильно не понравилось remark, и он перешел на мат. Ну как же, он же хотел языком почесать да Гапертону поуказывать, что тому следует говорить, а что не следует, а тут вдруг получается что нарисовался какой-то пример с MPI с OpenMP, про которые он никогда не слышал, и у него вдруг вырисовывается отличная перспектива оказаться в дураках.
E> (в большинстве которых, как ни странно OpenMP таки выигрывает).
Как ни странно, вы с remark думаете, что лучше авторов исследования знаете, какие выводы надо из них делать. Ну все прям идиоты кругом полные. Меж тем, из обоих сравнений следует, как и признали авторы обеих статей, что далеко не очевидно, что OpenMP дает преимущество даже на общей памяти.
E>Собственно, неприятное впечатления производят две вещи:
E>1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей.
На сообщениях также можно сделать много разных вещей, и работаеть это будет гораздо быстрее, чем MPI, который налетает на кросс-процессный маралинг работая на SMP. Выбор MPI и OpenMP очевиден, так как по ним накоплена большая практика применения, и есть бенчмарки, позволяющие делать сравнения на одинаковых задачах.
В любом случае, я нахожу эту претензию довольно нелепой. Что тебе неприятно? Перевод разговора с абстрактных рассуждений на конкретику? Валяй, покажи мне другой бенчмарк, который лучше. Тот, что ты показал — ложится на сообщения просто идеально, с ним нет абсолютно никаких проблем. Ну, или объясни, чем эти бенчмарки плохи.
E>2. Результаты тестов в приводимых тобой статьях ты же сам извращаешь.
Кстати, давай ты объяснишь мне, с цитатами, как именно я извращаю результаты тестов, цитируя тесты статей.
E>По твоим словам выходит, что в большинстве случаев OpenMP варианты медленее MPI, тогда как быстрые версии OpenMP программ в большинстве тестов быстрее MPI.
Что в твоей голове выходит по моим словам, я могу только догадываться — там могут самые разные чудеса происходить. По моим словам, и по мнению авторов статей, выходит, что тесты не подтверждают выраженного преимущества OpenMP.
E>При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор.
В OpenMP программист может нашпиговать код "прагмами", что весьма сильно влияет на распараллеливание.
E>И это, во-вторых, поскольку первая статья вообще проводила пример отвратительного качества сгенерированного OpenMP компилятором кода (он был даже медленее последовательного). А во второй статье рассматривается OpenMP компилятор из GCC, которому всего несколько лет отроду и в который не было вложено еще достаточного количества времени и ресурсов по сравнению с теми же реализациями MPI.
Во второй статье примеры MPI и OpenMP компилируется одним и тем же компилятором. Так что они находятся в равных условиях.
G>>Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
E>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?
Здравствуйте, Gaperton, Вы писали:
G>>>Да что ты говоришь, дорогой. Прям все совсем-пресовсем не так, да?
E>>Да, в первой статье прямо говорится, что хорошо оптимизированная OpenMP программа обгоняет хорошо оптимизированную MPI программу.
G>В первой статье прямо говорится, что это абсолютно не очевидно, что можно получить лучшую производительность при помощи OpenMP.
А здесь никто и не утверждал, что OpenMP всегда будет быстрее MPI. Так же как никто и не утверждал, что разделяемая память всегда имеет преимущества над обменом сообщений. Так что бесполезно акцентировать внимание на "не очевидно", это и так понятно.
G>Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".
Быстрее -- это быстрее. Причем в обоих из указаных тобой статьях. То, что для тебя 2% или 9% не делают погоды -- это частности, никак не влияющие на опубликованные в статьях результаты.
G>27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.
Значимый. В двух. Кто-то против этого?
G>Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.
MPI решения не могут нивелировать те 2%, 7% или 9% процентов. Хотят, но не могут. Видимо, из-за того, что у разделяемой памяти нет никаких преимуществ вообще. Ну совсем.
E>>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
G>Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
Сухой остаток из вашей баталии в том, что remark высказал утверждение, что в ряде случаев разделяемая память будет иметь преимущества. Но не доказал этого. Ты высказал контрпримеры, которые по твоему мнению должны показывать обратное. Но приведенные тобой примеры больше согласуются с утверждением remark-а, чем опровергают его. Так что никто из вас не доказал своей правоты.
Что до меня, то я не высказывал согласия ни с remark-ом, ни с тобой. Но в разговор меня заставила вмешаться первая статья, которую ты настойчиво и, с моей точки зрения некорректно, приводил как доказательство своей правоты.
G>Меж тем, из обоих сравнений следует, как и признали авторы обеих статей, что далеко не очевидно, что OpenMP дает преимущество даже на общей памяти.
Еще раз: я не помню, чтобы здесь кто-то утверждал, что это очевидно. Более того, никто кроме тебя не приводил здесь OpenMP как эталонный пример распараллеливания работы на основе общей памяти.
E>>1. Сам перевод разговора о преимуществах/недостатках разделяемой памяти только в плоскость OpenMP и MPI. Тогда как на разделямой памяти можно делать множество разных вещей.
G>Тот, что ты показал — ложится на сообщения просто идеально, с ним нет абсолютно никаких проблем.
Где можно посмотреть на его решение на сообщениях?
G>Ну, или объясни, чем эти бенчмарки плохи.
См. ниже.
G>Кстати, давай ты объяснишь мне, с цитатами, как именно я извращаю результаты тестов, цитируя тесты статей.
См. ниже.
G>Что в твоей голове выходит по моим словам, я могу только догадываться — там могут самые разные чудеса происходить. По моим словам, и по мнению авторов статей, выходит, что тесты не подтверждают выраженного преимущества OpenMP.
Давай не ставить тождества между твоими выводами и мнением авторов статей. Статья первая:
For CG class A, SPMD OpenMP provides a signifcant improvement over both MPI and other OpenMP versions (up to 15% over MPI, and 140% over `naive' OpenMP). For CG class B, MPI and SPMD OpenMP provide similar performance. The gain over `naive' OpenMP remains of about 15%.
For MG, the `optimized' and `improved' loop level versions provide good results (more than 30% better than MPI) for class A. For class B the `improved' version is less effcient than the `optimized' one. The SPMD OpenMP code is competitive with the others OpenMP versions for both classes.
For FT, the `optimized' version outperforms the others including MPI. The improvement comes from a performance tuning of the code based on array shape modification. SPMD OpenMP provides a at 15% improvement over MPI for class A and a non-uniform advantage (up to 25%) over MPI for class B. `Naive' and `improved' versions show a decreasing effciency for class A and reach MPI performance for class B.
For LU, SPMD OpenMP provides only a little advantage (about 15%) over MPI for class B. The other OpenMP implementations show a high negative slope meaning that they do not scale.
И затем в заключении авторы говорят, что хотя не очевидно, что OpenMP может дать преимущества, они все таки эти преимущества получили:
The performance analysis (hardware performance counters and breakdown of the execution time) of our OpenMP SPMD version of the NAS benchmark demonstrates that we succeed in getting the same performance as the MPI version for the computing loops and better performance than the
MPI version for the communication part.
Вторая статья:
If you want your application to be portable on clusters and SMP machines, MPI might be the
best solution. If, however, you do not envision using more than eight or sixteen cores, then
OpenMP is probably one of your best choices if the benchmarks point in that direction. From a
conceptual standpoint, those with experience in both paradigms state that using OpenMP and
MPI provide a similar learning curve and nuance level. There are no shortcuts or free lunches
with OpenMP, or MPI for that matter.
Так что обе статьи говорят вполне ожидаемые вещи: получение преимуществ с помощью OpenMP вовсе не гарантировано (не очевидно, если тебе так больше нравится), но временами OpenMP будет наилучшим выбором.
Что полностью соответствует утверждению remark-а о том, что разделяемая память будет иметь преимущества в некоторых случаях.
Соответственно, если такие случаи есть (а они есть, судя по результатам измерений), то в этих случаях механизм обмена сообщениями лишается преимуществ, которые имеет разделяемая память. О чем опять-таки remark и говорил, как о более честном, с его точки зрения, освящении достоинств обмена сообщениями.
E>>При этом сами эти тесты вызывают сомнения как аргументы в разговоре о достоинствах/недостатках разделяемой памяти. Во-первых, за распаралелливание в MPI полностью отвечает программист, тогда как в OpenMP кроме программиста на качества распаралелливания влияет еще и OpenMP компилятор.
G>В OpenMP программист может нашпиговать код "прагмами", что весьма сильно влияет на распараллеливание.
Так ведь я и сказал "кроме программиста". Программист ставит прагмы, а что из них получится -- это уж как разработчик OpenMP компилятора постарался. И, как видно из тех же статей, не всегда старался.
G>Во второй статье примеры MPI и OpenMP компилируется одним и тем же компилятором. Так что они находятся в равных условиях.
То, что это один компилятор ничего не решает. Решает качество OpenMP компилятора. Как тебе указал твой соратник, Сергей Зефиров, качество gcc не сильно выше плинтуса.
E>>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.
G>А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
У меня нет классического образования, зато воспитание хорошее.
G>Ты на личности переходить прекратишь?
В данной теме у меня еще не было случая перейти на личности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
E>>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.
G>Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.
E>> После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах...
....ПОСКИПАНО.....
E>>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством. G>А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой. G>Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?
Коллеги, давайте лучше про OpenMP и MPI!
Re[35]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Ссылку на корень можно подменить даже не рассылая ее worker-ам.
Это заблуждение.
Точнее, так можно сделать, но только в том случае, если эта ссылка наблюдаема из разных потоков.
Но тогда в них придется вставлять примитивы блокировки для обеспечения изоляции. На первый взгляд кажется, что можно обойтись атомарностью неблокирующего чтения, но это только в том случае, если транзакция маршрутизации требует только однократного прохода по дереву. В противном случае каждому worker придется перед началом каждой транзакции выполнять копирование ссылки на корень, что опять же дорого. Это эквивалентно постоянной рассылке сообщения "корень дерева теперь здесь".
Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Ссылку на корень можно подменить даже не рассылая ее worker-ам. S>Это заблуждение.
Конечно
S>Точнее, так можно сделать, но только в том случае, если эта ссылка наблюдаема из разных потоков.
Именно. Разные потоки видят одно и то же дерево.
S>В противном случае каждому worker придется перед началом каждой транзакции выполнять копирование ссылки на корень, что опять же дорого. Это эквивалентно постоянной рассылке сообщения "корень дерева теперь здесь".
Т.е. ты утверждаешь, что один atomic_read будет эквивалентен мультикастовой рассылке сообщения? С выбором получателей, блокировкой очередей, вставкой в N очередей экземпляра сообщения, разблокированием очередей, блокированием очередей на стороне приемника, сканирования очереди на предмет выбора подходящего сообщения (если используется отличная от FIFO политика обработки сообщений получателем). Правильно я тебя понимаю?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, DK3981, Вы писали:
DK>>>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
E>>Этот протокол нужен в любом случае.
DK>Если модифицирующий поток один, то ему не с кем будет конкурировать.
Я о другом: если есть несколько потоков-модификаторов, то им потребуется взаимный протокол захвата разделяемых данных для их модификации в любом из случаев -- будет ли доступ к общей таблице осуществляться через разделяемые переменные или через уведомления.
Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений.
Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы.
Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица". E>Мог бы ты свою точку зрения раскрыть?
Я уже пояснил: ты сравниваешь один atomic_read с broadcast-ом. А нужно сравнивать 100 atomic_read с 99 local read и 1-м message_receive. Так понятнее?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений. S>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы. S>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".
Это автоматически обязывает worker-а работать с очередями сообщений. Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри.
E>>Мог бы ты свою точку зрения раскрыть? S>Я уже пояснил: ты сравниваешь один atomic_read с broadcast-ом. А нужно сравнивать 100 atomic_read с 99 local read и 1-м message_receive. Так понятнее?
Да, теперь я понял к чему именно относились твои слова "Не совсем."
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[43]: пример eao197: "сообщения" рвут "разделяемую память"
S>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше. S>>Никаких проблем. E>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.
Поддержи очередь аппаратно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений. S>>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы. S>>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".
E>Это автоматически обязывает worker-а работать с очередями сообщений. Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри.
1. Никаких проблем обрабатывать большие пакеты данных со множеством сообщений внутри, в рамках модели "гармонично взаимодействующих процессов", нет. Просто посылаешь большой пакет. Который вовсе не обязан копироваться, и будет передан по ссылке — никто его модифицировать не будет.
2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.
Ты вообще живой раутер в глаза видел, или как? Давай, поучи эрлангистов делать раутеры.
Да здравствует всемирная пионерская организация! .
Re[37]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, DK3981, Вы писали:
DK>Здравствуйте, Sinclair, Вы писали:
S>>Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.
DK>Я здесь вижу только одну проблему: если у нас есть 2 потока, модифицирующих дерево, и оба они "одновременно" получат сообщение, приводящее к необходимости это дерево модифицировать. Тогда каждый из них построит своё новое дерево, и после этого разошлёт новый корень, но в результате данные, изменённые одним из потоков будут потеряны.
DK>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
Модифицирующий поток должен быть один. Что в данной задаче, очевидно, не является никакой проблемой. Если какой другой поток вдруг с какого-то дуба хочет поправить таблицу — он шлет сообщение главному. И все.
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.
Есть такие услуги у ряда контент-провайдеров -- массовые рассылки sms по результатам какого-то события, как-то начисление зарплаты, результаты футбольных матчей, объявление курсов валют, прогнозы погоды и т.д. При их организации решаются задачи быстрой обработки большого числа sms (от нескольких сотен тысяч штук до нескольких миллионов).
Достаточно? Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
T>Сейчас у тебя это не так, чем ты и пользуешься.
Да ничем он не пользуется, он вообще слабо себе представляет, что говорит. Ты-то хоть на глупость не ведись. Очередь почти ничем не по затратам не отличается от обычного вызова synchronized метода. Более того, она на практике гораздо гуманнее, поскольку асинхронна, и не требует "рандеву" приемника и получателя.
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.
Классическое образование, надо полагать, заставляет думать, что доступ к разделяемым данным можно сделать только на семафорах. Ничего не поделать, у классического образования так же есть недостатки.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.
E>В разговоре с Siclair я несколько раз упоминал использование atomic_read. И он понял о чем я говорю, поскольку идея очень простая.
Sinclair не просто понял, о чем ты говоришь (это дело нехитрое), он, если ты не заметил, еще и объяснил тебе, почему ты неправ со своим atomic_read.
Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
Здравствуйте, Gaperton, Вы писали:
EC>>А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?
G>Почему нельзя? Можно. Получишь в точности очередь сообщений, а именно — ее предельный случай с глубиной 1 и полиси вытеснения при переполнении по FIFO — что станет совершенно очевидно даже тем, кто в танке, если завернуть то что получится в класс, и посмотреть на функциональный интерфейс.
Можно и о скаляре думать как об одномерном массиве с одним элементом, вопрос в том когда такой взгляд на вещи полезен. G>Потом можно пойти еще дальше, упереться, и под разными предлогами не называть это очередью сообщений.
Я ниразу не против называть это очередью.
Я спрашивал не в разрезе вашего увлекательного спора message passing vs shared memory,
а исключительно в контексте конкретного решения с иммутабельным деревом. G>Видишь ли, asynchronous message passing — это не более чем дизайн-идиома, которая в конечном счете на современных архитектурах все равно превратится в те примитивы, через которые реализуются семафоры все остальное. Так же, как программа на функциональном языке в конечном счете превратится в ассемблерные инструкции.
Мне кажется важным различать то, в каких терминах мы можем думать о решении и то, как оно реализуется.
G>Если использовать это как аргумент, все закончится Теоремой Существования Дворкина (http://rsdn.ru/forum/message/3194838.1.aspx
), на которую любят опираться люди, которым с пеной у рта нечего сказать. Ну так что на таких время тратить — только портить.
Что вы так Дворкина любите пинать? Я с ним во многих случаях тоже не согласен, это же не повот его пинать по любому поводу.
Здравствуйте, kdw, Вы писали:
kdw>Достал ты уже со своим ерлангом,
Так не читай мои посты. Кто-то заставляет?
kdw>Как абстракции на нем писать предлагаешь , можно конешно через жопу (и на асемблере можно), Но в данном kdw>случае например предпочитаю нормальные обьектно ориентированные языки.
С чего ты взял, что я тебе что-то предлагаю.
kdw>Я смотрел на синтаксис ерланга и чесно говоря он него тошнит , хотя в некоторых случаях думаю имеет смысл
заюзать.
Меня совершенно не трогают твои предпочтения, предположения, душевные терзания, и от чего именно тебя тошнит.
Здравствуйте, Gaperton, Вы писали:
G>Более интересный пример, демонстрирующий силу фьючерсов. Допустим, мы хотим рассчитать массив из десяти значений. Каждое — параллельно. Мы просто заполняем этот массив в цикле фьючерсами, каждый из которых — RPC-вызов к какому-то потоку (или старт отдельного потока, выполняющего рассчет, возможно — асинхронный старт, по мере доступности потоков в пуле). И все. Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.
что характерно, все эти, действительно полезные вещи, скажем, в java доступны на уровне стандартной библиотеки, начиная с версии 5. т.е. я хочу сказать, что это не какое-то вчерашнее открытие, раз есть давно и в таком популярном языке
что касается их применения, то мне доводилось использовать Future в реализациях протоколов уровня приложения с возможностью ожидания подтверждения от контрагента для более, чем одного посланного пакета (windowing > 1)
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
E>>Может быть тогда ты сможешь сказать, у какой именно очереди сообщений накладные расходы на проверку наличия нового элемента будут меньше одного atomic_read?
G>Может быть, я тебе это уже сказал во второй части своего сообщения, которую ты предусмотрительно вырезал? Может быть, Синклер тебе все то же самое объяснил?
Не может быть.
G>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
Одного обычного read будет недостаточно, о чем уже было сказано.
G>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
Этот красочный оборот речи был предназначен для сокрытия факта того, что нити-читатели должны проверять свою очередь сообщений перед каждой новой транзакцией, и что эта проверка не может быть дешевле одного atomic_read-а.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
E>>Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.
G>Это как раз очень важно, потому что работая через "разделяемую переменную" ты налетаешь на примитив синхронизации на каждом чтении. И на синхронное взаимодействие, требующее "рандеву" — все должны ждать, когда ты ее изменишь
"Примитив синхронизации и рандеву" в языках платформы CLI (C#) и Java представляет из себя копирование объектной ссылки, что является не более чем обычной инструкцией загрузки указателя (доли такта) на всех современных аппаратных платформах.
Именно таким образом в этих языках и реализовывалось бы распространение неизменяемого объекта: изменяющий поток совершает подмену объектной ссылки на новый объект (одна обычная запись в память), читающие потоки совершают считывание текущей объектной ссылки (одно обычное чтение из памяти). Это в противопоставление обмену сообщениями, где придётся рассылать N сообщений, принимать N сообщений, и ещё ряд неприятных факторов (типа работы не обязательно с текущей версией объекта, жадного обновления объект в отличие от ленивого и др.).
G>Чтобы добиться таких же характеристик, как с решением на актерах, не изображая при этом актеров, тебе придется через задний проход реализовать их на семафорной модели, проиграв в сложности, и не выиграв ничего в производительности. Так как ты не владеешь дизайн-идиомой актеров, то ты во многих случаях просто не додумаешься до такого решения, как привел я.
Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. Евгений разработал несколько версий собственной библиотеки для агентно/актёрно-ориентированного программирования (SObjectizer), и работал с этим подходом ещё в 1994 году. Скорее всего это не всё, это так сказать "по материалам открытой печати". И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
Я, хочешь ты этого или нет, тоже разработал 2 библиотеки для актёрно-ориентированного программирования, и вплотную работаю с такими вещами как использование иммутабельных структур в многопоточном окружении (а также значительно более общим и гибким подходом — partial copy-on-write; STM; примитивы синхронизации; современные модели для параллельного программирования и др.).
Твои же технические знания и опыт пока под большим сомнением. Очевидно, не представляешь что такое атомарное чтение (http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, remark, Вы писали:
R>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.
R> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал... R>Твои же технические знания и опыт пока под большим сомнением.
Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.
я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".
"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.
ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.
Re[43]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
R>>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
G>Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
G>Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.
Хммм... неплохой приём — вот так в последний момент переменить своё точку зрения, и накатать такое "высокое" оправдание, что бы типа очистить свою совесть. Неплохо!
Личности тебе значит по-барабану? И тебя волнует только конкретная дискуссия? Если немного пройтись по твоим сообщениям в этом топике:
Говоришь собеседнику, что ему придётся реализовывать что-то через "задний проход"; абсолютно необоснованно говоришь, что собеседник не владеет "дизайн-идиомой актёров"; говоришь, что собеседник не додумается до таких решений как ты: http://www.rsdn.ru/forum/message/3213290.aspx
сказал собеседнику: "ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы": http://www.rsdn.ru/forum/message/3197730.1.aspx
Будь добр, поясни как это всё согласуется с твоей позицией, что тебя интересует только дискуссия, а на личность собеседника ты типа не обращаешь внимания? По-моему, практически каждый твой пост пропитан неуважением к собеседнику, личными оскорблениями и чувством собственного превосходства. При этом, кстати, техническая сторона страдает. Говоришь людям приводить аргументы и ссылки, сам же никаких ссылок не приводишь, и отвечаешь "Сам поищи. Лень".
Где, кстати, на вранье меня поймали?
Самое забавное, что ты так и не понял моё первоначальное высказывание. Как при этом вообще спорил и шашкой махал — совершенно не понятно...
R>> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал... R>>Твои же технические знания и опыт пока под большим сомнением.
G>Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.
G>Видишь-ли, меня интересует мнение о моей персоне тех людей, кого я уважаю.
Это я заметил, что тебя интересуют только те, кого ты уважаешь. А на тех кого, ты не уважаешь тебе плевать. При этом, где истина и объективность тебя совершенно не волнует.
G>я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".
G>"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.
Это я тоже заметил, что ты на ум не претендуешь. Нет, определенный звон (МЕМОРИ БАРЬЕР, lwsync и т.д) ты видимо слышал. Но вот где он совершенно не представляешь.
Смотри ответ: http://www.rsdn.ru/Forum/message/3214044.aspx
Но при этом шанса по-оскорблять собеседника ты не упустил: "Абыдно, да?", "На, почитай первоисточник", "И здесь ты неправ".
G>ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.
А ты прям ангел такой. У тебя типа в каждом втором посте не встречаются плохо замаскированные оскорбления, неуважительные высказывания и указания на собственное превосходство.
Да ещё вот эта тема непонятная — дофантазирование технических деталей. Откуда на POWER lwsync в load-consume? Откуда в паттерне публикации на стороне потребителя store-load последовательность? Как барьеры памяти влияют на когерентность? Откуда ты эти факты взял? У меня 2 варианта: (1) либо действительно любишь фантазировать (такое можно понять на уроке литературы, но в техническом форуме ), (2) либо очень хитро врёшь/выставляешь реальные факты лживо в надежде типа "а вдруг прокатит", со стороны неискушенного читатели выглядит типа авторитетно.
Или просто прочитал где-то такие некорректные факты? Будь добр укажи, где такое пишут.
Здравствуйте, remark, Вы писали:
G>>2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
R>Ну и чем ты можешь это аргументировать?
Ниже пример почитай.
R>>>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
G>>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
R>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
В сторону уводишь ты, ты вообще по хожу не держишь контекста дискуссии. Не буду считать, что это "вообще на асме", поскольку сравнивается очередь и разделяемая мутабельная память в контексте задачи. И работа компилятора здесь важна.
G>>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>>
G>>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>>different location.
G>>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
R>Я поражаюсь, как тебе получается такую ахинею оборачивать в благовидный облик.
Язык попридержи. Достал. Я дал тебе человеческое объяснение, и ссылку на документ. Мозгов не хватает понять, что я имею в виду, или как? У меня нет никакого желания тебе что-то втолковывать помимо твоей воли — считай как хочешь. Можешь мнить мебя мегаэкспертом в параллелизме — я не против.
R>Нет, не Абыдно. Где ты в паттерне публикации увидел store-load последовательность, которую надо упорядочивать? Поток потребителя её исполняет? Ну и что же он сохраняет и куда?
Я рассматриваю решение задачи в целом, а не бессвязные отдельные фрагменты, которые ты хочешь мне навязать, лишив разговор смысла. В целом же ты вроде как собираешься передавать потребителю новый указатель на корень новой структуры, при том, что ты только что модифицировал этот корень в источнике. В данном случае, чтобы переупорядочивание записи в память не испортило тебе все, ты должен выставить memory barrier, поскольку сам разделяемый указатель, и то, на что он указывает, должно меняться скоординировано, а таких гарантий тебе ни интеловская, ни (тем более) power-овская memory model сами по себе не дают.
Поэтому, "по причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync". Потому, что именно lwsync наиболее дешевым образом в POWER дает тебе локальный TSO, на который ты так рассчитываешь, говоря про atomic_read в данной задаче.
Я достаточно доступно объясняю тебе про архитектуру POWER? Или ты опять дурачка включишь? Ты странно себя ведешь, вроде слова правильные знаешь, однако как до дела доходит, то включаешь феерического дурака. Либо ты это бросаешь, либо я прекращаю с тобой говорить. Надоело.
Здравствуйте, Gaperton, Вы писали:
G>Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке.
Ничего подобного. Писатель создает новую копию структуры, а затем подменяет ссылку на нее в глобальной переменной одной атомарной операцией (перед которой писатель выполняет все необходимые fences).
G>Касательно того, что atomic_read, на котором eao
eao197, eao -- это такое же некорректное сокращение, как и Gaper.
G>собирался решать эту задачу, медленнее обычного — это правда и остается правдой, в данном случае нужен честный барьер в получателе чтобы все работало.
Зачем барьер в получателе?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[52]: пример eao197: "сообщения" рвут "разделяемую память"
R>>>>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
G>>>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
R>>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
G>В сторону уводишь ты, ты вообще по хожу не держишь контекста дискуссии. Не буду считать, что это "вообще на асме", поскольку сравнивается очередь и разделяемая мутабельная память в контексте задачи. И работа компилятора здесь важна.
Ну, ладно, как хочешь — в исходном коде на С там стоит volatile. Ну и в чём тут твоя мысль? Что ты хочешь этим сказать? Кроме того, что создаёшь у неискушённых читателей впечатление, что ты типа тоже что-то умное отвечаешь с какими-то терминами?
G>>>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>>>
G>>>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>>>different location.
G>>>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
R>>Я поражаюсь, как тебе получается такую ахинею оборачивать в благовидный облик.
G>Язык попридержи. Достал. Я дал тебе человеческое объяснение, и ссылку на документ. Мозгов не хватает понять, что я имею в виду, или как? У меня нет никакого желания тебе что-то втолковывать помимо твоей воли — считай как хочешь. Можешь мнить мебя мегаэкспертом в параллелизме — я не против.
Ну докажи, что это не ахинея. В ссылке надо документ ничего нет про то, где в паттерне публикации store-load последовательность на стороне читателя.
R>>Нет, не Абыдно. Где ты в паттерне публикации увидел store-load последовательность, которую надо упорядочивать? Поток потребителя её исполняет? Ну и что же он сохраняет и куда?
G>Я рассматриваю решение задачи в целом, а не бессвязные отдельные фрагменты, которые ты хочешь мне навязать, лишив разговор смысла. В целом же ты вроде как собираешься передавать потребителю новый указатель на корень новой структуры, при том, что ты только что модифицировал этот корень в источнике. В данном случае, чтобы переупорядочивание записи в память не испортило тебе все, ты должен выставить memory barrier, поскольку сам разделяемый указатель, и то, на что он указывает, должно меняться скоординировано, а таких гарантий тебе ни интеловская, ни (тем более) power-овская memory model сами по себе не дают.
Аааа! Я понял твою линию — теперь ты хочешь незаметно перейти со стороны потребителя на сторону производителя. Да, где производитель делает сохранение в объект и потом сохранения указателя на объект действительно будет барьер памяти (кстати, не на x86 — тут ты вообще в пролёте). С этим никто не спорит, поэтому переходим дальше.
Покажи на стороне потребителя (который делает только чтения, при этом data-dependent чтения) имеется store-load последовательность.
G>Поэтому, "по причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync". Потому, что именно lwsync наиболее дешевым образом в POWER дает тебе локальный TSO, на который ты так рассчитываешь, говоря про atomic_read в данной задаче.
Где записи-то на стороне потребителя?
"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
G>Я достаточно доступно объясняю тебе про архитектуру POWER? Или ты опять дурачка включишь? Ты странно себя ведешь, вроде слова правильные знаешь, однако как до дела доходит, то включаешь феерического дурака. Либо ты это бросаешь, либо я прекращаю с тобой говорить. Надоело.
Ну хорошо, повторил свои слова ещё раз. Ничего плохого в этом нет, но это и совершенно не обязательно. Давай же перейдём дальше. Конкретный вопрос: на стороне потребителя не достаточно load-consume (data-dependent load)? или load-consume на POWER содержит барьер памяти?
Не надо опять уводить в какую-то прострацию, называть какие-то общие слова типа TSO.
Здравствуйте, Gaperton, Вы писали:
G>После чего, я бы предложил посмотреть, как масштабируется производительность в финальной задаче от количества аппаратных потоков и кристаллов в SMP, и, по всей видимости, довольно убедительно уложил бы их на Нехалеме и Ниагаре. За счет того, что у меня никто никого не блокирует, и все взаимодействие асинхронно.
А потом кто-нибудь додумался бы до того, чтобы читать из разделяемого мутабельного массива, используемого в качестве индекса, атомарними ридами, и писать туда атомарными райтами с мемори барьером. Типо тогда что-то напоминающее транзакционную память получится.
Вот это решение уже побить иммутабельными структурами будет достаточно тяжело, и оно, в принципе, кроссплатформенно.
Однако, достаточно взглянуть на данное решение под другим углом, и мы увидим массив мультикастных однослотовых мэйлбоксов а-ля фьючерс (но не совсем фьючерс — это именно однослотовая мультикаст-группа), и дело опять принимает чрезвычайно интересный оборот. Интересность оборота состоит в том, что это опять один из вариантов нашего дизайна, на сообщениях. Иллюстрирующая еще один прием, как можно креативно обращаться с очередьми сообщений.
Мультикастная очередь не обязана иметь один слот, кстати. Если построить ее на однонаправленном списке, то это может быть вполне честная очередь. Позволяющая множеству читателей спокойно из нее читать, не пользуясь блокировками, потому что она также транзакционна. Делается она так.
В очереди всегда лежит, пнимаете-ли, как минимум один элемент, даже в пустой. Этот элемент — по сути своей фьючер. Однако, когда песатель кладет в очередь новый элемент, он будет указывать на фьючер. Короче, эта фигня ведет себя точь в точь как ленивый список. Без сборки мусора будет тяжело, это дизайн для Java/.NET.
Вот. Теперь, очередной парадокс. Иммутабельная структура данных, состоящая из таких очередей, также функционально чиста и транзакционна, однако. И позволяет делать довольно необычные вещи, несколько уже выходящие за рамки обычных представлений о дизайне на асинхронных сообщениях. Причина крышесрывания состоит в том, что очередь сообщений здесь рассматривается как first class object, которая сама может быть составным элементом структур данных. Занятно, не так ли? Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
Re[71]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Понятно, просто я в C++ных примерах использования future никогда не видел continueWith.
Интересно, ты вообще мое исходное сообщение читал? Я ведь именно об этом и писал.
AVK>>Неа, RPC тут совсем никаким боком. Это совершенно обычный фьючерс.
E>Аналогия с RPC тут в том смысле, что запуск SetParams(...) и WriteData(...) будет произведен только после получения сигнала об окончании (по каким-либо принчинам) работы ResetDevice().
Оченно странная аналогия, надо сказать.
E>А каким боком Cilk к модели обмена сообщениями относится?
Это пример одной из методик балансинга — work stealing. Ее же можно для агентов применять, если мы агентов используем для распараллеливания вычислений. Ты ведь еще исходную тему топика, надеюсь, не забыл?
AVK>>А почему она может не позволять?
E>Например, по соображениям безопасности (один из узлов находится внутри банка, а второй -- снаружи) или скорости работы.
Лишь бы чего возразить
Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев. Все равно это будет намного легче распараллеливаемым, и в итоге более эффективным, чем жестко заданный ФИФО.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Gaperton, Вы писали:
G>на Itanium volatile не просто отключает регистровые оптимизации, но и добавляет барьер. Поэтому доступ к volatile-переменной на Itanium очень дорогой. Почитай здесь
G>http://software.intel.com/en-us/blogs/2007/11/30/volatile-almost-useless-for-multi-threaded-programming/
G>Кстати, твой мегабыстрый мутекс, который ты привел тут рядом, будет тормозить на Itanium (там обращения к volatile компилятся с барьерами), и не будет работать на Power (там требуется явный барьер).
Перегрузил значение volatile и сделал его примитивом синхронизации только один компилятор — MSVC. В общем случае volatile в С/С++ никаких барьеров ни на какой платформе не добавляет.
Во-вторых, а зачем ты тут собираешься использовать volatile, который вставляет барьер, если барьер тебе тут не нужен? Есть другие способы добиться требуемого результата.
G>В третьих, прекрати кривляться, валять дурака, и убеждать меня в том, что ты тупой. Ты можешь в этом и преуспеть.
Извини, меня не интересует твоё мнение обо мне
G>>>Язык попридержи. Достал. Я дал тебе человеческое объяснение, и ссылку на документ. Мозгов не хватает понять, что я имею в виду, или как? У меня нет никакого желания тебе что-то втолковывать помимо твоей воли — считай как хочешь. Можешь мнить мебя мегаэкспертом в параллелизме — я не против.
R>>Ну докажи, что это не ахинея. В ссылке надо документ ничего нет про то, где в паттерне публикации store-load последовательность на стороне читателя.
G>Я тебе уже дал объяснение. Его достаточно. Мозгов не хватает понять, зачем здесь нужен lwsync, зато хватает ума кривляться — извини.
Слабенько-слабенько. Уже наверное даже все читающие этот топик поняли, что ты тут на самом деле ничего не понимаешь. Уже пятый раз пытаешься так слабенько увиливать от совсем простых вопросов...
Не увиливаешь? Ну тогда ответь на них.
R>>"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
G>Да ладно, можешь уже прекратить истерику.
Мне наоборот забавно.
G>Собственно, и ты и eao, прекрасно знаете, что спор по существу вопроса вы проиграли. Твои дурацкие цепляния к деталям сейчас уже ничего не изменят — ты говорил, что сообщения на два порядка медленнее в любом случае, я тебе привел два исследования, и показал, как надо написать на сообщениях программу еао, чтобы она была быстрее, чем то что он в состоянии придумать с разделяемой памятью.
Единственная кривизна в твоём решении, которую надо исправить — это заменить бессмысленную массовую рассылку сообщений об обновлении на одно изменение разделяемого указателя. Очевидно, полученное будет быстрее (только не говори, что atomic_read медленный, или что atomic_read — это запись в память, которую надо упорядочивать ).
Если ты применишь свою так называемую single-element queue с неразрушающим чтением, то тогда ты сможешь догнать решение на разделяемой памяти.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Тут уже тема несколько десятков раз сменилась.
AVK>Ну вот такой я, всегда стремлюсь тему не сменять. Так оно понятнее и не приводит к бесконечным и бесполезным флеймам обо всем.
Ну это если ты с изначальной темой пришёл в разговор на изначальную тему. А если ты с изначальной темой пришёл в уже совсем другой разговор, то понятнее от этого отнюдь не стало.
R>>Какие навороты там не нужны?
AVK>Хитрые модели вроде TPL.
Никто и не говорит, что они там нужны.
R>>А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель.
AVK>Они хорошо ложаться на любую модель. Поэтому чем она проще, тем лучше. Модель AsyncOperation всего с 2 значимыми методами намного проще агентов.
Здравствуйте, remark, Вы писали:
R>Ну хорошо, если это "презерватив на глобус" и типа теперь под это всё подпадает, то тогда приведи ещё пару моделей, которые получаются из тасков и датафлоу путём переименования понятий один-к-одному
Путем переименования понятий можно сделать что угодно и этой казуистикой заниматься лично у меня нет никакого интереса.
R>Ну а по-существу?
А по существу не получится. Заниматься же разбором очередных переименований, натягиваний и аналогий мне не интересно, уж извини.
R>Чёткий датафлоу граф вырисовывается.
Угу. Получается, любая программа, которая обрабатывает данные в несколько этапов с зависимостью между этапами — это датафлоу. О чем я и говорил. Ну ОК, обозвал ты это все датафлоу, не хочу даже спорить о терминах. Дальше то что? Сколько воду в ступе не меси, все одно вода получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
LV>Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
Конечно есть, я как раз о параллельных вычислениях написал.
Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Что-то я сомневаюсь что ресурсоемкая java программа с shared memory без модификации будет испльзовать все 64 ядра, если они действительно ей нужны будут.
Нужно использовать внешние библиотеки. В этом и проблема джавы.
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, DenysSG, Вы писали:
DSG>>Все мы знаем что в "параллельном мире" существуют 2 основные концепции: DSG>>- Shared memory DSG>>- Message Passing Interface (MPI)
Y>Есть еще STM (Software transactional memory) и использование полностью immutable data types.
N>Так это же Compare And Swap. В java вполне себе присутствует. С учетом, опять же, собсвенных пространств памяти у потоков, java не сильно отличается от erlang. N>Надеюсь в erlang так же аллегорично описывается атомарность изменения нескольких значений и поддержка данных up to date в нескольких "мозгах".
Java и Erlang используют разные модели. Java — Shared Memory, Erlang — MPI.
Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков. Вообще подход написания другой.
В Java этого нету. В JVM поддержка multicore есть. В Java нужно писать explicit code используя сторонние библиотеки.
А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Прикол в том что в Erlang не нужно писать код для распаралеливания.
Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.
Все что нужно сделать — придерживатся маленьких рекоммендаций.
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, Nicht, Вы писали:
N>>Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. Но в данном контексте, yumi прав, т.к. то что имеет ввиду Nicht не является решением проблемы.
Здравствуйте, yumi, Вы писали:
Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.
Наверное это для тебя новость но у потоков в джава есть свой личный кусок памяти. И он рабобтает в основном в нем. Ты никогда не задумывался зачем нужны volatile переменный и Atomic классы. Как раз для того что бы потоки обменивались изменениями в своих локальных пространствах памяти.
Еще раз спрашиваю, как на счет атомарности изменений и синхронизации данных. Пока апологеты erlang говорили только о том, что потоки обмениваются сообщениями. Это самая простая многопоточная программа. Как на счет того что несколько сообщения должны быть переданы атомарно и изменения должны быть видны во всех потоках? Если там так все без дедлоков, в чем я лично сомневаюсь, как на счет лайвлоков.
И тут говорили что в erlang ненадо писать код синхронизации. Тоесть надо предпологать что он рассылает эти ваши мессаги на каждый чих? Даже моего скромного ума хватит что бы понять, что такой подход сомнителен.
Y>Боюсь Вы совсем не понимаете, что такое Эрланг.
А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.
N>>Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам N>>И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Y>Без поддержки виртуальной машины, это в принципе невозможно.
Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Здравствуйте, abch-98-ru, Вы писали:
Y>>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
A9R>см. 4.2 там же и про race condition (поиском)
У меня щас тупо нету смотрелки pdf, связано ли это с shared memory? Ну конечно нет, т.к. в Эрланге нет shared memory Это как уж если приводить аналогии, то типа в средах с управляемой кучей не может быть утечек памяти, но все равно можно держать ссылки на коллекцию уже не нужных объектов
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Y>Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?
Да ты не обижайся. Я же не говорю что erlang плохой. Мне просто кажется что шапашного знакомства недостаточно для того что бы об этом рассуждать. И я высказывал лично сове мнение. Как в общем то и просил создатель темы.
Но, можно сказать что вы меня заинтересовали. Как раз хотел поразбираться с функциональными языками. Вот и почитаю.
Вот кстати на злобу дня Интервью с Армстронгом.
Y>>>Без поддержки виртуальной машины, это в принципе невозможно.
N>>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Y>Erlang avalanche
опять двадцать пять
Y>>>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
A9R>>см. 4.2 там же и про race condition (поиском)
Y>У меня щас тупо нету смотрелки pdf,
не катит. любой текстовый вьювер (да хоть less) проблему решит. Открываешь и ищешь 4.2. Поиском внутри файла учить пользоваться ?
Y>связано ли это с shared memory? Ну конечно нет, т.к. в Эрланге нет shared memory Это как уж если приводить аналогии, то типа в средах с управляемой кучей не может быть утечек памяти, но все равно можно держать ссылки на коллекцию уже не нужных объектов
Здравствуйте, yumi, Вы писали:
А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Y>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
Здравствуйте, DenysSG, Вы писали:
А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
DSG>Прикол в том что в Erlang не нужно писать код для распаралеливания. DSG>Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.
out of box получится что? Загрузить на 100% все 100 ядер/машин? Или добиться 100 кратного ускорения работы?
DSG>Все что нужно сделать — придерживатся маленьких рекоммендаций.
А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).
Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели.
Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Здравствуйте, DenysSG, Вы писали:
DSG>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.
А где можно прочитать про этот адский отжиг?
Впервые слышу про NUMA в Java.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. S>А где можно прочитать про этот адский отжиг?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DenysSG, Вы писали: DSG>>Это интересно. До боли мне кажется что вы второй раз ошибаетесь. DSG>>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты? S>Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах. S>В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.
Воообще Эрланг исходно можно было запустить на многоядерной машине, стартовав по ВМ на ядро.
При отстутствии явных грабель в коде (без закладок на то, что вся работа идёт внутри одной ноды), разница в коде минимальна (фактически минимальные связи между ВМ через конфигурирование).
Но теперь и SMP в Эрланге уже довольно неплохо работает (цифр под рукой нет), правда в следующих релизах ещё хотят улучшить.
Правда вполне может получиться что запуск нескольких ВМ даст большую производительность (SMP-версия всё же содержит некоторую часть разделяемых данных, а это боттлнек)
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, DenysSG, Вы писали:
DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. S>А где можно прочитать про этот адский отжиг? S>Впервые слышу про NUMA в Java.
Здравствуйте, WFrag, Вы писали:
DSG>>Сейчас нету времени искать, но должно быть здесь DSG>>Threads and Locks
WF>Что-то мне подсказывает, что это всего лишь модель.
Здравствуйте, Sinclair, Вы писали:
S>Естественно, там ничего относящегося к твоим фантазиям нету. S>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком. S>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются". S>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Sinclair, Вы писали:
S>>Естественно, там ничего относящегося к твоим фантазиям нету. S>>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком. S>>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются". S>>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
WF>Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, DenysSG, Вы писали:
WF>Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Да, так и есть. Вообщем, я то про это тут топик и не заводил.
Это Nicht`у будет полезно почитать про то что он имел ввиду.
Здравствуйте, remark, Вы писали:
R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо)
А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает
Я даже слово волшебное знаю, пожалуйста
Здравствуйте, AndrewVK, Вы писали: AVK>Зеленые потоки в Джаве доступны уже давно.
В любом случае использование пула потоков однозначно решает проблемы стоимости создания. А уже зеленые потоки в пуле или красные — дело второе.
От этого, по идее, зависят только накладные расходы на переключение с потока на поток.
Если у нас выполняется могучий поток мелких задачек, то расходы на переключение можно свести к минимуму путем банального ограничения размера пула. В предельном случае на N-ядерной машине в пуле ровно N потоков, которые никогда не вытесняются, а постоянно вытаскивают задания из очереди и никогда не засыпают (кроме случаев отсутствия входящих задач).
Зеленые потоки помогают только в том случае, когда мы реально выполняем в потоке длинную операцию с периодическими засыпаниями в синхронном ожидании события.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
и как там таски обмениваются между собой сообщениями ?!
Здравствуйте, yumi, Вы писали:
Y>Здравствуйте, remark, Вы писали:
R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего*
назначения, они вообще ни по какому пути не идут. Они просто
предоставляют *все* возможности. Хочешь — пиши в разделяемую память,
хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и
пиши функции без побочных эффектов.
Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения,
тоже теоретически доступны *все* возможности. А вот на практике, увы
совсем другая картина.
Не понял смысл аналогии с ассемблером. Давай более конкретно. Вот
константный объект сообщения, который я передаю между потоками:
msg const* m = new msg (...);
Это С++. Что тут не так?
Вот функция без побочных эффектов, которая используется при распараллеливании:
void func(int* a, int* b, int begin, int end)
{
for (int i = begin; i != end; ++i)
a[i] += b[i];
}
Какие тут проблемы?
R>>В контексте "языки общего назначения vs языки специального
назначения" нельзя упускать из виду тот факт, что "практически любая
фича/идея/модель будучи реализована в языке специального назначения
достаточно тривиально реализуется и в языке общего назначения"
(вольный перевод, по-моему, Страуструпа).
Y>Также нельзя упускать из виду, что Эрланг тоже язык общего
назначения. Насчет "достаточно тривиально" очень спорное утверждение.
Мммм... ну и как в Эрланге работать с общей памятью?
Реализация фич определенно требует некоторого времени, но что сложного, например, передавать неизменяемые объекты между потоками? или писать функции без побочных эффектов? или сделать очередь передачи сообщений и работать в модели актёров? По своему опыту могу сказать, что всё это достигается легко. Никаких проблем не встречал.
R>>В чём проблема использовать в С++/C#/Java *уже существующие*
библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою
библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет
ряд существенных достоинств. Особенно учитывая, что любой вменяемый
проект на языке общего назначения в любом случае включает некую
начальную стадию по созданию подходящего "нижнего слоя" для всего
остального "мяса" приложения).
Y>Напиши. Вся проблема в том, что ты этого не напишешь.
Мммм... даже не знаю, что ответить... Разве что я уже две написал. И работал с рядом проектов, которые активно использовать передачу сообщений, хотя и до актёр-ориентированных не дотягивали.
Написать рабочую базовую версию — на это надо примерно 1 день. А дальше полная свобода действий. Хочешь вставляешь логирование всех проходящих сообщений, хочешь делаешь специальную фильтрацию при широковещательных рассылках, хочешь делаешь перехватчики сообщений, хочешь делаешь диспетчиризацию при отправке, хочешь при получении, хочешь делаешь reader-writer агенты и т.д.
R>>Так же можно привести такой пример. Допустим в программе есть некий
кэш данных (хэш-мап). В Erlang подходе мы этот хэш-мап отдадим одному
процессу, и когда нам надо будет к нему обратиться будем посылать
этому процессу сообщения. На физическом уровне это будет включать:
создание объекта сообщения, помещение его в очередь, переключение
контекста с текущего процесса, доставание сообщение сообщения другим
процессом, обработку сообщения, удаление первого сообщения, создание
сообщения-ответа, помещение сообщения-ответа в очередь, переключение
контекста опять на первый процесс, доставание сообщения из очереди,
удаление сообщения. R>>В модели с общей памятью мы... просто обращаемся к хэш-мапу.
Y>Переключение контекста очень дешевое, т.к. там легковесные потоки.
Там всё дешевое. Пара дешевых переключений, пара дешевых созданий сообщений, пара дешевых удалений сообщений, пара дешевых добавлений сообщений в очередь, пара дешевых доставаний сообщений из очереди. А в сумме? Максимум, чего они могут достичь при данной семантике это примерно 100 тактов на сообщение, а скорее 300-500. А если у нас запрос-ответ, то 600-1000. Это влияет на то, что вообще можно выносить в асинхронную обработку. Например, если у нас сама полезная операция занимает ~100 тактов, то накладненько получается её делать асинхронной и привлекать передачу сообщений.
Здравствуйте, DenysSG, Вы писали:
DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели. DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.
Вполне можно представить и ситуацию, когда "старая" многопоточная Java программу будет работать быстрее, ну не в 32, но допустим в 20 раз. И в тоже время "старая" Erlang программа будет работать медленнее. Автоматического линейного увеличения производительности никто не даёт.
DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Отсюда следует только один (уже хорошо известный) вывод — просто не надо часто создавать потоки. Точка. Проблема решена.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>remark,
R>>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.
LCR>В случае Эрланга дедлок совсем не смертелен
Смертелен или не смертелен — это другой вопрос. На С тоже делают программы, любое отклонение от нормальной работы в которых, не смертельно. В любом случае, дедлок — это ошибка, которая в последствии требует исправления. И получить её в Эрланг можно.
LCR> — потомушта процесс сохраняет возможность принимать другие сообщения. В том числе и те сообщения, которые вызовут badmatch с последующим перезапуском процесса (а мы же строим приложение на принципах OTP). Это кардинально отличается от замёрзшего на вайте потока.
Возможно ты удивишься, но на других языках программы тоже пишут на некоторых принципах, а не залочили тут, отлочили там, выделили тут, выделили там.
Замершие потоки прекрасно детектируются вотчдогами, встроенными средствами детектирования дедлоков и заданием таймаутов для ожидания.
LCR>Кроме того, в случае Эрланга есть эффективный и надёжный способ анализа программы на счёт отсутствия дедлоков: Towards a deadlock analysis for Erlang programs. Хотя возможно и для обычных джавы и дотнета есть подобные тулзы.
Наличие тулзов скорее говорит о наличии проблемы, а не о её отсутствии.
R>>Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.
LCR>Не мог бы ты проиллюстрировать сиё подробнее. Всегда считал, что как только мы пишем receive, то тем самым задаём явное упорядочение.
Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.
Здравствуйте, 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 очереди, или маршрутизация сообщений одному из нескольких агентов на основе фильтров, или балансировка нагрузки (когда несколько агентов подключаются к одной очереди) и т.д. Эрланг-то сам по себе как раз экстремально минималистичен, и чуть что надо сделать не типовое надо делать присядания.
Здравствуйте, 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]).
Здравствуйте, gandalfgrey, Вы писали:
G>Это реализация изначально кривого подхода — ибо затачиваться на последовательность действий вредно и опасно.
ага, это изначально реализация дедлока . достаточно запустить dl:start(). и вуаля
а у тебя код красивый, но не рабочий пока
что или как запускать-то чтобы заработало-то в смысле за дедлочило
можно по слогам
Здравствуйте, Gaperton, Вы писали:
G>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.
Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.
Здравствуйте, yumi, Вы писали:
R>>Не понял смысл аналогии с ассемблером. Давай более конкретно. Вот
Y>Этим я хотел выразить такую мысль, что Эрланг предоставляет наиболее высокий уровень абстракции при работе с многопоточными приложениями.
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>>Какие тут проблемы?
Y>А то, что тут как раз явный побочный эффект торчит, тебя не смущает? То есть при выполнении этой функции в отдельном потоке, у тебя где-то еще в другом потоке, может изменяться твой массив 'a', разве это не проблема?
Абсолютно не смущает. Это даже к лучшему — класс эффективно распараллеливаемых функций шире класса функций без побочных эффектов, и если можно этим воспользоваться, то это — хорошо.
Если измениться в другом потоке? Ну, я думаю, будет то же, что и если бы функцию без побочных эффектов применили 2 раза вместо одного — т.е. ошибка в программе. К счастью (хотя вполне логично), библиотеки поддержки параллелизма не будут вызывать функции над одними данными из разных потоков. Смысл?
Y>Теперь безотносительно побочного эффекта и связанных с ней проблем. По моим сугубо религиозным взглядам, твой пример должен параллелиться автоматически компилятором, средой, а не вручную как это делаешь ты. Попробую обосновать, когда ты это делаешь вручную, ты привязываешься на фиксированное количество ядер/процессоров
Не правильно... ну или смотря, что называть ручным распараллеливанием. Я называю что-то типа такого:
#pragma omp parallel for schedule(dynamic, 256)
for (...)
Вся интеллектуальная часть (самое сложное) ложится на программиста. Вся рутинная работа (в т.ч. подгон под кол-во ядер) — на ран-тайм.
Y>(хотя конечно можно вручную тоже это рулить, но это тот еще геморрой). Поэтому я считаю, что такой код должен быть распараллелен компилятором, средой. По одной простой причине, что среде исполнения будет известно количество ядер/процессоров на которой исполняется твоя программа и она сможет эффективно ее распараллелить для конкретной машины. Например, твой пример для одно ядерной машины будет эффективнее выполнить целиком, то бишь передать: begin = 0, end = lenght — 1. А для двух ядерной машинки в два потока: (begin = 0, length/2) и (begin = length/2 + 1, end = length — 1).
Рутинные-то операции компилятор/ран-тайм могут сделать, в т.ч. учитывая число ядер. Проблема в том, что они не могут сделать интеллектуальную часть.
А всё полностью делать руками никто особо и не призывает... ну кроме разве что самых специфических случаев.
R>>Мммм... ну и как в Эрланге работать с общей памятью?
Y>См. mnesia.
Какая связь между DBMS и shared memory?
Y>>>Напиши. Вся проблема в том, что ты этого не напишешь.
R>>Мммм... даже не знаю, что ответить... Разве что я уже две написал. И работал с рядом проектов, которые активно использовать передачу сообщений, хотя и до актёр-ориентированных не дотягивали. R>>Написать рабочую базовую версию — на это надо примерно 1 день. А дальше полная свобода действий. Хочешь вставляешь логирование всех проходящих сообщений, хочешь делаешь специальную фильтрацию при широковещательных рассылках, хочешь делаешь перехватчики сообщений, хочешь делаешь диспетчиризацию при отправке, хочешь при получении, хочешь делаешь reader-writer агенты и т.д.
Y>Я имел ввиду Erlang style concurrency с такими же TTX.
Так в том-то и суть, что это не надо писать. Базовая часть естественно нужна. Что-то нужно, но не с такими ТТХ, а с меньшими. Что-то нужно, но с лучшими ТТХ. Что-то не нужно вообще. Что-то нужно, чего нет в Эрланг. И не всё из этого нужно сразу.
Y>Кстати уж больно ты мне одного товарища напоминаешь, ты случаем не с софтового отдела Intel'а?
Здравствуйте, cadet354, Вы писали:
C>Я особенно глубоко не разбирался с ССR (видимо зря), не подскажешь как сделать такую вещь как очередь с приоритетом, причем приоритет определяться по определенному полю в обьекте, его значению, грубо говоря больше/меньше определенного параметра.
Как там это сделать по-правильному не скажу. Возможно самое простое решение — завести 2 порта (очереди), каждая очередь под сообщения своего приоритета.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, Gaperton, Вы писали:
G>>>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
R>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.
R>>Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.
К>Или получая проблемы из обоих моделей
Ну плохое-то сделать это на любом языке и при любой технологии — не проблема... Но меня это не особо интересует. Меня интересует как сделать хорошо — соотв. я и предлагаю комбинировать с умом и брать лучшее.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
R>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.
R>Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.
Так будет не честнее, потому, что преимущество очевидно есть. Акторы гораздо, существеннее устойчивее к латентности системы. К тому же, в ряде случаев у тебя общей памяти натурально нет, и что удивительно, именно тогда, когда высока латентность каналов связи. Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Здравствуйте, Gaperton, Вы писали:
G>>>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.
R>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.
R>>Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.
G>Так будет не честнее, потому, что преимущество очевидно есть. Акторы гораздо, существеннее устойчивее к латентности системы. К тому же, в ряде случаев у тебя общей памяти натурально нет, и что удивительно, именно тогда, когда высока латентность каналов связи. Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить???
Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.
По поводу кластера, между узлами кластера разделяемой памяти нет (DSM не в счёт) поэтому тут и говорить особенно нечего. А вот внутри узлов кластера — другое дело. Например стандартная практика применять между узлами кластера MPI (обмен сообщениями), а внутри узлов — OpenMP (разделяемая память), просто потому что так получается значительно быстрее и проще.
Здравствуйте, remark, Вы писали:
G>>Так будет не честнее, потому, что преимущество очевидно есть. Акторы гораздо, существеннее устойчивее к латентности системы. К тому же, в ряде случаев у тебя общей памяти натурально нет, и что удивительно, именно тогда, когда высока латентность каналов связи. Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
R>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить???
Ну надо же, откуда-то вдруг какие-то преимущества нарисовались, которых у разделяемой памяти нет. Зачем? Затем, что чуть выше ты сказал:
R>>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе. R>>>Я думаю, так будет честнее.
Помнишь, что ты мне сказал? Теперь поступи так, как считаешь что будет честнее. Скажем, признай, что погорячился. Как вариант.
Здравствуйте, Gaperton, Вы писали:
G>Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
Вариант вполне рабочий, кстати. Это даже автоматизируется с помощью Terracotta, например. Естественно, оно не применимо на ВСЕХ задачах. Но это и не нужно..
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится? C>Вариант вполне рабочий, кстати. Это даже автоматизируется с помощью Terracotta, например. Естественно, оно не применимо на ВСЕХ задачах. Но это и не нужно..
Знаю, что рабочий. Берется низколатентная сеть, например InfiniBand, эмулируется общая память, и потом любуемся на график производительности. Херово он себя ведет. Умножение матриц на MPI с явно выделенными блоками на том же infiniband масштабируется значительно лучше, чем ты получишь на эмулированной общей памяти. Причина? Манипулируя сообщениями, ты выделяешь локальность данных. Вынужден. Оперируя общей памятью, тебе типа об этом можно не думать. Со всеми вытекающими.
Здравствуйте, Gaperton, Вы писали:
G>Знаю, что рабочий. Берется низколатентная сеть, например InfiniBand, эмулируется общая память, и потом любуемся на график производительности. Херово он себя ведет. Умножение матриц на MPI с явно выделенными блоками на том же infiniband масштабируется значительно лучше, чем ты получишь на эмулированной общей памяти. Причина? Манипулируя сообщениями, ты выделяешь локальность данных. Вынужден. Оперируя общей памятью, тебе типа об этом можно не думать. Со всеми вытекающими.
Я вот использую систему с "общей памятью" (распределённым кластерным кэшем) для кэширования данных. Подавляющая часть операций — это чтение, которое замечательно выполняется без всяких кластерных блокировок. Прекрасно работает даже на сравнительно высоколатентном Ethernet'е.
Здравствуйте, remark, Вы писали:
R>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить??? R>Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.
Я не вполне понимаю, что имеется в виду под "разделяемой памятью" и "неразделяемой памятью".
Какое именно преимущество есть у разделяемой памяти?
Отсутствие копирования? Ну так если у нас есть "передача владения", то среда может эмулировать эффекты приватной памяти без копирования.
Хочется понять, какие неотъемлемые проблемы есть у неразделяемой памяти.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, remark, Вы писали:
R>Как там это сделать по-правильному не скажу. Возможно самое простое решение — завести 2 порта (очереди), каждая очередь под сообщения своего приоритета.
да нет, надо чтоб если есть в очереди сообщения с определенном признаком, то их обработать в первую очередь, причем клиенты (те кто посылают сообщения о приоритетах мало что знают).
Т.е. прогнать текущую очередь, выбрать нужные, обработать, потом обрабатывать остальные в порядке получения, в ерланге это выглядит так:
priority_receive() ->
receive
{alarm, X} ->
{alarm, X}
after 0 ->
receive
Any ->
Any
end
end.
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, remark, Вы писали:
R>>Как там это сделать по-правильному не скажу. Возможно самое простое решение — завести 2 порта (очереди), каждая очередь под сообщения своего приоритета. C>да нет, надо чтоб если есть в очереди сообщения с определенном признаком, то их обработать в первую очередь, причем клиенты (те кто посылают сообщения о приоритетах мало что знают). C>Т.е. прогнать текущую очередь, выбрать нужные, обработать, потом обрабатывать остальные в порядке получения, в ерланге это выглядит так: C>
C>priority_receive() ->
C> receive
C> {alarm, X} ->
C> {alarm, X}
C> after 0 ->
C> receive
C> Any ->
C> Any
C> end
C> end.
C>
C>копирайты Армстронга.
Не подскажу, как такое смоделировать... там вроде ещё упоминалась возможность вручную создавать фильтры, может так можно... а может и что встроенное есть. Кстати, там по-моему совсем на днях новая версия вышла.
Здравствуйте, Gaperton, Вы писали:
G>>>Так будет не честнее, потому, что преимущество очевидно есть. Акторы гораздо, существеннее устойчивее к латентности системы. К тому же, в ряде случаев у тебя общей памяти натурально нет, и что удивительно, именно тогда, когда высока латентность каналов связи. Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
R>>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить???
G>Ну надо же, откуда-то вдруг какие-то преимущества нарисовались, которых у разделяемой памяти нет. Зачем? Затем, что чуть выше ты сказал:
R>>>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе. R>>>>Я думаю, так будет честнее.
G>Помнишь, что ты мне сказал? Теперь поступи так, как считаешь что будет честнее. Скажем, признай, что погорячился. Как вариант.
Я надеюсь, это шутка?
Очевидные и широко-известные приемущества разделяемой памяти — это (1) скорость работы и (2) низкая латентность.
Сравни 1 сохранение/загрузку из памяти против оверхеда на полный цикл 2 сообщений (запрос-ответ). 2 сообщения — это как минимум 2 записи в разделяемую память + 2 чтения из разделяемой памяти + 2 переключения контекста + в реальности значительно больше оверхеда (динамическая аллокация памяти, освобождениие памяти, копирования, добавления/извлечения из очереди).
А таком контексте вопрос по поводу факта наличия преимуществ у разделяемлой памяти меня просто шокирует.
Ну и так же есть преимущество в виде синхронного получения результата. Даже в Эрланге это (асинхронные сообщения) порождает некоторый синтаксический оверхед, а в большинстве языков необходимость в череде вызовов, на которые необходимы ответы для продолжения выполнения, — это просто @#$%^. Обычный вызов функции с синхронным получением результата для такого кода — это как манна с неба.
Здравствуйте, Sinclair, Вы писали:
R>>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить??? R>>Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.
S>Я не вполне понимаю, что имеется в виду под "разделяемой памятью" и "неразделяемой памятью". S>Какое именно преимущество есть у разделяемой памяти? S>Отсутствие копирования? Ну так если у нас есть "передача владения", то среда может эмулировать эффекты приватной памяти без копирования. S>Хочется понять, какие неотъемлемые проблемы есть у неразделяемой памяти.
Здравствуйте, remark, Вы писали:
G>>>>Так будет не честнее, потому, что преимущество очевидно есть. Акторы гораздо, существеннее устойчивее к латентности системы. К тому же, в ряде случаев у тебя общей памяти натурально нет, и что удивительно, именно тогда, когда высока латентность каналов связи. Возьми кластер, связанный гигабитным ethernet. Что будем делать? Эмулировать общую память (словив огромную латентность)? Знаешь, какая именно просадка в производительности у тебя получится?
R>>>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить???
G>>Ну надо же, откуда-то вдруг какие-то преимущества нарисовались, которых у разделяемой памяти нет. Зачем? Затем, что чуть выше ты сказал:
R>>>>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе. R>>>>>Я думаю, так будет честнее.
G>>Помнишь, что ты мне сказал? Теперь поступи так, как считаешь что будет честнее. Скажем, признай, что погорячился. Как вариант.
R>Я надеюсь, это шутка?
Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
R>Очевидные и широко-известные приемущества разделяемой памяти — это (1) скорость работы и (2) низкая латентность.
"Очевидное и широко-известное преимущество" не работает на современных суперкомпьютерах, состоящих их сотен или тысяч машин, соединенных сетями InifiniBand или подобными. Там рулит MPI, основанный на модели передачи сообщений.
R>А таком контексте вопрос по поводу факта наличия преимуществ у разделяемлой памяти меня просто шокирует.
Предлагаю перевести мозг в позицию on. И внимательно посмотреть, что я тебе пишу. И свои посты перечитать. Сопоставить. ПОДУМАТЬ.
R>
Хм. Я, наверное, очень тупой. Но ты сравниваешь какие-то непонятные мне вещи.
Давай сравним по честному.
Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
Что у нас в случае разделяемой памяти?
поток 1:
unlock(&s);
wait(e1);
lock(&s);
read(&s)
поток 2:
lock(&s);
write(&s, s+q);
unlock(&s);
set(e1);
Это точно будет дешевле, чем обмен сообщениями?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Хм. Я, наверное, очень тупой. Но ты сравниваешь какие-то непонятные мне вещи. S>Давай сравним по честному. S>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
S>Что у нас в случае разделяемой памяти? S>поток 1: S>
Это ты и реализовал обмен сообщениями!!! Это не разделяемая память! Ключевое слово — разделяемая, потоки *разделяют* данные. Вот разделяемая память
class foo
{
private:
mutex guard;
int q;
public:
int make(int s)
{
int r;
guard.lock();
r = q;
guard.unlock();
return r + s;
}
};
void thread(foo& f)
{
//...int s = rand();
int r = f.foo(s);
//...
}
Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков, аллокаций сообщений и т.д.
Это я привёл базовый вариант, данную конкретную задачу на С++ целесообразно реализовать так:
[ccode]
class foo
{
private:
std::mutex guard;
std::atomic<int> q;
public:
int make(int s)
{
return s + q.load(std::memory_order_relaxed);
}
};
[ccode]
Это уже будет на 2-3 порядка (!) (прописью: на два-три порядка, т.е. 100-1000 раз) эффективнее, чем обмен сообщениями. Тут исключили так же модификацию разделяемого состояния и убрали все барьеры памяти. Т.е. всё, что мы платим за синхронизацию — одна обычная инструкция загрузки из памяти. Плюс такая функция скорее всего будет встроена — т.е. вообще на всё-про-всё 0.5 такта.
Естественно, что такие оптимизации не приминимы во всех случаях, но тем не менее иногда они применимы, и зачастую задачу сводят к такому виду, что бы можно было применить такие оптимизации, и тогда можно получать на несколько порядков более эффективные решения, чем обмен сообщениями.
Здравствуйте, remark, Вы писали:
G>>Предлагаю перевести мозг в позицию on. И внимательно посмотреть, что я тебе пишу. И свои посты перечитать. Сопоставить. ПОДУМАТЬ.
R>Называется "научи дурака богу молиться...". Я, конечно, извиняюсь, что я не привёл контекст, просто я думал, что это достаточно очевидно. Контекст — многоядерные/многопроцессорные машины, которые имеют разделяемую память и даже более — разделяемая память — это основная (и скорее всего — единственная) физическая модель взимодействия на них. И даже ещё более — даже машины в кластере внутри себя могут общаться на основе разделяемой памяти, если машины — многоядерные/многопроцессорные. Естественно, если мы говорим о распределенных системах, то тут разделяемая память не релевантна. Так же как не релевантен обмен сообщениями на, например, некоторых микроконтроллере, там даже скорее всего и ран-тайм-то не влезет. Ну и что из этого? Если следовать твоей линии рассуждений, то получается, что обмен сообщениями — это @#$%%^, т.к. он не может применяться на маленьких микроконтроллерах. Конечно, это неправильно. Невозможность применения обмена сообщенями в некоторых ситуациях ничего не говорит о нём как таковом, просто значит — это не его область. Точно так же и с разделяемой памятью — просто не пытайся привинчивать её к распределенным кластерам (я этого не делаю). У неё другая область применения — и там у неё есть преимущества.
Дабы не быть голословным — вот пример, где разделяемая память на 2-3 порядка (100-1000 раз) быстрее, чем обмен сообщениями на современном многоядерном железе: http://www.rsdn.ru/forum/message/3187084.1.aspx
Здравствуйте, remark, Вы писали:
R>Это ты и реализовал обмен сообщениями!!! Это не разделяемая память! Ключевое слово — разделяемая, потоки *разделяют* данные. Вот разделяемая память
R>
R>class foo
R>{
R>private:
R> mutex guard;
R> int q;
R>public:
R> int make(int s)
R> {
R> int r;
R> guard.lock();
R> r = q;
R> guard.unlock();
R> return r + s;
R> }
R>};
R>void thread(foo& f)
R>{
R> //...
R> int s = rand();
R> int r = f.foo(s);
R> //...
R>}
R>
Ничего не понимаю. Ты не воспроизвел пример. У тебя s осталась неизменной, ты разделил q. Это совсем другая задача, при обмене сообщениями она тоже решается гораздо дешевле, чем двунаправленный обмен. Просто один поток пошлет другому s.
R>Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков,
А как же lock()? Ты думаешь, lock() не приведет к блокировке потока в ожидании того, пока кто-то другой не сделает unlock()? R>аллокаций сообщений и т.д. аллокация — это искусственный термин. Её стоимость можно свести к нулю.
Пример на С++ опять же показывает, что можно и вовсе без синхронизации работать, если жить в одном потоке.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Ничего не понимаю. Ты не воспроизвел пример. У тебя s осталась неизменной, ты разделил q.
Значит, я не понял условия. Опиши его, пожалуйста, более подробно. В условии вроде ничего не было про то, что надо изменить значение s. Но предположительно, если надо изменить s, значит допишем:
s = f.make(s);
S>Это совсем другая задача, при обмене сообщениями она тоже решается гораздо дешевле, чем двунаправленный обмен. Просто один поток пошлет другому s.
Если действие инициируется вторым потоком, то да, он может сам послать значение, тем самым инициировав действие. Но если у нас модель клиент-сервер, то первый поток вначале будет запрашивать значение.
R>>Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков, S>А как же lock()? Ты думаешь, lock() не приведет к блокировке потока в ожидании того, пока кто-то другой не сделает unlock()?
Если мьютекс не занят, то конечно нет. Мьютекс должен быть большую часть времени не занят — это нормальный режим функционирования для мьютекса. В примере с сообщениями же совершенно другая ситуация — мы просто вынеждены блокировать первый поток до прихода ответа.
Ну и в принципе, для задачи читатели-писатели есть совсем не блокирующие мьютексы для читателей.
R>>аллокаций сообщений и т.д. S>аллокация — это искусственный термин. Её стоимость можно свести к нулю.
Я понимаю. Стоимость практически всего можно свести к нулю. Однако на практике же из всех этих мелочей набегает достаточно значительная цифра. Кто Эрангом занимается скажите, сколько стоит передача запроса-ответа на многоядерном процессоре? Моя интуиция подсказывает, что не меньше 500 тактов должно быть.
S>Пример на С++ опять же показывает, что можно и вовсе без синхронизации работать, если жить в одном потоке.
Нет, ты упустил суть. Это — *многопоточный* код. Именно в многопоточном окружении мы платим всего одну инструкцию загрузки для синхронизации.
Здравствуйте, Sinclair, Вы писали:
S>Зеленые потоки помогают только в том случае, когда мы реально выполняем в потоке длинную операцию с периодическими засыпаниями в синхронном ожидании события.
Что в свою очередь решается I/O APM
Здравствуйте, remark, Вы писали: R>Значит, я не понял условия. Опиши его, пожалуйста, более подробно. В условии вроде ничего не было про то, что надо изменить значение s.
А иначе никаких разделяемых данных вовсе нет. Я имел в виду, что совместно используется общее значение s. Его нужно обязательно синхронизировать, потому что никакого контроля за тем, сколько потоков одновременно попробуют получать к нему доступ, нету.
R>Но предположительно, если надо изменить s, значит допишем: R>
R>s = f.make(s);
R>
Вот этот код — он в каком потоке исполняется?
Ты по прежнему разделяешь данные q, при этом только на чтение.
Может быть, нужно представить какой-то более человеческий пример? Ну вот — пусть у нас N потоков считают сумму массива. Каждый считает свой фрагмент и кидают сумму в общую кучу. В разделяемой памяти каждый вычислительный поток захватывает мьютекс — делает += — отпускает мьютекс.
В MPS один актер хранит сумму, остальные кидают ему слагаемые. Он ловит и прибавляет к своей сумме. Кто больше потратит на синхронизацию?
R>Я понимаю. Стоимость практически всего можно свести к нулю. Однако на практике же из всех этих мелочей набегает достаточно значительная цифра.
Я имею в виду не к мелочи, а к нулю. В том смысле, что передача сообшения на самом деле может вообще никаких операций в памяти не проводить. Просто адрес перестает быть виден одному актеру и становится виден другому. Мы же работаем в общем адресном пространстве — значит, маршалинг не нужен.
Всё, что нужно от MPS для обеспечения thread-safety — это гарантия того, что ни один указатель не достижим со стека более чем одного потока. Единственные "разделяемые" указатели — это ссылки на очереди сообщений. Есть подозрение, что сделать это всё можно крайне эффективно — по крайней мере, не менее эффективно чем lock/unlock для разделяемых данных.
R> Кто Эрангом занимается скажите, сколько стоит передача запроса-ответа на многоядерном процессоре? Моя интуиция подсказывает, что не меньше 500 тактов должно быть. Подождем, может ответят.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали: R>>Значит, я не понял условия. Опиши его, пожалуйста, более подробно. В условии вроде ничего не было про то, что надо изменить значение s.
S>А иначе никаких разделяемых данных вовсе нет. Я имел в виду, что совместно используется общее значение s. Его нужно обязательно синхронизировать, потому что никакого контроля за тем, сколько потоков одновременно попробуют получать к нему доступ, нету.
Как нет? q — разделяемые данные, множество потоков его меняют и множество — читают.
R>>Но предположительно, если надо изменить s, значит допишем: R>>
R>>s = f.make(s);
R>>
S>Вот этот код — он в каком потоке исполняется?
В смысле в каком? В каком-то.
S>Ты по прежнему разделяешь данные q, при этом только на чтение.
q разделяется и на чтение и на запись.
Когда в части операций данные нужны только "для чтения" — то это хорошая ситуация для разделямой памяти, т.к. можно обойтись без модификаций разделяемых данных. В принципе, многие системы обмена сообщениями для разделямой памяти могут разделять данные без копирования, т.е. просто констнтный объект рассылается всем заинтересованным лицам. Но тут будет проблема при обновлении, если они частые — то при каждом изменении надо будет делать массовые рассылки сообщений.
S>Может быть, нужно представить какой-то более человеческий пример? Ну вот — пусть у нас N потоков считают сумму массива. Каждый считает свой фрагмент и кидают сумму в общую кучу. В разделяемой памяти каждый вычислительный поток захватывает мьютекс — делает += — отпускает мьютекс. S>В MPS один актер хранит сумму, остальные кидают ему слагаемые. Он ловит и прибавляет к своей сумме. Кто больше потратит на синхронизацию?
Я думаю, что разделяемые данные будут эффективнее.
R>>Я понимаю. Стоимость практически всего можно свести к нулю. Однако на практике же из всех этих мелочей набегает достаточно значительная цифра. S>Я имею в виду не к мелочи, а к нулю. В том смысле, что передача сообшения на самом деле может вообще никаких операций в памяти не проводить. Просто адрес перестает быть виден одному актеру и становится виден другому. Мы же работаем в общем адресном пространстве — значит, маршалинг не нужен.
Ну в очередь-то надо что-то класть. Если очередь на основе списка, то нужен элемент, который класть в этот список. Тем более, например, в Эрланг зачастую посылают (PID отправителя, данные), такой структуры у потока нет — она ему не нужна, занчит надо её аллокировать, скопировать в неё данные, потом освободить (это плюс к тому элементу, который находится в очереди на основе списка).
S>Всё, что нужно от MPS для обеспечения thread-safety — это гарантия того, что ни один указатель не достижим со стека более чем одного потока. Единственные "разделяемые" указатели — это ссылки на очереди сообщений. Есть подозрение, что сделать это всё можно крайне эффективно — по крайней мере, не менее эффективно чем lock/unlock для разделяемых данных.
Максимум, чего мне удавалось добиться на достаточно примитивной системе — 70 тактов на одно сообщение. Т.е. в 2 стороны будет 140 тактов. Я делал передачу разделяемых данных, без компированиый/сериализаций, сложно сказать, что будет эффективнее в общем случае (наверное ничего). Плюс у меня не было переключенй контекстов, т.к. не было блокирующих операций приёма сообщений, переключение контекста по-любому не меньше 10-20 тактов.
Большую часть съедают всякие мелочи — аллокация вспомогательной структуры — несколько тактов, освобождение — несколько тактов, инициализация — несколько, проверки тут да там — несколько и т.д.
Я подозреваю, что в Эрланг всё значительно хуже. Тем более, что там есть такие вещи как преобразование PID в указатель (или PID это сразу указатель?), сериализация/десериализация данных, переключения контекстов и т.д.
Плюс разделяемых данных, что их не обязательно делать с мьютексом. Можно с атомарными read-modify-write операциями, можно с обычными чтениями/записями, можно применять "не традиционные" мьютексы, которые способны сводить стоимость lock/unlock практически к нулю.
Здравствуйте, remark, Вы писали:
S>>А иначе никаких разделяемых данных вовсе нет. Я имел в виду, что совместно используется общее значение s. Его нужно обязательно синхронизировать, потому что никакого контроля за тем, сколько потоков одновременно попробуют получать к нему доступ, нету.
R>Как нет? q — разделяемые данные, множество потоков его меняют и множество — читают.
В твоем примере нет никакой записи в q.
R>В смысле в каком? В каком-то.
Почему этот поток считает, что s можно безопасно модифицировать? Это вырожденный пример. В жизни слагаемые приватны, разделяются именно суммы.
Там, где нет конфликта зависимостей, ничего интересного с точки зрения распараллеливания не происходит.
S>>Может быть, нужно представить какой-то более человеческий пример? Ну вот — пусть у нас N потоков считают сумму массива. Каждый считает свой фрагмент и кидают сумму в общую кучу. В разделяемой памяти каждый вычислительный поток захватывает мьютекс — делает += — отпускает мьютекс. S>>В MPS один актер хранит сумму, остальные кидают ему слагаемые. Он ловит и прибавляет к своей сумме. Кто больше потратит на синхронизацию?
R>Я думаю, что разделяемые данные будут эффективнее.
На основании чего ты так думаешь?
R>Ну в очередь-то надо что-то класть. Если очередь на основе списка, то нужен элемент, который класть в этот список.
Пусть в этот список всегда кладется ссылка.
R>Тем более, например, в Эрланг зачастую посылают (PID отправителя, данные), такой структуры у потока нет — она ему не нужна, занчит надо её аллокировать, скопировать в неё данные, потом освободить (это плюс к тому элементу, который находится в очереди на основе списка).
Аллокирование у нас сделано заранее. Ведь данные уже есть, не так ли? Значит, сама передача может выполняться без аллокаций.
R>Большую часть съедают всякие мелочи — аллокация вспомогательной структуры — несколько тактов, освобождение — несколько тактов, инициализация — несколько, проверки тут да там — несколько и т.д.
Ну, я плохо знаком с предметом, но что-то мне подсказывает, что в очереди на основе кольцевого буфера "аллокирование" и "освобождение" может быть сравнимым с выделением в хипе.
R>Плюс разделяемых данных, что их не обязательно делать с мьютексом. Можно с атомарными read-modify-write операциями, можно с обычными чтениями/записями, можно применять "не традиционные" мьютексы, которые способны сводить стоимость lock/unlock практически к нулю.
Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
R>Не подскажу, как такое смоделировать... там вроде ещё упоминалась возможность вручную создавать фильтры, может так можно... а может и что встроенное есть. Кстати, там по-моему совсем на днях новая версия вышла.
точно, правда не новая версия, а релиз(странно как-то без беты, сразу из CTP) , появилась платная студия, вот я только не понял, а рантаймом бесплатно можно пользоваться?
Здравствуйте, Gaperton, Вы писали:
R>>Это просто не тот случай, когда у разделяемой памяти есть приемущества. Зачем его вообще в таком контексте приводить???
G>Ну надо же, откуда-то вдруг какие-то преимущества нарисовались, которых у разделяемой памяти нет. Зачем? Затем, что чуть выше ты сказал:
R>>>>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе. R>>>>Я думаю, так будет честнее.
G>Помнишь, что ты мне сказал? Теперь поступи так, как считаешь что будет честнее. Скажем, признай, что погорячился. Как вариант.
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
R>>>Я надеюсь, это шутка?
G>>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
R>Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ.
Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
Показать тебе особую, форумную магию? Пока ты ищещь мой пост, которого нет, я могу тебе показать твой пост, где ты серьезно утверждаешь, что у модели с сообщениями "преимуществ нет в принципе". На пост свой посмотри.
Здравствуйте, remark, Вы писали:
R>Дабы не быть голословным — вот пример, где разделяемая память на 2-3 порядка (100-1000 раз) быстрее, чем обмен сообщениями на современном многоядерном железе: R>http://www.rsdn.ru/forum/message/3187084.1.aspx
Ага. Быстрее. До той поры, пока ты не догадаешься в данном примере применить для обмена сообщениями lock-free очередь. Тогда, волшебным образом, обмен сообщениями станет быстрее разделяемой памяти .
Здравствуйте, Gaperton, Вы писали:
G>Ага. Быстрее. До той поры, пока ты не догадаешься в данном примере применить для обмена сообщениями lock-free очередь. Тогда, волшебным образом, обмен сообщениями станет быстрее разделяемой памяти . G>Хреновый у тебя пример, на самом деле.
Да, можно сделать намного лучше
Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно.
Здравствуйте, Gaperton, Вы писали:
R>>>>Я надеюсь, это шутка?
G>>>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
R>>Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ.
G>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
G>Показать тебе особую, форумную магию? Пока ты ищещь мой пост, которого нет, я могу тебе показать твой пост, где ты серьезно утверждаешь, что у модели с сообщениями "преимуществ нет в принципе". На пост свой посмотри.
G>http://rsdn.ru/forum/message/3183921.1.aspx
Здравствуйте, Gaperton, Вы писали:
R>>Дабы не быть голословным — вот пример, где разделяемая память на 2-3 порядка (100-1000 раз) быстрее, чем обмен сообщениями на современном многоядерном железе: R>>http://www.rsdn.ru/forum/message/3187084.1.aspx
G>Ага. Быстрее. До той поры, пока ты не догадаешься в данном примере применить для обмена сообщениями lock-free очередь. Тогда, волшебным образом, обмен сообщениями станет быстрее разделяемой памяти .
Вообще, обычно, у меня хорошо с отличением и понимаем шуток... Но ты ставишь меня просто в тупик...
Хммм... Ну на самом деле если я посмеюсь: ХА-ХА-ХА-ХА-ХА [небольшой отдых] ХА-ХА-ХА-ХА-ХА
то это будет релевантно под оба варианта: если это шутка и нет.
Если это не шутка, то это будет релевантно, т.к. lock-free очередь не будет быстрее даже спин-лока. Т.е. все оверхеды на обмен сообщениями так и останутся выше, чем у разделяемой памяти (там где они были выше).
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
Lock-free НЕ имеет никакого отношения ни к производительности, ни к масштабируемости, Lock-free — это ТОЛЬКО о гарантиях системного прогресса: http://rsdn.ru/Forum/message/2930849.1.aspx
Кстати, какой именно алгоритм lock-free очереди ты имеешь в виду?
G>Хреновый у тебя пример, на самом деле.
Хреновый для чего? Хреновый для выставления достоинств передачи сообщений? Согласен. Но ведь мы сейчас выставляем достоинства разделяемой памяти. Иногда ведь, знаешь, надо и глобальное время (или что-то типа этого) откуда-то считать; а откуда его считать, если мы от разделяемой памяти отказались в принципе? Придётся сообщения слать агенту, который за время отвечает... ну либо на каждый тик делать широковещательную рассылку... А так могли бы просто считать слово из памяти...
C>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно.
Это как это так это вот?
Неудобно с какой точки зрения?
Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
R>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf
We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines.
А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
S>>Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
R>Модель не предусматривает таких оптимизаций. Мы же сознательно открещиваемся от разделяемых данных. А это как раз оптимизации, которые хорошо ложатся именно на разделяемые данные, потому что данные... *разделяемые* по сути своей.
Модель вообще не касается оптимизаций — модель есть модель. Она допускает любые оптимизации, не нарушающие семантику.
Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
Какое отношение имеют твои фантазии к реальности, я показал на примере MPI и OpenMP.
Здравствуйте, remark, Вы писали:
R>>>>>Я надеюсь, это шутка?
G>>>>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.
R>>>Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ.
G>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?
R>Ну тогда — извини. Я просто не понял (и не понимаю) твоё высказывание, что будет НЕ честнее сказать, что у модели актёров нет преимуществ и недостатков разделяемой памяти (вместо только недостатков).
Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.
Даже если твою фразу понимать так, как ты здесь пишешь, то тезис о наличии значимых преимуществ у разделяемой памяти, которых якобы лишена модель передачи сообщений, тебе надо для начала доказать. Потому, например, что практика применения MPI и OpenMP его на данный момент не подтверждает. MPI во многих случаях быстрее, чем OpenMP даже на SMP конфигурациях с общей памятью.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, remark, Вы писали: S>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
Вот другой пример:
Есть некое число s инициализированное нулем.
Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Здравствуйте, Gaperton, Вы писали:
R>>Если у нас будет паттерн запрос-ответ (клиент-сервер), то всё будет намного хуже — будет ещё блокирование клиента, отправка ответа, доставание ответа, разблокирование клиента.
G>Все, хватит нести чушь и полоскать людям мозг. Надоело. Вот есть факт. Программы на MPI, основанные на передаче сообщений, в большинстве случаев быстрее, чем программы под OpenMP, который построен на разделяемой памяти. Даже на одной машине. Это наблюдаемый факт. А твои слова — это бла-бла-бла. Вот обгони для начала на разделяемой памяти умножение MPI-ное матриц на многоядерном проце, как ты говоришь, "на два порядка", и тогда будешь говорить мне, что там сказать честнее. Умнные все стали, сил нет, языками чесать.
Gaperton, ты как-то изличше категоричен. OpenMP — это вообще частный случай разделяемой памяти, не всегда удачный или применымий. Он вообще заточен под вычислительные задачи. Я думаю никому не прийдет в голову пытаться делать например разделяемый кэш на OpenMP. Так что не надо эти результаты экстраполировать на все возможные варианты разделяемой памяти.
G>http://www.lri.fr/~gk/QUID/papers/SPAA2003.pdf G>We have demonstrated that it is absolutely not obvious G>to get better performance with OpenMP codes compared to G>MPI ones on shared memory machines.
G>А на нескольких машинах, к сведению, OpenMP не просто отстает, он С.О.С.Е.Т. Именно так. Причина в том, что модель на сообщениях — асинхронна, и поэтому хорошо толерантна к высоким задержкам. Почему и дает почти линейную масштабируемость.
Возможно сосет в умножении матриц, не более, не надо на все обобщять
S>>>Вот хочется точно понять, почему такие же трюки неприменимы к передаче сообщений.
R>>Модель не предусматривает таких оптимизаций. Мы же сознательно открещиваемся от разделяемых данных. А это как раз оптимизации, которые хорошо ложатся именно на разделяемые данные, потому что данные... *разделяемые* по сути своей.
G>Модель вообще не касается оптимизаций — модель есть модель. Она допускает любые оптимизации, не нарушающие семантику.
G>Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
Ну в таком случае ты согласишься, что MPI реализация в рамках одной машины вполне может опираться на разделяемую память? В любом случае какая-то разделяемая память будет, иначе через что ты передашь сообщени от одного потока к другому?
У всего должно быть свое место, remark сказал, что у разделяемой памяти есть преимущества ктр нет у передачи сообщений . Не дстатки тоже есть, он и не отрицает.
Ты же пытаешься показать, что передача сообщений — некая серебряная пуля и разделяемая память может быть _везде_ заменена на передачу сообщений.
Здравствуйте, RailRoadMan, Вы писали:
S>>Здравствуйте, remark, Вы писали: S>>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
Согласен. Что бы показать, что у разделяемой памяти нет преимуществ, и обмен сообщениями всегда лучше, надо приводить ситуации, которые благоприятны для разделяемой памяти. Только анализ таких ситуаций может показать что-то по существу.
А то вот Gaperton приводит какие-то распределенные кластеры для супер-вычислений, и считает, что он этим что-то доказывает.
Здравствуйте, RailRoadMan, Вы писали: RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
То же самое. Один поток владеет этим числом; он раскидывает его остальным потокам, они обрабатывают число, а ему кидают сообщение "прибавь дельту".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>Вот другой пример: RRM>Есть некое число s инициализированное нулем. RRM>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, RailRoadMan, Вы писали: RRM>>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками S>Грамотная реализация очереди будет делать то же самое.
Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>>Вот другой пример: RRM>>Есть некое число s инициализированное нулем. RRM>>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
G>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
А почему бы и нет? Потоки делают ещё и что-то другое, что содержит параллелизм, но так же им надо сделать и это.
Здравствуйте, Gaperton, Вы писали:
G>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
А ничего, что в примере до этого (ктр про s и q) не сильно больше?
Здравствуйте, RailRoadMan, Вы писали:
G>>Религиозные соображения в духе "мы же сознательно открещиваемся" — нам, инженерам, малоинтересны. Вы открещиваетесь? Открещивайтесь дальше.
RRM>Ну в таком случае ты согласишься, что MPI реализация в рамках одной машины вполне может опираться на разделяемую память? В любом случае какая-то разделяемая память будет, иначе через что ты передашь сообщени от одного потока к другому?
Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?
Тем более, что это совершенно не имеет значения в конткесте разговора, как именно устроена реализация MPI. Главное, что она почему-то часто оказывается на практике на реальных задачах быстрее, чем манипуляции с разделяемой памятью — даже на SMP. Вот незадача.
RRM>Ты же пытаешься показать, что передача сообщений — некая серебряная пуля и разделяемая память может быть _везде_ заменена на передачу сообщений.
Да ну, правда штоли? Ссылку на мое сообщение можно посмотреть? Давай так — ты ссылку сначала найдешь, а потом расскажешь мне про список глупостей, которые я по твоему пытаюсь показать.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
S>То же самое. Один поток владеет этим числом; он раскидывает его остальным потокам, они обрабатывают число, а ему кидают сообщение "прибавь дельту".
Получается 2 посылки сообщений против одной операции над разделяемой памятью. Ну ладно, даже если мы это сведём к одной посылке сообщений (изначальную рассылку убрали — допустим изначальное значение всем уже известно). Что такое посылка/обработка сообщения — это в любом случае одна небольшая операция над разделяемой памятью (добавление в очередь)(если машина с разделяемой памятью) + ещё_что_то (это ещё что-то по моему опыту оказывается не меньше 100 тактов, или больше). А если у нас всё, что мы хотим сделать укладывается в ту же самую одну небольшую операцию над разделяемой памятью, без всякого ещё_что_то. То как обмен сообщенииями может быть быстрее?
Плюс к этому, обмен сообщениями может быть способом остужать данные в кэше. В то время как в модели с разделяемой памятью мы данные не остужаем.
Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
Здравствуйте, Gaperton, Вы писали:
RRM>>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.
RRM>>Вот другой пример: RRM>>Есть некое число s инициализированное нулем. RRM>>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.
RRM>>Можно взглянуть на решение этой задачи с помощью посылки сообщений?
G>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
Он на то и пример, чтобы быть простым.
Дельта зависит как от полученного числа так и от потока. В этом случае пример корректен, хотя получаемые числа и будут недерерминированы, а кто сказал, что это не то, что мы хотели? Потоки знают, что числа будут случайные.
G>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
Почему по очереди? За единицу времени, один поток может пять раз поработать числом, второй шесть, третий вообще не работал с ним. Потом ситуация изменится. Кроме того потокидолдны получать число каждые раз не только для того чтобы потом обновить но и для дальнейшего использования
Здравствуйте, RailRoadMan, Вы писали:
G>>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?
RRM>А ничего, что в примере до этого (ктр про s и q) не сильно больше?
Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
Здравствуйте, Gaperton, Вы писали:
G>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
G>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
G>Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы.
Ну, какой тут будет оптимизированный вариант на сообщениях?
Здравствуйте, remark, Вы писали:
R>Здравствуйте, Gaperton, Вы писали:
G>>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.
G>>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.
G>>Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
R>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>Ну, какой тут будет оптимизированный вариант на сообщениях?
Здравствуйте, RailRoadMan, Вы писали:
R>>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы. R>>Ну, какой тут будет оптимизированный вариант на сообщениях?
RRM>Именно это и имел в виду
Не знаю, что ты имел в виду и какое отношение это имеет к серверу, потому что описал ты отвратительную реализацию генератора случайных чисел.
Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?
Здравствуйте, RailRoadMan, Вы писали:
G>>Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.
RRM>Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
Так как у тебя обработка числа все равно фактически последовательная, ее надо перенести в процесс, который владеет числом, и изменить протокол его взаимодействия с worker-ами. Понятно? Так поступит проектировщик, оперируя моделью на сообщениях. Показать тебе, как это будет выглядеть, не зная задачи, как ты понимаешь — невозможно.
G>Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
Здравствуйте, Gaperton, Вы писали:
RRM>>Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.
G>Так как у тебя обработка числа все равно фактически последовательная, ее надо перенести в процесс, который владеет числом, и изменить протокол его взаимодействия с worker-ами. Понятно? Так поступит проектировщик, оперируя моделью на сообщениях. Показать тебе, как это будет выглядеть, не зная задачи, как ты понимаешь — невозможно.
Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все. Да если это erlang то поток будет очень легким, а если нет? Если у меня системные потоки?
Я же _не_ утрердаю, что передача сообщение плохо или не имеет преимуществ. Нет.
Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Здравствуйте, RailRoadMan, Вы писали:
RRM>>>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками S>>Грамотная реализация очереди будет делать то же самое.
RRM>Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
Опа! Т.е. когда я пишу программу на С++, у меня где-то в объектом файле будут ассемблерные инструкции? Или я не понял мысль?
Здравствуйте, RailRoadMan, Вы писали:
RRM>Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Пример задачи приведи в подтверждение. Что-нибудь кроме задачи эмуляции разделяемой переменной. Может быть, в реальной задаче я вообще без этой разделяемой переменной обойдусь. А я постараюсь.
Здравствуйте, thesz, Вы писали:
G>>Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
T>Вставлю свои пять копеек: http://thesz.mskhug.ru/browser/hiersort/doc/sdd2.pdf
T>Там описано программа умножения матриц для машины динамического потока данных, которая ничего, кроме посылки сообщений, делать не умеет.
ААААААААААА! Вы вместе? Какое это имеет отношение к тому, что разделяемая память имеет (или не имеет) преимущества перед посылкой сообщений на несколько-процессорных и/или многоядерных системах?
Здравствуйте, thesz, Вы писали:
R>>Плюс возможности перегрузок. Представь эта обработка периодическая. И как правильно сказал Gaperton, обмен сообщениями — асинхронный и толерантный к задержкам. Представь 127 ядер непрерывно генерируют эти сообщения для одного агента, успеет он их разгребать? А когда тестировали на нашем 4-ёх ядерном процессоре вроде всё было хорошо...
T>Настоящие программы содержат натуральные способы управления параллелизмом.
T>Выполнение некоторого этапа зависит от результатов выполнения предыдущего. Если это не так, то это взрывной параллелизм, который возникает, например, при умножении матриц (из O(N^2) данных получается O(N^3) операций).
T>В dynamic data flow сообществе с этим отлично умеют бороться. Штука называется throttling, успешно применялась ещё в CM-5, по-моему.
T>Читайте книги, это прикольно.
А теперь и на throttling.
По названию могу предположить, что это что-то типа того, что определяем агента, который вызывает перегрузку и временно отключаем его, и даёт приоритет перегруженному агенту. Если это так, то это ни фига не решение проблемы. Это не что иное как затычка, которая служит для предотвращения съедания всей памяти и падения системы. Но в то же время она снижает производительность системы. Представь система периодически входит в перегрузку и мы периодически отключаем все процессоры кроме одного, что бы разгрузить агнета.
Здравствуйте, remark, Вы писали:
R>зато придирающаяся к словам, и обвиняющая в отсутствии этих самых стёртых аргументов, приплетающая какие-то римские дискуссии, несущая логическую ахинею...
Спасибо, что ты мне напомнил, где я нахожусь и с кем разговариваю. Здесь, как говорил Синклер, обычаи напоминают скорее наш новый Comedy Club, чем старый римский парламент.
R>Против Синклера и thesz то я ничего не имею, но ты, блин, — настоящий тролль.
Ссылку на "логическую ахинею" у меня покажи, тролль. За базар надо отвечать.
T>>Там описано программа умножения матриц для машины динамического потока данных, которая ничего, кроме посылки сообщений, делать не умеет. R>ААААААААААА! Вы вместе? Какое это имеет отношение к тому, что разделяемая память имеет (или не имеет) преимущества перед посылкой сообщений на несколько-процессорных и/или многоядерных системах?
Во-первых, приведён пример программы, подтверждающей слова Gaperton.
Во-вторых, приведены соображения по возможностям управления параллелизмом в системах с посылкой сообщений. Хочешь больше — увеличь что-то, не хватает ресурсов — кое-что урежь.
Ну, и приведён пример (пусть и гипотетический) сильно многоядерной масштабируемой системы. Это третье, и последнее.
И совсем-совсем последнее — с тобой общаются совсем не дураки, а люди, которые были причастны к разработке и оценке многоядерных систем на протяжении трёх лет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
G>>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
G>Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>1) MPI — построена на обмене сообщениями? Да. G>2) OpenMP — построена на общей памяти? Да. G>3) На одной и то же SMP машине, без всяких кластеров, кто быстрее? MPI в подавляющем большинстве случаев, за редкими исключениями.
G>Что не так?
For CG class A, SPMD OpenMP provides a signifcant improvement over both MPI and other OpenMP versions (up to 15% over MPI, and 140% over `naive' OpenMP). For CG class B, MPI and SPMD OpenMP provide similar performance. The gain over `naive' OpenMP remains of about 15%.
For MG, the `optimized' and `improved' loop level versions provide good results (more than 30% better than MPI) for class A. For class B the `improved' version is less effcient than the `optimized' one. The SPMD OpenMP code is competitive with the others OpenMP versions for both classes.
For FT, the `optimized' version outperforms the others including MPI. The improvement comes from a performance tuning of the code based on array shape modifcation. SPMD OpenMP provides a
at 15% improvement over MPI for class A and a non-uniform advantage (up to 25%) over MPI for class B. `Naive' and `improved' versions show a decreasing effciency for class A and reach MPI performance for class B.
For LU, SPMD OpenMP provides only a little advantage (about 15%) over MPI for class B. The other OpenMP implementations show a high negative slope meaning that they do not scale.
Еще там нет таких четких указаний на то, что SPMD OpenMP версия дает лучшую производительность в тесте CG (классы A и B), но по приведенным на рисунке 8 графике видно, что это преимущество на IBM NH2 таки есть.
И это при том, что SPMD OpenMP версия была реализована как адаптированный к OpenMP вариант MPI решения. Так что не факт, что реализованная с изначальным прицелом на OpenMP программа не показала бы еще более высокой скорости работы.
G>Да чо ты говоришь. Что ж в этой статье Conclusion-то такой странный тогда, а?
G>
G>We have demonstrated that it is absolutely not obvious
G>to get better performance with OpenMP codes compared to
G>MPI ones on shared memory machines. The `naive' loop
G>level OpenMP version is simply not competitive compared
G>to MPI and other OpenMP versions. The `improved' loop
G>level version which uses less parallel regions provides very
G>limited performance improvement.
G>...
G>However, SPMD programming
G>style is not enough because 1) the code generation of the
G>compiler for handling thread private arrays may limit signi
G> cantly the performance and 2) the performance of shared
G>memory algorithms for interthread communications may be
G>lower than the one of MPI.
G>...
И еще там же:
The performance analysis (hardware performance
counters and breakdown of the execution time) of our OpenMP
SPMD version of the NAS benchmark demonstrates that we
succeed in getting the same performance as the MPI version
for the computing loops and better performance than the
MPI version for the communication part.
Сюда же нужно добавить интересные оговорки из текста статьи:
While nested parallelism with standard directives may generate effcient code for non-dynamic loop boundaries (typically: dense linear algebra), tests on a Compaq-HP ES40 4-way SMP machine demonstrate for the conjuguate gradient case (featuring dynamic boundaries computations) performance lesser than the one obtained with the sequential code. The analyze of the generated assembly code shows that the compiler produces a much larger executable code than for the singlelevel parallelism, including heavy management cost due to dynamic loop boundaries computation.
и
For our experiments, we have chosen three kernels (CG, MG, FT), and a mini application (LU) among the NAS (NPB) benchmark suite developed at NASA Ames Research Center [13]. We selected them because 1) they are well recognized by the parallel programming community, 2) the MPI version is highly tuned and 3) they feature dierent communication patterns and computation/communication ratio during their executions.
Т.е. круто оптимизированные MPI версии сравниваются с OpenMP компиляторами, которые временами генерят очень корявый код.
Ну и так, к слову:
The IBM SP3 Night Hawk II node features sixteen Power3+ processors at 375 MHz. They are connected to the main memory (up to 16 GB) by a crossbar switch, with a bandwidth up to 14.2 GB/s. The cache for each processor is 16KB of L1 and 8MB for the L2. The programs are compiled with XLF 7.1 using the options: -O3 -bmaxdata:0x80000000 -qcache=auto -qarch=auto -qtune=auto -qmaxmem=-1 -qunroll -qnosave.
The programs are executed via the LoadLeveler proprietary queuing system. We use the shared memory version of the MPI library in order to get the best performance.
У разделяемой памяти настолько нет никаких преимуществ, что иследователи из упомянутой статьи используют реализванную на основе разделяемой памяти MPI библиотеку специально для получения наилучшей производительности.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
А на каком месте решение на основе передачи сообщений?
Здравствуйте, Константин Б., Вы писали:
E>>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
КБ>А на каком месте решение на основе передачи сообщений?
Среди результатов WideFinder-2 я вообще не видел Erlang-а. Был там какой-то вариант на Scala, может быть со ScalaActors.
Решения на Erlang-е были в WideFinder-1: http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
Лучший вариант на Erlang в два раза медленее победителя на Perl-е. Но первый WideFinder был не очень показательным, так что вряд ли имеет смысл на него смотреть.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ.
Просто-напросто, модель OpenMP не подходит для многих задач.
Что тут такого удивительного, не понимаю?
OpenMP задумывался для реализации неинтрузивного параллелизма в С-шных программах. Естественно, его примитивы поэтому оказались не самыми оптимальными для многих условий. Зато на нём писать легко.
Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.
Здравствуйте, eao197, Вы писали:
G>>>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз? RRM>>>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
G>>Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
E>Есть такая забавная пенисометрия -- WideFinder-2. И ее результаты здесь. На первом месте решение на C++, которое работает на основе разделяемой памяти.
Я нихрена не понимаю Руби, и разбираться с ним ради теста — лень. Если ты дашб нормальное объяснение — могу прогу сделать. Правда, в Эрланге медленный ввод вывод, и поэтому он обычно проигрывает в этих тестах Питону. Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
Насколько я понял, это задача на анализ файла. Параллелится на основе сообщений тривиально на любом языке — применяя поток данных и "ленивые вычисления". Вот решение в лоб:
1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.
2. воркеры завершают парсинг, вычисляя статистику.
3. воркеры посылают результат в тот процесс, который хранит каждую статистику. Ну, типа топ 10 там отбирает, и все .
И все. Простая труба. Не вижу никаких сложностей. И не важно, на Erlang это будет, или на С++, С# или F#. Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.
Кстати, я подозреваю, что С# и F# войдут в топ на этом тесте, если применять обмен сообщениями — они быстры, и у них хороший аллокатор и сборщик мусора, так что там будет легко избежать копирования сообщений при передаче, и не будет лишних расходов на подсчет ссылок.
Здравствуйте, Gaperton, Вы писали:
G>Я нихрена не понимаю Руби, и разбираться с ним ради теста — лень.
Изначально все пошло из этого:
In my Finding Things chapter of Beautiful Code, the first complete program is a little Ruby script that reads the ongoing Apache logfile and figures out which articles have been fetched the most. It’s a classic example of the culture, born in Awk, perfected in Perl, of getting useful work done by combining regular expressions and hash tables. I want to figure out how to write an equivalent program that runs fast on modern CPUs with low clock rates but many cores; this is the Wide Finder project.
В WideFinder-2 добавились следующие требования:
Based on discussion on this page, I have proposed, and have heard no real objections, that we adopt a suggestion originally entitled "normal HTML report", as follows:
Report the top 10 URIs, by hits, which are articles (much the same regex as before)
Report the top 10 URIs of any kind by aggregate byte count downloaded
Report the top 10 URIs of any kind that returned 404 Not Found
Report the top 10 client addresses that fetched hit-counted articles
Report the top 10 referrers for hit-counted articles
G>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
Питон там давно порвали на британский флаг.
G>1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.
Ага, вычитывает блоки по несколько Mb, а затем высылает их другим процессам/нитям.
А если не высылает, а передает указатель на преаллоцированный буфер, то что это такое, как не использование разделяемой памяти?
G>Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.
Победитель просто использует boost::thread без очередей сообщений и аллокатора.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, thesz, Вы писали:
C>>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно. T>Это как это так это вот?
Это когда несколько потоков одновременно работают с одними разделяемыми данными и совместно их меняют.
T>Неудобно с какой точки зрения?
Нужно, фактически, создавать абстракцию разделяемой памяти с помощью сообщений.
T>Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений.
Это далеко не всегда возможно, да и вообще — это тупой подход.
Императивные программы просто надо специально под многопоточность рассчитывать.
Здравствуйте, Gaperton, Вы писали:
G>>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.
E>>Питон там давно порвали на британский флаг.
G>C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.
Тогда возникает вопрос:
Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает.
под "отлично" здесь понимается "правильно, но в четыре раза медленее"?
G>Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.
Видимо, у нас разные представления о разделяемой памяти и задачах, которые решаются с помощью передачи сообщений.
G>В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются...
Если только процессы не работают на разных нодах.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
AVK>Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.
Здравствуйте, Gaperton, Вы писали:
C>>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина. G>Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
Это понятно. Но для многих задач вполне приемлимо.
Умножение матриц на MPI, кстати, тоже относится к выгребанию ложками тоннеля под ЛаМаншем.
C>>>Проблема с message passing в том, что работать с большими массивами меняющихся данных так может быть очень неудобно. T>>Это как это так это вот? C>Это когда несколько потоков одновременно работают с одними разделяемыми данными и совместно их меняют.
Как ни странно, но и в этом случае очень часто может быть выявлен высокий параллелизм. И даже зависящий от параметров задачи (O(N) супротив O(1) для ILP).
T>>Неудобно с какой точки зрения? C>Нужно, фактически, создавать абстракцию разделяемой памяти с помощью сообщений.
Не вижу в этом ничего дурного.
T>>Если что, то анализ потока данных с учётом пространства выполнения программы может помочь в автоматическом преобразовании императивных программ в программы с посылкой сообщений. C>Это далеко не всегда возможно, да и вообще — это тупой подход.
Скажу так: это возможно во всех практически интересных случаях.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
C>>>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина. G>>Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем . C>Это понятно. Но для многих задач вполне приемлимо.
На практике в сложной программе добиться хорошего результата оперируя низкоуровневой семафорной моделью очень сложно — это занятие для мазохистов. Хоаровский wait-notify уже гораздо менее error-prone (у Хоара он, правда, как-то по другому назывался, но суть та же). Но я предпочту применять асинхронный обмен сообщениями даже в программах на С++. Удобства существенно превосходят кажущиеся недостатки.
Здесь очень простая вещь, как с ассемблером — теоретически, ты можешь обойти компилятор. На практике — ты проиграешь в производительности, как только задача становится достаточно сложна, по одной простой причине — у тебя не хватит времени его обойти.
C>Умножение матриц на MPI, кстати, тоже относится к выгребанию ложками тоннеля под ЛаМаншем.
Не без того, но — это свойство умножения матриц как задачи, а не привнесенное MPI. Тот же самый блочный алгоритм умножения матриц, который применяется в реализациях на MPI, рулит и на SMP с разделяемой памятью, вообще-то. Он лучше по целому ряду параметров — например, он гуманнее относится к кэшам, и он минимизирует издержки синхронихации.
Локальность данных — она фундаментальна, от нее легчает не только MPI и системам на основе передачи сообщений, но и вообще любой системе с иерархией памяти.
Кстати, умножение матриц в смысле ЛаМанша меркнет по сравнению с взятием обратной матрицы или решением СЛАУ.
Здравствуйте, remark, Вы писали:
R>Вообще, обычно, у меня хорошо с отличением и понимаем шуток... Но ты ставишь меня просто в тупик... R>Хммм... Ну на самом деле если я посмеюсь: ХА-ХА-ХА-ХА-ХА [небольшой отдых] ХА-ХА-ХА-ХА-ХА R>то это будет релевантно под оба варианта: если это шутка и нет.
Да? А по-моему, это больше похоже на иллюстрацию к детской поговорке "смех без причины — признак дурачины".
R>Lock-free НЕ имеет никакого отношения ни к производительности, ни к масштабируемости, Lock-free — это ТОЛЬКО о гарантиях системного прогресса: R>http://rsdn.ru/Forum/message/2930849.1.aspx
Ты правда считаешь себя таким авторитетом в этой теме, что считаешь допустимым ссылаться на собственные посты в форуме как на аргумент в дискуссии?
Тесты показывают преимущество по скорости очередей, написанных в lock-free стиле. Читайте книги, это прикольно. Статьи тоже ничего.
R>Кстати, какой именно алгоритм lock-free очереди ты имеешь в виду?
Поищи сам. Лень.
G>>Хреновый у тебя пример, на самом деле.
R>Хреновый для чего?
У тебя пример, который не имеет отношения ни к достоинствам ни к недостаткам ни передачи сообщений, ни разделяемой памяти. Это просто нерелевантный хреновый пример.
Здравствуйте, RailRoadMan, Вы писали: RRM>Опа! Т.е. у нас где-то в очереди будет разделяемый спинлок? Или я не понял мысль?
А то. Поскольку x86 не предлагает низкоуровневых конструкций типа "очередь", то любая реализация очереди так или иначе будет использовать что-то низкоуровневое. Совершенно необязательно при этом использовать тяжелые примитивы и прыгать в режим ядра. Спинлоки и прочие interlocked рулят.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали: G>Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?
Это, кстати, мне до боли напоминает "теорему существования" (c) P.Dvorkin. Там, где он "доказывал", что раз все языки высокого уровня компилируются в ассемблер, значит программа на ассемблере гарантированно не медленнее никакой программы на ЯВУ. Здесь только народ поаккуратнее, и не пытается протолкнуть аналогичное доказательство
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
RRM>>Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все. S>Видишь ли в чем дело — атомик функции хорошо работают тогда, когда память реально разделена. Ну там, к примеру, речь идет о нескольких ядрах с общим кэшем. S>Как только это предположение перестает выполняться, всё становится очень плохо. S>Тот "спец поток", который тебе кажется лишним, лучше описывает ситуацию с NUMA.
Про NUMA естественно все правильно — можно чуть раскрыть тему, и добавить, что данный подход хорошо учитывает локальность данных и иерархичность памяти, он еще позволяет писать программы, толерантные к высокой латентности операций обмена данными. Просто за счет того, что операции асинхронны, в то время как при стиле программирования с разделяемой мутабельной памятью программист полагается на синхронные операции с ней.
Но это объяснять бессмысленно, ИМХО, потому что причина спора, мне кажется, в другом. Человек не понимает, что сама структура его программы будет другой, если решать ее в терминах "актеров". И поэтому упорно предлагает в качестве задачи эмулировать мутабельную разделяемую переменную . Все это усугубляется тем, что вся тройка товарищей не делает разницы между разделяемой памятью и моделями синхронизации. Как нам с тобой известно , при использовании разделяемой памяти можно насчитать как минимум штуки 4 разных моделей синхронизации, они же думают, что все ограничивается семафорной моделью, посему и ставят этот знак равенства.
В этих условиях, объяснить что-либо им сложно — они просто не понимают в принципе, что такое "модель синхронизации" — примеров им не хватает для того чтобы эту абстракцию понять (посмотрели бы хотя бы на wait-notify, им уже было бы проще). А чтобы что-то понять, надо для начала признать, что ты что-то не понимаешь — теперь, когда они вошли в polemic mode — им будет очень тяжело это признать.
Здравствуйте, AndrewVK, Вы писали:
G>>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.
AVK>Плохо формализуемо. И для особо сложных случаев есть специальный пункт о том, что модератор может забанить на свое усмотрение даже за то, что в правилах не прописано. Есть все таки определенная прелесть в диктатуре
Ничо, пусть имеет статус не запретительный, а рекомендательный. Мне кажется, это хорошая идея, Андрей.
Здравствуйте, Gaperton, Вы писали:
G>Так вот, gcc одно умножение заряжает родное, а второе умножение в это время мутит на сдвигах-сложениях. Потому, что так быстрее. Я бы посмотрел на программиста на ассемблере, который попробует обойти gcc под простейший MIPS .
Кстати, о микроконтроллерах. У кого-то могут остаться иллюзии, что они смогут обогнать компилятор, программируя на ассемблере 8 или 16 битные микроконтроллеры, вроде MSP430 или AVR. Так вот, смогут, если только компилятор не называется IAR. Который дает до 40% выигрыша по сравнению с gcc.
Здравствуйте, Gaperton, Вы писали:
G>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?
Эта статья не может быть контрпримером, поскольку, если бы ты ее прочитал, то увидел бы, что там только в одном случае решение OpenMP SMPD чуть проигрывает MPI. В остальных случаях -- выигрывает, о чем в конце статьи авторы и заявили. Более подробно см. статью или выдержки
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?
E>Эта статья не может быть контрпримером, поскольку, если бы ты ее прочитал, то увидел бы, что там только в одном случае решение OpenMP SMPD чуть проигрывает MPI. В остальных случаях -- выигрывает, о чем в конце статьи авторы и заявили. Более подробно см. статью или выдержки
Для того, чтобы понять, может эта статья может быть контрпримером, или нет, достаточно внимательно прочитать одну ее часть — Conclusion, выдержки из которого я приводил. Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса. Мы читать хорошо умеем, уважаемый коллега? Специально для тебя еще раз привожу, и выделяю жирным ключевые фразы, чтобы заметнее были.
We have demonstrated that it is absolutely not obvious
to get better performance with OpenMP codes compared to
MPI ones on shared memory machines. The `naive' loop
level OpenMP version is simply not competitive compared
to MPI and other OpenMP versions. The `improved' loop
level version which uses less parallel regions provides very
limited performance improvement.
Это не опровержение тезиса?
However, SPMD programming
style is not enough because 1) the code generation of the
compiler for handling thread private arrays may limit signi
cantly the performance and 2) the performance of shared
memory algorithms for interthread communications may be
lower than the one of MPI.
Это не опровержение тезиса?
И последнее — тебе правда так сильно докопаться хочется, да?
Здравствуйте, Gaperton, Вы писали:
G>Для того, чтобы понять, может эта статья может быть контрпримером, или нет, достаточно внимательно прочитать одну ее часть — Conclusion, выдержки из которого я приводил.
Т.е. ты статью не читал, но в качестве примера привел.
G>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.
Конечно не очевидно. Плохая программа на OpenMP сольет крутооптимизированной на MPI (а именно такая рассматривается в статье). Это и ежу понятно, даже классическое образование не нужно. Зато оптимизированная программа на OpenMP обгоняет такую же на MPI. О чем свидетельствуют как графики в самой статье, так и последний абзац того же Conclusion (да, даже Conclusion стоило прочитать полностью).
Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.
Более того, как раз третья, самая быстрая, программа, именуемая OpenMP SPMD, является прямым отображением MPI-ной версии на OpenMP. Т.е. люди взяли те же принципы, те же алгоритмы, но заменили обмен сообщениями на работу с общей памятью. И что получили -- сумарное повышение производительности (такую же производительность на вычислениях и большую пропускную способность на коммуникациях). Что и согласуется как раз с предположениями remark-а о более низких накладных расходах при общей памяти.
G>Это не опровержение тезиса?
Неа. Утвеждение may be ни в коей мере не может быть опровержением, ни утверждением.
G>И последнее — тебе правда так сильно докопаться хочется, да?
Когда ты громогласно утверждаешь, что по заключении данной статьи выходит, что OpenMP сосет, а оказывается, что все совсем не так...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
G>>И последнее — тебе правда так сильно докопаться хочется, да?
E>Когда ты громогласно утверждаешь, что по заключении данной статьи выходит, что OpenMP сосет, а оказывается, что все совсем не так...
Вот на это в статье глянь.
Table One: Results for the OpenMP/MPI benchmarks. (winning test is in bold)
И давай я посмотрю, что ты сейчас будешь говорить. Давай, начинай сеанс особой, форумной магии — делай из этой статьи вывод, что OpenMP показывает убедительный отрыв. Ну, например, скажи на всякий случай, что Гапертон статью опять не читал — это никогда не вредно сказать, зато очень внушает. Ну добавь, что и эта статья не может быть опровержением тезиса ремарка, ведь в тесте "FT" OpenMP быстрее на целых 69%.
А то, что OpenMP, например, в тесте "IS" не медленнее, а С.О.С.Е.Т. (да именно так) на целых 139% — это, конечно, не имеет никакого отношения к делу, и никак не может служить опровержением тезисов remark, который установил безусловные и неоспоримые преимущества разделяемой памяти над передачей сообщений, не проводя никаких тестов, не читая статей, и не делая поиска в интернете . Да здрав-ству-ет ментальное сканирование, результаты которого не опровергнуть ничем! Ура!
Здравствуйте, Sinclair, Вы писали:
S>Лично мне как раз интересно, есть ли способ выбрать одну модель многозадачности, которая бы показывала оптимальную производительность на широком классе задач.
There is no silver bullet yet
Все зависит от того, какой класс задач ты рассматриваешь. Я их разделяю на distributed concurrency и non-distributed concurrency. Для первого я бы однозначно выбрал erlang или схожую message-passing actor model.
Для второго, конечно, тоже можно это же самое выбрать, более того erlang только такую модель и предоставляет. Но лично мне это на данный момент кажется неоправданным по нескольким причинам: усложненная модель программирования, снижение эффективности и снижение гибкости. Поэтому я бы выбрал immutability by default, agents & STM (см clojure).
Lisp is not dead. It’s just the URL that has changed: http://clojure.org
Да? А наши источники говорят, что я давно его выиграл, только кое-кому очень не хочется этого признавать.
S>З.Ы.: Если серьезно, то незачем подкалывать ремарка. Он честно старается выяснить истину. Позитивным моментом в этой драке на табуретках является то, что вы притаскиваете интересные ссылки, до которых большинство читателей бы сами не дорыли. А вот взаимное ущемление самолюбий — момент безусловно негативный.
"Вы" притаскиваете? Я что-то пропустил, помимо Comedy Club в эту субботу? Прости, можно посмотреть на какие-либо ссылки remark, которые он давал не на свои посты?
Он "честно" стараетя выяснить истину, не соблюдая при этом правила автора тезиса? Гы. Гы. Гы.
S>И сможет ли "очевидно тормозной обмен сообщениями" порвать "интуитивно быструю" разделяемую память.
Ну, мне кажется, ты получил ответ на этот вопрос из последней моей ссылки.
Здравствуйте, yumi, Вы писали:
Y>Для второго, конечно, тоже можно это же самое выбрать, более того erlang только такую модель и предоставляет. Но лично мне это на данный момент кажется неоправданным по нескольким причинам: усложненная модель программирования, снижение эффективности и снижение гибкости. Поэтому я бы выбрал immutability by default, agents & STM (см clojure).
В Эрланге, на самом деле, есть разделяемая память в виде таблиц ets, и mnesia, построенная на их базе. Дело в том, что Эрланг по другим своим характеристикам не подходит для всех задач, его целесообразно в паре с С++ применять.
А в clojure, по всей видимости, нет легких потоков, они тяжелые, что не позволяет полноценно использовать агентов. Хотя, в этом смысле он не хуже остальных языков.
Здравствуйте, Sinclair, Вы писали:
S>Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику.
Работы по автоматическому выводу типов и "мягким системам типов" стирают четкую грань между статикой и динамикой. Если раньше "статика" была фактически синонимом понятия "аннотации типов", то теперь не так. Теперь разница становится все более тонка и неуловима, а динамика — быстрее и надежнее.
Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Вот в "сообщениях" — они есть. Это асинхронность, именно это свойство позволяет писать почти линейно масштабируемые программы в случае латентных каналов данных. И именно за счет этого свойства MPI — реализации иногда обходят OpenMP. У OpenMP действительно меньшие оверхэд на передачу данных, чем в MPI, но при этом существенно хуже масштабируемость.
А ведь в MPI зело дубово сделано — по одному оперсистемному процессу пускается на аппаратный поток, он на одной кросспроцессной передаче теряет дофига, можно сделать сильно лучше.
При современных тенденциях в области многоядерных процов, я бы поставил на asynchronous message-passing. На четырехкристальном Нехалемном сервере, где должно быть в районе 64 аппаратных потоков, OpenMP будет сосать соску.
G>Кстати, о микроконтроллерах. У кого-то могут остаться иллюзии, что они смогут обогнать компилятор, программируя на ассемблере 8 или 16 битные микроконтроллеры, вроде MSP430 или AVR. Так вот, смогут, если только компилятор не называется IAR. Который дает до 40% выигрыша по сравнению с gcc.
gcc плохо работает с неортогональными архитектурами.
Да вообще никак не работает, если честно. Результат сразу можно выкидывать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
S>>Теперь мне интересно, сможет ли "очевидно тормозная" динамика порвать "интуитивно быструю" статику. G>Работы по автоматическому выводу типов и "мягким системам типов" стирают четкую грань между статикой и динамикой.
А зависимые типы снова её рисуют (там вывод невозможен).
G> Если раньше "статика" была фактически синонимом понятия "аннотации типов", то теперь не так. Теперь разница становится все более тонка и неуловима, а динамика — быстрее и надежнее.
Зависимые типы снова воздвигают знамя аннотации типов, заново увеличивают пропасть и задают новые границы по быстроте и надёжности.
Или хотя бы по надёжности.
G>Прям штоб "порвать" — сможет только в том случае, если от динамичности или статичности самой по себе мало что зависит, и все определяют другие факторы, скажем, качество рантайма или алгоритм. Строго говоря, динамика не имеет выраженных преимуществ такого рода, на которых можно было бы ловко сыграть и порвать статику хоть где-то. Или я их упускаю.
Ж.Е.Л.Е.З.О.
Которое Hardware в VHDL.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, AndrewVK, Вы писали:
E>>Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества.
AVK>Прокомментируй: AVK>
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
1. Я не могу отвечать за remark-a.
2. Лично я сомневаюсь в оценке "несколько порядков". Имхо, более вероятна разница в один порядок, максимум.
3. Я воспринимаю эту фразу в том же смысле: "в некоторых случаях обмен сообщениями на любых очередях останется медленее на несколько порядков", но не в 100% случаев.
4. В качестве примера такой ситуации я могу привести гипотетический пример с маршрутизацией звонков/sms по номерам телефонов: имеется большая таблица или специальное дерево, с помощью которой по префиксу номера адресата определяется оператор, которому принадлежит адресат. Эта таблица может совместно использоваться несколькими потоками-маршрутизаторами (может быть даже несколькими десятками таких потоков) -- они обращаются к ней только для чтения. И имеется один или два потока, которые на основании какой-то внешней информации время от времени вносят изменения в данную таблицу. Например, если процент успешно обработанных пакетов в канале связи с каким-то операторам падает ниже некоторого уровня, то его трафик переадресуется через других операторов. В данном случае оформление таблицы маршрутизации в виде агента, взаимодействие с которым выполняется только в режиме асинхронного обмена сообщениями, может повысить накладные расходы по сравнению с разделяемой памятью в разы. Только за счет того, что заявки должны складироваться в какой-то очереди, извлекаться оттуда, обрабатываться, ответ должен сохраняться в какой-то другой очереди и т.д.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AVK>>Прокомментируй: AVK>>
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
E>3. Я воспринимаю эту фразу в том же смысле: "в некоторых случаях обмен сообщениями на любых очередях останется медленее на несколько порядков", но не в 100% случаев.
Анализ ДНК показал, что сперма на синем платье – это сперма Билла Клинтона. 17 августа президент дал показания суду. Его выступление можно считать шедевром юридической казуистики – недаром же Клинтон долго время работал адвокатом и прокурором. Вот, например, знаменитая цитата из его показаний:
"Это зависит от того, какой смысл вкладывать в слово "есть". Если... если он... если "есть" означает "есть и никогда не было", то это не... то это одно. Если же это значит "нет", то это было совершенно правдивое заявление".
Ну прям чистый Comedy Club, прав Синклер. Тесты не показывают разницы даже на двоичный порядок, при этом, ты позволяешь себе "сомневаться" в том, что разница на два порядка, и тебе, недавно читавшем эти тесты, кажется "более вероятным" разница в один порядок. Еще пиши!
E>1. Я не могу отвечать за remark-a.
Ты уже взялся отвечать за remark-а. Теперь отвечай за себя. Знаешь ведь, как оно бывает .
Здравствуйте, AndrewVK, Вы писали:
E>>1. Я не могу отвечать за remark-a.
AVK>Ну так и не надо вообще за него тогда впрягаться.
Если мои сообщения здесь не желательны -- то какие проблемы, пусть модераторы меня забанят.
В противном случае хочу еще раз сказать, что я впрягся не за remark-а, а из-за статьи, которая, по словам Gaperton-а, доказывает, что OpenMP сливает MPI. Хотя даже разглядывание картинок в этой статье доказывает, что это не так.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>If you want your application to be portable on clusters and SMP machines, MPI might be the
E>best solution. If, however, you do not envision using more than eight or sixteen cores, then
E>OpenMP is probably one of your best choices if the benchmarks point in that direction. From a
E>conceptual standpoint, those with experience in both paradigms state that using OpenMP and
E>MPI provide a similar learning curve and nuance level. There are no shortcuts or free lunches
E>with OpenMP, or MPI for that matter.
E>Так что обе статьи говорят вполне ожидаемые вещи: получение преимуществ с помощью OpenMP вовсе не гарантировано (не очевидно, если тебе так больше нравится), но временами OpenMP будет наилучшим выбором. E>Что полностью соответствует утверждению remark-а о том, что разделяемая память будет иметь преимущества в некоторых случаях.
Надо отметить, что эти времена уходят, поскольку мы движемся в сторону using more than eight or sixteen cores.
E>Соответственно, если такие случаи есть (а они есть, судя по результатам измерений), то в этих случаях механизм обмена сообщениями лишается преимуществ, которые имеет разделяемая память. О чем опять-таки remark и говорил, как о более честном, с его точки зрения, освящении достоинств обмена сообщениями.
Разделяемая память поддержана аппаратно (да-да! поддержана аппаратно), передача сообщений — нет. Посмотрим, что будет, если будет хотя бы поддержка обоих.
E>То, что это один компилятор ничего не решает. Решает качество OpenMP компилятора. Как тебе указал твой соратник, Сергей Зефиров, качество gcc не сильно выше плинтуса.
Не сильно выше плинтуса в случае неортогональных архитектур вроде DSP или старых микроконтроллеров.
На других архитектурах gcc показывает себя вполне достойно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Разделяемая память поддержана аппаратно (да-да! поддержана аппаратно), передача сообщений — нет. Посмотрим, что будет, если будет хотя бы поддержка обоих.
А есть примеры как поддержка сообщений может быть поддержана аппаратно?
Re[37]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Именно. Разные потоки видят одно и то же дерево.
S>>В противном случае каждому worker придется перед началом каждой транзакции выполнять копирование ссылки на корень, что опять же дорого. Это эквивалентно постоянной рассылке сообщения "корень дерева теперь здесь".
E>Т.е. ты утверждаешь, что один atomic_read будет эквивалентен мультикастовой рассылке сообщения?
Ну почему один. Мы говорим об N atomic_read по количеству workeroв. E>С выбором получателей, блокировкой очередей, вставкой в N очередей экземпляра сообщения, разблокированием очередей, блокированием очередей на стороне приемника, сканирования очереди на предмет выбора подходящего сообщения (если используется отличная от FIFO политика обработки сообщений получателем). E>Правильно я тебя понимаю?
Не совсем.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, thesz, Вы писали:
T>Надо отметить, что эти времена уходят, поскольку мы движемся в сторону using more than eight or sixteen cores.
Думаю, что не ошибусь, если скажу, что очень многие разработчики пока не занимались оптимизацией своих программ даже для 2-х ядерных процессоров.
E>>То, что это один компилятор ничего не решает. Решает качество OpenMP компилятора. Как тебе указал твой соратник, Сергей Зефиров, качество gcc не сильно выше плинтуса.
T>Не сильно выше плинтуса в случае неортогональных архитектур вроде DSP или старых микроконтроллеров.
T>На других архитектурах gcc показывает себя вполне достойно.
Здравствуйте, Sinclair, Вы писали:
E>>Т.е. ты утверждаешь, что один atomic_read будет эквивалентен мультикастовой рассылке сообщения? S>Ну почему один. Мы говорим об N atomic_read по количеству workeroв.
Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений. Что не может быть дешевле одного atomic_read-а. Так что в лучшем (для очередей сообщений) случае производительность окажется баш на баш. Но все это без учета других накладных расходов, связанных с очередями сообщений.
E>>С выбором получателей, блокировкой очередей, вставкой в N очередей экземпляра сообщения, разблокированием очередей, блокированием очередей на стороне приемника, сканирования очереди на предмет выбора подходящего сообщения (если используется отличная от FIFO политика обработки сообщений получателем). E>>Правильно я тебя понимаю? S>Не совсем.
Мог бы ты свою точку зрения раскрыть?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[37]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, DK3981, Вы писали:
DK>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
Этот протокол нужен в любом случае.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[38]: пример eao197: "сообщения" рвут "разделяемую память"
DK>>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
E>Этот протокол нужен в любом случае.
Если модифицирующий поток один, то ему не с кем будет конкурировать.
... << RSDN@Home 1.2.0 alpha rev. 728>>
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Это автоматически обязывает worker-а работать с очередями сообщений. E>Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри.
Не очень понятно, какие сообщения здесь имеются в виду. Если не те, которые в очереди — то неважно. В любом случае worker получает задание из очереди — ему просто неоткуда его больше получить. Ведь разделяемой памяти нет. Мы говорим о случае, когда модификаций дерева мало по сравнению с чтениями.
Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
Никаких проблем.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Это автоматически обязывает worker-а работать с очередями сообщений. E>>Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри. S>Не очень понятно, какие сообщения здесь имеются в виду.
Речь о заданиях (транзакциях). Например, worker может стартовать с пакетом из 100K sms, для каждой из которых нужно выбрать маршрут.
S>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше. S>Никаких проблем.
Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
T>>Надо отметить, что эти времена уходят, поскольку мы движемся в сторону using more than eight or sixteen cores. E>Думаю, что не ошибусь, если скажу, что очень многие разработчики пока не занимались оптимизацией своих программ даже для 2-х ядерных процессоров.
Здравствуйте, Sinclair, Вы писали:
S>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?
now playing: Gimikk — Dancing On The Stars
Re[44]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
S>>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше. S>>>Никаких проблем. E>>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.
T>Поддержи очередь аппаратно.
Насколько мне известно, программистам сейчас приходится с большим трудом находить качественные реализации быстрых конкурентных очередей и т.п. в виде готовых широкораспространенных библиотек. Из-за чего эти очереди реализуются каждым разработчиком снова и снова -- NIH синдром процветает. Теперь ты предлагаешь разработчикам еще и аппаратную поддержку очередей делать самим?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
V>RSDN как обычно жжот. Спорят все команды. Одна команда воображает, будто вторая говорит, что разделяемая память всегда эффективнее сообщений, и, соответственно опровергает его. Вторая команда воображает, что первая утверждает, что сообщения всегда эффективнее разделяемой памяти и тоже опровергает его. Единственное в чем все спорщики сходятся — это в игнорировании аргументов друг друга
E>>>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read. T>>Поддержи очередь аппаратно. E>Насколько мне известно, программистам сейчас приходится с большим трудом находить качественные реализации быстрых конкурентных очередей и т.п. в виде готовых широкораспространенных библиотек. Из-за чего эти очереди реализуются каждым разработчиком снова и снова -- NIH синдром процветает. Теперь ты предлагаешь разработчикам еще и аппаратную поддержку очередей делать самим?
Нет.
Разделяемая память у тебя уже есть, и она реализована аппаратно.
(на всякий случай — и реализована на аппаратных сообщениях, пусть и ограниченных)
Как только ты реализуешь аппаратно очередь, стоимость операций будет примерно одинаковой.
Сейчас у тебя это не так, чем ты и пользуешься.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[43]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
G>>2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.
E>Есть такие услуги у ряда контент-провайдеров -- массовые рассылки sms по результатам какого-то события, как-то начисление зарплаты, результаты футбольных матчей, объявление курсов валют, прогнозы погоды и т.д. При их организации решаются задачи быстрой обработки большого числа sms (от нескольких сотен тысяч штук до нескольких миллионов).
E>Достаточно?
А, ты об этой маленькой фитюльке, которая в колл-центрах и контакт-центрах проходит под собирательным названием "outbound campaign". Ну какой же это раутер. Фигня это полная, а не раутер.
E>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?
Что за кривляния. Хочешь — спрашивай, я тебе отвечу. Я не понял, ты меня напугать штоли хотел?
Re[40]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
DK>>>>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
E>>>Этот протокол нужен в любом случае.
DK>>Если модифицирующий поток один, то ему не с кем будет конкурировать.
E>Я о другом: если есть несколько потоков-модификаторов, то им потребуется взаимный протокол захвата разделяемых данных для их модификации в любом из случаев -- будет ли доступ к общей таблице осуществляться через разделяемые переменные или через уведомления.
Весь "протокол" сводится к посылке сообщения процессу-модификатору, который владеет деревом. Все. Никакого "взаимного протокола захвата" делать в случае актеров на одном компе не надо, это глупость.
E>Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.
Это как раз очень важно, потому что работая через "разделяемую переменную" ты налетаешь на примитив синхронизации на каждом чтении. И на синхронное взаимодействие, требующее "рандеву" — все должны ждать, когда ты ее изменишь, в то время как в случае очередей никто никого ждать не должен, и взаимодействие асинхронно. Это ты еще не принимаешь во внимание обработку входящих сообщений, которые тебе надо отраутить.
Чтобы добиться таких же характеристик, как с решением на актерах, не изображая при этом актеров, тебе придется через задний проход реализовать их на семафорной модели, проиграв в сложности, и не выиграв ничего в производительности. Так как ты не владеешь дизайн-идиомой актеров, то ты во многих случаях просто не додумаешься до такого решения, как привел я.
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
E>>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений. S>>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы. S>>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".
E>Это автоматически обязывает worker-а работать с очередями сообщений. Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри.
"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.
Re[44]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>А, ты об этой маленькой фитюльке, которая в колл-центрах и контакт-центрах проходит под собирательным названием "outbound campaign". Ну какой же это раутер. Фигня это полная, а не раутер.
Как и 7% преимущества в скорости. Известная песня.
E>>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?
G>Что за кривляния. Хочешь — спрашивай, я тебе отвечу.
Ответь. Освети свой опыт разработки телекоммуникационных систем на Erlang-е.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>А, ты об этой маленькой фитюльке, которая в колл-центрах и контакт-центрах проходит под собирательным названием "outbound campaign". Ну какой же это раутер. Фигня это полная, а не раутер.
E>Как и 7% преимущества в скорости. Известная песня.
7% преимущества в скорости — это и правда фигня полная (особенно по сравнению с проигрышем OpenMP на примерно 140% в одном тесте, что ты предпочел забыть), что верно так же, как и то, что outbound — рассылка ни разу не раутер, а маленькая частная задача контакт-центра.
E>>>Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?
G>>Что за кривляния. Хочешь — спрашивай, я тебе отвечу.
E>Ответь. Освети свой опыт разработки телекоммуникационных систем на Erlang-е.
Давай, освещу. Хоть это к делу и не относится.
infratel.com. Там я был некоторое время директором разработки, пока не уволился делать свой стартап. Так что как устроен софт коллцентра, и телефонные софтсвитчи, я представляю себе довольно неплохо.
Системе 8 лет, это колцентр и АТС, написанная на С++. На эрланге, понятное дело, никто переписывать миллион строк кода там не будет, это нельзя сделать за разумное время, однако в перспективную архитектуру мы заложили "легкие потоки" с асинхронными сообщениями как в Эрланге. Потому, что по общему мнению, это удобно, просто в применении, и на практике в данных задачах данная модель дает выигрышь в производительности. "Телефонные" сервера — это задача массового параллелизма, и по доброй воле предпочтет иметь дело с явной низкоуровневой синхронизацией в таких задачах только идиот. Ну, я хотел сказать, очень упорный и трудолюбивый человек.
Задача, которую ты описал — это малюсенькая часть функциональности контакт-центра. Которая может быть сделана на коленке вообще без контакт-центра, и превращается в интересный фрагмент требований к ядру телефонии, будучи рассмотрена в контексте всей задачи. Естественно, производительность в данной задаче упрется в телефонию или сеть, и закачка больших пакетов в память для минимизации задержек не даст тебе почти ничего. Хотя, как я тебе показал, решая данную задачу на сообщениях, можно выиграть по сравнению с традиционной реализацией на разделяемой мутабельной памяти.
Причина? Если ты дозваниваешся по списку, то тебе просто не надо дозваниваться до большего количества людей, чем у тебя есть в наличии исходящих линий, которые стоят денег. Если ты делаешь рассылку, то тебя в подавляющем большинстве случаев не особо волнует, насколько быстро она пройдет — за час, или полчаса. Задачу целесообразно пустить с низким приоритетом.
Тем более, что в реальных условиях у тебя база для outbound кампаний часто берется из CRM-системы, а так как этот процесс далеко не моментальный, тебе совершенно не имеет смысла выполнять группировок. Если ты, конечно, не спам-центр, который дает услуги спам-рассылок (этим не занимался, но что-то мне подсказывает, что в этом случае ты все равно упрешься в исходящий канал, а не в примитивы синхронизации).
На Эрланге я телефонных раутеров не писал, но знаю одних парней, кто это делал. Это Эрикссон. AXD301. Тем не менее задачами телефонии интересовался, как, наверное, многие из тех, кто интересовался Эрлангом. Эрланг — "телефонный" язык. Хотя, вообще-то, говоря про Эрлангистов и раутеры, я тебе просто подкалывал, не имея в виду ничего серьезного. Ты не обижайся.
Re[43]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.
E>Классическое образование, надо полагать, заставляет думать, что доступ к разделяемым данным можно сделать только на семафорах. Ничего не поделать, у классического образования так же есть недостатки.
Извини, пока я не вижу никаких фактов, демонстрирующих какие-либо твои познания и представления, выходящие за рамки стандартного API, которое реализует в основном семафорную модель. Ты можешь меня разубедить, переведя тему разговоров с личностей обратно на предмет дискуссии. Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.
Re[44]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.
В разговоре с Siclair я несколько раз упоминал использование atomic_read. И он понял о чем я говорю, поскольку идея очень простая.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
E>>Как и 7% преимущества в скорости. Известная песня.
G>7% преимущества в скорости — это и правда фигня полная
Это полная фигня на словах в форуме. На практике, ты не сможешь этот выигрыш нивелировать.
G>(особенно по сравнению с проигрышем OpenMP на примерно 140% в одном тесте, что ты предпочел забыть)
Я не забыл. Проигрыш OpenMP всего лишь доказывает, что не всегда у разделяемой памяти есть преимущества. Но ты забыл, что этого здесь никто и не отрицал.
G>что верно так же, как и то, что outbound — рассылка ни разу не раутер, а маленькая частная задача контакт-центра.
Я ничего не говорил о контакт-центрах.
G>Задача, которую ты описал — это малюсенькая часть функциональности контакт-центра.
Ее масштаб вовсе не является преградой к тому, чтобы на ее примере показать наличие преимуществ у разделяемой памяти.
G>Причина? Если ты дозваниваешся по списку, то тебе просто не надо дозваниваться до большего количества людей, чем у тебя есть в наличии исходящих линий, которые стоят денег. Если ты делаешь рассылку, то тебя в подавляющем большинстве случаев не особо волнует, насколько быстро она пройдет — за час, или полчаса. Задачу целесообразно пустить с низким приоритетом.
Сейчас ты говоришь о каких-то своих собственных материях.
G>На Эрланге я телефонных раутеров не писал,
Почему я не удивлен?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Sinclair не просто понял, о чем ты говоришь (это дело нехитрое), он, если ты не заметил, еще и объяснил тебе, почему ты неправ со своим atomic_read.
Может быть тогда ты сможешь сказать, у какой именно очереди сообщений накладные расходы на проверку наличия нового элемента будут меньше одного atomic_read?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>>>Как и 7% преимущества в скорости. Известная песня.
G>>7% преимущества в скорости — это и правда фигня полная
E>Это полная фигня на словах в форуме.
Про то, что 7% это "не фигня" — пионерам рассказывай, ладно? На практике 7% называется "одинаковая производительность", и никто не будет расшибаться в лепешку, чтобы эти 7% ликвидировать.
E>На практике, ты не сможешь этот выигрыш нивелировать.
На практике, смогу. Если захочу. В любом случае, тебе-то откуда знать, что я смогу а что нет.
G>>(особенно по сравнению с проигрышем OpenMP на примерно 140% в одном тесте, что ты предпочел забыть)
E>Я не забыл. Проигрыш OpenMP всего лишь доказывает, что не всегда у разделяемой памяти есть преимущества. Но ты забыл, что этого здесь никто и не отрицал.
Да? Тогда прокомментируй еще вот это:
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
G>>Задача, которую ты описал — это малюсенькая часть функциональности контакт-центра.
E>Ее масштаб вовсе не является преградой к тому, чтобы на ее примере показать наличие преимуществ у разделяемой памяти.
Так вэлкам! Что ж ты никак не покажешь-то эти преимущества? Что тогда для тебя преградой то является, а?
Re[47]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
G>>Sinclair не просто понял, о чем ты говоришь (это дело нехитрое), он, если ты не заметил, еще и объяснил тебе, почему ты неправ со своим atomic_read.
E>Может быть тогда ты сможешь сказать, у какой именно очереди сообщений накладные расходы на проверку наличия нового элемента будут меньше одного atomic_read?
Может быть, я тебе это уже сказал во второй части своего сообщения, которую ты предусмотрительно вырезал? Может быть, Синклер тебе все то же самое объяснил?
G>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
Здравствуйте, EvilChild, Вы писали:
S>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше. EC>А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?
Почему нельзя? Можно. Получишь в точности очередь сообщений, а именно — ее предельный случай с глубиной 1 и полиси вытеснения при переполнении по FIFO — что станет совершенно очевидно даже тем, кто в танке, если завернуть то что получится в класс, и посмотреть на функциональный интерфейс.
Потом можно пойти еще дальше, упереться, и под разными предлогами не называть это очередью сообщений. Видишь ли, asynchronous message passing — это не более чем дизайн-идиома, которая в конечном счете на современных архитектурах все равно превратится в те примитивы, через которые реализуются семафоры все остальное. Так же, как программа на функциональном языке в конечном счете превратится в ассемблерные инструкции.
Здравствуйте, kdw, Вы писали:
G>>Так не читай мои посты. Кто-то заставляет?
kdw>Кроме тебя в этом форуме есть и другие люди , kdw>как ты себе представляешь чьи то посты читать а чьи то нет. kdw>вот приходиться и твои читать.
Значит, прими касторки. Мне, знаешь, пофигу, читаешь ты, не читаешь.
Здравствуйте, Gaperton, Вы писали:
G>Я думаю, фьючерсы — это лучшее, что придумано на текущий момент в области языкостроения и параллельного программирования.
До тех пор, пока код фьючерса не попробует обращаться к разделяемой памяти...
Хардкорный Эрланг. Добавляем туда самые настоящие, честные фьючера и ленивые вычисления. Две процедуры, которые возвращают фьючерс. Фьючерс — это функция без аргументов. Ее можно вызывать многократно, ничего страшного не произойдет, она вычисляет результат только один раз. Поэтому, в функции-фьючере допустимы побочные эффекты.
Даю две функции — первая вычисляется параллельно и энергично, вторая — тупое ленивое вычисление.
Функция eval — служебная, решение полагается на замыкания и словарь процессов. Внимание — код писан в один проход и не проверен, может не сработать.
concurrent_eval( F ) ->
PID = spawn( F ),
Eval = fun() ->
receive { PID, Result } -> Result end
end,
fun() -> eval( PID, Eval ) end.
lazy_eval( F ) ->
fun() -> eval( F, F ) end.
eval( Key, F ) ->
case get( Key ) of
none -> put( Key, Result = F() ), Result;
Value -> Value
end.
Хм... Подчеркнем-ка мы явно связь между ленивыми вычислениями и параллелизмом...
lazy_eval( F ) ->
fun() ->
case get( F ) of
none -> put( F, Result = F() ), Result;
Value -> Value
end
end.
concurrent_eval( F ) ->
PID = spawn( F ),
Receive = fun() ->
receive { PID, Result } -> Result end
end,
lazy_eval( Receive ).
rpc_future( PID, Message ) ->
PID ! Message,
Receive = fun() ->
receive { PID, Result } -> Result end
end,
lazy_eval( Receive ).
Правда, эта реализация с багой. Багу вызывает использование внутри lazy_eval аргумента в качестве ключа, что выйдет боком в случае аргумента с побочным эффектом. Здесь надо что-то придумать. Самое надежное — использовать в качестве ключа уникальный номер с автоинкрементом, который генерировался бы внутри lazy_eval. Однако, правильнее дать программисту над этим контроль.
Однако, думаю, идея понятна. RPC в таком стиле мне нравится даже в Эрланге. Приятный rpc. И более эффективный в том плане, что не режет параллелизм. В чем, собственно, и состоит преимущество фьючерсов.
Забыл передать аргументом новому процессу self(). И ваще, послать результат обратно . Но мысль мне нравится. Надо ее думать. Кажется, что-то похожее предлагал Армстронг со своим оператором bang-bang, и вроде как написал специальный модуль.
G>
Здравствуйте, C0s, Вы писали:
G>>Более интересный пример, демонстрирующий силу фьючерсов. Допустим, мы хотим рассчитать массив из десяти значений. Каждое — параллельно. Мы просто заполняем этот массив в цикле фьючерсами, каждый из которых — RPC-вызов к какому-то потоку (или старт отдельного потока, выполняющего рассчет, возможно — асинхронный старт, по мере доступности потоков в пуле). И все. Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.
C0s>что характерно, все эти, действительно полезные вещи, скажем, в java доступны на уровне стандартной библиотеки, начиная с версии 5. т.е. я хочу сказать, что это не какое-то вчерашнее открытие, раз есть давно и в таком популярном языке
Вообще, в этом деле довольно мало вещей, которые являются вчерашним открытием. Фьючерсы были известны в 80-х. Кажется. А про асинхронные сообщения Дийкстра писал ваще черт знает когда. Просто тема параллельного программирования пошла в мэйнстрим относительно недавно, с приходом в жизнь многоядерных мультитредных процов. Рядовому программеру просто не нужно было этого всего знать еще 5 лет назад. Да и сейчас в массе своей обходятся. Пока Нехалемы с Ниагарами не стали обыденными вещами, вызывающими зевоту.
Ну, это же очень хорошо, что они уже есть в библиотеке. Это означает, что можно начинать их "правильно готовить" немедленно . А если б их не было, их несложно было б добавить. Мое мнение — давно пора.
Здравствуйте, Cyberax, Вы писали:
G>>Я думаю, фьючерсы — это лучшее, что придумано на текущий момент в области языкостроения и параллельного программирования. C>До тех пор, пока код фьючерса не попробует обращаться к разделяемой памяти...
Отчего же, все будет в порядке. До тех пор, пока в этой разделяемой памяти лежат чисто функциональные транзакционные структуры данных .
Вообще же, фьючерсов, асинхронных сообщений, и чисто функциональных структур данных, видишь ли, достаточно для многих задач . Фьючера хороши для синхронных запросов в стиле rpc. Очереди сообщений — для асинхронного "потокового" взаимодействия. "Чистые" транзакционные структуры данных — для избавления как от необходимости межтредного маршалинга на одной машине, так и от синхронизации доступа к данным, да и от класса ошибок связанного с мутабельным состоянием заодно.
Отличный подход, который позволит писать потрясающие программы, в надежном стиле, и с почти линейной масштабируемостью. Позволяет применять метод потока данных для проектирования, что есть совершенно превосходная методология анализа, отлично приспособленная к параллельным задачам. Причем, программу, написанную в таком стиле, несложно раскидать на кластер — она получается очень толерантна к латентности передачи сообщений, и подсистем памяти.
Я думаю, F# на многоядерных мультитредных процах раскроет себя во всей красе при применении данного подхода.
Здравствуйте, Gaperton, Вы писали:
C>>До тех пор, пока код фьючерса не попробует обращаться к разделяемой памяти... G>Отчего же, все будет в порядке. До тех пор, пока в этой разделяемой памяти лежат чисто функциональные транзакционные структуры данных .
Ну да, помечтать не вредно...
G>Я думаю, F# на многоядерных мультитредных процах раскроет себя во всей красе при применении данного подхода.
У меня просто в программе (на Java) фьючерсы достаточно сильно используются, так что я наталкивался на интересные проблемы с ними. Например, они часто существенно увеличивают вероятность столкновения на оптимистических блокировках в БД (которая, по сути, есть разделяемые данные).
Так как если несколько фьючерсов выполняются параллельно, то вполне вероятно, что они будут одновременно обращаться к одним данным. Оптимистические блокировки это словят и корректно откатят транзакцию, но тогда нам нужно будет её повторять или возвращать ошибку клиенту. В общем, я как-то так производительность в 10 раз поднял, заменив в одном методе параллельные вызовы на последовательные
Так что тут всё тоже не так просто...
Sapienti sat!
Re[49]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
G>>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
E>Одного обычного read будет недостаточно, о чем уже было сказано.
Глупость, повторенная многократно, не перестает быть глупостью.
G>>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.
E>Этот красочный оборот речи был предназначен для сокрытия факта того, что нити-читатели должны проверять свою очередь сообщений перед каждой новой транзакцией, и что эта проверка не может быть дешевле одного atomic_read-а.
Ты зачем, интересно, глупости пишешь? Тут все слишком просто, чтобы ты мог кого-то запутать.
Очередь сообщений проверяется каждый раз при приеме тех данных, которые тебе надо отмаршрутизировать. Которых, замечу, как минимум на пару порядков больше, чем обновлений таблицы. Иногда (гораздо реже, чем пакеты с данными) в ту же очередь приходит сообщение с новой таблицой, так что ничего специального для приема корня таблицы делать не нужно. При обработке этого пакета происходит вычитка корня дерева из очереди, и сохранение в локальную память, откуда он уже читается без всяких atomic_read на каждое сообщение, которое тебе надо отмаршрутизировать. Без всякого atomic_read, на котором в твоем случае и будет просос.
Re[50]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Глупость, повторенная многократно, не перестает быть глупостью.
Подобные банальные истины обоюдоостры и могут быть с такой же степенью уверености обращены к тебе.
G>Очередь сообщений проверяется каждый раз при приеме тех данных, которые тебе надо отмаршрутизировать.
Один раз ты принимаешь N пакетов, каждый из которых тебе нужно отмаршрутизировать. При маршрутизации этого пакета тебе нужно проверить, не изменилась ли таблица маршрутизации. Ась?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, AndrewVK, Вы писали:
AVK>>Здравствуйте, remark, Вы писали:
R>>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.
AVK>>Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
G>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.
Какое самопожертвование
Из множества не доказанных и не подтверждённых фактами высказываний Gaperton выберем самые интересные.
Здравствуйте, remark, Вы писали:
R>Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
Неправда.
1) "Доли такта" не занимает ни одна инструкция. Вообще.
2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
R>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса.
Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
different location.
Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
Что же касается всех "остальных современных архитектур", то даже архитектуры с TSO (что из не-embedded процов имеет только Sun-овские Ниагары) для корректного поведения вашей программы с atomiс_read потребуют мемори барьеров. В случае SMP с несколькими кристаллами и независимыми кэшами, ты налетишь на проблемы когерентности и будешь вынужден выставить memory barrier, что необходимо просадит производительность. Чудес-то не бывает.
R>Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: R>http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
Ну вот, в аккурат после пропущенного Comedy Club ты опять поднимаешь мне настроение. Ну неужели такой крупный специалист по параллелизму как ты не заметил, что у тебя внутри каждого чтения стоит МЕМОРИ БАРЬЕР (20-90 накладных тактов в зависимости от ситуации на x86 сам по себе, плюс эффект от отключения переупорядочивания). На код свой посмотри!
void reader_lock()
{
reader_inside[current_thread_index] = true;
// no explicit #StoreLoad
// but it will be implicitly executed
// by sys_synch() in writer_lock() if (writer_pending)
{
// if writer is pending
// than signal that we see it
// and wait for writer to complete
reader_inside[current_thread_index] = false;
EnterCriticalSection(&cs);
reader_inside[current_thread_index] = true;
LeaveCriticalSection(&cs);
}
// need to order user code inside critical section
// acquire compiler barrier
_ReadWriteBarrier();
}
Объясни мне, каким именно образом такой барьер будет быстрее чем CAS в 300 раз (откуда ты вообще эту цифру взял, интересно), при том, что CAS занимает на x86 те же 30-90 тактов? Ась?
R>И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): R>http://www.rsdn.ru/forum/message/3213225.1.aspx
Здравствуйте, Gaperton, Вы писали:
R>>Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: R>>http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
G>Ну вот, в аккурат после пропущенного Comedy Club ты опять поднимаешь мне настроение. Ну неужели такой крупный специалист по параллелизму как ты не заметил, что у тебя внутри каждого чтения стоит МЕМОРИ БАРЬЕР (20-90 накладных тактов в зависимости от ситуации на x86 сам по себе, плюс эффект от отключения переупорядочивания). На код свой посмотри!
G>
G> void reader_lock()
G> {
G> reader_inside[current_thread_index] = true;
G> // no explicit #StoreLoad
G> // but it will be implicitly executed
G> // by sys_synch() in writer_lock()
G> if (writer_pending)
G> {
G> // if writer is pending
G> // than signal that we see it
G> // and wait for writer to complete
G> reader_inside[current_thread_index] = false;
G> EnterCriticalSection(&cs);
G> reader_inside[current_thread_index] = true;
G> LeaveCriticalSection(&cs);
G> }
G> // need to order user code inside critical section
G> // acquire compiler barrier
G> _ReadWriteBarrier();
G> }
G>
G>Объясни мне, каким именно образом такой барьер будет быстрее чем CAS в 300 раз (откуда ты вообще эту цифру взял, интересно), при том, что CAS занимает на x86 те же 30-90 тактов? Ась?
Ну ты опять жжёшь! Я от предыдущего сообщения ещё отойти не могу. Ты лучше Comedy Club не пропускай — им нужен твой юмор!
_ReadWriteBarrier() — это барьер КОМПИЛЯТОРА. Подавляет переупорядочивания компилятором. Всё. 0 тактов оверхеда в ран-тайм.
CAS занимает 30-90 тактов? Ну всё понятно — на одноядерном мерил или без разделения данных между разными ядрами. Да, на одноядерном и/или без раздлеления действительно 30-90 тактов. Только проблема в том, что в очереди у тебя будет разделение, и тогда уже стоимость CAS никого не волнует. Тогда начинает волновать издержки на когерентность — порядка 200-500 тактов на современных системах.
Ну ты не огорчайся. В принципе, у неискушённых людей может возникнуть ощущение, что ты осведомлённый и пишешь разумные вещи.
R>>И не говоря уже о случае, когда разделяемый объект иммутабельный (или используются более гибкие и мощные подходы типа partial copy-on-write) и для доступа к объекту достаточно обычной операции загрузки (доли такта): R>>http://www.rsdn.ru/forum/message/3213225.1.aspx
G>Когда разделяемый объект иммутабельный — это мой случай, а не твой.
Ну ладно-ладно, ты только не горячись. Оставляю его тебе. Благо таким подходом реализуется *очень* ограниченное число структур и *очень* ограниченнное число операций над ними.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Даже на архитектуре POWER, с одной из самых расслабленных моделей памяти на сегодняшний день, atomic_read с требуемым в данном случае упорядочиванием consume, является не более чем обычной инструкцией загрузки из памяти ld (той самой, которая десятками встречается в любой функции и занимает доли такта):
G>Неправда. G>1) "Доли такта" не занимает ни одна инструкция. Вообще.
Есть разные определения и методики измерения времени, занимаемого командой. Здесь я имею в виду CPI, как наиболее интересную для программиста. Я надеюсь, ты в курсе, что CPI может быть меньше 1.
Ну на самом деле это совершенно не принципиально в данном вопросе. Назвать можно по-разному, но суть — что это обычная инструкция загрузки, которые можно найти в изобилии в любой функции. Т.е. стоимость синхронизации в данном случае можно считать равной нулю, что с трудом можно сказать о массовой рассылке и приёме сообщений.
G>2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
Ну и чем ты можешь это аргументировать?
Ты хочешь сказать, что по ссылке приведена некорректная реализация атомарного чтения с упорядочиванием consume? Или что consume (data-dependent load) не достаточно в данном случае?
Да, про Comedy Club можно забыть после твоих отжигов.
Никакого lwsync там не надо.
R>>И точно так же, atomic_read с упорядочиванием consume является обычной инструкцией загрузки на архитектурах x86, IA-64, SPARC RMO/PSO/TSO, ARM, и на всех остальных современных архитектурах.
G>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? .
Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
G>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>
G>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>different location.
G>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
Я поражаюсь, как тебе получается такую ахинею оборачивать в благовидный облик.
Нет, не Абыдно. Где ты в паттерне публикации увидел store-load последовательность, которую надо упорядочивать? Поток потребителя её исполняет? Ну и что же он сохраняет и куда?
G>Что же касается всех "остальных современных архитектур", то даже архитектуры с TSO (что из не-embedded процов имеет только Sun-овские Ниагары) для корректного поведения вашей программы с atomiс_read потребуют мемори барьеров. В случае SMP с несколькими кристаллами и независимыми кэшами, ты налетишь на проблемы когерентности и будешь вынужден выставить memory barrier, что необходимо просадит производительность. Чудес-то не бывает.
Слушай, где ты такого понабирался? Можешь хоть ссылки какие-то дать? Интересно становится...
В каком месте-то ты там хоть этот барьер себе представляешь? Да, и какого, кстати, типа это барьер? Как-либо затрагивать когерентность и иметь отношение к SMP может только если полный барьер — значит тут полный барьер будет где-то в паттерне публикации на стороне потребителя?
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, remark, Вы писали:
R>>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.
G>Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.
По-существу то хоть что-нибудь ответишь:
"Примитив синхронизации и рандеву" в языках платформы CLI (C#) и Java представляет из себя копирование объектной ссылки, что является не более чем обычной инструкцией загрузки указателя (доли такта) на всех современных аппаратных платформах.
Именно таким образом в этих языках и реализовывалось бы распространение неизменяемого объекта: изменяющий поток совершает подмену объектной ссылки на новый объект (одна обычная запись в память), читающие потоки совершают считывание текущей объектной ссылки (одно обычное чтение из памяти). Это в противопоставление обмену сообщениями, где придётся рассылать N сообщений, принимать N сообщений, и ещё ряд неприятных факторов (типа работы не обязательно с текущей версией объекта, жадного обновления объект в отличие от ленивого и др.).
"Абыдно, Да?" (с) Gaperton
"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
Здравствуйте, Gaperton, Вы писали:
R>>Вот реализация "семафора" (или мьютекса), которая для доступа "на чтение" требует только 2 обычных сохранения в память, несколько загрузок из памяти и одно предсказываемое ветвление. При этом алгоритм распределенный, т.е. при доступе "на чтение" потоки работают с локальной памятью. За счёт этого такой мьютекс оказывается быстрее очереди с одним CAS в 300(!) раз уже на четырёх-ядерном процессоре Q6600 на тесте с высокой нагрузкой: R>>http://groups.google.com/group/lock-free/browse_frm/thread/1efdc652571c6137
G>Ну вот, в аккурат после пропущенного Comedy Club ты опять поднимаешь мне настроение. Ну неужели такой крупный специалист по параллелизму как ты не заметил, что у тебя внутри каждого чтения стоит МЕМОРИ БАРЬЕР (20-90 накладных тактов в зависимости от ситуации на x86 сам по себе, плюс эффект от отключения переупорядочивания). На код свой посмотри!
G>Объясни мне, каким именно образом такой барьер будет быстрее чем CAS в 300 раз (откуда ты вообще эту цифру взял, интересно), при том, что CAS занимает на x86 те же 30-90 тактов? Ась?
Ну что?
"Абыдно, Да?" (с) Gaperton
"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
Здравствуйте, Gaperton, Вы писали:
G>2) По причине переупорядочивания записи в память в архитектуре Power для корректного поведения твоего atomic read в данной программе тебе надо будет воспользоваться инструкцией lwsync, то есть барьер выставить, что занимает в районе 30-50 тактов. Это на многоядерном кристалле с общим кэшом L2, таком, какой стоит в XBox360. Это во-вторых.
G>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>
G>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>different location.
G>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
"Абыдно, Да?" (с) Gaperton
"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
"Ась?" (с) Gaperton
Здравствуйте, remark, Вы писали:
R> _ReadWriteBarrier() — это барьер КОМПИЛЯТОРА. Подавляет переупорядочивания компилятором. Всё. 0 тактов оверхеда в ран-тайм.
То есть, ты хочешь сказать, что эта хрень не дает компилятору переупорядочивать инструкции. И типа, совсем вся работа делается в блокировке писателя. Ну допустим. На самом деле, в реальном сравнении мутабельного словаря в данной задаче на разделяемой памяти, и иммутабельного на сообщениях, это мало что дает.
Во-первых, структура у тебя все-таки volatile, и регистровые оптимизации запрещены.
Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке. Что, в случае высоколатентной памяти, обойдется дорого.
В случае с дизайном на сообщениях нет ни того, ни другого. Читаешь ты из очереди один раз, переписывая сообщение в non-volatile память, и используя переменную потом в цикле, что разрешает регистровые оптимизации. Далее — во время модификации структуры в моем случае все спокойно работают на предыдущей ее версии, и не блокируются вовсе — единственная задержка будет на CAS, и очень редко — в момент получения пакета.
R>Ну ты не огорчайся. В принципе, у неискушённых людей может возникнуть ощущение, что ты осведомлённый и пишешь разумные вещи.
Пытаешься спасти свою репутацию? Угу, искушенные люди конечно сразу тебе поверили про ускорение в 300 раз . Которого в данной задаче, естественно, не будет, особенно если построить очередь на технике, подобной твоему mutex. Ты вообще плохо отдаешь себе отчет, с чем споришь.
R> "Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
Как тебе однако хочется, чтобы я обкакался. Вот это называется обкакался.
А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.
А то, что я не знаю, какой там нахрен барьер _ReadWriteBarrier(), что послужило поводом твоей бурной радости — так всего знать невозможно (ты, к примеру, не знаешь про lwsync), да и в контексте общего спора, в котором глупые тезисы выдвигаешь ты, а не я, это совершенно не принципиально. Касательно того, что atomic_read, на котором eao собирался решать эту задачу, медленнее обычного — это правда и остается правдой, в данном случае нужен честный барьер в получателе чтобы все работало.
Re[51]: пример eao197: "сообщения" рвут "разделяемую память"
G>>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? . R>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
Если нужен volatile, то на чём ни пиши, всё равно в регистры не уложишь.
Поэтому реплику про ассемблер считаю неорганизованной и отметаю.
Про передачу сообщений.
Её можно сделать сколь угодно мало требовательной путём группировки сообщений.
Типа, пишется в одну очередь, читается из другой. По переполнению/опустошению очереди сливаются, перед этим создаётся новый объект для изменяемой очереди.
Чтение из текущей рабочей очереди не имеет проблем с разделением ресурсов. Запись в текущую рабочую тоже таких проблем не имеет большую часть времени.
Это программная реализация. Про аппаратную вообще молчу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, remark, Вы писали:
R>Ещё одна из его фишек, типа называть собесебника на "Вы", но при этом "вы" писать с маленькой буквы...
Имхо, это вполне нормальное поведение. Насколько я знаю, в русском языке было принято писать "Вы" с большой буквы в двух случаях -- в официальной переписке, адресуемой конкретному получателю, и в личной переписке, опять же адресуемой конкрентному получателю. Поскольку общение в публичном форуме не попадает ни под одну из этих ситуаций, то "вы" с маленькой буквы вполне уместно, имхо.
R>Я ещё могу понять, когда человек высказывает такое прямо и открыто. Но когда вот так, изподтяжка...
Вполне нормальный полемический прием. И не он один здесь (в этой теме) этот прием применяет, и не всегда удачно
Предлагаю прислушаться к просьбе AVM и прекратить личные оскорбления, а то вся тема в СВ уедет.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[52]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
G>>>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? . R>>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
T>Если нужен volatile, то на чём ни пиши, всё равно в регистры не уложишь. T>Поэтому реплику про ассемблер считаю неорганизованной и отметаю.
Стоп-стоп-стоп. Что Вы имеете в виду с Gaperton'ом? В чём тезис и при чём тут всплыл volatile и регистровые оптимизации? Вы хотите сказать, что это вносит какие-то серьёзные издержки в работу алгоритма? Т.е. я правильно понимаю, что Вы хотите, что бы примитив синхронизации работал только с регистрами? Или что?
Я имею в виду, что суть в том, что там, на машинном уровне, стоит обычная инструкция загрузки. Как она там появилась — абсолютно не важно в данном контектсе — хоть volatile в С, хоть напрямую на асме её написали (на асме написали инструкцию загрузки! а НЕ заставили примитив синхронизации работать только с регистрами!).
Для любого примитива синхрониазации абсолютно важно подавить оптимизации/переупорядочивания компилятора. Очередь это тоже делает. К счастью, это НЕ вносит НИКАКОГО существенного оверхеда в ран-тайм.
T>Про передачу сообщений.
T>Её можно сделать сколь угодно мало требовательной путём группировки сообщений.
T>Типа, пишется в одну очередь, читается из другой. По переполнению/опустошению очереди сливаются, перед этим создаётся новый объект для изменяемой очереди.
T>Чтение из текущей рабочей очереди не имеет проблем с разделением ресурсов. Запись в текущую рабочую тоже таких проблем не имеет большую часть времени.
Теоретически — да. На практике это не работает.
Группировка будет работать только в вырожденном случае, когда агнет посылает сообщения только одному другому агенту, и всё это, понятно, в одном потоке. Когда произвольное множество агентов посылает сообщения произвольному множеству агентов + это происходит во множестве потоков + надо гарантировать ФИФО (это тут очень важно — это рушит всю идею группирования) — ничего не получится, придётся честно каждое сообщение посылать. Если не согласен — обрисуй схему, которая будет работать для множества отправителей, множества получаетелей, множества потоков.
Получается кэшировать только в очень частных случаях, например если агент посылает несколько сообщений другому агенту и не посылает между этим сообщений другим агентам. Но это не особо интересно для практики — допустим агнет начинает чередовать рассылку — отсылает то одному, то другому — всё, финита ля комедиа, оптимизация порушилась, система легла.
Плюс кэш сообщений уже надо хранить не один на рабочий поток, а один на каждого агента (которых могут быть сотни тысяч), а потом как-то эти кэши опрашивать, мы ж не можем кэшировать вечно. Плюс необходима поддержка языка, типа как для GC — должны иметь возможность гарантированно периодически дергать функцию сброса кэша из рабочего потока (или мы будет дергать сброс кэша из другого потока, и защищать каждое обращение к этой очереди мьютексом?).
Вобщем, на практике это сыпется как карточный домик, вопросов больше, чем ответов.
Про очередь вообще не понял, чего мы с такой схемой добились. У нас была multi-producer/single-consumer очередь. Потребитель тут и так работает без конфликтов, т.к. он один — взять хотя бы ту же two-lock queue. Производители гарантированно сталкиваются, и то, что разбили на 2 очереди ни как не повлияет на сталкновения — всё производители всё равно будут работать с одной очередью.
Здравствуйте, remark, Вы писали:
R>>>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
G>>В сторону уводишь ты, ты вообще по хожу не держишь контекста дискуссии. Не буду считать, что это "вообще на асме", поскольку сравнивается очередь и разделяемая мутабельная память в контексте задачи. И работа компилятора здесь важна.
R>Ну, ладно, как хочешь — в исходном коде на С там стоит volatile. Ну и в чём тут твоя мысль? Что ты хочешь этим сказать? Кроме того, что создаёшь у неискушённых читателей впечатление, что ты типа тоже что-то умное отвечаешь с какими-то терминами?
Во-первых, прекрати называть тех людей, кто со мной согласен — идиотами. Во-вторых, к примеру, на Itanium volatile не просто отключает регистровые оптимизации, но и добавляет барьер. Поэтому доступ к volatile-переменной на Itanium очень дорогой. Почитай здесь
Кстати, твой мегабыстрый мутекс, который ты привел тут рядом, будет тормозить на Itanium (там обращения к volatile компилятся с барьерами), и не будет работать на Power (там требуется явный барьер).
В третьих, прекрати кривляться, валять дурака, и убеждать меня в том, что ты тупой. Ты можешь в этом и преуспеть.
G>>>>И здесь ты неправ. В x86 у тебя сохранение порядка гарантируется только для одного адреса. G>>>>
G>>>>Intel 64 memory ordering allows load instructions to be reordered with prior stores to a
G>>>>different location.
G>>>>Будет прикольно, если ты считаешь адрес нового корня, а записи для самого нового корня еще не дошли . Крэшдамп получишь красивый вместо результата. Абыдно, да? На, почитай первоисточник.
R>>>Я поражаюсь, как тебе получается такую ахинею оборачивать в благовидный облик.
G>>Язык попридержи. Достал. Я дал тебе человеческое объяснение, и ссылку на документ. Мозгов не хватает понять, что я имею в виду, или как? У меня нет никакого желания тебе что-то втолковывать помимо твоей воли — считай как хочешь. Можешь мнить мебя мегаэкспертом в параллелизме — я не против.
R>Ну докажи, что это не ахинея. В ссылке надо документ ничего нет про то, где в паттерне публикации store-load последовательность на стороне читателя.
Я тебе уже дал объяснение. Его достаточно. Мозгов не хватает понять, зачем здесь нужен lwsync, зато хватает ума кривляться — извини.
R>"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton
Да ладно, можешь уже прекратить истерику. Собственно, и ты и eao, прекрасно знаете, что спор по существу вопроса вы проиграли. Твои дурацкие цепляния к деталям сейчас уже ничего не изменят — ты говорил, что сообщения на два порядка медленнее в любом случае, я тебе привел два исследования, и показал, как надо написать на сообщениях программу еао, чтобы она была быстрее, чем то что он в состоянии придумать с разделяемой памятью.
Вы при этом успели перейти на личности, и поэтому в результате выставили себя дураками, и теперь хотите выиграть спор любой ценой — враньем, смещениями акцента, и придирками. Вон, пятками в грудь себя колотите, сколько вы там параллельных фреймворков написали .
Извини, то что вы в дураках оказались — исключительно вы сами виноваты, я здесь не причем. Думать надо было, что говоришь. И помогать теперь тебе выкручиваться я не собираюсь. Я даже с удовольствием признаю (покривив душой немного, но зато тебе приятно будет) что ты мега-гуру в параллелизме. В конце концов я менеджер, мне можно в этом вообще не разбираться ни черта.
Re[55]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVM>>Коллеги, давайте перестанем друг друга подкалывать и не будем выяснять кто первый начал, просто перестанем. AVM>>Понимаю, что некоторый высказывания коллег провоцируют, но давай просто будем немного взрослее. AVM>>А то взрослые мужики, обсуждаете интересную тему, но ведете себя как малые дети в песочнице.
AVK>А еще лучше, если кто нибудь возьмет обсуждаемую задачу и напишет совсем совсем простой тест с очередью и разделяемой памяти и просто померяет.
Зачем писать, и так все понятно. Узкое место — обращение к словарю кодов городов. Оптимальная реализация на мутабельной памяти будет использовать хэш-таблицу или ваще тупой массив для кодов городов, где значение будет получаться в одно обращение (странно, что они до этого не до сих пор додумались, я все жду, жду, когда до них "преимущества разделяемой памяти" дойдут).
Затем они попробуют закрыть ее своим "быстрым" непортабельным мутексом, который адекватно работает только на IA32/64. Это решение засчитано не будет, разумеется. Ну хорошо, даже на обычной критической секции (в районе 200-300 сотен тактов накладных) уже не так очевидно, что будет быстрее — в бинарном дереве будет до 10 обращений к памяти все-таки (предполагая там 100 записей). Ладно, пусть даже у низ этот волшебный бесплатный хакерский mutex есть, неважно. Вот так бы они поступили, если бы немного отвлеклись от желания доказать, что Гапертон дурак, и подумали наконец о задаче.
Это бы они сделали в надежде, что чисто функциональных хэш-таблиц вроде как не бывает. В ответ я бы применил простой массив в качестве индекса, и стал бы его тупо копировать при изменениях, полагаясь на то, что размер у него всего порядка 4х килобайт, и операция это крайне редка. И получил бы кроссплатформенное решение, которое работает без блокировок, более того — воркеры не ждут, пока я патчу массив, и спокойно продолжают работать.
В результате, версии с хакерским мутексом и эта работали бы на IA32/64 примерно одинаково, с разницей в доли процента. На Power (то есть, на XBox360) версия на сообщениях была бы несколько быстрее, думаю, не более чем на десятки процентов (реальная разница зависит от того, сколько тратится на обработку сообщения, и, я думаю, будет незначительна).
Потом, они попробовали бы раздуть размер лукап-таблицы, и участив его модификации (последнее увеличит им оверхэд, на самом деле), выйдя за рамки исходной задачи, чтобы я просел на копировании данных. Нормальное желание, человеческое. Это и есть слабое место. На это бы я изобразил чисто-функциональный транзакционный массив в стиле B-Tree без ключей. Это надо, чтобы не перезаписывать при изменении весь индекс целиком — что на больших таблицах вышло бы боком. И опять обошелся кроссплатформенным решением без блокировок, наиграв всего одно-два лишних обращений в память, которое на Power и Itanium будет несколько быстрее, и примерно одинаково на Core 2 Dou.
После чего, я бы предложил посмотреть, как масштабируется производительность в финальной задаче от количества аппаратных потоков и кристаллов в SMP, и, по всей видимости, довольно убедительно уложил бы их на Нехалеме и Ниагаре. За счет того, что у меня никто никого не блокирует, и все взаимодействие асинхронно.
Примерно так бы все и было. С незначительными нюансами туда-сюда. Тока мне лень этим заниматься. Зачем? Мне и так все понятно, а у парней, я подозреваю, истерика в середине случится. Ну и кроме того, они ведь не додумались до хэш-таблицы. Да и задача слишком хороша для сообщений — могли бы и похуже что-нибудь придумать. Вроде поиска выхода из лабиринта, например . Правда, и в этой задаче их ждал бы небольшой сюрприз — сообщения как всегда наносят ответный удар с неожиданной стороны .
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G>Вот. Теперь, очередной парадокс. Иммутабельная структура данных, состоящая из таких очередей, также функционально чиста и транзакционна, однако. И позволяет делать довольно необычные вещи, несколько уже выходящие за рамки обычных представлений о дизайне на асинхронных сообщениях. Причина крышесрывания состоит в том, что очередь сообщений здесь рассматривается как first class object, которая сама может быть составным элементом структур данных. Занятно, не так ли? Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
Хм. Интересно, это новая парадигма, или это уже кто-то придумал? Надо бы статью написать, штоли, в любом случае. Чрезвычайно интересно.
Re[55]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>А еще лучше, если кто нибудь возьмет обсуждаемую задачу и напишет совсем совсем простой тест с очередью и разделяемой памяти и просто померяет.
В конце года не просто найти время на реализацию подобного теста, тем более, что готовой очереди на основе CAS у меня в распоряжении просто нет. Может быть на новогодних каникулах...
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
Я так понял:
Количество очередей должно быть равно количеству ядер или должны быть сгруппированы. В очередь должны попадать зависимые фьючерсы (блокирующие друг друга), а так как связи могут быть циклическими, нужно их заранее группировать на этапе компиляции. Для многих структур данных нужна еще и версионность, которую можно использовать для неблокирующего чтения, или использовать иммутабле.
и солнце б утром не вставало, когда бы не было меня
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Gaperton, Вы писали:
G> Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
Ну, remark в соседнем топике утверждал, что фьючерсы сотоварищи совсем уже не actors model, это совершенно отдельный task parallelism. Но это все спор о терминах.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Здравствуйте, thesz, Вы писали:
G>>>>Что, до такой степени "обычная", что в определении этой переменной, которую вы собрались читать обычными read даже не надо писать volatile, и компилятор ее спокойно применяет к ней регистровую оптимизацию, как в моем случае? . R>>>Ох, ну не надо только в сторону уводить. volatile, не volatile там в С. Считай, что это вообще на асме.
T>>Если нужен volatile, то на чём ни пиши, всё равно в регистры не уложишь. T>>Поэтому реплику про ассемблер считаю неорганизованной и отметаю.
R>Стоп-стоп-стоп. Что Вы имеете в виду с Gaperton'ом? В чём тезис и при чём тут всплыл volatile и регистровые оптимизации? Вы хотите сказать, что это вносит какие-то серьёзные издержки в работу алгоритма? Т.е. я правильно понимаю, что Вы хотите, что бы примитив синхронизации работал только с регистрами? Или что?
R>Я имею в виду, что суть в том, что там, на машинном уровне, стоит обычная инструкция загрузки. Как она там появилась — абсолютно не важно в данном контектсе — хоть volatile в С, хоть напрямую на асме её написали (на асме написали инструкцию загрузки! а НЕ заставили примитив синхронизации работать только с регистрами!). R>Для любого примитива синхрониазации абсолютно важно подавить оптимизации/переупорядочивания компилятора. Очередь это тоже делает. К счастью, это НЕ вносит НИКАКОГО существенного оверхеда в ран-тайм.
T>>Про передачу сообщений.
T>>Её можно сделать сколь угодно мало требовательной путём группировки сообщений.
T>>Типа, пишется в одну очередь, читается из другой. По переполнению/опустошению очереди сливаются, перед этим создаётся новый объект для изменяемой очереди.
T>>Чтение из текущей рабочей очереди не имеет проблем с разделением ресурсов. Запись в текущую рабочую тоже таких проблем не имеет большую часть времени.
R>Теоретически — да. На практике это не работает. R>Группировка будет работать только в вырожденном случае, когда агнет посылает сообщения только одному другому агенту, и всё это, понятно, в одном потоке. Когда произвольное множество агентов посылает сообщения произвольному множеству агентов + это происходит во множестве потоков + надо гарантировать ФИФО (это тут очень важно — это рушит всю идею группирования) — ничего не получится, придётся честно каждое сообщение посылать. Если не согласен — обрисуй схему, которая будет работать для множества отправителей, множества получаетелей, множества потоков.
Зачем надо гарантировать ФИФО именно в самой очереди?
Для синхронизации это не важно, будет ли ФИФО в очереди, или нет.
Я приводил ссылку на систему WaveScalar, там очень интересная система синхронизации обращений в память, построенная для недетерминированной по своей сути системы потока данных.
Так и здесь — надо всё писать из расчёта общей недетерминированности процесса.
R>Получается кэшировать только в очень частных случаях, например если агент посылает несколько сообщений другому агенту и не посылает между этим сообщений другим агентам. Но это не особо интересно для практики — допустим агнет начинает чередовать рассылку — отсылает то одному, то другому — всё, финита ля комедиа, оптимизация порушилась, система легла.
Смотри. Ты смотришь на агентов, как на совершенно независимые сущности, способные послать кому угодно что угодно.
В действительности же агенты будут получены из текста последовательной программы путём её преобразования (автоматического ли, ручного ли). Это наложит на их посылки определённый порядок. Далее мы построим иерархию узлов-процессоров (каждый нижний узел ответственен за выполнение нескольких агентов, узлы уровнем выше нижнего ответственны за группировку и передачу сообщений узлам выше и ниже).
Такая иерархия очень важна, это, буквально, единственный способ сделать нормальный межпроцесс(ор)ный обмен. Топология называется fat tree и она эффективней гиперкуба.
В результате получится, что у каждого узла-процессора будет не более трех источников входящих и исходящих данных. (в общем случае, конечно, коэффициент-репликации-нижних+коэффициент-репликации-верхних*2). Поскольку количество приемных очередей конечно, то производители (ретрансляторы) сообщений сталкиваться не будут.
Поскольку не будет никакого "отсылает то одному, то другому" больше, чем заранее заданное число этих самых одних и других.
При этом самих агентов могут быть сотни тысяч, а процессоров — всего десятки.
R>Плюс кэш сообщений уже надо хранить не один на рабочий поток, а один на каждого агента (которых могут быть сотни тысяч), а потом как-то эти кэши опрашивать, мы ж не можем кэшировать вечно. Плюс необходима поддержка языка, типа как для GC — должны иметь возможность гарантированно периодически дергать функцию сброса кэша из рабочего потока (или мы будет дергать сброс кэша из другого потока, и защищать каждое обращение к этой очереди мьютексом?).
Не очень понятно.
R>Вобщем, на практике это сыпется как карточный домик, вопросов больше, чем ответов.
Я же делал такие системы.
Вопросов много, но и ответы-решения очень простые.
R>Про очередь вообще не понял, чего мы с такой схемой добились. У нас была multi-producer/single-consumer очередь. Потребитель тут и так работает без конфликтов, т.к. он один — взять хотя бы ту же two-lock queue. Производители гарантированно сталкиваются, и то, что разбили на 2 очереди ни как не повлияет на сталкновения — всё производители всё равно будут работать с одной очередью.
Здравствуйте, AndrewVK, Вы писали:
E>>В конце года не просто найти время на реализацию подобного теста, тем более, что готовой очереди на основе CAS
AVK>Что такое CAS?
Я хотел использовать вот эту, но она написана с использованием atomic из состава C++0x, поэтому нужно будет ее адаптировать к C++03, а на это пока нет времени. К тому же она использует динамическую память, а это явный проигрыш, поэтому ее еще нужно адаптировать к сохранению указателей по значению.
Сам термин CAS применительно к очереди сообщений здесь первым, если не ошибаюсь, применил Gaperton. Поэтому нужно спросить у него, имел ли он в виду очередь на спин-локах или какой-то из вариантов lock-free очереди.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[54]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
R>>Теоретически — да. На практике это не работает. R>>Группировка будет работать только в вырожденном случае, когда агнет посылает сообщения только одному другому агенту, и всё это, понятно, в одном потоке. Когда произвольное множество агентов посылает сообщения произвольному множеству агентов + это происходит во множестве потоков + надо гарантировать ФИФО (это тут очень важно — это рушит всю идею группирования) — ничего не получится, придётся честно каждое сообщение посылать. Если не согласен — обрисуй схему, которая будет работать для множества отправителей, множества получаетелей, множества потоков.
T>Зачем надо гарантировать ФИФО именно в самой очереди?
T>Для синхронизации это не важно, будет ли ФИФО в очереди, или нет.
Потому что никто даже и не взглянет на такую реализацию актёров. Погляди на любые реализации модели актёров — они все гарантируют ФИФО, и это не спроста.
Или ты имешь в виду, что ФИФО будет делаться на уровень выше? Векторные часы там? Подожди, ты о железе опять говоришь? Для софта это не будет работать — проще сразу класть в одну очередь. Если о железе — ну для железа видимо подходит — поиск минимального времени можно сделать за O(1) и т.д. Но железо меня не сильно интересует, я ж не с программатором сижу.
T>Я приводил ссылку на систему WaveScalar, там очень интересная система синхронизации обращений в память, построенная для недетерминированной по своей сути системы потока данных.
Опять железо? В железе можно много чего сделать — аппаратную поддержку ассоциативных контейнеров, HTM, поддержку сборки мусораи т.д. Я сижу за x86, как я думаю 99% здесь, и меня интересует как я могу здесь и сейчас использовать модель актёров и передачуц сообщений.
T>Так и здесь — надо всё писать из расчёта общей недетерминированности процесса.
Какие есть прецеденты реализации модели актёров без ФИФО?
R>>Получается кэшировать только в очень частных случаях, например если агент посылает несколько сообщений другому агенту и не посылает между этим сообщений другим агентам. Но это не особо интересно для практики — допустим агнет начинает чередовать рассылку — отсылает то одному, то другому — всё, финита ля комедиа, оптимизация порушилась, система легла.
T>Смотри. Ты смотришь на агентов, как на совершенно независимые сущности, способные послать кому угодно что угодно.
T>В действительности же агенты будут получены из текста последовательной программы путём её преобразования (автоматического ли, ручного ли). Это наложит на их посылки определённый порядок. Далее мы построим иерархию узлов-процессоров (каждый нижний узел ответственен за выполнение нескольких агентов, узлы уровнем выше нижнего ответственны за группировку и передачу сообщений узлам выше и ниже).
T>Такая иерархия очень важна, это, буквально, единственный способ сделать нормальный межпроцесс(ор)ный обмен. Топология называется fat tree и она эффективней гиперкуба.
T>В результате получится, что у каждого узла-процессора будет не более трех источников входящих и исходящих данных. (в общем случае, конечно, коэффициент-репликации-нижних+коэффициент-репликации-верхних*2). Поскольку количество приемных очередей конечно, то производители (ретрансляторы) сообщений сталкиваться не будут.
T>Поскольку не будет никакого "отсылает то одному, то другому" больше, чем заранее заданное число этих самых одних и других.
T>При этом самих агентов могут быть сотни тысяч, а процессоров — всего десятки.
R>>Плюс кэш сообщений уже надо хранить не один на рабочий поток, а один на каждого агента (которых могут быть сотни тысяч), а потом как-то эти кэши опрашивать, мы ж не можем кэшировать вечно. Плюс необходима поддержка языка, типа как для GC — должны иметь возможность гарантированно периодически дергать функцию сброса кэша из рабочего потока (или мы будет дергать сброс кэша из другого потока, и защищать каждое обращение к этой очереди мьютексом?).
T>Не очень понятно.
R>>Вобщем, на практике это сыпется как карточный домик, вопросов больше, чем ответов.
T>Я же делал такие системы.
T>Вопросов много, но и ответы-решения очень простые.
Только один вопрос: fat tree — это ты про аппаратную реализацию, правильно? Если да, то тогда вопросов больше нет.
А нет, вот ещё один: как делать динамический лоад-балансинг агентов между процессорами?
Здравствуйте, remark, Вы писали:
R>Только один вопрос: fat tree — это ты про аппаратную реализацию, правильно? Если да, то тогда вопросов больше нет. R>А нет, вот ещё один: как делать динамический лоад-балансинг агентов между процессорами?
Всё ясно:
...invented the fat tree interconnection network, a hardware-universal interconnection network...
Понятно, что со специализированной аппаратной поддержкой чего угодно можно уехать далеко, и доказать потом превосходство этого над тем, что не имеет аппаратной поддержки.
Можно сказать: представь вся моя программа будет реализована в железе и будет занимать в программе одну инструкцию. Представь как она будет всё рвать!
Мне у Charles Eric Leiserson больше по душе Cilk, потому что я могу его сейчас скачать и запустить на своём компьютере. И чем они занимаются в Cilk Arts — Hyperobejcts там всякие и верификация параллельных программ.
Здравствуйте, Gaperton, Вы писали:
R>> _ReadWriteBarrier() — это барьер КОМПИЛЯТОРА. Подавляет переупорядочивания компилятором. Всё. 0 тактов оверхеда в ран-тайм.
G>То есть, ты хочешь сказать, что эта хрень не дает компилятору переупорядочивать инструкции. И типа, совсем вся работа делается в блокировке писателя. Ну допустим.
Ну типа того. Т.е. то, что ты говорил до этого — неправда.
G>Во-первых, структура у тебя все-таки volatile, и регистровые оптимизации запрещены.
Да, это ещё один тривиальный факт. Ты что-то ещё хочешь этим сказать?
Здравствуйте, Gaperton, Вы писали:
G>На самом деле, в реальном сравнении мутабельного словаря в данной задаче на разделяемой памяти, и иммутабельного на сообщениях, это мало что дает.
G>Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке. Что, в случае высоколатентной памяти, обойдется дорого.
G>В случае с дизайном на сообщениях нет ни того, ни другого. Читаешь ты из очереди один раз, переписывая сообщение в non-volatile память, и используя переменную потом в цикле, что разрешает регистровые оптимизации. Далее — во время модификации структуры в моем случае все спокойно работают на предыдущей ее версии, и не блокируются вовсе — единственная задержка будет на CAS, и очень редко — в момент получения пакета.
Что ж ты всё время так узко и так фанатично смотришь на вещи... Лучше, хуже, серебряные пули...
Моя позиция, что нет серебряных пуль, есть просто разные техники с разными наборами "плюсов" и "минусов". Задача профессионального инженера — грамотно выбрать среди альтернатив, а не слепо привязаться к одному подходу.
Если решение с мьютексом подходит хуже, то я просто не будут его использовать (оно, кстати, тут и появилось по другому поводу). Если оно подходит лучше, то будут использовать его.
На его минусы ты уже указал. Основной — длительное блокирование читателей. Но ключевой момент то, что на ряду с минусами у него есть и плюсы. Основные плюсы (которые, кстати, непосредственно следуют из минусов):
1. Нет необходимости копировать структуру или её части и хранить какие-либо предыдущие версии. Т.е. либо создаём новые части, вставляем их в структуру, и старые сразу освобождаем; либо непосредственно переиспользуем старые части под новые. В некоторых ситуациях это может быть showstopper'ом для подхода на иммутабельных структурах (если размер данных большой и/или изменения часты и/или каждый узел хранит много данных).
2. С мьютексом можно использовать структуру данных любой сложности, а не только тот очень и очень ограниченный набор структур, которые можно делать иммутабельными. Например, под такой мьютекс я могу положить cache-conscious hash-map. И в то время, как ты будешь экономить при редких изменениях со своим деревом, я буду экономить при каждом частом чтении. Ты, кстати, не можешь сделать своё дерево cache-conscious, т.е. будешь заниматься проверкой скорости работы основной памяти. Ну и не говоря уже обо всём разнообразии структур данных, т.е. я могу просто открыть справочник, выбрать структуру и положить её под мьютекс. Ты же будешь вынужден думать как прикрутить дерево к задаче.
Именно из таких соображений я и разрабатываю *различные* алгоритмы. Кстати, среди моих алгоритмов ты можешь видеть и алгоритмы для поддержки именно неизменяемых структур данных: http://groups.google.ru/group/lock-free
Здравствуйте, remark, Вы писали:
R>Здравствуйте, thesz, Вы писали:
R>>>Теоретически — да. На практике это не работает. R>>>Группировка будет работать только в вырожденном случае, когда агнет посылает сообщения только одному другому агенту, и всё это, понятно, в одном потоке. Когда произвольное множество агентов посылает сообщения произвольному множеству агентов + это происходит во множестве потоков + надо гарантировать ФИФО (это тут очень важно — это рушит всю идею группирования) — ничего не получится, придётся честно каждое сообщение посылать. Если не согласен — обрисуй схему, которая будет работать для множества отправителей, множества получаетелей, множества потоков.
T>>Зачем надо гарантировать ФИФО именно в самой очереди?
T>>Для синхронизации это не важно, будет ли ФИФО в очереди, или нет.
R>Потому что никто даже и не взглянет на такую реализацию актёров. Погляди на любые реализации модели актёров — они все гарантируют ФИФО, и это не спроста.
R>Или ты имешь в виду, что ФИФО будет делаться на уровень выше? Векторные часы там? Подожди, ты о железе опять говоришь? Для софта это не будет работать — проще сразу класть в одну очередь. Если о железе — ну для железа видимо подходит — поиск минимального времени можно сделать за O(1) и т.д. Но железо меня не сильно интересует, я ж не с программатором сижу.
Нет, я не про железо.
T>>Я приводил ссылку на систему WaveScalar, там очень интересная система синхронизации обращений в память, построенная для недетерминированной по своей сути системы потока данных.
R>Опять железо? В железе можно много чего сделать — аппаратную поддержку ассоциативных контейнеров, HTM, поддержку сборки мусораи т.д. Я сижу за x86, как я думаю 99% здесь, и меня интересует как я могу здесь и сейчас использовать модель актёров и передачуц сообщений.
Так же, как и любую другую модель.
WaveScalar недетерминирован. Он может выполнять "задачи из будущего". Главное — это синхронизация в ключевых местах. Синхронизация редкая, надо сказать.
T>>Так и здесь — надо всё писать из расчёта общей недетерминированности процесса. R>Какие есть прецеденты реализации модели актёров без ФИФО?
Да иди ты смотреть на WaveScalar. Хотя бы.
T>>Вопросов много, но и ответы-решения очень простые.
R>Только один вопрос: fat tree — это ты про аппаратную реализацию, правильно? Если да, то тогда вопросов больше нет.
Все, что делается в железе, может быть сделано и программно.
R>А нет, вот ещё один: как делать динамический лоад-балансинг агентов между процессорами?
Вероятностно.
Разбить пространство исполнения программы на примерно равные части, сделать простую хэш-функцию из пространства выполнения в узлы-процессора.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[56]: пример eao197: "сообщения" рвут "разделяемую память"
R>>Только один вопрос: fat tree — это ты про аппаратную реализацию, правильно? Если да, то тогда вопросов больше нет. R>>А нет, вот ещё один: как делать динамический лоад-балансинг агентов между процессорами?
R>Всё ясно: R>
R>...invented the fat tree interconnection network, a hardware-universal interconnection network...
R>Понятно, что со специализированной аппаратной поддержкой чего угодно можно уехать далеко, и доказать потом превосходство этого над тем, что не имеет аппаратной поддержки. R>Можно сказать: представь вся моя программа будет реализована в железе и будет занимать в программе одну инструкцию. Представь как она будет всё рвать!
Да ни-хе-ра.
Ты эту самую иерархию можешь сделать и программой. В случае программного решения тебе этого не избежать. Ни иерархии, ни её реализации.
А иначе будет так, как ты сказал — каждый тянется к каждому и все друг другу мешают работать постоянными блокировками.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Gaperton, Вы писали:
R>>Ну ты не огорчайся. В принципе, у неискушённых людей может
возникнуть ощущение, что ты осведомлённый и пишешь разумные вещи.
G>Пытаешься спасти свою репутацию? Угу, искушенные люди конечно
сразу тебе поверили про ускорение в 300 раз . Которого в данной
задаче, естественно, не будет,
А я на неискушенных людей и не рассчитываю, поэтому и не заворачиваю
всякий бред в умных вид. Для неискушенных людей — это фразы типа
"здесь нужен lwsync", повторённая 3 раза, или типа "Которого в данной
задаче, естественно, не будет" (ну "естественно", раз уж так
Gaperton сказал).
А люди из SUN, IBM, Intel, которые десятки лет занимаются
синхронизацией в ядрах ОС, виртуальных машинах, библиотеках поддержки,
не брезгают верить, слушать, просить лицензии на мои работы.
G>особенно если построить очередь на технике, подобной твоему mutex.
Опять трендёж. Ну давай, попробуй, построй. Хотя бы обрисуй алгоритм.
Это не возможно. В синхронизации всё не так просто, нельзя просто
взять 2 вещи и соединить. Так же как ты не можешь просто вот так взять
и применить технику иммутабельных/персистентых структур данных,
например, к вектору и сохранить при этом его свойства и малое число копирований.
G>Ты вообще плохо отдаешь себе отчет, с чем споришь.
Да, нет, я прекрасно понимаю с чем я спорю — с Gaperton'ом
R>> "Обкакался, так будь мужиком, блин, и имей смелость это признать"
(с) Gaperton
G>Как тебе однако хочется, чтобы я обкакался. Вот это называется обкакался. G>
G>А уж по поводу ситуации, где нам надо только считать данные — обмен
сообщениями (на любых очередях), так и останется медленнее на
несколько порядков.
Я за любое своё утверждение могу ответить и обосновать. Потому что я
на ходу не выдумываю, а чётко знаю о чём говорю. А если не знаю, то
молчу.
G>А то, что я не знаю, какой там нахрен барьер _ReadWriteBarrier(),
что послужило поводом твоей бурной радости
Ой, а уж тебя-то сколько радости вызвало, когда ты _ReadWriteBarrier()
подметил в коде. Звон услышал и понеслась шашка сверкать
G> — так всего знать невозможно
Конечно, нельзя. В этом нет никакой проблемы.
Просто нормальные адекватные люди, когда что-то не знают, либо вначале
разбираются, либо спрашивают, либо молчат. А не начинают пургу гнать,
да ещё выдавать её за истину, да ещё на основе своей пурги других
людей оскорблять.
G> (ты, к примеру, не знаешь про lwsync), да и в контексте общего
спора, в котором глупые тезисы выдвигаешь ты, а не я, это совершенно
не принципиально. Касательно того, что atomic_read, на котором eao
собирался решать эту задачу, медленнее обычного — это правда и
остается правдой, в данном случае нужен честный барьер в получателе
чтобы все работало.
Это хорошо, что ты вспомнил про lwsync. Ну что мы тут сдвинемся с
мёртвой точки? Твою фразу, что тут нужен lwsync, а на x86 надо ещё
какую store-load последовательность упорядочить уже все слышали 3
раза. Я же третий раз повторяю повторяю тебе свои простые и ясные
вопросы: в каком именно месте и для упорядочивания каких обращений
нужен lwsync? какую store-load последовательность требуется
упорядочить на стороне читателя?
Пока же это выглядит, что ты опять слышал какой-то звон, но не знаешь где он...
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Gaperton, Вы писали:
G>>Примерно так бы все и было. С незначительными нюансами туда-сюда.
E>Феерический рассказ о том, как Gaperton поспорил сам с собой и блестяще выиграл спор у самого себя.
Присоединяюсь к поздравлениям! Молодец, Gaperton, ты полностью себя порвал!
Здравствуйте, thesz, Вы писали:
R>>>Только один вопрос: fat tree — это ты про аппаратную реализацию, правильно? Если да, то тогда вопросов больше нет. R>>>А нет, вот ещё один: как делать динамический лоад-балансинг агентов между процессорами?
R>>Всё ясно: R>>
R>>...invented the fat tree interconnection network, a hardware-universal interconnection network...
R>>Понятно, что со специализированной аппаратной поддержкой чего угодно можно уехать далеко, и доказать потом превосходство этого над тем, что не имеет аппаратной поддержки. R>>Можно сказать: представь вся моя программа будет реализована в железе и будет занимать в программе одну инструкцию. Представь как она будет всё рвать!
T>Да ни-хе-ра.
T>Ты эту самую иерархию можешь сделать и программой. В случае программного решения тебе этого не избежать. Ни иерархии, ни её реализации.
Сделать-то, конечно, можно. Только смысл? Ты ж пытаешься скорость оптимизировать, а если ты своё решение не можешь сэмулировать быстро и с низкой латентностью, то вся твоя идея рассыпается.
T>А иначе будет так, как ты сказал — каждый тянется к каждому и все друг другу мешают работать постоянными блокировками.
Дело тут не с блокировках. Агентная система достаточно распределенная, плюс нет проблемы очереди сделать неблокирующими. Проблема в том, что каждая отправка сообщения имеет существенную стоимость и с ней надо считаться. Извини, но твоё решение на общее пока не тянет. И твой тезис "Её можно сделать сколь угодно мало требовательной путём группировки сообщений." в общем случае не выполняется.
Здравствуйте, thesz, Вы писали:
R>>Или ты имешь в виду, что ФИФО будет делаться на уровень выше? Векторные часы там? Подожди, ты о железе опять говоришь? Для софта это не будет работать — проще сразу класть в одну очередь. Если о железе — ну для железа видимо подходит — поиск минимального времени можно сделать за O(1) и т.д. Но железо меня не сильно интересует, я ж не с программатором сижу.
T>Нет, я не про железо.
Пока не похоже. Пока что ты обрисовал решение на *логическом* уровне. Попробуй обрисовать его *эффективную* реализацию на *физическом* уровне в софте для общего случая. Ты увидишь, что это сделать нельзя. То, что ты говоришь — это решение, но это решение либо для железа (ты ж оттуда эту идею взял?), либо для частных случаев в софте. Но не для общего случая в софте. Ты не можешь с таким решением выходить и громко заявлять, что ты решил какую-то общую проблему, и что "Её можно сделать сколь угодно мало требовательной путём группировки сообщений.".
Как ты будешь справляться со значительной внесённой латентностью? Кто будет рулить этими промежуточными узлами? Отдельные потоки, рабочие потоки этим нельзя нагружать, т.к. они могут обрабатывать сообщения долго. Отдельные процессоры выделять под эти потоки не целесообразно. Если они будут разделять процессоры с другими потоками, значит они могут шедулиться для выполнения через 40 мс и больше. Ну вот проходит такое сообщение через эту сеть и получаем внесённую латентность 200 мс.
Такой схемой ты порождаешь массу дополнительно трафика по протоколу когерентности. В традиционной схеме у нас сообщение сразу качует от кэша-источника в кэш-получателя. С твоей схемой оно покачает по N кэшей. Это чудовищный оверхед, проще сразу сделать одну атомарную RMW операцию и отправить сообщение получателю. Как ты предлагаешь это нивелировать?
Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
Динамический лоад-балансинг как будешь делать? Пока что ты увильнул статическим. Но это не катит для систем общего назначения. Обработка сообщений выполняется недетерминированнное время, зависит от входных данных, зависит от внешних систем, плюс часть процессоров периодически занимается другими процессами. Тот лоад-балансинг, который ты описал всасёт в такой ситуации — скорость работы системы будет определяться самым медленным процессором, а он может быть сколь угодно медленным.
Вобщем, пока ты никакой общей задачи не решил, и ничего нового не открыл. Я подобные решения применял, но в очень *частных* случаях, и оно не обобщается на общий случай.
Если можешь обрисовать решения всех проблем, которые я указал — то, пожалуйста. Буду очень признателен. И это будет, наверное, первая интересная и новая информация в этом топике.
Здравствуйте, Gaperton, Вы писали:
G>А потом кто-нибудь додумался бы до того, чтобы читать из разделяемого мутабельного массива, используемого в качестве индекса, атомарними ридами, и писать туда атомарными райтами с мемори барьером. Типо тогда что-то напоминающее транзакционную память получится.
Подожди, у нас же тут с атомарными чтениями должны быть какие-то дорогие барьеры памяти?
Или нет?
R>Дело тут не с блокировках. Агентная система достаточно распределенная, плюс нет проблемы очереди сделать неблокирующими. Проблема в том, что каждая отправка сообщения имеет существенную стоимость и с ней надо считаться. Извини, но твоё решение на общее пока не тянет. И твой тезис "Её можно сделать сколь угодно мало требовательной путём группировки сообщений." в общем случае не выполняется.
Вот смотрю я на ваш спор, и сразу на ум приходят Базы данных, где существуют и очереди для записи и разделяемая память без блокировок при применении версионности. (Причем версиооность нужна в во временном срезе создания отчета, где могут задействоваться большое число регистров)
Вспоминается и 1С восьмерка, где блокируются, а в юзерских реализациях создается очередь по сгруппированным по задействованным регистрам документы, что бы не ждать завершения транзакции, заранее зная о её успешности, или при неудачи время на доп обработку приемлемо для процесса.
Думаю все новшества в параллелизме внедряются там, или я очень многое упускаю?
и солнце б утром не вставало, когда бы не было меня
Re[58]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
R>>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
T>В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё
Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[59]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
ФИФО гарантируется для пары "автор-получатель", язык динамически типизированный, так что типы сообщений значения не имеют (если не учитывать более хитрые вещи аля вложенные receive).
Re[60]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Курилка, Вы писали:
E>>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
К>ФИФО гарантируется для пары "автор-получатель", язык динамически типизированный, так что типы сообщений значения не имеют (если не учитывать более хитрые вещи аля вложенные receive).
Про динамическую типизацию я в курсе Подразумевались конструкции вида:
Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[60]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, eao197, Вы писали:
E>>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
К>ФИФО гарантируется для пары "автор-получатель", язык динамически типизированный, так что типы сообщений значения не имеют (если не учитывать более хитрые вещи аля вложенные receive).
Ну тогда всё встаёт на свои места, я уж думал, что я совсем что-то важное упускал из вида, если Эрланг не гарантирует хоть какое-то ФИФО.
Аааа... понятно, почему он только per-producer fifo гарантирует, в сети не получится реализовать более строгий fifo. Хотя на SMP я бы предпочёл causal fifo.
Но даже с per-producer fifo будут проблемы при динамической балансировке нагрузке. Допустим переслали агнета на новый процессор. Дальше начинаем ему вслед пересылать сообщения, которые были отправлены ему ещё на старое место. Теперь надо эти сообщения, которые пошли вслед упорядочить с сообщениями, которые пошли этому агенту уже на новое место... Хммм... ну в общем случае это требует детектирования обще-системного quiescence point, что бы понять, что на старое место агенту сообщения уже не идут и не лежат ни в каких очередях в этой распределенной системе.
Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?
Здравствуйте, remark, Вы писали:
R>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?
немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации
Re[61]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, Вы писали:
R>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?
Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[62]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.
имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, C0s, Вы писали:
C0s>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"
Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, eao197, Вы писали:
E>>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.
C0s>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"
Это уже не асинхронный обмен сообщениями. Это уже RPC какой-то.
Это искуственное замедление системы. Зачем отправителю ждать, если он может сгенерировать сообщение сейчас. Зачем обязательно генерировать дополнительное подтверждение обработки предыдущего сообщения, зачем теперь занового шедулить агента отправителя, что бы он только сейчас сгенерировал второе сообщение. Плюс латентность существенно возростает. Фактически получается, что всё работает в одном потоке — вначале поток обрабатывает отправителя, потом устройство, потом опять отправителя и т.д.
Плюс это существенно снижает загрузку системы собщениями, а известно, что такие системы работают на полной мощности, только когда есть достаточный запас сообщений в системе.
Я не говорю, что такой подход сам по себе не имеет права на жизнь — зато во многих ситуациях он даёт большую простоту. Но это уж точно не то, о чём говорил thesz. Он говорил о ситуации когда у нас как раз все сообщения генерируются сразу.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, remark, Вы писали:
R>>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?
C0s>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации
Такой паттерн тоже есть, но он не охватывает много ситуаций. Фактически тут имеется множество *отдельных* *независимых* запросов и нам просто надо получить лоад-балансинг.
Один контр-пример привёл eao197. Другой, например, GUI прогресс-баг, который получает сообщения для обновления прогресса. Если мы получим вначале сообщение о 80% прогрессе, а потом о 20% прогресса, то мы в достаточно затруднительном положении. ... Понятно, конечно, что всё можно разрулить руками...
Здравствуйте, eao197, Вы писали:
E>Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.
выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно"
не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".
а из выделенного курсивом не должно следовать, что отправляющий команды имеет право, в том числе, поломать устройство некорректной последовательностью команд
возможна реализация, которая скроет логику неломаемости внутрь, но это приведёт к тому, что часть ордеров будет тихо отклонена — это тоже имеет право на жизнь. примерно как, если ты нажмёшь на пульте телевизора одновременно кнопки "предыдущий канал" и "следующий канал", телевизор сделает либо одно, либо другое, либо пульт проигнорирует оба нажатия
в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя
Re[64]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, Вы писали:
E>>>Допустим, агент управляет каким-то устройством (PCSC-ридером или GSM-модемом), подключенным к компьютеру. Агенту последовательно отправляют сообщения -- reset_device, set_params, write_data. А приходят они в виде set_params (когда устройство еще не проинициализировано), write_data и reset_device.
C0s>>имхо, это одна их те ситуаций, которая разруливается на уровне требований типа "нельзя выдавать новый ордер на устройство, если уже есть какой-либо ордер на то же устройство в статусе pending"
R>Это уже не асинхронный обмен сообщениями. Это уже RPC какой-то. R>Это искуственное замедление системы
да нет, я совсем не о скорости, а о том, что реальные софтверные системы на определённом не низком уровне часто имеют определённые бизнес-требования и бизнес-ограничения.
R>Это искуственное замедление системы. Зачем отправителю ждать, если он может сгенерировать сообщение сейчас. Зачем обязательно генерировать дополнительное подтверждение обработки предыдущего сообщения, зачем теперь занового шедулить агента отправителя, что бы он только сейчас сгенерировал второе сообщение. Плюс латентность существенно возростает. Фактически получается, что всё работает в одном потоке — вначале поток обрабатывает отправителя, потом устройство, потом опять отправителя и т.д.
и там присутствует борьба за скорость, но всегда в соответствии с требованиями
в частности (и мне такое доводилось делать), если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать в силу определённых ограничений — пожалуйста, ставим контроль ограничений на получателя
доводилось также делать многоступенчатую обработку, при которой была цепочка сообщений и, соответственно, цепочка получателей, каждый из которых проверял определённые условия, делал определённую работу и мог отсечь выполнение при несоблюдении каких-то условий
Re[65]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, C0s, Вы писали:
C0s>выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно" C0s>не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".
C0s>а из выделенного курсивом не должно следовать, что отправляющий команды имеет право, в том числе, поломать устройство некорректной последовательностью команд
C0s>возможна реализация, которая скроет логику неломаемости внутрь, но это приведёт к тому, что часть ордеров будет тихо отклонена — это тоже имеет право на жизнь. примерно как, если ты нажмёшь на пульте телевизора одновременно кнопки "предыдущий канал" и "следующий канал", телевизор сделает либо одно, либо другое, либо пульт проигнорирует оба нажатия
C0s>в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя
А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети...
На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.
Здравствуйте, C0s, Вы писали:
E>>Тот, кто генерирует управляющие сообщения для устройства может не иметь понятия о статусе ордеров. Он может просто знать, что устройство находится в его полном распоряжении и он может отправлять те команды, которые считает нужным. А делать на сообщениях двухфазные взаимодейтсвия типа запрос-ответ, временами, может быть слишком большим гемороем.
C0s>выделенное жирным имхо, слишком сильное требование из разряда "хочу большого интеллектуализма и бесплатно"
Мой опыт использования агентов как раз убеждает меня в том, что агенты и предназначены для достижения этой цели.
C0s>не в том смысле, что он должен прямо-таки разбираться в ордерах, но просто быть готовым к быстрому синхронному ответу "заявка не принята, попробуйте позже".
В принципе, этого может и не быть. Если агент-устройство диагностирует проблему, он может убить сам себя. Это спровоцирует агента-супервизора убить и тех, кто находится на связи с этим агентом (как раз генератора событий). А это спровоцирует еще одного агента-супервизора на рестарт всех ранее убитых агентов. Вполне нормальное, имхо, поведение для случаев, когда сбой в работе с оборудованием -- явление редкое и успешно лечится рестартом, или же не лечится программным путем вообще.
C0s>в сущности, речь о том, где контроль ставить — на стороне отправителя или на стороне получателя
Логика отправителя может очень сильно зависеть от того, как будет вести себя получатель. Хороший пример привел remark с прогресс-баром. Еще один пример -- один агент обслуживает TCP/IP канал (контроль к записи/чтению и операции ввода/вывода), а второй готовит исходящие данные (например, режет большой поток на пакеты). Если агент-канал вдруг получит сообщения с данными не в том порядке, в котором они ему приходили, то ничего хорошего из этого не получится.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, Вы писали:
C0s>>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации
R>Такой паттерн тоже есть, но он не охватывает много ситуаций. Фактически тут имеется множество *отдельных* *независимых* запросов и нам просто надо получить лоад-балансинг.
я лишь имел в виду, что лучше всего иметь действительно независимые запросы. т.е. стремиться к этому ещё на уровне выработки бизнес-требований и системного анализа до разраработки
если не получается, то вводятся промежуточные обработчики, или кто-то на стороне первоначального отправителя, которые должны контролировать и отсекать сообщения, которые не могут быть обработаны.
опять же, бывают интересные случаи (опять же доводилось так делать), когда сообщения отправляются обратно в ту же очередь с выставлением delay на следующую попытку redelivery — годится тогда, когда есть надежда, что в будущем сообщение сможет быть обработано, т.к. текущие ограничения на его обработку носят лишь временный характер, и с вероятностью 99% через delay пройдут
R>Другой, например, GUI прогресс-баг, который получает сообщения для обновления прогресса. Если мы получим вначале сообщение о 80% прогрессе, а потом о 20% прогресса, то мы в достаточно затруднительном положении. ... Понятно, конечно, что всё можно разрулить руками...
здесь легко разруливается на стороне получателя — он просто игнорирует сообщения о прогрессе со значением, меньшим текущего уже установленного в форме прогресса
Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, Вы писали:
R>А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети... R>На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.
на стороне получателя придётся ставить логику, которая будет игнорировать некоторые сообщения, либо откладывать их
Re[67]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, remark, Вы писали:
R>>А если эти 2 агента разнесены по сети, что ж мы теперь не можем 2 сообщения сразу отправить, и обязательно ждать двойного раунд-трипа по сети... R>>На примере сети это просто более явно видно, но те же тенденции сохраняются и на одной машине.
C0s>на стороне получателя придётся ставить логику, которая будет игнорировать некоторые сообщения, либо откладывать их
Я понимаю, что всё это можно сделать руками. Но что ты будешь делать в случае сетевого соединения? Правильно, восстанавливать ФИФО. Что ты будешь делать в случае с прогресс-баром? Правильно, восстанавливать ФИФО. Что ты будешь делать с сообщениями драйвера устройства? Правильно, восстанавливать ФИФО.
Я считаю, что этот паттерн настолко необходимый, что он должен быть просто по-умолчанию. При желании, если необходима скорость, то можно явно выборочно снизить требования до "произвольный порядок" (аналогия между TCP и UDP — кто в здравом уме использует для соединений UDP, если нет требований по производительности?). Ты, кстати, сказал, что ты не о скорости. Но если не о скорости, то зачем ты вообще смотришь в сторону НЕ ФИФО? Можешь пояснить. В любом случае тебе никто не мешает рассматривать ФИФО как частный случай произвольного порядка — не используй его гарантии и всё.
Здравствуйте, C0s, Вы писали:
C0s>Здравствуйте, remark, Вы писали:
R>>Кстати, Курилка, и все, кто работает с Эрланг и другими реализациями актёров или обмена сообщениями, как вы относитесь к идеи убрать любые гарантии ФИФО?
C0s>немного не в тему, может быть, но в высокоуровневых системах, построенных на обмене сообщениями, лично я всегда придерживался архитектур с более, чем одним потребителем, висящем на одной очереди (load balancing + failover), что автоматически отменяло возможность выдвигать требования обработки сообщений в порядке их генерации
Но не становится ли у тебя очередь нехилым ботлнеком с тучей (возможно конфликтующих) писателей/читателей?
Re[61]: пример eao197: "сообщения" рвут "разделяемую память"
E>Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?
Если это сообщения от одного отправителя — да.
Хотя есть некоторые ньюансы, см. здесь
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, remark, Вы писали:
R>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
можно представить себе такую систему. Есть обрабатывающие потоки и пишущие потоки. У обрабатывающего потока есть своя очередь для каждого пишущего потока, очередь для возврата результатов которые регестрируются при создании системы, и очередь при переполнении очереди на запись. Если у нас чтение неблокирующее и не зависит от записи (версионность), то обрабатывающие потоки выполняют чтение, если есть запись посылают в определенную очередь метод, и продолжают обрабатывать новые методы или возвращаемые из записывающих. В свою очередь записывающие обрабатывают очереди поочередно. Относительно очереди это будет ФИФО, а вот относительно времени поступления запроса, то нет
и солнце б утром не вставало, когда бы не было меня
Re[59]: пример eao197: "сообщения" рвут "разделяемую память"
T>>В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё
E>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
Не "пришло", а "послали".
Тогда — да.
Если они уже лежат в очереди процесса, то, по-моему, ФИФО.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[62]: пример eao197: "сообщения" рвут "разделяемую память"
E>>Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?
К>Если это сообщения от одного отправителя — да.
Во.
А у нас их несколько, в общем случае.
Так что можно считать, что и нет никакого ФИФО.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
E>>>Если процесс получил несколько сообщений вида {OK, D}, где D в каждом экземпляре сообщения имеет собственное значение (например, {OK, 2007}, {OK, 2008}, {OK, 2009}), то гарантирует ли Эрланг, что эти сообщения (т.е. {OK, D}) будут извлекаться из хранилища сообщений процесса в ФИФО?
К>>Если это сообщения от одного отправителя — да.
T>Во.
T>А у нас их несколько, в общем случае.
T>Так что можно считать, что и нет никакого ФИФО.
Ну то, что никакого — это ты загнул. Это в однопоточном окружении у нас либо ФИФО, либо нет ФИФО. А в многопоточном либо нет ФИФО, либо per-producer fifo, либо causal-fifo (happened-before fifo), либо best-effort fifo.
Эрланг вычёркиваем. Только не считай, что парировав аргумент про Эрланг, ты одновременно парировал и все остальные библиотеки, которые обеспечивают честный causal-fifo (happened-before fifo).
Здравствуйте, thesz, Вы писали:
E>>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
T>Не "пришло", а "послали".
Послали -- это другой случай.
Не очень представляю себе, как можно обеспечить ФИФО для отсылки сообщений разными отправителями без использования какого-либо вида глобальной синхронизации между ними (на основании меток времени или меток предшествования, к примеру).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[64]: пример eao197: "сообщения" рвут "разделяемую память"
T>>Так что можно считать, что и нет никакого ФИФО. R>Ну то, что никакого — это ты загнул. Это в однопоточном окружении у нас либо ФИФО, либо нет ФИФО. А в многопоточном либо нет ФИФО, либо per-producer fifo, либо causal-fifo (happened-before fifo), либо best-effort fifo.
R>Эрланг вычёркиваем. Только не считай, что парировав аргумент про Эрланг, ты одновременно парировал и все остальные библиотеки, которые обеспечивают честный causal-fifo (happened-before fifo).
Буду краток.
Наличие таких библиотек не говорит об эффективности программ с их использованием.
По некоторому размышлению выходит, что наоборот, проблем у них больше, чем получаемых решений.
Поэтому интересней рассматривать случай полного недетерминизма, который никак не ограничивает параллелизм, это раз (или надо применять спецсредства для его ограничения), и не требует поддержки дополнительного инварианта средой исполнения, это два.
С моей точки зрения, конечно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[61]: пример eao197: "сообщения" рвут "разделяемую память"
E>>>Правильно ли я понимаю, что если в Эрланге процессу пришло несколько однотипных сообщений, то Эрланг не гарантирует их выборку в receive в порядке ФИФО?
T>>Не "пришло", а "послали". E>Послали -- это другой случай. E>Не очень представляю себе, как можно обеспечить ФИФО для отсылки сообщений разными отправителями без использования какого-либо вида глобальной синхронизации между ними (на основании меток времени или меток предшествования, к примеру).
Я об этом же.
В общем случае, программу надо проектировать так, как будто нет никакого ФИФО.
Значит, его нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[62]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
T>В общем случае, программу надо проектировать так, как будто нет никакого ФИФО.
T>Значит, его нет.
Я смотрю на это со следующей точки зрения. Есть две составляющих механизма обмена сообщениями -- send и receive. Про send пока речь не идет, сейчас для меня важнее receive. Один из способов реализации receive -- это формирование для каждого агента (процесса, актера) очереди полученных им сообщений. Агент обращается к этой очереди и, если она не пуста, извлекает сообщение. Поэтому речь идет о том, обеспечиваются ли какие-либо ФИФО дисциплины по отношению к уже находящимся в очереди сообщениям.
Мое мнение состоит в том, что если для извлечения во время receive уже полученных агентом сообщений не обеспечивается ФИФО, то реализация целого ряда задач (управление оборудованием, например) будет крайне затруднена. И в таких условиях невыгодно заниматься проектированием в предположении об отсутствии ФИФО.
Что же до send-а, то у меня так же существует сильное подозрение, что если не будет обеспечиваться ФИФО доставки сообщений одного отправителя одному получателю, то реализация некоторого множества задач будет являться просто геморроем.
Выше речь шла о равноприоритетных сообщениях.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
E>Мое мнение состоит в том, что если для извлечения во время receive уже полученных агентом сообщений не обеспечивается ФИФО, то реализация целого ряда задач (управление оборудованием, например) будет крайне затруднена. И в таких условиях невыгодно заниматься проектированием в предположении об отсутствии ФИФО.
Ну вот та же миграция кода.
"Оборудование" (а вообще — некоторый процесс) узнало об изменении адреса узла доставки раньше, чем ранее обрабатывавший сообщения узел, и поэтому последний стал отправлять уже пришедшие сообщения позже. Получилось, что некоторые сообщения от оборудования пришли на обработку раньше своих предшественников.
Если мы жестко закладываемся на ФИФО, то у нас возникают трудности в реализации произвольного сценария. ФИФО здесь внешний инвариант, нами не обеспеченный, но нами используемый.
Это полезно, но это и уменьшает гибкость.
E>Что же до send-а, то у меня так же существует сильное подозрение, что если не будет обеспечиваться ФИФО доставки сообщений одного отправителя одному получателю, то реализация некоторого множества задач будет являться просто геморроем.
E>Выше речь шла о равноприоритетных сообщениях.
Понятно.
Я смотрю на всё это с точки зрения динамического потока данных.
В этом случае особой важности в ФИФО нет. Но там и состояния. как такового, тоже нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Мое мнение состоит в том, что если для извлечения во время receive уже полученных агентом сообщений не обеспечивается ФИФО, то реализация целого ряда задач (управление оборудованием, например) будет крайне затруднена. И в таких условиях невыгодно заниматься проектированием в предположении об отсутствии ФИФО.
Только совсем не обязательно при этом делать только ФИФО механику. Подобные задачки неплохо решаются при помощи обсуждаемых рядом фьючерсов — зависимость задач (сообщений) друг от друга задается наличием возвращаемого значения.
В более общем случае подобные ситуации разруливаются при помощи continuations. Если на пальцах, то к задаче (сообщению) по необходимости привязывается некий предикат, который определяет, может задача выполнится, или нет. При помощи такой механики можно строить сколь угодно хитрые цепочки зависимостей, и только там, где нужно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, eao197, Вы писали:
E>>Мое мнение состоит в том, что если для извлечения во время receive уже полученных агентом сообщений не обеспечивается ФИФО, то реализация целого ряда задач (управление оборудованием, например) будет крайне затруднена. И в таких условиях невыгодно заниматься проектированием в предположении об отсутствии ФИФО.
AVK>Только совсем не обязательно при этом делать только ФИФО механику. Подобные задачки неплохо решаются при помощи обсуждаемых рядом фьючерсов — зависимость задач (сообщений) друг от друга задается наличием возвращаемого значения.
Фьючерс -- это сторона отправителя. В процитированном абзаце я говорил только о стороне получателя.
AVK>В более общем случае подобные ситуации разруливаются при помощи continuations. Если на пальцах, то к задаче (сообщению) по необходимости привязывается некий предикат, который определяет, может задача выполнится, или нет. При помощи такой механики можно строить сколь угодно хитрые цепочки зависимостей, и только там, где нужно.
Может быть. Есть только у меня подозрение, что обеспечение ФИФО на стороне получателя будет приводить к более простым решениям (в плане телодвижений программиста), чем использование предикатов. Если же перейти к распределенным системам, где отправитель и получатель работают на разных узлах, то передача предиката в сообщении будет возможна не всегда.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[64]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
E>>Мое мнение состоит в том, что если для извлечения во время receive уже полученных агентом сообщений не обеспечивается ФИФО, то реализация целого ряда задач (управление оборудованием, например) будет крайне затруднена. И в таких условиях невыгодно заниматься проектированием в предположении об отсутствии ФИФО.
T>Ну вот та же миграция кода.
T>"Оборудование" (а вообще — некоторый процесс) узнало об изменении адреса узла доставки раньше, чем ранее обрабатывавший сообщения узел, и поэтому последний стал отправлять уже пришедшие сообщения позже. Получилось, что некоторые сообщения от оборудования пришли на обработку раньше своих предшественников.
Не очень понимаю, о чем ты говоришь. Не могу представить себе реальный пример этого сценария
T>Если мы жестко закладываемся на ФИФО, то у нас возникают трудности в реализации произвольного сценария. ФИФО здесь внешний инвариант, нами не обеспеченный, но нами используемый.
Можно еще одну ситуацию вспомнить. Допустим, у нас есть агенты s и r. Они работают на узлах A и B (имеются в виду узлы локальной сети). Но эти узлы соеденены не напрямую, а через несколько других узлов. И путь от A к B может лежать через маршрут A -> D -> E -> B или через маршут A -> C -> B. Агент s с узла A отправляет сообщения m1, m2, m3. Сообщения m1 и m3 уходят по маршруту A->D->E->B, а сообщение m2 -- по маршруту A->C->B. В этом случае сообщения r может получить как m2, m1, m3, так и m1, m3, m2, так и m1, m2, m3. Если логика взаимодействия s и r построена на гарантиях ФИФО для сообщений от одного источника, то все накрывается медным тазом.
T>Я смотрю на всё это с точки зрения динамического потока данных.
Я заметил, что мы находимся сильно в разных предметных областях. Отчего временами мне сложно понимать тебя. В частности, я мало чего понял из твоей статьи, ссылку на которую ты дал remark-у (с обсуждением задачи перемножения матриц на динамическом потоке данных).
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[65]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Фьючерс -- это сторона отправителя. В процитированном абзаце я говорил только о стороне получателя.
Только отправитель знает, что определенные сообщения должны дойти в определенном порядке.
E>Может быть. Есть только у меня подозрение, что обеспечение ФИФО на стороне получателя будет приводить к более простым решениям (в плане телодвижений программиста)
И оно же будет приводить к тому, что у лоад балансера будет намного меньше возможностей. И, что касается телодвижений — их нужно будет сделать один раз. Зато там, где ФИФО не нужно его не будет. А там, где простенькая схема ФИФО не обеспечивает нужной эффективности, всегда можно сделать что то более хитрое.
E>передача предиката в сообщении будет возможна не всегда.
Почему?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
T>>"Оборудование" (а вообще — некоторый процесс) узнало об изменении адреса узла доставки раньше, чем ранее обрабатывавший сообщения узел, и поэтому последний стал отправлять уже пришедшие сообщения позже. Получилось, что некоторые сообщения от оборудования пришли на обработку раньше своих предшественников. E>Не очень понимаю, о чем ты говоришь. Не могу представить себе реальный пример этого сценария
Твой пример тоже неплох, надо сказать.
T>>Я смотрю на всё это с точки зрения динамического потока данных. E>Я заметил, что мы находимся сильно в разных предметных областях. Отчего временами мне сложно понимать тебя. В частности, я мало чего понял из твоей статьи, ссылку на которую ты дал remark-у (с обсуждением задачи перемножения матриц на динамическом потоке данных).
Это дело я думаю исправить, но всё никак руки не дойдут.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Фьючерс -- это сторона отправителя. В процитированном абзаце я говорил только о стороне получателя.
AVK>Только отправитель знает, что определенные сообщения должны дойти в определенном порядке.
А получатель извлекает запросы из своей очереди в порядке WriteData, SetParams, ResetDevice. Даже не смотря на порядок отсылки отправителем. Имеет ли какой-то смысл то, что одноприоритетные сообщения перепутываются уже в очереди получателя? Или же ФИФО на стороне получателя -- это нормальное пожелание?
E>>Может быть. Есть только у меня подозрение, что обеспечение ФИФО на стороне получателя будет приводить к более простым решениям (в плане телодвижений программиста)
AVK>И оно же будет приводить к тому, что у лоад балансера будет намного меньше возможностей.
Load Balancer -- это слишком общее понятие. Боюсь, без более четкого органичения предметной области обсуждать load balancer-ы не имеет смысла.
E>>передача предиката в сообщении будет возможна не всегда.
AVK>Почему?
Если предикат -- это функция, т.е. код, то при использовании нативного кода на узлах, работающих на разных платформах, мы получаем проблему.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[67]: пример eao197: "сообщения" рвут "разделяемую память"
Налицо некоторое непонимание того, что такое фьючерс. Должно быть как то так:
var reset =
new Future(() => ResetDevice(...))
.ContinueWith(() => SetParams(...))
.ContinueWith(() => WriteData(...));
AVK>>И оно же будет приводить к тому, что у лоад балансера будет намного меньше возможностей.
E>Load Balancer -- это слишком общее понятие.
Оно достаточно специализированно, для того чтобы понять, что жесткое ограничение фифой сильно свяжет ему руки. Тот же work stealing, к примеру, пойдет лесом.
E> Боюсь, без более четкого органичения предметной области обсуждать load balancer-ы не имеет смысла.
Предметная область достаточно ограничена — распределение задач обработки сообщений по имеющимся аппаратным потокам.
E>>>передача предиката в сообщении будет возможна не всегда.
AVK>>Почему?
E>Если предикат -- это функция, т.е. код, то при использовании нативного кода на узлах, работающих на разных платформах, мы получаем проблему.
Это решаемо. Например, в C# есть expression tree, в F# собственная похожая механика, в С++ уродец из буста. А в интерпретируемых языках можно просто передавать исходник.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Кроме того, все это несколько завуалированный механизм RPC. При его использовании решение получается несколько иным, чем при асинхронных сообщениях.
AVK>>>И оно же будет приводить к тому, что у лоад балансера будет намного меньше возможностей.
E>>Load Balancer -- это слишком общее понятие.
AVK>Оно достаточно специализированно, для того чтобы понять, что жесткое ограничение фифой сильно свяжет ему руки. Тот же work stealing, к примеру, пойдет лесом.
Это общие слова.
E>> Боюсь, без более четкого органичения предметной области обсуждать load balancer-ы не имеет смысла.
AVK>Предметная область достаточно ограничена — распределение задач обработки сообщений по имеющимся аппаратным потокам.
Думаю, что если под сообщениями будет пониматься обработка HTTP-запросов, взаимодействие с PCSC-ридерами или шифрование данных, то подходы к распределению сообщений и балансировке нагрузки могут несколько отличаться друг от друга.
E>>Если предикат -- это функция, т.е. код, то при использовании нативного кода на узлах, работающих на разных платформах, мы получаем проблему.
AVK>Это решаемо. Например, в C# есть expression tree, в F# собственная похожая механика, в С++ уродец из буста. А в интерпретируемых языках можно просто передавать исходник.
Это если задача позволяет использовать у себя кодогенерацию/интерпритацию и передачу кода между узлами.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[69]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>А это где такой фьючерс?
Конкретно в моем примере это TPL. Но это неважно, я хотел просто идею продемонстрировать.
E>Кроме того, все это несколько завуалированный механизм RPC.
Неа, RPC тут совсем никаким боком. Это совершенно обычный фьючерс.
E>Это общие слова.
Это не общие слова, это вполне конкретные вещи. Почитай по ссылочке, там вообще применительно к вполне конкретному Cilk описано.
E>Это если задача позволяет использовать у себя кодогенерацию/интерпритацию и передачу кода между узлами.
А почему она может не позволять?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>А это где такой фьючерс?
AVK>Конкретно в моем примере это TPL.
Понятно, просто я в C++ных примерах использования future никогда не видел continueWith.
E>>Кроме того, все это несколько завуалированный механизм RPC.
AVK>Неа, RPC тут совсем никаким боком. Это совершенно обычный фьючерс.
Аналогия с RPC тут в том смысле, что запуск SetParams(...) и WriteData(...) будет произведен только после получения сигнала об окончании (по каким-либо принчинам) работы ResetDevice(). Т.е. обработчик ResetDevice должен будет послать в ответ какой-то сигнал. Что очень похоже на механизм call/return (а поскольку call передает управление другому процессору/узлу, то это очень похоже на remote).
AVK>Это не общие слова, это вполне конкретные вещи. Почитай по ссылочке, там вообще применительно к вполне конкретному Cilk описано.
А каким боком Cilk к модели обмена сообщениями относится?
E>>Это если задача позволяет использовать у себя кодогенерацию/интерпритацию и передачу кода между узлами.
AVK>А почему она может не позволять?
Например, по соображениям безопасности (один из узлов находится внутри банка, а второй -- снаружи) или скорости работы.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[67]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, AndrewVK, Вы писали:
E>>>Фьючерс -- это сторона отправителя. В процитированном абзаце я говорил только о стороне получателя.
AVK>>Только отправитель знает, что определенные сообщения должны дойти в определенном порядке.
E>Смотри, пусть отправитель вызывает: E>
Это вредный пример. Зачем делать такой протокол?
Пусть отправитель шлет sendWriteDataWithParams(params, data).
А получатель самостоятельно делает resetDevice.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Понятно, просто я в C++ных примерах использования future никогда не видел continueWith.
AVK>Интересно, ты вообще мое исходное сообщение читал?
Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?
AVK> Я ведь именно об этом и писал.
От того, что у .NET-овского фьючерса появился continueWith, он не стал каким-то особенным фьючерсом.
E>>А каким боком Cilk к модели обмена сообщениями относится?
AVK>Это пример одной из методик балансинга — work stealing.
Только в Cilk-е выполняется "кража" фрагментов стека. А в модели агентов будет просто другой подход.
AVK>Ее же можно для агентов применять, если мы агентов используем для распараллеливания вычислений.
Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться. При вычислениях, не завязанных на состояние, это будет нормально работать.
А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).
AVK>Ты ведь еще исходную тему топика, надеюсь, не забыл?
Я думал, мы здесь сейчас обсуждаем вопрос remark-а к пользователям различных систем на обмене сообщений о необходимости сохранения ФИФО вообще.
AVK>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.
Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[68]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
S>Пусть отправитель шлет sendWriteDataWithParams(params, data). S>А получатель самостоятельно делает resetDevice.
Это не всегда возможно. Так же, как не всегда известно на момент отправки setParams, какие данные затем будут записаны. Так же, как не всегда при отсылке данных известно, какие параметры нужно передавать устройству.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Можно еще одну ситуацию вспомнить. Допустим, у нас есть агенты s и r. Они работают на узлах A и B (имеются в виду узлы локальной сети). Но эти узлы соеденены не напрямую, а через несколько других узлов. И путь от A к B может лежать через маршрут A -> D -> E -> B или через маршут A -> C -> B. Агент s с узла A отправляет сообщения m1, m2, m3. Сообщения m1 и m3 уходят по маршруту A->D->E->B, а сообщение m2 -- по маршруту A->C->B. В этом случае сообщения r может получить как m2, m1, m3, так и m1, m3, m2, так и m1, m2, m3. Если логика взаимодействия s и r построена на гарантиях ФИФО для сообщений от одного источника, то все накрывается медным тазом. S>Вот мне в этом плане вот что интересно: протокол IP как раз описывает ровно эту ситуацию. S>И есть традиционное решение для построения на нём FIFO порядка, которое не требует никакой синхронизации "в середине", широко известное под аббревиатурой TCP.
Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.
В случае отсылки сообщений, если в сообщениях не заданы эти параметры предшествования/упорядочения самим разработчиком, информации для восстановления порядка отсылки сообщений нет. Можешь увидеть это на примере SMTP -- если ты отправляешь одному и тому же получателю несколько писем, то они могут придти к получателю в разном порядке (особенно, если сообщения сильно различаются по размеру).
Сделать так, чтобы транспортный протокол, используемый для передачи сообщений, поддерживал дисциплину ФИФО можно (для случая signle-producer->single-consumer и single-node-producers->single-consumer). И, если разработчик нуждается в подобной дисциплине, он должен проверить, поддерживает ли ее используемый им инструмент.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[69]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Это не всегда возможно. Так же, как не всегда известно на момент отправки setParams, какие данные затем будут записаны. Так же, как не всегда при отсылке данных известно, какие параметры нужно передавать устройству.
На мой взгляд, это очень странно. Ты только что написал пример. Даже если между строчками происходит масса всякой вредной деятельности, мне очень странно, что к моменту отправки writeData отправитель уже забыл, что за параметры он отправлял в прошлый раз. Если между ними нет зависимости, то и порядок прихода будет неважен. А если есть, то потерять их можно только специально. Я не вижу никакой нужды в этом.
Это примерно то же самое, что удаленная CУБД по сравнению с файловой системой. То есть клиент начинает слишком сильно заморачиваться передачей низкоуровневых деталей серверу. Это вредно, т.к. создает лишний трафик, а в нашем случае еще и порождает вопросы синхронизации.
Простой пример: протокол DNS не использует идеологии "удаленного чтения файла зоны". Он полностью асинхронный, и всё прекрасно работает, несмотря на отсутствие какого-либо FIFO.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[70]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
S>На мой взгляд, это очень странно. Ты только что написал пример. Даже если между строчками происходит масса всякой вредной деятельности, мне очень странно, что к моменту отправки writeData отправитель уже забыл, что за параметры он отправлял в прошлый раз. Если между ними нет зависимости, то и порядок прихода будет неважен. А если есть, то потерять их можно только специально. Я не вижу никакой нужды в этом.
Вот вполне реальный сценарий. Есть железяка, которая подключена к выделенному узлу сети. На этом узле работает часть софта, отвечающая только за взаимодействия с железякой. Есть другой узел, на котором работает основной софт. Этот основной софт взаимодействует с выделенным узлом и, следовательно, с железякой, посредством обмена сообщениями.
В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)). И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку. После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data.
В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[68]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя. S>Полностью корректна. Еще раз: если отправителю/получателю важно, в каком порядке приходят сообшения, он просто добавляет в сообщения seq number.
Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7? Или обработать сообщение с номером 8, а затем проигнорировать сообщения с меньшими seq_number-ами?
Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр.
S>Еще раз намекаю, что с моей точки зрения, не стоит запихивать поддержку FIFO прямо в самый-самый нижний слой системы. Достаточно сделать удобные библиотеки, позволяющие описывать протокол взаимодействия.
Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке. Даже с использованием selective receive, как в Эрланге -- сначала рассматривается m1, затем m2, затем m3. Если было извлечено m2, то следующий receive будет рассматривать m1, затем m3.
И я не вижу смысла в том, чтобы на стороне получателя уже находящиеся в его очереди сообщения извлекались не в FIFO порядке. К библиотекам, описывающим протокол взаимодействия это вообще практически не имеет отношения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[69]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7?
Конечно. Восьмое складывается во внутренний список и откладывается до момента прихода недостающих. Я же сказал — всё как в TCP.
E>Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр.
Всё как раз наоборот: если разработчик "знает", значит номерами их нагрузил транспорт. Только транспорт нагрузил все сообщения, а не только те, где важен порядок.
С моей точки зрения, это — преждевременная пессимизация.
E>Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке.
Непонятно, что значит "встали". Если это сообшения от разных отправителей, у которых нет скоординированного источника времени, то говорить об их порядке — бессмысленно. Ну вот тебе неожиданный пример: есть SQL. В нём нет никакого "естественного порядка записей". Если хочешь их упорядочить — сделай order by. Если хочешь сортировать по "порядку вставки" — придется делать поле "номер по порядку вставки". Но сам сервер за тебя это не обеспечивает. Ибо нефиг.
E>И я не вижу смысла в том, чтобы на стороне получателя уже находящиеся в его очереди сообщения извлекались не в FIFO порядке. К библиотекам, описывающим протокол взаимодействия это вообще практически не имеет отношения.
Видишь ли, я не хочу оперировать терминами навроде "уже находящиеся". С моей точки зрения, очередь — это в первую голову некий интерфейс.
А каков механизм хранения примитивов — дело десятое. Физически входящая очередь может состоять из набора очередей, каждая из которых посвящена одному отправителю. Благодаря этому можно обойтись без излишней синхронизации, т.к. два отправителя могут помещать туда сообщения, никак не договариваясь друг с другом.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[70]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Ну вставят они этот seq_number и что? Получит получатель сначала сообщение с номером 1, а затем с номером 8. И что он должен делать с этим сообщением? Ждать сообщений с номерами 2-7? S>Конечно. Восьмое складывается во внутренний список и откладывается до момента прихода недостающих. Я же сказал — всё как в TCP.
Ну и так отсекается целый ряд задач, где выгоднее просто выбрасывать выбившиеся из своего порядка сообщения. Например, при отображении progress-bar-а, при потоковом вещании, при on-line мониторинге и пр.
E>>Имхо, гораздо меньше проблем будет у разработчика, если он знает, что его транспорт обеспечивает FIFO. Тогда не нужно будет нагружать сообщения разными порядковыми номерами и пр. S>Всё как раз наоборот: если разработчик "знает", значит номерами их нагрузил транспорт. Только транспорт нагрузил все сообщения, а не только те, где важен порядок.
Поскольку разработчик сам не занимается номерами, то ему без разницы, как порядок обеспечивает транспорт.
S>С моей точки зрения, это — преждевременная пессимизация.
Может быть.
E>>Я вообще потерял нить разговора. Про FIFO я здесь пока говорил только применительно к извлечению уже полученных сообщений из очереди агента/процесса. Т.е. если в очередь к агенту уже встали равноприоритетные сообщения m1, m2, m3, то и извлекаться они должны имено в этом порядке. S>Непонятно, что значит "встали". Если это сообшения от разных отправителей, у которых нет скоординированного источника времени, то говорить об их порядке — бессмысленно.
"Встали" -- это значит оказались в хранилище сообщений из которых они забираются затем методом receive (или аналогичным ему).
S>А каков механизм хранения примитивов — дело десятое. Физически входящая очередь может состоять из набора очередей, каждая из которых посвящена одному отправителю. Благодаря этому можно обойтись без излишней синхронизации, т.к. два отправителя могут помещать туда сообщения, никак не договариваясь друг с другом.
Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[71]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)).
Не очень понятно, почему это обнаруживает не "локальная" часть софта, а какой-то "посторонний" узел сети. E>И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку.
Это два совершенно разных события. Почему ты думаешь, что порядок их получения важен?
E>После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data. E>В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data.
Совершенно верно. Ты привел пример независимых сообщений. Для них порядок не нужен.
Если порядок всё же важен, то сообщения можно объединить. Если имеет смысл структурное объединение, то можно просто склеить сообшения.
Пример: не имеет смысла делать reset_device в одиночку, потому что после него параметры приходят в неопределенное состояние. Значит, надо сразу делать ResetWirhParams.
Пример 2: нам не всё равно, с какими параметрами передавать данные. Значит, надо делать WriteDataWithParams.
Пример 3: накладные расходы на параметры в каждом пакете слишком велики, и мы хотим воспользоваться statefullness принимающего агента (что, конечно же, вредно, но если очень хочется, то рюмочку можно). Ок, тогда мы вводим в протокол порядок сообщений.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>В какой-то момент времени основной софт обнаруживает, что от железяки слишком долго не было никакой информации (такое бывает -- сама железяка подает признаки жизни и обмены с ней проходят корректно, но ничего полезного не происходит (некоторые GSM-модемы временами так "теряют" сеть)). S>Не очень понятно, почему это обнаруживает не "локальная" часть софта, а какой-то "посторонний" узел сети.
Потому, что локальная часть софта может не видеть всей картины в целом. Если устройство нормально отвечает и присылает какие-то пакеты, то для локальной части устройсво выглядит нормально. А для всей системы может быть очевидно, что устройство не выдает "значимой" информации в течении долгого времени.
E>>И отправляет команду reset_device -- в 99.9% процентах случаев это помогает. Затем основному софту приходит команда reconfigure с новыми параметрами. Эта команда в конце-концов приводит к отсылке set_params на железяку. S>Это два совершенно разных события. Почему ты думаешь, что порядок их получения важен?
Потому что для отправителя факт reset_device предшествует факту set_params.
E>>После чего основной софт может получить потребность в отправке каких-то данных на железяку -- это делается посредством write_data. E>>В таком случае нет необходимости заменять write_data на сообщение set_params_and_write_data. S>Совершенно верно. Ты привел пример независимых сообщений. Для них порядок не нужен.
Ну да. Начальник пишет подчиненному по e-mail: "Со стороны заказчика с нами теперь будет взаимодействовать не Иванов Иван Иванович, а Сидоров Сидор Сидорыч, его контактная информация вот такая: ...". Через какое-то время начальник дает подчиненному задание по e-mail: "Проинформируй заказчика о том, что нам потребуется увеличение финансирования по этапу X на Y процентов". Можно ли считать эти e-mail-ы независимыми, для которых порядок не нужен? Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного?
S>Пример: не имеет смысла делать reset_device в одиночку, потому что после него параметры приходят в неопределенное состояние. Значит, надо сразу делать ResetWithParams.
Тогда нет смысла в прикладном сообщении reset_device без параметров. Это означает, что в reset_device параметры будут. И так же это значит, что управляющему агенту придется хранить у себя параметры устройства постоянно, чтобы иметь их под рукой при необходимости отослать reset_device.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[73]: пример eao197: "сообщения" рвут "разделяемую память"
E>Потому, что локальная часть софта может не видеть всей картины в целом. Если устройство нормально отвечает и присылает какие-то пакеты, то для локальной части устройсво выглядит нормально. А для всей системы может быть очевидно, что устройство не выдает "значимой" информации в течении долгого времени.
Ок, принято.
E>Ну да. Начальник пишет подчиненному по e-mail: "Со стороны заказчика с нами теперь будет взаимодействовать не Иванов Иван Иванович, а Сидоров Сидор Сидорыч, его контактная информация вот такая: ...". Через какое-то время начальник дает подчиненному задание по e-mail: "Проинформируй заказчика о том, что нам потребуется увеличение финансирования по этапу X на Y процентов". Можно ли считать эти e-mail-ы независимыми, для которых порядок не нужен? E>Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного?
Если начальник — педант, то будет.
Но пойми, мы же говорим не об абстрактном "жонглировании сообщениями". Речь идет о некотором протоколе. Который и определяет, порядок каких сообщений важен, а каких — неважен. Этот протокол обязаны соблюдать и отправитель, и получатель. Получатель просто будет игнорировать нарушения протокола и всё.
В примере, который ты привел, нет никакой гарантии, что порядок сообщений важен. К примеру, мне до сих пор приходят письма по вопросам, связанным с моей деятельностью две должности назад. Это означает, что отправителю не пришло письмо от его начальника "Теперь с нами будет взаимодействовать не Антон, а Сергей"
Ничего страшного не происходит — я перенаправляю письма Сергею.
Если бы это было страшно, то начальник отправителя позаботился бы о том, чтобы все сообщения были упорядочены.
E>Тогда нет смысла в прикладном сообщении reset_device без параметров. Это означает, что в reset_device параметры будут.
Правильно! Вот видишь — ты всё понимаешь. E>И так же это значит, что управляющему агенту придется хранить у себя параметры устройства постоянно, чтобы иметь их под рукой при необходимости отослать reset_device.
Совершенно верно — если ему важны параметры, он обязан их предоставлять. Если не важны — то ему не страшно, если параметры будут сброшены.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[71]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Ну и так отсекается целый ряд задач, где выгоднее просто выбрасывать выбившиеся из своего порядка сообщения. Например, при отображении progress-bar-а, при потоковом вещании, при on-line мониторинге и пр.
Нет, ничего не отсекается. Я же не предлагаю захардкодить поддержку FIFO в платформу — это ваша с ремарком позиция.
Я как раз наоборот — предлагаю разработчику самостоятельно определять политику упорядочивания сообщений. Например, с помощью библиотек.
В частности, может быть FIFO, может быть LastOneRules или другие произвольные трактовки.
E>Поскольку разработчик сам не занимается номерами, то ему без разницы, как порядок обеспечивает транспорт.
Я сейчас говорю о том, чтобы не заниматься предоставлением дорогостоящих гарантий до того, как их закажет разработчик.
E>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали? Ты опять про "туда встали"? Это интимная подробность функционирования очереди. В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен. Зачем? Мы же стремимся к максимизации быстродействия, а ее главный лозунг — "если можешь — не делай!".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[74]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Какова вероятность того, что начальник будет нумеровать подобные письма для подчиненного? S>Если начальник — педант, то будет.
Ну вот в том-то и дело, что начинаются требования к участникам взаимодействия. В тоже время, хочется, чтобы при использовании механизма обмена сообщениями этих требований было как можно меньше. Ну тут как с со сборкой мусора в языке программирования -- ее наличие делает решение целого ряда задач гораздо более простой, надежной и, временами, более производительной. FIFO по умолчанию для single-producer->single-consumer, как мне кажется, является как раз удобным способом для решения задач на основе обмена сообщениями с минимальными требованиями к участникам взаимодействия.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
S>Нет, ничего не отсекается. Я же не предлагаю захардкодить поддержку FIFO в платформу — это ваша с ремарком позиция. S>Я как раз наоборот — предлагаю разработчику самостоятельно определять политику упорядочивания сообщений. Например, с помощью библиотек.
Так собственно, по большей части здесь и идет речь о функциональности, которая обеспечивается библиотеками. Поскольку промышленных языков, где обмен сообщениями реализован на уровне языка один, может быть два
S>В частности, может быть FIFO, может быть LastOneRules или другие произвольные трактовки.
Опять не понимаю, о чем мы спорим
То, что политики могут быть разными -- это очевидно. И если используемая библиотека обмена сообщениями может поддерживать их несколько, да еще одновременно, так это вообще замечательно.
Что мне хочется иметь, так это то, что если агентам S и R требуется FIFO, то они бы заказали это у своей библиотеки и она бы им эту политику предоставила. И чтобы агентам S и R не приходилось заморачиваться на выставление меток времени в своих сообщениях -- это вполне может быть сделано на низком уровне. Т.е. требования FIFO не должны сказываться на структуре сообщений, которыми обмениваются S и R.
E>>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали? S> Ты опять про "туда встали"? Это интимная подробность функционирования очереди.
Вероятно, это связано с тем, что мне эти интимные подробности приходится реализовывать.
S> В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен.
Понятно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Опять не понимаю, о чем мы спорим
E>То, что политики могут быть разными -- это очевидно. И если используемая библиотека обмена сообщениями может поддерживать их несколько, да еще одновременно, так это вообще замечательно.
Значит — разногласий нет. Это замечательно.
E>Что мне хочется иметь, так это то, что если агентам S и R требуется FIFO, то они бы заказали это у своей библиотеки и она бы им эту политику предоставила. И чтобы агентам S и R не приходилось заморачиваться на выставление меток времени в своих сообщениях -- это вполне может быть сделано на низком уровне. Т.е. требования FIFO не должны сказываться на структуре сообщений, которыми обмениваются S и R.
С этим я не спорю. Вопрос, в общем-то, в том, кто и как будет определять протокол. И как потом им пользоваться.
Некоторые разработки на эту тему были, насколько я помню, внедрены в MS SQL Server ажно 2005.
E>Вероятно, это связано с тем, что мне эти интимные подробности приходится реализовывать. Ок.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[75]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали: E>Ну вот в том-то и дело, что начинаются требования к участникам взаимодействия. В тоже время, хочется, чтобы при использовании механизма обмена сообщениями этих требований было как можно меньше. Ну тут как с со сборкой мусора в языке программирования -- ее наличие делает решение целого ряда задач гораздо более простой, надежной и, временами, более производительной. FIFO по умолчанию для single-producer->single-consumer, как мне кажется, является как раз удобным способом для решения задач на основе обмена сообщениями с минимальными требованиями к участникам взаимодействия.
В принципе, похоже что да. По крайней мере, обеспечение FIFO в таком случае должно гарантироваться каким-то нетрудоёмким способом.
Тот пример с ручной нумерацией сообщений, который я привел, конечно же неработоспособен. Должно быть что=то более простое.
А вот FIFO для общего случая хитрой топологии может оказаться overkill. А может и нет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[76]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
S>В принципе, похоже что да. По крайней мере, обеспечение FIFO в таком случае должно гарантироваться каким-то нетрудоёмким способом. S>Тот пример с ручной нумерацией сообщений, который я привел, конечно же неработоспособен. Должно быть что=то более простое. S>А вот FIFO для общего случая хитрой топологии может оказаться overkill. А может и нет.
Ну здесь я более-менее четко могу говорить только о своих разработках и своем опыте программирования агентов и с помощью агентов. Так вот, если агенты взаимодействуют друг с другом в рамках одного процесса, то обеспечение FIFO, тривиально, если у агента-получается очередь принятых сообщений одна. Здесь получается как с логированием: в двух нитях для одного объекта-логгера вызывается метод info(), а уже в каком порядке сообщения лягут в log-файл, это уж как нити лягут . Но важно то, что если одна и та же нить последовательно вызвает info() для объекта логгера, то ее записи не перепутаются.
Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет.
А вот если таких каналов несколько или же агенты соеденены не на прямую, а через посредников, тогда ситуация усложняется. В принципе, если каждому рантайму назначать свой GUID, и в каждом рантайме назначать последовательно возрастающие счетчики экземплярам отсылаемых сообщений, то на стороне получателя мы имеем возможность собирать сообщения в нужном порядке на основании GUID-ов и счетчиков. Хотя пока это у меня еще не реализовано , но потребность в подобной штуке начинает уже ощущаться.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[64]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, thesz, Вы писали:
E>>Выше речь шла о равноприоритетных сообщениях.
T>Понятно.
T>Я смотрю на всё это с точки зрения динамического потока данных.
T>В этом случае особой важности в ФИФО нет. Но там и состояния. как такового, тоже нет.
А ну тогда понятно, почему тебе не важен порядок и почему ты решил задачу для посылки сообщений в общем случае
Датафлоу, или то, что в программном мире называется task-based parallelism, не требует никакого порядка, в смысле, что термин порядок вообще для него не релевантен, элементы работы (задачи) выполняются как только для них готовы аргументы. Да и вообще, сама пересылка сообщений тут тоже не релевантна, т.к. нет отдельных данных (агентов), соотв. у них нет местоположения, соотв. и посылать даже некуда.
Редукция модели актёров до датафлоу (task-based) следующая: актёр за свою жизнь получает одно и только одно сообщение, соотв. актёр совмещён с этим своим сообщением. Упорядочивания нет, т.к. среди одного сообщения нет порядка, и в то же время на одно сообщение можно наложить любой порядок. Посылок сообщений нет — актёр шедулится либо там где он создаётся, если все данные уже есть в это время; либо тогда и там же когда/где готов последний аргумент.
T>Почему не могу. Могу. Смотри.
T>Громко заявляю, что я решил какую-то общую проблему, и что "её можно сделать сколь угодно мало требовательной путём группировки сообщений".
Ну давай посмотрим.
R>>Как ты будешь справляться со значительной внесённой латентностью? Кто будет рулить этими промежуточными узлами? Отдельные потоки, рабочие потоки этим нельзя нагружать, т.к. они могут обрабатывать сообщения долго.
T>Так не надо, чтобы долго обрабатывали. Надо, чтобы недолго.
Как мне быстро обрабатывать блокирующий вызов на ККМ или на принтер OPOS? Ну нет у меня драйверов неблокирующих. Как мне делать вызовы в сторонние библиотеки?
Мы ж по прежнему об *общем* случае говорим, правильно?
T>Более того, динамический поток данных даёт возможность рулить размером программы сообщения. Можно балансировать — чем больше входов у узла, тем больше будет программа узла и меньше выявляемый параллелизм выше уровня ILP. И наоборот.
На это я даже и не знаю, что ответить в контексте общего случая... Кстати, ты представляешь какой минимальный размер сообщения получится даже если очень хорошо реализовать твою схему в софте и считать, что оверхед должен быть не более 5%?
R>> Отдельные процессоры выделять под эти потоки не целесообразно. Если они будут разделять процессоры с другими потоками, значит они могут шедулиться для выполнения через 40 мс и больше. Ну вот проходит такое сообщение через эту сеть и получаем внесённую латентность 200 мс.
T>Да.
Ты видишь разницу между общим случаем и только throughput-oriented HPC????????
Вот именно, что ДА — 200 мс. Значит GUI — лесом, приложения для биржевой торговли — лесом, игры — лесом. Ну и где тут общий случай?
R>>В традиционной схеме у нас сообщение сразу качует от кэша-источника в кэш-получателя. С твоей схемой оно покачает по N кэшей. Это чудовищный оверхед, проще сразу сделать одну атомарную RMW операцию и отправить сообщение получателю. Как ты предлагаешь это нивелировать?
T>Путём высокопараллельной обработки небольших сообщений.
А если у нас нет много сообщений?
Мы ж по прежнему об *общем* случае говорим, правильно?
Может быть такой паттерн. Актёр А отправляет сообщение Б, после обработки Б отправляет А, и так сто раз. Всё, в системе больше сообщений нет. НО, потом приложение начинает что-то считать и тут появляются тысячи сообщений.
Нужно и throughput и latency. Вот и крутись как хочешь.
Ну а если ограничиться только throughput-oriented HPC, то действительно всё просто становится.
R>>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
T>В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё
per-producer fifo
R>>Динамический лоад-балансинг как будешь делать? Пока что ты увильнул статическим.
T>Динамическую балансировку нагрузки делать трудно, согласен. Но совсем не по той причине, о которой ты думаешь.
T>Дело в том, что одно из нескольких сообщений, необходимых для старта программы обработки оной группы сообщений может сперва пойти на один узел, а потом — динамически, — на другой.
T>Но это тоже решаемо. Достаточно отправлять выше по иерархии те сообщения, что не должны сейчас выполняться на этом процессоре.
А о чём ты думаешь я думаю? О досылке сообщений вслед за агентом я уже давно подумал и о тех проблемах, которые возникают следом. Досылку вслед я применял, НО ТОЛЬКО для случая который не требовал никакого упорядочивания.
R>>Но это не катит для систем общего назначения. Обработка сообщений выполняется недетерминированнное, но малое и с небольшой дисперсией время, зависит от входных данных, не зависит от внешних систем, плюс часть процессоров периодически занимается другими процессами. Тот лоад-балансинг, который ты описал всасёт в такой ситуации — скорость работы системы будет определяться самым медленным процессором, а он может быть сколь угодно медленным.
T>Вставки мои.
Ну, да, небольшие блокирующие вызовы на железяки. Небольшие вызовы в сторонние библиотеки.
T>Вот ссылки: T>http://thesz.mskhug.ru/svn/hiersort/ — там в подкаталоге doc лежит статья про машину динамического потока данных с частичной сортировкой сообщений.
T>http://thesz.livejournal.com/545287.html — чуток описания про преобразование обычной программы в программу для машины динамического потока данных. Делаем такую VM и все преимущества у нас в кармане.
T>Где-то у меня ещё что-то было, но я сейчас отыскать не могу.
А говоришь — не про железо.
Это всё равно, что если бы я из мира софта пришёл бы к тебе в мир железа и сказал бы:
Ребята, я решил все ваши проблемы. И что вы тут сидите и извращаетесь со своими гипер-кубами, жирными деревьями и торами. Всё, что вам нужно — это реализовать полносвязанный NxN коммутатор. И всего-то. Работает охерительно быстро. Не получается? Ну сделайте эмуляцию. Никакие свойства-то от этого не потеряются. Откуда им теряться, когда делаешь эмуляцию?
Здравствуйте, eao197, Вы писали:
E>Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет.
Делал терминал сбора данных через Wi-Fi. TCP/IP не проходил постоянно рвало сединение. Очень плохая связь. Пришлось создавать свой протокол через UDP по принципу отправил получил ответ еще отправил.
Правда сделал по простому. Отправитель посылал и дожидался определенное время ответа, при неудаче слал снова. Для каждой сессии сообщения свой ID и для каждого. Соответсвенно и фильтрация пакетиков по сессии и номеру сообщения.
Просто надежно (народ в пятницу отправлял, а в понедельник получал при выключенном приемнике), и сносно по скорости для решаемой задачи, но медленно для больших объемов. Передача большого количества пакетов, с запросом непришедших была бы значительно лучше. Просто все крутится вокруг того, что до нас уже сделано.
и солнце б утром не вставало, когда бы не было меня
Re[78]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет. S>Делал терминал сбора данных через Wi-Fi. TCP/IP не проходил постоянно рвало сединение. Очень плохая связь. Пришлось создавать свой протокол через UDP по принципу отправил получил ответ еще отправил.
А почему ты вначале брал TCP?
И если бы связь не рвалась, то оставил бы его?
Здравствуйте, remark, Вы писали:
R>Я не против того, что бы система предоставляла возможность сказать "для этого агента порядок не требуется", если она может реализовать что-то лучше для такого случая. Но в то же время для "высокоуровневой", "удобной" системы, я считаю обязательным так же и возможность задать гарантированный ФИФО. При этом ФИФО больше как выбор "по-умолчанию", а не ФИФО — как оптимизация.
я не против ФИФО, даже был бы за. просто в тех системах, которые мне доводится делать, требования к load balancing (более одного читателя очереди) всегда более сильные. а т.к. они вступают в противоречие с ФИФО по причине параллельной работы разных читателей, то про ФИФО-возможности я даже и не думаю. опять же, это не отменяет возможности в специальных случаях предусмотреть специальные агрегаторы не-на-сообщениях, но на очередях я уже привык обходиться без ФИФО
R>По моему опыту, если идут "низходящие" сообщения (т.е. менеджер устройства посылает устройству) и сообщения типа "запрос", то тогда, в принципе, возможно делать какое-то высокоуровневое управление. Хотя зачастую это только лишняя работа. R>Но если идут "восходящие" сообщения <...>
в целом, с разницей управления по нисходящему и восходящему потоку согласен, естественно, всегда приходится принимать во внимание ограничение доступной для принятия решения информации на определённом уровне... как ни странно, однако, зачастую не сложно в сообщения включать некоторую дополнительную информацию, обрабатываемую неким абстрактным образом — есть паттерны. в целом, не стоит пренебрегать такой возможностью при проектировании — есть паттерны, которые позволяют скрыть нюансы от определённого обработчика, тем не менее, не закрывая их совсем
Re[61]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Не очень представляю себе, как можно обеспечить ФИФО для отсылки сообщений разными отправителями без использования какого-либо вида глобальной синхронизации между ними (на основании меток времени или меток предшествования, к примеру).
если в-общем (безотносительно эрланга, о котором мне нечего сказать), то при использовании концепции очередей этой синхронизацией будет заниматься менеджер конкретной очереди — он же принимает send от разных отправителей в каком-то конкретном порядке, согласно которому и складывает сообщения в очередь. т.е. специальные метки для отправителей не видны, равно как и отправителям ничего знать друг о друге не нужно, т.к. всем этим занимается менеджер очереди
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали?
S> Ты опять про "туда встали"? Это интимная подробность функционирования очереди. В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен. Зачем? Мы же стремимся к максимизации быстродействия, а ее главный лозунг — "если можешь — не делай!".
Дизайн и реализация библиотеки, которая нацелена исключительно скорость — не составляет сложности.
Ответ на любой сложный проектный вопрос тривиален — как быстрее, так и делаем. Кстати, так же можно убрать требование, что в каждый момент времени для агента/актёра обрабатывается не более одного сообщения (многопоточная обработка) — в некоторых случаях агент сам может разрулить это значительное эффективнее — возможно ему вообще не нужно взаимное исключение, возможно он защитит себя reader-writer мьютексом, т.к. образом все reader сообщения будут обрабатываться параллельно, возможно он может защищать мьютексом только очень небольшие части своих функций обработки сообщений. Так же можно требовать с пользователя, что бы все сообщения обрабатывались малое и примерно равное время — так значительно проще для эффективного шедулинга. Так же можно требовать, что никакие сообщения не блокировались — значительно проще для шедулинга.
Это можно так сказать подход "ассемблер", т.е. мы вам даём только скорость. всё. хотите "удобно" — делайте сами поверх.
Мне больше нравится подход, так скажем, "С++" — мы вам даём "удобно", но если хотите можете всё взять в свои руки и делать "быстро" (думай о premature optimization). Т.е. вначале делаешь как удобнее и быстрее. Если нужна скорость И готов думать как её делать И готов жертвовать размером и читаемостью кода — пожалуйста, объявляй агента, как не требующего ФИФО и впуть реализовывать собственные протоколы.
Кстати, вопрос на засыпку — если большое число агентов всё равно требуют ФИФО, то что будет быстрее работать — хорошая и умная (у ран-тайм всегда больше возможностей) реализация ФИФО в ран-тайме или ручное докручивание пользователем ФИФО поверх того упорядочивания, которое реализовано в ран-тайм (фактически 2 упорядочивания).
Здравствуйте, eao197, Вы писали:
E>Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?
Нет, мое самое первое сообщение в этой ветке.
AVK>> Я ведь именно об этом и писал.
E>От того, что у .NET-овского фьючерса появился continueWith, он не стал каким-то особенным фьючерсом.
Совершенно верно. Именно это я тебе и говорил.
AVK>>Это пример одной из методик балансинга — work stealing.
E>Только в Cilk-е выполняется "кража" фрагментов стека. А в модели агентов будет просто другой подход.
Да пофик что там крадется физически. Главное принцип. И он, если мы хотим параллелить по процессорам, вполне применим и в агентах.
E>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
Именно. Но обязательное ФИФО всю малину портит.
E>А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).
Именно поэтому гибкая схема управления зависимостями для универсальных библиотек лучше, чем обязательный ФИФО.
AVK>>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.
E>Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.
ФИФО, которую ты тут защищаешь, неизмеримо более частное и ограниченное решение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
R>А почему ты вначале брал TCP? R>И если бы связь не рвалась, то оставил бы его?
Конечно. Зачем же себе геморой то придумывать. Причем в офисе все хорошо, а идешь на площадку производства всё йок. Правда сначала сделал свою версию, а только потом изучил более подробно ТСP ip, и был приятно удивлен, что мыслим то мы одинаково
и солнце б утром не вставало, когда бы не было меня
Re[74]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?
AVK>Нет, мое самое первое сообщение в этой ветке.
Дай ссылочку, плз. А то я не пойму о чем речь.
E>>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
AVK>Именно. Но обязательное ФИФО всю малину портит.
Как именно ФИФО портит эту малину?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[74]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
AVK>Именно. Но обязательное ФИФО всю малину портит.
E>>А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).
AVK>Именно поэтому гибкая схема управления зависимостями для универсальных библиотек лучше, чем обязательный ФИФО.
AVK>>>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.
E>>Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.
AVK>ФИФО, которую ты тут защищаешь, неизмеримо более частное и ограниченное решение.
Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже). Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.
Вот тут я ответил Sinclair более подробно: http://www.rsdn.ru/forum/message/3221599.1.aspx
Здравствуйте, Sinclair, Вы писали:
S>1. В схеме single producer-single consumer можно построить FIFO на протоколе без упорядочивания, применив 1-в-1 стандартные техники из TCP/IP, выкинув обработку потери пакетов.
Все таки техники TCP нацелены не на упорядочивание (в этом плане там ничего нетривиального нет, банальное восстановление последовательности по номеру пакета), а на минимизацию потерь от синхронной отсылки ACK.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Датафлоу, или то, что в программном мире называется task-based parallelism
Это не одно и то же совсем. Второе это просто способ параллелизации fine grained задач. А уж поверх можно и data parallelism строить, и фьючерсы, и твой любимый fork/join.
R>, не требует никакого порядка
Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)
Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено
R>. Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.
И чем конкретно тебе не нравятся фьючерсы с континьюэшенами?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
R>>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)
AVK>Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено
В SObjectizer есть только per-producer fifo и только в случае, если агенты работают в одном рантайме. До остального пока не доросли.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[76]: пример eao197: "сообщения" рвут "разделяемую память"
Все-таки фьючерсы с континуэшами не являются аналогами сообщений. Поскольку во фьючерсе изначально предполагается получение результата обработки. А в случае сообщения -- нет.
AVK>>>Именно. Но обязательное ФИФО всю малину портит.
E>>Как именно ФИФО портит эту малину?
AVK>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
Ну а конкретно, как ФИФО препятствует тому же work stealing?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[77]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Все-таки фьючерсы с континуэшами не являются аналогами сообщений. Поскольку во фьючерсе изначально предполагается получение результата обработки.
Опять ты читаешь невнимательно. Фьючерсы я привел в качестве примера автоматического разруливания зависимостей, если одна задача используетрезультат другой. А дальше я писал про более общий случай, который возврат значения не подразумевает.
AVK>>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
E>Ну а конкретно, как ФИФО препятствует тому же work stealing?
Work stealing предполагает изменение порядка обработки сообщений. Т.е. ФИФО в локальной очереди конечно останется, но вот сама эта очередь может быть раздергана в другие очереди, отсюда и смысла в ФИФО становится ноль, все равно оно правильно работать не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А дальше я писал про более общий случай, который возврат значения не подразумевает.
Передача предиката как критерия отбраковки/принятия очередного сообщения вряд ли может считаться более общим решением.
AVK>>>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
E>>Ну а конкретно, как ФИФО препятствует тому же work stealing?
AVK>Work stealing предполагает изменение порядка обработки сообщений. Т.е. ФИФО в локальной очереди конечно останется, но вот сама эта очередь может быть раздергана в другие очереди, отсюда и смысла в ФИФО становится ноль, все равно оно правильно работать не будет.
Если обработка сообщений агента может быть распараллелена, то нет никаких проблем с раздергиванием очереди. А если не может, то и никакого work stealing-а не будет в принципе.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Датафлоу, или то, что в программном мире называется task-based parallelism
AVK>Это не одно и то же совсем. Второе это просто способ параллелизации fine grained задач. А уж поверх можно и data parallelism строить, и фьючерсы, и твой любимый fork/join.
Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач и специальные способы задания зависимостей по данным.
R>>, не требует никакого порядка
AVK>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.
Так континуэшены — это что? Правильно — задание зависимости по данным. Ты говоришь "когда будет выполнена та задача, выполнить эту", что переводится на язык датафлоу "входные данные для этой задачи предоставляет та и только та задача; когда они будут готовы (когда выполнится та задача), можно выполнять эту задачу".
Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.
Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)
AVK>Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено
Ну а чего плохого в том, что человек сделал библиотеку под свои нужды и она полностью удовлетворяет его потребности. Если мы решили, что в целом было бы неплохо, что бы библиотеки и языки предоставляли и то и другое, это же не значит, что все должны моментально броситься это делать.
R>>. Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.
AVK>И чем конкретно тебе не нравятся фьючерсы с континьюэшенами?
В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею и сам их реализовываю. ФИФО сообщений там и не нужен, его там и приткнуть то не куда — каждая задача получает единственное сообщение "выполниться". Там упорядочивание идёт в другом смысле — задача ставится на выполнение, когда для неё готовы данные.
Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров (естественно, т.к. ФИФО к задачам не применимо, не путать с предпочтительным порядком шедулинга — что другое).
Здравствуйте, AndrewVK, Вы писали:
AVK>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
E>Все-таки фьючерсы с континуэшами не являются аналогами сообщений. Поскольку во фьючерсе изначально предполагается получение результата обработки. А в случае сообщения -- нет.
Конечно, нет. Фьючерсы — это способ задать зависимости по данным в параллельных вычислениях (HPC). Мы блокируемся на фьючерсе в тот момент, когда код ниже *зависит по данным* от результата вычисления этого фьючерса.
(О какой вообще последовательности сообщений можно говорить в контексте фьючерсов )
Что кардинально отличается от приёма *ряда* сообщений актёром с внутренним состоянием.
Здравствуйте, remark, Вы писали:
R>Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач
И при чем тут датафлоу? Таски прекрасно работают даже если никакого потока данных нет в принципе. Единственное требование — наличие fine grained разбиения. Автоматические зависимости по данным совсем не обязательны. Вот википедийное определение — http://en.wikipedia.org/wiki/Dataflow . Первых два варианта никак к task parallelism не подходят, а третье по сути описывает агентную модель, о которой здесь речь и идет, собственно.
R>>>, не требует никакого порядка
AVK>>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.
R>Так континуэшены — это что? Правильно — задание зависимости по данным.
Просто задание зависимости. Неважно по чему.
R> Ты говоришь "когда будет выполнена та задача, выполнить эту"
Задача != данные.
R>, что переводится на язык датафлоу
Э нет, я таким манером чего хочешь доказать могу. Задача != данные. Точка.
Мне это напоминает дисскуссию про монады здесь же. Там чуть ли не любая комбинирующая конструкция языка волшебно оказывалась монадой, а у тебя любой fine grained код точно так же чудесным образом превращается в датафлоу.
R>Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.
Это не суть, это модель. И она совсем не единственная.
R>Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.
TPL и вообще без графа их позволяет организовать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, eao197, Вы писали:
E>Передача предиката как критерия отбраковки/принятия очередного сообщения вряд ли может считаться более общим решением.
По сравнению с зависимостью по возвращаемому результату? Безусловно более общее, хотя бы потому что возвращаемого результата может не быть вовсе. Собственно, в TPL Future наследуется от Task, так что прекрасно видно, кто из них более общий. И это несмотря на то, что Task умеет только один вид предикатов — завершение другой задачи с определенным статусом.
E>Если обработка сообщений агента может быть распараллелена, то нет никаких проблем с раздергиванием очереди. А если не может, то и никакого work stealing-а не будет в принципе.
Ну так в этом и сила более гибких и абстрактных решений. Я декларативно говорю — здесь есть зависимость. Точка. А уж как там внутренняя механика это все организует — в виде ФИФО очереди, каких то более причудливых структур, или вообще с использованием каких нибудь аппаратных фич — личное дело рантайма. А если зависимости нет — то и не надо заморачиваться и спокойно выбирать оптимальное по производительности решение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Ну а чего плохого в том, что человек сделал библиотеку под свои нужды
Ничего. Но погляди как форум называется, мы здесь не конкретную библиотеку обсуждаем, а подходы и концепции.
R>В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею
А разве в этом топике не параллельные вычисления обсуждаются?
R>Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров
Эта модель неприменима для распараллеливания?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Ну а чего плохого в том, что человек сделал библиотеку под свои нужды
AVK>Ничего. Но погляди как форум называется, мы здесь не конкретную библиотеку обсуждаем, а подходы и концепции.
Так это ты сам про эту конкретную библиотеку и сказал
Я тебе про неё конкретно и ответил.
R>>В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею
AVK>А разве в этом топике не параллельные вычисления обсуждаются?
Конечно НЕТ!
Сетевой сервер — это НЕ параллельные вычисления.
Игры — это НЕ параллельные вычисления.
ОС и миддлваре — это НЕ параллельные вычисления.
ГУИ приложения — это НЕ параллельные вычисления.
Работа с физическими устройствами — это НЕ параллельные вычисления.
Однако всё это использует параллелизм.
R>>Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров
AVK>Эта модель неприменима для распараллеливания?
Применима. Но она применима не только для параллельных вычислений.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач
AVK>И при чем тут датафлоу? Таски прекрасно работают даже если никакого потока данных нет в принципе. Единственное требование — наличие fine grained разбиения. Автоматические зависимости по данным совсем не обязательны. Вот википедийное определение — http://en.wikipedia.org/wiki/Dataflow . Первых два варианта никак к task parallelism не подходят, а третье по сути описывает агентную модель, о которой здесь речь и идет, собственно.
Да, таски могут работать и с вырожденным потоком данных. Так же как и датафлоу — можно все элеметы вытянуть в цепочку или все расположить параллельно.
fine grained — это определение task-based programming?
fine grained — это уже деталь реализации, которая говорится только после того, как дано общее определение концепции. А концепция тут как раз — зависимость по "данным".
R>>>>, не требует никакого порядка
AVK>>>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.
R>>Так континуэшены — это что? Правильно — задание зависимости по данным.
AVK>Просто задание зависимости. Неважно по чему.
Я имел в виду "данные" (в кавычках). Извиняюсь. Т.е. некая абстракция. В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных". Понятно, что железо не может передавать в сообщении сокет; или один элемент отрисовывает часть GUI, а потом другой — поверх дорисовывает. Однако в софте мы можем с таким оперировать.
R>> Ты говоришь "когда будет выполнена та задача, выполнить эту"
AVK>Задача != данные.
Задача == "данные" (абстрактный ресурс).
Но ресурс обязательно есть, иначе зачем мы говорим, что бы этот таск выполнился после того — мы зависим от того, что сделает тот таск — посчитает ли какие-то данные, откроет сокет, отрисует часть ГУИ.
R>>, что переводится на язык датафлоу
AVK>Э нет, я таким манером чего хочешь доказать могу. Задача != данные. Точка. AVK>Мне это напоминает дисскуссию про монады здесь же. Там чуть ли не любая комбинирующая конструкция языка волшебно оказывалась монадой, а у тебя любой fine grained код точно так же чудесным образом превращается в датафлоу.
агнеты != датафлоу.
R>>Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.
AVK>Это не суть, это модель. И она совсем не единственная.
R>>Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.
AVK>TPL и вообще без графа их позволяет организовать.
То, что возможны более простые (вырожденные) графы — это понятно.
Здравствуйте, remark, Вы писали:
R>Да, таски могут работать и с вырожденным потоком данных.
Таски могут работать совсем без потоков данных. Более того, собственно исходные таски никак на поток данных и не завязаны. Data flow строится поверх них.
R>fine grained — это определение task-based programming?
Нет конечно, с чего ты взял? Fine grained это требование к коду, чтобы можно было воспользоваться task parallelism.
R>fine grained — это уже деталь реализации
Нет, не деталь. Это принципиальное требование к коду.
AVK>>Просто задание зависимости. Неважно по чему.
R>Я имел в виду "данные" (в кавычках).
А я тебе об этом и говорю. Если данные брать в кавычках, то все вокруг станет гвоздями. Только смысл то в том какой?
R> В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных".
И готовности там, в общем то, тоже никакой нет. Там есть зависимость, причем опциональная, не отражающая исходную суть механики. И это фундаментальное понятие, не являющееся ни данными, ни "данными", ни "готовностью ресурса". Иначе все закончится как в том топике про монаду — расширять понятие будем до бесконечности, пока не натянем таки его на предмет обсуждения, аки презерватив на глобус.
R>Задача == "данные" (абстрактный ресурс).
Задача это задача. К чему выдумывать еще какие то термины?
R>Но ресурс обязательно есть
Нет.
R>, иначе зачем мы говорим, что бы этот таск выполнился после того
А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?
R>агнеты != датафлоу.
А в википедии написано, что:
Concurrency
A dataflow network is a network of concurrently executing processes or automata that can communicate by sending data over channels (see message passing.)
Аутоматы, которые мессагами обмениваются, это так похоже на агентов, что прям и не отличить
AVK>>TPL и вообще без графа их позволяет организовать.
R>То, что возможны более простые (вырожденные) графы — это понятно.
А с чего ты взял, что это исключительный, вырожденный случай?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Так это ты сам про эту конкретную библиотеку и сказал
Я ее привел в качестве источника мнения eao197
R>Я тебе про неё конкретно и ответил.
Ответил только ты на какой то вопрос, который я не задавал.
AVK>>А разве в этом топике не параллельные вычисления обсуждаются?
R>Конечно НЕТ!
Ясно А я думал, что parallel computing в названии топика это все таки оно.
Что же касается гуев и прочих устройств, то там совершенно иные подходы, там все эти навороты нафик не нужны, там можно тупо синхронизироваться по старому, потому что упирается не в процессоры, а в само устройство. Мне вон нетовской AsyncOperation за глаза хватает и никакой потребности изобретать чего то хитрое никогда не возникало.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Как ФИФО мешает work stealing?
AVK>ФИФО мы при этом соблюсти не сможем, потому что задачи уйдут в другую очередь.
У меня сейчас работает агентная система на work-stealing'е.
Я понял, в чём тут конфьюжн.
Ты путаешь 2 вещи. Первая — упорядочивание сообщений для агента (пользовательская сущность), вторая — упорядочивание элементов работы шедулера (сообщения агента != элементы работы шедулера!!!).
В контексте task-based, futures, dataflow ты говоришь об упорядочивании элементов работы шедулера, что его не требуется (и это правильно). Однако сообщений пользовательских сущностей в этой модели нет (ну точнее они есть, но они не интересны, формально каждый таск обрабатывает одно сообщение "исполниться", т.е. элементы шедулера и пользовательские сообщения объединены).
В агентной же модели добавляется 2 принципиальных вещи, которых нет в той модели — (1) агент обрабатывает последовательность, множество сообщений, и (2) у агента есть состояние. Во-первых, это вносит второе упорядочивание, т.е. мы можем, например, не упорядочивать элементы работы шедулера (агентов), но упорядочивать сообщения для каждого отдельного агента. Естественно глобальное упорядочивание элементов работы шедулера не имеет никакого смысла, т.к. тогда у нас фактически будет только один поток. Думай — таск==агент, мы не упорядочиваем в каком порядке шедулер берёт агентов и начинает выполнять для них сообщения. И это логично их не упорядочивать, например я применял следующую схему: для пользователя документированный порядок — порядок не гарантируется, реальный порядок — близко в LIFO (Cilk style LIFO work-stealing scheduler).
Далее. Почему я настаиваю на ФИФО для сообщений агентов (ещё раз — (1) это не ограничивает шедулер — у него по-прежнему достаточно "элементов работы" (агентов), (2) это не требует порядка обработки шедулером — пусть какого хочет агента, того и берёт на исполнение). У агента есть состояние, и помимо потребленных и порожденных сообщений появляются побочные эффекты на состоянии агента. А как известно большинство операций над состоянием не коммутативные, т.е. мы не можем вначале записать в сокет, потом его открыть; мы не можем А поделить на Б, если нам надо Б поделить на А.
Необходимость такого упорядочивания очевидна — достаточно рассмотреть объектно-ориентированные системы. Когда ты вызываешь у объекта несколько методов (что в объектной теории называется как-раз посылкой сообщения), ты требуешь (и это логично), что бы они выполнились в программном порядке (ФИФО). А как тебе такая реализация — методы объектов вызываются в недетерминированном порядке (как компилятору удобнее)? Добавляем в список элемент А и элемент Б, а они добавляются в произвольном порядке; хочешь упорядочивания — добавляй сиквенсы и разруливай руками; слишком старые вызовы отбрасываем и делаем пере-посылку. А ты предлагаешь фактически то же самое. Методы выполняются в программном порядке, однако если у нас в этой же программе есть несколько потоков — то, пожалуйста, пусть ОС их шедулит как ей удобнее.
А агент — это и есть фактически тот же объект. То же состояние, та же последовательность вызовов/посылок сообщений, та же инкапсуляция.
Агентная модель мощнее модели тасков (надмножество). Редукция следующая: там где ты порождаешь таск — создаешь агента, когда таск становится готовым для исполнения (возможно сразу) — посылаешь ему соощение "исполниться", после исполнения этого сообщения разрушаешь агента. Т.о. ты получаешь модель основанную на тасках из агентной, заметь порядок исполнения — НЕ ДЕТЕРМИНИРОВАННЫЙ. Т.е. и Эрланг и SObjectizer при такой редукции дадут тебе то самое отсутствие упорядочивания "элементов работы".
Над этим агентная модель вводит новый уровень — "таск" получается собственную очередь сообщений, ему разрешается жить дольше, разрешается принимать множество сообщений, соотв. для него приобретает смысл иметь состояние. Упорядочивание сообщений в этой очереди — это отдельный вопрос, мы можем его выбрать каким угодно, как нам надо для этой, уже агентной, модели. Т.е. агент получается сам себе мини-шедулер.
Важно различать эти 2 *независимых* уровня шедулинга. Пока ты не будешь различать, будет получаться, что ФИФО мешает work-stealing. ФИФО в агенте никак не мешает шедулеру, который шедулит самих агентов на исполнение.
Здравствуйте, AndrewVK, Вы писали:
R>> В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных".
AVK>И готовности там, в общем то, тоже никакой нет. Там есть зависимость, причем опциональная, не отражающая исходную суть механики. И это фундаментальное понятие, не являющееся ни данными, ни "данными", ни "готовностью ресурса". Иначе все закончится как в том топике про монаду — расширять понятие будем до бесконечности, пока не натянем таки его на предмет обсуждения, аки презерватив на глобус.
Я не уверен, имеет ли смысл говорить о том, что эти 2 модели одно и тоже, это больше философско-риторический вопрос. Я имел в виду, что эти 2 модели получаются одна из другой фактически "переименованием" понятий с чёткой аналогией между этими парами понятий.
R>>Задача == "данные" (абстрактный ресурс).
AVK>Задача это задача. К чему выдумывать еще какие то термины?
R>>Но ресурс обязательно есть
AVK>Нет.
R>>, иначе зачем мы говорим, что бы этот таск выполнился после того
AVK>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?
Ну это смешно. Из ты можешь получить из N полностью независимых сущностей систему, ты можешь получить только N отдельных систем. Ты когда запускаешь таски, ты потом не ждёшь из завершения? Код, который отображает потом картинку пользователю, не зависит от данных, подготовленных тасками рей-трейсинга?
Здравствуйте, AndrewVK, Вы писали:
AVK>Ответил только ты на какой то вопрос, который я не задавал.
AVK>>>А разве в этом топике не параллельные вычисления обсуждаются?
R>>Конечно НЕТ!
AVK>Ясно А я думал, что parallel computing в названии топика это все таки оно.
Тут уже тема несколько десятков раз сменилась.
AVK>Что же касается гуев и прочих устройств, то там совершенно иные подходы, там все эти навороты нафик не нужны, там можно тупо синхронизироваться по старому, потому что упирается не в процессоры, а в само устройство. Мне вон нетовской AsyncOperation за глаза хватает и никакой потребности изобретать чего то хитрое никогда не возникало.
Какие навороты там не нужны?
А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель. Никаких хитростей, просто удобство, асинхронность, ограниченное распараллеливание (возможно и не ограниченное, а возможно и то и другое).
Здравствуйте, remark, Вы писали:
R>Я не уверен, имеет ли смысл говорить о том, что эти 2 модели одно и тоже, это больше философско-риторический вопрос. Я имел в виду, что эти 2 модели получаются одна из другой фактически "переименованием" понятий
Вот я и говорю, презерватив на глобус.
AVK>>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?
R>Ну это смешно.
Именно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>У меня сейчас работает агентная система на work-stealing'е.
Замечательно.
R>В контексте task-based, futures, dataflow ты говоришь об упорядочивании элементов работы шедулера
Нет. Я вобще нигде ничего про шедулер не писал, не выдумывай. Вобщем, опять все у тебя скушно, безпредметно, и неконструктивно. Сам выдумываешь модели, пытаешься их натянуть на конкретику, и пытаешься этим доказать, что моя модель при этом неверная.
Уже одно то, что тебе понадобилась такая куча слов, через которую я еле продрался, для объяснения простых концепций, говорит, что что то здесь не так.
R>У агента есть состояние
А есть ли? Ты на частном случае строишь общую теорию.
R>Необходимость такого упорядочивания очевидна — достаточно рассмотреть объектно-ориентированные системы
Все больше и больше понятий. Ты за несколько сообщений успел такую кучу нечетких терминов нагородить, что остается только диву даваться.
R>. Когда ты вызываешь у объекта несколько методов (что в объектной теории называется как-раз посылкой сообщения), ты требуешь (и это логично), что бы они выполнились в программном порядке (ФИФО)
Аналогии в качестве аргументов.
R>. А как тебе такая реализация — методы объектов вызываются в недетерминированном порядке (как компилятору удобнее)?
Аналогии. Кривые.
R>А агент — это и есть фактически тот же объект.
А тебе еще раз намекаю: такими приемами можно доказать что угодно, уж поверь. Нет, агент это не объект, и аналогиями ничего доказать нельзя. В принципе. Никакими.
R>Агентная модель мощнее модели тасков
Нет. Они эквивалентны, потому что на агентной модели можно реализовать модель тасков в полном объеме, и наоборот. Но я не понимаю, какое это имеет отношение к ФИФО vs гибкий механизм декларирования зависимостей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Тут уже тема несколько десятков раз сменилась.
Ну вот такой я, всегда стремлюсь тему не сменять. Так оно понятнее и не приводит к бесконечным и бесполезным флеймам обо всем.
R>Какие навороты там не нужны?
Хитрые модели вроде TPL.
R>А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель.
Они хорошо ложаться на любую модель. Поэтому чем она проще, тем лучше. Модель AsyncOperation всего с 2 значимыми методами намного проще агентов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
R>>У агента есть состояние
AVK>А есть ли?
Ну, если отталкиваться от различных определений агентов (в том числе и из Wikipedia), то агент с состоянием -- это более обыденная вещь, чем агент без состояния. Поскольку основная задача агента -- это реактивное и более-менее автономное поведение в достижении своей цели. Обеспечить автономность и реактивность без собственного состояния как-то затруднительно.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remark, Вы писали:
R>>Я не уверен, имеет ли смысл говорить о том, что эти 2 модели одно и тоже, это больше философско-риторический вопрос. Я имел в виду, что эти 2 модели получаются одна из другой фактически "переименованием" понятий
AVK>Вот я и говорю, презерватив на глобус.
Ну хорошо, если это "презерватив на глобус" и типа теперь под это всё подпадает, то тогда приведи ещё пару моделей, которые получаются из тасков и датафлоу путём переименования понятий один-к-одному с чёткой аналогией между этими парами понятий.
Полагаю, если вещи таковы как ты говоришь, то это не должно составить проблемы.
AVK>>>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?
R>>Ну это смешно.
AVK>Именно.
Ну а по-существу?
Из ты можешь получить из N полностью независимых сущностей систему, ты можешь получить только N отдельных систем. Ты когда запускаешь таски, ты потом не ждёшь из завершения? Код, который отображает потом картинку пользователю, не зависит от данных, подготовленных тасками рей-трейсинга?
Чёткий датафлоу граф вырисовывается. Параллельный рэй-трейсинг не начинается пока модель не считали из файла, а отрисовка не начинается пока не закончили рендеринг. Один кружочек расходится на N, а потом они сходятся опять в один.
Где ж тут "зависимостей нет никаких"???
Здравствуйте, eao197, Вы писали:
E>>>Это не единственный источник.
AVK>>И?
E>И твое замечание о том, что SObjectizer является источником моей приверженности FIFO, не соответсвует действительности.
В смысле, его проектировал не ты? Или тебя заставляли принимать некоторые решения по дизайну принудительно, без учета твоего мнения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
E>>И твое замечание о том, что SObjectizer является источником моей приверженности FIFO, не соответсвует действительности.
AVK>В смысле, его проектировал не ты? Или тебя заставляли принимать некоторые решения по дизайну принудительно, без учета твоего мнения?
В том смысле, что нельзя объять необъятного. SObjectizer -- это инструмент, построенный на некоем наборе принципов и архитектурных решений, выработанных лет двенадцать назад людьми гораздо более умными, чем я. А добавить в него что-то принципиально новое сейчас препятствует как недостаток ресурсов, так и требования к сохранению совместимости. Так что SObjectizer отражает далеко не все мои идеи и пристрастия.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[82]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
AVK>А если не заниматься перетасовкой терминов?
У агента нет общепризнаного одного определения. Но существующие в различных предметных областях определения указывают, что это сущность с собственным состоянием.
В MS-совской библиотеке асинхронных агентов из состава VS2010 агент -- это объект. Объект имеет соостояние.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[58]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
G>> Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
AVK>Ну, remark в соседнем топике утверждал, что фьючерсы сотоварищи совсем уже не actors model, это совершенно отдельный task parallelism. Но это все спор о терминах.
Ну мало-ли что утверждал remark. Эти товарищи пойдут на что угодно, лишь бы выиграть спор. В то время как достаточно открыть википедию, и увидеть удивительное рядом, в виде характерных отсылок к actors model. Вдруг оказывается, что Делеи с Фьючерами у нас отлично определяются своей денотационной семантикой в рамках модели актеров.
Futures and delays are well defined in terms of their denotational semantics in the Actor model. These definitions do not require recourse to low level implementation concepts such as threads.
Впрочем, любому нормальному человеку понятно и без всякой теории, что изобразить фьючер на актерах — раз плюнуть, это по своей сути специальный частный случай обмена асинхронными сообщениями. Вот он, весь фьючер. Простейшая реализация на Эрланге, без запоминания (Фьючер "грязный") — просто заворачивающая в замыкание весьма частоупотребимый паттерн кода.
future( Actor, Message ) ->
Actor ! { self(), Message }, % послали сообщение актору, приложив свой ID процесса, чтобы актор имел возможность вернуть результат
fun() -> % конструируем безымянную функцию без аргументов для отложенного вычисления
receive { Actor, Response } -> Response end % в котором мы тупо получим ответ.
end.
% И все. Было бы о чем говорить. Проектируя в терминах actor model фьючер не является чем-то чужеродным - это один из типовых "паттернов проектирования"
Вот теперь смотрим — если я вместо явных посылок сообщений, всего лишь завернув их в функции, и напишу вот так:
Res = future( SomeObject, DoSomething ),
...
X = A + Res().
Я что, резко перестал actor model использовать? Что, так уже низя, да, потому что фьючеры — "это совсем не actors model"? По моему, глупостей уже на данную ветку достаточно с избытком. Совершенно очевидно, что это дружественные, дополняющие друг друга техники. Просто явная посылка сообщений нужна для потокового обмена, а стиль с промисами-фьючерами — нужен для синхронного взаимодействия в стиле RPC. Вот и все. А по сути это совершенно одно и то же.
Здравствуйте, AndrewVK, Вы писали:
G>> Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
AVK>Ну, remark в соседнем топике утверждал, что фьючерсы сотоварищи совсем уже не actors model, это совершенно отдельный task parallelism. Но это все спор о терминах.
Простейший жизненный пример, показывающий, как великолепно фьючера дополняют сообщения и модель актеров, и что это суть одно и то же. Один из паттернов, который реально применялся у нас при разработке системы симуляции на Эрланге, и который можно повторить в любом языке.
Допустим, у нас есть дерево из "актеров". Некто шлет верхушке дерева rpc-style запрос, ответ на который он предполагает получить через фьючерс. Однако, верхушка дерева решает форварднуть запрос одному из своих потомков (выполняя его диспетчеризацию), потому, что он сам знает, как обработать запрос, но знает, кто сможет это сделать, выступая, таким образом, в роли брокера. Эта процедура, повторяясь рекурсивно, приводит к тому, что нужный actor в конце концов получает запрос, выполняет его, и кладет результат напрямую в фьючерс, который все это время путешествовал вместе с запросом.
Данный пример демонстрирует трактовку фьючерса в рамках модели актеров — как мэйлбокса для приема результата, а самого rpc вызова — как асинхронной посылки сообщения. От такой трактовки, как видите, есть польза. Вторая польза состоит в полной сетевой прозрачности — фьючерс, реализованный на сообщениях, легко сделать как межпроцессным так и межмашинным. Правда, это здорово, когда неважно, какой узел кластера выполняет ваш запрос, и где находится получатель результата? От то-то же.
можно рассмотреть иерархию того, как они реализуются.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
), (2) либо очень хитро врёшь/выставляешь реальные факты лживо в надежде типа "а вдруг прокатит", со стороны неискушенного читатели выглядит типа авторитетно.
