[Python-Dev] time.clock() on windows

[Kristján Valur Jónsson]

You are right, on windows time.clock() is based relative to its first call in the process.  There is no such promise made on unix.
QueryPerformanceCounter() (what time.clock uses()) is a robust high resolution timer that is processor/core independent.  It should be possible to use it across different processes too, if this annoying rebasing wasn't there.

I wonder if we should consider this a bug?

If so, I see three remedies:
1) simply using the absolute value and stop creating this arbitrary zero point.  this should be ok since the same is done on unix, but it would be a break from the documented behavior.  Never the less, the absolute value of this timer is irrelevant, it is the deltas that matter.
2) Add a flag to time.clock() for it to return absolute value
3) Create yet another api, either something like time.rclock() returning the absolute value or something like time.clockbase() returning the base of the zeroed clock timer.

If you just want to patch locally for your timing pleasure, change line 184 of timemodule.c to:
diff = (double)(now.QuadPart);

K

> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com at python.org
> [mailto:python-dev-bounces+kristjan=ccpgames.com at python.org] On Behalf
> Of Antoine Pitrou
>
 ---
> >
> > Background CPU task: Pi calculation (Python)
> >
> > CPU threads=0: 24727 ms. (std dev: 0 ms.)
> > CPU threads=1: 27930 ms. (std dev: 0 ms.)
> > CPU threads=2: 31029 ms. (std dev: 0 ms.)
> > CPU threads=3: 34170 ms. (std dev: 0 ms.)
> > CPU threads=4: 37292 ms. (std dev: 0 ms.)
> 
> Well apparently time.clock() has a per-process time reference, which
> makes it unusable for this benchmark :-(
> (the numbers above are obviously incorrect)
>