А, кстати, я начинаю понимать уважаемого @lws0954 , вот смотрите. допустим есть вот такая диаграмма, здесь симуляция идёт с шагом 1, рампа входная тоже с шагом 1, результат на выходе - шесть значений 0, 2, 8, 22, 52 и 114. На каждом шаге считается a[i+1] = (a[i] + i) * 2; Начальное а[0] = 0 разумеется:
Но беда в том, что сначала выполняется сложение, а потом умножение и никак иначе. И вот теперь я отчаянно возжелал выполнять умножение и сложение параллельно. Чтобы развязать эти операции я вкорячу вторую задержку (как выше было показано это таки даст возможность распараллелить эти операции). Но при единичном шаге результат сильно неверный. Но теперь я буду сильно уменьшать шаг симуляции, который в пределе стремится к нулю, я поставил 1E-5 и соответственно я буду уменьшать степень усиления, ну и шаг рампы тоже ну очень маленький, я эмпирически подогнал 5.5E-5 и вот смотрите, вуаля, я практически вписался в референсные точки:
То есть мы приходим к тому, что при бесконечно малом шаге симуляции все математические операции таки можно выполнять параллельно. Пора открывать новую страницу в математике.Хотя в данном конкретном случае простая полиномиальная интерполяция вероятно сразу даст ответ в любой точке, ну да ладно.
У вас меандр от -0.1 до 0.1, а у коллеги lws0954 от 0,5 до 1,5, вот и весь ответ.
Ещё вопросик, чтоб два раза не вставать — а можно разделить десятичный где-то подкрутить или брать его из системных настроек винды? Он в Германии не точка, а запятая и я всё время ошибаюсь:
Про С++. С++ не параллельный язык. "Степень его параллелизма" ;) - обсолютный ноль. Он обычный последовательный язык (см. три вопроса)
Чтобы он стал параллельным я его расширил понятиями активных объектов, имеющих автоматное управление (в моих примерах на С++ это базовый класс LFsaAppl). И затем создал ядро и среду ВКПа, которое эти объекты уже реально делают их активными...
Все. Буквально два щелчка и реальный параллелизм вот он! ;)
На самом деле я с вами согласен. С++ не параллельный язык. Но у меня другой критерий параллельности. Смотрите, еслия я возьму два абсолютно независимых цикла
for (int i = 0; i < N; i++){
x = x + i;
}
for (int j = 0; j < M; j++){
y = y * j;
}
То по умолчанию компилятор выдаст код, выполняющий их последовательно, хотя им абсолютно ничто не мешает выполняться параллельно. А в LabVIEW они автоматом будут исполняться параллельно (до 24 штук, кстати). Чтобы добиться параллельности в С++ мне придётся выполнить пару телодвижений, несложных, но всё же.
Тоже самое и здесь:
for (int i = 0; i < N; i++){
x = x + i;
y = y * i;
}
Этим двум операторам ничто не мешает распараллелиться, но нет.
Однако если идёт зависимость по данным (выключим на время оптимизатор), скажем
for (int i = 0; i < N; i++){
x = x + i;
y = x * 2;
}
То о параллельности мы не говорим.
Комментом ниже вы показали какой результат ВКПа вы считаете правильным с точки зрения параллельного программирования на примере вычисления тривиального выражения "в два щелчка"
a[i + 1] = (a[i] + i) * 2;
И мне в общем всё стало ясно. Также мне стало понятно почему вы считаете "правильную" реализацию триггера мерой степени "параллельности".
Ниже - схема, эквивалентная ВКПа. И - о, чудо! - график точь в точь такой, как и в ВКПа.
УРА! Глядя на ваш результат 0, 0, 2, 4, 10, 16 я, кажется понял глубоко сакральный смысл ПАРАЛЛЕЛьНОСТИ ВКПа!
Судя по всему, в вашем параллельном мире вы пытаетесь выполнить сложение и умножение параллельно. Но поскольку они зависимы по данным, вам приходится вкорячивать вторую задержку, чтобы иметь возможность начать умножение не дожидаясь результата сложения.
Я тоже так могу, это две диаграммы одинаковы, просто чтоб понятнее было, и вот откуда берутся ваши 0, 0, 2, 4, 10, 16:
И да, тут код выполняется параллельно, только результат не очень.
Если всё ещё не понятно, то вот эквивалент на Си, в предположении что наш Си умеет исполнять параллельно операторы, расположенные на одной строчке:
#include <ansi_c.h>
int main (int argc, char *argv[])
{
int mul = 0;
int add = 0;
for (int i = 0; i < 6; i++){
#pragma parallel
int add_out = (mul + i); int mul_out = (add * 2);
printf ("Result is %d at cycle %d\n", mul_out, i);
mul = mul_out; add = add_out;
}
return 0;
}
И результат тот же:
Result is 0 at cycle 0
Result is 0 at cycle 1
Result is 2 at cycle 2
Result is 4 at cycle 3
Result is 10 at cycle 4
Result is 16 at cycle 5
Более того, я могу разнести умножение и сложение в два отдельных цикла и они будучи независимымы, вполне себе буду бежать параллельно с тем же результатом:
Вот только в реальном мире мы зависимы по данным. Умножению нужен результат сложения, а сложению - результат умножения, поэтому я не имею права вставлять в очередь элемент для умножения, мне нельзя начинать его, не дождавшись результат сложения! Так что вот вам "правильная" параллельность:
Да только нет её тут, потому что автомат выполняющий умножение ждёт результата автомата, выполняющего сложение.
Эх, а у нас корпоративным полиси телеграм запретили. Заблокировать его не могут (хотя звонки не проходят), но большой брат следит и при использовании прилетает вежливое письмо счастья с просьбой убрать, а иначе его уберут через удалённый доступ. А жаль, удобная штука. А так MS Teams используется. Дело в филиале американской компании в Германии происходит.
Да, результат из LabView (см. выше) 0, 2 ,8, 22: что-то, похоже, не вкорячивается... :( Как это?
Вот так:
int main (int argc, char *argv[])
{
int shift_reg = 0;
for (int i = 0; i < 4; i++){
int out = (shift_reg + i) * 2;
printf ("Result is %d at cycle %d\n", out, i);
shift_reg = out;
}
return 0;
}
И вот:
Result is 0 at cycle 0
Result is 2 at cycle 1
Result is 8 at cycle 2
Result is 22 at cycle 3
Я не знаю, как ещё проще эту конструкцию объяснить
Да в общем ничего особенного, там четыре скорости есть (я иконки блоков у вас утащил чтоб аутентичненько было):
Я обычно подсветкой выполнения пользуюсь тогда, когда влетев в какой-нибудь блок всё встаёт колом, и тогда подсветка может мне показать, где я вообще в коде нахожусь. Ну или что-то совсем несложное отладить или просто выполнение замедлить.
А, да, и результаты:
Вот LabVIEW:
А вот Simulation In Technic:
Ну в общем было бы странно, если бы они принципиально отличались.
Стрелочек на проводникак в LabVIEW нет, они появляются лишь тогда, когда поток данных разбит и вызывает ошибку (в случае петли или просто выход не подключен), тогда вот так:
Такая логика в общем не мешает, как-то у LabVIEW программистов негласно принято, что поток данных распространяется слева направо и любая диаграмма по правилам хорошего стиля должна укладываться в один экран (поэтому на работе у меня моник в тридцать дюймов).
Как вариант можно взять недорогие 3D очки и показывать в них. Я давно хочу сделать такой эксперимент с диаскопом, у меня в детстве тоже такой был, уже купил на барахолке Zeiss VR One за десять евро, там оптика (просто две линзы) говорят неплохая:
Туда по идее надо вставлять смартфон подходящего размера, но я хочу найти и вкорячить пару небольших дисплеев, чтобы сразу с компа гнать туда картинки:
Две одинаковые недорогие камеры у меня уже есть. Может придётся поколдовать чуть с процессингом картинок, чтоб дисторсию убрать. Эх, жаль, времени нет.
Да, но только анимацией как правило не пользуются, так как глаза полопаются (это больше маркетинговый "вау эффект"). Обычно ставят бряк (точку останова) и пробники на проводочки. Ну вот к примеру, пример с коммента ниже - тут фаззи-контроллер, у него два входа (точнее массив из двух значений) и выход. Соответственно я ставлю пробники и бряк на него и дальше вижу, что ему прилетает на вход и пишется на выход (и я могу и внутрь него зайти если надо, и увидеть почему значения именно такие). Всё как у людей, там Step Into, Step Over и т.д.:
Ну и дальше можно отлаживаться пошагово. Точки останова могут иметь условия (если больше или меньше порога, то вставай, а иначе беги дальше)
Часть блоков в завимости от математического выражения в них и схемы соединения, требует наличе на входе результата расчета других блоков (возникает алгебраическая петля).
Йоу, да это одно из лучших описаний парадигмы потоков данных LabVIEW.
Вот, смотрите, у меня есть цикл for на четыре итерации, я беру счётчик итераций (он с нуля начинается, да домножаю его на два, получаю на выходе 0, 2, 4, 6:
Теперь перед умножителем я вкорячу сумматор и заведу выход умножителя на вход сумматора, LabVIEW мне скажет, мол так нельзя:
Это алгебраическая петля. Чтобы разрешить противоречие, мне нужно добавить сдвиговый регистр и перебрасывать данные через него, соответственно сумматор будет получать результат предыдущего умножения, на первой итерации ноль, и на второй ноль, и лишь на третьей прилетит двойка, которая сложится с двойкой и на неё же умножится, что даст 8, и так далее, поэтому будет 0, 2 ,8, 22:
Чтобы не выносить мозг программисту есть и другая запись того что выше, называется Feedback Node, но это просто "синтаксический сахар", просто чтобы было нагляднее, от того, что выше ничем не отличается:
Ну а всё, что не связано потоками данных, будет выполняться параллельно, в примере ниже оба сумматора будут ждать прихода значения индекса, а вот умножители отработают параллельно, и я не могу наверняка утверждать, в каком порядке они будут выполнены - умножение на двойку вперёд умножения на три или наоборот:
и кстати, в Си мне таки придётся повозиться, если я захочу выполнить асинхронно и параллельно что.то типа a *= 2; b *= 3, (оптимизатор может переставить инструкции, если они не влияют на результат, но создавать потоки он точно не будет). На самом деле и LabVIEW не всегда будет ибо накладные расходы на создание потоков тоже ненулевые, но стоит мне взять пару увесистых циклов и они мгновенно сядут на два ядра процессора. Факт в том, что
часть блоков может расчитыватся конкурентно, когда выход блока не зависит от выхода дргого блока и мы можем построить конкурентный механизьм вычисления, который на многоядержном процессоре станет паралельным
Я вот не вижу тут ничего уникального, налицо неверно настроенный контроллер нечёткой логики. На верхних графиках там фактически два состояния открыто/закрыто, соотвтетственно, клапан при низком уровне открывается на всю катушку и уровень воды проскакивает установленный уровень и клапан резко закрывется. При большом шаге дискретизации при закрытом клапане мы проваливаемся по уровню до 1,4, что вызывает резкое открытие клапана и начинаются осцилляции. Начинаются они на втором периоде потому что значально уровень был нулевой, а на втором периоде мы стартуем с 0,5. При малом шаге мы не даём системе провалиться до такого низкого уровня, поскольку ловим уровень мéньшим шагом и осцилляций нет. При правильно настроенном контроллере открытие и закрытие происходят плавно, и система не так чувствительна к шагу. Никакой мистики тут нет на мой взгляд, я вам ровно такие же осцилляции в LabVIEW могу устроить, если шаг в десять раз увеличу:
Я вроде уже много раз писал, что LabVIEW — суть компилируемый язык программирования. Самый обычный язык, просто представление кода там графическое, а не текстовое, только и всего. Алгоритм — это действительно главное. И вот я беру на себя смелость утверждать, что любой алгоритм (абсолютно любой, без исключений), который можно реализовать, скажем на С++, я могу переписать один-в-один на LabVIEW. Справедливо и обратное утверждение — любой алгоритм, написанный на LabVIEW, можно переписать на С++. Где-то надо будет больше кода, где-то меньше, но в этом алгоритмическом смысле эти языки полностью эквивалентны и С++ вы вроде знаете. Я, кажется, это даже практически показывал, когда мы RS триггер обсуждали. Ну а теперь вопрос к вам — удовлетворяет ли с вашей персональной точки зрения язык программирования С++ вашим личным критериям "параллельного программирования" и какова его "степень параллелизма"?
Исключения обеспечивают более высокую производительность
Вот с этим утверждением я не совсем согласен, поскольку это зависит от многих факторов, хотя синтетический Фибоначчи и показывает ускорение. Пару лет назад я расширял библиотеку-wrapper для использования OpenCV в LabIVEW, где изначально обработка ошибок (размер картинок, тип, нулевой указатель и т.п.) была сделана как раз на исключениях. Это было красиво с точки зрения архитектуры, удобно и элегантно, но отжирало несколько процентов от общей производительности, а там где это использовалось был реалтайм и потоковое видео с детектора, мне была важна каждая миллисекунда. Я попробовал пооптимизировать всяко разно, но по итогу мне пришлось перейти к "Си-стилю" обработки ошибок на кодах возврата. К сожалению у меня под рукой нет кода, чтоб продемонстрировать. Это разумеется не значит, что утверждение абсолютно неверно, но это повод в случаях необходимости по крайней мере практически проверить и сделать трассировку и бенчмарк.
Вероятно у них есть свой интерес поднять продажи своих ноутов, куда они это хозяйство устанавливают. Я, кстати, почему пользуюсь Pop_OS - в основном из-за беспроблемности. И я так понимаю, что определённая дисциплина разработки таки оказывает положительное влияние. В каждом Линуксе, что я пробовал что-то да не работало - либо WiFi, либо траблы с док станцией, либо NVidia, либо что.то ещё. Это решаемо всё, но вы знаете как это с линуксом. У меня старенький Dell с NVidia, а у system76 есть дистр с вшитым драйвером, и там всё заработало сразу и из коробки, да и система приятная. Кстати, ноуты по слухам тоже неплохие - мой знакомый купил, был доволен как слон.
Ну можно дни до пенсии считать. Но это при условии, что виджет в курсе про праздники в конкретном месте, даёт возможность настроить количество отпускных дней в год, и т.п. (в чём я конкретно сомневаюсь). Мои коллеги, когда у них где-то трёхзначное число остаётся уже пару раз приходили с просьбой набросать маленькое десктоп приложение, хотя это можно и в Экселе наваять, и есть онлайн сервисы. Надо будет сделать, а то мне всего-навсего 3530 рабочих дней отработать осталось.
Cosmic Desktop, что на Расте написан также используется в Pop_OS. В релиз он пока не вышел, но попробовать альфу уже можно - https://system76.com/cosmic. Для меня Pop_OS! - основной домашний Линукс, и на ней вполне можно работать (мне комфортно). Cosmic десктоп, я ,правда пока не пробовал.
И тем не менее я всё-же не до конца понимаю словосочетание "степень параллелизма" в вашей интерпретации. Для меня параллелизм — это когда что-то с чем-то выполняется параллельно. Два потока в компьютере, к примеру. Да, там есть тонкости типа псевдопараллельности в зависимости от модели многозададачности, но LabVIEW параллельна сама по себе априори и из коробки, вплоть до того, что отдельные циклы (автоматы, если хотите) там вообще на разные ядра процессора раскидать можно и они будут выполняться параллельно (можно с синхронизацией, можно и без). Что значит "степень параллелизма?"
Но в контексте конкретно данного обсуждения я, кажется, начинаю вас понимать, и вот мне кажется, что вы в какой-то мере подменяете понятия "непрерывности/дискретности" понятиями "параллельно/последовательно". Вероятно вы считаете автоматы клапана и бака некими "параллельными" системами с "мгновенной" реакцией.
Давайте в качестве примера упростим всё до предела, рассмотрим сливной бачок унитаза. Там есть кнопка слива, поплавок и клапан, соединённый с поплавком. Чем ниже уровень воды, тем сильнее открывается клапан. Нас интересует уровень воды как функция времени после нажатия кнопки, определённая на временнóм участке до следующего наполнения. Это типичная непрерывная (аналоговая, если будет угодно) система. Чтобы хоть как-то проконтролировать нашу модель, мы вкорячим туда ардуинку, замеряющую уровень в определённые моменты времени. Понятно, что если мы будем менять частоту опроса ардуинки, то на систему это никак не повлияет, разве что график станет грубее. Также и в симуляции, если мы меняем частоту дискретизации, но модель возвращает одни и те же значения в одни и те же моменты времени, то это непрерывная модель. Я могу хоть через пять секунд попросить время и моделб мне скажет количество воды в этот момент.Всё просто.
Теперь мы слегка изменим наш бачок — добавим сервомотор, и ардуинка теперь будет не просто опрашивать уровень поплавка, но будет управлять мотором, подключённому к клапану. В этом месте мы внесли дискретность в наше устройство, причём не только временнýю, но и по значениям (что поплавок, что серва имеют ограниченный набор допустимых значений). Вот теперь время цикла ардуинки будет очень даже влиять на результат — если я поставлю пять секунд, то мало того, что бачок начнёт наполняться с задержкой, он ещё и запросто может переполниться. Очевидным образом при уменьшении времени дискретизации (увеличении частоты) наша система будет ближе и лучше приближаться к непрерывной (догонит ли Ахиллес черепаху?). Я так понял из вашего отчёта выше, что при 0,01 сек это примерно и произошло и "диаграммы совпали идеально".
Пока что всё просто, это просто азы САУ. Современные средства симуляции позволяют моделировать оба типа систем, равно как и смешанные, гибридные. Тот скриншот, что я показал в комменте к предыдущему посту — это классический пример симуляции дискретной, или последовательной, если будет угодно. Я подогнал результат под SimInTech, но меняя время дискретизации, я безусловно буду влиять на результат. Там всё исполнение в цикле идёт последовательно — вычисление управляющего воздействия контроллером нечёткой логики -> вычисление значений уровня воды и потока, и на следующей итерации (такте) передача их в контроллер (там сдвиговый регистр), и так далее по кругу, никакой "параллельности" там нет и в помине.
Однако LabVIEW Control Design and Simulation Module умеет и в непрерывную систему. Я не стал усложнять там коммент, но установка этого модуля добавляет специальный цикл для симуляции, и вот в нём возможно соединить выход напрямую с входом вот таким образом (что в общем противоречит парадигме потоков данных):
Но это даёт нам ту самую "параллельность" (хотя бы визуальную), когда выход мгновенно распространяется на вход, как если бы наш поплавок был жёстко соединён с клапаном. На самом деле авторы тулкита просто вдохновились Симулинком.
Для симуляции дискретной системы там свои отдкльные инструменты (поэтому и примеры отдельно для разных типов и инструменты для непрерывных и дискретных систем разные).
Цикл симуляции, кстати, универсален, вот посмотрите на его свойства, непрерывное и дискретное время раздельно:
Как я уже отметил выше, при уменьшении времени дискретизации наша дискретная система начинает приближаться к непрерывной, но расчёт с использованием очень большого количества шагов непродуктивен с точки зрения разбазаривания вычислительных ресурсов, поэтому тут всё хитрее — используется Рунге-Кутта с переменным шагом, и шаг уменьшается лишь на сильных изменениях. Так что симуляция в общем всегда дискретна, просто шаг очень маленький. При этом я могу задать требуемую точность симуляции, как относительную, так и абсолютную, а LabVIEW сама подгонит необходимый шаг. Документация: https://www.ni.com/docs/en-US/bundle/labview-control-design-and-simulation-module/page/lvsim/sim_configparams.html?srsltid=AfmBOopYUDq60ORMmPloKvwHHDw7du6r_GpWTyGoCd1bOwyr6plxTNRH Дискретный шаг на симуляцию непрерывной системы не влияет, а лишь на количество данных (но в точках отсчёта данные должны быть валидны).
Если же я выполняю симуляцию чисто дискретной системы, то переключусь вот так:
А так, кстати, там вот что доступно:
(надо будет на досуге разобраться с остальными, а то кроме Рунге-Кутта да Эйлера ничё не знаю). Вот это всё или почти всё есть и в Simulink в той или иной форме. Там, к примеру, также как и в LabVIEW есть как дискретный, так и непрерывный интегратор (https://de.mathworks.com/help/sps/ref/integratordiscreteorcontinuous.html).
SimInTech если верить документации также умеет симулировать как дискретные так и непрерывные системы, причём их можно комбинировать.
Технически мне совершенно понятно, что симуляция непрерывной ("параллельной") системы суть приближение, а уж насколько оно "адекватно"... Самолёты на автопилоте как-то летают, автомобиле на круиз контроле худо-бедно ездят, всё это достаточно адекватно симулируется с достаточной степенью точности. Степень "адекватности" модели для меня — это степень расхождения (отклонения) симуляции и реальной системы, которое может быть измерено. Степень же параллелизма — какое-то размытое эфемерное понятие. Параллелизм — он либо есть либо нет, либо просто выглядит так, как будто он есть, хотя его нет. В остальном вроде всё достаточно понятно, ну мне во всяком случае.
Я, признаться, совершенно не понял сути вашей проблемы из набора приведённых графиков.
Совершенно очевидно, что если вносить задержки, то мы будем получать различные эффекты. Скажем, алкоголь, неумеренно принятый накануне в тяпницу вносит определённую задержку в контур управления, так что наливая наутро стакан воды для компенсации обезвоживания организма, я обычно переливаю выше краёв.
Ну а если серьёзно, то нечёткая логика тут особо ни при чём, там довольно примитивный контроллер на два входа и один выход, и это первое же, что я проконтролировал, перекладывая код SimInTech на LabVIEW, так как там фактически библиотечные функции вне моего контроля (меня немного смутила "асимметрия" в параметрах контроллера, так что я довольно дотошно проверил, подавая на входы сгенерированные рампы и визуально контролируя форму сигнала на выходе, и там всё в общем честно, хотя расхождения и есть, но они незначительны). Если вам нужна реализация на плюсплюсах, то её вероятно можно найти готовую (на Питоне уж точно).
А вот дальше там два интегратора и обратная связь (кстати, интегратор в клапане мне кажется избыточным, можно обойтись и одним в баке, ну да ладно), и меняя шаг дискретизации мы также можем получить всё что душе угодно. Кстати, насколького я вижу, SimInTech автоматом подгоняет шаг интегрирования к шагу дискретизации, а вот в LabVIEW параметр dt интегратора настраиваемый:
так что я не только временнýю задержку могу получить, но и изменение амплитуды на выходе интегратора, если шаг интегрирования и шаг симуляции будут отличаться.
Вообще если вы по-какой-то причине не доверяете SimInTech, так возьмите Simulink, ведь пример SimInTech почти один в один взят вот отсюда:
И да, выходы контроллерва нечёткой логики тоже настроены слегка несимметрично (я имею ввиду close_slow/open_slow):
Ну и результат:
Если же начать накручивать параметры в симулинке, то, разумеется, тоже появятся всякие весёлые эффекты.
Либо вас смущает лёгкая специфика реализации на автоматах, но это вроде вот тут уже обсуждалось: Нечеткая логика и конечные автоматы против ПИД-регулятора. https://habr.com/ru/articles/500268/.
Короче, я не поленился, да скачал SimInTech, там взял этот пример, разве что добавил на график расхода обратного тока выход контроллера нечёткой логики для самоконтроля:
Собственно контроллер устроен вот так:
Там гаусс используется:
Правила выхода:
Переложил это дело на LabVIEW как есть:
Гаусс, к счастью там тоже поддерживается, вот два входа::
и
Выход настроен также как и в SimInTech:
Правила:
Я вижу тут маленькую ошибку в Antecedent connective и Consequent implication, но пусть будет, скриншоты переделывать лень, там влияние минимально, да и разобраться надо поглубже
Тут можно проверить:
Ну и вот, это SimInTech:
А это LabVIEW:
Визуализация клапана, что я взял из исходного LabVIEW примера, мне отчаянно не нравится, но пусть будет, я и так полдня угрохал, чтобы с этим хотя бы поверхностно разобраться. Как-то так.
Я, как обычно со своими пятью копейками, как пример нечёткой логики в графическом программировании (LabVIEW в данном случае). С Control and Simulation нечёткая логика там идёт из "коробки". вот некоторые примеры:
Блок-диаграмма пары баков с клапаном как есть из примера:
Вот как-то так оно работает:
Пример поинтереснее — парковка машины задним ходом в гараж:
Тут два контроллера нечёткой логики — один для езды передом, а второй — для езды задом, вот так это на передней панели выглядит:
Для настройки контроллеров там такая вот утилитка прилагается:
Надо будет на досуге долгими зимними вечерами переделать пример задней парковки в параллельную в качестве упражнения. Там и другие примеры есть, типа распознавания цветов или формы деталей на конвейере. Но я честно вообще не смотрел детально как оно там устроено, просто не было проекта, где я мог бы это вкорячить, как-то ПИД-регуляторами до сих пор обходился, так что оставлю примеры выше без комментариев. Вот доки (на английском) на всякий случай, если таки захочется полюбопытствовать - Fuzzy Logic.
А, кстати, я начинаю понимать уважаемого @lws0954 , вот смотрите. допустим есть вот такая диаграмма, здесь симуляция идёт с шагом 1, рампа входная тоже с шагом 1, результат на выходе - шесть значений 0, 2, 8, 22, 52 и 114. На каждом шаге считается a[i+1] = (a[i] + i) * 2; Начальное а[0] = 0 разумеется:
Но беда в том, что сначала выполняется сложение, а потом умножение и никак иначе. И вот теперь я отчаянно возжелал выполнять умножение и сложение параллельно. Чтобы развязать эти операции я вкорячу вторую задержку (как выше было показано это таки даст возможность распараллелить эти операции). Но при единичном шаге результат сильно неверный. Но теперь я буду сильно уменьшать шаг симуляции, который в пределе стремится к нулю, я поставил 1E-5 и соответственно я буду уменьшать степень усиления, ну и шаг рампы тоже ну очень маленький, я эмпирически подогнал 5.5E-5 и вот смотрите, вуаля, я практически вписался в референсные точки:
То есть мы приходим к тому, что при бесконечно малом шаге симуляции все математические операции таки можно выполнять параллельно. Пора открывать новую страницу в математике.Хотя в данном конкретном случае простая полиномиальная интерполяция вероятно сразу даст ответ в любой точке, ну да ладно.
У вас меандр от -0.1 до 0.1, а у коллеги lws0954 от 0,5 до 1,5, вот и весь ответ.
Ещё вопросик, чтоб два раза не вставать — а можно разделить десятичный где-то подкрутить или брать его из системных настроек винды? Он в Германии не точка, а запятая и я всё время ошибаюсь:
На самом деле я с вами согласен. С++ не параллельный язык. Но у меня другой критерий параллельности. Смотрите, еслия я возьму два абсолютно независимых цикла
То по умолчанию компилятор выдаст код, выполняющий их последовательно, хотя им абсолютно ничто не мешает выполняться параллельно. А в LabVIEW они автоматом будут исполняться параллельно (до 24 штук, кстати). Чтобы добиться параллельности в С++ мне придётся выполнить пару телодвижений, несложных, но всё же.
Тоже самое и здесь:
Этим двум операторам ничто не мешает распараллелиться, но нет.
Однако если идёт зависимость по данным (выключим на время оптимизатор), скажем
То о параллельности мы не говорим.
Комментом ниже вы показали какой результат ВКПа вы считаете правильным с точки зрения параллельного программирования на примере вычисления тривиального выражения "в два щелчка"
И мне в общем всё стало ясно. Также мне стало понятно почему вы считаете "правильную" реализацию триггера мерой степени "параллельности".
УРА! Глядя на ваш результат 0, 0, 2, 4, 10, 16 я, кажется понял глубоко сакральный смысл ПАРАЛЛЕЛьНОСТИ ВКПа!
Судя по всему, в вашем параллельном мире вы пытаетесь выполнить сложение и умножение параллельно. Но поскольку они зависимы по данным, вам приходится вкорячивать вторую задержку, чтобы иметь возможность начать умножение не дожидаясь результата сложения.
Я тоже так могу, это две диаграммы одинаковы, просто чтоб понятнее было, и вот откуда берутся ваши 0, 0, 2, 4, 10, 16:
И да, тут код выполняется параллельно, только результат не очень.
Если всё ещё не понятно, то вот эквивалент на Си, в предположении что наш Си умеет исполнять параллельно операторы, расположенные на одной строчке:
И результат тот же:
Более того, я могу разнести умножение и сложение в два отдельных цикла и они будучи независимымы, вполне себе буду бежать параллельно с тем же результатом:
Вот только в реальном мире мы зависимы по данным. Умножению нужен результат сложения, а сложению - результат умножения, поэтому я не имею права вставлять в очередь элемент для умножения, мне нельзя начинать его, не дождавшись результат сложения! Так что вот вам "правильная" параллельность:
Да только нет её тут, потому что автомат выполняющий умножение ждёт результата автомата, выполняющего сложение.
Офигенно увлекательная дискуссия.
Эх, а у нас корпоративным полиси телеграм запретили. Заблокировать его не могут (хотя звонки не проходят), но большой брат следит и при использовании прилетает вежливое письмо счастья с просьбой убрать, а иначе его уберут через удалённый доступ. А жаль, удобная штука. А так MS Teams используется. Дело в филиале американской компании в Германии происходит.
Вот так:
И вот:
Я не знаю, как ещё проще эту конструкцию объяснить
Да и тут тоже 0 2 8 22, что характерно:
Да в общем ничего особенного, там четыре скорости есть (я иконки блоков у вас утащил чтоб аутентичненько было):
Я обычно подсветкой выполнения пользуюсь тогда, когда влетев в какой-нибудь блок всё встаёт колом, и тогда подсветка может мне показать, где я вообще в коде нахожусь. Ну или что-то совсем несложное отладить или просто выполнение замедлить.
А, да, и результаты:
Вот LabVIEW:
А вот Simulation In Technic:
Ну в общем было бы странно, если бы они принципиально отличались.
Стрелочек на проводникак в LabVIEW нет, они появляются лишь тогда, когда поток данных разбит и вызывает ошибку (в случае петли или просто выход не подключен), тогда вот так:
Такая логика в общем не мешает, как-то у LabVIEW программистов негласно принято, что поток данных распространяется слева направо и любая диаграмма по правилам хорошего стиля должна укладываться в один экран (поэтому на работе у меня моник в тридцать дюймов).
Как вариант можно взять недорогие 3D очки и показывать в них. Я давно хочу сделать такой эксперимент с диаскопом, у меня в детстве тоже такой был, уже купил на барахолке Zeiss VR One за десять евро, там оптика (просто две линзы) говорят неплохая:
Туда по идее надо вставлять смартфон подходящего размера, но я хочу найти и вкорячить пару небольших дисплеев, чтобы сразу с компа гнать туда картинки:
Две одинаковые недорогие камеры у меня уже есть. Может придётся поколдовать чуть с процессингом картинок, чтоб дисторсию убрать. Эх, жаль, времени нет.
Да, но только анимацией как правило не пользуются, так как глаза полопаются (это больше маркетинговый "вау эффект"). Обычно ставят бряк (точку останова) и пробники на проводочки. Ну вот к примеру, пример с коммента ниже - тут фаззи-контроллер, у него два входа (точнее массив из двух значений) и выход. Соответственно я ставлю пробники и бряк на него и дальше вижу, что ему прилетает на вход и пишется на выход (и я могу и внутрь него зайти если надо, и увидеть почему значения именно такие). Всё как у людей, там Step Into, Step Over и т.д.:
Ну и дальше можно отлаживаться пошагово. Точки останова могут иметь условия (если больше или меньше порога, то вставай, а иначе беги дальше)
Йоу, да это одно из лучших описаний парадигмы потоков данных LabVIEW.
Вот, смотрите, у меня есть цикл for на четыре итерации, я беру счётчик итераций (он с нуля начинается, да домножаю его на два, получаю на выходе 0, 2, 4, 6:
Теперь перед умножителем я вкорячу сумматор и заведу выход умножителя на вход сумматора, LabVIEW мне скажет, мол так нельзя:
Это алгебраическая петля. Чтобы разрешить противоречие, мне нужно добавить сдвиговый регистр и перебрасывать данные через него, соответственно сумматор будет получать результат предыдущего умножения, на первой итерации ноль, и на второй ноль, и лишь на третьей прилетит двойка, которая сложится с двойкой и на неё же умножится, что даст 8, и так далее, поэтому будет 0, 2 ,8, 22:
Чтобы не выносить мозг программисту есть и другая запись того что выше, называется Feedback Node, но это просто "синтаксический сахар", просто чтобы было нагляднее, от того, что выше ничем не отличается:
Ну а всё, что не связано потоками данных, будет выполняться параллельно, в примере ниже оба сумматора будут ждать прихода значения индекса, а вот умножители отработают параллельно, и я не могу наверняка утверждать, в каком порядке они будут выполнены - умножение на двойку вперёд умножения на три или наоборот:
и кстати, в Си мне таки придётся повозиться, если я захочу выполнить асинхронно и параллельно что.то типа a *= 2; b *= 3, (оптимизатор может переставить инструкции, если они не влияют на результат, но создавать потоки он точно не будет). На самом деле и LabVIEW не всегда будет ибо накладные расходы на создание потоков тоже ненулевые, но стоит мне взять пару увесистых циклов и они мгновенно сядут на два ядра процессора. Факт в том, что
лучше и не скажешь.
Я вот не вижу тут ничего уникального, налицо неверно настроенный контроллер нечёткой логики. На верхних графиках там фактически два состояния открыто/закрыто, соотвтетственно, клапан при низком уровне открывается на всю катушку и уровень воды проскакивает установленный уровень и клапан резко закрывется. При большом шаге дискретизации при закрытом клапане мы проваливаемся по уровню до 1,4, что вызывает резкое открытие клапана и начинаются осцилляции. Начинаются они на втором периоде потому что значально уровень был нулевой, а на втором периоде мы стартуем с 0,5. При малом шаге мы не даём системе провалиться до такого низкого уровня, поскольку ловим уровень мéньшим шагом и осцилляций нет. При правильно настроенном контроллере открытие и закрытие происходят плавно, и система не так чувствительна к шагу. Никакой мистики тут нет на мой взгляд, я вам ровно такие же осцилляции в LabVIEW могу устроить, если шаг в десять раз увеличу:
Я вроде уже много раз писал, что LabVIEW — суть компилируемый язык программирования. Самый обычный язык, просто представление кода там графическое, а не текстовое, только и всего. Алгоритм — это действительно главное. И вот я беру на себя смелость утверждать, что любой алгоритм (абсолютно любой, без исключений), который можно реализовать, скажем на С++, я могу переписать один-в-один на LabVIEW. Справедливо и обратное утверждение — любой алгоритм, написанный на LabVIEW, можно переписать на С++. Где-то надо будет больше кода, где-то меньше, но в этом алгоритмическом смысле эти языки полностью эквивалентны и С++ вы вроде знаете. Я, кажется, это даже практически показывал, когда мы RS триггер обсуждали. Ну а теперь вопрос к вам — удовлетворяет ли с вашей персональной точки зрения язык программирования С++ вашим личным критериям "параллельного программирования" и какова его "степень параллелизма"?
Вот с этим утверждением я не совсем согласен, поскольку это зависит от многих факторов, хотя синтетический Фибоначчи и показывает ускорение. Пару лет назад я расширял библиотеку-wrapper для использования OpenCV в LabIVEW, где изначально обработка ошибок (размер картинок, тип, нулевой указатель и т.п.) была сделана как раз на исключениях. Это было красиво с точки зрения архитектуры, удобно и элегантно, но отжирало несколько процентов от общей производительности, а там где это использовалось был реалтайм и потоковое видео с детектора, мне была важна каждая миллисекунда. Я попробовал пооптимизировать всяко разно, но по итогу мне пришлось перейти к "Си-стилю" обработки ошибок на кодах возврата. К сожалению у меня под рукой нет кода, чтоб продемонстрировать. Это разумеется не значит, что утверждение абсолютно неверно, но это повод в случаях необходимости по крайней мере практически проверить и сделать трассировку и бенчмарк.
Вероятно у них есть свой интерес поднять продажи своих ноутов, куда они это хозяйство устанавливают. Я, кстати, почему пользуюсь Pop_OS - в основном из-за беспроблемности. И я так понимаю, что определённая дисциплина разработки таки оказывает положительное влияние. В каждом Линуксе, что я пробовал что-то да не работало - либо WiFi, либо траблы с док станцией, либо NVidia, либо что.то ещё. Это решаемо всё, но вы знаете как это с линуксом. У меня старенький Dell с NVidia, а у system76 есть дистр с вшитым драйвером, и там всё заработало сразу и из коробки, да и система приятная. Кстати, ноуты по слухам тоже неплохие - мой знакомый купил, был доволен как слон.
Ну можно дни до пенсии считать. Но это при условии, что виджет в курсе про праздники в конкретном месте, даёт возможность настроить количество отпускных дней в год, и т.п. (в чём я конкретно сомневаюсь). Мои коллеги, когда у них где-то трёхзначное число остаётся уже пару раз приходили с просьбой набросать маленькое десктоп приложение, хотя это можно и в Экселе наваять, и есть онлайн сервисы. Надо будет сделать, а то мне всего-навсего 3530 рабочих дней отработать осталось.
Cosmic Desktop, что на Расте написан также используется в Pop_OS. В релиз он пока не вышел, но попробовать альфу уже можно - https://system76.com/cosmic. Для меня Pop_OS! - основной домашний Линукс, и на ней вполне можно работать (мне комфортно). Cosmic десктоп, я ,правда пока не пробовал.
И тем не менее я всё-же не до конца понимаю словосочетание "степень параллелизма" в вашей интерпретации. Для меня параллелизм — это когда что-то с чем-то выполняется параллельно. Два потока в компьютере, к примеру. Да, там есть тонкости типа псевдопараллельности в зависимости от модели многозададачности, но LabVIEW параллельна сама по себе априори и из коробки, вплоть до того, что отдельные циклы (автоматы, если хотите) там вообще на разные ядра процессора раскидать можно и они будут выполняться параллельно (можно с синхронизацией, можно и без). Что значит "степень параллелизма?"
Но в контексте конкретно данного обсуждения я, кажется, начинаю вас понимать, и вот мне кажется, что вы в какой-то мере подменяете понятия "непрерывности/дискретности" понятиями "параллельно/последовательно". Вероятно вы считаете автоматы клапана и бака некими "параллельными" системами с "мгновенной" реакцией.
Давайте в качестве примера упростим всё до предела, рассмотрим сливной бачок унитаза. Там есть кнопка слива, поплавок и клапан, соединённый с поплавком. Чем ниже уровень воды, тем сильнее открывается клапан. Нас интересует уровень воды как функция времени после нажатия кнопки, определённая на временнóм участке до следующего наполнения. Это типичная непрерывная (аналоговая, если будет угодно) система. Чтобы хоть как-то проконтролировать нашу модель, мы вкорячим туда ардуинку, замеряющую уровень в определённые моменты времени. Понятно, что если мы будем менять частоту опроса ардуинки, то на систему это никак не повлияет, разве что график станет грубее. Также и в симуляции, если мы меняем частоту дискретизации, но модель возвращает одни и те же значения в одни и те же моменты времени, то это непрерывная модель. Я могу хоть через пять секунд попросить время и моделб мне скажет количество воды в этот момент.Всё просто.
Теперь мы слегка изменим наш бачок — добавим сервомотор, и ардуинка теперь будет не просто опрашивать уровень поплавка, но будет управлять мотором, подключённому к клапану. В этом месте мы внесли дискретность в наше устройство, причём не только временнýю, но и по значениям (что поплавок, что серва имеют ограниченный набор допустимых значений). Вот теперь время цикла ардуинки будет очень даже влиять на результат — если я поставлю пять секунд, то мало того, что бачок начнёт наполняться с задержкой, он ещё и запросто может переполниться. Очевидным образом при уменьшении времени дискретизации (увеличении частоты) наша система будет ближе и лучше приближаться к непрерывной (догонит ли Ахиллес черепаху?). Я так понял из вашего отчёта выше, что при 0,01 сек это примерно и произошло и "диаграммы совпали идеально".
Пока что всё просто, это просто азы САУ. Современные средства симуляции позволяют моделировать оба типа систем, равно как и смешанные, гибридные. Тот скриншот, что я показал в комменте к предыдущему посту — это классический пример симуляции дискретной, или последовательной, если будет угодно. Я подогнал результат под SimInTech, но меняя время дискретизации, я безусловно буду влиять на результат. Там всё исполнение в цикле идёт последовательно — вычисление управляющего воздействия контроллером нечёткой логики -> вычисление значений уровня воды и потока, и на следующей итерации (такте) передача их в контроллер (там сдвиговый регистр), и так далее по кругу, никакой "параллельности" там нет и в помине.
Однако LabVIEW Control Design and Simulation Module умеет и в непрерывную систему. Я не стал усложнять там коммент, но установка этого модуля добавляет специальный цикл для симуляции, и вот в нём возможно соединить выход напрямую с входом вот таким образом (что в общем противоречит парадигме потоков данных):
Но это даёт нам ту самую "параллельность" (хотя бы визуальную), когда выход мгновенно распространяется на вход, как если бы наш поплавок был жёстко соединён с клапаном. На самом деле авторы тулкита просто вдохновились Симулинком.
Для симуляции дискретной системы там свои отдкльные инструменты (поэтому и примеры отдельно для разных типов и инструменты для непрерывных и дискретных систем разные).
Цикл симуляции, кстати, универсален, вот посмотрите на его свойства, непрерывное и дискретное время раздельно:
Как я уже отметил выше, при уменьшении времени дискретизации наша дискретная система начинает приближаться к непрерывной, но расчёт с использованием очень большого количества шагов непродуктивен с точки зрения разбазаривания вычислительных ресурсов, поэтому тут всё хитрее — используется Рунге-Кутта с переменным шагом, и шаг уменьшается лишь на сильных изменениях. Так что симуляция в общем всегда дискретна, просто шаг очень маленький. При этом я могу задать требуемую точность симуляции, как относительную, так и абсолютную, а LabVIEW сама подгонит необходимый шаг. Документация: https://www.ni.com/docs/en-US/bundle/labview-control-design-and-simulation-module/page/lvsim/sim_configparams.html?srsltid=AfmBOopYUDq60ORMmPloKvwHHDw7du6r_GpWTyGoCd1bOwyr6plxTNRH Дискретный шаг на симуляцию непрерывной системы не влияет, а лишь на количество данных (но в точках отсчёта данные должны быть валидны).
Если же я выполняю симуляцию чисто дискретной системы, то переключусь вот так:
А так, кстати, там вот что доступно:
(надо будет на досуге разобраться с остальными, а то кроме Рунге-Кутта да Эйлера ничё не знаю). Вот это всё или почти всё есть и в Simulink в той или иной форме. Там, к примеру, также как и в LabVIEW есть как дискретный, так и непрерывный интегратор (https://de.mathworks.com/help/sps/ref/integratordiscreteorcontinuous.html).
SimInTech если верить документации также умеет симулировать как дискретные так и непрерывные системы, причём их можно комбинировать.
Технически мне совершенно понятно, что симуляция непрерывной ("параллельной") системы суть приближение, а уж насколько оно "адекватно"... Самолёты на автопилоте как-то летают, автомобиле на круиз контроле худо-бедно ездят, всё это достаточно адекватно симулируется с достаточной степенью точности. Степень "адекватности" модели для меня — это степень расхождения (отклонения) симуляции и реальной системы, которое может быть измерено. Степень же параллелизма — какое-то размытое эфемерное понятие. Параллелизм — он либо есть либо нет, либо просто выглядит так, как будто он есть, хотя его нет. В остальном вроде всё достаточно понятно, ну мне во всяком случае.
Я, признаться, совершенно не понял сути вашей проблемы из набора приведённых графиков.
Совершенно очевидно, что если вносить задержки, то мы будем получать различные эффекты. Скажем, алкоголь, неумеренно принятый накануне в тяпницу вносит определённую задержку в контур управления, так что наливая наутро стакан воды для компенсации обезвоживания организма, я обычно переливаю выше краёв.
Ну а если серьёзно, то нечёткая логика тут особо ни при чём, там довольно примитивный контроллер на два входа и один выход, и это первое же, что я проконтролировал, перекладывая код SimInTech на LabVIEW, так как там фактически библиотечные функции вне моего контроля (меня немного смутила "асимметрия" в параметрах контроллера, так что я довольно дотошно проверил, подавая на входы сгенерированные рампы и визуально контролируя форму сигнала на выходе, и там всё в общем честно, хотя расхождения и есть, но они незначительны). Если вам нужна реализация на плюсплюсах, то её вероятно можно найти готовую (на Питоне уж точно).
А вот дальше там два интегратора и обратная связь (кстати, интегратор в клапане мне кажется избыточным, можно обойтись и одним в баке, ну да ладно), и меняя шаг дискретизации мы также можем получить всё что душе угодно. Кстати, насколького я вижу, SimInTech автоматом подгоняет шаг интегрирования к шагу дискретизации, а вот в LabVIEW параметр dt интегратора настраиваемый:
так что я не только временнýю задержку могу получить, но и изменение амплитуды на выходе интегратора, если шаг интегрирования и шаг симуляции будут отличаться.
Вообще если вы по-какой-то причине не доверяете SimInTech, так возьмите Simulink, ведь пример SimInTech почти один в один взят вот отсюда:
Water Level Control in a Tank
Там вот так всё устроено:
И да, выходы контроллерва нечёткой логики тоже настроены слегка несимметрично (я имею ввиду close_slow/open_slow):
Ну и результат:
Если же начать накручивать параметры в симулинке, то, разумеется, тоже появятся всякие весёлые эффекты.
Либо вас смущает лёгкая специфика реализации на автоматах, но это вроде вот тут уже обсуждалось: Нечеткая логика и конечные автоматы против ПИД-регулятора. https://habr.com/ru/articles/500268/.
Короче, я не поленился, да скачал SimInTech, там взял этот пример, разве что добавил на график расхода обратного тока выход контроллера нечёткой логики для самоконтроля:
Собственно контроллер устроен вот так:
Там гаусс используется:
Правила выхода:
Переложил это дело на LabVIEW как есть:
Гаусс, к счастью там тоже поддерживается, вот два входа::
и
Выход настроен также как и в SimInTech:
Правила:
Я вижу тут маленькую ошибку в Antecedent connective и Consequent implication, но пусть будет, скриншоты переделывать лень, там влияние минимально, да и разобраться надо поглубже
Тут можно проверить:
Ну и вот, это SimInTech:
А это LabVIEW:
Визуализация клапана, что я взял из исходного LabVIEW примера, мне отчаянно не нравится, но пусть будет, я и так полдня угрохал, чтобы с этим хотя бы поверхностно разобраться. Как-то так.
О, спасибо огромное, любопытно.
Я, как обычно со своими пятью копейками, как пример нечёткой логики в графическом программировании (LabVIEW в данном случае). С Control and Simulation нечёткая логика там идёт из "коробки". вот некоторые примеры:
Блок-диаграмма пары баков с клапаном как есть из примера:
Вот как-то так оно работает:
Пример поинтереснее — парковка машины задним ходом в гараж:
Тут два контроллера нечёткой логики — один для езды передом, а второй — для езды задом, вот так это на передней панели выглядит:
Для настройки контроллеров там такая вот утилитка прилагается:
Надо будет на досуге долгими зимними вечерами переделать пример задней парковки в параллельную в качестве упражнения. Там и другие примеры есть, типа распознавания цветов или формы деталей на конвейере. Но я честно вообще не смотрел детально как оно там устроено, просто не было проекта, где я мог бы это вкорячить, как-то ПИД-регуляторами до сих пор обходился, так что оставлю примеры выше без комментариев. Вот доки (на английском) на всякий случай, если таки захочется полюбопытствовать - Fuzzy Logic.