为什么在Windows Server 2008 X64上time.clock()返回如此大的值

Question

我在不同的机器上运行了以下脚本，结果差别很大。耗时的时间.clock()值非常大。

脚本：

#------------------------------------------------------------------------------------
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

附注：
我还没有在其他X64操作系统上测试过。这个Windows Server 2008是一个正在运行的亚马逊实例。

Answer 1

根据文档，关于time.clock这个函数：

在Windows系统上，这个函数会返回自第一次调用这个函数以来经过的实际时间，以浮点数的形式表示，这个时间是基于Win32的QueryPerformanceCounter()函数计算的。

所以我猜测，亚马逊的虚拟化技术可能没有深入到足够的层面，无法干扰QueryPerformanceCounter（这是一个非常底层、开销很小的函数）。而干扰time.time（在虚拟化的环境中）要简单一些，也更常见。

你知道在微软的Azure上会发生什么吗？还有其他非微软的虚拟化工具，比如Parallels或VMWare呢？我不会感到惊讶，如果每种情况的“干扰”程度不同（即虚拟化的深度不同）。我相信这个现象的解释一定和虚拟化有关，尽管我上面提到的具体猜测可能有误。

如果能在不同的虚拟化环境中尝试一个简单的C程序，只调用QueryPerformanceCounter，那就很有意思了，这样可以确认Python的运行时和这个情况没有关系（我相信是这样的，因为我查看了运行时的源代码，但确认一下总是好的——可惜我没有资源去自己尝试）。