formula node, производительность

Простейшие вопросы в области инженерной разработки
Ответить
Artem.spb

Activity Автор
expert
expert
Сообщения: 1992
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 5 раз
Поблагодарили: 8 раз
Контактная информация:

formula node, производительность

Сообщение Artem.spb »

Не вопрос, а наблюдение (или мысли вслух).
Почему-то у меня в голове сидит мысль, что FN - зло злостное, надо использовать нативные узлы и всё такое.
И решил я в этом усомниться (сжечь еретика за такие мысли! :evil: ).
И вот тест показал что FN рулит.
FN1.png
fn2.PNG
fn2.PNG (6.42 КБ) 1739 просмотров
Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти.
fn3.PNG
Но почему FN уверенно лидирует? и откуда пошла мысль, что этот способ вычислений надо избегать?
:labview: 14 и 16 цифры практически одинаковые

Alex Dem
assistant
assistant
Сообщения: 110
Зарегистрирован: 06 май 2015, 22:24
Версия LabVIEW: 2014, 2018

Re: formula node, производительность

Сообщение Alex Dem »

У меня на i7 8086k nodes 743, arr 736, FN 681, так что arr не всегда на последнем месте (LV18).
Но поведение FN просто радует, благодарю за информацию, иногда сильно может упростить БД. :super:

ujin
user
user
Сообщения: 92
Зарегистрирован: 28 июл 2019, 13:16
Версия LabVIEW: 19
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Re: formula node, производительность

Сообщение ujin »

Среда разработки Labview и скомпилированый .exe используют один и тот же runtime.
Поэтому для измерения реальной производительности нужно:
1. Отключить отладку
2. Установить настройки оптимизации на максимум
3. Выполнить Tools - > Advanced -> Mass compile
В этом случае компилятор (насколько я понял)выделит нужную память заранее, разделит на параллельные потоки в соответствии с процессором.
В обучалках правильные ответы с массивами если есть выбор с циклами или напрямую в функции, всегда без циклов - напрямую в функции
Еще один момент я заметил. Если массив большой и количество вычислений тоже большое, можно скомплировать динамическую библиотеку с максимальной оптимизацией.
Тогда затраты на один вызов оправдаются и то не в разы.
Вложения
Untitled 8.vi
(37.05 КБ) 36 скачиваний

Artem.spb

Activity Автор
expert
expert
Сообщения: 1992
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 5 раз
Поблагодарили: 8 раз
Контактная информация:

Re: formula node, производительность

Сообщение Artem.spb »

="ujin" писал(а): В этом случае компилятор (насколько я понял)выделит нужную память заранее.
Он сможет это сделать при заранее известном массиве. В реальной жизни длина в большинстве случаев неизвестна на этапе компиляции
В обучалках правильные ответы с массивами если есть выбор с циклами или напрямую в функции, всегда без циклов - напрямую в функции
Потому что как минимум это сильно упрощает код. А как максимум всё же обычно быстрее работает.

Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3529
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2020
Благодарил (а): 2 раза
Поблагодарили: 9 раз
Контактная информация:

Re: formula node, производительность

Сообщение dadreamer »

Artem.spb, вот такой тест сюда ещё просится.
2020-02-05_23-30-11.jpg
Untitled 1.vi
lv2014
(29.37 КБ) 39 скачиваний
Сразу FN уходит из списка победителей.
2020-02-05_23-32-34.jpg
2020-02-05_23-32-34.jpg (39.66 КБ) 1716 просмотров
>> Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти.
Я это объясняю тем, что на каждую операцию нужен отдельный For Loop, итого получается 12 переборов вместо одного.

>> Но почему 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. Короче, мысли вслух, спускаться на ассемблерный уровень нет желания. :)

ujin
user
user
Сообщения: 92
Зарегистрирован: 28 июл 2019, 13:16
Версия LabVIEW: 19
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Re: formula node, производительность

Сообщение ujin »

Он сможет это сделать при заранее известном массиве. В реальной жизни длина в большинстве случаев неизвестна на этапе компиляции
В этом случае разницы не должно быть. В этом примере при рекомендуемых настройках компилятора результаты получаются одинаковыми.
Если получается учесть какие либо известные параметры или на этапе компиляции или на этапе выполнения вариант с formula node теоретически должен быть всегда хуже.
При усложнении задачи, например повторный вызов, вариант с formula node не оптимизируется.
Но у варианта с For Loop можно еще включить Iteration Parallelism, а у nativ варианта я не увидел как.
Вложения
Настройки компилятора.jpg
Mass compile.jpg
test.jpg
test massiv1.png
test2.jpg

ujin
user
user
Сообщения: 92
Зарегистрирован: 28 июл 2019, 13:16
Версия LabVIEW: 19
Благодарил (а): 2 раза
Поблагодарили: 3 раза

Re: formula node, производительность

Сообщение ujin »

Плюс еще организация теста у Вас отличается от предлагаемой NI в примерах Perfomance.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.
Вложения
test4.jpg

Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3529
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2020
Благодарил (а): 2 раза
Поблагодарили: 9 раз
Контактная информация:

Re: formula node, производительность

Сообщение dadreamer »

