Why Time.clock() Returns Such A Large Value On Windows Server 2008 X64

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

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