Страница 5 из 7

Re: Странное торможение параллельных потоков

Добавлено: 30 май 2016, 15:12
Boris_K
Так что меняйте ОСь.
Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.

Re: Странное торможение параллельных потоков

Добавлено: 31 май 2016, 09:45
dadreamer
Boris_K писал(а):Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.
На правах оффтопика. На работе везде стараюсь ставить семёрку 64 бита, а программки пишу в 64-битном :labview: . Это даёт доступ ко всему объёму оперативки для одного процесса, а также получаю распараллеливание потоков по всем ядрам процессора. В результате лучше быстродействие и больше доступных ресурсов для работы трудоёмких приложений (работа с изображениями / видео / мат. вычисления). Дома пользуюсь в основном тоже семёркой x64, порядком к ней привык уже. Хотя ставил и 8-ку, и 10. Восьмёрка не очень понравилась из-за неудачного (на мой взгляд) плиточного интерфейса, отсутствия Пуска, наличия Metro-приложений, "заточки" под сенсорные устройства. Можно, в принципе, её настроить, но на это тоже требуется время, которого на производстве может не быть. С семёркой такой возни намного меньше. 10-ку поставил ради интереса, выглядит красиво, не глючит, не тормозит, обновы часто прилетают. Но в итоге всё равно Пуск стандартный заменил на классический (через софтину). Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно). Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане. А то вдруг M$ подложит свинью какую. :D

Re: Странное торможение параллельных потоков

Добавлено: 31 май 2016, 11:18
Vitekkz88
Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане.
Купили мне ноут на работе с 10-ой. Поставил всё необходимое. К шпионским фишкам отношусь философски. Всё работает. На виртуалках развернул 7, ХР, Linux(OpenSUSE,Astra). Десятка нравится. Претензий к производительности и функционалу нет. То, что криво вставало на 8,8.1 , на 10 встало без проблем. Отключил визуальные эффекты, всё равно красиво) Нравится OpenSUSE и 10.
Ах да, тулкиты я не использую и на 10 не устанавливал.

Re: Странное торможение параллельных потоков

Добавлено: 31 май 2016, 13:16
Boris_K
Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно)
Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/

Re: Странное торможение параллельных потоков

Добавлено: 31 май 2016, 13:29
dadreamer
Boris_K писал(а):Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/
dadreamer писал(а):Шпионские службы при желании отключаются [...] через сторонние софтины (которых тоже полным-полно).
http://www.ghacks.net/2015/08/14/compar ... acy-tools/

Re: Странное торможение параллельных потоков

Добавлено: 02 июн 2016, 14:41
Boris_K
Возвращаясь к основной теме. Решение нашёл. И оно лежит на поверхности :haha: Называется Timed loop. Как-то всегда обходил его стороной. Со всеми терминалами, выглядит он конечно монструозно. Но выкурив справку, понял, что в большинстве случаев не нужны никакие доп. настройки, кроме задания периода цикла.

Во время выполнения тестовой проги запускал другие проги, "мурыжил" окна. Бывало вообще без тормозов, а макс. тормоза что видел - 2 - 3 мс (это на старых компах с WinXP!). Вот где, наверное, уже действительно сказывается не реалтаймовость винды. От переключения в UI-поток он, конечно, не спасёт, поэтому все элементы, чувствительные к потоку UI, надо также выносить из этого цикла. Но проделав это, получаем почти идеальную работу. Причём лишней загрузки процессора не происходит, то есть, в оставшееся свободное время на каждой итерации, цикл действительно "спит".

Причём приоритет процесса даже не пришлось увеличивать. Ещё интересно, что структура эта позволяет замерять время между итерациями в наносекундах! Ясно что это задел для различных аппаратных таргетов, но на компе это тоже работает, правда, вопрос, с какой точностью. В общем, проблему считаю решённой!

Re: Странное торможение параллельных потоков

Добавлено: 02 июн 2016, 20:11
dadreamer
Я тоже его избегал вплоть до текущего момента, считая предназначенным почти полностью для RT-платформ. Пробовал несколько раз его вместо обычного While, но особых преимуществ не увидел, только минус в виде излишней загромождённости.
А тут... Кто бы мог подумать... :shok:

Полезная инфа, буду иметь в виду в своих проектах, у меня тоже есть весьма чувствительные в плане времени циклы. Кстати, интересно, как он внутри устроен и как ему удаётся сохранять такую стабильность показаний времени?.. Из официальной инфы я нашёл только это - Timing and Synchronization in NI LabVIEW. И там есть вот такая картинка:
Timed_Loop_Timing_Sources.png
Судя по ней используется внутренний источник тактов (верхняя линия) Real-Time Clock (RTC), который также используется и для GetTickCount. А погрешность измерения таймера для GetTickCount составляет 10-15 мс. Отсюда не совсем понятно, откуда берутся наносекунды с такой точностью. Ещё более непонятна эта фраза:
NI писал(а):There are a variety of functions and structures in LabVIEW that use the nanosecond engine for time keeping, such as the Wait function and the Timed Loop structure.
Мы прекрасно видели проблемы с Wait, но проблем с Timed Loop нет. Как так происходит, раз один и тот же источник тактов?..

