Python time.sleep 与忙等待精度 [英] Python time.sleep vs busy wait accuracy

查看:156
本文介绍了Python time.sleep 与忙等待精度的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在使用 python 标准库中的 time.sleep 函数,发现它不适用于 sub-ms 延迟.从测试中我发现它实际上等待 1.1-1.2 毫秒等待 1 毫秒.实施忙等待使准确度达到 1% 以内.我用过:

def busy_wait(dt):current_time = time.time()而 (time.time() < current_time+dt):经过

并且可能会降低到 0.0001 秒,然后才打破 1% 的准确率.

我的主要问题是:

  • 为什么 sleep 函数如此不准确(可能是 C 问题)?获得具有更高时钟速度的更好 CPU 会改变这一点吗?
  • 为什么会有人使用睡眠?我看到的唯一优势是节能,仅限于嵌入式系统,不是吗?
  • 通过校准来补偿睡眠的不准确性是否可行?像这样:
<前>定义睡眠(dt):睡眠(校准功能(DT))

顺便说一句,我读到睡眠在等待时间过长的情况下甚至无法正常工作:Python time.sleep() 的上限?我还在 SO 上的某处阅读了制作更短时间间隔的循环以提高精度的内容,但是当我想延迟 0.01 秒时,这是无用的.Karl Voigtland 提到使用 ctypes 的 nanosleep,但我觉得这有点矫枉过正,而 time.sleep 应该按照预期的行为进行.

time.sleep 是一个损坏的 python 功能?还是没有人足够关心准确的时间测量?

解决方案

在 Windows 上,OS Sleep 函数(Python 必须使用)只能在当前计时器间隔的倍数上唤醒线程.通常,这范围在 1.0 毫秒和 15.6 毫秒之间.降低计时器间隔可能很方便,因为它可以缩短睡眠时间,但会浪费电力,正如我在本文中所写:

http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

忙等待可能会提供更好的准确性,但通常是一个可怕的想法,因为它会浪费更多电力并从更有价值的任务中窃取 CPU 时间:

https://randomascii.wordpress.com/2012/06/05/in-praise-of-idleness/

最后,忙等待的准确性将取决于您使用什么定时器函数来获取当前时间,也可能取决于定时器间隔:

https://randomascii.wordpress.com/2013/05/09/timegettime-versus-gettickcount/

你为什么要睡这么短的时间?通常最好等待某事发生——等待一个事件——而不是等待这么短的时间.

I was playing around with the time.sleep function from python's standard library and found it inadequate for sub-ms delays. From testing I found it to actually wait 1.1-1.2 ms for a 1ms wait. Implementing a busy wait got the accuracy to within 1%. I used:

def busy_wait(dt):   
    current_time = time.time()
    while (time.time() < current_time+dt):
        pass

and could get down to 0.0001 seconds before breaking 1% accuracy.

The main questions I have are:

  • Why is the sleep function so inaccurate (possibly a C issue)? Will getting a better CPU with a higher clock speed change this?
  • Why would anyone use sleep? The only advantage I see, power conservation, is limited to embedded systems, no?
  • Would it be viable to compensate for sleep's inaccuracy with calibration? Like so:

def sleep(dt):
    sleep(calibration_function(dt))

As an aside, I read that sleep doesn't even function well with long wait times: Upper limit in Python time.sleep()? I also read somewhere on SO of making a loop of shorter time intervals to increase precision, but that is useless when I want to delay 0.01 sec. Karl Voigtland mentions using ctypes' nanosleep, but I feel this is overkill and that time.sleep should do it's intended behavior.

time.sleep is a broken python feature? Or does nobody care about accurate time measurement enough?

解决方案

On Windows the OS Sleep function (which Python necessarily uses) can only wake up a thread on a multiple of the current timer interval. Typically this ranges between 1.0 ms and 15.6 ms. Lowering the timer interval can be handy because it allows for shorter sleeps, but it wastes electricity, as I wrote about in this article:

http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/

Busy waiting may give better accuracy but is generally a horrible idea since it wastes even more electricity and steals CPU time from more deserving tasks:

https://randomascii.wordpress.com/2012/06/05/in-praise-of-idleness/

Finally, the accuracy of busy waiting will depend on what timer function you are using to get the current time, and may also depend on the timer interval:

https://randomascii.wordpress.com/2013/05/09/timegettime-versus-gettickcount/

Why do you want to sleep for such short time periods? Usually it would be better to wait for something to happen -- waiting on an event -- rather than waiting for such short time periods.

这篇关于Python time.sleep 与忙等待精度的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