Re[56]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 16.12.08 08:35
Оценка: +6 :)))
Здравствуйте, Gaperton, Вы писали:

G>Примерно так бы все и было. С незначительными нюансами туда-сюда.


Феерический рассказ о том, как Gaperton поспорил сам с собой и блестяще выиграл спор у самого себя.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: Offtop
От: kdw Россия  
Дата: 07.12.08 07:31
Оценка: -5 :))
Достал ты уже со своим ерлангом , Я не ничего не имею против ассинхронных сообщений (сделать это можно на любом языле я думаю)
Как абстракции на нем писать предлагаешь , можно конешно через жопу (и на асемблере можно), Но в данном
случае например предпочитаю нормальные обьектно ориентированные языки.

Я смотрел на синтаксис ерланга и чесно говоря он него тошнит , хотя в некоторых случаях думаю имеет смысл
заюзать.

G>В случае Эрланга, где присутствует сопоставление с образцом и селективный receive, заводить явно этого mailbox не надо. Достаточно написать:


G>rpc_call( CalleePID, Method, ArgList ) ->

G>CalleePID ! { self(), Method, ArgList },
G>receive { CalleePID, Result } -> Result.
Re: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 18.11.08 21:23
Оценка: 45 (4) +1 -1
Здравствуйте, 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).
...

Это действительно не столь принципиально, ты можешь использовать любую модель, можешь надстроить над любой любую, и всё равно в конечном итоге будешь использовать обе



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[30]: Java Parallel computing: multicore, Erlang, Scala
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.12.08 07:07
Оценка: 43 (3) +3
Здравствуйте, Gaperton, Вы писали:

G>Понятно, то есть, тебе хочется докопаться.


Мимо.

G>>>Если бы ты это сделал, то увидел бы вывод авторов статьи в его начале, что их исследование показало, что далеко не очевидно, что OpenMP дает лучшую производительность на SMP машинах, что является прямым опровержением тезиса.


E>>Кстати, в статье рассматриваются три версии программ на OpenMP. Две из них показывают не очень хорошие результаты. Что и позволяет авторам говорить о неочевидности того, что OpenMP является залогом успеха. Зато третья версия уделывает MPI. Что не позволяет использовать данную статью в качестве опровержения тезисов remark-а.


G>Для опровержения тезисов ремарка вполне достаточно одного примера, где "сообщения" показывают лучший результат, а тут их два.


См. ниже.

G>Еще раз, приведу два тезиса:


G>remark: "разделяемая память" имеет преимущества, которые безвозвратно и необходимо утрачиваются при применении message passing style.


Итак, смотрим
Автор: remark
Дата: 22.11.08
:

Разделяемая память будет иметь приемущества в некоторых ситуацяиях на HT/CMT/HWT, multicore, SMP, SMP-NUMA. И тут она может дать приемущества как по скорости так и по латентности. Особенно целесообразна разделяемая память для небольших операций.

Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества. Для доказательства этого тезиса, как я наивно полагал, достаточно привести пример случая, когда это преимущество доказано экспериментально. Такое доказательство приведено в упомянутой тобой статье.

Однако, если бы remark утверждал, что разделяемая память всегда имеет преимущество, тогда было бы достаточно всего лишь одного контрпримера для его опровержения. Но remark этого не утверждает. А вот какие тезисы ему приписываешь ты -- это совсем другая история.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[22]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 01.12.08 10:54
Оценка: 85 (4)
Здравствуйте, Sinclair, Вы писали:

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

G>>Вы как дети прям малые. Аппаратно передача сообщений в современных процах НЕ ПОДДЕРЖИВАЕТСЯ. Естественно, она будет реализована посредством разделяемой памяти, ПО ДРУГОМУ на современных процах просто НЕЛЬЗЯ, и я не понимаю, как это в принципе может являться предметом спора. Совсем за идиота собеседника держать не надо, ладно?

S>Это, кстати, мне до боли напоминает "теорему существования" (c) P.Dvorkin. Там, где он "доказывал", что раз все языки высокого уровня компилируются в ассемблер, значит программа на ассемблере гарантированно не медленнее никакой программы на ЯВУ. Здесь только народ поаккуратнее, и не пытается протолкнуть аналогичное доказательство


Отчего же аккуратнее? Одна такая попытка уже зарегистрирован от remark в соседней ветке.

Дворкина можно было бы отослать на форум геймеров, где они пытались обойти Intel C++ ручным кодированием на ассемблере на короткой программе — я ссылку несколько лет назад давал, — подтверждать свою теорию практикой. Проблема в том, что авторы таких теорем обычно не имеют представления, как на современных процах выполняется программа на ассемблере, и насколько компилятор больше них знает об исполнительном конвейре проца . Вот на том форуме, я помню, народ чуть себе лоб до затылка не расшиб, пытаясь понять (когда попытки обогнать уже бросили), почему более длинный "и корявый" код, сгенеренный IC++, быстрее, чем их "оптимизированный" ассемблер .

Вот, кстати, пример — как бесхитростный gcc компилирует формулу с двумя умножениями для прямолинейного MIPS.
В MIPS, который сам по себе single issue, команда умножения асинхронна. То есть, она занимает один такт, однако результат полагается забирать через несколько тактов из специальной регистровой пары HL.

Так вот, gcc одно умножение заряжает родное, а второе умножение в это время мутит на сдвигах-сложениях. Потому, что так быстрее. Я бы посмотрел на программиста на ассемблере, который попробует обойти gcc под простейший MIPS .
Re[46]: А можно еще лучше
От: Gaperton http://gaperton.livejournal.com
Дата: 07.12.08 23:02
Оценка: 9 (3) -1
Здравствуйте, 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.

Читаем про фьючерсы здесь.
http://en.wikipedia.org/wiki/Future_(programming)

Я думаю, фьючерсы — это лучшее, что придумано на текущий момент в области языкостроения и параллельного программирования.
Re[22]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 28.11.08 14:53
Оценка: +1 :)))
Здравствуйте, remark, Вы писали:

R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.


Афигеть. Ну тогда я делаю тезис — remark пьет по ночам кровь христианских младенцев. Все согласны? Нет? Ну тггда вперед, доказывай
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[44]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 13.12.08 20:50
Оценка: 26 (2) :)
Здравствуйте, 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
Автор: remark
Дата: 13.12.08



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.11.08 10:25
Оценка: 15 (1) +2
Здравствуйте, yumi, Вы писали:

R>>Они не пошли по первому пути. С/С++, C#, Java — это языки *общего* назначения, они вообще ни по какому пути не идут. Они просто предоставляют *все* возможности. Хочешь — пиши в разделяемую память, хочешь — отправляй сообщения, хочешь — делай неизменяемые объекты и пиши функции без побочных эффектов.


Y>Все? Да неужели? Тогда уж и ассемблер тоже язык *общего* назначения, тоже теоретически доступны *все* возможности. А вот на практике, увы совсем другая картина.


Демагогия.

Проектов, которые на универсальных императивных языках реализуют модель актеров, не так уж и мало. Для Ruby -- Revactor, для Java была сделана SEDA, для Scala -- ScalaActors, для Python -- Eventlet и Kamaelia.

R>>В чём проблема использовать в С++/C#/Java *уже существующие* библиотеки моделирующие модель Erlang? Ну или на крайняк написать свою библиотеку (Что не так уж и страшно, как это малюют. К тому же имеет ряд существенных достоинств. Особенно учитывая, что любой вменяемый проект на языке общего назначения в любом случае включает некую начальную стадию по созданию подходящего "нижнего слоя" для всего остального "мяса" приложения).


Y>Напиши. Вся проблема в том, что ты этого не напишешь.


Вы пытаетесь брать "на слабо" не того человека. Ему и не нужно писать это самому, вокруг достаточно велосипедостроителей, которые делают уже это. При этом широко используя знания и идеи remark-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: Можно
От: Gaperton http://gaperton.livejournal.com
Дата: 06.12.08 15:58
Оценка: 13 (2) -1
Здравствуйте, EvilChild, Вы писали:

EC>>>А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?


G>>Почему нельзя? Можно. Получишь в точности очередь сообщений, а именно — ее предельный случай с глубиной 1 и полиси вытеснения при переполнении по FIFO — что станет совершенно очевидно даже тем, кто в танке, если завернуть то что получится в класс, и посмотреть на функциональный интерфейс.

EC>Можно и о скаляре думать как об одномерном массиве с одним элементом, вопрос в том когда такой взгляд на вещи полезен.

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

Данный объект по всем своим свойствам объективно является мэйлбоксом для приема асинхронных сообщений, и в данном случае употребляется в том контексте, где применяется мэйлбокс. Подобного рода мэйлбоксы на одно сообщения — распространенная вещь в дизайне на асинхронных сообщениях. А вот, например, семафор по всем своим свойствам мэйлбоксом не является.

Характерный пример — во время обработки какого-либо сообщения, процесс хочет выполнить RPC-вызов. Для этого, он отправляет сообщение процессу, и встает в блокирующее ожидание на мэйлбокс. Второй процесс выполняет запрос, и возвращает результат. Один. В виде одного объекта. В указанный мэйлбокс, специально для этого созданный.

В случае Эрланга, где присутствует сопоставление с образцом и селективный receive, заводить явно этого mailbox не надо. Достаточно написать:

rpc_call( CalleePID, Method, ArgList ) ->
CalleePID ! { self(), Method, ArgList },
receive { CalleePID, Result } -> Result.

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

EC>Что вы так Дворкина любите пинать? Я с ним во многих случаях тоже не согласен, это же не повот его пинать по любому поводу.

Я в данном случае "пинаю" не Дворкина.
Re[32]: Ну надо же, еще одна статья.
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.08 11:08
Оценка: 2 (1) +2
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: Aib https://razborpoletov.com
Дата: 16.11.08 12:37
Оценка: -1 :))
Здравствуйте, DenysSG, Вы писали:

DSG>+ в дополнительное чтение

DSG>Challenges and Directions in Java Virtual Machines

Нуууу эээээ, это похоже на то как какой-нить крестьянин заснул в 1900 году, потом проснулся в 1950 и сказал — "Ох$%ть!! Большевики!!?"

Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.
Машины для erlang пока сыроваты, но когда-нибудь и они займут свою нишу в production. Но мне кажется это будет просто отдельный критический функционал как JNI, а обвязка все равно будет на java или .net.
Re[24]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 30.11.08 00:07
Оценка: :)))
Здравствуйте, Gaperton, Вы писали:

G>Слушай, может вы это в правила внесете, а? В качестве антифлудерского закона? Штоб можно было ссылаться. По-моему, неплохая идея.


Плохо формализуемо. И для особо сложных случаев есть специальный пункт о том, что модератор может забанить на свое усмотрение даже за то, что в правилах не прописано. Есть все таки определенная прелесть в диктатуре
... << RSDN@Home 1.2.0 alpha 4 rev. 1115 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[26]: Java Parallel computing: multicore, Erlang, Scala
От: prVovik Россия  
Дата: 02.12.08 07:00
Оценка: +3
Здравствуйте, Gaperton, Вы писали:


G>Я отлично знаю, что я говорю. И если бы ты внимательно читал, что пишут, то понял бы, это не я доказываю, что сообщения быстрее. Это remark доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?


G>Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.


RSDN как обычно жжот. Спорят все команды. Одна команда воображает, будто вторая говорит, что разделяемая память всегда эффективнее сообщений, и, соответственно опровергает его. Вторая команда воображает, что первая утверждает, что сообщения всегда эффективнее разделяемой памяти и тоже опровергает его. Единственное в чем все спорщики сходятся — это в игнорировании аргументов друг друга
лэт ми спик фром май харт
Re[32]: Ну надо же, еще одна статья.
От: remark Россия http://www.1024cores.net/
Дата: 13.12.08 22:11
Оценка: +3
Здравствуйте, Gaperton, Вы писали:

G>Ой ли. А давай посмотрим, что конкретно кроется за словом "быстрее".


G>2%, 7%, 9%, и 69% — тесты с выигрышем OpenMP. Значимый отрыв только в одном тесте. 2% — это вообще не смешно, а что такое 9% — ну вместо минуты займет у тебя расчет 55 секунд. Для вашей пенисометрии это может быть и значимый отрыв, но мне, честно, на такую разницу плевать — что есть она, что нет.


G>27% и 139% — тесты с выигрышем MPI. Значимый отрыв в двух тестах.


G>Я весь внимание — все еще жду как ты будешь делать вывод о преимуществах разделяемой памяти.


Gaperton, постарайся хотя бы для начала понять моё изначальное высказывание, которое изложено на вполне нормальном русском языке, и которое, я вижу, тут понял не один человек, и даже были попытки тебе его тут пояснить.
Ещё раз, дабы не затуманить основную мысль: ТЫ НЕ ПОНЯЛ МОЁ ВЫСКАЗЫВАНИЕ, и говоришь о чём-то другом.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 16:36
Оценка: 27 (1) +1
Здравствуйте, AndrewVK, Вы писали:

C>>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?


AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.


TPL — это другое, это — task-based программирование, подходит в одновном для паралельных вычислений, а неструктурированный параллелизм поддерживается плохо. M$ ещё делает AAL (Asynchronous Agents Library), но это для С++. Но о каких планах переноса потом агентно-ориентированного программирования под .NET я пока не слышал, хотя это вполне логично, так что возможно в MSVC2012...


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[17]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 25.11.08 12:36
Оценка: 25 (2)
Здравствуйте, 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, который говорит, что у разделяемых данных нет никаких преимуществ вообще.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[65]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 17.12.08 17:44
Оценка: 21 (1) +1
Здравствуйте, C0s, Вы писали:

C0s>в частности (и мне такое доводилось делать), если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать в силу определённых ограничений — пожалуйста, ставим контроль ограничений на получателя

C0s>доводилось также делать многоступенчатую обработку, при которой была цепочка сообщений и, соответственно, цепочка получателей, каждый из которых проверял определённые условия, делал определённую работу и мог отсечь выполнение при несоблюдении каких-то условий

Если говорить о бизнес-требованях и высоком уровне, то тут, мне кажется, выгода от ФИФО становится ещё более явной.
Во-первых, ФИФО — это надмножество НЕФИФО, т.е., пожалуйста, делай синхронный запрос-ответ.
Но так же ФИФО позволяет реализовывать и другие паттерны. Один, мне кажется, ты сам привёл — "...если отправитель должен всегда иметь воможность быстро послать сообщение, но получатель не всегда должен его обрабатывать...", в этой ситуации требовалось ФИФО для этих быстро посланных сообщений?

Я не против того, что бы система предоставляла возможность сказать "для этого агента порядок не требуется", если она может реализовать что-то лучше для такого случая. Но в то же время для "высокоуровневой", "удобной" системы, я считаю обязательным так же и возможность задать гарантированный ФИФО. При этом ФИФО больше как выбор "по-умолчанию", а не ФИФО — как оптимизация.

