Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.Так что меняйте ОСь.
Странное торможение параллельных потоков
Re: Странное торможение параллельных потоков
Race conditions - опасный и скользкий баг!
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
На правах оффтопика. На работе везде стараюсь ставить семёрку 64 бита, а программки пишу в 64-битном . Это даёт доступ ко всему объёму оперативки для одного процесса, а также получаю распараллеливание потоков по всем ядрам процессора. В результате лучше быстродействие и больше доступных ресурсов для работы трудоёмких приложений (работа с изображениями / видео / мат. вычисления). Дома пользуюсь в основном тоже семёркой x64, порядком к ней привык уже. Хотя ставил и 8-ку, и 10. Восьмёрка не очень понравилась из-за неудачного (на мой взгляд) плиточного интерфейса, отсутствия Пуска, наличия Metro-приложений, "заточки" под сенсорные устройства. Можно, в принципе, её настроить, но на это тоже требуется время, которого на производстве может не быть. С семёркой такой возни намного меньше. 10-ку поставил ради интереса, выглядит красиво, не глючит, не тормозит, обновы часто прилетают. Но в итоге всё равно Пуск стандартный заменил на классический (через софтину). Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно). Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане. А то вдруг M$ подложит свинью какую.Boris_K писал(а):Новее Win7 как-то не тянет ставить, не нужен мне наглый персональный шпион. Всё чаще смотрю в сторону Linux. Сорри за оффтоп, не удержался.
-
Vitekkz88
- expert
- Сообщения: 1100
- Зарегистрирован: 21 янв 2014, 15:45
- Награды: 3
- Версия LabVIEW: 12,13,14
- Откуда: Томск
- Контактная информация:
Re: Странное торможение параллельных потоков
Купили мне ноут на работе с 10-ой. Поставил всё необходимое. К шпионским фишкам отношусь философски. Всё работает. На виртуалках развернул 7, ХР, Linux(OpenSUSE,Astra). Десятка нравится. Претензий к производительности и функционалу нет. То, что криво вставало на 8,8.1 , на 10 встало без проблем. Отключил визуальные эффекты, всё равно красиво) Нравится OpenSUSE и 10.Однако для работы 10-ку пока ставить не рискую, мало ли что. Подождём пока полгодика, посмотрим тенденции в этом плане.
Ах да, тулкиты я не использую и на 10 не устанавливал.
Инженер - это открыто светящийся интеллект, свободный и не обидный юмор, это легкость и широта мысли...Это воспитанность, тонкость вкусов, хорошая речь, плавно согласованная и без сорных словечек...
-А. И. Солженицын
-А. И. Солженицын
Re: Странное торможение параллельных потоков
Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/Шпионские службы при желании отключаются либо вручную (в сети есть мануалы), либо через сторонние софтины (которых тоже полным-полно)
Race conditions - опасный и скользкий баг!
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
Boris_K писал(а):Весь вопрос в том, что именно отключать. И какие именно утилиты юзать. Штатными средствами винды всё не отключишь. Надеюсь видели эту статью? https://xakep.ru/2015/09/03/windows-10-spying/
http://www.ghacks.net/2015/08/14/compar ... acy-tools/dadreamer писал(а):Шпионские службы при желании отключаются [...] через сторонние софтины (которых тоже полным-полно).
Re: Странное торможение параллельных потоков
Возвращаясь к основной теме. Решение нашёл. И оно лежит на поверхности Называется Timed loop. Как-то всегда обходил его стороной. Со всеми терминалами, выглядит он конечно монструозно. Но выкурив справку, понял, что в большинстве случаев не нужны никакие доп. настройки, кроме задания периода цикла.
Во время выполнения тестовой проги запускал другие проги, "мурыжил" окна. Бывало вообще без тормозов, а макс. тормоза что видел - 2 - 3 мс (это на старых компах с WinXP!). Вот где, наверное, уже действительно сказывается не реалтаймовость винды. От переключения в UI-поток он, конечно, не спасёт, поэтому все элементы, чувствительные к потоку UI, надо также выносить из этого цикла. Но проделав это, получаем почти идеальную работу. Причём лишней загрузки процессора не происходит, то есть, в оставшееся свободное время на каждой итерации, цикл действительно "спит".
Причём приоритет процесса даже не пришлось увеличивать. Ещё интересно, что структура эта позволяет замерять время между итерациями в наносекундах! Ясно что это задел для различных аппаратных таргетов, но на компе это тоже работает, правда, вопрос, с какой точностью. В общем, проблему считаю решённой!
Во время выполнения тестовой проги запускал другие проги, "мурыжил" окна. Бывало вообще без тормозов, а макс. тормоза что видел - 2 - 3 мс (это на старых компах с WinXP!). Вот где, наверное, уже действительно сказывается не реалтаймовость винды. От переключения в UI-поток он, конечно, не спасёт, поэтому все элементы, чувствительные к потоку UI, надо также выносить из этого цикла. Но проделав это, получаем почти идеальную работу. Причём лишней загрузки процессора не происходит, то есть, в оставшееся свободное время на каждой итерации, цикл действительно "спит".
Причём приоритет процесса даже не пришлось увеличивать. Ещё интересно, что структура эта позволяет замерять время между итерациями в наносекундах! Ясно что это задел для различных аппаратных таргетов, но на компе это тоже работает, правда, вопрос, с какой точностью. В общем, проблему считаю решённой!
Race conditions - опасный и скользкий баг!
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
Я тоже его избегал вплоть до текущего момента, считая предназначенным почти полностью для RT-платформ. Пробовал несколько раз его вместо обычного While, но особых преимуществ не увидел, только минус в виде излишней загромождённости.
А тут... Кто бы мог подумать...
Полезная инфа, буду иметь в виду в своих проектах, у меня тоже есть весьма чувствительные в плане времени циклы. Кстати, интересно, как он внутри устроен и как ему удаётся сохранять такую стабильность показаний времени?.. Из официальной инфы я нашёл только это - Timing and Synchronization in NI LabVIEW. И там есть вот такая картинка: Судя по ней используется внутренний источник тактов (верхняя линия) Real-Time Clock (RTC), который также используется и для GetTickCount. А погрешность измерения таймера для GetTickCount составляет 10-15 мс. Отсюда не совсем понятно, откуда берутся наносекунды с такой точностью. Ещё более непонятна эта фраза:
Порылся тут ещё в гугле, нашёл альтернативу Sleep - ждущие таймеры: http://stackoverflow.com/questions/1339 ... -1ms-error (последний пост + пример). Будет интересно посмотреть, какая точность получится в результате. Это, скорее всего, завтра проверю.
А тут... Кто бы мог подумать...
Полезная инфа, буду иметь в виду в своих проектах, у меня тоже есть весьма чувствительные в плане времени циклы. Кстати, интересно, как он внутри устроен и как ему удаётся сохранять такую стабильность показаний времени?.. Из официальной инфы я нашёл только это - Timing and Synchronization in NI LabVIEW. И там есть вот такая картинка: Судя по ней используется внутренний источник тактов (верхняя линия) Real-Time Clock (RTC), который также используется и для GetTickCount. А погрешность измерения таймера для GetTickCount составляет 10-15 мс. Отсюда не совсем понятно, откуда берутся наносекунды с такой точностью. Ещё более непонятна эта фраза:
Мы прекрасно видели проблемы с 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.
Порылся тут ещё в гугле, нашёл альтернативу Sleep - ждущие таймеры: http://stackoverflow.com/questions/1339 ... -1ms-error (последний пост + пример). Будет интересно посмотреть, какая точность получится в результате. Это, скорее всего, завтра проверю.
Рад, что так легко всё разрешилось. Кстати, всегда думал, что Timed Loop - это просто кастомизированный While Loop в виде XNode. Оказалось, что XNode там только как пристройка (входы-выходы по бокам цикла, диалоги настройки и прочие плюшки), а сама структура реализована внутри (в исходнике прописана). Так что в неё даже не залезть толком. Ещё у Timed Loop есть своя "фишка" - можно его остановить из другого цикла или через Stop Timed Structure (вызывается внутренняя функция из lvalarms.dll). Это можно даже во внешнем коде использовать.Boris_K писал(а):Решение нашёл. И оно лежит на поверхности Называется Timed loop.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
Попробовал сегодня заменить обычную задержку на ждущий таймер. Результат заметно улучшился. В проге на Delphi теперь выдаёт
Т сум. = Т кода + Т wait, где T wait = 2 ms.
Timed Loop ведёт себя так же, или получается следующее:
Т сум. = Т кода + (Т wait - Т кода) = Т wait (когда Т кода < 2 ms)
Т сум. = Т кода (когда Т кода > 2 ms)
В первом случае имеем высокоточный аналог Wait, во втором - код реально выполняется с заданной частотой, независимо от времени выполнения самого кода.
В проге на получил такие результаты: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 писал(а):В общем, проблему считаю решённой!
Т сум. = Т кода + Т wait, где T wait = 2 ms.
Timed Loop ведёт себя так же, или получается следующее:
Т сум. = Т кода + (Т wait - Т кода) = Т wait (когда Т кода < 2 ms)
Т сум. = Т кода (когда Т кода > 2 ms)
В первом случае имеем высокоточный аналог Wait, во втором - код реально выполняется с заданной частотой, независимо от времени выполнения самого кода.
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
Что-то у меня фигня получается на 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
Re: Странное торможение параллельных потоков
Почему? В том моём примере (async) время итерации цикла должно быть равно времени задержки, без добавления времени выполнения нагрузки, т. к. в качестве задержки стоит Wait until next ms multiple. Если, конечно, нагрузка успевает выполняться за этот период (успевает). Ваш код на Delphi не разбирал, т. к. не приходилось на Delphi кодить.Судя по вашему примеру, и по моему, который я делал по вашему, время выполнения одной итерации цикла складывается из времени выполнения нагрузочного когда плюс собственно задержки
А в Deltatime.vi вы тоже поменяли Tick count на High resolution timer, и умножали на 1000? Тогда странно. Попробуйте оставить обычный Tick count.Что-то у меня фигня получается на Timed Loop'е:
А теперь снова печаль. Аналогичная тестовая прога с опросом спектрометра Avantes на Timed loop тормозится виндой по-прежнему, в том числе и когда она без UI и с асинхронным вызовом, и с одним потоком в коде, всё лишнее удалено, в ивент-структуре - только user event для получения сигнала о спектре, все вызовы dll - run in any thread. Все subVI пробовал делать сабрутинами и с нормальным приоритетом. Всё бестолку, хоть ты тресни. Уже называю это проклятием Авантеса.
Последний раз редактировалось Boris_K 03 июн 2016, 15:18, всего редактировалось 3 раза.
Race conditions - опасный и скользкий баг!
-
- leader
- Сообщения: 932
- Зарегистрирован: 17 янв 2016, 15:02
- Награды: 1
- Версия LabVIEW: 6.1,8.5,20
Re: Странное торможение параллельных потоков
Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?dadreamer писал(а):Что-то у меня фигня получается на Timed Loop'е:
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Re: Странное торможение параллельных потоков
Конкретно этот док - ни о чём, и в данном контексте не поможет.Why Is a Timed Loop Slower Than a Regular While Loop in LabVIEW?
http://digital.ni.com/public.nsf/allkb/ ... 9C001EB323
Race conditions - опасный и скользкий баг!
-
dadreamer
- professor
- Сообщения: 3926
- Зарегистрирован: 17 фев 2013, 16:33
- Награды: 4
- Версия LabVIEW: 2.5 — 2022
- Благодарил (а): 11 раз
- Поблагодарили: 127 раз
- Контактная информация:
Re: Странное торможение параллельных потоков
Да. Вот и мне непонятно.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
Re: Странное торможение параллельных потоков
Ну там конечно упомянуто что винда - не ОСРВ.Там нет ответа на вопрос, почему Timed Loop вдруг "выскакивает" за предел заданного в его настройках интервала
Можно конечно. Но нужна именно большая скорость, максимум 5 мс на спектр. Продиктовано задачей.Зачем нужна такая высокая частота получения данных? Это как-то продиктовано производителем прибора? Возможно ли снизить интервал набора, скажем, до 50 мс на 1 пакет данных?
Race conditions - опасный и скользкий баг!
Re: Странное торможение параллельных потоков
Попробовал сейчас дома (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 его вообще нет (зато есть вирусы ). На домашнем, с большой вероятностью, вирусов нет. В понедельник проверю со спектрометром.
Race conditions - опасный и скользкий баг!
-
- Похожие темы
- Ответы
- Просмотры
- Последнее сообщение