> -----Original Message-----
> From: gvanros...@gmail.com [mailto:gvanros...@gmail.com] On Behalf
> Of Guido van Rossum
> Sent: 2. apríl 2012 17:43
> To: Kristján Valur Jónsson
> Cc: Cameron Simpson; Python Dev
> Subject: Re: [Python-Dev] Use QueryPerformanceCounter() for
> time.monotonic() and/or time.highres()?
>
> You seem to have missed the episode where I explained that caching the last
> value in order to avoid going backwards doesn't work -- at least not if the
> cached value is internal to the API implementation.
>
Yes, and I can't find it by briefly searching my mail. I haven't had the
energy to follow every bit of this discussion because it has become completely
insane.
Of course we cannot promise not moving backwards, since there is a 64 bit
wraparound some years in the future. Otherwise, evidence contradicts your
claim.
Here's actual code from production:
BOOL WINAPI QueryPerformanceCounterCCP( LARGE_INTEGER* li )
{
static LARGE_INTEGER last = {0};
BOOL ok = QueryPerformanceCounter(li);
if( !ok )
{
return FALSE;
}
if( li->QuadPart > last.QuadPart )
{
last = *li;
}
else
{
*li = last;
}
return TRUE;
}
This has been running for many years on an incredible array of hardware and
operating systems. However, we mostly don't do this caching anymore, this code
is a rudiment. In all other places, a straight QPC is good enough for our
purposes. Even negative delta values of time are usually harmless on the
application level. A curiosity, but harmless. I am offering empirical
evidence here from hundreds of thousands of computers over six years: For
timing and benchmarking, QPC is good enough, and will only be as precise as the
hardware and operating system permits, which in practice is good enough.
Which is why am flabbergasted by all of this bikeshedding. My original
submission (http://bugs.python.org/issue10278) Is merely a suggestion to
provide a standardised clock function, useful for measuring the delta-t to the
best abilities of the platform. This is incredibly useful in many areas and
necessary because time.clock() currently means different things on different
operating systems.
There is no need to try to overspecify this to become something which it never
can be. If someone wants a real time clock with no time slew to control a
radio telescope, he better write his own interface to an atomic clock. What he
definitely shouldn't be doing is using a built in timer on an old computer with
an old operating system.
Also, since you objected to the original suggestion of time.wallclock(), here
is the definition from Wikipedia: http://en.wikipedia.org/wiki/Wall_clock_time
. I actually never read this before, but it agrees with my original definition
of relative passage of time in the real world. I got the term myself from
using profiling tools, which measure program execution in cpu time or wallclock
time.
Cheers,
Kristján
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
