Golang Framework

[kichay.d]

Добрый день.

Хочу более подробно разобраться с опцяами выполнения для VI. Конкретно интересует:
1. Non-reentrant execution (тут я предполагаю, что конкретный VI будет подобен классу, а каждое появление этого VI в виде SubVI на диаграмме равносильно раздельным инстансам со своими раздельными стейтами и памятью)
2. Shared clone reentrant execution (тут я предполагаю, что для всех включений VI реализован только один инстанс, который со своим общим стейтом работает на всех, тут у меня непонятки, как этот стейт может консистентно использоваться несколькими потоками одновременно.)
3. Preallocated clone reentrant execution (тут просто не понимаю что это, и что там заранее аллоцировали)
4. Suspend when called (подозреваю, что VI встаёт на паузу при выполнении, а может и нет, не понятно...)
5. Clear indicators when called (тут вертоятно задаётся какое-то поведение типа принудительной инициализации для индикаторов перед запуском (а может и не только). Кто именно страсывается до дефолтов, только индикаторы? А что с контролами? Что со сдвиговыми регистрами циклов, что в FeedbackNode?)
6. Auto handle menus at launch (тут тоже ничего не понимаю)

Помогите разобраться, что это и зачем...

Скриншот:

[IvanLis]

Помогите разобраться, что это и зачем...

Execution Page (VI Properties Dialog Box)
Там все написано достаточно подробно.
С правой частью вкладки думаю проблем не будет.
Что касается настроек реентерабельности, во еще пояснения:
Differences Between Reentrant ....

Если совсем коротко
Non-reentrant - функция исполняется в единственном экземпляре, а если используется в нескольких местах программы, то по очереди.
Shared clone - при запуске программы создается один независимый экземпляр, потом по необходимости еще. По этому одна функция может выполняться в нескольких местах программы (разделяемая память), а могут одновременно работать несколько экземпляров.
Preallocated clone - это случай, когда программа знает точно, сколько экземпляров функции должно работать и создает их и запускает все сразу, при запуске программы (память у каждого независимая).

[kichay.d]

Стало ясно, где искать документацию. Спасибо!

Теперь остался один вопрос, почему в современных реалях, когда на компьютерах нет проблем с памятью и многопоточный процессор, preallocated схема не является стандартно используемой?
Зачем выполнять что-то последовательно, да ещё и с риском переиспользовать чужой стейт в случае ошибки разработчика или то просить операционную систему выделить память, а потом отдавать ей обратно?
Ведь само периодическое выделение памяти с последующим освобождением вызывает значительные проблемы с производительностью, операционная система не готова делать это мгновенно, особенно конкурируя с кэшем для работы с дисковой подсистемой (кеширование в "свободную" память). Создаётся значительная фрагментация физической памяти, увеличивается количество промахов в TLB кэше процессора.
Если же организовать свой внутренний аллокатор памяти из своего внутреннего заранее зарезервированного у ОС пула, то тут также имеет место быть фрагментация, но дополнительно будет тратиться процессороное время на резолв таблицы соответствия.

[IvanLis]

Стало ясно, где искать документацию. Спасибо!

Теперь остался один вопрос, почему в современных реалях, когда на компьютерах нет проблем с памятью и многопоточный процессор, preallocated схема не является стандартно используемой?

Многопоточность это миф, а память конечна.

Не всегда есть возможность заранее определить, сколько функций необходимо запустить (при динамическом запуске или внутри цикла).
В большинстве задач достаточно Non-reentrant режима и все с этим нормально живут.
Включение Shared clone делается как правило, когда необходимо ускорить какие-то участки кода, но делается это не так часто.
Preallocated clone это на грани, и как правило используется в критических задачах, при создании FGV или рекурсиях.

[Artem.spb]

Preallocated clone это на грани, и как правило используется в критических задачах, при создании FGV или рекурсиях.

Рекурсия это как раз shared, именно потому что невозможно предсказать, сколько клонов понадобится :)

[Kosist]

Теперь остался один вопрос, почему в современных реалях, когда на компьютерах нет проблем с памятью и многопоточный процессор, preallocated схема не является стандартно используемой?

