Re[66]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 19.12.08 14:18
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


R>>Датафлоу, или то, что в программном мире называется task-based parallelism


AVK>Это не одно и то же совсем. Второе это просто способ параллелизации fine grained задач. А уж поверх можно и data parallelism строить, и фьючерсы, и твой любимый fork/join.


Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач и специальные способы задания зависимостей по данным.


R>>, не требует никакого порядка


AVK>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.


Так континуэшены — это что? Правильно — задание зависимости по данным. Ты говоришь "когда будет выполнена та задача, выполнить эту", что переводится на язык датафлоу "входные данные для этой задачи предоставляет та и только та задача; когда они будут готовы (когда выполнится та задача), можно выполнять эту задачу".

Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.

Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.


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

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


R>>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)


AVK>Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено



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


R>>. Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.


AVK>И чем конкретно тебе не нравятся фьючерсы с континьюэшенами?



В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею и сам их реализовываю. ФИФО сообщений там и не нужен, его там и приткнуть то не куда — каждая задача получает единственное сообщение "выполниться". Там упорядочивание идёт в другом смысле — задача ставится на выполнение, когда для неё готовы данные.

Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров (естественно, т.к. ФИФО к задачам не применимо, не путать с предпочтительным порядком шедулинга — что другое).



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

AVK>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.


Как ФИФО мешает work stealing?


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

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


E>>>Дай ссылочку, плз. А то я не пойму о чем речь.


AVK>>Re[63]: пример eao197: "сообщения" рвут "разделяемую память"
Автор: AndrewVK
Дата: 18.12.08


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



Конечно, нет. Фьючерсы — это способ задать зависимости по данным в параллельных вычислениях (HPC). Мы блокируемся на фьючерсе в тот момент, когда код ниже *зависит по данным* от результата вычисления этого фьючерса.
(О какой вообще последовательности сообщений можно говорить в контексте фьючерсов )
Что кардинально отличается от приёма *ряда* сообщений актёром с внутренним состоянием.



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

R>Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач


И при чем тут датафлоу? Таски прекрасно работают даже если никакого потока данных нет в принципе. Единственное требование — наличие fine grained разбиения. Автоматические зависимости по данным совсем не обязательны. Вот википедийное определение — http://en.wikipedia.org/wiki/Dataflow . Первых два варианта никак к task parallelism не подходят, а третье по сути описывает агентную модель, о которой здесь речь и идет, собственно.

R>>>, не требует никакого порядка


AVK>>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.


R>Так континуэшены — это что? Правильно — задание зависимости по данным.


Просто задание зависимости. Неважно по чему.

R> Ты говоришь "когда будет выполнена та задача, выполнить эту"


Задача != данные.

R>, что переводится на язык датафлоу


Э нет, я таким манером чего хочешь доказать могу. Задача != данные. Точка.
Мне это напоминает дисскуссию про монады здесь же. Там чуть ли не любая комбинирующая конструкция языка волшебно оказывалась монадой, а у тебя любой fine grained код точно так же чудесным образом превращается в датафлоу.

R>Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.


Это не суть, это модель. И она совсем не единственная.

R>Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.


TPL и вообще без графа их позволяет организовать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[79]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 15:24
Оценка:
Здравствуйте, eao197, Вы писали:

E>Передача предиката как критерия отбраковки/принятия очередного сообщения вряд ли может считаться более общим решением.


По сравнению с зависимостью по возвращаемому результату? Безусловно более общее, хотя бы потому что возвращаемого результата может не быть вовсе. Собственно, в TPL Future наследуется от Task, так что прекрасно видно, кто из них более общий. И это несмотря на то, что Task умеет только один вид предикатов — завершение другой задачи с определенным статусом.

E>Если обработка сообщений агента может быть распараллелена, то нет никаких проблем с раздергиванием очереди. А если не может, то и никакого work stealing-а не будет в принципе.


Ну так в этом и сила более гибких и абстрактных решений. Я декларативно говорю — здесь есть зависимость. Точка. А уж как там внутренняя механика это все организует — в виде ФИФО очереди, каких то более причудливых структур, или вообще с использованием каких нибудь аппаратных фич — личное дело рантайма. А если зависимости нет — то и не надо заморачиваться и спокойно выбирать оптимальное по производительности решение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[77]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 15:24
Оценка:
Здравствуйте, remark, Вы писали:

R>Как ФИФО мешает work stealing?


ФИФО мы при этом соблюсти не сможем, потому что задачи уйдут в другую очередь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[77]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 15:24
Оценка:
Здравствуйте, remark, Вы писали:

R>Ну а чего плохого в том, что человек сделал библиотеку под свои нужды


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