По моему опыту, если идут "низходящие" сообщения (т.е. менеджер устройства посылает устройству) и сообщения типа "запрос", то тогда, в принципе, возможно делать какое-то высокоуровневое управление. Хотя зачастую это только лишняя работа.
Но если идут "восходящие" сообщения (т.е. устройство посылает кому-то — нижние уровни не должны знать о верхних) и/или сообщения типа "нотификация", то тут ФИФО необходимо, т.к. нижний уровень и/или нотификатор не знает даже есть ли там кто-то сверху, а при нотификациях бессмысленно ждать ответа — ну посылает агент-устройство нотификацию, что он детектировал, что связь с устройством разорвалась, ну и что ему делать потом с ответом? отменить разрыв соединения, если с верхнего уровня сказали "отменить"? Детектировал агент, что связь установлена — послал нотификацию, что установлена; детектировал что разоравана — послал, что разорвана. А обрабатывает там кто ещё предыдущие сообщения или нет — пофигу, главное — что бы сообщения "связь установлена", "связь разорвана" не перепутались местами. Плюс не этот агент выбирает время разрыва соединения, его тоже ставят перед фактом, что ему делать? Можно конечно сообщения складывать во внутренний вспомогательный буфер (кстати, обязательно в ФИФО порядке) и потом выдавать их, когда приходят ответы на предыдущие сообщения. Но попахивает уже маразмом...



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 16.11.08 07:03
Оценка: 11 (2)
Я никогда не занимался девелопментом 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, как я понимаю,
еще в худшем положении, если возникнет потребность увеличить ресурсы и использовать все ядра.

Решения, которые я нашел
A Java Fork/Join Framework
DataRush
Что выглядит не очень привликательно.

А что ещё есть — Scala или Erlang через Jinterface Application.

Вообщем, еще пару новвоведений и в мире появится новый доминирующий язык, в доке которого о причинах его появления мы будем читать не только о всех недостатках C++, но и Java.
Другой вариант — многоязычное приложение, что, возможно, тоже не самое лучшее — ведь разные языки должны интегрироваться, и интеграция потребует затрат.

У кого какое мнение — высказывайтесь.

Дополнительное чтение
http://architects.dzone.com/news/building-multi-core-ready-java
http://www.infoq.com/news/2008/06/scala-vs-erlang









19.11.08 03:38: Перенесено из 'Java'
Java Multicore Erlang Scala Parallel computing
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: Lazy Cjow Rhrr Россия lj://_lcr_
Дата: 19.11.08 02:44
Оценка: 10 (2)
remark,

R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.


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

Кроме того, в случае Эрланга есть эффективный и надёжный способ анализа программы на счёт отсутствия дедлоков: Towards a deadlock analysis for Erlang programs. Хотя возможно и для обычных джавы и дотнета есть подобные тулзы.


R>Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.


Не мог бы ты проиллюстрировать сиё подробнее. Всегда считал, что как только мы пишем receive, то тем самым задаём явное упорядочение.

R>Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.


Ну трудно не согласиться.
http://files.rsdn.org/10144/thinker.gif quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 21.11.08 11:33
Оценка: 1 (1) +1
Здравствуйте, 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 нет.

Еще раз повторяться вам, мне кажется, не стоит. А то народу может и надоесть.
Re[14]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 12:24
Оценка: 1 (1) +1
Здравствуйте, RailRoadMan, Вы писали:

G>>Пример очень плохой, это совершенно бессмысленный микротест. Потому, что в данном случае очевидно надо воспользоваться коммутативностью и ассоциативностью сложения, и попросить потоки просто прислать свои числа. Если же число зависит от счетчика, то пример некорректен, так как у программы недетерминированное поведение.


RRM>Он на то и пример, чтобы быть простым.


RRM>Дельта зависит как от полученного числа так и от потока. В этом случае пример корректен, хотя получаемые числа и будут недерерминированы, а кто сказал, что это не то, что мы хотели? Потоки знают, что числа будут случайные.


Если все, что ты хочешь получить, это случайное число, то я выполняю алгоритмическую оптимизацию и убираю все твои потоки.

Разные модели программирования нельзя сравнивать на бессмысленных тестах, потому что применяются разные подходы к декомпозиции алгоритмов. Давай другой пример — осмысленный. Задача, которую надо распараллелить. И посмотрим, что получится.

G>>Однако, если ты так хочешь — то пожалуйста. Надо заметить, что операции над числом у тебя сериализованы, то есть потоки выполняют операцию по очереди. После чего, главный поток ждет на барьере. Вот, что у тебя происходит.


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


Чушь полная. Все вычисления сериализованы, и конкурируют за общий ресурс. Это очень плохая программа.

Реальную задачу приведи, и мы ее попараллелим. Для справки, даже умножение матриц отлично на сообщениях параллелится, хотя на первый взгляд это невозможно, и там просто необходима разделяемая память.
Re[17]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 13:14
Оценка: 1 (1) +1
Здравствуйте, RailRoadMan, Вы писали:

RRM>Когда нечего сказать — переходят на личности (ну или на оценки примеров).


Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.

А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.

RRM>Я описал совершенно надуманный пример максимально оптимальный для разделения памятию. Это в первую очередь пример.

RRM>Готов ты именно его решить на передаче сообщений, что бы получилось эффектичнее чем с разделением памяти?

Ты не описал вообще никакого примера. Ты предложил нам с Синклером эмулировать разделяемую память на одной переменной поверх сообщений. Что разумеется не получится эффективнее, чем прямое использование разделаемой памяти, и чего ни один нормальный человек, работая с сообщениями, в реальных условиях делать не будет.

RRM>Да — с удовольствием посмотрю.

RRM>Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.

Ну да, если взять плохо написанную программу на разделяемой памяти, да переписывать на сообщениях, эмулируя разделяемую память — станет еще хуже. С этим кто спорит-то?

G>>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?

RRM>Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?

Блин, да опиши какую хочешь, мне все равно. Но реальную, чтобы можно было выбирать подход к распараллеливанию.
Re[30]: Ну надо же, еще одна статья.
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 02.12.08 04:49
Оценка: 1 (1) +1
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[53]: пример eao197: "сообщения" рвут "разделяемую память"
От: AVM Россия  
Дата: 15.12.08 13:18
Оценка: 1 (1) +1
Здравствуйте, remark, eao197, Gaperton Вы писали:

R>"Обкакался, так будь мужиком, блин, и имей смелость это признать" (с) Gaperton


Коллеги, давайте перестанем друг друга подкалывать и не будем выяснять кто первый начал, просто перестанем.
Понимаю, что некоторый высказывания коллег провоцируют, но давай просто будем немного взрослее.
А то взрослые мужики, обсуждаете интересную тему, но ведете себя как малые дети в песочнице.
Re[54]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 15.12.08 23:16
Оценка: 1 (1) +1
Здравствуйте, AVM, Вы писали:

AVM>Коллеги, давайте перестанем друг друга подкалывать и не будем выяснять кто первый начал, просто перестанем.

AVM>Понимаю, что некоторый высказывания коллег провоцируют, но давай просто будем немного взрослее.
AVM>А то взрослые мужики, обсуждаете интересную тему, но ведете себя как малые дети в песочнице.

А еще лучше, если кто нибудь возьмет обсуждаемую задачу и напишет совсем совсем простой тест с очередью и разделяемой памяти и просто померяет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 18.11.08 09:42
Оценка: +2
Здравствуйте, 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
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 19.11.08 01:51
Оценка: +1 -1
Здравствуйте, 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
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.11.08 07:27
Оценка: +1 :)
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.11.08 08:53
Оценка: -1 :)
Здравствуйте, DenysSG, Вы писали:
DSG>Сейчас нету времени искать, но должно быть здесь
DSG>Threads and Locks
Естественно, там ничего относящегося к твоим фантазиям нету.
Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 28.11.08 11:14
Оценка: +2
Здравствуйте, Gaperton, Вы писали:

G>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?


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


G>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.


Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...

G>Даже если твою фразу понимать так, как ты здесь пишешь, то тезис о наличии значимых преимуществ у разделяемой памяти, которых якобы лишена модель передачи сообщений, тебе надо для начала доказать. Потому, например, что практика применения MPI и OpenMP его на данный момент не подтверждает. MPI во многих случаях быстрее, чем OpenMP даже на SMP конфигурациях с общей памятью.


Отвечу там.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[20]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 12:12
Оценка: +1 -1
Здравствуйте, remark, Вы писали:

R>Это уже становится интереснее — хотя бы какие-то объяснения с твоей стороны. Обязательно прочитаю статью.

R>НО, во-первых, что бы показать, что у разделяемой памяти нет преимуществ, ты должен приводить ситуации благоприятные для разделяемой памяти, если окажется, что таких ситуаций не удаётся найти или по всех них разделяемая память проигрывает, тогда возможно у неё действительно нет преимуществ.

Тезис доказывает тот, кто его выдвигает. Я говорил, что у разделяемой памяти есть некие недостатки, которых модель с
сообщениями лишена. Это я готов доказать.

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

R>Приводить же просто какие-то ситуации и показывать на них, что обмен сообщениями оказывается быстрее — бессмысленно. Это никак не показывает, что у разделяемой памяти нет преимуществ.


Это ты должен доказать, что они у разделяемой памяти _есть_, а не я, что их нет. Тезис — твой. Для начала — тебе стоит хотя бы озвучить эти декларируемые преимущества. Скорость им не является — MPI обходит OpenMP во многих случаях даже на SMP.

R>Да, на экзотических распределенных машинах для супер-вычислений разделяемая память С.О.С.Е.Т. С этим никто не спорит. Там просто нет разделяемой памяти. Но это, в принципе, и мало кому интересно. Сколько процентов из нас разрабатывает ПО для распределенных кластеров?


Тесты в данной статье производятся на SMP-машине, а не на распределенном кластере.

R>Для того, что бы показать, что у разделяемой памяти ЕСТЬ преимущества мне НЕ надо обгонять MPI умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ.

R>Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.

Сформулируй мою точку зрения, которую я пытаюсь доказать. Очень любопытно. По-моему, я оппонирую тебе насчет твоего тезиса о якобы имеющихся преимуществах разделяемой памяти, которые необходимо утрачиваются в модели передачи сообщений.
Re[14]: Java Parallel computing: multicore, Erlang, Scala
От: thesz Россия http://thesz.livejournal.com
Дата: 28.11.08 12:41
Оценка: +1 :)
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)
Re[21]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 28.11.08 13:14
Оценка: +1 -1
Здравствуйте, 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 — самый крутой и эрудированный, за словом в карман не лезет, аргументы приводит не в тему, но зато сильные, и готов спорить, даже не читая, что пишет оппонент.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[22]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 13:40
Оценка: +1 -1
Здравствуйте, remark, Вы писали:

G>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.


R>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.


Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.

Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.

Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.

R>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.


Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.

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

Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.
Re[18]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 28.11.08 14:30
Оценка: +1 -1
Здравствуйте, Gaperton, Вы писали:

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


R>>ААААААААААА! Вы вместе?


G>Ага. Что, страшно? По-моему, неплохая у нас компания получилась. Синклер, thesz, и я. Мне нравится.



Ну молодцы, радуйтесь дальше, компания пытающаяся доказывать нерелевантными примерами, стирающая в ответе аргументы оппонента, зато придирающаяся к словам, и обвиняющая в отсутствии этих самых стёртых аргументов, приплетающая какие-то римские дискуссии, несущая логическую ахинею...
Против Синклера и thesz то я ничего не имею, но ты, блин, — настоящий тролль.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[23]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.08 21:46
Оценка: -2
Здравствуйте, eao197, Вы писали:

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


G>>>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.


E>>>Питон там давно порвали на британский флаг.


G>>C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.


E>Тогда возникает вопрос:

E>

E>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает.

E>под "отлично" здесь понимается "правильно, но в четыре раза медленее"?

Под "отлично" здесь понимается то, что задача хорошо ложится на модель передачи сообщений, а Эрланг служит для иллюстрации.

Если ты не понял, мы здесь говорим о моделях параллелизма, разделяемая память vs на сообщениях, а не о том, что С++ быстрее чем Эрланг. В таком же стиле как на Эрланге, с асинхронными сообщениями, можно писать и на С++. Скажем, при помощи MPI.

G>>Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.


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


Мое представление в целом соответствует взглядам Дийкстры и Хоара, ты уж меня прости, классическое образование — ничего не могу с собой поделать. И комплексовать на тему, что оно у меня не такое, как у тебя — тоже не получается, извини.

Читайте книги, это прикольно. ((с) Зефиров)

G>>В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются...


E>Если только процессы не работают на разных нодах.


А что, изобрели способ передавать данные с одного компа на другой без копирования? С этого момента подробнее.

В Эрланге нет абсолютно никакого резона запускать несколько нодов на одной машине — виртуальная машина знает, что такое SMP и умеет его готовить.
Re[31]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.12.08 19:20
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Т.е. remark утверждает, что в некоторых случаях, но не в 100% случаев, разделяемая память будет иметь преимущества.


Прокомментируй:

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[33]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 02.12.08 21:54
Оценка: +2
Здравствуйте, 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>>
AVK Blog
Re[33]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 02.12.08 22:59
Оценка: +1 -1
Слыш, Sincler, ты хотел примера, где у гармонично взаимодействующих процессов есть убедительный чистый выигрышь? Так вот, eao197 преподнес все ценителям данного подхода настоящий подарок. Он наконец дал пример, в котором отрыв у "сообщений" будет точным убедительным — а я, честно говоря, до последнего момента думал, что такое в принципе невозможно. Спасибо, дорогой друг eao197.

Ну а теперь, парни, читаем задачу. Это отличный пример, как можно писать на Java или C#, в надежном стиле, с иммутабельными структурами данных, да еще и выиграть в производительности.

E>4. В качестве примера такой ситуации я могу привести гипотетический пример с маршрутизацией звонков/sms по номерам телефонов: имеется большая таблица или специальное дерево, с помощью которой по префиксу номера адресата определяется оператор, которому принадлежит адресат. Эта таблица может совместно использоваться несколькими потоками-маршрутизаторами (может быть даже несколькими десятками таких потоков) -- они обращаются к ней только для чтения.

И имеется один или два потока, которые на основании какой-то внешней информации время от времени вносят изменения в данную таблицу. Например, если процент успешно обработанных пакетов в канале связи с каким-то операторам падает ниже некоторого уровня, то его трафик переадресуется через других операторов.

Таблица выполняется в виде функционально-чистого сбалансированного дерева. Когда изменяющий поток ее изменяет, он высылает потокам worker-ам новую ссылку на корень одним сообщением, multicast-рассылкой. Все.

Это будет работать быстрее, чем [мутабельная] "разделяемая память" [требующая явной синхронизации], по причине того, worker-ы при look-up-ах по таблице не будут пользоваться вообще никакими примитивами синхронизации, а функционально-чистое дерево обладает свойством транзакционности. Учитывая то, что look-up выполняется в сотни раз чаще, чем изменения.

E>В данном случае оформление таблицы маршрутизации в виде агента, взаимодействие с которым выполняется только в режиме асинхронного обмена сообщениями, может повысить накладные расходы по сравнению с разделяемой памятью в разы. Только за счет того, что заявки должны складироваться в какой-то очереди, извлекаться оттуда, обрабатываться, ответ должен сохраняться в какой-то другой очереди и т.д.


