formula node, производительность
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
formula node, производительность
Не вопрос, а наблюдение (или мысли вслух).
Почему-то у меня в голове сидит мысль, что FN - зло злостное, надо использовать нативные узлы и всё такое.
И решил я в этом усомниться (сжечь еретика за такие мысли! ).
И вот тест показал что FN рулит. Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти. Но почему FN уверенно лидирует? и откуда пошла мысль, что этот способ вычислений надо избегать?
14 и 16 цифры практически одинаковые
Почему-то у меня в голове сидит мысль, что FN - зло злостное, надо использовать нативные узлы и всё такое.
И решил я в этом усомниться (сжечь еретика за такие мысли! ).
И вот тест показал что FN рулит. Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти. Но почему FN уверенно лидирует? и откуда пошла мысль, что этот способ вычислений надо избегать?
14 и 16 цифры практически одинаковые
-
- assistant
- Сообщения: 119
- Зарегистрирован: 06 май 2015, 22:24
- Версия LabVIEW: 2014, 2018
- Благодарил (а): 1 раз
- Поблагодарили: 1 раз
- Контактная информация:
Re: formula node, производительность
У меня на i7 8086k nodes 743, arr 736, FN 681, так что arr не всегда на последнем месте (LV18).
Но поведение FN просто радует, благодарю за информацию, иногда сильно может упростить БД.
Но поведение FN просто радует, благодарю за информацию, иногда сильно может упростить БД.
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: formula node, производительность
Среда разработки Labview и скомпилированый .exe используют один и тот же runtime.
Поэтому для измерения реальной производительности нужно:
1. Отключить отладку
2. Установить настройки оптимизации на максимум
3. Выполнить Tools - > Advanced -> Mass compile
В этом случае компилятор (насколько я понял)выделит нужную память заранее, разделит на параллельные потоки в соответствии с процессором.
В обучалках правильные ответы с массивами если есть выбор с циклами или напрямую в функции, всегда без циклов - напрямую в функции
Еще один момент я заметил. Если массив большой и количество вычислений тоже большое, можно скомплировать динамическую библиотеку с максимальной оптимизацией.
Тогда затраты на один вызов оправдаются и то не в разы.
Поэтому для измерения реальной производительности нужно:
1. Отключить отладку
2. Установить настройки оптимизации на максимум
3. Выполнить Tools - > Advanced -> Mass compile
В этом случае компилятор (насколько я понял)выделит нужную память заранее, разделит на параллельные потоки в соответствии с процессором.
В обучалках правильные ответы с массивами если есть выбор с циклами или напрямую в функции, всегда без циклов - напрямую в функции
Еще один момент я заметил. Если массив большой и количество вычислений тоже большое, можно скомплировать динамическую библиотеку с максимальной оптимизацией.
Тогда затраты на один вызов оправдаются и то не в разы.
- Вложения
-
- Untitled 8.vi
- (37.05 КБ) 114 скачиваний
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
Re: formula node, производительность
Он сможет это сделать при заранее известном массиве. В реальной жизни длина в большинстве случаев неизвестна на этапе компиляции="ujin" писал(а): В этом случае компилятор (насколько я понял)выделит нужную память заранее.
Потому что как минимум это сильно упрощает код. А как максимум всё же обычно быстрее работает.В обучалках правильные ответы с массивами если есть выбор с циклами или напрямую в функции, всегда без циклов - напрямую в функции
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: formula node, производительность
Artem.spb, вот такой тест сюда ещё просится.
Сразу FN уходит из списка победителей.
>> Неожиданно работа с массивом вообще на последнем месте, но это (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. Короче, мысли вслух, спускаться на ассемблерный уровень нет желания. :)
Я это объясняю тем, что на каждую операцию нужен отдельный 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. Короче, мысли вслух, спускаться на ассемблерный уровень нет желания. :)
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: formula node, производительность
В этом случае разницы не должно быть. В этом примере при рекомендуемых настройках компилятора результаты получаются одинаковыми.Он сможет это сделать при заранее известном массиве. В реальной жизни длина в большинстве случаев неизвестна на этапе компиляции
Если получается учесть какие либо известные параметры или на этапе компиляции или на этапе выполнения вариант с formula node теоретически должен быть всегда хуже.
При усложнении задачи, например повторный вызов, вариант с formula node не оптимизируется.
Но у варианта с For Loop можно еще включить Iteration Parallelism, а у nativ варианта я не увидел как.
-
- user
- Сообщения: 94
- Зарегистрирован: 28 июл 2019, 13:16
- Версия LabVIEW: 19
- Благодарил (а): 2 раза
- Поблагодарили: 3 раза
- Контактная информация:
Re: formula node, производительность
Плюс еще организация теста у Вас отличается от предлагаемой NI в примерах Perfomance.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: formula node, производительность
Прогнал этот же тест на NXG 4.0. Результат ожидаемый.
Роль Formula Node в NXG отведена узлу C Node (за кадром ANSI C компилятор из LabWindows/CVI). Всё-таки встроенные в конструктивы по-прежнему работают лучше всего. Код с участием C Node во-первых не самый оптимальный, во-вторых требует конвертации входных/выходных параметров в/из C-нотации с последующей передачей из среды в среду (последнее может и отсутствовать, если код инлайнится). На итерациях в 10000000 штук даже самая мизерная задержка в доли мс может оказаться роковой. Хотя на небольшом числе итераций - почему бы и нет...
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
Re: formula node, производительность
[quote=="dadreamer"]
>> Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти.
Я это объясняю тем, что на каждую операцию нужен отдельный For Loop, итого получается 12 переборов вместо одного.[/quote]
Про циклы я как-то не подумал, но ведь и правда они должны быть.
Но вот выделение всё же медленная штука. Опять же на основе тестов.
Мне в одном проекте регулярно надо иметь довольно большой массив -200.
Так вот, я не выделяю его каждый раз, а беру (старый*0-200)
[quote=="ujin"]Плюс еще организация теста у Вас отличается от предлагаемой NI в примерах Perfomance.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.[/quote]
выделение буферов однозначно влияет на результат, поэтому я и делаю копии проводов до кадрирования
[quote=="dadreamer"]Прогнал этот же тест на NXG 4.0. Результат ожидаемый.[/quote]
результат совсем уж печально выглядит
>> Неожиданно работа с массивом вообще на последнем месте, но это (imho) объяснимо выделением памяти.
Я это объясняю тем, что на каждую операцию нужен отдельный For Loop, итого получается 12 переборов вместо одного.[/quote]
Про циклы я как-то не подумал, но ведь и правда они должны быть.
Но вот выделение всё же медленная штука. Опять же на основе тестов.
Мне в одном проекте регулярно надо иметь довольно большой массив -200.
Так вот, я не выделяю его каждый раз, а беру (старый*0-200)
[quote=="ujin"]Плюс еще организация теста у Вас отличается от предлагаемой NI в примерах Perfomance.
Перестановка местами порядка выполнения тестов приводит к другому результату.
Хотя разница в 3% больше похожа на погрешность.[/quote]
выделение буферов однозначно влияет на результат, поэтому я и делаю копии проводов до кадрирования
[quote=="dadreamer"]Прогнал этот же тест на NXG 4.0. Результат ожидаемый.[/quote]
результат совсем уж печально выглядит
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: formula node, производительность
>> результат совсем уж печально выглядит
Я бы сказал, реалистично. Любой вызов внешнего или каким-то образом встроенного кода влечёт накладные расходы, будь это FN, MathScript, DLL или ActiveX/.NET. Вызовы Питона так ещё больше времени занимают. Даже прямое обращение к внутренним функциям самого занимает больше времени, чем вызов аналогичной функции из стандартной палитры. Однако NI и правда стоит лучше поработать над интеграцией движка CVI в NXG, да и вообще, похоже, над оптимизацией они пока толком не работали: нет настроек параллелизации циклов, нет соответствующих настроек для gvi, много чего пока нет. А что касается FN и классического LV, если позарез важна производительность, я пишу (переписываю) на нативных блоках, если нет, то оставляю как есть (многие разрабы используют FN, им так "проще", "нагляднее" и т.п.). Порой сложные формулы реально проще в FN прописать, чем соединять всё проводами. Да и потом спустя год или два будет легче вспомнить, что и как работает.
Я бы сказал, реалистично. Любой вызов внешнего или каким-то образом встроенного кода влечёт накладные расходы, будь это FN, MathScript, DLL или ActiveX/.NET. Вызовы Питона так ещё больше времени занимают. Даже прямое обращение к внутренним функциям самого занимает больше времени, чем вызов аналогичной функции из стандартной палитры. Однако NI и правда стоит лучше поработать над интеграцией движка CVI в NXG, да и вообще, похоже, над оптимизацией они пока толком не работали: нет настроек параллелизации циклов, нет соответствующих настроек для gvi, много чего пока нет. А что касается FN и классического LV, если позарез важна производительность, я пишу (переписываю) на нативных блоках, если нет, то оставляю как есть (многие разрабы используют FN, им так "проще", "нагляднее" и т.п.). Порой сложные формулы реально проще в FN прописать, чем соединять всё проводами. Да и потом спустя год или два будет легче вспомнить, что и как работает.
-
- professor
- Сообщения: 3406
- Зарегистрирован: 31 июл 2011, 23:05
- Награды: 2
- Версия LabVIEW: 12-18
- Благодарил (а): 49 раз
- Поблагодарили: 176 раз
- Контактная информация:
Re: formula node, производительность
Всё совсем внешнее понятно, особенно если там какой-нибудь рантайм запустить надо. Но не своё же полуродное.="dadreamer" писал(а):>> результат совсем уж печально выглядит
Я бы сказал, реалистично. Любой вызов внешнего или каким-то образом встроенного кода влечёт накладные расходы, будь это FN, MathScript, DLL или ActiveX/.NET.
Я в итоге к этому и пришёл. Очень мало проектов грузят проц на 150%, обычно жрут 10-20, так что упираться в оптимизацию нужно не всегда.А что касается FN и классического LV, если позарез важна производительность, я пишу (переписываю) на нативных блоках, если нет, то оставляю как есть (многие разрабы используют FN, им так "проще", "нагляднее" и т.п.). Порой сложные формулы реально проще в FN прописать, чем соединять всё проводами. Да и потом спустя год или два будет легче вспомнить, что и как работает.
Как говорится, компьютер должен работать, а голова думать. Хотя, цитата не очень уместная, можно опять начать думать над оптимизацией и проц снова перестаёт работать
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: formula node, производительность
>> Всё совсем внешнее понятно, особенно если там какой-нибудь рантайм запустить надо. Но не своё же полуродное.
В разные годы я встречал на разных форумах инфу о том, что NI когда-то покупала у той или иной фирмы некоторый тулкит/пакет и встраивала в . Таким образом были созданы 3D Picture Control Toolkit и Vision Module. Да и компилятор в у них LLVM. Не удивлюсь, если парсер для FN тоже когда-то покупался у третьих лиц. Для CVI CLang например используется: http://zone.ni.com/reference/en-XX/help ... icompiler/
В разные годы я встречал на разных форумах инфу о том, что NI когда-то покупала у той или иной фирмы некоторый тулкит/пакет и встраивала в . Таким образом были созданы 3D Picture Control Toolkit и Vision Module. Да и компилятор в у них LLVM. Не удивлюсь, если парсер для FN тоже когда-то покупался у третьих лиц. Для CVI CLang например используется: http://zone.ni.com/reference/en-XX/help ... icompiler/
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение
-
- 8 Ответы
- 2045 Просмотры
-
Последнее сообщение Eugene_Eugene
-
- 23 Ответы
- 4627 Просмотры
-
Последнее сообщение maxim_MA
-
- 8 Ответы
- 687 Просмотры
-
Последнее сообщение Select