On Wed, 07 Dec 2005 18:32:50 -0000, Grant Edwards <[EMAIL PROTECTED]> wrote:
>On 2005-12-07, Fredrik Lundh <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