Не я реально не пойму — ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы, и путая "гармонично взаимодействующие процессы" с полным отсутствием разделяемой памяти? Честно?
Re[48]: Offtop
От: kdw Россия  
Дата: 07.12.08 12:22
Оценка: -2
Здравствуйте, Gaperton, Вы писали:

G>Так не читай мои посты. Кто-то заставляет?


Кроме тебя в этом форуме есть и другие люди ,

как ты себе представляешь чьи то посты читать а чьи то нет.

вот приходиться и твои читать.
Re[50]: Offtop
От: kdw Россия  
Дата: 08.12.08 09:11
Оценка: :))
Здравствуйте, Gaperton, Вы писали:

G>Значит, прими касторки. Мне, знаешь, пофигу, читаешь ты, не читаешь.



Ты форум не перепутал ? тебе скорее всего на медицинский надо, рецепты выписывать.

Ладно , кто то должен быть умнее , думаю это мой последний пост если будешь продолжать
в том же стиле .
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 13.12.08 20:28
Оценка: -1 :)
Здравствуйте, 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, и на всех остальных современных архитектурах.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[49]: опять начинается
От: remark Россия http://www.1024cores.net/
Дата: 15.12.08 19:06
Оценка: -2
Здравствуйте, eao197, Вы писали:

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


G>>Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке.


E>Ничего подобного. Писатель создает новую копию структуры, а затем подменяет ссылку на нее в глобальной переменной одной атомарной операцией (перед которой писатель выполняет все необходимые fences).



Именно. Так где используется широковещательная рассылка сообщений для публикации объекта, можно использовать обычную публикацию указателя, мьютекс тут не нужен. Не надо его сюда приплетать.


G>>Касательно того, что atomic_read, на котором eao


E>eao197, eao -- это такое же некорректное сокращение, как и Gaper.


Ещё одна из его фишек, типа называть собесебника на "Вы", но при этом "вы" писать с маленькой буквы, или вставлять в середину абзаца вспомогательное предложение что типа собеседник не написал ни одной программы, или что собеседнику никогда не додуматься до таких первоклассных решений как Gaperton'у. А потом ещё как ни в чём не бывало говорить, что он типа выше таких низких вещей, и что его интересует только техническая дискуссия.
Я ещё могу понять, когда человек высказывает такое прямо и открыто. Но когда вот так, изподтяжка...



G>>собирался решать эту задачу, медленнее обычного — это правда и остается правдой, в данном случае нужен честный барьер в получателе чтобы все работало.


E>Зачем барьер в получателе?


Вот видишь, Gaperton, люди-то тут следят за ходом дискуссии. И твои левые попытки оправдать свою техническую неграмотность приплетанием левых фактов типа, что получателю надо упорядочивать какие-то store, или пуще того какие-то store-load последовательности — не остаются не замеченными. Тебя уже все раскусили.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[65]: пример eao197: "сообщения" рвут "разделяемую память"
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.12.08 05:36
Оценка: +2
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[67]: пример eao197: "сообщения" рвут "разделяемую память"
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.12.08 06:58
Оценка: +2
Здравствуйте, eao197, Вы писали:

E>Аналогия между TCP и передачей сообщений некорректна. В TCP данные передаются потоком и любой новый пакет автоматически объявляется шествующим за предыдущим пакетом. Поэтому параметры упорядочения присутствуют в каждом из пакетов и позволяют производить их пересборку на стороне получателя.

Полностью корректна. Еще раз: если отправителю/получателю важно, в каком порядке приходят сообшения, он просто добавляет в сообщения seq number.
Другого способа нет — разве что неявно всовывать LSN принудительно во все сообщения, но я не вижу в этом никакого смысла.

E>В случае отсылки сообщений, если в сообщениях не заданы эти параметры предшествования/упорядочения самим разработчиком, информации для восстановления порядка отсылки сообщений нет. Можешь увидеть это на примере SMTP -- если ты отправляешь одному и тому же получателю несколько писем, то они могут придти к получателю в разном порядке (особенно, если сообщения сильно различаются по размеру).

И, заметь, никакой проблемы это не представляет.
Если получатель хочет упорядочить по порядку отправки — нет проблем, в каждом письме есть хидер sent timestamp.
Опять же, если мне важно, чтобы ты читал письма в определенном порядке, то я включу эту информацию в письмо.

Еще раз намекаю, что с моей точки зрения, не стоит запихивать поддержку FIFO прямо в самый-самый нижний слой системы. Достаточно сделать удобные библиотеки, позволяющие описывать протокол взаимодействия.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[57]: пример eao197: "сообщения" рвут "разделяемую память"
От: thesz Россия http://thesz.livejournal.com
Дата: 17.12.08 08:38
Оценка: 57 (1)
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)
Re[24]: Java Parallel computing: multicore, Erlang, Scala
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 30.11.08 07:42
Оценка: 36 (1)
Здравствуйте, 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: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.12.08 07:03
Оценка: 17 (1)
Здравствуйте, Gaperton, Вы писали:

G>Таблица выполняется в виде функционально-чистого сбалансированного дерева. Когда изменяющий поток ее изменяет, он высылает потокам worker-ам новую ссылку на корень одним сообщением, multicast-рассылкой. Все.


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

G>Не я реально не пойму — ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы, и путая "гармонично взаимодействующие процессы" с полным отсутствием разделяемой памяти? Честно?


Ты правда думаешь, что можешь просить меня не переходить на личности утверждая, что я не написал ни одной программы?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.12.08 09:15
Оценка: 16 (1)
Здравствуйте, Gaperton, Вы писали:

G>На практике 7% называется "одинаковая производительность", и никто не будет расшибаться в лепешку, чтобы эти 7% ликвидировать.


Расшибаться не обязательно. Достаточно выбрать для задачи подходящий инструмент. В некоторых случаях это будет OpenMP.

E>>На практике, ты не сможешь этот выигрыш нивелировать.

G>На практике, смогу. Если захочу.

"Дайте мне точку опоры и я сдвину Землю". Вижу, что аргументы в разговоре уже перешли в разряд "непробиваемых".

G>В любом случае, тебе-то откуда знать, что я смогу а что нет.


Судя по твоему заявлению о том, что на C++ можно программировать в стиле Erlang с использованием MPI.

G>Да? Тогда прокомментируй еще вот это:

G>

G>А уж по поводу ситуации, где нам надо только считать данные — обмен сообщениями (на любых очередях), так и останется медленнее на несколько порядков.


А там все понятно. Remark дал эту оценку одному вполне конкретному примеру. Вот этому
Автор: remark
Дата: 25.11.08
. Все. Никаких претензий на всемирное господство разделяемой памяти.

G>Так вэлкам! Что ж ты никак не покажешь-то эти преимущества? Что тогда для тебя преградой то является, а?


Нет смысла заниматься доказательствами, когда глобальная переменная-указатель в любой момент может быть объявлена вырожденой очередью сообщений длиной 1. Что такой же маразм, как и утверждение, что точка является частным случаем прямой.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[47]: А можно еще лучше
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 13.12.08 20:22
Оценка: 15 (1)
Здравствуйте, Gaperton, Вы писали:

G> Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.


Пример из моего последнего выступления на Платформе:
count =
    data
        .Select(text => Future<int>.Create(() => CalcWords(text)))
        .ToArray()
        .Select(future => future.Value)
        .Sum();


Но можно проще

count =
    data
        .AsParallel()
        .Select(text => CalcWords(text))
        .Sum();
... << RSDN@Home 1.2.0 alpha 4 rev. 1120 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: gandalfgrey  
Дата: 21.11.08 13:23
Оценка: 8 (1)
Здравствуйте, 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]).


Таперича дедлочит
Re[25]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 01.12.08 18:32
Оценка: 4 (1)
Здравствуйте, 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 доказывает, что разделяемая память быстрее, и обладает какими-то преимуществами. Разница понятна? Понятно, что это не обратные тезисы, получаемые отрицанием друг друга? Эта статья — контрпример к его тезису. Так понятнее?

Пойми хотя бы, о чем идет спор, и у кого какая позиция, прежде чем влезать — сэкономишь всем время. Ну неохота ни о чем спорить. А то как обычно — навоображали себе идиотизма, приписали его участникам, и давай шашкой махать.
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: Nicht Россия  
Дата: 17.11.08 10:00
Оценка: 3 (1)
Здравствуйте, 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 используя сторонние библиотеки.


Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам
И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 18.11.08 20:23
Оценка: 3 (1)
Здравствуйте, yumi, Вы писали:

Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.



Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.

Гонки — тоже запросто. Одно сообщение подразумевает, что перед ним уже было обработано другое. И в 99.99% случаев так и происходит. А в 00.01% случаев получается по-другому.

Обмен сообщениями — бесспорно более высокоуровневая модель нежели "голая" разделяемая память — пиши что-куда хочешь, читай что-откуда хочешь. Но архитектурных проблема она автоматически не решает. Эти проблемы решаемы. Так же как и проблемы с разделяемой памятью.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[13]: Java Parallel computing: multicore, Erlang, Scala
От: RailRoadMan  
Дата: 28.11.08 11:19
Оценка: 3 (1)
Здравствуйте, Sinclair, Вы писали:

R>>Это будет дешевле и значительно быстрее чем обмен сообщениями — нет никаких очередей, блокирований/разблокирований потоков,

S>А как же lock()? Ты думаешь, lock() не приведет к блокировке потока в ожидании того, пока кто-то другой не сделает unlock()?

Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Re: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 17.11.08 08:00
Оценка: 2 (1)
Здравствуйте, DenysSG, Вы писали:

DSG>Все мы знаем что в "параллельном мире" существуют 2 основные концепции:

DSG>- Shared memory
DSG>- Message Passing Interface (MPI)

Есть еще STM (Software transactional memory) и использование полностью immutable data types.

DSG>А что ещё есть — Scala или Erlang через Jinterface Application.


Для JVM есть еще Clojure.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re: Java Parallel computing: multicore, Erlang, Scala
От: Аноним  
Дата: 17.11.08 15:44
Оценка: 1 (1)
Здравствуйте, DenysSG, Вы писали:

DSG>Я никогда не занимался девелопментом parallel computing, поэтому все что я здесь напишу результат 2-х дневного исследования,