Порылся тут ещё в гугле, нашёл альтернативу Sleep - ждущие таймеры: http://stackoverflow.com/questions/1339 ... -1ms-error (последний пост + пример). Будет интересно посмотреть, какая точность получится в результате. Это, скорее всего, завтра проверю.
Boris_K писал(а):Решение нашёл. И оно лежит на поверхности :haha: Называется Timed loop.
Рад, что так легко всё разрешилось. Кстати, всегда думал, что Timed Loop - это просто кастомизированный While Loop в виде XNode. Оказалось, что XNode там только как пристройка (входы-выходы по бокам цикла, диалоги настройки и прочие плюшки), а сама структура реализована внутри :labview: (в исходнике прописана). Так что в неё даже не залезть толком. Ещё у Timed Loop есть своя "фишка" - можно его остановить из другого цикла или :vi: через Stop Timed Structure (вызывается внутренняя функция из lvalarms.dll). Это можно даже во внешнем коде использовать.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 11:22
dadreamer
Попробовал сегодня заменить обычную задержку на ждущий таймер. Результат заметно улучшился. В проге на Delphi теперь выдаёт
Result values: min time = 0,47 ms, max time = 5,04 ms
Result values: min time = 0,47 ms, max time = 2,53 ms
Result values: min time = 0,47 ms, max time = 2,98 ms
Result values: min time = 0,47 ms, max time = 3,25 ms
Result values: min time = 0,27 ms, max time = 3,01 ms
В проге на :labview: получил такие результаты:
1,74 ; 2,24
1,47 ; 3,02
1,31 ; 3,08
1,20 ; 4,66
1,81 ; 3,11
Всё остальное как обычно: пауза после отрабатывания нагрузочного кода - 2 мс, прога работает 90 секунд, GUI полностью отключен. Проверял на семёрке, на XP проверю позже. ̶Х̶о̶т̶ь̶ ̶и̶ ̶р̶е̶з̶у̶л̶ь̶т̶а̶т̶ ̶с̶т̶а̶л̶ ̶л̶у̶ч̶ш̶е̶,̶ ̶н̶о̶ ̶T̶i̶m̶e̶d̶ ̶L̶o̶o̶p̶ ̶в̶с̶ё̶ ̶р̶а̶в̶н̶о̶ ̶в̶ ̶п̶о̶б̶е̶д̶и̶т̶е̶л̶я̶х̶.̶
Boris_K писал(а):В общем, проблему считаю решённой!
В экзешнике тоже проверяли? Тоже нет тормозов на 7/XP? И такой ещё вопрос (сам сейчас не имею возможности проверить). Судя по вашему примеру, и по моему, который я делал по вашему, время выполнения одной итерации цикла складывается из времени выполнения нагрузочного когда плюс собственно задержки, т.е.
Т сум. = Т кода + Т wait, где T wait = 2 ms.
Timed Loop ведёт себя так же, или получается следующее:
Т сум. = Т кода + (Т wait - Т кода) = Т wait (когда Т кода < 2 ms)
Т сум. = Т кода (когда Т кода > 2 ms)
В первом случае имеем высокоточный аналог Wait, во втором - код реально выполняется с заданной частотой, независимо от времени выполнения самого кода.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 12:12
dadreamer
dadreamer писал(а): ̶Х̶о̶т̶ь̶ ̶и̶ ̶р̶е̶з̶у̶л̶ь̶т̶а̶т̶ ̶с̶т̶а̶л̶ ̶л̶у̶ч̶ш̶е̶,̶ ̶н̶о̶ ̶T̶i̶m̶e̶d̶ ̶L̶o̶o̶p̶ ̶в̶с̶ё̶ ̶р̶а̶в̶н̶о̶ ̶в̶ ̶п̶о̶б̶е̶д̶и̶т̶е̶л̶я̶х̶.̶
Что-то у меня фигня получается на Timed Loop'е:
0,44 , 6,35
0,10 , 13,74
0,08 , 13,91
0,06 , 15,00
0,17 , 8,47
Period = 2 ms, остальное по дефолту.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 13:51
Boris_K
Судя по вашему примеру, и по моему, который я делал по вашему, время выполнения одной итерации цикла складывается из времени выполнения нагрузочного когда плюс собственно задержки
Почему? В том моём примере (async) время итерации цикла должно быть равно времени задержки, без добавления времени выполнения нагрузки, т. к. в качестве задержки стоит Wait until next ms multiple. Если, конечно, нагрузка успевает выполняться за этот период (успевает). Ваш код на Delphi не разбирал, т. к. не приходилось на Delphi кодить.
Что-то у меня фигня получается на Timed Loop'е:
А в Deltatime.vi вы тоже поменяли Tick count на High resolution timer, и умножали на 1000? Тогда странно. Попробуйте оставить обычный Tick count.