R>В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею


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

R>Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров


Эта модель неприменима для распараллеливания?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[78]: пример eao197: "сообщения" рвут "разделяемую память"
От: remark Россия http://www.1024cores.net/
Дата: 19.12.08 15:35
Оценка:
Здравствуйте, AndrewVK, Вы писали:

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


R>>Ну а чего плохого в том, что человек сделал библиотеку под свои нужды


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


Так это ты сам про эту конкретную библиотеку и сказал
Я тебе про неё конкретно и ответил.

R>>В библиотеках для параллельных *вычислений* (HPC) я против них ничего не имею


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


Конечно НЕТ!
Сетевой сервер — это НЕ параллельные вычисления.
Игры — это НЕ параллельные вычисления.
ОС и миддлваре — это НЕ параллельные вычисления.
ГУИ приложения — это НЕ параллельные вычисления.
Работа с физическими устройствами — это НЕ параллельные вычисления.
Однако всё это использует параллелизм.


R>>Поэтому, когда я говорил про ФИФО, я, естественно, имел в виду модель актёров


AVK>Эта модель неприменима для распараллеливания?


Применима. Но она применима не только для параллельных вычислений.


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

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


R>>Фьючерсы и форк/джоин — это тоже программная реализация датафлоу. Фьючерсы и форк/джоин — это просто частные случаи графа задач


AVK>И при чем тут датафлоу? Таски прекрасно работают даже если никакого потока данных нет в принципе. Единственное требование — наличие fine grained разбиения. Автоматические зависимости по данным совсем не обязательны. Вот википедийное определение — http://en.wikipedia.org/wiki/Dataflow . Первых два варианта никак к task parallelism не подходят, а третье по сути описывает агентную модель, о которой здесь речь и идет, собственно.


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

fine grained — это определение task-based programming?
fine grained — это уже деталь реализации, которая говорится только после того, как дано общее определение концепции. А концепция тут как раз — зависимость по "данным".


R>>>>, не требует никакого порядка


AVK>>>Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.


R>>Так континуэшены — это что? Правильно — задание зависимости по данным.


AVK>Просто задание зависимости. Неважно по чему.


Я имел в виду "данные" (в кавычках). Извиняюсь. Т.е. некая абстракция. В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных". Понятно, что железо не может передавать в сообщении сокет; или один элемент отрисовывает часть GUI, а потом другой — поверх дорисовывает. Однако в софте мы можем с таким оперировать.


R>> Ты говоришь "когда будет выполнена та задача, выполнить эту"


AVK>Задача != данные.


Задача == "данные" (абстрактный ресурс).
Но ресурс обязательно есть, иначе зачем мы говорим, что бы этот таск выполнился после того — мы зависим от того, что сделает тот таск — посчитает ли какие-то данные, откроет сокет, отрисует часть ГУИ.


R>>, что переводится на язык датафлоу


AVK>Э нет, я таким манером чего хочешь доказать могу. Задача != данные. Точка.

AVK>Мне это напоминает дисскуссию про монады здесь же. Там чуть ли не любая комбинирующая конструкция языка волшебно оказывалась монадой, а у тебя любой fine grained код точно так же чудесным образом превращается в датафлоу.

агнеты != датафлоу.


R>>Поверхностные отличия, конечно, имеются; но суть одна же — есть DAG, рёбра — зависимости по данным, когда все зависимости по данным удовлетворены — вершину можно ставить на выполнение.


AVK>Это не суть, это модель. И она совсем не единственная.


R>>Кстати, Threading Building Blocks и TPL позволяют вычисления организовывать и в виде произвольного DAG.


AVK>TPL и вообще без графа их позволяет организовать.


То, что возможны более простые (вырожденные) графы — это понятно.


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

R>Да, таски могут работать и с вырожденным потоком данных.


Таски могут работать совсем без потоков данных. Более того, собственно исходные таски никак на поток данных и не завязаны. Data flow строится поверх них.

R>fine grained — это определение task-based programming?


Нет конечно, с чего ты взял? Fine grained это требование к коду, чтобы можно было воспользоваться task parallelism.

R>fine grained — это уже деталь реализации


Нет, не деталь. Это принципиальное требование к коду.

AVK>>Просто задание зависимости. Неважно по чему.


R>Я имел в виду "данные" (в кавычках).


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

R> В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных".


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

R>Задача == "данные" (абстрактный ресурс).


Задача это задача. К чему выдумывать еще какие то термины?

R>Но ресурс обязательно есть


Нет.

R>, иначе зачем мы говорим, что бы этот таск выполнился после того


А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?

R>агнеты != датафлоу.


