Все графики, кроме красных совпадают. Чем можно объяснить сей факт?
Я сегодня отчаянно не ленив, так что пожертвую обеденным перерывом ради высокого искусства. Выше я писал, что все значения, полученные в ходе симуляции имеют строгое мат обоснование, это можно даже в Экселе проверить. Я переброшу этот код на LabVIEW, вот так это выглядит:
Для непосвящённого может чуть непривычно, но два интегратора тут видны хорошо, формулу я оставил как есть, тут примитивная арифметика, а как работают сдвиговые регистры, я уже выше писал.
Результат:
И заметьте, полученные данные такие же как в SimInTech, при этом они не "примерно" такие же, они точно такие же (я пару колонок местами переставил, но переделывать не буду, всему есть предел).
А вот теперь следите за руками, я внесу задержку в первое попавшееся место, это легко сделать, просто растянув сдвиговый регистр вниз, второй его терминал будет выдавать данные на цикл позже. Я скопирую оригинал и сделаю вот так, оставив только то, что меня (точнее вас) интересует:
Ну и вот, получите и распишитесь:
При этом я могу строго обосновать, как и почему значение, скажем 0,180327 магическим образом превратилось в 0,250503 и так далее. Ну какие могут быть ещё вопросы? Всё что выше, я могу и на Си переписать, там двадцать строчек кода, но уж увольте. У вас амлитуда вроде в другую строну уваливается, но тут зависит что относительно чего задерживать.Вот если я в другом месте задержку вдую:
Вы уж меня простите, но вы совершенно не умеете изложить суть даже в таком простейшем случае. Да мы тут телепаты все и прекрасно понимаем что вы там понакрутили.
Давайте строго подойдём к вопросу. Итак у вас в руках система, результаты которой вас удивляют, которые вы считаете неправильными. Поскольку единственный код, который есть у нас в руках - это тот, что был предоставлен выше, вот на его примере и покажу как производится поверка.
Прежде всего вместо мутных графиков я сброшу все значения в лог файл, вот так, включая меандр, потому что я вообще никому не доверяю в этом мире:
А теперь открываю его в любой удобной программе и начинаю разбираться:
В лог файле шесть колонок - время с начала эксперимента и те пять входов, что я добавил. В точке "ноль" я вижу 0.1 - это мой меандр, всё остальное стоит в нуле. ОК.
Едем дальше, следующая секунда, мы находимся здесь:
Меандр так и стоит в 0,1, а вот следующее значение стало 0,05. Почему так? А потому что это выход интегратора, который набрал за эту секунду 0,1, помноженный на 0,5, вот откуда 0,05. Интегрировать, кстати, тоже можно по-разному, но это так, вскользь. Как бы то ни было, это же значение пролетело насквозь нашего бака из rate в dh, а остальные два параметра в нуле, потому что там второй интегратор, а он выдаст нам значение лишь на следующем шаге.
С этим разобрались, едем дальше. Мы здесь:
О, тут уже интереснее. Значение первого интегратора увеличилось с 0,05 до 0,1 (мы не забываем, что там деление на два, поэтому приращение 0,05). Второй интегратор наконец отработал, так что теперь там 0,05. А число дальше это outrate = sqrt(2gh) outarea; где outarea это константа, то есть sqrt(2 x 9,8 x 0,05) x (1/20). Берём калькулятор, считаем, совпадает аж до последнего знака:
А откуда берётся последнее число? А это 0,1 минус то что выше, и оно записано в лог в этом же такте, это важно!
Едем дальше, мы здесь и первый интегратор клапана наинтегрировал ещё, увеличившись до 0,15, а второй в баке теперь учёл дельту, которая сложилась с входным значением и стало 0,100502525316942 (насколько я понимаю это именно ваше "проблемное" число, которое там где-то дальше не сходится):
Вот ровно тоже самое вы должны проделать до момента расхождения и в вашей программе в том числе (хотя я думаю у вас там уже вначале будет разбегаться). Никакое число тут не берётся из воздуха, это результат расчёта согласно алгоритму. И если я повторю эти вычисления в LabVIEW, то получу строго такой же результат, вплоть до последнего знака после запятой, (если точность будет та же). И если вы утверждаете, что результат расчёта по вашей параллельной методике заметно отличается, то должны внятно изложить где и почему. Просто скриншоты графиков тут не катят. Берёте два листинга, прикладываете сторона к стороне и дотошно проверяете. У вас лабораторных по физике или электронике в институте не было что ли, где мы проверяли законы физики экспериментально, списывая в тетрадку показания приборов, строя графики и убеждаясь, что законы всё еще в силе? Ну вот тут тоже самое. Сдёрните логи с обеих систем, покажите их, ткните пальцем в расхождение, и объясните почему так а не иначе, почему именно ваши значения именно такие, как вы к ним пришли и что там с чем у вас складывается параллельно или попендикулярно или как ещё, ибо только вы в курсе того, как производятся вычисления в вашей параллельной среде. Любому наблюдаемому и значимому расхождению всегда есть рациональное объяснение, чудес на этом свете не бывает. Я всё ещё думаю, что вы снова съехали на один такт с этим вашим параллелизмом, берёте предыдущее значение, оно ниже, оттого размах амплитуды вашего графика несколько меньше, чем должен быть. Ошибки в SimInTech тоже исключать нельзя, но тут настолько базово всё, что тестировалось сто раз и достаточно вычищено. Впрочем - доверяй, но проверяй.
Ну не знаю, в примере простейшего алгоритма, который должен был вернуть значения 0, 2, 8, 22, 52 и 114 вы получаете значения 0, 0, 2 ,4, 10, 16 и утверждаете что это правильно и только так и нужно. В прошлом обсуждении триггера мне пришлось также поставить пару сдвиговых регистров крест накрест, чтобы достичь параллельности, о которой вы просили, но тактовый сдвиг, дающий это, там оставался. Я понял, как вы этого достигаете в ВКПа, язык программирования тут вообще не при чём, и ровно того же результата можно добиться дополнительной кодовой обвязкой и в С++ и в LabVIEW, но об эту самую параллельность можно в какой-то момент очень даже нехило обжечься. А так если данные независимы и могут обрабатываться параллельно, то оно вполне себе работает.
Конечно, я могу поставить там точку, но тогда мне станет неудобно решительно везде. LabVIEW вот понимает запятую, а в SimInTech запятая разделяет элементы массивов и мне потом каждый раз надо это дело править или не пользоваться цифровой клавой сбоку.
Ну да, тут работает простая арифметика, основанная на том факте, что при малом приращении шага изменения настолько малы, что пофиг на то, что мы берём часть результатов из соседнего шага, ошибка не успевает набегать. Вероятно под это дело можно подвести и строгое математическое обоснование, но практическая применимость этой фишки сильно ограничена необходимостью дикого количества итераций плюс надо автоматом корёжить вычисления, чтоб результат сошёлся.
А, кстати, я начинаю понимать уважаемого @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 рабочих дней отработать осталось.
Я сегодня отчаянно не ленив, так что пожертвую обеденным перерывом ради высокого искусства. Выше я писал, что все значения, полученные в ходе симуляции имеют строгое мат обоснование, это можно даже в Экселе проверить. Я переброшу этот код на LabVIEW, вот так это выглядит:
Для непосвящённого может чуть непривычно, но два интегратора тут видны хорошо, формулу я оставил как есть, тут примитивная арифметика, а как работают сдвиговые регистры, я уже выше писал.
Результат:
И заметьте, полученные данные такие же как в SimInTech, при этом они не "примерно" такие же, они точно такие же (я пару колонок местами переставил, но переделывать не буду, всему есть предел).
А вот теперь следите за руками, я внесу задержку в первое попавшееся место, это легко сделать, просто растянув сдвиговый регистр вниз, второй его терминал будет выдавать данные на цикл позже. Я скопирую оригинал и сделаю вот так, оставив только то, что меня (точнее вас) интересует:
Ну и вот, получите и распишитесь:
При этом я могу строго обосновать, как и почему значение, скажем 0,180327 магическим образом превратилось в 0,250503 и так далее. Ну какие могут быть ещё вопросы? Всё что выше, я могу и на Си переписать, там двадцать строчек кода, но уж увольте. У вас амлитуда вроде в другую строну уваливается, но тут зависит что относительно чего задерживать.Вот если я в другом месте задержку вдую:
То зацените какая неописуемая красота получится:
И даже тут нет магии, просто арифметика.
Вы уж меня простите, но вы совершенно не умеете изложить суть даже в таком простейшем случае. Да мы тут телепаты все и прекрасно понимаем что вы там понакрутили.
Давайте строго подойдём к вопросу. Итак у вас в руках система, результаты которой вас удивляют, которые вы считаете неправильными. Поскольку единственный код, который есть у нас в руках - это тот, что был предоставлен выше, вот на его примере и покажу как производится поверка.
Прежде всего вместо мутных графиков я сброшу все значения в лог файл, вот так, включая меандр, потому что я вообще никому не доверяю в этом мире:
А теперь открываю его в любой удобной программе и начинаю разбираться:
В лог файле шесть колонок - время с начала эксперимента и те пять входов, что я добавил. В точке "ноль" я вижу 0.1 - это мой меандр, всё остальное стоит в нуле. ОК.
Едем дальше, следующая секунда, мы находимся здесь:
Меандр так и стоит в 0,1, а вот следующее значение стало 0,05. Почему так? А потому что это выход интегратора, который набрал за эту секунду 0,1, помноженный на 0,5, вот откуда 0,05. Интегрировать, кстати, тоже можно по-разному, но это так, вскользь. Как бы то ни было, это же значение пролетело насквозь нашего бака из rate в dh, а остальные два параметра в нуле, потому что там второй интегратор, а он выдаст нам значение лишь на следующем шаге.
С этим разобрались, едем дальше. Мы здесь:
О, тут уже интереснее. Значение первого интегратора увеличилось с 0,05 до 0,1 (мы не забываем, что там деление на два, поэтому приращение 0,05). Второй интегратор наконец отработал, так что теперь там 0,05. А число дальше это outrate = sqrt(2gh) outarea; где outarea это константа, то есть sqrt(2 x 9,8 x 0,05) x (1/20). Берём калькулятор, считаем, совпадает аж до последнего знака:
А откуда берётся последнее число? А это 0,1 минус то что выше, и оно записано в лог в этом же такте, это важно!
Едем дальше, мы здесь и первый интегратор клапана наинтегрировал ещё, увеличившись до 0,15, а второй в баке теперь учёл дельту, которая сложилась с входным значением и стало 0,100502525316942 (насколько я понимаю это именно ваше "проблемное" число, которое там где-то дальше не сходится):
И так далее:
Листинг:
Скрытый текст
Вот ровно тоже самое вы должны проделать до момента расхождения и в вашей программе в том числе (хотя я думаю у вас там уже вначале будет разбегаться). Никакое число тут не берётся из воздуха, это результат расчёта согласно алгоритму. И если я повторю эти вычисления в LabVIEW, то получу строго такой же результат, вплоть до последнего знака после запятой, (если точность будет та же). И если вы утверждаете, что результат расчёта по вашей параллельной методике заметно отличается, то должны внятно изложить где и почему. Просто скриншоты графиков тут не катят. Берёте два листинга, прикладываете сторона к стороне и дотошно проверяете. У вас лабораторных по физике или электронике в институте не было что ли, где мы проверяли законы физики экспериментально, списывая в тетрадку показания приборов, строя графики и убеждаясь, что законы всё еще в силе? Ну вот тут тоже самое. Сдёрните логи с обеих систем, покажите их, ткните пальцем в расхождение, и объясните почему так а не иначе, почему именно ваши значения именно такие, как вы к ним пришли и что там с чем у вас складывается параллельно или попендикулярно или как ещё, ибо только вы в курсе того, как производятся вычисления в вашей параллельной среде. Любому наблюдаемому и значимому расхождению всегда есть рациональное объяснение, чудес на этом свете не бывает. Я всё ещё думаю, что вы снова съехали на один такт с этим вашим параллелизмом, берёте предыдущее значение, оно ниже, оттого размах амплитуды вашего графика несколько меньше, чем должен быть. Ошибки в SimInTech тоже исключать нельзя, но тут настолько базово всё, что тестировалось сто раз и достаточно вычищено. Впрочем - доверяй, но проверяй.
Ну не знаю, в примере простейшего алгоритма, который должен был вернуть значения 0, 2, 8, 22, 52 и 114 вы получаете значения 0, 0, 2 ,4, 10, 16 и утверждаете что это правильно и только так и нужно. В прошлом обсуждении триггера мне пришлось также поставить пару сдвиговых регистров крест накрест, чтобы достичь параллельности, о которой вы просили, но тактовый сдвиг, дающий это, там оставался. Я понял, как вы этого достигаете в ВКПа, язык программирования тут вообще не при чём, и ровно того же результата можно добиться дополнительной кодовой обвязкой и в С++ и в LabVIEW, но об эту самую параллельность можно в какой-то момент очень даже нехило обжечься. А так если данные независимы и могут обрабатываться параллельно, то оно вполне себе работает.
Конечно, я могу поставить там точку, но тогда мне станет неудобно решительно везде. LabVIEW вот понимает запятую, а в SimInTech запятая разделяет элементы массивов и мне потом каждый раз надо это дело править или не пользоваться цифровой клавой сбоку.
Ну да, тут работает простая арифметика, основанная на том факте, что при малом приращении шага изменения настолько малы, что пофиг на то, что мы берём часть результатов из соседнего шага, ошибка не успевает набегать. Вероятно под это дело можно подвести и строгое математическое обоснование, но практическая применимость этой фишки сильно ограничена необходимостью дикого количества итераций плюс надо автоматом корёжить вычисления, чтоб результат сошёлся.
А, кстати, я начинаю понимать уважаемого @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 рабочих дней отработать осталось.