Это распространенная ошибка новичков, считать что многопоточность = скорость исполнения. Это далеко не так. Есть еще понятие асинхронного (или же параллельного) исполнения. Вот кратко пояснение - https://www.baeldung.com/cs/async-vs-multi-threading.
В приложении есть, скажем, четыре задачи - прочитать данные с прибора, их обработать, изобразить на графике, и сохранить в файл. И чтобы программа работала эфективно, достаточно сделать каждый процесс паралельным, асинхронным. Для этого есть свои паттерны программирования. И нет смысла каждую сабвиайку при этом делать preallocated - это просто ничего не даст. И будут бежать все процессы на одном ядре, или паралельно на отдельных - разницы в конечном счете не будет.
Не нужно считать, что создатели не понимают тонкостей работы с памятью, многопоточностью, и т.д. Они знали, что делали.

[IvanLis]

Рекурсия это как раз shared, именно потому что невозможно предсказать, сколько клонов понадобится :)

До, верно....
Я накосячил

[kichay.d]

Это распространенная ошибка новичков, считать что многопоточность = скорость исполнения. Это далеко не так. Есть еще понятие асинхронного (или же параллельного) исполнения. Вот кратко пояснение - https://www.baeldung.com/cs/async-vs-multi-threading.
В приложении есть, скажем, четыре задачи - прочитать данные с прибора, их обработать, изобразить на графике, и сохранить в файл. И чтобы программа работала эфективно, достаточно сделать каждый процесс паралельным, асинхронным. Для этого есть свои паттерны программирования. И нет смысла каждую сабвиайку при этом делать preallocated - это просто ничего не даст. И будут бежать все процессы на одном ядре, или паралельно на отдельных - разницы в конечном счете не будет.
Не нужно считать, что создатели не понимают тонкостей работы с памятью, многопоточностью, и т.д. Они знали, что делали.

Спасибо конечно за разъяснения, но я выше писал о накладных расходах операционной системы на выделение/высвобождения памяти и бессмысленности её экономии, когда её девать некуда. И мне кажется, довольно сложно не согласиться с тем, что preallocated схема в любом случае при всех прочих равных будет быстрее любой шаренной схемы, пусть даже с динамическим пуллом и скейлером, который предугадывает количество потребляемых инструментов и динамически заранее аллоцирует их в пул.
Что касается создателей LabVIEW, то всё что они могут, это просить операционную систему выделить память и отдавать её обратно. И выбора тут мало, если часто просить её и отдавать обратно, то будут дополнительные задержки. Даже если делать это с предугадыванием, будет доля ошибок предугадывания. Если же "лениво" отдавать память операционной системе, то такая схема работы будет мало выигрывать в памяти у preallocated, но добавлять много накладных расходов на менеджменте собственного пула памяти.
Интересуюсь я всем этим в контексте не то что бы самого LabVIEW, а скорее в контексте парадигм языка G. Решил напилить маленький фреймворк, позволяющий выполнять в golang рантайме G код, пока всё только началось, и дело дошло до реализации структур.
Если кому интересно, могу в личку скинуть ссылку на репозиторий в github, но быструю разработку я не обещаю, проект веду больше как хобби. Код лицензирован boost (BSL-1) лицензией.

[Kosist]

Спасибо конечно за разъяснения, но я выше писал о накладных расходах операционной системы на выделение/высвобождения памяти и бессмысленности её экономии, когда её девать некуда. И мне кажется, довольно сложно не согласиться с тем, что preallocated схема в любом случае при всех прочих равных будет быстрее любой шаренной схемы, пусть даже с динамическим пуллом и скейлером, который предугадывает количество потребляемых инструментов и динамически заранее аллоцирует их в пул.

Если виайка не shared/preallocated - то она существует в одном экземпляре. Значит, память под нее выделяется раз, и далее "общение" с виайкой происходит по ссылке на ячейку памяти (грубо говоря). Никакого предугадывания не надо, и не надо "динамически аллоцировать их в пул". Все эффективно. А вот если каждая виайка будет по умолчанию preallocated - то ран-тайму еще нужно просчитать количество этих виаек (а это придется еще делать и динамически при запуске параллельных процессов), и выделять под каждую виайку "весом" X, N инстансов - забивая память. И это не будет быстрее не shared/preallocated виаек.

Что касается создателей LabVIEW, то всё что они могут, это просить операционную систему выделить память и отдавать её обратно.

код исполняется Run-Time движком, который все контроллирует. Это не обычные exe, которые исполняются прямо операционкой. Поэтому, мне кажется, что работа с памятью там происходит и в самом рантайме тоже.