А в википедии написано, что:

Concurrency

A dataflow network is a network of concurrently executing processes or automata that can communicate by sending data over channels (see message passing.)


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

AVK>>TPL и вообще без графа их позволяет организовать.


R>То, что возможны более простые (вырожденные) графы — это понятно.


А с чего ты взял, что это исключительный, вырожденный случай?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[79]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 16:18
Оценка:
Здравствуйте, remark, Вы писали:

R>Так это ты сам про эту конкретную библиотеку и сказал


Я ее привел в качестве источника мнения eao197

R>Я тебе про неё конкретно и ответил.


Ответил только ты на какой то вопрос, который я не задавал.

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


R>Конечно НЕТ!


Ясно А я думал, что parallel computing в названии топика это все таки оно.
Что же касается гуев и прочих устройств, то там совершенно иные подходы, там все эти навороты нафик не нужны, там можно тупо синхронизироваться по старому, потому что упирается не в процессоры, а в само устройство. Мне вон нетовской AsyncOperation за глаза хватает и никакой потребности изобретать чего то хитрое никогда не возникало.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[80]: пример eao197: "сообщения" рвут "разделяемую память"
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 19.12.08 16:26
Оценка:
Здравствуйте, AndrewVK, Вы писали:

R>>Так это ты сам про эту конкретную библиотеку и сказал


AVK>Я ее привел в качестве источника мнения eao197


Это не единственный источник.


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

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


R>>Как ФИФО мешает work stealing?


AVK>ФИФО мы при этом соблюсти не сможем, потому что задачи уйдут в другую очередь.



У меня сейчас работает агентная система на work-stealing'е.
Я понял, в чём тут конфьюжн.
Ты путаешь 2 вещи. Первая — упорядочивание сообщений для агента (пользовательская сущность), вторая — упорядочивание элементов работы шедулера (сообщения агента != элементы работы шедулера!!!).
В контексте task-based, futures, dataflow ты говоришь об упорядочивании элементов работы шедулера, что его не требуется (и это правильно). Однако сообщений пользовательских сущностей в этой модели нет (ну точнее они есть, но они не интересны, формально каждый таск обрабатывает одно сообщение "исполниться", т.е. элементы шедулера и пользовательские сообщения объединены).
В агентной же модели добавляется 2 принципиальных вещи, которых нет в той модели — (1) агент обрабатывает последовательность, множество сообщений, и (2) у агента есть состояние. Во-первых, это вносит второе упорядочивание, т.е. мы можем, например, не упорядочивать элементы работы шедулера (агентов), но упорядочивать сообщения для каждого отдельного агента. Естественно глобальное упорядочивание элементов работы шедулера не имеет никакого смысла, т.к. тогда у нас фактически будет только один поток. Думай — таск==агент, мы не упорядочиваем в каком порядке шедулер берёт агентов и начинает выполнять для них сообщения. И это логично их не упорядочивать, например я применял следующую схему: для пользователя документированный порядок — порядок не гарантируется, реальный порядок — близко в LIFO (Cilk style LIFO work-stealing scheduler).
Далее. Почему я настаиваю на ФИФО для сообщений агентов (ещё раз — (1) это не ограничивает шедулер — у него по-прежнему достаточно "элементов работы" (агентов), (2) это не требует порядка обработки шедулером — пусть какого хочет агента, того и берёт на исполнение). У агента есть состояние, и помимо потребленных и порожденных сообщений появляются побочные эффекты на состоянии агента. А как известно большинство операций над состоянием не коммутативные, т.е. мы не можем вначале записать в сокет, потом его открыть; мы не можем А поделить на Б, если нам надо Б поделить на А.
Необходимость такого упорядочивания очевидна — достаточно рассмотреть объектно-ориентированные системы. Когда ты вызываешь у объекта несколько методов (что в объектной теории называется как-раз посылкой сообщения), ты требуешь (и это логично), что бы они выполнились в программном порядке (ФИФО). А как тебе такая реализация — методы объектов вызываются в недетерминированном порядке (как компилятору удобнее)? Добавляем в список элемент А и элемент Б, а они добавляются в произвольном порядке; хочешь упорядочивания — добавляй сиквенсы и разруливай руками; слишком старые вызовы отбрасываем и делаем пере-посылку. А ты предлагаешь фактически то же самое. Методы выполняются в программном порядке, однако если у нас в этой же программе есть несколько потоков — то, пожалуйста, пусть ОС их шедулит как ей удобнее.
А агент — это и есть фактически тот же объект. То же состояние, та же последовательность вызовов/посылок сообщений, та же инкапсуляция.
Агентная модель мощнее модели тасков (надмножество). Редукция следующая: там где ты порождаешь таск — создаешь агента, когда таск становится готовым для исполнения (возможно сразу) — посылаешь ему соощение "исполниться", после исполнения этого сообщения разрушаешь агента. Т.о. ты получаешь модель основанную на тасках из агентной, заметь порядок исполнения — НЕ ДЕТЕРМИНИРОВАННЫЙ. Т.е. и Эрланг и SObjectizer при такой редукции дадут тебе то самое отсутствие упорядочивания "элементов работы".
Над этим агентная модель вводит новый уровень — "таск" получается собственную очередь сообщений, ему разрешается жить дольше, разрешается принимать множество сообщений, соотв. для него приобретает смысл иметь состояние. Упорядочивание сообщений в этой очереди — это отдельный вопрос, мы можем его выбрать каким угодно, как нам надо для этой, уже агентной, модели. Т.е. агент получается сам себе мини-шедулер.
Важно различать эти 2 *независимых* уровня шедулинга. Пока ты не будешь различать, будет получаться, что ФИФО мешает work-stealing. ФИФО в агенте никак не мешает шедулеру, который шедулит самих агентов на исполнение.



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

