On 2005-12-07, Grant Edwards <[EMAIL PROTECTED]> wrote:
>>>> for f in range(10):
> ... print t()-t()
> ...
> -4.05311584473e-06
> -1.90734863281e-06
> -1.90734863281e-06
> -2.14576721191e-06
> -2.86102294922e-06
> -1.90734863281e-06
> -2.14576721191e-06
> -2.14576721191e-06
> -9.53674316406e-07
> -1.90734863281e-06
>
> The min delta seen is 0.95us. I'm guessing thats
> function/system call overhead and not timer resolution.
After looking at the implimentation of time.time under Linux,
it should have _exactly_ 1us resolution. I suspect that on a
Linux platform the resolution of time.time() is being limited
by IEEE double representation.
Yup:
>>> print len("%0.0f" % (time.time()*1e6,))
16
1us resolution for the time.time() value requires 16
significant digits. That's more than IEEE 64bit floating point
can represent accurately, and why the apparent resolution of
time.time() under Linux is only approximately 1us.
--
Grant Edwards grante Yow! Should I do my BOBBIE
at VINTON medley?
visi.com
--
http://mail.python.org/mailman/listinfo/python-list