[IvanLis]

Понимаете, если бы все боролись за производительность, то писали бы на Assembler, а языки высокого уровня не использовались вовсе.

Возможно для реализации Вашей задумки это на самом деле важно.
Но как программист могу сказать, что проблемы с производительностью решаются по мере их возникновения. Зачастую нет смысла зарываться в код и стремиться к совершенству, если он и так выполняет свою задачу. А вот если начинаются проблемы, то существует достаточно много механизмов его ускорить. Начиная от настройки приоритетов, Iteration Parallelism, разносом по потокам выполнения и много много всякого (вот один из примеров)
Тем более, не стоит забывать, что LabVIEW это в первую очередь среда для инженеров, а не программистов. По этому, зачастую многим даже не интересно, как там все происходит "под капотом".

Решил напилить маленький фреймворк, позволяющий выполнять в golang рантайме G код, пока всё только началось, и дело дошло до реализации структур.

Идея возможно хорошая, на сколько я понимаю, позволит расширить список ОС и устройств, на которых можно запустить свою программу, так ли это?
Цель какая и до какого уровня Вы планируете реализовать, ведь в LabVIEW есть структуры, которые не имеют аналогов в других языках программирования. Да и сам код LabVIEW, прежде чем стать программой, проходит несколько этапов трансформации и оптимизации.

Если кому интересно, могу в личку скинуть ссылку на репозиторий в github, но быструю разработку я не обещаю, проект веду больше как хобби. Код лицензирован boost (BSL-1) лицензией.

Если Вы хотите, что бы проектом заинтересовались, то можете выложить ссылку здесь.
Это конечно добавит много вопросов от пользователей и потребует разъяснений, но позволит корректировать вектор развития и переопределить приоритеты.

[kichay.d]

Но как программист могу сказать, что проблемы с производительностью решаются по мере их возникновения. Зачастую нет смысла зарываться в код и стремиться к совершенству, если он и так выполняет свою задачу.

В моём случае я могу решать или не решать проблему с экономией памяти ценой производительности и пока не вижу в этом смысла.

Идея возможно хорошая, на сколько я понимаю, позволит расширить список ОС и устройств, на которых можно запустить свою программу, так ли это?
Цель какая и до какого уровня Вы планируете реализовать, ведь в LabVIEW есть структуры, которые не имеют аналогов в других языках программирования. Да и сам код LabVIEW, прежде чем стать программой, проходит несколько этапов трансформации и оптимизации.

Golang компилируемый ЯП, поддержка ОС будет ограничена наличием компилятора/интерпретатора golang для этой ОС. Панели (фронтэнд) планирую реализовать в виде веб сервера, а при запуске VI просто отдавать пользователю ссылку на созданный сервер. Не очень понимаю, про какие структуры без аналогов идёт речь? Да и мне не нужны аналоги в языке, мне нужна реализация структуры на языке.

Если Вы хотите, что бы проектом заинтересовались, то можете выложить ссылку здесь.
Это конечно добавит много вопросов от пользователей и потребует разъяснений, но позволит корректировать вектор развития и переопределить приоритеты.

https://github.com/DanilKichai/goji - вот ссылка не репозиторий. Пока это больше набросок, реализована логика SubVI, констант, локальных и глобальных переменных, бэкенд частей индикаторов и контролов, узлов (когда один выход подключен к нескольким входам SubVI). Рано или поздно я напишу осмысленный README.md.
В трёх словах:
project.go - описывает глобальные переменные и подключает несколько VI для асинхронного запуска
hello/hello.go - VI hello_world
core/*.go - непосредственно сам фреймворк
crutch/*.go - библиотека инструментов с "костылями" для тестов фреймворка, на данный момент в ней реализован VI, выводящий в консоль стандартного вывода текст, который был получен на единственный вход.

На данный момент ни кого не планирую заинтересовывать, так как нет даже документации.

[IvanLis]

Golang компилируемый ЯП, поддержка ОС будет ограничена наличием компилятора/интерпретатора golang для этой ОС. Панели (фронтэнд) планирую реализовать в виде веб сервера, а при запуске VI просто отдавать пользователю ссылку на созданный сервер.

В таком случае, список ОС фактически не ограничен .
Надеюсь Вам хватит терпения и времени, что бы получить ожидаемый результат.

-----
p.s. С Вашего разрешения, переименовал тему в Golang Framework