DSG>т.к. в пятницу мне сообщили что я буду программировать на Erlang`е для нашего Java EE проекта.

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

Что касается MPI — то это, скажем так, с одной стороны, некоторое конкретное апи, а сдругой стороны просто идеология. Тут, конечно, без сторонних библиотек не обойтись, причем есть готовые библиотеки для MPI в виде JNI оберток вокруг с-шных реализаций MPI, есть Pure Java библиотеки, реализующие MPI, и есть библиотеки, которые предоставляют аналогичный по смыслу сервис обмена сообщениями между потоками при помощи не-MPI апи. Конечно, нормальный MPI позволяет общяться не только ядрам в одном процессоре, но если рассматривать отдельно взятый компьютер, то передача сообщений между потоками сделана, очевидно, через ту самую общую памать.

Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 18.11.08 10:34
Оценка: 1 (1)
Здравствуйте, yumi, Вы писали:

Y>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.


см. 4.2 там же и про race condition (поиском)
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 03:44
Оценка: 1 (1)
Здравствуйте, 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[35]: Ну надо же, еще одна статья.
От: gandalfgrey  
Дата: 03.12.08 10:02
Оценка: 1 (1)
Здравствуйте, Курилка, Вы писали:

К>А есть примеры как поддержка сообщений может быть поддержана аппаратно?

А на транспьютерах. Тамошние каналы как раз служат для передачи сообщений, а вот разделяемой памяти у них, насколько я понимаю, нет вовсе.
Между прочим, сейчас начинается некий ренессанс транспьютеров — видимо, вследствие того, что научились эффективно их использовать
Re[36]: пример eao197: "сообщения" рвут "разделяемую память"
От: DK3981 Россия  
Дата: 03.12.08 12:24
Оценка: 1 (1)
Здравствуйте, Sinclair, Вы писали:

S>Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.


Я здесь вижу только одну проблему: если у нас есть 2 потока, модифицирующих дерево, и оба они "одновременно" получат сообщение, приводящее к необходимости это дерево модифицировать. Тогда каждый из них построит своё новое дерево, и после этого разошлёт новый корень, но в результате данные, изменённые одним из потоков будут потеряны.

Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.
... << RSDN@Home 1.2.0 alpha rev. 728>>
Re[35]: Ну надо же, еще одна статья.
От: thesz Россия http://thesz.livejournal.com
Дата: 03.12.08 14:13
Оценка: 1 (1)
T>>Разделяемая память поддержана аппаратно (да-да! поддержана аппаратно), передача сообщений — нет. Посмотрим, что будет, если будет хотя бы поддержка обоих.
К>А есть примеры как поддержка сообщений может быть поддержана аппаратно?

На уровне инструкций: http://wavescalar.cs.washington.edu/

Это совсем низкий уровень, совсем маленькие сообщения.

Сравни общую простоту реализации и масштабируемость с простотой реализации и масштабируемостью "системы с разделяемой памятью", ранее известной под именем обычный процессор (RISC, допустим).

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

И мало кто знает, что в лучшем представителе семейства RISC DEC Alpha 21264 оная память была разделена на две части по числу каналов исполнения инструкций и половинки синхронизировались через такт после окончания операции.

Это ужас просто.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: LeonidV Ниоткуда http://vygovskiy.com
Дата: 16.11.08 23:13
Оценка: +1
Здравствуйте, Aib, Вы писали:

Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.


Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
http://jvmmemory.com — простой способ настройки JVM
Re: Java Parallel computing: multicore, Erlang, Scala
От: Nicht Россия  
Дата: 17.11.08 08:15
Оценка: +1
Здравствуйте, 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 лет наза люди писали приложения которые работали на сотнях процессоров и ничего, справлялись. Просто серверные стойки будут меньше, шуму будет меньше, отдача температуры будет меньше. В общем к светлобу будущему движемся
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 18.11.08 10:12
Оценка: -1
Здравствуйте, Аноним, Вы писали:

А>Java давным давно позволяла писать многопоточные приложения, причем без использования сторонних библиотек. И так же давным давно Java использует все ядра, какие найдет в вашем процессоре, причем опять без использования сторонних библиотек и без каких-либо дополнительных настроек.


Ну дык, тогда уж и С++ это умеет. Да и вообще ОС сама масштабирует потоки на ядра. Речь-то ведь изначально совсем о другом шла...

А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.


Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 18.11.08 13:08
Оценка: -1
Здравствуйте, Nicht, Вы писали:

N>А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.


Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?

Y>>Без поддержки виртуальной машины, это в принципе невозможно.


N>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?


Erlang avalanche
Автор: Lazy Cjow Rhrr
Дата: 12.12.06
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.11.08 04:20
Оценка: -1
Здравствуйте, DenysSG, Вы писали:
DSG>Это интересно. До боли мне кажется что вы второй раз ошибаетесь.
DSG>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты?
Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах.
В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 07:14
Оценка: +1
Здравствуйте, remark, Вы писали:

R>А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).

а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: Курилка Россия http://kirya.narod.ru/
Дата: 21.11.08 18:19
Оценка: +1
Здравствуйте, remark, Вы писали:

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


G>>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.


R>...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.


R>Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.


Или получая проблемы из обоих моделей
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 25.11.08 07:58
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

R>>Я надеюсь, это шутка?


G>Ты о чем? О том, что у современных суперкомпьютеров нет общей памяти? Нет, это не шутка. Разделяемой памяти у них нет, правда.


Нет, я не об этом. Я о том, что ты серьёзно утверждаешь, что у разделяемой памяти нет приемуществ. Вопрос на подумать — почему, например, параллельная одновременная сборка мусора в .NET/Java реализована на основе разделяемой памяти, а не основе обмена сообщениями.


R>>Очевидные и широко-известные приемущества разделяемой памяти — это (1) скорость работы и (2) низкая латентность.


G>"Очевидное и широко-известное преимущество" не работает на современных суперкомпьютерах, состоящих их сотен или тысяч машин, соединенных сетями InifiniBand или подобными. Там рулит MPI, основанный на модели передачи сообщений.


R>>А таком контексте вопрос по поводу факта наличия преимуществ у разделяемлой памяти меня просто шокирует.


G>Предлагаю перевести мозг в позицию on. И внимательно посмотреть, что я тебе пишу. И свои посты перечитать. Сопоставить. ПОДУМАТЬ.


Называется "научи дурака богу молиться...". Я, конечно, извиняюсь, что я не привёл контекст, просто я думал, что это достаточно очевидно. Контекст — многоядерные/многопроцессорные машины, которые имеют разделяемую память и даже более — разделяемая память — это основная (и скорее всего — единственная) физическая модель взимодействия на них. И даже ещё более — даже машины в кластере внутри себя могут общаться на основе разделяемой памяти, если машины — многоядерные/многопроцессорные. Естественно, если мы говорим о распределенных системах, то тут разделяемая память не релевантна. Так же как не релевантен обмен сообщениями на, например, некоторых микроконтроллере, там даже скорее всего и ран-тайм-то не влезет. Ну и что из этого? Если следовать твоей линии рассуждений, то получается, что обмен сообщениями — это @#$%%^, т.к. он не может применяться на маленьких микроконтроллерах. Конечно, это неправильно. Невозможность применения обмена сообщенями в некоторых ситуациях ничего не говорит о нём как таковом, просто значит — это не его область. Точно так же и с разделяемой памятью — просто не пытайся привинчивать её к распределенным кластерам (я этого не делаю). У неё другая область применения — и там у неё есть преимущества.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: prVovik Россия  
Дата: 25.11.08 11:11
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

V>>Что в свою очередь решается I/O APM
S>Ну то есть опять же пул потоков.

Только потоки там халявные, и по сути не потоки вовсе. Это я к тому, что зелёные потоки для этого случая являются скорее средством повышения удобства программирования, чем необходимостью.
лэт ми спик фром май харт
Re[16]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 11:28
Оценка: -1
Здравствуйте, remark, Вы писали:

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


G>>>>Да ну? Правда штоли? А можно мне посмотреть на мой пост, где я это говорю?


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


G>>Убить нельзя помиловать. Твою фразу вполне корректно с точки зрения русского языка трактовать так, как будто у сообщений нет преимуществ [перед разделяемой памятью] в принципе.


R>Хммм... мне кажется, что, что бы трактовать так как ты подумал, там должна была бы быть запятая: ...проблем, и преимуществ...


Форумный язык таков, что запятую можно и пропустить, это нормально и на это никто не обращает внимания. К тому же, слово "преимуществ" ты выделил болдом, что играет роль запятой, отделяя его от предыдущих слов акцентом. Можно, можно было так воспринять. Я так и воспринял.
Re[19]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 28.11.08 11:31
Оценка: -1
Здравствуйте, 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 умножение матриц. И уж точно не надо это делать ВНАЧАЛЕ.
Я надеюсь, что это ты просто специально пытаешь внести некоторые логические ошибки в свои доказательства, что бы доказать свою точку зрения.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[12]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 11:43
Оценка: +1
Здравствуйте, RailRoadMan, Вы писали:

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


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

S>>Итак, у нас есть некоторое число s. Поток 1 передает его в поток 2; поток 2 прибавляет к s некое число q, известное только ему, и возвращает обратно.

RRM>Это немного нечестно предлагать пример оптимизированный под модель обмена соообщениями.


RRM>Вот другой пример:

RRM>Есть некое число s инициализированное нулем.
RRM>Несколько потоков каждый из которых читает это число и увеличивает на известное только ему значение. Далее поток как-то обрабатывает прочитанное значение.

RRM>Можно взглянуть на решение этой задачи с помощью посылки сообщений?


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

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

Оптимизированный вариант на сообщениях — процессы worker-ы объединены в линейный список по PID-ам. Последний worker знает PID главного процесса, главный — PID первого. И действие выполняется передачей сообщения по этому кольцу.
Re[14]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 28.11.08 11:44
Оценка: +1
Здравствуйте, RailRoadMan, Вы писали:
RRM>Грамотная реализация мьютекса под SMP даже в случае если невозможности захвата мьютекса не будет сразу блокировать поток, а некоторое время покрутиться на спин локе в юзер моде ожидая быстрого освобождения мьютекса и только если мьютекс не освободится заблокирует поток в ядре. В случае очень коротких блокировок мьютексы могут работать без переходя в ядро для блокировки потока, даже если есть реальная конкуренция между потоками
Грамотная реализация очереди будет делать то же самое.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[15]: Java Parallel computing: multicore, Erlang, Scala
От: RailRoadMan  
Дата: 28.11.08 12:24
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

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


G>>>Кстати, это как, ничего, что твой пример, который "оптимизирован под разделяемую память" — последовательный, и содержит ноль параллелизма?


RRM>>А ничего, что в примере до этого (ктр про s и q) не сильно больше?


G>Ну, вообще-то "чего" . Надо реально параллельные примеры брать, мне кажется. А то немного странно получается, сравнивать модели параллелизма на последовательных программах.


Ну если это принципиально, то работа с этим числом лишь малая часть работы потоков в системе. Они вообще независимы, кроме этого числа их больше ничего не связывает.

Практически идеальная ситуация но увы, есть это число и с ним нужно работать именно так как я описал.
Re[16]: Java Parallel computing: multicore, Erlang, Scala
От: RailRoadMan  
Дата: 28.11.08 12:43
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

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


R>>>Я думаю, RailRoadMan имел в виду ситуацию, когда эта операция это только одна из стадий обработки запроса на сервере — число процессов не детерминировано, времена и частота выполнения этой операции тоже не детерминированы.

R>>>Ну, какой тут будет оптимизированный вариант на сообщениях?

RRM>>Именно это и имел в виду


G>Не знаю, что ты имел в виду и какое отношение это имеет к серверу, потому что описал ты отвратительную реализацию генератора случайных чисел.


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

Да — с удовольствием посмотрю.
Нет — признай, что этом (именно в этом идиотском случае, если так легче) случае разделяемая память рулит.

G>Не стесняйся, опиши реальную серверную задачу, а я тебе ее положу на Эрланг, и она отлично заработает. Думаешь, в первый раз?

Кстати а почему серверную? Stanalone приложение параллельным быть права не имеет?
Re[18]: Java Parallel computing: multicore, Erlang, Scala
От: RailRoadMan  
Дата: 28.11.08 13:25
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

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


RRM>>Когда нечего сказать — переходят на личности (ну или на оценки примеров).


G>Я ничего не сказал про твою личность. Я сказал, что ты привел в качестве примера отвратительную, неэффективную реализацию генератора случайных чисел. Это — правда, это можно при желании математически доказать.


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

G>А вот ты перешел на мою личность, заявив, что мне нечего сказать. Ответный переход на личности с моей стороны, мог бы выглядеть, например, так — для иллюстрации: "иногда слышишь такие глупости, что в ответ действительно мало что можно сказать". Но я ведь тебе этого не говорю, правда? А мог бы.


Re[19]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 13:52
Оценка: +1
Здравствуйте, RailRoadMan, Вы писали:

RRM>


Ага, именно Задачу разбирать будем, или как?
Re[23]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 28.11.08 14:17
Оценка: -1
Здравствуйте, Gaperton, Вы писали:

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


G>>>Ты взялся спорить, и заявил, что у разделяемой памяти есть еще и преимущества. Ты этот тезис и доказывай, что они есть.


R>>Это что за бред такой? Я сделал утверждение. Если все согласны, то и никто ничего не доказывает. Если кто-то несогласен, то это значит, что он делает обратный тезис, значит оба вольны доказывать свою точку зрения.


G>Это не бред, а правило научных дискуссий, в первый раз, кстати, появившееся в римском праве. Бремя доказательства истинности тезиса лежит на стороне, выдвигающей этот тезис. Не наоборот. Если ему не следовать, то один дурак способен наворотить столько, что не разгрести и сотне мудрецов. Докажи, например, что Барака Обама — не инопланетянин, а земля не была сотворена за 7 дней вместе со скелетами динозавров.


Что-то я только не понял, почему точка, что разделяемая память не имеет преимуществ принята за изначальную и не требующую даказательств. Вообще-то это не доказано. Так что давай так, за изначальную точку принимаем, что разделяемая память лучшая по всем параметрам модель. А дальше применяем твои "правила научных дискуссий".
Отмашка. Начинаем. Пожалуйста, мы все слушаем тебя — теперь ты *должен* даказать, что обмен сообщениями имеет хоть какие-то преимущества перед разделяемой память, а потом, что он лучше во всех ситуациях.


А вот это я вообще не понял твоей @#$ни с вырезанием и игнорированием как раз моих аргументов по существу вопроса в таком контексте, что типа я ничего не доказываю, а ты типа ведёшь "научные дискуссии", и ты опять тычешь своим неревантным примером и говоришь, что я ничего на него не отвечаю, хотя я тебе по поводу него уже отвечал. И как тут не переходить на личности?! Озвучивать я не буду, но мне про тебя уже всё понятно...
Аргументы придётся скопировать ещё раз:

Я между прочим, если ты не заметил, или немеренно игнорируешь, как раз доказываю, что разделяемая память имеет приемущества. Краткое содержание предыдущих серий: (1) обмен сообщениями — это как минимум одна модифицирующая операция с разделяемой памятью (добавлние в очередь) + ещё некий оверхед. Это не может быть быстрее чем просто одна модифицирующая операция с разделяемой памятью. По моему опыту — выигрыш как *минимум* 100 тактов, в реальности может быть и 500. Если мы можем обойтись немодифицирующй операцией над разделяемой памятью, то тут обмен сообщениями будет проигрывать на порядки. (2) ФИФО обмен сообщениями склонен остужать данные в кэше. Это системный фактор касающийся производительности, его сложно описать в терминах микробенчмарка. Но именно поэтому те фреймворки могут обойтись ЛИФО обменом реализуют именно его. Большинство же фреймворков НЕ могут обойтись ЛИФО. (3) обмен сообщениями иногда пораждает очень неприятный феномен перегрузок из-за того, что каждый агнет может генерировать неограниченный объём работы для *других* агентов. Врагу не пожелаешь оказаться в такой ситуации, т.к. как исправлять порой просто не понятно. Мне приходилось просто переписывать на разделяемую память. Плюс проявление эффекта зависит от аппаратной платформы.
Ты же ничего не прокомментировал по сути, зато сотряс много воздуха насчёт распределенных кластеров и того, что обмен сообщениями иногда лучше. Все, конечно, рады твоей эрудиции, но она тут не будет объективным аргументом.




G>Это не я должен доказывать, что ты не прав. Хотя я, кстати, привел тебе контрпример с MPI, реакции на который пока нет. Тишина.


Во-первых, я не раз указывал, что твой пример практически не имеет отношения к вопросу. Во-вторых, ну ты рассмешил, ты сам-то смотрел эту статью? Там во множестве случаев OpenMP быстрее причём на обеих машинах. А вот это факт уже имеет отношение к делу и доказывает, что разделяемая память имеет преимущества перед обменом сообщениями.


G>Короче, с людьми не соблюдающих элементарных правил дискуссии я не спорю. Либо придерживайся правил, либо — никаких проблем, завязываем, и изволь спорить с пионерами.


А какое правило-то? Что твоя точка принимается за аксиоматическую, а моя за требующую доказательства? В споре-то 2 точки зрения, нет?


R>>У тебя, кстати, какая точка зрения? Будь добр высказать её явно. А то за твоей мастерской игрой слов ничего не понятно, начинает складываться такое ощущение, что твоя цель просто бессмысленно поспорить.


G>Я тебе, кажется, ясно сказал, нет? Я оппонирую тебе в твоем тезисе, что у разделяемой памяти есть неотъемлемые преимущества, которые обязательно потеряются при использовании модели сообщений. Своих тезисов, помимо того, с которым ты согласен, и с которыми тебе удалось бы поспорить, я в данной дискуссии не выдвигаю. Я очень аккуратен с тезисами, отличаю их от "мнений", и стараюсь не нести херню.


Ну вот реальное доказательство — посмотри статью, которую ты приводил


G>Не удивляйся, в дискуссии вовсе не обязательно у обеих сторон должны быть строго противоположные тезисы. В ней доказательство одного тезиса ни как не связано с тезисом противоположной стороны.


Т.е. ты согласен с моим тезисом? Замечательно, молодец. Прекращаем дискуссию.


G>Если тебя все-таки интересует мое "мнение" о проблеме (мнение, как известно, во отличии от тезиса, ни доказать ни опровергнуть невозможно, это считай базарный треп), то я сильно сомневаюсь, что класс задач, на которых разделяемая память даст убедительный отрыв от модели с сообщениями, достаточно широк, чтобы это принимать во внимание. Хотя я допускаю, что вполне возможно найти такие примеры. Ты, впрочем, их пока не нашел.


Ну свою-то статью посмотри. Класс задач — научные вычисления.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[16]: Java Parallel computing: multicore, Erlang, Scala
От: thesz Россия http://thesz.livejournal.com
Дата: 28.11.08 15:27
Оценка: -1
R>Всё ещу жду от тебя ссылок про dynamic data flow:
R>http://www.rsdn.ru/forum/message/3190055.1.aspx
Автор: remark
Дата: 27.11.08


Я не ставлю отсылки уведомлений.

R>А теперь и на throttling.

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

Нет.

Читайте книги, это прикольно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[24]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 15:36
Оценка: -1
Здравствуйте, 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>Ну свою-то статью посмотри. Класс задач — научные вычисления.


Да ну? А тут какой-то тролль давеча с матюгами орал, что этот пример не имеет отношения к делу? Кто ж был этот тролль, а, не напомнишь?
Re[26]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.08 20:40
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

G>>Я тебе привел ссылку на ИССЛЕДОВАНИЕ ПРОИЗВОДИТЕЛЬНОСТИ, где MPI основанный на сообдщениях в большинстве случаев БЫСТРЕЕ чем система на OpenMP НА ОБЩЕЙ ПАМЯТИ НА ОДНОЙ МАШИНЕ.

C>Просто-напросто, модель OpenMP не подходит для многих задач.

C>Что тут такого удивительного, не понимаю?


А я разве удивляюсь? Это вон remark так удивился, что аш в истерике зашелся .

Тише, не спугни его, я хочу посмотреть, у него ума хватит в интернете что-нибудь поискать, или нет.

C>Если делать задачи на разделяемой памяти с нормальными явными блокировками и потоками, то тут будет совсем другая картина.


Ну да, а на ассемблере можно MS SQL Server написать, а чайной ложкой вырыть тоннель под ЛаМаншем .
Re[21]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.08 08:15
Оценка: +1
Здравствуйте, eao197, Вы писали:

G>>Но это мы еще посмотрим — думаю, шансы порвать Питон у меня есть.


E>Питон там давно порвали на британский флаг.


C++ быстрее Эрланга на микротестах, а Питон примерно ему равен, языки одного класса.

G>>1. один поток читает файл, выполняя минимальный лексический разбор — вычленяя записи друг от друга, откладывая всю возможную работу на потом, и раздает их как сообщения воркерам.


E>Ага, вычитывает блоки по несколько Mb, а затем высылает их другим процессам/нитям.

E>А если не высылает, а передает указатель на преаллоцированный буфер, то что это такое, как не использование разделяемой памяти?

Если этот указатель кладется в queue, или в объект с интерйесом queue, то это передача сообщения. И совершенно неважно, указатель там на преаллоцированный буфер, или нет. Важно, что ты не оперируешь явно разделяемой памятью и примитивами синхронизации.

В Эрланге, например, я воспользуюсь для этого иммутабельными бинарями, и уверяю тебя — на нижнем уровне данные ни разу не скопируются, управление памятью будет практически аналогично С++. При этом, никакой разделяемой памяти, видимой программисту, в Эрланге нет.

G>>Для С++ потребуется толковый класс треда, очереди сообщений, и хороший аллокатор.


E>Победитель просто использует boost::thread без очередей сообщений и аллокатора.


Победитель просто использует С++, и оптимизированный ввод-вывод, потому что программа утыкается в диск, а не в CPU.
Re[18]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 01.12.08 05:52
Оценка: +1
Здравствуйте, RailRoadMan, Вы писали:
RRM>Да все это понятно. Ты только объясни зачем мне здесь заводить спец поток, ктр будет владеть этим числом. Зачем он мне _тут_ уперся, хватит простейшего кода на atomic функциях и разделяемых данных и все.
Видишь ли в чем дело — атомик функции хорошо работают тогда, когда память реально разделена. Ну там, к примеру, речь идет о нескольких ядрах с общим кэшем.
Как только это предположение перестает выполняться, всё становится очень плохо.
Тот "спец поток", который тебе кажется лишним, лучше описывает ситуацию с NUMA.
RRM>Да если это erlang то поток будет очень легким, а если нет? Если у меня системные потоки?
Поясняю: этот "владеющий поток" — всего лишь удобная абстракция. Не нужно трактовать его буквально, как "системный поток". Идея именно в том, что некий фреймворк (например эрланг) предоставляет тебе некий набор абстракций. Ты строишь реализацию из этих абстракций; а затем она автоматически превращается в низкоуровневое решение на конкретной аппаратуре. Если есть возможность — потоки окажутся лёгкими. Если нет — будет поднят системный поток.
RRM>Единственно что мы с remark-ом (надеюсь я правильно его понимаю) хотим показать, что _иногда_ разделяемый память может быть лучше.
Тут важно при обсуждении пользоваться одинаковыми уровнями абстракции. А то получается, что под разделяемой памятью понимается InterlockedIncrement, а под сообщениями — PostThreadMessage. В таком варианте разделяемая память почти всегда победит. А если мы говорим об абстракциях, то оптимизировать программу с разделяемой памятью крайне тяжело — в отличие от программы, написанной в терминах посылки сообщений. Дийкстра неспроста придумал гармонично взаимодействующие процессы
RRM>
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[29]: Java Parallel computing: multicore, Erlang, Scala
От: Gaperton http://gaperton.livejournal.com
Дата: 01.12.08 23:09
Оценка: -1
Здравствуйте, eao197, Вы писали:

Понятно, то есть, тебе хочется докопаться.

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.

Противоречие налицо. Всего доброго, докапывайся дальше.
Re[30]: Ну надо же, еще одна статья.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.12.08 12:14
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Да что ты говоришь, дорогой. Прям все совсем-пресовсем не так, да?


Да, в первой статье прямо говорится, что хорошо оптимизированная OpenMP программа обгоняет хорошо оптимизированную MPI программу.

G>А вот, удивительное рядом — глянь — тесты на Core 2 Duo.

G>http://www.cmpe.boun.edu.tr/~ozturan/CMPE49B/linuxmagarticle.pdf

Глянул.

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++.
Re[31]: Ну надо же, еще одна статья.
От: Gaperton http://gaperton.livejournal.com
Дата: 02.12.08 15:29
Оценка: -1
Здравствуйте, 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, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.


А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?
Re[32]: Ну надо же, еще одна статья.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 02.12.08 18:42
Оценка: +1
Здравствуйте, 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++.
Re[32]: Ну надо же, еще одна статья.
От: AVM Россия  
Дата: 02.12.08 20:25
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

E>>Самое время, имхо, заговорить о форумной магии. Remark сказал, что в некоторых случаях разделяемая память будет иметь преимущества над обменом сообщениями.


G>Началось все с того, что я сказал, что модель asynchoronous message passing лишен недостатков, свойственной модели разделяемой [мутабельной] памяти. Remark влез с комментариями, что я, мол, недостаточно честен, и мне стоило бы сказать, что она лишена еще и преимуществ разделяемой памяти. Пересказывая вкратце дальнейшую дискуссию, я не согласился с тем, что с моей стороны было бы честнее утверждать то, что мне далеко не очевидно, и предложил remark-у, раз ему так хочется — озвучить эти преимущества, о которых он говорит, а потом обосновать их наличие. Что remark делать отказался, предложив мне опровергнуть их отсутствие.


E>> После чего разговор был переведен на сравнение OpenMP и MPI на некоторых вычислительных задачах...


....ПОСКИПАНО.....

E>>Ну ты на RSDN, пожалуй, самый главный мастер художественного слова. Данная тема служит тому еще одним доказательством.

G>А ты им, пожалуй, не являешься. Что еще раз подтверждается данной темой.
G>Ты на личности переходить прекратишь? Или так сильно неймется, что это никак сделать нельзя?

Коллеги, давайте лучше про OpenMP и MPI!
Re[35]: пример eao197: "сообщения" рвут "разделяемую память"
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.08 07:45
Оценка: -1
Здравствуйте, eao197, Вы писали:
E>Ссылку на корень можно подменить даже не рассылая ее worker-ам.
Это заблуждение.
Точнее, так можно сделать, но только в том случае, если эта ссылка наблюдаема из разных потоков.
Но тогда в них придется вставлять примитивы блокировки для обеспечения изоляции. На первый взгляд кажется, что можно обойтись атомарностью неблокирующего чтения, но это только в том случае, если транзакция маршрутизации требует только однократного прохода по дереву. В противном случае каждому worker придется перед началом каждой транзакции выполнять копирование ссылки на корень, что опять же дорого. Это эквивалентно постоянной рассылке сообщения "корень дерева теперь здесь".
Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[36]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.12.08 10:25
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

E>>Ссылку на корень можно подменить даже не рассылая ее worker-ам.

S>Это заблуждение.

Конечно

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


Именно. Разные потоки видят одно и то же дерево.

S>В противном случае каждому worker придется перед началом каждой транзакции выполнять копирование ссылки на корень, что опять же дорого. Это эквивалентно постоянной рассылке сообщения "корень дерева теперь здесь".


Т.е. ты утверждаешь, что один atomic_read будет эквивалентен мультикастовой рассылке сообщения? С выбором получателей, блокировкой очередей, вставкой в N очередей экземпляра сообщения, разблокированием очередей, блокированием очередей на стороне приемника, сканирования очереди на предмет выбора подходящего сообщения (если используется отличная от FIFO политика обработки сообщений получателем). Правильно я тебя понимаю?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.12.08 12:49
Оценка: +1
Здравствуйте, DK3981, Вы писали:

DK>>>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.


E>>Этот протокол нужен в любом случае.


DK>Если модифицирующий поток один, то ему не с кем будет конкурировать.


Я о другом: если есть несколько потоков-модификаторов, то им потребуется взаимный протокол захвата разделяемых данных для их модификации в любом из случаев -- будет ли доступ к общей таблице осуществляться через разделяемые переменные или через уведомления.

Если же поток-модификатор один, то не важно, как потоки-читатели будут видеть изменения -- через разделяемую переменную или через уведомления. Но тогда и протокол не нужен, тут вы правы.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[39]: пример eao197: "сообщения" рвут "разделяемую память"
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 03.12.08 13:26
Оценка: -1
Здравствуйте, 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>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[40]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 03.12.08 13:34
Оценка: +1
Здравствуйте, 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: "сообщения" рвут "разделяемую память"
От: thesz Россия http://thesz.livejournal.com
Дата: 03.12.08 21:59
Оценка: :)
S>>Хорошо, worker получил пакет, в котором 100 транзакций, каждая из которых читает дерево. Выполнил — полез в очередь — получил новое дерево — поехал дальше.
S>>Никаких проблем.
E>Ну да, никаких. Чтение очереди ведь явно более дешевая операция, чем atomic_read.

Поддержи очередь аппаратно.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 03.12.08 22:50
Оценка: -1
Здравствуйте, eao197, Вы писали:

E>>>Если каждый worker будет получать уведомление о смене таблицы маршрутизации, то это означает, что он периодически будет проверять свою очередь сообщений.

S>>Не то чтобы периодически. Он ее вообще проверяет непрерывно: собственно оттуда он и берет задания для работы.
S>>Просто на 100 заданий, которые требуют чтения таблицы, приходится одно "вот тебе новая таблица".

E>Это автоматически обязывает worker-а работать с очередями сообщений. Тогда как это может быть совершенно избыточно, если worker обрабатывает большие пакеты данных с множеством сообщений внутри.


1. Никаких проблем обрабатывать большие пакеты данных со множеством сообщений внутри, в рамках модели "гармонично взаимодействующих процессов", нет. Просто посылаешь большой пакет. Который вовсе не обязан копироваться, и будет передан по ссылке — никто его модифицировать не будет.
2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.

Ты вообще живой раутер в глаза видел, или как? Давай, поучи эрлангистов делать раутеры.

Да здравствует всемирная пионерская организация! .
Re[37]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 03.12.08 22:53
Оценка: +1
Здравствуйте, DK3981, Вы писали:

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


S>>Модель с рассылкой позволяет worker выполнять все чтения дерева без блокировок, при этом транзакционная целостность гарантирована архитектурой.


DK>Я здесь вижу только одну проблему: если у нас есть 2 потока, модифицирующих дерево, и оба они "одновременно" получат сообщение, приводящее к необходимости это дерево модифицировать. Тогда каждый из них построит своё новое дерево, и после этого разошлёт новый корень, но в результате данные, изменённые одним из потоков будут потеряны.


DK>Так что для модифицирующих потоков потребуется дополнительный протокол, гарантирующий остуствие коллизий при изменениях.


Модифицирующий поток должен быть один. Что в данной задаче, очевидно, не является никакой проблемой. Если какой другой поток вдруг с какого-то дуба хочет поправить таблицу — он шлет сообщение главному. И все.
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 04.12.08 06:29
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>2. "Больших пакетов" в случае твоей задачи, т. е. раутера, не будет и не может быть. Потому, что он принимает пакеты по сети, которые суть по природе своей небольщие. И ты технически не можешь в раутере их группировать в большие.


Есть такие услуги у ряда контент-провайдеров -- массовые рассылки sms по результатам какого-то события, как-то начисление зарплаты, результаты футбольных матчей, объявление курсов валют, прогнозы погоды и т.д. При их организации решаются задачи быстрой обработки большого числа sms (от нескольких сотен тысяч штук до нескольких миллионов).

Достаточно? Или спросить тебя о твоем опыте разработки телекоммуникационных систем на Erlang-е?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[46]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 05.12.08 10:25
Оценка: -1
Здравствуйте, thesz, Вы писали:

T>Сейчас у тебя это не так, чем ты и пользуешься.


Да ничем он не пользуется, он вообще слабо себе представляет, что говорит. Ты-то хоть на глупость не ведись. Очередь почти ничем не по затратам не отличается от обычного вызова synchronized метода. Более того, она на практике гораздо гуманнее, поскольку асинхронна, и не требует "рандеву" приемника и получателя.
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 05.12.08 11:59
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>"Избыточно" это очень интересное слово, учитывая, что один раз написанная очередь сообщений на примитивах CAS будет иметь оверхэд раза в два меньше, чем то, что ты врукопашную будешь каждый раз по месту изображать на семафорах.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[45]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 05.12.08 13:28
Оценка: :)
Здравствуйте, eao197, Вы писали:

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


G>>Вопрос по существу — ты сказал, что реализация очереди будет "избыточнее", чем то неизвестно что, что ты там планируешь в данной задаче вместо нее применять. Докажи.


E>В разговоре с Siclair я несколько раз упоминал использование atomic_read. И он понял о чем я говорю, поскольку идея очень простая.


Sinclair не просто понял, о чем ты говоришь (это дело нехитрое), он, если ты не заметил, еще и объяснил тебе, почему ты неправ со своим atomic_read.

Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?
Re[44]: Можно
От: EvilChild Ниоткуда  
Дата: 06.12.08 11:35
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

EC>>А почему нельзя перед обработкой пакета тупо скопировать ссылку себе на стек?


G>Почему нельзя? Можно. Получишь в точности очередь сообщений, а именно — ее предельный случай с глубиной 1 и полиси вытеснения при переполнении по FIFO — что станет совершенно очевидно даже тем, кто в танке, если завернуть то что получится в класс, и посмотреть на функциональный интерфейс.

Можно и о скаляре думать как об одномерном массиве с одним элементом, вопрос в том когда такой взгляд на вещи полезен.
G>Потом можно пойти еще дальше, упереться, и под разными предлогами не называть это очередью сообщений.
Я ниразу не против называть это очередью.
Я спрашивал не в разрезе вашего увлекательного спора message passing vs shared memory,
а исключительно в контексте конкретного решения с иммутабельным деревом.
G>Видишь ли, asynchronous message passing — это не более чем дизайн-идиома, которая в конечном счете на современных архитектурах все равно превратится в те примитивы, через которые реализуются семафоры все остальное. Так же, как программа на функциональном языке в конечном счете превратится в ассемблерные инструкции.
Мне кажется важным различать то, в каких терминах мы можем думать о решении и то, как оно реализуется.

G>Если использовать это как аргумент, все закончится Теоремой Существования Дворкина (http://rsdn.ru/forum/message/3194838.1.aspx
Автор: Sinclair
Дата: 01.12.08
), на которую любят опираться люди, которым с пеной у рта нечего сказать. Ну так что на таких время тратить — только портить.

Что вы так Дворкина любите пинать? Я с ним во многих случаях тоже не согласен, это же не повот его пинать по любому поводу.
now playing: Ralph Sliwinski — Freak & Muscle
Re[47]: Offtop
От: Gaperton http://gaperton.livejournal.com
Дата: 07.12.08 12:09
Оценка: +1
Здравствуйте, kdw, Вы писали:

kdw>Достал ты уже со своим ерлангом,


Так не читай мои посты. Кто-то заставляет?

kdw>Как абстракции на нем писать предлагаешь , можно конешно через жопу (и на асемблере можно), Но в данном

kdw>случае например предпочитаю нормальные обьектно ориентированные языки.

С чего ты взял, что я тебе что-то предлагаю.

kdw>Я смотрел на синтаксис ерланга и чесно говоря он него тошнит , хотя в некоторых случаях думаю имеет смысл

заюзать.

Меня совершенно не трогают твои предпочтения, предположения, душевные терзания, и от чего именно тебя тошнит.
Re[47]: А можно еще лучше
От: C0s Россия  
Дата: 08.12.08 00:29
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Более интересный пример, демонстрирующий силу фьючерсов. Допустим, мы хотим рассчитать массив из десяти значений. Каждое — параллельно. Мы просто заполняем этот массив в цикле фьючерсами, каждый из которых — RPC-вызов к какому-то потоку (или старт отдельного потока, выполняющего рассчет, возможно — асинхронный старт, по мере доступности потоков в пуле). И все. Потом — просто пользуемся массивом, не выставляя никакой явной синхронизации, и не принимая сообщений. Допустим, так же пробегаемся по нему в цикле, считая сумму.


что характерно, все эти, действительно полезные вещи, скажем, в java доступны на уровне стандартной библиотеки, начиная с версии 5. т.е. я хочу сказать, что это не какое-то вчерашнее открытие, раз есть давно и в таком популярном языке

что касается их применения, то мне доводилось использовать Future в реализациях протоколов уровня приложения с возможностью ожидания подтверждения от контрагента для более, чем одного посланного пакета (windowing > 1)
Re[48]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 08.12.08 09:21
Оценка: :)
Здравствуйте, Gaperton, Вы писали:

E>>Может быть тогда ты сможешь сказать, у какой именно очереди сообщений накладные расходы на проверку наличия нового элемента будут меньше одного atomic_read?


G>Может быть, я тебе это уже сказал во второй части своего сообщения, которую ты предусмотрительно вырезал? Может быть, Синклер тебе все то же самое объяснил?


Не может быть.

G>>Мне очень жаль, но это совершенно очевидно будет работать медленнее, чем мое решение на очередях сообщений. Потому, что у меня будет просто обычный read на каждый lookup. Я думал, еще раз тебе этого объяснять не стоит, и ты придумал что-то новенькое?


Одного обычного read будет недостаточно, о чем уже было сказано.

G>Ты что, не знаешь, что atomic_read заметно медленнее обычного read? Может быть, ты наконец перестанешь прикидываться валенком? Обкакался, так будь мужиком, блин, и имей смелость это признать. Тем более — это всего лишь форум, и всего знать невозможно. Я был о тебе лучшего мнения, короче.


Этот красочный оборот речи был предназначен для сокрытия факта того, что нити-читатели должны проверять свою очередь сообщений перед каждой новой транзакцией, и что эта проверка не может быть дешевле одного atomic_read-а.


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[41]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 13.12.08 21:45
Оценка: :)
Здравствуйте, 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
Дата: 13.12.08
), не представляешь стоимость примитивных операций и источники оверхеда как в модели обмена сообщениями, так и в модели разделяемой памяти (http://www.rsdn.ru/forum/message/3201553.1.aspx
Автор: Gaperton
Дата: 05.12.08
).



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[42]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 14.12.08 21:20
Оценка: -1
Здравствуйте, remark, Вы писали:

R>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.


Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.

Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.

R> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал...

R>Твои же технические знания и опыт пока под большим сомнением.

Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.

Видишь-ли, меня интересует мнение о моей персоне тех людей, кого я уважаю.

R>Очевидно, не представляешь что такое атомарное чтение (http://www.rsdn.ru/forum/message/3213225.1.aspx
Автор: remark
Дата: 13.12.08
), не представляешь стоимость примитивных операций и источники оверхеда как в модели обмена сообщениями, так и в модели разделяемой памяти (http://www.rsdn.ru/forum/message/3201553.1.aspx
Автор: Gaperton
Дата: 05.12.08
).


Дык после этого
http://rsdn.ru/forum/message/3213225.1.aspx
Автор: remark
Дата: 13.12.08

я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".

"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.

ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.
Re[43]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 15.12.08 01:38
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

R>>Твои попытки замаскировать свою техническую неграмотность личными оскорблениями eao197 просто смешны. И я лично, и много людей на этом форуме знают, что это — действительно умный человек.


G>Вопрос вашего Действительного Ума или Идиотизма меня совершенно не волнует. То есть, мне все равно, гении вы, идиоты, или что-то посередине, не задаюсь я этим вопросом в принципе по поводу его совершенной малозначительности и праздности. Думаю, этот вопрос вообще мало кого волнует, кроме вас. Называйте друг друга Действительно Умными, если вам так нравится — я не против. Я возражаю на конкретные посты, в конкретной дискуссии, и ваши личности мне по барабану.


G>Одно могу сказать — в отличии от тебя и Действительно Умного Человека, я не чувствую необходимости привлекать в дискуссии в качестве аргументов матюги (чем давеча отметился ты), переходы на личности (чем ты сейчас занят), и вранье (на котором здесь ловили вас обоих — но в этом больше Действительно Умный Человек" отметился). Мне проще привести факты с логикой.



Хммм... неплохой приём — вот так в последний момент переменить своё точку зрения, и накатать такое "высокое" оправдание, что бы типа очистить свою совесть. Неплохо!

Личности тебе значит по-барабану? И тебя волнует только конкретная дискуссия? Если немного пройтись по твоим сообщениям в этом топике:

Говоришь про собеседника, хватит ли у него ума поискать в интернете:
http://www.rsdn.ru/forum/message/3193174.1.aspx
Автор: Gaperton
Дата: 28.11.08


Называешь высказывания собеседника "фантазиями":
http://www.rsdn.ru/forum/message/3192241.1.aspx
Автор: Gaperton
Дата: 28.11.08


Говоришь собеседнику, что ему придётся реализовывать что-то через "задний проход"; абсолютно необоснованно говоришь, что собеседник не владеет "дизайн-идиомой актёров"; говоришь, что собеседник не додумается до таких решений как ты:
http://www.rsdn.ru/forum/message/3213290.aspx
Автор: remark
Дата: 14.12.08


Постоянно тыкаешь собеседнику: "Читайте книги, это прикольно.".
http://www.rsdn.ru/forum/message/3193953.1.aspx
Автор: Gaperton
Дата: 30.11.08


Обращаешся к собеседнику: "навоображали себе идиотизма, приписали его участникам, и давай шашкой махать"
http://www.rsdn.ru/forum/message/3196033.1.aspx
Автор: Gaperton
Дата: 01.12.08


сказал собеседнику: "ты, что, правда, всерьез думаешь, что ты в состоянии реалистично представить себе оптимальное решение на "актерах", не написав ни одной программы":
http://www.rsdn.ru/forum/message/3197730.1.aspx
Автор: Gaperton
Дата: 03.12.08


сказал собеседнику, что он обкакался, что он прикидывается валенком, что он не мужик и не имеет смелости:
http://www.rsdn.ru/forum/message/3201890.1.aspx
Автор: Gaperton
Дата: 05.12.08



Будь добр, поясни как это всё согласуется с твоей позицией, что тебя интересует только дискуссия, а на личность собеседника ты типа не обращаешь внимания? По-моему, практически каждый твой пост пропитан неуважением к собеседнику, личными оскорблениями и чувством собственного превосходства. При этом, кстати, техническая сторона страдает. Говоришь людям приводить аргументы и ссылки, сам же никаких ссылок не приводишь, и отвечаешь "Сам поищи. Лень".

Где, кстати, на вранье меня поймали?

Самое забавное, что ты так и не понял моё первоначальное высказывание. Как при этом вообще спорил и шашкой махал — совершенно не понятно...


R>> Евгений разработал... Я, хочешь ты этого или нет, тоже разработал...

R>>Твои же технические знания и опыт пока под большим сомнением.

G>Тебе не приходило в голову, что на фоне той белиберды, которая присутствует в некоторых постах Действительно Умных Людей, мне может быть совершенно пофигу, что Действительно Умные Человеки разработали, и что они думают про мои технические знания и опыт? Нет? Ну так вот — твои сомнения в моей технической экспертизе я как-нибудь переживу.


G>Видишь-ли, меня интересует мнение о моей персоне тех людей, кого я уважаю.



Это я заметил, что тебя интересуют только те, кого ты уважаешь. А на тех кого, ты не уважаешь тебе плевать. При этом, где истина и объективность тебя совершенно не волнует.


R>>Очевидно, не представляешь что такое атомарное чтение (http://www.rsdn.ru/forum/message/3213225.1.aspx
Автор: remark
Дата: 13.12.08
), не представляешь стоимость примитивных операций и источники оверхеда как в модели обмена сообщениями, так и в модели разделяемой памяти (http://www.rsdn.ru/forum/message/3201553.1.aspx
Автор: Gaperton
Дата: 05.12.08
).


G>Дык после этого

G>http://rsdn.ru/forum/message/3213225.1.aspx
Автор: remark
Дата: 13.12.08

G>я и не претендую. Где мне с Действительно Умными Людьми сравняться, тонко представляющими себе стоимость примитивных операций . Вот, например, оказывается, что самая "обычная инструкция загрузки из памяти ld (та самая, которая десятками встречается в любой функции)", в соответствии с авторитетнейшим исследованиям remark, "занимает доли такта".

G>"Доля такта" — ну кто мог бы подумать. Надо же, ld выполняется быстрее, команда "регистр-регистр" . Жжешь, адский сатана.



Это я тоже заметил, что ты на ум не претендуешь. Нет, определенный звон (МЕМОРИ БАРЬЕР, lwsync и т.д) ты видимо слышал. Но вот где он совершенно не представляешь.
Смотри ответ:
http://www.rsdn.ru/Forum/message/3214044.aspx
Автор: Gaperton
Дата: 15.12.08


Но при этом шанса по-оскорблять собеседника ты не упустил: "Абыдно, да?", "На, почитай первоисточник", "И здесь ты неправ".


G>ЗЫ: Знаешь, чем опасен переход на личности, которым ты занялся? Тем, что ты случайно можешь выставить полным идиотом самого себя. Поэтому, а не почему-то другому, не стоит переходить на личности. Однако, я вижу — ты упорный, и тебя с линии не собьешь, ты любишь дела до конца доводить.



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

Да ещё вот эта тема непонятная — дофантазирование технических деталей. Откуда на POWER lwsync в load-consume? Откуда в паттерне публикации на стороне потребителя store-load последовательность? Как барьеры памяти влияют на когерентность? Откуда ты эти факты взял? У меня 2 варианта: (1) либо действительно любишь фантазировать (такое можно понять на уроке литературы, но в техническом форуме ), (2) либо очень хитро врёшь/выставляешь реальные факты лживо в надежде типа "а вдруг прокатит", со стороны неискушенного читатели выглядит типа авторитетно.
Или просто прочитал где-то такие некорректные факты? Будь добр укажи, где такое пишут.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[51]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 15.12.08 04:56
Оценка: -1
Здравствуйте, 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? Или ты опять дурачка включишь? Ты странно себя ведешь, вроде слова правильные знаешь, однако как до дела доходит, то включаешь феерического дурака. Либо ты это бросаешь, либо я прекращаю с тобой говорить. Надоело.
Re[48]: опять начинается
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 15.12.08 06:16
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>Во-вторых, пока ты меняешь структуру, все читатели стоят на блокировке.


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

G>Касательно того, что atomic_read, на котором eao


eao197, eao -- это такое же некорректное сокращение, как и Gaper.

G>собирался решать эту задачу, медленнее обычного — это правда и остается правдой, в данном случае нужен честный барьер в получателе чтобы все работало.


Зачем барьер в получателе?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[52]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 15.12.08 12:55
Оценка: +1
Здравствуйте, Gaperton, Вы писали:


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.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[56]: пример eao197: "сообщения" рвут "разделяемую память"
От: Gaperton http://gaperton.livejournal.com
Дата: 16.12.08 05:37
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

G>После чего, я бы предложил посмотреть, как масштабируется производительность в финальной задаче от количества аппаратных потоков и кристаллов в SMP, и, по всей видимости, довольно убедительно уложил бы их на Нехалеме и Ниагаре. За счет того, что у меня никто никого не блокирует, и все взаимодействие асинхронно.


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

Вот это решение уже побить иммутабельными структурами будет достаточно тяжело, и оно, в принципе, кроссплатформенно.

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

Мультикастная очередь не обязана иметь один слот, кстати. Если построить ее на однонаправленном списке, то это может быть вполне честная очередь. Позволяющая множеству читателей спокойно из нее читать, не пользуясь блокировками, потому что она также транзакционна. Делается она так.

В очереди всегда лежит, пнимаете-ли, как минимум один элемент, даже в пустой. Этот элемент — по сути своей фьючер. Однако, когда песатель кладет в очередь новый элемент, он будет указывать на фьючер. Короче, эта фигня ведет себя точь в точь как ленивый список. Без сборки мусора будет тяжело, это дизайн для Java/.NET.

Вот. Теперь, очередной парадокс. Иммутабельная структура данных, состоящая из таких очередей, также функционально чиста и транзакционна, однако. И позволяет делать довольно необычные вещи, несколько уже выходящие за рамки обычных представлений о дизайне на асинхронных сообщениях. Причина крышесрывания состоит в том, что очередь сообщений здесь рассматривается как first class object, которая сама может быть составным элементом структур данных. Занятно, не так ли? Кстати, это вроде как уже не совсем actors model. Это довольно интересное обобщение.
Re[71]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.12.08 19:52
Оценка: +1
Здравствуйте, 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>>
AVK Blog
Re[54]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 19.12.08 13:34
Оценка: +1
Здравствуйте, 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 с неразрушающим чтением, то тогда ты сможешь догнать решение на разделяемой памяти.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[82]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 19.12.08 21:27
Оценка: -1
Здравствуйте, AndrewVK, Вы писали:

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


R>>Тут уже тема несколько десятков раз сменилась.


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


Ну это если ты с изначальной темой пришёл в разговор на изначальную тему. А если ты с изначальной темой пришёл в уже совсем другой разговор, то понятнее от этого отнюдь не стало.


R>>Какие навороты там не нужны?


AVK>Хитрые модели вроде TPL.


Никто и не говорит, что они там нужны.


R>>А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель.


AVK>Они хорошо ложаться на любую модель. Поэтому чем она проще, тем лучше. Модель AsyncOperation всего с 2 значимыми методами намного проще агентов.


А HPC тогда на OpenMP



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[73]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.08 01:18
Оценка: +1
Здравствуйте, remark, Вы писали:

R>Ну хорошо, если это "презерватив на глобус" и типа теперь под это всё подпадает, то тогда приведи ещё пару моделей, которые получаются из тасков и датафлоу путём переименования понятий один-к-одному


Путем переименования понятий можно сделать что угодно и этой казуистикой заниматься лично у меня нет никакого интереса.

R>Ну а по-существу?


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

R>Чёткий датафлоу граф вырисовывается.


Угу. Получается, любая программа, которая обрабатывает данные в несколько этапов с зависимостью между этапами — это датафлоу. О чем я и говорил. Ну ОК, обозвал ты это все датафлоу, не хочу даже спорить о терминах. Дальше то что? Сколько воду в ступе не меси, все одно вода получится.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[83]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 20.12.08 12:57
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>В MS-совской библиотеке асинхронных агентов из состава VS2010 агент -- это объект. Объект имеет соостояние.


Но это состояние совсем не обязано быть изменяемым.
... << RSDN@Home 1.2.0 alpha 4 rev. 1132 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 16.11.08 10:31
Оценка:
+ в дополнительное чтение
Challenges and Directions in Java Virtual Machines
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 17.11.08 03:27
Оценка:
LV>Что-то мне подсказывает, что есть разница между многопоточным программированием и параллельными вычислениями.
Конечно есть, я как раз о параллельных вычислениях написал.
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 17.11.08 03:30
Оценка:
Aib>Новый сановский сервак на T2 plus выдает 256 параллельных потоков на 64 ядрах — джавка работает просто изумительно. И потом там столько либов для много поточности написали, что любые ваши желания возможны.

Что-то я сомневаюсь что ресурсоемкая java программа с shared memory без модификации будет испльзовать все 64 ядра, если они действительно ей нужны будут.
Нужно использовать внешние библиотеки. В этом и проблема джавы.
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 17.11.08 03:46
Оценка:
Здравствуйте, Aib:
Aib>Машины для erlang пока сыроваты,

Это интересно. До боли мне кажется что вы второй раз ошибаетесь.
С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты?
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 17.11.08 09:07
Оценка:
Здравствуйте, yumi, Вы писали:

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


DSG>>Все мы знаем что в "параллельном мире" существуют 2 основные концепции:

DSG>>- Shared memory
DSG>>- Message Passing Interface (MPI)

Y>Есть еще STM (Software transactional memory) и использование полностью immutable data types.


http://en.wikipedia.org/wiki/Software_transactional_memory

for controlling access to shared memory in concurrent computing


т.е. это разновидность Shared Memory.
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 17.11.08 09:15
Оценка:
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 используя сторонние библиотеки.
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 17.11.08 11:16
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>http://en.wikipedia.org/wiki/Software_transactional_memory


DSG>

DSG>for controlling access to shared memory in concurrent computing


DSG>т.е. это разновидность Shared Memory.


Ну простой shared memory с локами и прочими и STM все же немного разные я думаю. Я думал ты имеешь ввиду первое.
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 18.11.08 02:03
Оценка:
А>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.

Прикол в том что в Erlang не нужно писать код для распаралеливания.
Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.
Все что нужно сделать — придерживатся маленьких рекоммендаций.
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 18.11.08 02:40
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>+ в дополнительное чтение

DSG>Challenges and Directions in Java Virtual Machines

еще

Higher-Order Java Parallelism, Part 1: Parallel Strategies and the Callable Monad
Multi-core state of play

А вот здесь про X10
Multi-Core and Massively Parallel Processors
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 18.11.08 09:57
Оценка:
Здравствуйте, yumi, Вы писали:

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


N>>Опять же мне не понятно что значит shared memory. Опять же повторюсь что потоки в жава оперируют своими кусками памяти и время от времени синхронизируются между собой. А уж как этот процесс себе в мозгу представлять, либо мессагами либо просто синхронизацией, от этого команды процессора не поменяются.


Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.


Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются. Но в данном контексте, yumi прав, т.к. то что имеет ввиду Nicht не является решением проблемы.
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: Nicht Россия  
Дата: 18.11.08 10:54
Оценка:
Здравствуйте, yumi, Вы писали:

Y>Эммм... либо Вы какой-то другой жавой пользуетесь или я чего-то упустил в своей жизни. Но насколько я знаю, потоки в жава разделяют память в контексте процесса. У каждого процесса, да своя память, а у потоков живущих в ней, она одна. Так вот, вся проблема в том, что когда несколько потоков начинают использовать одну и ту же область памяти, начинаются жуткие проблемы в виде дедлоков, гонок и прочих проблем. В эрланге как поступили, да очень просто, сделали так, чтобы у каждого потока была своя область памяти к которой имеет доступ только этот поток. Соответсвенно все проблемы связанные с дедлоками и гонками отпадают как класс.


Наверное это для тебя новость но у потоков в джава есть свой личный кусок памяти. И он рабобтает в основном в нем. Ты никогда не задумывался зачем нужны volatile переменный и Atomic классы. Как раз для того что бы потоки обменивались изменениями в своих локальных пространствах памяти.

Еще раз спрашиваю, как на счет атомарности изменений и синхронизации данных. Пока апологеты erlang говорили только о том, что потоки обмениваются сообщениями. Это самая простая многопоточная программа. Как на счет того что несколько сообщения должны быть переданы атомарно и изменения должны быть видны во всех потоках? Если там так все без дедлоков, в чем я лично сомневаюсь, как на счет лайвлоков.

И тут говорили что в erlang ненадо писать код синхронизации. Тоесть надо предпологать что он рассылает эти ваши мессаги на каждый чих? Даже моего скромного ума хватит что бы понять, что такой подход сомнителен.

Y>Боюсь Вы совсем не понимаете, что такое Эрланг.


А что же это такое? Вернее чем же он отличается от всего остального? Язык — это модель. В независимотси от того какой язык ты используешь, процессор, чипсет и пямать работь по другому не будут.

N>>Да, в джава нужно это писать такой код. Но многопоточное программирование — это сфера где люди не выдерживают, куда уж там машинам

N>>И библиотеки кстати совсем даже не сторонние, а наоборот совсем даже стандартные.

Y>Без поддержки виртуальной машины, это в принципе невозможно.


Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 18.11.08 13:29
Оценка:
Здравствуйте, 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
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: Nicht Россия  
Дата: 18.11.08 13:47
Оценка:
Здравствуйте, yumi, Вы писали:


Y>Все разжуй да в клюв положи, не надо устраивать тут флей, пойди почитай о том, что такое erlang или тебя бедного гугл забанил?


Да ты не обижайся. Я же не говорю что erlang плохой. Мне просто кажется что шапашного знакомства недостаточно для того что бы об этом рассуждать. И я высказывал лично сове мнение. Как в общем то и просил создатель темы.

Но, можно сказать что вы меня заинтересовали. Как раз хотел поразбираться с функциональными языками. Вот и почитаю.
Вот кстати на злобу дня Интервью с Армстронгом.

Y>>>Без поддержки виртуальной машины, это в принципе невозможно.


N>>Блин, что значит поддержка джава машины? Джава машина реализцет модель памяти, описанный в JSR 133, ну и там еще jit компилятор, GC и другой обвес. Все остальное это библиотеки. Потоки в жава реализованы через JNI колы к нативным потоковым библиотекам платформы (в линуксе это NPTL). Всякие Atomic переменные тоже реализованы через JNI вызовы. При чем тут виртуальная машина?


Y>Erlang avalanche
Автор: Lazy Cjow Rhrr
Дата: 12.12.06


Тут много букав. Без подготовки не осилить. Большой загиб в системы реального времени. И мне кажется что именно это там основная тема.
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 18.11.08 16:50
Оценка:
опять двадцать пять

Y>>>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.


A9R>>см. 4.2 там же и про race condition (поиском)


Y>У меня щас тупо нету смотрелки pdf,


не катит. любой текстовый вьювер (да хоть less) проблему решит. Открываешь и ищешь 4.2. Поиском внутри файла учить пользоваться ?

Y>связано ли это с shared memory? Ну конечно нет, т.к. в Эрланге нет shared memory Это как уж если приводить аналогии, то типа в средах с управляемой кучей не может быть утечек памяти, но все равно можно держать ссылки на коллекцию уже не нужных объектов


не про shared memory речь.

ты говорил про то, что "в Эрланге ты по лбу всмысле дедлоков и гонок не получишь <b>вообще</b> никак."
Автор: yumi
Дата: 18.11.08
И это типа решает.

может оговорился?
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 18.11.08 20:12
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Достатки MPI, к примеру, — не нужно писать код синхронизации, нету дедлоков.


Если используется явное (блокирующие вызовы) или не явное ожидание ответов на сообщения — то дедлок — как два пальца.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 18.11.08 20:26
Оценка:
Здравствуйте, yumi, Вы писали:

А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.


Y>Зависит, в Эрланге ты по лбу всмысле дедлоков и гонок не получишь вообще никак.


Пара рецептов как можно этого "вообще никак" всё-таки добиться:
http://gzip.rsdn.ru/forum/message/3179801.1.aspx
Автор: remark
Дата: 18.11.08



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 18.11.08 20:30
Оценка:
Здравствуйте, DenysSG, Вы писали:

А>>Так что каждый разработчик выбирает себе грабли сам: не умеешь пользоваться общей памятью, но лезешь — получи по лбу; не умеешь пользоваться MPI, но лезешь — получи по лбу. От Java/Erlang/... тут ничего не зависит.


DSG>Прикол в том что в Erlang не нужно писать код для распаралеливания.

DSG>Все работает out of box: одно ядро у вас или 100 физических машин на которые нужно разбрасывать задачи.

out of box получится что? Загрузить на 100% все 100 ядер/машин? Или добиться 100 кратного ускорения работы?

DSG>Все что нужно сделать — придерживатся маленьких рекоммендаций.


А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 02:05
Оценка:
Здравствуйте, Nicht:

Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели.
Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.

Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.
Re[2]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 03:17
Оценка:
Здравствуйте, remark, Вы писали:
почитайте
http://www.rsdn.ru/Forum/?mid=2414192
Автор: Didro
Дата: 22.03.07
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.11.08 04:20
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.

А где можно прочитать про этот адский отжиг?
Впервые слышу про NUMA в Java.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 04:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.

S>А где можно прочитать про этот адский отжиг?

Скорее всего имеется ввиду thread local heap, искать ключевые слова тут: http://java.sun.com/docs/hotspot/threads/threads.html

Но это только для выделения памяти. Возможно, на синхронизацию тоже как-то влияет.

S>Впервые слышу про NUMA в Java.


http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: Курилка Россия http://kirya.narod.ru/
Дата: 19.11.08 06:25
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

DSG>>Это интересно. До боли мне кажется что вы второй раз ошибаетесь.
DSG>>С чего вы взяли что "машины" для Erlang, которому уже 20 лет, сыроваты?
S>Наверное с того, что вплоть до самого недавнего времени Erlang в принципе не умел работать на нескольких ядрах.
S>В этом смысле вопрос его эффективности на честной многоядерной архитектуре остаётся, имхо, открытым.

Воообще Эрланг исходно можно было запустить на многоядерной машине, стартовав по ВМ на ядро.
При отстутствии явных грабель в коде (без закладок на то, что вся работа идёт внутри одной ноды), разница в коде минимальна (фактически минимальные связи между ВМ через конфигурирование).
Но теперь и SMP в Эрланге уже довольно неплохо работает (цифр под рукой нет), правда в следующих релизах ещё хотят улучшить.
Правда вполне может получиться что запуск нескольких ВМ даст большую производительность (SMP-версия всё же содержит некоторую часть разделяемых данных, а это боттлнек)
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 08:28
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


DSG>>Ну там система типа есть Shared memory и есть у каждого потока своя локальная рабочая память, в которую он загружает данные для обработки, а потом опять отправляет их в shared memory, где они и синхронизируются.

S>А где можно прочитать про этот адский отжиг?
S>Впервые слышу про NUMA в Java.

Сейчас нету времени искать, но должно быть здесь
Threads and Locks
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:29
Оценка:
Здравствуйте, Sinclair, Вы писали:

WF>>http://blogs.sun.com/jonthecollector/entry/help_for_the_numa_weary

S>Бугога. И какое отношение это имеет к заявлениям DenysSG?

Тогда зачем было спрашивать про NUMA в Java, если то-что-описал-DenysSG — это не NUMA?
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:30
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Сейчас нету времени искать, но должно быть здесь

DSG>Threads and Locks

Что-то мне подсказывает, что это всего лишь модель.
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 08:35
Оценка:
Здравствуйте, WFrag, Вы писали:

DSG>>Сейчас нету времени искать, но должно быть здесь

DSG>>Threads and Locks

WF>Что-то мне подсказывает, что это всего лишь модель.


Да, и причем это модель памяти предыдущей версии Java (JLS 2): http://java.sun.com/docs/books/jls/second_edition/html/memory.doc.html

В третьей редакции упоминания о разделяемой и локальной памяти нет.
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 09:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Естественно, там ничего относящегося к твоим фантазиям нету.

S>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
S>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
S>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.

Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.
Re[10]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 09:17
Оценка:
Здравствуйте, WFrag, Вы писали:

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


S>>Естественно, там ничего относящегося к твоим фантазиям нету.

S>>Разве что ты имел в виду под "локальной рабочей памятью" стек потока. Ну так нигде не сказано, что поток работает в основном с стеком.
S>>Кроме того, нигде там не сказано ничего про "отправку обратно в shared, где они и синхронизуются".
S>>В общем, стоит поучить матчасть, прежде чем делать такие прикольные заявления.

WF>Смотрим JLS 2, глава 17.1. Но это модель. Причём старая. Думаю, именно это имелось ввиду.


Вообщем, я нашел то что имел ввиду
http://www.intuit.ru/department/pl/javapl/12/3.html

Читайем раздел Хранение переменных в памяти.

Думаю, официальный материал должен быть в
http://java.sun.com/docs/books/jvms/
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: WFrag США  
Дата: 19.11.08 09:31
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Вообщем, я нашел то что имел ввиду

DSG>http://www.intuit.ru/department/pl/javapl/12/3.html

DSG>Читайем раздел Хранение переменных в памяти.


DSG>Думаю, официальный материал должен быть в

DSG>http://java.sun.com/docs/books/jvms/

Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.
Re[12]: Java Parallel computing: multicore, Erlang, Scala
От: DenysSG  
Дата: 19.11.08 09:39
Оценка:
Здравствуйте, WFrag, Вы писали:

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


WF>Там только для Java 1 и 2. Для современной Java нету. Более того, поскольку это всего лишь модель, реально JVM могла быть реализована сколь угодным способом. Думаю, что в 1.4 JDK локальной памятью были просто-наспросто регистры потока.


Да, так и есть. Вообщем, я то про это тут топик и не заводил.
Это Nicht`у будет полезно почитать про то что он имел ввиду.
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 19.11.08 09:59
Оценка:
Здравствуйте, remark, Вы писали:

R>Дедлок при обмене сообщениями — как 2 пальца. Один поток ждёт ответа от второго, второй — от первого. Естественно схемы дедлоков в реальных приложениях могут быть и сложнее — затрагивать больше потоков.


А это... ну... а можно примерчик, работающий на erlang-е. Демонстрирующий дедлок, который честно распадается по таймеру. (! и receive ... after видимо)
А то меня это дискуссия подвигла залезть на erlang.org, но скиллзов на что-то кроме пинг-понга пока не хватает
Я даже слово волшебное знаю, пожалуйста
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.08 11:43
Оценка:
Здравствуйте, cadet354, Вы писали:

C>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?


В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.11.08 11:55
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG> А в Java создание потока — ресурсоемкая операция.


Зеленые потоки в Джаве доступны уже давно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 19.11.08 12:17
Оценка:
Здравствуйте, AndrewVK, Вы писали:
AVK>Зеленые потоки в Джаве доступны уже давно.
В любом случае использование пула потоков однозначно решает проблемы стоимости создания. А уже зеленые потоки в пуле или красные — дело второе.
От этого, по идее, зависят только накладные расходы на переключение с потока на поток.
Если у нас выполняется могучий поток мелких задачек, то расходы на переключение можно свести к минимуму путем банального ограничения размера пула. В предельном случае на N-ядерной машине в пуле ровно N потоков, которые никогда не вытесняются, а постоянно вытаскивают задания из очереди и никогда не засыпают (кроме случаев отсутствия входящих задач).
Зеленые потоки помогают только в том случае, когда мы реально выполняем в потоке длинную операцию с периодическими засыпаниями в синхронном ожидании события.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 12:21
Оценка:
Здравствуйте, AndrewVK, Вы писали:


AVK>В .NET это называется task parallelism. Смотреть соответственно ParallelFX и TPL в частности.

и как там таски обмениваются между собой сообщениями ?!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:23
Оценка:
Здравствуйте, 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 тактов, то накладненько получается её делать асинхронной и привлекать передачу сообщений.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:29
Оценка:
Здравствуйте, DenysSG, Вы писали:

DSG>Можно все, но язык Java,- именно язык -, не позволяет распараллеливать код на процессоры из-за используемой модели.

DSG>Для этого нужно использовать сторониие библиотеки, которые я перечислил. т.е. на 32 процессоров ваша старая java программа не будет работать в 32 раза быстрее.

Вполне можно представить и ситуацию, когда "старая" многопоточная Java программу будет работать быстрее, ну не в 32, но допустим в 20 раз. И в тоже время "старая" Erlang программа будет работать медленнее. Автоматического линейного увеличения производительности никто не даёт.

DSG>Добавлю ещё что в Erlang создание процесса дешевле чем вызов функции. А в Java создание потока — ресурсоемкая операция.


Отсюда следует только один (уже хорошо известный) вывод — просто не надо часто создавать потоки. Точка. Проблема решена.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: Gajdalager Украина  
Дата: 19.11.08 12:56
Оценка:
Здравствуйте, 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>Какие тут проблемы?

