T>Почему не могу. Могу. Смотри.
T>Громко заявляю, что я решил какую-то общую проблему, и что "её можно сделать сколь угодно мало требовательной путём группировки сообщений".
Ну давай посмотрим.
R>>Как ты будешь справляться со значительной внесённой латентностью? Кто будет рулить этими промежуточными узлами? Отдельные потоки, рабочие потоки этим нельзя нагружать, т.к. они могут обрабатывать сообщения долго.
T>Так не надо, чтобы долго обрабатывали. Надо, чтобы недолго.
Как мне быстро обрабатывать блокирующий вызов на ККМ или на принтер OPOS? Ну нет у меня драйверов неблокирующих. Как мне делать вызовы в сторонние библиотеки?
Мы ж по прежнему об *общем* случае говорим, правильно?
T>Более того, динамический поток данных даёт возможность рулить размером программы сообщения. Можно балансировать — чем больше входов у узла, тем больше будет программа узла и меньше выявляемый параллелизм выше уровня ILP. И наоборот.
На это я даже и не знаю, что ответить в контексте общего случая... Кстати, ты представляешь какой минимальный размер сообщения получится даже если очень хорошо реализовать твою схему в софте и считать, что оверхед должен быть не более 5%?
R>> Отдельные процессоры выделять под эти потоки не целесообразно. Если они будут разделять процессоры с другими потоками, значит они могут шедулиться для выполнения через 40 мс и больше. Ну вот проходит такое сообщение через эту сеть и получаем внесённую латентность 200 мс.
T>Да.
Ты видишь разницу между общим случаем и только throughput-oriented HPC????????
Вот именно, что ДА — 200 мс. Значит GUI — лесом, приложения для биржевой торговли — лесом, игры — лесом. Ну и где тут общий случай?
R>>В традиционной схеме у нас сообщение сразу качует от кэша-источника в кэш-получателя. С твоей схемой оно покачает по N кэшей. Это чудовищный оверхед, проще сразу сделать одну атомарную RMW операцию и отправить сообщение получателю. Как ты предлагаешь это нивелировать?
T>Путём высокопараллельной обработки небольших сообщений.
А если у нас нет много сообщений?
Мы ж по прежнему об *общем* случае говорим, правильно?
Может быть такой паттерн. Актёр А отправляет сообщение Б, после обработки Б отправляет А, и так сто раз. Всё, в системе больше сообщений нет. НО, потом приложение начинает что-то считать и тут появляются тысячи сообщений.
Нужно и throughput и latency. Вот и крутись как хочешь.
Ну а если ограничиться только throughput-oriented HPC, то действительно всё просто становится.
R>>Неупорядоченные сообщения это, может, и кошерно. Но факт в том, что никто такую систему использовать не будет. Если кто-нибудь придёт к пользователям Erlang, Scala Actors, Concurrency and Coordination Runtime и др. и скажет, что давайте ка мы у вас уберём ФИФО, т.к. так более кошерно, то его сразу пинками погонят. Правильно, а зачем им это надо?
T>В Эрланге нет ФИФО, как такового. "Внимательней вглядись" (C) Басё
per-producer fifo
R>>Динамический лоад-балансинг как будешь делать? Пока что ты увильнул статическим.
T>Динамическую балансировку нагрузки делать трудно, согласен. Но совсем не по той причине, о которой ты думаешь.
T>Дело в том, что одно из нескольких сообщений, необходимых для старта программы обработки оной группы сообщений может сперва пойти на один узел, а потом — динамически, — на другой.
T>Но это тоже решаемо. Достаточно отправлять выше по иерархии те сообщения, что не должны сейчас выполняться на этом процессоре.
А о чём ты думаешь я думаю? О досылке сообщений вслед за агентом я уже давно подумал и о тех проблемах, которые возникают следом. Досылку вслед я применял, НО ТОЛЬКО для случая который не требовал никакого упорядочивания.
R>>Но это не катит для систем общего назначения. Обработка сообщений выполняется недетерминированнное, но малое и с небольшой дисперсией время, зависит от входных данных, не зависит от внешних систем, плюс часть процессоров периодически занимается другими процессами. Тот лоад-балансинг, который ты описал всасёт в такой ситуации — скорость работы системы будет определяться самым медленным процессором, а он может быть сколь угодно медленным.
T>Вставки мои.
Ну, да, небольшие блокирующие вызовы на железяки. Небольшие вызовы в сторонние библиотеки.
T>Вот ссылки: T>http://thesz.mskhug.ru/svn/hiersort/ — там в подкаталоге doc лежит статья про машину динамического потока данных с частичной сортировкой сообщений.
T>http://thesz.livejournal.com/545287.html — чуток описания про преобразование обычной программы в программу для машины динамического потока данных. Делаем такую VM и все преимущества у нас в кармане.
T>Где-то у меня ещё что-то было, но я сейчас отыскать не могу.
А говоришь — не про железо.
Это всё равно, что если бы я из мира софта пришёл бы к тебе в мир железа и сказал бы:
Ребята, я решил все ваши проблемы. И что вы тут сидите и извращаетесь со своими гипер-кубами, жирными деревьями и торами. Всё, что вам нужно — это реализовать полносвязанный NxN коммутатор. И всего-то. Работает охерительно быстро. Не получается? Ну сделайте эмуляцию. Никакие свойства-то от этого не потеряются. Откуда им теряться, когда делаешь эмуляцию?
Здравствуйте, eao197, Вы писали:
E>Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет.
Делал терминал сбора данных через Wi-Fi. TCP/IP не проходил постоянно рвало сединение. Очень плохая связь. Пришлось создавать свой протокол через UDP по принципу отправил получил ответ еще отправил.
Правда сделал по простому. Отправитель посылал и дожидался определенное время ответа, при неудаче слал снова. Для каждой сессии сообщения свой ID и для каждого. Соответсвенно и фильтрация пакетиков по сессии и номеру сообщения.
Просто надежно (народ в пятницу отправлял, а в понедельник получал при выключенном приемнике), и сносно по скорости для решаемой задачи, но медленно для больших объемов. Передача большого количества пакетов, с запросом непришедших была бы значительно лучше. Просто все крутится вокруг того, что до нас уже сделано.
и солнце б утром не вставало, когда бы не было меня
Re[78]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, eao197, Вы писали:
E>>Если агенты работают в разных рантаймах, соединенных одним прямым потоковым каналом (тем же TCP/IP), то и здесь проблем нет. S>Делал терминал сбора данных через Wi-Fi. TCP/IP не проходил постоянно рвало сединение. Очень плохая связь. Пришлось создавать свой протокол через UDP по принципу отправил получил ответ еще отправил.
А почему ты вначале брал TCP?
И если бы связь не рвалась, то оставил бы его?
Здравствуйте, remark, Вы писали:
R>Я не против того, что бы система предоставляла возможность сказать "для этого агента порядок не требуется", если она может реализовать что-то лучше для такого случая. Но в то же время для "высокоуровневой", "удобной" системы, я считаю обязательным так же и возможность задать гарантированный ФИФО. При этом ФИФО больше как выбор "по-умолчанию", а не ФИФО — как оптимизация.
я не против ФИФО, даже был бы за. просто в тех системах, которые мне доводится делать, требования к load balancing (более одного читателя очереди) всегда более сильные. а т.к. они вступают в противоречие с ФИФО по причине параллельной работы разных читателей, то про ФИФО-возможности я даже и не думаю. опять же, это не отменяет возможности в специальных случаях предусмотреть специальные агрегаторы не-на-сообщениях, но на очередях я уже привык обходиться без ФИФО
R>По моему опыту, если идут "низходящие" сообщения (т.е. менеджер устройства посылает устройству) и сообщения типа "запрос", то тогда, в принципе, возможно делать какое-то высокоуровневое управление. Хотя зачастую это только лишняя работа. R>Но если идут "восходящие" сообщения <...>
в целом, с разницей управления по нисходящему и восходящему потоку согласен, естественно, всегда приходится принимать во внимание ограничение доступной для принятия решения информации на определённом уровне... как ни странно, однако, зачастую не сложно в сообщения включать некоторую дополнительную информацию, обрабатываемую неким абстрактным образом — есть паттерны. в целом, не стоит пренебрегать такой возможностью при проектировании — есть паттерны, которые позволяют скрыть нюансы от определённого обработчика, тем не менее, не закрывая их совсем
Re[61]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Не очень представляю себе, как можно обеспечить ФИФО для отсылки сообщений разными отправителями без использования какого-либо вида глобальной синхронизации между ними (на основании меток времени или меток предшествования, к примеру).
если в-общем (безотносительно эрланга, о котором мне нечего сказать), то при использовании концепции очередей этой синхронизацией будет заниматься менеджер конкретной очереди — он же принимает send от разных отправителей в каком-то конкретном порядке, согласно которому и складывает сообщения в очередь. т.е. специальные метки для отправителей не видны, равно как и отправителям ничего знать друг о друге не нужно, т.к. всем этим занимается менеджер очереди
Re[72]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, Sinclair, Вы писали:
E>>Да ради бога. Только ты можешь сказать, какой смысл в том, чтобы сообщения от одного отправителя извлекались из этих очередей не в том порядке, в котором они туда встали?
S> Ты опять про "туда встали"? Это интимная подробность функционирования очереди. В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен. Зачем? Мы же стремимся к максимизации быстродействия, а ее главный лозунг — "если можешь — не делай!".
Дизайн и реализация библиотеки, которая нацелена исключительно скорость — не составляет сложности.
Ответ на любой сложный проектный вопрос тривиален — как быстрее, так и делаем. Кстати, так же можно убрать требование, что в каждый момент времени для агента/актёра обрабатывается не более одного сообщения (многопоточная обработка) — в некоторых случаях агент сам может разрулить это значительное эффективнее — возможно ему вообще не нужно взаимное исключение, возможно он защитит себя reader-writer мьютексом, т.к. образом все reader сообщения будут обрабатываться параллельно, возможно он может защищать мьютексом только очень небольшие части своих функций обработки сообщений. Так же можно требовать с пользователя, что бы все сообщения обрабатывались малое и примерно равное время — так значительно проще для эффективного шедулинга. Так же можно требовать, что никакие сообщения не блокировались — значительно проще для шедулинга.
Это можно так сказать подход "ассемблер", т.е. мы вам даём только скорость. всё. хотите "удобно" — делайте сами поверх.
Мне больше нравится подход, так скажем, "С++" — мы вам даём "удобно", но если хотите можете всё взять в свои руки и делать "быстро" (думай о premature optimization). Т.е. вначале делаешь как удобнее и быстрее. Если нужна скорость И готов думать как её делать И готов жертвовать размером и читаемостью кода — пожалуйста, объявляй агента, как не требующего ФИФО и впуть реализовывать собственные протоколы.
Кстати, вопрос на засыпку — если большое число агентов всё равно требуют ФИФО, то что будет быстрее работать — хорошая и умная (у ран-тайм всегда больше возможностей) реализация ФИФО в ран-тайме или ручное докручивание пользователем ФИФО поверх того упорядочивания, которое реализовано в ран-тайм (фактически 2 упорядочивания).
Здравствуйте, eao197, Вы писали:
E>Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?
Нет, мое самое первое сообщение в этой ветке.
AVK>> Я ведь именно об этом и писал.
E>От того, что у .NET-овского фьючерса появился continueWith, он не стал каким-то особенным фьючерсом.
Совершенно верно. Именно это я тебе и говорил.
AVK>>Это пример одной из методик балансинга — work stealing.
E>Только в Cilk-е выполняется "кража" фрагментов стека. А в модели агентов будет просто другой подход.
Да пофик что там крадется физически. Главное принцип. И он, если мы хотим параллелить по процессорам, вполне применим и в агентах.
E>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
Именно. Но обязательное ФИФО всю малину портит.
E>А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).
Именно поэтому гибкая схема управления зависимостями для универсальных библиотек лучше, чем обязательный ФИФО.
AVK>>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.
E>Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.
ФИФО, которую ты тут защищаешь, неизмеримо более частное и ограниченное решение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
R>А почему ты вначале брал TCP? R>И если бы связь не рвалась, то оставил бы его?
Конечно. Зачем же себе геморой то придумывать. Причем в офисе все хорошо, а идешь на площадку производства всё йок. Правда сначала сделал свою версию, а только потом изучил более подробно ТСP ip, и был приятно удивлен, что мыслим то мы одинаково
и солнце б утром не вставало, когда бы не было меня
Re[74]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Исходное -- это какое? Там где ты написал, что я не понимаю, что такое фьючерс?
AVK>Нет, мое самое первое сообщение в этой ветке.
Дай ссылочку, плз. А то я не пойму о чем речь.
E>>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
AVK>Именно. Но обязательное ФИФО всю малину портит.
Как именно ФИФО портит эту малину?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[74]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, AndrewVK, Вы писали:
E>>Ее можно применять, например, и так: у какого-то агента есть очередь с N уже помещенных туда сообщений. При наличии свободных процессов сообщения из этой очереди могут извлекаться свободными процессорами и обрабатываться.
AVK>Именно. Но обязательное ФИФО всю малину портит.
E>>А если операция завязана на состояние, то даже в Clik-е для этого применяется специальная конструкция inlet, которая сильно сокращает возможности work stealing-а (по крайней мере так я понял из Wikipedia).
AVK>Именно поэтому гибкая схема управления зависимостями для универсальных библиотек лучше, чем обязательный ФИФО.
AVK>>>Все это решаемо, возможно просто придется редуцировать набор предикатов до небольшого количества стандартных случаев.
E>>Тогда ты предлагаешь не универсальное, а частное и весьма ограниченное решение.
AVK>ФИФО, которую ты тут защищаешь, неизмеримо более частное и ограниченное решение.
Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже). Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.
Вот тут я ответил Sinclair более подробно: http://www.rsdn.ru/forum/message/3221599.1.aspx
Здравствуйте, Sinclair, Вы писали:
S>1. В схеме single producer-single consumer можно построить FIFO на протоколе без упорядочивания, применив 1-в-1 стандартные техники из TCP/IP, выкинув обработку потери пакетов.
Все таки техники TCP нацелены не на упорядочивание (в этом плане там ничего нетривиального нет, банальное восстановление последовательности по номеру пакета), а на минимизацию потерь от синхронной отсылки ACK.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, remark, Вы писали:
R>Датафлоу, или то, что в программном мире называется task-based parallelism
Это не одно и то же совсем. Второе это просто способ параллелизации fine grained задач. А уж поверх можно и data parallelism строить, и фьючерсы, и твой любимый fork/join.
R>, не требует никакого порядка
Для task parallelism в общем случае это не так. Поэтому, скажем, в TPL у тасков есть континуэшены.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, 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 с неразрушающим чтением, то тогда ты сможешь догнать решение на разделяемой памяти.
Здравствуйте, remark, Вы писали:
R>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)
Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено
R>. Вопрос только в том, будем ли мы заниматься premature optimization сразу и всегда, или только, когда это нам надо.
И чем конкретно тебе не нравятся фьючерсы с континьюэшенами?
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
R>>Никто и не говорит про "только ФИФО" (ну по крайней мере я... я думаю eao197 тоже)
AVK>Что то мне подсказывает, что в SObjectizer ничего окромя ФИФО не предусмотрено
В SObjectizer есть только per-producer fifo и только в случае, если агенты работают в одном рантайме. До остального пока не доросли.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[76]: пример eao197: "сообщения" рвут "разделяемую память"
Все-таки фьючерсы с континуэшами не являются аналогами сообщений. Поскольку во фьючерсе изначально предполагается получение результата обработки. А в случае сообщения -- нет.
AVK>>>Именно. Но обязательное ФИФО всю малину портит.
E>>Как именно ФИФО портит эту малину?
AVK>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
Ну а конкретно, как ФИФО препятствует тому же work stealing?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[77]: пример eao197: "сообщения" рвут "разделяемую память"
Здравствуйте, eao197, Вы писали:
E>Все-таки фьючерсы с континуэшами не являются аналогами сообщений. Поскольку во фьючерсе изначально предполагается получение результата обработки.
Опять ты читаешь невнимательно. Фьючерсы я привел в качестве примера автоматического разруливания зависимостей, если одна задача используетрезультат другой. А дальше я писал про более общий случай, который возврат значения не подразумевает.
AVK>>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
E>Ну а конкретно, как ФИФО препятствует тому же work stealing?
Work stealing предполагает изменение порядка обработки сообщений. Т.е. ФИФО в локальной очереди конечно останется, но вот сама эта очередь может быть раздергана в другие очереди, отсюда и смысла в ФИФО становится ноль, все равно оно правильно работать не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1127 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>А дальше я писал про более общий случай, который возврат значения не подразумевает.
Передача предиката как критерия отбраковки/принятия очередного сообщения вряд ли может считаться более общим решением.
AVK>>>Пошли по кругу. ФИФО ставит крест на многих техниках оптимизации и балансинга, например на спекулятивных вычислениях или work stealing.
E>>Ну а конкретно, как ФИФО препятствует тому же work stealing?
AVK>Work stealing предполагает изменение порядка обработки сообщений. Т.е. ФИФО в локальной очереди конечно останется, но вот сама эта очередь может быть раздергана в другие очереди, отсюда и смысла в ФИФО становится ноль, все равно оно правильно работать не будет.
Если обработка сообщений агента может быть распараллелена, то нет никаких проблем с раздергиванием очереди. А если не может, то и никакого work stealing-а не будет в принципе.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Ты опять про "туда встали"? Это интимная подробность функционирования очереди. В случае одного отправителя можно говорить про очередность отправки. А смысл извлекать в другом порядке простой — благодаря отсутствию зависимостей, инфраструктура может оптимизировать передачу сообщений. К примеру, оба сообщения могут передаваться одновременно по двум независимым шинам, вместо того, чтобы дожидаться друг друга. И receive не будет тратить время на упорядочивание сообщений, порядок которых неважен. Зачем? Мы же стремимся к максимизации быстродействия, а ее главный лозунг — "если можешь — не делай!".
