Resolution of core.time.Duration...

[Dmitry Olshansky]

On 17.05.2011 15:44, Alexander wrote:
> On 17.05.2011 12:34, Jonathan M Davis wrote:
>
>> Also, the system clock definitely does not reach hnsecs on any system that I've seen.
>    Duration (unlike TickDuration) is not tied to system clock only, AFAIK (at least, this is not mentioned in the documentation).
>
>    Using rdtsc it is possible to obtain even more precision than 1ns.
Actually, rdtsc is limited and useful mostly for performance measures, 
and has it's fare share of caveats:
http://msdn.microsoft.com/en-us/library/ee417693.aspx
or more practical:
http://www.strchr.com/performance_measurements_with_rdtsc
(also there are processors with dynamic frequency...)

And like you said there are no APIs that use such precision.

>    Also, Duration can be used to store intervals which are not really related to system clock at all.
>
>> Or it would require splitting up the seconds and sub-seconds which makes the types take up
>> more space and makes the math that much worse.
>    OK, though I don't think that 4 or 8 bytes more will really make any noticeable change (many Phobos/druntime structures are over-sized anyway, IMHO) - time values are not used in big arrays, usually.
>
>    As to math - for most operations involving calendar computations only seconds are relevant, and math itself takes literally nanoseconds to execute - so only functions which actually require better precision may use more complex math.
>
The gain of using these fat integers is obscure so far. Unless, again, 
we are talking about small scale CPU performance measures.
>    What could be done, though - is to hide the internal format (hnsecs), i.e. do not expose it to functions like Thread.sleep() with ulong argument.
>
Right.
> /Alexander


-- 
Dmitry Olshansky