То, что здесь есть побочные эффекты, проблемой не является?
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 12:58
Оценка:
Здравствуйте, 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% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 13:02
Оценка:
Здравствуйте, cadet354, Вы писали:

R>>А можно чуть-чуть поподробнее про "маленькие рекомендации"? Потому как я слышал, что проблема эффективной утилизации параллельного железа для всех классов задач всё ещё не решена (каким бы языком/библиотеками мы не пользовались, тем более что агентное программирование (модель Erlanga) переложено на все распространённые промышленные языки (C/C++, .NET, Java)).


C>а где прочитать про actor model(я так понял это скрывается под агентное программирование) на .net ?



Вот, что удалось нарулить:
http://code.google.com/p/retlang/
http://weblogs.asp.net/podwysocki/archive/2008/06/18/concurrency-in-net-learning-from-erlang.aspx
http://209.85.173.132/search?q=cache:ecuvy8jU4B0J:se.inf.ethz.ch/people/nienaltowski/papers/scoop_easy_draft.pdf+actor+message+asynchronous+%22.net%22+C%23&amp;hl=en&amp;ct=clnk&amp;cd=71&amp;gl=us&amp;client=firefox-a

Ещё вот тут:
http://209.85.173.132/search?q=cache:6IwcVJKBfzgJ:lucacardelli.name/Papers/Polyphony%2520(TOPLAS).pdf+%22Concurrency+Abstractions+in+C%23%22&amp;hl=en&amp;ct=clnk&amp;cd=1&amp;gl=us&amp;client=firefox-a
упоминаются некие ActiveObjects, которые по сути агенты.