R>> В разрезе софта возможно правильнее сказать "готовность ресурса", а не "готовность данных".


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



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



R>>Задача == "данные" (абстрактный ресурс).


AVK>Задача это задача. К чему выдумывать еще какие то термины?


R>>Но ресурс обязательно есть


AVK>Нет.


R>>, иначе зачем мы говорим, что бы этот таск выполнился после того


AVK>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?


Ну это смешно. Из ты можешь получить из N полностью независимых сущностей систему, ты можешь получить только N отдельных систем. Ты когда запускаешь таски, ты потом не ждёшь из завершения? Код, который отображает потом картинку пользователю, не зависит от данных, подготовленных тасками рей-трейсинга?



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

AVK>Ответил только ты на какой то вопрос, который я не задавал.


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


R>>Конечно НЕТ!


AVK>Ясно А я думал, что parallel computing в названии топика это все таки оно.


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

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


Какие навороты там не нужны?
А никто и не говорит про что-то хитрое. И такие задачи тоже очень хорошо ложатся на агентную модель. Никаких хитростей, просто удобство, асинхронность, ограниченное распараллеливание (возможно и не ограниченное, а возможно и то и другое).



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

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


Вот я и говорю, презерватив на глобус.

AVK>>А мы можем и не говорить, если этого не нужно. Я именно об этом тут и писал. Вот, к примеру, параллелю я рейтрейсер. Зависимостей нет вообще никаких. Пользуюсь при этом TPL. Что, в этом случае уже не task parallelism? Или он при этом какой то неполноценный?


R>Ну это смешно.


Именно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[79]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 17:17
Оценка:
Здравствуйте, remark, Вы писали:

R>У меня сейчас работает агентная система на work-stealing'е.


Замечательно.

R>В контексте task-based, futures, dataflow ты говоришь об упорядочивании элементов работы шедулера


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

R>У агента есть состояние


А есть ли? Ты на частном случае строишь общую теорию.

R>Необходимость такого упорядочивания очевидна — достаточно рассмотреть объектно-ориентированные системы


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

R>. Когда ты вызываешь у объекта несколько методов (что в объектной теории называется как-раз посылкой сообщения), ты требуешь (и это логично), что бы они выполнились в программном порядке (ФИФО)


Аналогии в качестве аргументов.

R>. А как тебе такая реализация — методы объектов вызываются в недетерминированном порядке (как компилятору удобнее)?


Аналогии. Кривые.

R>А агент — это и есть фактически тот же объект.


А тебе еще раз намекаю: такими приемами можно доказать что угодно, уж поверь. Нет, агент это не объект, и аналогиями ничего доказать нельзя. В принципе. Никакими.

R>Агентная модель мощнее модели тасков


Нет. Они эквивалентны, потому что на агентной модели можно реализовать модель тасков в полном объеме, и наоборот. Но я не понимаю, какое это имеет отношение к ФИФО vs гибкий механизм декларирования зависимостей.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[81]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 17:17
Оценка:
Здравствуйте, eao197, Вы писали:

E>Это не единственный источник.


И?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Re[81]: пример eao197: "сообщения" рвут "разделяемую память"
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 19.12.08 17:17
Оценка:
Здравствуйте, remark, Вы писали:

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


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

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


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

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


Они хорошо ложаться на любую модель. Поэтому чем она проще, тем лучше. Модель AsyncOperation всего с 2 значимыми методами намного проще агентов.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
AVK Blog
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.