On 18.05.2011 01:18, Jonathan M Davis wrote:
A monotonic clock is as good as you're going to get for accurate stopwatch
functionality. The system cannot possibly do any better than that. Context
switching can always get in the way. Increasing precision doesn't help that.
Probably, you
On 2011-05-18 02:13, Alexander wrote:
On 18.05.2011 01:18, Jonathan M Davis wrote:
A monotonic clock is as good as you're going to get for accurate
stopwatch functionality. The system cannot possibly do any better than
that. Context switching can always get in the way. Increasing precision
On 18.05.2011 12:12, Jonathan M Davis wrote:
To my knowledge, using the system's monotonic clock is the absolute best that
you're going to get for stuff like benchmarking.
It depends. If system is not busy, then it doesn't really matter - which
clock to use, especially if you take average
...why it is in hnsec? I know that this resolution is used in Win32 API (file
time), but since TickDuration may be 1 ns resolution, wouldn't it be better to
make Duration to be stored with maximum (defined so far) resolution?
Especially because Duration may not hold long intervals ( months) -
On 2011-05-17 03:15, Alexander wrote:
...why it is in hnsec? I know that this resolution is used in Win32 API
(file time), but since TickDuration may be 1 ns resolution, wouldn't it be
better to make Duration to be stored with maximum (defined so far)
resolution?
Especially because Duration
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
On Tue, 17 May 2011 06:15:54 -0400, Alexander aldem+dm...@nk7.net wrote:
...why it is in hnsec? I know that this resolution is used in Win32 API
(file time), but since TickDuration may be 1 ns resolution, wouldn't it
be better to make Duration to be stored with maximum (defined so far)
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
Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
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
On 17.05.2011 15:25, Steven Schveighoffer wrote:
if you use hnsecs, then you get a range of SysTime of -30k to 30k years.
That might seem overkill, but consider that even going to dnsecs (10
nanoseconds) reduces your range to -3k to +3k years. The problem is that
nobody is likely to care
On Tue, 17 May 2011 09:42:27 -0400, Daniel Gibson metalcae...@gmail.com
wrote:
Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
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
On Tue, 17 May 2011 09:55:49 -0400, Alexander aldem+dm...@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
On 17.05.2011 16:45, Steven Schveighoffer wrote:
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
On Tue, 17 May 2011 09:42:27 -0400, Daniel Gibson metalcae...@gmail.com
wrote:
Am 17.05.2011 15:25, schrieb Steven Schveighoffer:
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
On 17.05.2011 16:45, Steven Schveighoffer wrote:
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
On May 17, 2011, at 11:06 AM, Jonathan M Davis wrote:
I very much support the idea of deprecating all of the functions in druntime
and phobos which take naked time values. And then if a function that sleeps
at
nanosecond resolution is considered to be of real value (which I question),
On 2011-05-17 12:34, Sean Kelly wrote:
On May 17, 2011, at 11:06 AM, Jonathan M Davis wrote:
I very much support the idea of deprecating all of the functions in
druntime and phobos which take naked time values. And then if a function
that sleeps at nanosecond resolution is considered to be
On 17.05.2011 20:06, Jonathan M Davis wrote:
StopWatch uses a mononotonic clock.
Monotonic clock is not CPU-usage-bound - it is in sync with wall-time, so
problem on busy systems remains.
/Alexander
On 17.05.2011 20:06, Jonathan M Davis wrote:
StopWatch uses a mononotonic clock.
Monotonic clock is not CPU-usage-bound - it is in sync with wall-time, so
problem on busy systems remains.
A monotonic clock is as good as you're going to get for accurate stopwatch
functionality. The system
19 matches
Mail list logo