Так же можно поглядеть на
Concurrency and Coordination Runtime (CCR) — это уже от MS

И на Polyphonic C и Join (это тоже от MS)
http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.html

Чо-то ещё я такое видел серьёзное, там даже препроцессор был, но сейчас не могу вспомнить название. Мне кажется, если погуглить или посоурсфорджить, то можно значительно больше найти.



1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[3]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 13:15
Оценка:
Здравствуйте, DenysSG, Вы писали:

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

DSG>почитайте
DSG>http://www.rsdn.ru/Forum/?mid=2414192
Автор: Didro
Дата: 22.03.07



Это же с Thinking Parallel, правильно? Я на него подписан и читал там всё по мере публикации.
Ну и что мы там видим?
Удаётся получить 4-ёх кратное увеличение производительности на 4-ёх ядерном процессоре. Заметь как он аккуратен в формулировках. Полная версия — Удаётся получить 4-ёх кратное увеличение производительности на 4-ёх ядерном процессоре для некоторых программ, которые мы специально сделали для этого теста. Ну это уже хорошо, что они устранили очевидные боттлнеки внутри самого ран-тайма. Но это никак не говорит о легкости/возможности достижения этого результат для всех реальных программ.
Далее ещё интереснее. На 32-ядерной машине получили только 18-кратное ускорение. Почему не 32 кратное? Потому что масштабируемость не линейная, т.е. на 48-ядрах у нас будет 20-кратное, а на 64 — 10 кратное. И это опять же на программе, которую они специально для этого выбрали.




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 19.11.08 13:22
Оценка:
Здравствуйте, 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]).
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 13:32
Оценка:
Здравствуйте, remark, Вы писали:

R>Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.

там же очередь сообщений, сначала Г ждем сообщения от Б, а потом уж от B и ничего выдумывать не надо, разве не так?
что то вроде этого:
receive
    {from, Б, Value} ->
        receive
            {from, B, Value2}->{ok, MakeSmth(Value, Value2)}
        end,    
end.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[6]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 13:38
Оценка:
Здравствуйте, remark, Вы писали:

R>Вот, что удалось нарулить:

R>http://code.google.com/p/retlang/
пробывал, реально не удобно, не то.
R>http://weblogs.asp.net/podwysocki/archive/2008/06/18/concurrency-in-net-learning-from-erlang.aspx
R>http://209.85.173.132/search?q=cache:ecuvy8jU4B0J:se.inf.ethz.ch/people/nienaltowski/papers/scoop_easy_draft.pdf+actor+message+asynchronous+%22.net%22+C%23&amp;hl=en&amp;ct=clnk&amp;cd=71&amp;gl=us&amp;client=firefox-a

R>Ещё вот тут:

R>http://209.85.173.132/search?q=cache:6IwcVJKBfzgJ:lucacardelli.name/Papers/Polyphony%2520(TOPLAS).pdf+%22Concurrency+Abstractions+in+C%23%22&amp;hl=en&amp;ct=clnk&amp;cd=1&amp;gl=us&amp;client=firefox-a
R>упоминаются некие ActiveObjects, которые по сути агенты.

R>Так же можно поглядеть на

R>Concurrency and Coordination Runtime (CCR) — это уже от MS
это из другой оперы, там поток ждет выполнения другого, или выполняются в определенном порядке и т.д.
R>И на Polyphonic C и Join (это тоже от MS)
R>http://channel.sourceforge.net/boost_join/libs/join/doc/boost_join_design.html

R>Чо-то ещё я такое видел серьёзное, там даже препроцессор был, но сейчас не могу вспомнить название. Мне кажется, если погуглить или посоурсфорджить, то можно значительно больше найти.

там много чего найти можно, но в реальности хрен применишь ,
посмотрю по другим ссылкам,что ты выложил, реально что-то из этого пробывал?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 13:45
Оценка:
Здравствуйте, 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

Я думаю, что там должны быть примеры. Ну и соотв. видимо проблема не надуманная, раз пишут статьи и делают тулзы.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[7]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 13:56
Оценка:
Здравствуйте, cadet354, Вы писали:

C>там много чего найти можно, но в реальности хрен применишь ,

C>посмотрю по другим ссылкам,что ты выложил, реально что-то из этого пробывал?

Я на .NET мало программирую, поэтому ничего не пробовал. Возможно кто-то из .NET программистов что-то подскажет. Можно спросить в .NET разделе.

А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 13:58
Оценка:
Здравствуйте, cadet354, Вы писали:

R>>Агент А посылает сообщения агентам Б и В. Агент Б в ответ на сообщение практически сразу отсылает сообщение агенту Г. Агент В делает что-то длительное (считает, читает файл), потом отправляет сообщение агенту Г. В 99.99% случаев, агент Г получает вначале сообщение от Б, потом от В. Однако это не гарантируется. Если на это положиться, то вот, пожалуйста гонка сообщений.


C>там же очередь сообщений, сначала Г ждем сообщения от Б, а потом уж от B и ничего выдумывать не надо, разве не так?


В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 14:06
Оценка:
Здравствуйте, 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>То, что здесь есть побочные эффекты, проблемой не является?


О, действительно.
Но так даже лучше. Потому что наличие таких специфических побочных эффектов действительно НЕ мешает для распараллеливания (это плюс, т.к. больше свободы и не надо создавать дополнительный объект под результат). Но в то же время можно и чисто без побочных эффектов (надеюсь в этот раз получится):
int func(int a, int b)
{
  return a + b;
}




1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 19.11.08 14:07
Оценка:
Здравствуйте, remark, Вы писали:


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>Ну и соотв. видимо проблема не надуманная, раз пишут статьи и делают тулзы.

я и не спорю. просто хотелось хлеба, а не только зрелищ.
да и не ожидал, что ерлангистов здесь нет. Думаю то, что я написал
Автор: abch-98-ru
Дата: 19.11.08
, продираясь сквозь синтаксис — они б написали легко и непринужденно минут за 5-10.
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 14:20
Оценка:
R>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.
не видел там такого, в любом случае паттерн матчинга не будет хватать.
Сейчас смотрю в сторону F#
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[10]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 14:20
Оценка:
Здравствуйте, remark, Вы писали:

R>В смысле? Определенно, это можно исправить. Я даже думаю, что любую ошибку можно исправить.

я к тому что если надо закладываться на определенный порядок сразу, это легко сделать с минимальными приседаниями,
в отличие от других языков. С другой стороны, конечно erlang на это заточен, dsl так сказать, в последней версии
они поправили кстати баг с jinterface

A bug when Jinterface did not detect remote node disconnects has been corrected.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 15:31
Оценка:
Здравствуйте, cadet354, Вы писали:

R>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.

C>не видел там такого, в любом случае паттерн матчинга не будет хватать.
C>Сейчас смотрю в сторону F#

Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[10]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 19.11.08 16:06
Оценка:
Здравствуйте, remark, Вы писали:

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


R>>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.

C>>не видел там такого, в любом случае паттерн матчинга не будет хватать.
C>>Сейчас смотрю в сторону F#

R>

R>Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.
в С# ? про batch это понятно, а вот как например обработать конкретное сообщение, а остальные пусть подождут и пусть накапливаются?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 16:11
Оценка:
Здравствуйте, cadet354, Вы писали:

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


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


R>>>>А CCR чем не устраивает не понял? Там те же очереди, можно выбирать даже не последнее сообщение, прям как в Erlang.

C>>>не видел там такого, в любом случае паттерн матчинга не будет хватать.
C>>>Сейчас смотрю в сторону F#

R>>

R>>Паттерн-матчинг там как раз есть. Там даже круче — можно, например, дожидаться прихода сразу N сообщений, когда они все придут, то можем их обработать. Или например, "reader-writer" агенты — часть сообщений для агента обрабатывается как обычно по одному, а другая — параллельно из разных потоков.

C>в С# ? про batch это понятно, а вот как например обработать конкретное сообщение, а остальные пусть подождут и пусть накапливаются?


АФАИК Сhoice называется примитив для выборки одного сообщения из множества.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[11]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 19.11.08 16:33
Оценка:
Здравствуйте, 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 очереди, или маршрутизация сообщений одному из нескольких агентов на основе фильтров, или балансировка нагрузки (когда несколько агентов подключаются к одной очереди) и т.д. Эрланг-то сам по себе как раз экстремально минималистичен, и чуть что надо сделать не типовое надо делать присядания.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[4]: Java Parallel computing: multicore, Erlang, Scala
От: yumi  
Дата: 20.11.08 01:32
Оценка:
Здравствуйте, 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
Re[12]: Java Parallel computing: multicore, Erlang, Scala
От: cadet354 Россия
Дата: 20.11.08 07:13
Оценка:
Здравствуйте, 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 (видимо зря), не подскажешь как сделать такую вещь как очередь с приоритетом, причем приоритет определяться по определенному полю в обьекте, его значению, грубо говоря больше/меньше определенного параметра.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[8]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 20.11.08 12:24
Оценка:
Здравствуйте, 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]).
Re[9]: Java Parallel computing: multicore, Erlang, Scala
От: gandalfgrey  
Дата: 20.11.08 14:21
Оценка:
Здравствуйте, abch-98-ru, Вы писали:

Это реализация изначально кривого подхода — ибо затачиваться на последовательность действий вредно и опасно. Все должно быть асинхронно :
start_two(P1,P2)->
    P1 ! {take,self()},
    two({P1,none},{P2,none}).

two({P1,S1}=R1,{P2,S2}=R2)->
    receive
        {get_state,Pid}->
            Pid ! {state,S1,S2},
            two(R1,R2);

        {taken,P1}->
            P2 ! {take,self()},
            two({P1,taken},R2);

        {taken,P2} when S1==none ->
            io:fwrite("P1 desynchronyzed~n ",[]),
            P2 ! {free,self()},
            two(R1,R2);

        {taken,P2}->
            P2 ! {free,self()},
            P1 ! {free,self()},
            P1 ! {take,self()},
            two({P1,none},{P2,none})
    end.


Ну, как-то вот так...
Вложенные receive — некузяво !
Re[10]: Java Parallel computing: multicore, Erlang, Scala
От: abch-98-ru Россия  
Дата: 20.11.08 16:06
Оценка:
Здравствуйте, gandalfgrey, Вы писали:

G>Это реализация изначально кривого подхода — ибо затачиваться на последовательность действий вредно и опасно.

ага, это изначально реализация дедлока . достаточно запустить dl:start(). и вуаля

а у тебя код красивый, но не рабочий пока
что или как запускать-то чтобы заработало-то в смысле за дедлочило
можно по слогам
Re[5]: Java Parallel computing: multicore, Erlang, Scala
От: remark Россия http://www.1024cores.net/
Дата: 21.11.08 15:36
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Фундаментальное отличие actors model и гармонично взаимодействующих процессов" от всего остального в том, что они не имеют разделяемых данных, и связанных с ними проблем в принципе.


...они не имеют разделяемых данных, и связанных с ними проблем и преимуществ в принципе.

Я думаю, так будет честнее. Кстати, никто не запрещает комбинировать актёров и разделяемые данные (с умом, естественно), беря от обоих моделей лучшее.


1024cores &mdash; all about multithreading, multicore, concurrency, parallelism, lock-free algorithms
Re[5]: Java Parallel computing: multicore, Erlang, Scala