In message <[EMAIL PROTECTED]>, Peter Hansen
<[EMAIL PROTECTED]> writes
(I've read the five or so following messages you and Bengt
have posted, but not in detail so I'm not sure where you're
going with all this, but... )
We've gone off at a tangent about Windows timing etc. Pretty much over
now.
Stephen Kellett wrote:
that time.clock() is inaccurate. The problem is that the "time.clock()"
statement takes several hundred microseconds to execute.
The statement is incorrect. clock() itself isn't slow, but it is
accessing a resource, the accuracy of which is no better than 1ms.
There are va
In message <[EMAIL PROTECTED]>, Bengt Richter
<[EMAIL PROTECTED]> writes
>>QueryPerformanceCounter is 47 times slower to call than clock() on my
>>1Ghz Athlon.
>That really makes me wonder. Perhaps the Athlon handles RDTSC by way of
>an illegal instruction trap and faking the pentium instruction?
On Tue, 25 Jan 2005 15:46:30 +, Stephen Kellett <[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>, Bengt Richter
><[EMAIL PROTECTED]> writes
>>I believe that is quite wrong as a general statement.
>
>Actually my initial statement should have been written
>"accessing a resource, the a
In message <[EMAIL PROTECTED]>, Bengt Richter
<[EMAIL PROTECTED]> writes
I believe that is quite wrong as a general statement.
Actually my initial statement should have been written
"accessing a resource, the accuracy of which is no better than 10ms.". I
was thinking of the 1ms multimedia timer b
On Tue, 25 Jan 2005 11:42:35 +, Stephen Kellett <[EMAIL PROTECTED]> wrote:
>>>that time.clock() is inaccurate. The problem is that the "time.clock()"
>>>statement takes several hundred microseconds to execute.
>
>The statement is incorrect. clock() itself isn't slow, but it is
>accessing a r
that time.clock() is inaccurate. The problem is that the "time.clock()"
statement takes several hundred microseconds to execute.
The statement is incorrect. clock() itself isn't slow, but it is
accessing a resource, the accuracy of which is no better than 1ms.
There are various timers available,
On Tue, 25 Jan 2005 00:18:44 -0800, Tim Roberts <[EMAIL PROTECTED]> wrote:
>Ray Schumacher <[EMAIL PROTECTED]> wrote:
>>
>>I have a need for a time.clock() with >0.16 second (16us) accuracy.
>>The sleep() (on Python 2.3, Win32, at least) has a .001s limit.
>>
>>Are they lower/better on other's
Ray Schumacher <[EMAIL PROTECTED]> wrote:
>
>I have a need for a time.clock() with >0.16 second (16us) accuracy.
>The sleep() (on Python 2.3, Win32, at least) has a .001s limit.
>
>Are they lower/better on other's platforms?
You need to be careful about describing what you're seeing here. It
On my 2.8GHz P4, Windows 2000 SP4 with Python 2.3.4 I am getting
totally different results compared to Ray. Does Python 2.3.4 already
use the Pentium RTDSC instruction for clock()?
Claudio
# \> Claudio Grondi, 2.8GHz P4 Python 2.3.4 (2005-01-24 14:32)
# time of taking time:
# 0.013968255742
Ray Schumacher <[EMAIL PROTECTED]> writes:
> I have a need for a time.clock() with >0.16 second (16us) accuracy.
> The sleep() (on Python 2.3, Win32, at least) has a .001s limit.
>
> Are they lower/better on other's platforms?
>
> The alternative appears to be more C code...
C code is your
alternatively you could use the now() method of the datetime module, it
has a resolution of 1 microsecond
--
http://mail.python.org/mailman/listinfo/python-list
Ray Schumacher wrote:
I have a need for a time.clock() with >0.16 second (16us) accuracy.
The sleep() (on Python 2.3, Win32, at least) has a .001s limit.
Are they lower/better on other's platforms?
The meaning of time.clock() is entirely different on other platforms.
See the documentation. Yo
I have a need for a time.clock() with >0.16 second (16us) accuracy.
The sleep() (on Python 2.3, Win32, at least) has a .001s limit.
Are they lower/better on other's platforms?
Test code, 2.4GHz P4
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32
import time
t0
14 matches
Mail list logo
