а как вы видите практическое применение GetMicrosecondCount что оно вам портит всю работу программы в текущем варианте ? опишите практическое применение
я к примеру ни в С++ ни тут не вижу вариантов, кроме тех, что описал Ренат, т.е. замер времени исполнения кода с точность в mcs
т.е. я не понимаю вашего упорства если честно
Область применения этой функции весьма обширна, если есть полет фантазии. Я уже говорил выше от мультитаймере, который позволяет запускать несколько таймеров с разными периодами одновременно. Об этом также уже писал fxsaber . Микросекундная функция в сравнении с миллисекундной удобна не только для теста скорости выполнения, но и для снятия различной телеметрической информации в процессе работы советников. Если точность такой телеметрии в 16 мс ( точнее 1/64 с = 15625 микросекунд) - то это весьма большая погрешность.
Настроено, но не помогает - не понимаю причину. Правда сервер у меня ntp2.stratum2.ru
Если Вы для счетчика таких больших промежутков времени используете GetTickCount, то проблем быть не должно. Проблемы будут если Вы используете GetMicrosecondCount. Если использование микросекундной функции - это принципиальный момент, то лучше тогда использовать этот вариант функции.
Если Вы для счетчика таких больших промежутков времени используете GetTickCount, то проблем быть не должно. Проблемы будут если Вы используете GetMicrosecondCount. Если использование микросекундной функции - это принципиальный момент, то лучше тогда использовать этот вариант функции.
Slava: Какова вероятность изменения локального времени компьютера между двумя вызовами GetMicrosecondsCount, используемых для замера времени в микросекундах?
Это зависит, в первую очередь, от заданного периода синхронизации системного времени с временем интернета. У меня например задана синхронизация раз в сутки, и за это время набегает более 1 с расхождения. У кого-то синхронизируется раз в час, или ещё чаще. Вот и прикидывайте вероятность.
...так как уже знаю о такой особенности работы GetMicrosecondCount() и что эта функции более чем на порядок медленее GetTickCount.
Полагаю, такая медлительность связана с тем, что помимо получения нативного PerfomanceCount там дополнительно дёргается локальное время, вот и приходится оплачивать эту медвежью услугу. Если бы сравнивалась скорость непосредственно PerfomanceCount и GetTickCount, то разница была бы гораздо меньше.
Хотя, честно говоря, мне не очень понятны эти разговоры о скорости выполнения, когда речь идёт о 2-20 наносекундах. Эту разницу реально ощутить только гоняя практически пустой цикл (с данной функцией) на сотне миллионов итераций. Это само по себе неправильно спроектированное решение.
И да, вас точно также взорвет чистая WinAPI функция (что GetTickCount, что QueryPerformanceCounter), когда вы подсунете лом в бензопилу, поменяв дату даже на секунды. Вообще нет никакой защиты, о якобы наличии которой вы говорите. Высосанная из пальца как проблема, так и якобы решение.
Так что все верно - таков WinAPI и такова реальность.
Вы ошибаетесь. Я же вот здесь специально привёл код с использованием WinApi. Запустите, поменяйте часы в процессе, и посмотрите на результат.
Не очень понятно, как с вами вести какой-либо диалог, если ваши аргументы основаны на домыслах. И даже не считаете нужным ознакомиться с ходом обсуждения темы.
Область применения этой функции весьма обширна, если есть полет фантазии. Я уже говорил выше от мультитаймере, который позволяет запускать несколько таймеров с разными периодами одновременно. Об этом также уже писал fxsaber . Микросекундная функция в сравнении с миллисекундной удобна не только для теста скорости выполнения, но и для снятия различной телеметрической информации в процессе работы советников. Если точность такой телеметрии в 16 мс ( точнее 1/64 с = 15625 микросекунд) - то это весьма большая погрешность.
я замеряю постоянно скорость исполнения, о чем писал Ренат, проблем ни когда не видел, вы похоже накручиваете из пустого, либо не хотите написанное ранее изменить, так бывает когда как говорится наго...шь и потом понимаешь что писалось все зря, без обид, но тот же приведенный вами мультитаймер спокойно реализовывается без всяких погрешностей, но за это придется платить, Ренат выше так же давал описание в ответе на мой вопрос
Это зависит, в первую очередь, от заданного периода синхронизации системного времени с временем интернета. У меня например задана синхронизация раз в сутки, и за это время набегает более 1 с расхождения. У кого-то синхронизируется раз в час, или ещё чаще. Вот и прикидывайте вероятность.
а как вы видите практическое применение GetMicrosecondCount что оно вам портит всю работу программы в текущем варианте ? опишите практическое применение
я к примеру ни в С++ ни тут не вижу вариантов, кроме тех, что описал Ренат, т.е. замер времени исполнения кода с точность в mcs
т.е. я не понимаю вашего упорства если честно
Область применения этой функции весьма обширна, если есть полет фантазии.
Я уже говорил выше от мультитаймере, который позволяет запускать несколько таймеров с разными периодами одновременно.
Об этом также уже писал fxsaber .
Микросекундная функция в сравнении с миллисекундной удобна не только для теста скорости выполнения, но и для снятия различной телеметрической информации в процессе работы советников.
Если точность такой телеметрии в 16 мс ( точнее 1/64 с = 15625 микросекунд) - то это весьма большая погрешность.
Настроено, но не помогает - не понимаю причину. Правда сервер у меня ntp2.stratum2.ru
Если Вы для счетчика таких больших промежутков времени используете GetTickCount, то проблем быть не должно.
Проблемы будут если Вы используете GetMicrosecondCount.
Если использование микросекундной функции - это принципиальный момент, то лучше тогда использовать этот вариант функции.
Информация для принятия к сведению:
Примерное время выполнения функций:
- GetTickCount - ~ 2 нс
- GetMicrosecondCount - ~ 30 нс
- RealMicrosecondCount - ~ 40 нс
Если Вы для счетчика таких больших промежутков времени используете GetTickCount, то проблем быть не должно.
Проблемы будут если Вы используете GetMicrosecondCount.
Если использование микросекундной функции - это принципиальный момент, то лучше тогда использовать этот вариант функции.
Информация для принятия к сведению:
Примерное время выполнения функций:
- GetTickCount - ~ 2 нс
- GetMicrosecondCount - ~ 30 нс
- RealMicrosecondCount - ~ 40 нс
Я использую чужой код, там как то вообще нет этих функций, но эффект рассинхронизации возникает.
Какова вероятность изменения локального времени компьютера между двумя вызовами GetMicrosecondsCount, используемых для замера времени в микросекундах?
Это зависит, в первую очередь, от заданного периода синхронизации системного времени с временем интернета. У меня например задана синхронизация раз в сутки, и за это время набегает более 1 с расхождения. У кого-то синхронизируется раз в час, или ещё чаще. Вот и прикидывайте вероятность.
...так как уже знаю о такой особенности работы GetMicrosecondCount() и что эта функции более чем на порядок медленее GetTickCount.
Полагаю, такая медлительность связана с тем, что помимо получения нативного PerfomanceCount там дополнительно дёргается локальное время, вот и приходится оплачивать эту медвежью услугу. Если бы сравнивалась скорость непосредственно PerfomanceCount и GetTickCount, то разница была бы гораздо меньше.
Хотя, честно говоря, мне не очень понятны эти разговоры о скорости выполнения, когда речь идёт о 2-20 наносекундах. Эту разницу реально ощутить только гоняя практически пустой цикл (с данной функцией) на сотне миллионов итераций. Это само по себе неправильно спроектированное решение.
И да, вас точно также взорвет чистая WinAPI функция (что GetTickCount, что QueryPerformanceCounter), когда вы подсунете лом в бензопилу, поменяв дату даже на секунды. Вообще нет никакой защиты, о якобы наличии которой вы говорите. Высосанная из пальца как проблема, так и якобы решение.
Так что все верно - таков WinAPI и такова реальность.
Вы ошибаетесь. Я же вот здесь специально привёл код с использованием WinApi. Запустите, поменяйте часы в процессе, и посмотрите на результат.
Не очень понятно, как с вами вести какой-либо диалог, если ваши аргументы основаны на домыслах. И даже не считаете нужным ознакомиться с ходом обсуждения темы.
Область применения этой функции весьма обширна, если есть полет фантазии.
Я уже говорил выше от мультитаймере, который позволяет запускать несколько таймеров с разными периодами одновременно.
Об этом также уже писал fxsaber .
Микросекундная функция в сравнении с миллисекундной удобна не только для теста скорости выполнения, но и для снятия различной телеметрической информации в процессе работы советников.
Если точность такой телеметрии в 16 мс ( точнее 1/64 с = 15625 микросекунд) - то это весьма большая погрешность.
я замеряю постоянно скорость исполнения, о чем писал Ренат, проблем ни когда не видел, вы похоже накручиваете из пустого, либо не хотите написанное ранее изменить, так бывает когда как говорится наго...шь и потом понимаешь что писалось все зря, без обид, но тот же приведенный вами мультитаймер спокойно реализовывается без всяких погрешностей, но за это придется платить, Ренат выше так же давал описание в ответе на мой вопрос
Уста Истинны немы для непосвященных.
ну так то да ))
Это зависит, в первую очередь, от заданного периода синхронизации системного времени с временем интернета. У меня например задана синхронизация раз в сутки, и за это время набегает более 1 с расхождения. У кого-то синхронизируется раз в час, или ещё чаще. Вот и прикидывайте вероятность.
Вы вопрос точно весь прочитали?
...между двумя вызовами GetMicrosecondsCount...