новичку нужен помощь

[nazar]

[zxc_pavel]

Это время одного цикла

[Borjomy_1]

Связано с тем, что использование Formula Node чрезвычайно замедляет выполнение программы. По сути это текстовый интерпретатор. Перемножение двух чисел с помощью операций умножения занимает несколько тактов процессора. А выполнение через Formula Node - сотни тактов, если не тысячи. Поэтому лучше отказаться от использования этой функции и написать вычисления с помощью функций из арифметической и тригонометрической палитры.

[alerm]

Связано с тем, что использование Formula Node чрезвычайно замедляет выполнение программы. По сути это текстовый интерпретатор. Перемножение двух чисел с помощью операций умножения занимает несколько тактов процессора. А выполнение через Formula Node - сотни тактов, если не тысячи. Поэтому лучше отказаться от использования этой функции и написать вычисления с помощью функций из арифметической и тригонометрической палитры.

Это уже не так, уже как несколько лет разницы особо нет.

Хотя может я где накосячил при сравнении

[dadreamer]

По сути это текстовый интерпретатор.

К счастью нет, а то была бы производительность как у Python Node или MathScript Node (т.е. ещё раза в три медленнее). Просто код FN не проходит через оптимизации, в отличие от G. Я об этом уже писал тут:

>> Но почему FN уверенно лидирует? и откуда пошла мысль, что этот способ вычислений надо избегать?
В случае с FN раз на раз не приходится. И это в основном зависит от компилятора. Не слишком научный ответ, зато ближе всего к истине. Общий консенсус таков, что для узла FN диаграмма не проходит через конвертацию в DFIR (Dataflow Intermediate Representation), соответственно никакой декомпозиции и оптимизации не выполняется. Вероятно, текст парсится и сразу перегоняется в некие шаблонные блоки машинного кода. Часто такой код получается "рыхлым", т.е. присутствует много ненужных или сомнительных инструкций. Но иногда звёзды сходятся в одну линию и результирующий код получается довольно неплохим в плане производительности. Здесь то же самое немного другими словами: https://lavag.org/topic/16414-formula-n ... ent=101234 Я заметил, что это зависит не от сложности текстового кода в FN. Часто даже простой код формулы работает медленнее нативного: http://digital.ni.com/public.nsf/allkb/ ... A30050320E Внизу статьи есть примеры Formula Node.vi и Traditional.vi. Код на БД простейший, однако у меня получается 91 мс для FN и 17 для нативных узлов. С противоположной ситуацией мы как-то уже сталкивались: http://labviewportal.org/viewtopic.php?p=72440#p72440 Думаю, что именно эта неоднозначность при компиляции FN и является тем фактором, из-за которого NI и каждый второй юзер советуют использовать нативные функции. В их производительности можно хотя бы приблизительно быть уверенным, чего не скажешь о FN. Короче, мысли вслух, спускаться на ассемблерный уровень нет желания. :)

Кстати, прогнал тест из той темы на 2022, снова получил такие цифры:

2022-10-19_22-47-08.jpg (38.62 КБ) 1019 просмотров

Так что ничего особо не изменилось.

Это уже не так, уже как несколько лет разницы особо нет.

Попробуйте что-нибудь посложнее, например, циклы или работу с массивами На простых операциях FN работает приемлемо, иногда не хуже нативных узлов.