Прогнал этот же тест на NXG 4.0. Результат ожидаемый.
2020-02-06_15-23-54.jpg
2020-02-06_15-25-30.jpg
Роль Formula Node в NXG отведена узлу C Node (за кадром ANSI C компилятор из LabWindows/CVI). Всё-таки встроенные в :labview: конструктивы по-прежнему работают лучше всего. Код с участием C Node во-первых не самый оптимальный, во-вторых требует конвертации входных/выходных параметров в/из C-нотации с последующей передачей из среды в среду (последнее может и отсутствовать, если код инлайнится). На итерациях в 10000000 штук даже самая мизерная задержка в доли мс может оказаться роковой. Хотя на небольшом числе итераций - почему бы и нет...
Вложения
2020-02-06_15-39-47.jpg

Artem.spb

Activity Автор
expert
expert
Сообщения: 1992
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 5 раз
Поблагодарили: 8 раз
Контактная информация:

Re: formula node, производительность

Сообщение Artem.spb »

[quote=="dadreamer"]
>> Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти.
Я это объясняю тем, что на каждую операцию нужен отдельный For Loop, итого получается 12 переборов вместо одного.[/quote]
Про циклы я как-то не подумал, но ведь и правда они должны быть.
Но вот выделение всё же медленная штука. Опять же на основе тестов.
Мне в одном проекте регулярно надо иметь довольно большой массив -200.
Так вот, я не выделяю его каждый раз, а беру (старый*0-200)

[quote=="ujin"]Плюс еще организация теста у Вас отличается от предлагаемой NI в примерах Perfomance.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.[/quote]
выделение буферов однозначно влияет на результат, поэтому я и делаю копии проводов до кадрирования

[quote=="dadreamer"]Прогнал этот же тест на NXG 4.0. Результат ожидаемый.[/quote]
результат совсем уж печально выглядит

Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3529
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2020
Благодарил (а): 2 раза
Поблагодарили: 9 раз
Контактная информация:

Re: formula node, производительность

Сообщение dadreamer »

>> результат совсем уж печально выглядит
Я бы сказал, реалистично. Любой вызов внешнего или каким-то образом встроенного кода влечёт накладные расходы, будь это FN, MathScript, DLL или ActiveX/.NET. Вызовы Питона так ещё больше времени занимают. Даже прямое обращение к внутренним функциям самого :labview: занимает больше времени, чем вызов аналогичной функции из стандартной палитры. Однако NI и правда стоит лучше поработать над интеграцией движка CVI в NXG, да и вообще, похоже, над оптимизацией они пока толком не работали: нет настроек параллелизации циклов, нет соответствующих настроек для gvi, много чего пока нет. А что касается FN и классического LV, если позарез важна производительность, я пишу (переписываю) на нативных блоках, если нет, то оставляю как есть (многие разрабы используют FN, им так "проще", "нагляднее" и т.п.). Порой сложные формулы реально проще в FN прописать, чем соединять всё проводами. Да и потом спустя год или два будет легче вспомнить, что и как работает.

Artem.spb

Activity Автор
expert
expert
Сообщения: 1992
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 5 раз
Поблагодарили: 8 раз
Контактная информация:

Re: formula node, производительность

Сообщение Artem.spb »

="dadreamer" писал(а):>> результат совсем уж печально выглядит
Я бы сказал, реалистично. Любой вызов внешнего или каким-то образом встроенного кода влечёт накладные расходы, будь это FN, MathScript, DLL или ActiveX/.NET
.
Всё совсем внешнее понятно, особенно если там какой-нибудь рантайм запустить надо. Но не своё же полуродное.
А что касается FN и классического LV, если позарез важна производительность, я пишу (переписываю) на нативных блоках, если нет, то оставляю как есть (многие разрабы используют FN, им так "проще", "нагляднее" и т.п.). Порой сложные формулы реально проще в FN прописать, чем соединять всё проводами. Да и потом спустя год или два будет легче вспомнить, что и как работает.
Я в итоге к этому и пришёл. Очень мало проектов грузят проц на 150%, обычно жрут 10-20, так что упираться в оптимизацию нужно не всегда.
Как говорится, компьютер должен работать, а голова думать. Хотя, цитата не очень уместная, можно опять начать думать над оптимизацией и проц снова перестаёт работать :D

Аватара пользователя
dadreamer

Activity Professionalism Автор
professor
professor
Сообщения: 3529
Зарегистрирован: 17 фев 2013, 16:33
Награды: 4
Версия LabVIEW: 2.5 — 2020
Благодарил (а): 2 раза
Поблагодарили: 9 раз
Контактная информация:

Re: formula node, производительность

Сообщение dadreamer »

>> Всё совсем внешнее понятно, особенно если там какой-нибудь рантайм запустить надо. Но не своё же полуродное.
В разные годы я встречал на разных форумах инфу о том, что NI когда-то покупала у той или иной фирмы некоторый тулкит/пакет и встраивала в :labview: . Таким образом были созданы 3D Picture Control Toolkit и Vision Module. Да и компилятор в :labview: у них LLVM. Не удивлюсь, если парсер для FN тоже когда-то покупался у третьих лиц. Для CVI CLang например используется: http://zone.ni.com/reference/en-XX/help ... icompiler/

Ответить

Вернуться в «Для чайников»