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
18 matches
Mail list logo
