Execution system (экспериментируем)

[Artem.spb]

Коротко об Execution system (для новичков)

В LabVIEW шесть потоков (систем исполнения):

• user interface - отвечает за пользовательский интерфейс. В многопоточных приложениях ведет себя так же, как и в однопоточных. VI работают в потоке пользовательского интерфейса без проблем, но система исполнения чередует совместную многозадачность и реагирование на действия пользователя – вот тут подводные камни и прячутся. В нагруженных системах интерфейсная часть может сильно «подвешивать» программу при том, что процессор будет загружен далеко не на 100%
• standard – выполняется в отдельных от пользовательского интерфейса потоках.
• instrument I/O – для периферии вроде VISA, GPIB и последовательного ввода/вывода.
• data acquisition – для сбора данных (DAQms и пр).
• other 1 и other 2 – если standard не хватает.
• same as caller – рекомендуемая настройка subVI для запуска в той же системе исполнения, что и вызвавший VI.

Базово функции исполняются в стандартном потоке, но, если нужно обновить индикатор, в дело вступает UI поток. А неприятное в этом то, что остальные части функции начинают подтормаживать.

Вот тут интересный вопрос: а на сколько подтормаживать?

Для тестов я выбрал упрощённую модель системы:

Часть кода отвечает за сбор данных, а проще говоря, генератор случайных чисел создаёт массив заданной длины. Операция повторяется много раз, после чего в очередь отправляется время выполнения. Так же замечу, что очередь специально создаётся размером 1, так что поток «сбора данных» будет ждать, пока обработчик выполнит свою часть задачи. Это сделано для упрощения замеров времени. Сама начинка оформлена в виде subVI с режимом inline, что позволит использовать одинаковые функции в тестах, при этом без затрат времени на вызов функций.

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

И, наконец, интерфейсная часть.

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

Интересное же происходит в нижней части цикла. Программа на каждой итерации меняет вид точки графика с результатами и смещает само окно программы. Кроме того, таймаут ожидания очереди равен нулю, так что программа будет пытаться забрать все ресурсы, что сможет.

Пора запустить тест.

Первые сравнения проведу по описанной схеме.
Из графиков результатов, видим, что разнесение операций по потокам (системам исполнения) ускоряет программу в 5-20 раз.

Мало какие программы так издеваются над пользователем активно манипулируют с окнами, поэтому убираю вызовы property node и повторяю тест.
Время выполнения задач по-прежнему различается в 5 раз.

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

Видео для тех, кто не любит читать


Комментарии и замечания приветствуются.
Любопытно (на видео видно), почему при старте второго теста процессор улетает в космос загружается на 100%, но через некоторое время частично разгружается.

[Borjomy_1]

Любопытно (на видео видно), почему при старте второго теста процессор улетает в космос загружается на 100%, но через некоторое время частично разгружается.

Автошкалинг по оси X трендов, возможно.

[Artem.spb]

Автошкалинг по оси X трендов, возможно.

Но понял, про какую именно шкалу речь. Отключил все, эффект сохраняется

А ещё обнаружил, что активное окно ползает медленнее, чем задвинутое на второй план (если активировать диспетчер задач).