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
