time.clock（）倒退？ [英] time.clock() going backwards??
问题描述
你好，
我几天前尝试了一些非常奇怪的事情。我在客户的网站上调试了一个
的应用程序，结果问题是
time.clock（）正在向后，是否有时（随机）
返回一个小于的浮点值。上一次调用返回的值为
。计算机是一个相当快的计算机（我认为P4 3Ghz，运行Windows XP的价格为b $ b），这只发生在非常接近的时间内。
time.clock（）。 br />
我已经对此进行了三重验证，包括打印浮动
点数的repr（）并验证它是否比之前的值少了一些
微秒。换句话说，我绝对肯定这不是一个错误
在我身边，但那个time.clock（）显然是向后跳。
当然，这让我的应用程序感到困惑，而且我只是为了忽略这些虚假的读取，而只是再次阅读。由于错误
只有几微秒，读取time.clock（）再次产生一个数字
，这比我之前的数字高，因此可以应用程序。
我想知道是否有人之前曾尝试过这种行为。我试过了
谷歌搜索但没有效果。这可能是Python本身的一个错误
（也许，在月球上拍摄，在64位性能之间的转换中，
计数器和返回的浮点表示time.clock（）），或者
可能是Windows本身或主板驱动程序中的错误（如果是这样的话，那么
就不会有其他应用程序开始运行了疯了）？
-
Giovanni Bajo
Hello,
I experimented something very strange, a few days ago. I was debugging an
application at a customer''s site, and the problem turned out to be that
time.clock() was going "backwards", that is it was sometimes (randomically)
returning a floating point value which was "less than" the value returned by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I think,
running Windows XP), and this happened only between very close invokations of
time.clock().
I have triple-verified this, including printing the repr() of the floating
point number and verifying it was really minor than the previous value by a few
microseconds. In other words, I''m absolutely positive that it''s not a mistake
on my side, but that time.clock() was really apparently "jumping backward".
This was confusing the hell out of my application, of course, and I just hacked
it so to ignore these bogus reads, and just reading off again. Since the error
was just of a few microseconds, reading time.clock() again produces a number
which was higher than what I had before, and thus OK for my application.
I was wondering if someone had experimented this behaviour before. I tried
googling but to no effect. Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit performance
counter and the floating point representation returned by time.clock()), or
could it be a bug in Windows itself or the mother board drivers (buf if so,
wouldn''t other application start going mad)?
--
Giovanni Bajo
推荐答案
Op 25-aug-2006，om 16:13 heeft Giovanni Bajo het volgende geschreven：
Op 25-aug-2006, om 16:13 heeft Giovanni Bajo het volgende geschreven:
你好，
这可能是Python本身的一个错误
（也许，在月球拍摄，64bit之间的转换
性能
计数器和时间点返回的浮点表示
（）），或者
可能是Windows本身或主板驱动程序中的错误
（如果是这样的话，
就不会其他了应用程序开始疯了）？
-
Giovanni Bajo
Hello,
Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit
performance
counter and the floating point representation returned by time.clock
()), or
could it be a bug in Windows itself or the mother board drivers
(buf if so,
wouldn''t other application start going mad)?
--
Giovanni Bajo
非常有趣！虽然我不可能知道答案，但是我想知道你使用的是哪个版本的Python。这是
出血边缘2.5发布候选人吗？
Michiel
Very interesting! While I couldn''t possibly know the answer to this,
I do wonder which version of Python you were using. Is it the
bleeding edge 2.5 release candidate?
Michiel
Giovanni Bajo写道：
Giovanni Bajo wrote:
你好，
几天前我尝试了一些很奇怪的东西。我在客户的网站上调试了一个
的应用程序，结果问题是
time.clock（）正在向后，是否有时（随机）
返回一个小于的浮点值。上一次调用返回的值为
。计算机是一个相当快的计算机（我认为P4 3Ghz，运行Windows XP的价格为b $ b），这只发生在非常接近的时间内。
time.clock（）。 br />
我已经对此进行了三重验证，包括打印浮动
点数的repr（）并验证它是否比之前的值少了一些
微秒。换句话说，我绝对肯定这不是一个错误
在我身边，但那个time.clock（）显然是向后跳。
当然，这让我的应用程序感到困惑，而且我只是为了忽略这些虚假的读取，而只是再次阅读。由于错误
只有几微秒，读取time.clock（）再次产生一个数字
，这比我之前的数字高，因此可以应用程序。
我想知道是否有人之前曾尝试过这种行为。我试过了
谷歌搜索但没有效果。这可能是Python本身的一个错误
（也许，在月球上拍摄，在64位性能之间的转换中，
计数器和返回的浮点表示time.clock（）），或者
可能是Windows本身或主板驱动程序中的错误（buf ifso，
其他应用程序开始不会疯狂）？
Hello,
I experimented something very strange, a few days ago. I was debugging an
application at a customer''s site, and the problem turned out to be that
time.clock() was going "backwards", that is it was sometimes (randomically)
returning a floating point value which was "less than" the value returned by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I think,
running Windows XP), and this happened only between very close invokations of
time.clock().
I have triple-verified this, including printing the repr() of the floating
point number and verifying it was really minor than the previous value by a few
microseconds. In other words, I''m absolutely positive that it''s not a mistake
on my side, but that time.clock() was really apparently "jumping backward".
This was confusing the hell out of my application, of course, and I just hacked
it so to ignore these bogus reads, and just reading off again. Since the error
was just of a few microseconds, reading time.clock() again produces a number
which was higher than what I had before, and thus OK for my application.
I was wondering if someone had experimented this behaviour before. I tried
googling but to no effect. Is it possible this to be a bug in Python itself
(maybe, shooting at the moon, in the conversion between the 64bit performance
counter and the floating point representation returned by time.clock()), or
could it be a bug in Windows itself or the mother board drivers (buf ifso,
wouldn''t other application start going mad)?
来自QueryPerformanceCounter的MSDN文档：
备注：
在多处理器计算机上，无论哪个处理器被称为
都无所谓。但是，由于基本输入/输出系统（BIOS）或硬件
抽象层（HAL）中的错误，您可以在不同的处理器上获得不同的结果
。要指定线程的处理器关联，请使用
SetThreadAffinityMask函数。
您是在多核或多处理器计算机上运行吗？ />
解决这个问题的最佳方法可能是让你的应用程序对这种情况给予
''宽容'。
[sreeram;]
-----开始PGP SIGNATURE -----
版本：GnuPG v1.4.2.2（MingW32）
评论：将GnuPG与Mozilla一起使用 - http://enigmail.mozdev.org
iD8DBQFE7yhsrgn0plK5qqURAp1sAJ9mOO0UbZUhjZQsjew3ro LGQHUabACgvwCJ
I8wDMKiuL2xF / dY7d2b1ccA =
= hRd5
----- END PGP签名-----
From the MSDN docs for QueryPerformanceCounter:
Remarks:
On a multiprocessor computer, it should not matter which processor is
called. However, you can get different results on different processors
due to bugs in the basic input/output system (BIOS) or the hardware
abstraction layer (HAL). To specify processor affinity for a thread, use
the SetThreadAffinityMask function.
Are you running on a multi-core or a multi-processor machine?
The best way to handle this is probably to make your application
''tolerant'' to such cases.
[sreeram;]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE7yhsrgn0plK5qqURAp1sAJ9mOO0UbZUhjZQsjew3ro LGQHUabACgvwCJ
I8wDMKiuL2xF/dY7d2b1ccA=
=hRd5
-----END PGP SIGNATURE-----
" Giovanni Bajo" < no *** @ sorry.comwrote in message
news：vk ******************** @ twister2.libero.it。 ..
"Giovanni Bajo" <no***@sorry.comwrote in message
news:vk********************@twister2.libero.it...
您好，
我几天前尝试了一些非常奇怪的事情。我在客户的网站上调试了一个
的应用程序，结果问题是
time.clock（）正在向后，是否有时
（随机）
返回一个小于的浮点值返回值
由
上一次调用。计算机是一个相当快的计算机（P4 3Ghz我认为，运行Windows XP的是
），这只发生在非常接近的
调用之间
time.clock（）。
Hello,
I experimented something very strange, a few days ago. I was debugging an
application at a customer''s site, and the problem turned out to be that
time.clock() was going "backwards", that is it was sometimes
(randomically)
returning a floating point value which was "less than" the value returned
by
the previous invokation. The computer was a pretty fast one (P4 3Ghz I
think,
running Windows XP), and this happened only between very close
invokations of
time.clock().
我似乎记得以前在名单上提到这个，也许是由Tim
Peters。也许他会参与其中。
tjr
I seem to remember this being mentioned before on the list, perhaps by Tim
Peters. Perhaps he will chime in.
tjr
这篇关于time.clock（）倒退？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