А теперь снова печаль. Аналогичная тестовая прога с опросом спектрометра Avantes на Timed loop тормозится виндой по-прежнему, в том числе и когда она без UI и с асинхронным вызовом, и с одним потоком в коде, всё лишнее удалено, в ивент-структуре - только user event для получения сигнала о спектре, все вызовы dll - run in any thread. Все subVI пробовал делать сабрутинами и с нормальным приоритетом. Всё бестолку, хоть ты тресни. :dntknw: Уже называю это проклятием Авантеса.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 14:09
Blackman
dadreamer писал(а):
Что-то у меня фигня получается на Timed Loop'е:
Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 14:15
Boris_K
Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Конкретно этот док - ни о чём, и в данном контексте не поможет.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 16:15
dadreamer
Boris_K писал(а):А в Deltatime.vi вы тоже поменяли Tick count на High resolution timer, и умножали на 1000? Тогда странно.
Да. Вот и мне непонятно.
Boris_K писал(а):Попробуйте оставить обычный Tick count.
Поставил обычный Tick Count. Получаю:
1 , 9
0 , 6
0 , 7
1 , 12
1 , 4
Boris_K писал(а):А теперь снова печаль. Аналогичная тестовая прога с опросом спектрометра Avantes на Timed loop тормозится виндой по-прежнему, в том числе и когда она без UI и с асинхронным вызовом, и с одним потоком в коде, всё лишнее удалено, в ивент-структуре - только user event для получения сигнала о спектре, все вызовы dll - run in any thread. Все subVI пробовал делать сабрутинами и с нормальным приоритетом. Всё бестолку, хоть ты тресни. :dntknw: Уже называю это проклятием Авантеса.
Попробуйте тогда ждущий таймер, может, хоть он как-то спасёт ситуацию.
Asynchronous call goal.vi
lv2011
(12.66 КБ) 151 скачивание
Deltatime.vi
lv2011
(13.76 КБ) 156 скачиваний
Больше, увы, мне предложить нечего. Может, я упустил из виду... Зачем нужна такая высокая частота получения данных? Это как-то продиктовано производителем прибора? Возможно ли снизить интервал набора, скажем, до 50 мс на 1 пакет данных?
Blackman писал(а):Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Там нет ответа на вопрос, почему Timed Loop вдруг "выскакивает" за предел заданного в его настройках интервала, хотя позиционируется как высокоточный инструмент. По тем данным, что я приводил выше, видно, что Timed Loop может работать ничуть не хуже обычного While, а то и лучше (в некоторых случаях). Единственный ответ, который я здесь вижу - используемый RTC вносит погрешность времени 10-15 мс и в Timed Loop, так что его использование на Винде бессмысленно.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 20:03
Boris_K
Там нет ответа на вопрос, почему Timed Loop вдруг "выскакивает" за предел заданного в его настройках интервала
Ну там конечно упомянуто что винда - не ОСРВ.
Зачем нужна такая высокая частота получения данных? Это как-то продиктовано производителем прибора? Возможно ли снизить интервал набора, скажем, до 50 мс на 1 пакет данных?
Можно конечно. Но нужна именно большая скорость, максимум 5 мс на спектр. Продиктовано задачей.

Re: Странное торможение параллельных потоков

Добавлено: 03 июн 2016, 20:59
Boris_K
Попробуйте тогда ждущий таймер, может, хоть он как-то спасёт ситуацию.
Попробовал сейчас дома (WinXP), из .exe. Тестировал при активной работе с разными окнами. Задержки порядка 15 - 30 мс. Но когда поставил высокий приоритет у процесса:

2,13 , 4,43
2,02 , 3,83
2,33 , 3,53
2,23 , 4,60
2,31 , 6,74

То есть, в любом случае, этот таймер кардинально отличается от лабвьюшного wait, он всегда спасает от длительных задержек 250 - 270 мс при сворачивании/разворачивании окон. И проц не грузит. Улучшение налицо, но не идеально конечно. При тестах отключал антивирус. На работе на тех компах с WinXP его вообще нет (зато есть вирусы :crazy: ). На домашнем, с большой вероятностью, вирусов нет. В понедельник проверю со спектрометром.