Resolution of core.time.Duration...

[Steven Schveighoffer]

On Tue, 17 May 2011 09:55:49 -0400, Alexander <aldem+dmars at nk7.net> wrote:

> On 17.05.2011 15:25, Steven Schveighoffer wrote:
>
>> Plus, we have good precedence, both Microsoft and Tango use that tick  
>> duration.  It's a natural conclusion.
>
>   Linux/Posix are using ns (clock_gettime(), nanosleep() etc - timespec)  
> - I guess there is a reason for this.

I just read the man page on time (page 7) and indeed, there is support for  
sub-jiffy timing.  And Duration will support that notion quite well.  If  
you need sub-hnsec timing, you can call these functions directly.

The structures have used nanoseconds for over 10 years (I think  
gettimeofday used it back in the 90s!), so the reason for using it was  
likely for future compatibility (clearly nanosecond timing wasn't possible  
back then).  It looks like the future is now, so it's good to have that  
resolution.

I still maintain that for things like sleeping, it is pointless to sleep  
less than 100ns since it likely takes longer than that to do a context  
switch, and your sleep time is only guaranteed to be *greater* than what  
you requested.  The only time this is useful is for very specific  
real-time applications.  I could be wrong, there have obviously been  
improvements to the timing mechanisms of Linux since I last looked at it.

As for measuring time, yes, it would be good to use a higher precision  
timer.  And in fact, std.datetime.StopWatch does just that.

http://www.digitalmars.com/d/2.0/phobos/std_datetime.html#StopWatch

The core.time.Duration type is for low-level timing facilities, such as  
waiting on a condition or sleeping a thread.  It is also beneficial to  
re-use the structure in std.datetime for timing facilities that are  
generically useful for most cases.  This allows one to fluently do date  
calculations, timing calculations and pass them directly to low level  
facilities.  There will always be those cases where the time resolution is  
not enough, and for those cases, you will need to use a more specialized  
API.

Consider that Java, C#, and many other languages get by just fine with  
coarser resolution timing.  IMO dealing with times less than 1ms is pretty  
specialized.

>> Again, the resolution of the *structure* may be nsecs, but the actual  
>> intervals you have access to is about every 4ms on linux ( see  
>> http://en.wikipedia.org/wiki/Jiffy_(time) ).
>
>   Not really. Take a difference from two consecutive get_clock() calls  
> on Linux, and you will see that it is far below 1 µs (depends on CPU,  
> though). Not all systems use timer interrupt for timekeeping.

I stand corrected, I was not aware of these timing facilities.

>> I agree that accepting a long as an alternative to Duration, it makes  
>> sense to use a more normal tick resolution.  The chances of someone  
>> wanting to have their process sleep for more than 300 years (e.g. for  
>> nanosecond resolution) is pretty small.
>> This might be a worthwhile change.
>
>   Well, this is, actually, the whole reason of my post :) While 100ns  
> resolution seems reasonable (after your explanations), accepting 100ns  
> intervals as values directly seems not really good idea.

Yes, hnsecs is not a typical concept one has to deal with.

-Steve