Re: Странное торможение параллельных потоков
Добавлено: 30 май 2016, 15:12
Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.Так что меняйте ОСь.
LabVIEW Portal, Forum, Chat, Tutorials
https://labviewportal.org/
Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.Так что меняйте ОСь.
На правах оффтопика. На работе везде стараюсь ставить семёрку 64 бита, а программки пишу в 64-битном . Это даёт доступ ко всему объёму оперативки для одного процесса, а также получаю распараллеливание потоков по всем ядрам процессора. В результате лучше быстродействие и больше доступных ресурсов для работы трудоёмких приложений (работа с изображениями / видео / мат. вычисления). Дома пользуюсь в основном тоже семёркой x64, порядком к ней привык уже. Хотя ставил и 8-ку, и 10. Восьмёрка не очень понравилась из-за неудачного (на мой взгляд) плиточного интерфейса, отсутствия Пуска, наличия Metro-приложений, "заточки" под сенсорные устройства. Можно, в принципе, её настроить, но на это тоже требуется время, которого на производстве может не быть. С семёркой такой возни намного меньше. 10-ку поставил ради интереса, выглядит красиво, не глючит, не тормозит, обновы часто прилетают. Но в итоге всё равно Пуск стандартный заменил на классический (через софтину). Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно). Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане. А то вдруг M$ подложит свинью какую.Boris_K писал(а):Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.
Купили мне ноут на работе с 10-ой. Поставил всё необходимое. К шпионским фишкам отношусь философски. Всё работает. На виртуалках развернул 7, ХР, Linux(OpenSUSE,Astra). Десятка нравится. Претензий к производительности и функционалу нет. То, что криво вставало на 8,8.1 , на 10 встало без проблем. Отключил визуальные эффекты, всё равно красиво) Нравится OpenSUSE и 10.Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане.
Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно)
Boris_K писал(а):Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/
http://www.ghacks.net/2015/08/14/compar ... acy-tools/dadreamer писал(а):Шпионские службы при желании отключаются [...] через сторонние софтины (которых тоже полным-полно).
Мы прекрасно видели проблемы с Wait, но проблем с Timed Loop нет. Как так происходит, раз один и тот же источник тактов?..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.
Рад, что так легко всё разрешилось. Кстати, всегда думал, что Timed Loop - это просто кастомизированный While Loop в виде XNode. Оказалось, что XNode там только как пристройка (входы-выходы по бокам цикла, диалоги настройки и прочие плюшки), а сама структура реализована внутри (в исходнике прописана). Так что в неё даже не залезть толком. Ещё у Timed Loop есть своя "фишка" - можно его остановить из другого цикла или через Stop Timed Structure (вызывается внутренняя функция из lvalarms.dll). Это можно даже во внешнем коде использовать.Boris_K писал(а):Решение нашёл. И оно лежит на поверхности Называется Timed loop.
В проге на получил такие результаты: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
Всё остальное как обычно: пауза после отрабатывания нагрузочного кода - 2 мс, прога работает 90 секунд, GUI полностью отключен. Проверял на семёрке, на XP проверю позже. ̶Х̶о̶т̶ь̶ ̶и̶ ̶р̶е̶з̶у̶л̶ь̶т̶а̶т̶ ̶с̶т̶а̶л̶ ̶л̶у̶ч̶ш̶е̶,̶ ̶н̶о̶ ̶T̶i̶m̶e̶d̶ ̶L̶o̶o̶p̶ ̶в̶с̶ё̶ ̶р̶а̶в̶н̶о̶ ̶в̶ ̶п̶о̶б̶е̶д̶и̶т̶е̶л̶я̶х̶.̶1,74 ; 2,24
1,47 ; 3,02
1,31 ; 3,08
1,20 ; 4,66
1,81 ; 3,11
В экзешнике тоже проверяли? Тоже нет тормозов на 7/XP? И такой ещё вопрос (сам сейчас не имею возможности проверить). Судя по вашему примеру, и по моему, который я делал по вашему, время выполнения одной итерации цикла складывается из времени выполнения нагрузочного когда плюс собственно задержки, т.е.Boris_K писал(а):В общем, проблему считаю решённой!
Что-то у меня фигня получается на Timed Loop'е:dadreamer писал(а): ̶Х̶о̶т̶ь̶ ̶и̶ ̶р̶е̶з̶у̶л̶ь̶т̶а̶т̶ ̶с̶т̶а̶л̶ ̶л̶у̶ч̶ш̶е̶,̶ ̶н̶о̶ ̶T̶i̶m̶e̶d̶ ̶L̶o̶o̶p̶ ̶в̶с̶ё̶ ̶р̶а̶в̶н̶о̶ ̶в̶ ̶п̶о̶б̶е̶д̶и̶т̶е̶л̶я̶х̶.̶
Period = 2 ms, остальное по дефолту.0,44 , 6,35
0,10 , 13,74
0,08 , 13,91
0,06 , 15,00
0,17 , 8,47
Почему? В том моём примере (async) время итерации цикла должно быть равно времени задержки, без добавления времени выполнения нагрузки, т. к. в качестве задержки стоит Wait until next ms multiple. Если, конечно, нагрузка успевает выполняться за этот период (успевает). Ваш код на Delphi не разбирал, т. к. не приходилось на Delphi кодить.Судя по вашему примеру, и по моему, который я делал по вашему, время выполнения одной итерации цикла складывается из времени выполнения нагрузочного когда плюс собственно задержки
А в Deltatime.vi вы тоже поменяли Tick count на High resolution timer, и умножали на 1000? Тогда странно. Попробуйте оставить обычный Tick count.Что-то у меня фигня получается на Timed Loop'е:
Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?dadreamer писал(а):Что-то у меня фигня получается на Timed Loop'е:
Конкретно этот док - ни о чём, и в данном контексте не поможет.Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Да. Вот и мне непонятно.Boris_K писал(а):А в Deltatime.vi вы тоже поменяли Tick count на High resolution timer, и умножали на 1000? Тогда странно.
Поставил обычный Tick Count. Получаю:Boris_K писал(а):Попробуйте оставить обычный Tick count.
1 , 9
0 , 6
0 , 7
1 , 12
1 , 4
Попробуйте тогда ждущий таймер, может, хоть он как-то спасёт ситуацию. Больше, увы, мне предложить нечего. Может, я упустил из виду... Зачем нужна такая высокая частота получения данных? Это как-то продиктовано производителем прибора? Возможно ли снизить интервал набора, скажем, до 50 мс на 1 пакет данных?Boris_K писал(а):А теперь снова печаль. Аналогичная тестовая прога с опросом спектрометра Avantes на Timed loop тормозится виндой по-прежнему, в том числе и когда она без UI и с асинхронным вызовом, и с одним потоком в коде, всё лишнее удалено, в ивент-структуре - только user event для получения сигнала о спектре, все вызовы dll - run in any thread. Все subVI пробовал делать сабрутинами и с нормальным приоритетом. Всё бестолку, хоть ты тресни. Уже называю это проклятием Авантеса.
Там нет ответа на вопрос, почему Timed Loop вдруг "выскакивает" за предел заданного в его настройках интервала, хотя позиционируется как высокоточный инструмент. По тем данным, что я приводил выше, видно, что Timed Loop может работать ничуть не хуже обычного While, а то и лучше (в некоторых случаях). Единственный ответ, который я здесь вижу - используемый RTC вносит погрешность времени 10-15 мс и в Timed Loop, так что его использование на Винде бессмысленно.Blackman писал(а):Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Ну там конечно упомянуто что винда - не ОСРВ.Там нет ответа на вопрос, почему Timed Loop вдруг "выскакивает" за предел заданного в его настройках интервала
Можно конечно. Но нужна именно большая скорость, максимум 5 мс на спектр. Продиктовано задачей.Зачем нужна такая высокая частота получения данных? Это как-то продиктовано производителем прибора? Возможно ли снизить интервал набора, скажем, до 50 мс на 1 пакет данных?
Попробовал сейчас дома (WinXP), из .exe. Тестировал при активной работе с разными окнами. Задержки порядка 15 - 30 мс. Но когда поставил высокий приоритет у процесса:Попробуйте тогда ждущий таймер, может, хоть он как-то спасёт ситуацию.