为什么 time.clock() 在 Windows Server 2008 X64 上返回如此大的值 [英] Why time.clock() returns such a large value on Windows Server 2008 X64

问题描述

我在不同的机器上运行以下脚本并得到完全不同的结果.经过的 time.clock() 是如此之大.

I ran following script on different machine and got quite different results. The elapsed time.clock() is so large.

脚本:

#------------------------------------------------------------------------------------
import time
start_clock = time.clock()
time.sleep(60)
end_clock = time.clock()
print "Sleep Clock = ", str(end_clock - start_clock)

start_time = time.time()
time.sleep(60)
end_time = time.time()
print "Sleep Time = ", str(end_time - start_time)
#-------------------------------------------------------------------------------------

输出:

Instance (Windows Server 2008, X64):
Sleep Clock =  938.306471633
Sleep Time =  60.0119998455

Local Machine (Windows Vista, X86):
Sleep Clock =  59.9997987873
Sleep Time =  59.996999979

下面的结果让我很困惑:
睡眠时钟 = 938.306471633

Following result really confused me:
Sleep Clock = 938.306471633

附:我没有在其他 X64 操作系统上测试过.此 Windows Server 2008 是一个正在运行的 Amazon 实例.

P.s: I have not tested on other X64 OSs. This Windows Server 2008 is a running Amazon Instance.

推荐答案

Per time.clock

在 Windows 上，此函数返回挂钟秒数过去了第一次调用这个函数，作为一个浮点数，基于 Win32 函数 QueryPerformanceCounter().

On Windows, this function returns wall-clock seconds elapsed since the first call to this function, as a floating point number, based on the Win32 function QueryPerformanceCounter().

所以我的(盲目的，即，我从未见过亚马逊的 Windows 虚拟化代码！-)猜测是亚马逊的虚拟化不够深入，无法欺骗 QueryPerformanceCounter(这是一个非常低级、低开销的功能).欺骗 time.time(在虚拟化管理程序中)更容易(也是更常见的需求).

so my (blind, i.e., I've never seen Amazon's code for Windows virtualization!-) guess would be that Amazon's virtualization doesn't go quite deep enough to trick QueryPerformanceCounter (which is a very low-level, low-overhead function). Tricking time.time (in a virtualizing hypervisor) is easier (and a more common need).

你知道会发生什么吗?在 Microsoft 的 Azure 上，以及与其他非 Microsoft 虚拟器(例如 Parallels 或 VMWare)一起使用?看到在每种情况下执行的诡计"(深度虚拟化)的数量不同，我不会感到惊讶.(我不怀疑对这种观察的解释一定与虚拟化有关，尽管我上面做出的具体猜测可能有缺陷).

Do you know what happens e.g. on Microsoft's Azure, and with other non-Microsoft virtualizers such as Parallels or VMWare? I wouldn't be surprised to see different "depth" to the amount of "trickery" (deep virtualization) performed in each case. (I don't doubt that the explanation for this observation must have to do with virtualization, although the specific guess I make above could be flawed).

尝试(再次，在各种不同的虚拟化器上)一个仅执行 QueryPerformanceCounter 的微型 C 程序也很有趣，只是为了确认 Python 的运行时与案例无关(我相信如此，通过检查运行时的源代码，但确认不会有什么坏处——不幸的是，我无法访问自己尝试所需的资源).

It would also be interesting to try (again, on various different virtualizers) a tiny C program doing just QueryPerformanceCounter, just to confirm that Python's runtime has nothing to do with the case (I believe so, by inspection of the runtime's source, but a confirmation could not hurt -- unfortunately I don't have access to the resources needed to try it myself).

这篇关于为什么 time.clock() 在 Windows Server 2008 X64 上返回如此大的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！