Calculating Elapsed Time

[Bengt Richter]

On Wed, 07 Dec 2005 18:32:50 -0000, Grant Edwards <grante at visi.com> wrote:

>On 2005-12-07, Fredrik Lundh <fredrik at pythonware.com> wrote:
...
>> if I keep running the script over and over again, I do get individual
>>
>> -1.19209289551e-06
>>
>> items from time to time on both machines...
>
>We're seeing floating point representation issues.  
>
>The resolution of the underlying call is exactly 1us.  Calling
>gettimeofday() in a loop in C results in deltas of exactly 1 or
>2 us.  Python uses a C double to represent time, and a double
>doesn't have enough bit to accurately represent 1us resolution.
>
Is there a timer chip that is programmed to count at exactly 1us steps?
If this is trying to be platform independent, I think it has to be
faking it sometimes. E.g., I thought on windows you could sometimes
get a time based on a pentium time stamp counter, which gets 64 bits
with a RDTSC instruction and counts at full CPU clock rate (probably
affected by power management slowdown when applicable, but I don't know this),
If you write in C, you can set a base value (which ISTR clock does
the first time it's called) and return deltas that could fit at full time
stamp counter LSB resolution in the 53 bits of a double for quite a while,
even at a Ghz (over 100 days, I think ... let's see:
 >>> (2**53/1e9)/(24*3600)
 104.24999137431705
yep. So there has to be a floating convert and multiply in order to get seconds.

It would be interesting to dedicate a byte code to optimized inline raw time stamp reading
into successive 64-slots of a pre-allocated space, and have a way to get a call to
an identified funtion name be translated to this byte code instead of normal function call
instructions. One could do it with a byte-code-hacking decorator for code within a function
if the byte code were available, and a module giving access to the buffer were available.
Then the smallest interval would be a loop through the byte code switch (I think you
can read the register in user mode, unless a bit has been set to prevent it, so there
shouldn't even be kernel call and context switch overhead. Of course, if no counter is available,
the byte code would probably have to raise an exception instead, or fake it with a timer chip register.

I have a rdtsc.dll module, but I haven't re-compiled it for current version. Another back burner
thing. (I was trying to get CPU chip version detection right so the module would refuse to
load if there wasn't a suitable chip, IIRC). Sigh.

Regards,
Bengt Richter