Higher-resolution time for win32

[Andy Grundman]

On Jul 2, 2009, at 5:34 AM, Marc Lehmann wrote:

> On Wed, Jul 01, 2009 at 09:39:19PM -0400, Andy Grundman <andy at hybridized.org 
> > wrote:
>> Two problems with this patch:
>
> Actually, looking at it, it patches against the higher-resolution  
> clock
> alraedy in use in CVS. on the w2000, xp and vista amchiens I tested,
> the resolution is much higher than 1ms - are you sure it only has 1ms
> resolution?  In that case it might be worthwhile to investigate why  
> your
> machine has such a low resolution when the reslution approaches more  
> like
> 25µs over such a wide variatey of windows versions normally.

OK, before you dismiss it, here's the original problem I was trying to  
solve.  I was using Perl EV 3.6 which didn't have the latest CVS fix  
in it, and saw that the resolution was only 3 decimal places.  This  
causes some issues when trying to use EV::time instead of  
Time::HiRes::time for measuring execution time, for example.  I tried  
out the CVS version which improves this to 5 decimal places, but does  
not increase the value every time it's called, as happens with T::H.   
(libev would only increase the value every 1ms.)  That's the main  
issue I was trying to fix.  It's a very ugly hack but I'm not sure  
there is any other way of achieving the desired resolution. :(

> The method you propose is totally unworkable on multicore machines,  
> and
> requires special hardware to begin with. It cannot be used inside a
> portable library (if you google for a while, you will see that this  
> emthod
> is often implemented for a while in other libraries, and then removed,
> because it doesn't work in practise).

It seems to work fine on my quad-core Windows box in a single-threaded  
program, but yeah I see the potential issues.

> Also note that libev doesn't guarantee any higher precision then  
> around
> 1ms even on systems supporting higher resolutions.

Really?  I thought Linux/Mac would be fine in this respect.