Sturla Molden skrev:
I have a suggestion, forgive me if I am totally ignorant. :-)
Ah, damn... Since there is a GIL, we don't need any of that crappy
synchronization. And my code does not correct for the 20 ms time jitter
in GetSystemTimeAsFileTime. Sorry!
S.M.
__
Kristján Valur Jónsson skrev:
Thanks, I'll take a look in that direction.
I have a suggestion, forgive me if I am totally ignorant. :-)
Sturla Molden
#include
union __reftime {
double us;
__int64 bits;
};
static volatile union __reftime __ref_perftime, __ref_filetime;
doubl
Thanks, I'll take a look in that direction.
> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> I've even played with using Kalman filtering to do it... The idea is
> > to use the low frequency timer to apply correction coefficients to
> > the high frequency timer, yet
Kristján Valur Jónsson wrote:
> Yes. The problem with QPC is that although it has very high
> resolution, it is not precise in the long term. And
> GetSystemTimeAsFileTime() is high precision in the long term but only
> updated evey 20ms or so. In EVE Online we use a combination of the
> two for
> -Original Message-
> From: Mark Hammond [mailto:mhamm...@skippinet.com.au]
> Sent: 22. október 2009 10:58
> To: Kristján Valur Jónsson
> Cc: Scott Dial; python-dev@python.org
> It was made in the context of the APIs available to implement this.
> The
> code is short-and-sweet in timemod
M.-A. Lemburg egenix.com> writes:
>
> I'm not sure I understand why time.clock() should be considered
> broken.
Because in some cases you want comparable high-resolution numbers from distinct
processes.
> time.clock() is used for measuring process CPU time
According to the docs, under Windows
On 22/10/2009 3:45 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote:
I'd be very surprised if any applications rely on
the fact that each process starts counting at zero, so if someone can
come up with a high-res counter which avoids that artifact I'd expect it
On 22/10/2009 8:47 PM, Kristján Valur Jónsson wrote:
The point in question seems to be this this (from the thread):
* Need some sort of static "start value", which is set when the
process starts, so I can return to Python in seconds. An easy hack
is to set this the first time clock() is ca
Curt Hagenlocher wrote:
> On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou wrote:
>>
>> Kristján Valur Jónsson ccpgames.com> writes:
>>>
>>> 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.
>>> QueryPerformanceCo
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Robert Collins
> > I'd be very surprised if any applications rely on the fact that each
> > process starts counting at zero, so if
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Mark Hammond
> The thread seems to be at
> http://groups.google.com/group/comp.lang.python/browse_frm/thread/be324
> 78a4b8e77b6/8
Robert Collins robertcollins.net> writes:
>
> Could you offset it by the system time on the first call?
Two problems:
- the two measurements are not done simultaneously, so the result *still* does
not guarantee you have the same time reference in all processes (but gives you
the illusion you do,
On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote:
> I'd be very surprised if any applications rely on
> the fact that each process starts counting at zero, so if someone can
> come up with a high-res counter which avoids that artifact I'd expect it
> could be used.
Could you offset it by
On 22/10/2009 8:52 AM, Scott Dial wrote:
Curt Hagenlocher wrote:
But it makes more sense to
understand why someone chose to implement time.clock() on Windows the
way they did -- this seems very broken to me, and I think it should be
changed.
Some SVN detective work takes this to all the way ba
> Presumably you could fake something like this by combining output from
> an initial time(), an initial QueryPerformanceCounter() and the
> current QueryPerformanceCounter(). But it makes more sense to
> understand why someone chose to implement time.clock() on Windows the
> way they did -- this
Curt Hagenlocher wrote:
> But it makes more sense to
> understand why someone chose to implement time.clock() on Windows the
> way they did -- this seems very broken to me, and I think it should be
> changed.
Some SVN detective work takes this to all the way back to r7713
(1997-04-02). The origina
On Wed, Oct 21, 2009 at 1:51 PM, Antoine Pitrou wrote:
>
> Kristján Valur Jónsson ccpgames.com> writes:
>>
>> 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())
Kristján Valur Jónsson ccpgames.com> writes:
>
> 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 ind
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 diff
19 matches
Mail list logo
