Why time.clock() returns such a large value on Windows Server 2008 X64

Question

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

Script:

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

Output:

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

Following result really confused me:
Sleep Clock = 938.306471633

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

Answer 1

Per the docs on time.clock

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().

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).

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).

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).