Минимальнейшая конфигурация, на которой у меня крутится 24Н2 это Acer Aspire XC-105 c AMD камушком, ему чуть больше одиннадцати лет, я ему память до 8 ГБ проапгрейдил:
Но мне просто потребовался комп с голой ОС для подключения кой-каких USB накопителей, плюс я хотел просто "потестить" LTSC на древнем железе. Даже если просто подключиться к нему через RDP, то уже загрузка процессора улетает в 50%. Работать на нём - ну такое себе.
Как ведет себя такая сеть в случае если розетки подключены к разным автоматам в щитке?
Нет проблем, лишь бы они висели на одной фазе. Но даже если не на одной, то есть такая штука:
Правда она скорость роняет. В моём случае через розетки где-то 60-70 мегабит, а через фазу - скорость падала вдвое, так что я все комнаты где интернет через розетки, на одну фазу повесил. Чем длиннее линия, тем ниже скорость. Но у меня модули очень старенькие стоят, им лет пятнадцать уже.
Да, выросли. Я б не сказал что "вдвое", но раза в полтора (мука, молоко, сыр, масло), пожалуй да, что есть, то есть. Вот тут есть табличка в Экселе, правда на немецком, но переводится легко. Хотя сейчас вроде потихоньку начинают падать, но очень слегка.
Справедливости ради надо отметить, что когда я приезжаю в Россию (в Питер) со своей "немецкой" зарплатой и банально иду там в магазин, да хоть в тот же "Ашан" или "Азбуку вкуса" или что там ещё сейчас есть, то не то чтобы чувствую себя нищебродом, но оставляю там сумму, сравнимую с немецкой, покупая там набор продуктов и вкусняшек, к которым привык в Германии. Рестораны тоже примерно в одной ценовой категории. Может, если в "Пятёрочке" отовариваться то разница будет существенная, а так - сравнимо (местами даже дороже чем в Германии или Италии). Но "в комплексе" (с расходами на жильё, транспорт и т.п.) мне тяжело сравнивать, я уже почти четверть века в Германии живу. В Европе тоже не везде одинаково - во Франции заметно дороже, а про Норвегию так я вообще молчу.
фортран быстрее си в математике и оптимизированей того же си
О, я так не думаю, если брать интеловские компиляторы, то на плюс минус одинаковых вычислениях что фортран, что си выдадут скорее всего плюс-минус одинаковый компилят и всё упрётся в производительность процессора. Вот первый попавшийся под руку бенчмарк. Что же касается симуляции, то там придётся овердофига кода положить, так как из коробки в фортране необходимых численных методов вероятно нет. И если для того же Рунге-Кутта с переменным шагом ещё можно найти библиотеки, то "обвязку", вероятно придётся писать заново. Я так полагаю, что фортран поддерживается из-за большого количества уже существующего кода (это был первый язык, который я в Политехе учил в прошлом веке), но в активной разработке современных проектов я его давно не встречал. А современные инструменты сильно высокоуровневые, там симуляция буквально в несколько кликов собирается, а "оверхед" компенсируется высокой скоростью современных процессоров. Ну и вычислительное ядро - как правило оптимизированные библиотечные функции, в LabVIEW точно также - есля я соберу симуляцию на нативных примитивах LabVIEW, то результата вероятно вообще не дождусь.
Вообще это то, что нынче называется модным "софт-скиллс". Если вы устроились в "одну очень большую компанию", то надо понимать специфику работы в такой компании. Их очень много, таких специфических моментов. И если говорить о "продвижении по службе", то одно из первых правил успешного карьерного роста — это говорить "правильные" слова, правильному человеку и в правильный момент времени. Высший пилотаж - скажем при съезде менеджеров из головного офиса вычленить "правильного" решающего менеджера, затем на обеденном перерыве подгадать момент, подсесть к нему и вежливо "разрешите представиться, я тут программист такой-то...", и пошла-поехала карьера в гору (если повезёт). Сотрудники на одном с вами грейде это, конечно будут видеть, мол, вот жеж Н, хитрая лиса, ты смотри... Надо уметь "толкаться", как сказал кто-то. Я это видел много раз, так как в IT четверть века и работал в "больших" компаниях (100К+ сотрудников). Это дано не всем, тут надо иметь определённый запас этих самых "софт скиллс" (сами вставьте подходящее слово), что ли. Но мне повезло работать и маленьких, где было чуть больше двадцати человек, и вы весь на виду, все ваши удачи и неудачи - как на ладошке. И да, там было реально "как семья", и небольшие неудачи вам по-дружески прощаются, тут вы можете быть честным и откровенным (потому что в основном судить будут по делам, а не по словам), и основной принцип — просто не делать "*овна". Но сейчас по-моему таких очень мало, разве что стартап какой, где все сплошь энтузиасты своего дела и приоритетом является работа, а не карьера.
Кстати, в Германии обычно первые полгода — это обычно "пробецайт", ну то есть "пробное" время", и в течение этих месяцев (обычно шести) действуют упрощённые правила расторжения контракта, когда можно пробкой вылететь в один миг (это в контракте прописано), так что это время имеет смысл сидеть "тише воды, ниже травы" и просто качественно делать свою работу (внимательно присматриваясь что к чему).
Ну и всё вышесказанное не значит что "в большой компании всё плохо, а в маленькой - всё шоколадно". Бывает и так и сяк, и в большой насквозь прогнившей корпорации может быть "чудо-отдел", равно как и маленькая "семейная" компания может оказаться весьма нездоровой. В этом случае в большой можно попробовать поменять отдел, ну а из маленькой надо просто валить. И по внешним признакам бывает непросто распознать насколько здоров коллектив и как вы персонально в него вписываетесь (люди-то все разные). Опять же везде есть баланс "минусов и плюсов", кои можно отыскать и в большой компании. Но сразу с плеча рубить "правду-матку", наверное нигде не стоит, иногда ведь и "молчание-золото".
Ну а процесс "онбординга" в большой компании - это бывает и просто "стандартный чек лист", и вам никто не обязан отчитываться, просто уровнем выше на очередном митинге на капитанском мостике (куда вы не вхожи из вашего машинного отделения) ваш начальник коротко отрапортовывает "сотрудники такие-то проходят "онбординги", и ему надо проставить галочку да раскидать часы, на этот процесс потраченные, а все эти тесты да экзамены, равно как и фидбек — просто строчки этого чеклиста, только и всего.
На самом деле я немного "натянул сову на глобус". Дело в том, что LabVIEW сама по себе не совсем про симуляцию. Да, тулкит симуляции там есть, но он довольно "куцый" сам по себе, у вас навскидку значительно больше "высокоуровневых" кирпичиков, которых в LabVIEW просто нет. Но дьявол он в мелочах — мне с диаграммой работать проще чем в SimInTech (хотя тут действительно дело привычки). Кроме того, LabVIEW имеет уклон в сторону языка программирования общего назначения, ну то есть тут есть все стандартные конструкции - циклы for, while, структуры switch и т.д. В SimInTech это тоже есть, но сильно подозреваю, что вам придётся местами "спускаться" на уровень олдскульного текстовогоя языка, а тут это решено графически. Есть и ООП - классы, перегрузка методов, параллельность и необходимая синхронизация - очереди, семафоры, рандеву, акторы и куча всего. C точки зрения визуализации разделение на "переднюю панель/блок-диаграмму" даёт чуть больше свободы, да и GUI элементов тут побольше. Я бы посоветовал взять LabVIEW, можно либо community edition, она вообще бесплатна, а можно и Simulation Toolkit (но он на community скорей всего не встанет, вам проф может потребоваться), ну и критически посмотреть как оно там решено и "позаимствовать" хорошее что там есть на уровне идей, причём не "один в один", ведь как кто-то из великих сказал — "нет такой вещи, которую нельзя было бы улучшить", а LabVIEW в общем тоже далека от "идеала".
Вам имеет смысл действительно попробовать "встрять" в учебный процесс, и оттуда уже "прорастать" в промышленность. Так NI с LabVIEW в Германии поступает — почти каждый выпускник уни с ней поработал (и с Матлабом тоже). Что касается цен, то "спрос рождает предложение", кровавый энтерпрайз готов платить много и обильно, особенно если промышленности дело касается. Вот взять ту же LabVIEW — 4350. В год. Но это голая среда, к ней тулкиты ещё надо, Vision Development — ещё 2200, реалтайм c FPGA до кучи — 3260, ну и там мелочёвка OPC UA - ещё три сотни сверху. Вот и получите десяточку. У нас трое разрабов, так что тридцать тысяч евро в год улетает (хотя там есть скидки). А так, я в рамках соседнего топика с вашим тёзкой SimInTech покрутил, и был впечатлён, честно говоря, хотя я только нечёткую логику погонял с симуляцией водяного бака. Но в процессе экспериментов если честно, меня, привыкшего к LabVIEW, не покидало лёгкое ощущение того, что я как будто пересел с Texas Instruments TI-84 на Электроника МК-61. Но считает, да.
Всегда стоит попробовать, хотя не у всех попытки будут успешны. Я вот, как "правильный" папа-программист чуть ли не с пелёнок приготовил детишкам комп, поставил туда Scratch, и мы даже погоняли каких-то персонажей по экрану, но особого интереса честно говоря не возникло, ну я в общем и не стал настаивать, их как-то более музыка, искусство и языки заинтересовали. Впрочем программирование таки настигло их в одиннадцатом классе гимназии в виде Java (дело в Германии происходит). Я, кстати, не считаю Java идеальным для первого языка ввиду своей "объектоориентированности". Ну вот показывает моё чадо вот такой код, мол, смотри, папа, моя первая программа:
class HelloWorld {
public static void main(String[] args) {
System.out.println("Moin Moin, Welt!");
}
}
Я, само собой, ехидно поинтересовался, понимает ли ученик что такое "class", "public", "static" да "void" и почему "System.out.println()" а не просто "println()", на что последовал логичный ответ "нам так учитель сказал, пока просто запомнить". В это и проблема — для понимания этого надо иметь самое общее представление о принципах ООП, типах и т.д., а его пока нет, получается лёгкий "перекос" в последовательности изложения материала. Я б хотя бы с Си начал или там с Питона; в своё время в Политехе я так вообще с Фортрана начинал и потом Паскаль был, а Си я уже сам по K&R учил. Но в учебный процесс я не особо вмешиваюсь, всему своё время. У меня такое ощущение, что вся Германия на Java "помешана", потому что все выпускники, что приходят к нам на практику или на работу так или иначе в школе или институте это дело изучали, и учебник информатики я полистал, там тоже Java, и ООП там объясняется, но ближе к концу. Технически они там что-то в каком-то клоне BlueJ ваяют, чем-то отдалённо тот же Scratch напоминает, тоже всё раскрашено в весёлые цвета и картинки по экрану бегают.
Да, это знакомо, я несколько лет назад делал маленький "пет"-проект просмотрщика рентгеновских картинок в рамках изучения C#/WPF и там мне потребовалось пара несложных графиков — профиль интенсивности пикселов изображения по линии да гистограмма. Я попробовал все опенсорсные либы, до которых смог дотянуться, однако мне, привыкшеиу к графикам LabVIEW, всё чего-то не хватало, так что я кажется использовал две библиотеки для разных типов графиков (Interactive Data Display и LiveCharts, если мне не изменяет память). Сам писать не стал, потому что я уже делал это упражнение когда писал дипломную работу, и хорошо помню объём работы, особенно с размещением значений на осях, вот так, чтобы они не перекрывались, но и не очень редко стояли, всё аккуратно выравнивалось и т.п.
А, кстати, LDPC в LabVIEW тоже есть в составе LabVIEW Modulation Toolkit, вот так примерчик выглядит:
Он по виду в древней LabVIEW сделан, а в последних версиях добавили Silver и Fuze темы, так что теперь графики симпатичнее выглядит, вот Silver, например:
И да, можно зуммировать, скроллировать, ставить курсоры, менять внешний вид, в том числе программно, экспортировать данные в Excel буквально парой щелчков и т.д. LabVIEW (как и MATLAB) в принципе заточена под исследования и анализ данных, так что с графиками там всё более-менее норм, можно использовать как источник идей для своего проекта.
Эх, я в начале девяностых, будучи студентом, подрабатывал в ФТИ Иоффе (что напротив Политеха), в лаборатории Владимира Максимовича Тучкевича. Программировал на ДВК-3 и потом на ДВК-4, той что на КМ1801ВМ3, там где-то пять мегагерц было плюс минус. Когда я диплом писал, у меня уже топовая по тем временам конфигурация была с жёстким диском аж на двадцать мегабайт, мегабайтным RAM-диском и КЦГД. Рядом в ВЦ стоял VAX (11/780 кажется). И вот периодически долетали до меня слухи, что где-то в недрах Физтеха стоит тот самый Cray. Это произносилось с благоговейным придыханием "А ты уже видел Крей?". Кто-то из однокурсников даже говорил, что он на нём поработал и он рассказывал что там, вроде как первый, и ходили слухи, что будет (или есть) и второй. "Ты представляешь, там же МЕГАФЛОПСЫ", — говорил мне один друг с факультета технической кибернетики. В памяти отложилась цифра 80, а ДВК, я так думаю, и до одного мегафлопса не дотягивал, в лучшем случае сотни тысяч и то, если на сопроцессоре. Но я вживую этот мистический Крей так и не увидел, да даже не уверен, что он там был, впрочем кто знает. Мегафлопсы меня в то время не очень интересовали - я там дифрактометер, подключённый через КАМАК программировал. Прогресс, конечно потрясающий — на компе, что я пишу этот коммент — если верить Аиде, двести пятьдесят ГИГАфлопсов с двойной точностью на процессоре , плюс ещё восемьсот с лишним в GPU (и он далеко не топовый). Но я когда вижу все эти гигафлопсы с гигагерцами и терабайтами, то вспоминаю старушку ДВК с пятимегабайным диском, который постоянно стоял с открытым корпусом, потому что иногда головку приходилось самому за рычажок сбоку отводить в крайнее положение, иначе он стартовать ну никак не хотел.
Я ни в коей мере не проверял вас на знание теории автоматов, вы вполне в теме, я читаю ваши публикации и вы их иногда снабжаете списком литературы, я кое-что оттуда почерпнул, спасибо, кстати.
Да мы тут и не на экзамене, просто у вас весьма любопытный стиль мышления, я тут один из немногих, кто пытается понять. Если бы вы мыслили системно, то ответили бы иначе. Я вовсе не придираюсь, просто фразу о том, что автомат не выполнит умножение вы привели лишь после моего доказательства (спорить с ним, понятное дело бессмыссленно, ибо оно железобетонное). Ваш пассаж про y = a*b на петле я честно говоря тоже понять не в силах, ведь я говорил о двоичных числах, они прилетают вам порязрядно, и поразрядно же вы должны вернуть результат. Ну какое тут a*b, помилосердствуйте.
Про то, что заморочек с нулём в ВКПа не надо, я уже понял, хотя в любой нормальной системе я могу и имею полное право получать значения как до задержки, так и после, в том же LabVIEW я использую и так и сяк по ситуации (я бы мог тут спросить, не беспокоят ли вас в Си постфиксные и префиксные операции, но не буду). Ну получим чуть другой результат, там амплитудка повыше, тут чутка пониже да и "пох", как пару раз заметил тут коллега Вячеслав.
Ну а что касается И-НЕ элемента, то очевидным образом у него два состояния - 0 и 1, и для упрощения я положу ему четыре входа со всеми комбинациями значений х1х2 - 00 01 10 и 11, подключу их соответственно таблице истинности - 11 будет загонять его в состояние 0, остальные три - в 1, между ними он и будет прыгать. Рисовать лень, я с планшета отвечаю — два кружка да пара стрелочек, вот и весь разговор. Не вижу смысла что тут обсуждать. Вот нарисовать автомат, на примере которого показать правильную параллелизацию - значительно более интересно и полезно. Но тут мне надо подумать.
Нет, единственный и верный ответ, который я ожидал услышать — "Умножение двоичных чисел не может быть выполнено с помощью конечного автомата". Точка. А вот дальше уже можно было пускаться в пространные размышления, что де есть "классические" или "дебильные" конечные автоматы, а есть и другие в ВКПа, и на них оно будет вот так-то и так-то. Я, в общем, в курсе, как числа умножаются.
Ладно, оставим это. Что касается двух нулей, то у меня к ним претензий особых не было вроде бы. Я смею напомнить, что при первом подходе к снаряду вы считали правильным результат [0, 0, 2, 4, 10, 16, ...], но потом таки смогли смогли получить [0, 0, 2, 8, 22, 52, ...]. Получите же вы лидирующий ноль или нет - это зависит от того, в каком месте вы присасываетесь к данным, это легко достигается вот так:
(Я надеюсь, мне не нужно объяснять, что и в LabVIEW я получу ровно тот же результат перекладыванием одного-единственного проводочка).
Как вы готовите данные для сумматора на АВМ? Клапаны на проводочки врезаете? Тумблеры ставите? Сумматор берет значения со входов (какие есть) и выдает результат (с задержкой, блин!) на выход.
Лихо, безусловно. У меня вообще классические представления о программировании (коим я занимаюсь четверть века). Теория автоматов изучена вдоль и поперёк уж лет восемьдесят как, а про старину Эйлера, как заметил Вячеслав, я так вообще молчу, и после моего простого (но хитрого и подлого) вопроса-теоремы про умножение и вашего более чем уверенного ответа на него я таки позволю себе несколько усомниться в вашем новом определении модели автоматного программирования, равно как и знании и понимании, численных методов в том числе. Это не значит, что надо сидеть на багаже старых знаний и прогресс, безусловно надо двигать, но слегка в другом направлении.
Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли. Без проблем. Легко. Как бы Вы сказали, - лихо
Это сильное заявление, весьма сильное. Смотрите, предположим то, что такой конечный автомат реально существует. Пусть он имеет n состояний. Подадим на вход этого автомата два одинаковых двоичных числа 2^(n+1). Каждое из этих чисел записывается n+2 двоичными разрядами. Наш автомат, выполняющий умножение, получает на вход n+1 пар нулей, за которыми следует пара единиц — последовательное представление пары входных аргументов. Автомат (если он существует) должен выдать в качестве результата число 2^(2n+2), то есть он должен выдать 2n+2 нуля, за которыми следует единица. Иными словами, после того как автомат получит n+2 входных сигналов, он, перейдя в автономный режим, должен выдать ещё n нулей, за которыми он должен выдать единицу. Однако очевидно (уж вам должно быть точно), что никакой конечный автомат с n состояниями, работая в автономном режиме (под действием только входных сигналов синхронизации), не может выдать на выход n нулей, за которыми следует единица по той простой причине, что максимальный цикл в автомате с n состояниями ну никак не может превышать n. Вот и всё, приехали. Вообще невозможность построения такого автомата для решения этой проблемки является отражением того, что объём информации которую должен был бы "помнить" такой автомат, неограниченно растёт с ростом значений исходных чисел.
Другое дело — сложение, тут да, достаточно иметь только два состояния, одно из которых помнит наличие, а другое — отсутствие переноса в следующий разряд. Но я задал вопрос именно про умножение.
Её я читал, и вы там лихо проводите декомпозицию триггера (кстати, вы это сами придумали или где-нибудь вычитали?), но при этом у вас там появляются синхронизирующие связи (кажется в алгебраической теории это называется стягивающие компоненты для получения стягивающего действия и в некоторых случаях стягивающий автомат представляет собой именно задерживающий элемент) и наличие таких связей (а они появляются как раз из-за наличия обратной связи) мгновенно переводит параллельно декомпозированный автомат просто в форму групповых компонентов, как это и происходит в простейшем примере, что выдаёт нам 0, 2, 8, 22. Я там безусловно могу выполнить декомпозицию на два автомата, но у меня будет синхронизирующая связь, причём так устроенная, что прибьёт параллелизм на корню, я такие автоматы истинно параллельными не считаю. Где-то у меня дома валялась книжка, годов шестидесятых, Хартманис, кажется, надо будет почитать, равно как на досуге смастрячить пример конечного автомата, демонстрирующий истинную параллельность, это несложно должно быть.
Я всё равно считаю, что далеко не каждый автомат можно вот так вот запросто перевести в параллельную форму. Более того, не каждый алгоритм вообще можно переложить на автоматную модель. Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли.
Вы совершенно напрасно сомневаетесь, поскольку я взял на себя смелость утвержать, что всё, что вы сделали на С++ я могу реализовать и на LabVIEW, соответственно если вы смогли это дело надстроить над С++, то я смогу это повторить. У меня тоже есть ООП и классы, кроме того есть акторы в придачу, и три разных тулкита для конечных автоматов и один для симуляции. Более того я это ещё и визуально решу, так что вам в Visio не придётся рисовать автоматы, они будут прямо в среде. У меня был проект, в котором вся логика конечного автомата подгружалась извне, то есть один "генерализованный" автомат выполнял другой (там всё довольно просто, поскольку у нас всего две сущности — состояние и переход между ними).
Пробежав по простыне комментов выше, я вдруг задумался, откуда вы по большому счёту вообще всё это взяли? Ну не могли вы сами придумать вот это вот всё то, что ваш тёзка вежливо называет "бесмысленными забредушками". Сегодня утром за чашкой кофе я решил таки освежить свои знания теории автоматов да полистал учебники, и кажется понял.
Да, верно, есть такая штука, как последовательная и параллельная декомпозиции конечных автоматов. И говоря о том, "последовательна" или "параллельна" система вы судя по всему имеете ввиду именно эти декомпозиции, утверждая при этом ВКПа истинно параллельна. И про вопрос о задержках я теперь понял, вы имеете ввиду их распространение в таких средах, перефразируя, можно ли меняя задержки выяснить, выполена ли последовательная или параллельная декомпозиции? Действительно, вы имеете полное право проводить параллельную декомпозицию конечных автоматов, но с одной малюсенькой оговоркой. Полученные параллельные автоматы должны быть ортогонально конгруэнтны. Формально выражаясь языком учебника "если на множестве состояний автомата А существует две ортогональные конгруэнции а1 и а2, то пара независимо работающих фактор-автоматов А/а1 и А/а2 реализуют исходный автомат А", и это можно доказать. Таким образом для выполнения параллельной декомпозиции конечного автомата необходимо произвести поиск конгруэнций, построить диаграммы Хассе решёток конгруэнции и лишь после этого параллелить.
С какого-то перепугу вы решили что можете произвести параллельную декомпозицию вообще любого конечного автомата. Но поскольку далеко не в каждом автомате можно изыскать ортогональные конгруэнции, и вы привносите их искусственно, добавляя "задержки", попутно аргументируя их мистической "инерционностью процессов". Внесённые задержки судя по всему двигают состояния по графу, делая возможной параллельную декомпозицию, вот только результат иногда не очень, и вы начинаете постить графики "в вашей последовательной среде вот так, а в моём параллельном мире вот этак" и давайте объясните мне, почему бы это. Вот как буквально только что — вы спрашиваете куда делся дополнительный ноль в последовательности 0, 2, 8, 22. Я же привёл вам Си код выше, там ровно десять строчек, посмотрите. А у вас 0, 0, 2, 8 и вы не можете понять откуда он берётся в вашей же среде? Сильно подозреваю, что вы снова сместились на такт и он выплюнул вам дополнительный нуль. Вообще для этого обычно существует режим пошаговой отладки.
Вопросы декомпозиции автоматов рассматриваются в куче учебников (в том числе вопросы генеральной параллелизации автоматов). В реальной же жизни мы прагматически смотрим на систему и просто и смело параллелим то, что параллелится и не трогаем то, что трогать не надо, вот и всё. При этом мы не анализируем дотошно, но в теории да, можно проанализировать и найти все суб-автоматы, которые могут быть выполнены параллельно. На самом деле LabVIEW частично делает это за меня, анализируя граф выполнения блок-диаграммы, разбивая его на "чанки", которые и выполняются параллельно (при этом она достаточно умна, чтобы не параллелить всё и вся, а лишь то, где я получу выигрыш) и само собой разумеется на конечный результат это влиять не будет. Кстати, хорошая мысль, в том проекте, где автомат конфигурируется "налету" я действительно могу провести такой анализ.
Если всему, что вы пишете про "абсолютный параллелизм" есть формальное теоретическое обоснование, ткните меня носом в учебник и параграф, в котором эта теория изложена и строго доказана, я с удовольствием почитаю на досуге.
все, что считается/моделируется в SimInTech будет считаться/моделироваться и в ВКПа.
Кстати, справедливо и обратное утверждение — все, что считается/моделируется в ВКПа будет считаться/моделироваться и в SimInTech. И даже если относительная высокоуровневость SimInTech не позволит что-либо реализовать (я не профи в этом), то можно перефразировать как "все, что считается/моделируется в ВКПа будет считаться/моделироваться и в LabVIEW". Есть пакет Control Design and Simulation Module. Если мне по какой-то причине не хватит его возможностей, я спущусь на уровень ниже и допишу недостающее прямо в LabVIEW, со всеми необходимыми параллельностями, задержками, активными объектами и автоматами. Если же мне не хватит возможностей (или производительности) LabVIEW, я спущусь ещё ниже ниже и напишу недостающее на Си, сделаю библиотеки и подключу их. На чём сама по себе ВКПа написана-то? На некошерных плюсплюсах вроде, насколько я знаю? "Надстроить" ВКПа можно и в LabVIEW, но зачем?. И я помню триггер, и по-моему всё, что вы попросили меня продемонстрировать, я вам тогда показал и объяснил.
Я старательно пытаюсь разобраться в этом потоке сознания, но не могу.
задержка нужна для моделирования инерционности процессов. Процессов, но не обычных расчетов. Еще раз - процессов. Еще раз - процессов!!! Их иненрционность - святое.
Инерционность инерционности рознь. Я примерно в курсе как бороться с инерционностью процесса, скажем используя предиктор Смита (пятьдесят седьмой год, кстати), но слабо вкуриваю, как можно делать это тривиальными тактовыми задержками. Где-то это и будет работать, но далеко не везде.
сложнность ни чем не ограничивается. Нужен миллион сложений - используйте миллион. Но учитывайте, что этот миллион требует тоже времени. И это время не должно превышать время дискретного такта. А если время такта маленькое в силу необходимости, то этот миллион разделяется на части
Вообще всё в кучу. Если я моделирую процес срабатывания воздушной подушки, что составляет миллисекунды, то мне нафиг не упало укладываться в те же миллисекунды процессорного времени. Если мне нужны сутки для обсчёта, пусть будут сутки, главное - реалистичный и адекватный результат. Реалтайм-то хоть не трогайте.
должна быть правильная работа с памятью.
Правильная работа с памятью - это понимание атомарности, спинлоков, состояния гонок, и т.д. и т.п., это-то всё тут при чём? Я в общем хорошо понимаю как устроена и работает та железка, на которой я пишу этот коммент. У вас там в ВКПа я слышал есть теневые переменные или теневая память, или как-то так, я сильно подозреваю для хранения всяких данных во время задержек, используемых для борьбы со святой инерционностью процессов, но к "правильной работе с памятью" это слабо относится. Давайте ешё кеш сюда до кучи добавим, что ли.
На мой взгляд, вы всё, вообще всё смешали в одной большой кастрюле и теперь вывариваете это дело на медленном огне.
Минимальнейшая конфигурация, на которой у меня крутится 24Н2 это Acer Aspire XC-105 c AMD камушком, ему чуть больше одиннадцати лет, я ему память до 8 ГБ проапгрейдил:
Но мне просто потребовался комп с голой ОС для подключения кой-каких USB накопителей, плюс я хотел просто "потестить" LTSC на древнем железе. Даже если просто подключиться к нему через RDP, то уже загрузка процессора улетает в 50%. Работать на нём - ну такое себе.
Нет проблем, лишь бы они висели на одной фазе. Но даже если не на одной, то есть такая штука:
Правда она скорость роняет. В моём случае через розетки где-то 60-70 мегабит, а через фазу - скорость падала вдвое, так что я все комнаты где интернет через розетки, на одну фазу повесил. Чем длиннее линия, тем ниже скорость. Но у меня модули очень старенькие стоят, им лет пятнадцать уже.
Да, выросли. Я б не сказал что "вдвое", но раза в полтора (мука, молоко, сыр, масло), пожалуй да, что есть, то есть. Вот тут есть табличка в Экселе, правда на немецком, но переводится легко. Хотя сейчас вроде потихоньку начинают падать, но очень слегка.
Справедливости ради надо отметить, что когда я приезжаю в Россию (в Питер) со своей "немецкой" зарплатой и банально иду там в магазин, да хоть в тот же "Ашан" или "Азбуку вкуса" или что там ещё сейчас есть, то не то чтобы чувствую себя нищебродом, но оставляю там сумму, сравнимую с немецкой, покупая там набор продуктов и вкусняшек, к которым привык в Германии. Рестораны тоже примерно в одной ценовой категории. Может, если в "Пятёрочке" отовариваться то разница будет существенная, а так - сравнимо (местами даже дороже чем в Германии или Италии). Но "в комплексе" (с расходами на жильё, транспорт и т.п.) мне тяжело сравнивать, я уже почти четверть века в Германии живу. В Европе тоже не везде одинаково - во Франции заметно дороже, а про Норвегию так я вообще молчу.
О, я так не думаю, если брать интеловские компиляторы, то на плюс минус одинаковых вычислениях что фортран, что си выдадут скорее всего плюс-минус одинаковый компилят и всё упрётся в производительность процессора. Вот первый попавшийся под руку бенчмарк. Что же касается симуляции, то там придётся овердофига кода положить, так как из коробки в фортране необходимых численных методов вероятно нет. И если для того же Рунге-Кутта с переменным шагом ещё можно найти библиотеки, то "обвязку", вероятно придётся писать заново. Я так полагаю, что фортран поддерживается из-за большого количества уже существующего кода (это был первый язык, который я в Политехе учил в прошлом веке), но в активной разработке современных проектов я его давно не встречал. А современные инструменты сильно высокоуровневые, там симуляция буквально в несколько кликов собирается, а "оверхед" компенсируется высокой скоростью современных процессоров. Ну и вычислительное ядро - как правило оптимизированные библиотечные функции, в LabVIEW точно также - есля я соберу симуляцию на нативных примитивах LabVIEW, то результата вероятно вообще не дождусь.
Вообще это то, что нынче называется модным "софт-скиллс". Если вы устроились в "одну очень большую компанию", то надо понимать специфику работы в такой компании. Их очень много, таких специфических моментов. И если говорить о "продвижении по службе", то одно из первых правил успешного карьерного роста — это говорить "правильные" слова, правильному человеку и в правильный момент времени. Высший пилотаж - скажем при съезде менеджеров из головного офиса вычленить "правильного" решающего менеджера, затем на обеденном перерыве подгадать момент, подсесть к нему и вежливо "разрешите представиться, я тут программист такой-то...", и пошла-поехала карьера в гору (если повезёт). Сотрудники на одном с вами грейде это, конечно будут видеть, мол, вот жеж Н, хитрая лиса, ты смотри... Надо уметь "толкаться", как сказал кто-то. Я это видел много раз, так как в IT четверть века и работал в "больших" компаниях (100К+ сотрудников). Это дано не всем, тут надо иметь определённый запас этих самых "софт скиллс" (сами вставьте подходящее слово), что ли. Но мне повезло работать и маленьких, где было чуть больше двадцати человек, и вы весь на виду, все ваши удачи и неудачи - как на ладошке. И да, там было реально "как семья", и небольшие неудачи вам по-дружески прощаются, тут вы можете быть честным и откровенным (потому что в основном судить будут по делам, а не по словам), и основной принцип — просто не делать "*овна". Но сейчас по-моему таких очень мало, разве что стартап какой, где все сплошь энтузиасты своего дела и приоритетом является работа, а не карьера.
Кстати, в Германии обычно первые полгода — это обычно "пробецайт", ну то есть "пробное" время", и в течение этих месяцев (обычно шести) действуют упрощённые правила расторжения контракта, когда можно пробкой вылететь в один миг (это в контракте прописано), так что это время имеет смысл сидеть "тише воды, ниже травы" и просто качественно делать свою работу (внимательно присматриваясь что к чему).
Ну и всё вышесказанное не значит что "в большой компании всё плохо, а в маленькой - всё шоколадно". Бывает и так и сяк, и в большой насквозь прогнившей корпорации может быть "чудо-отдел", равно как и маленькая "семейная" компания может оказаться весьма нездоровой. В этом случае в большой можно попробовать поменять отдел, ну а из маленькой надо просто валить. И по внешним признакам бывает непросто распознать насколько здоров коллектив и как вы персонально в него вписываетесь (люди-то все разные). Опять же везде есть баланс "минусов и плюсов", кои можно отыскать и в большой компании. Но сразу с плеча рубить "правду-матку", наверное нигде не стоит, иногда ведь и "молчание-золото".
Ну а процесс "онбординга" в большой компании - это бывает и просто "стандартный чек лист", и вам никто не обязан отчитываться, просто уровнем выше на очередном митинге на капитанском мостике (куда вы не вхожи из вашего машинного отделения) ваш начальник коротко отрапортовывает "сотрудники такие-то проходят "онбординги", и ему надо проставить галочку да раскидать часы, на этот процесс потраченные, а все эти тесты да экзамены, равно как и фидбек — просто строчки этого чеклиста, только и всего.
На самом деле я немного "натянул сову на глобус". Дело в том, что LabVIEW сама по себе не совсем про симуляцию. Да, тулкит симуляции там есть, но он довольно "куцый" сам по себе, у вас навскидку значительно больше "высокоуровневых" кирпичиков, которых в LabVIEW просто нет. Но дьявол он в мелочах — мне с диаграммой работать проще чем в SimInTech (хотя тут действительно дело привычки). Кроме того, LabVIEW имеет уклон в сторону языка программирования общего назначения, ну то есть тут есть все стандартные конструкции - циклы for, while, структуры switch и т.д. В SimInTech это тоже есть, но сильно подозреваю, что вам придётся местами "спускаться" на уровень олдскульного текстовогоя языка, а тут это решено графически. Есть и ООП - классы, перегрузка методов, параллельность и необходимая синхронизация - очереди, семафоры, рандеву, акторы и куча всего. C точки зрения визуализации разделение на "переднюю панель/блок-диаграмму" даёт чуть больше свободы, да и GUI элементов тут побольше. Я бы посоветовал взять LabVIEW, можно либо community edition, она вообще бесплатна, а можно и Simulation Toolkit (но он на community скорей всего не встанет, вам проф может потребоваться), ну и критически посмотреть как оно там решено и "позаимствовать" хорошее что там есть на уровне идей, причём не "один в один", ведь как кто-то из великих сказал — "нет такой вещи, которую нельзя было бы улучшить", а LabVIEW в общем тоже далека от "идеала".
Вам имеет смысл действительно попробовать "встрять" в учебный процесс, и оттуда уже "прорастать" в промышленность. Так NI с LabVIEW в Германии поступает — почти каждый выпускник уни с ней поработал (и с Матлабом тоже). Что касается цен, то "спрос рождает предложение", кровавый энтерпрайз готов платить много и обильно, особенно если промышленности дело касается. Вот взять ту же LabVIEW — 4350. В год. Но это голая среда, к ней тулкиты ещё надо, Vision Development — ещё 2200, реалтайм c FPGA до кучи — 3260, ну и там мелочёвка OPC UA - ещё три сотни сверху. Вот и получите десяточку. У нас трое разрабов, так что тридцать тысяч евро в год улетает (хотя там есть скидки). А так, я в рамках соседнего топика с вашим тёзкой SimInTech покрутил, и был впечатлён, честно говоря, хотя я только нечёткую логику погонял с симуляцией водяного бака. Но в процессе экспериментов если честно, меня, привыкшего к LabVIEW, не покидало лёгкое ощущение того, что я как будто пересел с Texas Instruments TI-84 на Электроника МК-61. Но считает, да.
Всегда стоит попробовать, хотя не у всех попытки будут успешны. Я вот, как "правильный" папа-программист чуть ли не с пелёнок приготовил детишкам комп, поставил туда Scratch, и мы даже погоняли каких-то персонажей по экрану, но особого интереса честно говоря не возникло, ну я в общем и не стал настаивать, их как-то более музыка, искусство и языки заинтересовали. Впрочем программирование таки настигло их в одиннадцатом классе гимназии в виде Java (дело в Германии происходит). Я, кстати, не считаю Java идеальным для первого языка ввиду своей "объектоориентированности". Ну вот показывает моё чадо вот такой код, мол, смотри, папа, моя первая программа:
Я, само собой, ехидно поинтересовался, понимает ли ученик что такое "class", "public", "static" да "void" и почему "System.out.println()" а не просто "println()", на что последовал логичный ответ "нам так учитель сказал, пока просто запомнить". В это и проблема — для понимания этого надо иметь самое общее представление о принципах ООП, типах и т.д., а его пока нет, получается лёгкий "перекос" в последовательности изложения материала. Я б хотя бы с Си начал или там с Питона; в своё время в Политехе я так вообще с Фортрана начинал и потом Паскаль был, а Си я уже сам по K&R учил. Но в учебный процесс я не особо вмешиваюсь, всему своё время. У меня такое ощущение, что вся Германия на Java "помешана", потому что все выпускники, что приходят к нам на практику или на работу так или иначе в школе или институте это дело изучали, и учебник информатики я полистал, там тоже Java, и ООП там объясняется, но ближе к концу. Технически они там что-то в каком-то клоне BlueJ ваяют, чем-то отдалённо тот же Scratch напоминает, тоже всё раскрашено в весёлые цвета и картинки по экрану бегают.
Да, это знакомо, я несколько лет назад делал маленький "пет"-проект просмотрщика рентгеновских картинок в рамках изучения C#/WPF и там мне потребовалось пара несложных графиков — профиль интенсивности пикселов изображения по линии да гистограмма. Я попробовал все опенсорсные либы, до которых смог дотянуться, однако мне, привыкшеиу к графикам LabVIEW, всё чего-то не хватало, так что я кажется использовал две библиотеки для разных типов графиков (Interactive Data Display и LiveCharts, если мне не изменяет память). Сам писать не стал, потому что я уже делал это упражнение когда писал дипломную работу, и хорошо помню объём работы, особенно с размещением значений на осях, вот так, чтобы они не перекрывались, но и не очень редко стояли, всё аккуратно выравнивалось и т.п.
А, кстати, LDPC в LabVIEW тоже есть в составе LabVIEW Modulation Toolkit, вот так примерчик выглядит:
Он по виду в древней LabVIEW сделан, а в последних версиях добавили Silver и Fuze темы, так что теперь графики симпатичнее выглядит, вот Silver, например:
И да, можно зуммировать, скроллировать, ставить курсоры, менять внешний вид, в том числе программно, экспортировать данные в Excel буквально парой щелчков и т.д. LabVIEW (как и MATLAB) в принципе заточена под исследования и анализ данных, так что с графиками там всё более-менее норм, можно использовать как источник идей для своего проекта.
Эх, я в начале девяностых, будучи студентом, подрабатывал в ФТИ Иоффе (что напротив Политеха), в лаборатории Владимира Максимовича Тучкевича. Программировал на ДВК-3 и потом на ДВК-4, той что на КМ1801ВМ3, там где-то пять мегагерц было плюс минус. Когда я диплом писал, у меня уже топовая по тем временам конфигурация была с жёстким диском аж на двадцать мегабайт, мегабайтным RAM-диском и КЦГД. Рядом в ВЦ стоял VAX (11/780 кажется). И вот периодически долетали до меня слухи, что где-то в недрах Физтеха стоит тот самый Cray. Это произносилось с благоговейным придыханием "А ты уже видел Крей?". Кто-то из однокурсников даже говорил, что он на нём поработал и он рассказывал что там, вроде как первый, и ходили слухи, что будет (или есть) и второй. "Ты представляешь, там же МЕГАФЛОПСЫ", — говорил мне один друг с факультета технической кибернетики. В памяти отложилась цифра 80, а ДВК, я так думаю, и до одного мегафлопса не дотягивал, в лучшем случае сотни тысяч и то, если на сопроцессоре. Но я вживую этот мистический Крей так и не увидел, да даже не уверен, что он там был, впрочем кто знает. Мегафлопсы меня в то время не очень интересовали - я там дифрактометер, подключённый через КАМАК программировал. Прогресс, конечно потрясающий — на компе, что я пишу этот коммент — если верить Аиде, двести пятьдесят ГИГАфлопсов с двойной точностью на процессоре , плюс ещё восемьсот с лишним в GPU (и он далеко не топовый). Но я когда вижу все эти гигафлопсы с гигагерцами и терабайтами, то вспоминаю старушку ДВК с пятимегабайным диском, который постоянно стоял с открытым корпусом, потому что иногда головку приходилось самому за рычажок сбоку отводить в крайнее положение, иначе он стартовать ну никак не хотел.
Я ни в коей мере не проверял вас на знание теории автоматов, вы вполне в теме, я читаю ваши публикации и вы их иногда снабжаете списком литературы, я кое-что оттуда почерпнул, спасибо, кстати.
Да мы тут и не на экзамене, просто у вас весьма любопытный стиль мышления, я тут один из немногих, кто пытается понять. Если бы вы мыслили системно, то ответили бы иначе. Я вовсе не придираюсь, просто фразу о том, что автомат не выполнит умножение вы привели лишь после моего доказательства (спорить с ним, понятное дело бессмыссленно, ибо оно железобетонное). Ваш пассаж про y = a*b на петле я честно говоря тоже понять не в силах, ведь я говорил о двоичных числах, они прилетают вам порязрядно, и поразрядно же вы должны вернуть результат. Ну какое тут a*b, помилосердствуйте.
Про то, что заморочек с нулём в ВКПа не надо, я уже понял, хотя в любой нормальной системе я могу и имею полное право получать значения как до задержки, так и после, в том же LabVIEW я использую и так и сяк по ситуации (я бы мог тут спросить, не беспокоят ли вас в Си постфиксные и префиксные операции, но не буду). Ну получим чуть другой результат, там амплитудка повыше, тут чутка пониже да и "пох", как пару раз заметил тут коллега Вячеслав.
Ну а что касается И-НЕ элемента, то очевидным образом у него два состояния - 0 и 1, и для упрощения я положу ему четыре входа со всеми комбинациями значений х1х2 - 00 01 10 и 11, подключу их соответственно таблице истинности - 11 будет загонять его в состояние 0, остальные три - в 1, между ними он и будет прыгать. Рисовать лень, я с планшета отвечаю — два кружка да пара стрелочек, вот и весь разговор. Не вижу смысла что тут обсуждать. Вот нарисовать автомат, на примере которого показать правильную параллелизацию - значительно более интересно и полезно. Но тут мне надо подумать.
Нет, единственный и верный ответ, который я ожидал услышать — "Умножение двоичных чисел не может быть выполнено с помощью конечного автомата". Точка. А вот дальше уже можно было пускаться в пространные размышления, что де есть "классические" или "дебильные" конечные автоматы, а есть и другие в ВКПа, и на них оно будет вот так-то и так-то. Я, в общем, в курсе, как числа умножаются.
Ладно, оставим это. Что касается двух нулей, то у меня к ним претензий особых не было вроде бы. Я смею напомнить, что при первом подходе к снаряду вы считали правильным результат [0, 0, 2, 4, 10, 16, ...], но потом таки смогли смогли получить [0, 0, 2, 8, 22, 52, ...]. Получите же вы лидирующий ноль или нет - это зависит от того, в каком месте вы присасываетесь к данным, это легко достигается вот так:
(Я надеюсь, мне не нужно объяснять, что и в LabVIEW я получу ровно тот же результат перекладыванием одного-единственного проводочка).
Тут, по-моему, только статьёй из Википедии ответить можно — Программирование потоков данных.
Кстати, АВМ — это Артерио Венозные Мальформации головного мозга, от которых я уже недалёк, читая это обсуждение.
Лихо, безусловно. У меня вообще классические представления о программировании (коим я занимаюсь четверть века). Теория автоматов изучена вдоль и поперёк уж лет восемьдесят как, а про старину Эйлера, как заметил Вячеслав, я так вообще молчу, и после моего простого (но хитрого и подлого) вопроса-теоремы про умножение и вашего более чем уверенного ответа на него я таки позволю себе несколько усомниться в вашем новом определении модели автоматного программирования, равно как и знании и понимании, численных методов в том числе. Это не значит, что надо сидеть на багаже старых знаний и прогресс, безусловно надо двигать, но слегка в другом направлении.
Это сильное заявление, весьма сильное. Смотрите, предположим то, что такой конечный автомат реально существует. Пусть он имеет n состояний. Подадим на вход этого автомата два одинаковых двоичных числа 2^(n+1). Каждое из этих чисел записывается n+2 двоичными разрядами. Наш автомат, выполняющий умножение, получает на вход n+1 пар нулей, за которыми следует пара единиц — последовательное представление пары входных аргументов. Автомат (если он существует) должен выдать в качестве результата число 2^(2n+2), то есть он должен выдать 2n+2 нуля, за которыми следует единица. Иными словами, после того как автомат получит n+2 входных сигналов, он, перейдя в автономный режим, должен выдать ещё n нулей, за которыми он должен выдать единицу. Однако очевидно (уж вам должно быть точно), что никакой конечный автомат с n состояниями, работая в автономном режиме (под действием только входных сигналов синхронизации), не может выдать на выход n нулей, за которыми следует единица по той простой причине, что максимальный цикл в автомате с n состояниями ну никак не может превышать n. Вот и всё, приехали. Вообще невозможность построения такого автомата для решения этой проблемки является отражением того, что объём информации которую должен был бы "помнить" такой автомат, неограниченно растёт с ростом значений исходных чисел.
Другое дело — сложение, тут да, достаточно иметь только два состояния, одно из которых помнит наличие, а другое — отсутствие переноса в следующий разряд. Но я задал вопрос именно про умножение.
Её я читал, и вы там лихо проводите декомпозицию триггера (кстати, вы это сами придумали или где-нибудь вычитали?), но при этом у вас там появляются синхронизирующие связи (кажется в алгебраической теории это называется стягивающие компоненты для получения стягивающего действия и в некоторых случаях стягивающий автомат представляет собой именно задерживающий элемент) и наличие таких связей (а они появляются как раз из-за наличия обратной связи) мгновенно переводит параллельно декомпозированный автомат просто в форму групповых компонентов, как это и происходит в простейшем примере, что выдаёт нам 0, 2, 8, 22. Я там безусловно могу выполнить декомпозицию на два автомата, но у меня будет синхронизирующая связь, причём так устроенная, что прибьёт параллелизм на корню, я такие автоматы истинно параллельными не считаю. Где-то у меня дома валялась книжка, годов шестидесятых, Хартманис, кажется, надо будет почитать, равно как на досуге смастрячить пример конечного автомата, демонстрирующий истинную параллельность, это несложно должно быть.
Я всё равно считаю, что далеко не каждый автомат можно вот так вот запросто перевести в параллельную форму. Более того, не каждый алгоритм вообще можно переложить на автоматную модель. Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли.
Вы совершенно напрасно сомневаетесь, поскольку я взял на себя смелость утвержать, что всё, что вы сделали на С++ я могу реализовать и на LabVIEW, соответственно если вы смогли это дело надстроить над С++, то я смогу это повторить. У меня тоже есть ООП и классы, кроме того есть акторы в придачу, и три разных тулкита для конечных автоматов и один для симуляции. Более того я это ещё и визуально решу, так что вам в Visio не придётся рисовать автоматы, они будут прямо в среде. У меня был проект, в котором вся логика конечного автомата подгружалась извне, то есть один "генерализованный" автомат выполнял другой (там всё довольно просто, поскольку у нас всего две сущности — состояние и переход между ними).
Пробежав по простыне комментов выше, я вдруг задумался, откуда вы по большому счёту вообще всё это взяли? Ну не могли вы сами придумать вот это вот всё то, что ваш тёзка вежливо называет "бесмысленными забредушками". Сегодня утром за чашкой кофе я решил таки освежить свои знания теории автоматов да полистал учебники, и кажется понял.
Да, верно, есть такая штука, как последовательная и параллельная декомпозиции конечных автоматов. И говоря о том, "последовательна" или "параллельна" система вы судя по всему имеете ввиду именно эти декомпозиции, утверждая при этом ВКПа истинно параллельна. И про вопрос о задержках я теперь понял, вы имеете ввиду их распространение в таких средах, перефразируя, можно ли меняя задержки выяснить, выполена ли последовательная или параллельная декомпозиции? Действительно, вы имеете полное право проводить параллельную декомпозицию конечных автоматов, но с одной малюсенькой оговоркой. Полученные параллельные автоматы должны быть ортогонально конгруэнтны. Формально выражаясь языком учебника "если на множестве состояний автомата А существует две ортогональные конгруэнции а1 и а2, то пара независимо работающих фактор-автоматов А/а1 и А/а2 реализуют исходный автомат А", и это можно доказать. Таким образом для выполнения параллельной декомпозиции конечного автомата необходимо произвести поиск конгруэнций, построить диаграммы Хассе решёток конгруэнции и лишь после этого параллелить.
С какого-то перепугу вы решили что можете произвести параллельную декомпозицию вообще любого конечного автомата. Но поскольку далеко не в каждом автомате можно изыскать ортогональные конгруэнции, и вы привносите их искусственно, добавляя "задержки", попутно аргументируя их мистической "инерционностью процессов". Внесённые задержки судя по всему двигают состояния по графу, делая возможной параллельную декомпозицию, вот только результат иногда не очень, и вы начинаете постить графики "в вашей последовательной среде вот так, а в моём параллельном мире вот этак" и давайте объясните мне, почему бы это. Вот как буквально только что — вы спрашиваете куда делся дополнительный ноль в последовательности 0, 2, 8, 22. Я же привёл вам Си код выше, там ровно десять строчек, посмотрите. А у вас 0, 0, 2, 8 и вы не можете понять откуда он берётся в вашей же среде? Сильно подозреваю, что вы снова сместились на такт и он выплюнул вам дополнительный нуль. Вообще для этого обычно существует режим пошаговой отладки.
Вопросы декомпозиции автоматов рассматриваются в куче учебников (в том числе вопросы генеральной параллелизации автоматов). В реальной же жизни мы прагматически смотрим на систему и просто и смело параллелим то, что параллелится и не трогаем то, что трогать не надо, вот и всё. При этом мы не анализируем дотошно, но в теории да, можно проанализировать и найти все суб-автоматы, которые могут быть выполнены параллельно. На самом деле LabVIEW частично делает это за меня, анализируя граф выполнения блок-диаграммы, разбивая его на "чанки", которые и выполняются параллельно (при этом она достаточно умна, чтобы не параллелить всё и вся, а лишь то, где я получу выигрыш) и само собой разумеется на конечный результат это влиять не будет. Кстати, хорошая мысль, в том проекте, где автомат конфигурируется "налету" я действительно могу провести такой анализ.
Если всему, что вы пишете про "абсолютный параллелизм" есть формальное теоретическое обоснование, ткните меня носом в учебник и параграф, в котором эта теория изложена и строго доказана, я с удовольствием почитаю на досуге.
Кстати, справедливо и обратное утверждение — все, что считается/моделируется в ВКПа будет считаться/моделироваться и в SimInTech. И даже если относительная высокоуровневость SimInTech не позволит что-либо реализовать (я не профи в этом), то можно перефразировать как "все, что считается/моделируется в ВКПа будет считаться/моделироваться и в LabVIEW". Есть пакет Control Design and Simulation Module. Если мне по какой-то причине не хватит его возможностей, я спущусь на уровень ниже и допишу недостающее прямо в LabVIEW, со всеми необходимыми параллельностями, задержками, активными объектами и автоматами. Если же мне не хватит возможностей (или производительности) LabVIEW, я спущусь ещё ниже ниже и напишу недостающее на Си, сделаю библиотеки и подключу их. На чём сама по себе ВКПа написана-то? На некошерных плюсплюсах вроде, насколько я знаю? "Надстроить" ВКПа можно и в LabVIEW, но зачем?. И я помню триггер, и по-моему всё, что вы попросили меня продемонстрировать, я вам тогда показал и объяснил.
Я старательно пытаюсь разобраться в этом потоке сознания, но не могу.
Инерционность инерционности рознь. Я примерно в курсе как бороться с инерционностью процесса, скажем используя предиктор Смита (пятьдесят седьмой год, кстати), но слабо вкуриваю, как можно делать это тривиальными тактовыми задержками. Где-то это и будет работать, но далеко не везде.
Вообще всё в кучу. Если я моделирую процес срабатывания воздушной подушки, что составляет миллисекунды, то мне нафиг не упало укладываться в те же миллисекунды процессорного времени. Если мне нужны сутки для обсчёта, пусть будут сутки, главное - реалистичный и адекватный результат. Реалтайм-то хоть не трогайте.
Правильная работа с памятью - это понимание атомарности, спинлоков, состояния гонок, и т.д. и т.п., это-то всё тут при чём? Я в общем хорошо понимаю как устроена и работает та железка, на которой я пишу этот коммент. У вас там в ВКПа я слышал есть теневые переменные или теневая память, или как-то так, я сильно подозреваю для хранения всяких данных во время задержек, используемых для борьбы со святой инерционностью процессов, но к "правильной работе с памятью" это слабо относится. Давайте ешё кеш сюда до кучи добавим, что ли.
На мой взгляд, вы всё, вообще всё смешали в одной большой кастрюле и теперь вывариваете это дело на медленном огне.