Наверняка вы знакомы или даже работали с Simulink (или подобными инструментами). Симуляция там реализована как пошаговое вычисление состояния модели, т.е. на каждом шаге значения выходов блоков (состояние) с прошлого шага "передаётся" на входы блоков, затем все блоки вычисляются, в результате чего получаем состояния для следующей итерации (видео о блоках: https://www.youtube.com/watch?v=qoj8Pa2wi0A).
Идея в том, чтобы реализовать подобный инструмент, но построенный на асинхронном обмене сообщениями (на реактивных потоках в частности) вместо пошагового выселения состояния. Т.е. в целом это будет работать также: значения с выходов блоков будут передаватся на входы, но в виде посылки сообщений, а вычисления блоков будет выполнятся асинхронно.
Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию. Что вероятно позволит симулировать более сложные модели.
можно попинать мою скромную попытку реализовать это, и здесь почитать больше и посмотреть код.
Спасибо!
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Идея в том, чтобы реализовать подобный инструмент, но построенный на асинхронном обмене сообщениями (на реактивных потоках в частности) вместо пошагового выселения состояния. Т.е. в целом это будет работать также: значения с выходов блоков будут передаватся на входы, но в виде посылки сообщений, а вычисления блоков будет выполнятся асинхронно.
CAB>Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию. Что вероятно позволит симулировать более сложные модели.
CAB>Что думаете вы?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, C.A.B, Вы писали:
CAB>>...на реактивных потоках в частности...
I>Непонятно, чем это отличается от обычных акторов.
Образно можно представить что модель реактивных потоков накладывает некоторые ограничения на акторы. Больше можно узнать здесь.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
I>>Непонятно, чем это отличается от обычных акторов.
CAB>Образно можно представить что модель реактивных потоков накладывает некоторые ограничения на акторы. Больше можно узнать здесь.
Главная проблема акторов (да и взаимодействия на асинхронных сообщениях вообще) при обработке потоков данных -- это отсутствие механизма back-pressure. Но, если вы пишете про пошаговую симуляцию ("Симуляция там реализована как пошаговое вычисление состояния модели, т.е. на каждом шаге значения выходов блоков (состояние) с прошлого шага "передаётся" на входы блоков, затем все блоки вычисляются, в результате чего получаем состояния для следующей итерации"), то зачем здесь вообще нужен back-pressure? Ведь у вас следующий шаг не начнется, пока предыдущий не закончится.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, C.A.B, Вы писали:
CAB>>... Больше можно узнать здесь.
S>... то зачем здесь вообще нужен back-pressure? Ведь у вас следующий шаг не начнется, пока предыдущий не закончится.
Это в случае если все блоки (из которых построена модель) вычисляются синхронно (на каждом шаге вся симуляция ждёт пока все блоки будут вычислены).
Но идея в том, чтобы вычислять их асинхронно (каждый блок ждёт только те блоки от которых зависит), тут-то нам и пригодится back-pressure
К тому-же пошаговость не всегда нужна. Если к примеру, вы симулируете как-то логическую схему и можете пренебречь временем её работы то достаточно вычислять только отдельные её элементы (в которых происходят изменяя).
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Но идея в том, чтобы вычислять их асинхронно (каждый блок ждёт только те блоки от которых зависит), тут-то нам и пригодится back-pressure
Тогда это банально делается на CSP-каналах (вроде каналов в Go). Тут единственный фокус -- это так распределить блоки модели по рабочим потокам (сопрограммам), чтобы блок, который пишет в канал, не оказался заблокирован при переполнении канала, если блок-читатель из этого канала работает на том же потоке.
Здравствуйте, C.A.B, Вы писали:
I>>Непонятно, чем это отличается от обычных акторов.
CAB>Образно можно представить что модель реактивных потоков накладывает некоторые ограничения на акторы. Больше можно узнать здесь.
Я посмотрел
public class InfiniteIncrementNumberPublisher extends AsyncIterablePublisher<Integer> {
public InfiniteIncrementNumberPublisher(final Executor executor) {
super(new Iterable<Integer>() {
@Override public Iterator<Integer> iterator() {
return new Iterator<Integer>() {
private int at = 0;
@Override public boolean hasNext() { return true; }
@Override public Integer next() { return at++; } // Wraps around on overflow
@Override public void remove() { throw new UnsupportedOperationException(); }
};
}
}, executor);
}
}
Адъский адъ эта ваша джава, чисто блудняк, куда ни посмотри С таким уровнем абстракций до внятной асинхронной модели как до луны раком.
Столько мусора ради одной простой идеи:
@Override public Iterator<Integer> iterator() {
int i = 0;
while(true) {
yield i++;
}
}
Да это очень похоже на реактивные потоки, возможно с той разницей что концептуально здесь на «первом плане» каналы. Тогда как в РП это блоки «трансформирующие» поток сообщений, а каналы как «само собой разумеющееся».
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, C.A.B, Вы писали:
I> Адъский адъ эта ваша джава, чисто блудняк, куда ни посмотри С таким уровнем абстракций до внятной асинхронной модели как до луны раком.
Лучше смотреть как это выглядит на Scala
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>Идея в том, чтобы реализовать подобный инструмент, но построенный на асинхронном обмене сообщениями (на реактивных потоках в частности) вместо пошагового выселения состояния. Т.е. в целом это будет работать также: значения с выходов блоков будут передаватся на входы, но в виде посылки сообщений, а вычисления блоков будет выполнятся асинхронно.
CAB>Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию. Что вероятно позволит симулировать более сложные модели.
CAB>Что думаете вы?
Я думаю, что потоки и реактивное функциональное программирование идут отдельно, а распараллеливание и распределенность идут тоже отдельно. Они фактически мало связаны, даже ортогональны друг другу, но правильная организация позволяет их красиво интегрировать друг с другом для задач моделирования, прежде всего, дискретно-событийного моделирования
Здравствуйте, C.A.B, Вы писали:
CAB>Идея в том, чтобы реализовать подобный инструмент, но построенный на асинхронном обмене сообщениями (на реактивных потоках в частности) вместо пошагового выселения состояния. Т.е. в целом это будет работать также: значения с выходов блоков будут передаватся на входы, но в виде посылки сообщений, а вычисления блоков будет выполнятся асинхронно.
Такая схема хорошо работает только в случае однонаправленного распространения сигналов. В случае любой обратной связи процесс распространения сигнала грозит стать бесконечным. Причем, наивный трюк в остановкой распространения сигнала в случае, если новое вычисленное значение не отличается от старого, может не сработать в случае чисел с плавающей запятой — запросто можно получить бесконечный колебательный процесс даже в случае "сходящихся" колебаний сугубо из-за точности вычислений (получить бесконечные колебания на младших разрядах).
Тоже экспериментировал с этим не раз.
CAB>Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию.
"Пошаговое" исполнение легко можно распараллелить, т.е. вычислять новое значение каждого функционального узла независимо от остальных. Каждый блок в такой схеме — это триггер, который запоминает результат предыдущих вычислений и этот результат считается неизменным в течении "такта".
Ну и при пошаговом исполнении можно юзать такой параметр как "время", т.е., при эмуляции, например, простой RC-цепи dy интеграла по накапливаемому заряду будет зависеть от виртуальной "длительности" такта. Ну или можно брать реальную длительность такта (для обработки звука иногда балуюсь примерно тем же).
Здравствуйте, vdimas, Вы писали:
V>... В случае любой обратной связи процесс распространения сигнала грозит стать бесконечным...
Да, эффект имеет место быть. Но от этого не избавится в силу дискретной природы чисел с плавающей запятой и компьютеров в целом. Нужно искать компромисс между точностью, устойчивостью, скоростью и т.п. Это не серебряная пуля.
CAB>>Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию.
V>"Пошаговое" исполнение легко можно распараллелить, т.е. вычислять новое значение каждого функционального узла независимо от остальных...
В общем-то в этом и фишка Чтобы распараллелитьи и сделать вычисление асинхронным, на сколько это возможно.
К тому же пошаговая симуляция не всегда нужна, по крайней мере мне. В Scala я могу вынести это в отельный трайт и подключать по необходимости.
V>Ну и при пошаговом исполнении можно юзать такой параметр как "время"...
О, это самое интересное. Параметр "время" можно юзать и без пошагового вычиления! Нужно только следить за согласованностью этого параметра с остальными параметрами модели, в то время как вычисления могут асинхронными.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, so5team, Вы писали:
S>Главная проблема акторов (да и взаимодействия на асинхронных сообщениях вообще) при обработке потоков данных -- это отсутствие механизма back-pressure. Но, если вы пишете про пошаговую симуляцию ("Симуляция там реализована как пошаговое вычисление состояния модели, т.е. на каждом шаге значения выходов блоков (состояние) с прошлого шага "передаётся" на входы блоков, затем все блоки вычисляются, в результате чего получаем состояния для следующей итерации"), то зачем здесь вообще нужен back-pressure? Ведь у вас следующий шаг не начнется, пока предыдущий не закончится.
А что такое back-pressure в данном случае?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, C.A.B, Вы писали:
CAB>Идея в том, чтобы реализовать подобный инструмент, но построенный на асинхронном обмене сообщениями (на реактивных потоках в частности) вместо пошагового выселения состояния. Т.е. в целом это будет работать также: значения с выходов блоков будут передаватся на входы, но в виде посылки сообщений, а вычисления блоков будет выполнятся асинхронно.
CAB>Думаю, это даст возможность ускорить (через распараллеливание/распределение вычислений) симуляцию. Что вероятно позволит симулировать более сложные модели.
CAB>Что думаете вы?
Это одна из реализаций диаграммы потока данных. Более формальной (и правильной, на мой взгляд) реализацией является явное построение графа зависимостей. По нему уже можно делать разные реализации. Это может быть и реактивная схема (как предлагаешь ты), и прямая интерпретация графа зависимостей, и генерация кода.
Самым быстрым способом будет — генерация кода. Код, при этом, можно автоматически распараллеливать (ведь заранее известны все участки которые могут выполняться параллельно).
Проблемой всех таких решений будет то, что ты будешь распараллеливать и то, что не выгодно распараллеливать. Скажем глупо распараллеливать сложение двух числе, даже если оно делается 10 рез. Переключение контентов, ожидания и последующая синхронизация создадут куда большие непроизводительные затраты, чем получится выигрыш от распараллеливания.
Еще одна проблема — как получается схема. Если она получается статически, то генерация кода становится предпочтительной. Если динамически, то решения вроде реактивной модели будут более приемлемыми
Но в любом случае сначала лучше строить граф зависимостей.
По сути, реактивная модель — это один из вариантов его реализации. Причем довольно не эффетивный, так как узлы строятся в виде замыканий (функцональных).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, C.A.B, Вы писали:
V>>Ну и при пошаговом исполнении можно юзать такой параметр как "время"...
CAB>О, это самое интересное. Параметр "время" можно юзать и без пошагового вычиления! Нужно только следить за согласованностью этого параметра с остальными параметрами модели, в то время как вычисления могут асинхронными.
При распараллеливании и/или создании распределенной имитации модельное время — это самый главный фактор. Возникает так называемый "парадокс времени", когда время входящего сообщения может оказаться меньше текущего модельного времени. С этим нужно как-то бороться. Для этого существуют "консервативные" и "оптимистичные" алгоритмы. Тут целая теория развита. На эту тему есть хорошая книга "Parallel and Distributed Simulation Systems" за авторством Richard M. Fujimoto.
Но как я написал выше, это мало связано с функциональным программированием в том смысле, что все это прекрасно сочетается вместе. Например, мне это удалось сделать в своей Айвике: http://hackage.haskell.org/packages/search?terms=aivika. Там есть и упомянутые потоки, и элементы FRP, и монады, и продолжения, и распределенность с параллельностью. Я реализовал оптимистичную стратегию деформации времени с одним известным алгоритмом синхронизации глобального модельного времени между "локальными процессами" узлов распределенного кластера. В общем, можно запускать полноценные дискретно-событийные имитационные модели на суперкомпьютере.
И добро пожаловать в клуб любителей моделирования!
Здравствуйте, dsorokin, Вы писали:
D>...хорошая книга "Parallel and Distributed Simulation Systems" за авторством Richard M. Fujimoto.
D>...сделать в своей Айвике: http://hackage.haskell.org/packages/search?terms=aivika.
Мегакруть! Большое спасибо!
D>И добро пожаловать в клуб любителей моделирования!
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, VladD2, Вы писали:
VD>Самым быстрым способом будет — генерация кода...
И самый сложный в реализации. Не думаю что я буду трогать это в ближайшее время. Хотя идея интересная да и в Скале есть макросы для кодогенерации.
VD>Еще одна проблема — как получается схема. Если она получается статически, то генерация кода становится предпочтительной. Если динамически, то решения вроде реактивной модели будут более приемлемыми
Пока что статическая, но в планах сделать динамической.
VD>Но в любом случае сначала лучше строить граф зависимостей.
VD>По сути, реактивная модель — это один из вариантов его реализации. Причем довольно не эффетивный, так как узлы строятся в виде замыканий (функцональных).
Этого я честно говоря не понял. Но реактивные потоки построены на обмене сообщениями (без замыкания, насколько я знаю), когда одни узел (блок) шлёт сообщения другому узлу где они ставятся в очередь и затем обрабатываются в отдельном потоке (как в акторах). И относительно вопроса выше, back-pressure это алгоритм балансировки вычислений, предотвращающий переполнения очередей сообщений.
PS: Пользуясь случаем хочу передать привет вашей компании и тому чуваку который пилит плагин для Скалы. Спасибо вам за отличный инструмент, но блин не пора ли заняться его оптимизацией, я ещё могу жить с инспектором выводящем типы по 2-3 минуты, но подвисание UI при редактирования... WTF?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, C.A.B, Вы писали:
CAB>И самый сложный в реализации.
Зависит от опыта и используемого подхода.
CAB>Не думаю что я буду трогать это в ближайшее время.
Тебе решать. Я просто описал возможные подходы и их преимущества/недостатки. По скорости исполнения и минимальности утилизации ресурсов у генерации кода конкурентов нет. А нужно тебе или нет решай сам.
CAB>Хотя идея интересная да и в Скале есть макросы для кодогенерации.
Могу похвастаться тем, что они их появление было не без моего участия.
Несколько лет назад я предложил их автору модель приемлемую для Скалы. Рад, что он смог их реализовать.
CAB>Пока что статическая, но в планах сделать динамической.
Не стоит делать что-то без необходимости. Сложность увеличиться, а вот преимуществ может и не появиться.
VD>>По сути, реактивная модель — это один из вариантов его реализации. Причем довольно не эффетивный, так как узлы строятся в виде замыканий (функцональных).
CAB>Этого я честно говоря не понял.
Матмодель там одна. Граф зависимостей выражает ее явно. Реактивная модель неявно создает аналог графа зависимости. Но как и все не явное при этом появляются непроизводительные расходы.
CAB>Но реактивные потоки построены на обмене сообщениями (без замыкания, насколько я знаю),
Это в рекламных булшитах, может быть. А на практике в каком-нибудь RX-е или в Скале эта модель реализуется за счет функциональных замыканий. Практически вся обработка данных упирается в работу со списками. А реактивный список отличается от обычного тем, что из него тянут данные, вместо того, чтобы толкать их туда.
Ну, и что такое события в той же Скале? Это все те же функциональные типы и их вызовы.
Надо просто понимать, что один и тот же алгоритм будучи реализованным на низком уровне будет значительно эффективнее. Вот почему в Склае так тормозять обычные циклы? Да потому что реализованы через функциональные типы. Там в итоге получается замыкание которое и вызванивается для каждого элемента. Как не оптимизируй вызовы, но это не может сравниться с реальным циклом.
CAB>когда одни узел (блок) шлёт сообщения другому узлу где они ставятся в очередь и затем обрабатываются в отдельном потоке (как в акторах).
А ты задумывался, что означает "шлет сообщение" и "очередь"? Вот это ваше сообщение и есть вызов функционального объекта. При этом получаются косвенные вызовы и замыкания разных переменных. Все это создает кучу говна в памяти и является менее эффективным.
CAB>И относительно вопроса выше, back-pressure это алгоритм балансировки вычислений, предотвращающий переполнения очередей сообщений.
Ну, вот используя явный граф зависимостей очередей не будет в прицепи.
CAB>PS: Пользуясь случаем хочу передать привет вашей компании и тому чуваку который пилит плагин для Скалы.
Я в этой "конторе" уже год как не работаю. Но ребята от туда этот форум читают, думаю.
CAB>Спасибо вам за отличный инструмент, но блин не пора ли заняться его оптимизацией, я ещё могу жить с инспектором выводящем типы по 2-3 минуты, но подвисание UI при редактирования... WTF?
Насколько я знаю плагин для Салы пишется по остаточному принципу. Вот плагин к Котлину — другое дело. Да и язык этот более IDE-пригодный. Так что возможно стоит не него посмотреть. Хотя Скале он, конечно, сильно проигрывает (для опытного пользователя).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>По сути, реактивная модель — это один из вариантов его реализации. Причем довольно не эффетивный, так как узлы строятся в виде замыканий (функцональных).
Другие способы нисколько не лучше.
Особенно прикалывает неэффективная и крайне наивная реализация имитации через системные нативные или зеленые потоки (нити). Вроде бы гонятся за эффективностью, а как в дело вступают ресурсы, то тут сразу возникают системные блокировки, и все, полный абзац. Да и неточный ужасно метод, который сильно зависит от системного планировщика. Да еще и масштабировать модельное время надо. Ну, нафиг такое счастье!
На Си++ еще пытаются использовать со-программы (OMNeT++), играя с системным стеком, а чем это лучше монад и продолжений? Вопрос крайне неоднозначный.
Тут тема такая, что нет явного победителя. Как ни реализуй, везде где-то проигрываем, где-то выигрываем. Да и нынче на питончике во всю моделируют (SimPy), а там с эффективностью выполнения, вообще, не очень.
Здравствуйте, VladD2, Вы писали:
VD>А что такое back-pressure в данном случае?
Остановка поставщика если получатель не успевает обрабатывать сообщения.
Самый простой вариант ограничить размер очереди сообщений и при достижении порога блокировать добавление сообщения пока из очереди старое не заберут.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Адъский адъ эта ваша джава, чисто блудняк, куда ни посмотри 
С таким уровнем абстракций до внятной асинхронной модели как до луны раком.
