Здравствуйте, Didro, Вы писали:
I>>пока (В свете использования TraceMode) больше нравится этот путь. но... зависит от уточнений см.выше D>Если можно поподробнее, что за TraceMode? В смысле пошаговое исполнение? и почему в его свете нравится 3-ий вариант...
См. здесь
D>Мне последний вариант нравится по причине того что, на структурном и динамическом уровне модель при такой реализации будет похожа на реальную систему(т.е. звенья будут функционировать параллельно), что на мой взгляд облегчает построение\проектирование системы. Возможно я ошибаюсь — реального опыта мало.
TraceMode какраз реальными системами и управляет
... << RSDN@Home 1.2.0 alpha rev. 676>>
Re[4]: Число и тип потоков в системе моделирования
Здравствуйте, ironwit, Вы писали:
I>>>кажется книга примерно о том...
G>>Вообще ничего общего. Это линейная теория управления. К моделированию и предмету обсуждения никак не относится. I>тады извините
Да лана, тож прикольная тема . Системы линейных диффуров, построение обратной связи (управления), критерий управляемости Калмана (отличная фамилия; "я русский бы выучил только за то..."), построение системы наблюдателя — что может быть прекраснее?
архитекторы предпочли не отвечать на мой вопрос, видимо тому есть свои причины. честно выждав, пока сообщение спустят в конец списка, решился написать сюда.
p.s. опыта в проектировании таких систем мало, поэтому если пишу полную бредятину, не имеющую к практике никакого положительного отношения, дайте знать, пожалуйста
__
Известно, что
при моделировании отражают два аспекта моделируемого объекта — структурный и динамический.
при структурном моделировании применяют "черных ящиков" и принимают решение о размерах каждого ящика и связях между ними.
при моделировании динамического аспекта можно выделить 2 подхода:
Математическое моделирование — когда и структура и динамика системы моделируются математически;
Моделирование, при котором структура и динамика системы моделирования в большей степени аналогична самой системе.
Пример: Моделирование потока газа: можно описывать связь между входными и выходными сигналами системы на основе диф.уравнений(1-ый подход), а можно моделировать каждую частичку газа с помощью конечного автомата, объединенного в сеть(что и делается с помощью мелкозернистого параллелизма).
Реальные примеры первого подхода думаю всем известны, а второго есть тут, тут и тут
Таким образом, на вопрос о степени аналогичности(похожести) моделируемой системы и моделирующей не возможно дать ответ, не зная целей моделирования. Тем не менее, мне кажется, что время отклика системы и модели должны всё-таки быть сопоставимы и когда мне приходится ждать результатов моделирования по 2 часа, а потом, немного подправив какой-то параметр модели ждать ещё 2 часа, то это плохо. Причём зависит это не только от мощности аппаратуры, но и от реализации самой модели. Согласны?
Теперь собственно проблема, которую я решаю и которая натолкнула меня на мысли, изложенные вверху.
Необходимо создать систему моделирования САУ(т.е. моделировать системы авт. управления). Затрудняюсь в выборе числа потоков в системе и механизма реализации этих потоков.
Под потоком имею в виду — различные реализации потоков управления — OS threads или fibers или lightweight process ala Erlang или самодельная кооперативная многозадачность(как, например, здесь).
Очевидно, что число потоков и механизм их реализации взаимоувязаны.
Варианты: 1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.)
Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads?
Пока что изучаю опыт зарубежных коллег, хотел бы услышать Ваше мнение. На RSDN-е по теме нашёл только это
Здравствуйте, Didro, Вы писали:
D>Необходимо создать систему моделирования САУ(т.е. моделировать системы авт. управления). Затрудняюсь в выборе числа потоков в системе и механизма реализации этих потоков.
про выделенное хотелось бы больше услышать...
D>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads? D>[/list]
пока (В свете использования TraceMode) больше нравится этот путь. но... зависит от уточнений см.выше
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[2]: Число и тип потоков в системе моделирования
Здравствуйте, Didro, Вы писали:
D>Таким образом, на вопрос о степени аналогичности(похожести) моделируемой системы и моделирующей не возможно дать ответ, не зная целей моделирования. Тем не менее, мне кажется, что время отклика системы и модели должны всё-таки быть сопоставимы и когда мне приходится ждать результатов моделирования по 2 часа, а потом, немного подправив какой-то параметр модели ждать ещё 2 часа, то это плохо. Причём зависит это не только от мощности аппаратуры, но и от реализации самой модели. Согласны?
От числа потоков время ожидания никак не зависит , если, конечно, программа даёт возможность завершить процесс досрочно и потоков не слишком много.
Время отклика самой системы и её модели никак друг с другом не связаны и полностью зависят от реализации модели и системы.
D>Варианты: D> D>1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.) D>Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
D>1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
D>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads? D>
Ты забыл ещё вариант: GUI thread + work thread => на каждую систему уравнений по количеству потоков, соотв. доступному числу ядер. Т.е. параллелизм на уровне решения систем уравнений, а не на уровне каких-то ящичков...
Дык что тебе надо???
Если ты хочешь менять в модели коэффициенты прямо по ходу рассчёта, то зачем тебе 2-х часовой расчёт??? Наверное, дело в чём-то другом? Может, просто тебе нужно прекратить расчёт, запомнить состояние системы и начать следующий расчёт с изменёнными параметрами из этого начального состояния? И сколько потоков будет в программе совершенно не важно тогда. Если, конечно, у тебя однопроцессорная машина с одноядерным процессором
Представляешь себе по второму варианту... это что же, мне на каждый шаг нужно задавать параметры??? Зачем??? А если мне это не нужно, я буду сидеть и долбить одни и те же числа??? Или что? Как интерактивность связана с количеством потоков??? Достаточно прервать рассчёт и изменить параметры
И что будет в 3-ем варианте??? Потоки будут постоянно друг друга ждать, ведь они должны активно обмениваться информацией. Лишние ресурсы... хотя, конечно, на многопроцессорной машине может быть что-нибудь и получится... только как ты будешь останавливать процесс и менять параметры??? Ведь у тебя каждая часть системы будет находится в рассинхронизированом состоянии с другими частями системы (один ящик уже досчитает до n-ого шага, а другой будет отставать от него на шаг, третий — на два и т.п.). Но как связана многопоточность с изменяемыми параметрами я не понял
Re[2]: Число и тип потоков в системе моделирования
Здравствуйте, ironwit, Вы писали:
D>>Необходимо создать систему моделирования САУ(т.е. моделировать системы авт. управления). Затрудняюсь в выборе числа потоков в системе и механизма реализации этих потоков. I>про выделенное хотелось бы больше услышать...
Задача реальная, т.е. не курсовая работа и т.п.) Но система моделирования будет использоваться в учебном процессе(в ВУЗе). Ранее использовали систему, разработанную под DOS. В ней был простенький граф.редактор для соединения заранее заданных звеньев системы в структурную схему. После чего запускался процесс моделирования в заданном временном диапазоне, результатом которого были графики выходных характеристик выбранных звеньев, вывод ЛЧХ и возможность оптимизации системы по выходному сигналу.
В новой системе ожидается примерное повторение функциональности с реализацией под Windows. На реализацию дано 3 мес, 2 человека. Однако мне бы хотелось(как вообщем-то обычно и бывает ) добавить нечто новое, во-первых, интересное для студентов, во-вторых, полезное в плане собственного развития. Например, добавить случайные процессы или моделирование релейных звеньев или адаптивных систем.(может ещё чего интересного подскажете?)
D>>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads? D>>[/list]
I>пока (В свете использования TraceMode) больше нравится этот путь. но... зависит от уточнений см.выше
Если можно поподробнее, что за TraceMode? В смысле пошаговое исполнение? и почему в его свете нравится 3-ий вариант...
Мне последний вариант нравится по причине того что, на структурном и динамическом уровне модель при такой реализации будет похожа на реальную систему(т.е. звенья будут функционировать параллельно), что на мой взгляд облегчает построение\проектирование системы. Возможно я ошибаюсь — реального опыта мало.
Re[3]: Число и тип потоков в системе моделирования
Здравствуйте, FDSC, Вы писали:
D>>Причём зависит это не только от мощности аппаратуры, но и от реализации самой модели. Согласны?
FDS>Время отклика самой системы и её модели никак друг с другом не связаны и полностью зависят от реализации модели и системы.
Согласен.
D>>Варианты:
[скип] FDS>Ты забыл ещё вариант: GUI thread + work thread => на каждую систему уравнений по количеству потоков, соотв. доступному числу ядер. Т.е. параллелизм на уровне решения систем уравнений, а не на уровне каких-то ящичков...
Да, действительно. Правда мне почему-то удобнее думать в терминах ящиков, поведение которых описывается этими самыми уравнениями.
FDS>Дык что тебе надо???
Подробно о задании см. выше
.
FDS>Если ты хочешь менять в модели коэффициенты прямо по ходу рассчёта, то зачем тебе 2-х часовой расчёт??? Наверное, дело в чём-то другом?
Да, 2-х часовой расчёт это не про меня(это был пример ).
FDS>Может, просто тебе нужно прекратить расчёт, запомнить состояние системы и начать следующий расчёт с изменёнными параметрами из этого начального состояния? И сколько потоков будет в программе совершенно не важно тогда. Если, конечно, у тебя однопроцессорная машина с одноядерным процессором
Это по сути дело и есть второй вариант, я не имел ввиду, что параметры системы обязательно должны быть введены заново на каждом шаге. Пользователь может их просто обновить в любой момента(в GUI-thread'e), на следующем шаге система сама их считает(если обновлять параметры не нужно — оставляем старые значения, система считает их).
FDS>Представляешь себе по второму варианту... это что же, мне на каждый шаг нужно задавать параметры??? Зачем??? А если мне это не нужно, я буду сидеть и долбить одни и те же числа??? Или что? Как интерактивность связана с количеством потоков??? Достаточно прервать рассчёт и изменить параметры
Объяснил в этом же посте,выше.
FDS>И что будет в 3-ем варианте??? Потоки будут постоянно друг друга ждать, ведь они должны активно обмениваться информацией. Лишние ресурсы... хотя, конечно, на многопроцессорной машине может быть что-нибудь и получится... только как ты будешь останавливать процесс и менять параметры??? Ведь у тебя каждая часть системы будет находится в рассинхронизированом состоянии с другими частями системы (один ящик уже досчитает до n-ого шага, а другой будет отставать от него на шаг, третий — на два и т.п.). Но как связана многопоточность с изменяемыми параметрами я не понял
В 3-ем варианте всё будет плохо, если использовать при реализации OS-threads, тогда да — будет недетерминизм, проблемы с синхронизацией, с доступом к данным. Но ведь можно:
а) Использовать легковесные потоки(нпр. как в Erlang или Stackless Python) с высокоуровневыми средствами синхронизации — потери в ресурсах практически никакой не будет(ибо не будет переключений контекста, поскольку легковесные потоки запускаются в одном потоке ОС).
б) использовать потоки ОС, но не работать с ними напрямую — либо написать DSL(нпр. в Nemerle), либо использовать средства готового языка — MC#, A#\Ada, Scala ...
Преимущества варианта №3 мне самому не очевидны(свою куцоватую причину я изложил выше, здесь
Замечу, что в третьем случае (поток на объект) выигрыш в скорости
моделирования будет только если а) количество процессоров в системе
примерно равно количеству потоков и б) потоки редко обмениваются данными
(период обмена на 2-3 порядка времени переключения контекста потока). Иначе
накладные расходы сожрут весь выигрыш.
Иначе говоря, если моделируемая система содержит >5 звеньев или каждое звено
имеет передаточную функцию, которая описывается <100 команд плавающей
арифметики (арифметика, тригонометрия, логарифмы) -- нет смысла плодить
потоки. _Для параллельных вычислений нужны параллелизуемые алгоритмы._
(Разумеется, все цифры оценочные, из общих соображений и интуиции).
Разумеется, строить такие модели на функциональных языках -- одно
удовольствие. Но вот обеспечат ли "ленивые вычисления" хорошую
производительность?
Кое-что в формулировке задачи осталось неясным:
> Тем не менее, мне кажется, что время отклика системы и модели должны
всё-таки быть сопоставимы и когда мне приходится ждать результатов
моделирования по 2 часа, а потом, немного подправив какой-то параметр
модели ждать ещё 2 часа, то это плохо. Причём зависит это не только от
мощности аппаратуры, но и от реализации самой модели. Согласны?
Представьте, что мы моделируем гармонический осциллятор. Предположим, с
точностью 1000 отсчетов на период. Пусть расчет одного периода занимает 10
миллисекунд. Это "время отклика модели". Теперь рассмотрим систему -- Г.О.
с собственной частотой 1 Гц. "Время отклика системы" (один период) будет 1
секунда. А при собственной частоте 10 ГГц? Я понимаю, что у Вас какая-то
конкретная система, конкретная модель и конкретный компьютер. Но и вопрос
надо формулировать более конкретно
> цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам
входного сигнала — нарисовали выходные графики, таблицы и т.д.) > Большой минус — резко падает интерактивность системы, если процесс
вычислений затягивается. Пользователь может захотеть увидеть промежуточные
результатыю...
Обычно в таких случаях после каждой итерации (обработки отсчета) рабочий
поток отправляет сигнал UI, а то рисует все, что нужно. И работу можно
прервать в любой момент
> Work thread (который по-тактово , на каждом шаге моделирования
считывает текущие параметры звеньев САУ(которые задаются пользователем в
UI-thread) и прогоняет текущую группу отсчётов входного сигнала через
звенья)
Не понял. Вот есть у нас ФНЧ с частотой среза 1 кГц. Мы прогнали через него
первые 100 отсчетов, получили 100 отсчетов на выходе. Затем поменяли
частоту среза, установили 5 кГц, и прогнали следующие 100 отсчетов. Каков
будет смысл выходного сигнала в целом, всех 200 отсчетов? Все равно ведь
нужно сначала пересчитывать?
Posted via RSDN NNTP Server 2.0
Re[3]: Число и тип потоков в системе моделирования
Здравствуйте, Didro, Вы писали:
D>Здравствуйте, ironwit, Вы писали:
D>>>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads? D>>>[/list]
I>>пока (В свете использования TraceMode) больше нравится этот путь. но... зависит от уточнений см.выше D>Если можно поподробнее, что за TraceMode? В смысле пошаговое исполнение? и почему в его свете нравится 3-ий вариант...
tracemode это СКАДА. дальше гугль почитай. просто я с ней близко более менее работаю и в ней мне нравится как сделан обсчет ее логических и физических каналов. там примерно сделано так (Как мне показалось) по потоку на отдельную логическую часть. GUI совершенно независимо от расчетов.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[2]: Число и тип потоков в системе моделирования
Здравствуйте, Didro, Вы писали:
D>Варианты: D> D>1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.) D>Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
D>1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
D>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads? D>
Пропустил вариант. Можно подойти к этому вопросу гибко.
Я так понял, у тебя время дискретное, а система тактирована. Допустим также, ты применяешь классический ОО язык. Тогда
1) Структуру системы задаешь в виде дерева объектов — оно натурально отрадает декомпозицию системы на блоки. У объектов уровня будет основной метод — "пересчитать такт", в котором он забирает данные со входов и обновляет выходы.
2) Тактовую частоту спускаешь по дереву вниз, рекурсивно. При этом, ты можешь оставить себе возможность гибко менять тактовую частоту для фрагментов системы (например — поддерево работает втрое быстрее).
3) Объекты также связаны горизонтальными связями — по ним пойдут потоки данных. Здесь удобна схема множественной подписки на именованные выходы блока. Как ты ее реализуешь — по большому счету неважно.
4) По тактовому сигналу объекты обмениваются сигналами по связям и пересчитывают состояние. Процесс пересчета блоков независим, и эелементарно параллелится. Локальность вычислений тоже выделяется простым и натуральным образом — поддерево обладает локальностью. Таким образом, тебе неважно, каким количеством физических потоков выполнять пересчет. Замечу — файберы тебе при таком подходе не нужны. Просто ну совсем не вперлись. И вообще — при написании модели программист не видит никаких потоков, он задает только структуру системы и реакцию на тактовые сигналы — причем, все достаточно декларативно.
К нас на этих принципах построен фреймворк моделирования на Erlang. Аналогичным образом можно сделать в любом языке.
Re[2]: Число и тип потоков в системе моделирования
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, ironwit, Вы писали:
I>>может поможет
I>>http://all-ebooks.com/index.php?m=book&id=2305
I>>кажется книга примерно о том...
G>Вообще ничего общего. Это линейная теория управления. К моделированию и предмету обсуждения никак не относится.
тады извините
... << RSDN@Home 1.2.0 alpha rev. 0>>
Я не умею быть злым, и не хочу быть добрым.
Re[3]: Число и тип потоков в системе моделирования
G>Вообще ничего общего. Это линейная теория управления. К моделированию и предмету обсуждения никак не относится.
Это еще почему?
В учебном пособии представлены базовые положения современной теории линейных систем управления и основного аппарата теории — метода пространства состояний. Значительное внимание уделяется моделям динамических систем: представлены традиционные методы описания и модели с использованием переменных состояния.
Давно это было, но в одной курсовой я моделировал именно САУ именно методом пространства состояний.
Re[3]: Число и тип потоков в системе моделирования
Здравствуйте, TheBeard, Вы писали:
TB>Замечу, что в третьем случае (поток на объект) выигрыш в скорости TB>моделирования будет только если а) количество процессоров в системе TB>примерно равно количеству потоков и б) потоки редко обмениваются данными TB>(период обмена на 2-3 порядка времени переключения контекста потока). Иначе TB>накладные расходы сожрут весь выигрыш.
Да, безусловно, я понимаю, что если мы работаем на 1 ядерной\1 процессорной машине с несколькими потоками, то о выигрыше в скорости мы не говорим. Я и не говорю .
Потоки, однако, могут быть использованы не только для повышения реального быстродействия системы(т.е. нпр, не только для распараллеливания алгоритмов по данным), но и для повышения интерактивности приложения(и в частотности снижения времени отклика). Точнее говоря, для повышения степени интерактивности взаимодействия приложения с внешней средой, в частности с пользователем или с другим компьютером в сети(нпр — nonblocking IO,легко реализуемый в Erlang
). Классический пример — разделение на GUI thread и work thread, при этом в самом простом случае будет хотя бы выполняться параллельная с работой work-thread перерисовка элементов интерфейса.
TB>Иначе говоря, если моделируемая система содержит >5 звеньев или каждое звено TB>имеет передаточную функцию, которая описывается <100 команд плавающей TB>арифметики -- нет смысла плодить потоки. _Для параллельных вычислений нужны параллелизуемые алгоритмы._ TB>Разумеется, строить такие модели на функциональных языках -- одно TB>удовольствие. Но вот обеспечат ли "ленивые вычисления" хорошую TB>производительность?
К сожалению мало опыта у меня в ФП, с ленивостью знаком, но при моделировании не применял, надеюсь, что пока.
[про осциллятор и возрастающее время отклика]
Пример хороший, спасибо. Разумеется, я не имел в виду, что модельное время должно обязательно совпадать с реальным(системным). Говоря об сопоставимости времён отклика я этого, правда, не учёл...
D>Work thread (который по-тактово , на каждом шаге моделирования D>cчитывает текущие параметры звеньев САУ(которые задаются пользователем в D>UI-thread) и прогоняет текущую группу отсчётов входного сигнала через D>звенья)
TB>Не понял. Вот есть у нас ФНЧ с частотой среза 1 кГц. Мы прогнали через него TB>первые 100 отсчетов, получили 100 отсчетов на выходе. Затем поменяли TB>частоту среза, установили 5 кГц, и прогнали следующие 100 отсчетов. Каков TB>будет смысл выходного сигнала в целом, всех 200 отсчетов? Все равно ведь TB>нужно сначала пересчитывать?
Во-первых, не стоит использовать ровно 200 отчётов, я планировал не ограничивать длину входного сигнала, поэтому если пользователь поменять частоту среза, то он получит ФНЧ с новыми параметрами и сможет продолжить моделирование(однако поскольку ФНЧ будет одним из звеньев системы, а входной сигнал может быть нестационарным, то возможно пользователю придётся пересчитать заново, чтоб восстановить первоначальные условия для всей системы — это видимо принципиальная проблема). Кроме того, хотелось бы, чтобы пользователь, меняя параметры, плавно мог наблюдать постепенное изменение выходного сигнала(устраивая, таким образом, переходный процесс )
Re[2]: Число и тип потоков в системе моделирования
Здравствуйте, palm mute, Вы писали:
G>>Вообще ничего общего. Это линейная теория управления. К моделированию и предмету обсуждения никак не относится. PM>Это еще почему?
Хотя, к количеству потоков книга таки действительно не имеет отношения, сорри.
Re[3]: Число и тип потоков в системе моделирования
Здравствуйте, Gaperton, Вы писали:
D>>Варианты:
[skip] G>Пропустил вариант. Можно подойти к этому вопросу гибко.
G>Я так понял, у тебя время дискретное, а система тактирована. Допустим также, ты применяешь классический ОО язык. Тогда G>1) Структуру системы задаешь в виде дерева объектов — оно натурально отрадает декомпозицию системы на блоки. У объектов уровня будет основной метод — "пересчитать такт", в котором он забирает данные со входов и обновляет выходы. G>2) Тактовую частоту спускаешь по дереву вниз, рекурсивно. При этом, ты можешь оставить себе возможность гибко менять тактовую частоту для фрагментов системы (например — поддерево работает втрое быстрее). G>3) Объекты также связаны горизонтальными связями — по ним пойдут потоки данных. Здесь удобна схема множественной подписки на именованные выходы блока. Как ты ее реализуешь — по большому счету неважно.
Про похожую систему я сейчас читаю в описании проекта Ptolemy. Они тоже используют модели на основе графов(называют их Cluster graphs). Под кластеризованностью насколько, я понял, они имеют в виду возможность локализации подмножества связанных объектов графа и эти кластера используют для реализации блокировок при доступе к объектам из потоков.
Вот пример кода от туда —
public class C extends NamedObj {
public void foo() {
synchronized(workspace()) {
...
}
}
}
где workspace() возвращает ссылку на кластер(можество объектов), к которому принадлежит данный объект. Наверняка они используют их ещё для чего-ниубдь, пока только про это прочитал...
G>4) По тактовому сигналу объекты обмениваются сигналами по связям и пересчитывают состояние. Процесс пересчета блоков независим, и эелементарно параллелится. Локальность вычислений тоже выделяется простым и натуральным образом — поддерево обладает локальностью. Таким образом, тебе неважно, каким количеством физических потоков выполнять пересчет. Замечу — файберы тебе при таком подходе не нужны. Просто ну совсем не вперлись. И вообще — при написании модели программист не видит никаких потоков, он задает только структуру системы и реакцию на тактовые сигналы — причем, все достаточно декларативно.
Спасибо, знатный абзац , особенно понравилось о независимости от числа потоков, а то я слишком увяз в них сейчас. О том же пишут в Ptolemy, но когда читал не очень понял о чём они говорят.
Т.е. можно резюмировать, что потоки в системах моделирования могут применяться в следующих случаях:
Использование вычислительного потенциала аппаратуры за счёт масштабирования приложения на несколько ядер\несколько машин. Т.е. увелечение быстродействия.
Повышение интерактивности GUI. _ Если моделируемая система предполагает разбиение на параллельно функционирующие объекты, то и модель должна отразить сей факт. При этом при реализации разумно использовать потоки, а вот их тип и число непосредственно не ограничены классом\природой моделируемой системы и лучше, чтоб система моделирования инкапсулировала способ реализации параллелизама моделируемых объектов в себе.(т.е. по сути переписанный абзац выше)
Думаю, опять же тремя вариантами дело не ограничится, просто хотелось закрепить мыслю.)
Re[2]: Число и тип потоков в системе моделирования
D>Варианты: D>1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.) D>Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
D>1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
Мой опыт основан на временах, когда только-токлько появились P-III. САР Смита (модифицированная). Основное процессорное время уходило на обсчет модели объекта управления, который распараллелить было достаточно проблематично. Распараллеливание вычислений на остальные звенья практически не давало прироста производительности (точно не замерял, но может 3-5%), за то очень усложняло систему в целом. Т.о., сейчас я бы остановился на варианте 1 UI + 1 work. Обновление интерфейса по запросу UI-потока. При чем, не обязательно на каждом такте моделирования. Т.е. work-поток обсчитывает данные и сохраняет их в какой-либо буфер, а UI-поток, через какие-либо промежутки времени просто забирает буфер и отрисовывает то, что требуется. ИМХО.
Re: Re:Число и тип потоков в системе моделирования
D>1 UI-thread + 1 Work thread (который полностью за один "прогон" обсчитывает систему: т.е. предполагается цикл — нажали кнопку — провели все необходимые вычисления по всем отсчётам входного сигнала — нарисовали выходные графики, таблицы и т.д.) D>Большой минус — резко падает интерактивность системы, если процесс вычислений затягивается. Пользователь может захотеть увидеть промежуточные результаты и самостоятельно подкорректировать систему в процессе её работы. Т.е. это плохой подход.
D>1 UI-thread + 1 Work thread (который по-тактово , на каждом шаге моделирования считывает текущие параметры звеньев САУ(которые задаются пользователем в UI-thread) и прогоняет текущую группу отсчётов входного сигнала через звенья). Это, на мой взгляд, промежуточный, компромиссный подход.
D>Many threads — т.е. по сути, концепция Active Object — каждому звену(моделируемому объекту) выделяем поток. Имеет ли смысл в данном случае использовать lightweight потоки и высокоуровневые средства синхронизации(взаимодействие через сообщения)) ? Или оставаться в рамках OS-threads?
У 3-го варианта есть один подводный камешек, который в результате сведёт его ко второму варианту. Это синхронизация процесса моделирования. Т.к. потоки работают не одинаковое время, либо за одинаковое время выполняют разный объём работ, то, чтобы обеспечить синхронную работу моделируемых объектов, придётся где-то вставлять временные точки, которые бы давали возможность убежавшим вперёд потокам ожидать отстающих. В результате алгоритм так или иначе придётся адаптировать для пошаговой работы. В результате получится второй вариант.
У второго варианта есть ещё одно преимущество. Если данные используемые моделью можно каким-то образом снять и сохранить на диске, то всегда можно будет начать работу с такого сохранённого места. Т.е. для отладки модели не надо будет ждать каждый раз 2 часа.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
, если, конечно, программа даёт возможность завершить процесс досрочно и потоков не слишком много.
Если нам не помогут, то мы тоже никого не пощадим.
